AI 2026年4月22日

AIに夜間コード巡回を任せるとき、なぜ「自前実装」ではなく「委譲」を選ぶべきなのか

AIが夜中にコードを直す、その設計判断の話

AIエージェントに夜間のコード巡回を任せる。アイデアとしては面白いが、実際に設計しようとすると「どこまで自前で実装するか」という判断が必ず発生する。

Qiitaに投稿されたYuji Naramoto氏の記事は、まさにその判断を丁寧に記録したものだ。Claude Codeのスキルとしてnight-patrolを設計する際、修正ロジックをスキル内に全部書くのか、既存スキルに委譲するオーケストレーターに徹するのか。その選択の理由と、その結果どうなったかが具体的にまとめられている。

「誰もやりたくない仕事」は夜も積み上がる

記事が出発点として挙げる課題は、開発チームなら身に覚えがあるものばかりだ。

PRのレビュー待ちが何日も放置される
// TODO: あとで直す が何ヶ月も残り続ける
lint警告が数百件積み上がり、もはや誰も見ていない
スキップされたテストの理由を誰も覚えていない

どれも「誰かがやれば片付く」が「誰もやりたくない」類の仕事だ。そしてこういう技術的負債は、人間が寝ている間にも静かに積み上がり続ける。ならばAIに夜間巡回させて、検出・修正・PRまで自動化してしまおう、というのがnight-patrolの発想だ。

3つの設計案と、採用されなかった理由

記事では設計の選択肢を3つに整理している。

A案：修正ロジックをnight-patrol内に全部書く
夜間用に最適化しやすく、外部依存が少ない。ただし「昼のワークフローと品質基準が分岐する」「既存の実装スキルと重複する」という問題が生じる。

B案：CI/cronから既存の汎用スクリプトを呼ぶだけ
運用はシンプル。しかしTriageや依存解析といった判断をスクリプトで書くのは現実的に辛い。

C案：既存スキル（dev-flow）に委譲するオーケストレーター
昼夜で品質ゲートが完全に同一になり、責務分離がきれい。dev-flow側の変更に引きずられるリスクはあるが、それは管理できる問題だ。

採用されたのはC案。その決め手は「夜間用という理由で品質基準を下げたくなかった」という一言に集約されている。

「昼と夜で同じ基準を通す」という発想の鋭さ

ここが記事全体の核心だと思う。

もしnight-patrol内に修正ロジックを自前実装すると、夜用に「少し甘い基準」を作りたくなる誘惑が生まれる。結果として、夜に通ったPRが昼のレビュー基準で落ちる事態が発生する。朝レポートを見た人間が「このPRは本当にdevにマージしていいのか」と毎回迷うことになれば、自動化の意味がない。

だからnight-patrolは「何を直すか」だけを担当し、「どう直すか」は昼も使っているdev-flowに委譲する構造にした。

night-patrol (何を直すか)
├── Phase 1: Scan
├── Phase 2: Triage
├── Phase 3: Execute → dev-flow に委譲
└── Phase 4: Report

dev-flow (どう直すか / 昼と同じ実装ワークフロー)
├── dev-issue-analyze
├── dev-kickoff → plan → implement → validate → evaluate
├── git-pr
└── pr-iterate → pr-review → pr-fix

この分離により、夜間の修正PRも昼のコードレビュー基準・テスト基準・validateを同じ経路で通ることが自動的に保証される。

Triageが出力するバッチプランもよくできている。ファイルの重複はスクリプトで機械的に検出し、論理的な依存関係だけをLLMに判定させるハイブリッド設計だ。「全部LLMに任せる」でも「全部スクリプト」でもなく、得意な方に寄せる、という割り切りが実用的だ。

ガードは1つではなく重ねる

オーケストレーターとして責務を絞った分、ブレーキ設計は自前で持つ。記事では6つのガードを重ねている。

ガード	何を防ぐか	デフォルト
破壊的変更検出	public API変更、DBマイグレーション	issueスキップ
1 issue変更行数上限	巨大修正の混入	500行超過でスキップ
denylistパス	.env、migrations/等の保護	glob指定
denylistラベル	do-not-autofix等	ラベル指定
denylist issue番号	人間が手動対応したいもの	番号指定
累積変更量上限	ブランチ全体の差分爆発	2000行で残り全スキップ