10月29日、Matt Saundersが「Datadog Builds a Specialist AI Model for SRE Investigations」と題した記事を公開した。DatadogがSRE向けに特化したAIモデル「Scout」を開発し、汎用モデルの3〜8分の1という推論コストでインシデント調査の品質を維持できることを示した取り組みだ。「すべてのアラートに対して自動的に動かすにはコストが見合わない」という現実的な課題に向き合い、汎用モデルではなく専用モデルを選択した判断の背景が詳しく紹介されている。
汎用モデルでは「コストが合わない」という現実
Datadogは、AIによるSRE調査製品「Bits Investigation」の内部で動作する専門モデル「Scout」をリリースした。現在はDatadog社内エンジニアと一部顧客によるクローズドプレビュー段階にある。
Scoutが生まれた背景にある課題はシンプルだ。アラートを受け取り、テレメトリを調べ、次に何を確認すべきかを判断する一連の調査では、モデルへの呼び出しが何度も発生する。GPT-4やClaudeのような汎用モデルでもこれは可能だが、すべてのアラートに対して自動的に動かすにはコストが見合わない、というのがDatadogの判断だ。
目標は、エンジニアがページに気づいて対応し始める前に、Bitsがすでに証拠を集め終わっている状態を作ることだ。
「私たちの目標は、Bitsが常時稼働するファーストレスポンダーとして、エンジニアが介入する前に証拠を集め、可能性の高い原因を特定することだ。」
— Othmane Abou-Amal, Ben Cohen, Afshin Rostamizadeh, Ameet Talwalkar, Omri Sass and Daniel Shan
コスト対性能の実績数値
Datadogが独自に構築したベンチマーク「AlertEval」では、元記事に記載のモデル名として、Scout medium が GPT-6.1 Sol high および Claude Opus 5.5 high と同等のスコアを記録しつつ、推論コストは3〜8分の1に抑えられたとしている。xhigh設定では Claude Fable 5.1 xhigh に匹敵するスコアで、コストは4分の1だ。
AlertEvalは実際のアラート、アーカイブされたテレメトリ、Datadogエンジニアが書いた解説から構成される。LLMジャッジが即時原因・根本原因の両レベルでScoutの分析と専門家の分析を比較し、矛盾や根拠のない主張は減点される。スコアは0〜100だが、Datadog自身が「解決できたインシデントの割合ではない」と明示している点は重要だ。
公開ベンチマーク「SREGym」（90件の障害シナリオを収録）での結果は以下のとおり（元記事掲載の表より抜粋）：
| 設定 | Scout | GPT-6.1 Sol（元記事記載、xhigh） |
|---|---|---|
| medium | 71件 | — |
| high | 79件 | — |
| xhigh | 80件 | 82件 |
なお、AlertEvalおよびSREGymのいずれのテストもDatadog自身が実施したものであり（比較モデルの実行も含む）、第三者による独立した検証はまだ行われていない。元記事の表では一部の設定と競合モデルの組み合わせにおける数値が省略されており、横並びの全数値比較については元記事を直接参照されたい。
/filters:no_upscale()/news/2026/10/datadog-scout-sre-model/en/resources/11791923332-bits-investigation-scout-postgres-diagnosis-1793038065922.jpg)
訓練の設計と「早期終了」問題
ScoutのベースモデルはGLM-5.3 Flash（元記事記載）。Datadogはこれを強化学習でポストトレーニングしており、過去の実際のインシデントパターンから生成したシミュレーションを使用した。シミュレーションにはアラート・クエリ可能なテレメトリ・既知の原因が含まれており、顧客データは使用していないとDatadogは述べている。
テクニカルレポートには、訓練中に直面した問題が正直に記述されている。最終的な回答の正確さだけを報酬にすると、Scoutは主張の数を減らして早めに調査を打ち切るという戦略を学習してしまった。減点を避けるための最適化であり、調査精度の向上ではない。
これに対してDatadogは、報酬関数を「正確さ・探索の深さ・根拠の充実度」の複合指標に変更した。また、固定のルートを学習させないために、一部の訓練ではツールを意図的に制限したり、調査時間を短縮したりした。
「その訓練では、原因を特定し、証拠でその結論を裏付けることが報酬となる。」
— 同チーム
競合との比較：調査にとどまるか、修復まで踏み込むか
同様のAI SREアプローチを取る競合各社との違いも整理されている。
- **AWS DevOps Agent**：複数の監視製品のテレメトリにソースコード・デプロイ記録・ランブックを組み合わせる。ツール横断型のアプローチ。
- **Honeycomb Canvas Agent**：アラート発火時に共有Canvasを開き、クエリを実行しながら調査の記録をエンジニアに残す。専用SREモデルは発表していない。
- **Splunk AI SRE**：アラートをグルーピングし、根本原因と証拠チェーンを生成。接続されたClaudeエージェントがサンドボックスでコード変更を準備してプルリクエストを開くことができる。
- **New Relic SRE Agent**：ランブックや過去の解決事例を分析に組み込む。Autopilotが修復アクションを提案。
箇条書きで並べると横並びに見えるが、競合間の差異は単なる機能の有無にとどまらない。SplunkとNew Relicが修復フェーズまで踏み込んでいるのに対し、ScoutはあくまでBitsが調査・診断・回復アクション提案を担い、実際の変更はエンジニアの責任としている。これはリスク設計上の選択でもある。障害対応中にAIが自律的にコードを変更する場合、誤判断のコストは調査フェーズとは桁違いに大きくなる。Scoutが現時点で「提案止まり」である点は、製品としての慎重さと見ることができる一方、修復自動化を求めるユーザーにとっては物足りなさとして映りうる。
独立した検証の欠如が課題
X（旧Twitter）上でのAIニュースアカウント「AGTP」の指摘が紹介されている。
AlertEvalは独立したテストを受けていない。また、Scoutがどの証拠を採用し、どれを棄却したかを示す監査証跡も求められている。
— AGTP（X上のコメント）
HoneycombのCanvas（調査過程を可視化）やSplunkの証拠チェーン（根拠を明示）は、他のベンダーも同じ課題を認識していることを示している。インシデント対応中の短い回答は助けになるが、エンジニアはモデルがその結論に至った過程も確認する必要がある。AlertEvalのスコアが高くとも、「なぜその証拠を選んだか」が追跡できなければ、本番環境での信頼獲得は難しい。この透明性の問題は、GA移行に向けた最大の課題の一つといえる。
一般提供（GA）の時期はまだ発表されていない。Datadogは今後、シミュレーションに含まれる障害の種類を増やし、最終的にはBitsが修復を実行できるようにする計画だが、現時点のプレビューはその手前の段階にとどまっている。
詳細はDatadog Builds a Specialist AI Model for SRE Investigationsを参照していただきたい。
