ChatGPTの会話を読み込めない。再試行で消耗しないための復旧手順

「このChatGPTの会話を読み込めませんでした」と表示され、再試行を押しても戻れない。長い仕事をChatGPTへ任せていると、この画面は単なる表示エラーでは済みません。

困るのは会話本文そのものより、何を決めたか、どこまで終わったか、外部で動かした処理が成功したか、次に何をしてよいかが一緒に見えなくなることです。

ただし、この画面だけから原因やデータ消失を断定することもできません。そこでNetsujoでは、問題を二つに分けます。

1. 画面を復旧する — ChatGPTの会話へ再びアクセスできるか切り分ける
2. 仕事を復旧する — 元の会話が読めなくても、現物と状態記録から安全に続ける

後者まで設計しておけば、「再試行」が通るまで仕事全体を止める必要はありません。

まず5分だけ、画面側を切り分ける

OpenAIの公式トラブルシューティングでは、ページの再読み込み、新しい会話での確認、サービス状況の確認、キャッシュやCookie、シークレット／プライベートウィンドウ、拡張機能、VPN・プロキシ、別ブラウザーや別ネットワークなどを切り分け候補として挙げています。

ここで重要なのは、表示の再試行と、仕事そのものの再実行を混ぜないことです。

Netsujoでは、最初の切り分けを次の順で行います。

「5分」はOpenAIの保証時間ではなく、同じ再試行に時間を溶かさないための運用上の上限です。

組織のVPNやセキュリティ設定は、許可なく無効化しません。複数環境でも再現する場合は、OpenAIが案内するHARやブラウザーコンソール、会話URL/IDなどを揃えてサポートへ渡します。

公式の現在の案内は、Troubleshooting ChatGPT Error Messagesで確認できます。

サイドバーから消えたことと、削除されたことも分ける

対象会話が一覧に見当たらない場合、すぐに「消えた」と判断しません。

OpenAIのチャット履歴の検索方法では、サイドバー検索から過去の会話を検索でき、アーカイブ済み会話も検索対象になると説明されています。また、古い会話がサイドバーの高速表示対象から外れていても、検索やオープンで取得できる場合があります。

したがって、

一覧にない
≠
削除された
≠
会話URLを開けない

として扱います。

この三つを混ぜると、必要のない再構築を始めたり、逆に本当にアクセスできない問題の切り分けが遅れます。

会話を読めないことと、外の仕事が失敗したことは別

AIに文章案だけを出させていたなら、主に失うのは文脈です。

しかしGitHub、デプロイ、メール送信、外部API、バッチ処理などを動かしていた場合は危険度が上がります。ChatGPTの会話を読み込めないことは、外部処理が実行されなかった証拠ではありません。

たとえば、公開処理を依頼した直後に会話が開けなくなったとします。

このとき新しい会話で「さっきの公開をもう一度やって」と送るのは危険です。最初の処理が成功していて、返答だけ読めない可能性があるからです。

Netsujoでは状態を最低でも次のように分けます。

結果不明を「たぶん失敗」と読み替えないことが要点です。

停止操作についても同じです。Netsujoでは別記事「Stopを押しても、仕事は止まらない」で、会話の停止と外部processの停止を分けています。会話UIが壊れたときも、外側の状態は外側で取り直します。

会話全文ではなく、「再開に必要な状態」を別に持つ

根本対策は、会話を絶対に壊れないようにすることではありません。

会話が読めなくても再開できるよう、仕事の現在地を会話の外へ出します。

最低限、次を保持します。

WORK_ITEM_ID:
OBJECTIVE / DONE:
ARTIFACT:
DECISIONS:
COMPLETED + EVIDENCE:
RUNNING:
OUTCOME_UNKNOWN:
NEXT_ACTION:
AUTHORIZED / PROHIBITED:
UPDATED_AT:

重要なのは、単なる要約ではないことです。

「かなり進んだ」「CIは通った」では復旧できません。どの成果物か、どの版か、何を根拠に完了としたか、結果不明が残っていないかまで必要です。

開発ならrepository、PR、branch、HEAD SHA、CI runを加えます。記事制作なら原稿の保存先、採用した主張、捨てた案、参照した一次情報を残します。

Netsujoでは、作業の同一性をチャット名ではなくWORK_ITEM_IDで持つ設計へ移しています。詳しくは「同じ案件なのに、チャット名が違う。問題は名前ではなく識別子だった」にまとめています。

新しい会話では、いきなり「続き」を実行させない

元の会話が読めないとき、新しい会話へ「引き継いで進めて」とだけ書くと、AIは不足した状態を会話文脈から補おうとします。

最初の指示は、実行ではなくreadbackにします。

この作業を、下記の状態記録と成果物から引き継いでください。

WORK_ITEM_ID: [ID]
STATE: [状態記録の保存先]
ARTIFACT: [成果物の保存先]

まず読み取りだけで、
- 目的と完了条件
- 成果物の最新版
- 完了済みとそのEvidence
- 実行中
- 結果不明
- 承認済みの範囲
を確認してください。

記録と現物が違う場合は、現物との差を明示してください。
結果不明を失敗・未実行とみなして再実行しないでください。
アクセスできない参照先を、読んだ前提で進めないでください。

確認後、重複実行を避けた次の一手を報告してください。

ここでの目的は「前の会話を再現する」ことではありません。

現在の現物から、これから安全に何をできるかを再構築することです。

Memoryは便利だが、タスク台帳にはしない

ChatGPTのMemoryは、好みや過去の文脈を引き継ぐ用途には有効です。一方、OpenAIのMemory FAQでも、過去の会話のすべての詳細を保持する仕組みではないと説明されています。

したがって、

• 文体や継続的な好み → Memoryで補助
• 採用した仕様 → 正本ファイル
• 実行済み処理 → 実行先の記録
• 承認 → 承認記録
• 最新版 → Gitや成果物ストア

と役割を分けます。

「AIが覚えているはず」は、公開、送信、上書き、デプロイの根拠にしません。

復旧設計の合格条件は、「元の会話を見ずに続けられる」こと

テンプレートを作っただけでは不十分です。

安全な小さな作業で、元の会話を見ずに新しい会話へ移し、状態記録と成果物だけを渡します。そして次を確認します。

• 目的と完了条件を復元できたか
• 完了済みを作り直さなかったか
• 却下済みの案を復活させなかったか
• 結果不明の処理を再実行しなかったか
• 現在の成果物と記録の差を検知できたか
• 承認されていないmutationで止まれたか

測る指標も、「会話が再び開くまで」だけでは足りません。

Netsujoでは、安全に次の作業へ戻るまでの時間（Time to Safe Resume）と、重複してやり直した仕事の数を見る方が実務に近いと考えています。現時点では、この方式による削減率の定量値までは計測していません。

まとめ

「このChatGPTの会話を読み込めませんでした」が出たとき、再試行だけに依存すると、画面の障害がそのまま仕事の障害になります。

復旧を二層に分けます。

UI RECOVERY
検索 / 再試行 / 別環境 / Status / Support
          ↓
WORK RECOVERY
現物確認 / 外部process照合 / durable state / readback
          ↓
SAFE RESUME
重複実行なしで次の一手へ

ChatGPTは相談と指示の入口として使う。

仕事の現在地、成果物、実行結果、承認は、会話が読めなくても確認できる場所にも残す。

これで、元の会話が復旧するまで「待つ」しかなかった状態から、確認できる事実を使って次の仕事へ進める状態へ変えられます。

参考資料

• OpenAI Help Center: Troubleshooting ChatGPT Error Messages
• OpenAI Help Center: How do I search my chat history in ChatGPT?
• OpenAI Help Center: Memory FAQ
• OpenAI Status
• Netsujo: Stopを押しても、仕事は止まらない
• Netsujo: 同じ案件なのに、チャット名が違う
• Netsujo: CodexとClaude Codeを並列で動かして分かった。AIエージェント開発で本当に難しいのは「状態管理」だった

よくある質問

再試行を何回押せばよいですか

回数に意味を持たせません。数回試して変化がなければ、履歴検索、別ブラウザー、プライベートウィンドウ、Status確認などへ切り替えます。同じ操作を延々と繰り返さないため、Netsujoでは初期切り分けに時間上限を置きます。

会話が開けないなら、新しい会話で同じ指示を送り直してよいですか

外部への副作用がない依頼なら影響は限定的です。公開、送信、デプロイ、DB変更などを含む場合は、先の処理が実行済みかを受け側で確認してから判断します。結果不明のまま再実行しません。

新しい会話に元の会話URLだけ渡せば復旧できますか

URLを開けるなら有用な手掛かりです。しかし今回のように元の会話自体を取得できない状況では、URLだけでは復旧できません。WORK_ITEM_ID、成果物、現在状態、Evidenceを別に持たせます。

ChatGPTのMemoryへ全部覚えさせれば十分ですか

十分ではありません。Memoryは継続文脈を助けますが、作業状態・実行結果・承認・Exact SHAなどの正本にはしません。検証が必要な状態は、検証可能な保存先へ残します。