はじめに
Claude CodeのCoworkモードで、長時間かけてローカルLLM環境を構築していたときのことです。Step 5まで順調に進んだところでセッションが長くなり、「そろそろ会話を圧縮しておこう」と思って /compact を打ちました。
何も起きません。
AIに聞いてみると、こんな返答が来ました。
/compactはClaude Codeのコマンドです。今使っているのはCoworkモードなので、そのコマンドは使えません。ただ、この会話の内容（Step 1〜4完了、Step 5完了、次はStep 6）はmdファイルに記録されているので、新しい会話を始めてもmdファイルを読み込めば続きから再開できます。
なるほど、と思いました。そして同時に、「これ、ちゃんと設計すれば /compact がなくても全然困らないな」とも気づきました。
この記事でわかること：
- Coworkモードで
/compactが使えない理由 - mdファイルへのコンテキスト外部化という設計アプローチ
- 「いつ・何を書くか」の具体的なテンプレートと更新ルール
- 新セッション冒頭の定型プロンプトで1〜2分で再開する方法
Coworkモードに/compactはない
Claude CodeのCLIには /compact コマンドがあり、会話コンテキストを要約・圧縮してトークン消費を抑えることができます。長時間の作業では欠かせない機能です。
ところが、Coworkモード（デスクトップアプリ）にはこのコマンドが存在しません。
Coworkはターミナルベースのコマンドとは別のセッション管理モデルを採用しているため、CLIコマンドがそのまま使えるわけではありません。知らずに使おうとするとスルーされるか、AIに「それはCLIのコマンドです」と教えてもらうことになります。
この制約を前提に考えると、「会話の中にコンテキストを維持しようとするからしんどい」という視点の転換ができます。
解決策：コンテキストをmdファイルに外部化する
会話に記憶させるのをやめて、mdファイルに書く。
AIとの会話は揮発性のメモリです。セッションが切れれば消えます。それに依存しているから、断絶がコストになる。ならば、永続ストレージであるファイルシステムにコンテキストを置けばいい。
この設計のメリットは /compact の代替にとどまりません。
- セッションが切れても再開できる
- 別のAIツール（Cursor、Copilot等）に引き継げる
- 作業ログとして後から参照できる
- チームメンバーに共有できる
mdファイルが「単一の真実の源泉」になることで、会話ではなくファイルがプロジェクトの状態を管理するようになります。
作業状況mdのテンプレート
「何を書けばいいかわからない」を防ぐために、テンプレートを固定します。5セクション構成です。
# 作業状況: [プロジェクト名]
最終更新: YYYY-MM-DD HH:MM
## 環境情報
- OS: Windows 11 / Ubuntu 22.04 etc.
- 主要ツール・バージョン: (例: Docker 25.0, Python 3.12)
- 設定ファイルパス: (例: C:\Users\xxx\project\config.yaml)
- 特記事項: (プロキシ設定、認証方式など環境固有の制約)
## 完了ステップ
- [x] Step 1: Dockerのインストールと動作確認
- [x] Step 2: ベースイメージのpull
- [x] Step 3: コンテナ起動設定
- [ ] Step 4: モデルのダウンロード ← 次のアクション
## 試行コマンドとエラーログ
### うまくいかなかったこと
```bash
# エラーになったコマンドとメッセージ
docker run --gpus all ...
# Error: could not select device driver "" with capabilities: [[gpu]]
→ 原因：nvidia-container-toolkitが未インストール
→ 解決策：apt install nvidia-container-toolkit で解消
次のアクション
- Step 4: モデルファイルのダウンロード（約4GB）
- Step 5: APIエンドポイントの確認
未解決のTODO・懸念事項
- メモリ割り当ての上限値が未確認
- 再起動後の自動起動設定がまだ
このテンプレートのポイントは**エラーログを必ず書く**ことです。「何を試してダメだったか」は、再開時に同じ失敗を繰り返さないために最も重要な情報です。環境情報も「次のAIが読んだときに環境前提を0から説明しなくていい状態」を目指して書きます。
# いつ・何を書くか：更新タイミングの3ルール
テンプレートがあっても「書くのを忘れる」が最大の敵です。更新タイミングを3つに絞ります。
### ルール1: ステップ完了時に更新する
完了ステップの `[ ]` を `[x]` に変え、次のアクションを書き換えます。30秒で終わります。
### ルール2: エラー遭遇時に即記録する
エラーメッセージをその場でコピーして「試行コマンドとエラーログ」に貼ります。「後で書こう」は存在しません。エラーを踏んだ瞬間に書く。
### ルール3: セッションを終える前に「次のアクション」を更新する
ここが肝心です。次回セッション開始時のコストがここで決まります。「次に何をするか」が一行でも書いてあれば、AIへの説明は「このmdを読んで続きからやって」の一言で済みます。
#### Before（更新なし）
次のセッションで5〜10分かけて「どこまで進んだか」「環境はどうなっているか」「何が問題だったか」を説明し直す必要があります。
#### After（更新あり）
このファイルを読んで、作業を続きから再開してください。
[作業状況.md の内容をペースト]
これだけで1分以内に再開できます。
# 実際の運用例：ローカルLLM構築での適用
ローカルLLM（Ollama + WebUI）の環境構築を例に、実際にどう記録するかを示します。
Step 6に差し掛かったタイミングでセッションを意図的に終了し、翌日新しいCoworkセッションを開いて以下のように投げました。
以下の作業状況mdを読んで、Step 6から作業を再開してください。
環境情報
- OS: Windows 11
- Docker Desktop 4.x インストール済み・動作確認済み
- WSL2バックエンド使用
完了ステップ
- Step 1〜5: Ollamaコンテナのセットアップ完了
次のアクション
- Step 6: Open WebUIのコンテナ起動とOllamaとの接続確認
AIは即座に「では `docker run` コマンドで Open WebUI を起動するところから始めます」と返し、前のセッションの文脈を完全に引き継いだ状態で作業が再開しました。
ポイントは「全部書かない」ことです。AIが次のアクションを判断できる最小限の情報に絞る。長いほど良いわけではありません。
# さらに活用する：AIへの「リード指示」の定型化
毎回「このmdを読んで」と書くのも手間なので、新セッション冒頭のプロンプトを定型化しておくと便利です。
```text
以下の作業状況mdを読んでください。
内容を把握したら「了解しました。[作業名]のStep [N]から再開します。[次のアクション]を実施します」と返してください。確認できたら作業を開始してください。
---
[mdの内容]
---
「了解しました」と返させることで、AIが内容を正しく読み込めたかを確認できます。いきなり作業を始められると、どこまで把握しているか分からなくて不安になるので、一度確認ステップを挟むのがおすすめです。
まとめ
/compact が使えないことに気づいたとき、最初は「不便だな」と思いました。しかし考えてみると、会話コンテキストに依存することの方が本質的に脆弱です。セッションが切れれば消えるものに、作業の継続性を依存させるのはそもそも設計として怪しい。
mdファイルへの外部化は、単なる /compact の代替ではなく、AIとの作業状態をファイルシステムに永続化する設計です。1ステップあたり1〜2分の追加コストで、セッション再開時の5〜10分を丸ごと消せます。
制約を見つけたときに「どう回避するか」より「どう受け入れるか」を先に考えると、だいたい良い方向に転ぶことが多いです。