分割攻撃とは｜AIエージェントの安全を破る新手口

研究・論文

有害な依頼を「一つひとつは無害な小さな作業」に分けてAIエージェントに渡すと、安全機構をすり抜けて結果的に危険な目的が達成されてしまう——。この分割攻撃（Decomposition Attack）を体系的に測る新しいベンチマーク「DECOMPBENCH」を提案した研究が、2026年6月にarXivで公開されました。本記事は査読前のプレプリントに基づく解説です。結論を先に言えば、「単発の有害指示は断れるAIでも、分割されると断れない」という弱点が改めて示されており、社内で生成AIやAIエージェントを使い始めた組織にとって見過ごせない論点です。

この記事でわかること

  • 分割攻撃とは何か、なぜ既存のガードレールをすり抜けるのか
  • 研究（DECOMPBENCH）が示した「単発」と「分割」の拒否率ギャップ
  • 社内でAIエージェントを導入する情シスが取るべき視点と、公的指針へのつなぎ方

分割攻撃とは何か

分割攻撃とは、本来であればAIが拒否するはずの有害なタスクを、個別には無害に見える複数のサブタスクに分解して実行させ、最終的に有害な成果物を組み立てる攻撃手法です。たとえば、ある危険な手順を「一般的な化学の質問」「ありふれた調達方法の質問」「文章の整形依頼」のように切り分けると、各ステップ単体ではフィルタに引っかからず、しかし全部をつなげると元の有害な目的が達成されてしまう、という構図です。

従来のジェイルブレイク（安全機構の回避）が「特殊な呪文のようなプロンプト」でモデルを騙そうとしたのに対し、分割攻撃は奇妙なプロンプトをまったく使わず、ごく自然な業務依頼の積み重ねで成立する点が厄介です。入力・出力フィルタは「いま目の前にある1ターン」しか見ていないことが多く、全体の文脈（最終的に何を作ろうとしているか）を把握できないことが根本的な弱点になります。

なぜAIエージェントで深刻になるのか

AIエージェントとは、人間の細かい指示を待たずに、目標達成のためツールを呼び出しながら多段階のタスクを自律的に進めるAIシステムを指します。エージェントはまさに「大きな目標を小タスクに分解して順番に実行する」ことを得意とするため、攻撃者が分解の手間をかけなくても、エージェント自身が有害な目的を無害そうな手順へと“親切に”分解・遂行してしまうリスクがあります。自律性とツール実行能力が高まるほど、被害は「不適切な文章の生成」にとどまらず、実際の操作（情報収集・送信・コード実行など）に及びかねません。

研究（DECOMPBENCH）が示したこと

今回のプレプリント（Kothamasuら、2026年6月公開）は、分割攻撃に対する安全性を測るための評価フレームワークDECOMPBENCHを提案しています。グラフ構造を使った「分解前提（decomposition-by-design）」の設計により、有害なタスクを現実的なワークフローの形で、個別には無害な実行可能サブタスクへと体系的に変換する点が特徴です。データセットはHugging Faceで公開されているとされています。

主要な結果は明快です。最新のエージェントは「ひとかたまりの有害タスク（monolithic）」に対しては高い拒否率を保つ一方で、それを分割した変種に対しては拒否率が大きく下がり、意図せず有害な目的を完遂してしまうケースが多い、というものです。つまり安全評価を「単発の有害指示を断れるか」だけで行うと、現実の脅威を見落とすことになります。

観点 単発の有害タスク 分割された有害タスク
見た目 明らかに危険 各ステップは無害に見える
AIの拒否率 高い（断りやすい） 低下（通してしまう）
必要なテクニック 特殊なプロンプトが必要なことも 自然な業務依頼の連続で成立
検知のカギ その場の入出力で判定可能 会話・行動の全体文脈が必要

この研究の限界（査読前である点）

重要な前提として、本論文はarXivのプレプリントであり、現時点で査読を経たものではありません。結果や数値は今後変わりうるため、断定的に受け取るべきではありません。また本研究の主眼は「攻撃の評価（ベンチマーク）」であり、実運用にそのまま使える防御策が確立されたわけではない点にも注意が必要です。1本の論文を過度に一般化せず、「分割攻撃という脅威が定量的に確認されつつある」という事実として押さえるのが妥当でしょう。

情シス目線での率直な所感

現場感覚で言うと、これは「対策しづらさ」が際立つ問題です。従来の不正検知は「怪しい1リクエスト」を捕まえる発想で組み立てられていますが、分割攻撃は一つひとつが“正常な業務利用”にしか見えないため、ログを眺めても異常として浮かび上がりにくい。社内のAI利用が増えるほど、限られた人員で全ての会話文脈を追うのは現実的に不可能です。このもどかしさは、エンドポイントの細部まで目が届かない端末管理の悩みとよく似ています。

さらに悩ましいのは、悪意ある人間だけが脅威ではない点です。善意の従業員が、業務効率化のつもりで何気なくタスクを小分けにしてエージェントに任せた結果、機密情報の外部送信や不適切な処理が“事故として”起きる可能性もあります。つまりこれは「攻撃対策」であると同時に「利用ルールと教育」の問題でもある、というのが正直な実感です。

情シスは何をすべきか（公的指針へのつなぎ方）

では現場は何から手を付けるべきでしょうか。単純な答えは「AIを単発の入出力ではなく、行動の連なり（文脈）として監視・統制できる体制に寄せていく」ことです。とはいえ自前で巨大なチェックリストを作る前に、まずは公的機関の整理された指針を出発点にするのが効率的です。

そのうえで実務の勘所を一言だけ添えると、(1) エージェントに与えるツール権限・データアクセスを最小化する、(2) 一連の操作を後から追えるよう行動ログを残す、(3) 「機密情報は入力しない」「重要操作は人間が承認する」といった利用ルールを定め、地道に周知・教育する——この3点が現実的な第一歩です。技術的な防御（会話の流れ全体を見る軽量モニタの研究なども進んでいます）に過度に依存せず、ルールと教育の両輪で構えるのが現時点では堅実だと考えます。

まとめ

  • 分割攻撃は、有害タスクを無害な小タスクに分けてAIの安全機構をすり抜ける手口。自然な業務依頼の連続で成立するため検知が難しい。
  • 査読前論文のベンチマークDECOMPBENCHは、「単発なら断れるが分割されると通してしまう」拒否率ギャップを定量的に示した。ただし防御策が確立したわけではない。
  • 情シスは、ツール権限の最小化・行動ログ・利用ルールと教育を第一歩に、IPAのAIセキュリティ指針を出発点として体制を整えるのが現実的。

出典

コメント

タイトルとURLをコピーしました