目次

前回の最後に物差しを一つ置きました。あるツールの三層が本当に結合しているかは、同じ状態を共有しているかで判断できる、と。今回はそれを具体的な形にします——三層は最初から最後まで一度も互いを呼び出していません。ディスク上の一つのファイルを介して引き継ぐだけです。さらに、当時は予想していなかった副作用もあります。そのファイルが機能ごとに分かれているおかげで、このパイプラインは縦に一本走るだけでなく、横に広げて何本も同時に走らせられます。

前回は、三層が pdlc-skills のどこに落ちているかを整理しました。全コマンドが共有するルールがプロンプト層、自動で前に進む区間が Loop 層、段階の順序と関係グラフが Graph 層です。

ただし、誰が何を担当しているかを知ることと、それらがどう組み合わさっているかを知ることは別の話です。

その流れで考えると、いちばん手っ取り早いのはコードの中で呼び出し行を探すことです。Graph はどこで Loop を呼んでいるのか、Loop はどこでプロンプト層を呼んでいるのか。しかし見つかりません——この三層が互いを参照している行は、一行も存在しないからです。

では、どうやって一緒に仕事をしているのでしょうか。

鍵は「呼び出し」ではなく「効くタイミング」

三層が互いを知らなくて済むのは、そもそも効くタイミングが重なっていないからです。

層 いつ効くか 何を決めるか
Graph 段階の境界で 次の一歩に進んでよいか
プロンプト 一回の呼び出しの内側で 今回モデルに何を見せるか
Loop 段階と段階のあいだで もう一周いるかどうか

たとえるなら、Graph は入口でチケットを切り、プロンプト層は会場の中で話し、Loop は場外で残り何公演かを数えています。三人は一度も口をきいていません。頼りにしているのは同じスコアボードです。

そのスコアボードが、ディスク上のあのファイルです。

三本のスイムレーンによる時間軸：Graph は段階の境界にだけ現れ、プロンプト層は各呼び出しの内側で展開し、Loop は二つの段階のあいだに位置する

一つの機能を最後まで追いかける

抽象論はここまでにして、実際の機能を一拍ずつ追いかけます。

第一拍、始動。 新しい機能が立ち上がった直後、ディスクには何もありません。この段階で受け止められるコマンドは一つだけ——要件を書くコマンドです。なぜか。他のコマンドはすべて、自分に必要な前段のドキュメントを宣言しているからです。設計には要件が要り、テストには設計が要る。前提条件がどれ一つ満たされていません。これは「まず要件を書きましょう」という助言ではなく、前段の成果物がなければこの扉を通れないという話です。 ここで効いているのが Graph で、その仕事は「通すか通さないか」だけです。

第二拍、作業。 扉を通るとGraph は退場し、場はプロンプト層のものになります。この一回の呼び出しでモデルが見るのは、そのコマンド自身の本文だけではありません。全コマンドが共有する一式のルール——成果物は必ずディスクに落とす、引き継ぐ前に必ず自己点検する、修正は一度だけで再帰しない——も一緒に見えています。これらのルールは一か所に書かれていて、呼び出し時に展開されます。各コマンドに書き写してあるわけではありません。

出てくるものも自由作文ではありません。ファイル名、置くディレクトリ、含まれる章立てはすべて決まっていますし、ドキュメントの先頭には小さな身元情報が付きます。どの機能に属し、どの段階にいて、前のドキュメントは何か。書式そのものは今回は展開しませんが、意味するところだけ言うと、成果物が自分の座標を持ち歩いているということです。そこから遡れば最初の要件までひと続きに辿れます。

第三拍、締めのディスク書き込み。 ここがいちばん重要な一拍です。主な作業が終わっても流れは終わりではなく、コマンドはあのファイルに一行記録しなければなりません。この区間は終わった、出来はどうだった、次は誰が受け取るのか。このファイルはディスク上にあり、機能ごとに一つです。

第四拍、止めるかどうかの判定。 ここで初めてループが出てきます。しかも読むのはあのファイルだけ——コードも成果物もチャット履歴も見ません。読んだうえで一つの結果を返します。次に走らせるコマンド名か、「完了」か、「詰まった」か。外側のスクリプトはその結果を受け取って次の一本を走らせ、走り終えるとまた第三拍に戻ります。

レビュー完了まで来るとループは停止し、「完了」を出して人を待ちます。リリースとデプロイは決してループの中に入りません——一度出したら引き戻せませんし、影響するのは本番の実ユーザーだからです。

つまり、この鎖の上で本当の引き継ぎは三か所しかなく、そこを渡っていくのはいずれも関数呼び出しではなく、一つの名前です。

  • Graph が呼び出しに渡すのは「担当する区間はここだ」；
  • 呼び出しがディスクに渡すのは「終わった、結果はこうだ」；
  • ディスクがループに渡すのは「続けるかどうか」。

三層のどれも、他のどれにも触れていません。

三つの引き継ぎ点：Graph はどの区間を担当するかを渡し、段階は締めに結果をディスクへ書き、ループはディスクから続行の可否を読み取る

あのファイルで最も効いている設計

「実際に走らせて得たもの」と「モデルが自分で言っていること」は、別々の枠に入っています。

一つ目の枠に入れてよいのは、本当にコマンドを走らせて得た結果だけです。テストが通ったか、カバレッジは足りているか、lint はきれいか——すべて終了コードから翻訳された真偽値です。走らせるコマンドがそもそも無い段階（ドキュメントしか作らない要件と設計の段階）なら、そこは空のままにします。「この区間はうまくいったと思う」という理由で「通った」と書き込むことは許されません。

二つ目の枠がモデルの自己点検で、何項目が通らなかったかだけを記録します。参考情報であり、止める判定には決して関与しません。

違いはどこに出るか。ループの停止判定は一つ目の枠しか見ません。つまりモデルの自己申告は、「正直に報告してください」という一文ではなく、データ構造のレベルで停止判定の経路から外されているのです。二つ目の枠に何を書こうと、今回のラウンドが止まるかどうかは変わりません。

前回言った「三層が同じ状態を共有している」は、具体的にはこの枠のことです。

状態ファイルの二つの枠の違い：一方は実際に走らせたコマンドの結果だけを入れて停止を決め、もう一方はモデルの自己点検を参考として入れる

本当のループは二段構えになっている

ここで一つ認めておきます。上で描いたループは、内側のループでしかありません。

自分で実際に動かすときの形はこうです——

主管 agent：全体設計 → 互いに独立した N 個の機能に分割
    ↓
外側のスクリプト：機能ごとに一本ずつ起動
    ↓
内側のループ × N（それぞれ別の機能を担当）   ← 同時に走る
    ↓
それぞれ「レビュー完了」か「詰まった」で停止 → 人がまとめてリリースを判断

まず主管 agent が全体設計をして、やるべきことを互いに独立した複数の機能に分割します。外側のスクリプトが機能ごとに内側のループを一本ずつ起動し、それらが並行して進み、それぞれ自分の終点で止まる。最後に人が N 本の結果をまとめて見ます。

なぜ同時に走らせて大丈夫なのか。 前提として、切り出したものが相対的に独立した機能でなければなりません。互いに依存がないからこそ同時に着手できます。その前提の上で、状態ファイルも機能ごとに分かれていて、一機能一ファイル、互いに依存しません。

機能 ID は「日付＋時分秒」で、その日の連番ではありません。リポジトリに理由が明記されています——複数人あるいは複数の AI が同時に着手すると、各自が「その日の最大番号＋1」を取りにいくため必ず衝突し、同名になった状態ファイルは手作業で振り直すしかありません。作成した瞬間の時分秒にすれば、各自が勝手に動いてもまず衝突しません。この ID 形式はもともと並行のために用意したものでした。当時はきちんとした設計だと思っておらず、衝突よけの小技のつもりで入れただけでしたが。

コードの層も隔離が要ります。各機能の内側のループはそれぞれ自分の git worktree で走り、互いに干渉せず、成果物は別々の PR を通ります。

では、なぜ「分割」だけは人、あるいは主管 agent に残さなければならないのか。 前回、判断基準を一つ出しました。誤りを自動で見つけられるものはループへ、そうでないものは人へ。「この要件群をいくつの機能に割るべきか、どれとどれに依存があるか」——間違えてもどのコマンドもエラーを返しません。判断の問題であって、検証の問題ではないからです。だからループの外にあります。

二段の終点も違います。内側の終点はレビュー完了、外側の終点は「N 本すべてが収束したこと」。そしてリリースは変わらず唯一の人手のゲートです。何本同時に走らせようと、最後にボタンを押すのは人です。

このやり方は、自分のコマンドラインツールのプロジェクトで実際に走らせました。どう動かすか、ガードレールをどう設定するか、一晩走らせると何が出てくるか——それは後の回で扱います。今回は形だけを描きます。

二段構えのループ：主管 agent が相対的に独立した N 個の機能に分割し、外側のスクリプトがそれぞれ自分の worktree で内側のループを起動し、最後は人手のリリースゲートに集約される

次回：自分のプロジェクトで動かすには

この記事から一文だけ持ち帰るとしたら、これにしたいと思います。三層が噛み合うのは互いを呼び出しているからではなく、同じ一つのファイルの別々の枠に、それぞれが書き込んでいるからです。

インターフェイスは関数ではなく名前です。だから一つの層を変えても他の層に波及しませんし、だからこのパイプラインは横に何本も複製できます。

今回は意図的に踏み込みませんでした。あの状態ファイルに具体的にどんなフィールドがあるか、ループのガードレールと上限をどう決めるか、並行で走らせたあとどう畳むか——どれも後の回に回します。まず形をはっきりさせてから、部品を見る。

これで、三層とは何か、それぞれどこに落ちるか、どう噛み合うか、の三本が終わりました。次回は方向を変えます。自分のプロジェクトにどう入れるか、どう始めるか、既存のコードベースをどう取り込むか——この記事の図面から、あなたの端末で本当に走る最初の一行へ。

試してみる：

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

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

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

あの二段構えの図は自分が実際に走らせている形で、描くまでは頭の中にしかありませんでした。具体的な像が持てたなら、いいねをいただけると嬉しいです。周りに「AI に複数のことを同時にやらせたい」と考えている方がいれば、共有していただけると助かります。