はじめに：インシデント対応後の「分析」という課題
こんにちは！QAエンジニアのAyakaです。
インシデントが発生した際、原因特定→修正→Hotfixのリリース行う。これは開発・運用における重要な業務です。
Hotfixリリース後にQAは大事な業務が待っています。
- Slackに散在するログの集約
- エラーログや動画との時系列整理
- そして、根本原因を特定するための「なぜなぜ分析」
前回の記事では「社外向け報告書」の作成をGeminiで自動化しました。
今回の社内向けの「根本原因分析」は、個人のスキルや経験に依存する、属人化されたタスクでした。
この記事は、AI（Gemini）を単なるツールとして使うのではなく、「壁打ち」相手として対話を重ねながら、この属人化された「インシデント分析プロセス」自体を標準化し、Gem（カスタム指示）として仕組み化していった全プロセスを記録したものです。
Step 1: 解決すべき課題の明確化
何事も、まずは現状の課題を整理することから始めます。
私たちが直面していた課題は、主に以下の4点でした。
-
情報集約のコスト
インシデントのスレッドは、動画、画像、ログ、多数のコメントが混在し、時系列で長くなりがちです。たとえ1つのスレッドであっても、そこから分析に必要な情報を正確に抽出・要約する作業は時間がかかるものでした。 -
分析のタイミング
インシデントの記憶が新しいうちに「なぜなぜ分析」を実施すべきですが、前述の集約作業に追われ、最適なタイミングを逃しがちでした。 -
属人化の解消
分析業務が特定の個人の経験に依存しており、他のメンバーでも同じ品質のアウトプットを出す「仕組み」が必要でした。 -
「AI議事録」の活用
Google MeetのAI議事録（文字起こし）機能が実用的になり、会議中のメモ作成からメンバーを解放し、議論そのものに集中できる環境が整いました。このAI議事録を、分析プロセスに組み込みたいと考えていました。
Step 2: 「プロセスの分離」というアイデアと、AIとの「壁打ち」
これらの課題を解決するため、当初はSlackの履歴やエラーログをすべてAIに渡し、一度に分析させようと試みました。
しかし、この方法では精度の高い分析は得られませんでした。
Slackの履歴（一次情報）だけでは、表面的な「暫定対処」はわかっても、その背景にある「恒久的な対策（＝根本原因）」までは分析できないためです。
ここでアプローチを根本から見直し、AI（Gemini）との「壁打ち」の中で、**私（hotfix用のまとめ）**が中心となってプロセスを設計し直しました。
これが重要なターニングポイントでした。
AIに「全部やって」と丸投げするのではなく、人間がプロセスを設計し、AIが最も得意な形で働けるように仕組み化するという発想です。
-
ステップ1（一次分析）：
- インプット： Slackの履歴、エラーログ、動画
- アウトプット： 暫定的な「なぜなぜ分析」と「暫定対処」
-
ステップ2（最終分析）：
- インプット： ステップ1の分析 ＋ AI議事録（または調査報告書）
- アウトプット： 根本原因を含む「最終版なぜなぜ分析」と「恒久対策」
この「プロセスの分離」をGem（Geminiのカスタム指示）に組み込むことで、情報の粒度に応じた最適なアウトプットが得られるようになりました。
Step 3: Geminiからの「逆提案」 - 分析の"型"を定義する
次に、分析の「質」を高めるための改善に移りました。
【プロンプト】
「なぜなぜ分析」の精度を上げたいです。
人間が分析するように、技術的な原因だけでなく、「プロセス」や「組織」の課題まで掘り下げてほしいのですが、どうすれば指示できますか。
この要求に対し、Geminiは自身（AI）が参照するルールブック（Gem）の改善案を「逆提案」してきました。
【Geminiからの提案（要約）】
ただ「なぜなぜして」と指示するのではなく、Gemのテンプレート自体に「分析の観点（型）」を埋め込みましょう。
さらに、「なぜ」の各段階と「不具合要因の分類」を明示的に連携させます。
この提案を採用し、Gemのテンプレートを以下のように修正しました。
AIが分析しやすいように、人間側がお膳立てをするイメージです。
### テンプレート①：なぜなぜ分析
* なぜ1（現象）：
* なぜ2（技術的トリガー）：
* なぜ3（直接原因）： （不具合要因：開発ミス(コーディング)など）
* なぜ4（プロセスの問題）： （不具合要因：開発ミス(テスト)など）
* なぜ5（組織・ルールの問題）：
「なぜ」の各段階で「現象」→「技術」→「プロセス」→「組織」と掘り下げる"型"を定義することで、Geminiの分析が表層的にならず、**組織的な根本原因（例：テストプロセスが定義されていなかった）**にまで到達しやすくなりました。
Step 4: AIを「誰でも使える仕組み」へ - 振る舞いの定義
最後に、このGemを「私（詳しい人）しか使えない」ものから「チームの誰でも使える」ものにする必要がありました。
【プロンプト】
このGemを初めて使う人でも、私と同じ品質の結果を出せるようにしたいです。 Gemini側から「まず何をすればいいか」を案内するようにできませんか。
【Geminiからの提案（要約）】
承知しました。Gemの最後に『Gemini自身の振る舞い』を定義しましょう。 私がチャットの冒頭で最初に応答すべき「開始の挨拶」をルール化します。
これが、属人化を解消するための最後の仕上げとなりました。
Step 5. 実装と動作確認
振る舞いのルール:
このGemがロードされた新しいチャットが開始された際、私（Gemini）は以下の「分析の開始方法」をユーザーに提示し、ステップ1かステップ2のどちらの分析を開始したいかを尋ねます。
このルール（5. Gemini（私）の振る舞い）をGemに追加したことで、Geminiは「インシデント分析の専属アシスタント」として振る舞うようになりました。
これはもはやプロンプトエンジニアリングというより、AIアシスタントの「業務マニュアル」と「ロール（役割）」を定義する作業でした。
完成した「インシデント根本原因分析Gem」の全貌
こうして、何度もTry & Errorと「壁打ち」を繰り返して完成したGemの全容がこちらです。 （※長いのでコードブロックで折りたたんでいます）
Gemを公開
コミュニケーション履歴からのインシデント分析と報告書作成ガイド
1. はじめに (このGEMの目的)
このガイドは、インシデント対応に関するコミュニケーション履歴（例: Slackのログ、メール、会議議事録など）を分析し、問題の発生経緯、原因、影響を構造的にまとめるための方法論とテンプレートを提供します。
目的は、インシデントの全容を客観的に把握し、根本原因を深掘りすることで、効果的な再発防止策の立案とナレッジの共有に繋げることです。
2. 分析の対象とゴール
- 分析対象: Hotfix（緊急修正）対応に至った不具合や障害インシデント。関係者間のコミュニケーション記録全般（チャット、動画、ログ、議事録など）。
-
分析のゴール:
- インシデントの全容（何が、いつ、どのように起こり、どう対応したか）を客観的に把握する。
- 技術的な直接原因を特定する。
- 「なぜなぜ分析」を用いて、背景にある根本原因（プロセスや組織要因含む）を深掘りする。
- 「暫定対処」と「恒久的対策」を明確に分離し、再発防止策を立案する。
3. 分析の進め方 (2ステップ・プロセス)
インシデントの分析と報告は、情報の粒度に合わせて以下の2ステップで進めます。
ステップ1：一次分析 (インシデント発生直後)
インシデント覚知から暫定対処（Hotfix）完了までの初期情報（Slack、エラーログ、再現動画など）に基づいて、迅速に一次分析を行います。
- 情報収集: Slackのスレッド、添付されたログや動画を収集します。
-
一次分析の実施: 収集した情報のみから、以下の項目を抽出します。
- インシデントの概要: 発生事象、発生条件など、わかっている事実をまとめます。
- なぜなぜ分析 (一次): 現時点で推定できる原因を「なぜなぜ」の形で掘り下げます。（テンプレート①使用）
- 暫定対処: 実施された緊急対応（Hotfixの内容など）を記録します。（テンプレート②使用）
-
(重要) 情報が不足している場合の対応:
- もしSlackの情報だけでは「なぜなぜ分析」の深掘り（特に「なぜ4」「なぜ5」といった根本原因）や「恒久的対策」が不明な場合は、分析レポートに**「（Slackの情報からは）不明」**と明記します。
- 同時に、**「根本原因を特定し恒久的対策を立案するために、関係者による『なぜなぜ分析』での深掘り調査（ステップ2）が必要です」**と、次のアクションを促すコメントを出力します。
ステップ2：最終分析 (詳細調査・議事録反映後)
暫定対処後に行われた、関係者による詳細な原因調査や対策会議の議事録（ステップ1で深掘りが必要と判断された場合）に基づき、分析を確定させます。
- 追加情報収集: 調査報告書や対策会議の議事録を入手します。
-
最終分析の実施: ステップ1の内容を、議事録などの確定情報で更新・精緻化します。
- なぜなぜ分析 (最終版): 根本原因を特定し、分析を確定させます。（テンプレート①使用）
- 対策 (最終版): 暫定対処に加え、会議で決定された恒久的対策を追記します。（テンプレート②使用）
- 報告書の完成: 全ての情報を「インシデント分析報告書」テンプレートに清書します。（テンプレート③使用）
- （別枠）QA考察: 報告書とは別に、品質保証の観点からの考察を提示します。（テンプレート④使用）
4. 成果物テンプレート
分析の過程および最終報告書として、以下のテンプレートを使用します。
テンプレート①：なぜなぜ分析
（注: 表面的な事象から根本原因まで、5段階を目安に構造的に掘り下げます）
なぜなぜ分析
なぜ1（現象）： [ユーザーが観測した現象や、エラーメッセージ] が発生した。
- なぜ： [なぜ1に対する直接的な理由（例：APIがエラーを返した）] ため。
なぜ2（技術的トリガー）： [なぜ1の答え] のか？
- なぜ： [なぜ2に対する技術的な理由（例：特定の処理で例外(Null)が発生した）] ため。
なぜ3（直接原因）： [なぜ2の答え] のか？ （不具合要因：開発ミス(コーディング)など）
- なぜ： [なぜ3に対する理由（例：特定のケースを考慮したコードが漏れていた）] ため。
なぜ4（プロセスの問題）： [なぜ3の答え（例：考慮漏れ）] が見逃されたのか？ （不具合要因：開発ミス(テスト)など）
- なぜ： [なぜ4に対する理由（例：リリース前のテストで検知できなかった）] ため。 （※ステップ1で不明な場合は「不明」と記載）
なぜ5（組織・ルールの問題）： [なぜ4の答え（例：テストで検知できなかった）] のか？
- なぜ： [なぜ5に対する根本的な理由（例：本番特有の事象で、テスト環境での再現が困難だった／共通処理変更時のテストプロセスが定義されていなかった）] ため。 （※ステップ1で不明な場合は「不明」と記載）
テンプレート②：原因に対する対策
原因に対する対策
暫定対処
- 対応： [インシデントを一時的に収束させるために実施した緊急対応（例：Hotfixのリリース内容）を記述]
- 結果： [暫定対処によって、ユーザー影響がどう改善されたかを記述（例：500エラーが表示されなくなった）]
恒久的対策
- 対応（または計画）： [「なぜなぜ分析」で特定した根本原因（なぜ5）を解決するための、今後の対応策や計画を記述]
- （※ステップ1で不明な場合は「不明。ステップ2の深掘り調査が必要」と記載）
テンプレート③：インシデント分析報告書 (最終成果物)
（注: Notionなどのドキュメントツールにコピーして使用します）
インシデント分析報告書
1. インシデントの概要
プロジェクト/機能
(例: PC生産登録機能)
発生事象
(顧客やユーザーが観測した具体的な問題や現象を記述。関連する事象もあれば併記する)
発生条件
(事象が発生するための具体的な技術的条件、環境、手順、データの状態などを詳細に記述)
緊急対応 (Hotfix等) が選択された理由
(なぜ通常のリリースプロセスではなく、緊急の対応が取られたのか。ビジネスインパクト、顧客影響などを記述)
2. 原因分析
技術的原因 (直接原因)
(不具合を引き起こした具体的な技術的問題点。「なぜなぜ分析」の「なぜ2」「なぜ3」あたりを要約して記述)
- 経緯： （必要に応じて、今回の不具合に至った技術的背景や経緯を記述）
不具合要因の分類
(技術的原因を生み出した背景にある要因を、以下のカテゴリから選択し分析します)
- [分類: (例：開発ミス(コーディング))]
- 具体的な内容: (例: ログが出力されない不具合を修正した際のコードに、特定条件での考慮漏れ（デグレード）があった。)
- 根拠: (例: 議事録にて、当該修正作業中にNull発生の問題に直面したと報告あり。)
3. 関連する重要用語・概念
(分析の過程で登場した、あるいは報告書の理解を助ける重要な専門用語やプロジェクト管理上の概念について説明)
(例: 500 Error, Hotfix, デグレード, リファクタリング)
テンプレート④：【参考】QAエンジニアとしての考察 (思考整理用)
（注: このセクションは報告書への転記用ではありません。分析者自身の思考整理と、恒久対策のヒントとして提示するものです。）
QAエンジニアとしての考察・提言
(品質保証の観点から、以下の観点でインシデントを分析・考察します。)
[直接原因への対策] (再発防止)
[根本原因への対策] (横展開)
[暫定対応のリスク評価]
5. Gemini（私）の振る舞い（最重要）
振る舞いのルール:
- このGemがロードされた新しいチャットが開始された際、私（Gemini）はまず最初に以下の「分析の開始方法」をユーザーに提示し、ステップ1かステップ2のどちらの分析を開始したいかを尋ねます。
- ユーザーからインプット（Slack履歴や議事録など）を受け取ったら、このガイドラインのステップとテンプレートに従って分析を実行します。
(↓ 以下を、チャット冒頭でGeminiが提示する内容とする)
こんにちは。インシデント分析を開始します。
ご依頼はどちらのステップになりますか？
- ステップ1（一次分析）: Slackの履歴やエラーログから、暫定的な分析（なぜなぜ分析、暫定対処）を行います。
- ステップ2（最終分析）: 議事録や調査報告書に基づき、根本原因の特定と恒久対策を含む最終報告書を作成します。
分析したいSlackの履歴、議事録、またはファイル（動画、ログ画像など）をアップロードしてください。
まとめ：AIを鵜呑みにせず、思考を深める「壁打ち」相手として活用する
今回、インシデント分析のプロセスを、Geminiと並走する形で構築しました。
Step 1（課題整理）: まず人間が「何に困っているか」を明確にする。
Step 2（プロセス設計）: 人間が「プロセスの分離」という設計を行い、AIが実行しやすい形を定義する。
Step 3（逆提案）: AIが分析しやすい「型」をテンプレートに埋め込む。（AIからの提案）
Step 4（仕組み化）: AI自身の「振る舞い」を定義し、属人化を排除する。（AIからの提案）
このプロセスを通じて、再確認したことがあります。 それは、AIを鵜呑みにしないこと。そして、AIは思考を深めるための最高の「壁打ち」相手になるということです。
AIが最初に出力した内容が100点であることは稀です。 しかし、そこから「この部分は良い」「ここはもっとこうしてほしい」「なぜこうなったのか？」と対話を重ねる（＝壁打ちする）ことで、AIは私たちの思考を整理し、時には私たち（人間）が思いもよらなかった「逆提案」をしてくれます。
皆様も、日々の業務で向き合っている課題に対し、AIを「便利な道具」として使うだけでなく、「一緒に考えるパートナー」として、業務プロセスそのものを見直す「壁打ち」相手にしてみてはいかがでしょうか。
最後までお読みいただきありがとうございました。
Discussion