Claude Code Projectsのクラウドセッションを復元するには？2026年の容量計画

Claude Code Projectsを長時間運用する開発者向けに、クラウドセッション復元の考え方を整理します。会話状態、並列スレッド、プロジェクトファイル、生成物、ビルド処理、復旧用の余力を分け、実際に拡張すべき条件を判断できる構成です。

セッションが途中で止まり、ローカルMacを再接続しても、どこまで作業が終わったのか分からない状態になっています。

結論：Claude Code Projectsのクラウドセッション復元を重視するなら、Agent数ではなく、ピーク時の並列スレッド、プロジェクトファイル、生成物、ビルド処理、復旧用の余力を分けて見積もります。 長時間・高並列・日をまたぐ作業は永続化できるクラウド開発ワークスペースを優先し、短時間の単独作業はローカルまたは軽量環境で十分です。

この記事は、長時間のClaude Code Projects作業中に端末がスリープしたり、接続が切れたりする開発者向けです。複数Agentを同じコードベースで動かす小規模チーム、クラウドMacや開発環境の容量と復旧方針を管理する担当者にも適しています。

まず「セッション数」ではなく、止まった時に残すものを分けます

Projectsでは、プロジェクトに関連付けた資料、指示、スレッド、記憶をまとめて扱えます。公式のプロジェクト管理手順でも、プロジェクト情報と会話スレッドを分けて管理する考え方が示されています。

そのため、1つの作業を単純に「1セッション」と数えると、容量を誤ります。少なくとも次の状態を別々に記録します。

• 実行中：Agentが推論、ファイル操作、コマンド実行を続けている状態
• ツール待ち：ビルド、テスト、外部サービス、ファイル処理の返答を待つ状態
• 中断・保留：再接続後に続行したいが、処理が完了していない状態
• 完了保管：結果、ログ、変更履歴を後から確認するために残した状態

容量表には、1日の平均件数ではなく、同じ時間帯に存在する最大数を記録します。さらに、失敗した処理を再実行するための空きも別枠にします。空きがない状態で再試行すると、元のログや生成物を削除してしまい、復旧の手掛かりまで失うためです。

Claude Code Projectsのクラウドセッション復元は、何を保存できるかで決まります

「Projectsのプロジェクトファイルと記憶が容量にどう影響するか」を考えるとき、論理上の共有と物理上の保存を分ける必要があります。共有メモリーや指示が同じでも、各Agentが別の作業ツリーを持てば、実際のファイル、ログ、ビルド生成物は増えます。

Gitの一時退避は、未コミット変更を保護する手段の1つです。ただし、Git stashの公式説明が示す通り、退避は長期保管そのものではありません。復旧の基準にする変更は、コミット、パッチ、または別の永続領域にも残します。

複数Agentを分離する場合は、worktreeを使う設計もあります。Git worktreeの仕様を確認すると、同じリポジトリから複数の作業ツリーを持てる一方、各作業ツリーの変更、依存関係、ビルド出力まで自動的に共有されるわけではないことが分かります。論理的に同じリポジトリでも、物理容量が比例して減るとは限りません。

並列Agentは、何を基準にクラウド開発ワークスペースを選ぶべきか

多 Agent 並列では、Agentの人数をそのまま必要容量に変換しません。実際に見るべきなのは、処理の種類と同時実行の山です。

たとえば、コード調査だけならCPUより会話履歴とファイル読み込みが問題になります。一方、テストやビルドを複数の作業ツリーで走らせると、メモリー、ディスクI/O、ログ保存、ビルド待ち行列が同時に膨らみます。Agentを増やしても、依存関係のある処理は速くならず、むしろ同じファイルを触る競合と再実行が増える場合があります。

評価は「最大Agent数」ではなく、次の式で行うと整理しやすくなります。

必要容量 ＝ 基本ワークスペース ＋ ピーク並列分 ＋ 依存関係・キャッシュ ＋ 生成物保管分 ＋ 復旧余力

ここで各項目を絶対値で決められないのは、公式資料がクラウドワークスペースの一律容量や料金を定めていないためです。実際のプロジェクトのリポジトリ、依存関係、ログ保管期間、同時ビルド数を測ってから、契約候補と照合します。

第一歩：作業を4種類に分類します

まず、予定している処理を次のように分類します。

1. 短時間の対話、コード検索、単一ファイルの修正
2. 長時間のテスト、ビルド、移行、データ処理
3. 複数Agentによる調査、実装、レビューの分担
4. 日をまたいで再開する必要がある作業

4番に該当するなら、端末が切れても作業状態が残ることを優先します。端末のスリープ設定だけで解決しようとするのは危険です。Macのスリープと復帰に関する公式設定ガイドを確認しても、ネットワーク切断、プロセス終了、外部サービスの失敗まで防げるわけではありません。

第二歩：活発な処理と保留中の処理を分けます

一覧表には、処理名、担当Agent、開始状態、待機理由、変更ブランチ、最後に保存されたログを記録します。ツール待ちの処理を「停止」と見なして削除すると、外部サービスの返答後に必要な手順を失います。

逆に、完了済みのログをすべて永続保存すると、生成物と会話履歴が増え続けます。保管対象を「再現に必要なログ」「監査に必要な変更」「一時的なデバッグ出力」に分け、期限を決めて削除します。

第三歩：依存関係と生成物を共有できるか確認します

依存関係を読み取り専用キャッシュとして共有できる構成なら、重複保存を抑えられます。ただし、Agentやビルドがキャッシュを書き換える設計なら、破損したキャッシュを全作業が共有するリスクがあります。

コンテナを使う場合も、コンテナ本体と永続データは別に扱います。永続ボリュームの公式説明を基準に、ソースコード、キャッシュ、データベース、ログの保存先を分離します。再起動後にコンテナだけ戻っても、必要なボリュームが消えていればセッション復元にはなりません。

第四歩：Gitの復旧点を作ってから並列処理を開始します

並列作業の前に、基準ブランチ、Agentごとの担当範囲、変更を統合する条件を記録します。未コミット変更だけに依存せず、作業単位ごとに復元可能なコミットまたはパッチを作ります。

「失敗したタスクを同じ指示で最初から動かす」方法は、二重書き込みや重複した外部操作を起こしやすいです。再実行前に、最後のコマンド、変更済みファイル、生成物、外部サービス側の状態を確認し、再実行可能な段階から続けます。

第五歩：再接続後の復元テストを実施します

復元テストでは、次の順番で確認します。

• クラウドワークスペースに再接続できるか
• Projectsの対象スレッドと指示が確認できるか
• Gitのブランチと未コミット変更が一致しているか
• 実行中だったコマンドの結果が保存されているか
• 秘密情報や認証トークンが失効していないか
• 外部API、データベース、CI処理の状態を照合できるか
• Agentに「完了済みの操作」を繰り返させず続行できるか

クラウド開発環境には、停止、休止、再開などのライフサイクルがあります。クラウド開発環境のライフサイクル説明でも、環境の状態と保存データを同一視しない考え方が示されています。タイムアウト設定も、公式のタイムアウト設定手順を参考にしながら、長いビルド時間と自動停止の条件を確認します。

失敗したタスクを、重複実行せずに戻すにはどうするか

復元の要点は、会話、ファイル、Git、外部サービスの4つを別々に照合することです。

会話スレッドが残っていても、ファイル変更が保存されているとは限りません。反対に、ファイルが残っていても、最後にどのテストまで成功したか分からなければ、安全に続行できません。

そこで、各タスクに次の復元記録を添えます。

• 最後に確認できたコミット
• 未コミット変更の一覧
• 最後に成功したコマンド
• 実行中または未確認のコマンド
• 保存済みのログと生成物
• 外部サービスに送った操作
• 次に人間が確認すべき判断

CIの成果物も無期限に残すのではなく、復元に必要なものと一時出力を分けます。成果物の保存方法と不要な成果物の削除方法を基準に、保存期間と削除権限を決めます。

スコアで判断すると、次のようになります。

どの条件で容量を増やすべきか

拡張の判断は、Agent数ではなく次の条件で行います。

• ピーク時に複数のビルドやテストが待ち行列になる
• セッション復元のためのログを削除しないと空きが確保できない
• Agentごとのworktreeや依存関係が重複している
• 失敗時に再実行する余地がなく、元の状態を上書きしている
• 再接続後に、完了済み操作と未完了操作を区別できない
• 端末のスリープや回線断が、長時間タスクの停止原因になっている

逆に、処理が直列で、成果物をすぐ削除でき、日をまたぐ復元も不要なら、容量を増やしても効果は限定的です。先に並列度を制限し、ログと生成物の保管方法を見直します。

ローカルMacは、短い修正、物理デバイスを使う開発、常時手元で確認する作業に向いています。ただし、スリープ、回線断、個人端末の再起動、ローカルディスクの逼迫という弱点があります。長時間のClaude Code Projects運用をローカルだけに任せると、復元手順が人の記憶に依存しやすくなります。

そのため、短期の検証や一時的な多 Agent 並列では、ZekVPSのクラウドMac環境を候補にできます。自前端末の休止を避けやすく、作業場所を分離できる一方、長期の安定した高負荷運用、特殊な物理インターフェース、常時固定の開発基盤が必要なら、自社管理のMacや専用環境と費用・運用負荷を比較すべきです。

日本国内からの接続拠点や遅延を重視する場合は、日本向けクラウドMacレンタルの案内も確認します。実際の選択では、地域だけでなく、作業時間、同時接続者、保存する生成物、復旧テストの方法を合わせて確認する必要があります。

現在のローカル運用には、端末のスリープで処理が止まること、回線断後の状態確認が手作業になること、複数Agentのログと依存関係が同じディスクを圧迫することがあります。これらを避けながら短期間だけ検証したい場合は、ZekVPSのMacレンタルでクラウド開発ワークスペースを用意する方が、作業期間と必要容量を合わせやすい選択です。

契約前には、次の変数だけを先に埋めます。

ピーク同時セッション数、1セッションの最大実行時間、Agentごとの作業ツリー数、依存関係キャッシュ、生成物の保管期間、失敗時の再試行数、復元テストの頻度。

この表を埋めても物理容量や復旧余力が足りないなら拡張します。短時間の単独作業で数値が小さいなら、無理にクラウドへ移さずローカルを使います。判断をAgent数だけに絞らないことが、Claude Code Projectsのクラウドセッション復元を失敗させない最初の条件です。