ANTHROPIC_API_KEY をもう Secrets に置かない —— Claude キーレス認証（Workload Identity Federation）を初心者がゼロから導入する完全ガイド

API キーを Git に push してしまった、.env に置いたまま忘れた、ローテーションが面倒で結局放置——この「静的 API キー問題」に、Anthropic 公式から正面突破の解答が出ました。キーレス認証（Workload Identity Federation, WIF）です。本記事は、OAuth も OIDC も初めてという方が、まずは自分のローカル PC から「API キーを 1 個も発行せず」に Claude を呼べるところまで、世界一丁寧に手取り足取り進めます。コマンド 5 つだけで完了する最短ハンズオン付き。所要時間は読んで実装まで約 20 分です。

user@sinyblog:~/article ❯ 01_source.mdこの記事の出典：Anthropic 公式ドキュメント

本記事は Anthropic の公式ドキュメント Workload Identity Federation^[1] および Use WIF with GitHub Actions^[2] を一次情報として、初心者向けに再構成したものです。仕様の細部や最新の挙動は公式ドキュメントを必ず参照してください。コマンド例や設定 JSON はすべて公式準拠で、コピペで動作します。

user@sinyblog:~/article ❯ 02_why_keys_scare_us.mdなぜ「API キー」はそんなに怖いのか

Claude API を使うとき、誰もが最初に発行するのが sk-ant-api03-xxxxx... という静的な API キーです。便利ですが、運用に乗せた瞬間に次のリスクを抱え込みます。

1. 有効期限がない。一度漏れたら、運営者が手で revoke するまで永遠に使われ続ける。
2. CI/CD のシークレットに置きっぱなし。GitHub Actions の Secrets、CircleCI の環境変数、社内の .env……どこに何件埋まっているか、もう誰も把握していない。
3. ローテーションが激痛。新キー発行 → 全環境で差し替え → 旧キー破棄、を四半期ごとにやる気力が湧かない。
4. 誤コミット事故が後を絶たない。.env を間違って push、Slack に値を貼ってしまう、退職者の手元に残る、など。

Anthropic の WIF ドキュメントは、この問題を端的に「長寿命の静的シークレットを、数分で失効する短命トークンに置き換える」と表現しています^[1]。

Workload Identity Federation strengthens your security posture by removing static credentials from Anthropic's surface and replacing them with tokens that expire in minutes rather than never.

Anthropic Docs — Workload Identity Federation / [1]

user@sinyblog:~/article ❯ 03_one_minute_summary.md結論：WIF を 1 分で理解する

細かい話に入る前に、まず結論を 1 行で。

WIF とは、「あなたが既に持っている ID プロバイダ（GitHub・AWS・GCP・Azure など）が発行した署名付きトークン」を、Anthropic に提示して、その場で短命の Claude API トークンに引き換える仕組み。

銀行の窓口に運転免許証を提示すると、その日 1 日だけ有効な番号札がもらえる——あのイメージに近いです。免許証（GitHub OIDC トークン）はあなたの環境に最初から発行されているもので、銀行（Anthropic）はそれを検証して短命な番号札（sk-ant-oat01-...）を返します。番号札はすぐ失効するので、漏れても被害は数分で止まる。これが WIF の本質です。

user@sinyblog:~/article ❯ 04_how_it_works.md仕組み図解：JWT が Anthropic トークンに化けるまで

WIF の動作は、たった 3 ステップに分解できます^[1]。

1. あなたの ID プロバイダが JWT を発行する。GitHub Actions なら ACTIONS_ID_TOKEN_REQUEST_URL 経由で、AWS なら EKS の Projected Token、Kubernetes なら ServiceAccount Token として、環境に最初から備わっている仕組みで取得できます。手動で何かを管理する必要はありません。
2. SDK がその JWT を Anthropic に持っていく。POST /v1/oauth/token エンドポイントに、JWT を assertion として渡します。Anthropic 側は事前に登録された JWKS（公開鍵セット）で署名を検証し、ルールに合致すれば sk-ant-oat01-... という短命アクセストークンを返します。プロトコルは RFC 7523 の jwt-bearer^[3]。OAuth 2.0 標準なので、各言語の SDK が自動でやってくれます。
3. SDK は短命トークンで API を呼び続ける。期限が切れる 120 秒前から自動で再交換し、API キーのときと同じ感覚で client.messages.create(...) が動きます。

つまり、あなたのコードは 1 行も変えなくていいのがポイントです。Anthropic() を引数なしで呼び出すだけで、SDK が環境変数を見て勝手に WIF モードに入ります。

user@sinyblog:~/article ❯ 05_three_resources.md登場人物 3 つだけ覚えれば OK

Claude Console で WIF を設定するときに登場するリソースは、たった 3 種類です。最初に頭に入れておくと迷子になりません。

user@sinyblog:~/article ❯ 06_local_handson.md最短ハンズオン：自分の PC で「鍵なし Claude」を 5 分で動かす

CI/CD やクラウドの話に進む前に、まず自分のローカル PC で「API キーを 1 個も発行せずに Claude を呼ぶ」体験から始めましょう。これが WIF の世界の入口で、登録 → ターミナルで 5 コマンド → Python 1 ファイルで完結します。

Step 1：Anthropic CLI（ant）をインストールする

Anthropic が公式提供している CLI ツールが ant です。これがブラウザ認証の入口になります。残念ながら pip install では入りません。OS ごとにインストール方法が異なるので、自分の環境に合うものを選んでください^[7]。

macOS の場合（Homebrew）

brew install anthropics/tap/ant

Linux / WSL の場合

VERSION=1.5.0
OS=$(uname -s | tr '[:upper:]' '[:lower:]')
ARCH=$(uname -m | sed -e 's/x86_64/amd64/' -e 's/aarch64/arm64/')
curl -fsSL "https://github.com/anthropics/anthropic-cli/releases/download/v${VERSION}/ant_${VERSION}_${OS}_${ARCH}.tar.gz" \
  | sudo tar -xz -C /usr/local/bin ant

Windows の場合（3 つの選択肢）

Windows には専用インストーラがまだ用意されていません（2026-05 時点）。下のいずれかを選びます。初心者には選択肢 A（WSL）が最もハマりにくいのでおすすめです。

1. 選択肢 A: WSL（Windows Subsystem for Linux）を使う — Windows 11 なら PowerShell で wsl --install を 1 回実行 → 再起動 → Ubuntu のターミナルが開く → 上の「Linux / WSL の場合」のコマンドを実行。以降のハンズオンも全部 Ubuntu 側で進める。
2. 選択肢 B: Go から入れる — すでに Go 1.22+ が入っているなら以下 1 行。$(go env GOPATH)/bin に ant.exe が置かれるので、そのフォルダを PATH に追加すること（cmd.exe で setx PATH "%PATH%;%USERPROFILE%\go\bin"）。
3. 選択肢 C: GitHub Releases から zip / exe を直接落とす — releases ページ で ant_1.5.0_windows_amd64.* のような Windows 用アセットをダウンロード → 展開 → ant.exe を任意のフォルダに置いて PATH に追加。

go install github.com/anthropics/anthropic-cli/cmd/ant@latest

インストール確認

どの方法でも、最後にこれが通れば成功です（バージョンが 1.5.0 以上であることも確認）。

ant --version

Step 2：ant auth login でブラウザ認証する

下のコマンドを叩くと、ブラウザが自動で開いて Anthropic の認証画面に飛びます。普段 Console にログインするのと同じ感覚で「Allow（許可）」をクリックすると、ターミナルに戻ってきます。これだけで認証情報がローカルプロフィールに保存されます。

ant auth login

このフローはAPI キーを 1 つも作りません。Anthropic アカウント自身が認証材料になります。.env ファイルにコピペする値も発行されません。

Step 3：認証ソースを確認する

ちゃんと認証できているか、SDK 側から見える形で確認します。

ant auth status

下のような出力が表示されたら成功です。

user@host:~$ ant auth status
Active profile:  default (from active_config file)
Config dir:      /home/<your-name>/.config/anthropic
Profile config:  /home/<your-name>/.config/anthropic/configs/default.json
Credentials:     /home/<your-name>/.config/anthropic/credentials/default.json

Credentials
  Logged in to <your-org> as you@example.com
  (active) * Profile (user_oauth) [via active_config]       sk-ant-oat01-XXX...
               expires:        2026-05-05T22:18:05+09:00 (in 8h0m0s)
               scope:          user:developer user:inference user:profile
               organization:   <your-org> (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
               client_id:      xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Base URL
  (active) * SDK default                                    https://api.anthropic.com

Organization
  (active) * Profile organization_id                        xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Workspace
  (active) * Workspace                                      wrkspc_xxxxxxxxxxxxxxxxxxxxx (Default)

初めて見ると情報量が多くて圧倒されますが、本当に注目すべき行はたった 4 つです。下の表で「どこを見れば成功と分かるか」を整理しておきましょう。

同時に、念のため ANTHROPIC_API_KEY 環境変数が残っていないことも確認しておきましょう（残っていると後述 ch10 の罠 1 を踏みます）。OS とシェルごとに確認方法が違うので、自分の環境のものを使ってください。

# 何も出力されなければ未設定（OK）。sk-ant-api03-... が出たら NG
echo "$ANTHROPIC_API_KEY"

REM "Environment variable ANTHROPIC_API_KEY not defined" と出れば OK
set ANTHROPIC_API_KEY

# 何も出力されなければ未設定（OK）
$env:ANTHROPIC_API_KEY

Step 4：Python の SDK をインストールする

pip install anthropic

Step 5：hello.py を書いて実行する

3 行で Claude を呼ぶスクリプトを作ります。API キーはコードのどこにも書きません。Anthropic() を引数なしで呼び出すと、SDK が Step 2 で保存したローカルプロフィールを自動で読みます^[5]。

import anthropic

# api_key 引数は渡さない。
# SDK が ant auth login で保存されたプロフィールを自動で読み、
# 短命トークンを取得して API を叩く。
client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "こんにちは Claude、自己紹介してください"}],
)
print(message.content[0].text)

python hello.py

たとえば次のような応答が返ってきます（claude-sonnet-4-6 モデルでの実行例）。

(env) C:\tmp\claude>python hello.py
こんにちは！私はClaudeです。Anthropicが開発したAIアシスタントです。

## 私にできること：

- **会話・相談** — 日常的な質問や悩み相談
- **文章作成** — メール、レポート、創作など
- **情報提供** — 様々なトピックについての説明
- **分析・要約** — 文章の整理や要点まとめ
- **プログラミング** — コードの作成やデバッグ
- **語学サポート** — 翻訳や文法の説明

## 特徴：
- 日本語でも自然に会話できます 🇯🇵
- 誠実で、わからないことは「わからない」と答えます
- 有害なことや危険なことはお断りします

---

何かお手伝いできることはありますか？気軽に話しかけてください！😊

Claude の応答がターミナルに流れてきたら、ハンズオン完了です。.env も os.environ["ANTHROPIC_API_KEY"] も書いていないのに、API が動いている——これがキーレス認証の最初の手触りです。

TypeError: "Could not resolve authentication method.
Expected one of api_key, auth_token, or credentials to be set."

user@sinyblog:~/article ❯ 07_github_actions.md応用編：CI/CD（GitHub Actions）から鍵を消す

ローカルが動いたら、次は CI/CD です。WIF が真価を発揮するのはここから。本セクションは「応用編」なので、最初の 1 周は「ふーんこんな感じで設定するんだ」と眺める程度で十分です。実際にチームで導入する段階で、本記事末の公式ガイド^[2]と合わせて読み込んでください。

GitHub Actions での設定は、3 つのパーツを組み合わせます。

1. Anthropic Console: ch05 で説明した 3 リソース（Issuer / Service Account / Federation Rule）を作成。Issuer URL は GitHub の固定値 https://token.actions.githubusercontent.com で、JWKS source は discovery（自動取得）。
2. GitHub workflow: permissions: id-token: write を有効化して OIDC トークンを取得。これが「明示的に許可された job にのみ」発行される仕組みで、書き忘れると一発で詰まります。
3. アプリコード: 変更なし。CI 側で 4 つの環境変数を渡すだけで、SDK が自動で WIF モードに入ります。

ワークフロー YAML の最小例（コピペで動く形）：

name: Call Claude (keyless)
on: push

permissions:
  id-token: write   # ← OIDC トークンの発行スイッチ。忘れると 403
  contents: read

jobs:
  call-claude:
    runs-on: ubuntu-latest
    env:
      ANTHROPIC_FEDERATION_RULE_ID: fdrl_...
      ANTHROPIC_ORGANIZATION_ID: 00000000-0000-0000-0000-000000000000
      ANTHROPIC_SERVICE_ACCOUNT_ID: svac_...
      ANTHROPIC_IDENTITY_TOKEN_FILE: /tmp/gha-jwt
    steps:
      - uses: actions/checkout@v5

      - name: Fetch GitHub 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: Run your script
        run: |
          pip install anthropic
          python hello.py   # ← ch06 のスクリプトをそのまま流用できる

そしてセキュリティの心臓部が Federation Rule の match ブロック。GitHub Actions の OIDC トークンには「どのリポジトリ・どのブランチで動いているジョブか」が sub クレームに刻まれている^[4]ので、これを使って「main ブランチへの push でしか認証できない」と縛ります。

{
  "name": "gha-main",
  "issuer_id": "fdis_...",
  "match": {
    "subject_prefix": "repo:your-org/your-repo:ref:refs/heads/main",
    "audience": "https://api.anthropic.com",
    "claims": {
      "repository_owner": "your-org"
    }
  },
  "target": {
    "type": "service_account",
    "service_account_id": "svac_..."
  },
  "workspace_id": "wrkspc_...",
  "oauth_scope": "workspace:developer",
  "token_lifetime_seconds": 600
}

user@sinyblog:~/article ❯ 08_migrate_safely.md既存ワークロードを「無停止で」移行する 4 ステップ

すでに API キーで動かしている本番ワークロードを切り替えるときは、並行運用 → 切り替え → 鍵削除の順で慎重に進めます。Anthropic 公式が推奨する手順です^[1]。

1. WIF を並行で構築する。Issuer・Service Account・Rule を作り、テスト Workflow で sk-ant-oat01-... がもらえることを確認。ANTHROPIC_API_KEY はまだ残しておく。
2. どちらが勝っているか確かめる。ant auth status を本番環境内で実行。資格情報の優先順位は API_KEY > PROFILE > FEDERATION なので、キーが残っている限り WIF は使われない。
3. あらゆる場所から ANTHROPIC_API_KEY を消す。GitHub Secrets、Docker 環境変数、shell プロファイル、CircleCI、Vercel、社内の .env……漏れなく。再度 ant auth status で WIF が選ばれていることを確認。
4. Anthropic Console で API キーを revoke。Settings → API keys から該当キーを削除。これで「鍵が世の中に存在しない」状態が完成。

user@sinyblog:~/article ❯ 09_token_lifecycle.mdトークンの寿命と自動リフレッシュ

「短命トークンで運用が回るのか？」という不安に、SDK は二段階リフレッシュで答えます^[1]。

さらに、Anthropic トークンの寿命は「rule で設定した値」と「上流 JWT の残り寿命の 2 倍」のうち短い方に揃えられます（最低 60 秒）。GitHub Actions の OIDC トークンは約 5 分しか持たないため、長時間ジョブでは Step を再実行して JWT ファイルを更新するなどの工夫が必要、という注釈が公式に明記されています^[2]。

user@sinyblog:~/article ❯ 10_three_pitfalls.md初心者がハマる 3 つの罠

公式ドキュメントを読んでも、最初の導入で詰まるポイントは決まっています。先回りで回避しましょう。

user@sinyblog:~/article ❯ 99_summary.mdまとめ

Workload Identity Federation は、これまで「個人開発者の頑張り」に押し付けられていた API キーの安全管理を、プラットフォーム側のプロトコルで終わらせる仕組みです。要点は 3 つ。

1. 静的な API キーは過去のもの。GitHub・AWS・GCP・Azure・Okta など、すでに使っている ID プロバイダの JWT がそのまま認証材料になる^[1]。
2. 初回設定は 15〜20 分、その後はゼロメンテナンス。Service Account / Federation Issuer / Federation Rule の 3 リソースを作るだけで、SDK が JWT 交換とリフレッシュを自動でやってくれる。
3. セキュリティの本丸は match ブロック。subject_prefix を「リポジトリ＋ブランチ」まで絞り、repository_owner を claim でも縛る。ここを緩くすれば WIF の安全性は API キー以下に落ちるので、最重要ポイントとして覚えておく。

「まず自分の PC で、API キーを 1 個も発行せずに Claude を呼んでみる」を最初のゴールに、ch06 の 5 コマンドから手を動かしてみてください。動いた瞬間に WIF の世界観が腑に落ちます。そこまでいけば、ch07 の CI/CD 連携や ch08 の本番移行は「同じ仕組みのスケール違い」でしかないので、自然に導入できるようになります。設定ファイルが Git に入って履歴に残るので、後から「いつ・誰が・どう変えたか」が追えるのも、API キー時代にはなかった大きな利点です。