💬 NLP

Improved Generalized Planning with LLMs through Strategy Refinement and Reflection

この論文は、擬似コードの自動デバッグ、失敗原因の分析を含むリフレクション、および複数のプログラムバリエーションの生成と選択という 3 つの改良手法を導入することで、LLM を用いた一般化計画の品質を大幅に向上させ、平均 82% のカバレッジを達成したことを報告しています。

原著者： Katharina Stein, Nils Hodel, Daniel Fišer, Jörg Hoffmann, Michael Katz, Alexander Koller

公開日 2026-03-23

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Katharina Stein, Nils Hodel, Daniel Fišer, Jörg Hoffmann, Michael Katz, Alexander Koller

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

この論文は、**「AI（大規模言語モデル）に、複雑なパズルや物流のルールを一度教えるだけで、どんな大きさの問題でも解ける『万能な解決マニュアル』を作らせる」**という新しい方法を提案しています。

これまでの AI は、一つの問題（例えば「荷物を A から B に運ぶ」）に対して、その都度ゼロから考えさせられていました。しかし、この論文の手法は、**「その分野全体の『戦略（作戦）』をまず作り、それをプログラムとして実行させる」**というアプローチです。

これをより身近な例え話で説明しましょう。

🍳 料理のレシピを作る話

Imagine you want an AI to be a master chef.

昔のやり方（Silver 氏らのアプローチ）：
- AI に「今日の夕食を作ってください」と言います。
- AI は「まず卵を割って、フライパンで炒めて…」と、その瞬間瞬間で考えて料理を作ります。
- 問題点： 客が 10 人来たら、10 回も同じように考え直さなければなりません。また、AI が「卵を割る前にフライパンを熱すべき」という基本を間違えると、料理は台無しになります。
この論文の新しいやり方（戦略の洗練とリフレクション）：
- まず、AI に「卵料理の**『基本の戦略（レシピの骨子）』**を書いてください」と頼みます。
- ここが重要で、AI には**「擬似コード（プログラムに近い言葉でのメモ）」**で戦略を書かせます。
  - *例：「卵を割る→フライパンを熱する→卵を入れる」ではなく、「卵が冷たい場合は温める→フライパンが熱くなっているか確認する→熱くなければ加熱し続ける」のような、**条件分岐（もし〜なら）を含んだメモです。
- ステップ 1：戦略のチェック（デバッグ）
  - AI が書いたメモ（戦略）を、実際の小さな料理実習（デバッグ用タスク）に当てはめてテストします。
  - もし「卵を割る前にフライパンを冷たいままにしていた」というミスがあれば、AI に**「なぜそのミスが起きたのか？どこが間違っていたのか？」と「振り返り（リフレクション）」**をさせます。
  - AI は「あ、フライパンを温める手順を忘れていた！」と気づき、メモ（戦略）を修正します。
- ステップ 2：本番のプログラム作成
  - 戦略（メモ）が完璧になったら、それを本物の Python プログラム（料理の自動化ロボット）に変換します。
  - これも、一度で完璧なプログラムを作るのではなく、**「いくつかのバージョン（候補）」**を作らせて、一番うまく動くものを選びます。

🌟 なぜこれがすごいのか？（3 つの魔法）

この論文では、AI が失敗しないようにするための 3 つの工夫（魔法）が使われています。

魔法のメモ（擬似コード戦略）：
- AI にいきなり「プログラム書け」と言わず、「まずは日本語に近いメモで手順を考えろ」と言います。これにより、ロジックの大きなミス（「卵を割る前にフライパンを温める」という順序の逆転など）を、プログラムを書く前に見つけられます。
失敗からの学び（リフレクション）：
- AI が間違えたとき、「バグが出たよ」と言うだけでなく、**「なぜ間違えたのか？どの部分がダメだったのか？」**を AI 自身に考えさせます。
- これにより、AI は「あ、ここが抜けていたんだ！」と深く理解し、戦略を修正できます。まるで、料理が焦げた後で「火が強すぎたんだな」と反省して、次は火加減を調整する料理人のようです。
複数の候補からベストを選ぶ（多様な生成）：
- 一度の試行で全てを完璧にしようとするのではなく、AI に「同じ戦略でも、少し違う順序で考えてプログラムを 3 つ作って」と言います。
- その中から、最もうまく動いたものを選びます。これは、料理人が「今日は塩味を強め、次は薄味、最後に甘め」と 3 種類試して、一番美味しいものを選ぶようなものです。

📊 結果は？

成果： この方法を使えば、AI は 17 種類の異なるパズルや物流の分野で、平均 82% の問題を正しく解けるようになりました（従来の方法より大幅に向上）。
汎用性： 一度作られた「戦略プログラム」は、**どんなに大きな問題（荷物が 1000 個あっても、1 万個あっても）**でも、同じプログラムで解くことができます。
コスト： 毎回 AI に考えさせるのではなく、一度「戦略」を作れば、その後はプログラムが自動で動くため、コストも大幅に下がります。

🚀 まとめ

この論文は、**「AI に『答え』を直接させるのではなく、『考え方のルール（戦略）』を一緒に作り上げ、失敗から学ばせて、最後に完璧な自動化プログラムを作る」**という、より賢く、頑丈な AI の使い方を提案しています。

まるで、AI に「料理のレシピ本」を一緒に書き上げさせ、そのレシピ本さえあれば、どんな客数でも、どんな食材でも対応できる「万能料理ロボット」を完成させるようなイメージです。

論文「Improved Generalized Planning with LLMs through Strategy Refinement and Reflection」の技術的サマリー

この論文は、大規模言語モデル（LLM）を用いた PDDL（Planning Domain Definition Language）ドメインにおける**一般化計画（Generalized Planning）**の精度を大幅に向上させるための新しいフレームワークを提案しています。従来の手法が抱える戦略生成の誤りによる失敗を、疑似コード（Pseudocode）レベルでの検証とリフレクション（反省）プロセスによって解決し、高品質な Python プログラム（一般化された計画）を生成することに成功しています。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細にまとめます。

1. 問題定義と背景

背景

一般化計画: 特定のタスクだけでなく、ある PDDL ドメイン内の「すべてのタスク」に適用可能な計画（ループや条件分岐を含む Python プログラムなど）を生成する課題。
既存の手法（Silver et al. 2024）: LLM に自然言語（NL）でドメインの要約と戦略（Strategy）を生成させ、それを直接 Python コードに変換するアプローチ。
課題:
- 生成された自然言語の戦略に誤りがあると、そのまま実装された Python プログラムも誤ったものになる。
- 戦略の誤りを発見・修正するプロセスが不十分であり、コード生成段階でのデバッグだけでは根本的な論理ミスを特定しにくい。
- 単一の戦略生成に依存しており、失敗時の回復力が低い。

2. 提案手法：戦略の精緻化とリフレクション

著者らは、戦略生成を単なる思考の連鎖（Chain-of-Thought）ではなく、独立したサブタスクとして扱い、以下の 3 つの主要な拡張を導入しました。

2.1 疑似コード（Pseudocode）戦略の生成と検証

疑似コードによる戦略生成: LLM に自然言語の要約ではなく、詳細かつ構造化された疑似コードとして戦略を生成させます。これにより、最終的な Python コードの構造に近い形でロジックを定義できます。
戦略レベルでのデバッグ:
- 生成された疑似コードを、LLM に「デバッグ用タスク」に対する PDDL プランを生成させる指示として使用します。
- 生成されたプランを記号プラン検証器（VAL）で検証し、誤りがあればフィードバックを生成します。
- リフレクションステップ: LLM に、なぜその誤りが発生したか（どの戦略部分が不適切か）を分析させ、その後に疑似コードを修正させます。このプロセスを最大 $K_S$ 回繰り返します。
- 最も多くのデバッグタスクを正しく解決した疑似コードを、最終的なコード生成に使用します。

2.2 コード生成段階でのリフレクション

Python コード生成においても、単なるエラー修正ではなく、リフレクションを導入します。
実行失敗時のフィードバック（例外、タイムアウト、不正なプランなど）に加え、正しく解けたタスクの例も提示します。
LLM に「なぜこのコードが失敗したか」を分析させ、論理的な欠陥を特定した上でコードを修正させます。

2.3 複数バージョンの生成と選択

コード生成時に、入力データの順序（オブジェクトや事実の並び）をランダムに変化させ、複数の初期プログラムバージョンを生成します。
各バージョンを個別にデバッグ・修正し、デバッグデータに対する性能が最も高いプログラムを最終出力として選択します。

3. 主要な貢献

戦略検証の自動化: 自然言語の戦略ではなく、疑似コードレベルで LLM と記号検証器（VAL）を連携させ、コード生成前に戦略の論理的誤りを自動的に検出・修正するパイプラインを確立しました。
リフレクションの統合: 戦略生成とコード生成の両段階で、エラーの原因を分析させる「リフレクション」ステップを導入し、LLM の自己改善能力を最大化しました。
多様性の確保: 複数のプログラム候補を生成し、ベストなものを選択するアプローチにより、生成の安定性を高めました。
広範な評価: 17 のベンチマークドメイン（Silver et al. 2024 の 7 ドメイン＋追加 10 ドメイン）および、LLM の学習データに含まれていない「衣装付き（Costumed）」や「匿名化（Anonymized）」バリエーションで評価を行いました。

4. 実験結果

設定

モデル: 推論モデル（DeepSeek-V3.2, Qwen3-30B-A3B-Thinking）と非推論モデル（GPT-4o, Llama3.3-70B）の 4 種類を使用。
比較対象: Silver et al. (2024) の手法（Sil）、および同等の条件で再実装したベースライン（Bas）。
指標: 評価タスクに対する正解プラン生成率（Coverage）。

結果

性能向上: 提案手法（F5-3 構成：初期プログラム 5 個、コードデバッグ 3 回）は、すべての LLM でベースラインを大幅に上回りました。
- 平均カバレッジ: 17 ドメイン全体で**82%**の平均カバレッジを達成（DeepSeek + F5-3 の場合）。
- ベースライン（Sil）との比較では、GPT-4o で 23 ポイント、Qwen で 20 ポイント、DeepSeek で 14 ポイント、Llama で 12 ポイントの改善が見られました。
完全カバレッジ: 14 のドメインにおいて、3 回の試行のいずれかで 100% のカバレッジを達成しました。
一般化能力:
- 100% カバレッジを達成したプログラムは、評価データセットを超えて、インスタンスジェネレーターで生成可能な任意のサイズのタスクに対しても正しく動作することを手動検証で確認しました。
- 「衣装付き」ドメイン（意味は同じだが名称が異なる）でも高い性能を維持し、LLM が単なる記憶ではなく、ドメインの論理構造を理解して戦略を構築していることを示しました。
効率性:
- 生成された Python プログラムの実行時間は、従来の記号プランナー（FF など）による計画生成時間よりも97% のタスクで大幅に短縮されました（指数関数的なスケールアップに対応）。
- プランの長さについては、FF 生成プランの約 1.1 倍とわずかに長いものの、実用上許容範囲でした。

計算コスト

提案手法はベースラインよりも多くの LLM 呼び出しとトークン処理を必要としますが、これはドメインあたりのコストです。一度正しいプログラムが生成されれば、そのドメイン内の無数のタスクに対して高速に実行可能であるため、全体としてのコスト対効果は高いと結論付けられています。

5. 意義と結論

この研究は、LLM を用いた一般化計画において、**「戦略の質」**が最終的な成功の鍵であることを実証しました。自然言語での戦略生成を疑似コード化し、記号検証器とリフレクションを組み合わせて戦略段階で誤りを修正するアプローチは、LLM の推論能力を最大限に引き出す有効な手段です。

スケーラビリティ: 生成されたプログラムは任意のタスクサイズに適用可能であり、記号プランナーの計算コストのボトルネックを解消します。
汎用性: 学習データに含まれていないドメインや、意味的に同一だが表現が異なるドメインでも機能するため、実世界への応用可能性が高いです。
将来展望: 今後の課題として、デバッグタスクの自動生成や、記号探索手法とのハイブリッド化が挙げられています。

総じて、この論文は LLM を単なるプラン生成器ではなく、**「一般化可能な制御プログラムを設計・実装する自律的なエンジニア」**として機能させるための重要なステップを示しています。