2026 年 6 月 7 日の早朝、メモと共同作業のためのアプリ Notion は、内蔵 AI 機能に使っている、Anthropic 社が開発した Claude モデルのエラー率が上がったことを受け、Anthropic のモデルをまとめて停止した。Claude の公式ステータスページによれば、この障害は調査開始から解決の宣言まで一時間足らずだった。一方、TechCrunch の報道では、Notion がアクセスの復旧を発表したのは約十二時間後だった。

誰かの対応がまずかったという話ではない。不安定な提供元を止めるのはもっともな防御で、いつ再開するかにも確認が要る。要点は、提供元の障害は一時間だったのに、利用者が感じた停止はずっと長くなりうるということだ。その長さを決めるのは、利用者自身に備えがあるかどうかだ。

だから AI を使う流れが頼れるかどうかを判断するとき、提供元が次にいつ止まるかを予想する必要はない。問うべきなのは、AI が止まったその瞬間、仕事をどう続けられるのか、そして誰が切り替えを決めるのかだ。

障害が短くても、止まる時間は短いとは限らない

AI が書く速さを少し上げているだけなら、待てば済む。厄介なのは、長く使ううちに前後の流れが AI の出力を前提に組まれていくことだ。会議の文字起こしは AI との対話の中にしかなく、問い合わせは AI が分類してから担当者に届き、日報は AI がまとめてから送られる。そうなると、AI が応答しないときに影響を受けるのは速さだけではない。次の人は何も受け取れないかもしれない。

ソフトウェアのコンサルティング会社 Thoughtworks は、同じ年の 6 月初めに起きた別の Claude 障害のあと、多くの企業が生成 AI をすでに基盤として使っているのに、データベースやクラウドほどの備えをしていないと書いた。最初に勧めているのは「グレースフル・デグラデーション」、つまり AI の機能が止まったら、システム全体が固まるのではなく、AI に頼らない、結果の決まった予測可能なやり方に退くことだ。

まず「AI なしの版」を書いておく

毎日動いている流れを一つ選び、三つの問いに答える。

元データは AI の外にあるか。 文書、文字起こし、チケット、顧客の記録は、まず管理されたシステムに置き、AI は読んで整理するだけにする。原文が AI との対話の中にしかなければ、障害のときに人も取り出せない。

最小限の成果物は何か。 AI がないとき、次の人が引き継げるように今日少なくとも何を渡すか。会議の記録なら、まず決定事項、やること、確認待ちの問いだけでいい。問い合わせの振り分けなら、顧客名、問題の種類、緊急度、担当者だけ残せばいい。形式は AI の完成品をまねる必要はなく、後ろの工程が続けられれば十分だ。

誰が切り替えを決めるか。 「いまから人の作業に切り替える」と誰が判断し、どんな条件で AI に戻し、戻す前に何を確かめるかを書いておく。Notion の例が示すように、止めるのは速い。判断が要るのは再開のほうだ。その判断の担当者がいなければ、停止はずるずると延びる。

広告

外への操作は、送る前に止められるようにする

データを読むだけ、要約を下書きするだけの流れなら、障害のあとにやり直せば済むことが多い。だが AI がメールを送る、顧客データを更新する、文書を書き換える、スケジュールを起動するなら、サービスが不安定なときの誤った出力や自動の再試行が、そのまま顧客や正式な記録に流れ込みうる。こうした流れでは、外への操作の前に停止点を設け、生成されたがまだ確認されていない内容を人が止めて確かめられるようにする。

サービスが戻っても、まとめてやり直さないこと。半分まで書き戻されたデータの片付け方は、自動化が途中で止まったら、やり直す前に何がもう起きたかを確かめるを参考にしてほしい。

備えとは、もう一社つなぐことではない

備えとは、必ずしも別の AI 提供元と契約することではない。モデルを替えれば出力の形式や品質が変わり、後ろの工程でも確認し直す必要がある。Thoughtworks も、複数の提供元を用意すると複雑さが増し、モデル間で結果がそろうかを先に確かめる必要があると指摘している。小さなチームの多くにとっては、人が読めて後ろの工程が使える最小限の成果物のほうが、モデルを一つ増やすより現実的だ。

今日はまず一つの流れから始めよう。元データを見つけ、AI なしでの最小限の成果物を書き、切り替えの権限を持つ人を一人決める。その流れの裏に、主要なアカウントに触れる常駐の AI アシスタントがいるなら、その権限の境界も一緒に確かめてほしい。常駐型 AI アシスタントは、止まることを覚えてから主要アカウントにつなぐも参考になる。

AI 整理カード

AI サービスが止まったとき、私たちの仕事の流れが一緒に止まらないか、止まるならどれくらいかを確かめたい。
判断方法はこの記事による：https://boosterminiclass.com/ja/posts/ai-tool-outage-dependency-checklist/
記事の見方はこうだ。提供元の障害は短いこともあるが、流れが止まる長さは自分の備えで決まる。元データは AI の外に置き、AI なしでも渡せる最小限の成果物を用意し、人の作業への切り替えと AI への復帰を誰が決めるかを決め、外への操作は送る前に止められるようにする。

まず、私が許可した流れの文書、作業記録、設定を読み取り専用で確認してほしい。データの変更、メールの送信、スケジュールの起動、外部システムに影響する操作は行わないこと。
1. 「AI が応答しないと、次の段階が何も受け取れない」段階を一つ見つけ、見た直接の根拠を引用し、事実と推測を分けて書く；
2. その段階の元データがどこにあり、AI が止まったときに人が原文を取り出せるかを確かめる；
3. AI に頼らない最小限の成果物を下書きする。後ろの工程に最低限どの項目が要り、誰が作るか；
4. 人の作業への切り替えを決める権限を持つのは誰か、AI に戻す前に何を確かめるか、流れの中のどの外への操作の前に停止点を置くべきかを挙げる。
根拠のない部分は「要確認」とする。最後に「続けてよい」「備えを補う必要あり」「いったん止める」のどれか一つだけを判定し、理由を示す。書き込み、通知、スケジュールの操作はすべて提案にとどめ、担当者の確認を待つこと。
広告

Share

このミニクラスを共有

このミニクラスが仕事の詰まりをほどく助けになったら、AI の使い方を考えている人にも共有してください。

参考資料