「このプロジェクトをローカルチャットで使用できませんでした」――ChatGPT ProjectとLocal Workを切り分けて分かったこと
Windows版ChatGPTで、Project内から始めたLocal WorkがProjectに関連付かない状態を確認しました。Chat、Cloud Work、Project外のLocal Work、新規Projectでも試し、正常な範囲とまだ分からない原因を整理した記録です。
【2026年10月10日追記】
その後も同じエラーが発生していますが、追加検証によって、Workの作成方法や切り替え操作によって結果が異なることが分かってきました。また、CodexやWorkを使った新しいチャットへの引き継ぎについても検証しました。
詳しくは記事末尾の「2026年10月10日追記」に記載しています。
ChatGPTのWindowsデスクトップ版でWorkを使っていると、最近こんなエラーに何度か遭遇するようになりました。
このプロジェクトをローカルチャットで使用できませんでした
2026年9月23日は、特に露骨でした。
複数のProjectで試しても、Local WorkがProjectに入りません。Project外で作ったLocal Workを、後から目的のProjectへ移そうとしても失敗します。
ここ数か月も、Projectの中からWorkを作ろうとして、時々うまくいかなかった記憶はあります。一方で、普通に作れたと思う時もありました。
そのため、これまでは、
何か操作を間違えたかな。
くらいで済ませていました。
今回は何度試しても同じような状態になるため、Project、Chat、Work、Cloud、Localのどこまでが正常で、どこから失敗するのかを切り分けてみました。
この記事は、2026年9月23日時点の公式情報と、私のWindows環境で実際に確認した内容を分けて残したものです。
Projectに「仕事の情報」と「PCのフォルダー」がある
最初に整理し直したのは、Projectとは何かということでした。
私はなんとなく、Projectという一つの箱があり、その中でChatかWorkを選び、WorkならCloudかLocalを選ぶものだと思っていました。
しかし、OpenAI公式のProjects and chatsを読むと、Projects画面には、ChatGPT projectと、PC上のフォルダーへ接続するlocal projectがあると説明されています。
ChatGPT projectは、関連するチャット、アップロードしたファイル、Project固有の指示、接続した情報源などをまとめる場所です。同じProjectの中で、通常のChatとChatGPT Workを使えます。
一方、ChatGPT project自体が、PC上のフォルダーへ直接アクセスできるわけではありません。PC上のファイルを継続的に読み書きする用途では、公式にはlocal projectを使い、必要なフォルダーを接続する方法が案内されています。
つまり、私が頭の中で一つにしていた、
- Projectが持っている共有コンテキスト
- PC上のファイルへ接続するローカルの作業場所
- Workをクラウドで動かすか、PC側で動かすか
は、同じものではありませんでした。
ChatとWork、CloudとLocalも別だった
通常のChatは、相談、文章整理、壁打ちなどに使う会話です。
Workは、複数の資料を調べる、ファイルを比較する、Excelを処理する、成果物を作るといった、ある程度まとまった仕事を任せるときに使っています。
ChatGPT Workの公式案内では、デスクトップ版のWorkで、ローカルかクラウドかを選ぶ考え方が説明されています。
Cloud WorkはOpenAIが管理する環境で動きます。PCを閉じても作業を続けられ、Webやモバイルからも同じ作業を確認しやすい。
Local Workはデスクトップアプリを通じてPC側で動き、許可したローカルファイルやアプリを扱えます。
ただし、Localという名前でも、すべてがPC内だけで完結するという意味ではありません。ChatGPT Workのローカルセキュリティに関する公式説明では、タスクに必要なファイルの抜粋、指示、画面情報、ツールの結果などがOpenAIのサービスへ送られる場合があると説明されています。
以前、PC移行を通じてLocal Workが端末側の作業環境と結び付いていることを知りました。今回は、そこへProjectとの関係が加わりました。
Projectを選び忘れたわけではなかった
実際の操作では、Windowsデスクトップアプリで目的のProjectを開きました。
上部でChatではなくWorkを選び、入力欄の下にも現在のProject名が表示されていました。
画面上では、そのProjectの中でWorkを始める状態になっています。
ところが、メッセージを送った後に、
このプロジェクトをローカルチャットで使用できませんでした
と表示されます。
少なくとも、Projectを開き忘れた、Projectを選ばずにWorkを始めたという単純な操作ミスではありませんでした。
内部でどの処理に失敗したのかは確認できません。ただ、画面上の選択までは正常で、その後、Local WorkとProjectを結び付ける段階で止まっているように見えました。
ここは、見えた動きからの推測です。
別のProjectでも試した
特定のProjectだけに問題がある可能性も考えました。
そこで、別の既存ProjectでもLocal Workを作ってみました。
今度はLocal Work自体が作成されました。しかし、そのWorkはProjectの配下ではなく、Project外の「最近の項目」に表示されました。
そのWorkへ、Project固有の指示やファイルを参照できるか確認すると、現在のタスクはProjectに所属しておらず、Projectの情報も参照できないという回答でした。
AI自身の回答だけを絶対的な証拠にはできません。それでも、
- サイドバーではProject外にある
- Project固有の情報を使えない
- Work自身もProjectに所属していないと回答する
という状態でした。
さらに、Project外で作ったLocal Workを後から目的のProjectへ移そうとしても、同じエラーになりました。
ここまでで、
旧PCから引き継いだProject側に、何か古い情報が残っているのではないか
という可能性も考えました。
私の環境では、PCを新しくした後も、以前から使っていたProjectをそのまま利用しているものが多いからです。
新PCで、新しい空のProjectも作って試した
そこで今度は、既存Projectを使わず、新PCのWindowsデスクトップアプリで新しい空のProjectを一つ作成しました。
ファイルも入れず、特別な設定もしていないテスト用のProjectです。
Projectの作成画面は正常に開き、新しいProject名も表示されました。そのProjectの中でWorkを選び、Local Workを開始しました。
ここで少し興味深い結果になりました。
Local Workそのものは正常に起動しました。
作成されたWorkを確認すると、
Work
お使いのコンピューターで実行
と表示されており、Local Workとして動いています。
ところが、そのWorkは作成したばかりのProjectの配下には残りませんでした。再び、Project外の「最近の項目」に単独のWorkとして表示されました。
今回確認できた流れは、次のとおりです。
- 新しい空のProjectを作成Project画面は正常に開く
- その中でLocal Workを開始Local Work自体は正常に動く
- 作成後の表示を確認Projectには所属せず、「最近の項目」に単独で残る
この結果から、少なくとも、
旧PCから引き継いだ既存Projectだけの問題
とは考えにくくなりました。
また、Local Workそのものが動かないわけでもありません。Local WorkはProject外なら正常に起動しています。
今回うまくいっていないのは、ProjectとLocal Workの間の関連付け、あるいはその境界部分に見えます。
ただし、内部で何が起きているのかまでは確認できないため、原因は断定しません。
Cloud Workなら同じProject内に正常に作れた
さらに同じProjectをWebブラウザーで開き、Cloud Workを作ってみました。
こちらは正常です。
作成したWorkはProjectの中に入り、Windowsデスクトップアプリから見ても、雲の印が付いたWorkとしてProject内に表示されます。
今回実際に確認できた状態は、次のとおりです。
- 通常のChatProject内で正常に使える
- Cloud WorkProject内に正常に作成できる
- Local WorkWork自体は動く場合があるが、Projectとの関連付けに失敗する
- 後からProjectへ移動同じエラーになり、移動できない
Projectそのものや、旧PCからの移行だけが原因とは考えにくかった
ここまで試した結果、少なくとも次のことは確認できました。
通常のChatはProject内で使えます。
Cloud WorkもProject内に正常に作成できます。
Project外であればLocal Work自体も正常に動きます。
そして、旧PC時代から使っているProjectだけではなく、新PCで新しく作成した空のProjectでも、Local WorkがProject配下に残らない状態を確認しました。
そのため、
Projectそのものが壊れている
旧PCからProjectを引き継いだことだけが原因である
Local Workそのものが動かない
という三つは、今回の結果とは少し合いません。
現時点で一番しっくりくるのは、
ChatGPT projectとLocal Workの間をつなぐ部分で、何かがうまくいっていない
という見方です。
ただし、ここからすぐに、Windows版ChatGPTの不具合だと断定することも避けたいと思います。
現行の公式説明では、ChatGPT projectと、PC上のフォルダーへ接続するlocal projectは別のものとして説明されています。また、WorkにもCloudとLocalがあります。
つまり、
ChatGPT project / local project
というProject側の区分と、
Cloud Work / Local Work
というWork側の区分があり、私自身も最初はこの二つを混同していました。
今回の挙動が、
- 現在の仕様上の境界なのか
- Windowsデスクトップ版の不具合なのか
- 機能更新途中の一時的な挙動なのか
- 別の条件によるものなのか
そこまでは、現時点では判断できません。
同じ英語のエラーについて、Windows版の公開Issueも複数見つかりました。ただ、同じメッセージが出ていても、すべてが同じ原因とは限りません。
OpenAIの公式資料を確認した範囲でも、このエラーに対する確定した修復手順は見つけられませんでした。
記事作成時にデスクトップアプリの「ChatGPTについて」で確認した表示は、バージョン26.917.62051、リリース日2026年9月23日でした。その状態でも、私の環境では再現しました。
本当に使いたかったのは、Projectの情報とローカルファイルの両方だった
Cloud Workが使えるなら、それでよい仕事もあります。
Projectへ残してきた経緯や指示を使い、Web上の情報やアップロードした資料をもとに作業するなら、Cloud Workで進められます。
一方、Windowsデスクトップ版を使う大きな理由は、PCや社内ストレージ上にある実際の業務ファイルを扱ってもらうことです。
本当に使いたかったのは、
Projectに残した経緯や指示
＋
PC上の実データ
でした。
この二つを自然につなげられないことが、今回一番困ったところです。
私自身、ChatGPTを使い始めて1年弱になりますが、ここまで実務の流れそのものに影響する不安定さを強く意識したことは、あまりありませんでした。
もっとも、以前はブラウザー版を中心に使っていて、Local Workをここまで実務へ組み込んでいなかったという違いもあります。
今回もChatGPT全体が使えないわけではありません。通常のChatも使えますし、Cloud Workも動いています。Local Work単独でも動きます。
それでも、Projectに蓄積した経緯や指示と、PC上の実際の業務データを一緒に使いたい立場からすると、この境界がうまく動かない影響はかなり大きいと感じています。
公式案内には、local projectにPC上のフォルダーを接続し、ローカルファイルを扱う方法も示されています。ただ、今回は正常に使えている既存Projectを大きく変更することはせず、どこまで動くかの確認に留めました。
今はProjectを壊さず、用途を分けて使う
現時点で、私には恒久的な直し方は分かりません。
そのため当面は、用途で分けることにしました。
Projectの経緯や指示を重視し、PC上のファイルを直接扱う必要がない仕事はCloud Workを使う。
PCや社内ストレージ上のファイルを直接扱う必要がある仕事は、Project外のLocal Workを使い、必要な前提を別途渡す。
今回、新しく作った空のProjectでも同じ状態を確認したため、既存Projectを作り直せば解決するとも考えていません。少なくとも現時点では、正常に使えているProjectを削除したり再構築したりするより、この境界の挙動が変わるのを待つ方が安全だと判断しています。
正直、実務ではかなり不便です。
今回は、無理に直すところまでは進めません。
エラーが出たことで、これまで一つに見えていたProject、Chat、Work、Cloud、Localが、実際には別の役割と境界を持っていることが分かりました。
この記事は、「こうすれば直る」という解決記事ではありません。
2026年9月23日に、Windowsデスクトップ版ChatGPTで同じエラーを何度も確認し、どこまでは正常で、どこからうまくいかなかったのかを切り分けた記録です。
ChatGPTは更新が速いため、公開直後に挙動が変わる可能性もあります。症状や公式情報が変われば、その時点でまた追記したいと思います。
2026年9月24日追記
Windows版ChatGPTデスクトップアプリがバージョン26.917.71314へ更新された後、同じ環境で再度確認したところ、Project内から新しいWorkを作成できる状態になりました。前日に確認したバージョン26.917.62051では再現していた症状です。
ただし、公式リリースノートでは本件の修正内容を確認できていないため、今回の更新によって修正されたのか、別の提供条件の変化によるものかまでは断定していません。
2026年9月28日追記
9月24日に一度使えるようになりましたが、後日、同じエラーが再発しました。
今回はProject外のLocal WorkでChatGPT WorkにPCの設定を調べてもらいました。変更前のバックアップと影響範囲を確認し、私が承認した後に設定を修正。アプリを再起動すると、既存Project内に新しいLocal Workを作成できました。
Windowsでは、Projectの作業用フォルダーの更新が、裏方のプログラムによるファイルの使用とぶつかる事例が公開Issueで報告されています。今回も似た現象だった可能性がありますが、私のPCで原因となったプログラムまでは特定していません。
これは私の環境で復旧できた記録です。同じエラーでも原因や適切な変更は異なり、設定変更がほかのProjectに影響する場合もあります。そのため、この記事では共通の修復コマンドとして紹介しません。
2026年10月10日追記：エラーは今も出る。ただし、発生する操作に違いが見えてきた
9月28日に一度復旧できたと書きましたが、その後も同じエラーに遭遇しています。
このプロジェクトをローカルチャットで使用できませんでした
ただ、以前とは少し見方が変わってきました。
Local Workそのものが使えないわけではありません。以前からProject内で使っているWorkは現在も動いていますし、新しいWorkを作成できる場合もあります。
それなのに、ある操作をするとエラーになる。今回は、その違いをもう少し確認してみました。
Project内で直接作る場合と、Chatから切り替える場合を比べた
10月10日、いつものようにChatGPTのWindowsデスクトップアプリを使い、Project内から新しいWorkを直接作成してみました。
今回は正常に動きました。新しいWorkがProject内に作成され、作業も開始できています。以前から作成していたProject内のWorkも、引き続き利用できています。
一方、同じProject内でも、通常のChatから「ChatGPT Workで続ける」を選択すると、例のエラーが発生する場合があります。
そこで、Projectに所属していない通常のChatから、同じ切り替え操作を試してみました。すると、こちらは正常にWorkへ切り替えられました。
今回の確認結果を整理すると、次のようになります。
| 操作 | 10月10日の確認結果 |
|---|---|
| Project内の既存Workを利用する | 利用できる |
| Project内で直接、新規Workを作成する | 今回は成功 |
| Project内の通常ChatからWorkへ切り替える | エラー発生例あり。ただし成功する場合もある |
| Project外の通常ChatからWorkへ切り替える | 今回は成功 |
少なくとも私の環境では、Project内のLocal Workが全面的に使えなくなっているわけではありません。 また、Project内のChatからWorkへの切り替えも、常に失敗するわけではありません。
この結果から、Workの作成や実行機能そのものよりも、既存の通常ChatからWorkへ切り替える処理に、何らかの不安定さがあるのではないかと感じています。
切り替える際には、元のチャットやProjectとの関連情報を新しい作業環境へ渡す必要があるのかもしれません。ただし、これは画面上の動きから考えた仮説です。内部で何が起きているのか、原因がどこにあるのかは、今回も分かっていません。
「Workで続ける」の選択画面にも変化があった
もう一つ気になったのが、Workへの切り替え案内の表示方法です。
以前は、通常のChatで少し複雑な仕事を依頼すると、途中で次の選択肢が表示されることがありました。
- Chatに留まる
- Workで続ける
Chatに留まる側にはカウントダウンが表示され、Workに任せたい場合は、黒い「Workで続ける」ボタンを押す仕組みでした。
ところが最近、私が使っているデスクトップアプリでは、この選択画面が一瞬表示された後、「思考中」や「これまでのアクティビティ」のような一行に折りたたまれることがあります。
最初は、Workへの切り替え案内そのものが出なくなったのかと思いました。しかし、その表示を展開すると、従来の選択画面が残っていました。そこから「Workで続ける」を押すこともできます。
何も操作しなければ、カウントダウン後にChat側で処理が継続されるように見えます。ただし、正確なタイムアウトの動作までは確認できていません。
この表示の変化が今回のエラーと関係しているのかどうかも不明です。それでも、切り替え案内が見当たらないときには、折りたたまれたアクティビティ表示の中に残っていることがあると分かりました。
別の作業で、Codexが新しいチャットを作ってくれた
同じ日、別件でSCS評価制度の★3取得に向けた準備を、Codexで整理していました。SCS評価制度は、取引先を含むサプライチェーンのセキュリティ対策状況を可視化する制度です。
今回使っていたCodexは、許可したPC上のファイルを扱いながら作業できるAI環境です。ローカルでの作業については、OpenAIの公式案内にも説明があります。
何度もやり取りを重ねているうちに、会話のコンテキスト、つまりAIがその会話で参照する情報が長くなってきました。
私はこれまで、こういうときにはAIに引き継ぎ事項を整理してもらい、人間が新しいチャットを開いて、その文章を貼り付ける方法を取っていました。
今回も同じように引っ越しを考えていたのですが、ふと疑問が浮かびました。
新しいチャットを開いて、引き継ぎ内容まで入力する作業を、AI自身ができないのだろうか。
Codexに聞いてみると、できるという回答でした。そこで、実際に依頼してみました。
すると、引き継ぎ用のテキストファイルを保存し、新しい独立したチャットを作成。その最初のメッセージに、引き継ぎ事項や作業ファイルの保存場所などを入力してくれました。
新しいチャット側でも、既存のファイルを確認し、作業の続きを引き受けたという応答がありました。
これは少し驚きました。これまで人間が行っていた、チャットを開いて文章を貼り付ける作業が不要になったからです。
Workから新しいWorkモードのチャットへの自動引っ越しも成功した
そこで今度は、Work経由で同じことができるか試してみました。
Project外の通常ChatからWorkへ切り替え、新しい独立したチャットを作成し、引き継ぎメッセージを入力するように依頼しました。
最初は切り替えが承認されず、失敗しました。しかし、再試行では成功しました。
新しい独立したチャットが作られ、指定した引き継ぎメッセージも最初から入力されていました。新しいチャットの入力欄には「Workモードで作成」と表示されていました。
特に驚いたのは、引き継ぎメッセージの上部に、次の表示があったことです。
ChatGPTが別のタスクから送信
私が新しいチャットを開いて、文章を貼り付けたわけではありません。元のWorkからメッセージが送られ、新しいチャット側でも、引き継ぎを受け取ったという応答が返ってきました。
ここまで確認できたので、利用者から見たWorkモードのチャット同士の自動引っ越しは、今回の環境で成功したと考えています。新しいチャットの作成から、引き継ぎ内容の自動投入、それに対する応答まで確認できました。
内部的なチャットの分類やWorkとCodexの関係、この操作がいつから利用できたのかについては確認していません。ただ、それは画面上で確認できた今回の成功とは分けて考えています。
そもそも、会話のすべてを引き継ぐ必要があるのか
ここからは、今回のエラーとは少し違う話になります。
私はこれまで、ChatGPTのProjectに資料や指示を登録し、長期的な仕事の経緯を共有する使い方をしてきました。Projectに情報を集めておけば、新しいチャットでも同じ前提を参照しやすくなるからです。
しかし、Local WorkやCodexのように、許可したPC上の作業フォルダーを直接扱える環境では、少し違う考え方もできそうです。
例えば、仕事の途中経過や決定事項、未完了の作業、次に確認すべきことを、あらかじめ作業フォルダー内のファイルに保存しておく。そして、チャットが長くなったら新しいチャットを作り、そのファイルを読み込んで作業を再開する。
これなら、会話の内容をすべて新しいチャットへ渡す必要はありません。長いやり取りの中から重要な情報を毎回まとめ直すよりも、作業の進捗に合わせて引き継ぎファイルを更新しておく方が、確実な場合もあると思います。
仮に新しいチャットの自動作成ができなくても、人間が新しいWorkを開き、保存済みの引き継ぎファイルを参照するよう指示すれば、同じ考え方で作業を再開できます。
もちろん、引き継ぎファイルだけですべてが保証されるわけではありません。ファイルの内容が古ければ、古い情報を引き継ぐことになります。元の案件資料や成果物、判断の根拠なども、必要に応じて確認し直さなければなりません。
通常のChatではローカルファイルを直接扱えない環境もあるため、これまでどおり引き継ぎ文を作成し、新しいチャットへ貼り付ける運用が必要になると思います。
それでも、Local Workでは「会話を引き継ぐ」という発想から、保存された作業状態を、新しいAIに読み直してもらうという発想へ、少し変わっていくのかもしれません。
これは、今回の実験で個人的に感じたことです。OpenAIがProjectを不要にしようとしている、という意味ではありません。
OpenAI公式のProjectの説明でも、関連する会話、資料、共通の指示をまとめる役割が案内されています。私も、その利点は引き続きあると思っています。ただ、ローカルファイルを中心とする仕事では、Projectの情報だけに依存しない運用にも可能性があると感じました。
現時点では、エラーの原因はまだ分からない
10月10日時点でも、冒頭のエラーは発生しています。一方で、Project内で新しいWorkを直接作成できる場合があり、既存のWorkも利用できています。
今回のように操作方法を少し変えて比較してみると、何が動いていて、何がうまくいっていないのかが、以前よりも見えてきました。ただし、誰にでも当てはまる修復方法は、まだ分かりません。
同じエラーに遭遇している方にとって、Workの直接作成と通常Chatからの切り替えを分けて確認することが、一つの参考になればと思います。
そして、エラーへの対処とは別に、作業の経緯や引き継ぎ事項をファイルとして残すことも、これからのAI活用では重要になってくるのではないかと感じています。
今回も、解決方法を断定する記事ではなく、私のWindows環境で実際に試し、確認できたことを残す記録です。