はじめに
AWS Summit NewYorkで以下の新機能、アップデートが発表されました。
早速試してみましたので、ぜひ読んでみてください。
どんなアップデートか
AgentCore Gatewayからナレッジベースをツールとして利用可能に
AgentCore Gatewayのターゲットとしてナレッジベースが選択可能になりました！
そして、いきなり東京リージョンでも利用可能です！
今まではAgentCoreからRAGやナレッジベースを組み込む場合、以下のように神野さんがやってくれているのですがひと工夫が必要な場合があります。
ですが今回のアプデによってGatewayの組み込み機能の一つとして気軽に利用できるのは嬉しいですね。
具体的には、Gatewayにナレッジベースをターゲットとして登録するだけで、エージェントは MCP（Model Context Protocol）を通じて、検索ツールとして使えるようになります。
Managed KB というのができた
今までタイプとしてはManaged KBというのはありませんでした。
今回のターゲットとして利用する場合、このManaged KBに対応したナレッジベースが必要になります。なので、新規に作成が必要になります。
ちなみに既存のナレッジベースのタイプを確認すると、こんな感じで区別できます。
aws bedrock-agent get-knowledge-base \
--knowledge-base-id <KB_ID> --region us-west-2 \
--query 'knowledgeBase.knowledgeBaseConfiguration.type'
-
MANAGED… 今回のコネクタ対応（ストレージはAWSが完全管理） -
VECTOR… 従来型（OpenSearch / S3 Vectors などを自前で持つ）→ コネクタ非対応
なので、手持ちの VECTOR 型KBは流用できず、MANAGED 型を新規作成する必要がありました。
選べる二種類の検索手法
ナレッジベース作成時に「Runtime retrieval type」として2種類から選べます。
-
Standard retrieval
1回のハイブリッド検索（キーワード＋ベクトル）で、最も関連性の高い箇所を出典情報とともに返す（今までのいつも通りのRAGのイメージ）。コネクタではRetrieveツールとして公開されます。 -
Agentic retrieval（今回新しく利用可能に）
質問を「タスク」として扱い、検索戦略を計画 → 複数回検索 → 必要なら全文展開 → 引用付きの合成回答 をストリーミングで返す、複数ステップのエージェント検索。コネクタではAgenticRetrieveStreamツールとして公開されます。
※発表時のコンソール表記や記事によっては2つの説明が入れ替わって見えることがありますが、「単発のハイブリッド検索 = Standard」「計画して複数回検索＋合成回答 = Agentic」と覚えるのが正確です。
※Standard retrieval（従来のRAG）でも引用表示とかはやってたのでは？
「出典（ソース）を表示する」だけなら Standard でもできます。 Retrieve の結果には各チャンクごとに location（S3のURIなど）・score・metadata が付いてくるので、「どの文書から取ってきたか」は従来から分かります。
では Agentic の引用は何が違うのか。ポイントは2つです。
- 回答そのものをサービス側が合成して返す（Standardはチャンクを返すだけで、回答は自分やLLMが書く）
-
回答テキストのスパン単位の引用（
citationsにstartIndex/endIndexが入り、「回答の○文字目〜△文字目はこの根拠が出典」という対応づけまで返す）
つまり「出典リストを出す」のは両方できるが、「回答の“この一文”はこの出典」という粒度の引用と回答の自動生成が Agentic の本質的な差、という整理になります。
ちなみに、Agentic retrievalを実施してみた時の回答が以下です。非常に長い。
ですが、これをお手軽実装できるには確かに嬉しいかも...
ここに回答全部あります
質問: AgentCoreのベストプラクティスについて教えて
============================================================
回答（全文）:
AgentCoreのベストプラクティスについて、検索結果から包括的な情報をまとめてお答えします。
Amazon Bedrock AgentCoreには、セキュリティ、パフォーマンス、運用の各側面で推奨されるベストプラクティスがあります。
## セキュリティのベストプラクティス
**セッション分離とデータ保護**
- セッションIDを一貫して使用し、関連するリクエスト間でコンテキストを維持します
- 認証された主体からユーザーIDを導出し、任意のクライアント提供値を使用しないようにします
**IAMと最小権限の原則**
- IAM SigV4認証はAWS内のサービス間通信に使用します
- JWTベアラートークン認証はエンドユーザーが直接認証する場合に使用します
- AgentCore RuntimeとAgentCore Gatewayの両方に制限的な認証・認可権限を設定します
**認証情報の管理**
- 本番コードにトークンをハードコーディングしないでください
- エージェントコードに認証情報をハードコーディングしないでください
- 環境変数やAmazon SageMaker AIを使用して機密情報を管理します
- 外部サービスの認証情報を定期的にローテーションします
**ネットワークセキュリティ**
- 完全なARNを使用し、可能な限りワイルドカードを避けます
- VPCエンドポイントポリシーを認証方法に合わせて設定します
## 可観測性のベストプラクティス
- **一貫したセッションIDの使用**: 可能な限り、関連するリクエストに同じセッションIDを再利用してコンテキストを維持します
- **分散トレーシングの実装**: 提供されたヘッダーを使用してアプリケーションコンポーネント全体でエンドツーエンドのトレーシングを有効にします
- **カスタム属性の追加**: トラブルシューティングと分析のための追加コンテキストを提供します
- **リソース使用状況の監視**: メモリ使用量メトリクスに注意を払い、エージェントのパフォーマンスを最適化します
- **アラートの設定**: CloudWatchアラームを設定して、問題がユーザーに影響を与える前に通知を受け取ります
## InvokeAgentRuntimeのベストプラクティス
- セッション管理を使用して会話コンテキストを維持し、より良いユーザー体験を提供します
- ストリーミングレスポンスを段階的に処理して、ユーザーにリアルタイムフィードバックを提供します
- 堅牢なアプリケーションのために適切なエラーハンドリングとリトライロジックを実装します
- マルチモーダルコンテンツを送信する際は、ペイロードサイズの制限(100 MB)を考慮します
- テスト、git、ビルドなどの決定論的な操作には、エージェントのLLMを経由させずにInvokeAgentRuntimeCommandを使用します
## Code Interpreterのベストプラクティス
- コードスニペットを簡潔にし、特定のタスクに焦点を当てます
- コメントを使用してコードを文書化します
- 大規模なデータセットを扱う際はパフォーマンスのためにコードを最適化します
- 複雑な操作を実行する際は中間結果を保存します
- エラーを適切に処理するためにtry/exceptブロックを含めます
- リソースを解放するために完了時にセッションをクローズします
## パフォーマンスとコスト最適化
- **エラーハンドリング**: 失敗した処理のために適切なリトライロジックとデッドレターキューを実装します
- **モニタリング**: デバッグと処理失敗、レイテンシーのためにCloudWatchログ、メトリクス、アラームを設定します
- **S3ライフサイクルポリシー**: 処理済みペイロードの自動削除を設定してストレージコストを管理します
- **適切なサイジング**: 処理要件に基づいて適切なコンピュート、メモリ、タイムアウト設定を選択します
これらのベストプラクティスに従うことで、AgentCoreを使用した安全で効率的、かつ信頼性の高いエージェントアプリケーションを構築できます。
============================================================
citations 件数: 31
[引用1] 回答の 0〜201 文字目（resultIndex=[1]）:
「AgentCoreのベストプラクティスについて、検索結果から包括的な情報をまとめてお答えします。
Amazon Bedrock AgentCoreには、セキュリティ、パフォーマンス、運用の各側面で推奨されるベストプラクティスがあります。
## セキュリティのベストプラクティス
**セッション分離とデータ保護**
- セッションIDを一貫して使用し、関連するリクエスト間でコンテキストを維持します」
└ 出典: https://20260618-mkb.s3.us-west-2.amazonaws.com/bedrock-agentcore-dg%20%281%29.pdf
[引用2] 回答の 202〜248 文字目（resultIndex=[3]）:
「- 認証された主体からユーザーIDを導出し、任意のクライアント提供値を使用しないようにします」
[引用3] 回答の 250〜298 文字目（resultIndex=[3]）:
「**IAMと最小権限の原則**
- IAM SigV4認証はAWS内のサービス間通信に使用します」
[引用4] 回答の 299〜337 文字目（resultIndex=[3]）:
「- JWTベアラートークン認証はエンドユーザーが直接認証する場合に使用します」
[引用5] 回答の 338〜396 文字目（resultIndex=[4, 9]）:
「- AgentCore RuntimeとAgentCore Gatewayの両方に制限的な認証・認可権限を設定します」
[引用6] 回答の 398〜440 文字目（resultIndex=[3]）:
「**認証情報の管理**
- 本番コードにトークンをハードコーディングしないでください」
[引用7] 回答の 441〜475 文字目（resultIndex=[6]）:
「- エージェントコードに認証情報をハードコーディングしないでください」
[引用8] 回答の 476〜517 文字目（resultIndex=[6]）:
「- 環境変数やAmazon SageMaker AIを使用して機密情報を管理します」
[引用9] 回答の 518〜546 文字目（resultIndex=[6]）:
「- 外部サービスの認証情報を定期的にローテーションします」
[引用10] 回答の 548〜595 文字目（resultIndex=[3]）:
「**ネットワークセキュリティ**
- 完全なARNを使用し、可能な限りワイルドカードを避けます」
[引用11] 回答の 596〜627 文字目（resultIndex=[3]）:
「- VPCエンドポイントポリシーを認証方法に合わせて設定します」
[引用12] 回答の 629〜713 文字目（resultIndex=[1]）:
「## 可観測性のベストプラクティス
- **一貫したセッションIDの使用**: 可能な限り、関連するリクエストに同じセッションIDを再利用してコンテキストを維持します」
└ 出典: https://20260618-mkb.s3.us-west-2.amazonaws.com/bedrock-agentcore-dg%20%281%29.pdf
[引用13] 回答の 714〜787 文字目（resultIndex=[1]）:
「- **分散トレーシングの実装**: 提供されたヘッダーを使用してアプリケーションコンポーネント全体でエンドツーエンドのトレーシングを有効にします」
└ 出典: https://20260618-mkb.s3.us-west-2.amazonaws.com/bedrock-agentcore-dg%20%281%29.pdf
[引用14] 回答の 788〜837 文字目（resultIndex=[1]）:
「- **カスタム属性の追加**: トラブルシューティングと分析のための追加コンテキストを提供します」
└ 出典: https://20260618-mkb.s3.us-west-2.amazonaws.com/bedrock-agentcore-dg%20%281%29.pdf
[引用15] 回答の 838〜896 文字目（resultIndex=[1]）:
「- **リソース使用状況の監視**: メモリ使用量メトリクスに注意を払い、エージェントのパフォーマンスを最適化します」
└ 出典: https://20260618-mkb.s3.us-west-2.amazonaws.com/bedrock-agentcore-dg%20%281%29.pdf
[引用16] 回答の 897〜957 文字目（resultIndex=[1]）:
「- **アラートの設定**: CloudWatchアラームを設定して、問題がユーザーに影響を与える前に通知を受け取ります」
└ 出典: https://20260618-mkb.s3.us-west-2.amazonaws.com/bedrock-agentcore-dg%20%281%29.pdf
[引用17] 回答の 959〜1035 文字目（resultIndex=[2]）:
「## InvokeAgentRuntimeのベストプラクティス
- セッション管理を使用して会話コンテキストを維持し、より良いユーザー体験を提供します」
└ 出典: https://20260618-mkb.s3.us-west-2.amazonaws.com/bedrock-agentcore-dg%20%281%29.pdf
[引用18] 回答の 1036〜1084 文字目（resultIndex=[2]）:
「- ストリーミングレスポンスを段階的に処理して、ユーザーにリアルタイムフィードバックを提供します」
└ 出典: https://20260618-mkb.s3.us-west-2.amazonaws.com/bedrock-agentcore-dg%20%281%29.pdf
[引用19] 回答の 1085〜1129 文字目（resultIndex=[2]）:
「- 堅牢なアプリケーションのために適切なエラーハンドリングとリトライロジックを実装します」
└ 出典: https://20260618-mkb.s3.us-west-2.amazonaws.com/bedrock-agentcore-dg%20%281%29.pdf
[引用20] 回答の 1130〜1177 文字目（resultIndex=[2]）:
「- マルチモーダルコンテンツを送信する際は、ペイロードサイズの制限(100 MB)を考慮します」
└ 出典: https://20260618-mkb.s3.us-west-2.amazonaws.com/bedrock-agentcore-dg%20%281%29.pdf
[引用21] 回答の 1178〜1252 文字目（resultIndex=[2]）:
「- テスト、git、ビルドなどの決定論的な操作には、エージェントのLLMを経由させずにInvokeAgentRuntimeCommandを使用します」
└ 出典: https://20260618-mkb.s3.us-west-2.amazonaws.com/bedrock-agentcore-dg%20%281%29.pdf
[引用22] 回答の 1254〜1315 文字目（resultIndex=[5]）:
「## Code Interpreterのベストプラクティス
- コードスニペットを簡潔にし、特定のタスクに焦点を当てます」
[引用23] 回答の 1316〜1337 文字目（resultIndex=[5]）:
「- コメントを使用してコードを文書化します」
[引用24] 回答の 1338〜1376 文字目（resultIndex=[5]）:
「- 大規模なデータセットを扱う際はパフォーマンスのためにコードを最適化します」
[引用25] 回答の 1377〜1401 文字目（resultIndex=[5]）:
「- 複雑な操作を実行する際は中間結果を保存します」
[引用26] 回答の 1402〜1437 文字目（resultIndex=[5]）:
「- エラーを適切に処理するためにtry/exceptブロックを含めます」
[引用27] 回答の 1438〜1469 文字目（resultIndex=[5]）:
「- リソースを解放するために完了時にセッションをクローズします」
[引用28] 回答の 1471〜1544 文字目（resultIndex=[7]）:
「## パフォーマンスとコスト最適化
- **エラーハンドリング**: 失敗した処理のために適切なリトライロジックとデッドレターキューを実装します」
[引用29] 回答の 1545〜1608 文字目（resultIndex=[7]）:
「- **モニタリング**: デバッグと処理失敗、レイテンシーのためにCloudWatchログ、メトリクス、アラームを設定します」
[引用30] 回答の 1609〜1663 文字目（resultIndex=[7]）:
「- **S3ライフサイクルポリシー**: 処理済みペイロードの自動削除を設定してストレージコストを管理します」
[引用31] 回答の 1664〜1717 文字目（resultIndex=[7]）:
「- **適切なサイジング**: 処理要件に基づいて適切なコンピュート、メモリ、タイムアウト設定を選択します」
あれ、ベクトルバケットいらないの...？
思いませんでしたか？私は思いました。従来はS3 Vectorなどのベクトルストアを利用して検索に利用していましたよね。
ですが今回は作成していません。ではどうやっているのか？
構成を以下のように比較すると、よくわかるかと思います
従来（VECTOR 型） |
今回（MANAGED 型） |
|
|---|---|---|
type |
VECTOR |
MANAGED |
| 埋め込みモデル | 自分で指定 | 構成に無い |
| ベクトルストア | 自分で用意 | 構成に無い |
MANAGED 型の構成は実質 {"type": "MANAGED"} だけ。埋め込みモデルもベクトルストアも指定欄がありません。
ではベクトル化していないのかというと、そうではありません。Retrieve の結果にはちゃんと score（0.72 など）が返ってくるので、ベクトル/ハイブリッド検索は動いています。つまり、
埋め込みも保存も検索も「AWSが内部（アカウント外）で全部やっている」
ということ。自分のアカウントには S3 Vectors も OpenSearch も現れません。埋め込みモデルすら選べない（隠蔽されている）し、内部で何のストアを使っているかも公開されていません。「中身を気にせず使える」ことに全振りした設計、という理解が正確そうです。
その代わり、チャンク戦略・埋め込みモデル・距離関数といった細かいチューニングはできないので、手軽さと制御性のトレードオフですね。
今までと何が変わって何がhappyになるのか
- RAGの組み込みが「ターゲット登録」だけで完了する：ベクトルストアの構築・検索APIの実装・MCPサーバーの自作が不要。
- Gatewayの他のツールと同じ土俵に乗る：ナレッジ検索と、他のAPI/Lambdaツールを、同じGatewayエンドポイント・同じ認証・同じMCPインターフェースで扱える。
- Agentic retrieval を1コールで使える：多段の検索＋引用付き合成を、エージェント側のロジックを増やさずに利用できる。
逆に注意点として、コネクタが使えるのは MANAGED 型KBのみで、既存の VECTOR 型KBはそのままでは使えない、という制約があります。
逆にAgentic retrieval そこまでめっちゃ使いたいか？と言われると微妙な反応になるんですが...w
いやいやそれは違うよ、という方はぜひ教えていただきたいです。
とりあえず使ってみる
早速試してみました。
今回は以下のドキュメントを参考にやってみました。まだCDKとかは対応してないのかな？
また発表直後ということで、泣く泣くSDKとかを使用してます笑
数日後にはあまり推奨されていないかもしれませんが笑
ナレッジベースを作成する
まずナレッジベースを作成します。
データソースとなるS3バケットも合わせて作成しておき、選択しておきます。
作成時に type を Managed KB、retrieval type を Agentic（または Standard） にしておきます。
ドキュメントを追加したら、念のためちゃんと検索できるか確認しておくと安心です。
Gatewayにコネクタターゲットを登録する
Gateway本体（protocolType=MCP）を用意したうえで、ナレッジベースをコネクタターゲットとして登録します。SDK（boto3）だとこんな感じです。
import boto3
client = boto3.client("bedrock-agentcore-control", region_name="us-west-2")
client.create_gateway_target(
gatewayIdentifier="<GATEWAY_ID>",
name="managed-kb",
targetConfiguration={
"mcp": {
"connector": {
"source": {"connectorId": "bedrock-knowledge-bases"},
"configurations": [
{
"name": "AgenticRetrieveStream",
"parameterValues": {
"retrievers": [
{"description": "my managed KB",
"configuration": {"knowledgeBase": {"knowledgeBaseId": "<KB_ID>"}}}
],
"agenticRetrieveConfiguration": {
"foundationModelType": "MANAGED",
"rerankingModelType": "MANAGED",
},
},
},
{"name": "Retrieve", "parameterValues": {"knowledgeBaseId": "<KB_ID>"}},
],
}
}
},
credentialProviderConfigurations=[{"credentialProviderType": "GATEWAY_IAM_ROLE"}],
)
登録すると、エージェントからは以下2つのツールが見えるようになります（ツール名は <ターゲット名>___<ツール名>）。
managed-kb___Retrievemanaged-kb___AgenticRetrieveStream
利用可能な認証方法
認証は「インバウンド（誰がGatewayを呼べるか）」と「アウトバウンド（GatewayがKBをどう呼ぶか）」の2層で考えます。
アウトバウンド（コネクタ → ナレッジベース）
- コネクタターゲットは
GATEWAY_IAM_ROLEのみ対応。GatewayのサービスロールでKBを呼びます。 - サービスロールに必要な権限はこんな感じ（最小権限）。
{
"Version": "2012-10-17",
"Statement": [
{"Effect": "Allow", "Action": "bedrock:GetKnowledgeBase",
"Resource": "arn:aws:bedrock:us-west-2:<ACCOUNT_ID>:knowledge-base/<KB_ID>"},
{"Effect": "Allow", "Action": "bedrock:Retrieve",
"Resource": "arn:aws:bedrock:us-west-2:<ACCOUNT_ID>:knowledge-base/<KB_ID>"},
{"Effect": "Allow", "Action": "bedrock:AgenticRetrieveStream", "Resource": "*"}
]
}
（AgenticRetrieveStream だけはAPI仕様上リソースを絞れず * 指定が必要でした）
インバウンド（呼び出し元 → Gateway）
-
AWS_IAM（SigV4） … 自分のIAM資格情報で呼べるので検証が一番ラク -
CUSTOM_JWT… Cognito等のIdP連携。 -
NONE… 認証なし（基本おすすめしません）
検証では AWS_IAM にして実施しています。
AgentCore Runtime 上のエージェントから呼び出す
せっかくなので、AgentCore Runtime 上にデプロイしたエージェントから、この Gateway 経由でナレッジベースを使うところまでやってみます。
エージェントを作る
BedrockAgentCoreApp の entrypoint 内で、Gateway の MCP エンドポイントに繋いでツール一覧を取得し、そのままエージェントのツールとして使います。
import os
from bedrock_agentcore import BedrockAgentCoreApp
from strands import Agent
from strands.tools.mcp import MCPClient
from mcp.client.streamable_http import streamablehttp_client
from sigv4_auth import AwsSigV4Auth
app = BedrockAgentCoreApp()
GATEWAY_URL = os.environ["GATEWAY_MCP_ENDPOINT"]
MODEL_ID = "us.anthropic.claude-sonnet-4-5-20250929-v1:0"
@app.entrypoint
async def invoke(payload):
auth = AwsSigV4Auth(region=os.environ.get("AWS_REGION", "us-west-2"))
# MCPClient は with ブロック内で使い、ブロック内で実行まで完結させる
with MCPClient(lambda: streamablehttp_client(url=GATEWAY_URL, auth=auth)) as mcp:
tools = mcp.list_tools_sync() # managed-kb___Retrieve / ___AgenticRetrieveStream
agent = Agent(model=MODEL_ID, system_prompt="...", tools=tools)
async for event in agent.stream_async(payload.get("prompt", "")):
if "data" in event:
yield {"type": "text", "data": event["data"]}
elif "current_tool_use" in event:
yield {"type": "tool_use", "data": event["current_tool_use"].get("name")}
デプロイ（agentcore CLI）
発表直後でCDKはまだっぽかったです。
starter toolkit の CLI でデプロイします。GATEWAY_MCP_ENDPOINT を環境変数で渡します。
agentcore configure -e agent.py -n managed_kb_agent --region us-west-2
agentcore deploy --env GATEWAY_MCP_ENDPOINT="https://xxxx.gateway.bedrock-agentcore.us-west-2.amazonaws.com/mcp"
呼び出してみる
PAYLOAD=$(printf '{"prompt": "%s"}' "AgentCoreのコアサービスを教えて" | base64)
aws bedrock-agentcore invoke-agent-runtime \
--region us-west-2 \
--agent-runtime-arn "arn:aws:bedrock-agentcore:us-west-2:<ACCOUNT_ID>:runtime/managed_kb_agent-xxxx" \
--runtime-session-id "managed-kb-demo-session-0001-padpadpadpadpad" \
--payload "$PAYLOAD" --content-type "application/json" /tmp/out.txt
実行すると、エージェントが managed-kb___AgenticRetrieveStream（または Retrieve）を呼び、ナレッジベース由来の回答を返してくれます。Runtime → Gateway → コネクタ → KB が一気通貫で繋がる..はずです。
さいごに
AgentCore Gateway にナレッジベースがコネクタとして組み込まれたことで、RAGの導入が「ターゲット登録だけ」でできるようになりました。東京リージョンでも追加できるのは嬉しいですね。
発表直後ということでCDKとかはまだ追いついていない感はありますが...
今回はとりあえず使ってみた感が強いですが、かなり良さそうな感じがしました！
これによって今までのAgentCore✖️RAGの構成をいい感じに改善できるきっかけになるかもしれませんね。