APIキーをGitHubにpushしたら？流出時の対処手順

APIキーや秘密鍵をGitHubの公開リポジトリにpushしてしまったら、最初にやることは「ファイルを消す」ではなく「キーを無効化して再発行する」です。公開リポジトリは、秘密情報を探すボットに常時巡回されていて、pushから数分以内に拾われることが実験でも確認されています。そして一度pushしたキーは、ファイルを削除してもコミット履歴に残り続けます。

この記事では、流出直後の対処を優先順に手順化し、Git履歴からの完全削除、被害を限定する上限設定、再発防止の仕組み、公開前チェックリストまでを解説します。

まず落ち着いて：やることの優先順位

流出に気づいたときの行動順です。上から順に、飛ばさずに進めてください。

1. キーを無効化（失効）して、新しいキーを再発行する ← 最優先。数分で終わる
2. 利用状況と請求を確認する — 不正利用がすでに始まっていないか
3. 上限・アラートを設定する — 被害の拡大を止める
4. Git履歴からキーを完全に削除する — 痕跡を消す
5. 新しいキーを安全な場所に移し、再発防止の仕組みを入れる

「消してからキーを変えよう」は順番が逆です。消す作業をしている間にも、キーは生きています。

ステップ1：キーを無効化して再発行する

各サービスの管理画面（ダッシュボード）で、該当のキーを失効（revoke / delete）し、新しいキーを発行します。無効化した瞬間から、漏れたキーは使えなくなります。

• クラウド（AWS等）のアクセスキー — IAMの画面でアクセスキーを「無効化」→「削除」。該当ユーザーに付いている権限も確認する
• AIサービス・SaaSのAPIキー — APIキー管理画面で該当キーを削除し、新規発行
• 決済サービスの秘密鍵 — 管理画面でロールしてから旧キーを失効。Webhookの署名秘密も忘れずに
• DBの接続パスワード — パスワードを変更し、接続元の制限（IP等）を確認
• OAuthのクライアントシークレット — シークレットを再生成

再発行した新しいキーは、絶対にコードに書かず、ステップ5の方法で保管します。

ステップ2：利用状況と請求を確認する

無効化したら、漏れていた期間に不正利用がなかったかを確認します。

• 利用量のグラフに、自分の使い方と合わない急増がないか
• 見覚えのないリソース（インスタンス・ストレージ・APIコール）が作られていないか
• 請求額の予測が異常になっていないか

不正利用の痕跡があれば、サービスのサポートに「キー漏洩による不正利用」として連絡します。状況によっては請求の相談に応じてもらえる場合があるため、記録（気づいた時刻・無効化した時刻・不正利用の内容）を残しておきます。

ステップ3：上限とアラートを設定する

次に同じことが起きても被害が膨らまないよう、「使いすぎたら止まる」仕組みを先に入れます。

• 利用上限（ハードリミット） — 月額の上限を設定し、超えたら自動停止
• 予算アラート — 上限の50%・80%で通知が来るように
• キーごとの権限を最小に — 読み取りしか要らないキーに書き込み権限を付けない。IPやドメインで利用元を制限できるサービスは制限する

「気づける」より「止まる」を優先するのが、個人の財布の守り方です。

ステップ4：Git履歴からキーを完全に削除する

ファイルからキーを消してコミットしても、過去のコミットにはキーが残っています。 履歴そのものを書き換える必要があります。

方法A：git filter-repo（推奨）

# インストール（例: pip）
pip install git-filter-repo
# 特定ファイルを全履歴から削除
git filter-repo --path .env --invert-paths
# 特定の文字列を全履歴から置換（キー文字列を直接消す場合）
# replacements.txt に  sk-abc123...==>REMOVED  の形式で記述
git filter-repo --replace-text replacements.txt

方法B：BFG Repo-Cleaner

Java製のツールで、大きなリポジトリでも高速です。bfg --replace-text passwords.txt のように使います。

書き換え後に必ずやること

1. 強制pushで反映する — git push --force --all および git push --force --tags
2. 他のクローンにも周知する — チームメンバーの手元には古い履歴が残っているので、再クローンしてもらう
3. フォークとキャッシュに注意 — 誰かがフォークしていれば、そちらには残ります。GitHubのサポートに「機密情報のキャッシュ削除」を依頼できる場合があります

そして最も大切な前提：履歴を消しても、すでに拾われたキーは無効化しない限り生きています。 ステップ4は「痕跡を消す」作業であって、「安全にする」作業はステップ1です。

ステップ5：再発防止の仕組みを入れる

環境変数と.envファイル

キーはコードに書かず、環境変数から読み込みます。ローカル開発では .env ファイルに置き、ライブラリ（dotenv等）で読み込むのが定番です。

# .env（このファイルはコミットしない）
API_KEY=sk-新しいキー
DATABASE_URL=postgres://...

.gitignoreで除外する

# .gitignore
.env
.env.*
*.pem
*.key
credentials.json

.env.example のような「キーの値を空にした見本」をコミットしておくと、チームメンバーが何を設定すべきか分かります。

pushする前に自動検査する

• git-secrets / gitleaks / trufflehog — コミット前にキーらしき文字列を検出して止めるツール。pre-commitフックに組み込む
• GitHubのシークレットスキャン — 公開リポジトリでは自動で有効。プッシュ保護を有効にすると、キーを含むpushをブロックできる

本番はシークレットマネージャーへ

本番環境では .env ではなく、クラウドのシークレット管理サービス（AWS Secrets Manager、GCP Secret Manager等）や、CI/CDのシークレット機能に保管し、実行時に取り出す形にします。

AIで開発している人が特に注意すべきこと

AIにコードを生成させると、サンプルとしてキーを直書きした形で出力されることがあります。「動く例」として提示されるため、そのままコピーしてpushしてしまう事故が起きやすい。

対策は、AIへの依頼時に「APIキーは環境変数から読み込む形で書いて」と明示することです。CLAUDE.mdのような設定ファイルを使っている場合は、「秘密情報をコードに直書きしない」をルールとして書いておくと、毎回言わなくて済みます。

公開前チェックリスト

• ☐ コード内に sk- AKIA password= などの文字列が残っていないか検索した
• ☐ .env が .gitignore に入っている
• ☐ .env.example を用意し、実際の値は入っていない
• ☐ キーごとに利用上限とアラートを設定した
• ☐ キーの権限を必要最小限に絞った
• ☐ シークレット検出ツールをpre-commitに入れた
• ☐ 過去のコミット履歴にキーが含まれていないか確認した（git log -p | grep など）

よくある質問

Q. プライベートリポジトリなら大丈夫ですか？ A. 公開リポジトリより危険は小さいですが、安全ではありません。将来公開に切り替えたとき、共同編集者のアカウントが侵害されたとき、履歴ごと漏れます。プライベートでも同じ運用が必要です。

Q. 数秒で消したので、拾われていないと思います。 A. 巡回ボットは秒単位で動いています。「拾われたかどうか」を確認する手段はないので、時間に関係なく無効化が正解です。無効化はコストがほぼゼロで、しない理由がありません。

Q. 履歴を書き換えると、チームに迷惑がかかりませんか？ A. かかります。だからこそ、周知と再クローンの依頼をセットで行ってください。迷惑と、キーが残り続けるリスクを比べれば、書き換える方が正解です。

Q. 一度流出したキーは、無効化すれば完全に安全ですか？ A. そのキーでの不正アクセスはできなくなります。ただし、漏洩期間中に取得されたデータや作られたリソースは別途確認が必要です（ステップ2）。

まとめ

APIキー流出の対処は、「消す」より先に「殺す」——無効化と再発行が最優先です。そのあとに請求の確認、上限設定、履歴の完全削除、再発防止の順で進めます。

株式会社RJCが携わる保険・金融・決済のシステムでは、秘密情報の扱いは「注意点」ではなく「設計の前提」です。個人開発でも同じ守り方をしておくと、そのまま実務で通用する習慣になります。