Claude APIキーの漏洩が疑われるときの無効化手順と管理

Claude APIキーが漏れたかもしれないと思ったら、まずConsoleでそのキーを止めます。調べるのはその後です。

APIキーは、Claude Consoleアカウントへの鍵として働きます。クレジットカード番号と同じで、他人が入手して使えば、あなたの課金として請求されます。疑いの段階で止めれば、被害は使われた分で打ち止めになります。

漏洩が疑われたら最初にやること

初動は、キーを使えない状態にすることです。サポート記事の手順は、Consoleの画面でキーの三点メニューから削除を選ぶ流れです。

削除の後も不審なAPIアクティビティが続く場合や、ほかに気になる点がある場合は、サポートチームへ連絡する流れです。

無効化(Disable)と削除(Delete)は何が違うか

サポート記事は削除を案内していますが、Consoleの認証ドキュメントには、もう1つ手があります。API keysページの「Disable」は元に戻せる停止で、Admin APIではキーのstatusがinactiveになり、「Re-enable」でactiveに戻ります。「Delete」は恒久的な操作で、キーはアーカイブされ、List API Keysにはstatus: "archived"として残ります。

Admin APIを使う組織では、POST /v1/organizations/api_keys/{api_key_id}に{"status": "inactive"}を送って無効化することもできます。Consoleに入れない状況で、管理者用キーが手元にあるときの手段です。有効期限が切れたキーは削除しかできず、再有効化はできません。

キーがどこから漏れたかで動き方が変わる

最も多い原因は、公開コードリポジトリやサードパーティのツールへの不用意な露出です。平文のキーを公開GitHubリポジトリにコミットしたり、外部ツールに入力したりして、悪用につながるのが典型です。

履歴に残った文字列を消しても、漏れた事実は取り消せません。だからこそ先にキーを止め、古いキーを使えない状態にします。探す先は、公開リポジトリのコミット履歴(最新のファイルだけでなく過去のコミットも)、設定ファイルやサンプルコードへの直書き、共有したチャットやメールやスクリーンショットです。

スクリーンショットや画面共有に映り込んだ場合も同じです。見せた範囲が分からないなら、止めるほうが確実です。

自動失効のメールを受け取ったとき

AnthropicはGitHubのシークレットスキャンのパートナープログラムに参加しています。公開リポジトリに載ったClaude APIキーをGitHubが検出するとAnthropicへ通知され、Anthropicがキーを自動で無効化し、該当ユーザーに詳細なメールを送ります。

メールが届いても、片付くのはそのキー1本だけです。新しいキーの保管方法と、ほかに漏れた箇所がないかの確認は自分で行います。失効したキーを使っていたスクリプトやサービスは、新しいキーに差し替えるまで認証できなくなります。差し替え先の設定場所を先に洗い出しておくと、復旧が早く済みます。

止めた後に使用量と支出上限を見る

失効させただけでは、すでに起きた利用は分かりません。Consoleのログと使用量は、漏洩を疑った直後に次の順で見ます。

• 使用量のグラフに、心当たりのない急増や時間帯がないか
• ログに、想定していないリクエストが残っていないか
• 支出上限や自動リロードの設定が、想定した額に収まっているか

支出まわりの安全装置は、組織のレート制限の種類で変わります。

自動リロードは、閾値を下回るとカードに自動で課金してクレジットを補充する機能です。サービスを止めない利点がある一方で、キー漏洩やコードの不具合による想定外の大量利用に対する歯止めにもなるため、上限は慎重に決めます。

支出上限の継承や増額申請をAPIで扱う方法はClaude Spend Limits APIで解説しています。

新しいキーを安全に持つ

再発行したキーは、コードに直書きせず環境変数で渡します。公式SDKは、ANTHROPIC_API_KEY環境変数が設定されていれば自動で読み取ります。ローカル開発の例は、.envファイルとpython-dotenvの組み合わせです。

ANTHROPIC_API_KEY=your-api-key-here

from dotenv import load_dotenv
import os
 
load_dotenv()
my_api_key = os.getenv("ANTHROPIC_API_KEY")

.envはバージョン管理の除外ファイル(gitなら.gitignore)に必ず入れます。クラウドにデプロイするときは、dotenvファイルではなく暗号化されたシークレットストレージを使います。AWS、GCP、Azure、Vercel、Herokuは、それぞれの環境変数の受け渡し手段を用意しています。

echo ".env" >> .gitignore

有効期限を付けて、漏れたキーの寿命を区切る

Consoleでキーを作るとき、有効期限を選べます。選べるのは3時間・1日・7日・30日のプリセット、任意の期間、そして「Never」です。「Never」は、シークレット管理システムに保管して自分でローテーションするキー向けです。

期限は作成時に決まり、後から変更できません。期限が切れたキーで呼び出すと401 authentication_errorが返り、再有効化はできないので、新しいキーを作り直します。期限が近づくと、キーの作成者にメールが届きます。

• 寿命が14日以上のキー: 期限の7日前
• 寿命が7日以上のキー: 期限の1日前
• それより短い寿命のキー: 警告メールなしで失効

CIの一時ジョブや検証用のスクリプトなど、使い捨てに近い用途なら、短い期限を付けておくと漏洩後に放置しても自然に止まります。ただし公式ドキュメントも、期限は漏れた資格情報の寿命を限るだけで、シークレットの扱いの代わりにはならないと書いています。

キーの種類と、持ち主が組織を離れたとき

Consoleで作るキーには、種類があります。個人キーは作成者の権限で動き、組織から外されるとアーカイブされます。再招待されても復活しないので、新しく作り直します。サービスアカウントキーは、サービスアカウントがアーカイブされると止まります。

ワークスペースキー(旧来の形式)は、作成者が組織を離れても使い続けられます。ただしClaude Codeのワークスペースのキーは作成メンバーに紐づき、そのメンバーが外されると止まります。公式は、新しい連携には個人キーかサービスアカウントキーを優先する方針を示しています。共有や自動実行にはサービスアカウントを管理者が作る、というのが公式の整理です。退職者のキーが残り続ける構成を避けたいときの判断材料になります。

キー管理のベストプラクティス

用途別のキー分離は、漏洩時の初動を軽くします。本番用と開発用が同じキーだと、止めた瞬間に本番が止まります。分けてあれば、漏れた用途のキーだけを止めて済みます。

止めて困るものを、平時に洗い出しておく

キーを止めると、そのキーを使うリクエストは通らなくなります。漏洩を疑ったその場で「このキーはどのアプリが使っているのか」を調べていると、初動が遅れます。平時のうちに、次の台帳を用意しておく手があります。

1. キーの名前と用途(開発、テスト、本番、CIなど)を対応づける
2. そのキーをアプリが受け取る環境変数の名前と、値を置いている場所(シークレットストレージ、CIの設定画面など)を控える
3. 差し替えに必要な操作を書く。誰が新キーを発行し、どこの値を更新し、どのアプリを再起動するか

キーの名前に用途を入れておくと、Consoleの一覧から対象を選び間違えにくくなります。用途ごとに使用量が見えるので、心当たりのない急増がどのキーで起きたかも絞れます。

実際に漏洩を疑ったときの順番は、台帳があってもなくても変わりません。まず対象キーを止め、新しいキーを発行して、台帳に従って環境変数を差し替えます。止めたことでアプリが止まる時間は、この台帳があるかどうかでほぼ決まります。

定期ローテーションでも、同じ台帳が使えます。新しいキーを作り、台帳にある全アプリの値を差し替えてから、古いキーを無効にします。漏洩時と違って時間の余裕があるので、順番を逆にして本番を止める必要はありません。

Workspaceでキーを区切る場合は、Claude Admin APIキーの取得方法とスコープ選択と、Claude WorkspacesのロールとAPIキーのスコープも参考になります。Workspace単位でレート制限を絞る手順はClaude APIでWorkspace単位のレート制限を設定する手順にあります。

Claude Codeの作業ディレクトリにキーを置くとき

Claude Codeでキーを含む.envを作業ディレクトリに置くと、Claudeがそのファイルを読める位置にキーがあることになります。Claude Codeの権限設定には、指定したパスの読み取りを拒否するReadのdenyルールがあります。たとえばRead(./.env)やRead(./secrets/**)を指定します。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

denyルールが効く範囲は、次のように分かれます。

.claudeignoreファイルを置いていても、Claude Codeでは効果がありません。その中身はReadのdenyルールに移します。

ルールだけではBash経由のすべての読み取りを塞げないため、OS単位で止めたいときはサンドボックスの併用が公式の案内です。さらに、キー自体を持たない構成に寄せる方法もあります。その選択肢はClaude APIの認証方式まとめとWorkload Identity Federation(WIF)とはで整理しています。

まとめ

漏れが確実なら削除、原因を絞る間だけ止めたいなら無効化で、どちらでも先に止めてから新しいキーと使用量の確認に進みます。再発の備えは、キーに期限を付けること、用途ごとに分けること、差し替えの台帳を持つことの3点です。