導入部
「またエージェントが同じ検索を繰り返している……」
自律型AIエージェントの開発現場において、このような状況は珍しくありません。特定のタスクを与えられたLLM（大規模言語モデル）が思考のループに陥り、APIコールを無駄に消費し続けた挙句、最終的にエラーで停止する。あるいは、コンテキストウィンドウ（入力可能なトークン数）の上限に達し、当初の目的を忘却してしまう現象です。
これらは、これまで広く用いられてきた「ReAct（Reasoning + Acting）」パターンの限界を示唆しています。推論と行動を逐次的に繰り返すこのループ構造は、複雑なタスクにおいて破綻しやすく、技術的な課題であると同時に、AIシステムが予期せぬ挙動をとるという意味で、AI倫理やガバナンスの観点からも看過できない「制御不能性」の問題と言えます。
本記事では、システム導入支援や業務プロセス改善の現場で直面するこれらの課題に対し、「Plan-and-Execute（計画と実行）」というアーキテクチャへの移行がいかにして解決策となり得るのか、その構造と設計思想について論じます。ReActパターンのような単一のループ構造に過度に依存するのではなく、タスクの計画フェーズと実行フェーズを明確に分離することで、AIの意思決定プロセスの透明性を大幅に向上させることが可能です。
単に「LangChainでどう書くか」というコードの解説にとどまらず、なぜ計画と実行を分離することがシステムの堅牢性（Robustness）を高め、ビジネス上の成果につながるのかを解説します。さらに、LangGraphを用いた実装がいかにしてAIの「説明責任」を果たしやすくするのかにも焦点を当てます。
LangGraphの現行のアーキテクチャでは、Checkpoints APIなどを活用した状態の永続化機能も進化の傾向にあり、エージェントの思考プロセスや実行履歴をより確実かつ追跡可能な形で管理・制御できるようになっています。具体的な機能の仕様や実装手順は頻繁にアップデートされるため、開発の際は常にLangGraphの公式ドキュメントで最新情報をご確認ください。
現場の課題をロジックで分解し、倫理的リスクを軽減することで、社会的に信頼できる自律型エージェント構築への道筋を提示します。
なぜReActだけでは不十分なのか：自律型エージェントの「迷子」問題
自律型エージェントの初期実装として広く採用されてきたReActパターンは、LLMに「思考（Thought）」と「行動（Action）」、そして「観察（Observation）」を交互に行わせる手法です。これは人間の思考プロセスを模倣した画期的なアプローチでしたが、複雑な業務プロセスに適用した際、いくつかの構造的な欠陥を露呈します。特にAIシステムの透明性や予測可能性を担保する観点から分析すると、単一のループ構造に依存するReActパターンの限界が明確になります。
ReActパターンの構造的限界とトークン消費
ReActの最大の特徴は、すべてのステップを単一のコンテキストストリームの中で処理しようとする点にあります。エージェントは過去の思考と行動履歴をすべてプロンプトに含めた状態で、次のアクションを決定します。これは短期的な記憶保持には有効ですが、ステップ数が増えるにつれて致命的な問題を引き起こします。
それは、コンテキストウィンドウの圧迫です。検索結果やツール実行のログが蓄積されるほど、LLMに入力される情報量は肥大化します。情報量が増えれば増えるほど、LLMは「重要な情報」と「ノイズ」の選別に苦慮することになります。これは認知負荷が高まった人間がミスをしやすくなるのと同様の現象であり、システムの挙動が不安定になるリスクを孕んでいます。状態の永続化や適切なチェックポイント機構を持たない単純なReActループでは、この情報過多による破綻を防ぐことが困難です。
複雑なタスクにおける推論精度の低下
さらに深刻なのが「推論能力の劣化」です。ReActエージェントは、常に「次の1手」を考えることに集中します。これは近視眼的なアプローチになりがちで、タスク全体を俯瞰する視点を欠きやすいという特性を持っています。
例えば、「複数のデータソースを比較分析し、総合的な予測レポートを作成する」というタスクを想定します。ReActエージェントは、最初のデータを検索している最中にエラーが発生したり、予期せぬ情報が見つかったりすると、その対応に追われるあまり、本来の「総合的な比較」「レポート作成」という最終ゴールを見失う傾向があります。いわゆる「迷子」の状態です。自律型AIが目的から逸脱するこの現象は、システムに対する信頼性を大きく損なう要因となります。
Plan-and-Executeが解決する「視野」の問題
ここで求められるのが、メタ認知的な視点です。つまり、「作業を実行する機能」とは別に、「作業計画を立て、進捗を管理する機能」を持たせることです。Plan-and-Executeアーキテクチャは、まさにこの役割分担をシステム的に実装したアプローチです。
計画（Planning）と実行（Execution）を明確に分離することで、実行担当のエージェントは目の前の作業に集中でき、計画担当のエージェントは全体最適を維持できます。この分離こそが、複雑なタスクを完遂させるための鍵となります。倫理的な観点からも、AIの思考プロセスが「計画書」として事前に明文化され、各ステップの実行状態が適切に管理されることは、システムの透明性と説明責任を高める上で極めて重要です。LangGraphのようなフレームワークを活用し、条件分岐や状態の永続化を伴う堅牢なワークフローを構築することが、自律型エージェントの暴走を防ぐ有効な手段となります。
Plan-and-Executeエージェントの基本アーキテクチャと動作原理
では、Plan-and-Executeエージェントは具体的にどのような構造で動作しているのでしょうか。LangChainのエコシステム、特にLangGraphを用いた実装モデルをベースに、そのメカニズムを客観的かつ論理的に解剖します。
Planner（計画者）とExecutor（実行者）の役割分担
このアーキテクチャの中核は、Planner（計画者）とExecutor（実行者）という2つの異なる機能モジュールの連携にあります。
- Planner: ユーザーからの曖昧な指示を受け取り、それを具体的かつ論理的なステップに分解します。ここではLLMの高い推論能力が最大限に活用されます。Plannerはツールを直接使用しません。あくまで「何をすべきか」のリスト（Plan）を作成することに特化します。
- Executor: Plannerが作成したステップを一つずつ実行します。ここでは単一のタスク解決に向けた動きをしますが、そのスコープは「個別のステップ」に限定されます。ゴールが明確で小さいため、エージェントが迷走するリスクが大幅に低減されます。
この分業体制は、組織における「マネージャー」と「現場担当者」の関係に似ています。マネージャーが現場の作業に忙殺されればプロジェクトは漂流しますが、役割を明確に切り分けることで、システム全体として高いパフォーマンスと安全性を維持できるのです。
Replannerによる動的な軌道修正メカニズム
現実の環境では、初期の計画通りに物事が進むことは稀です。Webサイトがダウンしているかもしれませんし、APIの検索結果が予想と異なる場合もあります。ここで重要な役割を担うのがReplanner（再計画者）です。
Executorがあるステップを完了（または失敗）すると、その結果はReplannerにフィードバックされます。Replannerは以下の3点を客観的に評価します。
- 現在の計画において、残りのステップは何か？
- 直前の実行結果はどのようなものであったか？
- 当初のゴールに対して、現状はどの程度近づいているか？
この評価に基づき、Replannerは残りの計画を動的に更新します。不要になったステップを削除したり、新たな情報を補完するためのステップを追加したりします。この継続的なフィードバックループにより、エージェントは予期せぬ状況変化に対しても柔軟（Resilient）に対応し、論理的な破綻を防ぐことが可能になります。
ステート管理と情報の受け渡しフロー
システム的な観点で見ると、このアーキテクチャは高度なステート（状態）管理を必要とします。「現在の計画リスト」「完了したステップの成果物」「最終的な回答のドラフト」といった情報を、各コンポーネント間で正確に受け渡す必要があります。
従来の単一エージェントモデルでは、これらがすべて一つのプロンプト履歴（Message History）に詰め込まれていました。一方、Plan-and-ExecuteやLangGraphを用いたアプローチでは、これらをグラフ構造上の構造化されたデータとして管理します。
さらに最新の動向として、LangGraphのチェックポイント機能（Checkpointer API）を活用したステートの永続化が重要視されています。たとえば、外部のデータベース（Amazon DynamoDBなど）と連携してエージェントの実行状態を保存することで、プロセスの途中で処理を一時停止し、人間の承認を経てから再開するといった高度な制御（Human-in-the-loop）が容易になります。これにより、LLMが処理すべきコンテキスト量が最適化されるだけでなく、トークンコストの削減、精度の向上、そして予期せぬエラーに対する耐障害性（フォールトトレランス）が同時に達成されるのです。
検証データで見る：ReAct vs Plan-and-Executeの実力比較
理論的な優位性は理解できても、実際の開発現場で採用するか否かの判断には、客観的で具体的な根拠が必要です。ここでは、一般的なベンチマークや実際のユースケースに基づいた比較検証の結果について、AI倫理や信頼性の観点も交えながら考察します。
マルチステップタスクにおける成功率の違い
単純な質問応答（例：「富士山の高さは？」）では、ReActとPlan-and-Executeに大きな差はありません。むしろ、計画を立てるオーバーヘッドがある分、Plan-and-Executeの方が応答速度は遅くなります。
しかし、タスクの複雑度が増すと状況は逆転します。例えば「最新のAI規制法案をEU、米国、日本について調査し、共通点と相違点をまとめた表を作成せよ」といったマルチホップな質問（複数の情報源を辿る必要がある質問）において、Plan-and-ExecuteはReActと比較して高いタスク完遂率を示す傾向にあります。
検証データによれば、ステップ数が5を超えるタスクにおいて、ReActエージェントの成功率が60%前後まで低下するのに対し、Plan-and-Executeエージェントは85%以上の成功率を維持したという報告もあります。これは、ReActが途中で「比較する」という最終目的を見失い、単なる「調査」で終わってしまうケースが多いためです。計画フェーズを分離することで、目的へのアラインメントが保たれやすくなります。
トークン消費量とAPIコストの比較分析
コスト面での比較も興味深い結果を示します。一見すると、PlannerとReplannerを何度も呼び出すPlan-and-Executeの方がコスト高に見えます。
しかし、ReActエージェントが「迷走」して無駄なツール呼び出しを繰り返したり、コンテキストの溢れによるエラーで再実行を余儀なくされたりするケースを含めると、トータルコストではPlan-and-Executeの方が安価になる場合が多いと考えられます。
特にAPIのコスト計算においては、利用するモデルの選定が大きく影響します。OpenAIの公式情報によると、GPT-4oやGPT-4.1といった旧モデルは利用率の低下に伴い廃止され、より長い文脈理解や高度なツール実行能力を備えたGPT-5.2（InstantおよびThinking）などの新世代モデルが主力へと移行しています。このように、高度な推論能力を持つが高価なAPIモデルを使用する場合、無駄な試行錯誤を減らすアーキテクチャの採用は、直接的なコスト削減につながります。さらに、最新モデルの向上した推論能力とPlan-and-Executeの計画性を組み合わせることで、より効率的なトークン消費が可能になります。
エラー発生時の復旧能力（レジリエンス）の差
特に注目したいのは「エラーからの復旧能力」です。ReActエージェントがツール実行エラーに遭遇した場合、パニック（ハルシネーションや無限リトライ）を起こしやすい傾向があります。
対してPlan-and-Executeでは、エラーが発生してもReplannerが「この方法は失敗したから、別のルートで情報を探そう」と冷静に計画を書き換えることが可能です。この「失敗を前提とした設計」は、単なるシステム的な堅牢性にとどまりません。予期せぬ挙動による被害を防ぎ、ユーザーに対して透明で信頼性の高いAIシステムを構築する上で不可欠な要素であり、AI倫理の観点からも強く推奨されるアプローチと言えます。
実装ベストプラクティス①：堅牢なPlannerのプロンプト設計
Plan-and-Executeアーキテクチャの成否は、最初の計画を立てるPlannerの品質に大きく依存します。優秀なPlannerを実装するためのプロンプトエンジニアリングについて、技術的な知見を共有します。
抽象度を調整して「実行可能な」計画を出力させる
Plannerへの指示で最も重要なのは、「粒度（Granularity）」の制御です。計画が抽象的すぎると（例：「情報を集める」）、Executorは何をしていいかわからず混乱します。逆に細かすぎると（例：「Googleを開く」「検索窓に入力する」）、柔軟性が失われます。
プロンプトには、「各ステップは単一の明確なツール呼び出しに対応するように分解せよ」という制約を含めるべきです。また、使用可能なツールの一覧とその説明をPlannerに提供し、「これらのツールで実行可能なレベル」までタスクを分解させるよう誘導することが肝要です。
依存関係を考慮したタスク分解のテクニック
複雑なタスクには依存関係が存在します。「Bを実行するにはAの結果が必要」というケースです。LLMは時として並列処理可能なタスクと、順次処理必須なタスクを混同します。
これを防ぐためには、プロンプト内で「依存関係の明示」を求めると効果的です。例えば、出力フォーマットに dependencies というフィールドを設け、そのステップがどの前のステップに依存しているかを記述させます。これにより、論理的に破綻した計画が生成されるリスクを低減できます。
出力フォーマットの厳格化（Pydantic/Structured Output）
Plannerの出力は、プログラムでパース（解析）可能な形式である必要があります。自然言語で「まずは〜して、次に〜します」と返されても、システムはそれをステップとして認識できません。
AIの制御性を高めるためには、LangChainの PydanticOutputParser や、OpenAI等のモデルが提供する Structured Outputs 機能を活用し、厳格なJSONスキーマに従った出力を強制することが必須です。かつてのJSON Modeと比較して、Structured Outputsはスキーマへの準拠が保証されており、パースエラーによるシステム停止のリスクを最小限に抑えることが可能です。
以下のようなスキーマ定義が推奨されます。
{
"plan": [
{
"step_id": 1,
"description": "EUのAI法案の概要を検索する",
"tool": "web_search",
"dependencies": []
},
{
"step_id": 2,
"description": "検索結果から主要な規制項目を抽出する",
"tool": "text_summarizer",
"dependencies": [1]
}
]
}
このように構造化することで、システムは計画を確実に実行キューに乗せることができます。これはAIの挙動を「予測可能」にし、意図しない動作を防ぐための第一歩となります。
実装ベストプラクティス②：LangGraphを用いたState管理と制御
LangChainのエコシステムにおいて、自律型エージェントの構築手法は大きく進化しています。かつて実験的な実装として提供されていた PlanAndExecute チェーンは、複雑なタスクにおける制御の難しさが課題でした。現在、より堅牢で透明性の高い実装を行うために推奨されるのが LangGraph です。
LangGraphは、エージェントの動作をグラフ（ノードとエッジ）として定義し、循環的なフローや条件分岐を明示的に記述できるライブラリです。倫理的な観点からも、AIの挙動をブラックボックス化させないための重要な技術基盤と言えます。
AgentExecutorからLangGraphへの移行メリット
従来の AgentExecutor は、内部のループ処理が隠蔽されており、開発者が詳細に介入できる余地が限られていました。「特定の回数ループしたら強制終了する」「特定のステップでエラーが出たら人間に通知する」といったカスタムロジックの実装は、しばしば困難を伴いました。
LangGraphを使用すると、Planner（計画）、Executor（実行）、Replanner（再計画）をそれぞれ独立した「ノード」として定義し、それらの間の遷移（エッジ）を自由に設計できます。これは、システムの状態遷移を開発者が完全に掌握できることを意味し、AIシステムの信頼性を高める上で不可欠な要素です。
グラフ構造による動的ループの制御
Plan-and-ExecuteモデルをLangGraphで実装する場合、典型的なフローは以下のように構造化されます。
- Start Node: ユーザー入力を受け取り、状態（State）を初期化する
- Planner Node: 目標達成のための初期計画を作成する
- Executor Node: 計画されたタスクのステップを実行する
- Replanner Node: 実行結果を評価し、必要に応じて計画を更新する
- Conditional Edge:
- タスク完了と判定された場合 → End Node
- 未完了または新たな課題が発生した場合 → Executor NodeまたはPlanner Nodeへ戻る
この循環構造（Cyclic Graph）により、タスクが完了するまで柔軟にループを回すことが可能です。同時に、グラフ全体の状態（State）として「過去の全ステップの結果」や「思考の履歴」を保持できるため、文脈の喪失を防ぎ、一貫性のある推論を維持できます。
Human-in-the-Loop（人間による確認）の組み込み
実務の現場において特に重視されるのが、Human-in-the-Loop（HITL） の実装です。LangGraphはこの機能をアーキテクチャレベルでサポートしており、自律型エージェントに適切な「ブレーキ」を組み込むことができます。
例えば、Plannerが「外部データベースへの書き込み」を含む計画を立てた場合や、Executorが「メール送信」などの不可逆なアクションを実行しようとする直前に、グラフの遷移を一時停止（Interrupt）し、人間の承認を求めるフローを設計できます。
チェックポイント機能（Checkpointer）を活用することで、システムの状態を保存し、人間が内容を確認・修正した後に処理を再開するといった運用も可能です。これは、AIの暴走リスクを管理し、社会的責任を果たすシステムを構築するために極めて有効な手段です。
※LangGraphの機能やAPI仕様は頻繁に更新されています。チェックポイント機能やステート管理の最新の実装方法については、必ず公式ドキュメントで現行バージョンの仕様をご確認ください。
アンチパターン：Plan-and-Executeが機能しないケース
万能なアーキテクチャは存在しません。Plan-and-Executeも例外ではなく、不適切な適用はシステムのパフォーマンスを低下させ、予期せぬ動作を引き起こす要因となります。システムの透明性と制御可能性を維持する観点から、避けるべきアンチパターンを分析します。
単純なタスクでのオーバーエンジニアリング
「今日の天気を教えて」「この文章を要約して」といった、シングルステップで完了するタスクにPlan-and-Executeを適用するのは、明らかなオーバーエンジニアリングと言えます。
計画策定と再計画のプロセスが挟まるため、応答までのレイテンシ（待ち時間）が増加するリスクがあります。これはユーザー体験を損なうだけでなく、無駄なトークン消費によるコスト増大も招きます。タスクの複雑性に応じて、より軽量なReAct手法や単一の言語モデル呼び出しと、Plan-and-Executeを動的に使い分けるルーティング機構を設けることが、効率的なシステム設計の要です。
Plannerの幻覚による「存在しないツール」の使用計画
言語モデルの推論能力が高いゆえに生じる問題として、提供されていないツールまで「使えるはずだ」と推測し、計画に組み込んでしまう現象があります。「社内データベースを検索する」というステップを生成したものの、実際にはそのアクセス権限やツールがExecutorに渡されていないというケースです。
このような自律的な判断の逸脱を防ぐには、Plannerのシステムプロンプトに「使用可能なツールリスト」を厳密に定義する必要があります。「リストに明記されていないツールは絶対に使用しない」という制約を強く課すことで、エージェントの行動範囲を安全な領域に限定できます。
コンテキスト情報の断絶による実行エラー
Executorが各ステップを順次実行する際、前のステップの処理結果が正しく渡されていないと、後続のステップで致命的なエラーが発生します。例えば、ステップ1で特定したURLを、ステップ2のデータ抽出ツールが受け取れないといった状況です。
これはシステムの状態（ステート）管理における設計上の不備です。LangGraphのStateスキーマにおいて、各ステップの出力がどのように蓄積され、次のステップの入力としてどのように参照されるかを明確に定義しなければなりません。また、より堅牢な状態管理を実現するためには、単にログを追記するだけでなく、公式ドキュメントでも言及されているcheckpoints APIやデータベース（DynamoDBなど）を活用した永続化の仕組みを組み込み、確実な変数の受け渡し環境を構築することが推奨されます。
導入と成熟度評価：自社エージェントを進化させるステップ
最後に、ReAct型エージェントからPlan-and-Execute型へと移行し、さらにその品質と倫理的妥当性を高めていくためのロードマップを提示します。自律性の高いシステムを現場に導入する際は、導入して終わりではなく、実際に現場で運用され、ビジネス上の成果が出るシステム構築を重視する段階的なアプローチが不可欠です。
プロトタイプから本番運用への移行チェックリスト
導入にあたっては、いきなり完全な自律エージェントを目指すのではなく、リスクをコントロールしながら段階的に権限を委譲するプロセスを推奨します。
- フェーズ1（検証）: 特定の複雑なタスクに対し、手動で計画を与えてExecutorの動作を確認する。
- フェーズ2（半自律とHuman-in-the-Loop）: Plannerを導入しますが、計画の実行前や重要な分岐点で人間が確認・修正を行います。最新のLangGraphでは、checkpoints APIを利用した状態の永続化（Amazon DynamoDBなどのデータベースとの統合）が進化しており、処理を安全に一時停止し、人間の承認を経てから再開するワークフローを堅牢に構築できます。
- フェーズ3（自律化）: 過去の実行ログから安全性が証明され、信頼性の高いタスク領域に限定して、フルオートメーション化する。
このプロセスを経ることで、どの段階でハルシネーションが起きやすいか、どのツールの精度や倫理的判断が甘いかを正確に特定できます。
タスク複雑度に応じたアーキテクチャ選定基準
すべてのエージェントを最初から重厚なPlan-and-Executeにする必要はありません。入力されたプロンプトの複雑さや要求される安全性を判定し、アーキテクチャを動的に切り替える「ルーター（Router）」の実装が効果的です。LangGraphの条件付きエッジ（Conditional Edges）を用いれば、以下のような柔軟なルーティングを設計できます。
- 低複雑度・低リスク: 直接回答（Direct LLM）
- 中複雑度: ReAct Agent
- 高複雑度・高リスク: Plan-and-Execute Agent
この判断基準を設けることで、計算コストの最適化だけでなく、過剰な自律性による予期せぬ動作（暴走）のリスクを最小限に抑えることが可能です。
継続的な評価と改善のループ
エージェントの運用開始はゴールではなく、継続的な監視と調整のスタートです。ログデータを分析し、Plannerがどのような計画を立てたか、Replannerが何度修正を行ったかを常にモニタリングしてください。
データベースに永続化された実行履歴（チェックポイント）を活用することで、エージェントの「思考の軌跡」を詳細に追跡できます。もしReplannerによる修正回数が頻繁に発生しているなら、初期計画の精度（Plannerのプロンプト）に問題があるか、ツールの使い勝手が悪い可能性があります。倫理的かつ公平なAIシステムを維持するためには、これらのデータを客観的に分析し、システムの透明性を高め続ける姿勢が重要です。
まとめ
Plan-and-Executeアーキテクチャは、自律型エージェントに「メタ認知」を持たせ、複雑なタスクを確実かつ透明性高く実行させるための強力なフレームワークです。ReActの限界を超え、LangGraphによる緻密な状態管理と制御構造を加えることで、AIをより信頼できるパートナーへと進化させることができます。
しかし、技術はあくまで手段に過ぎません。最も重要なのは、AIにどの範囲の意思決定を委ね、人間がどのように監督・介入するかという設計思想そのものです。システムの自律性が高まるほど、その土台となる倫理的ガイドラインと制御メカニズムの重要性は増していきます。
本記事で解説したアプローチが、開発現場における「迷えるエージェント」を正しく導き、社会的に信頼されるAIシステムを構築するための実践的な指針となれば幸いです。AIの進化は速く、最新の公式ドキュメントや技術動向を常に確認しながら、ユーザーの使いやすさと機能性のバランスを最適化した堅牢なシステム設計を追求し続けることが確かな運用への鍵となります。
コメント