巻頭言：SRE × AIの事例ってどんなのがある？

著者：しょっさん
目次

MIXIでSREをやっているしょっさんと申します。

昨今は猫も杓子もAI,AIで、時代の流れが変わるのは早いなぁと感じています。
とはいえ、まだまだナレッジが世の中に少ないものに関しては、まともな出力を返さないのでこのあたりが今後どうなっていくのか非常に気になっています。
と、先週Argo NotificationsのTrigger書いた時にCopilotくんに大嘘をつかれたことを思い返すなど。

さて、そんなAIですがSREと掛け合わせた事例が増えてきたような印象があります。そこで、今回はGenAI活用に焦点を絞って調べてみました。日本の事例は皆さんチェックされていることだろうと思いますので、今回は海外の事例を中心に取り上げてみます。

eBayの事例

KubeCon EU 2025で発表されていた内容で、GenAIの組み込みに悪戦苦闘した結果を話されています。

活用の最初期はChatGPTなどを使い、Prometheusの転置インデックスの書き換え、サイト・アラートのトリアージに利用しようとした。
しかし、このように複雑なワークフローに組み込むことは、不確かな出力やハルシネーションなどが多く発生し、あまり使えないという結果になってしまった。

そこで、明確なワークフローにのみ利用することに注力し、LLMが得意な"要約"を中心とした組み込みを行うようにした。
その結果、以下のような「Explainers」という小規模ツール群が誕生した。

  • Trace explainer: 特定のトレースIDが与えられた際に、スパンを分析し、原因となるスパンを見つけ、その内容を要約する
  • Log explainer: ログ行群を分析し、調査に値するエラーやレイテンシパターンを見つけ、それらを要約する
  • Metric explainer: 時系列データ群を分析し、有用な特定のトレンドや異常を特定し、要約する
  • Change explainer: アプリケーションで行われた変更の種類を特定し、その内容を要約する

これらのexplainerは、さらに複雑なワークフローに組み込まれるために利用されるようになり、以下のような場面で活用されている

  • Dashboard explainer: 関連するMetric explainerや、Trace explainerなどを活用して、ダッシュボード全体に関する説明を生成する
  • インシデント発生時のトリアージワークフロー: 関連するダッシュボードや障害トレースを分析し、それらの結果をまとめて要約する際にexplainerを利用する

様々な紆余曲折を経た発見として、不確定な事象から何かを割り出そうとすると「非常にランダムな応答」が得られてしまう。
そのため、確定的な事象を入力とし、要約やシンプルな推論に集中させた方がよい。それ以外はコードやアルゴリズムによって予測可能で信頼性の高い結果を生成するという、旧来のやり方を採用するといいと述べている。

CircleCIの事例

AIをどのように活用すべきか？という記事の中にGenAI活用事例が書かれていました。 本題とは逸れますが、ただ単純にAIを活用しましょう！ではなく、ビジネス上の目標をまとめ、それらの解決すべき問題にAIが活用できないか？といったことを検討し、投資規模と予想利益の配分によってはAI活用を進めていきましょうという内容で、社内でAI推進を進めている方には参考になる記事となっております。

さて、この中で事例として「CircleCIのコンフィグファイルの作成支援」を挙げております。 CircleCIのコンフィグファイルは一般的に公開されるものではなく、LLMのトレーニングデータとしては使われていない状況のため、コンフィグファイルを作成するのにあまり使えないという問題がありました。 そのため、CircleCI自身がCircleCI コンフィグファイルをまとめたコーパスで独自のモデルをトレーニングし、提供できるように取り組んでいるようです。
これが一年前の記事だったので、もう既にMCPサーバで提供されてたりするのかな？と思って確認しましたが、まだ提供されていないようですね👀

このような、プラットフォーム側が抱えている大量のデータを利用して、開発の補助輪となるように提供をしてくれると良いですね。

Metaの事例

Metaはご存知の通り、多くのトラフィックを抱えているサービス「Facebook」を運用しており、10年以上拡張され続けてきたインフラは多くの依存関係が存在し、非常に複雑怪奇となっていました。また、システム変更も異常な速度で行われており、インシデント発生時の根本原因の探求を厄介にしておりました。
種々様々なデータ・ログの調査や相関付けを手動で行うには非現実的な時間がかかります。そういったインシデント対応の困難さを和らげるために着目したのがGenAIでした。

ヒューリスティック検索と大規模言語モデル（LLM）に基づくランキングを組み合わせ、インシデント対応の支援システムが作成されました。まずは、ヒューリスティック検索で、インシデントに関連したコード・ディレクトリの所有者情報・影響を受けたランタイムコードグラフの調査などから検索範囲を数千件から数百件に絞り込みます。
次にこの数百件まで絞り込んだ候補に対して、LLM（Llama2 7Bモデルをファインチューニングしたもの）に基づいたランキングシステムを利用したランク付けが行われます。その後、Electionアプローチという最大20個の候補をLLMに入力し、5つの上位候補を選出していきます。この選出された候補をさらに最大20個までグループ分けして5つ選出し・・・といったサイクルを繰り返し、最終的に選ばれた5つの根本原因候補を絞り込みます。このような手順を取っている理由としてはLLMのコンテキストウィンドウの制限に対応しているためらしいです。

このようなアプローチを取って運用していった結果、5つの候補の中に根本原因が含まれている可能性が42%まで引き上げることができたようです。この成果を生み出せたのは、Llama2のファインチューニングによるところが大きかったようです。

この精度をさらに高めるために、AIではどのような推論が行われたのか？を検証できるようにしたり、信頼度測定法を用いて（confidence measurement methodologiesとあるのですが、実際何をしているのかは調べてもわかりませんでした・・・）信頼度の低い回答を避けるようにしたりとしているのですが、最終的にAIには限界があるので自分の目で確かめることを重要視しているようです。

まとめ

今回は有名な３社の取り組みを調べ、紹介してみました。いかがだったでしょうか？
私もSRE × AIで何かできないか？を考えている真っ只中に置かれているため、非常に参考になる事例ばかりでした。こういった取り組みはすぐに効果が出るものから、じっくり腰を据えてストリームアラインドチームを巻き込みながら育てていくものまで多様にありますが、自分たちの組織のフェーズに合った取り組みを採用していきたいですね。

以上、巻頭言でした！