「朝起きたら、昨日のlint警告が全部直ってた」
そんな世界、欲しくないですか？ 私たちは本気で作りました。
レビュー待ち・技術的負債、溜まってませんか
開発チームなら心当たりがあるはずです。
- PRのレビュー待ちが3日目に突入している（もはや化石）
// TODO: あとで直すが半年間そのまま- lint警告が200件超えて、もう誰も見ていない
- テストが3つスキップされてるけど、なぜスキップしたか誰も覚えていない
人間は寝ます。でもコードベースの劣化は寝ている間も進む。
この「誰もやりたくないけど、誰かがやらないと積もる」問題に対して、私たちはAIエージェントに夜間巡回させるスキルを作りました。名前は night-patrol です。
night-patrol の全体像 — 4フェーズで回る自律ループ
night-patrolは、コードベースを巡回して問題を見つけ、自分でissueを作り、自分で直し、朝までにレポートを出す自律型スキルです。
Phase 1: Scan → 問題を見つける
Phase 2: Triage → 優先度をつけて整理する
Phase 3: Execute → 実際に修正してPRを出す
Phase 4: Report → 結果をまとめて通知する
1コマンドで全フェーズが回ります。
/night-patrol # フル実行（Phase 1-4）
/night-patrol --dry-run # 検出+トリアージまで（修正はしない）
/night-patrol scan --deep # code-audit-teamを使った深い分析
「寝る前に /night-patrol と打って、朝にレポートを読む」。これが基本の使い方です。
Phase 1: Scan — 3つのソースから問題を洗い出す
スキャンは3つの独立したスクリプトを並列実行します。
| ソース | スクリプト | 何を見つけるか |
|---|---|---|
| 静的解析 | scan-lint.sh | lint警告、型エラー、TODO/FIXME、未使用export、npm audit の脆弱性 |
| テスト | scan-tests.sh | 失敗テスト、.skip / .todo でスキップされたテスト |
| GitHub Issues | scan-issues.sh | 未アサインかつ対象ラベル付きのissue |
プロジェクトの種別（Node.js / Python / Rust...）は自動検出するので、設定不要です。
--deep モード：専門家チームによる多角分析
通常のスキャンに加えて、code-audit-teamを呼び出します。security / performance / architecture の3つの専門エージェントが並列でコードを監査する仕組みです。
ただしコストが高い（1回あたり$5-15）ので、週1-2回の「精密検査」として使うのが現実的です。毎晩の巡回は通常モードで十分。
Phase 2: Triage — 「直していいもの」だけを選別する
スキャン結果をそのまま全部直したら大惨事です。ここが night-patrol の設計で一番力を入れたフェーズ。
やっていること（6ステップ）
- 重複チェック — 既存のopen issueと照合。「もう報告済み」なら作成スキップ
- グルーピング — 同じファイル・同じ原因の検出結果を1つのissueにまとめる
- 安全ガードフィルタ — 触ってはいけないもの（後述）を除外
- 優先度スコアリング — critical / high / medium / low を自動判定
- 依存解析 — issue間のファイル重複を検出し、実行順序を決める
- Issue作成 — 新規分だけ
gh issue create（ラベル:night-patrol+ 優先度）
優先度の基準
| Priority | 対象例 |
|---|---|
| critical | テスト失敗、セキュリティ脆弱性 |
| high | 型エラー、バグラベル付きissue |
| medium | lint警告、enhancementラベル付きissue |
| low | TODO/FIXME、見た目の修正 |
テスト失敗とセキュリティ脆弱性が最優先。これは議論の余地がないですね。
依存解析と実行プラン
ここが地味に重要です。たとえば issue A と issue B が同じ auth.ts を触る場合、並列で修正するとマージコンフリクトが確定します。
night-patrol は analyze-dependencies.sh でファイル重複を検出し、LLMが論理依存（「Aの修正がBの前提になる」ケース）を判定。結果として以下のような実行プランが生成されます。
{
"batches": [
{
"batch": 1,
"issues": [456, 789],
"mode": "parallel",
"reason": "独立、ファイル重複なし"
},
{
"batch": 2,
"issues": [123],
"mode": "serial",
"depends_on_batch": 1,
"reason": "#123 は #456 が修正した auth.ts に依存"
}
]
}
独立したissueは並列で、依存があるものは直列で。この判断を自動でやってくれるのが、手動では面倒すぎるところです。
Phase 3: Execute — dev-flow に委譲して修正・PR・マージ
実際の修正は 既存の dev-flow スキルにそのまま委譲します。night-patrol 自体は「何を直すか」を決めるだけで、「どう直すか」は dev-flow に任せる。責務の分離です。
night-patrol → dev-flow → dev-issue-analyze → dev-kickoff
→ implement → validate → evaluate
→ git-pr → pr-iterate → pr-review → pr-fix
ブランチ戦略：nightly ブランチで隔離
修正は全て nightly/YYYY-MM-DD ブランチに集約されます。
main
├── dev ← 本流。朝にユーザーが確認してマージ判断
└── nightly/2026-04-01 ← night-patrol が作業するブランチ
├── PR #1 merged
├── PR #2 merged
└── PR #3 merged
dev に直接マージしないのがポイントです。朝起きて nightly ブランチの差分を確認し、問題なければ dev にマージする。夜中に何が起きたか、全て追跡可能です。
バッチ実行の流れ
各バッチについて以下を繰り返します。
- 事前ガードチェック — 累積変更量が上限を超えていたら、残りは全スキップ
- 修正実行 — 並列バッチは Task subagent で同時起動、直列バッチは1つずつ
- 自動マージ — dev-flow が LGTM を出した PR は nightly ブランチにマージ
- 事後ガードチェック — 1issue 完了ごとに累積変更量を再チェック
安全策 — 「暴走しない」ための6つのガード
自律で動くスキルに一番大事なのはブレーキです。アクセルだけの車には乗りたくない（命が惜しい）。
ガード一覧
| ガード | 何を防ぐか | デフォルト設定 |
|---|---|---|
| 破壊的変更検出 | public APIの変更、DBマイグレーション | 該当issueをスキップ |
| 1issue変更行数上限 | 巨大な修正の混入 | 500行超えでスキップ |
| denylistパス | .env、migrations/ など触ってはいけないファイル | glob パターンで指定 |
| denylistラベル | do-not-autofix、needs-discussion | ラベル名で指定 |
| denylist issue番号 | 人間が手動で対応したいissue | issue番号で指定 |
| 累積変更量上限 | nightly ブランチ全体の差分爆発 | 2000行超えで残り全スキップ |
--dry-run：まず「何をやるか」だけ見る
初めて night-patrol を導入するとき、いきなりフル実行するのは怖い（当然です）。
/night-patrol --dry-run
Phase 1（Scan）と Phase 2（Triage）だけ実行し、何が検出されて、何を修正しようとしているかをレポートで確認できます。修正は一切行いません。
「dry-run で3回回してみて、判断が妥当だと確認してからフル実行に切り替える」。これが私たちのおすすめの導入パターンです。
設定ファイルで細かく制御
skill-config.json で各ガードの閾値を調整できます。
{
"night-patrol": {
"max_lines_per_issue": 500,
"max_cumulative_lines": 2000,
"denylist_paths": [".env*", "*.secret", "migrations/"],
"denylist_labels": ["do-not-autofix", "needs-discussion"],
"allowed_labels": ["bug", "enhancement", "tech-debt"],
"telegram_chat_id": null
}
}
Phase 4: Report — 朝のコーヒーと一緒に読むレポート
巡回完了後、Markdownレポートが claudedocs/night-patrol/YYYY-MM-DD.md に出力されます。
# Night Patrol Report - 2026-04-01
## Summary
- 検出: 10件 → トリアージ後: 5件 → 処理: 3件
- ブランチ: nightly/2026-04-01
- 累積変更: 245行
## Completed
| Issue | PR | 変更行数 | 概要 |
|-------|-----|---------|------|
| #456 | #789 | 30 | テスト失敗の修正 |
| #457 | #790 | 95 | 型エラーの修正 |
## Skipped
| Issue | 理由 |
|-------|------|
| #234 | 推定変更行数 > 500 |
## Next Steps
- [ ] nightly/2026-04-01 を確認して dev にマージ
- [ ] スキップされた #234 を手動対応検討
Telegram通知も設定できるので、朝スマホを見た瞬間に結果がわかります（目覚めのコーヒーより先にレポートを読む生活、始まってます）。
他スキルとの連携 — 単独では動かない設計思想
night-patrol の特徴は、既存スキルの組み合わせで動くことです。新しく「修正ロジック」を書いたわけではありません。
night-patrol（オーケストレーター）
├── Phase 1: scan-*.sh（通常）/ code-audit-team（--deep）
├── Phase 2: scripts + LLM判断
├── Phase 3: dev-flow（実装の8割を担当）
│ ├── dev-issue-analyze
│ ├── dev-kickoff → plan → implement → validate → evaluate
│ ├── git-pr
│ └── pr-iterate → pr-review → pr-fix
├── Phase 4: generate-report.sh + Telegram
└── skill-retrospective（ジャーナルログ）
dev-validate との関係
dev-validateはコミット前の品質ゲートです。night-patrol が修正した PR も、dev-validate のチェックを通ります。品質基準は昼も夜も同じ。
skill-retrospective との関係
巡回が完了すると、skill-retrospectiveのジャーナルに実行結果を記録します。「何件検出して、何件処理して、何件スキップしたか」が蓄積され、night-patrol 自体の改善にもフィードバックが回ります。
スキルが自分の実行結果を記録し、その記録からスキル自体が改善される。この自己改善ループについては前回の記事で詳しく書きました。
導入のステップ
「面白そうだけど、うちでも使えるの？」という声が聞こえます。段階的に導入する方法を紹介します。
Step 1: dry-run で現状把握（5分）
/night-patrol --dry-run
まずはコードベースに何件の「放置された問題」があるかを知るだけ。これだけでも価値があります（見たくない現実が見える、という意味でも）。
Step 2: max-issues で控えめに始める（翌日の朝確認）
/night-patrol --max-issues 3
最大3件だけ修正。朝に nightly ブランチを確認して、修正の質を評価します。
Step 3: 設定を調整してフル実行
denylist や変更行数上限を自分のプロジェクトに合わせて調整し、制限なしで回す。
ここまで来れば、「寝ている間にコードが綺麗になっている」体験が日常になります。
まとめ
night-patrol は「AIエージェントに夜間巡回させる」という、一見すると大げさな話です。でも中身は地味で堅実。scan → triage → execute → report の4フェーズを、既存スキルの組み合わせと6つの安全ガードで制御しているだけです。
大事なのは、自律で動くからこそブレーキの設計に全力を注ぐこと。dry-run から始めて、信頼できると確認してから範囲を広げる。この段階的なアプローチが、人間とAIエージェントの信頼関係を作ります。
lint警告200件、放置されたTODO、スキップされたテスト。朝起きたらそれが片付いている世界は、もう手の届くところにあります。
Claude Code エージェント・安全設計 完全ガイド — この記事を含む10本の記事で、エージェント活用・Hooks安全設計・並列開発を体系的に解説しています。
