Pocket Musubi開発チームの開発ディレクター、松本です。 システムに障害はつきものです。カケハシでも時折障害が発生します。開発ディレクターの役割の一つとして、障害発生時の統制者（障害対応をリードする役割）を担います。 本記事では、統制者として、スピード感が求められる障害対応を少しでも効率化するために、「社内向け障害報告書の作成」を自動化した事例と、これから効率化していきたい部分について記載します。
カケハシの障害対応フローについて
まず前提として、カケハシの障害対応フローを簡単にご説明します。 下図は、一部簡略化していますが、カケハシの障害対応フローです。 カケハシでは障害対応フローの全工程にわたって、障害まとめファイルを作成し、障害の状況（原因、影響範囲、時系列など）、障害対応のTODOを管理しています。今回の自動化は、この障害まとめファイルを起点としたものです。
%%{init: {"themeVariables": {"fontSize": "18px"}}}%%
graph LR
A[障害検知]
B[障害体制の構築<br/>統制者/運用決定者/CP策定者/対応エンジニアのアサイン]
C[状況の把握]
D[影響範囲調査<br/>影響顧客・影響内容/機能の調査]
F[顧客報告]
G[止血対応]
H[原因調査]
I[恒久対応]
J[ポストモーテム]
K[社内向け障害報告書の作成]
A --> B --> C
C --> D --> F --> J --> K
C --> G --> I
C --> H --> I
I --> J
※状況の把握以降の「影響範囲調査」「止血対応」「原因調査」の優先度は障害の内容によって決定します。
Cursorを用いた社内向け障害報告書作成の自動化
次に、先述の障害対応フローの中で、Cursorを用いて「社内向け障害報告書の作成」を自動化した事例を共有させていただきます。
課題
- 障害まとめファイルやポストモーテムで使用するホワイトボードツールなど、障害情報が複数箇所に分散しており、1件あたりの障害報告書作成に30〜40分ほど要します。その結果、統制者の作業負荷が増大し、関係者への展開にかかるリードタイムも長くなりがちです。
- 障害報告書の品質が、統制者の稼働状況や個人の記載スタイルによりばらつきが生じます。関係者に分かりやすく周知するためには、障害の経緯を示す図などの視覚的情報が有効ですが、繁忙期には作成に十分な時間を割けず、省略しがちになります。
Cursorを選択した理由
カケハシでは生成AIサービス利用ガイドラインを社内向けに策定し、Cursorをはじめ、Gemini、Dify、Devin、Claude codeなど、さまざまな生成AIツールが使用可能です。その中でも今回の自動化にCursorを選択した理由は3つあります。
- Cursorルールを使って、事前にプロンプトを定義し、実行時にはメンションするだけのため、都度プロンプトのインプットが不要になります。
- 定義したスクリプトやMCPなどを用いて、柔軟に多岐にわたるツールと連携できるため、自動化の幅が広いです。Cursorを起点にすることで、障害対応フローの全工程にわたる自動化もしやすいのではと考えました。
- 障害まとめファイルや障害報告書をフォルダに配置しておくと後からLLMとの対話形式で情報を取得できるため、似たような障害が発生した際などの参照が楽になります。
自動化の流れ
本自動化では、以下の構造のプロンプトをCursorルールで指定し、障害まとめファイルおよびポストモーテムで使用するホワイトボードツールへのリンクを基に、カケハシで定められている障害報告書のテンプレートに沿った障害報告書作成を自動化しています。
入力情報
- 障害まとめファイル
- ポストモーテムで使用したホワイトボードツールのURL
Chain-of-Thought（CoT）プロンプティングを用いた障害報告書の生成
- 入力情報の抽出
- 入力情報の加工
- 障害報告書のテンプレート（出力形式の指定）の指定
- テンプレートの章ごとに、入力情報のどの部分を参照し、どのようなロジックで生成するかを指定しています。そのため、本テンプレートの章ごとに、障害報告書を生成する際の思考の流れ（Chain-of-Thought）を記載しています。
- 出力先と形式の指定
- Cursorのワークスペースの出力先フォルダを指定します。私は以下の形式でフォルダを指定しています。
- 障害発生日_障害の要約(障害まとめファイルより取得)/incident_report.md
生成の流れの例（Few-shotプロンプティング）
- 「Chain-of-Thoughtプロンプティングを用いた障害報告書の生成」を実際に実行した際のLLMの処理の流れを例示します。これにより、LLMが具体的な作業イメージを持ちやすくなり、生成品質の向上が期待できます。
制約事項
- 生成時にLLMに守ってほしい事項を明記します。私は以下を指定しています。
- 入力情報から生成できない部分は、正直に「わからない」と記載すること
- 入力情報の解析に使用するツールの指定
参考程度にプロンプトおよび障害報告書のテンプレート（一部抜粋）を添付します
▪️Cursorルール
▪️障害報告書テンプレート（一部抜粋）
効果
障害報告書の作成時間が30〜40分から、5〜10分ほどに短縮できました。これによって、障害のポストモーテム完了後最短10分以内に関係者への展開が可能になりました。 また、テンプレートに沿って、視覚的情報や丁寧な文言で障害報告書が生成されるため、品質が向上しました。
これから効率化していきたいこと
最後に、統制者として今後効率化したいことを共有します。
ポストモーテムにおける重要論点の洗い出しと再発防止策の検討
一般に、障害対応には社内の複数ロールが関与します。そのため、障害のポストモーテムにも多様なメンバーが参加します。 ポストモーテムは障害を同じ原因で繰り返さない状態を作るために非常に重要なアクティビティです。一方で、上記の理由からポストモーテムに使える時間も限られています。 そのため、限られた時間のなかで障害の内容、原因、障害対応の流れをもとに振り返るべき重要な論点を絞り込み、再発防止策を打っていくことが重要です。統制者としても、最も困難なことの一つだと感じています。 そういった状況の中で、障害のまとめファイルや、議事録、Slackでのやり取りをもとに、LLMの客観的な目線で再発防止策を打つべき論点を洗い出し、優先度順に並べて整理してもらうことで、振り返る論点の明確化をサポートしてもらえるのではないかと考えています。
まとめ
今回はCursorを使って、社内向け障害報告書の作成を自動化してみました！ 障害は顧客にご迷惑をおかけしている状況だからこそ、生成AIを活用して障害対応のスピードを高め、ポストモーテムを効率化し、復旧の迅速化や障害発生率の低減に貢献していければと思っています。
最後までお読みいただきありがとうございました。この記事が少しでも皆さまの障害対応の一助になれば幸いです。
