ChatGPTで生成したシナリオでインシデント対応の机上演習を行う方法

結論から言うと： 自社のシステム、取引先、データを概括的な表現でモデルに伝え、単一の事案説明ではなく、時刻付きのインジェクトを備えた90分のシナリオを作らせてください。この演習は「それについては手順がない」という瞬間を三つか四つ、確実に浮かび上がらせます。成果物はシナリオではなく、担当者と期日の付いた振り返りの指摘リストです。

多くのインシデント対応計画は、一度書かれ、承認され、保管され、二度と試されません。読めばよく書けています。対応チームが定義され、重大度が分類され、連絡系統図もあります。ただ一度もやっていないのは、時間の圧力の下、不完全な情報で、十二人が一つの部屋で実際に判断を下すことです。

机上演習の目的はそこにあります。計画が機能することを証明するためではなく、どこで機能しないかを見つけるためです。中小企業がこれを飛ばす理由は単純で、コンサルティング会社によるファシリテーション付き演習は相応の費用がかかり、自社で現実味のあるシナリオを書くのは本当に難しいからです。攻撃が内側からどう見えるか、時間単位でどう進むかを知っている必要があり、経験のない人が書くシナリオはたいてい綺麗すぎます。

これは言語モデルに向いた仕事です。シナリオ構築は形式のはっきりした執筆作業であり、モデルは膨大な数のインシデント報告を読んでいます。あなたの環境は知りませんし、部屋を仕切ることもできません。しかし「そもそも演習をやるかどうか」の最大の障壁を取り除きます。

試されていない対応計画が当日に破綻する理由

破綻の仕方は一貫していて、どれも技術力の問題ではありません。

誰がインシデントを宣言するのか、誰も知らない。 計画には「インシデント対応チームを招集する」とあります。日曜の22時に、その言葉を口に出す権限が誰にあるかは書かれていません。結果として最初の一時間は「これは本当にインシデントなのか」というチャットに費やされます。

連絡先リストが古い。 二人は退職済み、一つは誰も入れないオフィスの固定電話、そして計画そのものが、いま暗号化されたばかりのファイルサーバーに保存されている。計画がどこに置かれているかは、計画の一部です。

何を言うかを誰も決めていない。 顧客、従業員、保険会社、規制当局——そして増えつつある法域では、明確な時計の付いた通知義務。インシデントの最中に対外文を書くと、後悔するものが出てきます。事前に書けば20分です。

技術的対応の背後に事業判断がない。 封じ込めのためにERPを止めるのか、工場がその上で動いているのに。これはIT部門の判断ではなく、演習で誰かがこの判断を迫られた経験がなければ、本番では下手に、そして遅く下されます。

復旧が端から端まで試されていない。 バックアップはあります。それが復元できるか、主要システムの完全復元に実際どれだけかかるか、そしてバックアップ自体が侵害されたネットワークから到達可能かは、別々の三つの問いです。組織はその答えをインシデントの最中に知ることになりがちです。

机上演習は九十分でこの五つ全部を見つけます。やる理由はそれで十分です。

汎用テンプレートではなく、自社に合ったシナリオを生成する

「ランサムウェアの机上演習シナリオを」と頼めば、汎用的で居心地のよいものが返ってきます。居心地のよさは失敗状態です——部屋の誰も不確かさを感じていないなら、その演習は演劇です。

入力：自社のシステム、取引先、データ、そして現実的な攻撃者

モデルに四つを、概括的な表現で渡します。

何を動かしているか、機能で説明する。 「クラウドERP、ファイルサーバー、メール基盤、一拠点にオンプレミスの製造実行システム、そして分散した営業チームのリモートアクセス」。シナリオを地に足の着いたものにするのは機能と構成です。正確なバージョン、ホスト名、IPレンジは演習に何も足さないので、外に置いてください。

依存先を、カテゴリで挙げる。 委託先のIT事業者、給与計算のアウトソーサー、システム連携のある物流パートナー。サプライチェーンのシナリオが最も有用な部類なのは、対応の大半が非技術的で、しかもほとんど誰も予行演習していないからです。

痛むデータはどれか。 顧客の個人データ、設計図、価格、従業員記録。これがシナリオの通知・開示の分岐を決め、そこがたいていの組織の最も弱い場所です。

高度な攻撃者ではなく、現実的な攻撃者を。 よくあるのは、フィッシングによる認証情報の窃取、未修正のインターネット公開サービス、あるいは侵害された取引先アカウントです。あなたの規模と業種の会社にとって妥当な侵入経路を前提にしたシナリオを、と明示的に求めてください。国家支援型の相手はむしろ悪い演習です。そのインジェクトの大半に対する正直な答えが「誰かを呼びます」になるからです。

そのうえで、実際に部屋にいるのは誰か——IT責任者、運用、経理、人事、役員——を伝え、それぞれに判断を迫るインジェクトを書くよう求めます。ITがすべての問いに答える演習は、組織について何も試していません。

インジェクトとエスカレーション：九十分間、居心地の悪さを保つ設計

本物の演習と単なる議論の構造的な違いは、時刻付きのインジェクトにあります。一定の間隔で新しい情報が出され、状況が変わり、しばしば直前の判断を無効にします。

九十分に六つから八つのインジェクトを、それぞれ時刻、明かされる情報、そしてそれが引き出すために設計された判断とともに求めます。良い流れは三つの軸で同時に上がっていきます——技術的な範囲、事業影響、外部からの圧力。たとえば、アラート、次に三日前から始まっていた証拠、次に業務システムの不調、次に顧客からの直接の問い合わせ、次にデータが外に出た証拠、そして期限。

二つの指示でシナリオは目に見えて良くなります。対立を生むインジェクトを求めること——複雑さではなく。運用は復旧させたい、セキュリティは隔離したい、その瞬間こそ予行演習の価値があります。実際に争われる判断だからです。そして良い答えのないインジェクトを最低一つ、どの選択肢にも代償があるものを求めること。本物のインシデントはそれでできており、練習の意義は「一度そういう判断をしたことがある」状態を作ることです。

シナリオ文書はファシリテーターだけが持ちます。参加者が受け取るのは最初のインジェクトだけです。

実例：従業員120名の企業のランサムウェア机上演習

オフィスと工場を持つ製造業。クラウドERP、オンプレミスのファイルサーバーとMES、そして委託先のIT事業者。九十分、八名、ファシリテーター一名。

T+0。 二名の従業員がファイルを開くとエラーになると報告、ヘルプデスクにチケットが三件。まだ何も確認されていません。*引き出すもの：これはインシデントか、そして誰が決めるのか。*

T+10。 ファイルサーバーが応答せず、共有フォルダに身代金要求文が現れます。*引き出すもの：封じ込め。拠点ネットワークを隔離するか、工場が接続を失うことを誰が承認するのか。*

T+25。 ログは、初期侵入が九日前、委託先のリモートアクセスアカウント経由であったことを示唆します。*引き出すもの：取引先との会話、そして普段なら助けを求める相手が、いまインシデントの内側にいるという居心地の悪い認識。*

T+40。 MESが劣化し、工場の責任者がラインを止めるべきかと尋ねます。*引き出すもの：実際の時間あたりコストを伴う事業判断を、IT以外の人間が下すこと。*

T+55。 顧客が図面への影響を問うメールを送り、同時に記者が代表番号に電話してきます。*引き出すもの：対外コミュニケーション、そしてそもそも誰かが話す権限を持っているのか。*

T+70。 暗号化に先立つデータ持ち出しの証拠。*引き出すもの：通知義務、保険会社への連絡、法務——多くのチームが一度も歩いたことのない分岐。*

T+80。 バックアップ管理コンソールが、侵害されたドメインに対して認証している。*引き出すもの：直前の八十分間、全員が拠り所にしていた復旧の前提。*

実際にやると、この演習は多くの組織で同じ短いリストを生みます。指名されたインシデント指揮者がいない、帯域外の連絡手段がない、主要システムの復元時間が試されていない、顧客向けの文面が用意されていない。どれも予算が要る問題ではありません。しかしインシデントの最中に着手すれば、どれも数週間かかります。

AI生成のシナリオ vs ファシリテーション付き演習 vs 既製テンプレート

• 費用と実施までの時間 — AI生成シナリオの決定的な勝ち。準備一時間、外部費用なし、年一回ではなく四半期に一回実施できます。
• 実際の環境への適合 — AI生成シナリオはテンプレートに明確に勝ち、実際の文脈を与えればファシリテーション付き演習に迫ります。テンプレートが描くのは一般的な会社、モデルが描くのはあなたの会社です。
• 部屋の中の圧力 — ファシリテーション付き演習の勝ち。熟練した外部のファシリテーターは居心地のよい答えに反論し、誰が誰に委ねているかに気づき、「それはITが対応します」でインジェクトを片づけさせません。
• 組織の力学を読むこと — ファシリテーターの絶対的な勝ち。最も価値ある発見はたいてい権限とためらいに関するもので、経験ある外部者には見えても、同僚が仕切る場では見えにくいものです。
• 保険会社や監査に対する信頼性 — ファシリテーション付き演習の勝ち。独立した報告書は社内議事録にはない証拠力を持ちます。とはいえ、実際に行った演習の良い社内記録は、何もないよりはるかにましです。
• 既製テンプレート — 手間の少なさだけで勝ちます。生まれるのは演習ではなく議論です。自分たちのために書かれていないことが全員に分かるからです。

多くの中小企業にとって賢い進め方は二択ではありません。AI生成の演習を四半期ごとに回して安く筋肉をつけ、明白な穴を見つけ、年に一度——あるいは大きな監査の前に——ファシリテーターを入れて独立した目を通す。安いほうをやっておくと、高いほうの生産性がはるかに上がります。ファシリテーターの時間が、自分でも見つけられた指摘ではなく本当の弱点に使われるからです。

振り返りこそが成果物

演習そのものが目的ではありません。全員がまだ部屋にいるうちの三十分の振り返りが、価値が実際に生まれる場所であり、そして時間の都合で最も削られやすい工程です。

三つの問いで進めます。何をどうすればよいか分からなかったか。何を前提にしていて、それが未検証だったか。これが本物だったら、何を間違えていたか。

そして答えのそれぞれを、担当者名と期日の付いた指摘に変換します。「コミュニケーションを改善する」ではなく、「顧客向けの待機文面を作成し、三週間以内に社長の承認を得る、担当は誰々」。テーマの一覧しか生まない机上演習は何も生んでいません。担当者の付いた八つのアクションを生む演習は、作業計画を生んでいます。

指摘の集まり方は予測できます。権限とエスカレーション、帯域外の連絡、復旧時間の前提、第三者への依存、そして通知義務。あなたのリストがそう見えるなら、演習は機能しています。部屋を出る前に次回を予定し、六か月後に同じシナリオを再実施してください。二回目は修正が実際に定着したかを試すもので、それは新しいシナリオにはできません。

正しく進めるために——環境を安全に説明する方法と、いつITを入れるか

実務上の3点。

環境は鑑識的にではなく、機能的に説明する。 「オンプレミスのファイルサーバーとクラウドERP」と、ホスト名、IPレンジ、ファームウェアのバージョン、管理者アカウント名が入った文書との間には実質的な差があります。前者だけで良いシナリオには十分です。後者は第三者サービスの中に置かれた偵察資料です。契約上のデータ取り扱い条件がある法人向け階層を使い、シナリオを実システムに対応づけた版は自社の文書に留めてください。

シナリオを影のリスク評価にしない。 机上演習が教えるのは「どう対応するか」であって、「どれだけ露出しているか」ではありません。別の問いであり、前者にうまく答えることが後者について誤った安心を生むことがあります。指摘は、優先順位が付き、フレームワークに対応づけられた視点に流し込む価値があります——それがBrocentのITリスク評価が生むものです。ISO 27001、NIST CSF、CIS Controlsに対応づけたベンダー中立の評価と、取締役会に出せる報告書、そして90日・6か月・12か月の改善ロードマップ。机上演習の次に来るべき成果物は、もう一度の演習ではなくこれです。

運用面の指摘は、実際にITを回している相手と一緒に潰す。 帯域外の連絡、検証済みの復元時間、特権アクセスの棚卸し、取引先アクセスの制御は通常の業務であり、当社のAI+サポートとマネージドITサポートが担う領域です。Brocentは2007年の北京での創業以来アジア全域の顧客を支援してきました。本社はシンガポール、2016年から香港にオフィスがあります。人の側の備えについては、フィッシング訓練プログラムがこれらのシナリオの多くが始まる入口そのものを試し、AIによるフィッシング検知が同じ問題の技術面を扱います。

よくある質問

シナリオを作るために自社インフラをAIに説明するのは安全ですか？

どこまで説明するか次第です。機能的な説明——「クラウドERP、オンプレミスのファイルサーバー、委託先のIT事業者」——はほとんどリスクがなく、しかもシナリオに必要なのはそれで全部です。ホスト名、IPレンジ、ファームウェアのバージョン、アカウント名、ネットワーク図は別の話であり、演習には何も足しません。個人アカウントではなく契約上のデータ取り扱い確約がある法人向け階層を使い、シナリオと実システムの対応づけは自社の文書に留めてください。

誰が部屋にいるべきですか？

ITだけでは足りません。演習が試すのは組織の意思決定なので、システムを止める承認ができる人、顧客に話す人、従業員向けの連絡を担う人、そして金額の伴う判断を下せる役員が必要です。八名から十二名が扱いやすい規模です。すべてのインジェクトにITが答えているなら、そのシナリオは組織を試していません。他の役割に判断を迫るよう、インジェクトを書き直してください。

どのくらいの頻度でやるべきですか？

自分でシナリオを生成するなら四半期ごと——準備が一時間で済むなら現実的です。最低でも年一回、そして大きな変化のあと（基幹システムの入れ替え、買収、IT事業者の変更、実際のインシデント）。六か月後に同じシナリオを再実施するのは過小評価されています。前回の指摘が本当に閉じたかを試せる方法であり、新しいシナリオにはできないことです。

これは保険会社や監査人の要求を満たしますか？

場合によりますし、相手が何を求めたか次第です。多くの保険会社やフレームワークは「インシデント対応が試されているか」を問い、証跡を求めます——日付、参加者、シナリオ概要、指摘、改善状況の記録を残せば、社内実施でも十分に応えられます。独立した評価や正式な報告書が明示されている場合、社内ファシリテーションの演習では代替になりません。どちらにも決めつけず、要求の原文を読んでください。

指摘はどう扱えばよいですか？

誰かが部屋を出る前に、担当者と期日の付いたアクションへ変換し、次の演習ではなく決まった時点で確認します。権限、帯域外の連絡、復旧時間の前提、第三者アクセスのあたりに集まるはずです。多くは費用ではなく時間のかかるプロセス修正です。検証済みの復旧能力がない、調査に足るログがないといった構造的な穴を指す指摘は、アクションリストではなく優先順位の付いた改善計画に属します。

最初の一歩

四つの入力を書き出してください——機能で並べた自社のシステム、重要な取引先、痛むデータ、そして現実的に想定される侵入口——そして九十分のランサムウェアのシナリオを一つ生成します。書く前に会議室を押さえてください。予定に入った演習だけが実際に行われます。振り返りで、プロセスだけでは埋まらない穴が出てきたなら、そこが「もう一度の演習より、優先順位の付いた改善計画のほうが価値がある」地点です。お問い合わせください。