Gemini で IT 環境から事業継続計画の初稿を作成する方法

結論から先に：多くの中小企業はバックアップが機能していても、書かれた事業継続計画（BCP）を持っていません。その欠落は、顧客・保険会社・監査人が文書を求めた瞬間に初めて表面化します。Gemini は、自社 IT 環境の平易な説明を、説得力のある初稿——適用範囲、RTO と RPO の目標、復旧順序、役割、連絡体制——に、四半期ではなく半日で変えられます。できないのは、それらの目標が達成可能かを検証することです。演習していない計画は文書であって、能力ではありません。

シンガポールの 90 名規模の建築設計事務所は、バックアップが実際に機能しています。Veeam がオンプレミスのファイルサーバーとプロジェクトデータベースに対して毎晩実行され、Microsoft 365 には別途サードパーティのバックアップがあり、IT マネージャー自身が個別ファイルの復元を十分な回数こなしていて、この仕組みを信頼しています。

そこへ政府系の顧客から更新されたベンダー資料一式が届き、これまでになかった一行が含まれていました。事業継続計画を提出すること、顧客データを保持するシステムの復旧時間目標を含めること。入札回答の期限は三週間後。

文書はありません。あるのはバックアップのスケジュール表、監視ダッシュボード、そして一人の頭の中にある大量の知識です。「バックアップは堅牢で、これまで何も失っていない」という正直な立場は事実ですが、問いへの答えにはなっていません。問われているのは、ファイルサーバーが停止した後の四時間に何が起きるのか、誰が何を決めるのか、どの順序で復旧するのか、だからです。

この記事が扱うのはその欠落です。この事務所が持っているバックアップの能力ではなく、それを示す、他者がレビューできる書かれた計画のほうです。中小企業 IT でもっとも一般的な文書化の欠落のひとつであり、AI アシスタントが実際に得意とすることとよく噛み合います。

多くの中小企業がバックアップは持つのに、書かれた BCP を持たない理由

バックアップは何かが壊れたから作られます。計画は誰かが求めたから書かれます。多くの中小企業では、二つ目は単に一つ目より後に、たいてい何年も後に、そして内部要因ではなく外部の契機によって起こります。

その契機は増える一方です。大企業や公共部門の顧客はベンダー資料に継続性の質問を入れます。サイバー保険の申込書は RTO と RPO の数値、そしてどんなテストをしているかを尋ねます。認証制度は文書化された継続性の取り決めを求めます。親会社のグループ監査は子会社に計画の提出を求めます。いずれも、健全なバックアップジョブのスクリーンショットでは満たせません。

手つかずのまま残る理由は、BCP が本当に手強い白紙だからです。これは技術文書ではなく業務文書であり、どのシステムがどの順に重要か、各システムなしで事業がどれだけ耐えられるか、誰がインシデント宣言の権限を持つか、誰が顧客に連絡するかといった判断を要します。ゼロから作れと言われた IT マネージャーが、実際に壊れている仕事より後回しにするのは当然で、毎回そうなり、期限が来るまで続きます。

環境の説明から Gemini が実際に起草できるもの

Gemini は単体のアシスタントとしても、Google Workspace に統合された形でも利用でき、Docs の中で直接起草できます。長い入力を扱えるため、環境の完全な説明——システム、依存関係、拠点、人数、クラウドとオンプレミスの区分——を貼り付け、汎用テンプレートではなくそこから作業することが現実的になります。利用できる機能はプランとエディションによるため、思い込みで進めず最新のドキュメントを確認してください。

正直な位置づけは、白紙をレビュー可能な草案に変えるということです。得られるのは構造、語彙、網羅性です。評価者が期待する節立て、本来問うべきだった問い、すでに知っていることの配置。そこに書かれたすべての数値は、確認するか差し替えるかを要する提案にすぎず、計画は誰かがテストして初めて実体を持ちます。書かれたまま一度も演習されていない BCP は、必要になったその瞬間に失敗する文書です。

構造化された骨組み——適用範囲、RTO と RPO、復旧順序、役割

有効なプロンプトは「BCP を書いて」ではありません。自社環境の説明に加え、計画の構造を求め、IT ではなく事業側の判断が要る箇所にはすべて明示的な空欄を置かせることです。

機能する構造の一例。適用範囲と、意図的に範囲外とするもの。対象とする中断シナリオ——拠点喪失、システム障害、ランサムウェア、主要供給者の停止。重要度で階層化したシステム一覧。階層ごとの RTO と RPO。復旧順序とその依存関係。役割と、指名された代理者。発動基準と宣言権限者。社内および顧客への連絡。そしてテストと見直しの予定。

このうち二つは特に注意に値します。AI が起草した計画がたいていつまずくのがここだからです。RTO と RPO は事業上の判断であって IT の好みではありません。そのシステムなしで会社がどれだけ稼働できるか、どれだけの作業を失う余裕があるか。事業側が答えるべき明示的な問いとして出力させ、モデルが提示した数値はすべて、その会話を始めるきっかけとして扱ってください。

システム一覧を、優先順位のついた復旧順序に変える

本当に有用な二つ目の成果物は順序付けです。中小企業のシステム一覧の多くはアルファベット順か履歴順で、「何が最初に戻らねばならないか」で並んでいるものはほとんどありません。そして計画の成否はまさにその並びにかかっています。

依存関係を平易に記述し——プロジェクトデータベースはファイルサーバーの共有を必要とし、見積ツールはオンプレミスのディレクトリサービスで認証し、VPN が復旧しないとリモート勤務者は何もできない——そこから導いた復旧順序を、各手順の依存関係を明示した形で求めます。返ってくるものはたいてい八割方正しく、一か所だけ示唆に富む誤りを含みます。その誤りはたいてい、チームが気に留めなくなっていた依存関係です。それを見つけるだけでも、この作業には価値があります。

実践ワークフロー——「うちが動かしているのはこれです」からレビュー可能な初稿まで

1. まず環境の説明を文書として書く。システム、バージョン、それぞれの稼働場所、何がバックアップしているか、頻度、バックアップの保存先、管理者。計画を書くかどうかに関わらず価値があり、以降のすべてはその正確さに依存します。

2. 内容より先に構造を求める。節の一覧をまず受け取り、顧客や保険会社が実際に求めた内容と突き合わせ、本文を一段落も書く前に調整します。骨組みの修正は安く、完成稿の再構成は安くありません。

3. 答えだけでなく、問いを受け取る。草案が事業側から必要としていて IT には決められない事項——システムごとの許容停止時間、許容されるデータ損失、発動を承認できる人——を明示的に列挙させます。その一覧を役員のところへ持っていってください。この会話こそが本当の作業であり、草案はそれを引き起こすために存在します。

4. 節ごとに、毎回のプロンプトへ自社環境を添えて起草する。汎用の継続性文は無価値ですが、自社のファイルサーバー、バックアップツール、実際の依存順序を名指しした段落はそうではありません。環境の説明を最後まで文脈に保ってください。

5. 復旧順序は、レビュアーではなくエンジニアの目で読む。現実と突き合わせて一手順ずつ歩いてください。ドメインコントローラーが停止していてそのサーバーに到達できるのか、復元に誰も持っていないライセンスキーが要るのではないか、記載の時間枠でその量のデータを引き戻す帯域はあるのか。確信が持てない手順はすべて印を付けます。

6. RTO と RPO は証拠から定め、そのうえで演習する。代表的なシステムの復元を実際に計測し、願望ではなくその数値を使います。そして計画に名前のある人々を集めて机上演習を行い、日付を記録してください。「最後にテストしたのはいつですか」は、いまや定番の質問です。

AI が起草した BCP vs コンサルタントが書いた BCP vs 書面計画なし

• AI による初稿。白紙を取り除き、完全で定型に沿った文書を素早く生み、そして過小評価されている点として、事業側が答えるべき問いの一覧を生成します。目標をひとつも検証できず、貼り付けた以上の環境知識を持たず、一度も試したことのない復旧について自信ありげでもっともらしい文章を書きます。正しい使い方は、レビュー可能な草案と判断事項の一覧に素早く到達し、すべての数値を暫定として扱うことです。
• コンサルタントが書いた計画。方法論と、同業他社が同じリスクをどう扱っているかとの比較、そして楽観的な前提に外部者として異議を唱える姿勢をもたらします。実費がかかり数週間を要し、よくある失敗は、納品され、ファイルされ、一度も演習されないことです。質の悪い計画と同じ末路を、より高い価格で辿ります。正しい使い方は、規制や契約の要求が厳しい場面、そして順序付けに本当に専門性が要るほど複雑な組織です。
• 書面計画なし。一人が復旧の全体を頭に収められ、誰も文書を求めていない極小規模の企業では、直ちに怠慢とは言えません。しかし顧客・保険会社・監査人が尋ねた瞬間に成り立たなくなります。あるいは、その一人が休暇中にファイルサーバーが止まった瞬間にも。正しい使い方は、外部の誰かが尋ね始めた時点で事実上なくなり、そして尋ねる相手は増える一方です。

テストしていない草案計画が危険なところ

誰も測っていない RTO は、目標ではなく数字です。計画に書かれた「四時間」が一度もテストされていなければ、それは復元スループット、ライセンスの可用性、手元のハードウェア、手順を知る人に連絡がつくこと、これらすべてについての仮定です。実際の復元は、初回の試行では見積もりの数倍かかることが普通にあり、その初回がインシデント中であってはなりません。

誰も演習していない役割を名指しした計画は、最初の判断で止まります。失敗する手順が技術的であることは稀です。計画にはインシデント責任者が発動を宣言すると書いてあるのに、いまの状況が該当するのか、その支出を承認する権限が自分にあるのかを誰も確信できない、その瞬間です。机上演習なら一時間で露呈し、実際の停止では高くつく形で露呈します。

自信に満ちた文書は、かえって安全でなくすることがあります。これは、検証されていない前提の上に丁寧に書かれた計画に固有のリスクです。正直な不確実性を、明言された約束に変換してしまうのです。保険会社や顧客に数値を提出することは表明であり、計画書は楽観的であってよい場所ではありません。目標が未検証であれば、そう文書に書き、いつテストするのか日付を添えてください。

これを正しくやるために——プロンプトに書くインフラの粒度、計画のテスト、そして IT を巻き込むべきとき

環境をどこまで記述するかを意識的に決める。有用な草案に必要なのは、システムの役割、依存関係、おおよその規模です。ホスト名、IP アドレス設計、外部公開エンドポイント、管理者アカウント名、バックアップ事業者のポータル情報は必要ありません。自社インフラとその復旧上の弱点を詳細に記した文書は、まさに攻撃者が欲しがる資料です。識別子ではなく機能を記述し、何かを貼り付ける前に法人プランと個人プランの AI アカウントに関する自社方針を確認してください。

計画は、緊張下で実際に使える長さに抑える。継続性計画は、内容の不備と同じくらいの頻度で、長さによって失敗します。インシデント中に本当に使うのは数ページです。発動基準、誰が何をするか、復旧順序、連絡先一覧。それ以外は附属資料です。この分割を明示的に求めてください。放っておけばアシスタントは一様に長い文書を作ります。

順序付けとテストには IT を呼ぶ。計画が本当に形になるのはそこだから。どのシステムが本当に最初に戻らねばならないか、いま実際に回しているバックアップ計画でその RPO が達成できるのか、ランサムウェアに備えた不変または隔離されたコピーが存在するか、完全復元に本当はどれだけかかるか。これらはテストが答える問いであって、起草が答える問いではありません。そしてそこが、計画が紙であることをやめる地点でもあります。

継続性の取り組みの中でアシスタントが本当に役立つ地点を見極めること——そして誰かがそれに依存する前に出力をテストさせること——は AI+ サポートの仕事です。文書の背後にある能力、すなわち RTO と RPO をめぐる BCP の戦略と方法論、オンプレミスおよびクラウド間のバックアップ、媒体の遠隔地保管、定期的な復旧訓練はクラウド管理バックアップであり、実際に計画を実行することになる同じ IT サポートチームが担います。計画をファイルせず演習するという規律についてはインシデント対応の机上演習シナリオの生成を、同じ構造化手順書の手法を本番稼働に適用した例については UAT スクリプトとカットオーバー手順書の作成をご覧ください。

よくある質問

草案の計画で、監査人や保険会社が実際に求めるものを満たせますか。

よく構造化された文書は最初の問いは越えられますが、二つ目は越えられません。評価者は、RTO はいくつか、その数値はどこから来たか、最後にテストしたのはいつか、テストで何が分かったかを尋ねます。誰も測っていない目標とテスト記録のない計画は、そのうち最初の問いにしか答えられません。草案は会話を可能にするものと捉え、そのうえで測定と演習を行ってください。実際に評価されているのはそちらです。

環境の説明はどれくらい具体的である必要がありますか。

機能と依存関係については具体的に、識別子についてはぼかして。草案が知るべきなのは、プロジェクトデータベースがオンプレミスのファイルサーバーの共有に依存していること、リモート勤務者が VPN 経由で到達すること、毎晩のバックアップが NAS に保存され週次で遠隔地コピーが取られていること、です。ホスト名、アドレス、アカウント名は不要です。この切り分けにより、実環境に根ざした草案を、その地図を書き残すことなく得られます。

これは実際の復旧訓練の代わりになりますか。

なりませんし、これが最も守るべき限界です。起草が生むのは計画であり、訓練が生むのは計画が機能するという証拠と、ほぼ必ず、機能しないものの一覧です。よくある発見は地味で決定的です。想定よりはるかに長くかかる復元、誰も見つけられなかったライセンスキー、誰も文書化していなかった依存関係。訓練を組み立てる助けになるなら先に計画を書いて構いませんが、計画を実体にするのは訓練のほうです。

BCP はどれくらいの頻度で更新すべきですか。

定期的に、かつ変更時に。そして重要なのは変更のほうです。年次の見直しとテストは一般的な基準線で、多くの評価者が記録として見たがるものです。しかし計画を無効にする変更は、システムのクラウド移行、新拠点、バックアップ基盤の変更、名指しされたインシデント責任者の退職といった事柄で、そのいずれもが年次見直しの一週間後に文書を誤りにし得ます。計画の更新をこれらの事象に明示的に紐づけ、暦だけに紐づけないでください。

顧客質問票の継続性の節に、これをそのまま使って回答できますか。

準備に使ってください。自動操縦で回答するためではありません。質問票の回答は顧客への表明であり、契約上の意味を持つこともあります。草案から貼り付けた未検証の数値は、自分で確認していない約束です。健全な進め方は、計画を作り、テストで目標を検証し、その検証済みの文書から回答することです。二回目、三回目に顧客から尋ねられたときはそのほうが速くもあります。土台の作業がすでに済んでいるからです。