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

機能カタログ 2026 を俯瞰する ── Foundation Models から AgentCore まで

2026/06/04

機能カタログ 2026 を俯瞰する ── Foundation Models から AgentCore まで

Bedrock 機能カタログ 2026 ── 推論 API / RAG / エージェント / 安全性・評価 / 開発支援 / 運用基盤の 6 グループと、2024–2026 の機能進化タイムライン

対象読者：Bedrock の機能群（30 以上）を俯瞰整理して、Part 2 以降の章選択の地図がほしい読者難易度：★☆☆☆☆（概念整理）想定読了時間：約 30 分関連章：第 8〜15 章（各機能の実装）/ 第 16 章（事例での機能対応）

Bedrock の機能は多い。多すぎる。だが 6 グループに収まる

第 2 章で Bedrock の 位置付け（FMaaS）を、第 3 章で他社サービスとの 設計差（データ主権・IAM 統合・モデル幅）を確認した。本章のテーマは、ここまでで「外から見た Bedrock」を理解した読者に、「内側の地図」 を渡すことだ。

Bedrock のコンソールを開くと、左ペインに 30 個以上のメニューが並ぶ。Foundation Models、Converse API、Knowledge Bases、Bedrock Agents、AgentCore、Bedrock Flows、Guardrails、Model Evaluation、Prompt Management、Bedrock IDE、Application Inference Profiles、Cross-Region Inference、Provisioned Throughput、Batch、Service Tiers、Intelligent Prompt Routing、Prompt Caching、Custom Model Import、Fine-tuning、Distillation … 。

率直に言って、初見では何から触ればよいかわからない。第 1 章で示した「壁 1：機能カタログと設計判断の壁」は、まずこの 見えなさ からくる。

だが安心してほしい。Bedrock の機能は 6 つのグループ に分けて整理すると、ぐっと見通しが良くなる。

A 推論 API ── モデルを呼ぶための入り口
B RAG ── 自社データを LLM に食わせる仕組み
C エージェント ── LLM が自律的にツールを使うための仕組み
D 安全性・評価 ── ガードレールと評価
E 開発支援 ── プロンプト管理と GUI
F 運用基盤 ── スループット・コスト・地域性

本章の目的は、この 6 グループで地図を頭に入れることだ。一つひとつの詳細は Part 2（第 6 〜 10 章）・Part 3（第 11 〜 15 章）で深堀りするので、ここでは「何があるか・いつ使うか」の概略だけ示す。「どれを使うべきか」の判断軸が手元に残れば、本章のミッションは達成だ。

対象読者：第 2 〜 3 章を読み終え、「Bedrock を仕事で使うことになった」段階のエンジニア。読了時間：約 15 分。本シリーズで最も「俯瞰」に振った章。

6 グループの機能カタログ

まず一枚の図で全体像を確認してほしい。

mindmap
  root((Amazon Bedrock<br/>機能カタログ 2026))
    A 推論 API
      InvokeModel
      Converse / ConverseStream
      Messages API ::icon(fa fa-cube)
      Responses / Chat Completions
    B RAG
      Knowledge Bases
      ベクトルストア統合
      チャンキング戦略
      Retrieve / RetrieveAndGenerate
      Reranking
    C エージェント
      Bedrock Agents マネージドな ReAct
      AgentCore 本番運用基盤
        Runtime
        Memory
        Identity
        Gateway
        Browser / Code Interpreter
        Observability
        Policy / Evaluations
      Bedrock Flows
    D 安全性 評価
      Guardrails
        Content Filters
        Denied Topics
        PII / Regex
        Contextual Grounding
        Automated Reasoning checks
      Model Evaluation
        Automatic
        Human
        LLM-as-a-Judge
    E 開発支援
      Bedrock IDE
      Prompt Management
      Prompt Optimize
    F 運用基盤
      Cross-Region Inference
      Application Inference Profiles
      Provisioned Throughput
      Batch / Flex / Priority
      Intelligent Prompt Routing
      Prompt Caching
      Custom Model Import
      Fine-tuning / Distillation

これが Bedrock の機能の 全体像 だ。以下、グループごとに「何があるか・いつ使うか」を見ていく。

A 推論 API ── モデルを呼ぶ入口

Bedrock の心臓部。モデルにテキストを投げて応答をもらう、最も基本的な操作だ。

API	何ができるか	いつ使うか
InvokeModel / InvokeModelWithResponseStream	モデル固有のリクエスト形式を直接叩く低レベル API	レガシー実装の維持、特殊パラメータ利用時
Converse / ConverseStream	マルチターン会話の統一 API。`messages` / `system` / `inferenceConfig` / `toolConfig` / `guardrailConfig` を共通スキーマで扱える	新規開発の第一選択（AWS 推奨）
Messages API（Anthropic ネイティブ）	`anthropic` SDK をそのまま Bedrock 向けに使える	既存の Anthropic API コードを Bedrock へ移行する場合
Responses / Chat Completions API（OpenAI ネイティブ）	`openai` SDK をそのまま Bedrock 向けに使える（`bedrock-mantle` endpoint 経由）	既存の OpenAI コードを Bedrock へ移行する場合

判断はシンプルだ。新規開発なら Converse 一択。AWS 公式が明確に推奨しており、複数モデルを切り替える前提のアプリでは Converse の統一スキーマが圧倒的に楽になる。Messages / Responses API は「既存コードの最小差分での移行」が目的の選択肢と考えてよい。

実装の詳細は第 6 章（Converse API）と第 7 章（Streaming + Tool Use）で扱う。

B RAG ── 自社データを LLM に食わせる

LLM 単体では「自社の社内規程」「最新の顧客 FAQ」「業務マニュアル」は答えられない。これを解決するのが Retrieval-Augmented Generation（RAG） で、Bedrock のマネージドサービスが Knowledge Bases だ。

Knowledge Bases は次の 4 層を 1 つのコンソールで束ねている。

データソース ── S3、Confluence、Salesforce、SharePoint、Web Crawler、カスタム。構造化データ側は Redshift / Aurora 等の自然言語 SQL 変換にも対応
ベクトルストア ── OpenSearch Serverless（コンソールから自動作成可）、Aurora PostgreSQL + pgvector、Pinecone、Redis Enterprise、MongoDB Atlas。さらに Amazon Kendra GenAI Index（フルマネージド検索）、Amazon Neptune Analytics（GraphRAG）といった特殊統合
エンベディング ── Titan Embeddings v2、Cohere Embed v4、Amazon Nova Multimodal Embeddings 等
検索 API ── Retrieve（検索のみ）/ RetrieveAndGenerate（検索 + 生成を一発で）/ Reranking（Cohere Rerank 3.5）

いつ使うか はわかりやすい。「LLM 単体では答えられない知識をモデルに与えたい」── これに尽きる。社内ドキュメント Q&A、技術サポート、商品レコメンドなど、プロダクション利用の 7 割がここに収まる と言ってよい現実がある。

ただし、Knowledge Bases は「デフォルト設定で動くが、デフォルトのままでは品質が出ない」というクセが強いサービスでもある。チャンキングサイズ、オーバーラップ、エンベディングモデル、検索後のリランクなど、調整ポイントが多い。詳細は第 8 章で深堀りし、第 11 章（Guardrails の Contextual Grounding）と第 12 章（RAG Evaluation）で品質保証側を扱う。

C エージェント ── LLM が自律的に動くための仕組み

LLM がツールを使い、複数のステップに分けて自律的にタスクを進める ── いわゆる エージェント の領域だ。Bedrock はここに 3 つの選択肢を持っている。

機能	立ち位置	いつ使うか
Bedrock Agents（マネージドな ReAct）	コンソールからノーコードで作れる従来型マネージドエージェント。Action Group（Lambda 経由のツール）、Knowledge Base 連携、4 ステージの Advanced Prompt、Trace、Alias/Version 管理	プロトタイプを早く立ち上げたい / コンソールで完結させたい
AgentCore（本番運用基盤）	フレームワーク非依存・モデル非依存の本番運用用エージェント基盤（後述）	Strands Agents / LangGraph / CrewAI / 自作フレームワークなどで本格的にエージェントを構築・運用したい
Bedrock Flows	Prompt / Agent / KB / Guardrail / Lex / Lambda をドラッグ&ドロップで繋ぐ Visual Workflow Builder	LLM の決定論的なワークフローを組みたい（自律性は抑えめ）

ここで強調しておきたいのは、AgentCore は Bedrock Agents の「上位互換」ではないことだ。AWS は AgentCore を「Bedrock Agents を置き換えるもの」とは位置付けておらず、別レイヤーのインフラとして整理している。Bedrock Agents が「コンソールで完結するマネージドエージェント」だとすれば、AgentCore は「任意のフレームワークでエージェントを書いた人のための本番運用基盤」だ。

AgentCore の中身は、9 つのコンポーネントから成る。

コンポーネント	役割
Runtime	低レイテンシ・セッション分離のサーバーレスランタイム
Memory	短期セッション + 長期メモリ。re:Invent 2025 で Episodic Memory が追加
Identity	OAuth 2.0 / API Key の Token Vault。Slack / GitHub / Salesforce など外部 SaaS への安全アクセス
Gateway	既存 API / Lambda を MCP / OpenAPI 経由でツール化、認証認可付き
Browser	マネージド Web ブラウザ。自律ブラウジングの実行環境
Code Interpreter	隔離されたコード実行環境
Observability	ステップごとの実行可視化。CloudWatch / Datadog / LangSmith / Langfuse 連携
Policy（Preview）	自然言語ポリシーを Cedar に変換し、Gateway と統合してアクション単位で違反を遮断
Evaluations（Preview）	13 種の prebuilt evaluator を本番トラフィックに対し継続実行

ここで一つ重要な注意を入れておく。AgentCore は GA したばかりで、各コンポーネントの料金体系は流動的だ。具体的な単価は公式ページの「最新情報」を必ず確認してほしい（本シリーズでも個別単価には踏み込まない）。

実装は第 9 章（Bedrock Agents）と第 10 章（AgentCore）で扱う。Part 2 を通じて、helpdesk-ai は 第 9 章で Bedrock Agents 版を作り、第 10 章で AgentCore に乗せ替える という進化を見せる。

D 安全性・評価 ── 「動く」と「正しく動く」の差を埋める

LLM が出力を返した。それは 安全か？正しいか？ ── これに答える機能群だ。第 1 章で言及した「壁 2」を破るための道具立てがここに集まっている。

Guardrails

Bedrock のガードレール機能。6 つのポリシータイプを持つ。

Content Filters ── Hate / Insults / Sexual / Violence / Misconduct / Prompt Attack。テキスト + 画像
Denied Topics ── 自然言語で「触れてはいけないトピック」を定義
Word Filters ── 単語ベースのフィルタ
Sensitive Information Filters ── PII / Regex でマスクまたはブロック
Contextual Grounding Check ── RAG のハルシネーション検出（日本語非対応 ← 第 11 章で扱う重要な落とし穴）
Automated Reasoning Checks ── 自動推論ベースの論理的整合性検証（2025-08 GA）

Guardrails には Classic / Standard の 2 階層 tier があり、Standard ではコードコメント・変数名内の有害コンテンツも検出する。さらに 独立 API（ApplyGuardrail） を持っており、Bedrock 外のモデル（自前ホスト LLM 含む）にも同じガードレールを適用できる。2026-04 には Cross-Account Safeguards が GA し、組織横断での適用も可能になった。

Model Evaluation

評価機能。4 系統ある。

Automatic Evaluation ── BLEU / ROUGE / Perplexity / Toxicity / Robustness などの自動メトリクス
Human Evaluation ── 自社レビュアー、または AWS マネージドの評価チームに依頼
LLM-as-a-Judge ── 2025-03 GA。Correctness / Completeness / Faithfulness（ハルシネーション）/ Answer refusal / Harmfulness を LLM が評価
RAG Evaluation ── Knowledge Bases の検索・生成品質を評価

いつ使うか は明確だ。Day 1 から。第 12 章で詳しく扱うが、評価は「動くようになってから組み込む」ものではなく、最初から組み込んでおき、改善のたびに回す ものだ。AgentCore Evaluations はこれをさらに進めて、本番トラフィックに対して継続的に評価を回す 思想で設計されている。

E 開発支援 ── プロトタイピングと運用の橋渡し

開発者の生産性を上げるための機能。

Bedrock IDE ── SageMaker Unified Studio 配下の GUI 開発環境。旧 Bedrock Studio がリブランドされたもので、SSO ログイン、KB / Agent / Guardrail を含む GenAI アプリのプロトタイピングをチームで共有できる。いつ使うか ── ノーコード〜ローコードで「まず触ってみる」段階、または非エンジニアと一緒にプロンプトを練りたいとき
Prompt Management ── プロンプトのバージョニング、変数（プレースホルダ）、Variant 比較、Optimize（自動改善）。Flows や推論呼び出しから参照可能。いつ使うか ── プロンプトをコードに直書きする運用が辛くなってきたら

このグループは本シリーズの主軸からは少し外れるが、プロンプトが現場で変更されるレベルのチームでは Prompt Management の導入を強く検討すべきだ。デプロイなしでプロンプトを差し替えられる効果は大きい。

F 運用基盤 ── スループット・コスト・地域性

最後のグループは「本番運用の地味で重要な仕組み」だ。Production Ready の鍵を握る。

機能	何ができるか	いつ使うか
Cross-Region Inference（CRIS）	リージョン横断ルーティング。Geographic（US/EU/APAC 等の境界内）と Global（世界中から最適選択、Geographic より約 10% 安価）の 2 種	本シリーズではほぼ常用。スループット確保とスロットル回避のため
Application Inference Profiles	アプリ単位の論理 ID で推論を発行。コスト配分タグを付けて部門・機能ごとに利用量を CUR / Cost Explorer で追跡	マルチテナント / 複数機能でコスト按分したい
Provisioned Throughput（PT）	Model Units 単位で容量予約。No commitment / 1 month / 6 months のコミットメント	稼働率 80〜85% 以上が見えるとき。詳細は第 15 章
Batch Inference	On-demand から 50% 割引、24 時間以内 SLA	リアルタイム不要のバルク処理（タグ付け、要約バッチ等）
Service Tiers（Flex / Priority）	Flex は −50%（レイテンシ要件緩い）、Priority は +75%（最優先処理）	レイテンシ要件とコスト感度で使い分け
Intelligent Prompt Routing	同一ファミリー内で Haiku ↔ Sonnet 等を自動ルーティング。RAG ユースケースで AWS 実測平均 63.6% コスト削減	プロンプトの難易度差が大きく、軽い質問の比率が高い
Prompt Caching	システムプロンプト等の cache write/read。コスト最大 90% 削減、レイテンシ最大 85% 削減。ただしヒット率 30% 以上が損益分岐	長いシステムプロンプトを反復利用する
Custom Model Import	S3 上の自前モデル（Llama / Mistral / Flan / GPT-NeoX 系のアーキテクチャ）を Bedrock のサーバーレス API として呼べる	自前 fine-tune したモデルを Bedrock の運用基盤に乗せたい
Fine-tuning / Distillation / Continued Pre-training	Nova、Claude 3 Haiku、Llama、Titan、Cohere 他で対応	ベースモデルをドメイン適応させたい

このグループの機能は「初日からは意識しないが、本番に出る前後で必ず触ることになる」性質を持つ。第 15 章（コスト設計）と付録 A（マルチリージョン）で具体的に深堀りする。

2024 〜 2026 で何が追加されたか ── タイムラインで読む

ここまで「何があるか」を見てきた。次に「いつ来たか」を時系列で把握しておく。Bedrock の進化速度を理解しておくと、「来年もきっと色々増える」という前提でアーキテクチャを組めるようになる。

timeline
  title Amazon Bedrock 機能進化タイムライン（2024-2026）
  2024-11 : Bedrock Flows GA
          : Inline Agents GA
  2024-12 : Multi-Agent Collaboration GA
          : Guardrails 最大 85% 値下げ
          : LLM-as-a-Judge Preview
          : Intelligent Prompt Routing Preview
          : Prompt Caching Preview
  2025-03 : LLM-as-a-Judge GA
          : Image content filters GA
  2025-04 : Intelligent Prompt Routing GA
          : Guardrails 日本語 Standard tier 対応
  2025-07 : AgentCore Preview
  2025-08 : Automated Reasoning checks GA
  2025-10 : AgentCore GA
  2025-12 : AgentCore Policy Preview
          : AgentCore Evaluations Preview
          : Episodic Memory（AgentCore Memory 拡張）
  2026-04 : Cross-Account Safeguards GA
          : Cost allocation by IAM principal

この年表から読み取れる流れは 3 つある。

2024 年後半は「ワークフローとガードレール」フェーズ ── Flows、Inline Agents、Multi-Agent Collaboration、Guardrails 値下げ。LLM を「決定論的に組み合わせる」道具が整った
2025 年は「評価とエージェントインフラ」フェーズ ── LLM-as-a-Judge、Intelligent Prompt Routing、AgentCore Preview → GA。「動く」を「正しく動く」に進化させる道具が一気に揃った
2025 年末〜 2026 年は「ポリシーと運用」フェーズ ── AgentCore Policy / Evaluations、Cross-Account Safeguards、IAM principal 単位のコスト配分。大企業の規制要件・組織横断ガバナンス に応える機能が前面に出てきた

つまり Bedrock は「機能追加」ではなく「Production Ready のための機能補完」を続けている。本シリーズが「Production Ready」を掲げるのは、まさにこの流れに沿ったタイミングだからだ。

いつ何を使うか ── クイック判断表

最後に、ユースケースから機能セットへの逆引き表を置いておく。Part 2 以降を読むときの 目次的なリファレンス として活用してほしい。

典型ユースケース	使う機能セット	主に扱う章
チャットボット（FAQ・問い合わせ対応）	Converse + Streaming + Guardrails + Application Inference Profiles	ch06, 07, 11, 13
社内ドキュメント Q&A（RAG）	Knowledge Bases + Converse + Guardrails（Contextual Grounding） + Model Evaluation（RAG Eval）	ch08, 11, 12
業務自動化エージェント（多段ステップ）	Bedrock Agents → AgentCore（Runtime + Memory + Identity + Gateway + Observability）	ch09, 10
マルチモーダル入力（画像・音声・動画）	Converse（Vision）+ Knowledge Bases マルチモーダル + Nova / Pixtral / TwelveLabs	ch07, 08
コスト最適化重視のチャット	Intelligent Prompt Routing + Prompt Caching + Batch	ch15
規制業種・データ主権要件	VPC Endpoint + KMS CMK + Geographic CRIS + Guardrails + Model Invocation Logging	ch14, 付録 A
自前 fine-tune モデル本番運用	Custom Model Import + Provisioned Throughput + Application Inference Profiles	（シリーズ範囲外、ch15 で言及）
決定論的なワークフロー（承認フローなど）	Bedrock Flows + Prompt Management + Guardrails	（Part 2 で概念のみ言及）
本番トラフィックの継続評価	AgentCore Evaluations + LLM-as-a-Judge + Model Invocation Logging	ch10, 12

この表は 「機能名から考える」のではなく「ユースケースから考える」 ためのものだ。Bedrock を初めて触る人は、まず自分のユースケースをこの表の左列にマッピングし、右列の機能セットから順に学ぶと迷いが少ない。

地図ができた

これで、Bedrock の機能地図が手元に揃った。本章のまとめは次の通りだ。

Bedrock の機能は 6 グループ（推論 API / RAG / エージェント / 安全性・評価 / 開発支援 / 運用基盤）に整理できる
新規開発の推論 API は Converse 一択。Messages / Responses は既存コード移行用
RAG は Knowledge Bases、エージェントは Bedrock Agents → AgentCore の流れで進化している
AgentCore は Bedrock Agents の上位互換ではなく、別レイヤーの本番運用基盤
Guardrails と評価は Day 1 から。後付けは「壁 2」を破れない
運用基盤は CRIS / Application Inference Profile / Intelligent Prompt Routing / Prompt Caching が現代の標準スタック
2025 年は「評価とエージェントインフラ」、2026 年は「ポリシーと組織横断ガバナンス」が拡充された

次章で「どのモデルを選ぶか」に進む。第 4 章で機能の地図を手にした読者は、次に「16 プロバイダー・100+ モデルから何を選べばよいか」という問いに直面するはずだ。Claude / Nova / Llama / Mistral / Cohere の使い分けを、ユースケース起点で整理していく。

なお、本章で名前だけ出した個別機能は、Part 2 で順番に深堀りする。RAG（第 8 章）/ Bedrock Agents（第 9 章）/ AgentCore（第 10 章）/ Guardrails（第 11 章） は、それぞれ独立した章として扱う。本章の地図を片手に、Part 2 へ進んでほしい。

章末まとめ

Bedrock の機能は A 推論 API / B RAG / C エージェント / D 安全性・評価 / E 開発支援 / F 運用基盤 の 6 グループに整理できる

新規開発の推論は Converse API が第一選択。Messages / Responses API は既存コード移行用

AgentCore は Bedrock Agents の置き換えではなく、フレームワーク非依存の本番運用基盤。9 コンポーネント構成

Guardrails と Model Evaluation は Day 1 から組み込む。Day 1 設計は本シリーズの中心思想

運用基盤は CRIS / Application Inference Profile / Intelligent Prompt Routing / Prompt Caching が標準スタック

2024 年後半「ワークフロー/ガードレール」→ 2025 年「評価/エージェントインフラ」→ 2026 年「ポリシー/組織横断」と進化中

個別機能の詳細は Part 2（実装）・Part 3（本番化）で深堀りする。本章は地図の役割