生成AIのサービスが数十分から数時間、応答しなくなる。あるいは、つながるけれど極端に遅い、長い文章を投げると途中で切れる——こうした不調は、特定のサービスに限らず、ここ数年たびたび報じられています。利用者が増えるほど、障害のニュースは目立つようになりました。
問題は「障害が起きること」そのものではありません。外部のサービスである以上、停止はゼロにできないからです。本当の問題は、止まったときに現場が固まってしまうことです。議事録が作れない、問い合わせの一次返信が出せない、見積書のたたき台が書けない。そして誰も、代わりに何をすればいいか決めていない。
この記事では、生成AIが止まった日に業務を止めないための「代わりの手順」を、30分程度で作れる形にまとめます。大がかりな事業継続計画（BCP、災害や障害が起きても事業を続けるための計画）を作る話ではありません。すでにAIを使っている業務について、紙1枚ぶんの決め事を先に用意しておく、という話です。
「止まる」は一種類ではない——4つの止まり方を分けて考える
対策を考える前に、止まり方を分けておくと判断が速くなります。全面停止だけを想定していると、「つながるけれど様子がおかしい」という一番やっかいな状態に対応できません。
| 止まり方 | 現場で見える症状 | やっかいな点 |
|---|---|---|
| 全面停止 | 画面が開かない、エラーが返る | 分かりやすい。むしろ対応しやすい |
| 部分停止 | 文章生成は動くが、ファイル読み込みだけ失敗する | 使える機能と使えない機能の切り分けに時間を取られる |
| 性能劣化 | 応答が極端に遅い、途中で切れる | 「もう少し待てば動く」と思い、待ち続けてしまう |
| 品質劣化 | 動くが、いつもより答えが雑、指示を無視する | 気づかないまま成果物に混ざる。最も発見が遅れる |
特に注意したいのが最後の品質劣化です。システムとしては正常に動いているため、提供側の障害情報にも載らないことがあります。「今日はなんだか出力がおかしい」という現場の違和感を、誰がどこに報告するかを決めておくと、成果物の事故を一段減らせます。
最初に決めるのは復旧手順ではなく「切り替えの判断基準」
障害時にいちばん時間を溶かすのは、復旧作業ではなく「待つか、切り替えるか」の迷いです。5分待ち、10分待ち、結局30分経ってから手作業を始める。これが一番遅い。
そこで、業務ごとに待ってよい時間の上限を先に数字で決めます。システム運用の世界では、どれくらいで復旧させるかの目標をRTO（目標復旧時間）と呼びますが、ここではもっと素朴に「何分で手を切り替えるか」で十分です。
- 締め切りから逆算する：15時までに顧客へ返信が必要なら、14時20分が切り替え時刻
- 判断する人を1人決める：全員が各自で判断すると、同じ作業を二重にやるか、誰もやらないかのどちらかになる
- 判断の合図を決める：チャットの特定チャンネルに「AI切り替え」と書く、といった単純なもので足りる
この「何分で切り替えるか」を決めるには、その作業をAIなしでやった場合に何分かかるかを知っている必要があります。導入前に作業時間を測っておくと、こういう場面で効きます。測り方はAI導入の成否は「始める前の1週間」で決まる — 削減時間を数字で置くベースライン測定の実務で詳しく書いています。
代替手順は3つの型に分けると設計が速い
すべての業務に完璧な代替案を用意する必要はありません。業務を次の3つに仕分けるだけで、作業量が大きく減ります。
| 型 | 内容 | 向いている業務 |
|---|---|---|
| 人手に戻す | AIを使う前のやり方に一時的に戻す | 議事録、要約、メール下書きなど、元々人がやっていた作業 |
| 別の経路に回す | 別サービス、別モデル、オフラインの手元ツールに切り替える | 文字起こし、翻訳、分類など、代替が効きやすい作業 |
| 後回しにする | その日は止める。溜めておいて復旧後にまとめて処理 | 社内向けの集計、分析、定期レポートなど締め切りが緩いもの |
「人手に戻す」は、戻れる状態を保っておく必要がある
ここが見落とされがちです。AIを入れて半年も経つと、元のテンプレートが行方不明になっていたり、新人が手作業のやり方を一度も経験していなかったりします。戻る先が残っていないと、「人手に戻す」は選択肢になりません。
対策はシンプルで、AIに渡しているひな形や指示文を、そのまま人が使える形で保管しておくことです。指示文には「どんな項目を、どんな順番で、どの粒度で書くか」が書かれているはずなので、それは人が書くときの手順書としてもほぼそのまま使えます。社内ひな形の整え方はAIの答えのぶれは頼み方でそろう — 社内ひな形の作り方が参考になります。
「別の経路に回す」は、事前の動作確認が前提
障害の最中に初めて別サービスを開いても、ログインできない、権限がない、出力形式が違う、で終わります。半年に一度でよいので、代替経路で実際に1件処理してみる時間を取ってください。
また、代替先に社外サービスを使う場合は、普段と同じ情報の線引きが適用されるかを確認します。緊急時だからといって、普段は入れない情報を別サービスに投げてしまうのが、障害対応で起きがちな事故です。線引きの考え方はAIに個人情報を入れる前に決める5つのこと──「全面禁止」より「線引き」が業務を回すにまとめています。
紙1枚の「AI停止時カード」に書く6項目
ここまでの内容を、業務ごとに1枚のカードへ落とし込みます。長い手順書は読まれません。印刷して貼れるくらいの分量が実用的です。
- 対象業務：例「問い合わせメールの一次返信下書き」
- 通常の手順：どのツールで、誰が、どう使っているか（1〜2行）
- 切り替え時刻の決め方：例「返信期限の40分前」
- 判断する人：役職名ではなく、担当者名と不在時の代理
- 代わりにやること：3つの型のどれか。手順は箇条書きで3〜5行
- 復旧後にやること：溜めた分の処理、品質の再確認、記録の残し方
6番目を忘れないでください。復旧後に「手作業で作った分」と「AIで作った分」が混在し、どちらが最新か分からなくなる混乱は、障害そのものより長引くことがあります。
たとえば次のような場面です。ある部署で、障害中に手作業で作った議事録と、復旧後にAIが自動生成した議事録が両方フォルダに入ってしまい、どちらを正とするかで後日の確認に時間がかかった——こうした取り違えは、「障害中に作った文書はファイル名の先頭に印をつける」といった一行の決め事で防げます。
平常時にやっておく4つの備え
1. 障害情報の確認先を1か所にまとめる
主要な生成AIサービスの多くは、稼働状況を知らせるステータスページを公開しています。自社が使っているサービスのページをブックマークし、社内の共有ドキュメントに並べておきます。「自分の環境だけの問題か、全体の障害か」を30秒で切り分けられるだけで、調査の無駄が消えます。
2. 依存している業務を棚卸しする
意外と多いのが、「誰かが個人的に使い始めたAIが、いつの間にか業務の前提になっている」というケースです。月に一度、部署内で「今AIを使っている作業」を挙げてもらうだけで、見えていなかった依存が出てきます。
3. 1つのサービスに全部を寄せない
これは「複数契約しましょう」という話ではなく、止まったときの影響範囲を1つの業務領域に閉じ込めるという設計の話です。文字起こしも、要約も、社内検索も、顧客対応も、すべて同じ1つの経路に乗せていると、その経路が落ちた瞬間に部署全体が止まります。
4. 年に一度は「止まった日」をやってみる
30分でいいので、「今日はAIを使わない」と決めて通常業務を回してみる日を作ります。手順書の抜けは、実際にやってみないと見つかりません。防災訓練と同じ発想です。
なお、国内では経済産業省と総務省が「AI事業者ガイドライン」を公開しており、AIを利用する事業者に対して、不具合や事故が起きた場合の対応をあらかじめ備えておくことの重要性が示されています。細かい要件は業種や用途によって変わるため、自社に関わる部分は原文で確認することをおすすめします。
まとめ
生成AIの障害は、今後も一定の頻度で起き続けると考えるのが現実的です。だからこそ、備えの中心は「止まらないようにする」ことではなく、止まったときに迷わないことに置くべきです。
- 止まり方は全面停止だけでなく、部分停止・性能劣化・品質劣化の4種類がある
- 最初に決めるのは復旧手順ではなく「何分待ったら切り替えるか」と「誰が決めるか」
- 代替手順は「人手に戻す」「別の経路に回す」「後回しにする」の3つに仕分ける
- 「人手に戻す」ためには、戻れる状態（ひな形と、経験のある人）を保つ必要がある
- 復旧後の後始末まで書いて、紙1枚のカードにする
まずは、自社でAIを使っている業務を3つ挙げて、そのうち止まると一番困る1つについてカードを作ってみてください。30分あれば書けます。そして次に障害のニュースを見たとき、慌てるのではなく「うちは決めてある」と言える状態になっているはずです。
この記事は、AI で下書きを作り、益山康秀（運営者）が内容を確認して公開しています
