デバシシュ・ゴーサル(Debashish Ghosal)はAugust 22, 2026、PlannerCriticの実地テストで、gpt-4oを使っても消えないLLMの計画失敗が繰り返し見つかったと報告した。PlannerCriticは、1つのLLMが計画を書き、別のLLMがそれをレビューするオープンソースエンジンである。テストでは63件の厳格な目標に対して132件の具体的な阻害要因が出た。内訳は、未検証の依存関係が57件、安全でない順序が46件、弱いロールバックが18件だった。

未検証の依存関係は、計画が事前条件を宣言しながら、それを先行タスクで確立していない場合に起きた。`ai-03-model-serving-migration`の例では、SageMakerからvLLMへトラフィックを100%切り替えるタスクが前段の切り替え段階に依存していたが、計画は10%と50%の段階が安定したことを明確に確認しないまま先へ進んでいた。安全でない順序は、必須の前提条件より前にタスクが置かれる失敗だった。`ai-02-embedding-index-migration`では、品質確認で止めるべき`backfill_vectors`が、その確認より前に配置されていた。

弱いロールバックは、高リスクの手順に信頼できる巻き戻し経路がない失敗だった。`db-10-multi-tenant-split`では、`dual_write_setup`のロールバックが単一書き込みモードへ戻すだけで、移行中に入り込む可能性のある不整合に対処していなかった。ゴーサルは、プランナーが通常手順にはロールバックを入れる一方、切り替え、撤去、フェイルバックのタスクでは省略したり弱めたりしていたと述べた。

ゴーサルは、より大きなモデルを2つの構成で試した。1つはgpt-4oをプランナー、miniを批評役にする構成で、もう1つはプランナーと批評役の両方にgpt-4oを使う構成だった。結果は、文章表現は良くなったが、未検証の依存関係、安全でない順序、弱いロールバックという同じ欠陥パターンが残った。ゴーサルは、問題はモデルサイズではなく計画構造にあると結論づけた。プランナーはもっともらしい手順を知っていたが、依存関係グラフを安定して閉じたり、順序を強制したりできなかったからだ。

修正ループも問題を直せなかった。批評役が阻害要因を報告し、プランナーが修正しても、プランナーは1件を直す一方で別の阻害要因を入れたり、依存関係の穴を閉じないままタスク順を並べ替えたり、誤ったタスクにロールバックを追加したりした。33件の厳格な目標における中央値である2回の修正後、プランナーは意味のある変更を止め、収束検出器が作動し、エンジンはエスカレーションした。ゴーサルは、批評役が修正をまたいで同じ阻害要因を安定して見つけたため、プランナーの構造的な修復失敗はArticle 2で扱われた深刻度調整のバグとは異なると述べた。

ゴーサルは、事前条件クローザーを提案した。これは、プランナーの草案後に走り、すべての事前条件が先行タスクで確立されているかを検証する決定論的リンター（ルールベースの検査器）である。あるタスクが`replica_verified`を必要とするなら、前のタスクがそれを生成しなければならない。この1回の処理により、LLMを賢くすることなく、132件中64件、つまり48%の阻害要因を除去できるという。残る安全でない順序と弱いロールバックの阻害要因には、より良いプロンプト設計、追加の決定論的検証、または順序とリスクに関するより強い推論が必要だとした。

投稿は実地テストを計画研究と結びつけた。論文「Why Reasoning Fails to Plan」（arXiv 2601.22311）は、LLMエージェントが将来の結果を考えずに局所的評価で行動を選ぶことがあり、知識グラフ探索では単一ステップの貪欲方策が55%超の頻度で近視眼的な罠を選ぶと述べている。PlanGenLLMs調査（arXiv 2502.11221）は、LLMの計画を完全性、実行可能性、最適性、表現の4基準で評価する。ゴーサルは、実地テストと研究の両方が、LLMだけに頼るのではなく、LLM、決定論的検証、古典的計画法を組み合わせるハイブリッドシステムを示していると述べた。

デバシシュ・ゴーサル(Debashish Ghosal)はAugust 22, 2026、PlannerCriticの実地テストで、gpt-4oを使っても消えないLLMの計画失敗が繰り返し見つかったと報告した。PlannerCriticは、1つのLLMが計画を書き、別のLLMがそれをレビューするオープンソースエンジンである。テストでは63件の厳格な目標に対して132件の具体的な阻害要因が出た。内訳は、未検証の依存関係が57件、安全でない順序が46件、弱いロールバックが18件だった。

未検証の依存関係は、計画が事前条件を宣言しながら、それを先行タスクで確立していない場合に起きた。`ai-03-model-serving-migration`の例では、SageMakerからvLLMへトラフィックを100%切り替えるタスクが前段の切り替え段階に依存していたが、計画は10%と50%の段階が安定したことを明確に確認しないまま先へ進んでいた。安全でない順序は、必須の前提条件より前にタスクが置かれる失敗だった。`ai-02-embedding-index-migration`では、品質確認で止めるべき`backfill_vectors`が、その確認より前に配置されていた。

弱いロールバックは、高リスクの手順に信頼できる巻き戻し経路がない失敗だった。`db-10-multi-tenant-split`では、`dual_write_setup`のロールバックが単一書き込みモードへ戻すだけで、移行中に入り込む可能性のある不整合に対処していなかった。ゴーサルは、プランナーが通常手順にはロールバックを入れる一方、切り替え、撤去、フェイルバックのタスクでは省略したり弱めたりしていたと述べた。

ゴーサルは、より大きなモデルを2つの構成で試した。1つはgpt-4oをプランナー、miniを批評役にする構成で、もう1つはプランナーと批評役の両方にgpt-4oを使う構成だった。結果は、文章表現は良くなったが、未検証の依存関係、安全でない順序、弱いロールバックという同じ欠陥パターンが残った。ゴーサルは、問題はモデルサイズではなく計画構造にあると結論づけた。プランナーはもっともらしい手順を知っていたが、依存関係グラフを安定して閉じたり、順序を強制したりできなかったからだ。

修正ループも問題を直せなかった。批評役が阻害要因を報告し、プランナーが修正しても、プランナーは1件を直す一方で別の阻害要因を入れたり、依存関係の穴を閉じないままタスク順を並べ替えたり、誤ったタスクにロールバックを追加したりした。33件の厳格な目標における中央値である2回の修正後、プランナーは意味のある変更を止め、収束検出器が作動し、エンジンはエスカレーションした。ゴーサルは、批評役が修正をまたいで同じ阻害要因を安定して見つけたため、プランナーの構造的な修復失敗はArticle 2で扱われた深刻度調整のバグとは異なると述べた。

ゴーサルは、事前条件クローザーを提案した。これは、プランナーの草案後に走り、すべての事前条件が先行タスクで確立されているかを検証する決定論的リンター（ルールベースの検査器）である。あるタスクが`replica_verified`を必要とするなら、前のタスクがそれを生成しなければならない。この1回の処理により、LLMを賢くすることなく、132件中64件、つまり48%の阻害要因を除去できるという。残る安全でない順序と弱いロールバックの阻害要因には、より良いプロンプト設計、追加の決定論的検証、または順序とリスクに関するより強い推論が必要だとした。

投稿は実地テストを計画研究と結びつけた。論文「Why Reasoning Fails to Plan」（arXiv 2601.22311）は、LLMエージェントが将来の結果を考えずに局所的評価で行動を選ぶことがあり、知識グラフ探索では単一ステップの貪欲方策が55%超の頻度で近視眼的な罠を選ぶと述べている。PlanGenLLMs調査（arXiv 2502.11221）は、LLMの計画を完全性、実行可能性、最適性、表現の4基準で評価する。ゴーサルは、実地テストと研究の両方が、LLMだけに頼るのではなく、LLM、決定論的検証、古典的計画法を組み合わせるハイブリッドシステムを示していると述べた。