ライブサービスの障害対応で「誰が指揮を執るか」を先に決める――DeNAの演習事例から学ぶ初動体制の作り方

フィーチャーフォン向けモバイルゲームを運営していた頃、午前4時半のデイリーバッチ処理が失敗したことがある。アラートメールはプランナーとエンジニアの双方に届いていた。それでも「誰かが対処するだろう」という空気があり、誰も最初の連絡を始めなかった。復旧は朝8時までずれ込んだ。

これは編者自身の記憶に基づくエピソードであり、時刻を統計や監査記録として示すものではない。ただ、そこから得た教訓ははっきりしている。通知を受け取る人が複数いることと、対応を始める人がいることは別である。

この経験の後、チーフエンジニアを第一エスカレーション先とし、次にディレクターである編者が判断を担う体制を明文化した。現在では監視やオンコールの仕組みが広がり、ここまで素朴な放置は起きにくい。それでも、責任の所在が曖昧なら「誰かが動くはずだ」という力学が働くこと自体は変わらない。

本稿が扱うのは、障害が起きた直後に誰が指揮を執るかという体制設計と、その訓練方法である。復旧後の検証は 重大インシデント後のポストモーテムを設計する、個人情報が関わるときの最初の48時間は 個人情報漏洩・不正アクセスの初動フロー、プレイヤーへの補填は 「詫び石」を仕組みで設計する を参照してほしい。いずれも重要だが、初動の指揮者を決める仕事とは切り分けて準備する必要がある。

役割を決めるとは、指揮する人を一人決めることである

障害対応の指揮役は、一般にインシデントコマンダーと呼ばれる。ここでいう「指揮」は、最も難しい修正を自分で行うことではない。情報を集め、次の手を決め、誰に何を頼むかを明確にし、復旧までの進行を止めない役割である。

PagerDutyのインシデント対応ドキュメントでは、インシデントコマンダーは重大インシデント中の意思決定を担い、専門家から意見を得つつタスクを委譲する。通常時の役職にかかわらず、インシデント中は最上位の決定権を持つ。ログ調査や修正作業を本人が抱え込むのではなく、担当者へ任せることも明記されている。求められるのは深い技術知識ではなく、状況を判断して方針を決め、専門家の意見に応じて計画を変える力である。[1]

避難訓練にたとえると分かりやすい。火元の確認、誘導、安否確認、消防への連絡を一人で行う人はいない。しかし「今は避難を優先する」「Aさんはこのフロアを確認する」と決める人がいなければ、参加者は次の行動を選べない。ライブサービスの障害でも、調査、ロールバック、告知、CSへの共有を別々の人が担える一方で、優先順位と担当の割り当ては一つの判断として扱う必要がある。

全員招集は安心感を生むが、初動を遅くする

「関係者を全員呼べば、知識が集まって早く解決できる」と考えたくなる。しかし、最初から大人数で集まると、誰が決めるかが曖昧になり、作業や意思決定が遅くなる。サイボウズのkintone.com DevOpsチームは、障害通知を全員に送る体制で、大人数による速度低下と夜間招集による日中体制の手薄さを経験した。[2]

同チームは、最初にアラートへ反応した人を機械的にインシデントコマンダーとするルールに改めた。重要なのは、その人が最も深い専門知識を持つことではなく、意思決定者がその場に必ずいることである。必要な専門家は、その後に招集すればよい。[2]

小規模なゲームチームなら、次のように最低限の約束を置くことから始められる。

ここでの「最初に反応した人」は万能の正解ではない。夜間の当番、権限のある運営責任者、セキュリティ窓口など、組織の実情に合う代替ルールでもよい。大切なのは、アラートを見た人が「誰が決めるのか」をその場で話し合わなくて済む状態にすることである。

図：初動は、アラートを受けた後に事前ルールで指揮者を決め、影響確認と担当割り当てを進めてから、必要に応じて引き継ぎや追加招集を判断する。

DeNAは、事業のマネージャを対応のオーナーに置く

この考え方を組織的な訓練へ落とし込んでいる例が、DeNAの新任マネージャ向けインシデント対応ワークショップである。DeNAはこれを「避難訓練」や「防災訓練」の情報セキュリティ版と説明している。想定外の事態で、誰がどのように動くかを、実際に近い状況で試す場である。[3]

特徴は、セキュリティ部門がすべてを代行するのではない点にある。DeNAでは、DeNA CERTの支援を受けながら、当該事業に責任を持つ事業部のマネージャが対応をリードする。つまり、インシデント対応のオーナーはマネージャであり、セキュリティ部門は専門的な支援役として加わる設計である。[3]

これは「マネージャが技術的な原因を一人で解く」という意味ではない。サービス継続、プレイヤーや顧客への影響、関係部署との連携を見ながら、何を優先するかを決める責任を事業側が持つ、という意味である。ゲームでいえば、サーバー担当がログを調べ、プランナーがイベントやゲーム内経済への影響を整理し、CSが問い合わせを見ている間に、誰がサービスの停止・継続、告知、追加招集を判断するかを明確にする考え方である。

月1回、2時間の必須訓練を継続する

ワークショップは月1回、オンラインで実施され、1回あたり2時間である。対象はDeNAグループで新たに、または再び役職者となる従業者で、所属や職種を問わず受講が必須となっている。セキュリティ部（DeNA CERT）とコンプライアンス・リスク管理グループが運営し、日程を複数用意することで年間100名以上のマネージャが参加している。[3]

ここで注目したいのは、訓練を「一度受けたら終わりの座学」にしていないことだ。月ごとの開催枠を持つことで、忙しい新任・再任のマネージャが参加できるようにしている。事業の決定権を持つ人が、平時から対応の流れを知っている状態を、対象者の入れ替わりに合わせて維持しているのである。

シナリオは、不完全な情報から始まる

シナリオは世の中で実際に起きたインシデントを基に、DeNAの事業や組織、ルール、学んでほしい点を織り込んで作られる。当日は、架空のサービスで突然インシデントが起きたと告げるところから始まる。参加者は不完全な情報を前に、今すぐ何を確認し、誰へ依頼し、どのように判断するかを議論する。[3]

さらに議論の途中で、調査結果や問い合わせ急増といった新たな情報が予告なく加わる。実際の障害では、必要な情報が順番よく届くとは限らない。この仕掛けは、知識を再生できるかではなく、情報が不足した状態でも指揮と連携を始められるかを試すものだといえる。[3]

運営側も毎回、KPT（Keep、Problem、Try）で振り返り、内容や運営方法を更新している。参加者が訓練で学ぶだけでなく、訓練自体を繰り返し改善することで、組織の変化に合わせて初動体制を育てている。[3]

図：机上演習はシナリオ作成、実施中の情報追加、KPTによる振り返りを循環させ、次回の運営へ改善を反映する。

演習は、連絡先リストに載らない関係を作る

この種の演習には、手順の確認を超える効果もある。DeNAは、異なる部署や子会社のリーダーが2時間議論することで、普段は接点のない参加者の横のつながりが生まれると紹介している。その関係は、いざというときの早期報告や相談のしやすさにつながる。[3]

また、セキュリティ部門の担当者と同じ場で考える経験は、「困ったら相談してよい」という心理的な入口を作る。ルールを出す部署として遠くから見るのではなく、対応を助ける専門家として顔と役割を知ることで、相談の遅れを減らせる可能性がある。[3]

内製チームがなくても、机上演習から始められる

DeNAのように専門部門を置き、毎月継続する体制はすぐに再現できないこともある。だからといって、体制づくりを先送りする必要はない。最初の目標は、完璧なシナリオを作ることではなく、「この状況なら誰が指揮者になるか」をチームで試し、曖昧さを見つけることである。

IPAは2025年4月15日に、ランサムウェア感染を想定したセキュリティインシデント対応机上演習教材を公開した。一般企業、特に中小企業向けと医療機関向けの2種類があり、PowerPoint形式の座学パートと、グループで対応方針を検討する演習パート、実施マニュアルで構成される。自組織向けにカスタマイズして使うこともできる。[4]

ゲームスタジオでは、教材の舞台を自社のライブサービスに置き換えるとよい。たとえば「週末イベントの終了3日前に、ポイント交換画面が開けないという問い合わせが急増した」とだけ示す。その後で「特定のプラットフォームに偏っている」「一部の報酬付与が遅れている」と情報を足す。参加者には、次の三点を順に問いかける。

1. いまの指揮者は誰か。
2. 最初の15分で、誰に何を確認・依頼するか。
3. 何が分かったら、誰へ指揮を引き継ぐか、または追加招集するか。

答えの技術的な正しさを採点する必要はない。指揮者が空席になったか、作業を「誰か」ではなく名前で割り当てられたか、引き継ぎや招集の条件を言葉にできたかを確認すればよい。最初は30分でも十分である。演習で出た不明点を、連絡先、権限、ランブック、当番表へ一つずつ戻していく。

もう一つの足場として、日本シーサート協議会（NCA）は、サイバー攻撃演習訓練実施マニュアルを公開している。公開ページでは、演習の概要、具体的な実装方法、演習訓練マップを理解し、日々のCSIRT活動に生かすことを目的としている。ページの更新日は2023年3月22日である。[5]

DeNA CERTはNCAの加盟団体であり、このマニュアルの執筆にも参加した。DeNAは、自社ワークショップの運営で得た経験や知見も執筆へ反映したと説明している。大規模組織の内製演習と、外部へ公開された教材が切り離されているのではなく、実践から得られた知見が、他組織が始めるための足場へつながっている。[3]

まとめ：最初の一手を、平時に合意しておく

ライブサービスの障害対応では、優秀な人が偶然アラートを見ることに期待してはならない。必要なのは、最初の数分で指揮者を決め、担当を割り当て、必要な人を追加招集できる仕組みである。

インシデントコマンダーは、最も技術に詳しい人を意味しない。状況を見渡して決め、実作業は専門家へ委譲する役割である。事業に責任を持つマネージャがそのオーナーを担い、セキュリティ部門が支えるDeNAの設計は、ゲームチームにも重要な視点を与える。

まずは次の定例で、一つの架空シナリオを使って問いかけてほしい。「このアラートに最初に反応した人は、誰が指揮者だと分かるだろうか」。答えが一つに定まらないなら、それは失敗ではない。障害が起きる前に見つけられた、最も価値のある課題である。

References

1. インシデントコマンダー - PagerDuty Incident Response Documentationの日本語版。指揮者の意思決定、権限、タスク委譲、必要な能力を説明する。

2. 障害発生！全員集合？－オンコールアンチパターンからの一歩前進 - サイボウズのkintone.com DevOpsチームが、全員招集と意思決定者不在を改め、「最初にアラートへ反応した人」をインシデントコマンダーとするまでを紹介する。

3. 年間100名以上のマネージャが体験する、DeNAのセキュリティインシデント対応ワークショップの仕組みと狙い - DeNAセキュリティ部・竹浪氏による、マネージャを対応オーナーとする設計、運用、演習シナリオ、継続改善、NCAとの接続の紹介。

4. セキュリティインシデント対応机上演習教材 - IPAが公開する、中小企業向け・医療機関向けのランサムウェア感染シナリオによる教材と実施マニュアル。

5. サイバー攻撃演習訓練実施マニュアル - 日本シーサート協議会が公開する、サイバー攻撃を想定した演習・訓練の実施マニュアル。

この文書は、Perplexity、Claude、OpenAI Codex の3つのAIの支援を受けて著述されたものです。引用画像を除き、MIT License にて提供されています。