使っているAIが止まったらどうする？｜業務を止めない備え

2025年11月18日、世界中のサイトの入口にあたる配信網で障害が起きました。提供元が公開した事後報告によると、影響が始まったのは協定世界時の11時20分、全機能の復旧は同日17時06分。約5時間46分です。きっかけは、あるデータベースの権限を変えたことで、自動判定に使う設定ファイルの中身が二重に出力され、容量が倍になって読み込み側の上限を超えたことでした。利用していた会社の側は、その日、自社では何も変えていません。「使っているAIが急に応答しなくなって、その日の作業が全部止まった」「提供元の障害だと分かったが、社内に何をどう伝えるかを誰も決めていなかった」——止まったあとの相談は、たいていこの二つの言い方で持ち込まれます。止まること自体は、利用する側では防げません。防げるのは、止まった当日に、何を止めて何を人手に戻すかを、その場で考えることです。この記事では、止まり方の四つの区分、最初の15分で確かめる順番、止めてよい業務の決め方、提供終了の告知が届く仕組み、代替の持ち方、復帰したあとの確認、そして契約で戻ってくるものの範囲までを、当日そのまま使える段取りとして整理します。

自社の設定を疑う前に、外で何が起きたかを見る

冒頭の障害の記録を、もう少し細かく追います。提供元の事後報告に載っている時刻は、影響の開始が11時20分、顧客の通信でエラーが観測されたのが11時28分、不正な設定ファイルの生成が止まったのが14時24分、主要な影響が解消したのが14時30分、そして全機能の復旧が17時06分です。主要な影響の解消から全面復旧までに、さらに2時間半かかっています。止まった時間と、元どおりに戻った時間は別物だということが、この記録から読み取れます。

同じ報告には、もう一つ実務に効く記述があります。この提供元の稼働状況を知らせるページは、自社の仕組みに依存しない外部で運用されているのに、同じ時間帯に見られなくなりました。報告はこれを偶然の一致だと記しています。理由はどうあれ、止まっているかを確かめるための公表ページが、同時に見られなくなることは実際に起きるという事実が残ります。稼働状況の確認先を一つしか持っていない備えは、この場合に無力です。

なお、この配信網の障害でどのAIサービスが止まったかは、この事後報告には書かれていません。報道や利用者の投稿では複数のサービス名が挙がっていましたが、どのサービスがどれだけ止まったかは、各社が自社で出す公表と突き合わせる以外に確かめる方法がありません。ここから引き出せる教訓は単純です。自社の設定や回線を疑って30分を使う前に、外を見る順番を持っておく。その順番を次章以降で組み立てます。

止まり方は四つに分かれる

「AIが止まった」という一言には、対処がまったく違う四つの状態が入っています。同じ言葉で報告されるため、受けた側が最初に区分を確かめないと、見当違いの手を打つことになります。応答が返らない、応答が遅い、応答は返るが中身が変わった、そして提供そのものが終わる。この四つです。

止まり方	最初に見えること	当日に打てる手	先に決めておくこと
応答しない	画面のエラー、処理の失敗が連続する	代替の経路に切り替える、人手に戻す	切り替えの判断者と、切り替え先
遅い	終わるが時間がかかる、途中で切れる	待ち時間の上限で打ち切る	何秒で打ち切るか、打ち切ったあとの扱い
答えが変わった	誰も気づかない。品質の低下として報告される	前の版に戻す、当面は人が確認する	出力を比べる固定の入力と、比べる頻度
提供が終わる	告知のメールが届いている	移行の計画を立てる、期限を逆算する	告知の受信先と、読む人

この四つのうち、実務でいちばん厄介なのは三番目の「答えが変わった」です。応答は正常に返るため、監視の仕組みには何も出ません。気づくのは現場の担当者で、報告は「最近この出力が使いにくい」という感想の形で上がってきます。感想は起票されにくく、起票されても原因の調査に回りません。障害として扱われない止まり方が、いちばん長く放置されるのは、この経路のせいです。第5章で、これが起きる仕組みを公開文書から確かめます。

二番目の「遅い」も軽く見られがちですが、業務の側から見れば止まったのと同じです。1件30秒で終わっていた処理が3分かかるようになれば、1日200件の処理は100分から600分に伸びます。人が待つ業務なら、その日の予定は崩れます。だから「遅い」には何秒で打ち切るかを数字で決めておく必要があります。打ち切りの数字がないと、担当者は延々と待ち続け、待っていること自体が誰にも共有されません。

最初の15分に、原因を探さない

止まった直後にやりがちなのは、原因を探すことです。しかし利用する側で分かる原因は限られています。提供元の内部で起きたことは、事後報告が出るまで分かりません。最初の15分を原因探しに使うと、その15分のあいだ業務は止まったまま、利用者への連絡も出ないままになります。最初の15分でやるのは、原因の特定ではなく切り分けと一報です。順番を固定しておきます。

この一報の文面は、止まる前に作っておきます。当日に文面を考え始めると、書いた人の判断で「復旧の見込み」を書いてしまい、それが外れて二次的な不信を生みます。見込みは書かず、次に知らせる時刻だけを書く。これを型にしておけば、誰が書いても同じ品質の一報が出ます。次に知らせる時刻は、30分後か1時間後のどちらかに寄せておくと、受け取る側も予定を立てられます。

止めてよい業務は、止まってから選べない

代替の道具をいくつ用意しても、当日にすべての業務を維持することはできません。人手に戻すには人が要り、人はその日ほかの仕事をしています。だから先に決めるのは道具ではなく、業務の順番です。三つの階層に分けると運用に載ります。止めない業務、半日待てる業務、今日は止める業務の三つです。

マーケや情報システムの現場で言えば、止めない側に入るのは、顧客からの問い合わせへの初回返答、受注や申込に関わる確認、当日公開が約束されている告知の類です。半日待てる側は、記事や資料の下書き、社内向けの要約、定例の集計。今日は止める側は、改善案の洗い出し、実験的な検証、優先度の低い一括処理です。この仕分けは業務の重要度ではなく、遅れたときに外へ影響が出るかで決めます。社内で重要とされている業務ほど、1日遅れても外には見えないことがよくあります。

決めるのは、業務の責任者ではなく一段上の人がよいです。自分の業務を止める判断は、担当者本人には出しにくいためです。そして仕分けの結果は、当日に探せる場所に置きます。共有の場所に1枚だけ置き、止まったときに開くのはこの1枚だと、名前で分かるようにしておく。四つの止まり方のうちどれが起きても、まずこの1枚を開くところから始まる、という形にします。

答えは返ってくるのに、中身が変わっている

三番目の止まり方が起きる仕組みは、提供元の公開文書に書いてあります。マイクロソフトが公開しているモデルのライフサイクルの文書には、標準的な三種類のデプロイの形態について「モデル バージョンが廃止されたときに自動アップグレードを管理します」と明記されています。つまり利用者が何もしなくても、呼んでいるモデルの版は入れ替わります。同じ文書には「自動アップグレードはリージョンごとに順次スケジュールされます」ともあります。

ここが実務で効きます。地域ごとに順次であれば、同じ社内で、東京から呼んだ結果と別の地域から呼んだ結果が、一時期だけ食い違うことが起こります。さらに同じ文書は「新しいモデル バージョンがまだそのリージョンで個別に使用できない場合……でも発生する可能性があります」と書いています。一覧に出ていないから自分の環境はまだだ、という読み方はできません。予約したスループットを使う形態については「自動アップグレードされません」と別に書かれており、こちらは逆に、自分で移さないと止まります。形態によって真逆の備えが必要です。

止めたい場合の設定も公開されています。同じ文書のよくある質問には、更新の選択肢として「新しい既定の版が出たら上げる」「提供終了時にだけ上げる」「自動では上げない」の三つが並び、三つ目については提供終了時にデプロイが動作を停止すると明記されています。勝手に変わらないようにすると、期限が来た日に止まる。どちらかを選ぶ話であって、変わらずに動き続ける選択肢はありません。なお試験提供中の版については「残るオプションはありません」と書かれ、少なくとも30日の通知で強制的に入れ替わります。

提供が終わる日は、使い始めた日に決まっている

四番目の止まり方は、事故ではなく予定です。前章と同じ公開文書には、一般提供されたモデルの引退日が起動から18か月後としてプログラムで設定されると書かれています。個別の告知があってから期限が決まるのではなく、使えるようになった時点で終わる日が入っている、という構造です。問い合わせ用の一覧を見ると、その日を延ばせるかという問いに対して「いいえ。退職日は延長できません」と答えが載っています。

18か月のあいだも一様ではありません。同じ文書によると、起動から12か月後の時点で「廃止」の段階に入り、既存の利用者は使い続けられますが新しい利用者はアクセスできなくなります。そしてこの「既存の利用者」の判定は契約の単位で行われ、同じ組織の中で新しく作った契約は、アクセスの権利を引き継がないと明記されています。部門を分けて新しい契約を切ったら、その部門だけ使えない。こういう形の詰まり方は、事前に読んでいないと当日まで気づけません。

提供元による差もあります。同じ文書には、一部の提供元の一般提供モデルは18か月ではなく12か月のライフサイクルに従うと書かれています。試験提供中のモデルは「通常は90日以内」の提供終了日を持って始まります。加えて、コンプライアンスや安全上の問題が判明した場合は短縮した通知で緊急の提供終了を行う権利が留保されています。18か月という数字は上限の目安であって、約束された利用期間ではありません。

通知は届いている。読む人が決まっていないだけ

提供終了の告知は、実際にはかなり手前で届きます。三つの提供元の公開文書から、告知の期間を並べてみます。日数の定義が微妙に違うので、そのまま比べるのではなく「自社はどの数字を前提に動くか」を決める材料として読みます。

提供元と対象	公表されている告知の期間	文書に書かれている届け方
マイクロソフト・一般提供のモデル	引退の少なくとも60日前	有効なデプロイを持つ契約の所有者へ電子メール、加えて稼働情報の画面に助言が出る
マイクロソフト・試験提供中のモデル	引退の少なくとも30日前	同上。代替がある場合は自動で入れ替わる
オープンエーアイ・一般提供のモデル	少なくとも6か月前	文書上の掲載と、停止予定日の一覧
オープンエーアイ・派生や試験提供	派生は少なくとも3か月前、試験提供は2週間程度もありうる	同上
アンソロピック・公開済みのモデル	引退の少なくとも60日前	有効な利用がある顧客へ電子メールと文書での告知

実際の間隔も数えてみました。アンソロピックの公開文書に載っている告知の履歴では、2026年4月14日の告知に対する引退が6月15日で62日、6月5日の告知に対する引退が8月5日で61日、2025年10月28日の告知に対する引退が2026年2月19日で114日、2025年6月30日の告知に対する引退が2026年1月5日で189日です。最短61日から最長189日まで、3倍以上の開きがある。つまり「だいたい半年ある」という前提で計画を立てると、短い側に当たったときに間に合いません。

そしてどの提供元も、届け先は契約の所有者や有効な利用がある窓口です。ここが実務の穴になります。契約を情報システム部門が持ち、実際に使っているのがマーケや営業の部門であれば、告知は使っていない人のところに届きます。受信先の共有メールを作り、そこを見る担当を月次で回す。稼働情報の画面については電子メールとテキストメッセージ、外部への通知の受け口でアラートを作れると文書に書かれているので、社内の連絡先に流し込む設定を最初にしておきます。

代替の持ち方は三通りしかない

止まったときに切り替える先は、整理すると三つです。同じ提供元の別の経路、別の提供元、人手。この三つは費用も準備の重さも違うので、業務ごとにどれを持つかを一つ選んでおきます。全部を持とうとすると、どれも準備が中途半端になって当日に使えません。

同じ提供元の別の経路は、いちばん軽い備えです。別の地域の窓口、別の契約、あるいは基盤を経由する形と直に呼ぶ形の二本立て。呼び出しの書き方がほぼ同じなので、切り替えは設定の変更で済みます。弱点は、提供元そのものが止まったときに一緒に落ちることです。別の提供元は、そこを埋めます。ただし出力の形と癖が違うので、切り替えたその日から同じ品質が出ると考えないほうがよい。事前に同じ入力で試して、どこがどう変わるかを控えておきます。

人手は、備えとしていちばん確実で、いちばん見落とされます。AIに任せる前の手順書を捨ててしまうと、人手に戻す道が消えます。自動化した業務については、人が手でやる場合の手順を1枚残しておく。所要時間と、その日に何件までさばけるかも書き添えます。三つのうちどれを選んでも、月に一度は実際に通します。通していない代替は、当日に認証が切れていたり、契約が失効していたりして使えません。

人手に戻す判断を、誰が何分で出すか

切り替えの判断は、技術の判断ではなく業務の判断です。にもかかわらず、止まったときに最初に気づくのは技術側なので、そのまま技術側が判断してしまいがちです。結果として「もう少し待てば復旧するかもしれない」という技術側の見立てで待ち続け、気づいたら半日が過ぎているという形になります。判断する人と、判断までの持ち時間を先に決めておきます。

持ち時間は、業務の階層に合わせます。止めない業務は15分、半日待てる業務は2時間、今日は止める業務は判断そのものが不要です。時間が来たら、復旧の見込みに関わらず切り替える。見込みで待つのをやめ、時計で切り替える。この一点だけでも、当日の混乱はかなり減ります。判断した人の名前と時刻は記録に残します。後日の振り返りで、その判断が早すぎたか遅すぎたかを見るためです。

ここで一つ、線を引いておくことがあります。切り分けと影響範囲の判定を、生成AIに任せてはいけません。止まっているのはその生成AIかもしれない、という理由だけではありません。障害の切り分けは、社内の構成と契約の形を前提にした判断で、そこを外部のモデルに推測させると、もっともらしい誤答が返ってきます。調べものの補助に使うのは構いませんが、切り替えるかどうかの判断は人が出します。第13章で詳しく書きます。

復帰したあとに、取りこぼしが出る

復旧の連絡が来た時点で対応が終わる、と考えると取りこぼします。止まっていた時間に何が起きたかを、三つの方向から確かめます。途中で切れた処理、二重に走った処理、待たせたままの相手です。第1章で見たとおり、主要な影響の解消から全面復旧まで時間が空くこともあるので、復帰したという連絡と、元どおりに動いているかの確認は分けて行います。

途中で切れた処理は、出力が途中までしか残っていないものが典型です。文章の生成なら文末が切れ、集計なら一部の行が欠けます。見た目が完成しているのに中身が欠けている出力は、そのまま使われる危険があります。止まった時間帯に作られた出力を一覧で洗い出し、その時間帯のものだけは人が全部見る、と決めておくのが安全です。時間帯で区切れば、洗い出す条件は単純になります。

二重に走った処理は、切り替えのときに起きます。人手に回した分を、復旧後に自動処理が改めて実行してしまう。メールの送信や外部への登録が絡む業務では実害になります。切り替えのときにどこまで人手でやったかを記録に残すことが、そのまま二重実行の防止になります。待たせたままの相手については、止まっていた時間に届いた問い合わせや申込を時刻で抽出し、遅れの連絡を出す範囲を決めます。全員に出す必要はなく、約束の期限を越えた相手に絞れば実行できる量になります。

当日の記録に、何を残すか

記録は、後日の振り返りのためだけではありません。止まっている最中に、担当者が交代しても同じ状態から続けられるようにするためです。だから項目は少なく、書く場所は1か所に固定します。以下の項目を1枚に並べておけば、当日は埋めるだけになります。

この記録票は、月に一度読み返します。読み返すときに見るのは原因ではなく、持ち時間を守れたか、一報が時刻どおりに出たか、記録の空欄はどこかの三点です。空欄が同じ場所に続くなら、その項目は当日には埋められない項目です。埋められる形に書き換えるか、削ります。埋まらない項目を残しておくと、記録票そのものが使われなくなります。

契約で戻ってくるのは、利用料の一部だけ

止まったことによる損失は、契約で戻ってくるのでしょうか。公開されている品質保証の条件を一つ読んでみます。ある大手クラウドが公開している、言語や音声などを扱う機能群の条件では、月間の稼働率を99.9パーセント以上とすると書かれています。1か月を30日とすると43,200分で、その0.1パーセントは43.2分。つまり月に43分ほどまでは止まってよい、という約束です。

下回った場合に戻るのは、サービスクレジットと呼ばれる利用料の割戻しです。同じ条件では、99.9パーセントを下回ると10パーセント、99パーセントを下回ると25パーセント。そしてサービスクレジットが、品質水準を満たさなかったことに対する顧客の唯一かつ排他的な救済であると明記されています。仮に自社が使っているAIの提供元で、冒頭の障害と同じ346分の停止が起きたとします。43.2分の約8倍ですが、99パーセントの境界である432分は下回るので、戻るのは利用料の1割です。月に数万円の利用料なら、戻るのは数千円。止まった半日の業務は戻りません

除外の範囲も読んでおきます。同じ条件では、無償の階層には品質保証がなく、試験提供中の機能も対象外、提供者の管理外の要因や利用者側の誤用も除かれています。無償や試験提供の範囲で業務を回している場合、止まったときに主張できる根拠は契約上どこにもありません。なお、ここで読んだのは公開されている条件の一例で、運営主体や契約の形によって数字も文言も変わります。自社の契約書で確かめるのが前提です。そのうえで結論は変わりません。止まった時間は業務側で吸収するしかない。だから前の章までの段取りが必要になります。

切り分けと判定を、AIに任せない

AIが止まったときの対応をAIに考えさせる、という発想は自然に出てきます。ただし任せてよい範囲と、任せてはいけない範囲があります。任せてはいけないのは判断です。切り替えるかどうか、どの業務を止めるか、誰に遅れを知らせるかは、社内の事情と約束を前提にした判断で、外から見えない前提を含みます。前提が見えていないモデルは、それでも自信のある答えを返します。それが当日いちばん危険です。

任せてよいのは、材料をそろえる仕事です。公開されている事後報告の要約、自社の記録票から時刻を並べた一覧、過去の同種の障害との比較。このとき条件を一つ付けます。答えだけでなく、どの資料の何行目から取ったかを一緒に書かせる。根拠が書けない項目は、モデルが埋めた項目です。障害対応の記録に、根拠のない時刻や件数が混ざると、後日の振り返りが成り立たなくなります。根拠を書かせる指示は、精度を上げるためではなく、人が確かめる場所を特定するために入れます。

そして、これは当日に決める話ではありません。人が確認する範囲を、平時に先に決めておきます。たとえば、外に出る文面は必ず人が読む、時刻と件数と金額は必ず原典で突き合わせる、相手の社名と担当者名は必ず記録から写す。この三つを決めておけば、当日にどこまで任せるかを考える必要がなくなります。止まっている最中に線引きを考えるのは、いちばんうまくいかない進め方です。

どこで使っているかを、先に棚卸しする

ここまでの段取りは、自社がどこでAIを使っているかを把握している前提で成り立ちます。実際には、この前提が満たされていないことが多いです。業務の中に少しずつ入り込んだ生成AIは、契約の一覧にも業務の手順書にも載りません。止まった当日に「どこが止まるのか分からない」という状態から始めると、切り分けにも一報にも入れません。

棚卸しの手がかりは、提供元の側にもあります。アンソロピックの公開文書には、利用状況の画面から書き出すと鍵ごと・モデルごとの利用がCSVで見られると手順が書かれています。まずこれで、どの鍵がどのモデルをどれだけ呼んでいるかを出します。そのうえで、鍵と業務の対応を人が埋めます。どの鍵が誰の業務のものか分からない、という空欄が必ず出る。その空欄が、止まったときに把握できない範囲です。

見落としやすいのは、契約の外側で使われている分です。個人名義の契約、無償の枠、表計算や文書作成の拡張機能、外部の業者が自社の業務のために使っているもの。これらは自社の契約が生きていても、相手側の都合で止まります。棚卸し表には、業務名・使っている道具・契約の名義・止まったときの代替・止めてよい階層の五つを並べます。五つで足りるので、増やさずに全業務を埋め切ることを優先します。項目を増やして半分しか埋まらない表より、五項目で全部埋まった表のほうが当日に使えます。

よくある備え方の失敗と、公開前の確認項目

最後に、備えたつもりで当日に効かなかった形を並べます。どれも文書としては存在していて、しかし当日に開かれないか、開いても使えないものです。

• 代わりの提供元だけ契約してあり、切り替えの手順も判断者も決まっていない
• 止めてよい業務の一覧が資料の中に埋まっていて、当日に誰も場所を知らない
• 復旧の見込みを一報に書いてしまい、外れたときの説明に追われる
• 月に一度の切り替えの練習をやめてしまい、当日に認証の期限切れで使えない
• 提供終了の告知が情報システム部門にだけ届き、使っている部門に伝わらない
• 止まっていた時間帯に作られた出力を確かめずに、そのまま外へ出す
• 人手に回した分を記録せず、復旧後に自動処理が同じことをもう一度実行する

そのうえで、平時に通しておく確認項目を挙げます。この一覧は年に一度でよく、担当者が変わったとき、使う道具を増やしたとき、契約の形を変えたときは必ず通します。

• 業務ごとに、止めない・半日待てる・今日は止めるの三階層が割り当てられているか
• 止まり方の四区分ごとに、当日打つ手が書かれているか
• 稼働状況の確認先を二つ以上控えているか（公表ページが見られない場合に備えて）
• 利用者への一報の文面が用意され、見込みを書かない型になっているか
• 切り替えの判断者と持ち時間（15分・2時間など）が決まっているか
• 代替を月に一度実際に通しているか。認証と契約が生きているか
• 提供終了の告知の受信先が共有の窓口になっており、読む担当が月次で決まっているか
• 更新の選択肢の設定を把握しているか（自動で上がるのか、期限で止まるのか）
• 出力を比べる固定の入力セットがあり、比べる頻度が決まっているか
• 人が確認する範囲（外に出る文面・数値・固有名詞）が平時に決まっているか

• 本稿で引いた告知の期間・ライフサイクルの日数・品質保証の数字は、各提供元が公開している文書の記述です。提供元と契約の形によって変わるため、自社の契約書と管理画面で確かめてください
• 冒頭の障害の時刻と原因は、提供元が公開した事後報告の記述に基づきます。この障害で個々のAIサービスがどれだけ止まったかは、その報告には書かれていません
• 品質保証の条件は運営主体ごとに文言が異なります。本稿で読んだのは公開されている条件の一例で、自社の契約に同じ数字が適用されるとは限りません

まとめ

使っているAIは止まります。配信網の障害で自社に非がなくても止まり、版の入れ替えで答えが変わり、18か月の期限で提供が終わります。利用する側で防げるのは、止まること自体ではなく、当日に考え始めることです。止まり方を四つに分け、最初の15分を切り分けと一報に使い、止めてよい業務を三階層で先に決め、代替は三通りから一つ選んで月に一度通す。提供終了の告知は少なくとも60日前や6か月前に届いているので、受信先と読む人を決めておく。契約で戻るのは利用料の1割から25パーセントで、止まった半日の業務は戻りません。そして切り替えの判断と影響の判定は人が持ち、AIには材料と根拠を出させる。この段取りを1枚で持っている会社は、止まった日に業務を止めずに済みます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。