Share
Embed
Slide 1
Slide 1 text
LLMは障害対応のお友達
さしみもち
2025/11/25【オンライン】エンジニア達の「完全に理解した」Talk#71
Slide 2
Slide 2 text
自己紹介
さしみもち
@Sashimimochi343
検索技術とその応用をこよなく愛する
エンジニア。ようやくバックエンドエ
ンジニア一本で名乗れるように。
最近は、GitHub Copilot Agentに個人
リポジトリのPR書かせまくっている。
2
Slide 3
Slide 3 text
技術書典19で新刊出しました!!
https://techbookfest.org/product/66gJ3xvWVQKPufbR18GFZF
深夜のアラート対応で、過去の類似障害を探すためにクエ
リを書き直し、Notionを検索し、Slackの履歴を漁
る―SREや運用エンジニアなら誰もが経験する「検索疲
れ」。本書は、そんな日常を変える一冊です。
- エラーログを見せるだけで、過去の類似障害と対処法を
自動で調べてくれる
- 自然言語で質問すれば、ログとナレッジベースを横断し
て回答してくれる
- アラート対応のたびに、情報が自動的に集約される
そんな未来が、もう手の届くところまで来ています。
3
Slide 4
Slide 4 text
深夜3時の悪夢
4
深夜3時、一通の電話で叩き起こされた。
眠い目をこすりながら画面を見ると、
「Production API - High Error Rate
Alert」の文字。心臓がドキッと跳ねる。
慌ててベッドから飛び起きたあなたは、
ノートPCを開き、Grafanaのダッシュボー
ドを確認する。警告を知らせる真っ赤なパ
ネルが目に飛び込んできた。
Slackには「スココッ」とひっきりなしに
通知が来ている。一体何が起こっている？
Slide 5
Slide 5 text
深夜3時の悪夢
5
ログを確認すると、見覚えのあるようなな
いような文言が並んでいる。Slackでやり
とりした履歴がないか、 「error」
「timeout」で検索する。
30分後にようやく類似事象を社外のテック
ブログで見つける。当時の対応を確認する
と、 「DBのコネクションプール枯渇。設
定値を調整して解決」と書いてある。願い
を込めて、同じ対応を実施。するとエラー
率は下がり、アラートも解除。
事故報告などを済ませてほっと息をついた
ときにはもう朝の5時だった。疲れ果てて
沈むように布団に戻るのだった。
Slide 6
Slide 6 text
深夜3時の悪夢
6
翌朝(というか数時間後)、チームのポスト
モーテム会議で先輩が言う。
「あー、それ俺も半年前に対応したわ。
Notionに書いたんだけどな」
先輩よ、あなたが電話に出てくれれば一瞬
で解決したのに......。
こういう経験1度はあるのでは
ないでしょうか？
Slide 7
Slide 7 text
こうなってほしい
7
私たちはあくまでAIに雑に聞
くだけ。
情報収集はAIくんが良しなに
やってくれる世界。
こうなれば新人でも臆せず、
オンコールローテーションに
参加できるはず！
Slide 8
Slide 8 text
できちゃいました
8
Slide 9
Slide 9 text
できちゃった様子
9
Slide 10
Slide 10 text
できちゃった様子
10
Slide 11
Slide 11 text
できちゃった様子
11
Slide 12
Slide 12 text
できちゃった様子
12
Slide 13
Slide 13 text
システム全体像
13
Slide 14
Slide 14 text
システム全体像
14
肝はMCPサーバーの登場
Slide 15
Slide 15 text
MCPサーバーとは
15
Anthropic社が2024年11月に発表したオープンな通信プロトコル
LLMと外部ツールを標準的な方法で接続するための標準規格
● LLMの種類によってアプリケーションの実装を変える必要がない
● LLMにシステムの存在を周知し、統一フォーマットでの仕様書提供
● LLMの利用可能な機能を制御（例:/_searchのみ提供して削除を防止）
● I/OをJSON Schemaで明示
検索エンジンのクエリを自分で考えなくて良くなった！
Slide 16
Slide 16 text
今回の例は一例にすぎない
16
MCPサーバーの登場によっ
て、既存のサービスを組み合
わせて、新サービスを作りや
すくなった!!
Slide 17
Slide 17 text
再掲）技術書典19で新刊出しました!!
https://techbookfest.org/product/66gJ3xvWVQKPufbR18GFZF
第1章:SREの現場とログ課題
第2章:Elasticsearchで始める障害ログ検
索基礎
第3章:ハイブリッド検索で「類似障害」を
見つける
第4章:MCPサーバー経由でElasticsearch
にアクセスする
第5章:自然言語でアラート分析を実現する
17
Slide 18
Slide 18 text
まとめ
18
● 情報が分散している状態で緊急性を求められる作業はつらい
● チャットで雑に聞くだけでログと原因調査と手順を調べてく
れるような仕組みが作れた！！
● MCPサーバー/AIエージェントの登場によってクエリを考えな
くて良くなったし、インターフェースを1か所に統合できるよ
うになった
● MCPサーバーは既存サービスをつなげて新しい体験価値を素
早く試せるツール
Slide 19
Slide 19 text
復旧作業までAIにやらせるのか
19
結局深夜に起こされるのは変わらないんだ...
● 判断が予めできているかつ定形作業はやらせても良いと
思う（すでにやってる）
● 都度判断が必要な本番サーバーの状態を変化させる操作
は抵抗感がある（SRE関連の勉強会でも出た意見）
とある読者様の感想
Slide 20
Slide 20 text
使用させていただいた素材
20
● いらすとや
https://www.irasutoya.com/