9月9日、Yuxing Luら4名が「Procedural Graphs: Self-Evolving Execution Structures for LLM Agents」と題した論文を公開した。LLMエージェントの実行手順を「手続きグラフ」として明示的に保持し、失敗と成功の軌跡の差分から自律的に改善するアーキテクチャを提案している。「何を知っているか」ではなく「どうやるか」を構造化して再利用するという発想で、従来のメモリ・RAGベースのアプローチを一貫して上回る性能を実験で示している。
なぜ今、エージェントの「手順の外在化」が問われているのか
LLMエージェント研究は近年急速に進んでいるが、実用上の壁として繰り返し指摘されるのが「過去の行動から何も学べない」問題だ。典型的な実装では、行動履歴がコンテキストウィンドウに積み上がっていくだけで、「この種のタスクはこういう順番で解く」という構造的な知識は残らない。コンテキストウィンドウが長くなるほど参照コストも増し、根本的な解決にはなっていない。
この問題に対してここ数年、RAG（検索拡張生成）による事例検索や、外部メモリへの経験蓄積といったアプローチが試みられてきた。しかしいずれも「何を知っているか（ファクト・事例）」の外在化であり、「どうやるか（手順・戦略）」の構造化には至っていなかった。本研究はまさにその空白を埋めようとするものだ。
「手順をグラフとして外在化する」という発想
本研究が提案するProcedural Graph（手続きグラフ）は、知識グラフが「エンティティ−関係−エンティティ」の三つ組でファクトを保持するのと同様に、「手順−関係−手順」の三つ組で「何をどの順番でやるか」を明示的に格納する構造体だ。エージェントはこのグラフをクエリすることで、次の行動を構造的に参照できる。
エージェントが各ステップを実行するとき、フレームワークはグラフ上の現在ノード（active node）を特定し、周辺のサブグラフを「状況的ガイダンス」に変換して、行動を実際に決定するLLM（ソルバー）の次の行動を誘導する。
重要なのは、ガイダンスは命令ではなく確率的なバイアスである点だ。グラフの記述が誤っていても、ソルバーは自由に逸脱できる設計になっており、グラフが不完全な状態でも動作が保証される。これが後述の「欠陥のある初期グラフでも機能する」堅牢性につながっている。
自己進化のメカニズム：失敗と成功の差分から学ぶ
このアーキテクチャの核心は自己進化ループにある。
- 別に用意したLLMリファイナー（ソルバーとは独立したLLM）が、失敗した軌跡と成功した軌跡を比較する
- グラフのトポロジー（ノードとエッジの構造）および属性を編集する
- 編集後のグラフをホールドアウトしたバリデーションデータで評価し、性能が維持または改善される編集だけをコミットする
- 却下された編集は記録に残し、同じ変更が再提案されないようにする
特筆すべきは、欠陥のある人手設計のグラフを出発点にしても、そのグラフ自体を修正できる点だ。初期の設計ミスを引きずらず、自己進化によって上書きできる。また、最小限のスケルトンから出発しても、人手設計と同等以上のグラフを構築できることが実験で示されている。
ベースラインとの比較：数値で示す優位性
実験は複数のデータセット・タスク種別・バックボーンLLMにわたって実施された。手続きグラフはメモリベースのベースライン（過去の会話履歴の保持やRAGによる事例検索など）を一貫して上回っており、自己進化ステップを加えると手動エンジニアリングなしでさらなる性能向上が得られる。論文では特にツール利用系タスクと多段推論タスクで顕著な改善が報告されている。
メモリベースのアプローチとの本質的な違いは、手続きグラフが「何を覚えているか」ではなく「どうやるか」を構造化している点にある。事例を引っ張ってきてその場で解釈するのではなく、抽象化された手順そのものを保持して再利用する、という設計思想の差だ。
実行知識を暗黙的な履歴から明示的なグラフ構造へと移し替えることで、参照・修正・進化を可能にするこの枠組みは、「フォールバック時もソルバーが自由に動ける設計」と「欠陥のある事前知識でも修正できる自己進化」を組み合わせた実運用を意識した設計になっている。
詳細はProcedural Graphs: Self-Evolving Execution Structures for LLM Agentsを参照していただきたい。
