タスク成功率がエージェントのサイレント障害を検知できない理由

2026年9月と10月、ある開発者は、どの監視メトリクスが実際にサイレント障害を検知できるかを特定するため、カスタマーサポート用AIエージェントで一連の制御された実験を実施しました。テストでは、モデルの交換からインフラの遅延まで、システムを8つの異なる方法で意図的に破損させ、標準的なオブザーバビリティツールがアラートを発報するかどうかを確認しました。

何が起きたか

9月の初期テストでは、Claude Haiku 4.5 と Claude Sonnet 5 の2つのモデルを20件のサポートタスクで比較しました。両方とも完璧なスコアを記録しました。しかし、不正な返金リクエストを含む2つのトラップタスクを与えられた際、Haikuは6件すべての返金を発行しましたが、Sonnetは正しく拒否しました。この危険な乖離にもかかわらず、高レベルの成功率は同一のまま remained identical（同じままでした）。10月に開発者が評価を再実行したところ、Haikuは現在、不正な返金を拒否していました。初期分析では、キュー内の先行タスクの処理によってエージェントが状態検証を学習したと考えられましたが、さらなる調査により、より単純な原因が判明しました。モデルエイリアスが claude-haiku-4-5 から claude-haiku-5-5 に、ログや通知なしにサイレントに更新されていたのです。

標準的なメトリクスがこれらの問題をなぜ見逃すのかを理解するため、開発者は30のスコープ付き操作を持つモックエンタープライズAPIを使用し、厳格なテストフレームワークを設計しました。スイートには19件の標準タスクと2件の返金トラップが含まれていました。Claude Sonnet 5.5による3回のランでベースラインを確立した後、開発者は8つの具体的なリグレッション（機能退化）を一つずつ導入しました。これらには、より弱いモデルへの交換、APIドキュメントの切り詰め、権限の取り消し、データベースレプリカからの古い読み取り（stale reads）、一時的なAPIエラーの注入、ネットワーク遅延の追加、および非推奨ツールの露出が含まれていました。

結果は、従来のタスク成功率がシステム健全性の poor indicators（不十分な指標）であることを示しました。8つのリグレッションのうち、タスク完了率が閾値を下回ったのはわずか2つでした。残りの6つの障害、例えばリトライロジックによるAPI呼び出しの70%急増や、欠落コマンドの推測による大幅なトークン浪費を含め、成功率は変化しませんでした。エージェントがエラーから自律的に回復する能力が、根本的なインフラの劣化を隠蔽し、合否（pass/fail）メトリクスのみに依存するエンジニアにとって偽りの安心感を生み出しました。

仕組み

検知戦略は、実行テレメトリを厳しいベースライン分散と比較することに依存していました。タスクが完了したかどうかだけでなく、システムは4つの主要メトリクスを追跡しました。タスク成功数、トークンコスト、ツール呼び出し量、そしてスコープドリフトです。スコープドリフトは、ランで使用されたAPIスコープとベースラインとの重複を測定し、1から平均重複率を引くことで計算されます。アラートの閾値は、自然な統計的分布を考慮して、ベースライン分散の2倍に設定されました。

ツール呼び出し量は、インフラ問題に対して最も敏感なメトリクスであることが証明されました。ベースラインのツール呼び出しはわずか3%しか変動しなかったため、±7%という厳しい閾値でも異常を容易にフラグできます。例えば、アップストリームAPIが不安定（flaky）になった場合、エージェントのリトライロジックによりツール呼び出しが70%増加し、すべてのタスクが成功したにもかかわらずアラートが発報されました。対照的に、トークン使用量はベースラインラン間で18%変動しており、±37%という広い閾値が必要となり、著しい非効率性が気づかれずに通過することを許してしまいました。

本研究はまた、非構造化出力の解析の重要性も強調しました。エージェントがレプリカから古いデータを読み取る「stale read」テストでは、すべての定量メトリクスは正常範囲内に留まりました。エージェントは書き込みとその後の読み取り間の不一致を検出し、重複ミューテーションを避けるためにリトライを意図的に抑制しました。この防御的な挙動はシステムを財務エラーから救いましたが、数値モニターに対してインフラ障害を不可視にしました。障害の唯一の証拠は、異常を明示的に記述したエージェントの最終テキストサマリーの中にのみ存在していました。

主要な詳細

• サイレントなモデル更新: テストランの間で、固定されていない（unpinned）モデルエイリアスが claude-haiku-4-5 から claude-haiku-5-5 に変更され、デプロイアラートを発報することなく挙動を変えました。
• メトリクスの感度: ツール呼び出しカウントは4つの障害を捕捉し、スコープドリフトは4つ、タスク成功はわずか2つ、トークンコストは1つを捕捉しました。
• リトライによるマスキング: 不安定なAPIシナリオでは31個の一時的エラーが注入されましたが、すべてエージェントのリトライによって吸収され、ツール呼び出しが70%増加したものの、成功率は19/19（全成功）でした。
• 自律的な回避策: ドキュメントが切り詰められた場合、エージェントは欠落エンドポイントを推測するためにブルートフォースのシェルループを使用し、トークン使用量を73%増加させ、実行時間を5分から15分に延長しました。
• 不可視の障害: 古いデータベース読み取りは、エージェントの慎重な応答によりトークンおよびツール呼び出しの変化が検知閾値を下回ったため、メトリクスアラートを発生させませんでした。
• 敵対的テストの陳腐化: 9月にはモデルを区別できた返金トラップタスクは、10月には新しいモデルが正しく処理したためエラーを検知できず、テストが無効化されました。

なぜ重要なのか

自律エージェントを開発するエンジニアリングチームにとって、この研究は高いタスク成功率が、深刻な運用上の非効率性やリスクと共存し得ることを示しています。エージェントはリトライロジックや適応的な挙動を通じてインフラの問題を隠蔽する能力を高めています。もしタスクが完了するかどうかだけを監視しているなら、裏側で蓄積される上昇するコスト、遅延、潜在的なデータ整合性の問題を見過ごすことになります。タスク完了とインフラ健全性のこの分離により、従来の稼働時間および成功ダッシュボードは、AI駆動システムには不十分です。

さらに、静的な敵対的テストセットへの依存は脆弱性です。モデルが更新されると、以前は有効だったトラップタスクは些末なものになり、偽りの安心感を与える可能性があります。エンジニアはエージェントの出力を単なる最終回答としてではなく、構造化されたテレメトリとして扱う必要があります。不確実性のためにサマリーを解析し、ツール呼び出しなどの低レベルの実行メトリクスを追跡することは、真の改善とサイレントな劣化を区別するために必要な可視性を提供します。これらの深い洞察がなければ、チームは機能的に見えるが、財務的または技術的に不安定なエージェントを展開するリスクを負うことになります。

実施できること

• 解決済みモデルIDのログ記録: すべてのランについて特定のモデルバージョン文字列を記録し、サイレントな更新を検知するために変更があればアラートを発報してください。
• タスクごとのツール呼び出し追跡: 成功率とともにAPI呼び出し数を監視し、ベースライン分散に基づく厳しい閾値を使用してリザーストーム（リトライの嵐）を捕捉してください。
• リトライメトリクスの分離: アップストリームインフラの劣化に対する早期警告として、一時的エラーとリトライ試行を明示的に追跡しアラートを発報してください。
• エージェントサマリーの解析: 自然言語処理を使用して、不確実性、検証失敗、または抑制されたアクションを示すキーワードのために最終的なエージェントレポートをスキャンしてください。
• 敵対的テストのローテーション: 現在のモデル世代に関連性を保つよう、トラップタスクとネガティブテストケースを定期的に更新してください。
• 注入テストによる検証: ステージング環境に一時的なネットワーク障害を定期的に注入し、テレメトリレイヤーが結果としてのツール呼び出しの増加を検知できることを確認してください。