「変更が消えた」の正体は、たいてい別の机で作業していただけ
まとめ（先に結論）
AI エージェントにコードを書かせていると、「さっき直したはずの変更が見当たらない」が起きます。私の場合、原因のほとんどはファイルが消えたことではありませんでした。別の作業机で作業していたのに、同じ机だと思い込んでいただけです。
混乱の元は、次の5つが全部いっしょくたに「プロジェクト」や「ブランチ」と呼ばれてしまうことにあります。
| 言葉 | 正体 | どこに存在するか |
|---|---|---|
| リポジトリ | 変更履歴をまるごと収めた箱 | Git の世界 |
| ブランチ | 履歴の分岐（main、feature/login など） | Git の世界（手元） |
| リモートブランチ | GitHub 側にあるブランチの、手元での写し（origin/main） | Git の世界（GitHub を映したもの） |
| worktree | 同じリポジトリに複数の作業机を用意する仕組み | ファイルシステム（フォルダ） |
| プロジェクト | アプリ側の登録。「このフォルダで作業する」というブックマーク | アプリの設定（Git とは無関係） |
いちばん誤解しやすいのは最後の2つです。プロジェクトはブランチではありません。そして worktree は、Git の履歴ではなくフォルダの話です。
困ったときに最初に打つコマンドは、これだけ覚えておけば足ります。
git worktree list && git branch --show-current前提
この記事は、自宅の Mac mini に外から入ってAI を動かす（ノンエンジニア向け） の続きです。前の記事では「どの画面から操るか」と「どのパソコンで処理させるか」を分けました。今回はもう一段内側、処理するパソコンの中で、AI がどのフォルダのどの履歴を触っているかの話になります。
私はノンエンジニアです。Git は AI に教わりながら使っている程度で、用語を正確に説明できる立場ではありません。ここに書くのは、実際に何度も混乱した末に「こう理解しておくと間違えなくなった」という整理です。正確な定義は公式ドキュメントを見てください。
やったこと
書庫と作業机にたとえる
用語のままだと頭に入らなかったので、たとえ話に置き換えました。
- リポジトリ ＝ 書物の全歴史が収まった書庫
- ブランチ ＝ その書物の系統。「正本の系統」「改訂試作の系統」と枝分かれしている
- リモートブランチ ＝ 中央図書館（GitHub）にある系統の控え。手元にあるが、中央の状態を映しているだけ
- worktree ＝ 書庫の隣に並べた複数の作業机。机ごとに別の系統を広げられる
- プロジェクト ＝ 「今日はこの机で作業します」とアプリに貼った付箋。書庫の中身とは何の関係もない
この置き換えで、私の混乱はだいぶ減りました。「変更が消えた」は、書庫から本が消えたのではなく、隣の机に広げてあったというだけの話です。
なぜ混ざるのか
そもそも、なぜ「プロジェクト」と「ブランチ」が同じものに見えてしまうのか。
デスクトップアプリが、新しいセッションを作るたびに、裏で自動的に作業机とブランチを同時に用意しているからです。こちらの操作は「新しいセッションを作る」の一度きりなのに、内側では2つのことが起きています。
- アプリが worktree（机）を用意する
- その机に新しいブランチが割り当てられる
「プロジェクトを作った」と「ブランチができた」が同時に起きるので、同じ操作に見える。ここが誤解の発生源でした。
Claude のデスクトップアプリは、Git リポジトリの場合、セッションごとに worktree を切って隔離します。既定の保存先は <プロジェクトの根>/.claude/worktrees/ です[1]。CLI でも claude remote-control --spawn worktree で同じ挙動になります[2]。
「プロジェクト」は製品ごとに別の意味
もうひとつの罠がこれでした。「プロジェクト」という言葉が、複数の製品で別の意味に使われています。
- Claude Code の作業フォルダ
- Claude.ai の Projects
- Claude Cowork の Projects
名前は同じでも、同じものではありません。「プロジェクトに入れておいたのに AI が知らない」の原因が、だいたいここでした。
結果・観測
整理した結果、次の3つの場面で迷わなくなりました。
1. クラウドのセッションと手元が食い違う
クラウド側のセッションから見えるのは、GitHub にコミット済みのものだけです。手元の机に広げたままコミットしていない変更は、当然そこにはありません。
これは不具合ではなく仕様です。前の記事に書いた「処理マシンがどこか」の話が、そのままここに効いてきます。
2. Codex の Handoff が候補に出てこない
ChatGPT / Codex の Handoff は、作業を別のパソコンへ移す機能です。ここに条件がひとつあります。移動先のパソコンにも、同じ Git リポジトリのプロジェクトを保存しておく必要がある[3]。
リポジトリのサブディレクトリを使っている場合は、両方のパソコンで同じサブディレクトリを登録する必要があります。
これは Git の問題ではなく、付箋を貼っていないという問題です。書庫は共有されているのに、移動先の机に「ここで作業します」の付箋がないから候補に出てこない。そう理解してから、詰まらなくなりました。
3. 「変更が消えた」の大半は錯覚だった
実際に多かったのは、別のセッション＝別の机で作業していたというケースです。ファイルは消えていません。隣の机に広げたままになっているだけです。
だから最初に打つのは、復旧コマンドではなく確認コマンドです。
git worktree list && git branch --show-current机の一覧と、いま自分がどの系統を開いているか。これを見れば、たいていは「ああ、あっちの机か」で終わります。
感想・Next
Git を正確に理解しようとするより、階層が違うものを混ぜないことのほうが、実用上は効きました。Git の世界（リポジトリ・ブランチ）と、フォルダの世界（worktree）と、アプリの設定（プロジェクト）。この3つは別の層にあります。
同じ「プロジェクト」という言葉が、製品ごとに違う意味で使われている以上、言葉に頼って理解するのは無理があります。どの層の話をしているのかを毎回確認するしかない、というのが今のところの結論です。
次は、AI に作業を頼むときの最初の一文に、対象のリポジトリと作業フォルダを必ず書く運用を試しています。セッション名だけでは、あとから見て判別できないことが多かったためです。
[1] Claude Code 公式ドキュメント「Desktop application」。Git リポジトリではセッションごとに worktree で隔離され、既定の保存先は <project-root>/.claude/worktrees/。Settings → Claude Code の「Worktree location」で変更できる。2026-08-24 に再確認済み。
https://code.claude.com/docs/en/desktop
[2] Claude Code 公式ドキュメント「Remote Control」。claude remote-control の --spawn <mode> オプションに worktree モードがあり、オンデマンドのセッションごとに git worktree が割り当てられる。このモードは git リポジトリを必要とする。2026-08-24 に再確認済み。
https://code.claude.com/docs/en/remote-control
[3] ChatGPT / Codex 公式ドキュメント「Remote connections」の「Hand off a chat between hosts」。Handoff の前提条件として、移動先ホストに同一リポジトリのプロジェクト登録が必要である旨が記載されている。サブディレクトリの場合は両方のパソコンで同じサブディレクトリを登録する必要がある、とも明記。2026-08-24 に再確認済み。
https://learn.chatgpt.com/docs/remote-connections
コメントを送信