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

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

Claude APIキーが漏れたかもしれないときに、Consoleで削除して再発行するまでの手順と、再発を防ぐキー管理の実践をまとめます。

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

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

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

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

初動は、キーの即時失効です。手順は次のとおりです。

  1. Claude Consoleにログインする
  2. プロフィールからAPI keysページを開く
  3. 対象キーの右にある三点メニューを開く
  4. 「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のシークレットスキャンのパートナープログラムに参加しています。流れは次のとおりです。

  1. GitHubが公開リポジトリに載ったClaude APIキーを検出する
  2. GitHubがAnthropicに通知する
  3. Anthropicが露出したキーを自動で無効化する
  4. 該当ユーザーにAnthropicから詳細なメールが届く

対象は「公開」リポジトリです。プライベートリポジトリ、社内チャット、外部ツールへの登録での漏洩は、この経路では拾われません。自動失効のメールを受け取った場合も、新しいキーの保管方法と、ほかに漏れた箇所がないかの確認は自分で行います。失効したキーを使っていたスクリプトやサービスは、新しいキーに差し替えるまで認証できなくなります。差し替え先の設定場所を先に洗い出しておくと、復旧が早く済みます。

新しいキーを安全に持つ

再発行したキーは、コードに直書きせず環境変数で渡します。ローカル開発の例は、.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

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

項目内容
共有しない内容他の人がClaude APIを使うなら、その人が自分のキーを取得する
外部ツールの選別内容外部サービスにキーを預けることは、そのサービスの開発元にConsoleアカウントへのアクセスを渡すのと同じ。信頼できないなら預けない
暗号化シークレット内容サードパーティ側には暗号化されたシークレットとして登録し、コードや設定ファイルに直書きしない
定期ローテーション内容例として90日ごとに新規作成と旧キーの無効化を行う
用途ごとに分離内容開発・テスト・本番でキーを分ける。漏れたときにその用途だけ止められる
リポジトリのスキャン内容ソース管理側のシークレットスキャン、Gitleaksなどのツール、CI/CDへの組み込み
KMSの利用内容キーが増えたら、集中管理・アクセス制御・監査証跡・ローテーションを備えた仕組みへ

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

削除で止まるものを、平時に洗い出しておく

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

  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/**)"
    ]
  }
}

このルールは、Grepなど組み込みの読み取りツールにもベストエフォートで適用されます。ベストエフォートなので、あらゆる経路を完全に塞ぐ保証ではありません。キー自体を持たない構成に寄せる方が確実で、その選択肢はClaude APIの認証方式まとめとWorkload Identity Federation(WIF)とはで整理しています。

よくある質問

キーを削除すると、そのキーを使っているアプリはどうなりますか。

そのキーを使うリクエストは通らなくなります。新しいキーを発行してアプリの環境変数を差し替えるまで、そのアプリからのAPI呼び出しは止まります。

まとめ

漏洩が疑われるときの順番は、キーの削除、新しいキーの発行と安全な保管、ログと使用量の確認です。それでも不審な動きが続くならサポートに連絡します。

日頃は、環境変数とシークレット管理、用途ごとのキー分離、定期ローテーション、リポジトリのスキャンで露出を減らします。支出上限や自動リロードの設定は、漏れたときの被害額を決める最後の歯止めです。

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