生成AIが止まった日に備える士業事務所のBCPと代替手段の7設計

AIのBCPとは、生成AIが止まったときに業務を続ける備えのことです。

申告期限の前日に、事務所で使っている生成AIが応答しなくなったらどうするか。この記事では、士業事務所が生成AIの障害を前提に業務継続の設計を組む手順を、七つの設計項目として整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で確認しています。

事業継続計画の対象に生成AIが入っていない事務所が多数です

結論から書きます。多くの士業事務所の事業継続計画は、地震と火災と停電を想定して作られており、クラウドサービスの停止が独立した項目として入っていません。生成AIを日常業務に組み込んだ事務所では、この空白が実害になります。

内閣府の事業継続ガイドラインは、事業継続マネジメントの考え方として、重要業務を特定し、その業務が停止する要因を洗い出し、代替手段を用意する流れを示しています（出典: 内閣府事業継続ガイドライン）。この枠組み自体は、対象が自然災害でもクラウド障害でも変わりません。変わるのは、停止要因の欄に何を書くかです。

生成AIの停止には、いくつか異なる型があります。一つ目は、サービス全体の障害です。提供元のシステム障害で、全ユーザーが使えなくなります。二つ目は、地域やネットワークに起因する接続不良です。事務所側の回線やプロキシの問題で、サービスは動いているのに届かない状態になります。三つ目は、アカウントや契約に起因する停止です。支払いの失敗、利用規約上の措置、プラン変更に伴う機能の制限。四つ目は、モデルの提供終了や仕様変更です。これは障害ではありませんが、事務所の業務フローが止まるという点では同じ結果をもたらします。

このうち一つ目については、主要な提供元が稼働状況のページを公開しています（出典: Anthropic Status ／ OpenAI Status）。障害が起きたとき、事務所側の問題なのか提供元の問題なのかを最初に切り分ける場所として、このページを事務所の手順書に書いておく価値があります。担当者が原因を探して三十分溶かす前に、一分で切り分けられます。

四つ目のモデル提供終了は、実務上もっとも読みにくい要因です。士業事務所が特定のモデルの出力特性に合わせてプロンプトを作り込んでいる場合、モデルが切り替わると同じプロンプトで同じ品質が出なくなります。障害としては検知されないまま、成果物の質だけが静かに落ちます。この型に備えるには、プロンプトを人が読める形で保管し、切り替え時に検証する手順を持っておくことになります。

生成AIの停止に備える7つの設計項目

結論として、設計するのは代替ツールの手配ではなく、業務ごとの撤退ラインです。どの業務を何時間止められるかを先に決めると、必要な備えの水準が自動的に決まります。

設計1は、業務の棚卸しと許容停止時間の設定です。生成AIが関与している業務を並べ、それぞれについて、止まっても構わない時間を書き込みます。議事録の要約なら一日止まっても支障はないかもしれません。申告期限直前の書類点検なら、二時間止まると影響が出ます。この差が、備えの優先順位になります。

設計2は、手作業への戻り方の明文化です。AIを使う前、その業務をどうやっていたかを手順として残します。導入から年数が経つと、若い職員は手作業の手順を知りません。戻り方を知らない状態で止まると、復旧まで何もできなくなります。

設計3は、代替サービスの確保です。主に使うサービスとは提供元の異なるサービスを、最低限のプランで契約しておきます。同じ提供元の別プランでは、全体障害のときに一緒に止まります。提供元を分けておくことが要点です。

設計4は、プロンプト資産の保管です。事務所で作り込んだプロンプトを、サービスの中だけに置かない設計にします。共有フォルダにテキストで保管し、どの業務で使うものかを記した索引を添えます。サービスを乗り換えるときも、この資産があれば移行が早く済みます。

設計5は、出力の途中成果物の扱いです。AIとのやり取りの途中でサービスが止まると、作業中の内容が消えることがあります。長い作業は、区切りごとに手元へ保存する運用にします。とくに、顧問先へ出す文書の草稿は、サービス側にだけ置かない習慣が要ります。

設計6は、連絡と説明の段取りです。障害で納期に影響が出る場合、顧問先への連絡は誰がいつ行うかを決めておきます。AIが止まったからと正直に伝えるかどうかで悩む時間が惜しいので、事前に方針を決めておくほうが早く動けます。

設計7は、情報漏えい事案との切り分けです。障害の中には、データの取り扱いに関わるものが混じります。提供元の障害で他のユーザーの内容が見えたといった事象が起きた場合、単なる業務停止とは扱いが変わります。個人データに関わる事態については、個人情報保護法第26条が、個人の権利利益を害するおそれが大きいものとして個人情報保護委員会規則で定める事態が生じたときの報告について定めています。報告の要否や手続については、個人情報保護委員会が公表している案内が起点になります（出典: 個人情報保護委員会漏えい等の対応）。

棚卸しに使うプロンプト例です。

あなたは士業事務所の業務継続計画づくりを補助します。
以下の業務一覧について、生成AIが停止した場合の影響を整理してください。

出力項目:
- 影響が出るまでの時間（即時／数時間／1日以上）
- 手作業で代替できるか（可／一部可／不可）
- 代替した場合に増える作業時間の見立て

制約:
- 断定せず、確認が必要な点は質問として添えてください
- 特定の製品名を推奨しないでください
- 法令上の義務の有無について評価しないでください

業務一覧:
1. 顧問先からの問い合わせへの一次回答の下書き
2. 面談記録の要約
3. 提出書類の記載内容の点検

手順書の草案を作るプロンプト例です。

生成AIサービスが応答しない場合に、事務所の職員が最初に行う切り分け手順の
草案を作ってください。

条件:
- 5ステップ以内
- 各ステップは「確認すること」と「次に進む条件」をセットで
- 提供元の稼働状況ページを確認する手順を含める
- 顧客情報の取り扱いに触れる手順は含めない
- 敬体、箇条書きではなく番号付きの手順で

どちらも、AIには整理と草案づくりだけを担わせています。最終的にどの業務をどこまで止められると判断するかは、事務所の責任者が決める部分です。AIの実行環境そのものをどう設計するかという論点は、OpenAI Agents API公開、士業事務所が見る実行環境3つの論点でも扱いました。

代替手段を用意するときの守秘義務と規程の論点

結論を先に書きます。代替サービスを増やすということは、顧問先の情報が触れる可能性のある場所を増やすということです。備えを厚くするほど、管理する対象が増えます。この緊張関係を規程で整理しておかないと、障害対応の現場で判断が割れます。

まず決めるのは、代替サービスの審査です。本番で使うサービスと同じ基準で、入力データの学習利用、保存期間、提供元の所在地を確認します。障害時だけ使うサービスだから審査を省く、という運用は避けたいところです。緊急時ほど、確認を飛ばした判断が起きやすくなります。

次に、障害時の情報の持ち出しです。クラウド上のAIが使えないとき、職員が私物の端末や個人アカウントのサービスで作業を続けてしまう事態が起こり得ます。これは業務継続としては動いているように見えて、守秘義務の観点では最も危うい状態です。事務所の規程に、緊急時であっても私物端末と個人アカウントは使わない旨を書いておきます。

士業ごとの守秘義務は、それぞれの資格法に根拠があります。たとえば社会保険労務士については社会保険労務士法第21条が、開業社会保険労務士または社会保険労務士法人の社員は、正当な理由がなくて、その業務に関して知り得た秘密を他に漏らし、または盗用してはならない、と定めています。弁理士については弁理士法第30条に同趣旨の規定が置かれています。緊急時の例外を認める書きぶりにはなっていないため、障害対応でも同じ規律の下で動くことになります。

三つ目は、記録の残し方です。障害が起きたとき、いつ何が止まり、誰がどう対応し、どの代替手段を使ったかを記録します。この記録は、後から顧問先に説明する材料になりますし、次回の設計を見直す材料にもなります。書式は簡素でかまいません。日時、事象、対応、影響。この四項目を一行ずつ残すだけでも、記憶に頼るより格段に役立ちます。

アカウントの管理も見直し対象です。障害の一部は、アカウント側の事情で起きます。支払い方法の期限切れ、管理者アカウントの引き継ぎ漏れ、多要素認証の端末紛失。これらは事務所側で防げる停止要因です。アカウントの乗っ取りや不正アクセスへの備えについては、AIアカウントの乗っ取り確認と事務所の点検で整理しています。

起こりがちな3つの想定漏れ

一つ目は、単一提供元への集中です。文書作成も、要約も、検索も、すべて同じ提供元のサービスに寄せている事務所は少なくありません。統合されているほど業務は速くなりますが、止まるときは全部一緒に止まります。速度と冗長性は基本的に交換関係にあるので、どこまで速度を取るかを意識して選んだかどうかが分かれ目です。

二つ目は、連携している業務システム側の想定漏れです。会計ソフトや案件管理システムにAI機能が組み込まれている場合、そのAI部分だけが止まることがあります。システム全体は動いているので障害だと気づきにくく、出力が返ってこない理由を探して時間を使います。連携先のAI機能も、停止要因の一覧に入れておきます。外部サービスとの接続を見直す際の型は、MCPのステートレス化で変わる事務所のAI連携で扱いました。

三つ目は、訓練をしないことです。手順書を作っただけで終わると、実際に止まった日に誰も手順書の場所を思い出せません。年に一度、あえてAIを使わずに半日業務を回す日を作る事務所があります。大掛かりな訓練でなくても、戻り方を体で覚えておくと復旧が早くなります。

費用・工数・体制

代替サービスの契約費用は、最小構成なら大きな負担になりません。主要な生成AIサービスの有償プランはユーザー単位の月額課金で、数千円の帯にあります。全員分を二重に契約する必要はなく、障害時に作業を継続する担当者の人数分だけ確保する考え方が現実的です。

工数は、初期の設計に半日から一日、その後の見直しに四半期ごと一時間程度を見込みます。業務の棚卸しさえ一度作ってしまえば、更新は差分の反映で済みます。時間がかかるのは、手作業への戻り方を書き起こす作業です。ここは、AI導入前を知っている職員がいるうちに済ませておくと楽になります。

体制面では、事業継続の担当を情報システムの担当と分けないことが要点です。業務側の事情を知らない担当者が設計すると、技術的には整っているが現場で回らない手順書ができます。業務を回している職員が設計に加わる形にします。

今後の論点

AIエージェントが定型業務を自律的に処理するようになると、停止の影響は今より大きくなります。人が手順を知らないまま自動化が進んだ業務は、止まった瞬間に代替手段がありません。自動化の範囲を広げるときは、同時に手動での回し方を文書化しておく設計が要ります。

もう一つは、提供元の集中です。業界全体が少数の提供元に依存する構造が進むと、一つの障害が同時に多数の事務所へ波及します。顧問先も同じサービスを使っている場合、事務所と顧問先の双方が同時に止まる事態も想定に入ります。この相関を前提にすると、代替手段は提供元を分けるだけでなく、AIに依存しない経路を一つ残す設計になります。

規制の側の動きも要確認です。金融や医療の分野では、外部サービスへの依存に関する管理が求められる場面が出てきています。士業事務所に同様の枠組みが及ぶかどうかは現時点で確立していないため、動向を追いながら自主的に整えておく姿勢が現実的です。

よくある質問

事業継続計画に生成AIを入れる必要はありますか

日常業務でAIに依存している度合いによります。判断の目安は、AIが一日止まったときに納期に影響が出る業務があるかどうかです。影響が出る業務が一つでもあるなら、停止要因の一覧に加えておく価値があります。

代替サービスは同じ提供元の別プランでもよいですか

全体障害への備えとしては弱くなります。提供元のシステム障害では、同じ提供元のサービスは一緒に止まります。備えとして意味を持たせるなら、提供元が異なるサービスを選ぶ設計が採られています。

障害が起きたとき最初に何を確認しますか

提供元の稼働状況ページです。事務所側の回線の問題か、提供元の障害かを一分で切り分けられます（出典: Anthropic Status ／ OpenAI Status）。切り分けができてから、代替手段に移るか復旧を待つかを判断します。

緊急時に職員が個人アカウントを使うのは避けるべきですか

避ける運用を規程に書いている事務所が多くなっています。緊急時は確認が飛びやすく、顧問先の情報が管理外の場所へ出る経路ができます。規程に明記しておくと、現場で迷わずに済みます。

障害でデータが見えてしまった場合はどうしますか

まず事実関係を記録し、提供元の公表を確認します。個人データに関わる事態については、個人情報保護法第26条が報告について定めており、手続の案内は個人情報保護委員会が公表しています（出典: 個人情報保護委員会漏えい等の対応）。事務所単独で判断せず、案内に沿って確認する順序が基本です。

手作業への戻り方はどこまで書けばよいですか

新しく入った職員が読んで再現できる粒度が目安です。使う様式、参照する資料の場所、確認する順序。この三つが書いてあれば、経験のない職員でも一定の水準で回せます。

訓練はどれくらいの頻度で行いますか

年に一度、半日程度から始める事務所があります。繁忙期を避けた時期に、AIを使わずに通常業務を回してみるだけでも、手順書の抜けが見つかります。

参考文献

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/

本記事の作成体制について

本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で、それぞれ確認したうえで記載しています。引用元は本文中および参考文献にすべて明示しています。

本記事には特定の資格者による監修は入っていません。個別の事案について法令の当てはめや手続の可否を判断する必要がある場合は、当該分野の有資格者にご相談ください。本記事は一般的な情報提供を目的としたものであり、個別具体的な法律判断・税務判断・労務判断を提供するものではありません。

記載内容に誤りを見つけられた場合は、お問い合わせよりご指摘ください。確認のうえ速やかに訂正し、訂正履歴を記事内に残します。編集方針の詳細は運営者情報をご覧ください。