結論：compact値ではなくsubagentの責任で決める
Claude Code公式changelog 2.1.296（2026年10月9日）は、subagent frontmatterと--agents定義へautoCompactWindowを追加したと記載しています。公式のsubagentsガイドが示すように、subagentは専門タスクへ分割する仕組みです。したがって、main conversationの全履歴を短くする設定ではなく、担当subagentの文脈を先に整理するための境界として評価します。
向くのは、ログを読み、決められた形式の報告を返す調査・テスト・分類subagentです。仕様の根拠を長く保持するレビューや、あとで同じ判断を再現するsubagentでは、早いcompactが根拠を隠す可能性があります。既存のClaudeのcontext管理は長文全体の整理、本稿はsubagent単位の境界と証跡へ意図を限定します。
設定対象を3つに分ける
| 対象 | compactの役割 | 先に固定するもの |
|---|---|---|
| 調査subagent | 読んだ資料と未解決点を要約 | 引用、出典URL、未確認点 |
| 実装subagent | 変更履歴を圧縮 | Git差分、テスト結果、未変更範囲 |
| レビューsubagent | 指摘候補を整理 | severity、再現手順、対象行 |
| main conversation | 全体判断を保持 | 決定、承認、次の作業 |
値の単位や最小値を推測して固定値として紹介しないでください。2.1.296の導入後に、使用中のClaude Codeが表示するschema、frontmatterの読み込み結果、実際のcompact発生点をreadbackします。設定例を書く場合も、値は自社の代表taskで測ったものとして管理し、公式の推奨値と誤認させないことが重要です。
導入前に行う8手順
- subagentの目的を「何を読んで何を返すか」で一文にします。
- 入力資料、tool、作業ディレクトリ、許可操作を一覧にします。
- compact後も絶対に残す情報を、引用、ID、変更ファイル、失敗理由に分けます。
- main conversationへ返す最小成果物をJSONや見出し付きの形式で決めます。
- 2.1.296以上のversionと、frontmatterまたは
--agents定義の読み込み元を確認します。 - 同一taskをcompact設定なしと設定ありで実行し、結果と根拠の差を保存します。
- 要約後に存在しない事実を作らないか、出典・Git差分・テストログで照合します。
- 合格条件を満たしたsubagentだけへ設定を広げ、rollback用の定義を残します。
最初の試験では、外部送信、削除、push、顧客通知を含めません。読み取り専用の資料とfixtureを使い、compact前後のメッセージ、tool結果、最終成果物を比較します。出力が短くなったことではなく、mainが次の判断に必要な情報を失っていないことを合格条件にします。
compact前後の品質を検証する
確認項目は三層に分けます。第一に事実です。引用、ファイル名、行番号、テスト結果が残っているかを確認します。第二に判断です。未解決、拒否、追加確認が明示されているかを見ます。第三に責任です。subagentの出力をmainがそのまま採用せず、誰が検証したかを記録します。要約が流暢でも、原資料へ戻れない報告は運用上の成功とは扱いません。
subagentがtool結果を大量に受け取る場合は、先に入力を絞る設計も比較します。重複ログを除き、必要な範囲だけ読み、根拠をartifactへ保存する方が、compact境界を早めるより説明しやすいことがあります。contextを節約する変更と、判断材料を削る変更を同じ「最適化」と呼ばないでください。
compactが起きた時刻を監視し、直前の入力と直後の要約をサンプル保存します。これにより、値を変更した時に作業時間が短くなったのか、重要な確認が省略されたのかを区別できます。問題が起きたときは値をさらに下げるのではなく、まず資料の重複、tool結果の保存、成果物の形式を見直します。
値を変更したら、同じ入力だけでなく、短い入力、長い入力、tool結果が多い入力の三つで再測定します。作業が早く終わっても、mainへの報告が欠けた場合は改善ではありません。
チームへ配る前の運用境界
設定を共有する場合は、誰でも値を変更できる状態を避けます。subagentの定義をrepositoryのreview対象にし、変更理由、想定するcontext、比較した実行結果、rollback先を同じpull requestへ残します。個人の環境だけでcompactが発生していると、CIや別OSで再現せず、問題が本番の成果物で初めて見つかることがあります。
また、compactした要約を永続的な業務記録と同一視しないでください。決定や顧客向け根拠は別のartifactへ保存し、subagentの会話は保持期限とアクセス権を決めます。要約後に判断が変わった場合は、元資料へ戻って再実行できる状態を合格条件へ含めます。
企業運用チェックリスト
- 2.1.296以上と設定schemaを実機で確認した
- frontmatterと
--agentsのどちらを正本にするか決めた - compact後に残す引用、ID、差分、失敗理由を定義した
- 設定なし・ありの同一taskを比較した
- 要約後の出典とtool結果をreadbackした
- main conversationが最終判断を保持している
- 外部送信や破壊操作を試験から隔離した
- rollback、再評価日、ownerを記録した
subagentの専門化は、作業を増やすためではなく、境界を説明するために行います。無料診断では、mainとsubagentの責任、入力資料、保存する証跡、compact後の確認者を一枚へ整理できます。無料診断（60秒）で、まず一つの読み取り専用taskを選んでください。
FAQ
- autoCompactWindowは何を短くしますか？
- subagentのfrontmatterまたは
--agents定義に設定し、main conversationより早いcompact境界をsubagentへ指定する機能です。 - 小さく設定すれば品質が上がりますか？
- いいえ。履歴は抑えられても根拠が失われる可能性があるため、成果物と要約を検証します。変更後は短いtaskと長いtaskの両方で確認します。
- subagentのcontext設計を相談できますか？
- できます。目的、入力、成果物、再確認者、停止条件を無料診断（60秒）で整理します。