公開：2026年10月6日, 最終更新：2026年10月6日
30秒サマリー
- 単一ベクトル検索では複数意図を含む質問の一部しか回収できない構造的限界がある
- Amazon Bedrock Managed Knowledge Baseのエージェント型検索APIが複数サブクエリへの分解・再検索を自動実行する
- LangChainから両APIを使い分ける実装手順と、コスト・レイテンシの使い分け基準をAWSが解説
何が起きたか
AWSはMachine Learning公式ブログにて、LangChainとAmazon Bedrock Managed Knowledge Baseを組み合わせた「エージェント型RAG（Retrieval Augmented Generation）」の実装方法を解説する記事を公開した。
記事は、従来の単一ベクトル検索（Retrieve API）の構造的限界を具体的に示す。例として「チェックアウトサービスとインベントリサービスを3つの軸で比較して」という質問は実質6つの意図を含むが、1つの埋め込みベクトルで代表させると検索結果5件では6意図中4つしかカバーできず、2つが欠落すると報告されている。10件に増やすと全6意図を網羅するものの、重複や無関係なチャンクも混入するとされる。
これに対しエージェント型検索は、Amazon Bedrock Managed Knowledge Baseが提供する「AgenticRetrieveStream API」を通じて機能する。同APIは質問を自動的にサブクエリへ分解し、証拠が十分かを自己判定して必要なら再検索するプランニングループを実行し、各ステップをトレースイベントとしてストリーム返却する。langchain-awsパッケージでは`agentic_retrieve`という独立した関数として実装されており、標準のLangChainリトリーバー（`AmazonKnowledgeBasesRetriever`）とは別のインターフェースとなっている。
実装上の注意点として、エージェント型検索が文書全体を取得する「FullDocumentExpansion」ステップを実行する際に`bedrock:GetDocumentContent`権限が必要であること、Boto3は1.43.32以上が必要であること、マネージドナレッジベースでは`vectorSearchConfiguration`ではなく`managedSearchConfiguration`を使うべきことなどが指摘されている。
原典ハイライト
「1つのベクトルで6つの意図を表現することはできず、取得した証拠が質問に答えるのに十分かどうかを確認するステップがプロセスに存在しない」という構造的限界を明示したうえで、エージェント型検索がサブクエリ分解・再検索・トレース出力の3機能でこれを克服すると解説している。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
従来のRAGは「質問が1つの意図に集中している」という暗黙の前提に依存しており、複合的な比較質問・多軸分析に対しては構造的に回答品質が低下する。エージェント型検索はその前提を排し、計画→実行→自己評価→再検索のループをモデル側で完結させる。ただし記事はコストとレイテンシが増加する点も明示しており、単純な1意図クエリには従来の単一検索が依然として適切とされている。
日本企業への示唆
社内文書検索・カスタマーサポート・調達比較など、複数製品・複数条件を同時に問い合わせる業務ユースケースでは、従来型RAGの回答漏れが品質問題として顕在化しやすい。エージェント型検索の導入検討にあたっては、①クエリの複雑度分布を事前に分析し単純・複合で振り分けるハイブリッド設計、②IAM権限設計（特に`bedrock:GetDocumentContent`の付与漏れ）、③Boto3バージョン管理（1.43.32以上）の3点を優先的に確認すべきである。コスト増を抑えるため、すべてのクエリをエージェント型に統一せず、意図数が多いと判定されたクエリのみ自動ルーティングする設計が現実的とみられる。
背景・経緯
Amazon Bedrock Managed Knowledge Baseは、ベクトルストアや埋め込みモデルの自己管理を不要にするフルマネージドRAG機能として提供されている。今回の解説記事はその機能の1つとして位置づけられるエージェント型検索（AgenticRetrieveStream API）の実装ガイドであり、既存のLangChainエコシステムとの統合方法を中心に構成されている。なお、エージェント型検索機能がいつ一般提供開始されたかは原文では明示されていない。
