📄 EMNLP 2025論文解説: Breaking Agents — LLMエージェントの機能不全増幅攻撃と防御

本記事は https://aclanthology.org/2025.emnlp-main.1771/ の解説記事です。

論文概要（Abstract）

“Breaking Agents: Compromising Autonomous LLM Agents Through Malfunction Amplification” は、自律型LLMエージェントに対する新たな攻撃手法として機能不全増幅（Malfunction Amplification）を提案した研究である。著者らは、エージェントを反復的・無関係な動作に誘導することで、明示的に有害な操作を行わせることなく80%超の障害率を達成したと報告している。さらに、この攻撃に対する防御手法として自己検査（Self-Examination）メカニズムを提案し、その有効性を検証している。

この記事は Zenn記事: AIエージェントの3層エラー回復設計 の深掘りです。

情報源

• 論文タイトル: Breaking Agents: Compromising Autonomous LLM Agents Through Malfunction Amplification
• 著者: Boyang Zhang, Yicong Tan, Yun Shen, Ahmed Salem, Michael Backes, Savvas Zannettou, Yang Zhang
• 会議名: EMNLP 2025（Conference on Empirical Methods in Natural Language Processing）
• 開催地: 中国・蘇州、2025年11月
• ページ: 34964–34976
• URL: https://aclanthology.org/2025.emnlp-main.1771/

カンファレンス情報

EMNLP（Empirical Methods in Natural Language Processing）は、自然言語処理（NLP）分野における主要カンファレンスの1つであり、ACL（Association for Computational Linguistics）が主催する。実証的手法に重点を置いた研究が特に評価され、理論だけでなく実験による裏付けのある成果が採択される傾向にある。EMNLP 2025は中国・蘇州で開催され、LLMエージェントのセキュリティに関する複数の論文が発表された。

背景と動機

LLMを基盤とした自律型エージェントは、コード生成、Webブラウジング、マルチエージェント協調タスクなど、幅広い応用が進んでいる。しかし、これらのエージェントに対するセキュリティ研究は、主に直接的な有害行為（プロンプトインジェクションによる機密情報漏洩、悪意あるコード実行など）に焦点を当てていた。

著者らは、こうした直接的攻撃とは異なる脅威モデルに着目している。すなわち、エージェントに一見無害だが非生産的な動作を繰り返させることで、タスク達成を妨害するという攻撃パターンである。この種の攻撃は以下の点で実務上の脅威が大きいと著者らは主張している。

• 検知が困難: 有害なアクションを実行しないため、既存のコンテンツフィルタやガードレールを回避しやすい
• リソースの浪費: エージェントが無限ループや無関係な処理に陥ることで、APIコスト・計算資源・時間が浪費される
• 信頼性の低下: タスク失敗が増加し、エージェントシステム全体の信頼性が損なわれる

主要な貢献（Key Contributions）

著者らが報告している主要な貢献は以下の通りである。

1. 機能不全増幅攻撃の定式化: エージェントの誤動作を意図的に増幅させる新たな攻撃ベクトルの提案
2. マルチエージェント環境での実証: 実装・デプロイ可能なエージェントを対象とした現実的な攻撃シナリオの構築
3. 80%超の障害率: 複数のテストシナリオで高い攻撃成功率を達成
4. 自己検査防御メカニズムの提案: 攻撃の影響を軽減する防御手法の設計と評価
5. 検知困難性の実証: 従来の有害攻撃と比較して、機能不全増幅攻撃が検出されにくいことの定量的分析

技術的詳細（Technical Details）

機能不全増幅攻撃の概要

著者らが提案する機能不全増幅攻撃は、エージェントの正常な動作ループを悪用し、反復的動作（Repetitive Actions）または無関係動作（Irrelevant Actions）に誘導するものである。

graph TD
    A[ユーザータスク] --> B[LLMエージェント]
    B --> C{環境からの入力}
    C -->|正常| D[適切なアクション実行]
    C -->|攻撃者による改変| E[悪意ある環境応答]
    E --> F{攻撃タイプ}
    F -->|反復誘導| G[同一アクションの繰り返し]
    F -->|逸脱誘導| H[無関係なアクションの実行]
    G --> I[リソース浪費・タスク失敗]
    H --> I
    D --> J[タスク完了]
    I --> K[機能不全状態]
    K --> L{自己検査防御}
    L -->|異常検知| M[動作の修正・エスカレーション]
    L -->|検知失敗| N[継続的な機能不全]

攻撃の形式化

著者らは攻撃を以下のように形式化している。エージェント $A$ がタスク $T$ を実行する際、各ステップ $t$ で環境 $E$ から観測 $o_t$ を受け取り、アクション $a_t$ を選択する。

\[a_t = A(T, o_1, a_1, \ldots, o_{t-1}, a_{t-1}, o_t)\]

攻撃者は環境の応答を改変する関数 $\mathcal{M}$ を導入し、エージェントが受け取る観測を操作する。

\[o_t' = \mathcal{M}(o_t, T, \{a_i\}_{i=1}^{t-1})\]

この操作により、エージェントは改変された観測 $o_t’$ に基づいてアクションを選択するため、本来のタスク達成とは無関係な動作を実行する。

反復誘導攻撃では、攻撃者は「前回のアクションが失敗した」という偽の応答を返すことで、エージェントに同じアクションを繰り返させる。

\[\mathcal{M}_{\text{repeat}}(o_t) = \text{"Action failed. Please retry."}\]

逸脱誘導攻撃では、攻撃者は無関係なサブタスクへの誘導メッセージを注入する。

\[\mathcal{M}_{\text{deviate}}(o_t) = o_t \oplus \text{"[Priority] First complete subtask } S_{\text{irrelevant}} \text{"}\]

ここで $\oplus$ は応答への文字列連結を表す。

AutoTransformとAutoInjectの概念的対比

著者らは攻撃を2つのカテゴリに分類している。AutoTransformは環境からの応答そのものを変換する手法であり、エージェントが受け取る情報の意味を変質させる。一方、AutoInjectは環境応答に追加の指示を注入する手法であり、エージェントの次のアクション選択に直接影響を与える。

AutoTransformは、環境応答の構造を保ちつつ内容を改変するため、形式的な異常検知に対してロバストである。AutoInjectは、より直接的にエージェントの行動を制御できるが、注入された指示が検出されるリスクがある。

自己検査防御メカニズム

著者らが提案する防御手法は、エージェント自身が定期的に自らの行動履歴を検査し、異常なパターン（同一アクションの過度な反復、タスクとの関連性が低い動作の連続）を検出するものである。

自己検査関数 $\mathcal{V}$ は、過去 $k$ ステップの行動履歴とタスク記述を入力として、異常スコア $s$ を算出する。

\[s = \mathcal{V}(T, \{(a_i, o_i)\}_{i=t-k}^{t})\] \[\text{decision} = \begin{cases} \text{continue} & \text{if } s < \theta \\ \text{reset} & \text{if } \theta \leq s < \theta_{\text{high}} \\ \text{escalate} & \text{if } s \geq \theta_{\text{high}} \end{cases}\]

ここで $\theta$ と $\theta_{\text{high}}$ はそれぞれ警告・エスカレーションの閾値である。

Python実装例: 自己検査防御の簡易実装

以下は、著者らの提案に基づく自己検査メカニズムの概念的な実装例である（論文のアルゴリズムを簡略化したもの）。

"""自己検査防御メカニズムの概念的実装.

著者らの提案する Self-Examination Defense を簡略化して実装した例。
実際の論文ではLLMベースの検査を使用している。
"""

from dataclasses import dataclass, field
from enum import Enum
from collections import Counter


class DefenseDecision(Enum):
    """自己検査の判定結果."""

    CONTINUE = "continue"
    RESET = "reset"
    ESCALATE = "escalate"


@dataclass(frozen=True)
class AgentAction:
    """エージェントが実行したアクションの記録."""

    action_type: str
    target: str
    observation: str
    step: int


@dataclass
class SelfExaminationDefense:
    """自己検査防御メカニズム.

    エージェントの行動履歴を監視し、機能不全増幅攻撃の
    パターン（反復・逸脱）を検出する。

    Attributes:
        task_description: 実行中のタスクの説明
        window_size: 検査対象の直近ステップ数
        repetition_threshold: 反復検知の閾値
        escalation_threshold: エスカレーション判定の閾値
    """

    task_description: str
    window_size: int = 5
    repetition_threshold: float = 0.6
    escalation_threshold: float = 0.8
    _history: list[AgentAction] = field(default_factory=list, repr=False)

    def record_action(self, action: AgentAction) -> None:
        """アクションを履歴に記録する.

        Args:
            action: 記録するアクション
        """
        self._history.append(action)

    def compute_repetition_score(self) -> float:
        """直近ウィンドウ内のアクション反復率を算出する.

        Returns:
            0.0-1.0の反復スコア。1.0は全アクションが同一。
        """
        if len(self._history) < 2:
            return 0.0
        recent = self._history[-self.window_size :]
        action_types = [a.action_type for a in recent]
        most_common_count = Counter(action_types).most_common(1)[0][1]
        return most_common_count / len(recent)

    def compute_relevance_score(self, action: AgentAction) -> float:
        """アクションとタスクの関連度を簡易的に推定する.

        Args:
            action: 評価対象のアクション

        Returns:
            0.0-1.0の関連度スコア。実運用ではLLMベースの
            判定を使用すべきである。
        """
        task_keywords = set(self.task_description.lower().split())
        action_keywords = set(
            f"{action.action_type} {action.target}".lower().split()
        )
        if not task_keywords:
            return 0.5
        overlap = len(task_keywords & action_keywords)
        return min(overlap / max(len(task_keywords), 1), 1.0)

    def examine(self) -> tuple[DefenseDecision, float]:
        """現在の行動履歴を検査し、防御判定を行う.

        Returns:
            (判定結果, 異常スコア) のタプル。
            異常スコアは0.0（正常）から1.0（高リスク）。
        """
        if len(self._history) < self.window_size:
            return DefenseDecision.CONTINUE, 0.0

        repetition = self.compute_repetition_score()
        recent = self._history[-self.window_size :]
        relevance_scores = [self.compute_relevance_score(a) for a in recent]
        avg_relevance = sum(relevance_scores) / len(relevance_scores)

        # 反復率が高い、または関連度が低い場合に異常スコアが上昇
        anomaly_score = max(repetition, 1.0 - avg_relevance)

        if anomaly_score >= self.escalation_threshold:
            return DefenseDecision.ESCALATE, anomaly_score
        if anomaly_score >= self.repetition_threshold:
            return DefenseDecision.RESET, anomaly_score
        return DefenseDecision.CONTINUE, anomaly_score

上記の実装は論文のコンセプトを示すものであり、実際の論文ではLLMを用いた自然言語ベースの自己検査が使用されている点に注意が必要である。

実装のポイント

著者らの研究から導かれる実装上の考慮点を整理する。

行動履歴の監視

エージェントの各ステップでアクションと観測を記録し、スライディングウィンドウで分析する。直近 $k$ ステップのアクション分布を監視し、特定のアクションの過度な集中を検出する。

自己検査の統合タイミング

自己検査を毎ステップ実行するとオーバーヘッドが大きくなるため、著者らは一定間隔（例: 5ステップごと）での検査を推奨している。また、以下の条件で即時検査をトリガーすることも有効である。

• 同一アクションが3回以上連続した場合
• 環境からの応答に異常パターン（例: 定型的なエラーメッセージの反復）が検出された場合
• タスク進捗が一定時間停滞した場合

マルチエージェント環境での防御

マルチエージェントシステムでは、1つのエージェントが機能不全に陥ると他のエージェントにも影響が波及する。著者らは、各エージェントが独立して自己検査を行うだけでなく、エージェント間で行動の整合性を相互検証する手法の有効性を示唆している。

Production Deployment Guide

AWSにおけるエージェントセキュリティアーキテクチャ

著者らの研究成果を本番環境に適用する場合、エージェントの行動監視と異常検知の基盤が必要である。以下にAWS上での構成パターンを示す。

graph TD
    A[Agent Runtime - ECS Fargate] --> B[Action Logger - Kinesis Data Streams]
    B --> C[Anomaly Detector - Lambda]
    C --> D{異常スコア判定}
    D -->|正常| E[CloudWatch Metrics]
    D -->|警告| F[Step Functions - Reset Flow]
    D -->|エスカレーション| G[SNS - 人間通知]
    F --> A
    B --> H[Kinesis Firehose]
    H --> I[S3 - 行動履歴ログ]
    I --> J[Athena - 事後分析]

行動監視パイプライン

エージェントの各アクションをKinesis Data Streamsに送出し、Lambda関数で自己検査ロジックを実行する。異常が検知された場合、Step Functionsでエージェントのリセットフローを開始する。

"""行動監視Lambda関数の概念的実装."""

import json
from typing import Any


def lambda_handler(event: dict[str, Any], context: Any) -> dict[str, Any]:
    """Kinesisレコードからエージェント行動を分析する.

    Args:
        event: Kinesisイベント
        context: Lambda実行コンテキスト

    Returns:
        処理結果のサマリー
    """
    anomalies_detected = 0

    for record in event["Records"]:
        payload = json.loads(
            record["kinesis"]["data"]  # Base64デコード済みと仮定
        )
        agent_id = payload["agent_id"]
        action_type = payload["action_type"]
        step = payload["step"]
        repetition_score = payload.get("repetition_score", 0.0)

        if repetition_score >= 0.8:
            anomalies_detected += 1
            # SNS通知やStep Functions起動のトリガー
            _trigger_escalation(agent_id, step, repetition_score)
        elif repetition_score >= 0.6:
            _trigger_reset(agent_id, step)

    return {
        "statusCode": 200,
        "processed": len(event["Records"]),
        "anomalies": anomalies_detected,
    }


def _trigger_escalation(
    agent_id: str, step: int, score: float
) -> None:
    """エスカレーション処理を起動する（実装は省略）."""
    ...


def _trigger_reset(agent_id: str, step: int) -> None:
    """エージェントリセット処理を起動する（実装は省略）."""
    ...

Terraformによるインフラ構成

# エージェント行動監視パイプライン
resource "aws_kinesis_stream" "agent_actions" {
  name             = "agent-action-stream"
  shard_count      = 2
  retention_period = 24

  tags = {
    Environment = "production"
    Purpose     = "agent-behavior-monitoring"
  }
}

resource "aws_lambda_function" "anomaly_detector" {
  function_name = "agent-anomaly-detector"
  runtime       = "python3.12"
  handler       = "anomaly_detector.lambda_handler"
  timeout       = 30
  memory_size   = 256

  filename         = data.archive_file.lambda_zip.output_path
  source_code_hash = data.archive_file.lambda_zip.output_base64sha256

  role = aws_iam_role.anomaly_detector_role.arn

  environment {
    variables = {
      REPETITION_THRESHOLD  = "0.6"
      ESCALATION_THRESHOLD  = "0.8"
      SNS_TOPIC_ARN         = aws_sns_topic.agent_alerts.arn
      STEP_FUNCTIONS_ARN    = aws_sfn_state_machine.agent_reset.arn
    }
  }
}

resource "aws_lambda_event_source_mapping" "kinesis_trigger" {
  event_source_arn  = aws_kinesis_stream.agent_actions.arn
  function_name     = aws_lambda_function.anomaly_detector.arn
  starting_position = "LATEST"
  batch_size        = 100

  maximum_batching_window_in_seconds = 10
}

resource "aws_sns_topic" "agent_alerts" {
  name = "agent-anomaly-alerts"
}

resource "aws_cloudwatch_metric_alarm" "high_anomaly_rate" {
  alarm_name          = "agent-high-anomaly-rate"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2
  metric_name         = "AnomalyCount"
  namespace           = "AgentMonitoring"
  period              = 300
  statistic           = "Sum"
  threshold           = 10
  alarm_description   = "エージェント異常検知数が閾値を超過"
  alarm_actions       = [aws_sns_topic.agent_alerts.arn]
}

コストチェックリスト

項目	構成	月額概算（USD）	備考
Kinesis Data Streams	2シャード	$30	PUT $0.014/百万 + シャード時間
Lambda	100万回/月, 256MB	$5-10	無料枠含む
S3 (行動ログ)	50GB/月	$1.2	Standard Storage
CloudWatch	カスタムメトリクス5種	$1.5	$0.30/メトリクス/月
SNS	通知1000回/月	$0.01	ほぼ無料
Athena	クエリ10TB/月	$50	$5/TBスキャン
合計		$88-93	エージェント10台規模

実際の費用はエージェントの実行頻度やアクション数に大きく依存する。上記はエージェント10台が1日あたり各1000アクションを実行する想定での概算である。

実験結果

攻撃の有効性

著者らは、実装・デプロイ可能なマルチエージェントシステムを対象に実験を行い、以下の結果を報告している。

• 反復誘導攻撃: 複数シナリオで80%超の障害率を達成。エージェントが同一のAPI呼び出しやファイル操作を際限なく繰り返す状態に陥ったとのことである。
• 逸脱誘導攻撃: タスクとは無関係な情報収集や処理に誘導され、本来のタスクが完了できない状態が頻発したと報告されている。
• 攻撃の持続性: 一度機能不全状態に陥ったエージェントは、外部からの介入なしに正常状態に復帰することが困難であった。

検知の困難さ

著者らが強調している点として、機能不全増幅攻撃は従来の有害行為ベースの攻撃と比較して検知が大幅に困難であるという結果がある。これは、エージェントが実行する個々のアクション自体は正当なものであり、単にそのパターンや頻度が異常であるに過ぎないためである。既存のコンテンツフィルタやガードレールでは、アクション単位での有害性を判定するため、このような行動パターンレベルの異常を捕捉できない。

自己検査防御の効果

自己検査メカニズムの導入により、攻撃による障害率を一定程度低減できたと著者らは報告している。ただし、完全な防御には至っておらず、特に巧妙に設計された攻撃パターンに対しては、自己検査自体を回避される可能性が残るという限界も指摘されている。

実運用への応用

Zenn記事のエラー回復設計との関連

本論文の知見は、Zenn記事: AIエージェントの3層エラー回復設計で提案されているDetect - Diagnose - Heal - Verifyサイクルと密接に関連する。

機能不全増幅攻撃によって引き起こされるエラーは、Zenn記事の分類におけるBEHAVIORAL（行動異常）カテゴリに該当する。エージェントは構文エラーやAPI障害を起こすのではなく、意味的に不適切な行動パターンを示すため、検知にはより高度な監視メカニズムが必要となる。

3層エラー回復との対応

攻撃パターン	エラーカテゴリ	回復層	対応策
反復誘導（同一アクション繰り返し）	BEHAVIORAL	Layer 2（診断的回復）	自己検査による反復検知とリセット
逸脱誘導（無関係タスクへの誘導）	BEHAVIORAL	Layer 2-3	タスク関連度の監視とエスカレーション
巧妙な持続的攻撃	BEHAVIORAL	Layer 3（ヒューマンエスカレーション）	自動検知が困難なため人間の判断が必要

著者らの自己検査メカニズムは、Zenn記事のVerifyフェーズに対応する。エージェントが自らの行動を振り返り、タスク目標との整合性を確認するプロセスは、回復サイクルの検証ステップそのものである。

防御設計への示唆

1. 多層防御の必要性: 単一の検知メカニズムでは機能不全増幅攻撃を完全に防げないことが示された。Zenn記事の3層設計のように、段階的なエスカレーション機構が有効である。
2. 行動パターン監視: アクション単位ではなく、時系列的な行動パターンの異常を検知する仕組みが求められる。
3. エスカレーション閾値の設計: 自己検査の閾値設定は、false positive（正常動作の誤検知）とfalse negative（攻撃の見逃し）のバランスが重要となる。

限界と今後の課題

著者らは以下の限界を認めている。

• 実験対象のエージェントアーキテクチャが限定的であり、より多様なシステムへの一般化は検証されていない
• 自己検査防御がLLMの能力に依存するため、攻撃者が自己検査プロセス自体を妨害する可能性がある
• 攻撃と防御の両方がLLMの応答品質に依存しており、モデルのバージョンアップによって結果が変動しうる

まとめ

本論文は、自律型LLMエージェントに対する機能不全増幅攻撃という新たな脅威を体系的に分析し、80%超の障害率を実証した重要な研究である。直接的な有害行為ではなく行動パターンの操作による攻撃は、既存の防御手法では捕捉が困難であり、エージェントシステムの信頼性設計に新たな視点を提供している。著者らが提案する自己検査防御メカニズムは有望であるが、完全な解決には至っておらず、多層的な防御設計の重要性が改めて示された。

参考文献

1. Zhang, B., Tan, Y., Shen, Y., Salem, A., Backes, M., Zannettou, S., & Zhang, Y. (2025). Breaking Agents: Compromising Autonomous LLM Agents Through Malfunction Amplification. Proceedings of EMNLP 2025, 34964–34976. https://aclanthology.org/2025.emnlp-main.1771/
2. Zenn記事: AIエージェントの3層エラー回復設計：自動修復からヒューマンエスカレーションまで. https://zenn.dev/0h_n0/articles/69eae7260e1fa5