Claude Models on Google Cloud (Anthropic managed) と Vertex AI の違い: IAM が API キーを置き換える、ただし届かない場所が 3 つある

10 月 22 日、Anthropic は Claude Models on Google Cloud (Anthropic managed) を公開しました。中身は Claude API そのもので、Anthropic が運用し、claude.googleapis.com 経由で呼び出し、Google Cloud IAM で認可し、Google Cloud Marketplace で課金されます。Google のプロジェクトから Claude を呼ぶ従来の方法、つまりこれまで Vertex AI と呼ばれていたものは、Anthropic のドキュメントでは Claude Models on Google Cloud (Google managed) という名前になりました。SDK クライアントの名前は今も AnthropicVertex のままです。

どちらも同じプロジェクト、同じ Google の認証情報、同じ請求書を使えます。違うのは API の形、IAM ロール、機能、そして Anthropic の組織がそもそも存在するかどうかです。新しい方の売りは「IAM が API キーを置き換える」ことです。それ自体は正しいのですが、3 つの場所では、うたい文句ほどには効きません。前段に置くゲートウェイ、読み取り専用ロール、そしてすでに動いているエージェントです。Python SDK の新しい AnthropicGoogleCloud クライアントを、偽のトークンを使い、どこにも何も送らないモックトランスポートに対して実行し、実際に何を送信するかを確かめました。ゲートウェイについての発見はこの実行から、残りの 2 つは IAM リファレンスそのものから来ています。

Claude Models on Google Cloud (Anthropic managed) とは何か、Vertex AI とどう違うのか

Google の入口の奥にあるファーストパーティの Claude API です。一方の Vertex AI は、Agent Platform の予測エンドポイントを通じて Google 自身が Claude を提供する仕組みです。Anthropic managed 側のリクエストは通常の Claude API リクエストと同じ形をしています。model はボディに、anthropic-version はヘッダーに入り、ストリーミングは "stream": true で、モデル ID も api.anthropic.com と同じです。Google managed 側では model が URL に、anthropic_version がボディに入り、ストリーミングには専用の :streamRawPredict エンドポイントがあり、Claude 4.6 より前のモデルはスナップショット日付の前に @ を付けます。

リクエストの形は小さな違いです。大きな違いは機能です。Google managed のドキュメントは、Files API、コード実行、Web フェッチ、advisor ツール、Agent Skills、MCP コネクター、Message Batches、Models API、サーバー側フォールバック、Claude Managed Agents を非対応として挙げています。Anthropic managed のページは、これらをすべて利用可能としています。こちら側の例外は、MCP トンネル、セルフホスト環境でのメモリストア、そして ant CLI と Python・TypeScript・Go の各 SDK に入っている既製のセルフホスト型サンドボックスワーカーです。これらについては、Environments Work エンドポイントに対して自分でワーカーを書くことになります。

Vertex を離れると、さらに 2 つのことが入れ替わります。1 つはデータ処理者です。Google managed では Google、Anthropic managed では api.anthropic.com と同じく Anthropic です。ドキュメントによれば「Anthropic の trust and safety システムなど、一部の支援サービスは Google Cloud の外でデータを処理します」。もう 1 つは制限です。Vertex 側では Google がクォータを設定し、新しい方では Anthropic がレート制限を設定します。使用量は Anthropic が 1 単位 0.01 ドルの Claude Consumption Units で計測し、Google の請求書に載り、他の Marketplace 購入と同じように Google Cloud の利用コミットメントに算入されます。

つまり Vertex を使っているチームにとって、移行は主に機能の解放です。すでに api.anthropic.com を使っているチームにとっては、処理者は変わりません。変わるのはアクセス、課金、そして作業する組織です。

Claude Models on Google Cloud (Anthropic managed) のセットアップで何が作られるのか

新しい Anthropic 組織です。その Google Cloud プロジェクトに紐づき、会社がすでに持っているどの組織とも別物で、Claude Enterprise も例外ではありません。既存の組織を変換することはできません。セットアップは 4 ステップです。Marketplace のリスティングをサブスクライブし、2 つのサービスを有効にし、Activate をクリックしてメールで届いたリンクから組織フォームに記入し、最後に Google Cloud コンソールから Claude Console を開きます。

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

claude.googleapis.com は API を提供し、IAM 権限を定義します。2 つ目のサービスは使用量をサブスクリプションに紐づけます。1 つ目を有効にするとプロジェクトにサービスエージェントが作られ、ドキュメントは、そのロール付与を外すとサービスが止まると警告しています。想定外のバインディングを整理する Terraform や組織ポリシーがあるなら、そこにコメントを残しておく価値があります。

api.anthropic.com から来る場合、すべてがゼロから始まります。API キー、ワークスペース、Console の設定は引き継がれず、ファイル、スキル、バッチ、Managed Agents のリソースは古い組織に残ります。別の組織で結んだゼロデータ保持 (ZDR) の取り決めも引き継がれません。こちらでは申請に応じて利用できます。交渉済みの割引は、始める前に担当者に相談しておく必要があります。「割引は過去の使用量には適用できない」からです。2 つの組織は独立していて並行してトラフィックを処理できるので、切り替えはワークロードごとに進められます。

新しい Console にメールアドレスでサインインする人はいません。Google Cloud が IAM を確認して platform.claude.com にリダイレクトし、開けるのは roles/claude.admin だけです。すべての呼び出し元が必要とするワークスペース ID をコピーするために、誰かが一度は開く必要があります。

AnthropicGoogleCloud SDK クライアントは何を送信するのか

Authorization: Bearer としての Google アクセストークン、SDK のデフォルト API バージョン、そしてプロジェクトとワークスペースを含む URL です。ファーストパーティ API を使っているマシンによくあるように ANTHROPIC_API_KEY と ANTHROPIC_BASE_URL の両方が設定されていても、クライアントはどちらも無視しました。モックトランスポートが messages.create について記録したリクエストは次のとおりです。

POST https://claude.googleapis.com/v1/projects/my-project-id/locations/global/workspaces/wrkspc_01FAKE/invoke/v1/messages
user-agent: AnthropicGoogleCloud/Python 2.3.0
anthropic-version: 2026-10-21
authorization: Bearer ya29.FAKE-token

x-api-key はなく、anthropic-workspace-id ヘッダーもありません。ワークスペースがパスに入っているため、ドキュメントはこのヘッダーを付けてはいけないとしています。組織レベルのルート (この SDK バージョンでは /v1/organizations/ と /v1/user_profiles) は、ワークスペースを含まないベースに送られます。

GET https://claude.googleapis.com/v1/projects/my-project-id/locations/global/claudeOrganization/invoke/v1/organizations/me

最初のデプロイの前に知っておきたい挙動が 3 つあります。

クライアントは認証情報なしで生成でき、最初のリクエストで失敗します。 マシンに Application Default Credentials がない状態でも、AnthropicGoogleCloud(project=..., workspace_id=...) は問題なく生成され、ベース URL も表示しました。DefaultCredentialsError が出たのは messages.create のときだけです。クライアントをインスタンス化するだけのヘルスチェックは、1 回も呼び出しができないホストでも通ってしまいます。

ワークスペース ID の欠落も、リクエスト時のエラーです。 ID がなくてもクライアントは生成され、メッセージの呼び出しで次のエラーが出ました。

AnthropicError: No workspace ID found. Set the `workspace_id` argument or the `ANTHROPIC_GOOGLE_CLOUD_WORKSPACE_ID` environment variable.

組織ルートはワークスペースを必要としないので、こちらは問題なく組み立てられ、モックに渡されました。

プロジェクトは GOOGLE_CLOUD_PROJECT にフォールバックします。 ANTHROPIC_GOOGLE_CLOUD_PROJECT が未設定だと、クライアントは GOOGLE_CLOUD_PROJECT を使い、そのプロジェクトの URL を組み立てました。この変数が別のプロジェクトを指していれば、呼び出しはそちらに行きます。Anthropic 専用の変数を明示的に設定してください。

AnthropicVertex から AnthropicGoogleCloud へコードを移すには

まずアカウントとアクセス、次に 1 行のクライアント差し替え、そのあとに挙動を変える 2 つの変更です。新しい SDK クライアントはベータ版です。上のセットアップのあと、API を呼び出すすべての ID にプロジェクト単位で roles/claude.user を付与し (roles/aiplatform.user のような Agent Platform のロールはここでは効きません)、ANTHROPIC_GOOGLE_CLOUD_PROJECT と ANTHROPIC_GOOGLE_CLOUD_WORKSPACE_ID を設定して、クライアントを差し替えます。Python では次のとおりです。

pip install -U "anthropic[google_cloud]"

# before: Google managed (Vertex AI)
from anthropic import AnthropicVertex
client = AnthropicVertex(project_id="my-project-id", region="global")
 
# after: Anthropic managed, project and workspace from the environment
from anthropic import AnthropicGoogleCloud
client = AnthropicGoogleCloud()

TypeScript ではパッケージが @anthropic-ai/google-cloud-sdk、Go では vertex.WithGoogleAuth() の代わりに googlecloud.NewClient()、Java では VertexBackend の代わりに GoogleCloudBackend を使います。

効いてくる 2 つの変更は次のとおりです。

• モデル ID。 Claude 4.6 より前のモデルでは、@ をハイフンに置き換えます。claude-haiku-4-5@20251001 は claude-haiku-4-5-20251001 になります。
• データ所在地。 所在地の要件のために Vertex のリージョンまたはマルチリージョンのエンドポイントを選んでいた場合、ここには対応する URL がありません。ロケーションは global です。ドキュメントが用意しているのは、米国内だけで推論するためのリクエスト単位の inference_geo: "us" で、Claude 4.6 以降のモデルのみ、料金は標準の 1.1 倍です。EU や単一リージョンの要件がある場合は移行前に個別の確認が必要で、Haiku 4.5 のワークロードはこのパラメーター自体を使えません。

API バージョンについても一言触れておきます。Vertex を離れることが原因ではありませんが、SDK 2.3.0 はどちらのクライアントからもデフォルトで 2026-10-21 を送るので、差し替えのためのアップグレードがそのままバージョン移行になります。このバージョンでは temperature、top_p、top_k が 400 を返し、SDK もこれらを引数として受け付けなくなりました。削除するか、API バージョン 2026-10-21 の解説にあるように、リクエスト単位で旧バージョンを指定してください。

ant CLI は SDK より注意が要ります。まず更新してください。ドキュメントによれば、対応していないバージョンは ANTHROPIC_GOOGLE_CLOUD_* 変数を無視し、見つけた別の認証情報でリクエストを Claude API に送るか、失敗します。最新の CLI でも、ファーストパーティの認証情報があればそちらを優先します。API キー、認証トークン、ANTHROPIC_PROFILE、フェデレーション関連の変数を外し、ANTHROPIC_WORKSPACE_ID も未設定のままにしてください。設定されていると、禁止されたワークスペースヘッダーを送ってしまいます。そのうえで本番トラフィックの前に、対象のプロジェクトとワークスペースで小さな実リクエストを 1 回送り、レート制限を確認します。制限は今や Google のクォータではなく Anthropic のものです。

Claude Models on Google Cloud の前に LLM ゲートウェイを置けるか

置けます。そしてゲートウェイは、トークンと一緒にルーティングも引き受けることになります。そのためのクライアントオプションが skip_auth で、「トークンを代わりに付けてくれるプロキシ」向けです。これを使うとクライアントは Google のトークンを生成しません。自分で設定したヘッダー、たとえばゲートウェイ用のトークンは、引き続き送信されます。トークンプロバイダーや認証情報オブジェクトとは併用できません。

ValueError: `skip_auth` is mutually exclusive with `token_provider` and `credentials`; `skip_auth` disables authentication entirely.

ドキュメントが明示していないのは URL のことです。クライアントをゲートウェイに向けるには base_url (または ANTHROPIC_GOOGLE_CLOUD_BASE_URL) を設定しますが、ベース URL を明示するとクライアント自身のルーティングが無効になります。skip_auth=True、ワークスペース ID を設定、base_url="http://gw.internal/claude" の条件で、モックトランスポートは次を記録しました。

POST http://gw.internal/claude/v1/messages
GET  http://gw.internal/claude/v1/organizations/me

プロジェクトもワークスペースもなく、2 種類のルートが同じベースに乗っています。クライアントに渡したワークスペース ID はどこにも使われませんでした。このような短いベースを持つゲートウェイは、claude.googleapis.com の URL を自分で組み立て直す必要があります。呼び出し元ごとにプロジェクトとワークスペースを選び、組織ルートは claudeOrganization のベースに送ります。ワークスペースが 1 つだけのゲートウェイなら、プロジェクトとワークスペースを含む完全なプレフィックスを base_url に埋め込むこともできますが、その場合は組織ルートがワークスペースのパスの下に入ってしまうので、別の設定が必要です。いずれにせよ、ゲートウェイはもうヘッダーの書き換えではありません。ルーティングテーブルになります。

ゲートウェイが付けるトークンには、もう 1 つの影響があります。ゲートウェイが自分のサービスアカウントで上流を呼ぶと、IAM が確認する ID も、有効にしている監査ログに記録される ID も、そのアカウントになります。どの開発者がリクエストを送ったかを知っているのはゲートウェイだけです。したがってゲートウェイは、Google のトークンに差し替える前に、独自の仕組みで呼び出し元を認証し、それぞれがどのワークスペースに届いてよいかを決め、それを記録しなければなりません。

API バージョン 2026-10-21 でのヘッダーの変更と比べてみてください。あちらではゲートウェイが X-Api-Key と Authorization のどちらかで認証情報を見つける必要がありました。ここでは上流側についてその問題はなくなります。キーは存在せず、x-api-key は送ってはいけないからです。下流側では、この問題は再びゲートウェイ側で扱う必要があります。同じゲートウェイが api.anthropic.com も扱ったり、古いクライアントに対応したりしているなら、それらが送ってくるものは引き続き受け取り、Google のトークンを付ける前に取り除く必要があります。ほかに何をそのまま通す必要があるかは Claude Code のゲートウェイの解説にまとめてあります。ドキュメントによれば、anthropic-version と anthropic-beta はここでも Claude API と同じように機能します。

Claude Models on Google Cloud の IAM ロールで誰が何を読めるのか

「読み取り専用」という言葉から想像するより多くを読めます。事前定義ロールは 3 つで、プロジェクト単位で付与します。roles/claude.viewer はワークスペースリソースに対するすべての get と list、roles/claude.user はメッセージ送信を含むワークスペースリソースに対するすべての操作、roles/claude.admin は組織レベルのルートと Console のためのロールです。

ワークスペースはアクセスの境界ではありません。 ロールはプロジェクト単位で付与されるので、1 つのロールがそのプロジェクト内のすべてのワークスペースに適用されます。アクセスを分ける必要があるチームに対するドキュメントの答えは、チームごとに Google Cloud プロジェクトを分け、それぞれに専用の Anthropic 組織と専用の Marketplace セットアップを用意することです。

viewer はメタデータだけでなく中身も読めます。 IAM リファレンスははっきり書いています。files.get はファイルの中身のダウンロード、messageBatches.get はバッチ結果のダウンロード、sessions.get はセッションのイベント履歴とストリームをカバーします。つまり「roles/claude.viewer はすべてのセッションの完全なイベント履歴を読める」ということです。メモリの内容やスキルバージョンの内容も同じように読めます。Vault の認証情報は一覧表示でき、秘密のフィールドは決して返されません。viewer はメッセージを送れませんが、プロジェクト内のすべての Managed Agents セッションについて、保存された履歴を読むことができます。

次にログのデフォルトです。Cloud Audit Logs は、このサービスを claude.googleapis.com として記録します。ほとんどのルートは Data Access ログに該当し、ドキュメントによればこれはデフォルトでオフです。メッセージ、ファイル、バッチ、ほとんどの Managed Agents リソースがここに含まれます。暗号鍵のルートとほとんどの Vault ルートは Admin Activity ログで、こちらは常にオンです。プロジェクトで Data Access ログが有効になっていない限り (直接でも、フォルダや組織のポリシーからの継承でも)、viewer が 1 か月分のセッションのトランスクリプトを読んでも監査エントリーは残りません。監査が必要になりうる相手に viewer を付与する前に、有効にしておいてください。

Google Cloud で IAM アクセスを取り消すと Claude Managed Agents はどうなるか

すでに動いているものには何も起きません。アクセスが確認されるのはセッションやデプロイメントの作成時で、実行中ではありません。アクセスを取り消した ID が開始したセッションは動き続け、スケジュールされたデプロイメントも実行のたびに作成者を確認し直すことはありません。ドキュメントの指示は、ユーザーを削除したりサービスアカウントをローテーションしたりするたびに、その ID が作成したセッションとデプロイメントを見直すことです。

ドキュメントが示しているのはルールで、手順ではありません。後片付けの間にその ID が新しい作業を始められないよう、筆者は次の順序で進めます。

• まずその ID の IAM バインディングを外し、その ID の代わりに呼び出すゲートウェイへのアクセスも外す。
• 次に、まだアクセス権のある管理者として、その ID が作成したスケジュール済みデプロイメントを一時停止、更新、またはアーカイブする。
• 実行中の各セッションに user.interrupt イベントを単独で送り、セッションが idle になったらアーカイブまたは削除する。
• もう一度一覧を取り、その ID が開始したものがもう何も動いていないことを確認する。

これは、その ID が何を作成したかを把握している前提です。共有のゲートウェイ ID を使っている場合、「作成者」は全員分がゲートウェイのサービスアカウントになります。誰がどのセッションとデプロイメントを開始したかは、自分で記録しておいてください。

「作成時にしか確認されない」の例外が予算です。セッション予算はセッションの実行中、モデルへの各リクエストの前に適用され、あとから変更や削除もできます。ただし付けられるのはセッション作成時だけなので、予算なしのセッションにあとから付けることはできません。Managed Agents の動的ワークフローのようにエージェントが自分で処理を分岐させるなら、予算は作成時に設定してください。

Vertex AI や api.anthropic.com を使うチームは Claude Models on Google Cloud に移るべきか

一度にすべてではなく、ワークロードごとに移ります。Vertex AI からなら、Vertex にない機能を必要とするものには強い理由があります。バッチ、ファイル、スキル、MCP コネクター、Managed Agents です。今うまく動いていて、リージョンのエンドポイントやデータ処理者としての Google に依存している素の Messages ワークロードについては、理由は弱くなります。その 2 つがどちらも変わるからです。

api.anthropic.com からなら、得られるのはキーの代わりの IAM と、Google のコミットメントに算入される使用量です。代わりに払うのは、空の状態から始まる組織、申請し直す ZDR の取り決め、作り直す保存済みリソース、そして新しいレート制限です。静的なキーをすでに Workload Identity Federation に置き換えたチームは、IAM の部分から得るものが少なくなります。

筆者の見方では、新しいワークロードは Anthropic managed 側に置き、履歴のあるワークロードは今の場所に残し、IAM の作業はトラフィックより先に済ませます。Data Access ログを有効にし、本当に viewer が必要なのは誰かを決め、最初の人が辞める前に Managed Agents のオフボーディング手順を書いておくことです。