エージェントに最新情報をどう持たせるか — Managed KB / Web Search / 自前検索を"鮮度とリージョン"で使い分ける設計
社内に無い最新情報をエージェントに持たせるなら、知識源は鮮度とリージョンで決まります。特定リージョン要件ではWeb Searchが使えずKB、最新性が必須ならWeb Search。データの所在・ガバナンス・コストの形まで含めた使い分けの判断軸を、どれかを礼賛せず中立に整理します。
- #AgentCore
- #Web Search
- #Managed Knowledge Base
- #グラウンディング
- #RAG
- #鮮度
- #データガバナンス
- #設計判断
エージェントに、モデルの学習データには無い「自社の知識」や「いまの最新情報」を持たせたいとき、知識源（グラウンディングの手段）をどう選ぶかは設計の分かれ道になります。2026年6月17日、Amazon Bedrock Managed Knowledge Base（以下、Managed KB）と Web Search on Amazon Bedrock AgentCore がそれぞれ一般提供（GA）となり、選択肢が公式に出そろいました。ところが公式は、これらの「使い分け」を比較してくれません。本記事は機能紹介ではなく、Managed KB・Web Search・自前検索を、鮮度とリージョンを軸にどう使い分けるかの判断軸に重心を置きます。どれかを礼賛せず、客観・中立で整理します。
3つの選択肢の実体
まず、3つの手段が何であるかを正確に押さえます。
Managed KB は、ベクトルデータベースやデータパイプライン、検索インフラを自分で管理せずにRAG（検索で補強した生成）を構築できる、フルマネージドのサービスです。S3・SharePoint・Confluence・Google Drive・OneDrive・Web Crawler の6種のコネクタでデータを取り込み、自動で同期します。重要な性質として、これは取り込んで索引した「スナップショット（同期した時点のデータ）」を検索する仕組みです。Web Crawler コネクタで公開ウェブを取り込めますが（シードURLは最大10件）、これも索引済みスナップショットであって、ライブ検索ではありません。
Web Search on AgentCore は、エージェントの応答を最新のウェブ知識に都度ライブで接地するマネージドのツールです。返り値には、関連するスニペットに加えて、出典のURL・タイトル・公開日が含まれ、引用付きで推論に使えます。さらに、ユーザープロンプトや検索クエリをAWS外の外部検索APIへ送らずに済む「zero data egress（データを外部へ出さない）」を満たせる点が特徴です。
自前検索 は、公式サービスではなく設計上の選択肢です。外部の検索APIや自社の検索基盤を自分で呼び出します。最大の制御とカスタム性が得られる代わりに、データ持ち出し・ガバナンス・インフラ運用・コストをすべて自分で負います。Web Searchが提供する「マネージドかつ zero data egress」の裏返しと捉えると位置づけが分かりやすくなります。
この3つを分ける最も実務的な違いは、「索引済みスナップショットか、都度ライブか」です。KBは取り込んだ時点のデータを検索し、Web Searchはクエリのたびに最新のウェブを引きます。この一点が、後述する鮮度要件への適合を直接左右します。
グラウンディングの判断軸6つ
公式が使い分けを示さない以上、自分で判断軸を持つ必要があります。次の6つで整理できます。
- データの所在: 知りたいのは自社内データか、公開ウェブか。自社データ中心ならKB、公開ウェブの最新ならWeb Search。
- 鮮度: 同期したスナップショットで足りるか、都度最新が要るか。
- ガバナンス: プロンプトやクエリをAWS外へ出せるか。
- リージョン: どのリージョンで動かす要件か。
- コストの形: 保有量に比例するのか、クエリ回数に比例するのか。
- 制御: 検索ロジックやランキングを自分で握る必要があるか。
このうち、実務で選択を強く縛るのが次の2軸、鮮度とリージョンです。
鮮度×リージョンが選択を規定する
本記事の背骨はここにあります。鮮度とリージョンの2軸が、しばしば他の検討を飛び越えて選択を決めます。
鮮度の軸では、社内文書・規程・FAQのように同期したスナップショットで足りるならKBが向き、価格・ニュース・最新仕様のように都度最新が必須ならWeb Searchが向きます。ここでKBのWeb Crawlerを「ウェブだからライブ」と誤解しないことが要点です。Web Crawler はあくまで索引スナップショットで、最新性は同期の頻度に依存します。
リージョンの軸はさらに直接的です。Managed KB は東京（Asia Pacific Tokyo）を含む複数リージョンで使えますが、Web Search は GA 時点で US East（バージニア北部）に限定されています。したがって、東京リージョンに閉じる要件がある案件では、最新性が欲しくてもWeb Searchを選びにくく、KBへ寄せる判断になりがちです。なお、Web Searchの対応リージョン拡大について公式の告知は見当たらないため、「いずれ東京でも使える」と憶測はしません。最新の対応状況は公式情報で確認してください。
二択でなく役割分担
ここまでを踏まえると、3つは「どれか一つを選ぶ」ものではなく、役割分担で組み合わせるのが自然です。自社の確定した知識はKBに、最新の公開情報はWeb Searchに担わせ、エージェントの別々のツールとして両方を持たせる構成が現実的です。AgentCore 上では、KBもWeb Searchもエージェントのツールとして接続できます。
たとえば、社内規程やナレッジは同期したKBに持たせて確定情報として扱い、相場や最新の公開仕様が必要になった場面だけWeb Searchを呼ぶ、という構成です。エージェントから見れば、確定知識を引くツールと、最新情報を引くツールを使い分けているだけで、どちらか一方に寄せる必要はありません。
自前検索が要るのは、特殊なデータソースや独自のランキング・ソース選別を自分で握りたい場面です。マネージドの枠で足りるならKBやWeb Searchに委ね、枠を超える制御が必要なときだけ自前を選ぶ、という線引きになります。自前を本格的に検討する段階では、費用構造の組み立てを別記事に整理しているので、そちらも参照してください。
採用前に知る落とし穴
選択を誤らないために、3つの落とし穴を押さえます。これらはデータガバナンスの要件を負う層ほど効いてきます。
第一に、Web Crawler はライブではない点です。KBに公開ウェブを取り込んでも、それは索引スナップショットであり、都度最新の検索とは別物です。ここを混同すると、鮮度要件を満たせていないのに満たした気になります。
第二に、Web Search の US East 限定です。前述のとおり、東京要件と最新性要件が同時にある場合は、現時点で両立しにくいというトレードオフを直視する必要があります。
第三に、コストの形の違いです。Managed KB は「保有するデータ量と検索の回数」に対する従量で、Web Search は「クエリ回数」に対する従量です（公式の参考値として、2026年6月時点で1,000クエリあたり7ドル、新規は最大200ドル相当の無料枠。いずれも改定され得るため料金ページで時点確認してください）。クエリ量が多いワークロードでは、per-query 課金の積み上がりが効いてきます。
そして、データ持ち出しの要件があるなら、Web Search の zero data egress が選択の決め手になります。プロンプトや検索クエリをAWS外へ出せない規制業界・エンタープライズでは、この一点が手段を絞り込みます。自前検索を選ぶなら、この egress とガバナンスを自分で設計しきれるかを問う必要があります。
自環境への当て方（チェックリスト）
判断軸を、自分の環境への当てはめとして整理します。
| 要件 | KB | Web Search | 自前検索 |
|---|---|---|---|
| 主に見るデータ | 自社内データ | 公開ウェブの最新 | 特殊ソース |
| 鮮度 | スナップショットで足りる | 都度ライブが必須 | 自分で制御 |
| リージョン | 東京を含む | US East 限定（時点） | 自分で選ぶ |
| データ持ち出し | 自社データ内 | zero data egress | 自分で設計 |
| コストの形 | 保有量×検索回数 | クエリ回数（per-query） | 自インフラ＋API |
| 制御 | マネージドの枠 | マネージドの枠 | 最大の制御 |
迷ったときは、まず鮮度とリージョンで候補を絞り、次にガバナンスとコストの形で確定する、という順で当てると整理しやすくなります。
まとめ — 次に読む
エージェントの知識源は、Managed KB・Web Search・自前検索を、鮮度とリージョンを軸に使い分けます。東京要件ではWeb Searchが使えずKBへ、最新性が必須ならWeb Searchへ。KBは索引スナップショット、Web Searchは都度ライブで、コストの形も違います。そして三者は二択ではなく、自社の確定知識と最新の公開情報を役割分担させるのが自然です。データ持ち出し要件があれば、zero data egress が選択を決めます。
自社データのRAGを「自前で組むかマネージドに載せるか」という一段下の判断はRAGはマネージドか自前かに、自前RAGを選ぶ場合の費用構造はRAGアーキテクチャのTCO設計に整理しています。なお、検索を担う専用エージェントに役割を割って協調させる設計（単一 vs マルチエージェント）も隣接テーマですが、こちらは公開後にあらためてご案内します。