止まった作業を毎晩検知し、進められるものだけ自動で前に進める

これが解く問題

CI を通過したまま誰にもマージされない PR、閉じ損ねた PR、放置されたブランチ、 途中で止まった作業メモ。どれも「存在は知られているのに誰も動かさない」状態で溜まる。

よくある対策は「棚卸しリストを作る」だが、それだけでは止まらない。 実測した現場では PR 20件 / ブランチ 70件 と件数は毎日数えていたのに、 CI 通過済みの PR が CLOSED 未マージのまま 18日間放置され、誰も気づかなかった。

原因は3つ揃っていなかったこと:

要素	棚卸しリストだけの状態
締切	件数は数えるが「何日止まっているか」を見ていない
通知	ファイルに書くだけ。見に行かない日は誰も知らない
自動前進	人がマージするまで何も起きない

設計

1. 収集して経過日数を出す

• PR: gh pr list --state all --json number,title,state,isDraft,updatedAt,headRefName,mergedAt,statusCheckRollup,author
• ブランチ: git for-each-ref --sort=-committerdate refs/remotes/origin の最終コミット日時
• 作業メモの未完了項目: 取り消し線が付いていない行
• セッション/作業ログ: ファイルの mtime

閾値（既定3日）を超えて動いていないものだけを「停滞」とする。

2. PR を状態で分類する

分類	条件	扱い
mergeable	OPEN / 非draft / checks 全pass	自動マージ
ci-failed	OPEN / checks に failure	通知のみ
ci-pending	checks が pending のまま閾値超過	通知のみ
closed-unmerged	CLOSED かつ未マージ	通知のみ（再オープンしない）
draft-stale	draft のまま閾値超過	通知のみ

closed-unmerged を自動で再オープンしないこと。 意図して閉じた PR を機械が開き直すと、判断を奪って混乱を生む。判断は人に残す。

3. 自動前進は「全pass の自作 PR」だけ

マージは既存のマージ用ヘルパー経由にし、自前で gh pr merge を直叩きしない （head SHA 照合・マージ後の read-back 検証といった安全確認を二重に実装しないため）。 --dry では収集と「マージ予定」の出力だけを行い、何も変更しない。

4. 通知が読まれる形にする ← ここが成否を分ける

初版は素直に全部出したところ 109KB / セッション479件 になり、 本当に行動できる 4 件（マージ可能3・閉じ損ね1）が完全に埋もれた。

行動できるものと在庫を分ける:

• actionable: mergeable / ci-failed / closed-unmerged / draft-stale / 未完了項目 → 1件ずつ出す
• inventory: セッション / ブランチ → 古いだけで次の一手が無い。件数と最古の日数だけの1行に畳む

さらに:

• サブエージェントの一時ログは親の成果物なので収集対象から外す（479件→187件）
• ファイル出力でも在庫は各分類 20件で打ち切り、残りは「他N件」（109KB→8KB）
• actionable が0件なら、在庫が何件あっても通知しない（毎日ほぼ同じ在庫を送らない）

実測結果

初回実行で CI 通過のまま 4〜8日眠っていた PR を検知:

• 1件を実際にマージ
• 2件は mergeable=CONFLICTING を検出して merge-failed として通知（握り潰さない）
• 1件は closed-unmerged として判断待ちに回す

踏んだ落とし穴

テストが緑でも CI で落ちる

ローカル（Windows）で 20/20 通ったのに CI（Linux）で失敗した。 パス区切り・改行コード・ホームディレクトリ依存・mtime の粒度が典型。 両 OS で走らせること。skip して通すのは解決ではない。

リポジトリ固有の規約に違反する

「全ての子プロセス起動にコンソール窓を隠すオプションを付ける」という既存ルールがあり、 新規ツールがそれに違反して CI が落ちた。 既存の規約テストが何を強制しているか、書く前に確認する。

スタブは実物の出力をキャプチャしてから作る

想像で書いたスタブは自分の誤った前提をそのまま再現するので、 テストが全部緑なのに実物では動かない。 別件では「標準出力に出る」と決めつけてスタブを書いたら実物は標準エラーに出しており、 テスト 6/6 緑のまま本番で 500 を返した。 API を叩く前に1回実行し、標準出力と標準エラーを分けて生ログを取り、それを写す。

導入手順

1. 収集・分類・通知を1ファイルのツールとして書く（外部依存なしで書ける）
2. 既存の夜間バッチの最後に1回だけ呼ぶ。空キュー終了やエラー終了の経路でも必ず通るようにする
3. --dry で実物を1回流し、actionable と inventory の件数比を見る — actionable が埋もれていたら閾値や除外条件を調整してから本番化する
4. 通知先は1通に集約。全文はファイルに書き、通知にはそのパスを添える

判断の勘所

• 自動で進めてよいのは「検証が機械的に完了しているもの」だけ。 CI 全pass の自作 PR はこれに当たる。コンフリクト・CI 失敗・意図的なクローズは人に戻す。
• 通知は「読まれるか」で設計する。件数を全部出すのは親切ではなく、無視される原因になる。
• 在庫（古いブランチや完了済みセッション）は消さずに数えるだけにする。 消す判断は別の仕組みに委ねる。