ralplan とは何か
ralplan は oh-my-claudecode（略して OMC）というオープンソースのハーネスに入っているプランニングワークフローだ。ハーネスとはモデルそのものではなく、そのモデルをどの順序で、どの役割で、どんな検証を通して働かせるかを定めた規則の束を指す。同じモデルでもハーネスが違えば結果が変わる。
使い方は一行だ。Claude Code のターミナルで /oh-my-claudecode:ralplan "決済失敗のリトライ処理を追加" のように書けばよい。この名前は /oh-my-claudecode:plan --consensus の短い別名で、consensus は合意という意味だ。
ここから先が普通のコーディングエージェントと違う。多くのエージェントは依頼を受けるとすぐファイルを開いてコードを書き始める。ralplan はコードを書かない。代わりに Planner・Architect・Critic が順番に、一つの計画ドキュメントを巡って合意に至るまで回る。合意ができて初めて人に承認を求め、承認が下りて初めて実行段階に進む。
なぜ一つのエージェントで済ませないのか
同じモデルに「計画を立てて」と頼み、続けて「この計画をレビューして」と三度尋ねればよさそうに見える。しかし実際には三度とも同じ死角に落ちる。自分が今書いたものを自分で反駁するのは、人間にとっても難しい。
そこで ralplan は役割ごとに権限と義務を変える。草案を書く側には形式を強制し、反論する側からは直す権限を取り上げ、判定する側には差し戻しの義務を課す。三つのエージェントは異なるプロンプトと異なるツール権限で起動する — 名前だけ違う同じ呼び出しではない。
以下の三節が、それぞれの役割が出すべきものだ。
Planner — 選択肢を最低二つ出す
Planner は計画の草案を書く。ただし自由には書けず、RALPLAN-DR という形式を埋めなければならない。必須項目は三つ — この計画が守る原則 3〜5 個、選択を分ける決定要因の上位 3 個、そして実行可能な選択肢を最低二つ、それぞれに範囲を限った長所と短所を添える。
いちばん効くのは最後の条項だ。残った案が一つだけなら、他をなぜ捨てたのかという無効化の根拠を書かねばならない。この一行が「最初に思いついた方法」がそのまま正解になる流れを断つ。比較対象が文書に残るので、数週間後の「なぜこう作ったのか」にも答えが残る。
成果物は会話の中に散らばらず、.omc/plans/ 配下に markdown ファイルとして保存される。計画は 3〜6 個の実行可能なステップで書き、各ステップに実行者が検証できる完了条件を付ける。30 個の枝葉リストでも、二行の宣言でもない。
リスクの高い作業で --deliberate を付けると、三つの失敗シナリオを想定するプレモーテムと、ユニット・結合・e2e・可観測性まで含む拡張テスト計画が追加される。
Architect — 直せないからこそ反論が立つ
Architect は Planner の書いた計画を読み、設計の観点から反論する。このエージェントの定義には disallowedTools: Write, Edit と書かれている — ファイルを書く・直すためのツールが完全に塞がれた、読み取り専用のエージェントだ。
権限を外したことが肝だ。直せる者は反論より先に手を出す。直せなければできることは一つしかない。Architect に求められる成果物は、有力案に対する最も強い反論（steelman antithesis）、少なくとも一つの実在するトレードオフの緊張、そして可能なら両者をつなぐ統合案だ。
根拠にも縛りがある。指摘はすべて file:line の参照を伴い、症状ではなく根本原因を突き、「リファクタリングを検討してはどうか」のような曖昧な助言は許されない。deliberate モードでは、計画が Planner 自身の立てた原則をどこで破っているかを明示する。
反論役をまるごと別のモデルにしたいときは --architect codex を渡す。Codex CLI が入っていればその段階だけ Codex が担い、なければ静かに既定の Architect に戻る。同じモデル三体が共有する死角まで外したいときのスイッチだ。
Critic — 通すためではなく、差し戻すためにいる
Critic の定義に書かれた前提が、このワークフロー全体の性格を決めている。誤った承認は、誤った差し戻しより 10〜100 倍高くつく。だから Critic は親切なレビュアーではなく最終品質ゲートとして設計され、書き手は承認を求めに来た側として扱われる。
見る角度も違う。通常のレビューは書かれているものを評価するが、Critic は書かれていないものも見る。実行者・利害関係者・懐疑者という三つの視点を順に当てて抜けを探す。確認項目は、原則と選択肢が噛み合っているか、代替案を公正に検討したか、リスク緩和が具体的か、完了条件が実際にテスト可能か、検証手順が書かれているかだ。
そして差し戻しの義務がある。浅い代替案、決定要因どうしの矛盾、ぼんやりしたリスク、弱い検証は明示的に拒否しなければならない。deliberate モードでは、プレモーテムや拡張テスト計画が欠けている、あるいは薄いというだけで差し戻しの理由になる。判定は承認・差し戻し・却下の三つのいずれかだ。
三役が揃って初めて生まれる三つの利点
一つ目、順序が強制される。Architect が終わる前に Critic を呼ばない。ドキュメントに大文字で書かれた規則で、二つの呼び出しを同じ並列バッチに入れるなとまで明記されている。同時に呼べば互いの指摘を読めないので、合意ではなく独白が二つ出てくる。
二つ目、やり直しが閉ループになっている。Critic が差し戻しか却下を出すと、Architect と Critic の指摘をまとめて Planner が計画を直し、再び Architect から審査が始まる。直した部分だけを見るのではない。このループは最大五回まわり、五回で承認に至らなければ、合意に届かなかったという説明とともに最良版を人に渡す。
三つ目、承認までコードが凍結される。計画は pending approval と印され、それまで ralplan はファイルを直すことも、コミットも、PR を開くことも、実行スキルへの委譲もできない。計画段階がコードに触り始めた時点で、計画は既にやったことの事後正当化に変わる。
承認後の実行もこのワークフローが自分でやるわけではない。--interactive で回していれば最後に実行方式を選ぶ問いが出て、選択に応じて team（並列実行）か ralph（順次実行と検証）へ引き渡す。計画する者と作る者を分ける原則が最後まで保たれる。
どう始めるか
まず Claude Code が入っていること。次に OMC を入れる。プラグインとして /plugin install oh-my-claudecode を実行するか、ターミナルで npm i -g oh-my-claude-sisyphus@latest を走らせる。どちらの場合も、そのあと /oh-my-claudecode:omc-setup を一度実行すれば準備は終わりだ。
基本の呼び出しは /oh-my-claudecode:ralplan "タスクの説明" だ。フラグを付けなければ Planner → Architect → Critic のループが自動で回り、仕上がった計画を pending approval と印して出力し、そこで止まる。途中で尋ねず、何も実行しない。
よく使うフラグは四つ。--interactive は草案レビューと最終承認の二か所で人に尋ねる。--deliberate は三シナリオのプレモーテムと拡張テスト計画を足すが、認証・セキュリティ・マイグレーション・本番障害・個人情報のようにリスク信号がはっきりした依頼では付けなくても自動で有効になる。--architect codex と --critic codex は、それぞれ反論役だけ、審判役だけを Codex に替える。
成果物は .omc/plans/ 配下に markdown として残り、末尾に ADR（決定・決定要因・検討した代替案・選んだ理由・帰結・フォローアップ）が付く。このファイルが実行の指示書であり、後から決定をたどる記録にもなる。
いつ使い、いつ使わないか
ralplan がいちばん効くのは、いきなり実行させようとした瞬間だ。OMC には「ralph でアプリをちょっと良くして」のような曖昧な実行依頼を横取りして ralplan に回すゲートがある。範囲が不明なまま複数のエージェントを立てると、本来は計画段階でやるべき範囲探索を実行しながらやることになり、結果はたいてい部分実装か方向のずれた成果物だ。
逆に、誤字の修正、関数一つのリネーム、一行の設定変更のように戻しやすく判断の余地がない作業には過剰だ。合意ループはただではなく、時間とトークンを使う。
基準を一つに縮めるとこうなる。元に戻すコストが計画するコストを上回る作業なら ralplan を使う。データマイグレーション、認証構造の変更、公開 API の修正、決済フローに手を入れる作業がここに入る。誤った承認は誤った差し戻しより 10〜100 倍高いという Critic の前提は、人が働く場面でもそのまま成り立つ。