MVP から始める、障害対応における AI 活用

背景

こんにちは。プログラマティック広告配信プロダクトを提供している AJA で DSP チームの SRE を担当している辻(jun06t)です。

SRE と言えば障害時のオンコールですね。オンコール当番の夜、以前の僕は次のような動きをしていました。

• アラートで電話が鳴り起きる

• 家族を起こさないよう、静かに自室へ移動する

• まぶしい PC を開いて、Claude を使いつつログやメトリクスを片っ端から確認する

• 仮説がまとまったら Slack に報告する

• すっかり目が覚めてしまい、そのまま起きる（そして日中に眠くなる）

深夜の一次調査は、健康にも日中の業務にも影響します。そこで今回は「オンコールの一次調査」を生成 AI に肩代わりさせた話を書きます。

課題

担当している DSP では Datadog の異常検知アラートが、多いときで月に十数件〜数十件ほど飛んできます。

厄介なのは、その大半は勝手に自動復旧してしまうのに、稀にリスクの高いケースが混ざっている点です。「誤報が多いから」とアラート自体を消すわけにもいかず、結局毎回 10 分〜1 時間ほどかけて調査することになります。

そして調査してみると、調査手順は毎回ほぼ同じだったりします。

関連サービスのエラーログを見て、Datadog のメトリクスを見て、直近のデプロイを確認して……という具合で、Runbook もあり手順としてはほぼ定型作業です。

にもかかわらず、オンコール担当には次のような負荷があります。

• 深夜・土日の対応が健康面と業務時間を圧迫する

• 調査内容が毎回同じで、担当者本人の学びや成長につながらない

• 自分が普段触っていない領域のアラートだと、何から見ればいいか分からず認知負荷が高い

そこで定型の一次調査は AI に委譲して、人間が必要になったときだけ人間にエスカレーションする。そういう形にできないか、というのが今回の出発点です。

なお、やらせるのは read-only の「一次調査」だけに限り、自動復旧（self-healing）はスコープ外にしました。本番リソースへの書き込み権限は AI には渡していません。AI は「調べて仮説を出す」ところまでで、意思決定と手を動かすのは人間、という境界を引いています。

進め方

ポイントを先に言うと、いきなり立派な基盤を作らず、GitHub Actions と GitHub Issue だけで MVP(Minimum Viable Product) を組んで「使える精度で調査できるのか？」をまず確かめ、価値を確認してから n8n で運用負荷を下げにいった、という順番です。

この順番自体が今回伝えたいことです。

MVP: まず GitHub Issue 駆動でチーム内でワークするかを確かめる

最初に考えたのは、「立派なワークフロー基盤を組む前に、そもそも AI に十分な精度で一次調査ができるのか？チーム内でこの運用がワークするのか」を確かめることでした。

前者は機能として必要で、後者は組織の文化浸透として Platform Engineering 観点で重要でした。これらがダメなら基盤投資は無駄になります。

そこで最初の MVP は、手持ちの道具だけで組みました。GitHub Issue を起票 → GitHub Actions が起動 → Claude Code が調査 → 結果を Issue にコメント、それだけです。

ai-investigate ラベルが付いた Issue でだけ workflow が起動するようにしています。

on:
  issues:
    types: [labeled]
jobs:
  investigate:
    if: ${{ github.event.label.name == 'ai-investigate' }}

トリガーを labeled だけにしているのは、調査の開始条件を「ai-investigate ラベルが付いたとき」に一本化するためです。Issue の新規作成（opened）は見ていません。ラベルさえ付ければ、新規 Issue でも既存 Issue でも同じように調査が始まります。ラベルを外して付け直せば、同じ Issue で再調査もできます。

この設計だと、調査を始める主体が誰でも同じです。最初は人間が手でラベルを付け、後から n8n が同じラベルを自動で付けるようにしました。調査側の workflow は変えずに済みます。

GitHub Issue & GitHub Actions にした理由

Issue を単なるトリガーにしたわけではありません。Issue そのものを調査ログ／ポストモーテムの資産として残すこと（暗黙知を形式知に）を狙っていました。

これまでは調査作業もドメイン知識も個人の頭の中や散らばった Slack スレッドにありました。なのでGitHub 上に「アラート → AI の調査結果 → 人間の追記」を残していけば、後から辿れる調査ログになる、という狙いです。

実際、Issue に溜まった過去事例を AI が参照できるようになったことで、現在では類似インシデントの経緯も含めた対応方針を提案してくれます。

もうひとつはバックテストのしやすさです。Issueをトリガーにしておけば、今実際に障害が起こらずとも過去の障害でテスト可能です。プロンプトや調査手順を変えたあとにラベルを付け直すだけで、同じケースを再調査できます。精度の確認や改善の効果測定を、本番の障害を待たずに回せます。

また、AJA DSP チームはモノリポ構成を取っているので、GitHub 上で扱うことで AI がソースコードを読んで的確な調査をできるというメリットもありました。

権限管理

社内方針で Anthropic API の直叩きはできないため、モデルは Gemini Enterprise Agent Platform（旧 Vertex AI） 上の Claude（Claude Opus）を使っています。anthropics/claude-code-action を use_vertex: true で起動し、composite action でラップしています。

権限まわりは絞りました。専用の GitHub App と専用の read-only な Google Cloud サービスアカウントを切り、付与する Google Cloud の IAM ロールは bigquery.dataViewer / logging.viewer / monitoring.viewer / spanner.databaseReader など read 系のみです。AI に許可したツールも、

--allowedTools Bash(gh:*),Bash(gcloud:*),Bash(bq:*),mcp__github__*,mcp__datadog__*

と、gcloud / bq / gh と Datadog・GitHub の MCP に限定しています。プロンプトでも「UPDATE / DELETE / INSERT は禁止」を明記し、本番リソースへの書き込みを封じています。

鍵管理においては Google Cloud 上で管理できるので、 Workload Identity Federation で鍵を発行しない形で認証しています。

回答精度・判断精度を上げるための工夫

やってみて分かったのは、やはり汎用的な調査手順だけでは精度が頭打ちになるということでした。効いたのはサービス固有のドメイン知識をプロンプトに書き込むことです。

例えばAJAでは名前のよく似たログ種別が複数あり、それぞれ生成元も経路も保持している ID も異なります。ここを AI が取り違えると、見当違いのデータを見て的外れな結論を出します。そこでプロンプトに「この種別を混同しない」「この ID を参照するときはこう指定」といった、過去に人間がハマった罠をそのまま書き込みました。

実はこれは過去にローカルClaude用のSKILLSとして作ったものがベースとなっています。

細かいことではあるのですが、判断精度を上げる対応として効いたのが調査で対象を特定できたときに必要であれば運用者が開ける管理画面のリンクを組み立てて出力させることでした。管理画面は DB の生の値ではなくドメインロジックを経た正しい値で表示され一覧性も高いので、人間が確認するうえで必要十分な情報が手に入ります。

アウトカムの確認

この MVP で、狙っていた「一次調査を十分な精度でこなせるか？」はクリアできました。アラートを Issue に貼れば、AI が関連ログ・メトリクス・過去事例・コードを横断で調べて、影響範囲・想定原因・根拠・推奨アクションをコメントで返してくれる。出先でも PC を開かず、スマホで結果を確認できるようになりました。

次のようにアラート内容をただ貼り付けただけの雑な Issue でも、AI は精度高い一次調査を行ってくれました。

この仕組みにより、オンコールの夜の動きは、こう変わりました。

アラートで飛び起きるのは変わっていませんが、そこから先は変わりました。PC を開かず、AI の調査を待つあいだ少し休むこともできます。

副次効果①：モニタリング定例の一次調査に

アラート対応だけではありません。AJAではプロアクティブな SRE 活動として、週次でチーム内のモニタリング定例を開いています。

そこで「通常時とトラフィック傾向が違う」「原因の分からない 5xx が出ている」といった気づきが出た際に、メンバーにランダムアサインしています。

しかしながら、定常業務が忙しいためなかなか対応優先度が上がらないといった課題感がありました。

今回のラベル駆動の仕組みによってまずはAIで一次調査できるようになり、アサインされた人の負荷が大きく低減しました。

副次効果②：ジュニアが調査に入るようになった

もうひとつ、当初は狙っていなかった効果がありました。これまで一部のメンバーに偏りがちだった調査に、若手が参加するようになったことです。

障害調査は、経験のある人ほど速く原因にたどり着けるぶん、気づけば同じシニアメンバーが引き受け続ける状態になりがちでした。慣れていない領域のアラートは、ジュニアにとって「何から見ればいいか分からない」心理的なハードルが高く、手が出しづらい。

ところが、AI が一次調査で「影響範囲・想定原因・根拠・確認すべき手順」まで出してくれるようになると、ジュニアにとっての入り口が「ゼロから調べる」から「AI の仮説を読んで検証する・次の一手を判断する」に変わります。ハードルが下がったことで、これまで様子見だったメンバーも調査に入れるようになりました。

副次的に、シニアに集中していた調査負荷が分散し、若手にとっては調査を通じてドメイン知識に触れる機会が増えます。属人化の解消と育成が同時に進みはじめました。

これらの効果から、チーム内でも問題無く浸透できると確信しました。

n8n で運用負荷をさらに下げる

MVP で価値が確認できた一方、運用にはまだ人手が残っていました。「Slack にアラートが流れる → 人間が気づいて Issue を起票してラベルを付ける」の部分です。

そこで、ワークフロー基盤として n8n をセルフホストで導入しました。役割分担はこうです。

Slack上で所定のメンションを付けると n8n が起動し、自動で Issue を起票して ai-investigate を付ける。すると（MVP でつくった）同じ GHA が走って調査し、結果を Issue にコメントする。n8n がそのコメントを拾って Slack にサマリを投げ、必要なら人間にエスカレーションする、という流れです。

ここでも MVP の「ラベルを付ければ人でも n8n でも同じ経路を通る」設計が効きます。n8n は「ラベルを付ける人間」を肩代わりしているだけなので、調査ロジック（GHA 側）には手を入れずに自動化を被せられました。

n8n の選定理由

GitHub Actions だけで完結させる案や、Zapier / Make のような SaaS の連携基盤、Dify、内製、なども比較しました。決め手は主に、

• self-hosted で内部データを外部 SaaS に出さない（Datadog ログや障害情報を社外に流さずに済む）

• 既存のインフラ（GKE / Argo CD / kustomize / External Secrets / Cloud IAP）の標準パターンにそのまま乗る

• アラート元が Datadog に限らず、Argo CD のエラーや Google Cloud のアラートなども Slack に流れてくる。特定の監視ツールに紐づけるとソースが増えるたびにつなぎ直すことになるので、入口は Slack に寄せる疎結合にした。 n8n の発火も各ツールの Webhook 直結ではなく Slack メンションにしている

の 3 点です。Zapier / Make は立ち上げは速いものの、プランによっては内部の障害情報が社外に流れる可能性があるためコンプライアンス上許容しづらく外しました。

なお PoC スコープなので、n8n はまず standalone + SQLite の最小構成で始めています。継続利用が確定して可用性・スケール要件が見えてきたら queue mode（PostgreSQL + Redis）への移行を検討する、という段階の切り方にしました。

学び

生成AIの登場によってエンジニアキャリアを模索する時代ではありますが、AIを活用する基盤を導入する手法は従来の Platform Engineering と同じです。

• MVP で小さく始める（スキル → GitHub Issue → n8n連携）

• チーム内で浸透するかどうか

個人レベルのAI活用から組織レベルのAI活用にレベルアップするためには、AI ができる限り自律的に動ける環境を整備していく必要があります。そのためにも Platform Engineering の視点はこれから必須技能と言えるでしょう。

まとめ

今回の対応により深夜のオンコールによる消耗は減り、当初は想定していなかった育成面の効果まで得られました。

今回紹介した内容は、効果検証期間を除けば実装自体は1日合宿で実現できる内容で、実際に合宿形式で構築しました。なので同じように定型の一次調査に負担を感じているチームでも是非検討していただけると幸いです。