Claude APIキーとID連携の使い分け｜選ぶ基準
Claude APIキーを作ろうとClaude Consoleを開いたら、「ID連携を使用すれば、APIキーは不要です」という画面が出た。APIキーなら分かるけれど、ID連携とは何で、自分はどちらを選べばいいのか——そこで手が止まった方は多いはずです。
結論から言うと、自分のパソコンで動かすならAPIキーです。AWSやGoogle Cloud、GitHub Actionsのように「動いている処理に身分証を渡してくれる場所」で動かすなら、ID連携を使えます。迷ったらAPIキーで始めて、あとからID連携に移ることもできます。
株式会社Fyveは、中小企業のAI活用を支援しながら、自社の業務もClaudeで回している会社です。この記事では、2026年11月11日に私が自社のアプリ用にAPIキーを作ろうとして、実際にこの画面を見た経緯を書きます。続けて、画面の内容と、公式ドキュメントで確かめた両者の違い、私がAPIキーを選んだ理由を順に書きます。
Claude APIキーを作ろうとして出た「ID連携」の画面
私は自社で、Xの「いいね」を整理するアプリ（開発中の名前はx-likes）を作っています。いいねしたポストをAIに読ませて分類させる仕組みで、AIの判定にはこれまでCloudflareのWorkers AIを使っていました。
ところが試験中に、Workers AIの無料枠（1日10,000ニューロン）を使い切って止まりました。そこで判定をClaudeのAPIに切り替えることにして、Claude ConsoleでAPIキーを作ろうとしたところ、次の画面が出ました。
画面に書かれていた内容は次のとおりです。
- 見出し：「ID連携を使用すれば、APIキーは不要です」
- 本文：クラウドまたはCIプロバイダーが、リクエストを認証する有効期間の短いトークンを発行するため、静的なキーを管理する必要はありません
- 環境変数・設定ファイル・シークレットマネージャーに保存する必要はない
- トークンは自動的にローテーションされ、数分で有効期限が切れる
- GCP、AWS、Azure、GitHub Actionsに対応している
- 注記：ローカルスクリプト、サードパーティ製ツール、IDプロバイダーのない環境では、引き続きAPIキーが必要な場合がある
- ボタン：「IDフェデレーションを設定」と「APIキーで続ける」
つまりこの画面は、「APIキーを作る前に、キーを持たずに済む方法があるけれど、使える場所が決まっています」と案内しています。次の章から、その「ID連携」とは何かを公式ドキュメントで確かめた内容で説明します。
APIキーとID連携の違い｜公式ドキュメントの整理
Claude APIの認証の方法は、公式ドキュメント（Authentication）に3つ載っています。2026年11月11日時点の内容で、表にすると次のとおりです。
方法 | 認証に使うもの | 向いている場面（公式の記述） |
|---|---|---|
APIキー | Consoleで作る、sk-ant-api…で始まる固定の文字列 | 手元の開発、試作、スクリプト、秘密の保管場所を自分で管理できるサーバー |
ID連携（Workload Identity Federation） | 連携元（IDプロバイダー）が発行するIDトークンを引き換えた、有効期限の短いトークン | AWS・Google Cloud・Azure上の本番処理、CI/CD、Kubernetesなど、固定の秘密を持たずに済ませたい場所 |
App Attest | 登録済みのiOS・macOSアプリが本物だと確認されたときに出る、有効期限の短いトークン | 利用者に配るiOS・macOSアプリが、サーバーを挟まずにClaude APIを直接呼ぶ場合 |
この記事で比べるのは、上の2行です。App Attestは、自分が作ったiPhone・Macのアプリを人に配って、そのアプリから直接Claudeを呼ぶ場合の方法なので、ここでは触れません。
公式ドキュメントには、2つの関係を次のように書いています。
- APIキーとID連携は、Claude APIのエンドポイントに対して同じ権限を与える
- すぐ始めたいならAPIキーを選ぶ。自分の開発なら個人のキー、共有するものならサービスアカウントのキーにする
- 動かす処理がすでに「プラットフォームから発行された身分」を持っていて、それを連携に使えるなら、ID連携に移る
ここがいちばん大事な点です。ID連携は、APIキーより高機能なAPIの使い方ではありません。できることは同じで、違うのは「Claudeに自分を証明するために、何を持っていくか」です。
APIキーとは｜Consoleで作る固定の文字列
APIキーは、Claude Consoleの「APIキー」ページ（platform.claude.com/settings/keys）から「Create key」で作る、sk-ant-api…で始まる文字列です。リクエストのたびにこの文字列を送ることで、「このリクエストは自分のものだ」とClaudeに伝えます。公式SDKを使う場合は、環境変数のANTHROPIC_API_KEYに設定しておけば自動で読み込まれます。
キーの種類は3つある
作るときに種類を選びます。公式の整理は次のとおりです。
種類 | 誰として動くか | 向いている使い方 |
|---|---|---|
個人キー（Personal key） | 作った本人として、本人の役割と権限で動く | 自分の開発やスクリプト |
サービスアカウントキー | 人ではない「サービスアカウント」として動く | 複数人で共有する処理、自動で動く処理（CI、本番のサービス） |
ワークスペースキー（旧式） | 誰でもなく、作ったワークスペースに属する | 公式は、新しい用途には前の2つを勧めている |
個人キーとサービスアカウントキーは、どちらも「誰のキーか」がConsole上で決まっています。そのため、持ち主が組織から外れるとキーも使えなくなり、人が辞めたあとも誰にも気づかれずキーだけが残り続ける、ということが起きにくくなっています。
有効期限は作るときに選べる
キーを作るときに有効期限を選べます。3時間、1日、7日、30日、任意の期間、または「Never」（なし）です。期限は作ったあとに変えられません。期限が切れたキーで呼び出すと、401のauthentication_errorが返ります。期限なしのキーは、自分でシークレットマネージャーなどに保管して交換する前提の選択肢です。組織に有効期限の上限が設定されている場合は、「Never」を選べません。
APIキーを使うときの決まりごと
- 公式の勧めは、シークレットマネージャーに保管し、定期的に交換すること。漏れた疑いがあるキーは、すぐ無効化または削除する
- ユーザーのブラウザで動くコードにキーを書かない。ページのコードは誰でも読めるため、自分のサーバー側（バックエンド）にキーを置いて、そこからClaudeを呼ぶ
- 無効化（Disable）は元に戻せる。削除（Delete）は元に戻せない
キーの置き場所については、次の記事でも詳しく書いています。
ID連携（Workload Identity Federation）とは｜キーを持たずに呼び出す仕組み
ID連携は、英語ではWorkload Identity Federation（略してWIF）と呼ばれます。Claude Consoleの日本語画面では「ID連携」「IDフェデレーション」と表示されます。「ID」は身分、「連携」は、すでにある身分の仕組みをそのまま借りる、という意味だと考えると分かりやすいです。
APIキーが「Claudeが渡してくれた合言葉を、自分で持って使う」方式だとすると、ID連携は「動いている場所（AWSやGitHub Actionsなど）が発行する身分証を、Claudeに見せて通してもらう」方式です。
仕組みは3ステップ
公式ドキュメントの説明を、順番に並べます。
- 処理が動いている場所（AWS、Google Cloud、GitHub Actions、Kubernetesなど）が、その処理にIDトークン（JWTと呼ばれる署名つきの札）を渡す。これは、そのプラットフォームがもともと持っている仕組みで、多くの場合は何もしなくても処理から取り出せる
- SDKがそのIDトークンを、Claudeの/v1/oauth/tokenという窓口に送る。Anthropicは、Consoleに登録してあるルールと照らして確認し、合えば有効期限の短いトークン（sk-ant-oat01-…）を返す
- SDKがそのトークンでAPIを呼ぶ。期限が切れる前に、SDKが自動で引き換え直す
この流れのどこにも、人が作って保管する長期の秘密の文字列は出てきません。画面にあった「環境変数・設定ファイル・シークレットマネージャーに保存する必要はありません」は、このことを指しています。
使えるようにするには、事前に3つ作る
ID連携を使うには、Claude Consoleで次の3つを作ります。
- サービスアカウント：人ではない、処理用の名前つきの身分
- 連携元（発行元）の登録：「このIDプロバイダーが発行した札なら信用する」という登録。GitHub Actionsや自分のKubernetesクラスタなど、環境ごとに1つずつ登録する
- 連携ルール：「この連携元の、こういう条件の札なら、このサービスアカウントとして通す」という対応づけ。引き換えたトークンの有効期間は、ルールで60秒から24時間の間で決める（既定は1時間）
これを作るには、組織の管理者（admin）、オーナー、プライマリオーナーのいずれかの役割が必要です。Consoleの「Workload identity」ページには、3つをまとめて作る案内（Connect workloadという画面）があり、GitHub Actions、AWS、Google Cloud、Microsoft Entra ID、Kubernetesの選択肢と、それ以外の標準的な連携元に使う「Custom OIDC」が用意されています。
ここまで確かめたことをまとめると、ID連携は「連携元を登録する」手間を先に払うかわりに、キーを管理する手間をなくす方式です。手間を払う価値があるのは、すでに連携元のある環境で、キーの保管と交換が重荷になっている場合です。公式の全体の説明はWorkload Identity Federationにあります。
SDK側に渡す設定
ID連携で動かすとき、SDKには次の環境変数を渡します。4つがそろうと、SDKが自動でID連携を使います。
- ANTHROPIC_FEDERATION_RULE_ID：連携ルールのID
- ANTHROPIC_ORGANIZATION_ID：組織のID
- ANTHROPIC_SERVICE_ACCOUNT_ID：サービスアカウントのID
- ANTHROPIC_IDENTITY_TOKEN_FILE：IDトークンが入っているファイルの場所（ファイルではなく文字列で渡すなら、ANTHROPIC_IDENTITY_TOKEN）
ルールが複数のワークスペースにまたがる場合だけ、ANTHROPIC_WORKSPACE_IDも必要です。SDKは、期限が切れる120秒前から引き換え直しを試み、30秒前までに成功しないとエラーにします。
ここで1つ、注意があります。ANTHROPIC_API_KEYが設定されていると、ID連携より先に使われます。APIキーからID連携に切り替えたのに、環境にANTHROPIC_API_KEYが残っていると、ID連携は使われず、キーのまま動き続けます。
APIキーとID連携の使い分け｜選ぶ基準は「動かす場所」
ここまでを踏まえて、使い分けを3つの問いにしました。上から順に答えて、最初に当てはまったところで決めます。
問い1：自分のパソコンの上で動かすだけか
はい、ならAPIキーです。画面の注記にも「ローカルスクリプトでは、引き続きAPIキーが必要な場合がある」とありました。自分のパソコンには、AWSやGitHub Actionsのように身分証を渡してくれる仕組みがないためです。公式ドキュメントも、手元の開発とスクリプトはAPIキーが向く場面としています。
問い2：動かす場所が、IDトークンを発行してくれる場所か
動かす場所がAWS、Google Cloud、Azure、GitHub Actions、Kubernetesなどで、組織の管理者が連携を設定できるなら、ID連携を検討します。たとえば、次のような場面です。
- GitHub Actionsで、毎回の実行でClaudeに記事の要約や確認をさせている（キーをGitHubのシークレットに登録せずに済む）
- AWSやGoogle Cloudの上で、社内の業務システムがClaudeを呼んでいる（キーの交換作業をなくせる）
公式ドキュメントは、本番の処理やCI/CDで固定の秘密を持たずに済ませたい場合をID連携の向き先としています。ただし、組織のオーナー・管理者が連携の設定をする必要があるため、ひとりでConsoleを使っている場合や、設定の権限がない場合は、キーのほうが手早く始められます。
問い3：どちらでもない、または確かめきれない場合
この場合はAPIキーで始めます。公式も「早く始めたいならAPIキー」と書いています。そして、キーの置き場所を守ります。あとで動かす場所が連携に対応した環境に移ったら、ID連携に切り替えられます。
2つの違いを一覧にすると
比べるところ | APIキー | ID連携 |
|---|---|---|
Claudeに見せるもの | 自分で保管する固定の文字列 | 実行環境が出したIDトークンと引き換えた短期のトークン |
保管の手間 | キーを秘密の場所に置き、交換する | 保管する文字列がない |
期限 | 作るとき選ぶ（なしも選べる） | ルールで60秒〜24時間。SDKが自動で更新 |
最初に必要な準備 | Consoleで「Create key」 | サービスアカウント・連携元・ルールの3つ（管理者以上の権限） |
向く場所 | 手元の開発、試作、スクリプト | AWS・Google Cloud・Azure・GitHub Actions・Kubernetesなどの本番とCI |
私がAPIキーを選んだ理由｜x-likesの場合
私の場合、Xのいいね整理アプリ（x-likes）は、今は手元の開発サーバーで作っている段階で、動かす先はCloudflare Workersです。画面に挙がっていた対応先はGCP、AWS、Azure、GitHub Actionsの4つで、私の動かす場所はそのどれにも当たりません。画面の注記にも「ローカルスクリプトでは引き続きAPIキーが必要」とあります。
そこで、画面の「APIキーで続ける」を選びました。上の3つの問いにあてはめると、問い1（手元で動かしている）と問い3（連携に使える場所か確かめきれない）に当たる状況です。
ここで確かめていないこと
「Cloudflare WorkersではID連携を使えない」と断定はしません。確かめられたのは、次の2点までです。
- 私が見た画面では、対応先としてGCP、AWS、Azure、GitHub Actionsが挙がっていた
- 公式ドキュメントでは、連携元は「標準的なOIDCの発行元なら何でも」とされていて、Consoleには「Custom OIDC」の選択肢がある
つまり、画面に書かれた4つは「対応している代表例」で、それ以外が使えるかどうかは、この画面からは分かりません。Cloudflare Workersの処理から、ID連携に使える形のIDトークンを取り出せるかどうかは、私は確かめていません。今回は動かす場所が手元の開発サーバーでもあるので、無理に確かめず、APIキーで進めました。
費用は、Maxに付くAPIクレジットでまかなう
費用は、Claudeの個人プラン（Max 20x）に毎月付くAPIクレジット200ドル分でまかないます。このクレジットは、普段の対話で使うClaude Codeには使えないので、こうした自作アプリで使うのがちょうどいいと考えています。受け取り方と使い道は、次の記事にまとめています。
キーは画面にも会話にも出さずにファイルへ追記する
APIキーは、作った画面から1度コピーします。そして、AIとのやり取りやチャットには貼らず、次の1行で、開発用の設定ファイル（.dev.vars）に追記しました。
printf 'ANTHROPIC_API_KEY=%s\n' "$(pbpaste)" >> .dev.varspbpasteは、Macでコピーした内容をそのまま取り出すコマンドです。コピーしたキーが、画面にもチャットの履歴にも出ないままファイルに入ります。.dev.varsは、Cloudflare Workersを手元で動かすときに環境変数を渡すためのファイルです。
本番では、このファイルは使わず、Cloudflareのシークレットに登録する予定です。キーを書いたファイルは、Gitに記録する対象になっていないか、保存の前後に確かめてください。
APIキーで始めたあとに気をつけること
キーを置く場所を1か所に決める
キーは、それを使うプログラムの設定ファイルや、実行環境のシークレットにだけ置きます。パソコン全体の環境変数に設定してしまうと、ほかのツールまでそのキーで動こうとするためです。Maxに付くAPIクレジットの場合は、対話で使うClaude Codeがプランではなくキーで動こうとして、残高不足のエラーになる、という例を上の記事に書いています。
期限と権限を絞って作る
作るときに、期限を選べます。試作の間は「7日」「30日」のように期限つきにしておくと、置きっぱなしで漏れた場合の被害を限れます。権限は、個人キーなら作った本人の権限で動きます。キーを1つのワークスペースだけに限定して作ることもできます。
ブラウザの中にキーを書かない
アプリの画面（ブラウザで動くコード）にキーを書くと、ページを開いた人は誰でも読めてしまいます。公式の案内も、自分のサーバー側にキーを置き、画面からはそのサーバーを呼ぶ形にするよう書いています。x-likesのように、Cloudflare Workersの側でClaudeを呼ぶ作りなら、キーはWorkersのシークレットに置けるので、この条件を満たせます。
あとからID連携に移すときの手順
動かす場所が変わって、ID連携に切り替えたくなったときの手順は、公式ドキュメントに4ステップで書かれています。
- キーを残したまま、連携の設定を並行して作り、ルールが処理のIDトークンに合うことを確かめる
- どちらの認証が使われているか確かめる（CLIのant auth statusで分かる。この時点ではキーが優先される）
- 処理が動く環境から、ANTHROPIC_API_KEYをすべて外す（CIのシークレット、コンテナの環境変数、シェルの設定）
- 連携で動いているのを確認してから、Consoleでキーを削除する
3番目が抜けやすい点です。キーを外さないと、切り替えたつもりでもキーのまま動き続けます。
APIキーとID連携のよくある疑問
ID連携のほうが安全ですか
公式ドキュメントは、ID連携は、長く使える秘密を環境に置かずに済むため、漏れたときの被害を限れると説明しています。一方で、ID連携だけで安全が保証されるわけではない、とも書いています。連携の強さは、IDトークンを発行する側（クラウドなど）の設定に左右されます。たとえば、IDトークンを作れる固定の認証情報が手前にあれば、そこが弱点になります。
APIキーはもう古い方法ですか
古くはありません。公式ドキュメントの比較表でも、APIキーは手元の開発、試作、スクリプト、秘密の保管場所を自分で管理できるサーバーに向く方法として載っています。2つのアクセス権限は同じなので、使う場所に合うほうを選べば足ります。
ID連携は個人でも設定できますか
設定には、組織の管理者、オーナー、プライマリオーナーのいずれかの役割が必要です。公式が挙げている条件は役割だけで、個人か会社かは書かれていません。ただし、連携元（AWSやGitHub Actionsなど）が前提なので、手元で動かすだけなら使い道がありません。
「ID連携を使用すれば、APIキーは不要」の画面は、毎回出ますか
私が確かめたのは、2026年11月11日に1回出たことだけです。毎回出るのか、一定の条件で出るのかは確かめていません。出たら「APIキーで続ける」でキーの作成に進めます。
まとめ｜どちらを選ぶかは動かす場所で決まる
APIキーとID連携は、できることは同じで、「Claudeに自分を証明するための持ち物」が違います。
- 手元のパソコンや、連携に使える場所が決まっていない場合は、APIキーで始める
- AWS・Google Cloud・Azure・GitHub Actions・Kubernetesなどの上で動かし、管理者がConsoleの設定をできるなら、ID連携を検討する
- APIキーで始めても、置き場所を守れば問題ない。あとからID連携に移れる
私は、x-likesの動かす場所が画面に挙がっていた対応先に当たらないため、APIキーを選びました。この画面が出たら、まず「自分の処理はどこで動くのか」を考えてみてください。
この記事の内容は、2026年11月11日時点の公式ドキュメントと、私が見た画面に基づいています。Consoleの画面や条件は変わることがあるため、設定する前に、最新の公式ドキュメント（Authentication・Workload Identity Federation）をご確認ください。
Claudeのこの5つの設定、今すぐ見直した方がいい
共有・学習・入力・権限・委任。事故が起きるのはこの5つだけ（全28ページ）
2026年7月、Claudeの共有チャットがGoogle検索から読める状態になっていました。原因は設定そのものではなく、自分が過去に共有したものを覚えていないことでした。共有リンクの棚卸しから、学習をオフにしても残る例外条項、Claude Codeの権限モードまで、今日30分で確認できる形にまとめています。
- 見落としやすい共有リストは3つある（3つ目は画面の下）
- 学習をオフにしても残る、公式の例外条項
- 権限モード6つの違いと、Shift+Tabでの切り替え方
- 私が実際に禁止しているコマンド23行を全文公開
メールアドレス登録で他にも様々な資料を閲覧できます
＋11PDF 20点・合計513ページ ＋ すぐ使えるzip素材 3点
どれも登録後の受け取りページから、まとめてダウンロードできます。
毎週配信の無料ニュースレター「AIネイティブ超研究」の購読特典です。メール登録後すぐ、受け取りページのご案内が届きます。そこにはこの資料に加えて、過去の特典もすべてまとめて置いてあります。あわせて、AI活用に関するお知らせやお役に立てそうなご案内をお送りすることがあります。解除はいつでも1クリック。
「Claude を自分で使いこなしたい」「自社の業務に組み込みたい」
── そんな方は、まず初回無料相談でお話ししてみませんか。
御社の業務に合わせたClaude導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。