AIアシスタントを本番環境で動かすとき、APIキーの管理が頭を悩ませる。
2026年5月4日、AnthropicはClaude PlatformにAPIキーを必要としない新しい認証方式「keyless auth」を追加した。CLIからブラウザでサインインする方法と、AWSやGCP・Azureのクラウド基盤がすでに持っているIDをそのまま使う方法の2種類が選べる。
この記事でわかること：
- keyless authで何が変わるか
- ブラウザ認証とクラウドIDフェデレーションの違い
- AWS・GCP・Azure・OIDCそれぞれの認証の仕組み
- 既存のAPIキー認証とどう使い分けるか
APIキーを持ち回ることの問題
Anthropic APIを使うには、従来はAPIキーを取得して環境変数 ANTHROPIC_API_KEY にセットする必要があった。個人開発ならこれで十分だが、チームやCI/CDパイプラインに組み込もうとすると問題が増える。
まずキーの配布が面倒だ。CIの設定ファイルに書くとセキュリティリスクになり、シークレット管理ツールを別途用意する必要がある。次にキーのローテーション問題がある。長期間同じキーを使い続けると漏洩リスクが高まり、定期的に更新するたびに各環境の設定を変えて回る手間がかかる。さらにCLIやGitHub Actionsなど複数の場所で動くワークロードが増えると、キーが分散して管理が追いつかなくなる。
Anthropicによると、APIキーの管理は顧客から寄せられるセキュリティ上の懸念として最上位に挙がるという。
keyless authで選べる2つの方法
1. ブラウザ経由のCLI認証
CLIを起動するとブラウザが開き、Anthropicアカウントでサインインするだけで認証が完了する。このフローはOAuth 2.0をベースにしており、トークンはローカルに安全に保存される（macOSではキーチェーン、Linuxでは ~/.claude/.credentials.json に600のパーミッションで格納）。
一度ログインすれば、トークンは自動更新されるため再サインインは不要だ。WSL2やSSHなどブラウザのコールバックが届かない環境でも、ターミナルにOAuthコードを貼り付けるフォールバック手順に対応している。
2. クラウドIDフェデレーション（ワークロード向け）
AWS・GCP（Vertex AI）・Azure（Foundry）・任意のOIDCプロバイダーのIDをそのままClaude Platformの認証に使える。各クラウドがすでに発行しているトークンを引き継ぐ形なので、AnthropicのAPIキーを別途生成・管理する必要がなくなる。
AWS Bedrock経由のOIDC認証では、GitHub ActionsのワークフローにIAMロールを割り当て、role-to-assume でAWSに認証してからClaudeを呼び出す。ワークフローに permissions: id-token: write を追加するだけでOIDC連携が有効になり、AnthropicのAPIキーをシークレットに保存する必要はなくなる。
Google Vertex AIでは、X.509証明書ベースのWorkload Identity Federation（mTLS ADC）に対応した。GCPのサービスアカウントにVertex AIの権限を付与し、そのクラウドIDでClaude Code Actionを動かせる。
Azure Foundryでも同様に、GitHub ActionsのOIDCトークンをAzureに渡してClaudeを認証する構成が組める。認証プロバイダーはAnthropicが規定する4つのクラウドに限らず、OIDCトークンを発行できるIDプロバイダーであれば接続できる。
なお、複数の認証方式が共存している場合はクラウドプロバイダーの認証が最優先になる。その後、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_API_KEY、OAuthの順で評価される。クラウド認証が有効なときはAPIキーが環境変数に残っていても無視されるため、移行時に注意が必要だ。
既存のAPIキー認証との違い
| 認証方式 | 用途 | キー管理 |
|---|---|---|
APIキー（ANTHROPIC_API_KEY） |
個人・小規模チーム | 手動でシークレット管理が必要 |
| ブラウザ認証（OAuthトークン） | 開発者個人のCLI利用 | 不要（ローカルに自動保存） |
| クラウドIDフェデレーション | CI/CD・ワークロード | 不要（クラウドが管理） |
APIキー認証はトークン単位の従量課金に紐付く。OAuthはサブスクリプション（Max・Proなど）に含まれ、クラウド認証はそれぞれのクラウドアカウント経由の請求になる。現在のセッションがどの認証方式を使っているかは、Claude Code内で /status を実行することで確認できる。Auth token の欄が CLAUDE_CODE_OAUTH_TOKEN であればブラウザ認証、ANTHROPIC_API_KEY であればAPIキーを使っていると判断できる。
APIキーの棚卸しに良いタイミング
keyless authの導入は、チームの認証構成を見直す機会でもある。GitHub ActionsやCI/CDバッチに貼り付けたAPIキーをクラウドIDに置き換えるだけで、キーのローテーション作業がなくなり、漏洩リスクも下がる。
まずは claude auth login でブラウザ認証を確認し、CI環境ではBedrock・Vertex・FoundryのOIDC連携に順次切り替えていくのが現実的な移行順序だ。