> ## Documentation Index > Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt > Use this file to discover all available pages before exploring further. # 第8章 · 重要なことを測定する > エージェント運用は証拠によって成功または失敗します。8つのKPIダッシュボード、ROIの計算、ユニットエコノミクス、評価ハーネス。 *エージェント運用は証拠によって成功または失敗します。プロダクションシステムとして適切にプログラムを計装してください。* ## 8.1 主要な成果 公開されたデプロイメントと業界調査を通じて、規律を持ってエージェントインシデントレスポンスを実装したチームに4つの成果範囲が繰り返し現れます： | メトリクス | 文書化された範囲 | 要因 | | :-------- | :------------------------- | :------------------------------------------------ | | MTTR削減 | 40〜70%（ベンダーパイロットは最大75%を報告） | 自動化された調査と事前承認済みの修復が診断フェーズを短縮し、インシデント時間の大部分を占める | | アラート数削減 | 80〜90% | 人間がページを見る前の相関、重複除去、症状の抑制 | | 運用負荷削減 | L1/L2運用作業の30〜50% | トリアージ、ルーティン修復、証拠収集、レポートをエージェントが吸収 | | クラウドコスト削減 | 最適化可能なコストの10〜30% | 四半期ごとのレビューではなく、継続的なライトサイジング、アイドルクリーンアップ、コミットメント管理 | これらを前提とする約束ではなく、検証するベンチマークとして扱ってください。特にMTTR改善は実装の成熟度とデータ品質によって変わります — 記録されたパターンは、ノイズ削減が最初かつ最も一貫して実現し、次に根本原因の加速、最後に自律修復が来ます。 > *図8 — 規律あるデプロイメントにおける文書化された成果範囲、2025〜2026年。自社のベースラインと照合して検証してください。* 範囲の背後にある具体的なデータポイント：AWSはDevOps Agentのプレビュー顧客がMTTRを最大75%削減し、調査を80%高速化し、根本原因精度が94%に達したと報告しており、WGUは2時間の調査が28分に短縮されたと公に述べています。Microsoftは自社サービスで1,300以上のSREエージェントを稼働させ、35,000以上のインシデントを軽減し、20,000以上のエンジニアリング時間を節約したと報告しています。これらはベンダーおよびファーストパーティの数値です — 現在公開されている中で最も強力なものであり、信頼して受け入れるのではなく、自社のパイロットで検証すべき適切な数値です。 ## 8.2 運用ダッシュボード プロダクションのエージェントプログラムは、オンコールローテーションと月次でレビューするおよそ8つのKPIで運用されます： 1. **MTTDとMTTR** — 重大度別にトレンドされた検知時間と回復時間、エージェントが処理したインシデントと人間が処理したインシデントを分離して。 2. **自律解決率** — 人間のアクションなしに解決されたインシデントの割合。単一の最良の成熟度指標。 3. **推奨受諾率** — エージェントの提案が未修正で承認された割合。〜70%を下回る場合、エージェントの判断またはポリシーのチューニングが必要です；〜95%を超える場合、承認ゲートは形式的であり、アクションクラスは昇格すべきです。 4. **ロールバック / 介入率** — 元に戻すまたは上書きしなければならなかったエージェントのアクション。自律性の成長に対する安全性のカウンターウェイト。 5. **繰り返しインシデント率** — システムが学習しているかどうか。繰り返しの減少は、メモリと問題管理が機能していることを意味します。 6. **ランブック / カバレッジ比率** — エージェントチームがL2以上で対処できるインシデントクラスの割合。 7. **オンコール負荷** — エンジニア1人あたり週のページ数、特に時間外のページ。リーダーシップが感じる人間体験メトリクス。 8. **エージェントユニットコスト** — 解決されたインシデントごと、カバーされたサービスごとのモデルとプラットフォームのコスト。エージェントエコノミクスはファーストクラスのアーキテクチャ上の関心事です；初日からトラックしてください。 ## 8.3 ビジネスケースの構築 ROIモデルには3つのラインがあります。第1に、回避されたダウンタイム：インシデント頻度にダウンタイム1分あたりのコストにパイロットで検証するMTTR削減率を掛けます。コスト入力には、自社の財務チームの数値があればそれを使用してください；なければ、第1章で引用されたSplunk/Oxford Economics 2026年ダウンタイムベンチマーク（決済・取引システムでは大幅に高い）を最も防御可能な外部アンカーとして使用してください。第2に、変換された運用負荷：エージェントが吸収するL1/L2作業の時間を、エンジニアの満額コストで評価します — タレント制約のある市場では通常最大のライン。第3に、回収されたクラウドの無駄：ほとんどの組織が私的に認める20〜30%の無駄に対する継続的な最適化。これらに対して、プラットフォームサブスクリプション、モデル使用量、インテグレーションとガバナンスのエンジニアリング時間 — 自律性ポリシーオーナーの時間を正直に含めて — を計上します。規律あるデプロイメントは通常2〜3四半期以内にペイバックを達成し、運用負荷ラインだけでプラットフォームコストをカバーすることが多いです。モデルがダウンタイムラインを必要とする場合、パイロットドメインが間違っています；運用負荷の節約がケースをカバーし、ダウンタイムがアップサイドとなるものを選んでください。 ## 8.4 エージェントのユニットエコノミクス 第4章は、2層構造のセンシングが24時間365日のエージェントカバレッジを経済的に実現するものだと論じました。このセクションはそれを具体化します。なぜなら「それは自分でコストを回収する」はまさにこの本が買い手に拒否するよう言っている種類の曖昧な主張だからです。エージェントプログラムのコストはモデル推論に支配されており、推論コストは高コストの推論がどこで実行されるかに支配されます。規律は、安価な知覚を常時稼働させ、フロンティア推論をそれに値する少数のシグナルのために予約することです。 1つのインシデントをコストオブジェクトとして読みましょう。常時稼働の「Pulse」が低コストですべてのシグナルにわたって軽量な知覚を実行します；重量級のリゾルバーはPulseが調査に値するものを見つけた場合にのみマルチステップ推論を実行します。代表的な分割では、センシングがインシデントごとの支出の小部分を占め、トリアージがもう少し多く、深い解決が大部分を占めます — しかし深い解決はトリアージを生き残った少数のシグナルにのみ発動します。具体的な例：1日に約50のシグナルを発する環境で、ほとんどはPulseのみの知覚で処理され、フルリゾルバーの実行にエスカレートするのは少数のみであれば、高コストの層のデューティサイクルを低く保ちながらすべてのシグナルをカバーします。正確な比率はあなたが測定するものです；アーキテクチャはその比率を有利にするものです。 > *図12 — 1つのインシデントでトークンがどこに行くか：安価な知覚はすべてのシグナルで実行されます；高コストの推論はトリアージを生き残った少数のみで実行されます。解決されたインシデントあたりのコストを初日からトラックしてください。* これが「エージェントの解決インシデントあたりのコスト」と「エージェントのカバードサービスあたりのコスト」が第8章ダッシュボードにおいてファーストクラスのKPIであり後付けではない理由です：あらゆるノイズシグナルにフロンティア推論を実行するアーキテクチャは、最初の更新前にROIを消滅させます。そしてインシデントごとの数値を初日からトラックしていない限り、それが起きているのを見ることができません。 商業的な構造は、それと戦うのではなくこの現実に合わせることができます。成果ベースのオプション — 検証された節約の割合として設定された料金、節約がなければ支払いなし — はベンダーの収益を顧客の実現された利益に結びつけ、それ自体のために推論コストを積み上げるインセンティブを取り除きます。具体的な例として：検証された年間節約の50%で価格設定されたコスト最適化エンゲージメントは、何も見つからなければゼロを請求し、利益の一致を完全にします。どのような構造であれ、ビジネスケースに属する数値は第9章の90日ベースラインに対して自社環境で測定したものです — 本書を含む誰かのスライドからの見出しではありません。 ## 8.5 エージェントを信頼する前に評価する 本書は第3章から「自己検証」としてエージェント運用を呼んできましたが、検証ステップが具体的に何を確認するか、または自信を持った誤った修復がプロダクションに到達する前にどのように捕捉するかは示していませんでした。このセクションはそのギャップを埋めます。なぜなら、序文が約束するエンジニアたちはまさにこのハーネスを構築し実行しなければならない人たちだからです。 エージェント評価ハーネスには4つの部分があります。第1に、シナリオライブラリー：記録された実際のインシデントと意図的に注入された障害、それぞれが既知の正しい結果 — 正しい根本原因、安全なアクション、クリーンなロールバック — を持つ。第2に、シャドーラン：エージェントはプロダクションのサンドボックスミラーに対してアクションし、プロダクション自体ではないため、提案されたアクションを影響なしに観察できます。第3に、基準となる答えに対するスコアリング：正しい根本原因に到達したか、安全なアクションを選択したか、ロールバックは機能したか？第4に、リグレッションゲート：以前のエージェントバージョンと比較した動作変更は、出荷前にライブラリーを通過しなければなりません — チームが他のプロダクションコードに適用するのと同じ規律。 > *図13 — エージェント評価ハーネス：シナリオライブラリー、サンドボックスミラーに対するシャドーラン、基準となる答えに対するスコアリング、バージョン出荷前のリグレッションゲート。* 非決定論は決定論的な自動化から来るチームを驚かせる部分です：同じシナリオが異なる実行で異なるエージェントの動作をもたらす可能性があります。ハーネスは各シナリオを多数回実行し、単一のパスではなく結果の分布をスコアリングすることでこれを処理します — 70%の時間で正しい修正は99%の時間で正しい修正とは異なるリスクプロファイルであり、分布だけがどちらを持っているかを明らかにします。具体的な検証チェックはこれを具体化します：データベース接続枯渇シナリオでは、ハーネスはエージェントが接続プール枯渇を根本原因として特定すること、そのアクションが単にサービスを再起動するのではなく正しい接続制限を復元すること、アクション後に接続数がベースラインに戻りそのまま維持されることを検証します — エージェントがプロダクションで実行するのと同じDARV「Validate」ステップをここで既知の答えに対して実行します。ハーネスで自身の検証チェックに合格できないエージェントは、プロダクションで無人で実行するべきではありません。 **測定の原則** デプロイ前にベースラインを取る。最も一般的なビジネスケースの失敗は、信頼できる「以前」がないことです：最初のエージェントがプロダクションに触れる前に、90日分のMTTR、アラート数、ページ数、運用負荷時間を記録してください。そうしなければ、永遠に逸話から議論することになります。