GitHubへの誤コミット、CIログへの混入、退職者のローカル環境に残ったまま忘れられた認証情報——静的なAPIキーが引き起こすセキュリティインシデントは、クラウド業界が長年抱えてきた問題だ。Anthropicはこの問題に対し、業界標準の解決策をClaude APIに直接組み込んだ。2026年5月4日に発表されたWIF（Workload Identity Federation）サポート[1]により、sk-ant-で始まる静的APIキーをCIパイプラインや本番環境に保存する必要がなくなった。AWS IAM、Google Cloud、Microsoft Azure、GitHub Actions、Kubernetes、OktaといったIdP（アイデンティティプロバイダー）からの認証情報をそのまま活用でき、認証の仕組みがエンタープライズグレードに刷新された。これまで静的キー管理が採用障壁だった金融・医療・官公庁といった業界でも、Claudeの導入検討が現実的になった形だ。

AD

APIキー漏洩という「消えない問題」が、なぜ静的キーである限り解決しないのか

GitGuardianの調査[2]によると、2025年だけでGitHubに新たに公開されたシークレットは2,869万件以上にのぼり、そのうち64%以上が2026年1月時点でも有効なまま放置されていたという。AI関連シークレットの漏洩は前年比81%増と急増しており、LLMサービスのAPIキーも例外ではない。Cloud Security Allianceが委託した調査（Aembit、2026年1月）では、調査対象組織の3分の1はAIエージェントの認証情報がどれくらいの頻度でローテーションされているか把握できていないと回答し、9%は「ほとんどしない、または全くしない」と答えた。

静的なAPIキーの構造的な欠陥は、保存する場所が増えるほど漏洩経路が増えることにある。ローカル環境の.envファイル、CIの環境変数、コンテナのシークレットマネージャー——どこかひとつに保存した瞬間から、そのキーは攻撃面になる。Git履歴から削除したつもりでも、フォークやキャッシュに残ることがある。キーを定期ローテーションする運用は理想論として語られながら、実際の組織では徹底されていないケースが多い。ClaudeDevsは発表で「APIキーの管理は、お客様からよく耳にするトップレベルのセキュリティ懸念の一つです」と述べており、今回の対応が機能追加ではなく、顧客が実際に直面してきた問題への設計変更であることがわかる。

ワークロード——GitHubのActionsジョブでも、KubernetesのPodでも——は自分がどこで動いているかをIdPに証明し、その証明書を別サービスのアクセストークンに交換する。「シークレットを発行して管理する」モデルから「アイデンティティを証明する」モデルへの転換が、WIFの核心だ。静的なシークレットは発行も保存もされないため、漏洩リスクがゼロになる。Google Cloudはすでに「サービスアカウントキーの使用停止」をセキュリティベストプラクティスとして公式推奨しており、GCP・AWS・Azureがこのアーキテクチャを採用してきた背景にあるのも同じ論理だ。

WIFの仕組み：JWTがAnthropicトークンになるまでの3ステップ

ステップ1 — IdPがJWTを発行する。 GitHub Actionsが動いているとき、GitHubのOIDC（OpenID Connect）エンドポイントはそのワークロードに対してJWT（JSON Web Token）を発行する。このJWTはワークロードの身元証明書として機能し、「どのリポジトリのどのブランチから実行されているか」という情報が含まれており、署名によって改ざんできない。AWSではSTSのWeb Identity Token、Google CloudではメタデータサーバーのIDトークンがこれに相当する実装差があるが、いずれもAnthropicはRFC 7523（JWT Bearer Token Grant）という共通プロトコルで検証するため、プロバイダーによる処理の違いをアプリケーションコードで意識する必要はない。「キーレス認証」という通称は「静的APIキーが不要」という意味であり、IdP側の認証情報管理が不要になるわけではない。

ステップ2 — SDKがトークンをAnthropicアクセストークンに交換する。 SDKはRFC 7523に従い、IdPから受け取ったJWTをPOST /v1/oauth/tokenエンドポイントに送る。Anthropicはフェデレーションルール（後述）に照らしてJWTの内容を検証し、短命のアクセストークンを返す。このトークンはsk-ant-で始まる静的キーとは異なり、分〜時間単位で期限が切れる使い捨ての認証情報だ。

ステップ3 — SDKがトークンを管理しながらリクエストを送信する。 交換されたアクセストークンはSDKが内部で保持し、各APIリクエストに自動で添付される。トークンのライフタイムはデフォルト3600秒（1時間）で、期限120秒前（Advisory refresh）にSDKがバックグラウンドでリフレッシュを開始し、期限30秒前（Mandatory refresh）には必ず更新を完了させる。有効期限はルール設定のtoken_lifetime_secondsとIdP側JWTの残存ライフタイムの2倍のうち短い方が採用される。アプリケーションコードはこの管理サイクルを意識する必要がない。

AD

設定の3要素：サービスアカウント・発行者・フェデレーションルール

サービスアカウント（svac_...） は、APIリクエストを実行する主体のアイデンティティだ。従来の「APIキーを持つユーザー」に相当するが、実在の人間ではなくCI/CDシステムやアプリケーションのための機械的なアカウントとして機能する。Claude Consoleから作成するとsvac_プレフィックスのIDが払い出される。

フェデレーション発行者（fdis_...） は、信頼するIdPを登録する設定だ。GitHub ActionsのOIDCエンドポイントURL、AWSのSTSエンドポイント、Google CloudのIdPなど、どのサービスのJWTを信頼するかをここで指定する。これにより、AnthropicがそのIdPの公開鍵で署名を検証できるようになる。

フェデレーションルール（fdrl_...） は、JWTの内容に基づいてアクセスを制御する条件式だ。「このリポジトリのこのブランチから実行されたときだけ許可する」「このKubernetes名前空間のサービスアカウントにだけ許可する」といった細粒度の制御が可能になる。ここでトークンライフタイム（token_lifetime_seconds）も設定する。

SDKクライアント側では、WorkloadIdentityCredentialsクラスとIdentityTokenFileの設定が必要になる。IdPが生成したJWTトークンをファイルに書き出し、そのパスをSDKに渡すことで、トークン取得とリフレッシュがSDKに委任される。この3要素が揃って初めて、アプリケーションコードからシークレットを完全に排除できる。

APIキーからWIFへの無停止移行：4ステップで完結する

ステップ1 — WIF設定を並行構成する。 既存のAPIキーを削除せず、新たにWIFの設定（サービスアカウント・発行者・ルール）を構成する。この段階ではAPIキーがそのまま動き続けるため、移行中のサービス断は発生しない。

ステップ2 — WIF認証をテストする。 ant auth statusコマンドでWIF経由の認証が正常に機能していることをスモークテストで確認する。動作を検証してから次のステップに進む。

ステップ3 — ANTHROPIC_API_KEYを削除する。 環境変数からANTHROPIC_API_KEYを削除する。公式ドキュメントに明記されている仕様として、この環境変数が設定されている状態ではAPIキーが優先され、WIFの設定がサイレントに無効化される。WIF設定が完了しているように見えて実際にはAPIキーで動き続けるという状況が、エラーメッセージなしに発生しうる。必ず実施すること。

ステップ4 — 旧APIキーを失効させる。 Anthropicの管理画面から旧APIキーを失効させ、移行を完了する。移行後は静的シークレットが存在しない状態になり、キーローテーション運用からも解放される。

今回のAnthropicの対応は、Claude APIが「APIキー付きのAIサービス」から「GCP・AWS・Azureと同等のゼロトラスト対応クラウドサービス」に昇格した転換点として読むことができる。CI/CDパイプラインへのLLM統合が一般化する中で、認証の扱いだけがレガシーなまま残っていた状況に、エンタープライズ標準のアーキテクチャが正式に持ち込まれた。GitHubのActionsやKubernetes上のPodからClaude APIを呼ぶ構成が、IAMポリシーとOIDCによってセキュアに管理できるようになったことで、金融・医療・官公庁といったセキュリティ要件の厳しい領域でのClaude API採用を阻んでいた障壁のひとつが取り除かれた形だ。