計画の先制検証（Preemptive Plan Review）
実行前の計画は、最も安く直せる成果物である。
問題
エージェントは指示を受けると、すぐ作り始める。認識のずれがあっても、それが露見するのは大抵、成果物が出来上がってからである。しかもその頃には、ずれた前提の上にすでに大量の仕事が積まれている。修正はずれた部分だけでは済まず、その上に積まれた判断も一緒に崩れる。 ずれの発見が遅いほど、捨てる量が増える。
コンテキスト
適用する条件:
- 手戻りの代償が大きい — やり直しに時間・コストがかかる仕事
- 指示が抽象的で、進め方に複数の妥当な選択肢がある
- こちらの意図が、指示を書いた時点でまだ言語化しきれていない — 計画は「エージェントがこう理解した」の可視化になる
適用しないケース:
- やり直しが安い作業。 計画を読むコストが、手戻りのコストより高くつく
- 計画が自明なとき。 1ファイルの明白な修正に、計画の往復は要らない
- 探索そのものが目的のとき。 何をすべきかを調べるのが仕事であるなら、調べ終える前に計画は立たない
隣接パターンとの境界:
- 成果物の差分レビューと段階的採用 — 時間軸が違う。同パターンは出てきた物を受け取る作法、本パターンは出てくる前に介入する作法である。両方とも人間の介在点だが、置く位置が違うだけである
- 検証対象の明示 — 本パターンはやる前に計画を検証し、同パターンはやった後に何を検証させるかを扱う
- 思考深度をタスクに合わせる — 公式（VS Code）が「計画には推論モデルを、実装には速いモデルを」と推している（出典は具体例節）。本パターンが分ける位相が、深度を変える理由の一つになる
- 読み捨ての隔離 — 計画を立てるための調査そのものは隔離してよい。主コンテキストに持ち帰るのは計画である
解決
なぜ効くのか。二つの理由がある。
第一に、訂正費用の非対称性である。同じ「ずれ」でも、直す費用は発見された時点に強く依存する。計画段階のずれは、文章の書き換えで済む。実装後のずれは、コードの書き換えに加えて、その上に積まれた判断も一緒に崩れる。
同じ検証を、より早い時点に置くだけで、費用は下がる。これはエージェント固有の話ではない — 人間の設計レビューが同じ理由で存在する。
ただしエージェントでは効きが大きい。 エージェントは速く作業を進めるため、放置すれば、ずれた前提の上に積まれる仕事の量が、人間の場合よりずっと多くなる。
第二に、計画は「理解の可視化」である。 人間の指示はほとんどの場合曖昧であり、こちらは自分の指示が曖昧だったことに、出てきた成果物を見るまで気づかない。計画は、エージェントが指示を何とどう受け取ったかを、短い形で提示する。ここで見つかるずれは、多くの場合エージェントの誤りではなく、指示の側の穴である。
したがって本パターンの利得は、エージェントの進路を正すことだけではない。自分の指示の穴を、安く見つけることにもある。
図の階段は連続な傾きではなく、工程の境界を越えるたびに跳ね上がる段差である。境界を一つ手前に置くだけで、支払う額は一段分下がる。本パターンが指す「先制」とは、この段差のうち最も低い段を選んで介入するという意味であり、検証そのものを新しく持ち込むことではない。
トレードオフ
利点
- 手戻りが最も安い時点で直せる。 図の階段が示すとおり、後工程に行くほど同じ修正は高くつく。計画段階で捨てるものは、せいぜい数百字の文章である。
- 指示の曖昧さが可視化される。 ずれの多くは、エージェントの誤りではなく指示の穴として見つかる。この利得は、計画を書いたのがエージェントであっても、気づくのは人間の側だという点にある。
代償
- 計画を読む時間がかかる。 小さい仕事では、計画を読むより作らせて捨てるほうが速い。往復のたびに人間の手が要るため、細かく刻みすぎると本パターン自体が手戻りの原因になる。
- 計画が正しく見えることと、実行が正しいことは別である。 妥当な計画を承認しても、実装がその通りになる保証はない — 命令の遵守が非決定的にしか効かないのと同じである。承認は保証ではない。 計画の検証は、実行後の検証を省略してよい理由にはならない。
GitHub Copilot での具体例
Copilot は単一の製品ではない。本カタログが原文で確認できたのは、この実践に対応するものがCopilot CLI には機能として、VS Code には運用の助言として現れている、というところまでである。「Copilot には plan mode がある」と一括りにしない。
Copilot CLI — plan mode という機能
出典: CLI command reference（取得日: 2026-07-16）公式:
--mode=MODE| Set the initial agent mode (choices:interactive,plan,autopilot). Cannot be combined with--autopilotor--plan.〔訳〕
--mode=MODE: 初期のエージェントモードを設定する(選択肢:interactive、plan、autopilot)。--autopilotや--planと組み合わせることはできない。
--plan| Start in plan mode. Shorthand for--mode plan. Cannot be combined with--modeor--autopilot.〔訳〕
--plan: plan mode で開始する。--mode planの省略形である。--modeや--autopilotと組み合わせることはできない。
対話の途中からでも切り替えられる（出典: Running tasks in parallel with the /fleet command、取得日: 2026-07-16）公式:
Press Shift + Tab to switch into plan mode and work with Copilot CLI to create an implementation plan.
〔訳〕Shift + Tab を押すと plan mode に切り替わり、Copilot CLI と共に実装計画を作成できる。
plan mode は「計画を先に出させる」ためのモードであり、それ自体は本パターンの片側 — エージェント側の準備 — でしかない。その計画を人間が読み、直すところまでが本パターンである。 起動時に一括で計画モードへ入る（--plan）だけでなく、対話の途中で必要に気づいてから切り替える経路（Shift + Tab）も用意されている。先に決めておく手立てと、途中で気づいてから切り替える手立ての両方があることは、本パターンの適用条件を「最初から分かっている仕事」に限定しない。
Copilot CLI — 計画に敵対的な批評をつける、既定で有効な仕掛け
同 CLI には、計画そのものを検証するための組み込みエージェントがある（出典: CLI config dir reference、取得日: 2026-07-16）公式:
builtInAgents.rubberDuck|boolean|true| Enable the rubber-duck subagent that provides adversarial feedback on agent plans.〔訳〕
builtInAgents.rubberDuck(型:boolean、既定値:true): エージェントの計画に敵対的なフィードバックを与える rubber-duck subagent を有効にする。
既定は true である。計画への敵対的な検証が、製品側に既定で有効な形で入っている。「実行前に計画を検証する」という本パターンの本体を、検証者を人間からエージェントに置き換えて実演している。 本カタログが確認できたのはこの設定キーの既定値までであり、この検証が会話中のどの時点で差し挟まれるかまでは踏み込まない。
VS Code — 運用としての助言
VS Code の面で本カタログが確認できたのは、機能名ではなく運用としての助言である（出典: Optimize your AI usage、取得日: 2026-07-16）公式:
Jumping straight into code generation can lead to wasted effort if the approach is wrong. It also requires a model with enough reasoning capability throughout the process, which can consume more credits. Instead, separate the planning and implementation phases. This allows you to use a reasoning model for planning, and then switch to a faster, more efficient model for implementation once the plan is solidified.
〔訳〕いきなりコード生成に入ると、進め方が誤っていた場合に労力が無駄になりうる。また、その過程全体を通じて十分な推論能力を持つモデルが必要になり、より多くのクレジットを消費しうる。代わりに、計画の段階と実装の段階を分けるとよい。これにより、計画には推論モデルを使い、計画が固まった後は、より速く効率的なモデルに切り替えて実装できる。
いきなりコード生成に入ると、進め方が誤っていた場合の労力が無駄になる（wasted effort if the approach is wrong）— この一文が、「問題」節で述べた損失の構造そのものである。ここでの提案は機能の名前ではなく運用 — 計画の段だけ推論モデルに任せ、計画が固まってから速いモデルに切り替える、という順序の作法である。
面による違い
| 面 | 何があるか | 状態 |
|---|---|---|
| Copilot CLI | plan mode という機能（--mode=plan / --plan）＋計画への敵対的検証を行う rubberDuck サブエージェント（既定 有効） | 機能として確認済み |
| VS Code | 「計画と実装の段階を分けよ」という運用の助言 | 助言として確認済み |
同じ「実行前に計画を扱う」という狙いが、一方は機能として、他方は運用の助言として現れている。両方を並べることはできるが、同じ機能だとは書かない。 実践としては、CLI ではモードを明示的に切り替えて計画を先に出させ、承認してから実装に移る。VS Code では、計画の段だけ推論に強いモデルを選び、固まってから実装用のモデルに切り替える。呼び名も操作も違うが、支払っているものは同じである — 計画の段に時間とモデルの計算資源を割り当てる、という判断そのものである。
別名
| 呼称 | 出典 |
|---|---|
| Plan mode | 一次 — Copilot CLI 公式のモード名（--mode=plan / --plan。出典は具体例節）。ただしこれは機構の名であり、本パターンの名ではない |
| 計画の先制検証 / Preemptive Plan Review | 記述 — 本カタログの記述的呼称であり、一次資料に出典は無い |
公式が名前を与えているのは、計画を出させるモードまでである。「出た計画を人間が読み、直す」という実践には、確認できた範囲で確立した呼称が無い。モードに切り替えても、出てきた計画を読まずに承認すれば、この実践は行われていない。モードは入れ物であり、本パターンは中身の使い方である（失敗の制度記憶化 の別名節と同じ構図 — 入れ物の名前を実践の名前として使うと、「モードがある＝この実践をしている」という誤解になる）。
関連
- 成果物の差分レビューと段階的採用 — 実行前に計画を検証するのが本パターン、実行後に成果物を検証するのが同パターンである。人間の介在点という同じカテゴリの中で、置く位置が違う
- 検証対象の明示 — 本パターンはやる前に計画を検証し、同パターンはやった後に何を検証させるかを扱う
- 思考深度をタスクに合わせる — 計画には推論モデル、実装には速いモデルと**公式**（VS Code）が推している（出典は具体例節）。本パターンが分ける位相が、深度を変える理由の一つになる
- 読み捨ての隔離 — 計画を立てるための調査そのものは隔離してよい。主コンテキストに持ち帰るのは計画である
- まず次に読むなら 成果物の差分レビューと段階的採用 — 実行前の介在を見たら、次は受け取り時の介在を見る番である