クラウド経由で使う：Bedrock / Vertex

Claude や Gemini、GPT は各社の API から直接呼べます。それなのに、わざわざ AWS Bedrock・Google Vertex AI（現 Gemini Enterprise Agent Platform）・Microsoft Foundry（旧 Azure AI Foundry）といったクラウドプラットフォーム経由で同じモデルを使う企業が多いのはなぜか。理由は単純で、会社がすでに使っているクラウドの中に AI を“同居”させられるからです。請求・権限・データの置き場所・監査ログ——これらを新しく作り直さずに済むのが最大の価値です。この記事は、その仕組みと選び方を初学者向けに、図とともに整理します。

FIG.1　同じモデルでも、クラウド経由なら認証・ネットワーク・請求・ログを“自社の枠”の中で完結できる

01クラウド経由を選ぶ5つの動機

機能や速度はほぼ同じです。違いが出るのは「組織として運用しやすいか」という一点に集約されます。代表的な動機は次の5つです。

• セキュリティとコンプライアンス：通信や認証を自社の IAM／VPC の枠内に収め、既存の社内ルール（誰がどのモデルを呼べるか）にそのまま乗せられます。データの取り扱い条件も、すでに締結済みのクラウド契約に従います。
• 請求の一本化：AI の利用料が既存の AWS／GCP／Azure 請求に合算され、経理・予算管理が増えません。部門別のコスト配賦も既存の仕組みで回せます。
• データの所在（リージョン）指定：処理を行う地域を選べます。「EU 内で処理」「国内リージョンのみ」といった要件があるときに効きます。ただしモデルごとに使えるリージョンは限られるため、要件のリージョンで目的のモデルが提供されているかは必ず事前確認します。
• SLA とサポート：エンタープライズ契約があれば、稼働保証や問い合わせ窓口も既存の契約・サポート体制の延長で扱えます。
• マルチモデルを1つの基盤で：同じプラットフォーム上で Claude・Gemini・GPT・Llama・Mistral などを横並びに試し、用途ごとに切り替えられます。比較検証や乗り換えのコストが下がります。

02主要3プラットフォームの全体像

2026 年時点で、企業向けにモデルを束ねる主力は次の3つです。名称が近年変わっているので、まずそこを押さえます。

• AWS Bedrock（Amazon）：Claude を厚く揃え、Llama や Amazon 自社の Nova／Titan 系も扱う。
• Google Vertex AI：2026 年に Gemini Enterprise Agent Platform へ改称・拡張。Gemini を中心に、Claude や Llama も Model Garden から呼べる。
• Microsoft Foundry（旧 Azure AI Foundry）：GPT 系（GPT-5.x）の本拠地。2026 年からは Claude も提供開始し、Gemini を除く主要モデルがほぼ揃う。

かつては「Claude は Bedrock／Vertex、GPT は Azure、両者に Claude/GPT は無い」という棲み分けでしたが、各社が相互にモデルを取り込んだ結果、境界はかなり曖昧になっています。下表は“どこで何が一級市民として使えるか”の現状の目安です（提供状況は頻繁に変わるため、最終判断は各公式カタログで確認してください）。

プラットフォーム	主に呼べるモデル（2026 時点）
AWS Bedrock	Claude（Opus 4.8 / Sonnet 4.6 / Haiku 4.5 など）、Llama、Amazon Nova、Mistral ほか
Vertex AI / Gemini Enterprise Agent Platform	Gemini（3.x 系）、Claude（Opus / Sonnet / Haiku）、Llama、Gemma ほか 200+ モデル
Microsoft Foundry（旧 Azure AI Foundry）	GPT（5.x 系）、Claude（Opus / Sonnet / Haiku）、Llama、Mistral ほか多数

料金体系はどこも基本「従量制（使ったトークン分）」で、加えてキャパシティ予約の固定料金プラン（Bedrock の Provisioned Throughput、Azure の PTU など）を選べる、という構造は共通です。

03クラウド経由の“通り道”はどれも同じ形

3社で API の細部は違いますが、流れは同じです。「権限を持つ→モデルを指定して呼ぶ→結果を受け取る」。直接 API との一番の違いは、最初の「権限」が API キー1本ではなく、クラウドの認証基盤（IAM など）に置き換わる点です。

FIG.2　API キーの代わりにクラウドの権限基盤で認可し、モデル ID とリージョンを指定して呼ぶ

04AWS Bedrock で Claude を呼ぶ

Bedrock では3ステップで動かせます。①使いたいモデルへのアクセスを申請し、②IAM で呼び出し権限を与え、③コードから呼ぶ、という流れです。

具体的なコード例（Node.js）です。最新世代の Claude は、単純な anthropic.claude-... ではなく us.anthropic.claude-... のような推論プロファイル ID を使う点が以前と変わったところです。これは複数リージョンへ自動で負荷分散するための仕組みで、安定運用に役立ちます。

import { BedrockRuntimeClient, InvokeModelCommand }
  from "@aws-sdk/client-bedrock-runtime";

const client = new BedrockRuntimeClient({ region: "us-east-1" });

const body = JSON.stringify({
  anthropic_version: "bedrock-2023-05-31",
  max_tokens: 1024,
  messages: [{ role: "user", content: "東京の見どころは？" }],
});

const response = await client.send(new InvokeModelCommand({
  // クロスリージョン推論プロファイル ID（地域プレフィックス us. に注意）
  // 利用可能な正確な ID は Bedrock のモデル一覧で確認する
  modelId: "us.anthropic.claude-sonnet-4-6-v1:0",
  body,
}));

const json = JSON.parse(new TextDecoder().decode(response.body));
console.log(json.content[0].text);

モデル ID の文字列は世代やリージョンで変わります。必ず Bedrock のモデル一覧（コンソール／ドキュメント）に表示される正確な ID をコピーして使ってください。古い ID をハードコードすると、提供終了時にまとめて壊れます。

05Google Vertex AI（Gemini Enterprise Agent Platform）で Gemini を呼ぶ

Google のプラットフォームは 2026 年に Gemini Enterprise Agent Platform へ改称・機能拡張されました。ドキュメントやコンソールでこの名前を見かけても、従来の Vertex AI の後継と捉えて問題ありません。基本の使い方は「プロジェクトで API を有効化 → 認証 → モデルを指定して呼ぶ」です。

import { VertexAI } from "@google-cloud/vertexai";

const vertex = new VertexAI({
  project: "your-project",
  location: "us-central1",
});

const model = vertex.getGenerativeModel({
  // 現行世代の Gemini を指定（正確なモデル名は Model Garden で確認）
  model: "gemini-3-pro",
});

const result = await model.generateContent("東京の見どころは？");
console.log(result.response.text());

Gemini のバージョン番号は更新が速いため、gemini-2.5-pro のような旧世代名を埋め込んだままにせず、その時点で提供されている最新の安定版を Model Garden で確認してから指定するのが安全です。Claude を Vertex 経由で使う場合は、Anthropic 用の SDK／エンドポイント形式に従います（提供モデルやリージョンは公式ドキュメントで確認）。

06Microsoft Foundry（旧 Azure AI Foundry）の位置づけ

Azure 側のプラットフォームは Microsoft Foundry に名称が整理されました。GPT 系（GPT-5.x ファミリー）の中心地である一方、2026 年からは Claude も提供開始しています。つまり「Azure には Claude が無い」という以前の説明はもう正しくありません。GPT を主軸にしつつ Claude も同じ基盤で扱いたい、という構成が取れます。

3社とも、いまや「自社モデル＋他社の主要モデル」を同じ基盤に載せる方向へ動いている。

07クラウドを跨ぐなら抽象化レイヤーを挟む

「いまは Bedrock だが、将来 Vertex や直接 API に乗り換えるかもしれない」——そんなときは、アプリのコードを特定プラットフォームに固定しない抽象化レイヤーを挟むと移行が楽になります。代表例が Vercel AI Gateway（AI SDK と組み合わせて使う統一ゲートウェイ）です。

AI Gateway は1つの API で多数のプロバイダ／モデルにアクセスでき、予算上限の設定、使用量モニタリング、負荷分散、フォールバック（あるモデルが落ちたら別モデルへ自動切替）を一括で管理できます。2026 年時点で Anthropic・OpenAI・Google・Amazon Bedrock・Vertex AI・xAI など 40 以上のプロバイダに対応し、自前の API キーを持ち込む BYOK も可能です。

import { generateText } from "ai";

// プロバイダ間の差を意識せず "provider/model" の文字列で指定
// 裏側のルーティング・フォールバックは Gateway が担う
const { text } = await generateText({
  model: "anthropic/claude-opus-4-8",
  prompt: "東京の見どころを3つ、簡潔に。",
});

console.log(text);

抽象化は便利ですが万能ではありません。各モデル固有の機能（特殊なツール呼び出しやマルチモーダル指定など）は、共通インターフェースからは扱いにくいことがあります。「共通部分はゲートウェイ、モデル固有の作り込みは直接呼ぶ」と割り切ると現実的です。

08結局どれを選ぶか

難しく考える必要はありません。すでに使っているクラウドに寄せるのが基本で、そこに「主に使いたいモデル」を掛け合わせれば答えはほぼ決まります。

一方、スタートアップや個人開発で、まだ大きなクラウド統合の要件が無いなら、Anthropic／OpenAI／Google の直接 API で十分です。最新機能がいち早く来る、設定が軽い、というメリットがあります。複数モデルを跨ぐ予定があるなら、最初から AI Gateway のような抽象化を入れておくと後が楽です。

09事前に知っておきたい注意点

• 最新機能の到達にラグがある場合がある：新モデルや新機能は、まず提供元の直接 API で先行し、クラウド経由は少し遅れて対応——というケースがあります。最新機能を最速で使いたい用途では直接 API も検討します。
• リージョン制約：使いたいモデルが、要件のリージョンで提供されているとは限りません。導入前に「目的のモデル × 必要なリージョン」の組み合わせを必ず確認します。
• 料金は変動する：従量単価やキャパシティ予約の条件は頻繁に更新されます。固定料金プラン（Provisioned Throughput／PTU 等）は規模が読めるときに有効ですが、見積りは必ず最新の公式料金表で。
• モデル ID／名称をハードコードしない：世代交代で ID が変わったり旧版が終了したりします。設定ファイルや環境変数に切り出し、公式の最新 ID を参照する運用にします。
• 権限は最小限・重要操作は承認制：呼び出し権限は対象モデル・リージョンを絞り、ログ（誰が何を呼んだか）を残します。生成結果は一次情報での検証を前提にし、事実誤り（ハルシネーション）をそのまま業務判断に使わないこと。

クラウド経由は「同じモデルを、自社の運用ルールの中で安全に使う」ための選択肢です。機能で選ぶというより、組織として無理なく回せるかで選ぶ——これが判断の軸になります。