セキュリティの机上演習（Tabletop Exercise／TTX）とは、サイバー攻撃や情報漏えいなどの想定シナリオをもとに、参加者が「誰が、何を判断し、どの部門と連携するか」を議論する訓練です。
実際のシステムへ攻撃を加える訓練ではなく、インシデント対応手順、報告経路、経営判断、復旧優先順位、社外公表などが有事に機能するかを確認します。
IPAは2025年4月、ランサムウェア感染を想定した「セキュリティインシデント対応机上演習教材」を公開しました。NIST Cybersecurity Framework 2.0でも、机上演習やシミュレーションなどの結果からインシデント対応を改善し、必要に応じて経営層、法務、人事、重要な委託先を演習へ参加させる例を示しています。
600～3,000人規模の企業では、情シスやCSIRTだけで技術対応を確認するより、法務、広報、事業部門、経営層まで含め、「情報が不足した状態で何を決めるか」を確認する使い方が実務に合います。
机上演習とは
机上演習は、想定されたインシデントに対して、参加者が会議形式で対応方針を検討する演習です。
たとえば、次のような状況を段階的に提示します。
- VPNやSaaSへの不審なログインを検知した
- ファイルサーバーの一部が暗号化された
- 委託先から「不正アクセスの可能性がある」と連絡が入った
- 顧客情報へアクセスされた可能性が判明した
- 取引先から説明を求められた
- 復旧見込みが24時間から3日に延びた
参加者は、その時点で分かっている情報だけを使い、次の行動を決めます。
机上演習で確認するのは、攻撃手法の知識だけではありません。
- インシデントを誰が宣言するか
- 経営層へいつ報告するか
- どのシステムを止めるか
- 事業を継続するか停止するか
- 誰が顧客・取引先へ説明するか
- 個人情報保護委員会などへの報告要否を誰が判断するか
- 復旧順位を誰が決めるか
- 外部のフォレンジック会社、弁護士、警察へいつ相談するか
といった組織横断の判断を確認します。
机上演習とセキュリティ教育・実動訓練の違い
机上演習は、一般的なセキュリティ教育や技術演習とは目的が異なります。
| 手法 | 主な目的 | 参加者 | 実環境への操作 |
|---|---|---|---|
| eラーニング・集合研修 | 知識の習得 | 全社員など | 原則なし |
| フィッシング訓練 | 行動確認 | 一般社員 | 模擬メール等を利用 |
| 机上演習 | 判断・連携・手順の検証 | 情シス、CSIRT、法務、広報、経営層等 | 原則なし |
| 技術演習・サイバーレンジ | 検知・分析・封じ込め技能 | SOC、CSIRT、技術担当 | 演習環境で実施 |
| ペネトレーションテスト | システムの脆弱性・侵入可能性の評価 | 診断担当、技術担当 | 許可された範囲で実施 |
セキュリティ教育については、セキュリティ教育とは？重要性・必要性や実施手順を解説で整理しています。
机上演習は、知識を覚えるより「実際に自社で判断できるか」を確認する位置付けです。
なぜ机上演習が必要なのか
インシデント対応手順書があっても、有事にその通り動けるとは限りません。
実際のインシデントでは、初動段階で事実がすべて揃うことは少なく、次のような不確定な状態で判断が必要になります。
- 不正アクセスは確認したが情報流出は不明
- システム停止の範囲は分かるが復旧時間は不明
- 委託先から第一報だけ届き詳細ログは未入手
- 攻撃者がデータ窃取を主張しているが真正性は未確認
- バックアップはあるが安全に復元できるか未確認
机上演習では、この「分からない状態」をあえて残します。
答えが出そろった事故報告書を読むだけでは、誰が追加情報を集め、どの時点で暫定判断を出すかまでは確認できません。
IPAはランサムウェアの机上演習教材を公開
IPAは2025年4月15日、一般企業と医療機関を対象にした「セキュリティインシデント対応机上演習教材」を公開しました。
教材は、
- インシデント対応の基本を学ぶ座学
- ランサムウェア感染を想定したグループ演習
- 事前準備、当日運営、事後作業を説明する実施マニュアル
で構成されています。
セキュリティ対策Labでも、IPA、ランサムウェアを想定した「セキュリティインシデント対応机上演習教材」を公開で内容を整理しています。
初めて机上演習を実施する企業は、IPA教材を基礎にして、自社のシステム構成、組織、委託先、報告経路へ置き換える方法が使えます。
NIST CSF 2.0も演習結果からの改善を示す
NIST Cybersecurity Framework 2.0のImplementation Examplesでは、ID.IM-02として、セキュリティテストや演習から改善点を見つける例を示しています。
例には、
- 机上演習やシミュレーション等からインシデント対応を改善する
- 重要なサービス提供者や製品サプライヤーと事業継続・復旧・インシデント対応演習を行う
- 必要に応じて経営層、法務、人事などを演習へ参加させる
といった内容が含まれます。
机上演習はCSIRTだけの訓練ではなく、サプライチェーンと経営判断を含む改善活動として使えます。
机上演習で確認したい6つの領域
1. 検知とインシデント宣言
最初に確認するのは、「どの状態から重大インシデントとして扱うか」です。
SOCがアラートを検知しても、事業部門や経営層へ共有する基準がなければ対応が遅れます。
確認する項目：
- インシデント宣言の基準
- 責任者
- 夜間・休日の連絡先
- CSIRT招集条件
- 証拠保全の開始条件
2. 封じ込めと事業影響
ネットワーク遮断やアカウント停止はセキュリティ上有効でも、業務を止める可能性があります。
演習では「止める／止めない」ではなく、誰が事業影響を評価し、どの権限で遮断を決めるかを確認します。
3. 影響範囲の把握
個人情報、機密情報、製造、物流、決済など、影響を受けた対象を整理します。
ここでは「何件漏えいしたか」ではなく、「まだ漏えいが確定していない段階で何を調べるか」を設問にします。
4. 社内外への報告
法務、広報、経営、個人情報保護担当、取引先担当などがいつ参加するかを確認します。
報告先が多い企業では、窓口と承認者を決めておかないと、情報が部門ごとに異なる状態になります。
5. 復旧と事業継続
復旧優先順位は技術部門だけで決められません。
ERP、受注、工場、メール、ファイルサーバーが同時に使えない場合、「技術的に復旧しやすい順」ではなく「事業継続上の優先順位」で決める必要があります。
6. 振り返りと改善
演習後は、「正解だったか」より、判断できなかった理由を記録します。
- 連絡先が古かった
- 委託先との事故連絡条件が曖昧だった
- 誰が社外公表を承認するか決まっていなかった
- バックアップの復旧時間が分からなかった
- 顧客データの保存場所を把握できなかった
こうした項目を改善計画へ落とします。
机上演習の進め方
一般的には次の流れで設計できます。
| 手順 | 実施内容 |
|---|---|
| 1 | 演習目的を1～3個に絞る |
| 2 | 対象業務・システムを決める |
| 3 | 参加部門と役割を決める |
| 4 | シナリオと追加情報を作る |
| 5 | 当日、段階的に情報を提示する |
| 6 | 判断内容と不足情報を記録する |
| 7 | 改善事項、担当者、期限を決める |
NIST SP 800-84も、ITに関するテスト・訓練・演習について、設計、開発、実施、評価までを一連のプログラムとして扱っています。
参加者は誰にするか
目的によって変えます。
初動対応中心：
- 情報システム
- CSIRT
- SOC
- IT運用
- セキュリティ担当
情報漏えい中心：
- 情報システム
- 個人情報保護担当
- 法務
- 広報
- 顧客対応
事業停止中心：
- 経営層
- 情報システム
- 事業部門
- BCP担当
- 広報
- 財務・経理
委託先事故中心：
- 情報システム
- 調達
- 法務
- 委託先管理部門
- 個人情報保護担当
経営層向け演習については、別記事として「経営層向けサイバーセキュリティ机上演習」で扱う構成にすると検索意図を分けられます。
セキュリティ対策Labの実インシデントを演習へ変換する例
実際の事故をそのまま再現する必要はありません。
公表済みの事実を「自社なら何を判断するか」という設問へ変換します。
| 公表事例 | 確認された事実 | 演習用の架空設問例 |
|---|---|---|
| Boston Scientific | サイバーインシデントで製造・注文処理・出荷に影響 | 「受注システムが停止し、出荷遅延が拡大。どの業務を手作業へ切り替えるか」 |
| 大阪・関西万博 | 再委託先M365への不正アクセス、情報に漏えい等のおそれ | 「再委託先から第一報だけ届いた。何の証跡を何時間以内に要求するか」 |
| ワシントンホテル | ランサムウェア感染、業務データ復旧を継続 | 「予約・決済・社内管理の一部が利用不能。顧客向け営業継続条件を誰が判断するか」 |
関連記事：
上表の「演習用の架空設問例」は実際の各社対応を示すものではありません。公表された事実を参考に、自社の判断確認へ置き換えた例です。
無料で使える机上演習資料
社内で初めて実施する場合は、公開教材を利用できます。
IPA
一般企業・医療機関向けのランサムウェアシナリオ、実施マニュアルを公開しています。
CISA
米CISAはCybersecurity Tabletop Exercise Packages（CTEP）として、ランサムウェア、内部脅威、フィッシング、ICS侵害などのシナリオと、進行役向け資料、参加者フィードバック、After Action Reportのテンプレートを公開しています。
セキュリティ対策Lab
セキュリティインシデント対応 机上演習シナリオ｜不正アクセス編・ランサムウェア感染編では、不正アクセスとランサムウェアの2シナリオを扱っています。
机上演習で測定したい指標
「参加者が盛り上がった」「勉強になった」だけでは、改善につながりません。
次のような指標を残します。
- インシデント宣言までの判断時間
- 経営層へのエスカレーションまでの時間
- 連絡不能だった担当・委託先の数
- 担当者が決まっていない判断項目数
- 追加で必要になったログ・台帳・契約書の数
- 実行できないと判明した手順数
- 演習後の改善項目数
- 改善項目の期限内完了率
机上演習の成果は、演習中の「正解率」より、演習後に対応手順が変わったかで評価します。
机上演習でよくある失敗
シナリオを難しくしすぎる
高度な攻撃手法を盛り込んでも、参加者が判断する場面がなければ演習になりません。
答えを一つに決める
現実のインシデントでは、事業継続、法務、顧客影響を踏まえて複数の選択肢を比較します。
情シスだけで完結する
外部公表、顧客対応、業務停止を扱うなら、情シスだけでは実際の意思決定を再現できません。
演習後の改善を管理しない
After Action Reportを作っても、担当者と期限がなければ翌年も同じ課題が残ります。
情報システム部門が確認したいポイント
- インシデント対応手順を年1回以上実際に使っているか
- 夜間・休日の連絡先を演習で確認したか
- 経営層、法務、広報を含めた訓練を行っているか
- 委託先事故を想定したシナリオがあるか
- 情報流出が「未確定」の段階での報告判断を確認したか
- 復旧優先順位を事業部門と合意しているか
- 演習後の改善項目に担当者と期限を設定しているか
机上演習は、手順書を覚える訓練ではありません。
手順書、組織、委託先、経営判断が実際につながるかを確認し、止まった箇所を平時に修正するための演習です。
