Amazon Bedrock完全ガイド：Vertex AI・Microsoft Foundry比較でわかる「生成AI基盤」の選び方と実務設計
先に結論
Amazon Bedrockは、Amazonおよびサードパーティーの基盤モデルを使いやすくするフルマネージドの生成AI基盤です。単なるモデル推論APIではなく、推論、評価、バッチ推論、プロビジョンドスループット、モデルのファインチューニング、Knowledge Bases、Agents、Flows、Guardrailsまでを一つの製品群として持っているのが大きな特徴です。
比較対象として、Google Cloudでは Vertex AI が近く、生成AIモデルのテスト・チューニング・デプロイを行える統合基盤として提供されています。さらに Model Garden でGoogle製および一部OSS/パートナーモデルを探し、Vertex AI RAG Engine や grounding 機能でRAGを組み込みやすい構成です。
Azureでは、2026年時点の公式ドキュメント上、Microsoft Foundry がエンタープライズAIの統合PaaSとして案内されており、Foundry Models と Foundry Agent Service を中核に、モデル利用、ファインチューニング、エージェント構築、ガバナンスをまとめやすい形です。
つまり、ざっくり整理すると、
- AWS中心で生成AI基盤を作りたいなら Amazon Bedrock
- Googleの生成AIモデルやRAG設計に寄せたいなら Vertex AI
- Azureのモデル管理・エージェント・ガバナンスまで一体で進めたいなら Microsoft Foundry
という見方が実務ではかなり使いやすいです。
この記事が役に立つ方
この内容は、社内チャット、FAQ、検索、要約、レポート生成、エージェント化などを検討しているプロダクト開発チームに向いています。たとえば、「LLMを試したいが、モデル選定・RAG・安全対策・コストの全体像が散らばっていて見えにくい」と感じているバックエンドエンジニアやテックリードの方には、とても相性が良いテーマです。Bedrockは、推論だけでなく、Knowledge Bases や Guardrails、Agents といった周辺機能まで一つの世界観でまとめているため、PoCから本番への移行イメージを作りやすいからです。
また、SREやプラットフォーム担当として、「生成AIワークロードを誰がどう運用するのか」「安全対策とコスト統制をどこに置くのか」を決めたい方にも役立ちます。Bedrockのドキュメントには、IAMベースの制御、Guardrails、評価、プロビジョンドスループット、クロスリージョン推論など、運用・統制に関わる機能が明示されています。Vertex AIも、生成AI・Model Garden・RAG Engine・grounding を統合的に扱えますし、Microsoft Foundryも統合PaaSとエージェントサービス、モデル課金、コントロールプレーンを前面に出しています。どのクラウドも「モデルを呼べる」だけではなく、運用できる状態にするための部品を増やしてきています。
さらに、クラウド横断で基盤を選びたいアーキテクトの方にも有益です。Bedrock、Vertex AI、Microsoft Foundry は一見似ていますが、何を「中心の価値」にしているかが少しずつ違います。Bedrockは複数モデルへの統一アクセスと、RAG・ガードレール・エージェントをAWS側でまとめやすいのが強みです。Vertex AIはGoogle製モデルとモデルカタログ、RAG Engine、grounding の組み合わせが整理されています。Microsoft Foundryは統合PaaS、Foundry Models、Foundry Agent Service、Foundry Control Plane といった形で、組織統制とエージェント運用まで含めた“全体管理”が見えやすいです。
1. Amazon Bedrockとは何か
Amazon Bedrockは、Amazonとサードパーティープロバイダーの基盤モデルを使いやすくするフルマネージドサービスです。公式ドキュメントでは、Bedrock が「third-party providers and Amazon」の基盤モデルを簡単に利用できると明記されており、さらに推論、クロスリージョン推論、バッチ推論、プロビジョンドスループット、評価、ファインチューニング、継続事前学習、モデルインポート、プロンプトルーティングまで、かなり広い機能群が一つの製品体系に入っています。
ここで大切なのは、Bedrockを「ClaudeやLlamaを呼ぶための窓口」だけで終わらせないことです。Bedrockの本当の価値は、モデル呼び出しを中心に、RAG、エージェント、ガードレール、モデル評価、カスタマイズまでを同じAWS文脈で扱えることにあります。たとえば、推論だけ別API、RAGは別基盤、ガードレールは自作、エージェントは別製品、という分散構成にしなくても、PoCから本番までをかなり一つの流れで組み立てやすいのです。
実務での理解としては、Bedrockは「モデルのマーケットプレイス」ではなく、生成AIアプリケーションの基盤です。モデルを選ぶだけでなく、どのモデルに何をさせ、どのデータで補強し、どんな安全策を入れ、どのくらいのコストで回すか、という一連の設計を支えるためのサービス群として見ると、かなり整理しやすくなります。AWSの製品ページでも、Knowledge Bases、Data Automation、prompt engineering、fine-tuning などを組み合わせて、自社データで安全に最適化すると説明されています。
2. Bedrockの中核機能：推論、Knowledge Bases、Agents、Guardrails
2-1. 推論とモデル選択
Bedrockでは、複数ベンダーのモデルを同じサービス文脈で扱えるのが大きな強みです。料金ページには Amazon、Anthropic、Cohere、DeepSeek、Meta、Mistral、Google など多様なプロバイダー名が並び、モデルごとにオンデマンド、バッチ、プロビジョンドスループットなどの価格体系が示されています。これは、モデルを変えてもアプリ側の運用文脈を完全に作り直さなくて済む可能性がある、ということです。
ここが実務で効くのは、モデル選定が固定で終わらないからです。たとえば、最初は品質重視で高性能モデルを使い、運用が落ち着いたら一部の問い合わせを低コストモデルへ寄せたいことがあります。Bedrockには prompt routing や複数ティアの価格体系があり、単一モデル前提で設計を固めすぎない余地があります。料金ページでは Intelligent Prompt Routing が、同じモデルファミリー内で品質とコストのバランスを取りながら振り分けできると説明されています。
2-2. Knowledge Bases
Bedrock Knowledge Bases は、RAG を使って自社データで回答を補強するための機能です。公式ドキュメントでは、Knowledge Bases がデータソースから関連情報を検索し、それを回答生成に使えること、引用情報を返せること、マルチモーダルな文書や画像も扱えること、構造化データ向けに自然言語からSQLクエリを生成する使い方まで含まれることが説明されています。
これは実務では非常に大きいです。LLM単体では社内の最新情報や固有ルールを持っていないため、FAQ、製品マニュアル、社内規程、営業資料、チケット履歴などを使うにはRAGがほぼ必須になります。Knowledge Bases は、そのRAGをAWS側でまとめやすくしてくれるため、「まずは安全に社内文書検索付きチャットを作りたい」という段階と非常に相性が良いです。
2-3. Agents
Bedrock Agents は、ユーザー入力に基づいて、基盤モデル・データソース・ソフトウェアアプリケーション・会話をまたぎながらタスクを進める仕組みです。公式では、Agents が API を自動的に呼び、Knowledge Bases を使って補足しながら、エンドユーザーのタスク達成を助けると説明されています。さらに、OpenAPI スキーマや Lambda を使ってアクションを定義できることも示されています。
この機能が効くのは、「答えるだけ」で終わらない業務です。たとえば、在庫確認だけでなく発注APIを呼ぶ、問い合わせ要約だけでなくチケットを起票する、契約情報を検索するだけでなく社内承認フローにつなぐ、といった一連の行動を扱いたいとき、Agents の考え方が使いやすくなります。単なるチャットボットではなく、業務アクションへ進めるエージェントに寄せやすいのがポイントです。
2-4. Guardrails
Bedrock Guardrails は、安全対策とプライバシー対策のための設定可能なガード機能です。公式ドキュメントでは、ユーザー入力とモデル応答の両方を評価し、望ましくない内容や有害内容を検知・フィルタし、機微情報を保護できると説明されています。ユースケースとして、チャットボットの有害発話対策、金融領域での不適切アドバイス抑制、コールセンター要約のPIIマスキングなども例示されています。
生成AIを本番運用するなら、Guardrails はほぼ必須です。理由は簡単で、モデルの品質だけでは本番運用の安全性を担保できないからです。禁止トピック、PII、応答方針、業務上の境界を、アプリ側のロジックだけで全部管理するのは大変です。Bedrock Guardrails は、こうした「安全策の部品」をアプリ共通の機能として持てるため、組織的な統制に向いています。
3. モデルのカスタマイズ：ファインチューニングはいつ必要か
Bedrockでは、ファインチューニングを使って特定タスク向けにモデル性能を高められます。公式ドキュメントでは、Bedrock 上で foundation model を fine-tuning できること、学習データは少なくとも training dataset を .jsonl 形式で準備する必要があることが説明されています。また、強化学習による fine-tuning（reinforcement fine-tuning）も別手法として案内されています。
ただし、実務ではいきなりファインチューニングへ行かないほうが安全です。先にやるべきなのは、多くの場合、
- プロンプト設計
- RAG
- ガードレール
- 出力フォーマット制御
の整備です。ファインチューニングは強力ですが、データ準備、評価、継続運用、費用が増えます。Bedrockの価格ページでも、モデルプロバイダーによって fine-tuning や provisioned throughput の価格体系が分かれており、単純な推論より管理ポイントが増えることがわかります。
Vertex AI 側でも Gemini の supervised tuning や tuning API が提供され、Microsoft Foundry 側でも LoRA ベースの fine-tuning が公式に説明されています。つまり、どのクラウドでもファインチューニングは可能ですが、基本の考え方は同じです。チューニングは最後の武器であり、最初の武器ではない、ということです。
サンプル：ファインチューニングを急がない判断例
たとえば社内問い合わせチャットを作る場合、最初から学習データを何百件も整えてチューニングするより、
- Knowledge Bases で社内文書を検索可能にする
- Guardrails で禁止応答やPII漏えいを抑える
- 出力フォーマットを固定する
- そのうえで足りない精度だけを検証する
という順序のほうが、多くのチームでは現実的です。Bedrock はまさにこの順番を取りやすい構成になっています。
4. Vertex AIとの比較
Vertex AI は、Google Cloud の統合AI/MLプラットフォームです。公式ドキュメントでは、生成AIモデルを test、tune、deploy できること、Model Garden で Google 製および一部OSS・パートナーモデルを探してカスタマイズ・デプロイできることが説明されています。さらに、Vertex AI RAG Engine は、組織内データを取り込んで LLM の文脈を補い、回答精度や信頼性を高めるためのデータフレームワークとして案内されています。
ここでの違いは、Bedrock は“複数モデルをAWS文脈で利用しやすくする基盤”で、Vertex AI は“Google のAI/ML統合プラットフォームの中で生成AIも扱う基盤” という点です。Bedrock は、Knowledge Bases、Agents、Guardrails が生成AIアプリ基盤の部品としてまとまっている一方、Vertex AI は Model Garden、RAG Engine、grounding with Vertex AI Search、grounding with Google Search など、少し広い製品群の組み合わせで体験を作る印象があります。
料金の考え方も少し違います。Bedrock はプロバイダー・モデル・モダリティ別に価格が分かれ、Standard / Flex / Priority / Reserved といったティアや、バッチ推論・プロビジョンドスループットの考え方があります。Vertex AI 側は、Standard PayGo として消費ベース課金があり、Generative AI の価格は文字数・トークン・モデル別に管理され、パートナーモデル価格も Agent Platform の価格ページに整理されています。
実務的に言うと、
- AWS を主戦場にして、RAG・安全対策・エージェントを比較的素直にまとめたい → Bedrock
- Google の生成AI・検索・RAG・モデルカタログとの一体感を重視したい → Vertex AI
という選び方がしっくりきます。特に、Google Search や Vertex AI Search を grounding に使いたい場合は、Vertex AI 側の魅力が強くなります。
5. Microsoft Foundryとの比較
Microsoft Foundry は、2026年時点の Microsoft Learn で「enterprise AI operations, model builders, and application development」のための統合PaaSとして説明されています。さらに、Foundry Agent Service は、任意のフレームワークと Foundry model catalog の多様なモデルを使って、AIエージェントを構築・デプロイ・スケールするフルマネージド基盤とされています。
Bedrock と比べたときの Microsoft Foundry の特徴は、統合プラットフォームとしての見せ方が強いことです。Foundry の価格ページでは、Foundry IQ、Foundry Tools、Foundry Control Plane、Foundry Local などの項目が並び、プラットフォーム自体は無料で探索できる一方、各サービスや製品は個別課金であることが明記されています。Foundry Models の価格ページでは、OpenAI、DeepSeek、Llama、Mistral など多様なモデルが serverless deployment と provisioned throughput の両方で提供されることが示されています。
ここは Bedrock とかなり似ています。Bedrock も複数モデル、オンデマンド/バッチ/プロビジョンド、ガードレール、エージェント、RAG を持っています。ただし、Foundry はエージェントと統制の世界観がより前面に出ていて、Foundry Control Plane のような“組織全体の管理”が見えやすい印象です。一方 Bedrock は、AWS サービス群と自然につながることで、結果的に統制を組みやすい設計です。
ファインチューニングでも違いがあります。Foundry は公式に LoRA ベースの fine-tuning を説明し、短いプロンプト化、低レイテンシ化、トークン節約を利点として挙げています。Bedrock 側は fine-tuning や reinforcement fine-tuning をサポートしますが、製品全体としてはまず RAG、Agents、Guardrails を組み合わせる流れが見えやすいです。つまり、
- Azure 側は「統合プラットフォーム＋エージェント＋多モデル＋組織統制」
- AWS 側は「多モデル＋RAG＋ガードレール＋エージェントをAWSサービス文脈で運用」
という違いで考えると、かなり実務的です。
6. 料金設計：どこで費用が膨らみやすいか
Bedrock の料金は、単純な「1サービス1単価」ではありません。料金ページを見ると、モデルごとの推論料金に加えて、Knowledge Bases、Guardrails、Model Evaluation、Data Automation、Prompt Optimization、Intelligent Prompt Routing など、機能ごとに課金要素が分かれています。また、モデルプロバイダーごとにオンデマンド、バッチ、プロビジョンドスループット、キャッシュ書き込み/読み出しなどの価格体系が異なります。さらに、バッチ推論は一部モデルでオンデマンドより 50% 低価格だと説明されています。
ここで実務的に注意すべきなのは、費用が膨らみやすい場所が3つあることです。
- 高性能モデルの常時利用
- RAG の検索・埋め込み・再ランキングの積み上がり
- エージェントのツール実行や複数ステップ化
モデル単価だけ見ていると、Knowledge Bases や reranking、Guardrails、評価の費用が見落とされがちです。逆に、PoC では小さく見えても、本番では会話履歴、複数ターン、引用、検索、ツール呼び出しで総コストが増えます。だからこそ、Bedrock は「どの機能を使うか」を設計しないと、予算感がぶれやすいです。
サンプル：費用を抑えやすい設計
たとえば、社内FAQチャットを最初に出す場合は、
- 高難度質問だけ高性能モデル
- 定型的な問い合わせは軽量モデル
- まずは Knowledge Bases だけで始め、Agents は後から
- バッチでよい評価はバッチ推論へ寄せる
という設計にすると、PoCから本番まで費用の増え方をかなり穏やかにできます。Bedrock の Intelligent Prompt Routing やバッチ推論の考え方は、まさにこのような「品質とコストの折り合い」をつけるための機能です。
Vertex AI でも Standard PayGo の消費型課金があり、Azure Foundry Models でも Pay-As-You-Go と Provisioned Throughput の両方が示されています。つまり、どのクラウドでも “試す段階” と “本番で安定運用する段階” では、同じモデルでも料金戦略を分けて考えるのが基本です。
7. どんなチームに Amazon Bedrock が向くか
Amazon Bedrock が特に向くのは、AWS の既存資産を活かしながら生成AI機能を増やしたいチームです。既に AWS 上で、認証、権限、データストア、監査、ネットワーク境界、アプリ実行基盤が整っているなら、その中に生成AIを差し込むほうが運用は楽です。Bedrock は IAM ベースの制御や AWS サービスとの組み合わせ前提で設計されているため、この利点が大きいです。
また、RAG と安全対策を最初から一緒に進めたいチームにも向いています。生成AI導入で一番多い失敗は、「とりあえず会話できるもの」を出してから、後追いでデータ補強と安全策を考えることです。Bedrock は Knowledge Bases と Guardrails が初期から揃っているので、最初の設計段階で「何を見せるか」「何を見せないか」を考えやすいです。
さらに、業務アクションまで見据えたエージェント設計にも向いています。FAQ の先で、社内申請、問い合わせ振り分け、顧客対応、在庫確認、見積作成などに進みたいなら、Agents の設計思想が活きます。単なる文書検索チャットで止めず、業務ソフトウェアと API を呼ぶ前提にしやすいのは Bedrock の強みです。
8. 導入で失敗しにくい進め方
いきなり「全社AIポータル」「万能エージェント」を作ろうとすると、ほぼ確実に疲れます。おすすめは、用途を一つに絞ることです。たとえば、次のような進め方はとても現実的です。
サンプルA：社内FAQのRAGチャット
- Bedrock の基盤モデルを一つ選ぶ
- Knowledge Bases で社内マニュアルや規程を検索可能にする
- Guardrails でPIIや禁止トピックを制御する
- まずは「正しい情報源を引けるか」を重視する
この段階では、Agents も fine-tuning も急がないほうが成功しやすいです。
サンプルB：問い合わせ一次対応エージェント
- FAQ チャットの次段階として、API を呼ぶ Agents を追加
- 問い合わせ分類、ナレッジ参照、チケット作成を自動化
- 人手確認が必要な条件だけを残す
この構成は、Bedrock Agents の価値が見えやすいです。
サンプルC：モデル選定の比較実験
- 同じプロンプト・同じRAGデータで複数モデルを比較
- 品質、遅延、トークン消費、費用を並べる
- 本番は Prompt Routing やモデル分岐で最適化
Bedrock が複数プロバイダーを同じ基盤で扱いやすい利点が、ここで効いてきます。
まとめ
Amazon Bedrock は、Amazon とサードパーティーの基盤モデルを扱えるだけでなく、Knowledge Bases、Agents、Guardrails、モデルカスタマイズ、評価、バッチ推論、プロビジョンドスループットまでをまとめて持つ、かなり総合的な生成AI基盤です。単なる「モデルAPI」ではなく、生成AIアプリを本番運用へ乗せるための部品群として見ると、本質がつかみやすいです。
Vertex AI は、Google 製モデル、Model Garden、RAG Engine、grounding といった構成で、生成AIと検索・RAGの統合を進めやすい基盤です。Microsoft Foundry は、Foundry Models、Agent Service、Control Plane を含む統合PaaSとして、モデル運用・エージェント・ガバナンスを全体で扱いやすい構成です。
ですので、かなり実務的に言い切るなら、
- AWS で生成AI基盤を安全に育てたい → Amazon Bedrock
- Google のモデル・RAG・検索文脈を強く活かしたい → Vertex AI
- モデル・エージェント・組織統制を Azure で統合したい → Microsoft Foundry
という選び方がしっくりきます。
最初の一歩としては、Amazon Bedrock で 「一つの用途」「一つのデータソース」「一つの安全策」 に絞って小さく始めるのがおすすめです。RAG付きFAQでも、問い合わせ一次対応でも構いません。モデルを増やすのも、エージェント化するのも、そのあとで十分です。そう進めると、生成AI基盤は“派手な実験”ではなく、“運用できる仕組み”として育っていきます。
参考情報
- Amazon Bedrock の概要と機能一覧。推論、バッチ、プロビジョンドスループット、Knowledge Bases、Agents、Flows、Guardrails、カスタムモデルなどの全体像。
- Amazon Bedrock Knowledge Bases。RAG、引用付き回答、マルチモーダル検索、構造化データ活用の考え方。
- Amazon Bedrock Agents。API 呼び出しや Knowledge Bases を組み合わせたエージェント設計。
- Amazon Bedrock Guardrails。有害内容・機微情報・禁止トピックへの安全対策。
- Vertex AI と Model Garden、RAG Engine。Google Cloud 側の生成AI・RAG の全体像。
- Microsoft Foundry、Foundry Agent Service、Foundry Models。Azure 側の統合AIプラットフォームと課金の考え方。