生成 AI を業務に組み込む話が来て、「とりあえず Bedrock で」と言われたものの、それが何を肩代わりしてくれるサービスなのか、どこからを自分で設計しなければいけないのかを説明できずにいないでしょうか。モデルの名前は次々に増え、ナレッジベース、エージェント、ガードレールと機能の名前も多く、SageMaker との違いを聞かれると答えに詰まりがちです。
この記事では Amazon Bedrock を、「基盤モデルを借りて呼ぶ窓口」と、その周りに置かれた部品の集まりとして整理します。料金の金額やモデルの一覧は変わるので書かず、判断の軸と、公式ドキュメントに書かれている事実だけを扱います。
この記事の結論
- Amazon Bedrock は、複数の会社の基盤モデルを API で呼び出せるフルマネージドのサービスで、推論の基盤を自分で運用しなくて済みます。
- モデルは入出力の種類・品質・速さと費用・扱える長さ・リージョンでの提供状況の軸で選び、モデル評価で自分の業務のデータを使って比べます。
- ナレッジベースは RAG を、エージェントは複数の手順の計画と API の呼び出しを、ガードレールは有害な内容や個人情報の扱いを受け持ちます。
- Bedrock はプロンプトと応答を基盤モデルの学習に使わず、モデル提供元にも渡さないと公式ドキュメントに書かれています。
- 学習済みのモデルで作るなら Bedrock、学習と推論の基盤を細かく制御するなら Amazon SageMaker AI が向いています。
Amazon Bedrock とは何か（何を借りるサービスか）
たとえるなら、腕の良い専門家を何社分もそろえた窓口です。自分で専門家を雇って育てなくても、用件を窓口に出せば、選んだ専門家が答えを返してくれます。窓口の建物や専門家の机の手配は、窓口の側が持ちます。
正確な言葉に戻すと、Amazon Bedrock は、主要な AI 企業の高性能な基盤モデルを、安全に使えるようにするフルマネージドのサービスです。基盤モデルとは、大量で多様なデータで事前に学習され、さまざまな作業に転用できる大きなモデルのことです。Bedrock はサーバーレスなので、推論を動かすサーバーやGPUを自分で用意・運用する必要はありません。Amazon 自身のモデル（Amazon Nova など）と、他社のモデルが並んでいます。
アプリケーションから見ると、Bedrock は次の部品の集まりです。
WHAT YOU RENT4つの部品
Bedrock はモデルを呼ぶ窓口と、その周りの3つの部品
-
呼ぶ
モデルを呼ぶ API — 選んだ基盤モデルに推論させる
Converse API で共通の形に。基盤は AWS が持つ
-
調べる
ナレッジベース — 社内文書を検索して根拠に足す
RAG の取り込み・埋め込み・検索を受け持つ
-
動く
エージェント — 手順を計画して API を呼ぶ
アクショングループ（OpenAPI ＋ Lambda）
-
止める
ガードレール — 入力と出力を点検する
有害な内容・拒否するトピック・個人情報
- モデルを呼ぶ API: モデルを選んで推論させる。Converse API はメッセージ形式に対応したモデルを共通の形で呼べる
- ナレッジベース: 社内文書などを検索して、答えの根拠として足す（RAG）
- エージェント: 依頼を手順に分けて計画し、API を呼んで実行する
- ガードレール: 入力と出力を点検し、有害な内容や個人情報を止める・伏せる
呼び出しの権限は IAM で絞ります。どのモデルを、どの役割のプログラムが呼べるかは、ほかの AWS サービスと同じくポリシーで決めます。
READ ALSO — 未経験向け・段1 入口
IAM ポリシーの評価の仕組み｜許可と拒否はどの順で決まるか
モデルはどう選ぶのか（選び方の軸）
「一番新しくて一番大きいモデル」が、いつも正解とは限りません。業務の要件ごとに軸を決めて比べます。
| 軸 | 何を見るか | 確かめ方 |
|---|---|---|
| 入出力の種類 | テキストだけか、画像も読むか・作るか、埋め込み（ベクトル）が欲しいか | 公式のサポートされているモデルの一覧 |
| 品質 | 自分の業務の入力で、期待する答えが返るか | モデル評価で、自動の指標や人の評価で比べる |
| 速さと費用 | 応答までの時間と、トークンあたりの料金 | 小さいモデルや、大きいモデルの知識を移した蒸留モデルも候補にする。料金は公式の料金ページ |
| 扱える長さ | 一度に入れられる入力と出力の量（コンテキストウィンドウ） | モデルごとの説明ページ |
| 提供状況 | 使いたいリージョンで呼べるか、使いたい機能に対応しているか | リージョンとモデルの対応表。クロスリージョン推論で地域内の別リージョンに振り分ける方法もある |
いくつか補足します。
モデル評価は、候補のモデルを自分のデータで比べる機能です。公開されたベンチマークの順位は、自分の業務での出来を保証しません。過去の問い合わせを集めたものなど、実際の入力に近いデータで比べるのが確かです。
Converse API を使って書いておくと、モデルを差し替えるときの書き直しが少なくて済みます。モデルの選択は一度きりの決定ではなく、新しいモデルが出るたびに見直すものなので、差し替えやすい形にしておくこと自体が設計です。
クロスリージョン推論は、推論プロファイルを指定すると、同じ地域（米国・EU など）の中のリージョンに Bedrock がリクエストを振り分ける仕組みです。データがどのリージョンで処理されるかに決まりがある業務では、どの推論プロファイルを使うかを先に確かめます。
モデルの一覧と対応リージョンはよく変わります。記事やブログの表ではなく、公式の一覧で確かめてください。
CHECK 1ここまでの確認
同じ業務を複数の基盤モデルで試し比べたいとき、Bedrock 側で呼び出しのコードを書き分けずに済ませる手がかりになるものはどれですか?
答えと解説
答え: 2. メッセージ形式のモデルに共通の形で呼べる Converse API を使う
Converse API は、メッセージ形式に対応したモデルを共通の形で呼べるので、モデルを差し替えて比べやすくなります。「モデルはどう選ぶのか」の選び方の軸を読み直してください。
ナレッジベース・エージェント・ガードレールは何をするのか
ナレッジベース（RAG）
モデルは、学習したデータにない社内の情報を知りません。知らないことを聞かれると、もっともらしいが事実と違う答え（ハルシネーション）を返すことがあります。
RAG（検索拡張生成）は、質問に関係する文書を検索し、その内容を文脈としてプロンプトに足してから答えさせる方法です。モデルを再学習させずに、最新の情報や社内独自の情報を根拠にできます。ナレッジベースは、この流れ（取り込み・分割・埋め込み・検索・プロンプトへの追加）を Bedrock が受け持つ機能です。資料によっては Knowledge Bases for Amazon Bedrock と書かれます。
RETRIEVAL AUGMENTEDRAG の通り道
モデルを再学習せずに、社内文書を根拠に答えさせる
-
質問
利用者が聞く
-
埋め込み
意味をベクトルに
-
ベクトル検索
近い文書の断片を探す
-
プロンプトに追加
断片を文脈として足す
-
モデルが答える
根拠の文書も返す
文書は小さな断片に分けられ、意味を数値のベクトルで表した埋め込みに変えて、ベクトルストアに保存されます。質問も埋め込みに変え、意味の近い断片を探してプロンプトに足します。ベクトルストアは Bedrock に任せる形と、Amazon OpenSearch Serverless などを自分で用意する形があります。
モデルを業務に合わせる手段は、手軽な順にプロンプトの工夫 → RAG → ファインチューニングです。知識を足したいなら RAG、文体や振る舞いそのものを変えたいならファインチューニング（Bedrock では、ファインチューニング・継続事前学習・蒸留といったカスタマイズが用意されています）と分けて考えます。
エージェント
エージェントは、依頼を複数の手順に分けて計画し、社内の API を呼び、結果を見て次の手順を決める仕組みです。Bedrock のエージェントでは、呼べる API を OpenAPI のスキーマで定義し、実際の処理を Lambda 関数に書く「アクショングループ」と、ナレッジベースを組み合わせます。Lambda 関数には、エージェントからの呼び出しを許可するリソースベースのポリシーが必要です。
エージェントを本番で動かす基盤として、Amazon Bedrock AgentCore もあります。フレームワークやモデルを問わずエージェントを動かすためのサービスで、実行環境（Runtime）、会話の記憶（Memory）、既存の API や Lambda 関数をツールとして渡す（Gateway）、エージェントの ID と権限（Identity）、動きの観測（Observability）などの部品に分かれています。
READ ALSO — 学習中向け・段2 構成
AWS Lambda とは何か｜イベントで動く関数と、実行時間などの制約を EC2・コンテナと比べて理解する
ガードレール
ガードレール（Amazon Bedrock Guardrails。資料によっては Guardrails for Amazon Bedrock）は、入力と出力を点検する仕組みです。モデルとは別に設定するので、モデルを替えても同じ方針を当てられます。
- コンテンツフィルター: 憎悪・侮辱・性的な内容・暴力・不正行為・プロンプト攻撃の分類ごとに、強さを決めて止める
- 拒否するトピック: 業務で扱わない話題（例: 投資の助言）を定義して避ける
- 機密情報フィルター: 個人情報などを検知して、止めるか伏せる
- 文脈に基づくチェック: RAG の答えが、検索した文書に基づいていない・質問と関係ないときに検知する
ApplyGuardrail API を使うと、モデルを呼ばずにガードレールだけを当てることもできます。
プロンプトインジェクション（入力に紛れ込ませた指示でモデルに制約を破らせる攻撃）には、ガードレールのプロンプト攻撃のフィルターと、入力の検証を組み合わせて備えます。ガードレールは確率的な判定なので、すり抜けがゼロになる前提で設計しないことが大切です。エージェントに渡す権限は、IAM で必要な操作だけに絞っておきます。
CHECK 2ここまでの確認
社内の規程集を根拠に答えさせたいが、モデルの振る舞いそのものは変えたくない。まず検討するのはどれですか?
答えと解説
答え: 1. ナレッジベースで検索した内容を文脈に足す（RAG）
知識を足したいだけなら、モデルを再学習しない RAG が先です。ファインチューニングは文体や振る舞いを変えたいときの手段です。「ナレッジベース・エージェント・ガードレールは何をするのか」を読み直してください。
入力したデータはどう扱われるのか
生成 AI を業務に入れる前に、セキュリティの担当者からまず聞かれるのがこの点です。公式ドキュメントの記載をそのまま押さえます。
- Bedrock は、プロンプトと応答を保存・記録しない（既定の動作）
- プロンプトと応答を、どのモデルの学習にも使わず、第三者に渡さない
- モデルの提供元は Bedrock のログや利用者のプロンプトと応答にアクセスできない
- データは転送時と保管時に暗号化される
例外と、自分で決める設定もあります。
- 一部のモデルでは、不正利用の検知のために、分類器に検知されたやり取りが一定期間保持されることがあると書かれています。対象と期間は公式の Data retention のページで確認します
- モデル呼び出しのログは既定で無効です。有効にすると、入力と出力が自分のアカウントの CloudWatch Logs か S3 に残ります。残した先の暗号化と閲覧の権限は利用者の責任です
- VPC の中から呼ぶときは、インターフェイス VPC エンドポイント（PrivateLink）でインターネットを経由せずに届けられます
Bedrock の導入でやってはいけない3つ
- 「学習に使われない」という記載だけで、呼び出しログの保存先と権限を決めずに有効にする
- 検索元の文書に閲覧の制限があるのに、誰が聞いても全文書から答えるナレッジベースを作る
- エージェントに、業務で使わない API まで呼べる広い権限を渡す
ナレッジベースで一番起きやすい事故は、モデルではなく検索元のデータの権限です。人事の資料が入っていれば、それを見てはいけない人の質問にも答えの材料として使われます。何を取り込むかと、誰にどの文書から答えるかは、モデルを選ぶ前に決めておきます。
CHECK 3ここまでの確認
入力と出力の扱いについて、Bedrock の公式ドキュメントの記載に合うものはどれですか?
答えと解説
答え: 2. 入力と出力は基盤モデルの学習に使われず、モデル提供元とも共有されない
公式ドキュメントは、プロンプトと応答を学習に使わず、第三者に渡さないと説明しています。呼び出しログの記録は既定で無効で、有効にすると自分のアカウントの CloudWatch Logs か S3 に残ります。「入力したデータはどう扱われるのか」を読み直してください。
SageMaker とはどう違うのか
AWS で機械学習を扱うサービスには、もう1つ Amazon SageMaker AI があります。どちらも AI のアプリケーションを作れますが、借りる範囲が違います。
BEDROCK OR SAGEMAKER借りる範囲の違い
モデルの使い方で差をつけるなら Bedrock、モデルそのものなら SageMaker AI
Amazon Bedrock
学習済みの基盤モデルを借りる
- API で呼ぶ。基盤は AWS が持つ
- プロンプト・RAG・エージェントで作る
- 機械学習の専門家が少なくても始めやすい
Amazon SageMaker AI
モデルを作る基盤を借りる
- 学習・カスタマイズ・デプロイを制御する
- 推論の基盤の選択と調整まで持つ
- 従来型の機械学習も扱う
| 観点 | Amazon Bedrock | Amazon SageMaker AI |
|---|---|---|
| 何を借りるか | 学習済みの基盤モデルと、それを使う部品 | モデルを作り、学習させ、デプロイする基盤 |
| 主な作り方 | プロンプトの工夫、RAG、エージェント | 学習ジョブ、カスタマイズ、推論エンドポイント |
| 自分で持つ範囲 | アプリケーション、データ、権限、ガードレールの方針 | それに加えて、学習の設定、推論の基盤の選択と調整 |
| 向いている場面 | 機械学習の専門家が少なくても、生成 AI の機能を早く組み込みたい | 費用・応答時間・処理量の兼ね合いを、コンテナや基盤の層まで触って調整したい |
| 扱うモデル | 基盤モデル（生成 AI） | 生成 AI に加えて、予測や分類などの従来型の機械学習 |
公式の判断ガイドは、どちらか一方を選ぶより、段階的に進む使い方を示しています。まず Bedrock でプロンプトと RAG を試し、モデルの振る舞いを変える必要が出たら SageMaker AI でのカスタマイズへ、基盤まで制御したくなったら学習ジョブや HyperPod へ、という順です。
実務で迷ったら、「この機能の差別化は、モデルそのものにあるのか、モデルの使い方にあるのか」を問います。使い方（どの文書を根拠にするか、どの API を呼ぶか、何を止めるか）にあるなら、Bedrock で始めて基盤の運用を持たない方が、チームの時間を差別化に使えます。どちらを選んだかは、得るものと諦めるものをトレードオフとして説明できるようにしておきます。
READ ALSO — プロフェッショナル向け・段4 設計
トレードオフの考え方｜「なぜそのサービスか」を根拠つきで説明する型と、Well-Architected の6本柱の使い方
CHECK 4ここまでの確認
自社でモデルの学習から推論の基盤まで細かく制御したいとき、Bedrock より向いているのはどれですか?
答えと解説
答え: 1. Amazon SageMaker AI
学習・カスタマイズ・デプロイを細かく制御し、コンテナやオーケストレーションの層まで触りたいなら SageMaker AI が向きます。「SageMaker とはどう違うのか」を読み直してください。
まとめ
- Amazon Bedrock は、複数の会社の基盤モデルを API で呼べるフルマネージドのサービス。推論の基盤は AWS が持つ
- モデルは入出力の種類・品質・速さと費用・扱える長さ・提供状況で選び、自分のデータを使ったモデル評価で比べる。Converse API で差し替えやすくしておく
- ナレッジベースは RAG、エージェントは手順の計画と API の呼び出し、ガードレールは入力と出力の点検を受け持つ。本番のエージェントの基盤には AgentCore がある
- プロンプトと応答は基盤モデルの学習に使われず、提供元にも渡らない。呼び出しログを残すなら、保存先と権限は自分の責任
- 学習済みのモデルの使い方で差をつけるなら Bedrock、モデルそのものと基盤を制御するなら SageMaker AI
参照ソース
- Overview - Amazon Bedrock（AWS ドキュメント） — Bedrock がフルマネージドで複数社の基盤モデルを提供し、サーバーレスであることの根拠（2026年9月時点）
- Supported foundation models in Amazon Bedrock（AWS ドキュメント） — モデルの一覧と対応リージョンを公式で確かめる先（2026年9月時点。一覧は随時更新される）
- Inference using Converse API（AWS ドキュメント） — Converse API がメッセージ形式のモデルを共通の形で呼べることの根拠（2026年9月時点）
- Cross-Region inference（AWS ドキュメント） — 推論プロファイルで地域内のリージョンに振り分ける仕組みの根拠（2026年9月時点）
- Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases（AWS ドキュメント） — ナレッジベースが RAG の取り込みから検索・プロンプトへの追加までを受け持つことの根拠（2026年9月時点）
- How Amazon Bedrock Agents works（AWS ドキュメント） — アクショングループ（OpenAPI スキーマと Lambda 関数）とナレッジベースを使った手順の組み立ての根拠（2026年9月時点）
- Overview - Amazon Bedrock AgentCore（AWS ドキュメント） — AgentCore の存在と、Runtime・Memory・Gateway・Identity・Observability の部品の根拠（2026年9月時点）
- Detect and filter harmful content by using Amazon Bedrock Guardrails（AWS ドキュメント） — コンテンツフィルター・拒否するトピック・機密情報フィルター・文脈に基づくチェック・ApplyGuardrail API の根拠（2026年9月時点）
- Customize your model（AWS ドキュメント） — ファインチューニング・継続事前学習・蒸留のカスタマイズの種類の根拠（2026年9月時点）
- Data protection - Amazon Bedrock（AWS ドキュメント） — プロンプトと応答を保存せず学習に使わず第三者に渡さないこと、暗号化の根拠（2026年9月時点）
- Data retention - Amazon Bedrock（AWS ドキュメント） — 不正利用の検知のための保持という例外の根拠（2026年9月時点。対象と期間はこのページで確認）
- Monitor model invocation using CloudWatch Logs and Amazon S3（AWS ドキュメント） — 呼び出しログが既定で無効で、有効にすると CloudWatch Logs か S3 に残ることの根拠（2026年9月時点）
- Amazon Bedrock or Amazon SageMaker AI?（AWS Decision Guides） — Bedrock と SageMaker AI の選び分けと、段階的に進む使い方の根拠（2026年9月時点）
