F-5: Plan-then-Execute vs ReAct¶

この相反は何か¶

複数ステップのタスクを処理する際、まず計画を立ててから実行する（Plan-then-Execute）か、観察と行動を逐次的に交互に繰り返す（ReAct: Reasoning + Acting）かという二者択一です。これは「未来をどこまで見通してから動くか」に関する根本的な設計方針の違いです。

この選択が排他的である理由は、計画の扱い方がアーキテクチャ全体に影響するためです。Plan-then-Executeでは計画が明示的な中間成果物（構造化データ）として存在し、人間のレビュー・承認の対象になります。ReActでは計画は暗黙的であり、LLMの内部推論として各ステップの判断に織り込まれるだけで、外部から参照可能な「計画」は存在しません。この違いにより、承認フロー・コスト制御・デバッグの設計が根本的に異なります。

AIエージェント固有の事情として、LLMは1リクエストが高コスト（F2）であり、計画なしに試行錯誤するとトークンを浪費します。一方で環境が動的に変化する場合、精緻な計画を立てても実行中に陳腐化し、再計画のコストが膨らみます。[task_variability] がこの相反の支配的な駆動変数です。

選択肢A：Plan-then-Execute（計画先行）¶

タスクを受け取ったら、まずLLMが実行計画を構造化データ（JSON/YAML）として生成します。計画にはステップの順序、各ステップで呼ぶツールと引数、期待される結果が含まれます。計画が確定してから（必要に応じて人間が承認してから）、各ステップを順次実行します。実行結果は計画時の期待と照合されます。

Plan-then-Executeの最大の利点は透明性と制御性です。計画が明示的な中間成果物であるため、実行前に人間が「この手順で大丈夫か」を確認できます。不可逆な操作（決済、データ削除、外部送信）を含む計画を事前に検証でき、[failure_cost] が高い環境で安全性を確保できます。デバッグでも「計画が間違っていたのか、実行が間違っていたのか」を分離して調査できます。

コスト面でも有利です。計画段階で不要なステップを刈り込めるため、試行錯誤的なアプローチと比べてトークン消費を抑制できます。計画のステップ数からコストの上限を事前に見積もれるのも利点です。

弱点は計画の陳腐化です。環境が実行中に変化する場合（APIが一時的にダウンする、データの状態が他のプロセスで変わるなど）、計画の前提が崩れます。再計画の仕組みがないと、無効な計画を盲目的に実行し続けてしまいます。再計画を許容すると、「計画→失敗→再計画→失敗→再計画」のメタレベルのループが発生しうるため、再計画回数に上限を設ける必要があります。

選択肢B：ReAct（逐次推論行動）¶

LLMが「観察（Observation）→推論（Reasoning）→行動（Action）」のサイクルを1ステップずつ繰り返します。各ステップで環境の最新状態を観察し、それに基づいて次の1アクションを決定し、実行結果を次の観察として取り込みます。全体の計画は明示的に生成されず、LLMの内部推論に委ねられます。

ReActの最大の利点は適応性です。環境の変化にステップ単位で対応でき、予期しない状況（APIエラー、予想外のデータ形式、ユーザーからの追加情報）にも柔軟に反応できます。計画を立てる余裕がないほど動的な環境や、そもそも手順が不明で探索的に進める必要があるタスクに適しています。

実装の単純さも利点です。計画の生成・保存・検証・再計画のインフラが不要で、ツールセットとループ制御だけで動作します。プロトタイプや探索的な開発では、ReActで素早く動かしてから、手順が安定した部分をワークフロー化する段階的アプローチが有効です。

弱点は予測不能性とコストです。LLMが何ステップ踏むか事前にわからないため、コスト見積りが困難です。「もう少し調べよう」「もう一回試そう」と自己ループ（F13）に陥るリスクがあります。人間が実行前に手順を確認する機会がなく、不可逆な操作を含む場合は危険です。B3 予算付き自律ループによる予算制御が不可欠です。

選定基準¶

選定は [task_variability] を主軸に判定します。

環境の動的さを基準にした判定：

環境の特性	判定
静的：実行中にデータや外部状態がほぼ変わらない	Plan-then-Execute
半静的：大枠は安定だが一部のステップで状態が変わりうる	Plan-then-Execute＋逸脱時の再計画
動的：各ステップの結果が次のステップの選択を大きく左右する	ReAct

タスクの性質を基準にした判定：

タスクの性質	判定
手順が定型で人間が事前に承認したい	Plan-then-Execute
手順は概ね分かるが細部は実行時に決まる	Plan-then-Execute（粗い計画＋実行時微調整）
手順自体が不明で探索的に進める必要がある	ReAct

加えて、[failure_cost] が高い場合はPlan-then-Executeに強く倒す動機があります。不可逆な操作を含む処理では、実行前に計画を確認・承認できることが安全上不可欠です。

デフォルトとハイブリッド¶

デフォルト：計画先行（Plan-then-Execute）で、計画は人間が編集可能にしてください。 計画が明示的な中間成果物として存在することで、LLMの判断を人間が検証・修正する機会が確保されます。計画が陳腐化するリスクには再計画の仕組みで対処しますが、再計画回数には上限（概ね2〜3回）を設けます。

ハイブリッド：計画先行＋逸脱時のみ再計画が最も実用的な折衷です。まずPlan-then-Executeで計画を立て、各ステップの実行結果が期待と大きく異なる場合にのみ再計画を発動します。再計画では失敗した情報を添えて新しい計画を生成するため、同じ失敗を繰り返しにくくなります。B4 計画-実行-検証がこのアプローチを体現しています。

判断を誤ったときの症状¶

Plan-then-Executeを選ぶべきだったのにReActを選んだ場合：

毎回ほぼ同じ手順を踏むのに、LLMが手順を「再発見」するためにトークンが浪費されます。
不可逆な操作が人間の承認なしに実行され、インシデントが発生します。
事後に「どういう手順で処理されたか」を再構成するのに、全ステップのログを読む必要があります。
[failure_cost] が高い操作で、LLMが誤った判断をしたことに気づくのが実行後になります。

ReActを選ぶべきだったのにPlan-then-Executeを選んだ場合：

計画の半分以上のステップで再計画が必要になり、計画→再計画のループでトークンが浪費されます。
APIエラーや予想外のデータに対して、計画に書いていないため「該当ステップなし」で止まります。
計画生成に時間がかかり、実行開始までのレイテンシが不必要に増大します。
探索的なタスクで、LLMが本来なら動的に見つけられる解決策を、計画の制約で見逃します。