AIエージェントの導入審査で、情シスは何を確認すべきか ― 承認ゲートの仕組みと限界を整理する

2026年夏 プロンプトインジェクション対策の到達点と、審査の観点

この記事の要点

AIエージェントの導入提案が、情報システム部門に回ってくるようになった。多くの提案書には「重要な操作については人間の承認を挟みます」と書かれている。この一文が実際に何を保証しているのかを、正確に理解しておきたい。

前提として押さえておくべきことがある。プロンプトインジェクションは、対策が不十分だから起きるのではない。利用者からの指示と、メールやWebページから来る信頼できないテキストが、同じトークン列としてモデルに入る。モデルの側には、どこまでが命令でどこからがデータなのかを構造的に区別する手段がない。OWASPも、確実な防止策があるかどうかは不明としている。エージェントが誤った指示に従う可能性は、ゼロにできない前提として扱うのが現実的である。

そのうえで承認ゲートを見ると、これはエージェントに実行する能力を与えたまま、実行の前に確認を挟む仕組みだと分かる。能力は与えられている。手順が挟まっているだけである。したがって審査の論点は、その手順を飛ばす経路が存在しないと言えるかどうかに移る。

この記事では、プロンプトインジェクション対策の代表的な設計を3つ紹介し、実際に起きた脆弱性の事例を1件見たうえで、導入審査で確認したい4つの観点を整理する。専門的な前提知識は必要ない構成にした。

1. なぜ「対策済み」と言い切れないのか

まず、問題の性質を確認しておく。

プロンプトインジェクションという呼び名は、SQLインジェクションと同じ形の問題だという理由でつけられた。信頼できる指示と、信頼できないデータが、同じ入力として処理されてしまう構造である。

ただしSQLと違い、こちらにはプレースホルダに相当する仕組みがない。SQLでは、値を値として扱う書き方が用意されているため、入力に命令を混ぜられても命令として解釈されない。LLMには、それに相当する構造的な分離が存在しない。ある種類のテキストに書かれた指示には従い、別の種類のテキストに書かれた指示には従わない。その区別を確実に行わせる方法は、いまだ見つかっていない。

このため、防御の主戦場はモデルの中ではなくモデルの外にある。以降で紹介する設計は、いずれも「モデルを賢くする」のではなく「モデルの周囲をどう構成するか」という発想に立っている。

審査の場では、「インジェクション対策済みです」という説明があったとき、それがモデル側の対策なのか、周囲の構成による対策なのかを分けて聞くとよい。前者だけの場合、検知をすり抜けた入力に対する備えがないことになる。

2. 承認ゲートが守るもの、守らないもの

承認ゲートは有効な仕組みである。ただし守る範囲には限りがある。

守れること。 明らかにおかしい操作が実行される前に、人間が気づいて止められる。

守りにくいこと。 ひとつは、承認画面に操作の名前しか表示されない場合である。「顧客マスタを更新します」とだけ出ていて、何がどう変わるのかが見えないなら、押した人は操作の名前に同意しただけで、結果に同意したことにはならない。

もうひとつは、承認が繰り返される場合である。これは担当者の注意力の問題ではない。Google DeepMindがCaMeLという設計を発表した論文では、確認を求められ続けた人間が何にでも同意するようになる現象を、未解決の限界として自ら挙げている。安全側に倒した設計は、ほぼ例外なく負担を人間へ移す。そして人間は摩耗する。

構造として残ること。 承認ゲートを置いても、エージェントが実行する能力を持っているという事実は変わらない。ゲートは経路の上に置かれた検問であって、経路を断つものではない。

この3点目が、以降の設計が取り組んできた課題である。

3. 防御設計はどこまで来たか

この3年の主要な設計を、3つに絞って紹介する。日本語でまとまった解説がほとんどないため、審査の際の語彙として役立つはずである。

Dual LLM（2023年） LLMを2つに分ける。ひとつはツールを呼ぶ権限を持ち、利用者のプロンプトだけを見る。もうひとつは信頼できないテキストを読むが、ツールを呼ぶ権限を一切持たない。後者が扱った内容は、参照だけが前者に渡され、中身は渡らない。汚染された文字列が計画立案に届かない構造である。

CaMeL（2025年・Google DeepMind） Dual LLMには穴があった。計画は守られても、途中で取得した値そのものが攻撃者に差し替えられれば、正しい計画のまま誤った宛先に情報が届く。CaMeLはこれに対し、データの出所をタグとして追跡し、許されない流出経路を塞ぐ。インジェクションを検知するモデルをもう一段積むのではなく、ケイパビリティとデータフロー解析という枯れた技術に寄せたところに見識がある。公開ベンチマークで、証明可能な安全性を伴って67%のタスクを解いた。

Parallax（2026年） 考える系から実行能力そのものを取り上げ、検証層を推論システムから触れなくする設計である。推論プロセスはサンドボックスの中で動き、ファイルシステムにもネットワークにもアクセスできない。提案された操作は独立した検証層が4段階で評価し、最終段が人間の承認である。著者が構成した攻撃280件に対し、既定の設定で98.9%を遮断したと報告されている。

いずれも筋の良い進歩である。ただし3つとも、最後の砦として人間の承認を置いており、提案から実行へ至る機械の経路は残している。経路が残る限り、システムの安全性は、その途中に置いた判定器の精度と等価になる。

4. 実際の事例 ― 許可リストが攻撃の条件になった

2026年に入り、この議論は具体的になった。OWASPが公開しているAIエージェントのセキュリティ報告は、前年版が起こりうる脅威のカタログだったのに対し、最新版はCVE、ベンダー勧告、侵害報告のカタログに変わっている。

審査の参考になる事例として、コーディングエージェントCursorに対して開示されたCVE-2026-22708を挙げる。

仕組みは二段構えだった。まず、シェルの組み込みコマンドの一部が、許可リストに載っていなくても、承認を求められることなく実行できた。検査そのものを素通りしていたのである。攻撃者はこれを使って実行環境の環境変数を汚染する。すると、利用者が正規に承認したコマンドが、任意コード実行の経路に変わる。

ここで注目したいのは、利用者が自分で安全だと判断して許可リストに登録した操作ほど、汚染された環境の下では確実に実行されるという点である。安全のために作られた仕組みが、条件次第で攻撃の成立条件になりうる。

発見者はあわせて、サニタイズに基づく防御は、コードが入力として想定される文脈では原理的に成立しないと指摘している。許可リストや検査による防御を評価する際は、検査を通らずに実行できる経路がないかを合わせて確認する必要がある。

5. 別の方向 ― 経路そのものを断つ

判定器の精度に依存しない構成もありうる。参考として、我々が本番環境で採っている形を紹介する。

操作を可逆性で二分する。検索と追加は取り消しがきくので可逆群、削除と更新は情報が失われるため不可逆群とする。

不可逆群について、エージェントは実行しない。かわりに操作を表すURLを返す。利用者がそれを開くと、エージェントの存在しない環境で動く仕組みが、変更前と変更後を並べて表示する。利用者が実行を選ぶと、利用者自身の認証情報で処理が走る。

エージェントが作っているのは文字列である。URLを生成することと、URLを訪問することは別の行為であり、エージェントには実行器へ至る通信経路もなく、不可逆な操作を行うための認証情報もない。

運用の中で、こういうことがあった。タスク管理の機能で、エージェントに削除の権限を与えていなかった。ある場面で追加したタスクを取り下げる必要が生じ、エージェントは、削除するためのツールが存在しないので削除できない、と報告して止まった。

これは我々の設計漏れである。必要な機能を登録し忘れていた。ただ同時に、仕組みが意図どおりに働いていることの確認にもなった。エージェントは迂回を試みず、別の操作を組み合わせて実質的な削除を行おうともしなかった。

なお、この構成にも代償がある。登録された操作しか扱えないため、登録漏れは機能不全として現れる。利用者には手間もかかる。万能の設計ではなく、汎用性と引き換えに境界を得る取引だと理解している。

6. 導入審査で確認したい4つの観点

以上を踏まえ、AIエージェントの導入を検討する際に確認しておきたい観点を4つ挙げる。ベンダーへの質問票にそのまま使える形にした。

観点1｜承認を経ない実行経路の有無 承認を拒否したとき、あるいは承認の手順を経なかったとき、そのエージェントは操作を実行できるか。実行できないとして、それは設定によるものか、構造によるものか。設定であれば、誰がその設定を変更できるか。

観点2｜承認画面に表示される情報 承認画面には、操作の名前ではなく、変更前と変更後が表示されるか。またその差分を生成しているのは何か。エージェントが生成した差分は、実際に実行される内容と食い違いうるため、差分は実行を行うコード自身が生成することが望ましい。

観点3｜制限設定の変更権限 外部への通信先を制限する設定を、エージェント自身が書き換えられるか。監査ログを消去できるか。エージェントの実行権限で変更できるなら、それは制限ではなく設定である。

観点4｜権限が拡大する仕組みの有無 承認を重ねることで、エージェントにできることが増える仕組みはあるか。あるとすれば、増える先はどこまでか。手間を減らすための機構は攻撃の目標にもなりやすいため、拡大の範囲が取り消しのきく操作に限られているかを確認しておきたい。

これらは優劣を判定するためのものではなく、提案書の一文が実際に何を保証しているかを具体化するための質問である。明快に答えられるベンダーであれば、その説明自体が設計の理解度を示す材料になる。

おわりに

本稿は、特定の製品や実装方法を推奨するものではない。この分野の到達点を整理し、審査の場で使える観点を共有することが目的である。

AIエージェントの安全性は、承認の手順をいくつ挟むかではなく、そもそも何ができない状態になっているかで決まる部分が大きい。導入の検討にあたっては、「何を承認するのか」と並べて「何ができないのか」を確認していただきたい。

ホワイトペーパー（完全版・全27ページ）

本稿はホワイトペーパー本編の要点を抜粋・再構成したものです。本編では以下を詳述しています：

エージェント防御設計の系譜 ― Dual LLM、CaMeL、Parallaxの仕組みと、それぞれが解いた問題・残した問題の全景 CaMeL論文が自ら認める2つの限界（利用者によるポリシー保守と、承認疲労）が意味すること 既存設計に残る3つの課題 ― 承認の空洞化、動的にツールを決めるエージェントへの適用限界、機械の経路が残る限り安全性が確率になる構造 可逆性による二分を、段階ではなく2つに分ける理由 分類はテナントごとの設定だが、遮断は構造であるという区別 マネーフォワード連携における実装の詳細と、現時点で言えないことの明示 摩擦の問題 ― 利用者は任せきりにしたいという前提と、この設計が構造的に応えられないこと 承認ゲート・Dual LLM・CaMeL・Parallax・本構成の対照表を含む、図表5点

ホワイトペーパー全文をダウンロード