AIエージェントが間違いを犯すとき：マルチエージェント・システムにおける説明責任の危機

このアプローチは、初期の マルチエージェント研究 に基づいていますが、実運用では明確な基準と記録された選択に基づくべきです。低コストまたは低信頼のエージェントが勝者として選ばれた場合、その決定は後でインシデントレビューで明らかにされる必要があります。

仲介者
仲介者または裁定者エージェントは、他のエージェントが意見の不一致を生じたときに衝突を解決します。これはうまく機能することがありますが、責任の所在の見え方を変えます。仲介者は重要な意思決定点となり、その推論は追跡可能でなければなりません。通常、仲介者はより高度なモデルです。

重要なのは、仲介者がその決定を下した理由を知る必要があることです。裁定者がセキュリティ警告を覆した理由を説明できない場合、安全性を実際には改善していません。黒箱を移動しただけです。

実際には、これを正しく行うために学術的な合意プロトコルは必要ありません。必要なのは、単純なルールです。不一致を検出する方法を定義し、エスカレーションの閾値を設定し、不一致と解決をログに可視化することです。

この最後の部分は決定的です。これがなければ、出力はきれいである一方、証拠や監査証跡が残りません。

以下は、すべての方法を示す図です：

これらのアイデアを製品レベルの制御にどのように落とし込むかを考えましょう。

生産向けのプロセスフレームワーク

最も重要な一手は、エージェントのワークフローを生産システムのように扱うことです。実験ではありません。それは、明確な所有権、変更の管理、信頼性の高いテレメトリを意味します。

ガバナンス
まずガバナンスから始めます。AI品質管理機能は新しい部門である必要はありません。プロンプトと閾値の変更を承認する人、これらの変更の影響を評価する人、そしてシステムレベルの成果を所有する人という、軽量な責任のセットで構成できます。システムが高リスクの意思決定を行う場合、それらの役割は明示される必要があります。

意思決定記録
次に、意思決定記録を定義します。各エージェントのアクションについて、入力、ツール呼び出し、出力、信頼度、および適用された閾値やポリシーを記録します。読みやすい要約は人間には役立ちますが、それだけでは十分ではありません。生データが必要です。分析プラットフォームが非常に有用な点です。

Sumo Logicに取り込まれたとき、構造化された意思決定記録はこのように見えます：

{
    "timestamp": "2025-06-14T03:22:18.441Z",
    "trace_id": "abc-7f3a-...",
    "agent_id": "triage-classifier-v2",
    "action": "classify_alert",
    "inputs": {
      "alert_id": "SEC-90471",
      "source": "waf-east-1",
      "raw_severity": "medium"
    },
    "tool_calls": [
      {"tool": "lookup_ioc_feed", "result": "no_match", "latency_ms": 340},
      {"tool": "get_recent_alerts", "result": "3 similar in 24h", "latency_ms": 122}
    ],
    "output": {
      "classification": "low",
      "confidence": 0.72
    },
    "threshold_applied": "suppress_below_0.80",
    "escalated": false,
    "model": "gpt-5.2",
    "prompt_version": "classifier-v2.4.1"
  }

すべてのエージェントの意思決定がこのようなレコードを生成すると、エージェントの行動をインフラストラクチャイベントと関連付けることができます。次のように非常に簡単なクエリで：

_sourceCategory=agents | json \"output.confidence\" as confidence, \"agent_id\" | where confidence < 0.80 | count by agent_id

フリート全体のすべての低信頼度の意思決定を表面化し、検索可能な証拠の痕跡を作成します。

すべてを計測する
最後に、すべてを計測します。観測可能性は、「私たちは考えている」と「私たちは知っている」への架け橋です。 もしエージェントがツールを呼び出し、データストアから読み込み、出力を作成する場合、それらのアクションはエンドツーエンドで追跡されるべきです。OpenTelemetryは、サービスとツール全体でそれを実現する、実用的でベンダー中立の方法です。

実際には、OpenTelemetryのスパンでエージェントの意思決定をラップするには、非常に少ないコードで済みます：

from opentelemetry import trace

  tracer = trace.get_tracer(\"agent.triage\")

Each agent in the pipeline emits its own span under the same trace, so you get a full causal chain from alert ingestion to final decision. Then, using Sumo Logic's OpenTelemetry integration, we ingest these traces directly, letting you query across agent spans, tool calls, and infrastructure events in one place.

Next let's look at a hypothetical, but very plausible, failure of process that happens when observability is weak.

現実的な失敗事例（そしてそれが起こる仕組み）

Imagine a security operations team running a multi-agent triage system. One agent classifies incoming alerts, a second agent correlates with recent logs, and a third decides whether to open a ticket.

実際の侵入アラートが到着します。分類エージェントはそれを低優先度とラベル付けします。相関エージェントは弱い異常を示しますが、対応指標は見つかりません。意思決定エージェントはアラートを抑制することを選択します。数時間後、侵害が発覚します。

When the incident review begins, the team tries to answer a simple question: why was the alert suppressed?

インシデントのレビューが始まると、チームは単純な質問に答えようとします：なぜこのアラートは抑制されたのか？

The logs show the final decision but not the intermediate reasoning. It turns out the correlation tool was operating on stale data due to a delayed pipeline. The classification prompt had been tuned the prior week to reduce noise. The decision agent gave extra weight to the classification agent because it was historically more accurate. The system made a rational choice given its inputs. The problem is that no one can reproduce those inputs or see the disagreement that occurred.

ログには最終決定が示されますが、中間の推論は表示されません。相関ツールが遅延したパイプラインのために古いデータで動作していたことが判明しました。分類プロンプトはノイズを減らすために前の週に調整されていました。意思決定エージェントは、歴史的により正確だったため分類エージェントに追加の重みを与えました。システムは与えられた入力に基づいて合理的な選択をしました。問題は、誰もそれらの入力を再現できず、発生した不一致を確認できないことです。

This is the core accountability gap. The organization does not just lack a fix. It lacks a coherent explanation. And without an explanation, it can neither learn nor prove that the system is safe enough to keep in production. That is why analytics and evidence are not nice-to-haves. They are the difference between a system you can trust and one you cannot.

これがコアの説明責任のギャップです。組織には単なる修正が欠如しているだけでなく、首尾一貫した説明が欠けています。そして説明がなければ、学習もできず、システムを本番運用に耐えうるほど安全であることを証明することもできません。分析と証拠は、あればよいものではなく、信頼できるシステムと信頼できないシステムの違いです。

Now imagine the same scenario, but instrumented. The team opens Sumo Logic and runs:

_sourceCategory=agents "abc-7f3a"
    | json "agent_id", "action", "tool_calls", "output.confidence", "inputs", "trace_id"
    | where trace_id matches "abc-7f3a-*"
    | sort by _messageTime asc

They immediately see the full decision chain:

• The classifier's 0.72 confidence
• The correlation agent's lookup_ioc_feed call returned no_match against data that was 6 hours stale, and the decision agent's suppression.
• They can see that the classifier prompt was updated two days ago by checking prompt_version. And they can see the decision agent suppressed the alert despite the anomaly detector's 0.88 confidence flag, because the classifier's low-priority label and the correlation agent's no-match result both pointed toward suppression.

Most importantly, they can set a rule so it never happens the same way again: alert when tool_calls reference a data source with freshness older than a threshold, or when a high-confidence dissent is overridden on a security-tagged alert.

The hours-long investigation now just takes minutes.

なぜこれが重要なのか？

ビジネスの利害関係者、開発者、運用担当者は、運用結果を重視します。偽陽性の減少、トリアージの迅速化、信頼性の向上。マルチエージェントシステムはそれらの成果を提供できますが、チームがそれらを信頼できる場合に限ります。

And trust is not a feeling…or at least it shouldn't be. It’s a property of the system. It comes from being able to answer questions like: What did the agent see? What tools did it call? What did it ignore? Why was that alert suppressed? Who changed the thresholds last week?

信頼は感情ではない...少なくともそうあるべきではありません。信頼はシステムの特性です。エージェントは何を見たのか？どんなツールを呼んだのか？何を無視したのか？なぜそのアラートは抑制されたのか？誰が先週閾値を変更したのか？

This is exactly where observability helps. Your observability and analytics platform probably already collects and correlates logs and metrics at scale. The opportunity is to extend that same rigor to agentic workflows: treat agent decisions as first-class telemetry, and connect them to the infrastructure and security signals they depend on. When you do that, you can move from a black-box system to a transparent one, without sacrificing speed.

こここそ観測性が役に立つ点です。あなたの観測性と分析プラットフォームはすでに大規模にログとメトリクスを収集・相関させている可能性が高いです。その機会は、その同じ厳密さをエージェント主導のワークフローにも拡張することです。エージェントの意思決定を一級のテレメトリとして扱い、それらを依存するインフラとセキュリティ信号につなげます。これを実現すれば、速度を犠牲にすることなく、ブラックボックス系を透明なものへ移行できます。

結論

マルチエージェントシステムは現代の運用の標準的な一部になるでしょう。それらを活用して成功するチームは、説明責任を負担ではなく機能として扱うチームです。彼らは誰が何を所有しているかを知り、意思決定を追跡でき、物事がうまくいかなかった場合の結果を説明する証拠を持つでしょう。すべてのエージェントと跨ぐエージェント間の通信の完全な軌跡を含みます。これが信頼の形であり、規制当局、顧客、内部の利害関係者が求めているものです。

もしすでに深い観測性への投資をしているなら、ほとんどの構成要素を手にしています。次のステップは、それらをエージェント主導のシステムに適用することです。AI エージェントが間違えるとき、最も重要なのは彼らが間違っていたかどうかではなく、起こったことを証明できるか、そこから学ぶことができるか、そしてあなたのシステムが説明責任を負うことを示せるかどうかです。これにより、過去の過ちを繰り返さないよう迅速に改善する機会も開かれます。