「原因の橋渡し」を自動化するAIが運用を変える

運用現場で、終わりの見えない「ログ漁り」をしていませんか。手作業で相関を探す時間が長ければ、エンジニアは新機能や予防保守に時間を割けません。最近、インシデント調査支援のスタートアップDeductiveがDoorDashの広告プラットフォームに導入され、年間でエンジニア工数換算約1,000時間を節約したと報告されました。なぜそれが可能だったのか。技術の中身と導入の利点・注意点を分かりやすく整理します。

Deductiveは何をしているのか

Deductiveは複数のデータソースをつなぐナレッジグラフを作ります。ナレッジグラフとは、システム内の要素とその関係をノードとエッジで表した知識の地図です。これにより、コード、テレメトリ、議論、ドキュメントなどを横断して関係性を可視化します。

既存の仕組みには読み取り専用で接続します。DatadogやPagerDutyなどのオブザーバビリティや、コードリポジトリ、チャット、インシデント管理ツールから継続的に情報を取り込みます。取り込んだデータは随時ナレッジグラフに反映されます。

インシデント発生時は複数のAIエージェントが協調して仮説を立てます。ログやトレースと照らし合わせ、仮説を検証しながら原因へと収束させます。これを同社は「マルチエージェント調査」と呼んでいます。

さらに、どの調査手順が有効だったかを強化学習で学習します。エンジニアのフィードバックを取り込み、調査戦略を継続的に改善していく設計です。

Deductiveは既存ツールを置き換えるのではありません。むしろ、その上に乗る推論レイヤーとして補完します。提供形態はクラウド版とセルフホスト版。料金は調査したインシデント数と基本プラットフォーム費用の組み合わせです。顧客データを他顧客の学習に流用せず、自社サーバーに蓄えない方針も明示しています。

DoorDash事例：広告プラットフォームでの統合と成果

DoorDashはリアルタイム入札（RTB：広告枠を瞬時に競り合う仕組み）を扱う広告プラットフォームにDeductiveを導入しました。RTBは100ミリ秒未満で応答する必要があるなど、低レイテンシが必須です。DoorDashは2026年までにプロダクションインシデントを10分以内に解決する目標を掲げています。

導入後、過去数か月でDeductiveは約100件の本番インシデントの**ルートコーズ（根本原因）**を特定しました。DoorDashはこれが年間で1,000時間以上のエンジニア工数削減に相当すると見積もっています。

具体例を一つ。あるAPIのレイテンシが急増した事象では、表面上は当該サービス単体の問題に見えました。しかしDeductiveはログ、トレース、デプロイのメタデータを横断解析し、下流の機械学習プラットフォームでのデプロイ作業中に発生したタイムアウトが原因だと突き止めました。言い換えれば、複数サービスにまたがる“原因の橋渡し”を自動で行えたのです。

ほかの事例では、FoursquareがApache Sparkジョブの失敗診断時間を90%短縮し、年間で5,000時間超を節約したと報告しています。

なぜデバッグ負担は増えているのか

AI支援によるコード生成で開発は速くなりました。しかし同時に、生成コードの冗長性やアーキテクチャ境界の曖昧化が増えています。結果として、システム全体の理解と保守が難しくなりました。

Association for Computing Machinery（ACM）は、開発者が時間の35%〜50%を検証・デバッグに費やすと報告しています。別の調査（Harness）は、67%の開発者がAI生成コードのデバッグに時間を取られていると示します。Deductiveの創業者らも、この傾向がデバッグ負担を深刻化させていると指摘しています。

既存のオブザーバビリティツールは「何が壊れたか」を示すのは得意です。しかし「なぜ壊れたか」を説明するのは限定的でした。暗黙の依存関係や実行時の変化を横断的に推論できるツールの需要が高まっているのは、ここに原因があります。

誰が得をして、誰が影響を受けるのか

直接の恩恵はSRE（Site Reliability Engineer：信頼性を保つ運用担当）やソフトウェアエンジニアです。調査に費やす時間が減れば、新機能や予防保守にリソースを振れます。ダウンタイムが収益に直結するサービスほど導入効果は大きく、DoorDashのように数百万ドル相当の損失回避につながる可能性もあります。

一方で、既存のオブザーバビリティベンダーは役割の見直しを迫られるかもしれません。推論レイヤーを前提とした運用フローやツール設計を考える必要が出てきます。エコシステム全体で連携や導入方式が変わる余地があります。

導入時の注意点と今後の展望

Deductiveの効果は魅力的ですが、いくつかの留意点があります。

  • データの網羅性と質が重要です。ログやトレース、デプロイのメタデータが不十分だと、正しい因果特定は難しくなります。
  • 既存ツールとの統合作業や、運用フローの見直しが必要です。責任分担を明確にしてヒューマン・イン・ザ・ループを保つことも大切です。
  • 現状は即時の自動修正は行っていません。Deductiveは精緻な修正案や緩和策を提示し、エンジニアが検証・適用する運用を推奨しています。

将来的にインシデント予測や自動修復が実用化されれば、さらに大きな工数削減が期待できます。ただし自動化には高い信頼性と誤検知時の安全策が不可欠です。

プライバシー面でも注意が必要です。Deductiveは顧客データを他顧客の学習に使わないと明言していますが、実運用でのデータ管理と透明性の確保が導入判断の鍵になります。

最後に重要な点です。DoorDashやFoursquareの成功事例は有望ですが、同等の成果が必ず得られるわけではありません。データの質やシステム構成、運用体制によって効果は大きく変わります。導入時は評価期間を設けて実運用での効果検証を行うことをおすすめします。

まとめ：推論レイヤーは運用をどう変えるか

Deductiveのアプローチは、単なるログ集約や要約を超えています。因果を追う調査ワークフローに近づく試みです。運用負担が増す現代のソフトウェア開発において、こうした推論レイヤーはSREの働き方を変え得ます。とはいえ、その実効性は現場のデータと運用ルールに依存します。導入を検討する際は、この点を見極めることが肝心です。

読者の皆様へ。もし運用で夜中のアラートに悩まされているなら、原因の“橋渡し”を自動化する選択肢を一度、試してみる価値はあるでしょう。軽やかな運用が、意外と近くにあるかもしれません。