Claude Models on Google Cloudの2形態 — 運営元で変わる点の比較

運営者が違う2つの形態がある

Google CloudのプロジェクトからClaudeを使う方法は2つあります。AnthropicがClaude APIを運営する「Anthropic managed」と、GoogleがAgent Platformの一部としてClaudeモデルを運営する「Google managed」です。どちらも請求はGoogle Cloudの請求書に載りますが、APIの形、認証、レート制限の管理者、使える機能が違います。

従来から使われてきたVertex AI経由の呼び出しは、Google managedにあたります。Anthropic managedは後から加わった形態で、中身はClaude APIそのものです。そのため同じGoogle Cloud経由でも、Messages APIのリクエストをほぼそのまま流せる側と、Agent Platformの流儀に合わせて組み替える側に分かれます。

8項目で比べる違い

公式の比較表をもとに、読み替えの手間が出やすい順に並べ直しました。

表で目を引くのは、リクエストの組み立てです。Anthropic managedはClaude APIと同じ形なので、anthropic-version や anthropic-beta のヘッダー、リクエスト本文、ストリーミングの扱いがそのまま通ります。Google managedはmodelをURLに置き、バージョンを本文に入れ、ストリーミングには別のエンドポイントを使います。

モデルIDにも差があります。Claude 4.6より前のモデルでは、Anthropic managedがClaude APIのID(例: claude-haiku-4-5-20251001)をそのまま使います。Google managedは日付の前のハイフンを @ に替えます(例: claude-haiku-4-5@20251001)。Claude 4.6以降のモデルは、どちらもClaude APIのIDです。

有効化するサービスも別です。Google managedは aiplatform.googleapis.com だけを有効にします。Anthropic managedは claude.googleapis.com と、Marketplaceの利用を契約に紐づける anthropic-managed-claude.cloudpartnerservices.goog の2つが要ります。claude.googleapis.com が無効だと、呼び出しは失敗します。

共通点は認証の土台と請求書

違いが目立つ一方で、共通する部分もあります。

• 認証にはどちらもGoogle Cloudの認証情報(Application Default Credentialsを含む)を使います
• アクセスの許可は、形態ごとに別々のIAMロールで行います
• 請求は、どちらもGoogle Cloudの請求書に載ります
• AnthropicのクライアントSDKは、両方の形態に対応しています

「同じ認証情報で通る」ことと「同じ権限で通る」ことは別です。Anthropic managedでは roles/claude.viewer、roles/claude.user、roles/claude.admin を使います。Google managedでは aiplatform.endpoints.predict を含むAgent Platformのロール(例: roles/aiplatform.user)が必要です。片方で付けた権限は、もう片方には効きません。

Anthropic managedで増える手順と制約

Anthropic managedは、Claude APIを使う感覚に近い反面、Google Cloud側で初期設定が要ります。

有効化は次のコマンドです。

gcloud services enable claude.googleapis.com \
  anthropic-managed-claude.cloudpartnerservices.goog \
  --project=my-project-id

ここで押さえたい点が4つあります。

組織はプロジェクトごと。作られるAnthropic組織は、会社が既に持っている組織(Claude Enterpriseを含む)とは別物です。プロジェクトを増やすたびに、手順を2番から繰り返します。チームごとにアクセスを分けたいときは、プロジェクトを分けます。ロールはプロジェクトに付くので、ワークスペースだけを分けても権限は分かれません。

APIキーは使えない。認証はGoogle Cloudの認証情報だけで、Claude Consoleでもこの組織のAPIキーは作れません。SDKクライアントは ANTHROPIC_API_KEY、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_BASE_URL を無視します。

ワークスペースIDがURLに入る。リクエスト先は claude.googleapis.com で、パスにプロジェクト、ロケーション、ワークスペースが入ります。anthropic-workspace-id ヘッダーは送りません。ant CLIを使うときは ANTHROPIC_WORKSPACE_ID を未設定にし、ANTHROPIC_GOOGLE_CLOUD_WORKSPACE_ID を使います。

Consoleの入口はIAMが握る。メールアドレスでのサインインはできず、Google CloudコンソールのClaudeページから入ります。入れるのは、プロジェクトで roles/claude.admin を持つ人だけです。

既存のClaude API組織は、この形態の組織に変換できません。新しい組織へ切り替える形になり、APIキー、ワークスペース、Consoleの設定は引き継がれません。ファイル、スキル、バッチ、Managed Agentsのリソースも元の組織に残ります。ただし2つの組織は独立して並行稼働できるので、段階的に移せます。

Google managedで使えない機能

Google managedは、Agent Platformの枠に収まる範囲の機能を提供します。Messages API、プロンプトキャッシュ、拡張思考、ツール使用(bash、ブラウザー使用、computer use、メモリー、テキストエディター、ウェブ検索)、引用、構造化出力に対応しています。

対応しないものは次のとおりです。

• 画像やドキュメントのURLソース、Files API
• コード実行、ウェブフェッチ、アドバイザーの各サーバー側ツール
• Agent Skills、MCPコネクター、プログラムによるツール呼び出し
• Message Batches API、Models API、Admin API、Compliance API、Usage and Cost API
• Claude Managed Agents
• サーバー側フォールバック(fallbacks パラメーター)

フォールバックは、クライアント側で組む方法に置き換えます。リクエストのペイロードは30MBが上限で、大きな文書や多数の画像ではトークン上限より先にここへ当たることがあります。

一方Anthropic managedでは、Claude APIと同じように動く機能として、ファストモード(Claude Opus 5.5向け)、ウェブ検索・ウェブフェッチ・コード実行・メモリー・アドバイザー・MCPコネクターなどのツール、Agent SkillsとFiles API、プロンプトキャッシュ、構造化出力、トークンカウント、Message Batches APIが挙がっています。Managed Agentsも使えます。

ただし公式は、この一覧が全機能の網羅ではなく、載っていない機能の可否は示していないと断っています。さらに、Anthropic managedにも非対応があります。APIキー、MCPトンネル、セルフホスト環境でのメモリーストア、そして ant CLIや各SDKに付属する構築済みのセルフホストサンドボックスワーカーです。ワーカーが要るときは、Environments Workエンドポイントを直接呼ぶ自前の実装が必要になります。

機能の対応差をBedrockも含めて見たいときは、ClaudeをBedrockとGoogle Cloudで使う — API機能の対応差を比較が整理しています。

課金・レート制限・ログの管理者が変わる

課金の窓口は同じGoogle Cloudの請求書でも、中身は違います。

Anthropic managedはMarketplace経由です。Anthropicが利用量を計測し、Google CloudにClaude Consumption Unit(1単位が0.01米ドル)で報告します。Anthropicからの別途の請求書は届きません。利用量とコストはClaude ConsoleのUsageページとCostページで見られ、Google Cloudの支出コミットメントがあれば、他のMarketplace購入と同様に消化されます。既存の割引がある場合は、手順を始める前に営業担当へ連絡します。割引は過去の利用分にさかのぼって適用できないためです。

Google managedは、Agent Platformの利用料としてGoogle Cloudが請求します。価格はGoogle Cloudの料金ページに従い、エンドポイントの種類(global、マルチリージョン、リージョナル)でも変わります。リージョナルとマルチリージョンの上乗せは、Vertex AIのClaudeエンドポイント3種で扱っています。

レート制限は、Anthropic managedではAnthropicが管理し、上限の引き上げはAnthropicの担当者かセールスに依頼します。Google managedではGoogle Cloudのクォータで、引き上げもGoogle Cloud側の手続きです。本番トラフィックを寄せる前に、移行先の上限を確かめます。

ログと保持にも差があります。

• Anthropic managed: Cloud Audit Logsの claude.googleapis.com に記録されます。大半のルートはData Accessログで、既定ではオフです。リクエストの記録を残すなら、プロジェクトの監査ログ設定でオンにします。暗号鍵や認証情報保管庫の一部のルートは、常時オンのAdmin Activityログに入ります
• Google managed: プロンプトと応答の記録には、Agent Platformのリクエスト・レスポンスログを使います。公式は直近30日分以上の保管を勧めています
• データ保持: Anthropic managedはClaude APIと同じ方針で、Anthropicがデータ処理者です。ZDRは依頼ベースで、他の組織のZDRは引き継がれません。Google managedはGoogle Cloudがデータの扱いを定めます

自分がどちらを使っているかを見分ける

既存のコードを引き継いだときは、まず形態を確かめます。見るべき手がかりは、リクエスト先のホスト、SDKのクライアント名、IAMロール、管理画面です。

コードベースを手早く当たるなら、次のように探せます。

# SDKクライアント名で判定する
grep -rnE "AnthropicVertex|AnthropicGoogleCloud" .
 
# プロジェクトで有効なサービスで判定する
gcloud services list --enabled --project=my-project-id \
  | grep -E "claude.googleapis.com|aiplatform.googleapis.com"

api.anthropic.com をAPIキーで呼んでいるなら、どちらの形態でもありません。Anthropicから直接契約している通常のClaude APIです。

どちらを選ぶかは、組織・機能・窓口で決まる

選び方は、次の3点を順に見ると整理しやすくなります。

判断の根拠は、公式の比較表と機能一覧にあります。Anthropic managedのロケーションは global で、データ所在地を絞りたい場合はリクエストに inference_geo: "us" を指定してアメリカ内での推論に限定します。Google managedではエンドポイントの種類そのものを選びます。

移行は、どちらの向きでも公式の手順があります。両形態は並行して動かせるので、ワークロードを少しずつ寄せる進め方ができます。Claude Codeなど既存ツールの設定は、使っているのがVertex経由ならGoogle managed側のままです。リージョンの設定はClaude CodeでVertex AIのリージョンを設定するにあります。

プロバイダー別の料金を比較したい場合は、Claude Bedrock・Vertex・Foundryの料金を比較も参照できます。

まとめ

2形態の本質は、Claude APIをそのままGoogle Cloudの入口から使うか、GoogleのAgent Platformに載ったClaudeを使うかの違いです。前者は機能の対応が広い代わりに、プロジェクトごとのAnthropic組織、Marketplace購読、ワークスペースIDの管理が増えます。後者はAnthropic組織が要らずGoogle Cloudのクォータで完結しますが、Files APIやManaged Agentsなどは使えません。

既存コードの形態は、ホスト名かSDKのクライアント名で一発で分かります。ここを取り違えたまま権限や上限の相談をすると、見るべき管理画面から間違えるため、最初に確認しておく価値があります。