こんにちは。ソーシャル経済メディア「NewsPicks」のPlatform Engineeringチームの崔（ちぇ）です。
昨今、エンジニアのやるほとんどの仕事は「それはClaudeに」というものばかりになった気がします。調査に限らず実装やPR作成、なんならChrome拡張を使えば動作確認までさっとできちゃいます。GithubのCopilotレビューなんかも、かなりいいことに気づいてくれるので日々頼りにしています。
障害調査はどうでしょう？
AWS CloudWatch や New Relic といったo11y（observability）ツールのメトリクスを読んで、仮説を立てて、複数リポジトリのコードを追いかけて...。根本原因の特定から対応まで数人日かかる作業もAIに任せられるのであれば、人間の時間は浮くのだと！泥臭い作業ですが、大きくみるとパターンがあるはずで、そういうものこそClaudeのスキル化すべきだと思います。
今回は、実際にどのようなスキルを作って、どのように使っているのかの事例紹介ができればと思います。もし「スキルで何ができるの？」「スキルを作って自動化したいけど、参考にできる例が欲しい」などのお悩みがある方は、是非読んでみていただけると嬉しいです！
はじめに
SREチームはもちろん、私の属するPlatform Engineeringチームでも定期的にSLOモニタリングを実施しています。SLOモニタリングとは、サービスレベル目標（SLO）に対して実際のメトリクス（SLI）を継続的に監視し、ユーザー体験が損なわれていないかを確認する活動です。
サービスの信頼性を数値として定義し、基準を満たしているかどうかを継続的にチェックしています。
FYI : 信頼性を測る二つの指標
- Latency: レスポンスがどれくらいの速さで返っているか
- Availability: サービスが正常に提供できている割合
弊社は、数値を監視するためのAPM（Application Performance Monitoring）ツールとしてNew Relicを採用しており、専用のダッシュボードを構築してモニタリングしています。さらに、SLO違反が発生した際にはSlackへ通知が飛ぶので、早期対応が可能です。
エンジニアのやりたい開発ができる時間が足りない！
SLO違反が検知されると、その原因を突き止めるため上述した泥臭い調査作業をひたすら頑張ります。改めて図版としてそのフローを表します。
緊急性の高い違反はその都度調査します。それより優先度を落とせるものは、週次のモニタリングMTGでみんなで確認します。毎回 1.5〜4人時を費やしました。
1回のMTGで扱う件数は少ないときで2〜3件、多いときには10件を超えることもありました。しかも、MTGの時間内に原因特定＆方針策定ができなければ、そのまま差し込みタスク化するため、予定していたタスクが押し出されます。すると、やりたいことがどんどん後回しされるのです。
Claude Codeに頑張ってもらおう
スキルで自動化を目指す
目指すは、この調査フローをClaude Codeの「スキル」にして、自動化をすることです。
まずは、SlackのアラートURLをそのままClaudeに渡して、普段やっているのと同じ流れで調べさせました。例えば、下記のような指示を順に出しました。
- {URL} の通知が来たけど、どこで何が発生しているの？↓のフォーマットでまとめて
- エンドポイント（例: GET /users/{userId}）
- 発生時刻・復旧時刻
- 所要時間・SLO 閾値
- アラート種別キーワード（Latency / Availability）
- New Relic でどの処理が最も時間がかかったかを探して
- その処理が呼ばれるまでの道のりをまとめて
- その処理がどうして時間がかかっていると思う？
- じゃあ、それをどう直せばパフォーマンスが改善できる？
最初は単純な問題を解かせて、実現性を確認します。N+1問題（1 回の親リクエストに対して N 回の子 I/O が発生するパターン）の中でも最もシンプルで典型的な、forループを頑張って回してパフォーマンスが悪くなったケースを2〜3件調べさせました。
上記のような流れで想定通りに解に辿り着けるかを確認したところ、結果は概ね良好でした。Claude Codeは「じゃあ、今までの作業をスキルにして」と指示を出すだけでスキル化してくれます。スキルはMarkdownファイルです。
次に、今までとはちょっと変わった問題を渡します。たとえば、あるAPIの遅延が原因でコネクションプールが枯渇し、最終的にサービス全体が応答不能に至った、といった複数の要因が連鎖する障害です。
すると、Slackスレッドに言及された仮説を読んだだけで「因果方向は完全に一致」と断言したんです（0秒で！）。こんな適当な回答をさせないために、試行錯誤を経て以下のルールを設けました。
ルール1: 推測禁止
このルールを設けたのには、以下の二つのきっかけがあります。
- ちゃんと検証せず、人間が出した仮説を読んだだけで「仰るとおり」と断言
- 無料ユーザーは機能が制限されているのに「有料化したら直ります」と、仕様を把握せず提案
ルール2: 仮説を出力してから動く
ルール3: 2Kトークンで止まる
あるセッションで、まるで無限ローディングしているかのような画面になったことがあります。当時は個人でProプランに課金していたので、トークンの消費量だけが凄まじいスピードで上がっていて、冷や汗をかきました。結局、途中で辞めさせて「何をしようとしているの？まずは仮説を出力して」と指示してみました。すると、あらかた仮説は整っていて「すみません、寄り道してました」と言ったんです！それから、2Kを超えても原因特定ができない場合は、仮説を出力するようにしています。2Kという基準は、だいたいそのくらいだと仮説が立てられていたことを経験してエイヤーで決めたものです。
ルール4: 3回失敗で終了
ルール2、3と似たような話です。ある調査で、仮説を検証させていました。Claudeが当初考えていた通りに検証が進まなかったようで、本質ではない部分で深掘りしててトークンを無駄遣いしていました。そこで、できないものを勝手になんとかするのではなく、素早く諦めて人間の判断を待つようにしました。3という数字は、エイヤーで決めたものです。
ルール5: 辿り道の記録
ルール1の補完用でもあるのですが、N+1の原因を辿る調査で、Claudeがコードの辿り道を省略して適当な結論を出したことがあります。辿り道を出力させるようにしたら、今度は途中を省略して「なんらかの方法でここに飛び」のような曖昧な回答をしました。なので、ルールとして辿り道のパス全体を出力するように厳格化しました。
これらのルールとは別途、毎回の調査結果と対策をナレッジとして使えるよう、Claude Codeのメモリに記録させています。同じパターンの問題が再び現れたとき、以前の調査履歴を参照して早期に結論にたどり着けるようにするためです。
スキルの最終形
最終的に作られたスキルは、以下のような流れで調査と対応を進めます。
活用事例の紹介
弊社には、編成やコンテンツ入稿のために用意された社内のシステムがあります。その中でも、動画を検索する機能があるのですが、それが重すぎて、動画を扱わないチームの業務が止まったことがあります。
動画検索のリクエストの応答時間が220〜474秒/回にまで悪化し、ずっとTimeoutエラーを出していました。緊急でエンジニア数人が集まって確認したところ、11件のリクエストが同時にHTTPスレッドを占有、スレッドプールが枯渇してヘルスチェックに応答できなくなっていたのです。その結果、コンテナが強制的に入れ替えられ、約7分間使えませんでした。
障害発生直後、Slackの障害報告スレッドでは複数のエンジニアがそれぞれ別のメトリクスを確認して報告していました。調査を続けるうちに、社内システムが使えるようになったため、ここまでの調査に約7~10分がかかったのでしょう。
- エンジニアA: DBコネクションプールの使用率が急増している
- エンジニアB: CPU使用率が高まっている
- エンジニアC: コンテナが入れ替わっている
エスカレーションの連絡を受けてすぐ、スキルにこのSlackスレッドのURLを渡して調査を開始しました。Claude Codeは以下の項目を順に確認しました。
- NRQLでトランザクションデータを取得し、1リクエストあたりMySQLに 5,500〜7,500回、DynamoDBに 2,500〜3,600回がアクセスしていることが発覚
- 同じくNRQLでどのテーブルへのクエリが異常に多いかを確認し、N+1の疑いがあるテーブルを特定
- Controller → Facade → Service → Repository → Entity（6ファイル・7ステップ）を辿り、明示的N+1（Service層の個別DB呼び出し3箇所）を発見
- New Relic上のアクセス頻度とコード上の呼び出し回数を突き合わせ、EAGER関連による暗黙的N+1（8箇所）を発見
この問題は数年間潜伏していた構造的なもので、データ量の増加によって顕在化したものでした。Claude Codeが根本原因に辿り着くまでかかった時間は、たったの7分でした！対策の検証には13分がかかり、調査開始から25分経った時点で設計書が出来上がりました。
ちなみに、この調査では、上記の4ステップの調査のために、NRQLクエリ7本で以下の5系統のメトリクスを、時刻を揃えて照合したそうです。
1. Transaction（応答時間・DBコール数・外部コール数） 2. Datastore Metric（テーブル別アクセス頻度 — N+1特定の核心） 3. JMX ThreadPool（HTTPスレッドのActive数 — 死因の実証） 4. HikariCP（DBコネクションプールのBusy数 — 人間の仮説を棄却） 5. ECS Event（コンテナ入れ替えの理由）
人間がブラウザでぽちぽち同等の分析をするとしたら、複数のダッシュボードを行き来しながら時刻を揃えて読み解かねばなりません。特に、暗黙的N+1の存在は、誰が調べるのかによって見つけにくかったかもしれません。
もっと工夫するなら
実際にスキルを手元で何度も回し、社内で配布をしてみて、いくつかの改善点が見えてきました。
スキルづくりも結局エンジニアリング
ソフトウェアの世界には、Unix哲学の「1つのことをうまくやれ（Do one thing and do it well）」や、単一責任原則（Single Responsibility Principle）のように、小さく分割して組み合わせる設計思想があります。「スキル」にも同じ発想が適用できるのではないかと思います。
現在は1つのスキル（約550行）でLatency違反もAvailability違反も調査しています。しかし、この2つは調査の性質がかなり異なります。
Latency違反
「何が重いか」を探す。APMのDatastore MetricをFACETして支配的なクエリを特定し、コードを追って原因箇所に辿り着くパターンが多いAvailability違反
「どこでエラーが出ているか」を探す。呼び出し元だけでなく依存先サービスのAPMデータも突き合わせる必要があり、複数サービスを横断する調査になりがち
Latency調査用とAvailability調査用にスキルを分割し、親スキルが違反の種別を判定してサブエージェントに委譲する構成にすれば、各スキルがそれぞれの調査パターンに特化したルールを持てるようになります。小さなプログラムをパイプでつなぐように、小さなスキルを組み合わせて複雑な調査に対応する方向性です。
もちろん、サブエージェントに分割すると親のコンテキスト（Slackスレッドで得た障害の経緯、すでに確認したメトリクスの結果など）が引き継がれないため、文脈の欠落により精度が落ちる可能性があります。
ナレッジはみんなのもの
上では「Claude Codeのメモリに記録させています」と述べましたが、Notionなどの社内のドキュメントツールに集約しても良さそうに思います。
AIだけではなく人間がみてもためになる資料のはずで、なんらかの理由でAIが使えなくなった際に、人間が参考にして調査が進められるかもしれません。また、同時多発的にいろんな調査をさせて、そのナレッジが集まれば属人化が少しは解消されるかもしれません。
おわりに
このスキルは、私が作った最初のスキルです。もっと簡単な作業からスキル化しても良かったと思いますが、実は「スキル化」して云々することにあまり興味がわかなかったのです。勤怠ボタンをぽちぽちするくらいをスキル化するメンバーがいたのですが、「それくらいはスキルにする時間の方がかかりそう」みたいなよくない勤勉さがあったのです。
一方で、SLO違反調査やエラー調査のような作業は、一回スキル化しておくと、ずっと便利になる自分が見えたのかもしれません。それで作り始めたのですが、いざ手を出してみたら作る楽しさがそこにはありました！
Claude Codeを日常的に使っていると、出された質問や案に「yes/no」で答えるだけになったりします。そういう退屈な経験をされる際には、皆さんもぜひスキルを作って、ものづくりの楽しさを味わってみてください！そしてついでに（？）生産性向上にも貢献しましょう！
ちなみに、今回ご紹介したスキルは、社内に配布し告知したところ、「SLO向上委員会」から自動化に役立ちそうということで拾われていきました！更なる進化が楽しみです！
