pdlc-skills はどうやって無人で回すのか

最初の機能を通したあと、すぐ次の問題にぶつかります。各ステージごとに止まってこちらの承認を待つので、結局は画面の前に張りついたままです。一周ずつ自分で進めてもらい、その間こちらは別の作業をする——それはできるのか。 できます。ただし「自分で走る」と「一歩ごとに振り返って訊く」の差は、見た目より大きいものでした。

あのとき回っていたのは loop ではなかった

自分のマシンで完全な loop を回したことがあります。とても順調で、60 本あまりの PR を一気に片づけるあいだ、一度もこちらに訊いてきませんでした。だから別のマシンで回し直したとき、ほとんど即座に違和感がありました。

そのときは AI に同じセッションの中で「各ステージを自分でループして進める」ようお願いしていました。確かに前へは進むのですが、一歩ごとにこちらへ戻ってきます。この設計でいいですか。次に進めますか。続けましょうか。

そのとき私が言ったのは、だいたいこういうことです。この loop、前に使っていたものと何か違いませんか。普通の loop はこういう無駄なことを訊き返さず、仕事が終わるまで走り続けます。

問題は訊くこと自体ではなく、訊いてくる内容がすべて決着済みだという点です。PRD も決まり、設計も決まり、テストの書き方も決まっている。それでも確認しに戻ってくる。この種の確認は私を椅子に縛りつけるだけです。次に呼び戻されるのが三分後なのか三十分後なのか分からないので、ほかの作業に移れません。

表面上はループしていますが、実際には私が伴走させられていただけです。

これではっきりしました。偽の loop と本物の loop を分ける線は一本だけ——ループの制御権を誰が握っているか。

モデルが賢いかどうかは関係ありません。プロンプトに「自律的に完了させ、中断しないでください」と書いたかどうかも関係ありません。制御権がモデルの意思の側にあれば偽物、コードの側にあって初めて本物です。

機能一つなら、コマンド一本で足ります

先に譲れない前提から。PRD と設計は人が通し切ること。設計が確定してからでなければ loop に入れません。

ループが速くするのは TDD → 実装 → レビュー という収束の区間であって、「何を作るのかを考え切る」ところではありません。この機能をやるべきか、境界をどこに引くか、いくつに分けるか——どれも判断であって、終了コードを返してくれるコマンドは存在しません。

そこを通したあとは、コマンド一本で済みます。

/pdlc-loop-run F20260825-XXXXXX

その機能が今止まっているステージから始めて、tdd → implement → review を自動で進め、レビュー完了に達するか、詰まって停止するまで走ります。各ステージは新しい subagent に渡され、戻ってきたら状態機械を読んで、進めるか・止めるか・人に返すかを決めます。既定の上限は 4 ステップです。

前提として、前回の test-commands.yml が設定済みであること。 停止判断は実際にコマンドを走らせた終了コードに依っているので、あのファイルがなければ走らせるコマンドもありません。前回のあの一歩を飛ばすと、ここで書いていることはすべて空回りになります。

このコマンドが肩代わりしてくれるのは、最初に手作業で試して失敗した、まさにその部分です。「もう一周やるかどうか」の決定を、モデルの手から取り上げる。 それを三つの設計が支えています。

一つめ、制御フローはコードにあり、モデルの頭の中にはない。 各周でモデルに訊くのは二つだけです。次はどのコマンドか、そしてその一歩を終わらせること。前者の答えはさらにホワイトリストを通り、五つの語しか認められません。一文字でも説明が混じれば濾し取られます。モデルが余計なことを言っても意味がありません。下流がそれを読まないからです。

二つめ、各ステージはクリーンなコンテキストから始まる。 前のステージの迷い、誤解、自分で引き込んだ脱線は、次のステージへ持ち越されません。ステージをまたいで残す必要のあるものは、すべてディスク上の状態機械ファイルにあります——第 3 回で扱ったあのファイルです。セッションは死んでも、状態は失われません。

三つめ、停止判断はファイルを読む。モデルの言い分は読まない。 一歩終わるごとに、ループは「通ったと思いますか」とは訊かず、last_phase_result.ok を読みます。実際にコマンドを走らせた結果がディスクに落ちたものです。第 3 回のあの二つの枠のうち、停止判断が使うのは実行結果だけを入れる方の枠です。

機能が十数個になって、はじめて外部スクリプトの出番です

/pdlc-loop-run はプラグイン内で走るので、機能一つの短い収束に向いています。自分で bash のループを書くこともできます——各周が本当に独立したプロセスになるぶんコンテキストの隔離は厳密で、長時間の実行にも強い——けれどもそのやり方で機能点を一つ回すだけなら、あまり意味がありません。/pdlc-loop-run と同じ仕事を、プロセス境界だけ変えてやっているからです。

スクリプトの本当の居場所は一段外側です。第 3 回で二段構造を描きました。作業を N 個の比較的独立した機能点に分け、外側が機能点ごとにループを一本ずつ、それぞれ自分の worktree で起こす。外側がやるのはループの起動・結果の回収・次バッチの投入であって、個々の機能のステージを進めることではありません。今回はその外側をどう並べるかを補います——依存関係でバッチに分ける、です。

以前のあるプロジェクトは機能点が十数個あり、三つのバッチに分けました。まず土台、次にほかから依存されている機能、最後に互いに無関係な独立機能をまとめて全部。 各バッチの中は並列で走らせ、一バッチ終わるごとに人が確認し、それから次のバッチを起動して、順に全体を収束させていきます。

順序は逆にできません。土台が立っていなければ後ろはすべて砂上の楼閣ですし、依存されている側が終わらなければ、依存する側はただ待つだけです。最後のバッチは誰も待たないので、まとめて全部開くのがいちばん効率的です——機能 ID が「日付＋時分秒」なのはもともと並列のためで、同時に走らせても衝突しません。

はっきりさせておくと、このバッチ編成の層は私が自分で組んだもので、pdlc が用意しているものではありません。 pdlc が与えるのは「機能点一つがどう自力で走り切るか」と、/pdlc-relate の依存グラフで誰が誰に依存しているかを見えるようにすることです。どう分けるか、一バッチに何個入れるかは、依然として判断であり、依然としてループの外側にあります。

四つのガードレール、どれも実際に効く場面を見ています

ガードレールを文書に書くだけなら誰にでもできます。見るべきなのは、それが実際に作動したことがあるかどうかです。

① ハード予算：各周の --max-budget-usd

各周のプロセスに上限を置き、使い切ったらプロセスごと打ち切られます。交渉の余地はありません。これは外部スクリプト形態では必須の設定です。

これは一度の実行で二回作動しました。 最初の周は上限を 5 にしていて、実装の途中で断ち切られました。ディスク上の作りかけを確認し、続きから再開できると分かったので上限を 8 に上げて再実行——また上限に当たり、最終的に 12 で走り切りました。

断ち切られた瞬間について言うべきことは一つです。ディスク上のものは無傷でした。 ドキュメントは書き出され、状態機械には記録が残り、失ったのは「この周が終わらなかった」ことだけで、「全部やり直し」ではありません。ディスクへ書き出すことと記録を残すことが、乱暴なプロセス停止を、続きから再開できる中断に変えています。

数字が誤解されないように一つ断っておきます。5・8・12 は私が各周に設定した上限であって、実際に支払った金額ではありません。 私はサブスクリプションで週あたりの量で計算される形態ですし、そもそも API の単価はベンダーごとに違います。この三つの数字は「だいたいこのくらいの規模」という目安として見てください。実際のコストを出したいなら、トークン消費量を見て、ご自身が使っているベンダーの公式価格で見積もるほうが正確です。

② と ④：ok でなければ止まる、ステップを使い切っても止まる

fail-stop が受け止めるのは、いちばん見落とされやすい種類の不良です。失敗したステージが、次の周に「完了済み」として踏み越えられるというもの。一度踏み越えられると、以降の各周は偽の前提の上に積み上がり、長く走るほど深く狂っていきます。しかも全行程が緑のままです。

ステップ上限が防ぐのは振動です。壊す→直す→また壊す、と各周が作業しているように見えて、実際はその場で足踏みしている状態。既定の 4 ステップ＝収束の三段＋予備の一段。私は一度、保守的に 1 に設定して試し、予定どおり停止しました。

③ blocked エスカレーション：止まるべきときに本当に止まりました

レビューでプロダクトの判断が要る問題が見つかると、状態機械に blocked を書き、停止して人を待ちます。

これが実際に作動した一回で、この仕組みは信用できると思えました。

レビュー中、その周で追加された三つの設定フィールドが、バックエンドのどこからも消費されていないことが見つかりました。コードは正しく、テストも緑です。これはバグではなく、プロダクトレベルの欠落でした。フィールドを削るべきなのか、それとも経路が未完成で足すべきなのか。これは AI が私の代わりに決めていい問いではありません。

推測もせず、テストを緑に保つためにフィールドをこっそり消すこともせず——blocked を書き、停止し、問いをこちらへ返してきました。私はフィールドを残して消費経路を足すと決め、続きを走らせました。再レビューでは思わぬおまけもありました。その経路実装に紛れていた本物のバグを 2 件、ついでに直していったのです。

止まるべきところで止まり、見るべきところを見た。私が欲しかったのはこれです。

この一回で何が出てきたか

対象はあるコンソール系プロジェクトの三期分の反復で、バックエンドのエンドポイント群が 4 つ、フロントエンドのページが 3 つ、それに通知ルール一式。TDD → 実装 → レビュー を最初から最後まで無人で走り切り、テストは 301 件すべて通過、カバレッジは 87% 超でした。

人が関与したのは全部で三回だけ。予算を延長するときの確認判断が二回と、blocked のときのプロダクト判断が一回です。

これは午後一回分の仕事量で、実際以上に大きく語るつもりはありません。ただ loop のあいだ、それは私に対して完全に沈黙していました。戻ってきて目にするのは「次のこれをやりますか」の列ではなく、一つの終状態です。速いことが本質ではありません。私がその場にいなくてよい、というのが本質です。

人と機械の自動化の境界

判断基準は第 2 回から変わっていません。自動でエラーを見つけられるものだけを、ループに渡す。 この線で引くと、永久に渡せないものが二つあります。

• 何を作るのかを考え切ること（人の判断が要る）。 PRD と設計は人が通すこと。これは loop に入るための前提であって、推奨事項ではありません。
• リリース。 ループの終状態はレビュー完了で、そこで止まり、出すかどうかは人が決めます。--autonomous はリリースとデプロイには一切効きません——出してしまえば取り戻せないからです。

ここまでが「どの作業を渡せるか」の線引きです。これと対になる問いがもう一つあります。渡したあと、暴走しない保証はどこから来るのか。

第 1 回でプロンプトエンジニアリングを扱ったとき、その層の天井をこう書きました。それはソフトな制約であり、モデルが完全に従うとは限らず、その場で気づけるとも限らない、と。当時はただの原則でしたが、今回それに実例が付きました。

「節約して、消費に気をつけて」とプロンプトに書くのは簡単ですが、それはプロンプト層のやり方です——導くことはできても、保証はできません。--max-budget-usd はプロセス層のやり方で、何が書かれているかを読まず、上限で切ります。今回の二度の超過は、二度とも後者に止められたのであって、前者に諭されたのではありません。

「導きはするが保証しない」ものは、最終的にどれも一段上へ移すことになります。 今回はプロセスの引数まで移りました。

次回

この記事から一つだけ持ち帰るとしたら、これにしたいと思います。loop が本物か偽物かを見分けるには、一点だけ見ればいい——制御フローがコードの側にあるのか、モデルの意思の側にあるのか。 振り返って訊いてくるループは、ループではありません。

次回は品質の話です。このパイプラインは速く、見張りも要らない。ではその産物は何を根拠に信用できるのか。テストの赤信号ゲート、レビューのゲート、カバレッジがそれぞれ何を止めていて、合わせても何を止められないのかを扱います。

試してみる：

curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh | bash -s -- --global

リポジトリはこちら：https://github.com/kanfu-panda/pdlc-skills

役に立ったら star をいただけると励みになります ⭐

この四つのガードレールは、あの実行の記録をそのまま一つずつ書き起こしたものです。断ち切られたところも、詰まったところも含めて。「なるほど、これは信用できそうだ」と思ってもらえたなら、いいねで教えてください。ご自身で loop を回したことがある方は——うまくいった話でも、こじれた話でも——コメント欄でぜひ聞かせてください。