目次を表示する

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

Bedrock の位置付けを理解する ── AWS Generative AI Stack の中で何を担うか

Bedrock の位置付けを理解する ── AWS Generative AI Stack の中で何を担うか

対象読者：AWS の主要サービス（IAM・S3・Lambda）を知っているが、AI 関連サービス（Bedrock / SageMaker / Q）の棲み分けは曖昧という読者 難易度：★☆☆☆☆（概念導入） 想定読了時間：約 20 分 関連章：第 1 章（プロローグ）/ 第 4 章（機能カタログ）/ 第 16 章（事例）

タブ 17 枚問題、もう一度

プロローグで「Bedrock のドキュメントを開いたらブラウザのタブが 17 枚になっていた」という状況を共有しました。あれは決して誇張ではありません。Foundation Models、Knowledge Bases、Bedrock Agents、AgentCore、Guardrails、Model Evaluation、Prompt Management、Application Inference Profiles、Cross-Region Inference、Provisioned Throughput、Bedrock IDE。並べただけでめまいがします。

ただ、よく見るとこれらは全部「Bedrock の中の機能」です。そもそも、Bedrock そのものは AWS の中で何なのか。この問いが先に来ます。

プロローグで挙げた 壁 1 ── 機能カタログと設計判断の壁 の、最初の判断はじつは「Knowledge Bases か Agents か」ではありません。**「Bedrock を選ぶか、それとも別の AWS サービスを選ぶか」**です。ここを飛ばすと、その先のすべての設計が宙に浮きます。たとえば、自分でモデルを訓練する必要がある案件で Bedrock を選んでしまうと、Fine-tuning 機能の物足りなさにぶつかった瞬間に「やっぱり SageMaker AI に乗り換え」となり、Bedrock の RAG・Guardrails 周りの設計資産がまるごと無駄になります。

逆に、社内の社員ナレッジ検索 BOT を素直に Bedrock で組み始めてしまい、3 か月後に「これ Amazon Q Business で 10 分で作れたな」と気付くケースもあります。本シリーズで作る helpdesk-ai も、用途を絞れば Q Business でいけてしまう一面があります。にもかかわらず Bedrock で作るのは、後章で重ねていく Guardrails、AgentCore、評価・観測の設計判断こそが学びの本体だからです。

そこで本章では、AWS の Generative AI Stack の中で Bedrock がどの位置にいて、どういう局面で選ぶサービスなのかを、Amazon Q と SageMaker AI との棲み分けを軸に整理します。

AWS Generative AI Stack の 3 階層

AWS は公式の Decision Guide「Bedrock or SageMaker」で、自社の生成 AI 関連サービスを 3 階層で説明しています。下から上へ、抽象度が上がる順に並べると次のようになります。

graph TB
    subgraph App["アプリケーション層 ── 完成品の AI プロダクトとして使う"]
        Q["Amazon Q Business / Q Developer<br/>(月額シート課金・コネクタ設定のみ)"]
    end
    subgraph Platform["プラットフォーム層 ── FM を API で呼ぶ"]
        BR["Amazon Bedrock<br/>(FMaaS・16 プロバイダー・100+ FM)"]
    end
    subgraph Infra["インフラ層 ── モデルを自分で訓練・ホストする"]
        SM["Amazon SageMaker AI<br/>+ Trainium / Inferentia"]
    end

    App --> Platform
    Platform --> Infra

    classDef topLayer fill:#fef3c7,stroke:#d97706,stroke-width:2px
    classDef midLayer fill:#dbeafe,stroke:#2563eb,stroke-width:3px
    classDef botLayer fill:#dcfce7,stroke:#16a34a,stroke-width:2px
    class Q topLayer
    class BR midLayer
    class SM botLayer

この図でまず押さえてほしいのは、3 つは縦に積まれているように見えて、実際にはそれぞれ別の顧客に向けて作られているという点です。

  • Amazon Q は「AI を導入したい部門マネージャー」が顧客。ITS が SaaS を選定して各部署に配るのと同じ感覚で、シート単位で導入できる完成品プロダクトです。
  • Amazon Bedrock は「LLM を組み込んだ独自プロダクトを作るアプリ開発者」が顧客。FM を所有せずに API で呼ぶ、いわゆる FMaaS（Foundation Model as a Service）として位置付けられています。
  • Amazon SageMaker AI は「モデルを自分で訓練・改造したいデータサイエンティスト / ML エンジニア」が顧客。Trainium / Inferentia という AWS 独自アクセラレータと組み合わせて、訓練ジョブを自分で回します。

「自分が今やろうとしていることは、どの顧客の作業に近いか」を考えると、最初の選択が一段見通せます。helpdesk-ai を組み立てる本シリーズの読者は、ほぼ間違いなく真ん中の Bedrock 層の住人です。ただし、なぜ Q ではないのか、なぜ SageMaker ではないのか、を言語化できる状態にしておくことが、その後のすべての設計判断の根っこになります。

3 つを棲み分ける 5 つの基準

AWS 公式の Decision Guide が掲げる比較軸を、本シリーズで使う言葉に整えると、次の 5 つに整理できます。

観点BedrockSageMaker AIAmazon Q
抽象度高（API 呼び出しのみ）低（インフラ・パイプラインを自分で組む）最高（プロダクトとして完成済み）
主ユーザーアプリ開発者データサイエンティスト / ML エンジニアエンドユーザー / 部門マネージャー
課金モデルAPI 呼び出し（トークン）/ Provisioned Throughputコンピュート時間 + ストレージ月額シート課金
カスタマイズ性Fine-tuning / Custom Model Import / Knowledge Bases訓練から完全自由ほぼなし（コネクタ設定のみ）
典型用途RAG、エージェント、Copilot 機能独自モデル開発、ML 全般社内ナレッジ Q&A、コーディング支援

この表は丸暗記する必要はありませんが、次のように読むのが実務的です。

抽象度 は「自分が触る粒度」を表します。Q はもう触らなくていい、Bedrock は API を叩く、SageMaker は学習スクリプトを書く ── この順で抽象度が下がります。「自分は今、どの粒度の作業をしたいか」を最初に決めると、3 択は半分くらい絞れます。

主ユーザー は「どの部署が予算を持つか」と読み替えると分かりやすくなります。Q はだいたい総務・人事・営業企画あたりが顧客で、月額シート単位の予算が立てやすい。Bedrock はプロダクト開発チーム / プラットフォーム部門が予算を持ち、API 呼び出し量で費用を計画します。SageMaker AI はデータサイエンス部門が GPU 時間を計画します。組織の予算構造が、サービス選定にそのまま反映されることが多いということです。

課金モデル は 「コストが何にスケールするか」 を表します。Q はユーザー数、Bedrock はリクエスト量、SageMaker は GPU 稼働時間。helpdesk-ai のように「社員 5,000 人 × 月 20 リクエスト = 月 10 万リクエスト」のようなスケールするワークロードは、シート課金より API 課金のほうが大抵安く済みます。

カスタマイズ性 は本シリーズが最も意識する軸です。Bedrock は「マネージドの中で許される範囲のカスタマイズ」を提供します。Fine-tuning、Custom Model Import、Knowledge Bases、Prompt Management といった機能は、いずれもプロバイダー提供 FM の上に薄く乗る仕組みです。一方、ゼロから事前学習をしたい・独自アーキテクチャを試したい場合は SageMaker AI に降りる必要があります。

典型用途 は迷ったときの当てはめ用です。helpdesk-ai のように「社員問い合わせに対し、社内規程と社内 API と Web 検索を組み合わせて答える」というワークロードは、Q でも一部できますが、Guardrails・評価・観測を Day 1 から設計に組み込みたいなら Bedrock が素直です。

Bedrock を選ぶか、別の AWS サービスにすべきか

3 つの棲み分け基準を踏まえると、選択判断は次のフローに落ちます。

flowchart TD
    Start["生成 AI 機能を入れたい"] --> Q1{"既製プロダクト<br/>で十分か?"}
    Q1 -- "はい (社内 Q&A / コード補助)" --> AmazonQ["Amazon Q Business<br/>/ Q Developer を選ぶ"]
    Q1 -- "いいえ (独自 UX が必要)" --> Q2{"独自モデルを<br/>訓練する必要があるか?"}
    Q2 -- "はい (専用アーキ・<br/>完全自前学習)" --> SageMaker["SageMaker AI を選ぶ<br/>(必要なら Bedrock と併用)"]
    Q2 -- "いいえ (提供 FM で十分)" --> Bedrock["Amazon Bedrock を選ぶ<br/>(本シリーズの対象)"]

    classDef decision fill:#fef3c7,stroke:#d97706
    classDef result fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    classDef bedrock fill:#dcfce7,stroke:#16a34a,stroke-width:3px
    class Q1,Q2 decision
    class AmazonQ,SageMaker result
    class Bedrock bedrock

このフローは粗いですが、最初の絞り込みとしては十分です。実務では「Bedrock + SageMaker」「Bedrock + Q」のような併用も普通にあり得ますが、まずは主軸をどこに置くかを決めます。本シリーズは Bedrock を主軸に置く前提で書かれています。

なお、AWS は 2026 年現在も、Q と Bedrock の境界を意図的に重ねる動きを続けています。たとえば Q Business の中で Bedrock の Custom Plugin を呼べたり、AgentCore に乗せたエージェントを Q から呼べたりします。「Q か Bedrock か」は二択ではなく、**「主軸を Bedrock に置き、Q を窓口として併用する」**のような構成も今後増えるはずです。

「Foundation Model as a Service（FMaaS）」とは何か

ここまでで「Bedrock は 3 階層の真ん中、FMaaS の代表格」と整理しました。では FMaaS という概念は、より噛み砕くと何を指しているのでしょうか。本シリーズを貫く中心概念なので、4 つの特徴に分解しておきます。

1. モデルを所有しない

Bedrock を使うとき、私たちは Anthropic・Meta・Mistral・Cohere・Amazon・OpenAI・DeepSeek などのモデルを AWS が代行ホストした形で 利用します。モデル本体は AWS のインフラの上で動いていますが、知財はあくまでプロバイダー側にあります。

この「所有しない」が効いてくるのが、バージョンアップのコストがほぼゼロだという点です。Claude Sonnet 4 系から 4.5 系へ、Llama 3.3 から Llama 4 へ ── 新しい世代が出るたびにモデル ID を差し替えるだけで切り替えられます。自前ホストだとモデル変更ごとに GPU 再配備・推論最適化・キャパシティ計画のやり直しが発生しますが、そこを AWS が肩代わりしてくれている、というのが FMaaS の最初の恩恵です。

2. 統一 API

2026 年 6 月時点で Bedrock は 16 プロバイダー・100 以上の FM を提供していますが、これらを 同じインターフェース で呼べます。これが 2 つ目の特徴です。

具体的には次の API があり、bedrock-runtime と bedrock-mantle という 2 つのエンドポイントに分かれて提供されています。

  • InvokeModel / InvokeModelWithResponseStream：モデル固有のリクエスト/レスポンス形式を直接叩く低レベル API
  • Converse / ConverseStream：マルチターン会話向けの統一 API。新規開発では AWS 公式が Converse を推奨
  • Anthropic Messages API ネイティブ、OpenAI Responses / Chat Completions API ネイティブ：2025〜2026 で追加。anthropic / openai SDK をそのまま Bedrock 向けに使える

このうち本シリーズの実装章では Converse API を主に使いますが、その理由は単純で、Tool Use や Guardrails 設定を含めて モデルが変わっても呼び方が変わらない からです。実運用で「Claude から Nova に切り替えてコスト最適化」のような判断をしたとき、コードがほぼ書き換え不要になります。

3. AWS データ主権

ここが Bedrock を Production で選ぶ最大の理由になることが多い項目です。AWS 公式の Security & Privacy ページには、次のように明記されています。

“Your data is not shared with model providers, and is not used to train the underlying models.”

平たく言うと、プロンプトや fine-tune データはモデルプロバイダーには渡らず、FM の学習にも使われないということです。Anthropic のモデルを呼んでいても、そのプロンプトが Anthropic 側に転送されるわけではありません。データは AWS のリージョン内で完結します。

これは規制業界 ── 金融・医療・公共・製造の図面データ ── にとって、しばしば「OpenAI 直叩きを選べない理由」そのものになります。GDPR・APPI（個人情報保護法）対応の文脈でも、AWS のリージョン境界内で処理が閉じることは大きな安心材料になります。本シリーズの後章（特に 第 16 章の事例 と 第 18 章のエピローグ）で、このポリシーが企業の移行判断にどう効いたかを繰り返し見ることになります。今の段階では「Bedrock を選ぶ強い理由のひとつはこれだ」と覚えておいてください。

4. AWS ネイティブ統合

最後の特徴は「他の AWS サービスとシームレスに繋がる」ことです。これも他社 FMaaS と比べたときの差別化軸として大きく効いてきます。

  • IAM：「このロールはこのモデルしか呼べない」「このアカウントの Bedrock 呼び出しはこの Guardrail を強制する」を IAM ポリシーで宣言できる
  • VPC Endpoint / PrivateLink：Bedrock 呼び出しをインターネットに出さず、VPC 内に閉じられる
  • KMS：プロンプトログや fine-tune データを CMK で暗号化
  • CloudTrail：全 API 呼び出しが監査ログとして残る
  • CloudWatch：トークン使用量・スロットリング・レイテンシをメトリクス監視
  • Cost Explorer / CUR：Application Inference Profile に付けたタグで、アプリ単位・部門単位のコスト追跡

「LLM を業務システムに組み込むときに必要になる周辺要件」が、AWS で運用している既存システムの作法そのままで満たせる ── これが、AWS 中心の組織にとって Bedrock が「最後はそこに落ち着く」理由です。第 14 章のセキュリティ設計、第 13 章の観測、第 15 章のコストはどれも、この AWS ネイティブ統合の上に成り立っています。

Bedrock Studio から Bedrock IDE へ ── 統合の流れの中で

ここで小さな歴史的補足を入れておきます。Bedrock の周辺ツールとして、2024 年 5 月に Bedrock Studio という Web ベースのプロトタイピング環境が Preview リリースされました。SSO ログイン、Knowledge Base / Agent / Guardrail を組み合わせた GenAI アプリの試作、チーム共有ができる ── という位置付けでした。

その後、2024 年 12 月に Bedrock Studio は「Amazon Bedrock IDE」に改名され、SageMaker Unified Studio の配下に統合されました。AWS 公式 Decision Guide にも次のように記載されています。

Amazon Bedrock Studio, renamed to Amazon Bedrock IDE, is now available in Amazon SageMaker Unified Studio.

なぜ統合されたのか。背景には、AWS が 「データ・ML・GenAI を扱う統一ワークスペース」 として SageMaker Unified Studio を打ち出している事情があります。データ準備（Glue / Lake Formation）、ML 訓練（SageMaker AI）、GenAI 開発（Bedrock IDE）、BI（QuickSight）を 1 つの IDE から扱う ── という構想の中に、Bedrock Studio が吸収された形です。

この経緯から学べる教訓は 2 つあります。

ひとつは、AWS は Bedrock 単独のプロダクトとしてではなく、SageMaker AI も含む大きな AI スタックの一部として Bedrock を位置付けているということ。これは前節の 3 階層図と一致しています。Bedrock を選ぶ判断は、長期的には SageMaker AI との接続や Q への露出も視野に入る、ということです。

もうひとつは、周辺ツール（特に GUI 系）はリブランドや統合が頻繁に起きるということ。本シリーズで主に扱うのは API・SDK レベルの設計です。なぜなら、bedrock-runtime の Converse API や Guardrails の ApplyGuardrail API は変わりにくいのに対し、Bedrock Studio / Bedrock IDE のような GUI ツールは AWS 全体の戦略次第で形が変わるからです。Production Ready の土台は API レベルの設計判断だ、と覚えておいてください。

次章への接続

ここまでで、Bedrock が AWS の Generative AI Stack の中で「FMaaS の中層」を担い、Amazon Q（プロダクト）と SageMaker AI（自前訓練基盤）と棲み分けながら独自の位置を占めていることを確認しました。「Bedrock を選ぶか、別の AWS サービスにすべきか」という最初の設計判断には、これで一段解像度高く答えられるはずです。

ただ、ここで気付くはずです。FMaaS というカテゴリ自体は、他社にも存在します。OpenAI Platform、Azure OpenAI Service / Azure AI Foundry、Google Vertex AI、Anthropic API 直叩き ── どれも「自分でモデルを訓練せず API で呼ぶ」という点では同じ FMaaS です。

であれば、次の問いは自然とこうなります。

AWS の Bedrock を選ぶか、それとも他社の FMaaS を選ぶか。

これは「データ主権」「モデルラインナップ」「価格モデル」「エンタープライズ統合」など、いくつもの軸で評価する必要のある設計判断です。第 3 章「他社サービスとの設計差を読み解く」で、OpenAI / Azure OpenAI / Vertex AI / Anthropic 直叩きと Bedrock を、設計判断の観点から比較していきます。

そして「Bedrock を選ぶ」と決めた後の最初の難所が、本章冒頭の「タブ 17 枚問題」── つまり機能の多さに圧倒されることです。これに対しては、第 4 章「機能カタログ 2026 を俯瞰する」 で 2026 年 6 月時点の全機能を 1 枚の地図に整理します。本章は AWS Generative AI Stack の中での位置付けでしたが、第 4 章は Bedrock の内部地図、と覚えてください。

章末まとめ

  • AWS の Generative AI Stack は 3 階層 ── 上から Amazon Q（プロダクト）/ Bedrock（FMaaS）/ SageMaker AI（自前訓練基盤）
  • 3 つは「抽象度・主ユーザー・課金モデル・カスタマイズ性・典型用途」の 5 軸で棲み分ける。スケールするワークロードかつ Guardrails / 評価 / 観測を設計に組み込みたいなら Bedrock が素直
  • Bedrock は FMaaS（Foundation Model as a Service）の代表格で、特徴は「モデルを所有しない / 統一 API / AWS データ主権 / AWS ネイティブ統合」の 4 点
  • AWS 公式の明文化：「顧客データはモデルプロバイダーに共有されず、FM の学習にも使用されない」── これが Bedrock を Production で選ぶ最大の理由になることが多い（第 14 章セキュリティ章・第 16 章事例章で繰り返し回収する）
  • Bedrock Studio は 2024 年 12 月に Bedrock IDE に改名され SageMaker Unified Studio 配下に統合。Bedrock は単独ではなく AWS の AI スタック全体の一部として進化している
  • 次章では「他社の FMaaS と Bedrock の設計差」を読み解く。第 4 章では Bedrock 自身の機能カタログを 1 枚の地図に整理する