「Claude Code /compactは、いつ使うべきか？」への答え：2026年9月現在、同じ作業を続けながら会話履歴だけを要約したい時に使います。無関係な作業へ移るなら/clear、会話の一部だけを要約・復元したいなら/rewindです。
- 現在の仕様：
/compactは会話を構造化された要約へ置き換え、プロジェクト直下のCLAUDE.md、自動メモリ、Plan Modeの計画などはディスクから再注入されます。 - 長時間開発の要点：圧縮前に変更ファイル、未完了事項、テスト結果、次の一手を明文化し、圧縮後に
/contextと差分確認で戻りを検査します。 - 最新変更：2026年9月3日公開のv2.1.260では、100万トークン文脈モデルの自動圧縮が改善されました。翌9月4日のv2.1.261では、トークン計数APIが使えない時に
/contextがローカル推定へ切り替わるよう変更されています。
対象読者：Claude Codeを個人利用から、チームの長時間セッション、移行作業、障害対応、レビュー工程へ広げたいエンジニア、テックリード、Platform Engineering担当者。
最初の一手：進行中のセッションで/contextを開き、「何が文脈を使っているか」を確認してから、この記事の5手順を試してください。
この記事は公開仕様を基にした運用構成例です。特定企業での実測成果や、未公開の社内運用実績ではありません。コマンド、保持対象、バージョン条件はAnthropicの公式ドキュメントと公式変更履歴を2026年9月に再確認しています。
/compact・/clear・/rewindを最初に選び分ける
長いセッションで困った時、いきなり/compactを打つのは早計です。先に「今の作業を継続するのか」「別タスクへ切り替えるのか」「履歴の一部だけ扱いたいのか」を決めます。ここを間違えると、圧縮そのものより、不要な前提を持ち越したことが次の失敗になります。
| 状況 | 選ぶ操作 | 残したいもの | 避けたい誤用 |
|---|---|---|---|
| 同じ機能・障害対応を続ける | /compact |
決定、差分、失敗、テスト、次の手順 | 指示なしで圧縮し、重要度を自動判断だけに任せる |
| 無関係なタスクへ移る | /clear |
リポジトリ側の永続ルール | 前の議論を新しい作業へ持ち越す |
| 特定区間を要約・復元する | /rewind |
選んだチェックポイント前後の文脈 | 全履歴をまとめて圧縮する |
| 履歴に残さない横道の質問 | /btw |
主作業の会話履歴 | 小さな疑問で主文脈を増やす |
同じ作業なら/compact
/compactは、会話を終わらせずに履歴を要約して空きを作る操作です。認証バグの原因調査から修正へ進む、API移行の実装から回帰テストへ進む、といった「目的は同じだがフェーズが変わる」場面に合います。
別作業なら/clear
公式ベストプラクティスは、無関係なタスク間で/clearを使うよう案内しています。古い会話やファイル内容が残ると、新しい依頼に必要な文脈を圧迫するからです。戻る可能性があるなら、先に/renameでセッション名を付け、後で/resumeから再開できます。
局所的に扱うなら/rewind
/rewindでは、選んだメッセージから後、または選んだメッセージまでを要約できます。大きな設計判断は残し、途中の調査ログだけ縮める、といった局所制御が必要な時はこちらが向きます。
2026年9月の/compact仕様を公式情報で確認する
検索上位の記事には「残量が何割になったら実行する」といった固定しきい値の説明があります。しかし、Anthropicの公式ドキュメントは、自動圧縮の開始点がモデルと構成によって変わると明記しています。チーム標準を特定の割合へ固定するより、/contextで実セッションを確認し、作業の区切りと合わせて判断する方が現行仕様に沿っています。
文脈には画面に見えない内容も入る
Claude Codeのコンテキストウィンドウには、ユーザーの指示、読み込んだファイル、Claude自身の応答だけでなく、ターミナルに表示されない内容も含まれます。起動時にはCLAUDE.md、自動メモリ、MCPツール名、スキルの説明などが入り、作業中はファイル読込、適用されたルール、フック出力が積み上がります。公式のコンテキストウィンドウ解説は、この流れをタイムラインで示しています（2026年9月参照）。
/compactは会話履歴を構造化要約へ置き換える
/compactは「古い文字列を機械的に切り捨てる」だけの操作ではありません。会話履歴を構造化された要約へ置き換え、起動時コンテンツの多くを再読み込みします。だから、要約に残したい観点を引数で渡せます。
/compact Focus on the authentication bug, changed files, failed tests, and the next verification command上のコマンド形式は公式のコスト管理ガイドが案内する「カスタム圧縮指示」の応用です。新しいセッションなど、要約できる履歴が少ない場合はNot enough messages to compact.と表示されることも公式に記載されています。
v2.1.260とv2.1.261で長時間セッション周辺が更新
公式変更履歴によると、v2.1.260（2026年9月3日）は、100万トークン文脈を持つ対象モデルで上限直前に自動圧縮する挙動と、大きな文脈でのリカバリ圧縮を改善しました。v2.1.261（2026年9月4日）は、トークン計数APIを利用できない場合、/contextが追加の小規模モデル要求ではなくローカル推定を使うよう変更しています。この記事ではこの2版を現行スナップショットとして扱います。
これは「すべての利用者が100万トークンを使える」という意味ではありません。モデル、契約、ゲートウェイ構成で利用可能な文脈長は異なります。公式のコンテキスト解説は、通常の最大値と拡張文脈の可用性を別項目として案内しているため、組織内のモデルIDや契約画面を確認してください。
圧縮後に残る情報と消えやすい情報を地図化する
業務導入で重要なのは「圧縮できるか」より、「何がどの経路で戻るか」を理解することです。公式仕様を運用目線へ置き換えると、次の4分類になります。
そのまま維持されるもの
- システムプロンプトと出力スタイル：会話履歴の一部ではないため、そのまま維持されます。
- プロジェクト直下の
CLAUDE.mdとスコープなしルール：ディスクから再注入されます。 - 自動メモリ：ディスクから再注入されます。
- Plan ModeでClaudeが書いた計画：ディスクから再注入されます。
条件付きで戻るもの
- パス指定ルール：Claudeが対象ファイルを再び読む時に読み込まれます。
- サブディレクトリの
CLAUDE.md：その配下のファイルを読む時に戻ります。 - 読み書きしたファイル：最近変更されたものを優先し、最大5ファイルが再読込されます。
- 5,000トークンを超えるファイル：本文ではなくパス参照として戻ります。ただし適用ルールは再読込されます。
この「最大5ファイル」「5,000トークン」という数値は、Anthropic公式の保持一覧に明記された2026年9月時点の仕様です。大きな移行作業ほど、会話にしか存在しない決定事項を放置しない理由がここにあります。
要約されるもの
過去の会話、以前のフック出力、ファイル読込で入った一時的な説明は、会話履歴と一緒に要約対象になります。圧縮前に「なぜこの案を捨てたのか」「どのテストがまだ落ちるのか」を明示しないと、結果だけ残って理由が薄くなる可能性があります。
スキル本文には再注入上限がある
呼び出したスキル本文は再注入されますが、公式仕様では1スキルあたり5,000トークン、合計25,000トークンが上限で、古いスキルから落ちます。重要事項はスキル冒頭へ置くよう公式も勧めています。チームの長い手順書を1ファイルに詰め込むより、用途別スキルへ分ける方が運用しやすい設計です。
永続指示の整理方法は、既刊のCLAUDE.md設計・運用ガイドも合わせて参照してください。
長時間開発で文脈を守る5手順
ここからは、TypeScriptサービスの認証改修や段階的なライブラリ移行のように、調査・実装・テストが一つのセッションに積み上がる想定シナリオで進めます。数値成果を示す実案件ではなく、公開仕様から組み立てたチーム運用の構成例です。
手順1：/contextで現在地を確認する
最初に/contextを開き、コンテキストを占めるカテゴリ、読み込まれたメモリファイル、最適化候補を確認します。公式ドキュメントは、実際の使用量を見る方法として/contextを案内しています。パーセンテージだけでなく、「なぜ増えたか」を見ます。
/context- 長大な
CLAUDE.mdが常時入っていないか - 今のフェーズで使わないMCPサーバーが残っていないか
- 調査のために読んだ大きなファイルが主文脈へ入っていないか
- 同じ失敗と修正を何度も往復していないか
2026年9月4日公開のv2.1.261以降では、トークン計数APIが利用できない場合もローカル推定へフォールバックします。ただし推定は監視の補助です。重要な変更が保持されたかどうかは、圧縮後のファイルとテストで確かめます。
手順2：会話だけにある決定をリポジトリへ記録する
圧縮前に、会話だけに存在する判断をファイルへ移します。永続的な開発規約はCLAUDE.md、今回だけの進行状況は作業メモやIssue、実装計画へ分けます。なんでもCLAUDE.mdへ入れると起動時の文脈が膨らむため、将来の全セッションで本当に必要かを基準にします。
# Current migration state
- Goal: replace the legacy session store without changing the public API
- Changed: src/session/store.ts, tests/session/store.test.ts
- Rejected: direct schema rewrite because rollback would be difficult
- Failing: timeout case in the integration test
- Next: reproduce with the single timeout test, then review the diff
上は作業メモの構成例です。存在しないファイル名をそのまま使う指示ではありません。Claude Codeへ渡す時は、実リポジトリのパスとテストコマンドに置き換えてください。
手順3：圧縮前の基準点を固定する
要約の前後を比較できるよう、変更状態とテスト状態を固定します。まずClaude Codeへ「確認だけ」を依頼し、編集と検証を混ぜません。
Before compacting, inspect the current repository state without editing files.
Return:
1. modified and untracked files,
2. tests already run and their results,
3. unresolved errors,
4. decisions that exist only in this conversation,
5. the exact next verification command.
If information is missing, ask before proceeding. Mark every assumption explicitly.ここで大切なのは、「全部覚えて」ではなく、圧縮後に照合できる観測点を作ることです。変更ファイル一覧、失敗テスト、未完了事項、次の検証コマンドが揃えば、要約の抜けを発見できます。Gitを使うプロジェクトなら、git statusや差分も人間側で確認します。
手順4：残す観点を指定して/compactを実行する
作業の目的に合う圧縮指示を付けます。自然言語部分は日本語でも構いません。チームでは、保持項目の順序を共通化するとレビューしやすくなります。
/compact 次を優先して保持してください：目的、確定した設計判断、変更ファイル、却下した案と理由、失敗中のテスト、未完了事項、次に実行する検証コマンド。推測は事実と分けてください。公式ガイドは、/compact Focus on code samples and API usageのように焦点を渡せると説明しています。運用では「残す項目」を具体化し、抽象的な「重要なことを残す」だけで終わらせないのがポイントです。
手順5：圧縮後に再確認してから編集を再開する
圧縮が終わったら、すぐ大きな編集へ戻りません。まず/context、作業メモ、リポジトリ状態、対象テストを照合します。
After compaction, do not edit yet.
Re-read the project instructions and the migration state file.
Then report any mismatch among:
- the current goal,
- changed files,
- rejected approaches,
- failing tests,
- next verification command.
If there is no mismatch, propose one smallest next action.確認項目が合わなければ、ファイルに残した正本を優先して修正します。合っていれば、小さな次の一手へ進みます。セッション再開と命名を含めた運用は、Claude Codeセッション再開の実践も参考になります。
業務別に使える/compact指示5選
圧縮指示は、作業の種類によって残すべき証拠が変わります。以下はそのまま貼れる構成例ですが、パスやテスト名は実プロジェクトへ合わせてください。どの例にも「不足情報は先に質問」「仮定は明記」を入れています。
1. バグ修正：再現条件と失敗ログを残す
/compact バグ修正を継続できるよう、再現手順、期待動作、実際の動作、原因候補、却下した原因、変更ファイル、失敗中のテスト、次の検証コマンドを保持してください。不足情報は先に質問し、仮定は明記してください。バグ修正では、採用した解決策だけでなく、再現しなかった条件と却下理由が重要です。そこが薄いと、圧縮後に同じ仮説をもう一度試しやすくなります。
2. リファクタリング：不変条件と境界を残す
/compact リファクタリングの目的、変えてはいけない公開API、不変条件、依存関係、完了済み単位、未着手単位、回帰テスト、ロールバック境界を保持してください。不足情報は先に質問し、仮定は明記してください。リファクタリングは「きれいにする」ではなく、維持すべき外部挙動を先に固定します。圧縮後の会話に不変条件が残っていれば、新しい設計案を評価する軸がぶれにくくなります。
3. 障害対応：時系列と復旧条件を残す
/compact 障害対応を引き継げるよう、検知時刻、観測事実、未確認事項、実行済み操作、各操作の結果、現在の影響範囲、復旧判定、ロールバック手順、次の安全な確認だけを保持してください。推測は事実と分離してください。障害対応では速度が必要ですが、未確認の原因を事実扱いすると二次被害につながります。操作履歴と観測結果を対にして残し、次の担当者が同じ危険な操作を繰り返さない形にします。
4. API移行：互換性と段階移行を残す
/compact API移行の対象バージョン、破壊的変更、互換レイヤー、呼び出し元一覧、移行済み箇所、未移行箇所、契約テスト、段階リリース順、切り戻し条件を保持してください。数字と固有名詞には根拠を添えてください。API移行では、実装差分だけでなく「どの利用者が旧仕様に残っているか」が重要です。公式仕様、契約テスト、切り戻し条件を同時に残すと、圧縮後も移行順序を確認できます。
5. リリース前レビュー：未検証項目を残す
/compact リリース判定に必要な情報として、変更概要、影響範囲、レビュー済み差分、実行済みテストと結果、未実行テスト、既知の制約、監視項目、ロールバック手順、承認待ち事項を保持してください。不足情報は先に質問してください。「テスト済み」という一語ではなく、実行したテストと未実行のテストを分けます。圧縮後に未検証項目が見えれば、リリース判断を会話の雰囲気で進めずに済みます。差分レビューの工程は、Claude Code /diff活用の5手順で整理しています。
/autocompactとstatus lineで監視を仕組みにする
手動の/compactだけに頼ると、気づいた時には重要な議論の途中、ということがあります。Claude Codeには、自動圧縮の窓を設定する/autocompactと、文脈使用率を表示できるstatus lineがあります。ただし、数値だけで機械的に圧縮する運用にはしません。作業の区切り、変更の記録、テストの基準点とセットにします。
/autocompactはv2.1.221以降
公式コマンド一覧では、/autocompact [auto|<tokens>]はClaude Code v2.1.221以降で利用できると記載されています。引数なしなら現在の窓を示すダイアログが開き、autoならモデル向けの既定値へ戻ります。
/autocompact
/autocompact 500k
/autocompact auto500kは公式ドキュメントにある入力例で、すべてのチームへの推奨値ではありません。モデルの文脈長や組織設定によって受け付ける範囲と上書き関係が変わるため、まずダイアログと公式ドキュメントで現行値を確認してください。
status lineには実セッションの使用率を表示する
公式status lineガイドは、標準入力で渡されるJSONからcontext_window.used_percentageを表示する例を掲載しています。次は公式例を読みやすく整えた設定構成です。jqが必要であり、組織の共通設定へ入れる前に検証用ユーザー設定で確認してください。
{
"statusLine": {
"type": "command",
"command": "jq -r '\"[\\(.model.display_name)] \\(.context_window.used_percentage // 0)% context\"'"
}
}status lineスクリプトは、セッション開始時、新しい応答の到着時、/compact完了時、権限モード変更時などに更新されます。使用率が上がったことを「今すぐ圧縮」の命令にせず、「作業メモを更新して区切れるか」を判断する合図にします。
/usageと/contextは目的が違う
/usageは利用量や上限の状況、/contextは現在の文脈内訳を見るために使います。利用上限への対処は、既刊のClaude Code利用上限の対処法で詳しく扱っています。コスト、レート制限、文脈の混雑を一つの指標として混同しないでください。
チーム導入では「圧縮の前後」をレビュー対象にする
個人利用では、圧縮後に違和感があれば自分で補足できます。チーム利用では、別の開発者が再開したり、同じリポジトリで複数セッションが並行したりします。そのため、コマンドの使い方だけでなく、圧縮前後に残す成果物と確認責任を決めます。
プロジェクト正本とセッションメモを分ける
| 情報 | 置き場所の例 | 更新タイミング | 圧縮後の扱い |
|---|---|---|---|
| ビルド・テスト・命名規約 | プロジェクト直下のCLAUDE.md |
規約変更時 | 再注入される |
| ファイル種別固有のルール | .claude/rules/ |
対象領域の変更時 | 対象ファイル読込時に再適用 |
| 今回の進行状況 | Issue、計画、作業メモ | 区切りごと | 明示的に再読込する |
| 個人の一時的な好み | ユーザー設定またはローカルメモ | 本人が必要な時 | 共有正本へ混ぜない |
公式のメモリガイドは、プロジェクト直下のCLAUDE.mdが/compact後に再読込される一方、会話だけの指示、まだ再読込されていないサブディレクトリのCLAUDE.md、条件に一致していないパス指定ルールは見失ったように見える場合があると説明しています。圧縮を記憶装置として扱わず、正本の配置を先に設計します。
Pull Requestへ残すのは圧縮結果ではなく検証可能な状態
圧縮要約をそのままPull Request本文へ貼る必要はありません。レビューに必要なのは、目的、変更範囲、テスト結果、未検証事項、ロールバック方法です。要約はその材料であり、最終成果物ではありません。
- 変更ファイルと公開APIへの影響が一致している
- 実行したテストと未実行テストが区別されている
- 却下案のうち、将来また検討しそうなものに理由がある
- 設定変更には戻し方がある
- 会話内の推測が、確定事項として転記されていない
並行セッションでは担当境界を先に宣言する
複数セッションが同じファイルを編集すると、文脈圧縮以前に競合が起きます。担当ディレクトリ、変更禁止領域、統合担当、完了条件を作業メモへ置き、各セッションの圧縮指示にも含めます。Claude Codeのチーム展開全体は、Claude Codeチーム導入ロードマップで整理しています。
ロールバックは設定値と会話の両方を戻せる形にする
/autocompactを試す場合は、元の設定へ戻す/autocompact autoを変更票に添えます。status lineを共有する場合も、設定ファイルの差分と削除方法を残します。会話については、必要なら/rewindや別セッションへの/resumeを使い分けます。コード復元の詳細は、Claude Code rewindとチェックポイントを参照してください。
よくある失敗パターンと回避策
失敗1：固定の使用率を全モデルへ強制する
❌「全員、同じ割合になったら必ず/compactする」
⭕「/contextで実セッションを確認し、作業の区切り、モデル、設定、保持すべき成果物を合わせて判断する」
自動圧縮の開始点はモデルと構成に依存すると公式が説明しています。検索記事の経験則を組織ポリシーへそのまま転記しません。
失敗2：「重要なことを残して」だけで実行する
❌「いい感じに圧縮して、重要なことを残して」
⭕「目的、確定判断、変更ファイル、却下理由、失敗テスト、未完了事項、次の検証コマンドを残す」
重要度の基準を列挙すると、圧縮後に確認しやすくなります。プロジェクトごとに項目を追加して構いません。
失敗3：CLAUDE.mdをセッション日記にする
❌ 毎回の調査ログ、長いAPI仕様、今回だけのタスクをプロジェクト直下へ追記する
⭕ 将来の全セッションで必要な規約だけをCLAUDE.mdへ置き、進行状況はIssueや作業メモへ分ける
公式ベストプラクティスも、削除しても間違いにつながらない説明は削るよう勧めています。永続指示を増やしすぎると、圧縮前から文脈を使います。
失敗4：圧縮直後に大規模編集を再開する
❌ 要約を読まず、前の続きを一気に変更する
⭕ /context、作業メモ、Git差分、対象テストを照合し、一つの小さな操作から再開する
圧縮は検証の代替ではありません。正直に言うと、要約に何が残るかは会話の内容と指示に左右されます。だからこそ、圧縮後の再確認までを標準手順に含めます。
導入前後で確認する運用チェックリスト
チームへ展開する前に、次の項目をPull Requestテンプレートや開発標準へ落とします。ツールの設定だけでなく、圧縮前の正本化と圧縮後の検証まで含めるのがポイントです。
圧縮前の確認
- 同じ目的の作業を続けるのか、別タスクへ移るのかを決めた
/contextで現在の内訳を確認した- 会話だけにある確定判断を作業メモへ移した
- 変更ファイル、未追跡ファイル、未完了事項を一覧化した
- 実行済みテストと未実行テストを区別した
- 却下した案に、再検討を防ぐだけの理由を残した
- 次に実行する最小の検証コマンドを決めた
圧縮指示の確認
- 「重要なこと」のような曖昧語だけで終わっていない
- 目的、判断、差分、失敗、未完了、次の一手を指定した
- 観測事実と推測を分けるよう明記した
- 対象が障害・移行・リリースなら、ロールバック条件を含めた
- 機密値や個人情報を圧縮指示へ貼っていない
圧縮後の確認
- プロジェクト直下の
CLAUDE.mdが読み込まれている - 作業メモの目的と現在の要約が一致している
- Git差分と「変更済みファイル」の説明が一致している
- 失敗テストを再現できる、または解消を証明する結果がある
- 未検証項目が「完了」に変わっていない
- 次の操作が小さく、結果を確認できる
このチェックリストは「圧縮の成功率」を測った実測結果ではありません。Anthropicの保持仕様と一般的なソフトウェア変更管理から組み立てた運用構成例です。自社のレビュー規程、機密区分、インシデント手順に合わせて調整してください。
Claude Code compactのよくある質問
Claude Codeの/compactとは何ですか？
長くなった会話履歴を構造化された要約へ置き換え、同じセッションを続けやすくするコマンドです。プロジェクト直下のCLAUDE.mdや自動メモリなどは再注入されますが、会話内だけの細かな判断は要約対象です。残したい観点を引数で指定できます。
Claude Codeのコンテキスト容量と上限は？
モデルと利用構成で異なります。公式status line仕様は、標準的な文脈長を20万トークン、拡張文脈対応モデルを100万トークンとしてフィールドを説明しています。一方、利用可能なモデル、プラン、ゲートウェイ設定によって実際の上限は変わります。自分のセッションでは/contextとモデル設定を確認してください（2026年9月参照）。
/compactはどのタイミングで使いますか？
同じ目的の作業を続ける中で、調査から実装、実装から回帰テストのようにフェーズが区切れる時が候補です。公式は自動圧縮の開始点がモデルと構成に依存するとしており、すべての環境に共通する固定割合は示していません。/context、作業の区切り、正本化の完了を合わせて判断します。
/compactと/clearの違いは？
/compactは会話を要約して同じ作業を続けるための操作です。/clearは無関係なタスクへ移る時に、会話文脈を新しくします。後で戻るなら先に/renameし、/resumeで再開できるようにしておくと整理しやすくなります。
自動compactは設定できますか？
はい。公式コマンド一覧では、v2.1.221以降に/autocompactで自動圧縮の窓を確認・設定できるとされています。/autocompact autoでモデル向けの既定値へ戻せます。組織の管理設定やモデル構成による上書き関係は、現行ドキュメントを確認してください。
compact後にCLAUDE.mdの指示は消えますか？
プロジェクト直下のCLAUDE.mdはディスクから再読込されます。サブディレクトリのCLAUDE.mdやパス指定ルールは、適用対象のファイルを読む時に戻ります。会話だけで伝えた指示は要約対象なので、永続させる必要がある規約は適切な正本へ移してください。
compactすれば回答品質は必ず戻りますか？
保証はできません。圧縮は文脈量を整理する機能であり、要件の曖昧さ、壊れたテスト、誤った前提、同時編集の競合を解決するものではありません。圧縮前に状態を記録し、圧縮後に差分とテストを再確認して初めて、作業を安全に再開できます。
参考・出典
- Explore the context window — Anthropic Claude Code Docs（保持対象、再読込、
/autocompact、/context。2026年9月参照） - Claude Code changelog — Anthropic Claude Code Docs（v2.1.260、v2.1.261。2026年9月参照）
- Manage costs effectively — Anthropic Claude Code Docs（カスタム圧縮指示、
/clear、/context。2026年9月参照） - Best practices for Claude Code — Anthropic Claude Code Docs（文脈管理、
/rewind、/btw。2026年9月参照） - How Claude remembers your project — Anthropic Claude Code Docs（
CLAUDE.mdと圧縮後の再読込。2026年9月参照） - Commands — Anthropic Claude Code Docs（
/autocompactの書式とバージョン条件。2026年9月参照） - Customize your status line — Anthropic Claude Code Docs（文脈使用率フィールドと更新条件。2026年9月参照）
結論と次の一歩
/compactは、長い会話を短くするだけのコマンドではありません。圧縮前に検証可能な状態を作り、保持項目を指定し、圧縮後に正本・差分・テストを照合する工程です。同じ作業なら/compact、別タスクなら/clear、一部だけ扱うなら/rewindと分けてください。
- 今日：一つの進行中セッションで
/contextを開き、文脈の内訳を確認する。 - 今週：変更ファイル、失敗テスト、未完了事項、次の検証を残す圧縮前チェックをPull Requestテンプレートへ追加する。
- 今月：小さな対象チームでstatus lineと
/autocompactを試し、元へ戻す手順まで変更票に残す。
あわせて読みたい：
- CLAUDE.md設計・運用ガイド — 圧縮後も残したいプロジェクト規約の置き方
- Claude Codeセッション再開の実践 — 名前を付けて後から戻る運用
- Claude Code rewindとチェックポイント — 履歴の一部だけを扱う方法
- Claude Code /diff活用の5手順 — 圧縮後の変更確認をレビュー工程につなげる
- Claude Codeチーム導入ロードマップ — 個人運用からチーム標準へ広げる
次回予告：次の記事では、/contextの内訳を使って、CLAUDE.md、MCP、スキル、フックの常駐コストを棚卸しする手順を扱います。
Claude Codeの個別指導やチーム導入設計について確認したい点があれば、Uravationへのお問い合わせから相談内容をお送りください。まず現在のリポジトリ構成と運用境界を整理するところから対応します。
