- エージェントが推論し、複数の知識ベースから選んで反復検索する構成
- AgentCore Gatewayが各KBの検索をMCPツールとして公開し、Lambda不要
- 7層の可観測性と評価を組み込み、CloudFormationで一括デプロイ
背景：RAGからエージェント型検索へ
従来のRAGは、1回の検索と1回の生成を行うだけだった。複雑な質問や複数の情報源をまたぐ質問には、エージェントが推論して検索先を選び、反復して情報を集め、引用付きで回答する「エージェント型検索」が有効だ。しかし、エージェントが推論と検索を繰り返すと、何をしたかや回答の品質を把握しにくくなるという運用上の課題が生じる。
この記事で紹介するソリューションは、Amazon BedrockのマネージドKnowledge Baseが提供するAgenticRetrieveStream APIを中核としている。検索ルーティングや反復検索をエージェントに任せつつ、可観測性と評価を組み込んでいるのが特徴だ。本記事では、デプロイ手順とアーキテクチャを順に解説する。
アーキテクチャと2つの知識ベース
ソリューションは4つのCloudFormationスタックで構成される。01-knowledge-basesはS3バケットと財務・天気の2つのマネージドKnowledge Baseを作成する。02-agentic-gatewayはAgentCore Gatewayをセットアップし、各知識ベースをMCPツールとして公開する。03-agent-runtimeはエージェントのコンテナイメージをCodeBuildでビルドし、04-dashboardsがCloudWatchダッシュボードを展開する。
知識ベースを2つ用意するのは、エージェントが質問のトピックに応じてどちらを参照するかを選ぶ「セマンティックルーティング」を実際に動かすためだ。1つの知識ベースに2つのデータソースを入れる構成だと、ルーティングの判断が発生しない。2つの独立した知識ベースを用意することで、ルーティングの効果を明確に観測できる。
データセットには、合成の財務10-K報告書と、米国議会調査局の竜巻に関する公開レポートが含まれる。それぞれ約198KBと約560KBで、意図的に異なる分野にしている。このため、エージェントが質問の内容に応じて正しい知識ベースを選択できるかを試せる。
可観測性と評価の設計
エージェントの推論と検索のループは、AgentCoreランタイムがOpenTelemetryスパンを自動生成するため、最初の呼び出しから観測できる。さらに、送信元のスパンはCloudWatch Transaction Searchに送られ、レイテンシ、トークン使用量、検索品質などの7層のテレメトリとしてダッシュボードに表示される。これにより、ブラックボックス化しがちなエージェントの動作を可視化できる。
評価はオンデマンドと継続の2種類を用意する。継続的な評価は本番トラフィックを使い、回答の品質を継続的に測る仕組みだ。これらも同じCloudFormationテンプレートでプロビジョニングされるため、環境ごとに再現しやすい。
デプロイの前提条件と注意点
デプロイは1コマンドで実行できるが、事前にAWS CLI v2、Python 3.13、Amazon Bedrockのモデルアクセス、CloudWatch Transaction Searchの有効化が必要だ。記事の例ではus-west-2リージョンを使い、デフォルトのモデルはus.anthropic.claude-haiku-4-5-20251001-v1:0となっている。前提条件を満たせば、デプロイスクリプトが4つのスタックを順に作成する。
実際のデプロイでは、03-agent-runtimeがエージェントコンテナをCodeBuildでビルドするため、その段階だけで8〜10分程度かかる。運用に移す前に、生成されたダッシュボードのURLで各層のメトリクスを確認するのがよい。また、各スタックの出力を次のスタックに配線するため、デプロイ順序は自動的に制御される。
Once an agent reasons and retrieves in a loop, you can no longer see what it did or whether the answer was any good.
エージェントが推論と検索をループで行うようになると、何をしたのか、回答が良かったのかを、もはや把握できなくなります。
今後の見通し
今回のサンプルは、エージェント型検索の実装と監視を一つのCloudFormationチェーンで展開できることを示している。今後は、複数の知識ベースが増えたときのルーティング精度や、評価指標をビジネスKPIとどう結びつけるかが焦点になるとみられる。また、Amazon Bedrock AgentCoreやManaged Knowledge Baseの対応リージョンが拡大すれば、日本国内での採用も進むだろう。実際の運用データが蓄積されれば、どの層のテレメトリが有効だったかが明らかになり、本番適用の判断材料になる。
日本の開発者・IT企業にとっての意味
日本のIT企業にとって、エージェント型検索は問い合わせ対応や社内ナレッジ活用に有用だが、運用の複雑さが導入の壁になりがちだ。このソリューションは、マネージドサービスとCloudFormationによって、検索基盤の構築と監視を自動化している。ベクトルデータベースの運用を省けるため、既存のRAGより保守負荷を下げられる可能性がある。また、OpenTelemetryとCloudWatchを組み合わせた7層の可観測性は、本番適用時に必要なトレーサビリティを提供する。日本企業がエージェント型AIを業務に組み込む際の参考実装として、検証する価値がある。
気になる点
- このソリューションは、AWSのどのリージョンで利用できますか？
- 記事の例ではus-west-2を使用しています。対応リージョンはAmazon Bedrockの公式情報を確認する必要があります。記事にはそれ以外のリージョン記載はありません。
- デプロイにはどのような前提条件がありますか？
- AWSアカウントの各種権限に加え、Amazon Bedrockのモデルアクセス、CloudWatch Transaction Searchの有効化、AWS CLI v2、Python 3.13（boto3>=1.43）が必要です。また、CodeBuildによるコンテナビルドのため、デプロイに8〜10分程度かかります。
- 既存のRAGシステムから移行する際の注意点は？
- マネージドKnowledge BaseではベクトルDBの管理が不要になります。ただし、既存システムとの移行手順やコストは記事には明記されていないため、AWSのドキュメントで確認する必要があります。
用語解説
- RAG
- 大規模言語モデルが外部の知識ベースを検索し、その結果を踏まえて回答を生成する技術。
- エージェント型検索
- エージェントが質問を分析し、複数の知識ベースから適切なものを選んで反復検索した上で回答を生成する方式。
- Managed Knowledge Base
- Amazon BedrockがベクトルDBの管理を代行し、文書の取り込み・埋め込み・インデックス作成を自動で行うサービス。
- AgentCore
- Amazon Bedrockのエージェント実行基盤。エージェントのホスティングとMCPによるツール連携を提供する。
- MCP
- Model Context Protocolの略。エージェントと外部ツールを接続するためのプロトコル。
- OpenTelemetry
- 分散トレースやメトリクスを収集するためのオープンソースの計装規格。
出典
Build observable enterprise agentic retrieval using Managed Amazon Bedrock Knowledge Base with AWS CloudFormation
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する