Amazon Bedrock、単発RAGと検索専用モードを追加

Amazon Web Servicesは、Bedrock Managed Knowledge Baseを更新し、1つのAPIエンドポイントを通じて3つの異なる検索モードをサポートするようにしました。2026年11月9日にリリースされたこの変更により、開発者はパラメータを1つ調整するだけで、エージェント型計画、単発生成、または生の文章検索の間から選択できるようになります。今回のアップデートは、単純なクエリにおける遅延とコストを削減しつつ、複雑なタスク向けの深い推論能力を維持することを目的としています。

何が起きたか

従来、Amazon Bedrock上で検索拡張生成（RAG）アプリケーションを開発する場合、ユーザーからの質問の種類に応じて個別のコードパスやAPIを管理する必要がありました。「特定のチェックリスト項目を見つける」といった単純な参照処理でも、「複数の検索イテレーションを必要とする複雑な比較質問」と同じ重いオーケストレーションが適用されていました。この画一的なアプローチでは、単純なリクエストに対して不要な遅延が発生し、モデルの使用量も増えていました。

今回のアップデートでは、AgenticRetrieveStream APIに maxAgentIteration パラメータが導入され、値の範囲は0から5まで設定可能になりました。この1つの設定で検索プロセスの挙動を制御できます。値を1に設定すると「単発RAG」がトリガーされ、エージェント型の計画やクエリの書き換えを行うことなく、1回の検索のみで回答を生成します。値を0に設定すると「検索専用」モードが有効になり、基盤モデルを呼び出さずにソースとなる文章のみを返します。2から5までの値を設定した場合は、システムが計画を立てて複数回の検索を実行する既存のエージェント型検索動作が維持されます。

この統合により、アプリケーション側で単純なクエリと複雑なクエリを区別するためのセカンドAPIとの連携や、個別のロジック分岐を維持する必要がなくなりました。サービス側がワークフローを内部で管理するため、開発者は各リクエストの具体的なニーズに合わせて検索の労力を動的に調整できます。発表文にもある通り、「アプリケーション側でこれらのステップを調整するための独自ループを実装する必要はありません。」

仕組み

中核となるメカニズムは、システムのイテレーションカウント方法に基づいています。1回のイテレーションは、1回の基盤モデル呼び出しに相当します。応答生成が有効な場合、プロセスは必ず最終的な回答生成のための呼び出しで完了します。したがって、maxAgentIteration の値が n の場合、最大で n 回 minus 1 回のエージェント型計画ラウンドが許可され、最後のイテレーションは最終応答生成のために予約されます。重要な点として、プロセス高速化のため最初の計画ステップより前に実行される投機的検索（speculative retrieval）は、この制限にはカウントされないことに注意してください。

maxAgentIteration が1に設定されると、システムは計画フェーズを完全にバイパスします。元のクエリに基づいて関連する文章を一度だけ取得し、それを即座に基盤モデルに渡して回答を生成します。これは、答えが単一のドキュメントやセクションに存在するような、範囲が明確な質問に適しています。0に設定された場合、システムは保証された1回の検索を実行しますが、基盤モデルの呼び出しはスキップし、生のテキスト文章のみを返します。これはRetrieve APIを直接呼び出すのと同等ですが、ワークフローは AgenticRetrieveStream インターフェース内に留まります。

2から5までの値の場合、基盤モデルがプランナーとして機能します。複雑な質問をサブクエリに分解し、取得された証拠を評価して、さらなる検索が必要かどうかを判断します。この反復的なプロセスは情報のギャップを埋めるのに役立ち、異なるドキュメント間の比較や多部分的な質問に適しています。開発者はパラメータ自体による自動ルーティングに頼るのではなく、アプリケーションロジックを通じてモードを選択します。

主要な詳細

• maxAgentIteration パラメータは現在、0から5までの値を受け入れ、以前の限定的な範囲を置き換えています。
• maxAgentIteration=1 に設定すると単発RAGが有効になり、計画ラウンドなしで1回の検索と1回の回答生成を実行します。
• maxAgentIteration=0 に設定すると検索専用モードが有効になり、基盤モデルの呼び出しなしで文章を返します。この場合、generateResponse は false でなければなりません。
• エージェント型検索（値2〜5）では、最大で n 回 minus 1 回の計画ラウンドが許可され、クエリの分解と反復的な証拠収集をサポートします。
• すべての3つのモードは複数のナレッジベースをサポートしているため、単発検索が単一のデータソースに限定されることはありません。
• 最初の計画ステップの前に発生する投機的検索は、maxAgentIteration の制限にはカウントされません。

なぜ重要なのか

AIアシスタントを構築するソフトウェアエンジニアにとって、このアップデートはアーキテクチャを簡素化し、コスト効率を向上させます。以前は、単純なクエリに対する低遅延レスポンスを最適化するために、より複雑なエージェント型システムとは別に軽量な検索パイプラインを構築する必要がありました。しかし今後は、1つのAPI呼び出しで両方のシナリオを処理できます。これにより、複数の統合を維持する運用オーバーヘッドが削減され、すべてのクエリタイプにおいて引用とトレースイベントの一貫した処理が保証されます。

モード間を切り替える機能により、速度と精度のトレードオフに対するより細かな制御が可能になります。カスタマーサポートボットや社内エンタープライズ検索ツールなどの大量トラフィックを扱うアプリケーションでは、ほとんどのクエリは単純な事実確認である可能性が高いです。これらのリクエストに単発RAGを使用することで、トークン消費量と応答時間を削減できます。一方、複数のドキュメント間の相互参照が必要な少数の複雑なクエリについては、開発者はイテレーション制限を動的に増加させて、徹底性を確保できます。この柔軟性により、リソース配分の改善と、よりレスポンシブなユーザー体験の実現が可能になります。

できること

• agenticRetrieveConfiguration オブジェクト内の AgenticRetrieveStream 呼び出しを更新し、maxAgentIteration パラメータを含めてください。
• 範囲が明確な直接的な質問に対しては、maxAgentIteration=1 と generateResponse=true を設定して単発RAGを有効にします。
• AIサマリーを生成せずにユーザーにソース文章を表示する必要がある場合は、maxAgentIteration=0 と generateResponse=false を設定します。
• 異なるドキュメントやナレッジベース間で情報を比較する必要がある複雑な多部分的な質問には、2から5までの値を使用します。
• 代表的な質問を用いて異なるイテレーション制限をテストし、特定のユースケースにおける遅延と回答品質の最適なバランスを見つけてください。
• APIによる自動検出に頼るのではなく、クエリの複雑さに基づいて適切なモードを決定するよう、アプリケーションロジックを整備してください。