検証した主張
「新しいPCで同じChatGPTアカウントにログインすれば、ローカルのCodex作業も自動的に完全復旧する。」
発見元は調査の入口であり、判定の根拠には使用していません。アプリに再ログインすれば「昨日の続き」になる？
突然PCが使えなくなったとき、新しいPCにChatGPTアプリを入れるだけで開発中のWebサイトも戻るのでしょうか。答えは、どこに何を保存していたかで変わります。ChatGPTのプロジェクトや会話、GitHubに送ったソース、PC内だけの変更、別置きの画像は、同じ「作業」に見えても別々の場所にあります。
この記事では、アカウント側に残る情報とPCにしかない作業を分け、公開された公式資料に基づいて復旧の備えを整理します。
まず「戻せるもの」を保存先ごとに分ける
OpenAIのProjectsは会話、ファイル、指示をまとめるための機能です。一方、Codexのローカル作業やworktreeのリポジトリとコマンドは、その作業を実行するPCまたはリモート開発環境に残ります。Remoteで別端末から接続しても、接続先のPCが故障した際のバックアップにはなりません。
GitHubの公式説明では、ローカルのコミットをオンラインのリポジトリに送る操作がpushです。「保存」や「コミット」だけで、別PCから取得できる版が増えるわけではありません。
| 対象 | 復旧元 | 失われ得る部分 |
|---|---|---|
| ChatGPTの会話・プロジェクト | 同じアカウントでアクセスできるサービス側の情報 | PC内で編集中だった未保存ファイルまで自動で含まれるわけではない |
| Git管理のコード・記事 | 最後にリモートへpushした履歴 | 未コミット・未pushの変更 |
| 画像・動画・Office原本 | 別置きのバックアップや保管先 | 最後のコピー以降の変更と保管対象に含めなかったファイル |
| ログイン・秘密設定 | 本人が管理する認証手段と再設定手順 | 旧PCだけにある鍵、トークン、復旧コード、ローカル設定 |
| ホスティング上の運用データ | サービス側に残る既存リソース、別途用意したバックアップ | PC故障だけなら通常は再接続で済むが、サービス側のデータ消失は別の対策が必要 |
「1か月後に壊れたら、1か月分は消える？」
復旧できるコードの時点は「GitHubにリポジトリを作った日」ではなく、最後に正しいブランチへpushした時点です。毎回pushしていれば、その最後の版まで取得できます。逆に、1か月間PCの中だけで編集していたなら、その期間の変更はGitHubからは取り出せません。GitHub以外のバックアップがあれば、そこまで戻せる可能性があります。
公開用ブランチへのpushが自動デプロイを起動するサイトもあります。保全のためだけに未検証の変更を本番ブランチへ送るのではなく、別ブランチや適切なバックアップ経路を用意し、公開手順と区別してください。
故障する前に決めておく5つのこと
大切なのは「バックアップがあるはず」ではなく、保存先、更新頻度、別PCからの読み出し方法を明文化することです。
- ① コード・記事の正本となるリポジトリとブランチを案件ごとに特定し、作業終了時に変更を確認してcommit・pushする。
- ② READMEやSETUPなどに必要なソフト、起動・検査・公開手順を残す。手順書にはパスワードや復旧コードを書かない。
- ③ Gitに含まれない画像・動画・文書は、アクセス制御された別の保存先へ退避し、コピー後のファイルを読み出して確認する。NASだけを唯一の保管先にしない。
- ④ パスワード、APIキー、多要素認証の復旧手段は、信頼できる秘密管理と端末外の保管方法で扱う。リポジトリには必要な設定名だけを記す。
- ⑤ 定期的に別フォルダーや別PCへ取得し、ビルドと資料の読み出しを試す。運用データを持つサービスでは、PC交換とサービス側データの復元を別の試験にする。
新しいPCで再開するときの順序
最初に自分のアカウントへ安全に再ログインし、対象のGitHubリポジトリとブランチを確認します。新PCへcloneして、手順書に沿って依存関係や開発ツールを準備し、ローカルでビルド・テストを実行します。別置きの資料は、必要なものを読み取り権限と版を確認して取り込みます。
Cloudflareなどの既存の公開サービスやデータベースは、PCだけの故障ならまず同じリソースへ再接続する対象です。ローカル環境が復元できたことと、クラウドの実データのバックアップ・復元が確認できたことは別です。本番データを試験目的で上書きしないでください。
確認範囲と、あえて断定しないこと
この記事は、2026年9月22日時点のOpenAI Docs、GitHub Docs、Cloudflare Docs、NISTの公開資料に基づきます。特定のPC、NAS、アカウント、リポジトリの状態は確認していません。「この手順で必ず完全復旧する」という保証ではありません。
2台を同時に使う場合は、バックアップとは別に変更の取り込みと競合対策が必要です。切り替えの手順は関連する2台運用の記事で説明します。
検証条件・対象環境
| 対象プラン | ChatGPT・Codexの利用条件およびGitHub等の各サービスの権限に依存 |
|---|---|
| 地域 | 各サービスが利用できる地域 |
| 利用面 | ChatGPTデスクトップアプリ / Codex Local・Worktree / GitHub / クラウドストレージ・NAS |
| 提供状態 | 特定端末・アカウントの復旧保証ではなく、保存先ごとの一般的な復旧設計 |
| 実機確認 | OpenAI Docs、GitHub Docs、Cloudflare DocsとNIST資料を確認。別PCへの移行や全データの復元試験をこの記事のために実施したものではありません。 |
| 次回見直し | 2026.10.22 |
よくある質問
GitHubにリポジトリがあれば、故障直前の状態まで戻りますか？
いいえ。原則として最後にリモートへpushした版までです。未pushの変更は別のバックアップがない限りGitHubからは復旧できません。
Remoteを使えば、故障したPC内の作業も救えますか？
Remoteは接続先PCの作業を別端末から操作する仕組みで、独立したバックアップではありません。PCが利用できなくなる前にコードや資料を別の保存先へ退避します。
PCが壊れたらCloudflareのD1を復元する必要がありますか？
PCだけの故障なら、通常は既存のCloudflareアカウントとリソースへ再接続します。D1などサービス側データの破損・消失への備えは別のバックアップと復元試験が必要です。
更新履歴
PC故障時の復旧範囲を、会話、コード、資料、認証、運用データに分けて整理。
情報源
一次情報と発見元を区別し、各ページの公開日と確認日を記録しています。
- Projects and chats
ChatGPTプロジェクトで扱う会話、ファイル、指示の範囲を確認。
公開: 日付表記なし（随時更新）確認: 2026.09.22 - Worktrees
ローカルのリポジトリ・worktree・コマンドの配置を確認。
公開: 日付表記なし（随時更新）確認: 2026.09.22 - Remote connections
接続先のPCが利用できなくなればRemoteはバックアップの代わりにならない点を確認。
公開: 日付表記なし（随時更新）確認: 2026.09.22 - Pushing commits to a remote repository
ローカルコミットをリモートへ送るpushの役割を確認。
公開: 日付表記なし（随時更新）確認: 2026.09.22 - Configuring two-factor authentication recovery methods
認証デバイスを失った場合の復旧手段とコードを安全に保管する必要性を確認。
公開: 日付表記なし（随時更新）確認: 2026.09.22 - Time Travel and backups
PCの故障とD1側のデータ復元を別の問題として区別。
公開: 日付表記なし（随時更新）確認: 2026.09.22 - Protecting Data from Ransomware and Other Data Loss Events
ハードウェア故障を含むデータ喪失への備えと、バックアップの作成・維持・復元試験を確認。
公開: 2020.04.24確認: 2026.09.22