BCPの業務影響度分析をClaudeで進める — 復旧優先度の表を作る手順

業務影響度分析は「復旧優先度の表」を作る作業

事業継続計画(BCP)の最初の山は、業務影響度分析(BIA)です。何かが起きて業務が止まったとき、どの業務から、いつまでに、どの水準まで戻すかを決めるために、業務ごとの影響の大きさを調べます。

内閣府の事業継続ガイドライン(令和5年3月)は、この作業を「事業影響度分析」と呼びます。優先して継続・早期復旧すべき重要業務を選び、復旧させる目標時間を検討し、それを実現するために必要な経営資源を特定する、という位置づけです。

情報システムの担当者や経営企画の担当者がここで作りたいのは、次の1枚の表です。

• 業務ごとの重要度と、止まったときの影響
• 業務が依存するシステム
• システムごとの目標復旧時間(RTO)の案
• 復旧させる順序

この記事では、材料をClaudeのProjectsに置き、表のたたき台を作らせ、ヒアリングで検証するところまでを順に扱います。BIAの「答え」をClaudeに決めさせる手順ではありません。ヒアリングで集めた材料を整理し、抜けと矛盾を洗い出す手順です。

表に入れる項目と用語

ガイドラインは、目標復旧時間を「Recovery Time Objective、RTO」、どの水準まで復旧させるかを「目標復旧レベル(Recovery Level Objective、RLO)」と定義しています。データを過去のどの時点まで戻すかの目標値は、目標復旧時点(Recovery Point Objective、RPO)です。

ガイドラインの脚注には、RPOの例として「1週間前のデータまで」「1日前のデータまで」が挙がっています。直近まで戻せるのが望ましい一方、対策費用が高くなることが多い、とも書かれています。

ここで押さえておきたいのは、この段階で決めるRTOとRLOは「案」にとどまる点です。ガイドラインは、実現性が未検証なので、戦略・対策の実施可能性を検討してから経営判断で最終決定すると説明しています。ですから、Claudeに作らせる表の列名も「RTO案」「RPO案」とします。

影響を見る観点は、ガイドラインの表に例があります。利益・売上・マーケットシェア、資金繰り、顧客への影響、従業員の雇用・福祉、法令や契約・SLA違反の影響、社会的信用、社会的・地域的な影響です。この観点をそのままヒアリングシートの列にすると、部門ごとに答えの粒度がそろいます。

Projectsに材料を置く

Projectsは、プロジェクトごとにチャット履歴と知識ベースを持つ作業スペースです。文書や資料を知識ベースに上げておくと、そのプロジェクト内のどのチャットでも使われます。無料アカウントを含む全ユーザーが使えますが、無料アカウントが作れるプロジェクトは5つまでです。

BIAは、一度で終わりません。業務一覧を作り、ヒアリングを重ね、システムの依存を足していくので、材料を一か所に置いて、毎回同じ前提で続けられるProjectsと相性がよい作業です。

置くファイルの例

次の3種類を、テキストかCSVで用意します。

1. 業務一覧(業務名、担当部門、1日あたりの処理量や売上の目安)
2. システム一覧(システム名、使う業務、運用担当、バックアップの有無)
3. ヒアリングシート(部門ごとの許容停止時間と、その根拠)

ファイル形式は、PDF、DOCX、CSV、TXTなどに対応しています。XLSXを上げるには、アカウントで「コード実行とファイル作成」を有効にしておく必要があります。有効にしていない環境でもすぐ始められるよう、表はCSVにしておくのが無難です。

プロジェクトに上げるファイルには上限があります。1ファイル30MBまでで、ファイル数に制限はありませんが、内容全体がコンテキストウィンドウに収まる必要があります。抽出されるのはテキストだけです(マルチモーダル対応のPDFは例外)。業務フロー図を画像で貼っても、図の中身は読み取られないので、業務の流れは文字でも書き添えておきます。

知識ベースが大きくなったときの扱いは、有料プラン(Pro、Max、Team、Enterprise)で変わります。コンテキストの上限に近づくとRAGモードが自動で有効になり、容量が最大10倍まで広がります。仕組みと全文投入との違いは、Claude ProjectsのRAG検索の仕組みにまとめています。業務が数十件の中堅企業なら、多くは全文が収まる範囲に入る規模です。

プロジェクト指示に作業ルールを書く

「Set project instructions」から、そのプロジェクトのすべてのチャットに効く指示を保存できます。BIAでは、推測で数字を埋めさせないルールを最初に入れておくのが肝心です。例えば次のような指示になります。

あなたは情報システム部門のBCP策定を支援します。
- 資料に書かれていない数値(許容停止時間、売上額)は推測で埋めず、
  「未確認」と書いて、誰に何を聞くべきかを質問リストに出す
- 数値には必ず根拠の出典(ヒアリングシートの行、契約書名)を添える
- RTOとRPOは「案」として扱い、決定とは書かない
- 表は列名を固定する: 業務名/停止の影響/許容停止時間/依存システム/
  RTO案/RPO案/復旧順序/根拠/未確認事項

この指示で、Claudeの出力に「未確認」の列が残ります。後のヒアリングは、この未確認事項を潰していく作業になります。

会話をまたぐ情報は、知識ベースに戻す

注意したいのは、プロジェクト内でもチャット同士は文脈を共有しない点です。あるチャットで整えた表を、別のチャットが知っているわけではありません。共有されるのは、知識ベースに入れた情報だけです。

そのため、チャットで出来上がった表や確定した前提は、自分でCSVやテキストに保存して、知識ベースに追加し直します。ヒアリングの回ごとにファイル名へ日付を入れておくと、どの版の表かを後から追えます。

手順1: 業務ごとの影響と許容停止時間を整理する

最初に、業務一覧とヒアリングシートを元に、業務ごとの影響を時系列で整理させます。ガイドラインは、事業が止まった場合の影響の大きさと変化を、時系列でできるだけ定量的に評価するよう求めています。止まって1日、3日、1週間で何が起きるかを分けて聞くわけです。

知識ベースの業務一覧とヒアリングシートを使い、業務ごとに
「停止1日後・3日後・1週間後の影響」を表にしてください。
- 観点は、売上、資金繰り、顧客、契約・法令、従業員、信用
- ヒアリングシートに根拠がない欄は「未確認」にし、質問を出す
- 最後に、許容停止時間が空欄の業務を一覧にする

定量化は、凝らなくて構いません。ガイドラインの脚注にも、1日あたりの売上や事務処理量を使った簡易な評価で一定の目的は達せられ、定量化が難しいものは影響の大小による定性評価でもよい、とあります。事業影響度分析に時間をかけすぎると、その間に事業環境が変わって作業が無意味になりうる、という注意もあります。

法令や契約の期限は、許容停止時間の根拠として強い材料になります。脚注には、契約上の供給遅延の賠償責任、株主総会の開催期限、税務申告期限などが例に挙がっています。ヒアリングシートには、部門の体感とは別に「期限のある法令・契約」の列を設けておきます。

手順2: 業務とシステムの依存を表にする

次に、業務がどのシステムに依存するかを対応づけます。ここで抜けやすいのが、業務からは見えにくい共通基盤です。認証基盤、ネットワーク、メール、ファイルサーバーなどは、ほとんどの業務が使うので、各部門のヒアリングでは話題に出ません。

業務一覧とシステム一覧から、業務×システムの依存表を作ってください。
- 業務ごとに、直接使うシステムを列挙
- 資料に出てこない共通基盤(認証、ネットワーク、メール等)は、
  依存している可能性として別枠に書き、情報システム部門への質問にする
- 業務が複数あるのにシステム一覧に載っていないシステム名があれば指摘

依存表ができたら、システムの側から眺め直します。1つのシステムに多くの重要業務がぶら下がっていれば、そのシステムは復旧順序の上位に来る見込みです。逆に、重要業務が1つもぶら下がっていないシステムが一覧にあれば、一覧が古いか、依存の洗い出しが漏れているかのどちらかです。

手順3: システム別のRTO案とRPO案を導く

依存表ができたら、システム別のRTO案を導きます。考え方はシンプルで、システムのRTOは、そのシステムに依存する業務の許容停止時間のうち最も短いものより早く設定する、というものです。ガイドラインも、時間の許容限界より早く目標復旧時間を設定すると述べています。

依存表と許容停止時間を使い、システム別のRTO案を出してください。
- RTO案は、依存する業務の許容停止時間の最小値より短くする
- 根拠として「どの業務の許容停止時間が効いたか」を列に書く
- RPO案は、業務側の「何日前のデータまでなら再入力で戻せるか」の
  回答がある場合のみ出す。無い場合は「未確認」

RPOは、業務側の回答がなければ導けません。「前日の夜のバックアップまで戻っていればよいか」「午前中の受注は再入力できるか」といった質問は、システム部門だけでは答えが出ません。Claudeには、RPO案を空欄のまま残させて、業務部門への質問を作らせるほうが、後の手戻りが少なくなります。

出力の表の例

出来上がる表は、例えば次のような形になります。数値はすべて架空の例で、実際の値はヒアリングで決まります。

この例で1行目の「認証・ネットワーク」が最優先になっているのは、他のすべてのシステムの前提だからです。基盤の復旧が遅れるなら、上位システムのRTOは守れません。

手順4: 表の矛盾をClaudeに点検させる

表のたたき台ができたら、Claudeに点検役をやらせます。人が見落としやすいのは、行ごとには筋が通っているのに、行同士で矛盾している箇所です。点検の観点を決めておくと、結果が安定します。

作成した表を次の観点で点検し、問題の行だけを理由付きで挙げてください。
1. 基盤系システムのRTOが、依存する上位システムのRTOより長い行
2. 復旧順序が、RTOの短い順と食い違っている行
3. 許容停止時間の根拠が「未確認」のまま、RTO案が埋まっている行
4. 依存表にはあるのに、復旧順序の表に載っていないシステム

観点1は、見落としの代表格です。上位のシステムのRTOを6時間と置いても、それが動くための基盤のRTOが12時間では、6時間は実現できません。ルールとして単純ですから、Claudeに機械的に洗わせる作業に向いています。

ただし、点検の結果が「問題なし」でも、表が正しいとは限りません。点検できるのは表の内部の整合だけで、許容停止時間そのものが現実に合っているかは、ヒアリングでしか分かりません。

ヒアリング結果で検証する点

表は、完成した時点では「案」です。次の6点を、ヒアリングの場で確かめます。

4つ目の「現状で可能な復旧時間」について、ガイドラインは、現状で可能な時間やレベルが取引先のニーズを踏まえた目標の案を満たしていないことは「当然多い」と述べています。ギャップが出ること自体は異常ではありません。そのギャップを埋める対策を検討するのが、BIAの次の段階にあたる戦略・対策の検討です。

5つ目の手作業での代替も、ガイドラインの脚注に例があります。受注売上システムのバックアップを動かしたときに経理システムとの整合を取ること、手作業で処理した分がシステムに反映されたことを確認することなどです。こうした復帰時の作業は、RTOの表には出てきません。

ヒアリングの回答が戻ったら、回答メモを新しい版のファイルとして知識ベースに追加し、「回答に基づいて未確認を埋め、変わった行を一覧にして」と頼みます。変更行の一覧を出させると、前回の表からどこが動いたかを関係者に説明しやすくなります。ヒアリングメモから業務の流れを図にして抜けを洗う方法は、Claudeで業務フロー図を作成する手順で扱っています。

使うときの注意点

数値を決めるのは人

ガイドラインは、目標復旧時間と目標復旧レベルは単なる目標ではなく、講じた対策で達成できるものでなければならず、最終決定した値は対外的に説明するもので、一種の公約にあたるとしています。Claudeが出したRTO案をそのまま採用せず、実現可能性を確かめてから、経営判断で決めます。

許容限界を大幅に厳しく設定すると、達成のための対策費用が膨らみます。ガイドラインも、ある程度大胆に推定し、後で必要に応じて見直すことを勧めています。最初の表は粗くてよく、改訂前提で作る資料です。

想定する災害でも結果は変わる

BIAは発生事象の種類によらず実施しますが、停止時間の許容限界は状況で変わりえます。火災で自社だけが被災した場合と、広域災害で取引先も被災した場合では、許容される停止時間が異なる、とガイドラインは述べています。ヒアリングシートには、想定する状況を一行書き添えておきます。

社内情報の置き場を決める

業務一覧、システム構成、停止時の影響は、外部に出したくない社内情報を含みます。Team・Enterpriseプランでは、プロジェクトを非公開にして招待したメンバーだけに限定するか、組織全体に公開するかを選べます。共有する場合は、閲覧のみ(Can view)か、編集も可能(Can edit)かを選びます。BIAの材料は、非公開から始めるのがよいでしょう。

管理者が共有を無効にしている組織もあります。その場合、共同作業の材料はプロジェクト外の方法で渡すことになります。

Projectsの新しい版との関係

Claude Codeでは、Projectsの新しい版(ベータ)が展開されています。会話がスレッドを束ねる方式で、詳しくはClaude CodeのProjects刷新に書きました。チャットとCoworkの既存のプロジェクトは、これまでどおり動作します。この記事の手順は、知識ベースに資料を置く従来のProjectsを前提にしています。

表を使い回す

BIAの表は、BCP策定の一度きりの成果物ではありません。システムの入れ替えや組織変更があるたびに、依存表とRTO案は古くなります。知識ベースに最新の表を置いたまま、変更点だけを伝えて差分を更新させる運用にしておくと、年次の見直しを短い時間で済ませられます。

他の資料の作成にも同じ型が使えます。根拠資料をProjectsに置き、未確認を残させ、点検観点を決めて回す流れは、根拠資料が肝になる他の文書作成にも応用できます。Projectsに資料を置いて想定問答を作る例は、株主総会の想定問答をProjectsで作る手順にあります。

まとめ

BIAの表づくりで、Claudeが力を発揮するのは、材料の整理と整合の点検です。業務ごとの影響、依存システム、RTO案を並べ、行同士の矛盾と「未確認」を洗い出す作業は、人が手でやると時間がかかります。許容停止時間の根拠の確認や、実現可能性の判断は、ヒアリングと経営判断に残ります。

最初の1枚は、粗くて構いません。「未確認」が並んだ表が、次のヒアリングで聞くことの一覧になります。