この記事の内容は、実際に2週間運用した結果に基づいています。完成品はOSSキットとして公開しています（cc-quality-gates）。

はじめに

AIコーディングエージェントに開発を任せていると、コミットが人間の手では追いつかないペースで積み上がります。筆者の環境では、並行して動く複数のエージェントセッションが30日で340コミット以上を積み上げます。

この状況で一番怖いのは、コードの品質でもバグでもなく、**「うっかり秘密情報（APIキー・トークン）を公開リポジトリにpushしてしまうこと」**です。一度公開されると、ボットが数分で拾って悪用されるため、削除では手遅れになります。

人間の目でレビューするのは物理的に不可能なので、公開の直前に自動で止める門番（ゲート）を自作しました。この記事は、その設計と2週間の運用実績の記録です。

結論（先に数字を）

項目	実績
運用期間	2週間（14日・push継続中に判定）
ゲートによる停止（block）	5件
うち正しい停止（真陽性）	5件（100%）
誤警報（誤block）	0件
全履歴スキャンでの検出	17件（うち実際の秘密は0件・ローテーション不要と判定）

「止めるべきものは確実に止め、無駄に止めない」——これが数値で確認できたので、本運用に昇格させ、キットとして公開しました。

設計：3層の門番

「1つの強い検知」に頼るのではなく、3つの役割を分担させる構成にしました。

[層1] pre-push hook …… 公開直前の関所（止める係）
[層2] GitHub Actions CI … 裏口対策（層1を迂回したpushも毎週全履歴を走査）
[層3] 人間のレビュー …… 文脈判定の委譲先（「これはテスト用ダミーか?」は機械に判断させない）

層1: push直前のフック

git push の直前に作動し、pushしようとしている差分だけを走査します（過去の全履歴を見ないので、昔のダミーデータで誤爆しません）。

探知機は次の2種類です。

gitleaks（有名なOSS）——数百種類の既知パターンで「本物っぽい鍵の形」を検知
自作の単純パターン——token = "16文字以上..." のような代入形式を自前でも検知（gitleaksのルール更新ラグの対策）

検知したらpushをブロックし、どこで引っかかったかだけを表示します。値そのものは表示しない（ログにも残さない）ので、ゲート自身が情報漏洩源になることもありません。

層2: CIによる最終防衛線

hookは --no-verify で迂回できてしまう、という正直な限界があります。そこでGitHub Actionsでも全pushと毎週1回の全履歴走査をさせ、迂回pushがCIでfailすることをテストで実証しておきました。

層3: 文脈判定は機械に持たせない

ここが設計上の一番大事な判断です。

「この token = ... は本物か、テスト用のダミーか?」という文脈判断をhookに実装しない。

文脈判定をhookに入れると誤検知が温床になり、ゲートが生活を止めてしまいます（並行セッション5本が日常の環境では致命的）。そこでhookは単純パターンに限定し、止められたら人間が確認して、ダミーなら書き方を変えて再pushする運用にしました。「形式を変えろ」というブロックメッセージ自体が、「意図的ダミーであることの自己申告」を促します。

2週間の運用で起きたこと

導入から14日間、pushを続けながら観察しました。5件のblockが発生しましたが、内訳は:

テスト用のモック鍵（E2Eテストで意図的に書いたもの）——正しく停止。書き方を変えて再push
テストフィクスチャ内のダミートークン——正しく停止。同じく形式変更で解決

つまり、全部が「鍵っぽい文字列が本当に混ざっていた」ケースで、無駄止まりはゼロでした。逆に言うと、自分でも気づかないうちに「鍵の形をした文字列」が日常的にコミットに入ってくる——だから自動ゲートが必要、という実測でもあります。

合わせて、警告レベルの記録（68件）も全件レビューし、ブロックに昇格させるべきものがないことも確認しました。

キット化して公開した

2週間の実績を受けて、これを誰でも導入できるキットとして公開しました。

👉 github.com/fukukei23/cc-quality-gates

git clone https://github.com/fukukei23/cc-quality-gates.git
cd cc-quality-gates
bash scripts/setup.sh     # gitleaksのパス等を質問に答えて設定
bash scripts/selftest.sh  # 導入が正しく効いているか5項目で確認（PASS=5期待）

selftest.sh は単なる構文チェックではなく、モック鍵を実際にコミットしてhookが発火するかまで確認します。加えて「.gitleaks.toml の設定で検出を無効化されたらどうなるか」というバイパス耐性テストも入っています（gitleaks層を設定で無効化しても、自作パターン層が止める二重構造を確認できます）。

公開までに起きた実際のトラブル（読者への共有）

Linux（WSL2）では完璧に動いたキットが、Windowsでは5件の問題で動きませんでした。同じ悩みを持つ人のために、対応を残しておきます:

問題	対応
gitの改行コード自動変換（LF→CRLF）でbashスクリプトが構文エラー	`.gitattributes` でスクリプトの改行をLF固定
Windowsは実行ファイルに `.exe` が付く	セットアップ/テストで拡張子を自動解決
初めてのPCにはgitのユーザー設定が無くテストコミットが失敗	設定が無い場合のフォールバックを追加
対話式セットアップが一部のターミナル経由で動かない	環境変数による非対話モードを追加

（開発中に実装ミスで「存在するgitleaksまで .exe に書き換える」バグも作り込みましたが、テストが実動作で捕捉してくれました。テストは書いておいて損になりません）

既知の限界（正直な申告）

token2 = ... のような接尾語付き変数名は、単純パターン層を素通りします（正規表現の単語境界の問題・CI層のgitleaksは拾う可能性があります）。文脈判定を入れない設計方針の代償として、正直にREADMEに書いています
hook単体は --no-verify で迂回できます（最終防衛線はCI側）

まとめ

AIエージェントが大量にコミットする環境では、秘密情報のうっかり公開は「起こる前提」で対策すべき
検知は1つの強いツールでなく、hook（止める）+ CI（裏口）+ 人間（文脈）の3層分担が現実的
導入して終わりではなく、2週間の運用データ（真陽性5・誤警報0）で効いていることを数字で確認してから本運用に昇格した

キットはこちらからどうぞ。issue / PRも歓迎です。

※ この記事自体も、公開前に記事本文への機微スキャン（gitleaks）を通しています。ゲートを語る記事がゲートをすり抜けたら笑えないので。

本記事は個人Zennでも公開しています。