Amazon Bedrock Agents ClassicからAmazon Bedrock AgentCoreへ移行した際、ガードレール設定が2箇所に割れた話

2026年09月26日開催の「JAWS-UG KYUSHU QUEST 2026 in Fukuoka」にて登壇した資料になります。
https://jawsug-fukuoka.connpass.com/event/403616/

Transcript

1. Amazon Bedrock Agents Classic から Amazon Bedrock AgentCore へ移行した際、 ガードレール設定が2箇所に割れた話 JAWS-UG KYUSHU QUEST 2026 in Fukuoka (2026/09/26開催) 松延 航平 (Kohei Matsunobu) © Benjamin Inc
2. 自己紹介 名前： 松延 航平（まつのぶ こうへい） 所属： 株式会社ベンジャミン (部署：AWS Strategy Group) 役割： AWSエンジニア 業務： AWSを用いたシステムの要件定義・設計・構築、運用保守などを担当 (主にインフラ周り) 認定： 2026 Japan AWS Ambassador 2025-2026 Japan AWS Top Engineer(Services) 2025-2026 Japan All AWS Certifications Engineer 2026 AWS Community Builder(AI Engineering) 趣味： 旅行、温泉巡り © Benjamin Inc LinkedIn 1
3. 本日のアジェンダ 1 背景 — Agents Classic がメンテナンスモードに 2 移行してみた — 構成と、部品ごとの手間 3 同じ質問、違う結果 — 移行後に起きたこと 4 なぜ割れるのか — 検査ポイントが1つから2つへ 5 Guardrails の移行方針 — どこに置き直すか、まとめ © Benjamin Inc 2
4. 01 © Benjamin Inc 背景 3
5. 背景: Bedrock Agents Classic がメンテナンスモードに ・2026/7/30にBedrock Agent Classicがメンテナンスモード発効。公式の移行先は Amazon Bedrock AgentCore（推奨は Harness） ・廃止日は設定されていない。移行期限もない ・ただしモデルカタログは 2026/7/30 時点で凍結 → 現状維持のコストは時間とともに増えていく 「移行期限はありません。Bedrock Agents Classic は、メンテナンスモードで既存のお客様に引き続きご利用いただけます。end-oflife は予定されていません。」 「モデルカタログは、メンテナンスモードの発効日 (2026 年 7 月 30 日) の時点で凍結されています。」 出典: Amazon Bedrock Agents Classic のメンテナンスモード https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/agents-classic-maintenance-mode.html © Benjamin Inc 4
6. 今日話すこと 本発表は検証環境での結果です（実案件の移行事例ではありません） 移行は公式の手動手順（Migrate manually）で実施。CLI インポート・移行 Skill は未使用 検証構成 ・ECサイト問い合わせ対応アシスタント ・モデル ＋ Knowledge Base（RAG） ＋ Lambda Action Group ＋ Guardrails ・モデルは両側とも Claude Haiku 4.5（Classic の凍結カタログに含まれる）で揃えた 出典: Amazon Bedrock Agents Classic のメンテナンスモード（「手動で移行する」の節） https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/agents-classic-maintenance-mode.html © Benjamin Inc 5
7. 02 移行してみた © Benjamin Inc 6
8. 移行構成 before / after © Benjamin Inc 7
9. 部品ごとに「移行の手間」が違う 移行の手間 コンポーネント そのまま接続 Managed KB（AgentCore Gateway のコネクタで登録するだけ） 設定値を転記 システムプロンプト・モデル指定 修正・移行が必要 ・Action Group の Lambda（イベント形式が違う） ・従来型 KB（Managed KB へ移行。S3 の元データは共有可） 別の仕組みで再構成 ・Guardrails → モデル側の Bedrock Guardrails ＋ AgentCore Gateway 側の Policy に"割れる" ・オーケストレーション → Harness ※ AgentCore Gateway の KB コネクタは Managed KB 専用 4段目の中でも Guardrails だけは、Agents Classic で1つだったものが移行先で2つに割れる ……この「2つに割れる」、あとで効いてきます © Benjamin Inc 8
10. 移行してみた結果: 機能は同等に動いた テスト Agents Classic AgentCore（移行後） RAG 返品期限の質問 「商品到着後30日以内です。 ただし、未開封・未使用が条件」 同等の回答 （managed-kb___AgenticRetrieveStream を呼び出し） ツール 注文状況照会 「注文ORD-1001は発送済みです。 お届け予定日は2026年8月8日」 同等の回答 （order-tool___get_order_status を呼び出し） ※ どちらも実測。モデルは両側とも Claude Haiku 4.5 で揃えた（抜粋） ここまでは順調でした。「移行できた」と思いました。 © Benjamin Inc 9
11. 03 同じ質問、違う結果 © Benjamin Inc 10
12. 同じ質問、違う結果 同じ質問「返品に関する問い合わせ先を教えて」を両方に投げた Agents Classic 移行後（AgentCore Gateway の Policy のみ） 応答 返品に関するご問い合わせは以下まで ・メール: {EMAIL} ・電話: {PHONE} ・担当: {NAME} 返品に関する問い合わせ先は以下の通りです ・担当者: 山田太郎 ・メールアドレス: support@example.com ・電話番号: 03-1234-5678 会話 続けられる 続けられる。ただし個人情報がそのまま出る AgentCore Gateway 側に PII 検査ポリシーを作ろうとした結果 検査したいもの 作ったポリシー（Cedar） 結果 ツールの出力 （応答に含まれる PII） suppressOutput … [context.output.text] ✗ 作成失敗 ツールの入力 （引数） forbid … [context.input.order_id] ✓ 作成できる context.output.text is not present in the context of action 出典: Schema constraints（AgentCore Policy）— "Only available context is c ontext.input" https://docs.aws .amazon.com/bedrock-agentcore/latest/devguide/policy-schema-constraints.html © Benjamin Inc 11
13. PII を守る設定は、どこに置けるか 置き場所 置けるか・その理由 応答の個人情報 ✗ 置けない。理由は2つ AgentCore Gateway の Policy モデル側の Bedrock Guardrails ① 今回の MCP ツールでは、出力（返り値）を検査するポリシーが作れなか った（前ページ）。検査できたのは入力（引数）だけ ② 効果は permit / forbid / suppressOutput の3つ。「マスクして通す」という 選択肢がそもそも無い 生のまま出る ✓ 置ける マスクされる モデルの入出力テキストに掛かり、PII を {EMAIL} などに置き換えられる stopReason: guardrail_intervened ※ suppressOutput はガードレール違反時に出力を丸ごと落とす効果。今回の MCP ツールでは作成できなかった（前ページ）。作れる構成でも「消す」だけで「マスクし て通す」ではない Guardrails が効かなくなったわけではない。 置く場所を間違えていて、守りがどこにも掛かっていなかった。 © Benjamin Inc 12
14. 04 なぜ割れるのか © Benjamin Inc 13
15. 公式ドキュメントにこう書いてある 公式の機能比較表 「ガードレールと ポリシー」の行（原文） 要するに （私の言葉） Agents Classic AgentCore エージェントに宣言的にアタッチされ、オーケストレーシ ョン中に適用されるガードレールとエージェントポリシー Bedrock でのガードレール設定と AgentCore ゲートウェイ でのポリシーの適用 Guardrail を1つ エージェントに紐付けるだけ 2箇所に分かれる --guardrail-configuration guardrailIdentifier=... ,guardrailVersion=1 Bedrock 側の Guardrail を Harness の guardrailConfig で指定 ＋ AgentCore Gateway 側の Policy 公式ページの FAQ（原文） 「Bedrock モデルで設定されたガードレールは、モデルが AgentCore を介して呼び出された場合でも適用されます。エージェントレベルのガードレールの適 用は、AgentCore ゲートウェイポリシーを通じて利用できます。」 出典: Amazon Bedrock Agents Classic のメンテナンスモード（機能の比較・よくある質問） https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/agents-classic-maintenance-mode.html ※ 2026/6 GA の「Guardrails in policies」（Gateway の Policy で Guardrails の検出器を使う機能）は、ツール呼び出しの境界で ALLO W / DENY と出力抑止（suppressOutput）を判定するもの。 PII を別の文字列に置き換えて会話を続ける（マスク）ことはできず、既存 Guardrail の ARN も紐付けられない。マスクは依然としてモデル側の guardrailConfig だけ 出典: What's New 2026/6/17 https://aws.amazon.com/jp/about-aws/whats-new/2026/06/amazon-bedroc k-agentcore-policy-guardrails-generally-available/ © Benjamin Inc 14
16. 検査ポイントが1つから2つへ Agents Classic: 検査ポイントは1つ ユーザー 検査ポイント Guardrail を1つ紐付け モデル （検査なし） KB / Lambda 検査の外 AgentCore: 検査ポイントが2つ・掛かる場所が違う ユーザー ① Bedrock Guardrails モデルの入出力に掛かる © Benjamin Inc モデル ② AgentCore Policy ツール呼び出しの入力に 掛かる KB / Lambda AgentCore Gateway 経由 15
17. マスクできるのは、モデル側の Bedrock Guardrails だけ 掛かる場所 できること ① Bedrock Guardrails （モデル側） モデルの入出力テキスト ブロック ＋ マスク ② AgentCore Policy （AgentCore Gateway 側） ツール呼び出しの入力（今回の MCP ツー ルで確認できた範囲） ブロック（forbid）・出力抑止（ suppressOutput）のみ。マスク不可 マスキングが要る守りは、モデル側に置いたままにする必要があった それだけの話なんですが、公式の手動移行手順 Step 1 の対応関係 （モデル／アクショングループ／ナレッジベース／プロンプト）に Guardrails の行がない 出典: Amazon Bedrock Agents Classic のメンテナンスモード（「手動で移行する」の節） https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/agents-classic-maintenance-mode.html Guardrails in policies https://docs.aws.amazon.com/bedrock-agentcore/latest/dev guide/policy-guardrails-in-policies.html Schema constraints https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-schema-constraints.html Remove PII from conversations by using sensitive information filters https:// docs.aws.amazon.com/bedroc k/lates t/userguide/guardrails-sensitive-filters.html © Benjamin Inc 16
18. 05 Guardrails の移行方針 © Benjamin Inc 17
19. Guardrails の移行方針: どこに置き直すか いまの Guardrails を、2つの置き場所に振り分ける いまの Guardrail の設定 マスク PII を {EMAIL} などに置き換える 移行後の置き場所 AgentCore Gateway の Policy には置けない → モデル側の Bedrock Guardrails に置いたままにする モデル側が基本 ブロック 拒否トピック・コンテンツフィルタ ツール呼び出しの引数（例: order_id）で呼び出しを止めたいものだけ AgentCore Gateway の Policy へ（アクション単位で見られるので、移行前より強くなる面もある） ※ AgentCore Policy の効果は permit / forbid / suppressOutput の3つ。マスクという選択肢がそもそも無い 割れたのは機能ではなく、公式の説明と設定の置き場所 Classic と同じ守りだけなら guardrailConfig だけで足りる。Policy は追加の守り © Benjamin Inc 18
20. モデル側への置き方: guardrailConfig を足すだけ Harness の定義（CreateHarness / UpdateHarness）の model に足す "model": { "bedrockModelConfig": { "modelId": "jp.anthropic.claude-haiku-4-5-...", "apiFormat": "converse_stream", "additionalParams": { "guardrailConfig": { "guardrailIdentifier": "arn:aws:bedrock:...:guardrail/abc123", "guardrailVersion": "1" } } } } ① guardrailConfig のブロックを足す Agents Classic の --guardrail-configuration に相当。Harness の 定義に書くだけで、モデルの入出力に Guardrail が掛かる。 AgentCore Gateway 側の設定は不要 ② ARN は作り直さない Agents Classic で使っていた Guardrail の ARN とバージョンを そのまま指定する。マスクやブロックの設定本体は Bedrock 側 にあり、移行の対象ではない ③ apiFormat は converse_stream guardrailConfig が効くのは converse_stream のときだけ。省略 時のデフォルトなので書かなくても同じだが、効く条件を見え る化するためにあえて明示 ※ guardrailConfig は Harness ごとの設定。同じモデルを使う他のエージェントには波及しない 出典: Models and instructions（AgentCore Harness） https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-models.html 原文: “To apply a guardrail to each model request, add a guardrailConfig object to bedrockModelConfig.additionalParams. The harne ss passes this object to Amazon Bedrock with each model request. … configure bedrockModelConfig with the converse_stream API format. If you omit apiFormat, the harness uses converse _stream by default.” © Benjamin Inc 19
21. 移行後の最終構成: 守りが2箇所に掛かった状態 ① Bedrock Guardrails（モデル側・guardrailConfig）と ② AgentCore Gateway の Policy は役割が違う マスキングが要る守りは ① にしか置けない。② はツール呼び出しの引数（例: order_id）で止めたいときだけ（任意） © Benjamin Inc 20
22. まとめ • • 移行の手間は部品ごとに違う。 • Managed KB は AgentCore Gateway に登録するだけ • Lambda はコード修正 • Guardrails だけは移し先が分かりにくい。Classic 相当の守りは Harness の guardrailConfig 1箇所で足り、 Policy は追加の守り AgentCore Gateway の Policy は、今回の検証では出力を検査するポリシーが作れず、そもそもマスクの効果が無 い。 • PII のマスクは Harness の guardrailConfig（モデル側）に置く 今日帰ったらできること 自分の Guardrail を開いて、PII フィルタが「マスク（Anonymize）」になっている項目を数える 1つでもあれば、その Guardrail は Harness の guardrailConfig に指定する。AgentCore Gateway の Policy では 代替できない © Benjamin Inc 21
23. ご清聴ありがとうございました © Benjamin Inc 22