LLM APIキーが漏れたかもしれない時の初動：失効・再発行・利用履歴の確認順

先に判断する:止めるのが先か、切り替えが先か

• 公開リポジトリ・公開チャット・スクリーンショットに全文が出た、先にやること：旧キーの無効化、理由：第三者が使える状態が続くため
• 利用履歴に身に覚えのないリクエストや急な増加がある、先にやること：旧キーの無効化、理由：被害が増え続けるため
• 社内の共有場所に貼った程度で、悪用の形跡はない、先にやること：新キー配備 → 切り替え → 旧キー無効化、理由：停止を避けつつ収束できる
• 退職者・委託先に渡していたキーの扱いが不明、先にやること：新キー配備 → 切り替え → 旧キー無効化、理由：同上。ただし日程は早めに決める

Claudeのコンソールでは「Disable」は元に戻せ(管理APIではinactive)、「Delete」は元に戻せません(archivedになります)。出典は上記Authenticationページです。疑いの段階では、まず無効化して様子を見るという選び方ができます。Google CloudのAPIキーは、削除後30日以内なら復元できます(公式ドキュメント)。漏洩が疑われるキーを誤って復元しないよう、復元操作の対象を確認してください。

初動チェックリスト(コピーして使えます)

□ 0. 発覚時刻・発覚経路・担当者をメモする(1分)
□ 1. 漏れた可能性のあるキーを特定する
     - キー全文は書かない。名前・末尾4文字・作成日・所属プロジェクトだけ記録
□ 2. 利用履歴の画面を開き、旧キー削除前に現状をスクリーンショットか書き出しで保存する
□ 3. 上の判断表で「無効化が先」か「切り替えが先」かを決める
□ 4. 新キーを作成する(用途ごとに別キー、可能なら有効期限・権限・制限を付ける)
□ 5. シークレット管理か環境変数を新キーに更新し、デプロイする
□ 6. 新キーでの実リクエスト成功を確認する
□ 7. 旧キーを無効化する(削除はログ保全後)
□ 8. 無効化後、旧キーでの呼び出しが失敗することと、サービスが無事なことを確認する
□ 9. 利用履歴を調べる(次の章)
□ 10. 漏洩元(コード、Gitの履歴、ログ、チャット、CI)を洗い出して掃除する
□ 11. 請求・上限アラートを見直し、再発防止を1つ決める

手順2を削除より前に置くのは編集上の提案です。削除後に画面から追えなくなる情報があるかはサービスにより異なるため、先に保存しておくと安全です。

利用履歴の確認:何を見て、何と照らすか

各社の確認場所は、次の範囲で確認できました。

• OpenAI:Usageページで利用状況を確認できます。2023年12月20日以降に作ったキーは追跡が有効とされています(上記Production best practices)。プロジェクトごとの絞り込みや「最終利用日」の表示有無は、開いたページに記述がなかったため、実際の画面で確認してください。
• Gemini:Google AI StudioのUsageページで、プロジェクト内の名前付きキーや「unknown keys」にまとめられたリクエストを確認します。請求ログやAPI利用状況もGoogle Cloudコンソールで確認し、請求アラートを設定します(上記Geminiドキュメント)。ただし認証キーのリクエストはサービスアカウント利用指標に記録されません。
• Claude:管理APIのキー一覧・取得で、キーの状態(status)と有効期限(expires_at)を確認できます(上記Authentication)。キー単位の利用量を確認できる方法は今回開いた公式資料では確認できませんでした。

見るべき項目は共通です。

• 日時の山、自社の正規利用と照らす材料：デプロイ履歴、バッチの実行時刻
• モデル名、自社の正規利用と照らす材料：自社が使っていないモデルが動いていないか
• 量(トークン・リクエスト数・費用)、自社の正規利用と照らす材料：通常の日次推移
• 利用元の識別情報(取得できる場合)、自社の正規利用と照らす材料：自社サーバーのIP、リージョン
• 漏洩が疑われる時刻より前の利用、自社の正規利用と照らす材料：発覚より前から使われていないか

AIに履歴の整理を手伝わせる場合

ログやコンソールの数値を貼って整理させる時は、キー全文・顧客ID・プロンプト本文は伏せてください。以下は説明用の入力例で、実行結果ではありません。

次はAPI利用履歴の抜粋です(キーは末尾4文字のみ、数値は説明用の例)。
- 10/24 09:00-18:00 通常:約200 req/日、モデルA
- 10/25 03:10-03:40 約4,000 req、モデルB(自社未使用)
自社のデプロイ予定は10/24 09:00のみです。
1. 不審と判断できる点と、通常と判断できる点を分けてください。
2. 断定できない点は「追加で確認すべきログ」を挙げてください。

AIは整理役にとどめ、「被害なし」の判定は人が一次ログで行ってください。

キー交換時の切り替え手順メモ

サービスを止めずに交換する場合のメモです。

1. 新キーを作る:旧キーと同じ権限・制限を付けます。Google Cloudの手順でも、旧キーと同じ制限を付けた新キーを作ってからアプリを更新し、旧キーを削除する流れです。
2. キー名に日付を入れる(例:prod-chat-2026-10)。どの世代か後から分かります。
3. 保管場所を更新する:シークレット管理か環境変数を新キーに差し替えます。OWASPのSecrets Management Cheat Sheetも、漏れた秘密の失効・ローテーション・露出箇所からの削除を挙げています。
4. 段階的にデプロイする:全台ではなく1台か一部のワーカーで先に新キーを使い、実リクエストが通ることを確認します。
5. 全体を切り替える:ログには新キーの末尾4文字だけを出し、旧キーで動いている箇所が残っていないか見ます。
6. 旧キーを無効化する:Claudeの「Disable」のように戻せる操作があれば先にそれを使い、問題が出ないか一定時間見てから削除します。待つ時間は自社の定期バッチの周期に合わせて決めてください。
7. ロールバック条件を決めておく:新キーでエラーが出た時に旧キーへ戻せるのは、旧キーが「疑いの段階」の時だけです。漏洩が確実なら戻さず、新キーの設定側を直します。

漏洩元の掃除で見落としやすい場所

• Gitの履歴:現在のファイルから消しても、過去のコミットには残ります。OWASPは、履歴の書き換えが他のコミット参照を壊す可能性があるため、影響を計画するよう説明しています。まずキーを失効・ローテーションし、露出したコードやログから秘密を取り除いてください。
• CIのログ・ビルド成果物・コンテナイメージ
• クライアント側コード:ブラウザやモバイルアプリにキーを埋め込まず、バックエンドを経由する形が推奨されています(Geminiドキュメント)。
• チャット、チケット、スクリーンショット、AIアシスタントに貼ったログ

再発防止は、まず1つに絞るのが現実的です。たとえば、キーを環境ごとに分けて有効期限を付ける、請求アラートを置く、Claudeなら静的キー自体を減らせるWorkload Identity Federationを検討する、などです。