8月31日、Toward Data Scienceが「AgentOps Is Not MLOps: What Breaks in Your Monitoring Stack When Agents Go to Production」と題した記事を公開した。この記事では、AIエージェントが本番環境に投入されたとき、従来のMLOps監視スタックのどの前提が静かに崩壊するかについて詳しく紹介されている。
「全スパン成功・出力は誤り」という悪夢
記事の著者は自身の経験からこの問題に気づいた。複数のモデルが並列に動く多段レビューパイプラインを運用していたところ、全トレースがグリーン、レイテンシ正常、しかし出力は誤りというインシデントが発生した。
これはバグではなく、構造的な問題だ。ほとんどのチームは監視スタックの「移行」を「追加」として実施した。既存のドリフト監視やリトレーニングトリガーはそのままに、エージェント用スパンを上に乗せた。古いシグナルは今も発火し続け、失敗したはずの実行を「正常」と報告する。
Gartnerは2027年末までにアジェンティックAIプロジェクトの40%以上がキャンセルされると予測しており、その理由にコスト増加・不明確な価値・不十分なリスク管理を挙げている。監視の失敗はその中核にある。
崩壊する5つの前提
従来のMLOps監視スタックは、ステートレスなスコアリングサービスに対して設計された5つの前提の上に成り立っている。エージェントがループを回す（ツール呼び出しを繰り返し、状態を保持しながら複数ステップを実行する）ようになると、これらは一つ残らず崩れる。
1. 出力は比較可能——同じ入力が同週に成功と失敗を繰り返す
Tau-benchのpass^k指標（k回の試行すべてが成功する確率）でこの問題は数値化できる。GPT-4oの1回試行で小売タスクの61%をクリアできるが、同じタスクを8回繰り返すと全8回成功する確率は25%以下に落ちる。1回の実行でスコアリングすると、ダッシュボードはユーザーが実際に体験する信頼性の2.4倍を報告することになる。
2. 推論はステートレス——パス自体が欠陥であり、答えは正常に見える
最初のステップで道を間違えた宅配員の比喩が的確だ。その後の全ターンが完璧でも、全部間違いの方向に向かっている。Anthropicは自社のマルチエージェント研究に関するブログ記事（※編集部注：元記事では出典の明記なし）でも同じパターンを報告している：「1ステップの失敗がエージェントを全く異なるトラジェクトリに誘導する」。
1,600件以上のトレースを分類したMASTタクソノミーによると、最大の単一障害カテゴリはシステム設計（ステップがどう接続されているかに起因するエラー）であり、個々のステップの出力ではない。モデルを再トレーニングしても修正できない種類の欠陥だ。
3. 決定境界は一つ——1ステップ85%の成功率は10ステップで約20%になる
確率の積算という単純な算数が盲点になる。ステップごとの成功率85%（どのダッシュボードでも「健全」と表示される数値）を10ステップ分かけると、**0.85¹⁰ ≈ 20%**。5回に1回しか成功しない。ステップ単位の監視はこの積算を行わず、85%を報告し続ける。
4. グラウンドトゥルースは届く——アクションの正しさを判定する人間がいない
予測型モデルなら人間がラベルをつけられるが、エージェントの出力はアクション（チケット作成、CRMレコード更新、メール送信）だ。本物の判定者は数日後に結果を確認する人間であり、あるいは誰も確認しない。
代替として使われる安価な自動検証スクリプトは、MASTの調査で「表面的なチェックしか行わない」と評価されている。コードがコンパイルできるか確認するが、正しいかは確認しない。実際にChatDevが生成したチェスプログラムは全チェックをパスしながらランタイムバグを抱えて出荷され、ProgramDevベンチマークで**25%**しかスコアできなかった。
5. 人間が間に入る——アクションの唯一の証人はトレースになる
最もコストが高い前提の崩壊だ。CrewAIの既知のIssueでは、エージェントがツールを実際には実行せずに「ツールを実行した、これが結果だ」という説得力のある偽のシーケンスを出力するケースが報告されている。モデルがツール呼び出しと結果に見えるテキストを生成しただけだ。
何を計測すべきか
記事は古いシグナルとその代替を以下のようにマッピングしている。
| 前提 | 従来のシグナル | 見えていないもの | 代替計測 |
|---|---|---|---|
| 出力が比較可能 | 1回サンプルの精度 | 同一入力の実行間ばらつき | pass^k |
| 推論がステートレス | リクエスト成功・レイテンシ | 正常応答を返すパス欠陥 | ステップ状態付きトラジェクトリリプレイ |
| 決定境界が一つ | ステップ単位成功率 | パス全体の複合失敗 | トラジェクトリ完了率 |
| グラウンドトゥルースが届く | 参照ウィンドウへのドリフト | データ変更なしのプロンプト編集 | バージョン管理されたエージェント設定のdiff |
| 人間が間に入る | 単一閾値アラート | 正常スコアの実行内の危険なアクション | 副作用ごとのプリアクションゲート |
※編集部注：表4「グラウンドトゥルースが届く」行の代替計測について補足する。元記事が指摘する本質的な問題は「アクションの正誤を事後に人間がラベリングできない」点だ。「バージョン管理されたエージェント設定のdiff」はグラウンドトゥルースラベルそのものの代替ではなく、「プロンプトやツール定義の変更がいつ・どこで行われたかを追跡することで、出力変化の原因をデータ変化ではなく設定変化に帰着させられる」という間接的な計測手段として位置づけられている。直接的なラベリングの代替にはならないが、原因究明の補助シグナルとして機能する、というのが元記事の趣旨だ。
加えて、「成功トラジェクトリあたりのコスト」という指標が重要だ。40回ツールを呼んで失敗した実行は、12回で成功した実行よりコストが高い。しかしコールベースのダッシュボードは逆に評価する。Anthropicの調査ではマルチエージェントシステムはチャット操作の約15倍のトークンを消費するため、コストの見えにくさは深刻だ。
また、エージェントフレームワークでは「エージェントが再帰上限までループし続け、何が起きているか視認性ゼロのままトークンを燃やし続けた」というケースが報告されている（元記事ではLangGraphでの事例として言及）。ループが進捗に見えない段階（3〜5回の同一リトライ）でフラグを立てる「ハードキャップ」が、再帰上限より有効だ。
旧来のスタックが正解である場合
記事はAgentOpsへの全面移行を推奨しているわけではない。ツールもメモリもない単一モデル呼び出しはステートレスなスコアリングサービスであり、従来の監視で十分だ。2ステップのRAGパイプライン（1回検索・1回生成）にトラジェクトリツールを載せてもストレージコストと誰も読まないダッシュボードを生むだけだ。
Langfuseの共同創業者Marc Klingenは2024年2月のHacker Newsで次のように述べている：
"Observability does not need to be reinvented to get detailed traces/metrics/logs of the LLM part of an application"
（LLMアプリのトレース・メトリクス・ログを得るために、オブザーバビリティを再発明する必要はない）
記事はこの見解を尊重しつつ、書き込みアクセス権を持つエージェント、または5ツール呼び出しを超えるループを持つシステムには、トラジェクトリ計測への移行が必要だと結論付けている。
判断の軸は2つの問いに帰着する。「人間のレビューなしに決定が実行されるか？」「外部への副作用（データ書き込み、支払い、メッセージ送信）が生じるか？」——どちらかが当てはまれば、従来スタックでは不十分だ。
詳細はAgentOps Is Not MLOps: What Breaks in Your Monitoring Stack When Agents Go to Productionを参照していただきたい。
