会議が終わり、担当者は Notion のメモから決定事項とタスクを取り出そうとする。ところが、いつもの AI ボタンが使えない。要約が一つ遅れるだけなら待てばよい。しかし、その要約を受け取って動く同僚がいて、顧客への返信や CRM の更新まで同じ流れにつながっていれば、止まる範囲はボタンの外へ広がる。
2026 年 6 月 7 日には、Notion から Anthropic へのアクセスに影響するサービス不調と、その後の復旧が報じられた。同日付の Claude ステータスページにも、複数のモデルや製品でエラーや性能低下が発生し、解消された記録がある。この出来事から確認すべきなのは、特定のサービスが信頼できるかどうかではない。AI 機能が通常業務に入ったあと、使えない時間をチームがどう乗り切るかである。
考えるべき問いは一つだ。その AI ボタンが今すぐ灰色になったら、どこで仕事が止まり、何ならまだ届けられるだろうか。
止まる場所を四つの条件で見つける
AI は、使い始めた時点では作業を速める補助機能に見える。文書要約、会議メモからのタスク抽出、顧客サポートの振り分けが日常化すると、やがて次の担当者が AI の出力を待つようになる。そこで初めて、便利な機能が業務上の依存先になっていたと分かる。
確認に使うのは、ツールの性能表ではなく次の四条件である。
| 確認する条件 | 稼働中に確かめること | AI が使えない間の合格条件 |
|---|---|---|
| 元データ | 会議メモ、顧客記録、文書、調査資料がどこに保存されているか | AI チャットを開けなくても、管理下の記録から素材を読める |
| 人への引き継ぎ | 誰が代わりに処理し、どの形式を次の担当者へ渡すか | 担当者と、表・チケット・短いメモなどの実用形式が決まっている |
| 外部操作の停止点 | メール送信、CRM 更新、予約実行などをどこで止められるか | 誤った処理が外部へ広がる前に無効化し、人が内容を確認できる |
| 最小納品物 | AI なしでも今日中に何を渡せるか | 完成度は下がっても、次の人が作業を続けられる成果物を出せる |
四条件がそろっていれば、AI は重要な補助役でありながら、元データを閉じ込める唯一の入口にはならない。反対に、どれか一つでも答えられなければ、障害時の問題は「生成が遅い」ではなく「誰も続きを始められない」に変わる。
代替経路は、次の人が使えればよい
会議の文字起こしが AI の画面にしか残っていなければ、人は要約以前の素材へ戻れない。顧客の要望がモデルの短い結論にだけ圧縮されていれば、サポート担当者は判断の根拠を確認できない。元データは文書、表、CRM、リポジトリ、チケットシステム、共有フォルダなど、自分たちが管理できる記録先に残す必要がある。AI はそこから読み取り、整理し、候補を作ればよい。
人が引き継ぐ形式は、通常時の AI 出力と同じ品質でなくても構わない。会議メモなら、決定事項、担当タスク、未確認点だけで次の打ち合わせへ進める。顧客サポートの振り分けなら、顧客名、問題の種類、緊急度、担当者が分かれば一次対応を始められる。文書要約なら、重要な段落と確認が必要な箇所を抜き出すだけでも役に立つ。
ただし、AI エージェントがメールを送る、CRM を書き換える、予定された外部処理を起動するといった場合は、単に手作業へ切り替えるだけでは足りない。外部操作が実行される直前に止められなければ、障害中の再試行や不完全な出力が顧客や共有記録へ届くおそれがある。停止後の後始末まで設計するには、自動化が途中で失敗したら、誰が後始末をするのかという観点が役立つ。常時動く仕組みなら、常駐型AIアシスタントは、止まれるようになってから主要アカウントにつなぐで扱う権限境界も同時に確認したい。
今日の作業に「AI なし版」を一つ足す
今週使った AI ワークフローを一つ選び、普段の出力がなくても次の担当者へ渡せるものを決める。たとえば会議メモを扱うなら、元の記録を保存している場所を確認し、要約が作れないときの担当者と簡易フォーマットを用意する。メール送信や CRM 更新まで自動化しているなら、外部操作を止める担当者と停止位置も明記する。
最初から完全な災害復旧計画を作る必要はない。まずは、AI を使わずに作れる最小納品物を一つ実際に作ってみる。それを別の人が受け取り、続きを始められれば代替経路は機能している。受け取っても判断できないなら、足りない元データか引き継ぎ項目を一つだけ補う。
AI が復旧すれば、再び速く便利な方法へ戻せる。それでも、素材は手元に残り、外部操作は止められ、人が最低限の成果を渡せる。AI ボタンの状態と仕事の継続を切り離すとは、そういう設計である。
AI整理カード
現在の作業環境から、AI が止まったときに最初に困る工程を一つ見つけるためのプロンプトである。
現在アクセスできるワークスペース、リポジトリ、プロジェクト記録、チケット、文書を、変更を加えず読み取り専用で調査すること。AI ツールまたは単一のモデル提供元に依存している実際の工程を一つ自分で特定し、参照したファイル名、記録、設定、ログなどの直接的な根拠を示すこと。確認できた事実と推測は明確に分け、分からない項目は「要確認」と記すこと。必要な環境へアクセスできない場合に限り、対象や権限を特定する質問を一つだけ行い、読者に事前整理済みの資料を要求しないこと。
特定した工程について、元データが AI の外に残っているか、人が引き継ぐ担当者と実用形式があるか、メール送信・CRM 更新・予約実行などの外部操作を止められるか、AI なしで作れる最小納品物は何かを検討すること。結論は「継続可能」「条件付きで継続」「いったん停止」のいずれか一つとし、その理由、直接的な根拠、要確認事項を短くまとめること。最後に、今日すぐ実行できる次の一手を一つ示すこと。ただし、ファイル編集、送信、削除、権限変更、外部サービスの実行は行わず、提案した停止点と最小納品物は担当者の承認を受けてから適用すること。
生活四コマ

- 最初は、チームが多くのタスクを一つの AI ボタンにつなぎ、仕事は速く滑らかに見える。
- ボタンが暗くなると、止まるのはツールだけではなく、その出力を待つ人とデータだと分かる。
- 元データ、予備表、人の引き継ぎ点、停止スイッチを並べると、中断時に誰が何をするか分かる。
- 最後は、AI が便利な補助役に戻る。ただし最小納品物は、もう一つの提供元や一つのボタンだけに依存しない。
参考文献
- TechCrunch: Notion restores access to Anthropic after service disruption — https://techcrunch.com/2026/06/07/notion-restores-access-to-anthropic-after-service-disruption/
- Claude Status: Elevated errors on Claude Opus 4.7 — https://status.claude.com/incidents/1h2k3ryt64wl
- Claude Status: Degraded performance for multiple models — https://status.claude.com/incidents/s4pq658bt69h
- Notion Status: Notion status page — https://status.notion.so/
- Thoughtworks: What the Claude outage teaches us about AI as infrastructure — https://www.thoughtworks.com/en-us/insights/blog/generative-ai/claude-outage-june-2026



