Plan-and-Execute：先に計画してから実行する

横にスクロール

どんなパターンか

AIエージェントに込み入った仕事を任せるとき、最も素朴なやり方は「一手ずつ考えさせる」ことだ。次に何をすべきかをLLMに尋ね、返ってきた行動を実行し、その結果をまた渡して次の一手を尋ねる。この観察と行動を交互に繰り返す進め方がReActであり、単純で柔軟だが、手数が伸びるほど話が逸れやすいという弱点を抱える。

Plan-and-Execute（計画してから実行する）は、この順序を組み替える。まず最初に、与えられた課題をサブゴールの列へと分解した全体計画を立てる。そのうえで、計画に並んだステップを頭から一つずつ実行していく。行き当たりばったりに次の一手を探すのではなく、はじめに地図を描いてから歩き出すわけだ。

たとえば「競合3社の価格を調べて比較表にまとめよ」という課題を考える。ReActは毎回「まず何を検索しようか」と一手ずつ考えるが、Plan-and-Executeは着手前に「A社を調べる／B社を調べる／C社を調べる／3件を表に整形する」という4ステップの計画を先に固め、あとはそれを順にこなすだけになる。手数が3社どころか30項目に増えても、計画がある側は最後のステップまで筋を保ちやすい。

先に道筋を描く効果は三つある。第一に、脱線しにくい。全体像が計画として固定されているため、途中のステップで細部に気を取られても、最終ゴールを見失いにくい。第二に、トークンを節約しやすい。一手ごとに長い履歴を読み直して「次に何をするか」を考え直す負担が減り、費用のかかる思考を計画づくりの一度きりに集約できる。第三に、検証や再利用がしやすい。計画は人間が目を通せる中間成果物になり、実行前に妥当性を確かめたり、似た課題で計画を使い回したりできる。

仕組み

典型的な構成は、計画を立てるプランナーと、計画を実行する実行役の分業だ。

プランナーは、課題を受け取り、それを達成するためのサブゴールの列を出力する。多くの場合これはLLMへの一回の問い合わせで、「このゴールを、順に実行できる小さなステップへ分解せよ」と指示する。出力は番号付きの手順リストや、各ステップと使うツールを対応づけた構造化データになる。ここで粒度が肝心で、細かすぎれば計画自体が長大になり、粗すぎれば一つのステップに複数の判断が詰まって実行役が困る。

実行役は、計画のステップを先頭から順に取り出し、一つずつこなす。あるステップはツール呼び出し（検索、コード実行、API呼び出しなど）で、別のステップはLLMによる要約や整形かもしれない。ここで重要なのは、実行役が「次に何をするか」を毎回ゼロから考え直さないことだ。次にやることは計画がすでに指定している。だから実行役は、目の前のステップを正しくこなすことだけに集中でき、これが脱線とトークン浪費の両方を抑える。

もっとも、ステップは完全に独立しているわけではない。前のステップの出力を次のステップが使う場面は多く、実行役は各ステップの結果を作業用のメモリへ蓄え、後続へ引き渡す。この受け渡しをどう設計するか——全結果を丸ごと渡すのか、要約してから渡すのか——も、トークン量と正確さを左右する、地味だが重要な論点だ。

だが、計画は立てた時点の想定にすぎない。実行してみて初めて分かることは多い。検索の結果が空だった、想定したファイルが存在しなかった、前のステップの出力が次の前提を満たさなかった——こうしたずれが起きたとき、古い計画に固執して残りのステップを機械的に消化しても、正しい結果には届かない。

そこで要るのが再計画（replan）だ。実行役が各ステップの結果を観察し、計画との食い違いを検知したら、そこまでの実績を踏まえてプランナーに計画を作り直させる。先の例でB社の価格ページが消えていたなら、「B社は決算資料から推定する」という別ステップへ差し替える、といった具合だ。全部を捨てて一から引き直すこともあれば、残りのステップだけを差し替えることもある。どこまで作り直すかは、ずれの深さ次第だ。前提が根本から崩れたなら全面的に、局所的な取りこぼしなら部分的に直す。この「実行→観察→必要なら再計画」というループがあって初めて、Plan-and-Executeは現実の不確実さに耐える。

使いどころと注意

Plan-and-Executeが映えるのは、ゴールまでの手順がある程度見通せて、かつ手数の多い多段タスクだ。資料を集めて要約し、比較表にまとめて結論を書く、といった一連の作業では、先に段取りを決めておく利点が大きい。逆に、次の一手が直前の結果へ強く依存し、探索的に進むしかない対話では、先に固めた計画がかえって足かせになる。この場合はReActの即応性が勝る。両者は排他ではなく、大枠をPlan-and-Executeで敷き、各ステップの内側でReAct的に細かく動く、といった組み合わせも有効だ。

計画の粒度は、最初に迷う点だ。一つの目安は、各ステップが「一つのツール呼び出し、または一つの明確な判断」に対応する程度へ割ることだ。細かくしすぎると計画が長くなり、プランナーの負担も再計画のたびの費用も増える。粗くしすぎると、実行役が一つのステップの中で結局その場の判断を迫られ、計画を先に立てた意味が薄れる。手戻りが多いと感じたら、まず粒度が課題に合っているかを疑うとよい。

計画づくり自体にも費用がかかる点は見落としやすい。ゴールが単純で二、三手で終わるなら、わざわざ全体計画を立てるより、ReActでそのまま進めたほうが速く安い。Plan-and-Executeが元を取るのは、計画時の一度の思考が、その後の多くのステップで繰り返しの熟考を省いてくれる長丁場のタスクだ。

再計画の設計も詰めるべき点が多い。いつ再計画を起動するか（毎ステップ後か、失敗を検知したときだけか）、何回まで作り直しを許すか（無限ループを避ける上限）、作り直しの際にこれまでの計画と実績をどうプランナーへ渡すか。ここを詰めないと、再計画が暴走してトークンを浪費したり、逆に発動せず脱線を放置したりする。上限回数と、打ち切ったときの後始末は、最初に決めておきたい。

役割が増え、計画そのものが判断を要する規模になれば、計画を専門に受け持つエージェントと実行を受け持つエージェントに分けるマルチエージェント構成へ発展させる道もある。もっとも、分割は調整の複雑さも招くので、単一のプランナーと実行役で足りるうちは、無理に増やさないほうがよい。

まとめ

Plan-and-Executeは、「先に全体を計画し、その計画に沿って逐次実行する」という順序の組み替えで、長い多段タスクの脱線を抑え、トークンを節約するパターンだ。核心は計画と実行の分業にあり、そして計画を絶対視しない再計画の仕組みが、それを机上の理論から実務の道具へと変える。一手ごとに考えるReActとは補い合う関係にあり、タスクの性質に応じて使い分け、あるいは大枠と細部で組み合わせればよい。設計の勘所は、計画の粒度・失敗時の再計画・計画と実行の分業という三点に尽きる。ほかのエージェント設計パターンは設計パターン一覧から辿れる。