Claude Codeの無効なAPI keyエラーを解決する方法

Claude Code で無効な API key エラーが表示される理由

Claude Code が Invalid API key で失敗する原因は 2 つあり、対処方法は正反対です。API key で認証するつもりだった場合は、その key が間違っているか、取り消されているか、別のアカウントのものです。あるいは、そもそも key を使うつもりがなく、サーバーの環境に残った ANTHROPIC_API_KEY が、ログイン先のサブスクリプションより優先されている可能性があります。Anthropic のドキュメントでは、2026 年 9 月時点で後者について明確に説明されています。環境に設定された key は、ログイン済みの Claude Pro、Max、Team、Enterprise サブスクリプションより優先して使用されます。

変更する前に、どちらのケースかを確認してください。Claude Code を起動し、/status を実行します。ドキュメントには、サブスクリプションのアカウントを示す Login method 行と、API key の使用時に表示される API key 行が記載されています。/login だけを実行したことのあるサーバーで API key の行が表示された場合は、原因は環境にあります。再認証しても環境変数は変更されません。

以下は、各自のサーバーで実行するコマンドです。実行結果を確認してから操作してください。

認証情報の優先順位と、なぜ /login では解決しないのか

複数の認証情報が存在する場合、Claude Code は文書化された順序で 1 つを選択します。

• CLAUDE_CODE_USE_BEDROCK、CLAUDE_CODE_USE_VERTEX、または CLAUDE_CODE_USE_FOUNDRY が設定されている場合のクラウドプロバイダー認証情報。
• Authorization: Bearer ヘッダーとして送信される ANTHROPIC_AUTH_TOKEN 変数。
• X-Api-Key ヘッダーとして送信される ANTHROPIC_API_KEY 変数。
• apiKeyHelper スクリプトの出力。
• claude setup-token のトークンを保持する CLAUDE_CODE_OAUTH_TOKEN 変数。
• Anthropic のプロファイルおよびフェデレーション認証情報。
• /login が書き込むサブスクリプションの OAuth 認証情報。

この一覧を下から確認してください。/login は最後の項目として認証情報を書き込みます。Linux では、その認証情報は ~/.claude/.credentials.json にファイルモード 0600 で保存されます。その上にある環境変数の認証情報がすべて優先されます。そのため、新しいログインで更新されるのは、セッションが参照していない認証情報です。ログイン自体は成功しますが、その認証情報は使われません。分かりやすい対処で何も変わらない理由はこれだけです。

対話型セッションでは、さらに 1 つの手順があるため、混乱しやすくなります。ドキュメントによると、環境変数から検出された API key について、使用を承認するか拒否するかを 1 回だけ確認され、その選択が記憶されます。数か月前にクリックして承認した内容が、現在も有効です。/config の「Use custom API key」トグルで変更できます。このトグルは、環境に ANTHROPIC_API_KEY が設定されている場合にだけ表示されます。非対話型モード、つまりスクリプトや cron ジョブ内の claude -p では、確認は一切表示されません。キーが存在する場合は、常に使用されます。

VPS 上に残っている ANTHROPIC_API_KEY はどう探しますか？

まず、Claude Code を起動するシェルで、その変数が存在することを確認します。

env | grep -i anthropic

次に、Anthropic のトラブルシューティングページに記載されている修正を実行します。これはテストも兼ねています。

unset ANTHROPIC_API_KEY
claude

Claude Code が起動し、/status にサブスクリプションが表示された場合、原因を特定できたことになります。次のシェルで変数が戻るのは、unset が入力したシェルだけを変更するためです。このセクションの残りでは、その変数を設定している場所を探します。

Shell プロファイルとシステム全体の環境ファイル

grep -rn ANTHROPIC ~/.bashrc ~/.bash_profile ~/.profile ~/.zshrc \
  ~/.config/fish/config.fish /etc/environment /etc/profile /etc/profile.d/ 2>/dev/null

Anthropic のページでは ~/.zshrc、~/.bashrc、~/.profile が挙げられています。サーバーでは検索範囲を広げてください。/etc/environment は PAM（Pluggable Authentication Modules）がログイン時にサーバー上のすべてのユーザーに対して読み込むファイルです。そのため、同僚が設定したキーが自分のセッションに入ることがあります。/etc/profile.d/ 内のファイルは login shell で実行されます。.bashrc は interactive shell だけが読み込むため、systemd サービス内での失敗の原因にはなりません。確認すべきファイルは、Claude Code の起動方法によって異なります。

systemd ユニット

ユニットは shell プロファイルを読みません。環境は、ユニットおよび drop-in 内の Environment= と EnvironmentFile= の行から設定されます。

systemctl cat claude-agent.service
systemctl show -p Environment claude-agent.service

systemctl cat は、ユニットファイルに続けて /etc/systemd/system/claude-agent.service.d/ にあるすべての drop-in を表示します。通常、override はここにあります。systemctl show -p Environment は、systemd が実際にプロセスへ渡す内容を表示します。自分のユーザーで実行するサービスの場合は、両方のコマンドに --user を追加します。ユニットを編集した後は sudo systemctl daemon-reload を実行してからサービスを再起動してください。環境はプロセスの起動時に組み立てられ、実行中のプロセスは渡された環境のコピーを保持するためです。

編集後も残る tmux と screen のセッション

この問題で何時間も失うことがあります。tmux サーバーは起動時の環境を保持し、新しい pane には現在の shell ではなくサーバーの環境が継承されます。.bashrc から export を削除して新しい pane を開いても、古いキーが残ることがあります。

tmux show-environment | grep -i ANTHROPIC
tmux set-environment -r ANTHROPIC_API_KEY

set-environment -r は、tmux が新しいプロセスへ渡す環境から削除する変数名を指定します。-g を追加すると、サーバーの global environment からも同じように削除されます。すでに開いている pane は独自のコピーを保持します。プロセスの環境は、そのプロセス内部からしか変更できないためです。export を削除した後は、detach し、tmux kill-server を実行して、新しいセッションを開始するのが確実です。screen も同じ動作をします。VPS 上で 長時間実行する Claude Code セッションを tmux で構成する前に、この点を理解しておいてください。そのようなセッションは、設定を 3 回編集しても存続する種類のプロセスです。

すでに実行中のプロセスの環境を読むには、kernel に問い合わせます。

tr '\0' '\n' < /proc/$(pgrep -n claude)/environ | grep -i anthropic

これにより、exec 時にプロセスへ渡された値が表示されます。プロセスが実際に使用している値です。このファイルを読むには、プロセスの所有者または root である必要があります。pgrep -n claude は最も新しい一致を選ぶため、複数のプロセスがある場合は PID を確認してください。

Docker と Compose

docker exec claude-agent env | grep -i anthropic
docker compose config

最初のコマンドは、実行中の container 内の環境を表示します。--env-file、environment: ブロック、または image に組み込まれた ENV 行の内容も含まれます。docker compose config は変数を解決した compose ファイルを表示します。そのため、記述した ${ANTHROPIC_API_KEY} プレースホルダーではなく、渡される値を確認できます。どちらのコマンドも terminal に secrets を表示するため、消去しても問題ないセッションで実行してください。Compose は、明示しなくても compose ファイルと同じ場所にある .env ファイルも読み込みます。これは、誰も追加した覚えのないキーの一般的な発生源です。

すべての shell の修正後も残る settings ファイル

Claude Code の settings ファイルには env ブロックがあります。ドキュメントでは、この競合について明確に説明されています。同じ変数が shell と settings ファイルの env ブロックの両方で設定されている場合は、settings ファイルの値が適用されます。そこに記述されたキーは、入力した unset よりも優先されます。

grep -rn ANTHROPIC ~/.claude/settings.json .claude/settings.json .claude/settings.local.json 2>/dev/null

ユーザーのファイルだけでなく、project ファイルも確認してください。.claude/settings.json は通常 commit されるため、repository を clone するすべてのユーザーと共有されます。組織が managed settings を配布している場合もあり、その設定は自分のファイルより優先されます。削除できないキーを見つけた場合は、組織の管理者に確認してください。

もう一つの分岐: 本当にキーが間違っている場合

/status に API key が表示され、それが意図したものであれば、エラーの内容をそのまま受け取ってください。Anthropic のエラーリファレンスでは、Invalid API key の原因として次を挙げています。

• キーの形式が不正、または内容が間違っている。
• キーが無効化されている、または有効期限が切れている。
• キーが別の組織またはアカウントに属している。

スクロールバックに値を表示せずに確認します。

echo "len=${#ANTHROPIC_API_KEY} tail=${ANTHROPIC_API_KEY: -6}"

想定より 1 文字または 2 文字長い場合は、通常、コピーと貼り付けの際に末尾の改行または引用符が含まれています。末尾の改行を取り込んだ $(cat keyfile) が原因の場合もあります。この値は X-Api-Key ヘッダーとして送信されるため、余計な文字があると、送信される認証情報は作成したキーとは異なります。

同じ出力で ANTHROPIC_AUTH_TOKEN も確認してください。出力順では API key より上にあるためです。プロキシの検証時に残った bearer token があると、修正しようとしているキーは、実際にはまったく送信されていない認証情報になります。その出力では ANTHROPIC_BASE_URL も確認する価値があります。古い値が残っていると、クライアントが、すでに存在しない可能性のあるゲートウェイを参照するためです。ヘッダー全体の構成については、Anthropic API key 認証の仕組みで、それぞれの値が何を保持するかを確認できます。このマシンにどの認証情報を保持させるか決める前に、サブスクリプションログインと API key の違いを参照してください。

このエラーは、容量の問題ではありません。セッションの認証は成功し、その後、処理中のリクエストが失敗する場合は、モデルが過負荷の場合のエラーを確認してください。この場合、認証情報を変更する必要はありません。

API キーヘルパースクリプトが失敗するのはなぜですか？

apiKeyHelper は、認証情報を取得するために Claude Code が実行するスクリプトを指定する設定キーです。Vault から取得するキーなど、ローテーションするトークンや短時間だけ有効なトークンに使用します。契約は単純です。現在のキーを標準出力に出力し、正常終了します。ドキュメントによると、エラー終了、タイムアウト、または出力なしになるスクリプトでは、3 回以内の試行でリクエストが Your apiKeyHelper script is failing で失敗します。

手動で実行し、この契約の両方の条件を確認します。

out=$(/usr/local/bin/anthropic-key.sh)
echo "exit=$? len=${#out} tail=${out: -6}"

キーを正しく出力していても、終了ステータスが 0 以外なら失敗です。キーの前に Fetching credential... を標準出力へ出力するヘルパーも失敗します。その行が認証情報の一部になるためです。進捗メッセージは標準エラー出力へ送ります。

次に、サービスから実行される場合と同じ方法でテストします。

env -i HOME="$HOME" PATH=/usr/bin:/bin /usr/local/bin/anthropic-key.sh
echo "exit=$?"

env -i は、ほぼ空の環境でスクリプトを起動します。aws、vault、または gcloud を、あなたの .bashrc が PATH に追加したディレクトリから呼び出すヘルパーは、テスト時には動作しても、実行環境では失敗します。実行中の Claude Code プロセスがあなたの .bashrc を読み込んでいないためです。スクリプトに実行権限があることを確認し、スクリプトが呼び出すすべてのものに絶対パスを使用します。または、スクリプト内で PATH を設定します。

サーバーでは、ドキュメントに記載された動作がさらに 2 つ重要です。Claude Code はデフォルトで 5 分後にヘルパーを再実行し、CLAUDE_CODE_API_KEY_HELPER_TTL_MS で別の間隔を指定できます。そのため、起動時には動作して 1 時間後に壊れる構成は、起動時ではなく更新時に失敗しています。ヘルパーがキーを返すまでに 10 秒を超えると、Claude Code は経過時間を含む警告通知をプロンプトバーに表示します。この通知は呼び出しが遅いことを示すもので、壊れていることを示すものではありません。タイムアウトがエラーになる前に気付くための早期警告です。

このマシンに本当に API key が必要ですか？

修正方法は、必ずしも削除ではありません。マシンを個別に課金する理由がある場合は、key を残します。

• Console に課金される VPS 上の無人エージェントは、個人のサブスクリプションの利用上限を消費しません。
• 非対話的な実行では、claude -p に承認操作を行うターミナルがなく、key が存在すれば常に使用されます。
• サブスクリプションを関連付けていないマシン。
• 共有マシンまたはクライアント用マシン。個人のサブスクリプションログインを保存すべきではありません。

通常はコストで判断します。判断にはAPI とサブスクリプションの料金比較を使用します。

マシンが自分のもので、すでに支払っているサブスクリプションを使う場合は、key を削除します。そのうえで、削除状態を維持します。すべての対話シェルが継承する ~/.bashrc に key を export するのではなく、必要なサービスだけに渡します。

[Service]
EnvironmentFile=/etc/claude-agent.env

このファイルのモードは 600 にし、サービスを実行するユーザーが所有するようにします。対話セッションからはこのファイルを参照できません。そのため、自分の claude はサブスクリプションを使い続け、サービスは key を使い続けます。ブラウザーがない環境でサブスクリプションの認証情報が必要な場合は、claude setup-token で OAuth token を出力し、CLAUDE_CODE_OAUTH_TOKEN に貼り付けられます。利用前に、ドキュメントに記載された制限を確認してください。これは model request のみ実行できるため、Remote Control セッションと claude.ai connector は利用できません。この判断をマシンごとに一度行い、unit file に記録することが重要です。これにより、このページで扱う問題を防げます。この問題は、誰も設定した覚えのない key から始まるためです。認証情報を設定した後に、その認証情報がアクセスできる範囲を制限する作業は別途必要です。詳しくはVPS 上で Claude Code を安全に実行するを参照してください。

強力な削除操作を実行する前に、1 点注意してください。/logout は保存済みの認証情報を削除します。ドキュメントによると、保存済みの MCP (model context protocol) server login と plugin secret も削除されます。そのため、後で再認証が必要になります。

FAQ

Claude Code でサブスクリプションを契約しているのに、invalid API key と表示されるのはなぜですか？

環境変数に設定された ANTHROPIC_API_KEY が、サブスクリプションでのログインより優先されるためです。Anthropic のドキュメントによると、環境変数に設定されたキーは、ログイン済みであっても Pro、Max、Team、Enterprise のサブスクリプションの代わりに使用されます。また、非対話モードで -p が設定されている場合は、キーが存在すれば常に使用されます。Claude Code 内で /status を実行すると、セッションが選択した認証情報を確認できます。API key の行が表示され、自分で設定した覚えがない場合は、unset ANTHROPIC_API_KEY を実行してから claude を再度起動し、原因を確認してください。

/login を実行すれば invalid API key エラーは解消しますか？

変数が設定されたままでは解消しません。/login はサブスクリプションの OAuth 認証情報を書き込みますが、その認証情報は Claude Code の認証情報の優先順位で、環境変数および apiKeyHelper より下位にあります。ログイン自体は成功しても、その後で別の認証情報が優先されるため、繰り返しても状況は変わりません。変数が設定されている場所から削除するか、/config の「Use custom API key」トグルを無効にしてください。ドキュメントによると、このトグルは環境に ANTHROPIC_API_KEY が設定されている場合にのみ表示されます。

Claude Code が使用している認証方式を確認するにはどうすればよいですか？

セッション内で /status を実行します。ドキュメントでは、サブスクリプションアカウントを示す Login method の行と、API キーの使用時に表示される API key の行について説明しています。これを、起動元と同じ shell での env | grep -i anthropic の結果と比較してください。サービスまたはコンテナで Claude Code を実行している場合は、代わりに tr '\0' '\n' < /proc/<pid>/environ でプロセスの環境を確認してください。実行中のプロセスが保持するのは、現在の shell の環境ではなく、起動時に渡された環境だからです。

apiKeyHelper スクリプトを実行すると動作します。それでも Claude Code が失敗するのはなぜですか？

通常は、環境または終了ステータスが原因です。Claude Code は独自のプロセスから helper を実行します。このプロセスは shell の profile を読み込まないため、.bashrc の PATH エントリに依存する helper は、端末から実行すると動作しても、Claude Code 内では失敗します。env -i HOME="$HOME" PATH=/usr/bin:/bin /path/to/helper でテストし、その後に echo $? を確認してください。ドキュメントで説明されている失敗には、スクリプトがエラーで終了する場合、タイムアウトする場合、何も出力しない場合が含まれます。この状態は Your apiKeyHelper script is failing として表示されます。キー以外の内容を標準出力に出力すると、それも認証情報の一部になります。進行状況のメッセージは標準エラー出力に送ってください。