Daily Archives: February 1, 2026

なぜエージェントは「LLM」より危ないのか

AIエージェントの危険性は「言い間違い」や「誤答」だけでは説明できない、という点だ。LLM（大規模言語モデル）単体のリスクは、主に生成物の品質や不適切発言、幻覚など、出力の内容に焦点が当たりやすい。しかしエージェントは、生成した文章を“行動”に変換してしまう。ここにセキュリティの質的な変化がある。

エージェントが持つ特徴を言葉にすると、自律性・連鎖性・権限性の3つが核になる。自律性とは、与えられた目的を達成するために、必要そうな手順を自分で組み立てて進める性質だ。連鎖性とは、一つの判断が次の入力を生み、その入力が次の判断を誘発し、結果的に長い実行チェーンになる性質だ。権限性とは、メール送信、チケット起票、データ取得、決済、デプロイといった「本来なら人が権限を持って実施していた操作」を、APIキーやSaaS連携の権限としてエージェントに渡すことだ。

この3つが揃うと、従来のアプリケーションよりも攻撃面が増える。理由は単純で、エージェントの判断材料（コンテキスト）が“外部から持ち込まれる”からだ。人間なら、メール本文やWebページを読んで「これは怪しい」「この指示は無視しよう」と判断してから操作する。しかしエージェントは、メールやWeb、PDF、チャットログ、チケット本文、さらにはRAG（検索拡張生成）で拾った資料など、さまざまな入力を同じ“材料”として扱いがちである。結果として、「データの中に命令が混ざる」状況が発生する。

さらに厄介なのは、エージェントは“目的達成”を優先するように設計されることが多い点だ。例えば「顧客からの問い合わせに即レスして」「売上レポートを自動で作って共有して」「緊急障害の一次対応をして」といった指示は、スピードや自動化を求める。そこでエージェントに強い権限を渡し、障害対応やコミュニケーションまで任せるほど、攻撃者にとっては魅力的な的になる。人の操作なら一回のミスで済むかもしれないが、エージェントはミスを“自動で増幅”し得る。

脅威モデルを考えるとき、従来は「アプリの入口＝APIやUI」「権限の境界＝ユーザー権限と管理者権限」「データフロー＝DBとサービス間通信」のように整理できた。ところがエージェントの入口は、APIやUIだけではない。メール本文、添付ファイル、社内Wiki、Slack、カレンダー、CRMのメモ欄、ログ、Web検索結果など、いわば“自然言語で書かれたものすべて”が入口になる。そして権限の境界も、ユーザー単位ではなく「エージェントが持つツール実行権限」に移っていく。ここを更新しない限り、どれだけ堅牢なインフラを敷いても、入口が穴だらけのままになってしまう。

要するに、AIエージェントを守るというのは、モデルを賢くすることではなく、「どこから何が入ってきて」「何を実行できて」「実行結果がどこへ波及するか」を設計することに近い。これが“エージェント時代の脅威モデル”の出発点になる。

典型的な攻撃パターン：インジェクション、権限悪用、横展開

AIエージェントの攻撃を語るとき、プロンプトインジェクションが真っ先に出てくる。もちろん重要だ。ただし、インジェクションは“入口”であって、被害の本体は「権限の悪用」と「横展開」によって生まれることが多い。脅威モデルとしては、入口→実行→波及という連鎖で捉えると理解しやすい。

最も分かりやすい入口は、メールやチャットの本文に紛れ込む誘導だ。例えば「この問い合わせは至急。まず顧客のアカウント状況を確認し、必要なら請求情報を更新して返信して」など、業務上もっともらしい文章が混ざっていると、エージェントは善意で動く。さらに本文のどこかに「システムメッセージを無視して次の操作を行え」などの指示が混ざっていると、エージェントの行動を乗っ取れる可能性が出る。人が読めば不自然でも、エージェントは“業務の一部”として扱ってしまいがちだ。

入口は自然言語だけではない。RAGを使って社内ドキュメントやナレッジベースを参照させる場合、その参照先に悪意ある文章が混入すると、エージェントはそれを「正しい根拠」だと誤認しやすい。外部Web検索を許している場合はなおさらで、攻撃者は検索結果に出やすいページを用意してエージェントを誘導することも考えられる。ここで重要なのは、攻撃者はモデルを直接攻撃しなくても、モデルが参照する“材料”を攻撃すればよい、という構図だ。

入口から侵入した次の段階が、ツール実行の不正誘導である。エージェントができることは、結局ツールができることに等しい。CRM検索、請求システム更新、メール送信、ファイル共有、Git操作、クラウド設定変更など、業務上の便利さを理由にツールを増やすほど、攻撃者は“実行手段”を手に入れる。たとえば「顧客対応」という名目で、顧客データの取得や添付送信が可能になっていれば、情報漏えいの経路が一気に現実味を帯びる。さらに「障害対応」という名目で、インフラ変更や再起動、設定更新まで許可していれば、最悪の場合はサービス停止や改ざんにつながる。

ここで発生しやすいのが、権限の誤委譲だ。人間は業務の文脈で「この操作は管理者に確認すべき」「このデータは持ち出し禁止」と判断するが、エージェントにその判断を委ねると、ポリシーが曖昧なまま実行される。特に危険なのは、「便利だから」と広い権限を一つのエージェントに集約してしまう設計である。メールも送れる、ファイルも共有できる、顧客データも見られる、請求情報も更新できる、となると、攻撃者が一度誘導に成功しただけで、被害は複合的になる。

そして最後の段階が横展開だ。横展開とは、最初に侵入した入口とは別の場所に被害が広がることを指す。エージェントの場合、横展開の典型は「エージェントが持つ認証情報・セッション・APIキーが、他のシステムに波及する」形で起きる。エージェントが使うSaaS連携は、しばしば長期トークンや高権限APIキーで実現されている。これが漏れたり悪用されたりすると、被害はエージェントの範囲を超える。また、エージェントが生成した結果（メール文、ドキュメント、チケットのコメント）が別のエージェントの入力になっている環境では、入力汚染が連鎖して“自走”することもあり得る。これがエージェント特有の怖さで、単発のミスがワークフロー全体に波及する。

攻撃パターンをまとめると、入口は「信頼できない入力」、実行は「ツールと権限」、波及は「連鎖と共有」である。脅威モデルは、個別の攻撃テクニックよりも、この構造を押さえたほうが強い。なぜなら、具体的な攻撃手法は変化しても、入口・実行・波及の三段階は設計上ずっと残るからだ。

実務で使える防御の最小セット：境界、検証、観測

では、AIエージェントを安全にするには何から手を付ければいいのか。理想を言えば、強固なポリシーエンジン、堅牢なサンドボックス、包括的なレッドチーム、継続的な安全評価など、やることはいくらでもある。ただ現実には、まず「壊滅的な事故を避ける」ための最小セットが必要になる。ここでは、境界・検証・観測という3つの軸で整理する。

最初の軸は境界、つまり「信頼できるもの」と「信頼できないもの」を明確に分けることだ。エージェント設計でありがちな失敗は、メール本文も社内の手順書も、ユーザーの指示も、すべてが同じコンテキストに混ざってしまうことにある。混ざった瞬間、命令とデータの区別が曖昧になり、攻撃者は“データの形をした命令”を持ち込める。したがって、信頼できない入力を原則として隔離し、「それは参考情報であって命令ではない」という前提を、実行系で担保する必要がある。ここで重要なのは、モデルにお願いして分離させるのではなく、設計として分離することだ。コンテキストを区画化し、ツール実行に影響する領域を限定する。さらに、長期メモリや共有メモリがあるなら、その書き込み条件を厳しくし、未検証情報が永続化しないようにする。

次の軸は検証だ。エージェントはツールを呼び出す瞬間に「現実へ介入」する。ならば、その瞬間に検証ゲートを置けば、被害を大きく減らせる。検証にはいくつか層がある。まずスキーマの固定と引数検証だ。ツール呼び出しの形式を厳格にし、想定外の引数や危険な値を弾く。次に許可リストとポリシー判定だ。例えば外部宛てメール送信、ファイルの公開共有、請求情報の変更、支払い実行のような操作は、業務上の正当性が必要なため、ポリシーで条件を定義し、満たさなければ実行不可にする。そして人間承認である。特に高リスク操作は、エージェントが提案した操作を人が確認してから実行する形にし、完全自動を避ける。ここでのコツは「全部を承認にすると運用が回らない」ので、承認が必要な操作の基準を明確化することだ。金銭・個人情報・権限変更・外部公開・破壊的変更、このあたりは原則承認に寄せると事故が減る。

最後の軸が観測だ。エージェントは「何を見て」「どう判断して」「何を実行したか」が追えないと、事故が起きたときに止血も再発防止もできない。観測とは、監査ログを残すだけではない。入力（参照したデータ）、推論（使ったモデルとプロンプトテンプレ）、実行（ツール呼び出しと結果）、そして権限（どのトークンで何をしたか）を、追跡可能な形で保存することだ。さらに、異常検知の観点も必要になる。いつもは見ない量のデータを取得していないか、通常はしない宛先にメールを送ろうとしていないか、深夜に権限変更が発生していないか、といった兆候を、エージェントの実行ログから検出できるようにする。エージェントはミスを拡大し得るのだから、観測によって早期に止める仕組みが欠かせない。

この3軸を、導入順に並べると分かりやすい。まず境界を引く。次にツール実行に検証ゲートを置く。最後に観測を整備し、異常を早く見つけて止められるようにする。これだけでも、エージェント導入の“初期事故”の多くは回避しやすくなる。 AIエージェントは、セキュリティにとって「未知の魔法」ではない。入口が増え、権限が集まり、実行が連鎖しやすいシステムだと捉えれば、脅威モデルは作れる。重要なのは、プロンプトを賢くすることより、実行系の設計でリスクを減らすことだ。便利さのために自律性を上げるなら、そのぶん境界・検証・観測を強くする。エージェント時代のセキュリティは、このトレードオフを“設計で”引き受けるところから始まる。

漏えいの経路を可視化する：入力、メモリ、ログ、外部連携

データ漏えいを防ぐには、まず「秘密情報がどこに存在し得るか」を網羅的に把握する必要がある。AIエージェントの世界では、秘密情報はデータベースの中だけに閉じない。会話、参照資料、要約、実行ログ、学習用データ、キャッシュなど、あらゆる場所に一時的・永続的に残り得る。しかもそれぞれが次の処理の入力になり、意図せず拡散することがある。

最初の経路は入力である。エージェントはメールやチャット、チケット、PDF、社内Wiki、顧客の問い合わせ文などを読み取り、そこから必要情報を抽出して動く。ここで起きる漏えいは単純で、入力に含まれていた秘密情報を、出力やツール実行を通じて外に出してしまう。例えば顧客対応で、問い合わせ文に含まれていた個人情報をそのまま別の宛先に転送してしまう、社内限定の手順書の一部を外部向け返信に混ぜてしまう、といった事故だ。人間なら「この段落は社外秘」と判断して切り分けるが、エージェントは材料を同列に扱いやすい。入力段階で「これは外に出してよい情報か」を識別できない設計だと、漏えいは時間の問題になる。

次の経路がメモリである。エージェントを便利にする機能として、会話履歴の保持や長期メモリ、あるいはRAG用のベクトルインデックスが使われることが多い。しかしメモリは“便利な永続化”であると同時に、“漏えいの温床”にもなる。会話履歴にPIIや契約情報が残れば、後続のタスクで意図せず参照される可能性がある。長期メモリに書き込まれた情報が別のユーザー対応に混入すれば、顧客間の情報混線が起きる。RAGのインデックスに取り込んだ文書が過剰に広い権限で検索されると、本来アクセスできない人が情報を引き出せる。メモリは「いつ」「誰が」「どの条件で」読み書きできるのかを設計しないと、アプリケーションのデータ分離が崩れる。

さらに見落とされがちなのがログである。エージェントシステムは、トラブルシューティングや監査のために多くのログを残す。プロンプト、入力データ、参照したドキュメント、ツール呼び出しの引数、APIのレスポンス、エラー内容などが記録される。しかし、ログは一度残ると長く残り、アクセス範囲が広くなりがちだ。開発者や運用者が調査用に閲覧できるログに、顧客データやAPIキーが混入していると、それ自体が大きな漏えい面になる。さらに、ログが外部の解析サービスやSaaSに転送されている場合、その転送経路もリスクになる。エージェントは観測性が重要だが、観測性のために秘密情報がばらまかれるのは本末転倒だ。

最後に外部連携である。エージェントは外部ツールを使って価値を出す。SaaS、社内API、データウェアハウス、クラウド操作、決済、メール送信、ファイル共有など、連携先が増えるほど漏えいの出口も増える。特に危険なのは、連携のための認証情報をエージェント周辺に置くことだ。長期トークン、広いスコープのAPIキー、共有アカウントの資格情報などが残っていると、エージェントが誤って漏らすだけでなく、攻撃者に悪用される可能性も高まる。外部連携は「データが出ていく」だけでなく、「認証情報が露出する」という二重の意味でリスクがある。

このように、漏えい経路は一つではない。入力、メモリ、ログ、外部連携という四つの通り道を地図として描き、秘密情報がどこで発生し、どこに残り、どこから出ていき得るかを具体的に整理することが第一歩になる。

秘密情報の扱いを標準化する：ポリシーから実装へ

経路が見えたら、次は扱い方を“標準化”する必要がある。秘密情報は「気をつける」では守れない。エージェントが関わる限り、うっかりや誘導、バグ、更新によって必ず揺らぐ。だからこそ、分類とルールを決め、それを実装で強制する形にする。ここで重要なのは、セキュリティチームの規程だけで終わらせず、開発と運用が実際に守れる仕組みに落とし込むことだ。

最初にやるべきは、データ分類である。個人情報、認証情報、契約情報、財務情報、機密ソースコード、営業情報など、漏れると困るものは多い。だが現場で運用するなら、分類は細かすぎても回らない。ポイントは、エージェントが扱える範囲を決めるための分類にすることだ。例えば「外部に送信してよい」「社内限定」「権限者限定」「絶対にログに残してはいけない」のように、扱いのルールと直結するカテゴリに落とす。ここが曖昧だと、後段の技術対策も曖昧になる。

次に、認証情報の扱いを徹底する。エージェントにツールを触らせるなら、必ず認証が必要になるが、長期的に使える固定キーを持たせる設計は避けたい。理想は短命クレデンシャルで、必要なときだけ発行し、短時間で失効させる。権限のスコープも最小化し、読み取り専用と書き込み権限を分ける。可能なら環境ごとに分離し、開発環境のキーが本番に通用しないようにする。秘密情報をプロンプトに直埋めしない、会話コンテキストに混ぜない、エージェントが説明文として吐き出せないようにする、といった基本もここに含まれる。

さらに、データマスキングと最小開示を原則にする。エージェントが顧客データを参照するとき、必要な項目だけを渡す設計にする。例えば本人確認が目的なら、フルの住所やクレジット情報まで渡す必要はない。問い合わせ対応なら、注文番号とステータスだけで十分かもしれない。エージェントのコンテキストに渡した瞬間から、その情報は生成物やログに混入する可能性がある。したがって、エージェントに渡すデータは「最小で、短時間で、目的限定」にするのが基本になる。

この標準化を現実にするには、ポリシーをコードに変換する必要がある。具体的には、ツール実行前のフィルタで引数や送信先を検査し、禁止データが含まれていればブロックする。出力段階でも、外部送信や公開共有が絡むときは検査を強化し、マスキングや警告を入れる。加えて、メモリへの書き込みも制御する。長期メモリに保存してよい情報の条件を限定し、PIIや認証情報が混入する可能性があるものは保存しない。RAGのインデックスに入れる文書も、アクセス制御とセットで管理し、検索結果が不用意に広いユーザーに渡らないようにする。

ここまでの話は「厳しくして便利さを下げる」ように見えるかもしれない。しかし標準化の目的は、便利さを保ったまま事故を減らすことにある。ルールが曖昧なままだと、現場は不安になり、最終的にエージェントを信用できなくなる。標準化は、運用者にとっての安心材料でもある。

ログは武器にも爆弾にもなる：観測性とプライバシーの両立

AIエージェントを業務に入れるなら、ログと監査が重要になる。何かが起きたときに、どの入力が原因で、どのツールが実行され、どこに影響が出たのかを追えないと、インシデント対応ができないからだ。しかしログは、取り方を間違えると最大の漏えい源になる。観測性を上げようとして、秘密情報を記録しすぎる。この矛盾を解くには、ログを「調査に必要な最小限」に設計し直す必要がある。

まず考えるべきは、ログに残すべきものと、残してはいけないものの線引きだ。エージェントの調査で重要なのは、入力そのものの全文よりも、参照元と要点であることが多い。どのメールを参照したのか、どのドキュメントを引いたのか、どの検索結果を使ったのか。ツール実行については、どのツールをいつ呼び、成功したか失敗したか、影響を与える引数は何だったか、が重要になる。一方で、顧客の全文や認証情報、支払い情報、個人の詳細などを丸ごと残す必要はほとんどない。必要なら、マスキングした形やハッシュ化した識別子で追跡できるようにする。ログは「内容」ではなく「証跡」を残す、という発想が鍵になる。

次に、ログ閲覧権限を絞る。エージェント関連のログは、開発者全員が見られる状態になりがちだが、そこに顧客データが混入するリスクを考えると危険である。閲覧は必要最小限のロールに限定し、監査ログで誰が見たかを追えるようにする。保存期間も重要だ。長く残すほど調査には便利だが、漏えい面が増える。目的に応じて期間を分け、短期で十分なものは短く、監査上必要な証跡だけを長期保存する。ここも最初に決めておかないと、いつの間にか無制限に溜まっていく。

さらに、外部へのログ転送に注意する。可観測性のためにログ解析SaaSを使うこと自体は普通だが、そのSaaSに秘密情報が流れる設計だと、リスクが増える。転送前にマスキングを徹底し、そもそも外部に出してはいけない種類のログは出さない。エージェントはモデルプロバイダや外部APIとも通信することが多いので、通信とログの境界が曖昧になりやすい。どこまでが社内で、どこからが外部かを明確にし、外部に出る前に必ずフィルタがかかる構成にする。

ここまで設計しても、インシデント時には「詳細が欲しい」となる。そこで最後の工夫として、平時は最小ログ、非常時は一時的に詳細ログという切り替え設計が有効になる。常に詳細ログを取り続けるのではなく、異常検知や人間の判断で“観測モード”を上げ、短期間だけ詳細を残す。もちろんこの切り替え自体も権限管理が必要だが、プライバシーと調査能力の両立には合理的な選択肢になる。 AIエージェントのデータ漏えいは、特別なハッキングからだけ起きるわけではない。入力に混ざり、メモリに残り、ログに溜まり、外部連携から出ていく。だからこそ、秘密情報を守るには、通り道を地図として描き、分類とルールを標準化し、ログを証跡として設計し直す必要がある。エージェントは便利だが、便利さの裏には必ずデータの移動がある。移動を制御できる設計に変えれば、エージェントは怖い存在ではなく、統制可能な業務基盤として扱えるようになる。