Agentic LLM Planning via Step-Wise PDDL Simulation: An Empirical Characterisation

この論文は、LLM が PDDL 環境でステップごとのシミュレーションを通じて計画を行う「アジェンティック」アプローチを評価し、古典的ソルバーには及ばないものの直接計画よりわずかに優れ、より短い計画を生成する一方で、外部検証がない自己評価型のフィードバックが性能向上の限界要因であることを示しています。

要約

この論文は、**「AI（特に大規模言語モデル）が、ロボットのような自律的なシステムで『計画』を立てるのに、本当に使えるのか？」**という疑問に答える実験レポートです。

特に、**「AI に一度に全部の計画を言わせる（直接生成）」方法と、「AI に一つずつ行動させて、その結果を見て修正させる（エージェント型）」**方法のどちらが優れているかを、ブロックを積み上げる「ブロックワールド」というゲームを使って比較しました。

以下に、専門用語を避け、身近な例えを使って解説します。

---

1. 実験の舞台：ブロックワールド

想像してください。机の上に積み木（ブロック）が散らばっています。「赤いブロックを青いブロックの上に置き、その上に黄色いブロックを乗せて」というような**「ゴール」**があります。
これを達成するために、どの順序でブロックを動かすかという「計画」を立てる必要があります。これがロボットの「タスク計画」です。

2. 4 つの「計画屋」たち

研究者たちは、この問題を解くために 4 つの異なるアプローチをテストしました。

1. 古典的な天才（Fast Downward）:

   • 特徴: 数学と論理で完璧に計算する「古典的な AI」。
   • イメージ: 迷路を解くのが得意な、計算機のような頭脳。一度に最短ルートを計算し、間違えることはほぼありません。
   • 結果: 85% の成功率。非常に安定しています。

2. AI 作家 A（直接生成）:

   • 特徴: 「全部の動きを最初から最後まで考えて答えを出して」と頼む方法。
   • イメージ: 試験で「答えを全部書きなさい」と言われ、一度で書こうとする生徒。間違えたら、最初からやり直し（リトライ）します。
   • 結果: 64% 程度。

3. AI 作家 B（エージェント型・今回の主役）:

   • 特徴: 「一つだけ動いて、結果を見て、次に何をするか考えて」という対話型の方法。
   • イメージ: 迷路を歩きながら、「あ、ここは壁だ、引き返そう」と自分で判断する探検家。
   • 仕組み: 論文で開発された「PyPDDLEngine」というツールを使い、AI が一つずつブロックを動かして、その都度「今、どこにいるか」を確認できます。
   • 結果: 67% 程度。

4. 古典的な天才（改良版）:

   • 最初の計画を何度も見直して、より短い道を探すタイプ。

3. 驚きの結果：何がわかった？

① 「対話型」は少しだけ上手くなったが、大差ない

「一つずつ確認しながら進める（エージェント型）」方が、最初から全部言う（直接生成）よりもわずかに（3% ほど）成功率が上がりました。
しかし、コストは 5.7 倍もかかりました。つまり、「少しだけ上手くなったけど、その分、ものすごいエネルギー（計算コスト）を消費した」という結果です。

② 意外な事実：AI は「暗記」しているだけかも？

古典的な AI は、難しい問題ほど「長い計画」を立てますが、今回の AI たちは、古典的な AI が「何度も見直して短くした」計画よりも、最初から「短い計画」を出していました。
これは、AI が「論理的に考えて最短ルートを見つけ出した」のではなく、**「過去のトレーニングデータ（教科書）に載っていた、似たような問題の答えを思い出した（暗記）」**可能性が高いことを示唆しています。

• 例え話: 数学のテストで、公式を自分で導き出したのではなく、過去問の答えを丸暗記していた生徒が、たまたま同じ問題が出たので正解したようなものです。

③ 最大の発見：「正解のヒント」がないと AI は迷子になる

ここがこの論文の最も重要なポイントです。

• プログラミングの AI（成功例）:
  プログラムを書かせて「エラーが出たよ」と外部のコンピューターが教えてくれます。これは「客観的な正解のヒント」です。AI は「あ、ここが間違ってた」と修正できます。
• 今回のブロック計画（失敗例）:
  AI がブロックを動かしても、「ブロックが動いたよ」という事実しか教えてくれません。「ゴールに近づいているか？」「間違っているか？」という**「進捗のヒント」は与えられません**。
  • 結果: AI は「自分自身で『今、間違ってるかも』と判断」しなければなりません。しかし、AI はその判断が下手です。
  • 現象: AI は「この問題は解けない」と勝手に判断して、まだ時間があるのに**「あきらめて立ち去る（早期終了）」**というミスを犯しました。実際は解ける問題だったのに、です。

4. 結論：ロボットに何を教えるべきか？

この研究は、**「AI に『一つずつ行動させて、結果を見る』という仕組みだけでは、ロボットはうまく計画できない」**と警告しています。

• 重要な教訓:
  AI が「今、成功しているか失敗しているか」を自分で判断するのは無理です。
  ロボットを本格的に動かすためには、AI に「ブロックが動いた」という事実だけでなく、「あなたはゴールに近づいているよ（または遠ざかっているよ）」という、外部からの明確なフィードバック（進捗報告）を与える仕組みが必要です。

まとめ

• AI は「暗記」が得意だが、「新しい道筋を論理的に探る」のは苦手なようです。
• 「一つずつ確認する」方法は、プログラミングのような「明確な正解・不正解がある世界」では強力ですが、ブロック積み上げのような「進捗が曖昧な世界」では、AI が迷子になりやすいことがわかりました。
• 今後のロボット開発では、AI 自身に「今どうなってるか」を判断させるのではなく、**「進捗を正しく伝えるセンサーやシステム」**をどう作るかが鍵になります。

この論文は、AI に「何でもできる万能な頭脳」を期待するのではなく、**「AI が正しく判断できる環境（フィードバック）」**をどう設計するかが重要だと教えてくれています。

技術概要

以下は、提示された論文「Agentic LLM Planning via Step-Wise PDDL Simulation: An Empirical Characterisation」の技術的な詳細な要約です。

1. 問題定義 (Problem)

自律型ロボットシステムの中核となる能力として「タスクプランニング（初期状態から目標状態に至るまでの行動シーケンスの生成）」があります。従来の記号論理に基づく古典的プランナー（例：Fast Downward）は効率的ですが、大規模言語モデル（LLM）がこれを代替または補完できるかは未解決の課題です。

既存の LLM プランニング研究の多くは、以下のいずれかのアプローチに依存しています。

• 直接生成: 一度に完全な計画を生成する（失敗時のフィードバックなし）。
• 翻訳者モデル: LLM が PDDL 記述を生成し、それを古典的ソルバーに渡す。

しかし、**LLM を「探索ポリシー（search policy）」として PDDL シミュレーション環境内に埋め込み、行動を 1 段階ずつ実行し、その結果（状態遷移）を観測して次の行動を決定する「エージェント的アプローチ」**が、計画の成功率や品質を向上させるかどうかは、体系的な検証がなされていませんでした。特に、コーディングエージェントがコンパイラエラーやテスト失敗といった「外部に根ざした（externally grounded）」フィードバックで劇的に改善するのに対し、PDDL ステップフィードバック（自己評価のみ）では同様の改善が得られるのかという点が不明瞭でした。

2. 手法と提案システム (Methodology)

PyPDDLEngine の開発

著者は、PDDL シミュレーションエンジンを実装し、その操作を LLM のツール呼び出しとして公開するオープンソースライブラリ**「PyPDDLEngine」**を提案しました。

• インターフェース: Model Context Protocol (MCP) を使用し、LLM が 7 つの操作をツールとして呼び出せるようにしています。
  1. セッションの初期化
  2. 現在の状態の照会
  3. 適用可能な行動の取得
  4. 単一行動の実行（状態遷移と結果の返却）
  5. 初期状態へのリセット
  6. 行動履歴の照会
  7. 完全な計画の検証
• 役割: LLM は計画の生成者ではなく、PDDL 状態空間を 1 行動ずつナビゲートする「探索ポリシー」として機能します。

実験設定

• データセット: 国際プランニングコンペティション（IPC）の「Blocksworld」ベンチマークから 102 件のインスタンス。
• 時間制約: すべての手法に 180 秒の均一な時間予算を適用。
• 比較対象 (4 つのアプローチ):
  1. Fast Downward (lama-first): 古典的ソルバー（貪欲法、最速解）。
  2. Fast Downward (seq-sat-lama-2011): 古典的ソルバー（反復改善による品質向上）。
  3. Direct LLM: Claude Haiku 4.5 に PDDL 記述を与え、一度に完全な計画を生成させる（失敗時は最初から再試行）。
  4. Agentic LLM: Claude Haiku 4.5 が PyPDDLEngine を使用し、ステップごとに行動を実行・観測・修正する。

3. 主要な貢献 (Key Contributions)

1. PyPDDLEngine の公開: LLM を PDDL 遷移システム内のインタラクティブな探索ポリシーとして位置づける、再現性のあるエージェント的プランニング研究のためのオープンソースインフラ。
2. 実証的な評価: 102 件のインスタンスにおける 4 つのアプローチの包括的な比較。
   • エージェント的アプローチのメリットの範囲、コスト、難易度依存性を定量化。
   • PDDL ステップフィードバックが「自己評価」に留まるため、コーディングエージェントのような劇的な改善が見られないという知見の提示。

4. 結果 (Results)

成功率と失敗モード

• Fast Downward: 85.3% の成功率（15 件のタイムアウト）。
• Direct LLM: 63.7% の成功率。
• Agentic LLM: 66.7% の成功率。
  • 結果: エージェント的アプローチは直接生成より3 ポイント高い成功率を示しましたが、古典的ソルバーには劣ります。
  • 失敗モード: エージェント的アプローチは、6 件で「早期終了（Early Exit）」を起こしました（モデルが「解なし」と誤判定し、予算切れ前に停止）。そのうち 4 件は直接 LLM が解いた問題であり、モデルの自己評価が不正確であることを示しています。

計画の品質（解けたインスタンスのみ比較）

• 4 つの手法すべてが解いた 49 件のインスタンス（co-solved set）において、両方の LLM アプローチは、反復改善を行う Fast Downward (seq-sat-lama-2011) よりも短い計画を生成しました。
• これは、LLM が品質改善メカニズムを持たないにもかかわらず、より良い解を出していることを意味します。
• 考察: この結果は、LLM が検索によって計画を立てているのではなく、トレーニングデータからの**「記憶（recall）」**に基づいて近似的な最適解を生成している可能性を示唆しています（行動名をリネームすると成功率が崩壊するという既存研究とも一致）。

コスト

• トークンコスト: エージェント的アプローチは、1 解あたりのトークンコストが直接アプローチの約5.7 倍（169,864 トークン vs 28,488 トークン）かかりました。
• 3 件の追加成功に対して、約 1440 万トークンの追加コストが発生しています。

難易度別分析

• 成功率の向上は中程度の難易度帯に集中しており、簡単な問題や非常に難しい問題（Fast Downward すらタイムアウトする 15 件）では、LLM の改善効果は限定的または見られませんでした。
• 最も難しい 15 件中、エージェント的アプローチのみが 3 件を解いた事例（インスタンス 101 など）がありましたが、これは外れ値の可能性も指摘されています。

5. 意義と結論 (Significance & Conclusion)

外部フィードバックの重要性

この研究の最も重要な結論は、**「エージェント的相互作用の価値は、環境フィードバックの性質に依存する」**という点です。

• コーディングエージェント: コンパイラエラーやテスト失敗といった「外部に根ざした（externally grounded）」客観的なフィードバックがあるため、自己修正が機能し、大幅な性能向上が見られます。
• PDDL プランニング: ステップごとのフィードバックは「その行動が適用可能だったか」のみであり、「目標への距離」や「進捗の良し悪し」を外部が示しません。進捗評価はモデルの自己判断に委ねられるため、誤った判断（早期終了など）を修正できず、改善効果が限定的になります。

ロボティクスへの示唆

自律ロボットにおいて LLM を意思決定層として用いる際、単に「世界知識」と「ステップごとの相互作用」があれば十分であるという仮説は否定されました。

• センサーや状態推定は、単に現在の状態を報告するだけでなく、「目標への進捗があるか」「失敗の兆候があるか」を LLM に伝える「外部に根ざしたシグナル」を生成する設計が不可欠です。
• LLM プランナーの性能上限は、モデルの知識量ではなく、システムが提供するフィードバックの豊かさと解釈可能性によって決まります。

総括

現在の LLM プランニングエージェントは、汎用的な推論を行う「計画者」というよりは、トレーニングデータで学習した既知の問題空間を適応的にナビゲートする「ナビゲーター」として機能している可能性が高いです。PDDL におけるステップごとの相互作用だけでは、古典的ソルバーを凌駕する信頼性のあるプランナーを実現するには不十分であり、より質の高い外部フィードバックの統合が今後の課題となります。