なぜ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エージェントの導入を検討するとき、比較の目はモデルやフレームワークに向かいがちだ。だが周氏の整理に従うなら、先に問うべきは「渡せるデータが揃っているか」である。
