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

他社サービスとの設計差を読み解く ── OpenAI / Azure OpenAI / Vertex AI / Anthropic 直叩き

2026/06/04

他社サービスとの設計差を読み解く ── OpenAI / Azure OpenAI / Vertex AI / Anthropic 直叩き

対象読者：OpenAI API・Azure OpenAI を触ったことがあり、Bedrock との設計差を整理したい読者難易度：★★☆☆☆（概念整理）想定読了時間：約 25 分関連章：第 2 章（Bedrock の位置付け）/ 第 16 章（事例：移行動機）

Bedrock を選ぶ前に、選ばない場合の選択肢を理解する

第 2 章で、Bedrock が AWS の Generative AI Stack の中で「FMaaS のプラットフォーム層」を担うという位置付けを整理した。だがここで一度、視点を AWS の外に出してみたい。

理由は単純で、「Bedrock がなぜ良いか」は、Bedrock 単体を眺めていても見えてこないからだ。Bedrock の設計選択がどういう意味を持つかは、「もし Bedrock を選ばなかったら何を使うのか」を並べて比較したときに初めて浮かび上がる。

実務でも同じ問いに、必ずどこかで出会う。

「うちのプロダクト、OpenAI 直叩きで動いているんですけど、本番に出すにあたって Bedrock に乗せ換える価値ありますか？」

「Azure を主に使っているチームなのですが、Anthropic Claude を使いたい場合は Bedrock に行くしかないんですか？」

「Vertex AI と比べて Bedrock を選ぶ強い理由は何ですか？」

こうした問いに、雰囲気でなく 設計上の根拠 で答えられるようになるのが、この章のゴールだ。

具体的には、Bedrock と並べて検討対象になる 4 つの選択肢 ── OpenAI API 直叩き / Azure OpenAI（現 Azure AI Foundry） / Google Vertex AI / Anthropic API 直叩き ── を順に眺め、最後に 7 軸の比較表で全体を俯瞰する。読み終えると、自分の現場で「PoC は OpenAI、本番は Bedrock」のような棲み分けを選ぶか、最初から Bedrock に寄せるかを、判断軸を持って決められるようになる。

そして章末で、第 1 章プロローグで伏線として置いた「データ取り扱いポリシー」がここに収束する形で、Bedrock を選ぶ強い動機を 3 つに整理する。

OpenAI API 直叩き ── 最速の機能アクセスと最安級の単価

最初に並べるのは、もっとも素朴な選択肢 ── OpenAI のフロンティアモデル（GPT 系・o 系）を、OpenAI 公式の API キーで直接叩く構成だ。世の中で動いている AI 機能の少なくないパーセンテージが、いまもこの構成で動いている。

強み

OpenAI 直叩きの強みは、新機能アクセスの速さと シンプルな課金体系 に集約される。

GPT 系・o 系の最新世代モデルは、まず本家 OpenAI の API に出る。Bedrock や Azure に同等モデルが載るのは、必ず数週間〜数か月遅れる（OpenAI と AWS の戦略的パートナーシップで状況は変わりつつあるが、それでも「本家最速」の構図は変わっていない）。新機能の Day 1 アクセスが欲しい R&D 用途では、これは大きい。

課金もシンプルだ。API キーを発行し、トークン単価で従量課金。組織アカウントを 1 つ作れば、その日のうちに開発が始められる。フロンティアモデルの単価自体も最安級で、純粋に「1 トークンあたりいくらか」だけで見れば、OpenAI 直叩きが多くのケースで最安になる。

PoC や個人開発、社外向けデモを最速で作りたい局面では、これ以上手軽な選択肢はない。

弱み

しかし、本番システムに必要なエンタープライズ要件は、ほぼ別レイヤーになる。

データ主権の観点では、リクエストとレスポンスは OpenAI のインフラを通る。DPA（Data Processing Addendum）はあるが、データが置かれる場所は OpenAI 圏内 ── つまり AWS のコンプライアンス境界の外側だ。

IAM 連携はない。AWS の IAM ロールでアクセスを絞り込む発想は持ち込めず、API キーの管理を AWS Secrets Manager 等で別途行う必要がある。VPC エンドポイントも当然ない。プロダクションネットワークから OpenAI へのアウトバウンドは、原則インターネットを経由する。

エンタープライズ機能（SAML SSO、監査ログ、組織管理）は、ChatGPT Enterprise / OpenAI Platform のような上位プランの別レイヤーで提供される。Bedrock のように「素の API がそのままエンタープライズグレード」とは設計思想が異なる。

向いている用途

これらを踏まえると、OpenAI 直叩きが最も光るのは次の場面だ。

PoC や R&D 用途で、最速で動かして検証したい
個人開発・少人数チームで、IAM や VPC を整える前段階
外部公開しない検証アプリで、データ主権の制約がない

「PoC は OpenAI、本番は Bedrock（または Azure OpenAI）」というパターンが現場でよく見られるのは、まさにこの強みと弱みのトレードオフが、PoC と本番でちょうど逆転するからだ。

Azure OpenAI / Azure AI Foundry ── OpenAI モデルを Azure 境界内で

次に、OpenAI モデルを「Microsoft のコンプライアンス境界内で使いたい」場合の標準解、Azure OpenAI Service（2025 年に Azure AI Foundry へリブランド）を見る。

強み

最大の強みは、OpenAI の純正モデルを Azure テナント内で利用できることだ。データは Azure のリージョン内に閉じ、Entra ID（旧 Azure AD）で認証統合され、Private Endpoint で VNet 内に閉域化できる。コンプライアンス認定も豊富で、HIPAA、SOC2、FedRAMP High まで揃う。OpenAI 本家にはないエンタープライズグレードの「境界」が、ここでは引ける。

もうひとつは M365 エコシステムとの一体感 だ。Microsoft 365 Copilot や Teams、SharePoint との統合が前提で設計されており、社内文書を題材にした生成 AI を「業務システムの延長」として組み立てやすい。M365 が組織のグループウェアになっているなら、これは決定的な強みになる。

2025 年 12 月には Microsoft Agent Framework がリリースされ、エージェント領域での Microsoft 純正フレームワークも整いつつある。「Microsoft で固める」設計の総合力は高い。

弱み

弱みは、モデル選択が OpenAI 中心に偏ることだ。

GPT 系・o 系・一部の Mistral モデルは載るが、Anthropic の Claude は基本的に Azure には載らない。Claude を本番で使いたいなら、Azure を主軸にしている組織でも、Bedrock または Anthropic 直叩きを別途検討する必要が出てくる。

これは Bedrock が マルチプロバイダー前提で設計されているのと、Azure が OpenAI ファーストで設計されているという、両者の出自と戦略の違いに由来する。「将来 Claude / Llama / Mistral / Cohere を横断的に使い分ける」前提なら、Azure はやや窮屈になりやすい。

向いている用途

Azure OpenAI / AI Foundry が光るのは、次のような組織だ。

M365 を全社で使っており、社内データの中心が SharePoint / Teams にある
GPT 系のモデルだけで要件が満たせる（Claude を使う計画がない）
Entra ID をすでにアイデンティティ基盤として運用している

逆に言えば、AWS を主軸にする組織が Azure OpenAI を選ぶ強い理由は、「Anthropic Claude が Azure には載らない」という事実によって、結構な確率で消える。これが、第 2 章で予告した「Bedrock の特殊な立ち位置」のひとつだ。

Google Vertex AI ── Gemini と長コンテキスト、そして価格優位

3 つ目は、Google Cloud の Vertex AI。Gemini を中心としたモデルカタログと、GCP のデータ基盤との統合が魅力だ。

強み

Vertex AI の強みは大きく 3 つある。

第 1 に、Gemini の長コンテキスト。最大 1M トークン級のコンテキストウィンドウは、長文ドキュメントや大量のコード、長い動画を一気に流し込める。RAG の前段としても、「いったん全部詰める」という乱暴だが効く設計が成り立つ局面がある。

第 2 に、BigQuery / GCS との緊密統合。データウェアハウスのレコードに対して、SQL の延長線上で LLM を呼ぶような体験は、Google Cloud のデータ基盤を使っている組織にとっては自然な拡張になる。

第 3 に、価格優位とコンテキストキャッシュ。Gemini Flash 系の入力単価は最安級で、context caching が API レベルで標準化されている。「同じシステムプロンプトを大量に再利用する」ワークロードでは、効果が出やすい。

弱み

弱みは、マルチプロバイダー対応の限定性と コンプライアンス認定の差 だ。

Anthropic Claude は Vertex AI Model Garden 経由で限定的に提供されているが、Bedrock のように 16 プロバイダー横断という規模感ではない。OpenAI GPT 系は基本載らない。

コンプライアンス面では、FedRAMP High が未取得である点が、米国政府系・規制業種の一部で制約になる。Bedrock は GovCloud 経由で FedRAMP High に対応しており、ここは Bedrock のアドバンテージだ。

向いている用途

Vertex AI が光るのは、こういう組織だ。

GCP を主軸にしており、BigQuery にデータが乗っている
長コンテキストが本質的に必要（法務文書解析、コードベース全体への問い合わせ等）
コスト最優先で、Gemini Flash 系で要件が満たせる

Anthropic API 直叩き ── Claude をシンプルに、最速で

最後に、Anthropic API を直接叩いて Claude を使う選択肢。Bedrock 経由で Claude を使うのと、本家経由で Claude を使うのは、似ているようで設計思想が異なる。

強み

Anthropic 直叩きの強みは、OpenAI 直叩きと構造的に似ている。Claude のフロンティア機能が最速で出ること、そして Bedrock 経由よりも単価が割安なケースが多いことだ。

Prompt Caching、Computer Use、Files API、Claude Agent SDK といった Anthropic 固有のフロンティア機能は、原則として本家 API に先に載る。Bedrock へのバックポートにはタイムラグがある。最新の Claude を最速で使い倒したい R&D 用途では、本家直叩きが優位になる。

価格面でも、純粋なトークン単価で見れば、本家のほうが Bedrock 経由より割安に収まることが多い ── ただし、これは時期やリージョン・コミットメント条件で変動するので、「Bedrock より◯％安い」と数字で断言するのは避けたほうがよい。「割安なケースがある」程度の認識を持っておけば実務には十分だ。

弱み

弱みは、これも OpenAI 直叩きと相似形になる。

データは Anthropic 側に渡る。Anthropic は学習にユーザーデータを使わない契約を提供しているが、データが置かれるのは AWS のコンプライアンス境界の外側だ。GDPR 規制下や、政府機関・金融機関での利用には、ここがしばしば壁になる。

IAM 連携はなく、エンタープライズ機能は Claude Enterprise や Workspaces のような別ラインで提供される。

向いている用途

Anthropic 直叩きが光るのは、次の場面だ。

Claude のフロンティア機能を最速で使いたい（Computer Use 等）
コスト最優先で、データ主権の制約がない
個人開発・少人数チームで、設計より速度を優先

5 サービスを 2 軸でプロットする

ここまで 4 社（＋ Bedrock）を個別に見てきたが、全体感を 1 枚で押さえておきたい。データ主権の強さと マルチモデル対応度 の 2 軸で並べると、各サービスの設計差が一望できる。

quadrantChart
    title 5 サービスの設計ポジション
    x-axis "データ主権が弱い" --> "データ主権が強い"
    y-axis "単一プロバイダー寄り" --> "マルチプロバイダー寄り"
    quadrant-1 "本命：本番向け"
    quadrant-2 "PoC・R&D 向け"
    quadrant-3 "本家最速ゾーン"
    quadrant-4 "純血エンタープライズ"
    "Bedrock": [0.88, 0.92]
    "Azure OpenAI / AI Foundry": [0.82, 0.28]
    "Vertex AI": [0.72, 0.45]
    "OpenAI API 直叩き": [0.20, 0.15]
    "Anthropic API 直叩き": [0.22, 0.10]

Bedrock だけが右上に大きく振れているのが見える。「AWS のコンプライアンス境界内で、16 プロバイダーを統一 API で扱える」という設計が、ほかの 4 つとは別象限に置かれていることが、視覚的にもはっきりわかる。

Azure と Vertex は「右下」── データ主権は強いが、モデルは特定プロバイダー（OpenAI / Gemini）に寄っている。OpenAI 直叩きと Anthropic 直叩きは「左下」── 速度と価格は最強だが、データ主権とマルチモデル両方を割り切る前提だ。

7 軸の比較表

ここまでの議論を、設計判断で使う形に圧縮する。

軸	Bedrock	OpenAI API 直叩き	Azure OpenAI / AI Foundry	Vertex AI	Anthropic API 直叩き
データ主権	AWS リージョン内、プロバイダー非共有・学習非利用	OpenAI 側	Azure テナント内	GCP リージョン内	Anthropic 側
主要モデル	Claude / Nova / Llama / Mistral / Cohere / GPT / DeepSeek / Qwen ほか 16 社 100+ FM	GPT・o 系のみ	GPT・o 系 + 一部 Mistral	Gemini 中心 + 一部 Claude / Llama	Claude のみ
価格モデル	On-Demand / Batch / Provisioned / Flex / Priority	On-Demand / Batch	On-Demand / PTU	On-Demand / Committed Use / PT / Context Cache	On-Demand / Batch / Prompt Cache
エンタープライズ機能	IAM / VPC Endpoint / KMS / CloudTrail / Guardrails / AgentCore	別ラインで提供	Entra ID / Private Endpoint / Content Filter	IAM / VPC-SC / Model Garden	Workspaces / SSO
マルチリージョン	Cross-Region Inference Profile（Geo / Global）	リージョン限定	リージョン限定	リージョン分散	限定
FedRAMP High	あり（GovCloud）	なし	あり	なし	なし
エージェント / RAG	AgentCore + Bedrock Agents + Knowledge Bases	Assistants / Agents SDK / File Search	Microsoft Agent Framework / AI Search 統合	Vertex AI Agent Builder / Vertex AI Search	Claude Agent SDK（RAG は自前）

7 軸のうち、Bedrock が他社と決定的に差別化できているのは データ主権・マルチモデル幅・エンタープライズ機能（特に IAM/VPC/KMS のネイティブ統合）・FedRAMP High の 4 つだ。逆に「最新モデルへのアクセス速度」と「フロンティア機能の Day 1 サポート」では、本家直叩きに譲る。

この表は、章末ではなく 設計判断の場で繰り返し開く ことを想定して作った。

ケース別の選定指針

7 軸表を抽象的なまま終わらせずに、現場でよく出くわす 4 ケースに当てはめて指針化しておく。

ケース 1：AWS 中心 / 規制業種 / マルチモデル前提

→ Bedrock が本命。

データが AWS のコンプライアンス境界内に閉じることが必要で、かつ「将来は Claude も Llama も Mistral も状況に応じて使い分けたい」という前提なら、ほかの選択肢は半歩劣る。IAM ロールでアクセスを絞り、VPC Endpoint で閉域化し、KMS で暗号化キーを自分で握れる、という AWS ネイティブ統合の総合力が、ここでは決定的になる。

ケース 2：M365 中心 / OpenAI 純正で十分

→ Azure OpenAI / AI Foundry。

組織が Microsoft で固められており、社内文書の中心が SharePoint・Teams・OneDrive にあり、Claude を使う計画もないなら、Azure に揃えるのが摩擦が少ない。「全部 Microsoft」の一貫性は、運用負荷の面で侮れない。

ケース 3：Google Cloud 中心 / Gemini 長コンテキスト / 価格優先

→ Vertex AI。

データの中心が BigQuery にあり、長コンテキストや Gemini Flash の価格優位を活かしたいなら、Vertex AI が自然な選択になる。FedRAMP High が要件に入ってこない用途であれば、Bedrock を上回るケースもある。

ケース 4：Claude を最速・最安で使いたい / 個人〜少人数規模

→ Anthropic API 直叩き。

データ主権の制約がなく、まずスピードと価格を取りたいなら、本家を直接叩くのが筋がよい。本番化フェーズで「やはり AWS 境界内に寄せたい」となったら、そこで Bedrock に乗せ換えるパスがある。

Bedrock を選ぶ強い動機 3 つ ── 第 1 章の「データ取り扱いポリシー」を回収する

第 1 章プロローグで、Production Ready の 3 つ目の壁として「公式ドキュメントと現場の知恵の壁」を挙げた。そして暗に「データ取り扱いポリシー が選定の核心になる」と伏線を置いた。ここでその伏線を回収する。

ほかの 4 社と並べて初めて見えてくる、Bedrock を本番システムで選ぶ強い動機は、次の 3 つに集約される。

動機 1：データ主権 ── プロバイダー非共有・学習非利用

Bedrock では、プロンプトと出力はモデルプロバイダー（Anthropic, Meta, Mistral など）に共有されず、FM の学習にも使われない。AWS 公式が明文化している、おそらく Bedrock の最も強い約束だ。

ほかの選択肢で、これと完全に等価な保証を引くのは難しい。OpenAI 直叩きや Anthropic 直叩きでは、データは各社の境界内に置かれる ── 学習に使わない契約は提供されるが、データが物理的にどこに置かれるかは AWS のコンプライアンス境界の外側になる。

これは、金融・医療・政府・大手製造業など、データ取り扱いに監査の目が入る業種 にとって、決定的な差を生む。「クラウドベンダーのコンプライアンス境界内で完結する」ことが要件の組織では、Bedrock がほぼ唯一解になる。

動機 2：AWS ネイティブ統合 ── IAM / VPC / KMS

Bedrock は、AWS の他のサービスと 同じ言語で話せる。IAM ロールでアクセス制御を書き、VPC Endpoint でインターネットを通さずに呼び、KMS で暗号化キーを握り、CloudTrail で監査ログを残す ── すべて、ふだん AWS でやっているのと同じ作法で済む。

これがどれだけ大きいかは、対照的に OpenAI 直叩きを本番で運用する設計 を想像してみるとわかる。API キーの管理をどうするか、Secrets Manager に入れるとしてローテーションは、ネットワーク的に OpenAI へのアウトバウンドはどう許可するか、監査ログはどこに集めるか ── 設計するべきことが一段増える。

Bedrock を選ぶと、これらの問題が「すでに AWS でやっていること」に吸収される。設計の認知負荷が下がる。これは技術的な強みというよりも、運用上の現実的な強みだ。第 14 章「セキュリティを設計する」で、この具体的な実装パターンを詳しく見る。

動機 3：マルチモデル横断 ── 特に Anthropic Claude が独占的

Bedrock では、Anthropic Claude を含む 16 プロバイダーのモデルを、統一 API（Converse / Messages / Responses）で横断的に呼び分けられる。これは、「将来モデルを乗せ換える可能性がある」前提のシステム設計で効いてくる。

ここで特に重要なのが、Claude が Azure には載らないという事実だ。Azure を主軸とする組織でも、Claude を本番で使いたい瞬間に、Bedrock または Anthropic 直叩きへ寄り道する必要が出てくる。そして「Anthropic 直叩きはデータ主権の制約で本番に出せない」という条件が重なると、選択肢は実質的に Bedrock 一択になる。

Bedrock は「Claude を AWS の境界内で動かせる、ほぼ唯一のプラットフォーム」という、構造的に強い独占ポジションを持っている。マルチプロバイダー設計を志向するなら、ここは大きい。

「PoC は OpenAI、本番は Bedrock」というパターンの根拠

ここまでの議論を踏まえると、現場でよく見られる「PoC は OpenAI 直叩き、本番は Bedrock」というパターンが、なぜ合理的なのかが見えてくる。

PoC フェーズで重要なのは速度だ。アイデアを最速で動かして、ステークホルダーに見せて、要件をすり合わせる。OpenAI 直叩きが持つ「API キー 1 本で即日開発できる」軽さは、ここでは何より大きい。IAM や VPC を整える前段階で、「とにかく動くもの」が必要だ。

本番フェーズで重要なのは、軸が変わる。データ主権・IAM・VPC・KMS・監査ログ・コスト追跡・ガードレール・観測 ── これらをすべて、組織のコンプライアンス要件と整合させる必要がある。ここで効いてくるのが Bedrock の AWS ネイティブ統合だ。

つまり、PoC と本番では 重視する軸そのものが入れ替わる。両方に等しく強いサービスは存在しないので、フェーズに応じて使い分けるのが現実解になる。

ただし、最初から Bedrock を使う 選択肢も並行して検討に値する。理由は、PoC で書いたコードが、Bedrock の Messages API / Responses API を経由していれば、本番化の際にプロンプトロジックをほぼそのまま流用できるからだ。Bedrock の bedrock-mantle エンドポイントは、Anthropic Messages API・OpenAI Responses API・OpenAI Chat Completions API をネイティブサポートしている（第 2 章で触れた）。「PoC から Bedrock を使う」ことの心理的なコストは、見た目より小さい。

章末まとめと次章への接続

5 社の API を 7 軸で比較してみると、それぞれに尖った強みがあり、「どれが一番良い」という単純な答えはなかった。むしろ、自分の組織がどのコンプライアンス境界を引きたいか、どのモデルを使いたいか、どのフェーズにいるか によって、答えが変わる。

そして本シリーズが扱う Production Ready の文脈 ── AWS を主軸に、Claude を含む複数モデルを横断的に使い、データ主権を守り、IAM/VPC/KMS のネイティブ統合を活かす ── では、Bedrock を選ぶ動機が構造的に強くなる。これが、住信 SBI ネット銀行、みずほ銀行、Pfizer といった 規制業種のリーディングカンパニーが Bedrock を選んだ理由 とも重なる。彼らがなぜ Bedrock を採用したのか、その背後にあったコンプライアンスとアーキテクチャの判断は、第 16 章「国内・海外の事例から読み解く」で具体的に見ていく。

章末まとめ

Bedrock を理解するには、選ばない場合の選択肢（OpenAI / Azure / Vertex / Anthropic）を並べて比較する必要がある

OpenAI / Anthropic 直叩きは 速度と価格 が強み、データ主権とエンタープライズ機能は別レイヤー

Azure OpenAI / AI Foundry は M365 中心 なら強力だが、Anthropic Claude は載らない

Vertex AI は Gemini と長コンテキスト が強み、FedRAMP High が要件なら制約あり

Bedrock を選ぶ強い動機は (1) データ主権 (2) AWS ネイティブ統合 (3) マルチモデル横断（特に Claude が独占的） の 3 つ

「PoC は OpenAI、本番は Bedrock」が合理的なのは、フェーズごとに重視する軸が入れ替わるため

次章では、Bedrock 側が具体的に何を提供しているのか ── Foundation Models から AgentCore まで ── を機能カタログとして俯瞰する