📖 この記事で分かること
– Claude APIに「ワークロードID連携」が登場
– AWSやGoogle CloudのIdPで直接認証可能に
– 短期トークンで静的APIキーの漏洩リスクを縮小
– 既存ワークロードの段階的な移行が可能
💡 知っておきたい用語
– ワークロードID連携：長期間使える鍵を配るのではなく、その場で発行される短時間有効な「社員証」で認証する仕組み。CIや本番ワークロードからの認証に使う
最終更新日: 2026年5月6日
Anthropicが「Workload Identity Federation」を公式提供
AnthropicがClaude APIの新しい認証方式として、ワークロードID連携（Workload Identity Federation、以下WIF）を公式ドキュメントで案内しています。長期間有効な静的APIキー（sk-ant-…）の代わりに、利用者がすでに運用しているID基盤【アイディーきばん】が発行する短期トークンで、Claude APIに認証できる仕組みです。
対応する発行元（IdP【アイディーピー】）は幅広く、標準的なOpenID Connect【オープンアイディーコネクト】対応プロバイダが含まれます。
AWS IAM
Google Cloud
Microsoft Entra ID
GitHub Actions
Kubernetes【クバネティス】サービスアカウント
SPIFFE
Okta
CI/CDやコンテナ基盤でClaude APIを呼び出す際、専用のAPIキーを発行・配布せずに、すでに運用しているクラウド側のID基盤をそのまま流用できる点が特徴です。
短期トークンとサービスアカウントで認証する仕組み
中心となるのは、ワークロードのJWT【ジェイダブリュティー】（署名付きトークン）を、AnthropicのトークンエンドポイントでClaudeのアクセストークンに交換するという流れです。
公式ドキュメントによれば、手順は次のとおりです。
ワークロードが、所属するIdPからJWTを取得する（Kubernetesの投影トークン、Google Cloudのメタデータサーバ、GitHub ActionsのOIDCエンドポイントなどから自動取得可能）
AnthropicのSDKが、そのJWTを POST /v1/oauth/token に送信し、RFC 7523の jwt-bearer 方式でトークン交換する
Anthropicが署名と各種クレーム（iss exp など）を検証し、sk-ant-oat01-… で始まる短期アクセストークンを返す
SDKがそのトークンをキャッシュし、有効期限の前に自動でリフレッシュする
短期トークンの寿命は、ルールに設定した token_lifetime_seconds（60〜86400秒、既定3600秒）と、元のJWTの残寿命の2倍のうち、短いほうが採用されます。最低でも60秒は確保される設計です。
設定にあたっては、Claude Console上で以下の3つのリソースを作成します。
サービスアカウント（svac_…）：トークンが演じる「人ではないID」
フェデレーション発行元（fdis_…）：信頼するIdPの登録
フェデレーションルール（fdrl_…）：「このIdPの、この条件を満たすJWTは、このサービスアカウントとして振る舞ってよい」という対応規則
ルールのマッチ条件には、subject_prefix、audience、特定クレームの完全一致、CEL【シーイーエル】式による複雑な条件などを組み合わせられます。
静的APIキーの「置き場所」を消す効果と限界
このアーキテクチャの狙いは、Anthropic側に保管が必要な長期シークレットを実質的に消し去る点にあります。
公式ドキュメントは、WIFが静的なクレデンシャルをAnthropicの境界面から取り除き、数分で失効するトークンに置き換えることでセキュリティ姿勢を強化すると説明しています。CIシークレットや環境変数に長期APIキーを置く必要がないため、漏洩時の影響範囲（ブラスト半径）を小さくできるという考え方です。
ただし、Anthropicは同時に「これだけで万全ではない」と明記しています。理由は、フェデレーション認証の強度が結局は上流のIdPの強度に依存するためです。たとえばIdPがJWTを発行するために長期シークレットを使っていれば、そこを突かれた時点で連鎖的に影響を受ける可能性があります。
そのため、IdP側の制御と組み合わせた多層防御が前提となります。具体的には次のような既存統制が想定されています。
ワークロードIDのバインディング（特定ノードやPodへの紐付け）
条件付きアクセスポリシー
監査ログ
IPアロウリストやMFA【エムエフエー】
APIキーからの移行で注意すべき優先順位の罠
WIFは既存のAPIキーと共存できますが、移行時に「APIキーがフェデレーションを上書きしてしまう」という落とし穴があります。
各SDKは認証情報を5段階の優先順位で解決しますが、ANTHROPIC_API_KEY がフェデレーション系の環境変数より上位に位置します。コンテナや既存のシェルプロファイル、CIシークレットに古いAPIキーが残っていると、それが優先され、WIF設定が無視されてしまうという設計です。
公式ドキュメントは、無停止移行の手順として次のステップを案内しています。
WIFを並行構成し、ルールがワークロードのトークンと一致することを確認する
CLIの ant auth status で、現時点でどのクレデンシャルが選ばれているかを検証する
CI、コンテナ環境、シェル等から ANTHROPIC_API_KEY をすべて削除する
再度 ant auth status でWIF経由になっていることを確認する
旧APIキーをClaude Console上で失効させる
WIFの導入は、設定そのものよりも「過去のキーが本当にどこにも残っていないか」という運用面の徹底が肝となります。
よくある質問
Q: 既存のAPIキー方式は廃止されますか？
A: 公式ドキュメントに廃止の記載はなく、APIキーとWIFは併存可能です。ただし優先順位の関係でAPIキーが残っていると無自覚にそちらが使われるため、移行時は環境からの削除が必要です。
Q: オンプレミスのKubernetesでも使えますか？
A: 使用可能と説明されています。インターネットからJWKSエンドポイントに到達できない環境向けに、JWKS鍵を直接アップロードする「inline」方式が用意されています。
Q: 利用に追加料金はかかりますか？
A: 公式ドキュメント上で料金に関する明示的な記載は確認できませんでした。最新の条件はAnthropicの公式ページで確認することをおすすめします。
まとめ
Workload Identity Federationの公式提供により、Claude APIの認証は「長期APIキーを配って回す」モデルから、「すでにあるIdPに任せて短期トークンを都度発行する」モデルへ拡張されました。AWS、Google Cloud、Kubernetes、GitHub Actionsなど主要なクラウド・CI環境を網羅しているため、本番ワークロードのシークレット管理を再設計したい組織にとって、有力な選択肢になりそうです。
一方で、認証強度はあくまで上流IdPの設定次第であることを、Anthropic自身が強調しています。SDKが自動でトークン更新を担う一方、IdP側の権限設計や監査が甘ければ、WIFの利点は減ります。導入時はIdPの統制状況とセットで設計するのが現実的でしょう。
【用語解説】
OIDC【オープンアイディーコネクト】: OAuth 2.0をベースにしたID認証の標準仕様。「自分は誰か」を証明する署名付きトークン（JWT）の発行・検証ルールを定めている
JWT【ジェイダブリュティー】: JSON Web Tokenの略。発行元の電子署名が付いたトークンで、改ざんがないことを確認できるため認証情報のやりとりに使われる
サービスアカウント: 人間ではなく、プログラムやワークロード専用のアカウント。WIFでは、トークンが「演じる」対象として機能する
フェデレーションルール: 「このIdPの、この条件のJWTを受け取ったら、このサービスアカウントとして扱う」という対応規則。Claude Consoleで定義する
免責事項: 本記事の情報は執筆時点のものです。AI技術および各種仕様は急速に進歩しているため、機能や制限、提供条件は予告なく変更される場合があります。最新情報は公式ドキュメントをご確認ください。
引用元:
関連