Claude Media
Claude APIの認証方式まとめ — APIキー・WIF・App Attestの使い分け
AnthropicTips

Claude APIの認証方式まとめ — APIキー・WIF・App Attestの使い分け

Claude APIはAPIキー・Workload Identity Federation・App Attestの3方式で認証できます。それぞれの向き不向きと切り替えどきを解説します。

読了目安 約9分

Claude APIの認証方式は3つ、選び方は用途で決まる

Claude APIへのリクエストを認証する方法は、APIキー・Workload Identity Federation(WIF)・App Attestの3つです。どれもMessages APIなど同じエンドポイントを叩けますが、想定する運用が違います。APIキーはローカル開発・プロトタイピング・自分でシークレットを管理できるサーバー向け、WIFは本番ワークロードやCI/CDのように既にIdP(アイデンティティプロバイダー)発行のIDを持つ環境向け、App AttestはバックエンドなしでClaude APIを直接叩くiOS/macOSアプリ向けです。

APIキーとWIFはClaude APIエンドポイントへの権限としては同等です。まずAPIキーで素早く動かし、ワークロードがすでにプラットフォーム発行のIDを持っているならWIFへ移行する、という順序が現実的です。App Attestはこの2つとは前提が異なり、モバイルアプリの配布という特定シーンでのみ選択肢に入ります。

認証方式を選ぶタイミングは、多くの場合プロジェクトの初期構成を決める瞬間です。後から方式を変える場合、コード側の書き換えだけでなく、キーやトークンの管理体制そのものを作り直すことになるため、最初にどの方式が自分たちの運用に合うかを見極めておく価値があります。

使い分け早見表

認証方式資格情報の実体向いている場面
APIキー資格情報の実体sk-ant-api...の静的シークレット(Authorizationヘッダーで送信)向いている場面ローカル開発・スクリプト・自前でシークレット管理できるサーバー
Workload Identity Federation資格情報の実体IdPのIDトークンと交換する短命ベアラートークン向いている場面AWS/Google Cloud/AzureやKubernetes上の本番ワークロード、CI/CDパイプライン
App Attest資格情報の実体端末証明と引き換えに発行される短命トークン向いている場面バックエンドを持たずClaude APIを直接呼ぶiOS/macOSアプリ

APIキーは「誰が使うか」で3種類に分かれる

APIキーを作るとき、キーの種類を選びます。この選択がキーの権限・動作範囲・失効タイミングを決めます。

  • Personal key: 作成した本人として動作。個人開発や自分のスクリプト向け
  • Service account key: サービスアカウントとして動作。CI・本番サービスのような共有・自動化ワークロード向け
  • Workspace key(レガシー): 特定のワークスペースに紐づき、作成者が組織を離れても動き続ける。新規導入では非推奨

Personal keyとService account keyは「発行元の人・サービスアカウントが組織から外れると自動的に失効する」という共通の性質を持ちます。属人化したキーが放置される事故を防げるため、新規の統合ではWorkspace keyよりこちらを優先します。共有で使うキーを個人のPersonal keyにすると、その人が退職した瞬間に止まるので、複数人・自動化で使うキーは管理者にService account作成を依頼します。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello, Claude"}]
  }'

ワークスペースに紐づけていないキーでは、リクエストごとにanthropic-workspace-idヘッダーを送る必要があります(ワークスペース指定済みのキーなら省略できます)。ワークスペースIDのフォーマットが不正な場合は400エラー(invalid_request_error、メッセージは「anthropic-workspace-id header must be a valid workspace ID.」)になります。ワークスペースが存在しない場合やキーの所有者にアクセス権がない場合は404エラー(not_found_error)になります。

キーの有効期限をどう設定するか

キー作成時には有効期限も選びます。プリセットは3時間・1日・7日・30日で、カスタム期間や「無期限」も選べます(組織に上限ポリシーがある場合は選択肢が制限されます)。有効期限は作成後に変更できません。

無期限のキーはシークレットマネージャーで自分が確実にローテーションできる場合の選択肢で、それ以外は短い期限を選ぶほうが漏洩時の被害を限定できます。期限が近づくとキーの作成者へメール通知が届きます(有効期間14日以上のキーは7日前、7日以上のキーは1日前)。期限切れのキーは再有効化できず、新しいキーを作り直す必要があります。

Workload Identity Federationはどんな仕組みで長期キーを消すか

WIFは、AWS IAM・Google Cloud・GitHub Actions・Kubernetes・SPIFFE・Microsoft Entra ID・Oktaといった、標準準拠のOIDC発行者が出す短命のIDトークンを使います。ワークロードはそのIDトークンをPOST /v1/oauth/tokenでClaude APIの短命アクセストークンに交換し、SDKが期限切れ前に自動で更新します。発行・配布・ローテーションが要るsk-ant-api...文字列そのものが存在しません。

長期キーを環境から追放できる分、漏洩時の被害範囲は小さくなります。ただしIdPさえ守れば安全というわけではありません。信頼の連鎖はIdPの設定強度に依存し、たとえばIdPトークンを発行できる静的なクラウド認証情報が1つ上流に残っていれば、そこが弱点になります。IPアローリスト・MFA・監査ログといったIdP側の統制と組み合わせて使う設計です。設定はConsoleでサービスアカウント・連合発行者・連合ルールの3リソースを作るところから始まり、詳細な手順とエラー逆引きはWIFリファレンスにまとめています。

App Attestが向くのはモバイルアプリだけ

App Attestは、Claude APIを直接呼び出すiOS/macOSアプリのために用意された方式です。Appleの端末証明サービスでアプリの正当性を確認し、発行された短命トークンでワークスペースに課金されます。APIキーもWIFのIdPトークンも必要ないため、アプリの配布物に一切の秘密を含めずに済みます。

適用範囲は狭く、Claude APIへの直接呼び出しにしか使えません。Amazon Bedrock・Google Cloud・Microsoft Foundry経由でのアクセスや、Webサーバー・CLIツールのような非モバイル環境には使えません。仕組み・設定手順・失効方法の詳細はClaude App Attestの仕組みで扱っています。

選択でよくあるつまずき

共有スクリプトをPersonal keyで動かす。個人の開発機以外でPersonal keyを使うと、そのキーの所有者が退職・異動した瞬間にサービスが止まります。複数人や自動化で使うキーは、最初からService accountで作るのが安全です。

Workspace keyを作り続ける。レガシー扱いのWorkspace keyは今も新規作成できますが、誰の持ち物でもないため、退職時の自動失効が働きません。放置されたキーが漏洩に気づかれにくい温床になります。

WIFの信頼チェーンをIdP側だけで完結させたつもりになる。WIFは長期キーそのものを消しますが、IdPトークンを発行できる上流の認証情報が緩ければ、そこが新しい弱点になります。IPアローリストやMFAといったIdP側の統制とセットで設計する必要があります。

移行の順序 — どこから手を付けるか

Workspace keyを使っている場合、優先度が最も高いのはWIFか、ユーザーやサービスアカウントに紐づくキー(Personal/Service account、以下「本人紐づけキー」)への切り替えです。手順は次の通りです。

  1. 自分用ならPersonal key、共有・自動化ならService account keyを選ぶ
  2. 必要ならサービスアカウントを新規作成する(組織管理者への依頼が必要な場合あり)
  3. 統合先のワークスペース専用に新しいキーを作る
  4. ANTHROPIC_API_KEY環境変数やシークレットマネージャーのエントリを新しいキーに差し替える
  5. 動作確認後、旧Workspace keyをConsoleのAPI keysページで削除する

WIFへ完全移行できる基盤(既にIdPを持つクラウド環境)があるなら、本人紐づけキーを経由せず直接WIFへ進んでも構いません。判断基準は「その環境にすでにプラットフォーム発行のIDがあるか」の1点です。

3方式は併用できるか

1つの組織で複数の方式を同時に使うことは可能です。あるワークスペースはWIFで本番のクラウドワークロードを認証しつつ、別のワークスペースでは開発者がPersonal keyでスクリプトを動かす、という構成は珍しくありません。App Attestを使うモバイルアプリも、専用のワークスペースに課金先を分けておけば、利用量やコストの切り分けがしやすくなります。

方式ごとにワークスペースを分ける運用は、権限管理の面でも利点があります。APIキーの発行・失効・スコープはワークスペース単位で見えるため、モバイルアプリ用・CI用・個人開発用でワークスペースを分けておくと、どの方式がどこで使われているかを追跡しやすくなります。組織全体でどの方式を標準にするかを決めるより先に、まずワークスペースの切り方を決めておくと、後からの方式変更もしやすくなります。

まとめ

Claude APIの認証は、キーを自分で管理する前提のAPIキー、既存のIDを使い回すWIF、モバイルアプリ専用のApp Attestという性格の異なる3方式があります。開発初期はAPIキーで動かし、本番のクラウドワークロードはWIFへ、Claude APIを直接叩くモバイルアプリはApp Attestへ、という切り分けが実務上の出発点になります。Workspace keyを使い続けている場合は、本人紐づけキーかWIFへの移行を優先する価値があります。どの方式を選んでも、共通して効くのは「誰が・何が、どのくらいの期間このキーを持つか」を意識した設計です。個人・共有・自動化・端末という単位でキーの持ち主を明確にしておくほど、退職や漏洩といった想定外の事態への耐性が上がります。

この記事を共有:XはてブLinkedIn

関連する記事

Anthropic をもっと見る →