WINTICKETにおけるインシデント避難訓練の仕組みと1年間の運用知見

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

WINTICKETにおけるインシデント避難訓練の仕組みと1年間の運用知見

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト