なぜAIエージェントの夜間コード巡回スキルを『オーケストレーター』として設計したのか

Last updated at 2026-04-22Posted at 2026-04-22

この記事は playpark Blog からの転載です。

この記事で分かること

AIエージェントに夜間コード巡回を任せるときの設計アプローチ比較
「修正ロジックを自前で持つ」vs「既存スキルへ委譲する」の判断基準
自律スキルで安全策(ガード)をどう積むかの考え方

背景: こういう課題があった

コードベースを抱えた開発チームなら、おそらくどこも同じ問題に直面しています。

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

どれも「誰かがやれば片付く」けれど、「誰もやりたくない」系の仕事です。こういう劣化は人間が寝ている間にも進みます。そこで、AIエージェントに夜間巡回 → 検出 → 修正 → PRを自動化させる night-patrol というClaude Codeスキルを作りました。

ここで設計上の大きな分かれ道が一つあります。「修正ロジック」をこのスキル内に自前実装するか、既存のスキルに委譲してオーケストレーターに徹するかです。

選択肢の検討

3つの設計案を比較しました。

アプローチ	メリット	デメリット
A. 修正ロジックを night-patrol 内に全部書く	夜間用に最適化しやすい / 依存が少なくシンプル	昼のワークフローと品質基準が分岐する / 既存の実装スキルと重複
B. CI/cron から既存の汎用スクリプトを呼ぶだけ	運用が単純	Triage や依存解析などの判断をスクリプトで書くのは辛い
C. 既存スキル(dev-flow)に委譲するオーケストレーター	昼夜で品質ゲートが完全に同一 / 責務分離がきれい	dev-flow 側の変更に引きずられる

採用したのはCです。

なぜこのアプローチを選んだか

決め手は、「夜間用」という理由で品質基準を下げたくなかった ことです。

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

そこで「何を直すか」と「どう直すか」を明確に分離しました。

night-patrol (何を直すか / ブレーキ設計)
├── Phase 1: Scan   - lint / test / issue をスキャン
├── Phase 2: Triage - 重複排除・グルーピング・優先度・依存解析・ガード適用
├── Phase 3: Execute → dev-flow に委譲 (どう直すか)
└── Phase 4: Report - Markdownレポートと通知

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

night-patrol が決めるのはあくまで「対象と優先度と実行順」まで。コードを実際に書いて検証するのは昼も夜も同じ dev-flow。こうすると、夜間の修正PRも昼のコードレビュー基準・テスト基準・validateを同じ経路で通ることが自動で保証されます。

実装例: バッチプラン生成

Triageが出力する実行プランはこんなJSONです。

{
  "batches": [
    {
      "batch": 1,
      "issues": [456, 789],
      "mode": "parallel",
      "reason": "独立、ファイル重複なし"
    },
    {
      "batch": 2,
      "issues": [123],
      "mode": "serial",
      "depends_on_batch": 1,
      "reason": "#123 は #456 が修正した auth.ts に依存"
    }
  ]
}

ファイル重複をスクリプト側で機械的に検出し、論理依存だけLLMに判定させる、というハイブリッドにしています。「全部LLMに任せる」でも「全部スクリプト」でもなく、得意な方に寄せる。このバッチを受け取ったPhase 3は、mode に従って並列バッチは Task subagent で同時起動、直列バッチは順に dev-flow を呼ぶだけです。

安全ガードは単独ではなく重ねる

オーケストレーターとして責務を絞ったぶん、ブレーキ設計は自分で持ちます。単独では必ずすり抜けるので、6つを重ねています。

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