AWSはAmazon Bedrock Managed Knowledge Baseを一般提供へ移行し、エンタープライズAIエージェントと検索拡張生成ワークロード向けのマネージドな検索層として位置づけています。この発表が重要なのは、エンタープライズAIシステムを本番投入するうえで最も厄介な領域の一つ、つまり散在する社内データの接続、混在する文書形式の解析、権限制御の適用、そしてチームが独自にベクター、グラフ、オーケストレーションのスタックを組み上げなくても信頼できる検索を実現することに取り組んでいるためです。

AWS Machine Learning Blogによれば、このサービスは開発者がナレッジベースを作成し、データソースを接続し、最小限の設定で取り込みを開始できるように設計されており、一方で後から埋め込み、リランカー、チャンク分割を調整したいチーム向けの深い制御も維持します。AWSは、デフォルト設定とマネージドインフラによって、しばしば数日から数週間かかるプロセスを数分に短縮するのが目標だと述べています。これはベンダーの主張ですが、AIデモから、根拠に基づく回答とポリシーを意識したアクセスを備えた本番システムへ移行しようとする企業にとって、実際の市場圧力を示しています。

AWSが発表した内容

今回の発表の中心にあるのはAmazon Bedrock Managed Knowledge Baseで、AWSはこれを完全マネージドのエージェント型検索サービスと説明しています。実務上は、取り込み、解析、保存、検索、アクセス制御をAmazon Bedrock内のAWS管理レイヤーに統合します。

同社によると、チームはもはやベクターデータベースを別途用意したり、類似度メトリクスを決めたり、スケーリングを管理したり、コネクタや検索インフラをつなぎ合わせたりする必要がありません。その代わり、このサービスは対応ソースからの取り込みを処理し、基盤となるストレージを自動的に管理し、シンプルな検索からより複雑な多段階検索までを対象とした検索APIを公開します。

AWSはこれを、エンタープライズ検索、社内コパイロット、エージェント型RAGシステム向けのインフラとして訴求しています。この位置づけは重要です。今回の発表は単なる新しい検索機能ではなく、AWSがAmazon Bedrockを、特にエージェントに会社文書を安全に参照させたいチーム向けの、エンタープライズAIアプリケーションのエンドツーエンド実行基盤としてより魅力的にしようとしていることを示しています。

ネイティブコネクタの一覧は、今回の発表の注目点です。AWSによると、Managed Knowledge Baseには現在、Amazon S3、Microsoft SharePoint、Atlassian Confluence、Google Drive、Microsoft OneDrive、Web Crawler向けのコネクタに加え、未対応ソース向けの直接取り込みAPIが含まれています。これらの統合は、企業知識の典型的なサイロをカバーしており、初期導入でしばしば摩擦が生じる部分です。

なぜ検索がエンタープライズAIの難所であり続けるのか

AWSのブログ記事が有用なのは、多くのチームがすでに身をもって知っている運用負荷を指摘しているからです。根拠のあるエンタープライズAIシステムを構築するには、通常、取り込みツール、文書パーサー、ストレージエンジン、埋め込みモデル、チャンク分割戦略、検索ロジックを選定し、そのうえで可観測性とセキュリティを重ねる必要があります。各選択は新たな統合面と運用依存を生みます。

Managed Knowledge Baseは、それらの意思決定を既定の経路に圧縮しようとするAWSの試みです。同社は、開始時にコンソールでモデルを選ぶ必要はなく、多くのチューニング判断を後回しにできると述べています。社内検索や質問応答ツールを迅速に立ち上げるプレッシャー下にあるプロダクトチームにとって、ここが最も価値ある部分かもしれません。

AWSは混在フォーマットの解析も強調しています。同社によれば、このサービスはPDF、PPT、PPTX、DOCXファイルなど最大500MBの視覚文書に加え、最大2GBの音声ファイル、最大10GBの動画ファイルを扱えます。さらに、表、チャート、図、混在レイアウト、メディア向けに自動で解析戦略を選択するとのことです。これが本番環境でうまく機能すれば、異なるエンタープライズコンテンツごとに別々の前処理パイプラインを維持する必要を減らせるでしょう。

同社のストレージ抽象化も重要な賭けです。基盤となるベクター層やグラフ層を直接管理させるのではなく、AWSは統合されたストレージ層を自動プロビジョニングし、自動スケールし、キーワード検索と意味検索を組み合わせたハイブリッド検索を継続的に有効化するとしています。これは、データベース内部の調整よりも回答品質とガバナンスを重視するエンタープライズチームに魅力的でしょう。

シンプルな検索とエージェントワークフローのための2つの検索経路

AWSは製品を2つの主な検索パターンに分けています。1つ目は標準のRetrieve APIで、ランク付けされたソースチャンクをメタデータと関連度スコア付きで返します。AWSは、これは直接参照、FAQ形式のやり取り、その他の低遅延シナリオを想定していると述べています。

2つ目は戦略的により重要なAgentic Retrievalです。AWSはこのモードが基盤モデルを使って複雑な質問をサブクエリに分解し、1つ以上のナレッジベースを横断して検索し、結果が十分かどうかを評価し、必要なら追加の検索ラウンドを実行すると説明しています。同社によれば、最終回答はマネージドなオーケストレーションモデル、またはAmazon Bedrock経由で利用可能な別のモデルを使って合成することもできます。

この設計は、市場全体の変化と一致しています。企業はますますAIエージェントに、単一の一節を取り出す以上のことを求めています。ポリシーを比較し、複数文書からの知見を統合し、リポジトリをまたぐ多段推論チェーンをたどれるシステムを求めているのです。AWSがこのオーケストレーションを十分信頼できるものにできれば、Amazon Bedrockは単なるモデルアクセス層ではなく、実用的なエージェント基盤としてより強い主張を持つことになります。

ただし、「agentic retrieval」は慎重に読むべきです。AWSは、計画、検索、評価のループがあり、デフォルトで最大5回の検索ラウンドが行われると説明しています。これは紙の上ではより高機能な検索を示唆しますが、同時にレイテンシ、コスト、障害要因を増やす可能性のある要素も増えます。引用資料には、検索品質、レイテンシ、コストを代替スタックと比較した独立ベンチマークは示されていませんでした。

セキュリティとエンタープライズ制御が提案の中心

今回の発表で最も強いエンタープライズ面は、セキュリティと権限の扱いです。AWSは、Managed Knowledge Baseが検索前ACLフィルタリングに加えてリアルタイムのACLチェックを使用すると述べています。同社によれば、事前にフィルタリングされた文書はAPI呼び出しの間だけ一時的なものであり、大規模言語モデルやユーザーには見えません。

このアーキテクチャが重要なのは、古い権限マッピングがエンタープライズ検索やRAGシステムでよくある問題だからです。検索層が、ソースの現在の権限を反映せずにコンテンツをインデックス化すると、従業員が本来見られない資料を見てしまう可能性があります。AWSは、クエリ時チェックが、古くなっている可能性のあるACLデータのコピーではなく、正本ソースに依存しているとしています。

暗号化もメッセージの一部です。AWSは、データが転送時および保存時にAWS KMSキーで暗号化され、AWS管理キーまたは顧客管理キーのいずれかを使えると述べています。これでデータ所在地、監査可能性、モデル挙動に関する購入者の懸念が完全に消えるわけではありませんが、すでにAWS中心で動くエンタープライズAI導入の調達要件には合致しています。

企業の購入担当者にとって、これが実際の購買理由かもしれません。すでに信頼しているソースシステムの近くでアクセス制御を適用しながら、根拠に基づく検索をより少ない労力で実現できる、という点です。

証拠、顧客の主張、そして未検証の点

このニュースの証拠はほぼすべてAWS管理下のソース、具体的にはAWSの報道とAWS Machine Learning Blogに由来します。つまり、セットアップ時間、検索品質、スケール、顧客利用に関する最も好意的な主張は、独立確認がない限りベンダー報告として扱うべきです。

AWSはSyngenta GroupとMRH Troweの顧客コメントを掲載しました。Syngenta Groupのある幹部は、同社がBedrock Managed Knowledge Basesを使い、SharePointとConfluenceのデータを用いて従業員がオンデマンドでナレッジベースを作成し、社内検索やエージェント型RAGアプリケーションに活用していると述べています。MRH Troweは、この製品を、英語とドイツ語のコンテンツにまたがるConfluenceとSharePointの数千件の文書を対象とした社内AIコパイロットに使っていると述べました。

AWSはまた、OpenAIに帰属する発言として、Bedrock Managed Knowledge BasesのRAG機能を使って、正しい顧客コンテキストで数百万人のユーザー向けに推論とモデル応答を大規模に根拠付けていると記載しました。これは発表の中で最も目を引く導入シグナルですが、ソース資料にはデプロイの詳細、範囲、時期、独立検証は含まれていません。提示されている形では、これはベンダー公開の顧客コメントであり、報じられた提携事例ではありません。

また、発表資料に欠けているものも重要です。AWSは、引用された証拠の中で第三者ベンチマークデータ、自社管理型検索スタックとの比較、明確な価格例を示しませんでした。Amazon Bedrockを競合と比較する開発者にとって、これらの欠落は、総コスト、調整の柔軟性、エンタープライズ負荷下での実際の検索品質に関する疑問を残します。

開発者とエンタープライズチームにとっての意味

AI開発者にとって、この発表は初期の製品開発で必要なインフラ作業の大部分を減らす可能性があります。社内コパイロット、ワークフロー支援ツール、AIエージェントを作るチームは、プロンプトやアプリのロジックよりも、取り込みと権限設定に多くの時間を費やしがちです。Amazon Bedrock内のマネージドな経路があれば、より速くプロトタイプを作成し、アーキテクチャの多くを一つのクラウド契約内に保てるかもしれません。

エンタープライズアーキテクトにとっては、トレードオフはおなじみです。マネージドサービスは運用負荷を下げますが、上級チームが直接制御したい実装詳細を抽象化してしまいます。ベクターストアを選んだり調整したりしなくてよいことを歓迎する企業もあるでしょう。一方で、特にすでに独自のRAGインフラを使っている場合は、検索データベース、インデックス作成、チャンク分割パイプライン、リランキングスタックを明示的に制御したいと考える企業もあります。

Microsoft SharePoint、Atlassian Confluence、Google Drive、Microsoft OneDrive、Amazon S3のサポートにより、この製品は社内ナレッジ検索プロジェクトにすぐ有用です。Web Crawlerオプションは、プライベートなリポジトリを超えて範囲を広げるため、社内情報と公開情報を組み合わせる必要があるエージェントに役立つでしょう。ただし、ノイズの多い文書、多言語コーパス、ドメイン特有の用語をどれだけうまく扱えるかは、購入者が引き続き検証する必要があります。

市場の観点では、AWSはエンタープライズAIインフラは、個別ツールの集合体よりも、マネージドなアプリケーションプラットフォームのように見えるべきだという主張を強めています。Amazon Bedrockがより多くの機能を取り込むほど、スタンドアロンの検索ベンダーは利便性だけで競争するのが難しくなります。これはAWSが品質や価格で必ず勝つことを意味しませんが、RAGエコシステム全体への圧力は高まります。

今後注目すべき点

次に注目すべきシグナルは、レトリックよりも実務的なものです。まず価格の明確さです。取り込み、検索、エージェントオーケストレーションを含めた場合、Managed Knowledge Baseは総導入コストを下げるのでしょうか。次に検索品質です。AWSには、Agentic Retrievalが実際のエンタープライズ業務でどう機能するかを示す参照アーキテクチャ、ベンチマークデータ、独立した事例が必要になるでしょう。

第三に、コネクタの拡充が重要です。現在の一覧は有用ですが、企業データが6か所だけに存在することはほとんどありません。第四に、ガバナンス機能が重要な争点になります。監査ログ、ポリシー制御、失敗した検索チェーンのデバッグツールなどです。最後に、AWSがこのサービスを、Amazon Bedrock全体のAIエージェント向け広範な標準レイヤーに育てるのか、それとも独立した検索機能のままにするのかを見守る必要があります。

Creati.aiの視点

今回の発表は、エンタープライズAIにおける実際のボトルネックに対処しています。検索インフラは依然として断片化が激しく、多くのプロダクトチームが短期間で運用可能にするには不十分です。AWSは、取り込み、権限、解析、保存、多段階検索をAmazon Bedrockにまとめることで、根拠に基づくエンタープライズAIを個別統合ではなくデフォルトで導入可能にしようとしています。

未解決の問題は、利便性が確実な性能につながるかどうかです。エンタープライズ購入者は、設定の簡単さだけでマネージド検索層を採用しません。彼らは、Amazon Bedrockが、雑然とした現実の条件下で、一貫した関連性、正しいアクセス制御、許容できるレイテンシを提供できる証拠を求めます。AWSがそれを示せれば、Managed Knowledge Baseは、大企業におけるAIエージェント向けインフラの中でも特に重要な要素の一つになる可能性があります。