AIの不具合から考えた、業務を止めないための備え――会話はできても実務が止まる。更新の順番と再開資料を見直す
Windows版ChatGPTの更新後、会話はできてもPC上の処理が止まりました。社員の更新保留と代替経路で業務を続けた経過に、10月10日朝の更新・再起動後、dot経由のWorkでフォルダ参照が通った確認範囲を追記します。
ここ数日、AIアシスタントのDotには、たくさんの仕事を任せていました。ChatGPT Dotsは、接続したPCやアプリも使って仕事を進めるAIアシスタントの機能です。PC上の資料を扱い、依頼した作業を進めてもらう。そうした使い方ができていたのに、今日は、私が期待していたDotとしての機能がほぼ使えない状態になりました。
会話は続いていても、任せたかった実務が進まない。 この落差は大きいと感じました。
2026年10月7日、Windows版ChatGPTを更新した後、PC上のファイルを扱うWorkの処理が動かなくなりました。ChatGPT Workは、資料の分析や成果物の作成など、まとまった仕事をAIへ依頼する機能です。翌朝に社員へ更新を保留するよう伝え、未更新の環境を確認してもらったことで、仕事を続けられる選択肢が残りました。
原因はまだ断定できませんが、同じような症状で困っている方が、状況を比べる材料になればと思い、エラーの内容と試したことを残します。あわせて考えたのが、職場全体を止めないための備えです。BCP、つまり業務継続の考え方を、日常のAI利用にも当てはめる必要を感じました。
当初の本文は、2026年10月8日14時30分時点の状況を記録しています。その記録を残したまま、末尾に10月10日朝の更新と参照テストの結果を追記しました。確認できたのは、処理の開始とフォルダ参照までです。
会話はできるのにファイルを扱えない
更新後のアプリのバージョンは26.1002.52244でした。画面は開き、AIとの会話もできます。PCへの接続も表示されていました。しかし、実際にファイルを読ませようとすると、「setup refresh had errors」というエラーが出て止まります。
調べていくと、資料の内容を読み間違えたという段階ではなく、コマンドを実行するための準備で失敗していました。こちらから見ると「AIと話せている」「PCにつながっている」「ファイルを処理できる」は続いた動作に見えますが、途中まで動いていても、最後の処理が動くとは限らないようです。
まずアプリを再起動し、PCも再起動しましたが、改善しません。新しい会話や新しいWorkを作って試しても、同じように失敗しました。ところが、以前から使っていた技術ノートのWorkでは、一度、PC名を確認するコマンドと、同じ資料の読み取りが通りました。
それなら以前の作業を使えばよいのかと思ったのですが、その後はこちらも失敗しました。新しく作った作業だけの問題だとか、会話側とPC側の違いだとか、途中で立てた単純な説明では合わなくなりました。一度動いたことを、復旧したこととして扱うのは早すぎたのです。
ログで絞れた範囲と、まだ分からないこと
AIがPC上のログを直接読めなかったため、私がログを開き、直近3日分を会話に添付して調べました。私が確認したログの範囲では、10月7日22時24分54秒に処理が成功し、22時26分14秒には最初の致命的なエラーが出ていました。時刻はいずれも日本時間です。
この間に、実行環境の補助プログラムやパッケージの版が切り替わっていました。問題の出始めた時刻を絞れたことは手がかりになります。ただ、時刻が近いというだけで、その変更が唯一の原因だったとまでは言えません。
ログに残っていたのは、VCRUNTIME140_1.dllというDLLファイルに対する「os error 32」でした。DLLは、プログラムが共通の機能を使うための部品ファイルです。その後のログでは、node_repl.exeという補助プログラムに対する準備処理でも、同じエラー32が出ていました。
MicrosoftのWindowsエラー定義では、エラー32は、別のプロセスがファイルを使用しているためアクセスできない「共有違反」です。アクセス拒否を表すエラー5とは種類が違います。
似た「setup refresh」のエラーを扱った非公式記事には、ファイルの所有権を変更する対処が載っていました。しかし、今回のログをそれと同じ問題と見なす根拠はありませんでした。その方法をそのまま適用したり、保護機能を無効にしたりすることは見送りました。原因が分からないところへ変更を重ねると、何が効いたのか、何を戻せばよいのかも分かりにくくなります。
OpenAIの公開リポジトリには、同じ26.1002.52244で、ローカルファイルへのアクセスやコマンド実行に失敗するIssue #51778もありました。Issueは、不具合などを報告・議論する記録です。「helper_unknown_error: setup refresh had errors」とエラー32が報告されています。自分のPCだけの問題とは決めつけられない手がかりですが、これは利用者の報告であり、根本原因についての公式発表ではありません。
当初は次の更新を待つしかないと見ていましたが、調べ直すと、OpenAIの公開リポジトリに関連しそうな修正がありました。PR #51822は、Windowsの実行環境のアクセス権を修復する際、使用中のEXEやDLLを開く方法によって共有違反が起きる問題への修正です。PRは、コードの変更案と、その確認・取り込みを記録する仕組みです。必要な権限に絞ってファイルを開くように変更されており、今回のログと整合する内容でした。
この修正が取り込み済みであることは確認できました。ただし、公開コードに修正が入ること、その修正を含むアプリが配信されること、手元で正常に動くことは、それぞれ確認が必要です。10月8日14時30分の時点では、私のPCでの復旧は確認できていません。関連する修正を見つけたことをもって、解決済みとはしていません。
社員の更新をいったん止めた
翌朝、社員が来たところで、まずChatGPTをアップデートしないよう伝えました。そのうえで、未更新のPCから資料を読み取れるか確認してもらいました。結果は、問題なく読み取れるというものでした。
私の環境では失敗し、未更新の社員の環境では動く。この違いは重要でした。ただ、アプリの版以外にもPCごとの条件はあります。これだけで更新が原因と確定できるわけではありません。それでも、現に動いている環境まで、同じタイミングで変更する必要はないと判断しました。
もし皆が更新して、同じように使えなくなっていたら、対応の選択肢は減っていたと思います。社員に保留を伝えたことで、正常に動く環境を残せました。必要な作業を続けるためにも、不具合のある環境と比較するためにも、その状態を残しておく意味がありました。
この時点で全社の更新管理を整備できていたわけではありません。その朝に状況を共有し、いったん更新を待ってもらったという対応です。それでも、自分のPCの不具合を直すことだけに集中せず、まだ影響を受けていない人の環境を見る必要があると気づきました。
全員が同時に止まらないようにする
今回の経験から、今後の更新は、まず自分の環境など限られた範囲で確かめ、その結果を見ながら広げる形にしたいと考えています。全員が同じ日に更新して同じ不具合を受ける状態は、できるだけ避けたいところです。
確認する内容も、アプリが起動した、会話ができた、というところで終わらせないほうがよさそうです。今回の仕事で使う資料を読めるか。必要な処理が進むか。成果物を保存し、開き直せるか。普段の仕事を一通り動かしてみて、更新を広げる判断につなげたいと思います。
新しい機能を試す環境と、その日に必要な仕事を進める環境を、すべて同時に変えない。小さな職場でも、更新の順番を考えたり、確認が済むまで一部を残したりする余地はあります。今あるPCの使い方を少し変えることから始められる備えだと感じました。
もちろん、未更新ならいつまでも安心ということではありません。保留した更新をいつ進めるか、何を確認できれば進めてよいかまで考える必要があります。今回なら、同じ資料で読み取りを試し、一度成功しただけでなく、その後も仕事に使えるかを確認することが、ひとつの判断材料になります。
まだ固定した社内ルールとして完成しているわけではありません。私が先に試す範囲、社員へ伝えるタイミング、保留を解除する条件を、今回の経験から整理していきたいと思っています。
復旧の調査と、日々の仕事を分けて進める
不具合を調べる間も、その日の仕事は残っています。今回は、PCから直接読ませていたExcelやPDFを私が会話へ添付し直し、クラウド側で読み取ることで、実務の一部を進めました。ただ、そのために私がファイルを運び、画面を撮り、別のWorkへの指示を中継しています。任せていた作業を進めるための手間が、人の側へ戻ってきました。
別の経路が使えたから、従来どおり仕事が回ったとは言えません。手作業でつなぐ時間もかかり、その間は自分のほかの仕事を止めることになります。代替手段を考えるときには、使えるかどうかに加えて、誰がどれだけ手を動かせば続けられるのかも見ておく必要があります。
この切り替えができるかどうかは、元の資料を自分たちで持ち、何を進めていたのか把握しているかに関わります。AIの画面の中だけに途中の判断が残っていると、別の環境で再開するたびに説明し直すことになります。私も今回、必要な資料を選び、渡し直す作業をしました。
どれが原本で、どこまでが作業中のファイルなのか。どの条件は確認済みで、どこは仮置きなのか。次に何をすれば再開できるのか。そうした情報を資料と一緒に残しておけば、別のAI環境へ移る場合にも、人が引き取る場合にも役に立ちます。
また、動いているPCを残していても、その人にしか分からない場所に資料があり、作業の経過を説明できなければ、すぐには引き継げません。環境を残すことと、仕事を渡せる状態にすることを、合わせて考える必要があります。今回の対応で十分だったとは思いませんが、次に備えるときの課題は見えてきました。
使い続けるための備えを残す
私は、AIの仕組みや不具合の原因をすべて理解してから使おうとは考えていません。変化が速いので、自分で試しながら、実務に使えるところを取り入れていくことになります。ただ、仕事を任せる範囲が広がるほど、止まったときの影響も自分たちで考えておく必要があります。
今回、社員へ更新の保留を伝え、未更新の環境が動くことは確認できました。一方、私の作業は、人が資料を渡し直し、指示を中継して、ようやく一部を進めた状態です。根本原因の解明も、任せていたPC作業の復旧も、まだ残っています。
原因が確定するまで何も決められないわけではありませんでした。いま動いている環境を守ること、同じ変更を一斉に広げないこと、別の経路で仕事を再開できる資料を持つことは、その時点の情報でも判断できました。
この経過を残すのも、次に同じことが起きたとき、また一から迷わないためです。どの版で何が起き、何を試し、なぜ更新を保留したのか。うまくいったことだけでなく、途中で違うと分かった見方も含めて、自分たちの技術資産にしておきたいと思います。
10月10日追記：更新と再起動の後、Workからフォルダを参照できた
10月10日の朝、止まっていたWorkの処理開始と、PC上の業務フォルダの参照が通りました。原因を解明できたわけではありません。どの操作の後に何を確認できたかを、ここまでの記録に加えて残します。以下の時刻はすべて日本時間で、おおよその時刻です。
この間も、会話そのものはできていました。一部の既存Workでは技術ノートの更新などもでき、すべてのWorkが一律に止まっていたわけではありません。一方、主に使う新しいPCでは、dotから動かすWorkや新規Workで「helper_unknown_error: setup refresh had errors」が続き、アプリやPCを再起動しても改善していませんでした。
古いPCには更新が届き、新しいPCでは旧版が「最新」だった
6時56分頃、以前使っていたPCを試すことにしました。デスクトップアプリが残っているはずなので、更新前の環境なら使えるかもしれないと思ったのです。この時点では、まだ旧PCを起動していませんでした。
6時58分頃には公式情報も確認しました。関連する修正PRは取り込み済みでしたが、私が確認した情報からは、Windowsデスクトップ版への修正版配布を裏づけられませんでした。ただし、配布の告知を見つけられなかったのであって、修正版が存在しないと確認したわけではありません。
8時2分頃に旧PCを起動すると、バージョン表示は26.1002.52244、リリース日は10月7日でした。想定していた未更新の旧版ではなく、新PCで障害が出ていた版と同じです。ところが旧PCでは更新のダウンロードが始まり、その後「アップデートが利用可能です」と表示されました。新PCでは、そのような動きが見えていませんでした。
8時5分頃、旧PCの更新が終わりました。更新後は26.1007.21434、リリース日は10月9日と表示され、番号は後で画面でも確認しました。
新規Workには、デスクトップのファイル名一覧だけを確認し、ファイルは変更しないよう頼みました。結果として一覧が返ってきました。ただし、旧PCでは更新前に同じテストをしていません。更新の後に使えたことは確認できても、更新によって直ったとは、この比較だけでは断定できません。
一方、8時11〜14分頃に新PCで「更新を確認」を実行すると、「ChatGPT is up to date.」と表示されました。バージョンは26.1002.52244、リリース日は10月7日のままです。ウィンドウを閉じるだけでなく、通知領域のアイコンからExitで完全終了し、起動し直しても同じでした。
旧PCには新版が届き、新PCでは旧版が「最新」と表示される。 この違いは確認できましたが、なぜそうなったかは分かりません。
公式の配布経路で更新すると、今度は起動時のエラーが出た
8時15〜18分頃には、公式のアプリ更新管理の説明を参考に、設定の「一般」からアプリ内更新の項目を探しました。設定検索では「アプリ内更新」が見つかりましたが、選択しても右側に該当する設定が表示されず、更新の管理状態を確認できませんでした。
ここから、組織の設定で更新が止められているとは判断していません。権限やセキュリティ設定も変更しませんでした。
8時19分頃、新PCで公式Windows配布案内に記載されたインストーラーを利用しました。既存アプリのアンインストールはしていません。Microsoft Storeの画面にOpenAIのChatGPTが表示され、ダウンロードが進みました。
ところが8時21分頃、ダウンロードが終わって画面が閉じた後、今度はアプリ自体が起動できなくなりました。「ChatGPT failed to start」「code=1, signal=null」に続き、「failed to initialize sqlite state runtime」というエラーが表示されました。SQLiteは、アプリ内の状態などを保存するデータベースの仕組みです。
それまでの「setup refresh」とは違う表示でした。この情報だけでは、データベースが壊れたのか、別のプロセスとの競合なのか、それ以外なのかを判断できません。原因が分からないまま、アプリのデータや設定を削除・初期化したり、アクセス権を変更したりすることは見送りました。
Windows再起動後、dot経由で63件のファイル名を取得できた
8時24分頃、ほかの作業を保存して、新PCのWindows自体を再起動しました。その後、インストーラーを再実行せずにChatGPTを開くと、今度は起動できました。バージョンは26.1007.21434、リリース日は10月9日になっていることを画面で確認しました。
再起動後にはSQLiteの起動エラーは出ませんでした。ただし、その原因を特定できたわけではありません。
8時26〜27分頃、dotから、以前エラーで止まっていた既存Workを動かしました。実行先が新PCであることを確認し、業務フォルダ直下のファイル一覧を取得するテストを行いました。
結果は63件、終了コードは0でした。処理が正常終了したことを示す結果で、以前の「setup refresh had errors」は出ませんでした。
最初は日本語ファイル名が文字化けしましたが、その処理の中だけ出力をUTF-8という文字の符号化方式にすると、日本語名も正しく取得できました。PCの永続的な設定や、業務ファイルは変更していません。
今回通ったのは、処理の開始とフォルダ参照まで
今回確認できた範囲は、次の四つです。
- 新PCで新版アプリを起動できたこと
- dotからWorkの処理を開始できたこと
- PC上の業務フォルダのファイル一覧を取得できたこと
- 日本語ファイル名も正しく取得できたこと
この時点では、ファイル本文の読取り、編集、保存までの一連の動作は、まだ試していません。止まっていた実行開始とフォルダ参照が通ったという復旧確認であり、すべて完全に復旧したという意味ではありません。
関連するPRが今回の障害を直接直したか、2台で更新の届き方が違った理由は何か、SQLiteの起動エラーはなぜ出たか。これらも、まだ分かっていません。
リリース表示の10月9日と、私が更新できた10月10日朝の差についても、時差や段階配信が理由だと説明する根拠はありません。リリースの表示日と、各PCで更新が提示・適用される日は、分けて記録します。前日までに配布告知を見つけられなかったことも、その時点では配布されていなかった証拠にはなりません。
「最新です」ではなく、実際に使う経路で確かめる
今回、バージョン番号や「最新です」という表示だけでは、使える状態か判断できませんでした。端末ごとに更新状況が違い、最後は、実際の仕事で使うdotからWork、PCへの経路を通して、変更を伴わない小さな参照テストで確認しました。
10月8日に考えた備えは、復旧を確認する段階でも意味がありました。動いている社員の環境を一斉に更新しない。別PCや添付資料を使う経路を残す。別のエラーが出ても、すぐに設定やデータを削除しない。そして、復旧も「何ができたか」の範囲で残す。
次に確かめるのは、実際の資料の本文を読めるか、必要な処理を進め、成果物を保存して開き直せるかです。一度通っただけで更新保留をすべて解除するのではなく、普段の仕事を続けられるかまで確認する材料にしていきたいと思います。