Amazon Bedrock でエージェント向け検索基盤を構築

エンタープライズデータ上でエージェントや生成 AI アプリケーションを根付かせる知識基盤（Knowledge Base）を、大規模に構築するのは容易ではありません。多くのチームは、コネクタ、パーサー、ベクトルストア、知識グラフ、検索ロジックをつなぎ合わせ、それを生産環境向けに運用化しようとします。しかし、それぞれの要素には固有の課題が伴います。

どのデータソースを接続し、マルチモーダルなドキュメントタイプをどうパースするかを決める必要があります。また、グラフ型データベースとベクトルデータベースのどちらを選ぶか、さらにそれらをプロビジョニングしてスケールさせる判断も迫られます。多様なコンテンツにわたって推論を行う複雑なクエリへの対応に加え、生産環境で求められるドキュメントレベルのアクセス制御、観測性（Observability）、セキュリティを層として積み重ねる必要もあります。

Amazon Bedrock は現在、一般提供を開始した Managed Knowledge Base を通じて、スケーリング、高精度な検索、ドキュメントレベルのアクセス制御を代行する、完全に管理されたエージェント向け検索ソリューションを提供しています。エンタープライズデータソースを接続するか、ウェブをクロールしてデータを取り込むだけで利用可能です。

AWS Management Console を介した初期設定では、モデルの選択は不要です。適切なデフォルト設定により、ゼロから同等のパイプラインを組み上げるのに通常数日〜数週間かかるところを、数分で最初の検索機能を実現できます。必要に応じてカスタマイズする際は、埋め込みモデル（Embedding Model）、再ランク付け器（Reranker）、チャンキング戦略などを自由に制御可能です。

本稿では、この実現を可能にする3 つの柱——セットアップの簡素化、検索の高度化、そして本番環境での実用性——について解説します。また、知識ベースの構築とそこから情報を取得するためのコード例も紹介します。

セットアップの簡素化

現在、開発者はデータ取り込みパイプラインやベクトル・グラフストレージ、検索インフラをそれぞれ調達・構築するのが一般的です。つまり、別々のインフラを管理し、異なる課金モデルやレート制限に対応し、それらを一つの整合性のあるパイプラインに組み上げるという複雑な作業を背負うことになります。

Managed Knowledge Base（マネージド知識ベース）はこの複雑さを抽象化して隠蔽します。知識ベースを設定するだけで、ネイティブコネクタを通じてエンタープライズデータを取得することから、ベクトルストアの管理まで、その後のすべての処理をサービスが自動的に担当してくれます。

ACL サポート付きのネイティブエンタープライズコネクタ

Managed Knowledge Base には、Amazon S3、Microsoft SharePoint、Atlassian Confluence、Google Drive、Microsoft OneDrive、そして Web クローラーの 6 つのコネクタが標準で用意されています。また、対応するソースに存在しないドキュメントを直接取り込むための API も提供しており、柔軟なデータ連携が可能です。

Sync（同期）処理は、変更されたファイルや新規ファイルのみを対象とするため、処理時間の短縮、コスト削減、そして情報の鮮度維持を実現しています。

Managed Knowledge Base では、既存の検索前フィルタリングに加え、リアルタイムでのアクセス制御リスト（ACL）チェックをセキュリティ層として追加しています。検索前にフィルタリングされたドキュメントは、API 呼び出しの期間中のみ一時的に存在し、大規模言語モデル（LLM）やユーザーには表示されません。

この仕組みにより、古くなったりマッピングが正しくなかったりする ACL データに依存するのではなく、クエリ実行時に権限情報源と直接照合することで、最新のアクセス制御を確実に維持します。

シンゲンタグループは、Bedrock Managed Knowledge Bases を活用し、従業員がオンデマンドでナレッジベースを構築できるようにしています。SharePoint や Confluence からのデータ同期により、社内検索やエージェント型 RAG アプリケーションの基盤となっています。

– ジェイソン・クローン氏（データおよび AI テクノロジー担当責任者）

MRH トロウエは、Bedrock Managed Knowledge Bases を活用した内部 AI コパイロットを運用しています。これにより、従業員は社内のナレッジベース全体から、即座に根拠のある回答を得ることができます。対象となるのは Confluence や SharePoint に保存された数千件の文書で、英語とドイツ語の両方に対応しています。ネイティブコネクタと組み込みのアクセス制御機能を活用することで、カスタムの検索パイプラインを構築することなく、社内規定や顧客ドキュメント、業務関連コンテンツを検索可能に。これにより、従業員が顧客対応に必要な知識へ迅速にアクセスできる環境を整えています。

– マルテ・ポッリー博士（データ分析および AI チームリーダー）

多様なデータ形式の解析

データは、Web アプリケーション内の機械可読コンテンツから、PDF や PPTX、DOCX といった埋め込み画像を含むデジタルファイル、スキャンされた文書、さらに音声や動画などのメディアまで、多種多様なフォーマットに散在しています。それぞれの形式ごとに個別のパイプラインを構築するのではなく、Managed Knowledge Base はコンテンツの種類に応じて最適な解析戦略を自動的に選択する、完全マネージド型の解析機能を提供します。

テーブル、グラフ、図表、複雑なレイアウト、そしてメディアコンテンツの処理も、ユーザーが設定を行う必要はありません。このサービスは、最大 500 MB の画像を含む文書（PDF、PPT/PPTX、DOCX）、最大 2 GB の音声ファイル、そして最大 10 GB の動画ファイルをサポートしています。

解析が完了すると、サービスは検索可能なセグメントへとデータを分割します。デフォルトでは、Managed Knowledge Base がデータに最も適したチャンキング（分割）戦略を自動的に決定します。もしデータの特性を理解しており、より細かな制御を行いたい場合は、固定サイズのトークン数で分割する「固定サイズ・チャンキング」や、すでに前処理済みまたは分割済みの文書に対しては「チャンキングなし」といったカスタム戦略を選択することも可能です。

サービス管理型データストレージ

知識検索パイプラインにおいて、セマンティック検索用データベースの選定は最も複雑な判断の一つです。各選択肢には、パフォーマンス特性や課金モデル、スケーリング能力、機能セットなどが異なります。一度選択した後も、容量の割り当て、インデックス設定、バックアップ管理、そして時間経過に伴う性能チューニングなど、多くの作業が残ります。

Managed Knowledge Base（マネージド・ナレッジベース）は、こうした手間をすべて不要にする統合ストレージ層を提供します。このサービスはストレージを自動でプロビジョニングするため、ベクトルの次元や類似度計算の指標を手動で指定する必要はありません。また、ギガバイトからテラバイト規模まで、介入なしに自動的にスケールします。キーワード検索とセマンティック検索を組み合わせたハイブリッド検索も常時有効になっており、別途インデックスを設定して管理する必要もありません。データは、AWS Key Management Service (AWS KMS) のキー（AWS 管理型または顧客管理型のいずれか）を用いて、保存時および転送時に暗号化されます。

ユーザーが直接基盤となるストレージと対話することはありません。監視、チューニング、バックアップ、パッチ適用、容量管理といった作業はすべて AWS サービス側で自動的に処理されます。

*OpenAI は、Bedrock Managed Knowledge Base の RAG 機能を活用し、数百万人のユーザーに対して、適切な顧客コンテキストを反映した信頼性の高い推論とモデル応答を実現しています。*

– Lavanya Singh, OpenAI テクニカルスタッフ

3 ステップでセットアップ

プログラムを通じて管理型ナレッジベースを構築する方法を見ていきましょう。必要な API コールはたったの 3 つです。まずはナレッジベースを作成し、次にデータソースを追加して、最後に取り込み（インジェスト）を開始するだけです。

以下の例では、Amazon S3 をデータソースとして使用し、完全に管理された埋め込みモデルを採用しています。この構成では、モデルの Amazon Resource Name (ARN) やベクトルストア、チャンキング設定を手動で指定する必要はありません。

import boto3

bedrock_agent = boto3.client('bedrock-agent', region_name='us-west-2')

# ステップ 1: 完全管理型のナレッジベースを作成（ゼロ構成）
kb_response = bedrock_agent.create_knowledge_base(
    name='my-managed-kb',
    description='Product documentation knowledge base',
    roleArn='arn:aws:iam::123456789012:role/BedrockKBRole',
    knowledgeBaseConfiguration={
        'type': 'MANAGED',
        'managedKnowledgeBaseConfiguration': {
            'embeddingModelType': 'MANAGED'
        }
    }
)
kb_id = kb_response['knowledgeBase']['knowledgeBaseId']

# ステップ 2: S3 データソースを追加
ds_response = bedrock_agent.create_data_source(
    knowledgeBaseId=kb_id,
    name='my-s3-docs',
    dataSourceConfiguration={
        'type': 'S3',
        's3Configuration': {
            'bucketArn': 'arn:aws:s3:::amzn-s3-demo-bucket',
            'inclusionPrefixes': ['documents/']
        }
    }
)
data_source_id = ds_response['dataSource']['dataSourceId']

# ステップ 3: 取り込みジョブを開始
bedrock_agent.start_ingestion_job(
    knowledgeBaseId=kb_id,
    dataSourceId=data_source_id
)

より賢い検索

1 回の検索ステップだけですべての質問に答えることはできません。単純な直接照会なら単独でも機能しますが、比較分析や多段階推論、調査系のクエリにはさらに深い処理が必要です。Managed Knowledge Base では、複雑さのレベルに応じて設計された 2 つの検索 API を提供しています。

• Retrieve は、関連度スコアとメタデータ付きでランク付けされたソースチャンクを返します。直接照会や FAQ 形式の質問、低レイテンシが重要なシナリオに適しています。取得結果の数を手動で制御でき、検索範囲を絞り込むためのメタデータフィルタも適用可能です。

• Agentic Retrieval は、基盤モデル（FM）を活用して複雑なクエリをサブクエリに分解します。1 つまたは複数の知識ベースに対して反復的に検索を実行し、取得結果が十分かどうかを評価した上で返却します。また、Managed Orchestration LLM または Amazon Bedrock 上の任意のモデルを用いて、情報を統合した回答も生成できます。比較分析や多段階質問、調査系クエリ、あるいは複数のソースや文書からの情報を統合する必要があるシナリオで威力を発揮します。

Agentic Retrieval の仕組み

製品の比較、複数文書にわたる意思決定の追跡、異なるソースからの研究結果の統合には、複数の検索ステップが必要です。さらに、中間結果を評価し、「これで十分な情報がある」と判断するタイミングを見極めることも不可欠です。

Agentic Retrieval は、1 つまたは複数の知識ベースにまたがってこれらの処理を自動で実行します。クエリが入力されると、サービスは以下のように動作します：

クエリを分析して分解し、設定された各ナレッジベースに対して特定の検索を実行するサブクエリを作成します。

複数のナレッジベースに対して並列でサブクエリを実行し、結果を取得します。

取得した結果が十分かどうかを評価します。不十分な場合は、追加の検索ラウンドを計画・実行します（デフォルトでは最大 5 回まで）。

すべての反復処理から重複を除いたチャンクを返送し、追跡イベントをストリーミングして完全な可視性を確保します。

ユースケースに応じて、精度とレイテンシのバランスを調整できます。maxAgentIteration パラメータでモデルが実行する検索ラウンド数を制御し、計画と評価に使用するファウンデーションモデルを選択できます。

以下のコードは、エージェント型検索（Agentic Retrieval）の呼び出し例とそのストリーミング応答の処理を示しています。リクエストでは、ユーザーのクエリ、検索対象のナレッジベース、計画・評価用のファウンデーションモデル、および最大検索反復回数を指定します。サービス実行中は、各計画ステップとサブクエリの実行状況を示す追跡イベントがストリーミングされ、最終的な検索結果が表示されます：

bedrock_runtime = boto3.client('bedrock-agent-runtime', region_name='us-west-2')

Amazon Bedrock の Managed Knowledge Base を活用し、エージェント向けの企業検索機能を構築する方法について解説します（10 月 14 日更新）。

以下は、製品 A と B の価格比較を要求するユーザーのメッセージに基づき、Bedrock Runtime がエージェント検索ストリームを実行するコード例です。この処理では、指定された Knowledge Base から最大 10 件の結果を取得し、Anthropic の Claude Sonnet モデル（arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-sonnet-4-20250514）を基盤モデルとして使用します。エージェントの反復回数は最大 5 回（デフォルト値、範囲は 1〜10）に設定されています。

response = bedrock_runtime.agentic_retrieve_stream(
    messages=[{
        'role': 'user',
        'content': [{'text': 'Compare the pricing tiers of Product A and Product B'}]
    }],
    retrievers=[{
        'knowledgeBaseRetriever': {
            'knowledgeBaseId': kb_id,
            'maxResults': 10
        }
    }],
    agenticRetrieveConfiguration={
        'foundationModel': {
            'modelArn': 'arn:aws:bedrock:us-west-2::foundation-model/anthropic.claude-sonnet-4-20250514'
        },
        'maxAgentIteration': 5  # 1-10, default 5
    }
)

# Trace events stream in real time, then final results arrive
for event in response['stream']:
    if 'trace' in event:
        trace = event['trace']
        if 'planning' in trace:
            print(f"Planning: {len(trace['planning'].get('actions', []))} sub-queries")
        elif 'retrieval' in trace:
            print(f"Retrieving: {trace['retrieval'].get('input', {}).get('text', '')}")
    elif 'retrievalResults' in event:
        results = event['retrievalResults']['results']
        print(f"\n{len(results)} deduplicated results returned")
        for i, r in enumerate(results[:5], 1):
            print(f"  {i}. {r['content']['text'][:150]}...")

このコードでは、ストリームからリアルタイムでトレースイベントを監視し、最終結果が到着する様子を出力します。具体的には、エージェントの「計画」段階で生成されたサブクエリの数や、「検索」段階で入力されたテキスト内容を確認できます。また、検索結果が返却される際には、重複を除いた結果件数が表示され、先頭 5 件のコンテンツ（各 150 文字以内）がリスト形式で出力されます。

このように、Managed Knowledge Base を用いることで、エージェントが複雑なタスクを分解し、必要な情報を効率的に取得・統合するプロセスを可視化しながら制御することが可能になります。

## 本番環境対応

Retrieval Augmented Generation (RAG) のプロトタイプを動かすことと、適切なアクセス制御や可視性（オバザビリティ）、セキュリティを備えた状態で大規模運用を開始することは、別問題です。多くのチームが後者の段階でつまずきます。

Managed Knowledge Base には、AgentCore Gateway [への統合](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html) やドキュメントレベルのアクセス制御、可視性機能が標準で備わっています。これらのレイヤーを自前で構築する必要なく、すぐにデプロイ可能です。

## AgentCore Gateway とのネイティブ統合

Managed Knowledge Base は AgentCore Gateway とネイティブに連携しており、知識ベースをエージェントへ公開するためのスムーズな手段を提供します。Gateway 上で知識ベースをターゲットとして追加すると、Model Context Protocol (MCP) に準拠したエージェントがそれを自動的に検出し、呼び出せるツールとなります。

AWS の [Identity and Access Management](https://aws.amazon.com/iam/)（IAM）やルーティング、可視性は Gateway 上で一元管理されます。また、ユースケースによってはアプリケーション側から直接検索 API を呼び出すことで、Managed Knowledge Base をスタンドアローンで利用することも可能です。

AgentCore Gateway は、Managed Knowledge Base の統合に以下の機能を追加します：

インフラの抽象化：基盤となる知識ベース ID はゲートウェイの背後に隠されるため、エージェントは名前だけでツールを発見・呼び出すことができます。これにより、エージェントコードと基盤インフラが切り離されます。

フレームワークとの互換性：エージェントは標準化された MCP エンドポイントを通じて相互作用するため、Strands や LangChain、CrewAI といった MCP 対応フレームワークと知識ベースを即座に連携させることが可能です。

統一されたアクセスポイント：組織全体で単一のゲートウェイ URL を知識ベースのアクセスポイントとして利用できます。これにより、エージェントの設定やガバナンスが大幅に簡素化されます。

集中管理によるセキュリティ：個別の知識ベースごとの権限管理ではなく、ゲートウェイレベルでの IAM ポリシーを採用します。これにより、セキュリティの適用、アクセス監査、スケーリング管理を一元で実行できます。

運用の透明性：監視機能、ルーティング、認証はすべてシステムが自動的に処理するため、エージェントコードを一行も変更せずに、知識ベースの追加・置換やスケールアップが可能になります。

![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/06/19/ML-20588-3.png)

ゲートウェイを作成し、知識ベースをターゲットとして追加した後、MCP 対応のエージェントフレームワークは、基盤となる知識ベース ID を知らなくても発見・呼び出しが可能になります。

```python
from strands.tools.mcp import MCPClient
from mcp_proxy_for_aws.client import aws_iam_streamablehttp_client

mcp_client = MCPClient(lambda: aws_iam_streamablehttp_client(

endpoint=gateway_url,

aws_region='us-west-2',

aws_service='bedrock-agentcore',

))

with mcp_client:

# KB tools are auto-discovered via MCP

tools = mcp_client.list_tools_sync()

print(f"Available tools: {[t.tool_name for t in tools]}")

# Retrieve (the agent never sees the KB ID)

result = mcp_client.call_tool_sync(

'tool_call_1',

tools[0].tool_name,

{'retrievalQuery': {'text': 'What is our total revenue?'}},

)

このパターンは、Strands、LangChain、CrewAI、あるいは他の MCP 対応フレームワークでも動作します。ゲートウェイが IAM（アイアム）、ルーティング、観測性をシームレスに処理する仕組みです。

*ソニーグループでは、Amazon Bedrock AgentCore を活用したエージェント型チャットプラットフォームを構築しています。これにより、チームは複雑な企業コンテンツや最新のウェブ情報から信頼できる回答を得られるようになります。Bedrock Managed Knowledge Base と Web Search が AgentCore のツールとして利用可能になったことで、エージェントは内部の PDF やプレゼン資料、スプレッドシート、グラフ、表などを横断して推論できるようになりました。単なるベクトル検索を超え、データを AWS 内に保持したまま最新のウェブ情報を根拠に回答を生成します。社内知識とウェブ情報の両方に対応できる、一つの体験を提供するのです*。

– Masahiro Oba, ソニーグループ株式会社 シニアゼネラルマネージャー

オブザーバビリティ

SDK を通じてでもゲートウェイ経由であっても、すべてのナレッジベースへのクエリは自動的に AWS/Bedrock/KnowledgeBases 名前空間下の Amazon CloudWatch にメトリクスを公開します。具体的には、呼び出し回数やクライアント・サーバー側のエラー、スロットリング（過負荷による制限）などのデータが取得可能です。

特に Agentic Retrieval（エージェント型検索）においては、計画ステップ、サブクエリ、評価ラウンドなど、各処理の詳細なトレースイベントがリアルタイムでストリーミングされます。これにより、インストルメンテーションコードを記述することなく、検索プロセス全体を可視化できます。

完全なエンドツーエンドの解説については、GitHub 上の ノートブック をご覧ください。

Managed Knowledge Base の位置づけ

AWS には、エージェントや生成 AI アプリケーション、RAG パイプラインの基盤となる知識検索を構築するための複数の選択肢が用意されています。どのオプションを選ぶべきかは、「自分で制御したい範囲」と「管理（マネージド）に任せたい範囲」のバランスによって決まります。

以下の図は、Managed Knowledge Base がそのスペクトラム上でどのような位置を占めているかを示しています。これは、最高レベルの抽象化を提供する Amazon Quick から、ゼロから RAG パイプラインを構築する場合までを横断したものです。

もしあなたが