はじめに
「昨日の続きをやって」
そう伝えると、Claudeはこう返します。
「どのような作業を続けますか？詳しく教えてください」
……思わずため息が出ます。昨日あれだけ説明したのに、また最初から？
Claude CodeのCoworkモードは、ドキュメント作成・リサーチ・ファイル整理といった「知識労働」全般を自律的にこなせる強力なエージェントです。しかし、セッションをまたぐたびにコンテキストが完全にリセットされるという制約があり、数日にわたる大規模タスクでは「再説明コスト」が積み上がっていきます。
この記事では、その問題を作業状況をMarkdownファイルに書き出すだけで解決するワークフローを紹介します。特別なツールや設定は不要で、今日から即使えます。
執筆時点の環境： Claude Desktop（macOS / Windows）、2026年6月時点の仕様に基づいています。ツールのアップデートにより、以下で説明する制約が将来的に解消される可能性があります。
Coworkモードが抱える制約
CLIとCoworkモードの違い
「Claude Code」にはターミナルで使うCLIと、デスクトップアプリで使うCoworkモードの2通りがあります。この2つは、コンテキスト管理の面で大きく異なります。
| Claude Code CLI | Coworkモード | |
|---|---|---|
| 起動方法 | ターミナルで claude
|
Claude Desktopアプリの「Cowork」タブ |
| 主な用途 | コーディング・開発作業 | 知識労働全般（文書・リサーチ等） |
/compact コマンド |
✅ 使える | ❌ 使えない |
| セッション再開 |
claude -c でレジューム可 |
アプリが閉じると即終了 |
CLIには /compact というコマンドがあり、長くなった会話をその場で要約・圧縮して「続き」から作業できます。一方、Coworkモードにはこのコマンドがなく、公式ドキュメントにも次のように明記されています。
「セッション永続性：Claude Desktopアプリが開いており、コンピュータが起動している必要があります。アプリを閉じたりコンピュータがスリープに入ると、アクティブなタスクは停止します。現時点ではセッション間のメモリ永続化機能はありません。」
— Get started with Claude Cowork
何が起きているのか
AIの会話コンテキストは、コンピュータで言えば**RAM（揮発性メモリ）**です。電源が切れれば消えます。セッションが終了した次の新しいCoworkタスクでは、Claudeは以下をすべて忘れています。
- 前回どこまで作業が進んでいたか
- どんな設計判断を下したか
- 残っている問題・保留事項は何か
- なぜその技術選定にしたか
数時間の作業を1日に何度も中断・再開するだけで、毎回10〜20分の「再説明タイム」が発生します。1週間で積み上がると、かなりのロスです。
解決策：コンテキストをファイルに「セーブ」する
発想の転換はシンプルです。
会話コンテキスト（揮発性） → ファイル（不揮発性）
セッションをまたいでも消えないのはファイルです。作業状況をMarkdownとして書き出しておけば、次のセッションでそれを読み込ませるだけで「続き」から始められます。
■ 従来のワークフロー
セッション開始
↓
作業する
↓
セッション終了 ←── コンテキスト消滅
↓
次回セッション：ゼロから再説明（ロス大）
■ コンテキスト外部化ワークフロー
セッション開始
↓
作業する
↓
status.md に状況を書き出す
↓
セッション終了
↓
次回セッション：status.md を読み込む → 即座に続きから（ロスほぼゼロ）
具体的なワークフロー
Step 1：status.md のテンプレートを用意する
以下のテンプレートを status.md として作業フォルダに置いておきます。初回は空の状態でも構いません。
# 作業状況スナップショット
最終更新：{日時}
## タスク概要
（このプロジェクト全体で何をするか、1〜2文）
## 完了済み作業
- [x] ○○ファイルの作成
- [x] △△の調査・整理
## 現在の作業位置（次にやること）
→ **□□の実装**（最優先）
→ △△の見直し（次の優先）
## 未解決の問題・保留事項
- 問題A：○○が想定通りに動かない。暫定対処済みだが根本原因は不明
- 保留B：△△の仕様をユーザーに確認中
## 重要な設計判断メモ
- ○○は□□方式を採用（△△方式も検討したが、理由Xで却下）
- ファイル構成は現状維持（変更するとYのリスクあり）
## 参照すべき主要ファイル
- `src/main.py`：コアロジック
- `docs/spec.md`：仕様書
200行以内を目安に。 CLAUDE.mdと同じ原則で、長すぎるとコンテキストを圧迫して逆効果になります。「次に何をするか」と「なぜその判断をしたか」だけに絞るのがコツです。
Step 2：中断前にClaudeに書き出させる
作業を終える前に、このプロンプトを送ります。
この作業を一旦終了します。
次回再開できるよう、現在の作業状況を status.md に書き出してください。
以下を漏れなく記載してください：
- 完了済みの作業
- 次にやること（最優先のものを明示）
- 未解決の問題・保留事項
- 今回下した設計判断とその理由
Coworkモードはローカルファイルに直接書き込めるため、Claudeが status.md を作成・更新してくれます。自分で書く手間は一切ありません。
チェックポイントを設ける。 セッション終了時だけでなく、大きな作業単位が1つ完了したタイミングでも更新させると、より精度の高い状態が保存されます。「○○が完成したら status.md を更新して」とあらかじめ指示しておくのも効果的です。
Step 3：再開時は一言でOK
次のCoworkタスクを始める際に送るのは、たったこれだけです。
status.md を読んで、前回の続きから作業を再開してください。
Claudeは前回の進捗・設計判断・未解決問題をすべて把握した状態で「では□□の実装から始めます」と答えてくれます。
CLAUDE.md（Global instructions）との役割分担
CoworkモードにはGlobal instructionsという設定があり、毎セッション自動的に読み込まれます（Claude Codeで言えば CLAUDE.md に相当）。これを status.md と組み合わせることで、ワークフローが完全に自動化されます。
| Global instructions（CLAUDE.md相当） | status.md | |
|---|---|---|
| 役割 | プロジェクトの恒久的なルール | その時点の作業状態 |
| 更新頻度 | ほぼ変わらない | セッションごとに更新 |
| 内容例 | コーディング規約、出力形式の好み、使用スタック | 進捗、未解決問題、設計判断の経緯 |
Global instructionsに以下を追加しておくと、毎回のプロンプトすら不要になります。
## 作業開始時のルール
- 作業フォルダに status.md が存在する場合は、最初に必ず読んで現在の状況を把握すること
- 作業の完了時・中断時は status.md を最新状態に更新すること
Before / After：効果の比較
| Before（ワークフローなし） | After（status.md導入） | |
|---|---|---|
| 再開時のやり取り | 「どんな作業？」「どこまで進んだ？」「技術は？」「前回の判断は？」… | 「status.mdを確認しました。□□から再開します」 |
| 再説明・修正の発生回数 | 平均8回程度 | 0〜1回 |
| 再開までの所要時間 | 10〜20分 | 1〜2分 |
| 設計判断の引き継ぎ | ❌ 都度説明が必要 | ✅ 理由ごと引き継ぎ |
参考として、同様のアプローチをとるオープンソースツール「devpace」の比較テストでは、構造化されたMarkdown状態ファイルにより3回の中断ポイントを経ても修正ゼロを達成（手動のCLAUDE.md管理では同条件で8回の修正が必要）という結果が報告されています。原理的に同じ status.md 方式でも、同等の効果が見込めます。
応用：複数日にわたるプロジェクトへの拡張
数日〜数週間規模のプロジェクトでは、status.md に作業ログを累積させていくことで、過去の判断経緯をClaudeが参照できるようになります。
# 作業状況スナップショット
## 現在の状況（常に最新）
→ 次にやること：○○の実装
## 作業ログ
### 2026-06-10
- △△の設計を決定（モノレポ構成は複雑になるためシンプルな分離構成を採用）
- ○○コンポーネントの実装完了
### 2026-06-09
- プロジェクト全体の方針を固める
- ライブラリ選定：○○は△△ではなく□□を採用（理由：ビルドサイズ）
「なぜこの構成にしたか」「なぜこのライブラリを選んだか」という背景が蓄積されることで、Claudeが過去の判断を覆す提案をしてくる頻度が大幅に減ります。
注意点
status.mdが古くなると逆効果になります。
更新し忘れると古い状態から誤った方向で作業が再開されます。「セッション終了時に必ず更新する」をルールにするか、Global instructionsで自動更新を義務付けましょう。
詰め込みすぎは禁物です。
「全部書いておけば安心」という気持ちはわかりますが、長大な status.md はそれ自体がコンテキストを圧迫します。「次に何をするか」と「なぜそうするか」の2点に絞ると、200行以内に収まることがほとんどです。
Gitと役割を分けてください。
status.md は「Claudeへの引き継ぎメモ」であり、変更履歴の代替ではありません。実際のコード・ファイルの変更管理はGitで行い、status.md はGitにコミットするか .gitignore に入れるかプロジェクト方針に合わせて決めてください。
まとめ
Coworkモードの制約とその対処をまとめます。
| 制約 | 対処 |
|---|---|
| アプリを閉じるとセッション終了 | 中断前にstatus.mdへ書き出す |
/compact コマンドが使えない |
status.mdが「外部メモリ」として代替 |
| セッション間のメモリ継承なし | Global instructionsで自動読み込みを設定 |
コンテキストを外部ファイルに書き出すというアイデア自体はシンプルですが、実際に運用に組み込むと「再説明コスト」がほぼゼロになり、AIとの協調作業の体験が大きく変わります。Coworkモードに限らず、AIエージェントを複数日にわたって使うあらゆるシーンに応用できる汎用パターンです。
まずは1つのプロジェクトで試してみてください。
本記事の内容は2026年6月時点の仕様に基づいています。Claude DesktopおよびCoworkモードの仕様は今後変更される可能性があります。最新情報は公式ドキュメントをご確認ください。