コーディングエージェントのauto-compactの仕組みを読み解く - タスク引継ぎの再現性を高める方法
Claude Code, Codex, Cursor, GitHub Copilot, Cline...などコーディングエージェントはたくさんありますが、全てに共通する問題といえば「AIモデルのコンテキストウィンドウ制限」です。
Claude Opus 4.1が200k、GPT-5が400k、そしてGemini 2.5 Proが1Mとモデルにより異なります。
コーディングでは扱うファイルやコード数が非常に多く、平気でコンテキストウィンドウ以上のトークン数を必要とします。各コーディングエージェントは、コンテキストウィンドウ制限が起こっても快適なコーディング作業を継続するための仕組みとして「auto-compact（自動要約機能）」を提供しています。
ただ、auto-compactを使うと作業途中のタイミングで起動したりして、うまく前の作業を引き継いでくれないことが多いこと多いこと！
そこで実際に各コーディングエージェントがどのような仕組みでauto-compactをしているのか、特にその要約の指示を見ていきつつ、タスクを正しく引き継いでもらえる方法を考えていきます！
auto-compact機能の大まかな仕組み
auto-compactでやっていることは本当に単純で、一定の累積トークン数が閾値を超えた時点で、それまでのチャット履歴（ユーザーメッセージ、AIの応答、ツール出力）を要約して、それを差し替えるだけです。
-
残コンテキストの監視: メッセージ送信前にセッション開始から直近までの会話履歴 + 入力のトークン数を算出。閾値を超えそうなら
/compactを起動する - 要約実行: セッション開始から直近までの全会話履歴を入力にし、要約方針を示すプロンプト（圧縮テンプレ）を添えてモデル実行。
- 要約結果を取得: 生成された要約結果を取得
- 会話履歴の差し替え: 会話履歴を要約結果に差し替え
- 再開: 中断した箇所からそのまま再開
これまで全ての会話履歴を参照できていたのが、要約されることでコンテキスト損失が起こり作業をうまく引き継げなくなる可能性が高いです。
重要なのが、「タスクをミスなく引き継ぐために要約で残すべきコンテキストが何か」ということです。
そこで、それぞれのコーディングエージェントの要約の指示がどうなっているのか見ていきます。
確認が可能なCodex, Gemini CLI, Clineの3つの要約のプロンプトを取り上げます。
(Claude CodeとかCursorも知りたいですが公開されていないので残念...)
各コーディングエージェントの要約プロンプト
※ auto-compactの要約以外は細かい違いはあれど、基本的に似てますので触れません。
Codex
Codex v0.40.0でもauto-compactが導入されました。GPT-5-Codexの場合、250k/350k?のトークン数に達した時点でauto-compactが発火します。
要約の方向性は次のエージェントへの引き継ぎメモだけを短く作ること！
必要最小限に抑え、すぐに実務に取り掛かれるものになっていますが、詳細がズレる可能性もありそうです。
要約される項目:
- 完了した作業・未完の作業
- 残TODO
- 追加でテストが必要な箇所
- 既知のバグ・クセ・注意事項
要約されたメッセージはユーザーメッセージとして差し替えられます。
Gemini CLI
会話履歴を唯一の長期メモリとし、今後の作業は要約内容のみを前提に再開されることを想定してプロンプトが設計されています。セッション継続後の再現性を確保することができ、良さげですがちょい大味です！
要約される項目:
- overall_goal: 高レベル目標
- key_knowledge: 重要な事実・制約の箇条書き
- file_system_state: 作成/変更/削除/読み込みファイルのログ
- recent_actions: 直近の行動ログ
- current_plan: DONE/IN PROGRESS/TODO を含む手順
ちなみにですが、要約した指示をシステムメッセージに差し込みます（なぜ？？）
Cline
Clineの要約時の指示は個人的に参考になりそうと感じています！
開発継続に必要な作業コンテキストを"時系列重視"で洗い出し、それを要約します。
直近の内容とプロジェクト全体の状態の変化のコンテキストのバランスが取れているなと感じていて、指示の再現性が高く、とても好みです！
要約される項目:
- Primary Request and Intent: ユーザーの明示的意図
- Key Technical Concepts: 重要技術・用語・フレームワーク
- Files and Code Sections: 参照/変更したファイル・コード片・理由
- Problem Solving: 解決済み課題・トラブルシュート
- Pending Tasks: 未了タスク
- Current Work: 直前に取り組んでいた作業の詳細
- Optional Next Step: 直前作業に直結する次の一手
- Most Recent User Intent: 直近メッセージに基づく最新意図
要約プロンプトの内容比較 by ChatGPT
それぞれの要約プロンプトをChatGPTにまとめてもらいました。
同じauto-compactでもコーディングエージェントでかなり異なる指示で実施されており、かなり興味深いです。
| 観点 | Gemini CLI | Cline | Codex |
|---|---|---|---|
| 要約の方向性 | 唯一の長期メモリ用スナップショット | 現在地の全体把握＋直近の次アクション | 強制停止時の引継ぎ（最小限） |
| 出力 | 厳密なXML（固定） | 8セクション要約 | 自由形式のメモ |
| 対象範囲 | 全履歴を凝縮（不変情報中心） | 時系列で詳細（要求/決定/コード） | 直前作業が中心 |
| 粒度 | 知識・ファイル状態・計画を高密度 | ファイル名/コード片/決定事項を具体 | TODO・path/line・既知問題を実務特化 |
(Claude Code)
- Claude Codeは公開されていないので、何が行われているかわかりません
-
/compact <message>の<message>部分を適切に書けばなんとかなるよ！
ここまで見てきましたが、以下の内容が要約された出力に含まれるとうまくタスクを引き継げるのではと考えています！
- 全体のゴール
- 全体の考慮事項
- 現在の状態
- 直近の作業内容
- 次のアクション
これらを踏まえてauto-compactなしでも楽に次のセッションに作業を引き継ぐためにどうしていくべきか！
auto-compactに依存しないための解決策！
達成したいことは、「タスクをミスなく引き継ぐために要約で残すべきコンテキストが何か」です。
つまり、コンテキスト損失を減らしつつ、auto-compactを使わず適切なタイミングでセッションを切り替えることができればOK！
0. auto-compactを無効にする
auto-compactは使わずに、適切なタイミングでセッションを切り替えましょう！
Claude Codeでは/configコマンドでauto-compactを無効にすることができます。
その他は分かりませんが、もし知らせていただければと思います！
1. 要件と実装計画をドキュメント化しておく
そもそも論ですが、大事な要件や作業計画をコーディングエージェントのコンテキストウィンドウに留めておくのは、危ない危ない！しっかり齟齬が出ないようにドキュメント化しておくと、セッションを切り替えようがコーディングエージェントを変えようが全く問題ありません！
Kiroから始まった仕様駆動開発(Spec-Driven Development)などはまさにauto-compactに対抗するための最高の相棒です！
私が開発した仕様駆動開発ツールも使ってね！（ステマじゃないよw）
2. 引き継ぎ書を作成するオレオレ Commands を作成する
Vibe Codingしている際、ドキュメント化するのってめんどくさいことも多いです。そういう際に、自作のオレオレcommandsを作成して、「次のタスク実施」に必要なコンテキストをまとめてくれる引継書を作成してくれるCustom Commandsが便利です！
Custom Commandsで作成された引き継ぎ書を新規セッションに貼り付けるだけで作業が引き継がれます！auto-compactと違い、好きなタイミングでセッションを切り替えることができるので、より柔軟な作業が可能となりました！
私自身、残りトークン数が50%を切った段階から、キリの良いタイミングでセッションを切り替えることを意識しながら作業を進めています。
下記のようなcommandsをClaude CodeのCustom Slash Commands, CodexのCustom Promptsとして保存して使っているので、もしよかったら自分好みに改変して使ってみてください！Clineの要約プロンプトを参考に直近の作業内容をより反映させやすくし、自らの開発プロセスに合わせて改変した感じです。もちろんClineなどのものをそのままお借りしても良いと思います！
handoff.md:
You are producing a **minimal, agent-friendly handoff note** ("引き継ぎ書") for continuing the current coding task in a new session.
## Output contract
- **Format:** GitHub-Flavored **Markdown only**（日本語本文）。No meta commentary.
- **Deterministic structure:** Use the exact section order and headings below.
- **Keep it short:** 箇条書きで、各項目は1–3行、**次にやることは最大5個**。
- **No environment/setup instructions.** 「何を」「どこで」「どう完了判定するか」に集中。
- **空欄の扱い:** 不明な項目は `-` を入れ、**§8 未解決**に短く記載。
- **状態表示:** 現在の状態には 🟢（動作中）🟡（作業中）🔴（エラー）を使用
## Light auto-collection (best effort; if tools unavailable, infer)
- Git snapshot: branch, short SHA, last commit subject, changed files（ファイル名のみ）
- Recent focus: 直近で編集/閲覧していた主要ファイル/関数
- Quick check targets: 期待出力のファイル/関数/テスト名（コマンドは書かない）
## Produce exactly this Markdown (fixed schema)
---
title: 引き継ぎ書
version: 1.2
branch: {branch}
sha: {short_sha}
focus_file: {primary_file_or_dir}
---
# 引き継ぎ書
## 1. ゴール（DoD：達成条件を1–2行）
- …
## 2. タスク要約（1–3行）
- …
## 3. 検証方法（合否基準・期待出力／観点 1–3行）
- 例：`{path/to/artifact}` が生成され、関数 `{fn}` は `{expected}` を返す 等
- …
## 4. 現在の状態（3–5行、状態インジケーター付き）
- 🟢 {完了済み機能}: {動作確認済み内容}
- 🟡 {作業中機能}: {現在の作業内容}
- 🔴 {エラー/未着手}: {問題内容}
## 5. 変更ファイル（直近）
| Path | Note |
|---|---|
| … | … |
## 6. 次にやること（各1行、必要なら成功条件/フォールバックを括弧書き）
- [ ] …（成功条件：…／詰まったら：…）
- [ ] …
- [ ] …
- [ ] …
- [ ] …
## 7. スコープ外（今回はやらない）
- …
## 8. 未解決 / リスク（各1行で要点）
- …
## 8.5. 失敗した試み（時間の無駄を防ぐ）
- ❌ {アプローチ}: {失敗理由}
## 9. 決定事項（今回増分のみ）
- …
## 10. 参照（再オープン用パス/Issue/PR）
- `src/...`
- Issue/PR: …
## 11. 再開カーソル（ファイル:行番号/関数名）
- `path/to/file.ts:123`（関数 `foo` の直前）
今のところ良い感じに動いてくれてます🎵
まとめ
今回調査してみて、auto-compactの要約がコーディングエージェントごとにここまで違うとは正直予想していませんでした！面白い！
コーディングエージェントを使っていると、セッションを引き継ぐことはあると思いますが、auto-compactは使わずに、自作の引き継ぎ書コマンド作ってみてください！
そして良さげに動くものできたら共有してほしいですー！
X(@gota_bara)もやってますので、是非フォローしてください！
そして仕様駆動開発ツールcc-sddも是非使ってみてください！
Discussion