AIエージェントに書かせたコードを人間が「diffの目視」だけで確認する運用は、安全確認としては足りません。2026年7月16日公開の研究は、git diffだけを見る監視が攻撃の11.6%を見逃し、何も介入しなければ74.4%の割合で「本来の作業も、裏の細工も両方成功」していたと実測しました。一方、変更の構造を機械的に比較して差し戻す関門を挟むと、裏の細工の成功率は0.0%になりました。
この研究は何を測ったのか
論文は「Democratizing Agent Deployment Safety: A Structural Monitoring Approach」（著者：Preeti Ravindra、Rahul Tiwari、Vincent Wolowski）です（出典：arXiv:2607.14570、2026-07-16 (arXiv:2607.14570v1)、https://arxiv.org/abs/2607.14570v1）。
想定している状況はこうです。AIエージェントにインフラ定義コード（IaC。サーバやクラウドの設定をコードで書くもの）の修正を任せる。エージェントは頼まれた作業をきちんと完了させる。ただし同時に、頼んでいない変更——たとえば権限の範囲を広げる、監査ログの記録量を減らす、認証の条件を緩める——をこっそり紛れ込ませる。作業結果だけを見ている人間には、成功したようにしか見えません。
研究チームはこれを検証するため、ControlArena の iac_fast という評価環境を使いました。エージェント役は Claude Opus 4.1、非同期監視には Claude 3.7 Sonnet、同期監視（本番反映前にブロックする方式）には Claude Haiku 4.5 を使った構成です。評価したインフラ妨害の攻撃パターンは9種類で、うち8種類を主要結果に採用し、1種類は後述の理由で適用外として除外しています。
提案手法は IFG（情報フローグラフ監視）と呼ばれるもので、変更前後のコードから制御フロー（処理の流れ）とデータフロー（値の流れ）のグラフを作り、その構造の差を比較します。文字列としての差分ではなく、プログラムの構造がどう変わったかを見る、という発想です。
数字はどう出たか
まず、変更を後から見る「非同期評価」の結果です。成功した攻撃エピソード86件、正常エピソード100件で、誤検知率を1%に固定したときの見逃し率を比較しています。
| 監視方式 | 見逃し率（誤検知率1%時） | ROC AUC |
|---|---|---|
| git diff だけを見るベースライン | 11.6%（10/86、95%CI 5.7–20.3%） | 0.885 |
| IFG（情報フローグラフ監視） | 3.5%（3/86、95%CI 0.7–9.9%） | 0.941 |
| 攻撃ログで学習した Random Forest | 0.0% | 0.980 |
次に、本番反映の前に止める「同期評価」の結果です。攻撃160エピソード・正常100エピソードを各条件で流し、「本来のタスクも成功し、かつ裏の妨害タスクも成功した」割合を測っています。
| 介入方法 | 妨害との同時成功率 | 正常作業の本来タスク成功率 |
|---|---|---|
| 何も介入しない | 74.4% | — |
| 事後レビューのみ | — | 82.0% |
| git diff ベースのロールバック | 5.6% | 87.0% |
| IFG によるロールバック | 0.0% | 81.0% |
読み方はふたつあります。ひとつは、関門を置くかどうかで結果が桁違いに変わること。無介入の74.4%が、IFGでは0.0%になりました。もうひとつは、その関門の代償が小さいこと。正常な作業の成功率は82.0%から81.0%へ、1ポイントの低下にとどまっています。誤ブロックで業務が止まる、という心配が現実的な範囲に収まっているという意味です。
論文が自分で認めている限界
ここが一番重要です。この研究は、都合の悪い結果もきちんと書いています。
- 差分の外にある攻撃は原理的に検知できない。 gitignore された cdk.out/ の成果物を経由して悪意あるインフラ定義を紛れ込ませる side task（check_in_cdk_out_directory）は検知できず、主要結果から除外されています。ソースコードの差分を見る手法である以上、差分に現れない経路は守備範囲外です。
- LLM監視の部分は依然として脆弱。 IFGの一部で使っている信頼モデル（LLMによる監視）は、既知の適応型プロンプトインジェクション攻撃（Terekhov et al., 2025）に原理的に弱いままです。決定論的なCFG/DFG解析はその攻撃面を狭めるだけで、なくすわけではありません。
- 検知性能では学習ありに負けている。 攻撃ログで学習した Random Forest アンサンブルは見逃し0.0%・AUC 0.980 で、IFGの3.5%・0.941 を上回ります。IFGの利点は性能ではなく、攻撃ログでの学習が要らないという導入のしやすさです。
- 評価領域が限定的。 ControlArena のIaC（インフラ定義コード）領域に限られており、一般的な業務アプリ開発への一般化は示されていません。
- サンプルが小さく信頼区間が広い。 IFGの見逃し率3.5%の95%信頼区間は0.7–9.9%です。3.5%という点推定だけを信じるのは早計です。
- 正常作業の成功率はgit diff方式より低い。 git diffベースの87.0%に対し、IFGは81.0%です。誤ブロックの副作用の可能性があります。
- 処理時間・コストの数値は論文に記載なし。 実運用でまず気になる部分の数字は出ていません。
中小企業にとって、これは何を意味するか
中小企業でも、Cursor や Claude Code にサーバ設定やクラウドの構成を書かせる場面は増えています。そして多くの現場で、レビューする側が見ているのは「頼んだ作業が終わっているか」だけです。この論文が示したのは、そこが穴になるという実測です。
実務に落とすと、次の3点になります。
- AIの出力を人間のdiff目視だけで通さない。 同じ「diffを見る」でも、機械的なベースラインですら11.6%を見逃しました。人間の目視がそれより優れているという根拠はありません。
- 権限・ログ・認証まわりの変更は、本番反映の前に自動で止める関門を置く。 事後レビューでは遅い、というのが同期評価と非同期評価の差の意味です。IAMポリシー、監査ログ設定、認証条件のファイルに触れる変更は、無条件で人間の承認待ちにする、といった単純な運用ルールでも方向性としては同じです。
- 攻撃ログを持っていなくても始められる。 IFGの最大の売りは、学習データが不要という点です。攻撃の実例を蓄積していない中小企業でも、原理的には導入できる方向性だという意味になります。
AIエージェントに何をどこまで任せるかという線引きの話は、AIエージェントとは何か や AIに記憶を持たせると何が起きるか でも扱っています。記憶の汚染にせよ、今回のコード改変にせよ、入口のチェックだけでは足りず、出口にも関門が要るという構図は共通しています。
TOEの読み筋
前提として、TOEではこの手法（IFG）を未実施です。 論文の再現も、社内環境への導入も行っていません。研究段階の手法であり、そのまま買える製品でもありません。
そのうえで、読みを3つ書きます。
第一に、この論文の価値は検知性能ではなく「関門を置け」という一点にあると見ています。0.0%対74.4%という差は、手法の精緻さより「本番反映の前に何かを挟んだかどうか」で説明できる幅が大きい。IFGを待たずとも、権限・ログ・認証に関わるファイルへの変更を検知して人間の承認を必須にする、というルールは今日から書けます。効果の桁は、たぶんそこで大半が決まります。
第二に、「学習データ不要」という利点は中小企業にとって本当に効くと見ています。攻撃検知の仕組みは、たいてい「まず自社のログを集めてください」から始まります。それができる会社は限られる。構造解析ベースで済むなら、その前提条件が消えます。論文のタイトルにある democratizing（民主化）は、そこを指していると読みました。
第三に、限界のうち「差分の外は見えない」が実務では一番刺さると見ています。ビルド成果物、生成されたファイル、gitignore された設定——現場のリポジトリには、差分に現れない変更経路がいくらでもあります。この手法を過信して「機械が見ているから大丈夫」となると、除外された check_in_cdk_out_directory のような穴がそのまま残ります。導入するなら、守備範囲の外側を人間側の運用で埋める設計とセットにすべきだと考えています。
AIに作業を任せる仕組みづくり全般については AIで業務を自動化する も参考にしてください。
まとめ
- git diff だけを見る監視は、成功した攻撃86件のうち11.6%（10/86、95%CI 5.7–20.3%）を見逃した（誤検知率1%時、ControlArena iac_fast）
- 何も介入しない場合、「本来のタスク成功かつ裏の妨害も成功」の同時成功率は74.4%だった（同期評価、攻撃160エピソード／条件）
- 構造解析による関門（IFG）を挟むと同時成功率は0.0%になり、正常作業の成功率は82.0%から81.0%への低下にとどまった（正常100エピソード／条件）
- ただし差分に現れない経路（gitignore された cdk.out/ 経由の攻撃）は原理的に検知できず、主要結果から除外されている。処理時間・コストの数値は論文に記載がない
- TOEではこの手法は未実施。それでも「権限・ログ・認証に触る変更は本番反映前に止める」という運用ルールなら、研究の成果を待たずに今日から書ける