PRD とリリースゲートの間の道を自ら歩くループ。Master Plan = PRD + ゲート、反復ごとに一項目を出荷、DECISIONS キューで運営者の決定を隔離、24/7 の自律をドリフトにしない規律。

第10回 — PRD は何を作るかを言った。第11回 — Release gates はいつ作られたかを言った。

この記事は、運営者がキーボードに居ないとき、その間を何が埋めるかについての記事だ。

Ralph。ゲートの打たれた PRD を受け取って自ら道を歩む自律ループだ。一度に一 commit、検証されて。バックグラウンドで回る。可能なときに push する。決定が必要なときにキューに積む。運営者は起きて slash command を一つ走らせ、いくつかの決定をし、やっていたことに戻る。作業はシステムがやった。

このシリーズのワークフロー編 3 編のうちの最後で、それまでのすべてが累積して作動する記事でもある。ペルソナが決定空間を狭める。メモリがなぜを保管する。Skill が動詞を圧縮する。Hook が忘れそうなものを発動させる。Multi-Agent が負荷を分ける。検証が「完了」を固定する。トークン経済が信号を守る。PRD が意図を保管する。Release gate が到達を強制する。Ralph がその配置全体を時計に合わせて回す。

0. 出発前提 — 自律性は「エージェントをもっと信じる」ことではない

自律性の悪いバージョンは「エージェントが望むようにやらせて上手くいくよう祈る」だ。それは第10回の PRD のないワークフローが崩れる理由と同じ理由で崩れる — 運営者の意図が永続的に住む場所がなく、エージェントは即興でやることになる。

機能するバージョンは正反対だ。運営者が PRD を書く。運営者がゲートを書く。エージェントの裁量は鋭く境界づけられる — システムが 何であるか を変えないことは何でもできて、変えるものは何もできない。その境界の内側で、エージェントは監督なしで回る。境界の外で、エージェントは止まって待つ。

自律性は意図がコードに固定され労働だけが委任されるときに機能する。

Ralph はこの区別を運用上実在させるハーネスだ。

1. Ralph が実際に何か

Ralph はスクリプト 2 つとフォルダ 1 つだ。

ralph-code.sh — 一度に一 phase を回す。PRD-N を読む。次の [ ] 項目を選ぶ。実装する。verify を回す。verify 通過時に commit。繰り返し。
ralph-orchestrator.sh — 複数の phase を連続で回す。Master Plan を読む。各 phase で ralph-code.sh を呼ぶ。phase 間でゲートを検査する。ゲート通過 (Auto) か、止めて決定をキューに積む (Manual) か。
ralph-loop/ — プロジェクトごとに一つ。PRD たち、master plan、進捗ログ、blocker リスト、そして — 最も重要な — DECISIONS キュー を保管。

子プロセスは長生きするエージェントではない。反復ごとに新しいセッション だ。各反復は一項目 — 実装、検証、commit。次の反復は綺麗な状態で始まり、PRD を再読して次の [ ] を見つける。反復間で運ばれる context がないので、ドリフトが累積できない。

親 — orchestrator — は実装しない。唯一の仕事は ゲート強制 だ。各 phase の後で問う — 「ゲートは通過したか？」通過した場合、進める。通過しなかった場合、止まってキューに書く。

2. Master Plan — PRD とゲートが融合したもの

Master Plan は Ralph が読むドキュメントだ。PRD に phase 別ゲートが inline された形だ:

Approved-By: lead, 2026-05-18

Phase P1 — Privacy とコンプライアンス点検
  PRD: ralph-loop/PRD-P1.md
  Auto-Gate: pnpm verify:privacy && pnpm build && pnpm lint
  Manual-Gate: lead が privacy policy テキストを承認
  項目数: 12

Phase P2 — 資産 SHA-256 強制
  PRD: ralph-loop/PRD-P2.md
  Auto-Gate: pnpm verify:assets && pnpm build
  Manual-Gate: —
  項目数: 7

Phase P3 — i18n locale 拡張 (4 新規 locale)
  PRD: ralph-loop/PRD-P3.md
  Auto-Gate: pnpm build && pnpm verify:i18n
  Manual-Gate: 各 locale の機械翻訳コンテンツを lead が承認
  項目数: 24

...

三つの性質が重要だ。

Approved-By: 行は必須。orchestrator はその行なしでは始動を拒否する。lead が Master Plan に署名していなければ Ralph は回らない。

各 phase の PRD は事前生成。「orchestrator が P3 に到達したら PRD-P3 を生成する」ではなく — 始動時点で PRD-P3.md が既に存在する。Alice が Master Plan から起こして事前に書く。事前生成はドリフトの安全網だ。進行中に作られる PRD-P3 には運営者レビューがない。

Auto-Gate と Manual-Gate が phase ごとに名指される。Auto はシェルコマンド。Manual は名指しの承認者と何を承認するか。どの phase もゲート通過なしには進まない。

3. ループが実際にどう回るか

ralph-code.sh の一反復の単純化したトレース:

1. worktree に cd
2. PRD-N.md を読む
3. 最初に [ ] と記された項目を見つける
4. [ ] 項目が残っていない → 終了 (ALL DONE)
5. 新しい Claude Code セッションを開始
6. system prompt: "正確にこの一項目だけを実装して止まれ"
7. 子がコードを書く
8. 子が verify を回す (PRD に名指されたスクリプト)
9. verify 通過:
     - 子が項目 ID を含むメッセージで commit
     - 親が verify を再実行 (二重防御)
     - 親 verify も通過 → [ ] を [x] に印付け、続行
     - 親 verify 失敗 → revert、BLOCKERS に記録、次の項目へ
10. verify 失敗:
     - BLOCKERS に記録
     - 一度リトライ
     - まだ失敗 → blocked に印付け、次の項目へ
11. BLOCKERS が閾値 (デフォルト phase 当たり 3 個) に達する → abort
12. ステップ 2 に戻る

このループの核心的な性質たち、そして各々がなぜその形か。

反復ごとに一項目。子は「ここに来たついでにあれも直そう」をできない。system prompt が明示的に一 PRD 行に制限する。これがスコープドリフトを即死させる。

反復ごとに新しいセッション。項目間で context が運ばれない。次の項目は PRD を新しく読む。前の項目が微妙に悪い仮定を残しても伝播しない。

親が再検証。子の verify は一度のチェック。親の verify は同じスクリプトを、子のセッションの外で、commit された状態に再度回す。両者が食い違えば子の主張が間違っており、commit は revert される。幻覚で「verify passed」の行が書かれた場合でもシステムが生き残る方法だ。

Blocker の上限。一 phase に N 個の blocker が積まれれば phase は abort される。運営者が何が塞ぎ続けたかを検査し、根本原因を直すか PRD を書き直す。Ralph は同じ壁に永遠にぶつかり続けない。

4. Orchestrator — phase 境界が人間が住む場所

ralph-code.sh は phase 内の項目を扱う。ralph-orchestrator.sh は phase 間の遷移を扱う。

ある phase の ralph-code.sh が ALL DONE で終了した後:

1. 親が phase の Auto-Gate コマンドを実行
2. Auto-Gate 失敗:
     - DECISIONS に "Auto-Gate failed, see verify output" として記録
     - orchestrator を停止
3. Auto-Gate 通過、Manual-Gate なし:
     - ORCHESTRATOR-STATE.md に phase を [x] に印付け
     - 次の phase へ進む
4. Auto-Gate 通過、Manual-Gate あり:
     - DECISIONS に "Manual-Gate awaits: <承認者> approves <対象>" として記録
     - orchestrator を停止
5. 5 phase ごとに (状態に関わらず):
     - 強制 DECISIONS チェックポイント
     - orchestrator を停止
     - 運営者が /btw で方向を確認

三つの意図的な停止、各々が別の 人間にしかできない 責任に対応する。

Auto-Gate 失敗。技術的なイベントだが、解釈は人間のものだ。verify スクリプトが間違っていたか？spec が間違っていたか？世界が変わったか？運営者が決定する。orchestrator は永遠にリトライしない。

Manual-Gate 到達。明示的な引き継ぎ。lead が privacy policy、またはシードコンテンツ、または OAuth スコープの選択を承認する。この行は自動化できないので、orchestrator は扉の前で止まる。

強制チェックポイント。5 phase ごとに、何も問題が見えなくても、orchestrator が止まって方向を聞く。これは ドリフト安全網 だ。長期自律の最も厄介な失敗モードは「すべて動いたが間違った方向に行った」であり、知られている唯一の対策は固定周期の人間レビューだ。

5. DECISIONS キュー — 「人間が必要」を隔離する

3 つのファイルが ralph-loop/ に累積する:

ファイル	入る内容	トリガ	処理方法
`PROGRESS.md`	反復ごとに一行、成功または失敗	毎 iter	append-only、監査用
`BLOCKERS.md`	エージェントが解決できなかった技術的失敗	verify 二度失敗など	abort 閾値にカウント
`DECISIONS.md`	人間だけが決められるもの	オプション選択、セキュリティ/DB、依存追加	運営者が `/btw` で処理

これを機能させる規律は、子が解決できない状況をどう分類するかにある。

子が扱う方法を知らない状況に遭遇:
  ├── "やり方は分かる気がするが spec が沈黙" → BLOCKER
  ├── "合理的な選択肢が二つあり lead だけが選べる" → DECISION
  └── "新しい依存 / セキュリティレビュー / public API 変更が必要" → DECISION

迷ったら BLOCKER ではなく DECISION に分類する。決定を blocker に誤分類すれば反復を無駄にするだけだ。blocker を決定に誤分類すれば運営者を不要に起こすが、コードベースを壊すことはない。その非対称が要点だ。

[?] 状態 (決定保留) の PRD 項目は Ralph がスキップする。ループは [ ] 項目で回り続ける。やれることがすべて終わると [?] 項目だけが残り — ループは自然に終了し「運営者の番」を信号する。

6. `/btw` — 運営者側のループ

運営者側では相互作用全体が slash command 一つだ。

/btw

やること:

既知のすべてのプロジェクトの ralph-loop/DECISIONS.md を読む
保留中の決定を優先度で並べる (セキュリティ/DB +10 重み、待ち時間重み)
運営者にオプション付きの一括質問として提示
各回答ごとに:
- 決定を「保留」から「解決済み」に移し、回答とタイムスタンプを含める
- PRD で [?] を [ ] に戻し、決定に従って行内容を更新
- [Decision] D-NNN R0N: <要約> のメッセージで commit
影響を受けた phase で Ralph を再始動するか運営者に確認

運営者のメンタルモデルは — 私は質問に答えるのであって、作業を回しているのではない。orchestrator が実際の作業をした。orchestrator が私にしか決められないものに当たった。私が決める。orchestrator が続ける。

実際の形の相互作用:

運営者 (朝): /btw

Alice: 保留中の決定 3 件、2 プロジェクト。

  Project A (待ち 14 h):
    D-007  Phase P5 — トランザクションメールに Resend と Postmark のどちら？
           spec は沈黙。価格は Resend 優位、deliverability は Postmark 優位。
  Project A (待ち 14 h):
    D-008  Phase P6 — runtime 検証に `zod` 依存を追加？
           spec は runtime validator を予想していなかった。二つの代替:
           (a) zod (~14 kB)
           (b) hand-rolled validators

  Project B (待ち 2 h):
    D-002  Phase P2 — Manual-Gate: 機械翻訳コンテンツを lead が承認？
           24 ファイル、4 locale × 6 カテゴリ。サンプル diff 添付。

運営者: D-007: Resend。D-008: zod。D-002: 承認。

Alice: 3 件記録完了。Project A Phase P5 再開。
       Project B Phase P2 → P3 進行。Project B 継続。

あの会話が相互作用の全部だ。運営者はコードを書かなかった。ビルドを回さなかった。運営者は 1 分以内に 3 つの決定をした。Ralph がその会話の前に残りをやり、会話の後にも残りを続ける。

7. Ralph が間違った道具のとき

Ralph は万能ハンマーではない。ある形の作業には良くて、別の形には悪い。

良い適合。

似た項目が多数、各々が検証可能。(36 個の MDX ファイルに polish パスを適用。48 個の lens バリアントに boilerplate を生成。リネームされた関数の 24 個の呼び出し箇所をリファクタ。)
verify スクリプトが検査できる、生成されたテストやドキュメント。
大きな表面を一方向に動かす lint・format・型 strict バッチ。

悪い適合。

アーキテクチャ決定。(要点は決定が DECISIONS に行くことだが、すべての 項目が決定なら Ralph は作業をせずキューノイズだけを生む。)
セキュリティまたは DB スキーマ変更。両方とも Ralph が完全に検証できない不変量に触れ、両方とも「passed」が危険に間違う失敗モードを持つ。
public API 変更。verify スクリプトはローカル変更が動くことを確認できるが、下流の消費者がまだ動くかは確認できない。
新しい依存の追加。常に決定。

迷うときのヒューリスティック: 自分が眠っている間にこの commit が入っても気が楽か？yes なら Ralph。no なら運営者が同席する通常のセッションで。

8. 安全レール — 自律が火事にならないようにするもの

複数のレールが累積して Ralph を放置しても安全にする。

Worktree 隔離。Ralph は git worktree で回り、main では回らない。worktree は専用ブランチ (ralph/master-plan または ralph/{phase}) にある。運営者はいつでもブランチ全体を検査して廃棄できる。

Approved-By 行。orchestrator は Approved-By: lead, <date> なしでは Master Plan を始動しない。運営者の署名が機械的に強制される — 「lead がチャットで OK と言った」ではなく、orchestrator がパースするファイル内の文字列。

Verify が commit への唯一の道。子は verify スクリプトが 0 で終了しなければ commit できない。親が commit された状態で verify を再実行する。同じゲートの二つの独立した通過。

反復ごとに境界づけられたスコープ。子の system prompt が「正確にこの一 PRD 行を実装して止まれ」と言う。反復レベルのスコープクリープが機械的に塞がれる。

Phase abort 閾値。一 phase に N 個の blocker が積まれれば phase が abort される。計画全体に M 個の blocker が積まれれば orchestrator が abort される。システムは道が認識できなくなれば やめる。押し通そうとしない。

強制人間チェックポイント。5 phase ごとに orchestrator が止まって聞く。目に見えて間違ったものがなくても運営者が方向を確認する。人間レビューなしの長期無監督走行が最も危険なモードで、このレールがそれを塞ぐ。

決定隔離。運営者だけが決められるものは DECISIONS にルーティングされ Ralph がスキップする。エージェントは人間のものである問いを推測しない。

コスト上限。コストモニタリングは運営者の責任 (ccusage のような外部ツール)。予想外に高い phase は何かが漂流したという信号でもあり、点検する価値がある。

9. 一つの原則

Ralph の全体の形は一行に縮む。

「運営者の意図が日常として扱うものは、システムに自ら歩ませる。運営者の意図が決定として扱うものは、キューに入れて待つ。」

そしてその一行が、この 3 編の拡張の終わりであり — シリーズ自身のまとめでもある。

第1回 — Why Alice は問うた — 自分の意図を AI が失わないよう、どうやって蓄積するか？

最初の 9 編が答えた。意図の境界を引くペルソナ、セッションを越えて意図を保管するメモリ、動詞を圧縮する Skill、忘れそうなものを発動させる Hook、一つの context がすべてを背負わないようにする Multi-Agent、「完了」を固定する検証、信号スロットを守るトークン経済、そして毎日同じ場所から点灯して消灯するセッションプロトコル。

最後の 3 編が答えた。意図がセッションを生き残るよう PRD を書く。「完了」が事実になるよう release gate を書く。意図と到達の間の道が自ら歩くようループを回し、運営者は 自分のもの である決定だけを扱う。

12 個のピースがすべて所定の位置に収まると、運営者は 作業をする人 であることをやめ 何が作業する価値のあるものかを決める人 になる。意図 — 第1回の元の、還元不可能なそれ — はついにあるべき場所にある。スタックの頂上で、決定し、下のすべてが労働を背負っている。

これが運営者がこの数ヶ月かけて建てる時間を投じてきた AI 作業のバージョンだ。道具は Claude かもしれない、Codex かもしれない、次に来る何かかもしれない。上の 12 個の決定は道具に依存しない。道具を使う代わりに自分自身の協働者を 建てる と決めた誰にでも、同じ決定たちが待っている。

このシリーズがそれらの決定に到達する時間を少しでも縮めたなら — 運営者の意図は届くべき場所に届いたことになる。

12. Ralph loop — PRD から release まで、運営者なしで歩く道