AIが止まっても、仕事を止めないために

AIを業務に使うなら、止まったときの対応も決めておく必要があります。手動に切り替えるのか、別のサービスを使うのか、復旧を待つのか。その判断と、作業を引き継げる記録を、普段から用意しておきたいと思います。

ブラウザーを操作できなくなり、作業が止まった

2026年10月7日、私の利用環境ではCodexのComputer Use（AIがブラウザーなどを操作する機能）でエラーが起き、サイト更新などの作業を進められなくなりました。普段できていたことが、同じように依頼してもできない。今回は、急がない作業について復旧を待つことにしました。

ただし、この体験だけでサービス全体の障害や原因を断定することはできません。確認時点のOpenAI公式ステータスは正常稼働の表示でした。公式ページの全体状況と、自分の環境で特定の操作ができるかは分けて確認する必要があります。

AIサービスに限らず、通信、認証、端末、外部サービスなど、仕事を支えるどこかでトラブルは起こり得ます。原因を調べることと、今必要な仕事をどう進めるかは、別々に考えておくべきでしょう。

止まったときの対応を、仕事の期限で選ぶ

すべての作業で同じ対応を取る必要はありません。期限と影響を確認し、次の選択肢から決めます。

• 手動でできる部分は手動で進める。急ぎの連絡や期限のある更新では、担当者が操作手順と確認方法を把握していれば、切り替えやすくなります。AI導入前の手順も残しておきます。

• 他のサービスを検討する。代替候補は平常時に小さく試しておきます。同じ指示でも結果が変わるので、利用できる機能、費用、データの取扱条件、結果の確認方法を確かめます。

• 最低限の機能で続ける。文章の下書きが保存されていれば、画像の追加は後日にして、必要な案内だけ出す方法もあります。何を省略でき、何は省略できないかを決めておきます。

• 作業の順番を変える。AIを必要とする作業だけ保留し、原稿の確認や資料整理など、今できる仕事を進めます。

• 復旧を待つ。急ぎでなく、無理な切り替えでミスが増えるなら、待つ判断も必要です。保留した仕事、担当者、次に状況を確認する時刻を残します。

たとえば「当日中のお知らせは手動対応」「急がない記事制作は保留」と決めておけば、障害のたびに最初から相談する負担を減らせます。手動対応でも、必要な権限や公開前の確認を省略しないことが前提です。

AIが何をしていたか分からないと、引き継げない

AIが作業してくれていても、その中で何をしていたか把握していなければ、停止した時点で困ります。「資料を見てまとめて」と頼み、結果だけを受け取る運用では、人が同じ作業を引き継ぐための情報が足りないことがあります。

たとえば、資料から対象データを抽出する仕事なら、何を対象とし、何を除外し、重複や判断の難しいものをどう扱うかが必要です。結果の件数だけを見ても、抜けや誤りを確認できません。

把握しておきたいのは、AI内部の細かな思考そのものではありません。入力資料、判断基準、処理手順、出典、計算式、処理件数、エラー、未確認事項など、人が結果を確かめ、作業を再開できる情報です。AIに説明を出させても、それ自体が正しいとは限らないため、元の資料や実際の保存結果と照合します。

指示と一緒に、根拠と確認方法を指定する

依頼の仕方も少し変えられます。単に「この資料を見て必要なものをまとめて」ではなく、次のように条件を付けます。

こうしておくと、結果を確認する入口ができます。担当者は元資料と突き合わせ、件数が合うか、要確認項目が残っていないかを確認して完了にします。全部を同じ重さで確認する必要はありませんが、公開内容や顧客対応に影響する項目は人が判断します。

「AIが出した結果だから大丈夫」という習慣は避けたいものです。子どものころの「○○さんが言っていたから間違いない」に似た感覚があります。誰が答えたかだけで安心せず、何を根拠にした結果かを確認したいと思います。

途中で止まった作業は、保存状態から確認する

サイト更新のように外部へ書き込む仕事では、エラーが出たことだけで「何も保存されていない」と判断しないようにします。保存は済んでいて、返答だけ受け取れなかった可能性もあるからです。

再開前に、対象ページ、保存した下書き、更新済みの項目、まだ確認していない項目を確認します。実際の保存先を見ずに同じ処理を繰り返すと、二重投稿や別の編集の上書きにつながるおそれがあります。更新前の内容と作業途中の記録を残しておけば、どこから再開するかを判断しやすくなります。

まず、一つの仕事で手動に戻れるか試す

備えは、大きな仕組みを作るところから始めなくてもよいと思います。普段AIに任せている仕事を一つ選び、次の項目を一枚にまとめます。

• 仕事の期限と、止まると影響を受ける相手

• 入力資料、判断基準、作業手順、完了の確認方法

• 手動対応の担当者と、必要な権限・道具

• 代替サービスと、利用前に確認する条件

• 更新前の内容、途中保存の場所、最後に確認した工程

• 復旧を待つ条件と、次に状況を確認する時刻

記録はAIのチャットだけに置かず、担当者が使える共有フォルダーなどにも保存します。機密情報や認証情報を手順書にそのまま貼り付けず、必要な人だけが見られるように管理します。代替サービスにも、顧客情報や機密資料を確認なく移しません。

その手順を見ながら、AIを使わずに一度だけ作業してみます。担当者が迷った場所、足りない権限、再開までの時間、確認漏れを記録し、手順を直します。普段の効率化と、停止したときの引き継ぎを両方確かめるためです。

AIを使う仕事が増えた今こそ、「今日これが使えなかったら、どう進めるか」を一つずつ確認しておきたいと思います。

追記：設定変更後の確認

私の環境では、10月7日のバージョンアップで急に使用できなくなりました。その後、config.toml の設定を以下に変更した後、Computer UseからChromeへの接続とページ内容の読み取りに成功しました。

[windows]
sandbox = "unelevated"

変更後の確認では、以前の「trusted Node process exited unexpectedly」のエラーは発生していません。

参考情報

• OpenAI公式ステータス：2026年10月7日確認。全体の稼働状況と個別環境の症状は分けて判断します。

関連リンク

• 実施：PCはいずれ壊れる　業務を止めないための予備機とバックアップの準備

転載元：AIが止まっても、仕事を止めないために｜業務改善推進プロジェクト

関連記事

あわせて読みたい記事はこちらです。