AIにコードを書かせるなら、Git hookは重いほうがいい

Claude CodeやDevinのようなコード生成エージェントにコードを書かせると、pushされたPRのCIが落ちることがある。lint失敗、format崩れ、typecheck引っかかり。数秒で検出できる問題をCI待ちさせるのは、エージェントにとって最も無駄である。なぜなら、AIは結果を待つ間、セッションのコンテキストが結果ログで埋まり、修正を試みても手戻りループが増層するからだ。機械的に検出できる問題はローカルで、それもpush前に強制検出するべき。この考え方が「Git hookは重いほうがいい」という逆説を生む。

人間の開発ではGit hookは軽く保つのが定石だった。重いチェック（ビルド、テスト）はCIに置く。なぜなら、開発者がpushのたびに数分待たされたら、生産性が損なわれるからだ。だがAIエージェントの場合、この前提が反転する。hookの待ち時間に苛立つ主体がいない。エージェントは pre-pushの完了を淡々と待ち、失敗すれば出力を読んで修正する。つまり、AIに対しては「重いhook」の方が、CI落ち→手戻りループより全体の効率が高い。

hkというGit hookマネージャーが便利な理由は、設定がPklで宣言的に書ける、並列実行が前提、fail_fast=falseで複数失敗を一度に報告できる点。AIエージェント向けのAGENTS.mdも用意されている。つまり、hk自体がAIとの組み合わせを前提に進化しているツール。MCPサーバーとしても動き、エージェントがツール呼び出しで能動的に検証実行できる。AI時代の開発プロセスは、「何をチェックするか」ではなく「誰が待つか」で設計が変わる。エージェントのセッション効率が組織の生産性に直結する今、待機ループを徹底的に削るGit hookの重さは、一見の損失が実は最大の投資である。