質問で止めない——課題をIssueに投げると、朝には設計ドキュメントのPRが立っている

新しい取り組みを始めた。課題をGitHubのIssueに投げておくと、 夜のあいだにAIが尋問・検証・設計ドキュメント化まで進めてくれるパイプラインだ。 狙いは単純で、サブスクの余剰トークンを「寝ている間に働く時間」に変えること。

思いつきは大抵、思いついた瞬間がいちばん熱い。 だが実際には、その熱が冷めるまでのあいだに 「本当にそれで解けるのか」「もっと単純な手はないか」を調べる時間が取れない。 結果、Issueだけが溜まっていく。

そこで、溜まったIssueを夜のうちにAIに処理させることにした。 Claude Codeのcloud routine（クラウド側で定期実行されるルーチン）を2本立て、 リポジトリ内のスキルを使わせる構成だ。

1. パイプラインの全体像

日中は2時間おきにtriageが回り、新着Issueを尋問する。 深夜4:37にdeep-diveが1回だけ回り、尋問済みの課題を深掘りして docs/ に設計ドキュメントを書き、PRを立てる。 朝、自分がやることはPRを読んでマージするか、仮定にコメントを付けるかだけだ。

ルーチン      スケジュール(JST)        モデル      仕事
──────────────────────────────────────────────────────────────
triage       9:07〜23:07 の2hおき      Sonnet 5   inbox の尋問／再尋問
deep-dive    毎日 4:37（1日1回）       Fable 5    深掘り→設計ドキュメント→PR

ここでもモデルは層別に配っている。 数をこなすtriageは軽めのモデルで回し、 成果物の質がそのまま朝の判断材料になるdeep-diveだけは重いモデルを使う。 判断が集まる層だけ厚くするという前回までの型が、 そのまま別プロジェクトにも効いた形だ。

2. 状態はGitHubのラベルで持つ

無人で回すパイプラインには状態管理が要る。 専用のDBもキューも作らず、Issueのラベルをそのまま状態機械として使った。

inbox ──▶ grilling ──▶ plan-ready ──▶ deep-diving ──▶ docs-ready ──▶ approved
          (ロック)                      (ロック)                        ▲
          2hで失効                       4hで失効                        │
                                                              docs PR のマージ
                                                              ＝ 唯一の人間ゲート

grilling / deep-diving は「処理中」を示すと同時に 多重処理のロックになっている。 ルーチンが重なって同じIssueを二重に処理しないためだ。 ただしロックは事故る。途中で落ちるとラベルが残ったままになる。 そこで時間による失効を入れた—— 更新なしで2時間（deep-diveは4時間）経ったロックは、事故とみなして再処理してよい。

3. 対話前提のスキルを、無人向けに翻訳する

尋問部分は、ゼロから考えたわけではない。 Matt Pocockの /grilling というスキル （mattpocock/skills, MIT）が下敷きにある。 中身は驚くほど短く、思想がはっきりしている。

執拗に尋問する。質問は一度に1問だけ投げて答えを待つ。事実は自分で調べる。だが決定は人間のもの——ひとつずつ人間に問い、答えを待て。

これは対話型として完璧だが、答える人間がいない深夜のルーチンではそのまま動かない。 「答えを待つ」が「永遠に止まる」になるからだ。 そこで思想を保ったまま、無人実行向けに翻訳した自作スキル auto-grill / auto-docs を書いた。

尋問は2軸を必ず両方通す。 要件の曖昧さ（成功条件・非目標・未定義語・利用者と頻度・暗黙の期待）と、 技術的前提（実現可能性・暗黙のアーキテクチャ・反証・依存とコスト・先行事例）だ。 片方だけでは穴が残る。 なお本家の「事実は自分で調べる」は翻訳後も維持していて、 調べれば分かることは仮定にせず、WebSearchや公式ドキュメントで裏を取らせている。

尋問の目的は課題を潰すことではなく、強くすること。良い質問とは、答えると課題の解像度が上がる質問だ。だから「答えが変わると設計が変わる質問」だけを出させる。

4. 方針転換——「人間にしか決められない問い」でも止めない

ここが今回いちばん考えが変わったところだ。

最初の設計には needs-human というラベルがあった。 予算・好み・優先順位・外部との約束など、人間にしか答えられない問いにぶつかったら、 そこでパイプラインを止めて人間の回答を待つ——という素直な作りだ。

だが少し回してみて、これは間違いだと気づいた。 止まったIssueに残るのは質問リストである。 朝、質問リストを渡されても、答えるコストは自分で考えるのとさして変わらない。 それでは「寝ている間に働かせる」という目的を果たしていない。

分岐仮定の作りはこうだ。 答えによって結論が大きく変わる問いは「分岐点」として扱い、有力な回答パターンを2〜3個立てる。 各パターンに「そのパターンだと何が変わるか」を1行で添える。 そのうえで最も可能性が高いものを本命として選び、理由を書く。 下流の auto-docs は本命で主計画を作り、他パターンは差分として書く。

設計ドキュメントには「パターン別の差分」という節を必ず置かせている。 ここで効いてくるのが、どのパターンでも変わらない共通打ち手だ。 分岐がまだ決まっていなくても、そこは今日から着手していい部分になる。

5. 暴走させないための運用ルール

無人で回す以上、放っておくとトークンとレビュー負債の両方が溶ける。 そこで抑制側のルールを先に決めた。

• 人間ゲートは1箇所 — docs PRのマージのみ。それ以外は無人で進む。
• バッチ上限 — triageは1回3件まで、deep-diveは1晩2件まで。朝に読める量を超えさせない。
• 再処理禁止 — 処理済みのIssueは、人間の新規コメントがない限り触らない。空回りでトークンを焼かない。
• 自己再発火の禁止 — ルーチンはラベルでのみ対象を選ぶ。AI自身のコメントやPRをトリガーにしない。
• 数より1本の質 — 深掘りは重い処理なので、件数を増やさず1本の密度を上げる。

特に自己再発火の禁止は、無人パイプラインでは必須だと思う。 「コメントが付いたら反応する」という素直な設計にすると、 AIのコメントがAIを起こし、無限に回り続ける。 誰が書いたかではなく、ラベルという明示的な状態でだけ動くようにした。

6. まとめ

まだPhase 1（手で1サイクル回してプロンプトを磨く段階）で、 ルーチンの無人化はこれから、実装フェーズの自動化はその先だ。 それでも、設計の骨としてはっきりしたことがある。

• 対話型のスキルは、そのままでは無人で動かない。「待つ」を「仮定して進む」に翻訳する必要がある
• 状態はラベルで持てる。ロックと時間失効を入れれば専用基盤は要らない
• 止めないための装置が分岐仮定。パターンを立てて本命を選び、差分を書く
• 止めない代わりに、AIが決めたことは全部「仮定」として明示する
• 人間ゲートは1箇所に絞る。絞るからこそ、そこは必ず人間が通る

別のシリーズでずっと書いてきた 「人間の承認ゲートを越えさせない」という原則は、ここでも変えていない。 変えたのはゲートの数だ。 無人で長く回すパイプラインでは、ゲートを増やすほど止まる場所が増え、 結局どこも通らなくなる。 1箇所に集約して、そこだけは絶対に人間が通る—— 自律度を上げるほど、ゲートは減らして濃くするほうが機能する、という手応えがある。