Claude APIキーの漏洩が疑われるときの無効化手順と管理
Claude APIキーが漏れたかもしれないときに、Consoleで削除して再発行するまでの手順と、再発を防ぐキー管理の実践をまとめます。
Claude APIキーの漏洩が疑われるときの無効化手順と管理
Claude APIキーが漏れたかもしれないと思ったら、まずConsoleでそのキーを削除します。調べるのはその後です。
APIキーは、Claude Consoleアカウントへの鍵として働きます。クレジットカード番号と同じで、他人が入手して使えば、あなたの課金として請求されます。疑いの段階で止めれば、被害は使われた分で打ち止めになります。
漏洩が疑われたら最初にやること
初動は、キーの即時失効です。手順は次のとおりです。
- Claude Consoleにログインする
- プロフィールからAPI keysページを開く
- 対象キーの右にある三点メニューを開く
- 「Delete API Key」を選ぶ
削除したら、同じページの「Create Key」で新しいキーを発行します。新キーはシークレット管理システムなど安全な場所に保管し、バージョン管理には入れません。
削除の後も不審なAPIアクティビティが続く場合や、ほかに気になる点がある場合は、サポートチームへ連絡する流れです。
削除の後に確認すること
失効させただけでは、すでに起きた利用は分かりません。Consoleのログと使用量は定期的に見ておくものです。漏洩を疑った直後は、次の順に見ます。
- 使用量のグラフに、心当たりのない急増や時間帯がないか
- ログに、想定していないリクエストが残っていないか
- 支出上限や自動リロードの設定が、想定した額に収まっているか
支出まわりの安全装置は、組織のレート制限の種類で変わります。次のように分かれます。
| 組織の種類 | 安全装置 |
|---|---|
| カスタムレート制限の組織 | 安全装置アカウント設定で使用量と支出の上限を設ける |
| 標準レート制限の組織 | 安全装置自動リロードを有効にし、閾値を設定する |
自動リロードは、閾値を下回るとカードに自動で課金してクレジットを補充する機能です。サービスを止めない利点がある一方で、キー漏洩やコードの不具合による想定外の大量利用に対する歯止めにもなるため、上限は慎重に決めます。
支出上限の継承や増額申請をAPIで扱う方法はClaude Spend Limits APIで解説しています。
キーがどこから漏れたかを探す
最も多い原因は、公開コードリポジトリやサードパーティのツールへの不用意な露出です。平文のキーを公開GitHubリポジトリにコミットしたり、外部ツールに入力したりして、悪用につながるのが典型です。
探す場所は次の4つです。
- 公開リポジトリのコミット履歴(最新のファイルだけでなく過去のコミットも)
- 設定ファイルやサンプルコードに直書きしたキー
- Webベースのエディタ、クラウドプロバイダー、CI/CDなどの外部サービスに登録したキー
- 共有したチャットやメール、スクリーンショット
履歴に残った文字列を消しても、漏れた事実は取り消せません。だからこそ先にキーを削除し、古いキーを使えない状態にします。
漏れた場所ごとの動き方
どこから漏れたかで、自動失効が働くかどうかが変わります。公開GitHubリポジトリに載せた場合は、次の節で説明するとおり、GitHubとAnthropicが連携して止めてくれます。ただし止まるのは、GitHubが検出できたキーだけです。検出から失効までに間があるかどうかは示されていないため、公開してしまったキーも自分で削除して構いません。
プライベートリポジトリや社内チャット、メールへの貼り付けは、自動失効しません。誰も止めてくれないので、自分でConsoleから削除します。CI/CDやWebベースのエディタなど外部ツールに登録したキーは、そのツールの開発元にConsoleアカウントへの入口を渡したのと同じ扱いです。信頼できるか自信がなければ、削除して新しいキーだけを暗号化シークレットとして登録し直します。
スクリーンショットや画面共有に映り込んだ場合も同じです。見せた範囲が分からないなら、削除を選ぶほうが確実です。
GitHubの公開リポジトリに載せた場合の自動失効
AnthropicはGitHubのシークレットスキャンのパートナープログラムに参加しています。流れは次のとおりです。
- GitHubが公開リポジトリに載ったClaude APIキーを検出する
- GitHubがAnthropicに通知する
- Anthropicが露出したキーを自動で無効化する
- 該当ユーザーにAnthropicから詳細なメールが届く
対象は「公開」リポジトリです。プライベートリポジトリ、社内チャット、外部ツールへの登録での漏洩は、この経路では拾われません。自動失効のメールを受け取った場合も、新しいキーの保管方法と、ほかに漏れた箇所がないかの確認は自分で行います。失効したキーを使っていたスクリプトやサービスは、新しいキーに差し替えるまで認証できなくなります。差し替え先の設定場所を先に洗い出しておくと、復旧が早く済みます。
新しいキーを安全に持つ
再発行したキーは、コードに直書きせず環境変数で渡します。ローカル開発の例は、.envファイルとpython-dotenvの組み合わせです。
ANTHROPIC_API_KEY=your-api-key-herefrom 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キー管理のベストプラクティス
| 項目 | 内容 |
|---|---|
| 共有しない | 内容他の人がClaude APIを使うなら、その人が自分のキーを取得する |
| 外部ツールの選別 | 内容外部サービスにキーを預けることは、そのサービスの開発元にConsoleアカウントへのアクセスを渡すのと同じ。信頼できないなら預けない |
| 暗号化シークレット | 内容サードパーティ側には暗号化されたシークレットとして登録し、コードや設定ファイルに直書きしない |
| 定期ローテーション | 内容例として90日ごとに新規作成と旧キーの無効化を行う |
| 用途ごとに分離 | 内容開発・テスト・本番でキーを分ける。漏れたときにその用途だけ止められる |
| リポジトリのスキャン | 内容ソース管理側のシークレットスキャン、Gitleaksなどのツール、CI/CDへの組み込み |
| KMSの利用 | 内容キーが増えたら、集中管理・アクセス制御・監査証跡・ローテーションを備えた仕組みへ |
用途別のキー分離は、漏洩時の初動を軽くします。本番用と開発用が同じキーだと、削除した瞬間に本番が止まります。分けてあれば、漏れた用途のキーだけを削除して済みます。
削除で止まるものを、平時に洗い出しておく
削除すると、そのキーを使うリクエストは通らなくなります。漏洩を疑ったその場で「このキーはどのアプリが使っているのか」を調べていると、初動が遅れます。平時のうちに、次の台帳を用意しておく手があります。
- キーの名前と用途(開発、テスト、本番、CIなど)を対応づける
- そのキーをアプリが受け取る環境変数の名前と、値を置いている場所(シークレットストレージ、CIの設定画面など)を控える
- 差し替えに必要な操作を書く。誰が新キーを発行し、どこの値を更新し、どのアプリを再起動するか
キーの名前に用途を入れておくと、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/**)"
]
}
}このルールは、Grepなど組み込みの読み取りツールにもベストエフォートで適用されます。ベストエフォートなので、あらゆる経路を完全に塞ぐ保証ではありません。キー自体を持たない構成に寄せる方が確実で、その選択肢はClaude APIの認証方式まとめとWorkload Identity Federation(WIF)とはで整理しています。
よくある質問
キーを削除すると、そのキーを使っているアプリはどうなりますか。
そのキーを使うリクエストは通らなくなります。新しいキーを発行してアプリの環境変数を差し替えるまで、そのアプリからのAPI呼び出しは止まります。
まとめ
漏洩が疑われるときの順番は、キーの削除、新しいキーの発行と安全な保管、ログと使用量の確認です。それでも不審な動きが続くならサポートに連絡します。
日頃は、環境変数とシークレット管理、用途ごとのキー分離、定期ローテーション、リポジトリのスキャンで露出を減らします。支出上限や自動リロードの設定は、漏れたときの被害額を決める最後の歯止めです。