Workload Identity Federation

「Workload Identity Federation」（ワークロードIDフェデレーション）、すなわちWIFを使用すると、ワークロードは長期間有効な sk-ant-... APIキーの代わりに、短命のOpenID Connect（OIDC）トークンを使用してClaude APIに対して認証できます。トークンは、すでに運用している「identity provider」（IDプロバイダー）、すなわちIdPから発行されます。AWS IAM、Google Cloud、またはGitHub Actions、Kubernetes、SPIFFE、Microsoft Entra ID、Oktaなどの標準準拠のOIDC発行者が該当します。

ワークロードは、IDプロバイダーが署名したJWTを提示します。AnthropicはClaude Consoleで設定した信頼ルールに照らしてそれを検証し、組織内のサービスアカウントに紐付けられた短命のAnthropicアクセストークンを返します。発行したり、CIに保存したり、ローテーションしたり、漏洩したりする静的シークレットは存在しません。

Workload Identity Federationは、静的APIキーを、無期限ではなく数分で期限切れになるトークンに置き換えることで、セキュリティ体制を強化します。ただし、それ単体で完全なセキュリティ対策となるわけではありません。フェデレーション認証の強度は、JWTに署名する上流のIDプロバイダーの強度に依存します。多層防御のために、Workload Identity Federationを、IdPがすでにサポートしている制御（ワークロードIDバインディング、条件付きアクセス、監査ログ）と組み合わせてください。

概念

ワークロードがフェデレーションを行う前に、Claude Consoleで3つのリソースを設定します。これらを組み合わせることで、「発行者Xが署名し、クレームがYのように見えるトークンは、サービスアカウントZとして動作できる」ということを表現します。

サービスアカウント

service account（サービスアカウント、svac_...）は、Anthropic組織内の名前付きの非人間IDです。これは、サービスアカウントキーまたはフェデレーショントークンが代理として動作するプリンシパルです。サービスアカウントは組織レベルに存在し、ワークスペースのメンバーとして追加するとそのワークスペースでアクティブになります。交換時に、Anthropicはフェデレーションルールのワークスペースがサービスアカウントのワークスペースメンバーシップのいずれかと一致することを確認します。発行されたトークンは、APIキーと同様に、そのワークスペースのレート制限と使用量の帰属に従います。人間のユーザーとは異なり、サービスアカウントにはメールアドレスもパスワードもConsoleログインもありません。すべてのサービスアカウントは暗黙的に組織のデフォルトワークスペースのメンバーです。動作させたい他のワークスペースには明示的なメンバーシップを追加してください。全ワークスペース対象のサービスアカウントキーをあるワークスペースで動作させるには、そのワークスペースにサービスアカウントを追加します。

ワークスペースAPIキーとの主な違いは、ワークスペースAPIキーは認証情報そのものであるのに対し、サービスアカウントは認証情報を持つという点です。どのワークロードがどのサービスアカウントとして動作したかを、より簡単に監査できます。

フェデレーション発行者

federation issuer（フェデレーション発行者、fdis_...）は、OIDC IDプロバイダーを組織に登録します。発行者を登録することで、Anthropicに「このプロバイダーが署名したJWTは、私の組織のワークロードIDを主張できる」と伝えます。

発行者には2つの設定項目があります。

• 発行者URL： プロバイダーのJWTに現れる正確な iss クレーム値。例：https://token.actions.githubusercontent.com または https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLE。
• JWKSソース： AnthropicがJWT署名を検証するための公開鍵を取得する方法。発行者URLで /.well-known/openid-configuration を提供するプロバイダーには discovery（デフォルト）を使用します。JWKSエンドポイントを直接指定するには explicit_url を、パブリックインターネットから到達できない発行者（例：プライベートKubernetesクラスター）の鍵セットをアップロードするには inline を使用します。

発行者URLとJWKS URLは https で、ポート443を使用し、パブリックIPアドレスに解決されるパブリックDNSホスト名を使用する必要があります。IPリテラルは受け付けられません。これらの制約はAnthropicが取得するURLにのみ適用されます。explicit_url モードと inline モードでは、issuer_url は文字列として比較され、内部ホスト名を参照しても構いません。

通常、環境ごとに1つの発行者を登録します。本番EKSクラスター、ステージングクラスター、GitHub Actionsは3つの別々の発行者になります。

フェデレーションルール

federation rule（フェデレーションルール、fdrl_...）は、発行者とサービスアカウントの間の橋渡しです。「発行者XからのJWTのクレームがYのように見える場合、スコープSでサービスアカウントZのトークンを発行する」というものです。

ルールは、マッチ条件、ターゲット、およびルールがマッチしたときに適用される認可スコープとトークン有効期間を定義します。

• マッチ： 受信したJWTが満たすべき条件。subject_prefix（例：system:serviceaccount:prod:worker、または末尾に * を付けたプレフィックスマッチ）、正確な audience、正確なクレーム値のマップ、複雑なロジック用のCEL condition 式、またはそれらの任意の組み合わせでマッチできます。subject_prefix、claims、condition のうち少なくとも1つを設定する必要があり、JWTが受け入れられるには設定されたすべてのマッチャーを通過する必要があります。
• ターゲット： マッチしたJWTがマッピングされるサービスアカウント。
• 認可： 発行されたトークンに付与されるOAuth scope。デフォルトは workspace:developer で、ワークスペースAPIキーと同じアクセス権を付与します。一部の製品では、その製品のフローからルールを作成するとスコープが固定されます。例えば、MCPトンネルのトンネル作成モーダルは、workspace:manage_tunnels にスコープされたルールを作成します。OAuthスコープを参照してください。ルールは token_lifetime_seconds（60〜86400、デフォルト3600）も設定します。

1つの発行者に多数のルールを持たせることができます。チーム、名前空間、または権限レベルごとに1つずつです。ルールはIDで評価されます。クライアントは交換リクエストで使用するルールを指定し、AnthropicはJWTがそのルールのマッチ条件を満たすことを検証します。暗黙的なルール検索はありません。

仕組み

1. IdPがワークロードにJWTを発行します。 ほとんどのプラットフォームでは、これは環境から自動的に取得できます。Kubernetesのprojectedサービスアカウントトークン、Google Cloudメタデータサーバー、Azure IMDS、またはGitHub Actions OIDCエンドポイントなどです。JWTの iss クレームはプロバイダーを識別し、sub およびその他のクレームは特定のワークロードを識別します。
2. SDKがJWTをAnthropicアクセストークンと交換します。 SDKはRFC 7523の jwt-bearer グラントを使用して、JWTを POST /v1/oauth/token に送信します。Anthropicは発行者のJWKSとフェデレーションルールのマッチ条件に照らしてJWTを検証し、ルールのターゲットサービスアカウントの代理として動作する短命の sk-ant-oat01-... トークンを返します。
3. SDKはすべてのリクエストでトークンを送信し、期限切れ前に更新します。 アプリケーションコードは api_key なしでクライアントを構築し、通常どおりAPIを呼び出します。SDKはトークンの期限切れ前に交換を再実行します。

フェデレーションのセットアップ

Anthropic組織でadmin、owner、またはprimary ownerロールを持っていること、到達可能なJWKSエンドポイントを持つOIDC対応のIDプロバイダー（またはエアギャップクラスターの場合は貼り付け可能なJWKSドキュメント）、およびそのプロバイダーからIDトークンを取得できるワークロードが必要です。

Connect workload ウィザードは、3つのリソース（発行者、サービスアカウント、フェデレーションルール）すべてを1つのガイド付きフローで作成し、接続をエンドツーエンドで検証します。

1. 1

   Connect workloadを開く

   Claude Consoleで、Settings → Workload identity に移動し、Connect workload を選択します。

2. 2

   プロバイダーを選択する

   IDプロバイダーのタイルを選択します。GitHub Actions、AWS、Google Cloud、Microsoft Entra ID、またはKubernetesです。各タイルは、発行者URLパターンと、そのプロバイダーのJWTがサポートするマッチフィールドを事前入力します。その他の標準準拠プロバイダー（SPIFFEやOktaなど）の場合は、Custom OIDC を選択します。

3. 3

   ガイド付きフィールドに入力する

   ウィザードは、プロバイダー固有のフィールドを順に案内します。発行者の設定、受信JWTのマッチ条件、および作成するサービスアカウントとフェデレーションルールの名前です。ウィザードは oauth_scope=workspace:developer と token_lifetime_seconds=600 を事前入力します（token_lifetime_seconds を省略した場合のAPIデフォルトは3600です）。ワークロードが異なるスコープや有効期間を必要とする場合は調整してください。

4. 4

   発行者を検証する

   必要に応じて Verify issuer を選択し、何かが作成される前に発行者設定をドライランします。検証では、入力したURLからAnthropicがJWKSを取得して解析できることを確認するため、到達性や設定のミスを早期に発見できます。

5. 5

   接続をテストする

   ウィザードは発行者、サービスアカウント、フェデレーションルールを作成し、15分間トークン交換の成功を待ち受けます。その時間内にワークロードから交換をトリガーして（ワークロードからの認証を参照）、セットアップが機能することを確認します。時間が経過してもリソースは保持されます。フェデレーションルールの詳細ページからテストを再実行できます。ウィザードが作成するルールのID（fdrl_...）とサービスアカウントID（svac_...）を控えておいてください。ワークロードは、すべてのトークン交換リクエストで、組織ID（およびルールが複数のワークスペースを対象とする場合はワークスペースID）とともに両方を渡します。

これらのリソースをプログラムで管理するには、curlによる手順についてAdmin APIでWIFを管理するを参照するか、完全なパラメータの詳細とレスポンススキーマについてサービスアカウントAPIリファレンス、フェデレーション発行者APIリファレンス、フェデレーションルールAPIリファレンスを参照してください。

ワークロードからの認証

フェデレーションが設定されると、ワークロードは実行時にIdPが発行したJWTをAnthropicトークンと交換します。SDKが交換と更新のループを処理します。cURLタブは、シェルスクリプト、デバッグ、またはSDKサポートのない言語向けに、基盤となるHTTP交換を示しています。

SDKクライアントの構築

クライアントは、明示的な認証情報を指定して構築することも、引数なしで構築することもできます。引数なしの場合、SDKは認証情報の優先順位で説明されているように、環境変数またはアクティブなプロファイルから認証情報を解決します。引数なしの形式は、本番ワークロードに推奨されるパターンです。同じコンテナイメージをどこにでもデプロイし、環境ごとに ANTHROPIC_FEDERATION_RULE_ID、ANTHROPIC_ORGANIZATION_ID、ANTHROPIC_SERVICE_ACCOUNT_ID、ANTHROPIC_WORKSPACE_ID、ANTHROPIC_IDENTITY_TOKEN_FILE を注入します。

from anthropic import Anthropic, WorkloadIdentityCredentials, IdentityTokenFile

client = Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=IdentityTokenFile(
            "/var/run/secrets/anthropic.com/token"
        ),
        federation_rule_id="fdrl_...",
        organization_id="00000000-0000-0000-0000-000000000000",
        service_account_id="svac_...",
        workspace_id="wrkspc_...",
    ),
)

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

トークン交換レスポンスはRFC 6749 §5.1に従います。フィールドのリファレンスについてはトークン交換レスポンスを参照してください。

認証情報の優先順位

すべてのSDKは、同じ5段階の順序で認証情報を解決します。コンストラクタ引数、次に ANTHROPIC_API_KEY / ANTHROPIC_AUTH_TOKEN、次に明示的な ANTHROPIC_PROFILE、次にフェデレーション環境変数、最後に暗黙的なアクティブプロファイルです。最初に認証情報を返したソースが採用されます。

完全な優先順位表、各段階のセマンティクス、およびプロファイルファイルのスキーマについては、WIFリファレンスの認証情報の優先順位を参照してください。

APIキーからの移行

既存のワークロードを静的APIキーからフェデレーションにダウンタイムなしで切り替えるには、次の手順に従います。

1. フェデレーションを並行して設定します。 セットアップ手順を完了し、フェデレーションルールがワークロードのトークンにマッチすることを確認します。既存の ANTHROPIC_API_KEY は今のところそのままにしておきます。
2. どの認証情報が採用されるかをスモークテストします。 ワークロード内から ant auth status を実行します（またはSDKのデバッグログを確認します）。ANTHROPIC_API_KEY は優先順位チェーンでフェデレーションの段階より上位にあるため、この段階ではまだAPIキーが採用されます。
3. 注入されているすべての場所で ANTHROPIC_API_KEY を未設定にします。 CIシークレット、コンテナ環境、シェルプロファイルから削除します（前述の警告を参照）。ant auth status を再実行し、フェデレーションソースが選択されていることを確認します。
4. APIキーを削除します。 ワークロードがフェデレーショントークンで動作するようになったら、Claude Consoleの Settings → API keys でキーを削除します。

トークンの有効期間と更新

発行されるAnthropicトークンの有効期間は、(a) ルールの token_lifetime_seconds（デフォルト3,600秒）と (b) 提示したIdP JWTの残り有効期間の2倍のうち、短い方です。結果が60秒未満になることはありません。2番目の上限は、Anthropicトークンが派生元の上流IDよりもわずかな余裕を超えて長く存続することを防ぎます。

SDKはトークンをキャッシュし、botocore をモデルにした2段階のスケジュールで更新します。

• 推奨更新：期限切れの120秒前。SDKは新しい交換を試みます。トークンエンドポイントに到達できない場合、SDKはキャッシュされたトークンを引き続き使用します。このトークンはまだ約90秒間有効です。
• 必須更新：期限切れの30秒前。この時点で交換に失敗するとエラーが発生します。キャッシュされたトークンは期限切れに近すぎて安全ではありません。

SDKは交換のたびに ANTHROPIC_IDENTITY_TOKEN_FILE を再読み込みするため、ローテーションされたprojectedトークンを透過的に取得します（例えば、Kubernetesサービスアカウントトークンは exp よりかなり前にローテーションされます）。

デフォルトでは、jti クレームを持つIDトークンは1回限りの使用です。各交換では以前に交換されていないJWTを提示する必要があり、再提示すると認証履歴ページで理由 jti_reused として失敗します。ワークロードがIDプロバイダーから独自にトークンを取得する場合は、キャッシュされたものを再利用するのではなく、交換ごとに新しいJWTを発行してください（リトライループがよくある原因です）。ANTHROPIC_IDENTITY_TOKEN_FILE から読み込まれるトークンにも同じことが当てはまります。SDKは交換のたびにファイルを再読み込みするため、各更新の前にファイルに新しいトークンが格納されている必要があります。ローテーションされていないトークンを再読み込みする更新や、すでに交換したトークンを再提示する再起動されたプロセスは、同様に拒否されます。発行されたトークンの有効期間内に十分余裕をもってトークンをローテーションすれば、ファイルは更新スケジュールに先行し続けます。トークンソースがそれほど頻繁にローテーションできない場合は、最後の手段としてその発行者の check_jti を無効にできます（これにより、その発行者のすべてのルールでリプレイ保護が失われます）。詳細はJWT検証を参照してください。

IDプロバイダー

各ガイドでは、そのプラットフォームでJWTがどこから来るか、そのクレームがどのようなものか、および登録する発行者とルールの設定について説明します。

関連項目

• Admin APIでWIFを管理する：Infrastructure as Codeから発行者、サービスアカウント、ルールを作成する
• WIFリファレンス：環境変数、プロファイルファイルのスキーマ、検証ルール、エラーコード
• 認証：Anthropic SDK全体のすべての認証オプション
• Admin APIリファレンス：すべてのAdmin APIエンドポイントの生成されたリクエストおよびレスポンススキーマ