Claude Code・Codex・Devin──「APIキーを配らない」認証への移行が同時に進んでいる

AIコーディングエージェントを長時間動かすなら、ANTHROPIC_API_KEYやOPENAI_API_KEYのような「一度発行したら漏れるまで有効」な文字列を、CIの環境変数やコンテナイメージに置きっぱなしにするのが今までの標準だった。この方式には共通の弱点がある。キーが漏れれば、期限が来るまで（多くの場合は誰かが気づいて手動で失効させるまで）誰でもそのキーで使い放題になる。

2026年8月27日時点で公式ドキュメントを確認したところ、Anthropic（Claude Platform）とOpenAI（Codex）は、このAPIキーの代わりに自分の組織が既に持っているID基盤（AWS IAM、Google Cloud、Kubernetes、GitHub Actions、SPIFFE、Entra IDなど）が発行する短命トークンで認証する仕組みを、揃って公式機能として持っている。Cognition（Devin）も同じ「OIDCで長期キーを配らない」という方向性の機能を持っているが、こちらは向きが逆で、Devin自身が短命トークンを発行する側に回る。

• Anthropicは「Workload Identity Federation（WIF）」を、Claude PlatformのAPI認証手段として公式ドキュメント化している。ベータ表記は確認できなかった
• OpenAIはCodexに「workload identity federation」をベータ機能として実装済み。利用にはOpenAI担当者への申請とワークスペース単位の有効化が必要（Codex 0.148.0以降）
• Devinは「Cloud Authentication with OIDC」という名称で、DevinのセッションがAWS・GCP・Vault・JFrogなどの外部サービスに対して短命トークンで認証する機能を持つ。これはAnthropic・OpenAIの仕組みとは認証の向きが逆
• 3社が「同時に」「示し合わせて」動いたのか、業界の標準的な設計パターン（OIDC/JWT-bearer grant、RFC 7523）が広まった結果として似た機能に収斂しただけなのかは、公式発表からは判断できない

Anthropic：Claude APIに「静的キーなし」でアクセスする

Anthropicの公式ドキュメント（Claude Platform）は、Workload Identity Federation（WIF）を次のように説明している。

Workload Identity Federation (WIF) lets your workloads authenticate to the Claude API with short-lived OpenID Connect (OIDC) tokens instead of long-lived sk-ant-... API keys. The tokens come from an identity provider (IdP) you already operate: AWS IAM, Google Cloud, or any standards-compliant OIDC issuer such as GitHub Actions, Kubernetes, SPIFFE, Microsoft Entra ID, or Okta.

仕組みはこうだ。

1. 自社のIdP（AWS IAM、Kubernetesなど）が、ワークロードにJWT（署名付きトークン）を発行する
2. そのJWTをAnthropicに提示すると、Claude Console側で事前登録した「発行者（issuer）」「照合ルール（federation rule）」と突き合わせて検証し、組織内の「サービスアカウント」として動く短命のsk-ant-oat01-...トークンを返す
3. アプリ側のSDKは、このトークンを使ってAPIを呼び、期限が切れる前に自動で再交換する

発行されるトークンの寿命は「ルールで設定した秒数（デフォルト3,600秒）」と「元になったIdPトークンの残り寿命の2倍」のうち短い方で、必ず60秒以上とされている。公式ドキュメントはこの数値を次のように明記している。

The minted Anthropic token's lifetime is the lesser of (a) the rule's token_lifetime_seconds (default 3,600 seconds) and (b) twice the remaining lifetime of the IdP JWT you presented. The result is never less than 60 seconds.

つまり、元のIdPトークンより長生きするトークンは発行されない設計になっている。CI環境やKubernetesが元から自動ローテーションしているトークンを使えば、Claude API用のキーも自動的に生まれ変わり続ける、という理屈だ。

Claude Codeの認証ドキュメントでも、対応する資格情報の種類として「Anthropic profile and Workload Identity Federation credentials」が明記されている。つまりこれはClaude API単体の話ではなく、Claude Code自体も同じ仕組みで認証できる設計になっている。

OpenAI：Codexにも同じ仕組みがあるが、ベータで申請制

OpenAIのCodex公式ドキュメントにも、ほぼ同じ設計思想の機能が存在する。

Workload identity federation lets trusted automation use Codex without storing a personal access token or another long-lived OpenAI credential. Your workload presents a short-lived identity token from a provider you already operate. OpenAI verifies that token and returns a short-lived access token for a user or service account in your managed ChatGPT workspace.

対応するIdPも、Microsoft Azure、AWS、Google Cloud、Oracle Cloud Infrastructure、GitHub Actions、Kubernetes、SPIFFEと、Anthropicとほぼ重なる。ただし2つの違いがある。

1つ目は提供形態。 Codexのworkload identity federationは、公式に「ベータ」と明記されており、利用にはOpenAI担当者かサポートへの申請とワークスペース単位の有効化が必要と書かれている。

Codex workload identity federation is in beta and must be enabled for your workspace. To request access, contact your OpenAI representative or OpenAI Support.

Anthropic側の公式ページには、これに相当する「ベータ」「要申請」の表記は見当たらなかった（確認方法は後述の正直章を参照）。

2つ目はバージョン要件。 Codex側は「Codex 0.148.0以降」が必要と明記されている。古いバージョンのCodexでは使えない。

Devin：向きが逆──Devinが「トークンを発行する側」になる

Cognitionのドキュメントで見つかった「Cloud Authentication with OIDC」は、名前は似ているが仕組みの向きが逆だ。Anthropic・OpenAIの仕組みは「外部のIdPが発行したトークンで、AIベンダーのAPIに入る」向きだが、Devinのこの機能は「Devin自身がOIDC発行者（IdP）になり、AWSやGCPなど外部サービス側がそれを検証する」向きになっている。

Devin can authenticate to cloud services using OpenID Connect (OIDC) workload identity federation instead of long-lived credentials. Each Devin session receives a short-lived identity token issued by Devin, which your cloud provider verifies and exchanges for temporary credentials. No static API keys or secrets need to be stored in Devin.

具体的には、Devinのセッションが起動するたびに、Devin側の署名基盤が短命の「アイデンティティトークン」を自動発行する。このトークンにはorg_id（組織ID）、devin_id（セッションID）、requesting_user_email（起動したユーザー）といったクレーム（属性情報）が含まれ、AWSならIAMのAssumeRoleWithWebIdentity、GCPならWorkload Identity Federation、HashiCorp Vaultなら組み込みのJWT/OIDC認証方式といった、各サービス側が既に持っている「OIDCトークンを信頼して一時的な権限を渡す」仕組みで検証される。

公式ドキュメントは、Cognitionが用意したsetup-aws-oidcやsetup-gcp-oidcといった環境ブループリント用アクションを紹介しており、これをinitializeセクションに1行加えるだけでAWS・GCP側の認証を「静的キーなし」に切り替えられる、という設計になっている。

つまり3社を並べると、こういう構図になる。

AnthropicとOpenAIは「エージェントを呼び出す側」の認証を静的キーからOIDCに置き換える機能で、Devinは「エージェントが外に出ていく側」の認証を静的キーからOIDCに置き換える機能だ。どちらも同じ「長期キーを配らない」という設計思想を採用しているが、解決している問題は別物であることには注意が要る。

なぜ今、この方向にそろっているのか

公式ドキュメントが明示的に理由を書いているわけではないが、3社のドキュメントに共通して出てくる論点から、動機は読み取れる。

1つは、エージェントを長時間・無人で動かす運用が増えたこと。Codexのドキュメントは、この機能の想定用途を「unattended Codex processes in cloud platforms, Kubernetes, CI systems」（クラウド・Kubernetes・CIシステム上で人が張り付かずに動くCodexプロセス）と明記している。人が張り付いていない場所に静的キーを置くほど、漏洩のリスクは長期化する。

もう1つは、キーのローテーションという運用コストの問題。Anthropicのドキュメントは、WIFへの移行手順として「既存のAPIキーを残したまま並行稼働→どちらが優先されるか確認→APIキーを環境から削除→最後にキーを失効」という4段階の移行手順を明記している。これは裏を返せば、静的キーの管理・失効作業がそれだけ手間だったということでもある。

技術的な土台としては、3社ともOIDC（OpenID Connect）とJWT（署名付きトークン）を使っており、AnthropicのドキュメントはRFC 7523（JWT Bearer Grant）という業界標準の認可フローに準拠していると明記している。これはAnthropic・OpenAI・Devin固有の発明ではなく、クラウド業界で既に一般化している「静的な鍵より、短命の証明書を使う」という設計パターンを、AIエージェントの認証にも当てはめた形だ。GoogleのGoogle CloudやAWSも、GitHub ActionsからのOIDC連携を数年前からサポートしている。今回の3社の動きは、その延長線上にある。

個人開発者・小規模チームにとっての意味

この記事を読んでいる人の多くは、大規模なKubernetesクラスターやCIパイプラインを回しているわけではないだろう。個人や小規模チームにとって、この変化が今すぐ関係するかというと、答えは「ほぼ関係ない」に近い。

Workload Identity Federationは、社内に既にIAMやKubernetes、GitHub Actionsのような「トークンを発行できる基盤」があることが前提になる。個人開発者がclaudeコマンドをローカルのターミナルで叩くだけの使い方であれば、従来通りブラウザ経由のOAuthログイン（Claude.aiアカウントでの/login）で十分であり、AnthropicもClaude Codeの主要な認証手段としてこちらを案内し続けている。

関係が出てくるとしたら、次のような場面だ。

• GitHub Actionsで、Claude CodeやCodexを使った自動レビュー・自動修正のワークフローをCI上で常時稼働させている
• クライアントワークとして、企業のクラウド環境（AWS/GCP）上でエージェントを長時間運用する仕事を請け負っている
• チームでAPIキーを共有していて、誰が何に使ったか分からなくなっている

こうした状況にある場合は、静的なAPIキーをリポジトリのシークレットに置くのをやめ、OIDC連携に切り替える選択肢が「ある」ということだけでも知っておく価値がある。GitHub Actionsの場合、ジョブが実行されるたびにOIDCトークンが自動発行される仕組みが既にGitHub側に備わっているため、追加のインフラを作らなくても連携できる可能性が高い。

「示し合わせたか偶然か」は公式ドキュメントからは判定できない

• 「3社同時対応」が意図的な足並みなのか偶然なのかは分からない。 各社の公式ドキュメントには、他社の動きを意識した記述は見当たらなかった。OIDC/JWT-bearer grantという既存の業界標準に3社が独立に乗った、という解釈の方が妥当に見えるが、断定はできない。
• AnthropicのWIFが正式にGA（一般提供）なのか、実質的に大企業向けに限定運用されているのかは、ドキュメント本文からは断定できなかった。 ただしAPI Release Notes（curlで確認）を遡ると、2026年5月4日付の項目に「We've launched Workload Identity Federation」（Workload Identity Federationをローンチしました）という記載があり、"beta"や"preview"といった限定提供を示す語は付いていなかった。過去のリリースノート内の他の機能で"in beta"と明記されている例と比べると、少なくとも表記上はベータ扱いではなく正式ローンチとして案内されている。とはいえ、これは表現上の傍証であり、実際の提供範囲（全プランで使えるか、特定プラン限定か）を documentation 以外の方法（サポートへの問い合わせ等）で確認したわけではない。
• 日本語での実際の導入事例・利用データは確認できなかった。 本記事は3社の英語公式ドキュメントの記述のみに基づいている。日本企業でどれだけ使われているかについての一次情報は見つけられなかった。
• 料金への影響は確認できなかった。 WIFで発行されるトークンの利用が、通常のAPIキー利用と課金体系上で区別されるかどうかは、いずれの公式ドキュメントにも明記されていなかった。

あわせて読みたい

• Claude Codeがエラーで動かない時の切り分け手順──400・401・403は「認証の優先順位」を疑う
• 生成AIのセキュリティリスク──企業が押さえるべき6つの脅威と対策
• AIコーディング企業Cognition、10億ドル超を調達し評価額260億ドルに
• Claude Codeとは──コード生成に留まらない「仕事を渡せる」AIエージェント