「あの人に聞かないと分からない」が、開発ライフサイクル全体を止めていた
周氏はDMM.com ITインフラ本部SRE部に所属するSREで、後述するAIエージェント「DMM DevOps Copilot」の開発・運用を担当している。題材のDMMブックスは電子書籍を販売するサービスで、本番環境はAurora MySQL、ECS Fargate、CloudFront、ALB、ElastiCacheといった多数のAWSリソースで構成され、大量のJenkinsのバッチが動く。オブザーバビリティにはNew Relicを使っている。
この規模のサービスを運用していると、何か問題が起きた際に、判断に必要な情報があちこちに散らばる。周氏が挙げたのは「あるAPIのレスポンスが遅くなった」という、どの開発現場にもありそうな例だ。New RelicのAPM（アプリケーションパフォーマンス監視）でトランザクションの内訳を見る。Jenkinsで重いジョブが走っていないかを確認する。オンプレの基盤やDMM全体の共通基盤に障害が出ていないかを当たる。ソースコードを読んで処理のフローを理解し、最後にGitの変更履歴を追って原因になり得るリリースを確認する。確認すべき先は6か所に及ぶ。
「これら一つひとつは特に難しくはないです。ただし、横断的にすべてを確認して、整理して因果関係を明らかにするためには、それなりの時間と経験が必要になります」（周氏）
そしてこの「時間と経験」は、そのまま属人性に転化する。
「結果として何が起きたかというと、あの人に聞かないと分からない、その人でないと分からないという問題が時々出てきます」
特定の開発者やSREへの確認待ちが、開発ライフサイクル全体のボトルネックになっていた。押さえておきたいのは、これが監視ツールの不足を嘆く話ではない点だ。New Relicは導入済みで、データもある。それでも滞るのは、散らばったデータを因果関係の形に組み上げる作業が人の経験に依存していたからである。
AIに判断を任せない──「伴走者」というエージェントの置き方
そこでDMM.comが目指したのは、ツールの追加ではなく、コミュニケーションそのものの流れの変化だった。従来は「人に聞く→人が調べる→回答を待つ」。これを「エージェントに聞く→エージェントが横断的に調べる→人がその回答根拠を見て判断する」に置き換える。
ここで効いてくるのが、周氏がセッションの冒頭に置いた「伴走者」の定義である。
「AIに判断を任せるというわけではなく、開発者あるいはSREがより良い判断をするための材料を一緒に揃えてくれる存在、そういう意味で使っていきます」
エージェントは最終的な判断者ではない。開発者が質問を投げると、エージェントが複数のデータソースを横断的に確認し、根拠付きで回答する。開発者はその根拠を見て自分で判断する。判断が難しければ、根拠を持った状態でSREや他のチームに相談しに行く。
「この根拠を持った状態で相談するというのがかなり重要でして、ゼロから直接調べてもらう場合とは全然違います。議論の質も上がりますし、SRE側の対応も圧倒的に速くなっていきます」
縮めようとしているのは、調査そのものの所要時間だけではない。相談が成立するまでの距離である。
なぜSlackで、なぜ独自開発だったのか──DMM DevOps Copilotの構成
この思想を形にしたのが、Slack上で動作するAIエージェント「DMM DevOps Copilot」だ。
Slackを選んだ理由は明快で、DMMの業務がすでにSlack上でやり取りされているからだ。新しいツールを覚える必要がなく、チャンネルのメンバーは誰でも会話が見えるため、ナレッジや使い方が自然に共有されていく。
SaaSではなく独自開発を選んだ理由は3つある。1つ目は、いま述べたSlack完結だ。AIアシスト系のSaaS製品の多くは独自のUI上で動作するが、DMM.comはSlackのスレッドの中ですべてを完結させたかった。
2つ目は、事業部への横展開である。DMMにはブックス以外にも多様な事業があり、稼働しているインフラもオブザーバビリティツールも異なる。同じエージェントを広げるには自由にカスタマイズできることが望ましかった。
3つ目がガードレールだ。本番環境に直接アクセスして調査する以上、見ていい情報と見てはいけない情報を細かく制御する必要があり、しかもその線引きは部署によって異なる。
アーキテクチャはマルチエージェント構成だ。オーケストレーター役のInvestigator Agentが質問を受け取って調査計画を立て、専門のサブエージェントに作業を割り振る。NRQLでNew Relicからデータを取得するNew Relic Agent、AWSのAPIを叩くAWS Agent、ソースコードやPRを検索するGitHub Agent、社内のナレッジを探すSlack Agentという分担である。
「オブザーバビリティへの投資は、エージェントの性能への投資」──NRQLが調査のステップを削る
この構成で鍵を握るのが、New Relicとの連携部分である。周氏は、エージェントの性能をこう捉えている。
「AIの性能はLLMの能力だけでは決まりません。どちらかというと、LLMに渡せる運用コンテキストの質の方が重要だという風に考えています」
その運用コンテキストを供給する上で大きな役割を果たしたのが、New Relicのクエリ言語NRQLだった。APMのトランザクションデータ、ログ、メトリクス、Synthetic監視、SLI／SLOといった監視情報を、すべて同じインターフェースで取得できる。「直近3時間で主要サービスのスループットやエラー率を調査してほしい」という依頼に必要な情報も、NRQL1つで横断的に取れる。
他のツールであれば、メトリクス用、トレース用、ログ用とツールを個別に用意しなければならない。エージェントにとって、この差は小さくない。渡される道具が増えるほど、計画を立てて実行するステップ数は増え、取りこぼしや勘違いの余地も広がるからだ。
「NRQLであれば、すべて同じインターフェースで取得できるので、エージェントが計画を立てて実行する際に必要となるステップが圧倒的に減りました」
さらに運用を通じて分かったのが、オブザーバビリティを高めるとエージェント自体の性能が上がるという関係である。例に挙がったのはRDSのスロークエリログだ。New Relicに集約しておけば、「この時間帯にどういった重いクエリが走っていたのか」をNRQLで即座に調べられる。集約されていなければ別の手段が必要になり、場合によっては取得できない。
「観測しているデータの充実度がエージェントの回答の質に直結するという風に判断しています。つまりは、オブザーバビリティへの投資はエージェントの性能への投資だという風に考えています」
AIエージェントの導入を検討するとき、比較の目はモデルやフレームワークに向かいがちだ。だが周氏の整理に従うなら、先に問うべきは「渡せるデータが揃っているか」である。
想定を超えて広がったユースケース──アラートの一次調査から、運営チームの仕様確認まで
当初想定していた使い方は、アラートの一次調査だった。アラートが飛んでくるとエージェントが自動で調べ、原因・影響範囲・推奨対応をSlackに投稿する。紹介されたのは、深夜にCloudFrontの5xxエラー率アラートが上がったケースだ。エージェントは「APIの応答遅延でPHP-FPMのワーカープロセスが枯渇していますよ。ただ7分で自動復旧しています」と返し、タイムラインや影響範囲までまとめた。
面白いのはその先だ。CPU使用率のアラートが4週間で15回繰り返されたとき、エージェントは毎回同じ根本原因を指摘し続けた。その積み重ねが「恒久対策が必要だ」という判断材料になる。逆にステージング環境の13件のアラートは、ほぼすべてが誤検知と判定され、アラート疲れの軽減につながった。朝会向けレポートも、いまは毎朝自動で投稿される。
だが周氏が「個人的に一番面白かった変化」と語ったのは、開発者が自分で一次調査を完結させるようになったことだ。SlackにトレースIDを貼って「このリクエストがなぜ500エラーになったのか」と聞けば答えが返る。「PRをマージしたら近い時間に障害が起きたが、本当にこのPRが原因か」と聞けば、リリース前後のメトリクスから因果関係を検証する。従来なら「SREさん、ちょっとサポートお願いできますか」と連絡が飛び、30分から1時間待っていたものだ。
用途はさらに広がった。「このAPI、他のリポジトリで使われていますか。削除しても影響ないですか」と聞けば、組織全体のコード検索と実際のアクセス履歴を踏まえた可否が返る。1人で作業していてもレビューパートナーになるわけだ。設計段階で「APIコールを6件追加したいが、キャパシティは問題ないか」と聞けばシミュレーションが返る。そして想定外だったのが、エンジニア以外の利用である。運営チームが「このクーポンにはどういった設定条件が可能か」と聞くと、エージェントがコードと設定ファイルを読んで答える。
人と人の間にエージェントが入る──3つの変化と、運用して見えた勘所
周氏は、チームに3つの変化が起きたと総括する。
1つ目は、設計・実装・検証のサイクルに、エージェントとの会話が自然に組み込まれたこと。「Agentが『困ったときのヘルプデスク』ではなく、一緒に開発を進めるパートナーという風に考えています」（周氏）
2つ目は、人と人の間にエージェントが入るようになったこと。開発者からSREへの問い合わせに根拠が伴うようになり、会話の質が上がっているという。ただし人と人のコミュニケーションが不要になったとは考えていないと周氏は釘を刺す。「エージェントで解決できるものはエージェントに任せて、人はより人にしかできないことに集中するという形です」
3つ目は、LLMの広い視点が新しい気づきを生んだこと。人が調べるにはコストがかかるため、軽微な変動は後回しになりがちだ。エージェントは頼まれていない範囲まで見て、「DBのCPUスパイクが定期的に出ていますよ」といった指摘を返してくる。見逃されていた予兆に光が当たるようになった。
効果は数字でも確かめられている。利用部署へのヒアリングでは、1回の利用で調査業務なら30分〜1時間、レポーティングなら1〜2時間程度が短縮できた。一方で、ビジネス判断や組織間の調整、「そもそもこの領域はオブザーバビリティが足りていない」という見極めは人が担うという線引きも明確になった。
コストは1回あたりの調査で1ドル未満。その調整過程の知見が示唆に富む。トークン数を減らしすぎると逆効果になるのだ。ツールのレスポンスを削りすぎると、エージェントが「情報が足りない」と判断して追加でツールを実行し、かえってコストが上がる。もう一つの勘所が、取得元ごとにばらつくフォーマットやタイムスタンプの統一だ。特にJSTとUTCの混在は、無関係な時刻の変動を拾う勘違いを招く。
「AI Agentと伴走する開発プロセスは、AIに判断を任せることではなく、人がより良い判断をするための材料を、AIと一緒に揃えていくプロセス」。周氏はそう述べてセッションを締めくくった。
最後に、New Relic カスタマーサクセス部 テクニカルアカウントマネージャの小林良太郎氏が自社の取り組みを補足した。「お話しいただいた周さんがおっしゃっていたように、New Relicも人間に伴走するということを今コンセプトとして考えています」と小林氏。障害の予兆検知・対応・分析をAIが拡張し、自律的に調査していく方向を打ち出す。
MCPはプレビュー中ながら公開されており、ClaudeやCursorから接続して「今どんな障害が起きているか」と尋ねられる。SREエージェントをアラートの送信先に設定すれば、一次切り分けを経てSlackへ投稿する流れも組める。GitHubのMCPと接続すれば、設計ドキュメントのような監視データに収まらないコンテキストも踏まえた助言が可能になる。「パフォーマンスリスクインボックス」はN＋1やスロークエリを検出して画面上に整理する。
「皆さんが見やすいということは、AIも見やすいんです」と小林氏。EC2の再起動やPagerDuty連携を自動化するワークフローオートメーションも紹介された。
New Relicからのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひ公式サイトをご覧ください。
