Claude Workload Identity Federation は「CI に API key を置きっぱなし」を終わらせる入口

要点

要点まとめ

Anthropic は 2026-05-04 の release note で Workload Identity Federation を GA とし、AWS IAM、Google Cloud、GitHub Actions、Kubernetes、SPIFFE、Microsoft Entra ID、Okta などの OIDC token から短命な Claude API token を発行できるようにした。
本質は認証方式の追加ではなく、`sk-ant-...` の静的 API key を CI、shared runner、cluster に配る前提を崩したことにある。
公式 docs では issuer と JWKS の登録、claim match 条件、service account への scope 付与、token lifetime の設定まで分けており、『誰の token なら何をしてよいか』を workload 単位で切れる。
ただし WIF だけで安全になるわけではなく、上流の IdP 設定や long-lived cloud credential が甘ければ、結局そこが弱点になる。

続けて読む

読み終えたら次へ

この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。

同じ目的で読む 仕事で安全に使いたい

権限、秘密情報、監査、失敗時の扱いを確認したい人向け。

同じテーマで読む LLM API

Responses API、Gemini API、モデル更新、構造化出力、SDK。

次の記事 Workload identity federation は「OpenAI API key を配る前提」を崩す

OpenAI は、CI や Kubernetes に長寿命 API key を置いて配る運用から離れるための案内を出している。

読解

何が変わったのか

この変更は『API key が要らなくなった』という一言で片づきません。release notes は 2026-05-04 付で WIF を generally available とし、短命 OIDC token で Claude API へ認証できると案内しています。関連 docs を読むと、issuer、JWKS、match 条件、service account、OAuth scope、token lifetime を別々に設定させるため、認証の中心が static secret 保管から実行時の身元検証へ移っています。しかも Anthropic docs は rule の target、`workspace:developer` scope、`token_lifetime_seconds`、issuer verification、exchange test まで分けています。つまり『keyless login』ではなく、『どの workload がどの権限を何分だけ持てるか』を workload 単位で切り分ける運用設計です。

日本の文脈

なぜ重要か

日本の開発現場では、PoC のまま API key を CI secret に置き続け、そのまま本番運用へ滑り込みやすいです。しかし agent 化や自動化が進むほど、鍵 1 本の漏えいで複数 repo、shared runner、cluster に横展開します。WIF は、その blast radius を workload 単位で切るための現実的な入口になります。ただし本当に見るべきは『API key を消せたか』ではありません。issuer、claim、service account、scope、token lifetime をどう切ったか、つまり信頼境界がどこへ移ったかです。そこを曖昧にしたままでは、長寿命 key の代わりに broad token mint 権を配るだけになります。

技術ポイント

技術的ポイント

WIF は workload が持つ OIDC JWT を `POST /v1/oauth/token` で Claude API 用の短命 token に交換する方式で、SDK は refresh を自動処理できる。
issuer は OIDC provider 単位で登録し、docs では GitHub Actions、AWS、Google Cloud、Microsoft Entra ID、Kubernetes などを個別に切る前提で説明している。
federation rule は match 条件で JWT を照合し、どの service account と scope を与えるかを決める。implicit rule search はない。
docs では `workspace:developer` scope と `token_lifetime_seconds` が初期値として示されるが、本番では workload ごとに最小化して読むべきだ。
Anthropic 自身も upstream IdP の強さに依存すると明記している。conditional access、audit logging、workload identity binding まで含めて考える必要がある。

用語

英日キーワード

英語	日本語	補足
workload identity federation	ワークロードIDフェデレーション	workload の身元を使って短命 token を発行する認証方式。静的 API key 配布を減らすために使う。
OIDC subject token	OIDCサブジェクトトークン	外部 identity provider が発行する JWT。OpenAI 側では workload 属性検証の入力になる。
issuer	発行者	その JWT を誰が発行したかを示す主体。broad issuer 設定は broad trust の別名になりやすい。
JWKS	JSON Web Key Set	JWT 検証に使う公開鍵集合。rotation 失敗はそのまま token exchange failure になる。
short-lived access token	短命アクセストークン	OpenAI API 呼び出しに使う有効期限の短い token。漏えい時の持続被害を減らす。
service account mapping	サービスアカウント対応付け	どの属性の workload がどの OpenAI service account を使えるか決める設定。粗い mapping は broad permission の別形になる。

試す

試すなら

Claude API key を置いている場所を洗い出し、CI、Kubernetes、cloud job のどこが WIF へ移しやすいか分類する。
environment ごとに issuer を分け、production と staging で同じ発行元や同じ rule を使わない。
claim match を broad にせず、subject や audience で workload を絞る。
token lifetime と scope を最小化し、交換ログを IdP 側と Anthropic 側の両方で追えるようにする。

注意

注意点

WIF は static secret を減らすが、上流の IdP 設定が甘ければ意味が薄い。
private issuer や private JWKS を使う構成では、到達性や issuer verification 条件を docs に沿って確認する必要がある。
local development や単純 script では API key の方が速い場面もある。本番 workload と同じ扱いで混ぜないほうが安全だ。

この記事は役に立ちましたか

公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。