その commit、本当に安全？ コーディングエージェント時代に Git Hook で情報流出を防ぐ方法

こんにちは、AI に git 操作を任せるのが便利すぎて、逆にちょっと怖くなってきたアーキテクトのやまぱん！です 😅
補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！

TL;DR

• Git Hook と GitHub Copilot Hooks は別物です。今回の repo は ローカルで動く Git Hook を使います
• この repo の要所は、Git Hook を入口にして AI にセキュリティチェックさせる ところです
• pre-commit で staged diff を GitHub Copilot CLI に渡し、危ない変更なら commit を止めます
• AI にコードを書かせたり git 操作まで任せたりするなら、ローカルで最後に止める関所 があると安心しやすいです
• GitHub Copilot Hooks は、Copilot のセッションやツール呼び出しに割り込む仕組みです。今回の repo とは近いけれど、役割は少し違います

先に結論

今回の repo、ひとことでいうと 「Git Hook を使って AI に事前セキュリティチェックさせるローカル関所」 です。

いまは vibe coding っぽく、AI にコード生成だけでなく git add や git commit まで任せる流れが増えました。でも、その便利さの裏で「その変更、本当にそのまま commit して大丈夫？」という不安も出てきます。

そこで効くのが、push した後ではなく、手元の commit 前に止める 仕組みです。今回の GHCP_GitHook_Sec_demo は、Git Hook を入口にして staged diff を AI にレビューさせ、危ない変更ならその場で止めるところまでを初心者でも試しやすい形にしたデモです。

「でも自分には関係ない話では？」と思った人に、ちょっと怖いニュースを置いておきます。

2026年5月、CISA（米国サイバーセキュリティ・インフラセキュリティ庁）が GitHub でシークレットを流出させました。
セキュリティの専門機関が、「Private-CISA」という名のパブリックリポジトリに AWS GovCloud の管理者キー・平文パスワード・RSA 秘密鍵などを 2025年11月から約6ヶ月間 公開し続けていたことが発覚しました。GitGuardian が発見し、CISA は26時間以内にリポジトリを削除しましたが、削除後48時間たっても有効な認証情報が残っていたとの報告もあります。議会は事態の説明を要求しています。

参考: Dark Reading - CISA Exposes Secrets, Credentials in 'Private' Repo (2026/05/19)

シークレット情報の誤 commit は「うっかり」で起きます。AI にコードや git 操作まで任せる環境では、その「うっかり」が起きる機会はむしろ増えます。ローカルで早めに止める仕組みが効いてくる理由が、この事例に凝縮されています。

まず押さえたい: Git Hook と GitHub Copilot Hooks は別物です

Git Hook も GitHub Copilot Hooks も、どちらも「何かのタイミングで処理を差し込む」仕組みです。でも、差し込む先が違います。

仕組み	どこで動く？	いつ動く？	主な用途
Git Hook	ローカル PC、または Git サーバー	commit、push など Git コマンド実行時	commit 前の lint、秘密情報チェック、メッセージ整形
GitHub Copilot Hooks	Copilot CLI や Copilot クラウドエージェントの実行中	sessionStart、userPromptSubmitted、preToolUse など	エージェントの動作制御、ツール許可/拒否、監査ログ、通知

今回使っているのは Git Hook の pre-commit です。Git の commit ライフサイクル に割り込んで、コードがまだ手元にある段階でセキュリティチェックをかけます。

ここは単純で、git commit を叩くのが人でもエージェントでも、Git を呼ぶなら同じ Hook が動きます。手で commit する人にも、エージェントに commit させる人にも効きます。

• Git Hook は、まだ push していない変更を見られます
• GitHub Copilot Hooks は、Copilot がセッションを始めた、プロンプトを受け取った、ツールを使おうとした、といった エージェントのライフサイクル に割り込みます
• 「AI がいま commit しようとしている差分を止めたい」なら Git Hook、「Copilot がどのツールを使うか制御したい」なら GitHub Copilot Hooks です

Git Hook にはどんな Hook があるの？

Git の公式ドキュメントでは、Hook は .git/hooks 配下に置くプログラムとして説明されています。代表的なものだけ抜くと、こんな感じです。

Hook	タイミング	代表ユースケース
pre-commit	commit を作る直前	lint、secret 検知、セキュリティチェック
prepare-commit-msg	commit message を編集する前	message のひな形差し込み
commit-msg	commit message 確定前	Conventional Commits の強制
pre-push	push の直前	test 実行、ブランチ保護の補助
post-merge	merge / pull の直後	依存関係更新、生成物再作成
pre-rebase	rebase の前	rebase 禁止ルール、保護ブランチの事故防止
pre-receive / update / post-receive	サーバー側で push 受信時	組織ルール適用、監査、通知

このデモが pre-commit を選んでいるのは自然です。いちばん早く止められる からです。

pre-commit と commit-msg、どっちが向く？

ここは混ざりやすいので、先に切り分けます。

Hook	向いていること	今回のテーマとの相性
pre-commit	staged diff の確認、secret 検知、脆弱性確認	◎
commit-msg	commit message の形式チェック、命名規約	△

commit-msg でも技術的には staged diff を見られますが、役割としては commit message を整えるフェーズ です。今回みたいに「危ない差分を commit 前に止めたい」という用途なら、責務が素直なのは pre-commit です。

逆に commit-msg が向くのは、Conventional Commits を強制したい、チケット番号を必須にしたい、といった メッセージ側の gate です。

pre-commit と pre-push、どちらが向く？

AI の使い方や開発スタイル、commit の細かさによっては、pre-commit ではなく pre-push を選ぶ考え方もあります。

Hook	向いているケース	気をつけたい点
pre-commit	AI が高頻度でコードや git 操作を触る、小さく頻繁に commit する、危ない差分を早く止めたい	commit のたびに走るので、重いチェックだとテンポは落ちやすい
pre-push	commit は細かく積みたい、重めのチェックを毎 commit では回したくない、push 前にまとめて見たい	すでにローカル commit は作られているので、手戻りが後ろに寄りやすい

ここでは、pre-commit を軽い早期チェック、pre-push を重めの最終確認、と使い分ける方針でよいです。

ただ、今回みたいに 「AI が作った危ない差分を、できるだけ早く止めたい」 というテーマなら、pre-commit のほうが合っています。

理由は単純で、pre-push だと危ない変更がいったんローカルの commit 履歴には残るからです。もちろん push される前には止められますが、push 直前にまとめて落ちると、どの commit をどう直すかの手戻りが少し大きくなります。

特に AI を高頻度で使っていて、細かい差分がどんどん積まれる開発スタイルだと、あとでまとめて止めるより、その場で小さく止める ほうが扱いやすいです。

• まずは pre-commit で早めに止める
• もしチェックが重い、あるいは運用上まとめて見たいなら pre-push も候補にする
• 本番運用では、さらに GitHub Actions 側の後段チェックも重ねる

GitHub Copilot Hooks にはどんな Hook があるの？

GitHub Docs では、Copilot Hooks は エージェント セッションの戦略的なポイントでカスタム シェル コマンドを実行する仕組み と説明されています。

Copilot Hook	いつ動く？	代表ユースケース
sessionStart	セッション開始時	初期化、監査ログ開始、環境確認
sessionEnd	セッション終了時	後片付け、ログ保存、通知
userPromptSubmitted	ユーザーがプロンプトを送った時	プロンプト監査、使用状況分析
preToolUse	Copilot がツールを使う前	許可/拒否、危険操作ブロック、ポリシー適用
postToolUse	ツール実行後	結果ログ、追加コンテキスト注入
agentStop	メインエージェントがターンを終える時	終了条件チェック、次ターン強制
subagentStop	サブエージェント完了時	サブエージェント結果の評価
errorOccurred	エラー発生時	エラー記録、通知、復旧ガイダンス

さらに CLI では、もう少し運用寄りのフックも使えます。

CLI でよく見る Hook	役割
permissionRequest	ツール許可フローを短絡して allow / deny する
notification	通知に反応してメッセージや追加コンテキストを入れる
preCompact	コンテキスト圧縮前の通知や制御

イベントとは別に、フックの構成タイプ もあります。

構成タイプ	何をする？	メモ
command	シェル コマンドやスクリプトを実行する	いちばん基本。CLI と cloud agent の両方で使える
http	JSON を HTTP POST で外部 URL に送る	cloud agent では許可リストやネットワーク制限に注意
prompt	テキストやスラッシュコマンドを自動送信する	sessionStart のみ。CLI で特に分かりやすい

配置場所も Git Hook とは違います。GitHub Copilot Hooks は、リポジトリなら .github/hooks/*.json、Copilot CLI の個人設定なら Windows では %USERPROFILE%\.copilot\hooks\、macOS / Linux では ~/.copilot/hooks/ に置きます。

Git Hook は .git/hooks/ で Git に差し込むフック、GitHub Copilot Hooks は .github/hooks/*.json や ~/.copilot/hooks/ で Copilot に差し込むフック です。

Webhook と Actions は別の層です

GitHub Webhook と GitHub Actions は GitHub 上で起きたイベント起点の自動化 です。

• Webhook: GitHub から外部 URL へ通知する
• Actions: GitHub 上の workflow を起動する

整理すると「Git Hook は Git に差し込む」「Copilot Hooks は Copilot に差し込む」「Webhook / Actions は GitHub 上のイベントに反応する」という 3 層です。今回の repo は一番左の層を使っています。

この repo は何をしてくれるの？

GHCP_GitHook_Sec_demo は、Git の pre-commit Hook から GitHub Copilot CLI を呼び出して、staged diff に対するセキュリティレビューを実行するデモです。

GitHub Copilot Hooks のデモではありません。 Git Hook から Copilot CLI を呼んでいるデモです。

危ない変更が見つかれば、Hook が SECURITY_CHECK: FAIL と判定して commit を止めます。問題がなければ SECURITY_CHECK: PASS でそのまま commit が通ります。

見ているのは、次のような代表的なリスクです。

• SQL injection
• command injection / unsafe shell execution
• XSS / unsafe HTML rendering
• SSRF / arbitrary outbound requests
• hardcoded secrets や insecure defaults

「全部を完璧に見つける万能セキュリティ製品」ではありません。でも、AI が雑に書いた危ない差分を、ローカルで踏みとどまる ための関所としては使えます。

処理の流れ

出典: GHCP_GitHook_Sec_demo - https://raw.githubusercontent.com/aktsmm/GHCP_GitHook_Sec_demo/main/outputs/pre-commit-flow.drawio.svg

流れはこうです。

1. git commit を実行する
2. pre-commit Hook が起動する
3. staged diff を集める
4. PowerShell スクリプトが GitHub Copilot CLI にレビューさせる
5. PASS なら commit 継続、FAIL なら stop

Git Hook を AI レビューの入口にしている。そこがこのデモの芯です。

なぜ GitHub Copilot Hooks ではなく、Git Hook なのか

GitHub Copilot Hooks も便利です。実際、preToolUse なら危険なツール実行を止められますし、userPromptSubmitted なら監査ログも取れます。

でも今回やりたいのは、Copilot の内部ツール実行を制御することより、Git の staged diff そのものを見て commit を止めること です。

• AI が今まさに commit しようとしている
• その差分がまだローカルにしかない
• GitHub に出す前に止めたい

この要件だと、Git Hook のほうが合っています。

もう 1 つ大きいのは、Git Hook は Git に差し込む仕組みなので、GitHub Copilot 固有になりにくい ことです。いまは GitHub Copilot CLI を呼んでいますが、最終的に git commit を叩く別の coding agent に置き換わっても、Hook 側の考え方はそのまま持っていけます。

特にローカル coding agent の実験では、「まず自分の PC だけで安全弁を試せる」 のが大きいです。Copilot のセッションライフサイクルに乗るよりも、今回は Git の commit ライフサイクルに乗せるほうが目的にまっすぐなんですよね。

あと、少しユーモアっぽく言うと、自分の失敗ってあまり他の人に見せたくない じゃないですか。

AI がうっかり危ないコードや雑な差分を作ったとしても、それをまず自分の PC の中でチェックして止められるなら、少なくとも「とりあえず remote に出してから慌てる」よりはだいぶ平和です。

セキュリティの話としてももちろん意味がありますが、それと同時に 「失敗をローカルで小さく閉じる」 ための使い方もできるんですよね。

実際に Copilot CLI へどんな指示を渡しているの？

scripts/security_check.ps1 の中では、staged diff と一緒に 具体的な prompt を GitHub Copilot CLI へ渡しています。要点を抜粋すると、こんな形です。

You are performing a strict pre-commit security review for staged code changes.

Review these categories at minimum:
1. SQL injection
2. Command injection / unsafe shell execution
3. XSS or unsafe HTML rendering
4. SSRF or arbitrary outbound requests
5. Hardcoded secrets or credentials
6. Broken authentication or authorization
7. Unsafe deserialization / eval-like execution
8. Sensitive information leakage or insecure defaults

Respond in Japanese.
Do not use tools.
Review only the patch data provided in this prompt.

If the patch is acceptable, include exactly one line containing: SECURITY_CHECK: PASS
If the patch is not acceptable, include exactly one line containing: SECURITY_CHECK: FAIL

ここで効いているのは、次の 3 点です。

• 何を見てほしいか をカテゴリで固定している
• どこまで見てよいか を Review only the patch data で絞っている
• どう返してほしいか を SECURITY_CHECK: PASS / FAIL で固定している

単に「この差分どう？」と聞くのではなく、レビュー観点と出力形式を先に固定している のがポイントです。Hook 側では、その決まった返し方を見て PASS / FAIL を判定できます。

セキュリティ以外の指示にも広げられる

今回のデモはセキュリティレビュー寄りですが、骨格はかなり汎用です。

たとえば prompt を差し替えれば、こんな関所にもできます。

• 社内コーディング規約に反していないか確認する
• commit 前に秘密情報や顧客名、社内 URL が入っていないか見る
• 禁止ライブラリや禁止 API を使っていないか確認する
• テストを書いていない変更に warning を出す
• commit message や変更内容がチーム運用に合っているか軽く点検する

「staged diff を読ませて、PASS / FAIL を返させる」 という骨格さえあれば、中に入れる指示は自由です。

ローカル AI Gate のテンプレート としてそのまま流用できます。

セットアップはシンプルです

前提条件はこの 3 つです。

• Git
• PowerShell 7+
• GitHub Copilot CLI

PowerShell なら、基本はこんな感じです。

やっていることは 3 つだけです。

• git clone: デモ用 repo を手元へ持ってくる
• Set-Location: その repo に移動する
• Copy-Item: hooks/pre-commit を .git/hooks/pre-commit へコピーして、Git の Hook として有効化する

つまり、clone したあとに 手で pre-commit をコピーするだけ でも大丈夫です。

git clone https://github.com/aktsmm/GHCP_GitHook_Sec_demo.git
Set-Location GHCP_GitHook_Sec_demo
Copy-Item .\hooks\pre-commit .\.git\hooks\pre-commit

これだけで、次の git commit から Hook が動きます。

macOS / Linux の場合は cp hooks/pre-commit .git/hooks/pre-commit のようにコピーして、必要なら実行権限も付けます。

まずは FAIL パターンを試す

この repo には、最初から「わざと危ない」サンプルが入っています。たとえば Python 側には、SQL injection、os.system、ハードコードされたパスワードや API key を含むサンプルがあります。

PowerShell で試すなら、こんな流れです。

ここでやっているのは 3 つです。

• Copy-Item: 脆弱なサンプルを複製して、試験用ファイルを作る
• git add: そのファイルを staged に載せる
• git commit: Hook を走らせて、危ない差分なら止まることを確認する

Copy-Item .\demo\vulnerable_python\app.py .\demo\vulnerable_python\app2.py
git add .\demo\vulnerable_python\app2.py
git commit -m "test"

うまくいけば、Hook が走って commit は止まります。

その後の片付けはこうです。

git reset HEAD .\demo\vulnerable_python\app2.py
Remove-Item .\demo\vulnerable_python\app2.py

次に PASS パターンも試す

安全側の JavaScript サンプルも入っていて、こちらは HTML escape や nosniff ヘッダーを付けた素直な実装です。

こちらも流れは同じで、やっていることはシンプルです。

• Copy-Item: 安全側サンプルを複製して、試験用ファイルを作る
• git add: そのファイルを staged に載せる
• git commit: Hook を走らせて、問題ない差分なら通ることを確認する

Copy-Item .\demo\safe_js\app.js .\demo\safe_js\app2.js
git add .\demo\safe_js\app2.js
git commit -m "test"

こちらは PASS して commit が通るはずです。

片付けは README と同じくこうです。

git rm .\demo\safe_js\app2.js
git commit --no-verify -m "cleanup"

--no-verify を使っているのは、デモ用の掃除 commit を確実に通すためです。ここも初心者には「Hook は必要に応じて意図的に bypass できる」という学びになります。

ただし、この repo の AGENTS.md にはこんな注意事項が書いてあります。

If a hook or security check blocks an operation, do not try to bypass it. Explain why it was blocked, fix the underlying issue first, and ask the user before taking any further action.
Do not suggest fail-open bypasses such as SECURITY_HOOK_FAIL_OPEN, --no-verify, disabling hooks, or rewriting hooks to get around the check.

AI エージェントに対して「Hook が止めたからといって bypass を提案するな、まず問題を直せ」と明示しているわけです。

これが必要な理由は、autopilot モードで動いているエージェントは賢すぎて、自分で勝手に抜け道を探すことがある からです。Hook が FAIL を返すと、エージェントが「じゃあ --no-verify で通してしまおう」「Hook を書き換えてしまおう」と自律的に判断してしまう、というのは実際にあり得る動きです。

--no-verify は人間がデモの掃除のために意図的に使うぶんには手段の 1 つですが、エージェントが問題を直さずに突破口として使うのは設計上 NG、というメッセージをここで明示しています。この一文があることで「エージェントが Hook を素直に尊重して、詰まったらユーザーに聞く」という前提がこの repo では成り立っています。

実行イメージ

出典: GHCP_GitHook_Sec_demo - https://raw.githubusercontent.com/aktsmm/GHCP_GitHook_Sec_demo/main/samples/screenshots/copilot-cli-security-check.png

この画面を見ると、git commit の途中で Hook が動き、その中から GitHub Copilot CLI が呼び出されてセキュリティチェックを返している のが分かります。

実際に手元で試した 1: ターミナルから git commit

今回は、脆弱な Python サンプルを フォルダごとコピーして staged に載せた状態 で、そのままターミナルから git commit を打ってみました。

結果は想定どおり SECURITY_CHECK: FAIL で、commit はそこで停止しました。ログには SQL injection、command injection、ハードコードされた認証情報、認証不備、debug=True まで並んでいて、「危ない差分を commit 前に止める」 というこの Hook の役割がかなり分かりやすく出ています。

地味ですが、止まったあとも変更が staged のまま残る のは大事です。commit が通らなかった理由をログで確認し、必要なら修正か unstage をしてやり直す流れになります。

今回の実行結果では、logs/security-20260602-011819.log に検出内容が残り、ターミナル側にも同じ FAIL 要約が出ていました。

ターミナル実行で FAIL した時の画面です。

実際に手元で試した 2: エージェントに commit と push を依頼

もう 1 つ試したのが、エージェントに 「commit して push して」 とまとめて依頼するパターンです。

この場合も、止まったのは同じく commit のところでした。エージェント側の返答を見ると、pre-commit から呼ばれた security_check.ps1 が app.py の SQL injection、command injection、ハードコードされた資格情報、認証不備、debug 有効化を検出し、commit が成立していないので push には進めていない と説明しています。

面白いのは、人がターミナルで commit しても、エージェントに commit/push を頼んでも、最終的に Git を叩くなら同じ Gate が効く ところです。

エージェント実行でも commit で止まった時の画面です。

この 2 つを並べて見ると、今回の仕組みは「人向けの補助」ではなく、AI に git 操作まで任せる運用そのものに効くローカル関所 だと分かりやすいです。

中では何をやっているの？

実装の勘所は、思ったより堅実です。

1. pre-commit Hook から PowerShell スクリプトを呼ぶ

Hook 本体は薄くて、実質 scripts/security_check.ps1 を呼ぶだけです。複雑さは Hook ファイルに詰め込まず、PowerShell スクリプト側に寄せています。

2. staged diff だけを集める

スクリプトは git diff --cached で これから commit される差分だけ を集めます。

working tree 全体ではなく staged diff に絞っているので、「今から出るもの」だけをレビューできます。

3. 先に軽い static pre-scan を入れる

スクリプトには regex ベースの pre-scan も入っています。たとえば、秘密情報っぽい文字列、os.system、eval、危ない fetch パターンなどです。

構成としては、

• まず軽い機械的チェック
• そのあと AI に文脈付きでレビュー

の 2 段構えです。

4. GitHub Copilot CLI には stdin で prompt を渡す

実装では、一時ファイルや雑な -Command 文字列ではなく、PowerShell のプロセスを直接起動して stdin で prompt を渡す 形を取っています。

この作りだと、引用崩れや command injection 的な事故を減らしやすいです。こういう細部は実運用でも効きます。

5. 判定は SECURITY_CHECK: PASS / FAIL に固定する

AI の自由回答に丸投げせず、出力フォーマットを強めに固定しています。実運用ではこの固定が効きます。

自然文だけに頼ると判定がぶれますが、機械が最終的に見る 1 行 を固定しておくと、Hook として扱いやすくなります。

自分で作るなら、設計の芯はこの 5 ステップです

自分用 Hook を作るときも、この 5 ステップがそのまま型になります。

1. どのタイミングで止めたいか決める
2. Hook から本体スクリプトを呼ぶ
3. 対象は staged diff に絞る
4. AI の出力形式を固定する
5. タイムアウト、ログ、fallback を入れる

この順番にしておくと、後で AI を差し替えても設計が崩れにくいです。

GitHub Copilot 専用なの？

結論からいうと、専用ではありません。

ポイントは、今回フックしている相手が Copilot そのものではなく Git だということです。いまは GitHub Copilot CLI を呼ぶ作りですが、考え方としては次の条件を満たせば他の coding agent にも置き換えられます。

• prompt を CLI やローカル agent へ渡せる
• ツールを使わず diff だけでレビューさせられる
• PASS / FAIL を安定して返せる

copilot を呼んでいる箇所を、別の local coding agent CLI に置き換えればいいわけです。

もう少し抽象化して見れば、「AI を Hook に差し込むための雛形」 です。

どういう人に刺さる？

特に次の人には相性がいいはずです。

• AI にコード生成だけでなく git 操作まで任せ始めた人
• ローカルで安全弁を試したい人
• Git Hook と GitHub Copilot Hooks の違いを手を動かして理解したい人
• 将来的に別の coding agent へ差し替える前提で、まずは最小構成を見たい人

逆に、これ 1 本で組織全体のセキュリティを守れるわけではありません。

• --no-verify で bypass できます
• ローカル Hook は clone しただけでは共有されません
• AI の判定品質には限界があります

なので実運用では、ローカル Hook + GitHub Actions + SAST / secret scanning のように重ねるのが良いと思います。

まとめ

触ってみていちばん良かったのは、人がターミナルで git commit しても、エージェントに commit と push を頼んでも、最後は同じ pre-commit で止められるところでした。安全確認を「人だけが頑張る作業」にしなくていい、という感触があります。

GHCP_GitHook_Sec_demo を手元で動かすと、次の 3 つがかなり掴みやすいです。

• Git Hook と GitHub Copilot Hooks の違い
• pre-commit が AI の差分チェックに向く理由
• GitHub Copilot 固定ではなく、他の coding agent へも広げられること

まずはローカルで 1 回止めてみる。そこから自分の運用に合わせて prompt や Hook の場所を育てていく、くらいの入り方がちょうどよさそうです。

Thanks to

この記事の着想は、元ベーシストでもある @achu0628 さんとの会話から生まれました。会話の中でヒントをいただき、私が GHCP_GitHook_Sec_demo を作って使い方を詰め、その内容をこの記事にまとめています。広めることを快く許可していただき、ありがとうございます！

参考

• GHCP_GitHook_Sec_demo

• Git hooks

• GitHub Docs - フックについて GitHub Copilot

• GitHub Docs - GitHub Copilotフックリファレンス

• GitHub Docs - GitHub Copilot CLI でフックを使用する