Anthropic WIFがGA｜sk-antキーを葬る短命OIDCトークン認証の全貌

要点: (1) 2026年6月17日、Claude PlatformのWorkload Identity Federation（WIF）が一般提供開始、(2) sk-ant-で始まる長命キーの代わりに、AWS・GCP・Microsoft Entra ID・Kubernetes・GitHub Actions等の既存IdPが発行するOIDCトークンを短命Claudeトークンに交換する方式、(3) 「鍵を持たない」設計だがOIDC信頼ルールの検証不足は依然として人間の責任で残る

「GitHubのコミット履歴を遡ったら、過去のPRに sk-ant-api03-... が丸ごと残っていた」。AnthropicのWIFリリース発表後、開発者コミュニティでは似た体験談が散見された。AIブームで急ピッチに増えたCI/CDワークフローと、追いつかないシークレット管理。フリーランスの個人開発から大企業のSRE現場まで、似た悩みが横たわっていた。

Anthropicは2026年6月17日、その悩みに対する公式の回答を出した。Workload Identity Federation（以下、WIF）の一般提供開始だ（Anthropic公式ブログ）。sk-ant-で始まる静的APIキーを発行・保管・ローテーションする必要をなくし、ワークロード自身が持つOIDCトークンを短命のClaudeアクセストークンと交換する仕組みだ。なお、OIDC（OpenID Connect）はOAuth 2.0の上で動くID認証層、IdPは認証情報の発行元（Identity Provider）を指す。

これは「ようやくか」というニュアンスを含む。Anthropic自身、2026年3月にClaude Codeのソースコードがnpmのソースマップ経由で流出する事案を経験したと報じられている（当ブログ: Claude Codeソースコード流出の全貌）。社内外でクレデンシャル管理の課題が積み上がっていた。WIFのGAはその文脈で読むと意味が変わる。

なぜ静的APIキーは「設計負債」になったのか

sk-ant-...形式のAPIキーは長らく便利だった。1本のキーを.envに置けば、ローカルでもCIでも本番でも動く。問題は、便利すぎたことだ。

GitGuardianの公開レポートでは、AnthropicのAPIキーがパブリックリポジトリで日常的に検出され続けている（GitGuardian, Remediating Claude API Key leaks）。同社のドキュメントには「漏洩を発見したら即時失効・ローテーション・利用ログの監査」の3点セットが手順として並ぶ。それ自体は正しいが、「漏れる前提」で設計せざるを得ないところに、すでに静的キーの限界が見える。

実害も報じられている。Cyber Security Newsの報道によれば、Microsoft Threat IntelligenceはAnthropicのClaude Code GitHub Actionに対し、AIエージェントがリポジトリ内の環境ファイルを誤って読み出し、CI/CDのシークレットが外部に渡るリスクを指摘した（Cyber Security News）。原因は単純なバグではなく、「コードを書くAIエージェントに、コードと一緒にシークレットも見せている」という構造的な問題だ。

Anthropicが今年経験した出来事を並べると問題はより鮮明になる。3月にClaude Mythos関連の情報の一部が外部から閲覧可能になり（当ブログ: Claude Mythosリーク事件の解説）、その数日後にClaude CodeのTypeScriptソースが.mapファイルで流出した。両件とも顧客のAPIキー漏洩には至らなかったと報じられているが、「設定ミス1回で広範な情報が世に出る」モデルの脆さは内外に示された。

長命キーを発行する限り、漏洩は時間の問題でしかない。そこからの脱出口がWIFだ。

WIFの基本：OIDCトークンをClaudeトークンに交換する仕組み

WIFは何を変えるのか。一言で言えば、「sk-ant-を一度も生成せず、Claude APIを呼べるようにする」仕組みだ。Anthropic公式ドキュメントの定義はこうだ。WIFは、ワークロードが持つOIDC（OpenID Connect）トークンを短命のClaude APIアクセストークンと交換し、SDKがその期限切れを自動でリフレッシュする（Workload Identity Federation - Claude API Docs）。

仕組みを4ステップに分解できる。

1. ワークロードがIdPからOIDCトークン（JWT）を取得: AWS Lambda/ECS/EKSなら AssumeRoleWithWebIdentity 系の経路やEKS IRSAのprojected token、GCPならインスタンスメタデータサーバーがGoogle署名JWT、GitHub Actionsならid-token: write権限を持つジョブがACTIONS_ID_TOKEN_REQUEST_URL経由でJWTを取得する。JWTはJSON Web Tokenの略で、電子署名付きの自己完結型トークン。
2. AnthropicにPOST /v1/oauth/token: 取得したJWTを grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer（RFC 7523）で送信する。リクエストには federation_rule_id / organization_id / service_account_id を明示する。Anthropic側はConsoleで設定された「信頼ルール（federation rule）」と照合する。
3. Claude側がトークンを発行: 信頼ルールにマッチすれば、Anthropic組織内のサービスアカウントに紐づく短命アクセストークンが返ってくる。デフォルトは1時間程度で、設定により数分から最大24時間（86,400秒）の範囲で調整できる。
4. SDKがトークンを保持・自動更新: 期限が切れる前にSDKが裏で交換を繰り返す。アプリケーションコードはトークンの存在を意識しない。

設定対象は3つだ。Claude Consoleで「サービスアカウント」「フェデレーション発行者（issuer）」「フェデレーションルール」を作る。発行者には対象IdPのissuer URLとJWKS（IdPの公開鍵セット。Anthropic側がJWT署名検証に使う）の取得方法を、ルールにはJWTのclaim条件（sub、aud、repositoryなど）を指定する。SDKにはルールIDを渡せばよい。sk-ant-は一度も登場しない。

対応IdPと現実的なユースケース

WIFが想定するIdPは、すでに開発現場で使われているものばかりだ。

プロバイダ	主なユースケース	取得経路
AWS IAM	Lambda・EC2・ECS・EKSからの呼び出し	STSのweb identityトークンまたはEKS IRSA projected token
GCP	Cloud Run・Cloud Functions・GCE・GKE	インスタンスメタデータサーバー
Microsoft Entra ID	Azure App Service・Functions・AKS	Entra managed identity
Kubernetes	任意のクラウドのPod	Projected service account token
GitHub Actions	CI/CDのジョブ	id-token: write 権限
Okta	社員SSO経由のサーバーサイドジョブ	OIDC ID Token
SPIFFE	ゼロトラスト基盤上のサービス	SVID（SPIFFE Verifiable Identity Document）

特にGitHub Actionsとの組み合わせは効果が大きいケースが多い。従来は secrets.ANTHROPIC_API_KEY をリポジトリかOrgレベルに保存し、定期ローテーションが必要だった。WIFを使えばワークフローにシークレットを置く必要がない。代わりに permissions: id-token: write を付け、ワークフローからOIDCトークンを取得して環境変数で渡せば認証が完結する（Use WIF with GitHub Actions - Claude API Docs）。

以下は説明用の擬似コードである。最新のinput名や手順は必ず公式ドキュメントを確認すること。

permissions:
  contents: read
  id-token: write
jobs:
  claude-job:
    runs-on: ubuntu-latest
    env:
      ANTHROPIC_ORGANIZATION_ID: ${{ vars.ANTHROPIC_ORG_ID }}
      ANTHROPIC_FEDERATION_RULE_ID: ${{ vars.ANTHROPIC_FED_RULE_ID }}
      ANTHROPIC_SERVICE_ACCOUNT_ID: ${{ vars.ANTHROPIC_SA_ID }}
      ANTHROPIC_IDENTITY_TOKEN_FILE: /tmp/anthropic-oidc.jwt
    steps:
      - name: Get OIDC token
        run: |
          curl -sS -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
            "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=https://api.anthropic.com" \
            | jq -r .value > "$ANTHROPIC_IDENTITY_TOKEN_FILE"
      - name: Call Claude
        run: python ./scripts/run_claude.py

secrets. が消えた。vars. はリポジトリ可視性に従う設定値で、フェデレーションルールID自体が漏れても、Anthropic側のルールが信頼するclaim条件を満たさない限りトークン交換は通らない。これが「鍵を持たない」設計のコアになる。

AWSユーザーの場合も近い。LambdaにIAM Roleを割り当てておけば、関数コード内では AssumeRoleWithWebIdentity 経路で取得したJWTをAnthropicのSDKがClaudeトークンに交換する。エンジニアが触るコードに認証情報は出てこない。

Aembitが指摘した「WIFが解決しないもの」

WIFは万能ではない。サイバーセキュリティ企業Aembitは、リリース直後に評価と課題を整理した分析を公開した（Aembit, 2026年6月）。要点を3つに整理する。

第一に、WIFは認証の「鍵」を消すが、認可の「ポリシー」までは解決しない。フェデレーションルールに書かれた条件（どのIdP、どのリポジトリ、どのclaimまで信頼するか）を組織が正しく設計しないと、攻撃者がCI上のpull requestを介して任意のコードを動かし、AIエージェントの権限を奪うシナリオは依然として残る。

第二に、トラスト境界の管理は誰の仕事かが曖昧になりやすい。IdP側の信頼設計は組織のIT・セキュリティチーム、ルール設計はアプリ開発チームに分かれることが多い。両者の橋渡しが甘いと、sub:*のようなワイルドカードルールが残り、形だけのWIFになる。

第三に、AIエージェントが認証情報を読み出してしまう問題自体は別レイヤーだ。LLMエージェントがコンテキスト中の認証情報を出力に混ぜ込むリスクは、認証方式を変えても完全には消えない。Anthropic自身が今年学んだのはこのレイヤーだ。

それでも、AembitもRiptidesも全体としてはWIFの方向性を歓迎する論調だ（Riptides, 2026年）。理由は単純で、漏れたら世界中で使える長命キーと、漏れても数分から数十分で失効する短命トークンとでは、事故時の影響範囲の桁が違うからだ。

電脳狐影ならこう動く

PMとしてClaude APIを業務で使う立場から、自分ならこう動く。

まず、新規プロジェクトはCI/CDの認証を初日からWIFで組む。secrets.ANTHROPIC_API_KEYを一度作ってしまうと、PRレビューやログ流出の不安が続く。最初から「シークレットを設けない」設計にしておけば、検討すべきリスクが一段階減る。

既存プロジェクトは「鍵が漏れたら最も困る順」に移行する。本番のサーバーレス、CIの自動生成ジョブ、公開リポジトリで動かしているサンプルの順だ。ローカル開発用のキーは無理に消さず、短いTTLでの定期ローテーションで運用する。全部を一気にWIF化しようとして手を止めるよりは、効く所から潰す方が現実的だ。

そして、フェデレーションルールは「PMが読んで意味がわかる」粒度で書く。「このGitHub Orgの、このリポジトリの、mainブランチで、releaseジョブが、このサービスアカウントとして話せる」という具体性まで落とす。曖昧な書き方を許すと、WIFのメリットは半減する。PMの仕事として、ルールのレビューはエンジニアに丸投げしない方がよいと感じる。

関連記事

• Claude Codeソースコード流出の全貌｜npm経由で51万行が丸見えになった日
• Claude MCPコネクタがOkta一元管理に対応｜EMA正式安定化でゼロタッチSSO実現
• Claude Codeセキュリティ告知の解説
• Anthropic完全ガイド2026

---

本記事の情報は2026年6月21日時点のものを基準とする。WIFの対応IdP・対応SDK・契約条件は今後変更される場合がある。最新情報はAnthropic公式ドキュメント（Workload Identity Federation）と各IdPの公式情報を参照のこと。掲載コード例は説明用の擬似例であり、実運用前に公式ドキュメントの最新版で検証すること。