Procedural Graphs Self-Evolving Execution: LLMアプリ実装で見る設計論点

description: LLMエージェントの実行構造を動的に書き換える「Procedural Graphs」の論文を読み解きます。既存のReActやDAGベースのワークフローとの差分、実装上の注意点、プロダクト適用時の判断材料を整理します。

meta description: Procedural Graphsは、LLMエージェントが実行中にグラフ構造自体を更新する手法です。ReActやLangGraphとの設計差分、実装・運用上の論点をまとめました。

---

何が出たのか

2026年9月上旬、LLMエージェントの実行制御に関する論文「Procedural Graphs: Self-Evolving Execution Structures for LLM Agents」が公開され、Hacker NewsやHugging Faceのコミュニティで議論が広がっています。

この研究が提案するのは、エージェントが長期タスクを実行する際に、あらかじめ固定されたワークフロー（処理の流れ）ではなく、実行中にグラフ構造そのものを書き換えながら進む「Procedural Graphs（手続きグラフ）」という仕組みです。

従来のLLMエージェントの多くは、ReActパターン（思考→行動→観察を繰り返すループ）や、あらかじめ定義したDAG（有向非巡回グラフ：処理の依存関係を表す構造）に沿って動作します。これらは実行前に構造が決まっており、途中で計画を大きく変えることが難しいという制約がありました。Procedural Graphsは、この制約を「グラフ自体をLLMが動的に編集する」という方向で解こうとしています。

論文の主張は大きく3点です。まず、エージェントが実行履歴全体をコンテキストとして保持し続ける代わりに、グラフのノード（処理単位）とエッジ（依存関係）として構造化して管理します。次に、実行中に新しいサブタスクが必要になった場合や、既存の計画が失敗した場合に、LLMがグラフを更新（ノードの追加・削除・接続変更）します。そして、この構造化によってコンテキストウィンドウの消費を抑えつつ、長期タスクの追跡可能性を高めると主張しています。

---

技術的に面白い点

グラフ構造を「実行状態の記憶」として使う

通常のエージェントは、ツール呼び出しの結果や中間出力をすべてプロンプトの履歴として積み上げていきます。タスクが長くなるほどコンテキストが肥大化し、LLMが重要な情報を見失ったり、APIのトークン上限に達したりするリスクが高まります。

Procedural Graphsでは、各ノードが「タスクの状態」「実行結果」「依存関係」を持ちます。LLMは全履歴ではなく、現在のノードとその直接の依存ノードだけを参照して次の行動を決定します。これはグラフを「外部メモリ」として機能させる設計で、コンテキスト長の問題を構造的に緩和しようとしています。

LLMがグラフ編集操作を出力する

実装上の核心は、LLMの出力フォーマットにあります。通常のエージェントがJSON形式でツール呼び出しを出力するのと同様に、Procedural Graphsでは「ノード追加」「エッジ追加」「ノード状態更新」「ノード削除」といったグラフ操作命令をLLMが出力します。ランタイム（実行環境）がこれを受け取り、グラフを更新したうえで次のステップを実行します。

この設計は、LLMの出力を「アクション」だけでなく「計画構造の更新」にまで拡張しているという点で、既存のFunction Callingの延長線上にあります。ただし、グラフ操作の正確性はLLMの出力品質に直接依存するため、不正なグラフ操作（存在しないノードへのエッジ追加など）を検出・棄却するバリデーション層が必要になります。

失敗時の局所的な再計画

ReActパターンでは、ツール呼び出しが失敗した場合、エージェントは全体の思考ループを最初から再開するか、失敗をコンテキストに追記して次の判断を促します。Procedural Graphsでは、失敗したノードを「失敗状態」としてマークし、そのノードとその依存先だけを対象に再計画を行います。タスク全体を再実行せずに済む可能性があり、長時間タスクの途中失敗に対するfallback（代替処理）として機能します。

---

既存の流れとの違い

ReActとの比較

ReActは「思考→行動→観察」のループをプロンプト上で繰り返す手法で、実装がシンプルで多くのフレームワークに採用されています。一方で、タスクが複数のサブゴールを持つ場合、どのサブゴールがどの状態にあるかをLLMが追跡し続ける必要があり、コンテキストが長くなると精度が落ちやすい傾向があります。Procedural Graphsはこの「状態追跡」をグラフ構造に外出しすることで、LLMが参照すべき情報量を絞ります。

LangGraph・LlamaIndex Workflowsとの比較

LangGraphやLlamaIndex Workflowsは、開発者が事前にグラフ構造を定義し、LLMはそのノード内の処理を担当するという設計です。グラフ構造自体は静的（実行中に変わらない）であり、条件分岐はエッジの条件として事前に記述します。Procedural Graphsとの最大の差分は、「グラフ構造を誰が・いつ決めるか」です。LangGraphは開発者が設計時に決め、Procedural GraphsはLLMが実行時に決めます。

この差分は、ユースケースの向き不向きに直結します。処理フローが比較的予測可能な業務システムであれば、LangGraphのような静的グラフのほうが動作の予測可能性が高く、デバッグもしやすいです。一方、ユーザーの要求が多様で事前に全パターンを列挙できないタスク（調査・分析・コード生成など）では、動的なグラフ更新が有効に機能する可能性があります。

Plan-and-Executeパターンとの比較

Plan-and-Execute（計画を先に立ててから実行するパターン）は、タスク開始時にLLMがサブタスクのリストを生成し、それを順番に実行します。計画が固定されているため、実行途中で前提が崩れた場合に対応が難しいという課題があります。Procedural Graphsは計画（グラフ）を実行中に更新できる点で、この課題に対応しようとしていますが、その分だけLLMへの呼び出し回数が増え、レイテンシとコストが上昇します。

---

実装・運用で気になる点

グラフ操作のバリデーションとログ

LLMが出力するグラフ操作命令は、構文的に正しくても意味的に不正な場合があります（例：完了済みノードへの依存追加、循環参照の発生）。実装時には、操作命令を受け取ったタイミングでグラフの整合性チェックを行うバリデーション層を必ず設ける必要があります。また、どのステップでどのグラフ操作が行われたかをログとして保存しておかないと、エージェントが意図しない動作をした際の原因追跡が困難になります。グラフのスナップショットをステップごとに記録する設計が現実的です。

LLMモデルの選定と出力安定性

グラフ操作命令を正確に出力できるかどうかは、使用するLLMのInstruction Following（指示への追従性）に強く依存します。2026年9月時点では、GPT-4oやClaude 3.5系、Gemini 1.5 Pro系のモデルであれば構造化出力の安定性は比較的高いですが、より小さなモデルやファインチューニングなしのオープンソースモデルでは、グラフ操作命令のフォーマット崩れが頻発する可能性があります。プロダクト適用前に、対象モデルでのグラフ操作出力の成功率をベンチマークしておくことが重要です。

レイテンシとコストのトレードオフ

グラフを更新するたびにLLMへの呼び出しが発生するため、タスクの複雑さに比例してAPI呼び出し回数が増加します。長期タスクでは1回のタスク完了までに数十回のLLM呼び出しが発生することも想定されます。コスト管理の観点では、グラフ更新の頻度を制御するポリシー（例：n回のアクションごとにグラフを見直す）や、グラフ更新判断に使うモデルと実行に使うモデルを分ける（安価なモデルで更新判断、高性能モデルで実行）といった設計上の工夫が必要になります。

評価とモニタリング

エージェントが自律的にグラフを書き換えるため、最終的な実行パスが事前に予測できません。これは評価の難しさに直結します。タスク完了率や最終出力の品質だけでなく、グラフがどのように進化したか（ノード数の推移、再計画の発生回数、失敗ノードの割合）をモニタリング指標として設計しておくと、システムの挙動を把握しやすくなります。LangSmithやArize AIのようなLLMオブザーバビリティツールと組み合わせる場合、グラフのスナップショットをトレースに紐付ける仕組みが必要になります。

セキュリティと権限管理

エージェントが動的にグラフを拡張できるということは、意図しないツール呼び出しや外部アクセスが発生するリスクも高まります。特に、グラフのノードがAPIアクセスやファイル操作を伴う場合、どのノードがどのリソースにアクセスできるかを事前に制限するサンドボックス設計が重要です。LLMが生成したグラフ操作命令を無条件に実行するのではなく、許可されたノードタイプ・ツールセットの範囲内でのみ操作を受け付けるホワイトリスト方式が現実的な選択肢です。

---

Spectralの見解

1. 技術的な読み

Procedural Graphsは、LLMエージェントの「状態管理」と「計画の柔軟性」という2つの課題に対して、グラフ構造を実行時の中心的なデータ構造として据えることで対処しようとしています。アイデア自体は理にかなっており、コンテキスト長の問題や長期タスクの追跡可能性という実際の課題に対応しています。ただし、論文ベースの提案であり、2026年9月時点では実用的なOSSライブラリや標準的な実装パターンが確立されているわけではありません。LangGraphのような既存フレームワークとどう統合するか、あるいは独自実装が必要かは、適用するシステムの要件次第です。

2. PoCで確認すべき点

PoCの段階では、以下の3点を優先的に検証することを推奨します。まず、グラフ操作の安定性: 対象モデルが正しいフォーマットでグラフ操作命令を出力できる割合を、実際のタスクで計測します。次に、再計画の有効性: 意図的に失敗シナリオを作り、局所的な再計画がタスク全体の完了率を改善するかを確認します。そして、コストとレイテンシの実測値: 想定するタスクの複雑さに対して、1タスクあたりのAPI呼び出し回数とコストが許容範囲に収まるかを測定します。

3. 業務・プロダクト実装に移す時のリスク

業務システムへの適用を検討する場合、最大のリスクは「動作の予測可能性の低さ」です。グラフが動的に変わるため、同じ入力に対して毎回同じ実行パスを通る保証がなく、テストケースの設計が難しくなります。また、グラフ操作のバリデーション不備や権限管理の甘さは、意図しない外部アクセスや無限ループに直結します。プロダクト適用時は、静的グラフで対応できる範囲を先に切り出し、動的グラフが必要な部分を限定的に導入するハイブリッド設計が安全です。決裁者の視点では、「エージェントが自律的に計画を変える」という特性は、監査ログと承認フローの設計をセットで検討しないと、業務上のリスク管理が難しくなる点を認識しておく必要があります。

---

まとめ

Procedural Graphsは、LLMエージェントの実行構造をグラフとして動的に管理するアプローチです。コンテキスト長の問題、長期タスクの状態追跡、局所的な再計画という実際の課題に対して、構造的な解を提示しています。

既存のReActやLangGraphとの差分は「グラフ構造を誰が・いつ決めるか」という設計判断に集約されます。処理フローが予測可能な業務システムには静的グラフが向いており、多様なユーザー要求に対応する必要があるシステムでは動的グラフの価値が出てきます。

実装時の主な論点は、グラフ操作のバリデーション、LLMモデルの出力安定性、レイテンシとコストの管理、モニタリング設計、そして権限管理です。これらを事前に設計に組み込まないと、動的グラフの柔軟性がそのままデバッグの困難さとして返ってきます。

PoCで動作の安定性と実コストを確認したうえで、静的グラフとのハイブリッド設計を検討するのが、現時点での現実的な適用方針です。

---

*Spectralでは、LLMエージェントの設計・実装・評価に関する技術調査やPoC支援を行っています。Procedural Graphsのような新しい実行制御手法を自社システムに適用できるか検討したい場合は、お気軽にご相談ください。*

関連論点として Do AI Agents Know When a Task Is Simple? Toward: LLMアプリ実装で見る設計論点 もあわせて読むと、この技術動向の背景を追いやすくなります。

Spectralでは、技術調査からPoC設計、プロダクト実装まで支援しています。実現性の確認や事業活用の相談は サービス詳細 と お問い合わせ をご覧ください。