目次を表示する

Bedrockで Production Ready な AI 機能を作る ── 設計・運用・現場の知恵

エピローグ：Production Ready の 15 の判断ポイントを携える

エピローグ：Production Ready の 15 の判断ポイントを携える

Production Ready の 15 の判断ポイント（モデル&API 5 / RAG&エージェント 3 / ガバナンス&評価 3 / コスト&セキュリティ 4）とプロローグ 3 つの壁の回収を 1 枚に集約したチェックリスト

対象読者：本シリーズ全章を読み終えた読者。15 の判断ポイントを「現場の意思決定チェックリスト」として持ち帰りたい読者 難易度：★☆☆☆☆（まとめ） 想定読了時間：約 30 分 関連章：全章（伏線回収）/ 参考文献（章末）

ふたたび、ある朝の話

プロローグで、ある朝の場面から始めた。上司に「うちのプロダクトに AI 機能を入れたい。たぶん Bedrock でいけるよね」と言われ、ブラウザのタブが 17 個に増えていく、あの朝だ。

第 17 章までを読んだ今、もう一度同じ場面に立ってみてほしい。

あなたはおそらく、最初にこう考えるはずだ。「これは Converse API から始めて、max_tokens を明示しよう」「Knowledge Bases か自前 RAG かは、メタデータフィルタが本当に必要かで決まる」「Day 1 から Guardrails は Detect モードで、評価ジョブも回しておく」── そう、順番が見えている。これがプロローグから第 17 章までの 6 時間で起きた変化だ。

このエピローグでは、まずプロローグで提示した 3 つの壁が、どこでどう崩されたかを見直す。次に、シリーズを貫いてきた架空アプリ helpdesk-ai が 10 行のチャットから AgentCore Production 構成まで育った軌跡をたどる。そして、本シリーズの集大成として Production Ready の 15 の判断ポイントを 1 ページに集約する。最後に、Bedrock の未来と、次に読むべきものへの案内を置く。

プロローグの 3 つの壁を回収する

壁 1：機能カタログと設計判断の壁

「公式 docs は機能 X が何かは教えてくれるが、いつ X を選ぶべきかは教えてくれない」── そう書いた壁である。

この壁は Part 1 で 5 章かけて崩した。第 2 章で Bedrock を AWS Generative AI Stack の中層（FMaaS）に位置付け、第 3 章で OpenAI / Azure OpenAI / Vertex AI / Anthropic 直叩きとの設計差を読み解いた。「Bedrock を選ぶ判断はモデル性能ではなくデータ取り扱いポリシーと IAM 統制で決まる」という命題は、ここで腑に落ちたはずだ。

第 4 章で「機能カタログ 2026」を俯瞰し、Foundation Models → Converse API → Knowledge Bases → Agents / AgentCore → Guardrails → Application Inference Profile の地図を描いた。第 5 章では Claude / Nova / Llama / Mistral / Cohere をユースケース軸で並べ、「Haiku でワーカー、Sonnet で最終判断」のような階層運用パターンを提示した。

この時点で、「機能カタログを眺める」状態は終わっている。あなたは どの機能を、なぜ、どの順で選ぶか を自分の言葉で説明できるはずだ。

壁 2：「動く」と「正しく動く」の壁

「PoC は動いた。デモも通った。本番に出したら、ある日突然ハルシネーション・プロンプトインジェクション・想定外のコストが来る」── これが壁 2 だった。

Part 3 全章がこの壁の解体に費やされた。第 11 章で Guardrails を Detect モード → Block モードの段階導入で組み込み、第 12 章で Day 1 から評価を回す体制（Model Evaluation・LLM-as-a-Judge・AgentCore Evaluations）を立て、第 13 章で CloudWatch メトリクス + Model Invocation Logging で観測を設計した。特に第 13 章では「Mask モードでも input フィールドには原文が残る」という第 11 章の伏線を回収し、CloudWatch Log Data Protection で別途守る必要があることを示した。

第 14 章では IAM の bedrock:GuardrailIdentifier 条件キーで Guardrails を強制し、VPC Endpoint と KMS CMK で多層防御を設計した。第 15 章ではコストの「想定の 10 倍問題」を、PT 損益分岐 80–85%、Prompt Caching ヒット率 30%、Intelligent Prompt Routing の 63.6% 削減実測値という具体的な数値で押さえた。

「動く」と「正しく動く」の差は、Day 1 から評価・観測・ガードレールを設計に組み込むかどうかだ。プロローグでこう書いた中心思想は、Part 3 全章をくぐった今、もはやスローガンではなく具体的な実装手順として手の中にある。

壁 3：公式ドキュメントと現場の知恵の壁

「公式 docs は正しい。だが現場で実際に起きていることは別の場所に書いてある」── これが壁 3 だった。

Part 4 が回答である。第 16 章で国内・海外の事例を読んだ。住信 SBI ネット銀行が AgentCore Runtime でジェネレーティブ UI 銀行を作り、セゾンテクノロジーが Advanced RAG で回答作成時間を 30% 短縮し、Pfizer が VOX で年 16,000 時間削減・インフラコスト 55% 削減を達成した実例は、本シリーズのすべての技術要素が現実の業務でどう価値に変わるかを示していた。

第 17 章では、それと裏返しの 9 つのアンチパターンを扱った。max_tokens 未設定、PT 無駄買い、Guardrails 後付け、評価なしで本番投入、Knowledge Bases のチャンキング Default 放置、観測後付け、コスト見積もり失敗、VPC Endpoint 未使用、Cross-Region Inference の誤用 ── どれも公式 docs に明示的には書かれていない（あるいは目立たない）が、現場で繰り返し起きている失敗である。

事例とアンチパターンを両側から見ることで、Bedrock の使い方に「現場の重力」が宿った。これが壁 3 の崩壊である。

helpdesk-ai の軌跡 ── 10 行から Production まで

シリーズを貫いた架空アプリ helpdesk-ai が、本編 18 章でどう育ったかを振り返っておきたい。

Part章helpdesk-ai の状態
Part 2第 6 章10 行の Converse API。FAQ を system prompt に詰め込んだだけのチャット
Part 2第 7 章Streaming で typing 表示。get_holiday_balance(employee_id) の Tool Use
Part 2第 8 章Knowledge Bases に社内規程 PDF を載せ、引用付きで答える RAG
Part 2第 9 章Bedrock Agents で人事 API を Action Group 化、Trace で多段ステップを可視化
Part 2第 10 章AgentCore Runtime に移行。Memory（個人別履歴）・Identity（Slack 認証）・Observability を獲得
Part 3第 11 章Guardrails（PII Mask・給与情報 Denied Topics・英語ドキュメント時の Contextual Grounding）
Part 3第 12 章LLM-as-a-Judge と AgentCore Evaluations で 4 軸評価
Part 3第 13 章CloudWatch メトリクス + Model Invocation Logging。Application Inference Profile でコスト分離
Part 3第 14 章IAM 強制 + VPC Endpoint + KMS CMK の多層防御
Part 3第 15 章Intelligent Prompt Routing + Prompt Caching でコスト最適化
付録 A—マルチリージョン化（東京 + ソウル + 大阪）
付録 B—月次コスト見積もりワークシート

第 6 章の helpdesk-ai は、Converse を 1 回叩くだけの単純なチャットだった。それが第 10 章で AgentCore Runtime に乗り、第 11 〜 15 章で安全性・評価・観測・セキュリティ・コストを順に獲得した。

このスパイラルが「Production Ready とは何か」の操作的定義である。Production Ready は単一の機能ではなく、素朴な実装に対して 9 つの層を重ねた状態を指す ── そう言い切ってよい。

Production Ready の 15 の判断ポイント

ここからが本章の中核である。シリーズ全体を 1 ページに凝縮した、Production Ready のチェックリスト 15 項目。設計レビューの場で、コードを書く前に、本番デプロイの直前に、繰り返し参照してほしい。

モデルと API（5 項目）

1. モデル選定：階層運用するか単一にするか ユースケースが分類・要約中心なら Haiku 単一でも足りる。複雑な推論やコード生成が混ざるなら Haiku ワーカー + Sonnet 最終判断 の階層運用を検討する。住信 SBI や Pfizer の事例はいずれも階層運用型だ。

2. モデル ID は CRIS を使うか 素のリージョン単独 ID（anthropic.claude-sonnet-4-5-...）ではなく、Cross-Region Inference Profile（us.anthropic.claude-sonnet-4-5）を使う。スループット最大化とフェイルオーバの両方が得られる。Geographic CRIS と Global CRIS の使い分けはデータ主権要件で決める。

3. max_tokens を全呼び出しで明示しているか AWS が「最も多いスロットリングの原因」と明言している。未設定だとモデルの最大値（Sonnet では 64K）が TPM 予約される。要約 500 / 対話 2,000 / コード生成 8,000 のようにユースケース別に右サイズ化する。

4. Converse API を使っているか（InvokeModel ではなく） 新規開発は Converse API が AWS 推奨。モデル間のリクエスト/レスポンス差を吸収し、Tool Use・ストリーミング・マルチモーダルが統一的に書ける。InvokeModel はモデル固有 API が必要なときの最終手段に留める。

5. RAG が必要か、Knowledge Bases か自前構築か RAG が要るかどうかをまず判断する。要るなら最初は Knowledge Bases。S3 + ベクトルストア + 引用付きレスポンスがマネージドで揃う。メタデータフィルタの複雑な要件・自前埋め込みモデルが必要・チャンキングを完全に制御したい、のいずれかが出てから自前構築を検討する。

RAG とエージェント（3 項目）

6. チャンキングは Default 以外を試したか Default のままで本番に出す事例は、ほぼすべて検索精度で苦しむ。FIXED_SIZE 512 トークン + overlap 20% から始め、Hierarchical / Semantic の比較を実データで評価する。セゾンテクノロジーは Advanced RAG で Knowledge Bases 比 +22% 精度を出した。

7. Agents / AgentCore のどちらか 管理画面でツールと指示文を組み立てて素早く動かしたいなら Bedrock Agents。本番運用に耐える Runtime・Memory・Identity・Gateway・Observability が必要なら AgentCore へ移行する。Toyota Motor North America のディーラーアシスタントは v1（RAG）→ v2（AgentCore）の移行が成功事例として公開されている。

8. Guardrails を Detect モードで導入したか いきなり Block モードに入れると、想定外のフォールスポジティブで本番が止まる。Detect モードで 2〜4 週間ログを溜め、フォールスポジティブ率を見てから Block に切り替える。日本語は Standard tier で Content filters / Denied topics / PII filters が利用可能、Contextual grounding は非対応（2026 年 6 月時点）という制約も忘れない。

ガバナンスと評価（3 項目）

9. IAM で Guardrails を強制しているか アプリ側のコードに頼って Guardrails の guardrailIdentifier を渡す設計だと、コード変更ひとつで簡単に外せる。IAM ポリシーで bedrock:GuardrailIdentifier 条件キーを使い、指定ガードレールなしには InvokeModel を呼べないようにする。SCP まで使えば組織横断で強制できる。

10. 評価フレームワーク（LLM-as-a-Judge / AgentCore Evaluations）を Day 1 から組み込んだか 「とりあえず動いた」で本番に出すと、Agent の 3/4 は不可視のままになる。LLM-as-a-Judge で回答品質、AgentCore Evaluations で Action Group + KB + Guardrails の 4 構成すべてを評価する。CI に組み込めば、プロンプト変更でメトリクスが落ちた瞬間に気付ける。

11. CloudWatch メトリクス + Model Invocation Logging を有効化したか bedrock-runtime のメトリクス（Invocations / Latency / Throttles / TokenCount）と Model Invocation Logging はいずれも有効化が必須の入口。Logging が無効だと、ハルシネーションの再現も、コスト原因の特定も、後追いができない。Mask モードでも logs の input には原文が残る ── ここを忘れない。

コストとセキュリティ（4 項目）

12. Application Inference Profile + tag でコスト追跡しているか マルチテナント・マルチアプリで Bedrock を使うなら、Application Inference Profile に tag を付け、CUR と Cost Explorer で tenant 単位・アプリ単位のコスト配賦を行う。これがないと、「どのチームのどの機能がコストを食っているか」が永遠にわからない。

13. PT 検討前に On-Demand + CRIS で稼働率を確認したか Provisioned Throughput の損益分岐は稼働率 80〜85%。1 か月コミットで買って稼働率 50% で回せば、On-Demand より高くつく。まず On-Demand + Global CRIS でスループットを伸ばし、TPS が天井に張り付くようなら初めて PT を検討する。

14. Prompt Caching のヒット率 30% を計測したか Prompt Caching はヒット率 30% 以上でメリットが出る。未満だと逆にコスト増。導入前に CloudWatch メトリクスで実測し、長文 system prompt や Tool 定義などキャッシュ価値の高いブロックを特定する。

15. VPC Endpoint / KMS / SCP でセキュリティ多層防御したか Interface VPC Endpoint で Internet Gateway なしの閉域通信、KMS CMK で保管時暗号化のキー管理を顧客側に、SCP で「Bedrock は東京リージョン以外で叩けない」ような組織横断ガードを敷く。InterWorks のセキュリティガイドが整理しているように、これらは個別の機能ではなく多層防御として一体運用する。

チェックリストの使い方

15 項目すべてに「Yes」と答えられたら、helpdesk-ai は Production Ready と呼んでよい。「まだ No」が混ざっているなら、その項目に対応する章へ戻る ── 番号は章番号とおおむね一致する設計になっている（モデル選定は第 5 章、Converse は第 6 章、RAG は第 8 章、AgentCore は第 10 章、Guardrails は第 11 章、評価は第 12 章、観測は第 13 章、セキュリティは第 14 章、コストは第 15 章）。

設計レビューのアジェンダにこのチェックリストをそのまま貼り付けてもらえれば、本シリーズの目的は半分以上達成されている。

トンネリングの未来 ── Bedrock の今後

シリーズの中で何度も触れたように、Bedrock は 2025 〜 2026 年にかけて静かに、しかし大きく姿を変えてきた。最後に、その変化の延長線にある未来をいくつか言葉にしておく。

エージェントの相互運用 ── MCP / A2A プロトコル

AgentCore は MCP（Model Context Protocol）と A2A（Agent-to-Agent）プロトコルをすでにサポートしている。これは「エージェントが単一サービス内に閉じない」未来を示している。helpdesk-ai のエージェントが Slack のエージェント、SaaS の社内 API エージェント、別の AWS アカウントで動くエージェントとプロトコルで会話する世界が、もう半年先の景色に見え始めている。

オーケストレーションの進化 ── Multi-Agent / Inline / Policy

Multi-Agent Collaboration、Inline Agents、AgentCore Policy ── エージェントを「組み合わせて統治する」道具立てが揃ってきた。1 つの巨大エージェントではなく、専門エージェントの群を中央の Policy で律する設計が、おそらく 2026 年後半から 2027 年の主流になる。

評価とポリシー強制の自動化

AgentCore Evaluations（re:Invent 2025 で Preview）と Automated Reasoning checks（2025-08 GA）は、いずれも「評価を Day 1 から組み込む」という本シリーズの主張を、ツールとして体現するものだ。今後は CI/CD パイプラインに組み込まれ、プロンプトを 1 行変えただけで品質メトリクスとポリシー違反の両方が自動チェックされる体制が標準になっていく。

組織横断 AI ガバナンス ── Cross-Account Safeguards

2026-04 に GA した Cross-Account Safeguards は、「Guardrails や Inference Profile を中央アカウントで一元管理し、子アカウントに配布する」というガバナンス設計を可能にした。これは大企業の AI 統制が、個別プロジェクトの責任から組織横断のプラットフォーム責任へ移っていくことを意味する。CTO / VP of Engineering の関心事は、すでに「安全に AI を作る」から「安全に AI を作らせる」へ移行しつつある。

これらの未来は、本シリーズで扱った 18 章の延長線にある。だから安心してほしい ── 15 の判断ポイントは、明日のあなたを支える設計地図であり、半年後も同じ場所に立たせ続けてくれる。

次に読むべきもの

このシリーズの後に手を伸ばすと有益なものを挙げておく。

本シリーズの付録

  • 付録 A：マルチリージョン設計を Cross-Region Inference Profile で実装する ── 東京 + ソウル + 大阪のリージョン分散と、データ主権要件のある業界での Geographic CRIS の使い分けを扱う
  • 付録 B：コスト見積もりワークシートを作る ── CUR と Application Inference Profile で実測する ── 月次コストを「P95 ベース + ストレージ込み + 評価ジョブ込み」で設計する方法

AWS 公式ドキュメント

AWS Blog の必読シリーズ

re:Invent / AWS Summit セッションの探し方

YouTube の AWS Events チャンネルで「Bedrock」「AgentCore」「Generative AI」で検索すると、その年の re:Invent / AWS Summit のセッションがほぼ網羅できる。重要なのは セッションスライドの最後のページ（参考リンク集） を必ず控えておくこと ── ここに公式 docs と AWS Blog の最新リンクが整理されていることが多い。

re:Invent 2025 のセッションでは、Toyota Motor North America のディーラーアシスタント（AgentCore 移行）と Audi の溶接検査（Bedrock + Computer Vision）が事例として群を抜いて有用だった。第 16 章で触れた内容を映像で追体験したい人にはおすすめする。

おわりに

プロローグに書いたとおり、このシリーズは「PoC で満足しないで本番に出したい人」のためのものだった。

第 1 章で「3 つの壁」を見せ、Part 1 で地図を渡し、Part 2 で素朴な実装を作り、Part 3 で本番要件を重ね、Part 4 で事例とアンチパターンから現場の重力を確認した。そして本章で 15 の判断ポイント にすべてを集約した。

ここまで読んでくれたあなたは、もう Bedrock のドキュメントで迷子にならない。最初に何を選び、次に何を重ねるか、そして「動く」を「正しく動く」に変えるためにどこで立ち止まるべきかが、自分の言葉で語れるはずだ。

helpdesk-ai は架空のアプリだが、あなたの現場には本物の helpdesk-aiがある。社内ヘルプデスクかもしれないし、顧客向けチャットかもしれないし、設計レビューの伴走者かもしれない。何であれ、その本物を Day 1 から Production Ready で立ち上げるための地図を、あなたはもう携えている。

最後に一言、シリーズを締めくくる言葉として残しておく ── Production Ready は機能ではなく、設計の習慣である。15 の判断ポイントを、毎回のコードレビューでひとつずつ確かめる習慣を、ぜひあなたの現場に持ち帰ってほしい。

それでは、よい Bedrock ライフを。

参考文献

シリーズ本文で実際に引用・参照したものに限って、カテゴリ別に整理する。最新情報は常に AWS 公式 docs を優先して参照されたい。

AWS 公式ドキュメント（User Guide / API Reference）

AWS 公式ページ（製品ページ）

AWS What’s New（GA 発表）

AWS Blog（必読ガイド）

事例（Case Studies）

信頼できる技術ブログ / サードパーティ