AIエージェントのプランニングとは？計画を立てる仕組みと再計画の設計を実装目線で解説

AIエージェントのプランニングとは、ゴールを受け取ったモデルに「どの順序でどのサブタスクを片づけるか」を先に決めさせ、その計画を状態として保持したまま実行させる工程を指します。ツール呼び出しが「1手をどう打つか」なら、プランニングは「何手先まで決めておくか」の設計です。実装で詰まるのは計画の作り方ではありません。計画をどの形式で持つか、どこで作り直すか、どこで打ち切るか。この記事では暗黙プランニングと明示プランニングを分ける判定線、Plan-and-ExecuteとReWOOとLLMCompilerと外部プランナーの論文実測差、再計画のトリガー設計、そして入れずに済ませるべき場面までを実装者向けに整理します。

まとめ｜プランニングの実体と着手前に決める3つの設計点

実体は「計画を状態として持つかどうか」の一線です。ReActのように1手ずつ考えて次を決める方式でも頭の中では計画していますが、その計画はコンテキストに溶けて消えます。明示プランニングは計画を構造化データとして外に出し、検証・差し替え・監査の対象に変える。この違いが、費用も安全性も分けます。

着手前に決めるのは3点です。第一に計画の表現形式。自然言語のリストで持つか、ステップIDと依存関係を持つ構造化データにするかで、実行側が計画を検証できるかどうかが決まります。第二に再計画のトリガーと上限。何が起きたら作り直すのかを列挙し、同時に「作り直さない条件」と回数上限を決めておかないと、失敗したステップの周りを延々と回り続ける。第三に権限の固定タイミング。未信頼データを読み込む前に許可するツールを確定させておけば、実行中に計画を書き換えられる攻撃の効き幅がかなり狭まります。この3点を決めずにPoCを本番へ上げると、動くデモのまま費用と事故だけが積み上がります。

プランニングの定義とReActの逐次判断が計画と呼べない理由

「計画を立てる」という日本語が広すぎるせいで、まったく設計思想の違う2つが同じ名前で語られています。

ゴールをサブタスク列へ落とす工程とツール呼び出しを分ける責務境界

プランニングの入力はゴール、出力はサブタスクの列です。ここで出てくるのは「何をどの順でやるか」だけで、実際にAPIを叩く工程は含まれません。1つのサブタスクを実行する段になって初めて、モデルが関数名と引数を決め、アプリ側がそれを実行するAIツール使用の仕組みが動きます。プランニングが上流、ツール使用が下流。責務がこう分かれているため、計画が良くても引数の検証が甘ければ落ちますし、逆にツール定義が完璧でも計画が破綻していればゴールに届きません。

境界を混ぜると設計が濁ります。ツール使用の層に「次に何をすべきか」の判断を持たせた瞬間、計画は状態から消え、毎ターンのプロンプトの中でしか存在しなくなる。この状態を明示プランニングと呼ぶことはできません。

計画が状態に残るかで分かれる暗黙プランニングと明示プランニング

判定線は1つだけです。実行中の任意の時点で「残りの計画」を構造として取り出せるか。取り出せるなら明示、取り出せないなら暗黙です。

暗黙側の代表がReActパターンで、思考と行動を交互に出しながら1手ずつ進みます。全体像を持たないぶん途中で方針を変えるのは得意ですが、ステップが増えるほど毎ターン全履歴を読み直すことになり、費用と遅延が線形以上に膨らむ。明示側は最初にステップ列を書き切ってから実行に入るため、各ステップの実行では計画全体を読み直す必要がなく、小さいモデルへ実行を任せる余地も生まれます。ReWOOの論文（arXiv:2305.18323）は、この分離によって175BのGPT-3.5が担っていた処理を7BのLLaMAへ落とす構成を実証しました。

先に全体を分解する型と実行しながら分解する型を分ける3つの判断基準

明示プランニングの内側でも、計画をいつ確定させるかで2系統に割れます。分解優先型は着手前にサブゴールをすべて書き出し、そのあと各サブゴールの手順を詰める。交互型は1ステップ分だけ計画し、実行結果を見てから次を計画します。

• ゴールに至る手順が着手前に判明しているか（判明していれば分解優先型）
• 途中の観測結果が後続ステップの分岐を左右するか（左右するなら交互型）
• 実行のやり直しコストが高いか（高いなら分解優先型で事前検証を挟む）

3つのうち2つ以上が分解優先型を指すなら、迷わず分解優先型にしてよい。逆に観測依存の分岐が本質な業務、たとえば検索結果の中身次第で調査方針が変わるようなタスクは、事前に書いた計画が1ステップ目で無効になります。Anthropicの「Building effective agents」がorchestrator-workersを「サブタスクを事前に予測できない場合に向く」と限定しているのも同じ理由です。

主要4アーキテクチャの構成要素と論文実測値で見る費用と遅延の差

明示プランニングの実装は、この10年でほぼ4系統に収れんしました。どれを選ぶかは好みではなく、タスクの依存構造で決まります。

Plan-and-Execute・ReWOO・LLMCompiler・外部型の構成比較

4系統の違いは、計画に何を書けるかと、実行時に何回モデルを呼ぶかに集約されます。数値はいずれも各論文が公表した比較条件下の値で、自社タスクでそのまま再現する性質のものではありません。

実務での初手はPlan-and-Executeです。LangGraphのチュートリアルが plan_step・execute_step・replan_step の3ノードで組めるように、実装量が最も軽く、ここから並列化や変数参照へ寄せていくのが順路になります。いきなりDAGを設計する必要はありません。

変数参照でワーカーにモデルを呼ばせないReWOO記法の適用条件

ReWOOの肝は、計画の中で前のステップの出力を変数として参照する点にあります。「ステップ1の結果を使ってステップ2を実行する」を計画文中に書けるため、ステップ2に入る時点でモデルへ聞き直す必要がありません。観測を待たずに計画を最後まで書き切れる構造がトークン効率5倍という値を支えています。

適用できるのは、前段の出力が後段の入力にそのまま流れ込むタスクに限られます。前段の結果を見て後段の手順自体を変えたい場合、変数参照では表現できません。ここを無理に押し通すと、計画は通ったのに中身が噛み合わない実行結果が量産されます。

依存グラフを流しながら並列実行するLLMCompilerが効く問題の形

LLMCompiler（arXiv:2312.04511）はプランナーがタスクの依存グラフをストリーミングで出力し、依存が解けたものから順に並列実行します。ReAct比で遅延は最大3.7倍高速、費用は最大6.7倍削減、精度も最大で約9%改善したと報告されています。ただしこの数値が出るのは、独立に実行できるステップが同時に何本も立つ問題に限られる。

逆に言えば、5ステップすべてが前段依存の直列タスクにDAGを持ち込んでも、並列度は1のままで実装の複雑さだけが増えます。並列度が2以上になるステップが計画中に常時現れるか。この一点で判断してかまいません。

計画の表現形式とスキーマ設計で決まる実行時の安定度と検証性の両立

どの方式を選んでも、計画をどのデータ型で持つかは別途決めます。ここを自然言語のまま放置した実装が、最も高い確率で本番に落ちます。

自然言語リストと構造化データの2表現で変わる実行前の検証コスト

自然言語の箇条書きで計画を持つと、実装は数行で済みます。代償は検証不能です。「ステップ3で顧客マスタを更新する」と書かれた文字列から、実行前に危険操作の有無を機械判定することはできません。

構造化データに寄せるなら、最低限これだけは持たせます。ステップID、呼ぶツール名、引数、依存するステップIDの配列、期待する出力の型。この5フィールドがあれば、実行前に「存在しないツールを呼ぶ計画」「循環依存を含む計画」「許可外ツールを含む計画」を機械的に落とせます。計画そのものをJSON Schemaで検証する層を1枚挟むだけで、実行時エラーの相当数が着手前に消える。Plan-and-Solve Prompting（arXiv:2305.04091）がZero-shot-CoTの誤りを計算誤り7%・ステップ欠落12%・意味誤解27%に分類したように、計画段階の欠落は下流で必ず表面化します。

計画を毎回コンテキストへ載せる方式と外部状態へ置く方式の分岐点

計画を毎ターンのプロンプトに全文同梱すると、ステップ数に比例して入力トークンが膨らみます。20ステップの計画を20回投げれば、計画本文だけで20倍のトークンを払う計算です。

外部状態に置き、実行時は当該ステップと直近の結果だけを渡す設計にすれば、この膨張は止まります。分岐点は素朴で、ステップ数が概ね5を超えるか、1ステップあたりの出力が長いか。どちらかに当てはまれば外部状態へ寄せる価値があります。あわせて、完了済みステップの結果をどこまで残すかも決めます。全部残すと結局コンテキストが膨らむため、後段が参照するIDの結果だけを保持する方式が扱いやすい。

再計画を起動するトリガー設計と暴走を止める三重の打ち切り条件

計画は必ず外れます。外れたときに何をするかを決めていない実装は、同じステップを繰り返して費用だけを消費します。

再計画を起動する5つのトリガーと起動しない例外条件の明示方法

再計画を回す条件は、あらかじめ列挙して実装側に持たせます。モデルに「必要なら計画を見直して」と伝えるだけでは、見直す基準が毎回ぶれます。

1. ステップの実行が失敗し、リトライ上限に達した
2. 実行は成功したが、期待する出力の型やスキーマに適合しなかった
3. 実行結果が、後続ステップの前提を否定する内容だった
4. 利用者からの追加入力で、ゴール自体が変わった
5. ステップあたりの所要時間または費用が、設定した上限を超えた

同じくらい大事なのが、起動しない条件を書くことです。一時的なネットワークエラー、レート制限、単発のタイムアウトは再計画ではなくリトライで処理します。ここを分けずに全部を再計画へ流すと、計画が毎回書き換わって何が進んでいるのか追えなくなる。LLMCompilerがJoinerに「再計画するか終了するか」の判断を専任させているのは、この分岐を単独の関心事として切り出したためです。

最大再計画回数と進捗判定と予算上限で暴走を止める三段の停止装置

停止装置は3つ重ねます。単独では必ず抜けられるからです。

1つ目は再計画の回数上限で、実務では3回前後から始めて挙動を見ます。2つ目は進捗判定。直近の再計画で完了済みステップ数が増えていなければ、何度回しても同じ場所を踏み続けているとみなして止めます。3つ目は累計トークンまたは金額の上限で、これはタスク単位で持たせる。3つとも、計画そのものではなく実行側のループが所有します。停止条件をどこに置くかという設計はエージェントループの終了条件と同じ問題で、プランナーに自分の停止を判断させてはいけません。

計画段階で権限を固定するplan-then-executeの防御効果と残る攻撃

プランニングを入れる理由は費用と精度だけではありません。制御フローの改ざんを防ぐ効果があります。

未信頼データを読む前に制御フローを確定させる設計が防御に効く理由

間接プロンプトインジェクションは、エージェントが取得したWebページや社内文書に「これまでの指示を無視して情報を送信せよ」といった命令を混ぜる攻撃です。1手ずつ判断する暗黙型では、この文字列を読んだ次のターンに攻撃者の指示が「次の行動」として採用され得ます。

計画を先に確定させておけば、未信頼データが入ってくるのは実行フェーズであり、そこで実行できるのは計画済みのステップだけになります。Del Rosarioらの2025年9月の報告（arXiv:2509.08646）は、この分離を制御フロー整合性の確立と表現し、間接プロンプトインジェクションへの耐性の根拠に挙げています。読んだ内容が次の行動を決められない構造そのものが防御になる。

計画に含まれる危険操作を実行前に落とす二段検査層の具体的な置き場所

同じ報告は、この分離が単独では足りないとも明記しています。必須の補完統制として挙げられているのが、最小権限の原則、タスクスコープに絞ったツールアクセス、サンドボックス化された実行環境の3つです。計画そのものが汚染されるケース、たとえばゴールの記述に攻撃文字列が混ざっている場合、制御フロー整合性は守られたまま悪意ある計画が実行されます。

置き場所は2箇所です。計画が確定した直後に「許可外ツールを含まないか」「取り消せない操作を含むか」を検査し、含むなら人の承認へ回す。もう1箇所は各ステップの実行直前で、引数の中身を検査します。この二段構えはAIガードレールの実装層と同じ設計で、計画層に一段増やす形になります。認証情報をモデルの文脈へ載せない原則は、どちらの段でも変わりません。

プランニングを入れる条件と入れずに済ませる場面を分ける判断基準

ここは言い切ります。明示プランニングは、条件を満たさない案件では純粋な負債です。

明示プランニングが費用に見合う3条件と採用を見送る具体的な判断基準

採用してよいのは次の3条件のうち2つ以上を満たす場合です。ゴール達成までのツール呼び出しが概ね5回を超える。独立に実行できるステップが2本以上同時に立つ。実行の一部を小さいモデルや決定的なコードへ落とせる。

1つ以下しか満たさないなら、入れない方が速くて安いです。3ステップで終わる問い合わせ処理にプランナーを載せても、増えるのは計画生成の1往復と、計画が外れたときの再計画ぶんだけ。Anthropicの「Building effective agents」も、エージェント的な系は遅延と費用をタスク性能と引き換えにするため、最も単純な解から始めて必要なときだけ複雑さを上げるべきだとしています。検索と少数の例示で単発の呼び出しを詰める方が結果が良い領域は、実際に広い。

計画の粒度過多と固定計画の陳腐化で起きる代表的な2つの失敗パターン

本番で見る失敗は2型に集中します。ひとつは粒度過多で、1ステップが「変数に代入する」レベルまで細かく分解された計画です。ステップ数が20を超えたあたりから、どこで失敗したかの特定より計画の読解に時間がかかるようになります。目安として、1ステップは1回のツール呼び出しか1回の判断に対応させ、それ以上細かくしない。

もうひとつは固定計画の陳腐化です。分解優先型で書いた計画を最後まで守らせる実装にすると、3ステップ目で前提が崩れても残り7ステップを律義に実行します。再計画のトリガーを実装しない分解優先型は採用しない、と決めてよい。どちらの失敗も、計画の妥当性を測る指標がないと発見が遅れます。

PoCから本番へ持ち上げる際に運用要件へ必ず含めるべき5項目

PoCで動く計画立案を業務システムへ載せる段では、デモでは省かれる項目が要件になります。再計画の回数上限と予算上限、計画の検証スキーマ、危険操作の承認フロー、計画と実行の監査ログ、そして計画の妥当性を測る指標。ここまで含めて初めて、運用に耐える形になります。

どの業務にエージェントを載せるかという上流の判断はAIエージェントの導入判断にまとめています。要件定義から権限設計・監査までを含めて外部に任せる場合は、AIエージェント開発で相談を受け付けています。

よくある質問

プランニングの実装で実際に問われることの多い5点に答えます。

AIエージェントのプランニングとReActの違いは何ですか？

計画が状態として残るかどうかが違いです。ReActは思考と行動を交互に出しながら1手ずつ進むため、計画はコンテキスト内にしか存在せず、実行途中に「残りの手順」を構造として取り出せません。明示プランニングは着手前にステップ列を構造化データとして確定させるので、実行前の検証、途中の差し替え、監査ログへの記録ができます。ReActが計画していないわけではなく、計画を外に出さない設計だと理解すると整理しやすくなります。

計画は自然言語とJSONのどちらで持つべきですか？

本番運用に載せるなら構造化データを選びます。ステップID、ツール名、引数、依存ステップID、期待する出力型の5フィールドを持たせておくと、存在しないツールの呼び出し、循環依存、許可外ツールの混入を実行前に機械判定できます。自然言語の箇条書きは実装が数行で済む反面、危険操作の有無を検査できません。プロトタイプ段階だけ自然言語で始め、本番化の要件定義で構造化へ寄せる進め方が現実的です。

再計画は何回まで許容すればよいですか？

回数だけで制御する設計では不十分です。実務では上限3回前後から始めるものの、それ単独ではループを止めきれません。完了済みステップ数が前回の再計画から増えていなければ止める進捗判定と、タスク単位の累計トークンまたは金額の上限を重ね、三段で停止させます。加えて、一時的なネットワークエラーやレート制限は再計画ではなくリトライで処理し、再計画のトリガーから外しておきます。

プランニングを入れるとコストは上がりますか？

短いタスクでは上がり、長いタスクでは下がります。計画生成の往復が1回増えるため、3ステップで終わる処理では純増です。一方でステップ数が増えると、1手ごとに全履歴を読み直す方式のほうが費用は膨らみます。ReWOOの論文はトークン効率5倍とHotpotQAでの精度4%改善を、LLMCompilerの論文はReAct比で費用最大6.7倍削減を報告しています。分岐点はツール呼び出し5回前後です。

外部プランナーやPDDLはどんな案件で使いますか？

状態と操作を形式的に書き下せて、解の質を保証したい案件に限られます。LLM+P（arXiv:2304.11477）は自然言語の問題をPDDLへ変換し、古典プランナーで解いてから自然言語へ戻す構成です。配送順序や設備の段取りのように、制約と評価関数が明確な領域では有力になります。逆に調査や文書作成のようにゴールを形式化しにくい業務では、変換の手間に見合いません。多くの受託案件はこちら側で、Plan-and-Executeで足ります。

関連記事

• マルチエージェントオーケストレーションとは：計画したサブタスクを複数のエージェントへ委譲する場合の分割と統合の設計を扱います。
• AIエージェント評価とは：計画の妥当性やツール呼び出しの軌跡をどの指標で測るかをまとめています。
• エージェントメモリとは：計画と完了済み結果をどこに保持するかという短期・長期記憶の設計を解説しています。
• AIエージェントフレームワークとは：プランナーを自前で組むか既製フレームワークに載せるかの選定基準を比較しています。
• Agent SOPとは：モデルに計画させず人が定めた標準作業手順で制御する対極のアプローチです。