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では手順が若干異なります。

Anthropicを設定する

セットアップ手順に従って、Claude Consoleでフェデレーション発行者を登録し、Anthropicサービスアカウントを作成し、フェデレーションルールを作成します。以下のGoogle Cloud固有の値を使用してください。

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

{
  "name": "gcp",
  "issuer_url": "https://accounts.google.com",
  "jwks_source": "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-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from Cloud Run"}],
)
print(message.content[0].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つを取り消せるようにします。