AIエージェントのセキュリティ｜9つのリスクと6つの対策

学生時代、後輩に買い出しを頼んだことがあります。「適当に見て、良さそうなの買ってきて」と言いました。

戻ってきた後輩は、予算の倍のものを買っていました。

理由を聞くと、「先輩、良さそうなのって言ってたので」と言われました。そのとおりです。 私は良さそうの範囲を一度も言っていません。

そして後輩は、悪いことをしていません。判断を任されたので、判断しただけです。 任せた側が、任せる範囲を決めていなかった。

先に一行だけ置きます。AIエージェントとは、指示を1つずつ待つのではなく、与えられた目標に向かって自分で手順を決めて動くAIのことです。

題材は、自分で開発サイクルを回すエージェントです。目標を持ち、作業し、結果を見て、次を決める。それを人が張り付かずに繰り返します。

前置きはさておき、本題に入ります。

今日は、そのエージェントに目標そのものを書き換えさせようとして、何が起きたかという話をしていこうと思います。

① 教科書どおりに、自律の範囲を広げる

先に、AIエージェントのセキュリティを教科書どおりに整理しておきます。何が普通のシステムと違うのか、どんな攻撃があり、どこに手を打つのか。

AIエージェントのセキュリティリスクとは

AIエージェントは、目標を与えられると自分で手順を決め、道具を呼び、外の世界に触ります。このため、従来のシステムとは危険の出方が変わります。

境目は「誰が次の一手を決めるか」です。人が決めているうちは、危険な操作の手前に必ず人がいます。エージェントが決めるようになると、危険な操作が、誰にも見られないまま実行され得ます。

AIエージェントが持つ4つの危険な特性

特性	中身	何が起きるか
非決定論的	同じ入力でも、毎回同じ動きをするとは限らない	テストで再現できない不具合が残る
自律的	人の承認を挟まずに次の手を実行する	誤りが連鎖し、途中で止まらない
適応的	やりとりや結果を取り込んで振る舞いが変わる	与えた情報で、動き方そのものを誘導される
分散的	複数のエージェントや外部サービスと相互作用する	誰の指示で動いたのかが追えなくなる

従来のセキュリティ設計は、1行目を前提にしていません。「同じ入力なら同じ結果」を土台にした検証は、エージェントでは合格しても安全の証拠になりません。

攻撃対象領域（アタックサーフェス）が広がる

エージェントは、モデル本体だけでなく、指示文、参照する文書、呼び出す道具、記憶、連携先のサービスをすべて入口として持ちます。

守るべき対象が、コードの外側にあるのが特徴です。ソースコードを監査しても、読ませた文書に埋め込まれた命令は見つかりません。

なぜ検知が難しいのか｜3つの理由

• 正当な権限の範囲内で悪用される — 与えた権限で動いているため、不正アクセスとして検知されない
• 段階的に進む — 1手ずつは無害に見え、合成された結果だけが有害になる
• 内部の判断過程が見えない — なぜその手を選んだのかが記録に残っていない

1つ目が、既存の仕組みで拾えない核心です。「誰が」「どこへ」ではなく、「何のために」が判定の軸になるため、アクセス制御だけでは足りません。

リスク①｜プロンプトインジェクション（直接・間接）

指示文に割り込んで、意図しない動作をさせる攻撃です。

	経路	例
直接	利用者の入力に混ぜる	「これまでの指示を無視して…」
間接	読ませた文書・Webページ・メールに埋め込む	資料の中の白文字に命令が書かれている

実害が出やすいのは間接のほうです。社外から届くメールや、Webから取得した文書を読ませる仕組みでは、その文書自体が指示として解釈されます。外部の入力は「データであって命令ではない」と、設計で分けてください。

リスク②｜目標の操作とエージェントのハイジャック

与えた目標そのものを書き換えられると、エージェントは「正しく」別の目的を達成しにいきます。

厄介なのは、動作としては正常に見える点です。エラーも例外も出ません。目標を保持する場所は、利用者の入力が届かない側に置いてください。

リスク③｜ツール・API連携の悪用と、権限の侵害

エージェントに渡した道具は、攻撃側から見れば「使える機能の一覧」です。メール送信、ファイル削除、決済、社内データベースへの問い合わせ。

権限は人ではなくエージェントに付きます。担当者が異動しても権限が残る事故が起きるので、棚卸しの対象に加えてください。あわせて、認証やアクセス制御のなりすまし（スプーフィング）にも備えます。

リスク④｜データポイズニングとメモリポイズニング

データポイズニングは、学習や参照に使うデータに誤った情報を混ぜ込む攻撃です。メモリポイズニングは、エージェントが持ち越す記憶に嘘の前提を書き込む攻撃です。

後者は、1回の会話を超えて効き続けます。記憶を持たせる設計にするなら、何を記憶させ、いつ消すかを先に決めてください。

リスク⑤｜連鎖的な障害・リモートコード実行・過負荷

• 連鎖的な障害 — 1つの誤りが次の手の前提になり、被害が積み上がる
• リソースの過負荷 — 止まらないループで、外部APIや自社システムを叩き続ける
• リモートコード実行（RCE） — コードを実行できる道具を渡していると、任意の処理を走らせられる

2つ目は攻撃されなくても起きます。実行回数の上限と、時間の上限を必ず設けてください。

リスク⑥｜情報流出・敵対的攻撃・シャドーAI・サプライチェーン

	中身	備え
情報漏えい・不正侵入	社外に出せないデータが応答に混ざる	参照範囲と出力の検査を分けて設計する
敵対的攻撃	モデルが誤判定する入力を意図的に作られる	重要な判定はモデル単独に任せない
シャドーAI	把握されていないエージェントが社内で動く	作ってよい人と場所を決め、一覧を持つ
サプライチェーンの脆弱性	外部の部品・プラグイン・連携先が入口になる	依存関係を把握し、更新を追う

3行目が、いま最も増えています。作るのが簡単になったぶん、誰が何を動かしているか把握していない組織が増えました。

自律的な行動による、予期せぬ結果

攻撃されなくても起きる問題です。目標に対して忠実であるほど、人が想定していなかった手段を選ぶことがあります。

「やってはいけないこと」を書いていなければ、書いていないとおりに動きます。禁止事項は、指示ではなく仕組みの側にも置いてください。

対策①｜ゼロトラストと最小権限の原則

ゼロトラストは、内側からの通信であっても信用せず、都度確認する考え方です。エージェントは社内で動くため、「社内だから安全」という前提が最も危険になります。

最小権限の原則は、仕事に必要な最小限の権限だけを与えることです。「とりあえず管理者権限で動かす」検証環境が、そのまま本番になる事故が多くあります。

対策②｜認証・アクセス制御・暗号化・ネットワークの分離

• 状況に応じた認証 — 操作の重要度に応じて、確認の強さを変える
• データの暗号化 — 保存時と通信時の両方
• ネットワークの分離（マイクロセグメンテーション） — 侵入されても、届く範囲を狭くする
• 道具ごとの権限分離 — 読み取りと書き込みを、別の資格情報にする

最後の1つが、いちばん費用対効果が高い手当てです。読み取りしかできない構成なら、乗っ取られても壊されません。

対策③｜入力の検証と、出力の検証

	何を確かめるか	外せない理由
入力の検証	外部から来た文書に命令が混ざっていないか	間接プロンプトインジェクションの入口
指示文の防御	目標や制約が上書きされない構造か	目標操作への備え
出力の検証	個人情報・機密・外部送信の指示が混ざっていないか	入口を全部塞ぐことはできないため

3行目を省く設計が多く見られます。入力側の対策は、新しい手口が出るたびに追いかける形になります。出口に検査を置いておけば、想定外の入口から入られても被害が止まります。

対策④｜人の承認を挟む境目を決める

すべてを自動で通す必要はありません。外部に出る、金額が動く、契約に関わる、取り消せない。この4つのどれかに当たる操作は、人の承認を挟む形にします。

自律の範囲は、一度に全部渡さず段階的に広げてください。提案だけ→承認つき実行→限定範囲の自動実行、の順です。

対策⑤｜ログ・監視とインシデント対応の準備

• どの道具を、どんな引数で呼んだかを残す
• なぜその手を選んだかの根拠も残す
• 異常な回数・時間帯・対象を検知する仕組みを置く
• 止めるための手順（緊急停止）を決め、訓練しておく

4つ目まで用意している組織は多くありません。止め方を知らないまま動かさないでください。

対策⑥｜社内ルールと社員研修

誰が作ってよいか、どこまで自由に作ってよいかを決め、把握されていない利用（シャドーAI）を塞ぎます。

研修では、出力をそのまま使わないことを心構えではなく手順として教えてください。

責任の所在と、法規制・コンプライアンス

エージェントの判断で損害が出たとき、責任を負うのは導入した側です。この前提が、承認を挟む境目の決め方を左右します。

あわせて、個人情報の取り扱い、業種ごとの規制、データの保管国、監査に応じられる記録の有無を確認してください。コンプライアンス要件は、ツールを選ぶ前に社内側で決める項目です。

AIエージェントのセキュリティに関するよくある質問

Q. AIエージェントのセキュリティは、従来のシステムと何が違いますか。
4つの特性が違います。非決定論的（同じ入力でも同じ動きとは限らない）、自律的（人の承認を挟まず次の手を実行する）、適応的、分散的。とくに1つ目のため、「同じ入力なら同じ結果」を前提にした検証が合格しても、安全の証拠になりません。

Q. AIエージェント固有の攻撃には、どんなものがありますか。
プロンプトインジェクション（直接・間接）、目標操作とハイジャック、ツールやAPI連携の悪用、データポイズニング、メモリポイズニング、権限侵害、認証のなりすまし、リモートコード実行、連鎖的な障害と過負荷です。実害が出やすいのは間接プロンプトインジェクションで、読ませた文書自体が指示として解釈されます。

Q. なぜ既存のセキュリティ製品では検知しにくいのですか。
与えた権限の範囲内で悪用されるため、不正アクセスとして検知されないためです。あわせて、1手ずつは無害に見える段階的な進み方、判断過程が記録に残らないことも理由になります。

Q. まず何から手をつければよいですか。
最小権限の原則です。読み取りしかできない構成なら、乗っ取られても壊されません。次に出力側の検査を置きます。入口を全部塞ぐことはできないため、出口に検査があるほうが確実です。

Q. どこまでを人の承認なしで実行させてよいですか。
外部に出る、金額が動く、契約に関わる、取り消せない。この4つのどれかに当たる操作は、人の承認を挟んでください。自律の範囲は一度に渡さず、提案だけ→承認つき実行→限定範囲の自動実行、の順で広げます。

Q. 社内で勝手に作られたエージェントが心配です。
シャドーAIと呼ばれる状態です。作ってよい人と場所を決め、動いているものの一覧と保守の担当を持ってください。禁止の通知だけでは、把握できない場所へ移るだけです。

エージェントの教科書には、こう書いてあります。人が介在する回数を減らすほど、価値が出る。

そのとおりに広げていきました。

→ 作業を選ぶのを任せる
→ 順番を決めるのを任せる
→ やり直すかどうかを任せる

どれも、うまく動きました。

そして最後に残ったのが、目標そのものです。状況が変われば、目標も更新されるべきです。そこも任せてみることにしました。

仕組みはこうです。エージェントが「目標をこう書き換えたい」と提案する。理由と、根拠と、その提案にどれだけ自信があるかを添えて出す。 自信が高く、根拠がしっかりしていれば、人の承認なしで適用する。

ここまでは、教科書どおりです。
任せた範囲を数で置くと、こうです。作業の選択、順番の決定、やり直しの判断の3つ。 ここまでは事故がありませんでした。

任せたもの	期間	事故
作業の実行	3か月	0件
順番の決定	2か月	0件
やり直しの判断	1か月	0件

ここまでが、AIエージェントのセキュリティの教科書どおりの整理です。特性を押さえ、攻撃を並べ、権限を絞り、入口と出口に検査を置く。設計の指針としては、ここに出そろっています。

この記事の後半で扱うのは、その先です。これらの手当てを施したうえで、エージェント自身の報告を、何かの判定に使っていないか。

② そのとおりに動かして、存在しない根拠が出てくる

動きました。提案も出ます。理由も書いてあります。

ところが、提案に添えられた根拠を確かめたところ、引用されている見出しが、どこにも存在しませんでした。

存在しない見出しを、それらしい名前で引用してきていました。

そして、その提案には「確信度は高い」と書いてありました。

指示は出していました。 根拠を引用せよ、と。引用はされています。 ただ、引用先が無い。

③ そして、自己申告を判定に使っていたと気づく

構造を見直して、はっきりしました。

私は、エージェントが書いた文字を、判定の材料にしていました。

→ 確信度 → エージェントが書く
→ 根拠 → エージェントが書く
→ 適用するかの判定 → その2つを見て決める

判定の入力を、判定される側が全部握っています。
握られていた項目は3つでした。確信度、根拠、そして提案の内容そのものです。

さらに悪いものが見つかりました。理由の本文の中に、行頭で「確信度は高い」と書けば、それが拾われる経路がありました。つまり、本来の欄に低い値を書いておいて、本文で上書きできる。

エージェントが悪意を持っていたわけではありません。そういう抜け道が構造として空いていた、というだけです。
抜け道は2つありました。存在しない見出しを引用する経路が1つ、確信度を本文から上書きする経路が1つ。 どちらも指示では塞げません。

握られていた判定材料は3件でした。確信度、根拠、提案の内容です。このうち機械で検証できるのは根拠の1件だけで、残り2件は検証する術がありません。

④ 原因は「信頼境界がモデルの内側にあった」こと

原因を一つに絞ると、これでした。

信頼できる領域と、信頼できない領域を分ける線が、モデルの内側に引かれていました。

モデルの出力は、信頼できない領域から来るデータです。にもかかわらず、私はそれをそのまま判定に使っていました。

後輩の買い出しと同じです。「良さそう」の判定を後輩に任せた時点で、予算の線は消えています。

⑤ 直してみる — 安全弁を、直列に7つ置く

やったことは、条件を順番に通す形にしたことです。どれか一つではなく、全部を直列に置きます。

→ 1. 利用者による一時停止が入っていたら、自律適用しない
→ 2. 対話モードで動いているときは、自律適用しない
→ 3. 立ち上げ直後は適用しない（判断の材料が溜まっていない）
→ 4. 確信度が最高でなければ適用しない
→ 5. 根拠として引用された見出しが実在するかを検証する
→ 6. 既存の目標を含まない全置換の提案は拒否する
→ 7. 連続で自律適用した回数に上限を置き、クールダウンを入れる

5番が本体です。

引用された見出しを、実際の文書の見出し一覧と文字列で突き合わせます。 一致しなければ、確信度を強制的に下げる。そして、中身が空の見出しは一覧に入れません。 ひな形として置いてあるだけの空セクションを、根拠として認めないためです。

さらに、解析を先勝ちに変えました。 最初に出てきた値を採用し、本文中の後出しで上書きできないようにする。③で見つけた抜け道は、これで塞がっています。
7条件を入れた後の実測です。自律で適用された提案は10件中2件、残り8件は5番目の根拠検証で止まりました。 止まった8件のうち、5件が存在しない見出しの引用でした。

⑥ あとで知った — この誤りには、38年前の名前がついていた

素朴な対処のつもりでしたが、調べると同じ構造には、古い名前がありました。

混乱した代理人（Confused Deputy）です。1988年にノーム・ハーディが発表した論文で、コンパイラが、利用者側のプログラムから渡されたファイルパスを信じたために、課金ファイルを上書きしてしまったという事例が語られています。

定義はこうです。権限を持つプログラムが、より権限の低いプログラムに騙されて、自分の権限を誤って使ってしまう。

そして、なぜそうなるかも書かれています。代理人の側に、応じるべき要求と拒否すべき要求を区別するだけの文脈や安全策が無いからです。

エージェントは、まさにこの代理人です。

私のエージェントは、目標を書き換える権限を持っていました。そして、その権限を使ってよいかどうかの判断材料を、自分の出力から受け取っていました。 権限は正しく与えられている。使ってよい場面かどうかを、区別する手段が無かった。

ハーディは、さらに踏み込んだ問いを立てています。代理人が、与えられた権限をその目的のためだけに使い、他の目的へ誘導されないためには、どういう構造が必要か。

答えとして挙げられているのが、指名（どの資源か）と認可（何をしてよいか）を分離しない設計です。アクセス制御の一覧で守る方式ではこの問題は防げず、権限そのものを持ち回る方式なら防げる、と整理されています。

私が7つの条件を直列に置いたのは、この分離を手作業でやり直していたことになります。

新しい理屈は、ひとつも要りませんでした。
ハーディはこうも書いています。「代理人は、与えられた権限をその目的のためだけに使えるか」。ここで問われているのは能力ではなく構造です。ただし、当時の答えは「指名と認可を分離しない設計」でした。

記録に残っている実例

安全弁をどこに置くかは、開発中のツールの決定記録に残っています。

2026年2月2日の決定。 批評役が `needsClarification: true` を出すと、実行がそこで止まって人の入力を待ちます。状態はこう動きます。

“`
running → waiting_for_human → queued → running → done
“`

止めるのは、モデルの判断ではなく状態機械です。 質問は保存され、あとから追えます。

2026年2月3日の決定。 止まったままの実行を検出する閾値は、既定で10分。ただし、自動では失敗にしません。 理由が書かれています。「自動失敗は誤検知になりうる」。 警告を出して人に見せるところで止める、という線の引き方です。

2026年5月8日、再開時に道具を検証し直す処理を足しました。中断前に使えた道具が、再開時にも同じように使えるとは限らないためです。再開は、続きではなく、確かめ直しから始まります。

⑦ 何が変わったか

指示で縛るのをやめました。

“`
前：プロンプトに「必ず実在する根拠を引用せよ」と書く
後：実在しない根拠は、構造的に通らないようにする
“`

指示は、守られることもあれば守られないこともある提案です。 検証は、守られなければ止まります。

⑧ 現場で使うなら、この2枚

表1：エージェントの出力を、判定に使ってよいか

出力	判定に使ってよいか	代わりに何を見るか
確信度の自己申告	使ってはいけない	根拠の実在性
根拠として挙げた参照先	そのままは不可	実在するかを文字列照合
作業の完了報告	不可	成果物の有無を機械で確認
提案の内容	内容は使う	適用の可否は別の条件で決める

「使ってはいけない」の行を、そのまま設計に写してください。

表2：自律の段階（一度に全部を渡さない）

段階	任せるもの	人が持つもの
1	作業の実行	何をやるか
2	順番の決定	目標
3	やり直しの判断	目標
4	目標の更新提案	適用の可否
5	目標の適用	7条件を全部通ったときだけ

運用では、次の5件に名前を付けて配りました。名前が付くと、会議の中で指差せるようになります。

1件目、「自己申告は、判定材料にしない」。 確信度も根拠も、エージェント自身が書けます。そこを見て通す設計は、判定しているように見えて何も判定していません。

2件目、「信頼境界は、モデルの外に置く」。 内側に置いた境界は、内側から書き換えられます。7段の安全弁も、1段目が内側にあれば意味が薄くなります。

3件目、「根拠は、文字列として実在を確かめる」。 引用された箇所が原文に存在するかを、機械が突き合わせます。存在しなければ、内容の妥当性を見るまでもなく落とします。

4件目、「検証できない提案は、構造的に通らないようにする」。 禁止を書くのではなく、通り道を作らないという形にします。

5件目、「確信度が高い提案ほど、機械で殴る」。 自信のある書き方は、通しやすさを上げるだけで、正しさとは無関係です。

この5件は、1枚に印刷して配れる分量に収めています。増やすと、誰も覚えません。

⑨ この考え方が効き続ける理由

モデルは、これからも賢くなります。それでも、この問題は消えません。 賢さの問題ではなく、判定の入力を判定される側が握っているという構造の問題だからです。

→ 賢くなる → もっともらしい根拠を書けるようになる
→ もっともらしい → 人が読んでも気づけなくなる
→ 気づけない → 機械で照合するしかない
運用してからの数字も置いておきます。7条件のうち実際に発動したのは4条件、残り3条件は一度も発動していません。 発動しない条件を消すべきかは、まだ判断していません。

賢くなるほど、自己申告は使えなくなります。

そして、この設計には副産物がありました。エージェントの提案が、読みやすくなりました。 実在する見出ししか引用できないので、提案が必ず既存の文書に接続されるからです。

ただし、正直に書いておきます。7つの条件は、いま全部が必要かどうか分かっていません。 事故が起きるたびに1つずつ足した結果なので、重複しているものがあるはずです。減らす作業は、まだできていません。

条件を足した経緯も残しています。最初は2件、事故のたびに1件ずつ増えて7件になりました。実際に発動したのは4件で、残り3件は一度も発動していません。減らす作業は、まだ手をつけていません。

関連して、プロンプトインジェクションをツール層で止める話と、AI駆動開発で自作基盤とネイティブ機能を分ける話を別に書いています。AIエージェント導入でつまずく場所話はすでに公開しています。あわせて読むと、同じ判断が別の場所でも効いていることが分かると思います。

この判断を実際の案件で使う場面については、AIエージェント開発のページに整理しています。

---

自分で決めていい、といえば、夏休みの計画を自分で立てさせてもらった年があります。

8月30日に、全部やりました。 裁量は、範囲を決めてから渡すものだと思います。

以上です。