配送先の変更をエージェントが読んでも、変更前に作った配送計画がそのまま実行されることがある。
2026年9月3日公開のPlanFence論文は、最新情報の取得と、実行する計画の前提確認が別の処理であることを対照実験で示した。
必要なのは、計画が参照したデータの版を記録し、外部操作の直前に照合する仕組みだ。

Purdue大学とUniversity of ExeterのEvan Chen、Shiqiang Wang、Christopher G. Brintonによる研究である。対象は、複数のエージェントが計画・状態更新・ツール実行を分担するシステムだ。モデルの知識量ではなく、計画を作ってから実行するまでの時間差に焦点を当てている。論文の公開情報

本記事は2026年9月16日時点で公開されているarXiv v1を読む技術解説である。数値は著者の報告であり、筆者による追試ではない。研究は条件を制御した実験で、一般的なエージェントの故障率や、実サービスの安全性を測ったものではない。

「最新版を読んだ」と「最新版から考えた」は違う

配送処理を例にすると、問題は次の順序で起きる。以下の住所は説明用の例だ。

計画担当が、配送先「東京」の注文データ r3 を読む。
その版をもとに、東京宛ての配送計画 p3 を作る。
別の担当が、配送先を「大阪」に変えた r4 を確定する。
実行担当のメモリにも r4 が届く。
しかし実行担当は、手元に残る p3 の引数で配送ツールを呼ぶ。

4の時点で、情報の同期には成功している。それでも、計画の内容は自動では書き換わらない。論文はこれを stale-plan execution、古い計画に基づく実行 と呼ぶ。

この区別は、長い処理や人間の承認待ちが入るシステムで効いてくる。再開時に会話履歴を復元できても、停止前に決めた引数が現在の要求に合うとは限らない。これは論文の仕組みから導ける運用上の注意点である。

PlanFenceが確かめるのは、「実行担当が何を知っているか」よりも、「その操作の根拠となる計画が、どの版から作られたか」だ。論文第1・3節

計画に、入力データの版を結び付ける

PlanFenceでは、同じ情報を指すキーと、その情報の特定の版を区別する。

要素	配送の例	役割
意味的なキー	`order/42/requirement`	更新後も同じ注文要件を指す
不変のレコードID	`r3`、`r4`	特定の版を指す
正本を管理するowner	注文要件の管理プロセス	現在有効な版を回答する
計画の親ID	`p3` の親が `r3`	計画の導出元を残す
操作の依存キー	配送に影響する注文要件など	実行前に調べる対象を決める

親IDは、生成された文章に「最新版を使いました」と書かせるだけでは足りない。アプリケーション側が、派生レコードを書き込む際に実際の入力版を結び付ける。操作に影響するキーの集合も、ツールを包むアプリケーションコードが宣言する。論文ではこの集合を $D(a)$ と表す。

計画から親をたどって得られる入力版を $F_a(x)$、正本の管理者が回答する現在の版を $H(x)$ とすると、操作 $a$ の検証条件は次の形になる。

$$
F_a(x)=H(x)\quad\text{for every }x\in D(a)
$$

たとえば、計画側が r3、正本側が r4 なら不一致である。実行担当がすでに r4 を受信していても、その事実だけで判定を通さない。

計画が別の判断結果を参照し、その判断結果が注文要件を参照している場合は、親を複数段たどる必要がある。直近の親だけを見る実装では、途中の派生物に隠れた古い入力を検証できない。付録Cでは、親の連鎖を深さ1・2・4・8で調べ、この違いを確認している。論文第3〜4節・付録C

不一致なら一度だけ再計画する

検証処理は、外部ツールの呼び出し直前に置く。

計画の親をたどり、宣言された依存キーに対応する入力版を集める。
各キーの正本管理者へ、現在の版を並行して問い合わせる。
一致すれば、その検証時点では計画の前提が有効と判定する。
不一致なら、変更されたレコードを取得・検証して、一度だけ計画を作り直す。
新しい計画でもう一度照合し、再び変化している場合は停止する。

親レコードの欠落、正本管理者の応答不能、不正な応答などで検証を完了できない場合も停止する。無制限に再計画を繰り返す設計ではない。

これは新しいLLMの推論技法というより、生成された計画へ読み取り集合と来歴を持たせ、実行境界で検証するプロトコルである。論文も、データ来歴や楽観的並行制御と同じ基礎的な考え方を用いていると説明する。

30タスクで分かったことと、分からないこと

モデルを実際に呼ぶ対照実験では、予約・配送・デプロイの3種類に各10シードを使い、5体のエージェントを別プロセスで動かした。モデルはQwen3.5-35B-A3B、temperatureは0.2、thinkingは無効だった。

各タスクで、計画生成後から主要なツール操作までの間に、要件の更新を一度入れている。3方式それぞれに30タスク、計90試行を比較した結果が以下だ。

方式	完了タスク	古い前提による主要操作	成功した再計画
最新の正本を読むだけ	0/30	30/30	なし
集中管理で来歴を検証	30/30	0/30	30/30
PlanFence	30/30	0/30	30/30

出典は論文Table 2および付録A.5。ここでの「古い前提」とは、計画が現在の依存入力の版に結び付いていないことを指す。対照実験の原文

読み取れるのは、この競合を起こした条件では、最新版を読む処理だけでは足りず、計画の導出元を検証すると修復できたということだ。

一方、「世の中のエージェントは100%失敗する」「PlanFenceだけが防げる」とは読めない。前者は故意に更新を挟んだ実験設計を無視しており、後者は集中管理方式も同じ結果だったことを無視している。

また、監査担当のエージェントは、すでに有効だった操作を不要に繰り返している。集中管理方式で4回、PlanFenceで10回あった。古い前提を防ぐことと、重複実行を防ぐことは別の課題である。

違反が0/30だったことも、将来の違反確率がゼロという意味ではない。論文が示す片側95%の二項分布に基づく上限は9.5%で、これも当該実装の実験範囲に関する値である。

すべて同期するか、必要な依存先を確認するか

来歴の検証をするなら、全員へ毎回更新を配る方式でも安全条件を満たせる。PlanFenceの別の論点は、いつ、どこまで通信するかにある。

論文は性能比較のため、モデルの判断を固定したリプレイも行っている。これは30タスクのモデル実行とは別で、同じ判断と更新順序を各方式に与え、同期や検証による待ち時間を測る実験だ。

次の表は、共有キー8個、操作の依存先1個、5エージェント、固定した過去のAT&T回線トレースを使う条件である。1エピソードに42回の更新と11回の保護対象操作を入れ、30テンプレートで合計330操作を比較した。各RPCは新しいTCP接続を開く。

来歴を検証する方式	調整待ち時間 ms/操作	通信量 KiB/操作
集中管理	508.6	15.6
更新のたびにメタデータ同期	403.4	23.5
全キーを管理者単位でまとめて照会	258.4	16.4
PlanFence	230.8	8.1

この4方式はすべて、330操作を実行し、古い前提による操作は0回だった。数値は論文Table 1からの抜粋である。リプレイの条件と結果

ここでいう待ち時間は、同期・検証を待つ coordination stall である。モデル推論や外部サービス処理を含む、利用者の総待ち時間ではない。回線名も過去のトレースの識別子で、現在の通信事業者の性能評価ではない。

PlanFenceでは、その操作と関係のない共有キーを照会対象から外せる。一方、依存先が共有キー全体に広がると、この利点は縮む。別の実験では、依存先が8個中8個になると、全キー照会との差は著者が定めた10%未満の「実務上同等」の範囲に入った。

更新が少ない場合も、実行時の問い合わせを先に済ませられる逐次同期が有利になる。したがって、PlanFenceを常に最速の構成として選ぶ根拠にはならない。通信コストの差を生むのは、更新頻度と、操作が依存する範囲である。

保証が届かない境界

宣言し忘れた依存先は、自動では見つからない

配送先だけを検証しても、配送可否が支払い状態に依存するなら、それも宣言に含める必要がある。PlanFenceは、隠れた依存関係をモデルの文章から自動発見する仕組みではない。

付録Cでは、真の依存先4個のうち1個だけを必ず宣言し、残り3個を確率的に省略した。省略確率を50%にすると、不安全な操作の発行割合は37.4%に達した。これは宣言漏れを注入した実験であり、本番環境の発生率ではない。

検証器が欠落を検出できた場合には停止できる。しかし、アプリケーションが依存先そのものを黙って宣言から落とした場合、比較すべき対象が見えない。完全な依存宣言は、利用側が成立させる前提である。

検証と外部操作は、一つのトランザクションではない

さらに重要なのは、次の隙間だ。

計画p4と正本r4が一致
    ↓ 検証通過
要件がr5へ更新
    ↓
p4の引数で外部サービスを操作

PlanFence単体では、この隙間を閉じない。複数の正本管理者から同時点の状態を取得することも、検証から外部操作までを不可分にすることも保証していない。論文が保証する境界は、記録された検証時点である。

ほかにも、正本管理者が悪意を持たないこと、親IDが正確であること、認証された通信を使うことを前提とする。正本管理者の移行、意味的な変更のマージ、公開レコードに残らない内部推論などは対象外だ。論文第6節・付録C

実務では、外部操作の契約までつなぐ

以下は論文の保証を広げる説明ではなく、そこから考えられる実装上の方針である。

まず、配送確定や予約変更などのツールごとに、「何が変わったらこの引数を使えなくなるか」を列挙する。入力を読むアプリケーション層で版を捕捉し、計画からその入力までの連鎖を残す。計画本文と別々に更新してしまうと、来歴自体が信用できなくなる。

次に、操作先が対応する場合は、操作要求にも期待する版を渡す。HTTPなら If-Match がその一例だ。RFC 9110の13.1.1節は、対象リソースのETagとの強い比較を規定し、条件が偽なら要求されたメソッドを実行しないとする。2022年6月の既存仕様であり、今回の新提案ではない。RFC 9110のIf-Match

ただし、配送先が別サービスにあるのに、注文のETagを送るだけで整合性が生まれるわけではない。操作先がその版の意味を理解し、条件判定を実際の更新へ結び付ける必要がある。複数サービスにまたがる保証は、別途設計することになる。

重複実行の制御も分けて考えたい。同じ操作の再送を抑える冪等性の仕組みと、古い前提で作った新規操作を拒む版の検証は、異なる条件を扱う。論文の監査担当による重複操作は、この区別を忘れないための具体例になる。

運用テストには、通常の成功ケースに加えて、次の更新順序を入れるとよい。

計画後、実行前に、依存する要件を変える。
再計画中にもう一度要件を変え、処理が停止することを確認する。
親レコードや正本管理者を利用不能にし、未検証のまま操作しないことを確認する。
操作と無関係なキーだけを変え、不必要な再計画が起きないことを確認する。

完了率だけでなく、検証で止めた件数、再計画で回復した件数、重複操作、外部サービス側で拒否された版不一致を分けて記録する。これにより、停止によって古い計画を防いだのか、処理を完了しつつ防いだのかが分かる。

「メモリの更新は届いたか」に加え、「この操作を決めた入力版は、まだ有効か」を実行境界で問う。それが、この研究からエージェントの設計へ持ち帰れる具体的な変更である。

参考リンク

Fresh Memory, Stale Plans: Dependency-Scoped Validation for Distributed LLM-Agent Memory（Evan Chen、Shiqiang Wang、Christopher G. Brinton、2026-09-03、arXiv v1）

同論文の全文・実験表・付録（本文の図は説明用に作成し、表は原論文の数値を抜粋・日本語化。原論文はCC BY 4.0）

Creative Commons Attribution 4.0 International（原論文のライセンス）

RFC 9110: HTTP Semantics, Section 13.1.1 If-Match（2022-06。条件付き操作の補足資料）