社内ローカルAI停止時に経営者が確認すべき初動対応フローと業務継続の判断基準

「社内でAIが突然使えなくなった」と社員から報告が入ったとき、経営者としてどこから手をつければよいか。情報を外に出さない社内専用AI（ローカルLLM）を導入した中小企業では、停止時の対応手順が整備されていないケースが多く、復旧が遅れるほど業務へのダメージが拡大します。

この記事では、社内専用AIの停止時に経営者が確認すべき初動対応フローと、業務継続を判断するためのBCP基準を具体的に解説します。情シス専任がいない環境でも経営者自身が動けるよう、チェックリストと判断軸を一本化して整理しました。

社内ローカルAIが停止するとは何が起きているのか

まず「停止」の定義を正確に把握することが初動判断の出発点です。社内専用AIの停止には大きく3つのパターンがあり、パターンによって連絡先も復旧手順もまったく異なります。

パターン1：サーバーハードウェア障害
社内専用AIを稼働させているサーバーの電源ユニット、ストレージ（SSD・HDD）、メモリのいずれかが物理的に故障した場合、AIそのものにアクセスできなくなります。電源ランプが消えている、起動しても数分で落ちる、といった症状が特徴的です。ハードウェア交換が必要なため、復旧には最短でも数時間から半日程度かかります。

パターン2：ソフトウェア・設定障害
AIのモデルファイルが破損した、設定ファイルが誤って上書きされた、OSのアップデート後にサービスが起動しなくなった、というケースが該当します。ハードウェアは正常でもサービスが応答しない状態です。経験のある担当者であれば1～2時間で解決できる場合もありますが、設定の詳細が記録されていないと原因特定に時間がかかります。

パターン3：ネットワーク障害
サーバー自体は正常に稼働しているが、社員のPCからそのサーバーへのアクセスが遮断されている状態です。スイッチや無線LANルーターの設定変更、LANケーブルの物理的な断線、IPアドレスの競合が主な原因です。「一部の人は使えるが特定の部屋だけつながらない」という症状はこのパターンが多いです。

クラウドサービス（ChatGPTやCopilotなど）とは本質的に異なる点は、社内専用AIはすべての管理責任が自社内にある点です。インターネット接続が切れても社内専用AIが動き続けることがメリットですが、障害の一次対応も自社で行わなければなりません。「サービス状況ページ」を確認して待つという対応は通用しません。

中小企業で情シスを専任で抱えていない場合、「誰に連絡するか」「何を確認するか」が決まっていないと、停止時間が無駄に延びます。社内専用AIで1日あたり2時間の業務効率化を得ている会社が8時間停止すれば、1日分の効率化効果が消えるだけでなく、手作業による残業コストが発生します。この損失を具体的に意識しておくことが、初動の優先度判断を正確にする土台です。

停止後30分以内に経営者が動く初動対応フロー

社内専用AIが停止したという報告を受けてから30分以内に、経営者が確認・判断すべき内容をステップ形式で整理します。この段階の目標は「修理を完了させること」ではありません。「現状を正確に把握し、業務継続の手を打つこと」です。修理の完了は専門家に委ねてよい。判断と宣言は経営者の仕事です。

1. 停止の事実確認と影響範囲の把握（最初の5分）

報告を受けたら、まず以下の4点を確認します。

・利用不能な人数の確認: 全員か一部かを即座に確認する。全員が使えないなら共通インフラ（サーバーまたはネットワーク）の問題であり、一部だけなら端末・アカウント・ネットワーク経路の問題に絞り込める
・サーバーの物理状態の確認: サーバー機のランプが点灯しているか、電源が入っているかを担当者に確認させる。ランプが消えていればハードウェア障害を疑う
・他のネットワーク利用の確認: インターネット閲覧や社内の他のシステム（ファイルサーバー等）が問題なく使えているかを確認する。他も使えなければネットワーク障害が疑われる
・本日中に完了必須の業務の洗い出し: AIに依存している業務のうち、今日中に顧客対応・納品・申請などの期限があるものを5分以内にリストアップする

この5分間の確認で「ハードウェア障害か」「ネットワーク障害か」「ソフトウェア問題か」の大まかな切り分けができます。判断できない場合は「不明」として記録し、次のステップに進みます。

2. 担当者への連絡と状況確認の依頼（次の10分）

次の10分間は、誰に何を依頼するかを明確にします。経営者が直接サーバーを操作しようとすると、状況を悪化させるリスクがあります。必ず専門知識を持つ人間を動かすことを優先します。

・社内担当者の特定と連絡: 社内でサーバー管理を担当している人（情シス兼任、外部ITサポート、導入ベンダー）を特定して連絡する。AI導入時に受け取った「保守連絡先シート」「納品書」「契約書」を確認する
・初期診断の依頼: 担当者に「今の状況（ランプ、ログ、エラーメッセージ）を確認してほしい」と依頼する。詳細な技術的説明は不要。「何が起きているか」「いつ復旧できるか」の2点だけ報告させる
・対応形態の確認: 外部ベンダーが対応する場合は、リモート対応が可能か現地訪問が必要かを確認し、所要時間の見通しを得る

経営者がここで求めるべき情報は「いつ完全復旧するか」ではなく、「今日の業務に何が使えて何が使えないか」です。復旧見込みが2時間以上になると分かった時点で、次のステップに移ります。

3. 暫定運用への切り替え宣言（残りの15分）

復旧に時間がかかると判断したら、すみやかに暫定運用を宣言します。この判断を曖昧にすると、現場が「復旧を待って業務を止める」状態に入り、損失が拡大します。

・業務の分類と指示: AIを使っていた業務を「人手で代替できるもの」と「今日は一時停止するもの」に分類し、各部門に具体的な指示を出す
・優先案件の明示: 本日中に対顧客対応が必要な案件をリスト化し、担当者に確認の上で優先度を明示する。AIなしでも完了できるか、延期・連絡が必要かを判断する
・暫定ツールの利用許可の範囲: 必要に応じてクラウドサービスへの暫定的な移行を許可するかどうかを経営者として判断する。許可する場合は「入力してはいけない情報（顧客個人情報・契約内容・機密データ）の範囲」を同時に明示する
・状況報告の時間設定: 担当者から1時間後に状況報告を受ける約束を取り付ける。報告がない場合は経営者から確認する

この3ステップを30分以内に完了することで、「停止を知らなかった」「何をすべきか分からなかった」という混乱が起きにくくなります。重要なのは、技術的な解決を経営者が担うのではなく、業務判断と情報共有を経営者が担うという役割分担の明確化です。

業務継続の判断基準：停止が長引いたときのBCP指標

初動対応の後、復旧が半日以上かかりそうなときは、BCP（業務継続計画）の観点で判断基準を定めておく必要があります。社内専用AIはインフラの一部であり、停止シナリオをBCPに組み込んでいる中小企業はまだ多くありません。しかし、業務依存度が高まるにつれ、その重要性は増しています。

RTO（目標復旧時間）の設定
「何時間まで停止を許容するか」を業務用途ごとに決めます。社内文書の要約・社内Q&Aが主用途であれば、翌営業日復旧（24時間以内）で許容できるケースが多いです。一方、顧客対応の自動応答やリアルタイムデータ分析に活用している場合は、2時間以内のRTOが必要です。RTOを設定することで、保守ベンダーとの契約内容（SLA）が適切かどうかも評価できます。

RPO（目標復旧時点）の設定
「どの時点のデータまでなら失っても許容できるか」を定めます。AIモデルそのものは更新頻度が低いため、モデルファイルのバックアップは月次でも足りるケースが多いです。ただし、社内専用AIに蓄積した設定やカスタマイズデータ（プロンプトテンプレート、Fine-tuning済みモデルなど）は、最後のバックアップ以降の変更が失われます。

代替手段（バイパス）の事前準備
停止時にどの業務をどの方法で代替するかを事前に文書化します。たとえば「AIで自動作成していた週次報告書を手動作成に切り替えるための標準テンプレートを共有フォルダに保管しておく」という準備だけで、停止時の混乱が大幅に減ります。Before（AI停止前）：週次報告書の作成時間20分、After（AI停止時）：標準テンプレート利用で60分（差分40分の増加）。テンプレートがなければ90分以上に増える場合があります。

復旧手順書の存在確認
サーバーの再起動手順、AIサービスの再ロード方法、設定ファイルのバックアップ場所が文書化されているかを確認します。この手順書がなければ担当者が不在のときに復旧できません。中小企業でよく見られる問題は、「AI導入時は手順書があったが、その後のアップデートや設定変更で手順書が陳腐化している」というケースです。手順書は少なくとも四半期に一度、最新の設定を反映した状態か確認する仕組みが必要です。

クラウドAIと社内専用AIの停止対応比較

社内専用AIの停止対応の特性を正確に理解するために、クラウドサービス型AI（ChatGPT等）との比較を整理します。どちらが優れているかではなく、「対応の仕方がどう違うか」を把握することが目的です。

この比較から得られる重要な視点は2点です。

第1に、社内専用AIを選んだ企業は「停止対応能力を自社に持つ」という覚悟が必要だということです。クラウドサービスの停止対応は「サービス提供会社の復旧を待つ」で完結しますが、社内専用AIは自社が当事者として動かなければなりません。この違いを経営者が理解した上で、保守体制を設計することが求められます。

第2に、社内専用AIの停止リスクは「事前の投資」で大幅に低減できるという点です。ハードウェアの冗長化（電源の二重化、RAID構成によるストレージ保護）、定期的なメンテナンスの実施、復旧手順書の整備により、停止頻度と停止時間の両方を減らすことができます。クラウドサービスでは実施できないこの予防措置が、社内専用AIの運用上の優位点でもあります。

よくある質問

Q1. 社内専用AIが停止したとき、経営者がまず電話すべきはどこですか？

AI導入先のベンダーまたは保守委託先への連絡が最初です。導入時に受け取った「保守対応窓口シート」「緊急連絡先」を確認してください。これが見当たらない場合は、AIをインストールしたサーバーの管理者（社内の情シス兼任担当者）に連絡します。経営者が直接サーバーを操作しようとすると、状況を悪化させるリスクがあるため、まず専門知識を持つ人間を動かすことを優先します。

Q2. 停止中に業務データが消える可能性はありますか？

AIが停止しても、業務データが即座に消えることは通常ありません。ただし、停止の原因がストレージの故障である場合は、データへのアクセスが長期間できなくなるリスクがあります。定期的なバックアップ（外付けHDDまたはクラウドストレージへの自動バックアップ）が設定されているかを確認してください。バックアップが取れていない場合は、復旧後に最優先で設定を行います。

Q3. 社内専用AIの停止をBCPの対象として計画に含めるべきですか？

含めることを推奨します。AIを業務の基幹として活用している場合は特に重要です。BCP策定の観点では、「AIが使えなくなった際の代替業務フロー」を文書化しておくことが有効です。具体的には、AIで自動化しているタスクを一覧化し、それぞれの手動代替手順と担当者を割り当てます。BCP文書の中で「社内専用AI停止シナリオ」として1章立てると、停止時の初動判断が格段に早くなります。

Q4. 停止が月に1回以上繰り返す場合、経営者はどう判断すべきですか？

機器の老朽化または設定・環境の問題が疑われます。保守ベンダーに対して「停止記録（いつ、何が原因で止まったか、復旧にかかった時間）」の提出を求め、再発防止策を提案させることが必要です。改善が見られない場合は、機器の更新または保守ベンダーの変更を検討するタイミングです。停止コストの累積（復旧作業費＋業務停止による損失）が機器更新コストを上回ると試算できれば、投資判断の根拠になります。

Q5. 停止中に暫定でクラウドAIを利用してよいですか？

状況によっては有効な選択肢です。ただし、顧客情報・個人情報・法律上の守秘義務がある情報をクラウドサービスに入力することは、社内規程違反や情報漏洩リスクにつながります。暫定利用を許可する場合は、「入力可能な情報の範囲」を経営者判断として明示し、社員に周知することが必要です。「社内専用AIを選んだ理由（情報を外部に出さない）」と矛盾しない範囲での暫定利用にとどめることが原則です。

停止リスクに備えるための事前チェックリスト

以下のチェックリストを定期的（四半期に1回以上）に確認することで、停止時の被害を最小化できます。「確認できていない」項目が3つ以上ある場合は、優先的に整備を進めることを推奨します。

・緊急連絡先の文書化: サーバー保守ベンダーまたは社内担当者の連絡先が文書化されており、経営者を含む複数名がアクセスできる場所に保管されているか
・復旧手順書の存在と鮮度: サーバーの再起動手順、AIサービスの再起動手順が最新の設定を反映した状態で文書化されており、担当者不在でも実行できる内容になっているか
・バックアップの定期確認: 業務データおよびAIの設定ファイルのバックアップが定期的に取得されており、直近のバックアップが正常に完了しているかを月次で確認しているか
・RTOの設定: 「何時間以内に復旧できなければ代替手段に切り替えるか」の基準が業務用途ごとに決まっており、経営者と現場が共通認識を持っているか
・代替運用手順の準備: AI停止時に業務を手動またはクラウドサービスで代替するための手順と標準テンプレートが共有フォルダに用意されているか
・停止時の情報管理ルール: 暫定的にクラウドサービスを利用する際に入力してはいけない情報の範囲が社内規程として定められており、全員に周知されているか
・停止記録の管理と再発防止: 過去の停止記録（日時・原因・復旧時間）が記録されており、同じ原因での再停止を防ぐための対策が実施されているか
・保守契約の内容確認: 保守ベンダーとのSLA（対応時間の保証）が現在のRTOと整合しているかを年次で確認しているか

特に「緊急連絡先の文書化」と「復旧手順書の存在」の2項目は、停止時の初動に直接影響します。他の項目より先に対応することを強く推奨します。

まとめ

社内専用AIの停止対応で経営者が押さえるポイントを3点に整理します。

第1に、初動30分以内に3ステップを完了することです。「停止の事実確認と影響範囲の把握（5分）」「担当者への連絡と診断依頼（10分）」「暫定運用の宣言と業務指示（15分）」という流れを事前に意識しておくだけで、停止時の混乱が大幅に減ります。経営者が担うのは技術的な修理ではなく、業務判断と情報共有です。

第2に、停止が長引く場合の判断基準を事前に設定しておくことです。RTOの設定、代替手段の準備、復旧手順書の整備という3点がBCPの核心です。BCPの「社内専用AI停止シナリオ」として1章立てて文書化しておくと、経営者の判断スピードが大きく上がります。

第3に、クラウドサービスとの対応の違いを理解した上で、自社で対応できる体制を整えることです。保守ベンダーの連絡先、管理権限の所在、バックアップ設定の有無がこの体制の基盤です。四半期ごとに上記のチェックリストで確認する習慣をつけることが、停止リスクの継続的な低減につながります。

社内専用AIは情報漏洩ゼロで業務効率化を実現するための重要なインフラです。この機会に、停止時の対応体制が整っているかを経営者自身の目で確認してみてください。