Amazon Bedrock Managed Knowledge Baseが示すエージェント検索基盤｜社内データ連携をどう本番化するか

目次

---

1. 社内検索は「チャットの補助」からエージェントの実行基盤へ変わる

生成AIを社内に入れるとき、多くの企業はまず「社内文書を検索できるチャット」を作ります。規程を聞く。提案書の過去事例を探す。手順書から答えを出す。これは便利ですが、AIエージェントの本番活用が始まると、社内検索の役割はそれだけでは足りなくなります。

エージェントは、単に回答するだけでなく、CRMを更新したり、稟議の下書きを作ったり、問い合わせを分類したり、担当者へ引き継いだりします。その前提になるのは、エージェントが社内データを正しい権限で参照し、根拠を持って判断できることです。検索結果が古い、権限外の文書が混ざる、根拠を追えない、ログが残らない状態では、エージェントに業務を任せるほどリスクが増えます。

AWSは2026年7月16日、Amazon Bedrock Managed Knowledge Baseの一般提供を公式ブログで発表しました。AWSの発表によると、このサービスは企業データに対するエージェント型検索をマネージドで提供し、スケーリング、高精度な検索、文書レベルのアクセス制御をAWS側で扱う構成です。従来は、コネクタ、パーサー、ベクトルストア、検索ロジック、監視、セキュリティを個別に組み合わせる必要がありましたが、Managed Knowledge Baseはこの重い土台づくりをまとめて引き受ける方向へ踏み込んでいます。

今回の発表で注目したいのは、RAGが「文書検索の部品」ではなく「エージェントが使う社内データ基盤」として整備され始めた点です。企業側の論点も、どのベクトルDBを使うかだけではなく、どのデータに接続し、どの権限で検索し、どのログを残し、どのエージェントに使わせるかへ移っていきます。

2. AWSが発表したManaged Knowledge Baseの要点

AWSの公式発表では、Managed Knowledge Baseの価値を大きく3つに整理しています。1つ目はセットアップの簡素化、2つ目はより賢い検索、3つ目は本番運用への対応です。開発者が個別にデータ取り込み、ベクトルまたはグラフ系ストレージ、検索インフラを調達してつなぐのではなく、ナレッジベースを設定すると、データ取り込みからストレージ管理までをサービス側が扱うという考え方です。

データ接続では、Amazon S3、Microsoft SharePoint、Atlassian Confluence、Google Drive、Microsoft OneDrive、Web Crawlerの6つのネイティブコネクタが示されています。対応ソースにない文書については、直接取り込みAPIも使えると説明されています。さらに、2回目以降の同期では変更または新規文書だけを処理するため、取り込み時間、コスト、情報の古さを抑えやすくなります。

アクセス制御も重要なポイントです。AWSの発表では、既存の事前検索ACLフィルタリングに加え、クエリ時に権威あるソースへ直接権限を確認するリアルタイムACLチェックを使うとされています。検索候補として事前に絞られた文書はAPI呼び出しの期間だけ一時的に扱われ、大規模言語モデルやユーザーから見えない設計だと説明されています。RAGでよく問題になる「インデックス時点の権限が古くなる」リスクに対し、かなり実務寄りの回答です。

検索機能については、単純な類似検索だけではなく、複雑な質問に対するエージェント型検索が前提になっています。AWSの発表では、通常の検索APIに加え、複数段の推論が必要な場合にAgentic Retrievalを使う価格体系も説明されています。社内規程の一問一答なら単純検索で足りても、複数文書をまたいで矛盾や条件を確認する業務では、検索そのものが推論を含む方向へ進んでいくことがわかります。

本番対応としては、文書レベルのアクセス制御、リアルタイムACLチェック、Amazon CloudWatchによる可観測性が組み込まれているとされています。また、AgentCore Gatewayとのネイティブ統合により、ナレッジベースをMCP互換エージェントがカスタムコードなしで発見し、ツールとして利用できる点も示されました。対応リージョンには、米国、欧州、シドニー、ロンドンなどに加え、ap-northeast-1、つまり東京リージョンも含まれています。

AWSの発表では、Syngenta GroupがSharePointとConfluenceのデータ同期を使った社内ナレッジ検索やAgentic RAGアプリケーションに活用していること、MRH TroweがConfluenceとSharePointにまたがる企業ナレッジから、英語とドイツ語の文書を対象に内部AI Copilotを動かしていることも紹介されています。ここでの主役はチャットUIではなく、社内データをエージェントに渡すための管理された検索基盤です。

3. なぜエージェント時代の検索基盤として重要なのか

企業のAI活用では、最初のPoCがうまくいっても、本番展開でつまずくことがよくあります。理由はモデル性能だけではありません。社内データが複数の場所に分散している。文書の更新頻度が部署ごとに違う。権限がファイル、フォルダ、グループ、プロジェクト単位で入り組んでいる。検索ログや回答ログをどこまで残すかが決まっていない。こうした運用課題が、チャットの裏側で一気に表面化します。

特にAIエージェントでは、検索の失敗がそのまま実行の失敗につながります。古い契約テンプレートを参照して稟議文を作る。権限外の顧客資料をもとに営業メールを下書きする。根拠が曖昧なまま問い合わせ回答を送る。人間が検索結果を見て判断するだけなら途中で気づけることも、エージェントが次の操作まで進むと事故になりやすくなります。

Managed Knowledge Baseのような仕組みが重要なのは、RAGの部品を減らせるからだけではありません。検索、アクセス制御、監視、エージェント連携を同じ運用面で扱えることに意味があります。たとえば、SharePointやConfluenceの権限を見ながら検索し、CloudWatchで利用状況を追い、MCP互換エージェントからツールとして呼び出す。この流れが標準化されると、企業は「検索基盤を毎回作る」段階から「業務ごとのデータと権限を設計する」段階へ移れます。

日本企業にとっては、東京リージョン対応も見逃せません。すべての要件がリージョンだけで解決するわけではありませんが、社内文書、営業資料、規程、顧客対応ナレッジを扱うAI基盤では、データ所在地、監査、ネットワーク、既存AWS環境との接続が重要になります。すでにAWS上に業務基盤を持つ企業なら、社内検索やエージェント基盤を既存のIAM、ログ、監視、ネットワーク設計に寄せやすくなります。

もう一つの示唆は、RAGの評価軸が変わることです。これまでは「正しい文書を検索できるか」「回答が自然か」が中心でした。今後はそこに、「権限が現在の状態と一致しているか」「エージェントがどの検索を使ったか」「複雑な質問で複数文書をどうたどったか」「コストとレイテンシが業務に合うか」が加わります。検索基盤は、AI活用の裏方ではなく、業務自動化の信頼性を決める中核になります。

4. 導入時に決めるべき設計ポイント

導入時に最初に決めるべきなのは、対象データの範囲です。社内FAQだけを扱うのか、営業資料、提案書、契約書、問い合わせ履歴、設計書まで広げるのかで、必要なコネクタ、権限、更新頻度、評価方法が変わります。Managed Knowledge Baseは複数のネイティブコネクタを持ちますが、つながることと使えることは別です。どのデータが業務判断に使える品質か、古い文書やドラフトをどう扱うかを先に決める必要があります。

次に、権限モデルを設計します。RAGでは、検索前に権限で絞るのか、検索後に回答生成前で絞るのか、ログにどこまで残すのかが重要です。AWSの発表ではリアルタイムACLチェックが強調されていますが、企業側でも元システムの権限設計が整理されていなければ、AI基盤だけでは解決できません。部署異動、プロジェクト終了、外部委託先のアクセス、退職者の権限削除まで含め、元データ側の統制を整える必要があります。

エージェント連携の設計も早めに決めるべきです。ナレッジベースを人間向けチャットで使うだけなら、質問と回答の品質を中心に見れば足ります。しかし、MCP互換エージェントがツールとして使うなら、検索ツールの説明、入力パラメータ、返す根拠、失敗時のふるまい、アクセス拒否時のメッセージまで設計対象になります。エージェントが「検索できなかった」ことを「情報が存在しない」と誤解しないようにすることも重要です。

運用面では、検索モードの使い分けが必要です。単純な規程確認やFAQは標準的な検索でよいかもしれません。一方、複数文書をまたいで条件を確認する、過去事例と現在のルールを照合する、顧客別の資料と共通テンプレートを突き合わせる、といった用途ではAgentic Retrievalのような複雑な検索が効きます。ただし、複雑な検索はコストや応答時間にも影響します。全リクエストを高機能な検索に寄せるのではなく、業務リスクと検索難度で使い分けるべきです。

PoCでは、きれいな文書だけを入れて精度を見るのではなく、実際に混ざる文書を入れることが大切です。古い手順書、部署限定資料、重複した提案書、英語資料、スキャンPDF、似た名前のファイルを含めて評価します。質問も、答えがあるものだけでは足りません。答えてはいけない質問、権限がない質問、複数文書を見ないと答えられない質問を用意すると、本番化のリスクが見えます。

5. 運用で見落としやすい注意点

Managed Knowledge Baseのようなマネージドサービスは、基盤づくりを大きく楽にします。ただし、サービスが運用のすべてを肩代わりしてくれるわけではありません。企業側が決めるべきことは残ります。特に重要なのは、データの責任者、権限の責任者、回答品質の責任者を分けて考えることです。

データの責任者は、どの文書を検索対象に入れるかを決めます。古い資料を残すのか、最新版だけを使うのか、草稿や個人メモを除外するのか。ここが曖昧だと、AIは技術的には正しく検索していても、業務上は使ってはいけない文書を根拠にしてしまいます。社内検索の品質は、モデルだけでなく、文書管理の品質に強く依存します。

権限の責任者は、元システムのアクセス制御が業務実態と合っているかを確認します。リアルタイムACLチェックがあっても、SharePointやConfluence側で権限が広すぎれば、その広さがAIにも反映されます。AI導入をきっかけに、これまで人間の目では見過ごされていた権限のゆるさが問題になることがあります。

回答品質の責任者は、検索結果と生成回答を継続的に評価します。エージェントが使う検索基盤では、正解率だけでなく、検索できなかったときの挙動、根拠の示し方、古い文書を避ける動き、低信頼時の人間確認が重要です。特に、顧客対応、法務、医療、金融、人事のような領域では、AIが答える範囲と、人間へ引き継ぐ条件を明確にする必要があります。

コストにも注意が必要です。AWSの発表では、raw dataのストレージ、標準検索API呼び出し、複数段推論が必要なAgentic Retrievalなどの利用に応じた価格体系が示されています。マルチモーダル文書パーサー、管理されたEmbeddingモデル、管理されたリランカーは追加費用なしと説明されていますが、別のAmazon BedrockモデルをEmbedding、リランキング、オーケストレーションに使う場合は標準のBedrock料金が適用されます。PoCでは安く見えても、本番で利用者数や検索回数が増えると費用構造が変わります。

最後に、エージェントに接続する範囲を急に広げすぎないことです。検索基盤が整うと、さまざまなエージェントから使わせたくなります。しかし、営業支援エージェント、問い合わせ対応エージェント、開発支援エージェント、人事エージェントでは、参照してよい文書もログの扱いも違います。最初は読み取り専用の支援から始め、業務システムへの書き込みや外部送信を伴う場合は、人間承認と監査ログを必ず挟むべきです。

6. まとめ

Amazon Bedrock Managed Knowledge Baseの一般提供は、RAGが単なる検索機能から、AIエージェントの実行を支える社内データ基盤へ進んでいることを示しています。AWSの発表では、ネイティブコネクタ、変更差分同期、リアルタイムACLチェック、CloudWatchによる可観測性、AgentCore Gatewayを通じたMCP互換エージェント連携、東京リージョンを含む複数リージョン対応が示されました。

企業が見るべきポイントは、サービス名そのものよりも、自社の社内データをエージェントにどう安全に渡すかです。どの文書を対象にするか。権限をどう保つか。検索ログと回答ログをどう残すか。複雑な検索をどの業務に使うか。AIが答えられないときにどう止めるか。ここを決めずに検索基盤だけ導入しても、本番運用では必ず迷いが出ます。

OpenBridgeでは、社内RAG、AIナレッジ検索、AIエージェント、MCP連携、アクセス制御、監査ログを含めたAIシステム開発を支援しています。エージェント時代の社内検索基盤は、便利なチャットを作る話ではなく、業務データを安全に使える形へ整える設計課題です。最初のPoCでは、機能の多さよりも、対象業務、権限、評価、運用責任を具体化することが成功の近道になります。