目次
この記事で学べること
- インシデント対応の属人化を解消するための避難訓練の設計と運用方法
- ビジネスメンバーと協働するための GUI ツール選定の考え方
- 過去のポストモーテムを AI で活用し、リアルなインシデントシナリオを自動生成する手法
想定読者
- インシデント対応力の底上げに課題を感じているエンジニア・EM
- ノーコード/ローコード AI ツールの実践的な活用例を探している方
はじめに
WINTICKET 開発責任者の織田（@0daryo）です。
WINTICKET では、サービスの迅速な復旧のためにインシデント発生時は職種を問わず対応に当たる文化があります。
新しいメンバーにもこの動き方を身につけてもらうため、Slack Bot によるインシデント避難訓練を 1 年以上運用してきました。
本記事では特にビジネスメンバーを対象とした訓練にフォーカスし、ツール選定の背景や AI シナリオ生成の工夫、運用から得られた知見を紹介します。
背景と課題
WINTICKET のインシデント対応体制
WINTICKET では、インシデント対応における役割として IC（Incident Commander）と OL（Operations Leader）を独自に定義しています。
- IC（指揮官）：インシデント全体の把握・意思決定を担い、ステークホルダーへの報告やユーザー告知の判断を行う。作業はなるべく避け、対応チーム全体のファシリテートに徹する
- OL（対応責任者）：インシデント対応の現場指揮を担い、IC と連携しながら調査・対応を推進する。職種を問わず、インシデントの内容に近い業務を担当するメンバーが務めることが多い
対応フローは以下のとおりです。
- アラートや CS への問い合わせで事象を検知
- 発見者が Slack でコマンドを実行し、Warroom（専用のインシデント対応チャンネル）の立ち上げと IC・OL の選出を行う
- IC の指揮のもと、OL が現場の調査・対応を推進。インシデント重要度レベルや対応方針を決定する
- 復旧後、IC が Warroom で復旧を宣言
- ポストモーテムを実施し、再発防止策を確定
IC・OL はエンジニアだけでなく、プロダクトマネージャーやビジネスメンバーも担当します。インシデントの重要度や影響領域に応じて担当者が変わり、対応中の交代も可能です。
課題
幅広いメンバーが IC や OL を担えるのが理想ですが、組織の拡大や異動に伴い、対応経験が古参メンバーに偏りつつありました。新メンバーはインシデント対応を本番で初めて経験することになり、心理的なハードルも高い状態です。
そこで、2 つの目的で避難訓練の仕組みを立ち上げました。
- IC・OL を担当できるメンバーを増やす
- 誰でもインシデント対応をサポートできるようになる
ゴールは「明日からインシデントに入れそう」と参加者が思えることです。評価とは一切関係なく、純粋にインシデント対応を体験してもらうための取り組みとして位置づけています。
避難訓練の全体像
避難訓練はすべて Slack 上で完結します。参加者は 2 名 1 組で、50 分程度で実施します。IC は主に元から所属しておりインシデント時の役割を広げたいメンバー、OL は新規にジョインしたメンバーが担当する形で役割を分担しています。
訓練の流れ
- Slack チャンネルで
@incident-training-bot 避難訓練開始とメンションする - Bot が過去のポストモーテムを元に架空のインシデントシナリオを生成し、初報として投稿する
- 参加者は IC役とOL役 として指揮を取りながら、Bot を通じて各分掌に問い合わせる
- 事実確認と情報の整理、考察、対応方針の 3 点をテキストで投稿したら訓練終了
各分掌への問い合わせは、@incident-training-bot server-inc 〇〇を確認してください のようにBotへメンションする形式です。CS（cs-inc）、サーバー（server-inc）、アプリ（app-inc）、WEB（web-inc）の4つの分掌に対応しています。
n8n が Slack のメンションを Webhook で受け取り、Dify の Chat API を呼び出します。n8n の役割はメッセージの受信・API リクエストの組み立て・会話 ID の管理で、シナリオ生成や分掌別の応答は Dify 側で処理します。
IC・OLの役割
IC はメンバーに指示を出しながら全体の指揮を取ります。影響範囲の確認をエンジニアに依頼したり、ユーザー対応の草案作成を指示したりと、情報を整理して意思決定を行う役割です。
OLは IC の指示を受けて手を動かしつつ、「この情報も必要ではないですか？」「ユーザー対応どうしますか？」といった提案も積極的に行います。
GUIベースのツールを選定した理由
本プロジェクトはマーケティングチームと一緒に進めました。当初は自前実装も検討しましたが、最終的に n8n（ワークフロー自動化）と Dify（LLM アプリケーション構築プラットフォーム）を採用しています。
決め手は 2 つあります。
ビジネスメンバーが直接触れること
シナリオの妥当性や Bot の応答品質を判断できるのは、実際にユーザーと接しているビジネスメンバーです。
GUI ベースのツールなら、プロンプトの更新や訓練フローの調整をビジネスメンバー自身で行えます。エンジニアがボトルネックにならない体制を作りたかったので、ここを重視しました。実際にマーケティングチームのメンバーが訓練シナリオの妥当性を議論したり、Bot の応答が実務と乖離している箇所のプロンプトを自ら修正したりと、運用改善の主体になっています。
エンジニアの視点では自前サーバーの方が管理しやすいと感じる場面もありましたが、複数のビジネスメンバーが関わるプロジェクトではメンテナンス性の観点から GUI ツールの選定は正解だったと考えています。
AIによるシナリオ生成が必要だったこと
後述しますが、リアルなインシデントシナリオを毎回手動で作成し続けるのは現実的でありません。過去のポストモーテムをナレッジとして活用し、AI でシナリオを自動生成する仕組みが必要でした。Dify の RAG機能なら、ナレッジベースの構築からチャットフローの設計まで GUI 上で完結でき、これが採用の決め手になりました。
AIによるシナリオ自動生成の工夫
手動作成の限界
避難訓練を始めた当初、過去の実際のインシデントを元に手動でシナリオを作成していました。しかし、新規メンバーが加わるたびにシナリオを用意する運用は持続が難しく、仕組み化が必要でした。
そこで、Kibela に蓄積されたポストモーテムを Dify の Knowledge 機能に保存し、過去事例をベースに LLM が架空のインシデントシナリオを自動生成する仕組みへ移行しました。ナレッジにはポストモーテム 1 件を 1 ドキュメントとしてそのまま登録しており、事象・影響範囲・原因・対応内容を含む情報がベクトル検索で取得されます。
初報の情報設計
シナリオ生成で最も工夫した点は、初報として正解を与えすぎないことです。
実際のインシデントでは、最初の報告時点ですべてが判明しているわけではありません。この不確実さを再現するために、初報には以下の情報を断片的に含めつつも、事象の詳細や原因、対応方針は含めない設計としました。
- いつ発生したか
- 対象ユーザーの環境（OS・アプリバージョンなど）
- 対象ユーザーの状態（ログイン状況・登録直後・ステージなど）
- 対象ユーザーのアクション（投票・招待・チャージなど）
- 影響を受けたユーザー数の概算
- 問い合わせ件数
参加者はこの初報をもとに各分掌へ問い合わせ、自ら原因を特定し対応方針を立てる必要があります。
分掌別LLMによる情報の非対称性
Dify のワークフロー上では、ユーザーの入力を IF-ELSE ノードで判定し、問い合わせ先の分掌に応じて異なる LLM ノードへ振り分けています。
各分掌のLLMには、それぞれの担当領域に特化したシステムプロンプトが設定されています。サーバー担当であればK8sやGolangの知識をベースに回答し、アプリ担当であればFlutterやOS・バージョンの観点で回答します。重要なのは、担当外の質問には「わからない」と返すように設計している点です。
実際のインシデントでも、各チームは自分の担当領域しか把握していません。訓練でもこの非対称性を再現し、IC が誰に何を聞くべきかを考える練習にしています。
生成されたシナリオは Dify の会話変数に保存され、訓練中のどの問い合わせに対しても整合性のある回答が維持されます。
回答品質の維持
LLM を使う以上、回答の整合性やリアリティの維持は課題になります。初期には、生成されたシナリオと各分掌 LLM の回答に矛盾が生じたり、実務からかけ離れた内容が返ったりするケースがありました。
対策として、訓練のたびにマーケティングチームが Bot の応答を確認し、不自然な点があればプロンプトを調整しています。受講者に近いメンバーが直接チューニングできる GUI ツールを選んだことが、ここでも効いています。
運用成果とフィードバック
実績
1 年以上の運用を通じて、ビジネスメンバーを中心に 10 人以上が避難訓練を体験しました。参加者は中途入社・新卒入社・異動者と幅広く、いずれもインシデント対応が初めてのメンバーです。
参加者の声
訓練後のフィードバックでは、以下のような声が寄せられました。
ポジティブなフィードバック
- 「IC をやることで主体的になれた。OLに何を助けてほしいかも分かった」
- 「アプリのバージョンや OS など、確認すべき観点が実務に活かせそう」
- 「お知らせ記事を書くところまで体験できたのが良かった」
- 「IC がちょっとできそうだなと思えた」
改善に向けたフィードバック
- 全体の流れが事前に把握しにくく、何をしていいか分からない場面があった
- 時間制限が明示されていないと緊張感が薄い
これらのフィードバックを受け、以下の点を改善しました。
フィードバックを受けた改善
インシデント対応の流れを整理し、訓練で体験してもらう形にした
「何をしていいか分からない」という声に対し、インシデント対応の流れを 3 つのステップに整理しました。訓練ではこの流れに沿って実際に手を動かしてもらう構成としています。
-
事実確認と情報の整理
- 影響範囲の確認
- 対象ユーザーの環境（OS・アプリバージョン等）
- 対象ユーザーの状態（ログインステータス・ステージ等）
- 対象ユーザーのアクション（投票・招待・チャージ等）
-
考察
- 重要度（severity）の判定
- 要因の特定
-
対応方針
- 暫定対応
- ユーザー個別対応（カスタマーサポート部門との連携）
- ユーザー全体対応（お知らせ記事の作成・投稿判断）
- 恒久対応
この 3 点をテキストでチャンネルに投稿してもらうことで、訓練のゴールも明確になりました。
50 分の時間制限を設けた
「緊張感が薄い」という声を受け、50 分という時間制限を明示するようにしました。実際のインシデントでも限られた時間で判断を迫られるため、その緊張感を再現する狙いです。
実インシデントでの効果
訓練を受けたメンバーが、近日中に発生した実際のインシデントで warroom（インシデント対応の集中対応チャンネル）に参加し、調査を手伝うことができたケースもありました。訓練で warroom の立ち上げ方や各分掌への連携方法を体験していたことが、本番でのスムーズな参加につながっています。
避難訓練を導入する以前は、IC を担える人材が限られており、特定のメンバーに負荷が集中していました。訓練を経た現在では、IC 経験者が着実に増え、インシデント発生時に「誰が入るか」で悩む場面が減りつつあります。
今後の展望
現在の避難訓練は主にビジネスメンバーを対象としていますが、今後はエンジニア向けのシナリオも展開していく予定です。Datadog 等の MCP を活用し、メトリクスやログの調査を含むより技術的な訓練シナリオを検討しています。
また、現在は 2〜3 名での実施が基本ですが、ビジネスメンバーとエンジニアが混成チームを組んで演習する形式への拡張も計画しています。実際のインシデント対応により近い体制で訓練することで、チーム間の連携もスムーズになることを期待しています。
まとめ
本記事で紹介した取り組みをまとめます。
- インシデント対応の属人化という課題に対し、Slack Bot を活用した避難訓練の仕組みを構築した
- ビジネスメンバーと協働するために GUI ベースのツール（n8n・Dify）を選定し、プロンプトのチューニングまでビジネスメンバーが主体的に行える体制を実現した
- 過去のポストモーテムを RAG で活用し、初報として正解を与えすぎないリアルなシナリオを自動生成する仕組みを設計した
- 1 年以上の運用で 10 人以上が体験し、実際のインシデント対応にも効果が見られた
インシデント対応力の底上げに取り組む現場の参考になれば幸いです。