技術別対策

gitleaksでコミット前に秘密を止める：APIキー漏洩をpushの前で食い止める

APIキーや秘密鍵をうっかりコミットしてpushすると、消しても履歴に残り『漏れた前提』で失効が必要になります。gitleaksはリポジトリとコミット履歴をスキャンして秘密を検出するツール。pre-commitフックでローカルのpush前に止め、CI/cronですり抜けを捕まえる二段構えの組み方と、検出後にやるべき失効までを、当サイトの運用視点で解説します。

公開日 2026-06-12 更新日 2026-06-12 9分で読める

対象：個人開発・小規模運営でGitを使っていて、「APIキーをうっかりコミットしないか不安」という人。攻撃側の手口は扱わず、自分のリポジトリから秘密の流出を止める仕組みだけを扱います。

当サイトの視点：.gitignore だけでは秘密は守れない

「.envを.gitignoreに入れているから大丈夫」とよく言われますが、これは穴があります。.gitignoreは新しく追跡対象に入れないだけで、既にコミット済みの秘密や、急いでgit add -fで強制追加した秘密、.env.local.bakのような想定外のファイル名は捕まえられません。gitignoreは「入口の一部」を塞ぐだけ。実際にコミット内容を見て「秘密らしい文字列」を検出する仕組み——つまり検出器が別に要ります。それがgitleaksの役割です。

なぜ「コミット前」で止めるのか

秘密が危険なのは、Gitが履歴を永久に保持するからです。最新のファイルから消しても、過去のコミットには残る。そしてpushされた瞬間、その履歴は他者の手元やサーバ、CIのログにも複製されます。

履歴に残る

最新から消しても過去コミットに残存

push＝拡散

他端末・サーバ・CIログに複製される

失効が必須

一度漏れた鍵は再発行しかない

2つの門

pre-commit と CI で二重に止める

つまり秘密対策は、漏れた後の回収ではなく漏れる前の阻止が本命です。これは「公開ディレクトリに秘密を置き忘れない」棚卸し（→ webrootの棚卸し）と同じ発想を、コードの世界に持ち込むものです。

止め所はどこか

秘密がコードから世界に出ていく経路には、2つの止め所を置けます。手元のコミット時と、共有される直前（CI）です。

コード内の秘密

APIキー・鍵・トークン

→

門1：pre-commit

コミット時にローカルで検出・中断

→

門2：CI / cron

push後にマージ/デプロイ前で検出

→

公開・共有

ここまで来たら漏れた前提

秘密の流出経路と2つの門。pre-commitはローカルで、CIはマージ/デプロイ前に止める。

gitleaksの組み込み方

まず既存の履歴をスキャンする

導入時に一度、リポジトリ全体の履歴を gitleaks detect でスキャンする。過去のコミットに眠っている秘密を洗い出すのが最初の仕事。ここで見つかったものは、後述のとおり失効が前提。

pre-commitフックで門1を作る

コミットのたびに gitleaks protect --staged を走らせ、秘密を含むコミットをその場で中断する。pre-commitフレームワーク（.pre-commit-config.yaml）に追加すると、チームでもローカルでも同じ検査が掛かる。

CI / cron で門2を作る

フックは各自が無効化できるため、共有される手前でもう一度検査する。CIのジョブ、あるいは自前運用なら定期的なスキャンとして gitleaks detect を回し、すり抜けを捕まえる（→ 依存監査と同じく機械監視の発想）。

誤検出は .gitleaks.toml で調整

テスト用のダミー鍵やサンプル値が引っかかったら、ルールやallowlistを .gitleaks.toml に書いて調整する。「黙らせる」のではなく「なぜ安全かを記録する」のが正しい運用——根拠のない除外は次の事故の温床になる。

検出したら『失効』が先、履歴の書き換えは後

一度コミット・pushされた秘密を見つけたら、最優先はその鍵・トークンの失効と再発行（ローテート）です。git filter-repo 等で履歴から消すのは大事ですが、それは『これ以上広げない』ための後処理にすぎません。公開リポジトリ・フォーク・CIログ・他人のクローンに渡った秘密は回収不能と考え、まず無効化してから履歴をクリーンにしてください。順番を逆にすると、消している間に使われます。

.gitignore 頼み

新規の追跡しか防げない
既にコミット済みの秘密は素通り
git add -f や想定外のファイル名に無力
「入れたつもりがない」を検証できない

gitleaks（検出＋失効運用）

作業ツリーと履歴の中身を実際に検査
pre-commitとCIの二段で止める
検出したら失効までを手順化
誤検出は根拠を記録して除外

当サイトはどうしているか

当サイトは、そもそも秘密をGitに一切入れない設計を土台にしています——接続情報やAPIキーはサーバ上の保護された設定（権限を絞った環境ファイル）にだけ置き、リポジトリにも引き継ぎ資料にも平文では残しません（→ 秘密をgitに入れない／自前Git vs GitHub）。その上で、人間は必ずミスする前提で検出器を重ねます。設計で「入れない」を担保し、gitleaksのようなスキャンで「入ってしまった」を捕まえる——この二層が、秘密漏えいに対する当サイトの守りです。秘密の扱いの原則そのものは .envと秘密情報やパスワードの安全な保管とも地続きです。

次に読む

よくある質問

Qgitleaksとは何ですか？

Gitリポジトリの作業ツリーとコミット履歴をスキャンし、APIキー・秘密鍵・トークンなどの秘密がコミットされていないかを検出する無料のツールです。正規表現のルールと文字列のエントロピー（ランダムさ）で『秘密らしい文字列』を見つけ、pre-commitフックやCIに組み込んで自動チェックできます。

Q.gitignoreに書いておけば秘密は守れますか？

不十分です。.gitignoreは『新しく追跡対象に入れない』だけで、既にコミット済みの秘密や、git add -f で強制追加された秘密は検出できません。gitignoreは事故の一部しか防げないので、gitleaksのような検出器をpre-commitとCIに入れて二重化します。

Qうっかり秘密をコミットしてpushしてしまったら？

その秘密は『漏れた前提』で扱います。最優先は履歴の書き換えではなく、漏れた鍵・トークンの失効とローテート（再発行）です。一度公開リポジトリやログに乗った秘密は回収できないと考え、まず無効化し、その後に履歴のクリーンアップと再発防止（gitleaks導入）を行います。