この記事で覚えてほしいのは、この1枚だけです。「早く見つかる」「消しても残る」「だから鍵を替える」「次からは貼る前に止める」。以下の章は、この絵の中身を1つずつ確かめていきます。

APIキーは、プログラムがクラウドやAIのサービスに入るための合鍵です。人間のパスワードと違って、持っている人を「本人かどうか」確かめないことがほとんど。鍵を持っている人＝入ってよい人として扱われます。

その合鍵を、GitHubの公開リポジトリに置くのは、世界中の人が通る町の掲示板に合鍵を貼るのと同じです。しかもこの掲示板には、合鍵だけを探して24時間見回っている人たちがいます。

※厳密には違う部分もありますが、最初の理解としてはこの絵で十分です。たとえば「非公開リポジトリ」は掲示板ではなく社内の回覧板ですが、回覧板も外に持ち出されることがあります（事例1）。

このたとえで考えると、正しい行動は自然に分かります。貼ってしまった合鍵に気づいたら、掲示板から剥がしに走るより、錠前を替えるのが先。定点カメラの写真や、もう誰かが持ち帰った合鍵は、剥がしても消えないからです。

出典：GitGuardian「The State of Secrets Sprawl 2026」（2026年3月）、Palo Alto Networks Unit 42（2023年10月）。「秘密」はAPIキー・トークン・パスワードなどの認証情報のこと。

1. 鍵をファイルに書く。動作確認のためにコードへ直書きしたり、.env や設定ファイルに書いたりする。AIに書かせたサンプルコードに、そのまま貼っていることもある。
2. git add . で全部入れる。.gitignore を作り忘れている、または .env を除外し忘れている。
3. コミットする。この瞬間、鍵はGitの履歴に刻まれる。あとでファイルを消しても、このコミットは残る。
4. push して公開される。公開リポジトリなら、その瞬間から世界中が読める。非公開リポジトリでも、公開設定のミス・メンバーの持ち出し・委託先経由で外に出ることがある。
5. 自動収集プログラムが拾う。公開された更新を監視し、鍵らしい文字列を探す仕組みが常に動いている。数分の勝負。
6. 使える鍵だけが悪用される。クラウドなら採掘用サーバーを立てて高額請求、AIのキーなら他人の利用料で使い放題、データベースなら情報の持ち出し、パッケージ公開用のキーなら不正な版の配布（サプライチェーン攻撃）につながる。

鍵が紛れ込みやすい場所

どちらも無料で使えるオープンソースの「秘密（シークレット）スキャナー」です。GitHub上の星の数はどちらも3万前後（2026年9月30日時点で約2.96万と約2.82万）。よく比べられますが、得意な場面が違います。

順番が大事です。まず過去の棚卸しで「もう貼ってしまった鍵」を見つけ、次にコミット前の自動チェックで「これから貼る鍵」を止めます。

ステップ1：インストール

ダウンロードは必ず公式リポジトリ（github.com/gitleaks/gitleaks、github.com/trufflesecurity/trufflehog）のReleasesから。似た名前の偽ツールに注意してください。

ステップ2：過去をまるごとスキャンする

結果の読み方（gitleaksの例）

表示項目は公式READMEの出力例に沿った説明用です（値は架空）。

見るべきはFile・Commit・Dateの3つ。「どのファイルに・いつから・今も最新版に残っているか」が分かれば、どれだけの期間、外から見えていたかを判断できます。TruffleHogでは Found verified result と出たものが「今も開く鍵」です。

ステップ3：次からコミット前に自動で止める

一番おすすめなのは、pre-commit（コミットの直前に検査を走らせる仕組み）にgitleaksを組み込む方法です。リポジトリの一番上に .pre-commit-config.yaml を作ります。

そのあと pre-commit install を1回実行すれば準備完了。以後、鍵を含むコミットをしようとすると次のように止まります。

検査の対象はこれからコミットする変更だけなので、速く終わります。なお SKIP=gitleaks git commit … で検査を飛ばせますが、これは本当にダミーだと分かっているときだけにしましょう。

ステップ4：GitHub側の「最後の網」も確認する

GitHubには、公開リポジトリへ鍵をpushしようとすると止める「Push protection for yourself（自分用のプッシュ保護）」があり、既定でオンです。設定画面の「Code security」で Enabled になっているかを確認しておきましょう。ただし前の章のとおり、止まるのは対応している種類の鍵だけです。手元のgitleaks＝1枚目の網、GitHub＝2枚目の網と考えます。

0〜2個：今の習慣を続けつつ、コミット前チェックだけ入れておきましょう。3〜5個：今日、過去の履歴を1回スキャンしてください。6個以上：スキャンに加えて、使っていないキーの無効化と、残すキーの権限の見直しまでやりましょう。

クイズ：こんなとき、どうする？

まず自分の状況を選んでください。

• A. コミットしたが、まだpushしていないコミットをやり直せばOK（クイズQ4）。外に出た可能性がなければ交換は不要。
• B. 非公開リポジトリにpushした鍵を交換する。リポジトリを見られる人・CI・委託先の範囲も確認。
• C. 公開リポジトリにpushした分単位で動く。下の手順①を今すぐ。使われた前提で②まで進める。
• D. 身に覚えのない請求・操作がある①②に加え、サービスの窓口（AWSならサポートケース）と社内のインシデント対応へ。

1. 鍵を止める（最優先）。発行元の管理画面でキーを無効化・削除し、新しいキーを発行してアプリを差し替える。GitHubのトークンなら設定画面から削除（revoke）。
2. 使われていないか確かめる。利用履歴・請求額・ログを確認。AWSなら操作の記録（CloudTrail）と、見知らぬ地域のサーバーがないか。詳しくはクラウドのログ調査の記事を参照。
3. コードから外す。鍵は .env などに移し、.gitignore に登録。本番はクラウドの秘密情報の保管サービスやCIの「シークレット」機能で渡す。
4. 必要なら履歴から消す。git filter-repo（--sensitive-data-removal が使える2.47以上）で書き換えて強制push。ただし他人の複製やフォークは消せない。GitHub上のキャッシュ表示やPRの参照は、GitHubサポートに削除を依頼できる。
5. 次から防ぐ。前の章のコミット前チェックを入れ、チーム全員に広げる。

会社の場合は、個人で抱え込まず報告するのが鉄則です。初動の考え方はインシデント発生から最初の30分にまとめています。

1. 自分のリポジトリを1回スキャンする。gitleaks git -v --redact か trufflehog git file://. --results=verified,unknown。見つかったら、verified（生きている鍵）から順に交換。
2. コミット前に止める仕組みを入れる。pre-commitにgitleaksを登録し、GitHubの「Push protection for yourself」がEnabledかも確認。チームなら全員の環境に。
3. 「漏れても被害が小さい鍵」にする。鍵は .env に置いて .gitignore で除外。権限は必要最小限、利用上限や有効期限を設定。使っていない鍵は今日消す。

GitHubの基本操作に不安がある人は、先にGitHub入門も読んでおくと、この記事のコマンドが分かりやすくなります。

gitleaks（v8.30.1）

TruffleHog（v3.97.9）

GitHub側の仕組み（2026年9月30日時点のドキュメント）

AWSの隔離ポリシー

AWSは、IAMユーザーの認証情報が漏れた・公開されたと判断すると、管理ポリシー AWSCompromisedKeyQuarantineV3（2024年8月作成、2026年3月更新）を付けます。インスタンスの起動、IAMの変更、S3の読み書き、Bedrockのモデル呼び出しなどを拒否し、不正な課金を抑える目的です。公式説明は「このポリシーを外さず、作成されたサポートケースの指示に従う」。Unit 42の実験当時はV2でした。

Betterleaks（gitleaksの後継）

gitleaksの作者を含むメンバーが開発。MITライセンス、2026年2月公開。正規表現に加えて、鍵が生きているかの確認（-v／--validate）、権限の分析（-a／--analyze）、任意の無効化、GitHub・GitLab・Hugging Face・S3などの読み込みに対応。2026年9月時点で main はv2開発中で、パッケージ管理ツールやDockerの latest はまだv1を返す場合があると案内されています。新規導入なら比較候補に入れる価値があります。

数字の出どころ（GitGuardian 2026年版）

2025年に公開GitHubのコミットへ新たに加わった秘密は2,865万件（前年比34%増、過去最大の伸び）。AI関連サービスの秘密は1,275,105件（81%増）で、伸び率上位10種のうち8種がAI関連。2022年に有効だった秘密の64%が2026年1月時点でも有効。社内リポジトリは公開リポジトリより約6倍秘密を含みやすい。いずれもGitGuardian社の独自集計で、検出方法は同社のものです。