Google CloudでWIFを使用する

インスタンスメタデータサーバーにアクセスできるGoogle Cloudコンピュート環境（Cloud Run、Cloud Functions、App Engine、Compute Engine（GCE）、およびWorkload Identityを使用するGKE）は、アタッチされたサービスアカウントに対するGoogle署名付きIDトークンをリクエストできます。トークンの発行者はhttps://accounts.google.comであり、Anthropicは標準のOIDCディスカバリーを通じて直接検証できるため、追加のGoogle Cloud設定は不要です。

このガイドでは、Google発行者をAnthropicに登録し、GoogleサービスアカウントをAnthropicサービスアカウントにバインドし、ワークロードがそのIDトークンを短期間有効なClaude APIアクセストークンと交換する方法を説明します。



前提条件

• WIFの概念（サービスアカウント、フェデレーション発行者、フェデレーションルール）に精通していること。
• Cloud Run、Cloud Functions、App Engine、Compute Engine、またはGKEで実行されているワークロードを持つGoogle Cloudプロジェクト。
• そのワークロードにアタッチされたユーザー管理のGoogleサービスアカウント（Compute Engineのデフォルトサービスアカウントではないもの）。
• Anthropic組織のClaude Consoleでサービスアカウント、フェデレーション発行者、フェデレーションルールを作成する権限。



Google Cloudを設定する

Googleは、サービスアカウントがアタッチされたすべてのワークロードに対して自動的にIDトークンを発行します。適切なサービスアカウントをアタッチする以外にGoogle側で有効化するものはありませんが、標準のコンピュートとGKEでは手順が若干異なります。

gcloud run deploy my-service \
  --service-account [email protected]

GET http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://api.anthropic.com&format=full
Metadata-Flavor: Google

gcloud auth print-identity-token \
  --audiences="https://api.anthropic.com" \
  --include-email

{
  "iss": "https://accounts.google.com",
  "aud": "https://api.anthropic.com",
  "sub": "104892...",
  "azp": "104892...",
  "email": "[email protected]",
  "email_verified": true,
  "exp": 1775527120
}



Anthropicを設定する

Claude Consoleで、Settings → Workload identityを開き、Connect workloadをクリックして、Google Cloudタイルを選択します。ウィザードが発行者の登録、サービスアカウントの作成、フェデレーションルールの作成を案内します。

ウィザードがこれらのリソースを作成します。ウィザードに入力する場合でも、Admin API に送信する場合でも、以下の値を使用してください。

フェデレーション発行者： GoogleはOIDCディスカバリードキュメントを公開しているため、ディスカバリーモードを使用してください。この単一の発行者が、すべてのGoogle Cloudサーフェス（Cloud Run、GCE、Cloud Functions、App Engine、およびWorkload Identityを使用するGKE）をカバーします。ワークロードの区別は発行者ではなくルールで行ってください。

{
  "name": "gcp",
  "issuer_url": "https://accounts.google.com",
  "jwks": { "type": "discovery" }
}

フェデレーションルール： subとemailの両方のクレームでマッチさせます。emailは読みやすいサービスアカウントのアドレスです。subはサービスアカウントの数値の一意のIDであり、Googleは決して再利用しないため、これを固定しておくと、サービスアカウントが削除され、後で同じメールアドレスで新しいものが作成された場合でもルールが保護されます。一意のIDはgcloud iam service-accounts describe SA_EMAIL --format='value(uniqueId)'で確認できます。

{
  "name": "gcp-inference-worker",
  "issuer_id": "fdis_...",
  "match": {
    "audience": "https://api.anthropic.com",
    "claims": {
      "sub": "104892101234567890123",
      "email": "[email protected]"
    }
  },
  "target": {
    "type": "service_account",
    "service_account_id": "svac_..."
  },
  "workspace_id": "wrkspc_...",
  "oauth_scope": "workspace:developer",
  "token_lifetime_seconds": 600
}



トークンの取得と使用

Google Cloudワークロード内で、メタデータサーバーからIDトークンを取得し、POST /v1/oauth/tokenで交換し、返されたベアラートークンを使用してClaude APIを呼び出します。以下の例に示すように、メタデータサーバーから新しいIDトークンを返すトークンプロバイダーのcallableを指定すると、各Anthropic SDKが交換とリフレッシュのループを処理します。

import os
import anthropic
import google.auth.transport.requests
import google.oauth2.id_token
from anthropic import WorkloadIdentityCredentials

AUDIENCE = "https://api.anthropic.com"


def fetch_google_identity_token() -> str:
    request = google.auth.transport.requests.Request()
    return google.oauth2.id_token.fetch_id_token(request, AUDIENCE)


client = anthropic.Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=fetch_google_identity_token,
        federation_rule_id=os.environ["ANTHROPIC_FEDERATION_RULE_ID"],
        organization_id=os.environ["ANTHROPIC_ORGANIZATION_ID"],
        service_account_id=os.environ["ANTHROPIC_SERVICE_ACCOUNT_ID"],
        workspace_id=os.environ.get("ANTHROPIC_WORKSPACE_ID"),
    ),
)

message = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from Cloud Run"}],
)
print(next(block.text for block in message.content if block.type == "text"))

Google IDトークンは約1時間で有効期限が切れます。SDKは有効期限前にトークンプロバイダーを再呼び出しし、自動的に再交換します。アクセストークンのexpires_inより長く実行されるシェルスクリプトの場合は、タイマーでリフレッシュして交換を繰り返してください。



セットアップを検証する

ワークロード内から、IDトークンをデコードし、クレームがルールと一致することを確認します：

curl -sS -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://api.anthropic.com&format=full" \
  | jq -rR 'split(".")[1] | gsub("-";"+") | gsub("_";"/") | @base64d | fromjson'

issがhttps://accounts.google.com、audがhttps://api.anthropic.comであり、emailがフェデレーションルールの値と一致することを確認してください。その後、前のセクションの交換を実行します。交換が成功すると、sk-ant-oat01-で始まるaccess_tokenと秒単位のexpires_in値が返されます。400 invalid_grantの場合は、失敗した交換のトラブルシューティングを参照してください。Google Cloud側で最も一般的な原因は、emailクレームが欠落していることです（トークンに含まれるようにformat=fullでリクエストしてください）。



ルールのスコープを設定する

ルールのmatchブロックを、ユースケースに適合する最も狭いスコープにロックしてください：

• subを完全一致させる： claims.subに完全な数値の一意のIDを設定し、Googleトークンには決してsubject_prefixを使用しないでください。
• emailクレームを固定する： subに加えてclaims.emailを追加し、安定したIDと読みやすいアドレスの両方が一致する必要があるようにします。
• audienceを固定する： メタデータサーバーにリクエストする正確な値をaudienceに設定し、他のコンシューマー向けに発行されたトークンが拒否されるようにします。
• GKEでプロジェクトを固定する： format=fullトークンの場合、claims.google.compute_engine.project_id == "my-project"のようなconditionを追加して、ルールを1つのプロジェクトのノードに制限します。



次のステップ

• 完全なリソースモデルとSDKの認証情報の優先順位については、Workload Identity Federationページをお読みください。
• 環境（本番、ステージング）ごとに個別のフェデレーションルールを追加して、他に影響を与えずに1つを取り消せるようにしてください。