【更新 2026-07-22】本記事を見直し、修正しました。主な修正点：論文のページ数を「全31ページ」から「全32ページ」に訂正（arXiv掲載のComments欄「32 pages」に基づく）。
AIエージェントに付いている「承認待ち」「実行キャンセル」「タイムアウト」といった安全装置は、名前の通りに“止めて”くれるとは限りません。2026年7月に公開された査読前の研究論文が、広く使われる6つのオープンソースのエージェント基盤（フレームワーク）を検証し、いずれも「停止中は副作用が実行されない」という暗黙の約束を守れていなかったと報告しました。人の承認を挟んでいるのに、承認前に外部への書き込みやメール送信などが走ってしまう——本記事は、この“実効性の欠落”を情シスの視点で読み解きます。
この記事でわかること
- エージェント基盤の「制御プリミティブ」が抱える4類型の抜け穴
- 実際にどのくらいの頻度で“止まらない”のか（実測値）
- 自社でAIエージェントを検証・導入する際に確認すべき観点
※本記事は査読前（プレプリント）の論文を基にしています。結果は今後の査読・追試で変わりうる点にご留意ください。
どんな研究か（1文で）
「Stop Means Stop（停止とは停止のことだ）」と題したこの論文は、LLMエージェント基盤の制御機能が“止めたはずの副作用”を本当に止められているかを実測し、止められていない箇所を修復する外部ゲートを提案した研究です（Sajjad Khan、2026年7月15日 arXiv公開、全32ページ）。
ここで言う「制御プリミティブ」とは、エージェントの動作を人間や仕組みが押しとどめるための基本部品を指します。具体的には次の3つです。
- 承認ゲート（human-in-the-loop approval）：危険な操作の前で一時停止し、人の承認を待つ
- 実行キャンセル（run cancellation）：走っている処理を途中で止める
- タイムアウト（execution timeout）：一定時間で処理を打ち切る
いずれも「止めている間は、外部への副作用（メール送信・API呼び出し・ファイル書き込み・送金など）は起きない」という“バリア（関門）”の意味合いを名前と説明文で暗示しています。論文が検証したのは、その暗黙の契約が実際に成立しているかどうかです。
見つかった4つの抜け穴
論文は「モデルに依存しない差分プローブ」という手法で、6基盤に共通する4類型のギャップを切り分けました。要点を表に整理します。
| 類型 | 何が起きるか |
|---|---|
| 兄弟リーク（sibling leak） | 承認ゲートが自分の枝（branch）だけを止め、並行する“兄弟の枝”の副作用は止まらない。後から却下しても、その副作用はすでに実行済みで取り消せない。事前実行ゲートを持つ5基盤すべてで発生。 |
| リプレイ二重実行 | 処理の再実行（リプレイ）時に、同じ副作用が複数回実行される。 |
| キャンセルの孤児 | キャンセル信号を出したのに、副作用がそのまま進んでしまう。 |
| タイムアウトのゾンビ | タイムアウトで打ち切ったはずのプロセスが、制約を超えて動き続ける。 |
とりわけ「兄弟リーク」は分かりにくい落とし穴です。承認待ちで画面が止まっていても、裏で並行して走っている別ルートの処理は関門をすり抜けて実行され得る——「止まっているように見えて、止まっていない」わけです。
“作れる”ではなく“届いてしまう”——実測値
この種の欠陥で重要なのは、「理屈上は起こせる」で終わらず「普通に使っていて到達してしまう」かどうかです。論文は、リスクが現実に到達可能だと実測で示しました。
- あらかじめ固定した手順（プロトコル）の下で、最新の（フロンティア）モデルがリークを誘発する“計画の形”を出す割合は、まとめて最大14%。
- 実モデルが無改造のフレームワークを動かし、承認で一時停止させた条件では、1,200回の実行のうち215回（約18%）で、一時停止中に副作用が実行された（3種のスケジューラ・2種の言語ランタイムにまたがって観測）。
5回に1回近い割合で「承認前に副作用が漏れる」というのは、承認ゲートを“安全の最後の砦”と考えている運用にとって無視できない数字です。
情シスの実務にどう効くか
AIエージェントを社内業務（問い合わせ対応、チケット処理、SaaS操作の自動化など）に組み込む動きが広がるなか、多くの現場は「危険な操作の前に人の承認を挟めば安全」という前提で設計しがちです。本研究が突くのは、まさにその前提です。
- 「承認ゲートがある＝安全」ではない。ゲートが“分岐単位”でしか効かず、並行処理をすり抜けるなら、承認は形だけの儀式になりかねません。
- 取り消せない副作用ほど危険。送金・外部送信・削除・公開など、実行してしまうと元に戻せない操作を、エージェントの承認前実行に委ねていないかを棚卸しすべきです。
- “停止系”の機能は名前を信用せず、実挙動を確かめる。キャンセル・タイムアウトも同様に、打ち切ったつもりの処理が裏で続いていないかを検証対象にする必要があります。
これはAIエージェント特有の新しい攻撃面が次々と見つかっている流れの一つでもあります。関連して、AIエージェントのメモリが新たな攻撃面になるという研究や、SOCのログ分析AIを狙うプロンプトインジェクション、LLMで攻撃を全自動で再現する敵対的エミュレーション研究も併せて押さえておくと、エージェント導入時のリスク像を立体的に描けます。
提案された修復：外部ゲート「SOUNDGATE」
論文は問題提起だけでなく修復策も示しています。SOUNDGATEは、エージェントの実行環境の“外側”に置くRust製のゲートで、あらゆる副作用はここを通らないと実行できません。4つのギャップに1対1で対応する性質を課すのが特徴です。
- 決定が下るまで保留（hold-until-decided）
- 却下はキャンセルとして扱う（reject-cancels）
- リプレイ時は重複排除（dedup-on-replay）
- キャンセル時は隔壁を設ける（fence-on-cancel）
著者らは中核部分をモデル検査（TLA+/TLC、Verus、Loom等）で検証し、実装との突き合わせも大規模に行ったとしています。性能は書き込み1件あたり約1ミリ秒の許可判定で、毎秒1.2万〜2.6万件の耐久的な許可をさばけると報告。6基盤すべてで測定された違反を止めつつ、正当な副作用は通せたとしています。ただし著者自身が「これは（完全な機械化証明ではなく）精緻化の“証拠”だ」と位置づけている点は読み手として押さえておきたいところです。
限界と留意点
- 査読前の単著論文であり、結果は今後の追試・査読で補強・修正されうる。
- 検証対象は「広く使われる6つのオープンソース基盤」とされるが、要旨では具体名が挙げられていない。自社が使う製品・基盤が該当するかは、各基盤のドキュメントと実挙動で個別に確かめる必要がある。
- SOUNDGATEはあくまで研究上の実装であり、そのまま本番導入できる完成品とは限らない。考え方（副作用を外部で一元的に許可制にする）を自社設計にどう取り込むかが実務上の論点になる。
現場目線の所感
「承認を挟んでいるから大丈夫」という安心感は、運用者にとってとても心地よいものです。しかし現場で起きがちなのは、UIで「承認待ち」と表示されている裏側で、実装の都合上すでに走ってしまっている処理があること——この“見えている状態と実際の状態のズレ”こそ、限られた人員では気づきにくく、事故になって初めて表面化します。ツールの機能名やドキュメントの文言を鵜呑みにせず、「本当に止まっているのか」を小さな検証環境で自分の手で確かめる。地道ですが、AIエージェントを業務に載せる前にやっておく価値のある一手間だと感じます。
まとめ
- 査読前研究は、6つの主要なLLMエージェント基盤すべてで「停止中は副作用が実行されない」という約束が守られていないと実測した。
- 承認一時停止中に副作用が漏れる割合は1,200回中215回（約18%）に達し、リスクは机上ではなく現実に到達可能だった。
- 情シスは「承認ゲートがある＝安全」と考えず、取り消せない副作用を洗い出し、停止系機能の実挙動を自ら検証する姿勢が要る。
出典
- Sajjad Khan, “Stop Means Stop: Measuring and Repairing the Enforcement Gap in Agent-Framework Control Primitives”, arXiv:2607.14166（2026年7月15日, 査読前）: https://arxiv.org/abs/2607.14166
- AIエージェント導入時のリスク管理の考え方は、IPAの各種ガイドラインも参考になります（中小企業の情報セキュリティ対策ガイドライン ほか）。
