Claude Codeの/compactコマンド活用法｜コンテキスト管理で長時間作業の品質を維持する

Claude Codeの品質低下は、能力の問題ではなくコンテキストの設計問題です。/compactを「使う人の勘」ではなく「チームの仕組み」に落とすと、長時間作業でも出力が安定します。

「セッション前半では的確に動いていたのに、後半になると急に精度が落ちる」「大規模なリファクタリングの途中から、最初に指示した前提を忘れ始める」「同じツールを使っているのに、メンバーによって出力品質がまるで違う」——Claude Codeを日常的に使い始めた組織で、共通して聞かれる声です。

/compactとは、Claude Codeの会話履歴を要約・圧縮して、コンテキストウィンドウの空き容量を回復するコマンドです。単なるリセットではなく、「何を残すか」をフォーカス指示として渡せる点が特徴で、ここを設計できるかどうかが長時間作業の品質を左右します。

本記事では、/compactの仕組みと/contextとの違い、実務での圧縮パターン、70-80%を目安にした実行タイミングと自動コンパクト設定、そして個人の勘に依存せずチームで再現するための仕組み化までを解説します。

この記事でわかること

Claude Codeで長時間作業すると回答品質が低下する原因と、その解決策を具体的に解説します。/compactを使いこなすことで、セッションの途中で精度が落ちる問題を、属人的な工夫ではなく運用ルールとして解消できます。

• /compactの仕組みとコンテキストウィンドウの影響 — 会話履歴を要約・圧縮して空き容量を回復する仕組みと、なぜ上限に近づくと品質が落ちるのかを整理します。
• 実務での5つの圧縮パターン — 大規模リファクタリング、デバッグ、タスク切り替え、ドキュメント生成、日次の引き継ぎという実務シーンごとに、Before/Afterで書き分けます。
• 70-80%を目安にした実行タイミングと自動コンパクト設定 — 使用率ごとの推奨アクションと、自動・手動のハイブリッド運用の考え方をまとめます。
• フォーカス指示のテンプレートとチームでの仕組み化 — 「残すものを明示する」書き方を型にし、リポジトリで共有するフォーカス指示集とCLAUDE.mdで、新しいメンバーでも同じ品質を出せる状態にします。
• compactが向かないケース — 圧縮で解決しない問題と、セッションを切り替えるべき判断基準も率直に書いています。

Claude Codeで長時間セッションを回しているエンジニア、そしてAIツールの活用をチームに広げたいマネージャーの方に向けて、コンテキストが尽きる仕組みから、圧縮タイミングの判断基準、チームでの仕組み化までを解説しています。最後まで読むと、自分の作業だけでなく、チーム全体で長時間作業の品質を安定させる運用ルールを設計できるようになります。

Claude Codeの品質低下はコンテキストの「置き場所」問題

まず押さえておきたいのは、セッション後半の精度低下が、AIの能力ではなく「情報の置き場所」の設計に起因しているという点です。ここを誤解したまま「Claude Codeは長い作業に向かない」と結論づけてしまうと、本来得られる効果を取りこぼしてしまいます。この節では、なぜ品質が落ちるのかという仕組みから整理します。

コンテキストウィンドウという上限がある

LLMにはコンテキストウィンドウという、処理可能なテキスト量の上限があります。Claude Codeでの作業が長くなるほど、ファイルの読み込み結果、コマンドの実行ログ、過去のやり取りが蓄積され、この上限に近づいていきます。

上限に近づくと、Claude Codeは自動でコンテキストを整理します。公式ドキュメントによれば、まず古いツール出力（ファイルの読み込み結果やコマンドの実行ログ）を取り除き、それでも足りなければ会話を要約します。ユーザーの依頼と主要なコードは保持されますが、会話の早い段階で伝えた詳細な指示は失われることがあります。セッションの最初に丁寧に伝えた「このプロジェクトでは型定義を共通化する」といった前提条件も、この対象になりうるということです。後半で急に指示を忘れたように見えるのは、実際に前提が要約から落ちている場合があるからです。

「作業ログ」と「判断材料」は価値が違う

コンテキストに溜まる情報は、すべてが同じ価値を持つわけではありません。ここを分けて考えられるかどうかが、/compactを使いこなす分岐点になります。

作業ログは量が多いわりに後半では使いません。一方で判断材料と前提条件は、量が少ないのに失われると影響が大きい情報です。自動の整理は、何が判断材料かを人の意図まで汲んで区別できるわけではありません。会話の要約に回った段階で、量の少ない前提条件が落ちてしまうことが起こります。何を残すかを自分で伝える手段が、後述のフォーカス指示とCLAUDE.mdの「Compact Instructions」です。

Excel管理と同じ構造の問題

この構造は、Excelやスプレッドシートで案件情報を管理している状態とよく似ています。シートの行がどんどん増えて、どこに何が書いてあるのかわからなくなり、結局その場の記憶を頼りに探す——という状態です。

解決策も似ています。情報を漫然と1か所に積み上げるのではなく、「常に参照すべき前提」「今のタスクに必要な情報」「済んだ作業の記録」を置き場所ごとに分けることです。Claude Codeでいえば、前提条件はCLAUDE.mdへ、今のタスクの判断材料はコンテキストへ、済んだ作業ログは/compactで要約へ、という振り分けになります。

/compactと/contextの基本的な使い方

/compactは圧縮する手、/contextは現状を測る手です。ここでは、引数なしとフォーカス指示付きでの実行の違い、/contextで使用率を確認してから圧縮する順序までを、具体的なコマンド例で見ていきます。

シンプルな実行とフォーカス指示付きの実行

引数なしで実行すると、Claude Codeが会話全体を分析し、重要な情報を残しつつ不要な部分を自動的に圧縮します。

/compact

引数として「何を残すべきか」を指定すると、その領域の情報を優先的に保持した状態で圧縮が行われます。これは/compactの実用的な使い方の一つです。

/compact 認証機能の実装に関する内容を重点的に残してください

同じコマンドでも、この一行があるかないかで圧縮後の使い勝手は大きく変わります。引数なしの実行は「とりあえず容量を空ける」操作、フォーカス指示付きの実行は「次の作業のために情報を整える」操作だと捉えていただくといいかと思います。

/compactと/contextの役割の違い

2つのコマンドは目的が異なります。

/contextを実行すると、現在のコンテキストウィンドウの使用率がパーセンテージで表示されます。この数値を見て/compactの実行タイミングを判断する、という流れが基本になります。

/context

以下の画面は、本記事で扱う/compactと/contextをターミナルで実行する際の入力イメージです。バージョン確認のコマンド出力を先頭に置き、その下に2つのスラッシュコマンドを並べています。

測ってから圧縮する、という順序を守る

実務で崩れやすいのが、この順序です。体感で「そろそろ重いかな」と思ったときに/compactを打つ運用にしてしまうと、圧縮しすぎて直前の作業文脈まで失ったり、逆に手遅れになってから慌てて実行したりということが起きます。

数値で判断する習慣をつけると、この揺らぎがなくなります。特に1,000行を超えるソースコードや長いログ出力を読み込む前には、/contextで空き容量を確認してから読み込むようにすると、読み込み直後に自動の整理が走って、直前の作業の経緯が要約されてしまう事態を減らせます。

実務での圧縮パターン5選

/compactの価値は、フォーカス指示を実務の場面に合わせて書き分けられるかどうかで決まります。この節では、開発現場で頻出する5つのシーンについて、圧縮なしの状態と圧縮後の違いを具体的に見ていきます。自社の開発スタイルに合わせて、指示文を調整していただければと思います。

パターン1・2：大規模リファクタリングとデバッグ

大規模なリファクタリングでは、複数のファイルを順番に修正していきます。前半で修正したファイルの詳細なdiff情報は、後半の作業にはほとんど不要です。

圧縮しない場合、セッション前半でsrc/components/配下の20ファイルを修正したあと、後半でsrc/hooks/の修正に入ると、前半のdiff情報がコンテキストを圧迫し、型定義の整合性チェックが不正確になります。そこで次のように指示します。

/compact hooks/ディレクトリの修正に集中します。componentsで変更した型定義の一覧だけ残してください

前半の詳細なdiffは要約に圧縮されつつ、後半の作業に必要な型定義の情報だけが正確に残ります。結果として、hooks/の修正でも型の整合性を維持したコードが生成されます。

デバッグも同じ構造です。試行錯誤が続くと、失敗したアプローチのログが大量に蓄積されます。エラーの原因を探るために5つのアプローチを試したとして、失敗した4つのログがコンテキストを埋め尽くすと、6つ目のアプローチで過去の成功パターンを参照できなくなります。

/compact 判明した事実と未検証の仮説だけ残してください。失敗したアプローチの詳細ログは不要です

「何がわかったか」「何がまだわからないか」だけが残り、次のデバッグステップに集中できます。デバッグは本来、事実と仮説を整理していく作業ですから、圧縮の指示自体がデバッグの思考整理にもなるという副次的な効果もあります。

パターン3・4：タスク切り替えとドキュメント生成

1つのセッションで複数のタスクを切り替える場合、前のタスクの情報が次のタスクの作業を妨げることがあります。API設計のタスクを終えてテストコード作成に移行したとき、API設計時に読み込んだOpenAPI仕様書の全文がコンテキストに残り、テストフレームワークの設定情報を読み込む余地がなくなる、といったケースです。

/compact APIのエンドポイント一覧とレスポンス型だけ残してください。テストコードの作成に移ります

テスト作成に必要な最小限のAPI情報だけが残り、テストフレームワークの設定やモックライブラリのドキュメントを新たに読み込む余裕が生まれます。

ドキュメント生成も似た課題を抱えます。コードベースを分析してドキュメントを作る作業では、ソースコードの読み込みだけでコンテキストが埋まりがちです。20ファイルのソースコードを読み込んでAPI仕様書を作成しようとすると、ソースコードの全文がコンテキストを占有し、ドキュメントの構成を考える余地がなくなります。

/compact 各ファイルの公開関数のシグネチャと、JSDocコメントの内容だけ残してください

ドキュメント生成に必要な関数シグネチャとコメントだけが残り、構成の検討や文章の推敲に十分な容量が確保されます。

パターン5：日次セッションの引き継ぎ

複数日にわたるプロジェクトで、前日の成果を引き継いで作業を再開する場面での使い方です。その日の作業を終える前に、次のような圧縮を行います。

作業を終える前:

/compact 今日の作業で完了したタスク、未完了のタスク、明日着手すべき箇所をまとめてください

保存された会話は、claude --continue（直近の会話）やclaude --resume（一覧から選択）で再開できます。再開すると同じセッションIDのまま、圧縮後の要約を含む会話の続きから作業できます。一方、新しいセッションを開始した場合は前日の会話が自動では引き継がれないため、完了・未完了タスクと次の着手点をCLAUDE.mdやメモリに書き出しておくと、セッションをまたいだ引き継ぎが可能になります。

このパターンは、個人の作業効率という以上に引き継ぎの仕組みとして効いてきます。休暇や担当変更で別のメンバーが作業を引き継ぐとき、「どこまで終わっていて、次に何をすべきか」が要約として残っていれば、口頭での引き継ぎに頼らずに再開できます。Claude Codeによる経営データの可視化やコンテンツマーケティングの支援といった継続的な業務でも、同じ考え方が応用できると考えています。

5つのパターンの整理

こうして並べると、共通しているのは「一覧・方針・状態は残し、本文とログは捨てる」という判断軸だとわかります。この軸さえ掴んでおけば、ここに挙げていない場面でも自分で指示文を組み立てられるようになります。

70-80%ルール：実行タイミングの設計

/compactは早すぎても遅すぎても効果が下がります。この節では、/contextで確認できる使用率を基準に、どの段階で何をするかを整理します。数値を基準にすることで、判断がその日の気分や経験値に左右されなくなります。

使用率ごとの推奨アクション

この表の区切りは、公式の仕様ではなく、本記事が実務の経験から置いた運用上の目安です。自動compactが走る位置は固定の割合ではなく、モデルや設定によって変わります。公式ドキュメントでは、200Kのコンテキストウィンドウのモデルは200Kの境界で、1Mウィンドウのモデルは既定で約967Kトークンで自動compactすると説明されており、autoCompactWindowや/autocompactで変更もできます。したがって「何%で自動圧縮が発動する」と固定の数字では言えず、自分の環境の発動位置は設定とモデルで確かめる必要があります。

そのうえで、70-80%の段階で自分からcompactを実行するのが、効果的なタイミングの一つと考えられます。この段階ならフォーカス指示を丁寧に書く余裕があり、残すべき情報をコントロールしやすくなります。

なぜ早すぎても遅すぎてもいけないのか

早すぎる圧縮の問題は、直前の作業文脈まで要約されてしまう点にあります。50%前後で頻繁に/compactを打つと、いま進めているタスクの細かい経緯が失われ、同じ説明を繰り返す羽目になります。

遅すぎる圧縮の問題は、タイミングを自分で選べなくなる点です。使用率が上限近くまで進むと自動コンパクトが発動します。自動の場合はその都度のフォーカス指示を渡せないため、CLAUDE.mdに「Compact Instructions」を書いていなければ、残しておきたかった情報まで要約に回ってしまう可能性があります。また、コンテキストが埋まるにつれて前半の指示が参照されにくくなることがあるため、上限近くで生成されたコードは後から見直しが必要になることもあります。

作業の区切りと数値を組み合わせる

数値だけでなく、作業の区切りと組み合わせると判断がさらに安定します。目安として、大きなファイルの読み込みを3-5回行った後、またはデバッグの試行錯誤を5回以上繰り返した後は、使用率を確認するタイミングだと考えていただくといいかと思います。

理想は「タスクの節目で、かつ使用率が70-80%に入っている」ときに圧縮することです。節目で圧縮すれば、捨てても困らない情報と次に必要な情報の線引きが明確になり、フォーカス指示も書きやすくなります。

自動コンパクトとのハイブリッド運用

ここまで手動の/compactを中心に説明してきましたが、Claude Codeには自動でコンパクトを実行する設定もあります。どちらか一方を選ぶのではなく、役割を分けて併用するのが実務的な答えになります。

settings.jsonでの設定

2026年10月時点の公式仕様では、settings.jsonのautoCompactEnabled（真偽値、既定はtrue）で自動compactの有効・無効を切り替えます。trueならコンテキストが上限に近づいた際にcompactが自動実行され、falseにすると自動実行されません（手動の/compactはそのまま使えます）。自動実行の発動タイミングを変えたい場合は、autoCompactWindow（100000〜1000000のトークン数）で設定できます。

{
  "autoCompactEnabled": true
}

自動と手動のトレードオフ

自動コンパクトでも、残す方針をあらかじめ渡すことはできます。公式ドキュメントのとおり、CLAUDE.mdに「Compact Instructions」の節を設け、「変更した型定義の一覧と未完了タスクを残す」のように書いておけば、自動・手動を問わず圧縮時の保持方針として使われます。一方で、「今のタスクの次に何をするか」といったその場の状況に応じた指示は、手動の/compact <指示>で渡すほうが細かく制御できます。重要度の高い作業では、Compact Instructionsを整えたうえで、節目では手動で/compactを実行する運用が安全です。

推奨はハイブリッド運用

実務での推奨は、autoCompactEnabled: trueを有効にしつつ、70-80%到達時に手動でフォーカス指示付き/compactを実行するハイブリッド運用です。手動で圧縮できればベスト、忘れても自動がセーフティネットとして機能します。

これは、AIに任せる部分と人が判断する部分を分ける考え方そのものです。「容量が溢れないよう監視する」という定型的な仕事はAI側に任せ、「何を残すべきか」という設計判断は人が握る。この役割分担を明確にしておくと、どちらの機能にも過度な期待をせずに済みます。

フォーカス指示を「型」にする

フォーカス指示は、うまく書ける人とそうでない人の差が出やすい部分です。だからこそ、個人のセンスに任せずテンプレート化しておく価値があります。この節では、そのままコピーして使える型と、書くときの3つのポイントを整理します。

テンプレート一覧

効果的な指示を書く3つのポイント

フォーカス指示を書く際は、以下の3点を意識します。

1. 「残すもの」を明示する — 「不要なものを消して」ではなく「○○を残して」と指定する方が精度が高くなります。消すものを列挙するアプローチは、挙げ漏れたものの扱いが曖昧になりがちです。
2. 具体的なファイルパスや機能名を含める — 「認証機能」より「src/auth/配下のJWTトークン検証ロジック」の方が正確に伝わります。プロジェクト内で複数の解釈ができる言葉は避けるのがポイントになってきます。
3. 次の作業内容を伝える — 「テストコード作成に移ります」と次のタスクを書くと、それに必要な情報を推測して残してくれます。圧縮は「過去を捨てる操作」ではなく「未来の準備」だと考えると、この指示が自然に書けるようになります。

自社の開発スタイルに合わせて調整する

ここに挙げたテンプレートはあくまで出発点です。企業様によって最適な形は異なりますので、自社のプロジェクト構成や開発プロセスに合わせて調整していただくのがいいかと思います。

例えばマイクロサービス構成であればサービス単位の指示が中心になりますし、モノリスで大きな型定義を共有しているなら型情報の保持が重要になります。まずは自社で頻度の高い作業を2〜3個だけ選んで型を作り、そこから運用しながら段階的に広げていく進め方をおすすめします。最初から10パターン用意しても、使われないテンプレートが増えるだけになりがちです。

個人技をチームの仕組みに変える

ここまでの内容は、そのままだと「詳しい人だけがうまく使える」状態にとどまります。AIツールの導入で成果が分かれやすいのは、こうしたノウハウを個人の力量ではなく仕組みに落とし込めるかどうかです。この節では、そのための3つの打ち手を紹介します。

フォーカス指示のテンプレートをリポジトリで共有する

注意したいのは、カスタムコマンドに保持指示を書いても、それだけでは圧縮が実行されない点です。組み込みの/compactはSkillツール経由でClaudeから呼び出せないため（公式ドキュメントでも/compactは対象外と明記されています）、コマンドの中から/compactを起動する形にはできません。圧縮の実行は、利用者自身が/compact <保持指示>を直接入力する必要があります。

そこで、保持指示の文面そのものをチームの資産にします。例えば「タスク別のフォーカス指示集」をリポジトリのドキュメントにまとめておき、タスクの節目でそこからコピーして/compactの後ろに貼り付けて実行する運用です。指示文をリポジトリにコミットしておけば、新しく参加したメンバーも初日からその型に沿った圧縮を実行できます。ベテランが頭の中で組み立てていた判断が、共有された文面に置き換わり、属人化していた引き継ぎがそのまま仕組みとして残るということです。

CLAUDE.mdで前提条件を永続化する

/compactのあと、Claudeが作業に使うコンテキストでは詳細が要約に置き換わります。元のやり取りはローカルの会話履歴ファイル（既定では30日間保持）に残るので、細部が必要になったらClaudeにそのファイルから探してもらえますが、作業中のコンテキストに自動で戻るわけではありません。また、保存された会話はclaude --continueやclaude --resumeで再開できますが、新しいセッションを始めると前の会話は引き継がれません。プロジェクト固有の重要な前提条件は、プロジェクトルートのCLAUDE.mdに記述しておくことで、compactの後もディスクから再度読み込まれ、新しいセッションでも最初から含まれます。あわせてCLAUDE.mdに「Compact Instructions」の節を設けておけば、圧縮時に何を残すかの方針も共有できます。詳しくは「Claude Codeのメモリ・コンテキスト管理」で解説しています。

コーディング規約、ディレクトリ構成のルール、使ってはいけないライブラリといった「毎回説明していること」は、CLAUDE.mdに移す候補です。毎セッション同じ説明を繰り返しているなら、それは永続化すべき情報のサインだと考えていただくといいかと思います。

置き場所を3層で設計する

ここまでの3つの打ち手を整理すると、情報の置き場所を層に分ける設計になります。

この3層を意識すると、「なんでもプロンプトに書く」状態から抜け出せます。恒久層と定型層に置くべきものを揮発層に置いているから、毎回同じ説明が必要になり、圧縮のたびに要約へ回って薄れるわけです。

スモールスタートの進め方

いきなり全社ルールを作ろうとすると、たいてい止まります。

導入は一気に進めるのではなく、個人での確認習慣から始めて、よく使うフォーカス指示の文面化、チームのリポジトリへの共有という順で段階的に広げていく進め方が、ひとつの例です。すべてを一気に整えるのではなく、効果が出そうなものから優先順位をつけてトライいただければと思います。

/compactが向かないケースと限界

最後に、/compactでは解決しない場面についても率直にお伝えしておきます。万能な手段として扱うと、かえって作業効率を落とすことがあります。

別タスクへ移るなら新セッションの方がよい

タスクの継続性がない場合、/compactで無理に継続するより、新しいセッションを開始した方がクリーンに始められます。

判断の軸は「前のタスクの情報が、次のタスクで1つでも役に立つか」です。役に立たないなら、圧縮して残すコストの方が高くつきます。

圧縮では直らない問題もある

/compactはコンテキスト量の問題を解決する手段であって、指示の曖昧さやプロジェクト構成の複雑さそのものを解決するものではありません。圧縮しても出力が安定しない場合は、そもそもの指示が具体性を欠いている、あるいはCLAUDE.mdに書くべき前提が書かれていない可能性を疑った方がいいかと思います。

また、頻繁に実行しすぎると直前の作業のコンテキストまで圧縮されてしまうため、必要以上に実行しないことも大切です。「困ったらとりあえずcompact」という使い方は、かえって手戻りを増やします。

圧縮後のコンテキストは要約で動くことを前提にする

圧縮すると、Claudeが作業に使うコンテキストは要約に置き換わります。元のやり取りは会話履歴ファイル（~/.claude/projects/ 配下のJSONL）に残るため、細部はClaudeにそのファイルから探してもらえば参照できます。ただし履歴は既定で30日を過ぎると自動で削除されますし、毎回探してもらうのは手間です。あとで参照する可能性がある調査結果や設計の検討過程は、圧縮前にファイルやドキュメントとして書き出しておくのが安全です。

この点は、CRMでレポートの信頼性を守る考え方と同じです。あとから確認できない状態を作らないために、残すべき記録は揮発する場所ではなく永続する場所に置いておく。Claude Codeでいえば、リポジトリ内のドキュメントやCLAUDE.mdがその役割を担います。

よくある質問

Q1. /compactを実行すると、それまでの会話内容は完全に消えますか？

消えるのではなく、要約されます。/compactは会話履歴を分析し、重要な情報を要約として残しつつ、詳細なログや中間的なやり取りを圧縮します。フォーカス指示を指定することで、どの情報を優先的に残すかをコントロールできます。圧縮前のやり取りはローカルの会話履歴ファイルに残っており、Claudeにそこから探してもらうことはできますが、作業中のコンテキストには要約しか残りません。後から何度も参照したい内容は、事前にファイルへ書き出しておくのが安全です。

Q2. /compactはどのくらいの頻度で実行すべきですか？

/contextで使用率を確認し、70-80%に達したタイミングで実行する運用がひとつの目安になります。大きなファイルの読み込みやデバッグの試行錯誤を重ねた後も、使用率を確認する節目として使いやすいタイミングです。頻繁に実行しすぎると直前の作業のコンテキストまで圧縮されてしまうため、必要以上に実行しないことも大切です。

Q3. 自動コンパクトと手動コンパクトはどちらを使うべきですか？

両方を併用するのが実務的です。autoCompactEnabled: trueを設定して自動コンパクトを有効にしつつ、重要な作業の切り替え時には手動でフォーカス指示付きの/compactを実行します。自動コンパクトにはその場の作業内容に合わせたフォーカス指示を渡せないため、何を残すかの精度は手動に劣ります。CLAUDE.mdの「Compact Instructions」に保持方針を書いておけば自動でも反映されるので、手動compactを主軸に、自動をセーフティネットとして位置づける運用がおすすめです。

Q4. /compactと新しいセッションの開始、どちらが良いですか？

タスクの継続性によります。同じタスクを続ける場合は/compactで圧縮してセッションを継続する方が、作業の文脈が保持されて効率的です。まったく別のタスクに移る場合は、新しいセッションを開始した方がクリーンな状態で始められます。新しいセッションを開始する場合でも、CLAUDE.mdに重要な前提条件を書いておけば引き継ぎが可能です。

Q5. チームで使う場合、何から整備すればよいですか？

まずは「使用率が70-80%になったら圧縮する」という判断基準を共有することから始めるのがおすすめです。次に、チームで頻度の高い作業のフォーカス指示を1つ文面にしてリポジトリのドキュメントにコミットし、最後にコーディング規約などの前提条件をCLAUDE.mdへ移します。最初から網羅的なルールを作ろうとせず、効果の出そうなものから段階的に広げる方が定着しやすいかと思います。

まとめ

/compactは、Claude Codeの長時間セッションで回答品質を維持するための中核的な機能です。コンテキストの使用率が70-80%に達した段階で、フォーカス指示付きの/compactを実行することで、不要な作業ログを圧縮しつつ、判断材料となる情報を正確に保持できます。

本記事の要点を整理すると、次の3つになります。

• 情報の価値で分ける — 作業ログは要約でよく、判断材料と前提条件は正確に残す。この区別がフォーカス指示の質を決めます
• 数値で判断する — 体感ではなく/contextの使用率を基準にすることで、圧縮のタイミングが人や日によってぶれなくなります
• 置き場所を3層に設計する — 恒久層（CLAUDE.md）・定型層（フォーカス指示集）・揮発層（セッション）に分けることで、個人の勘に頼らない運用になります

最初の一歩としては、まずは/contextで今の使用率を確認するところから始めていただくのがいいかと思います。そのうえで、次の3ステップを進めてみてください。

1. 作業中に一度/contextを実行し、自分のセッションがどのくらいの速度で埋まるかを把握する
2. 使用率が70-80%に達したタイミングで、「〇〇を残してください」というフォーカス指示付きの/compactを1回試す
3. 効果のあった指示文をフォーカス指示集としてチームのリポジトリのドキュメントに保存し、全員が/compactの後ろに貼って使えるように共有する

企業様によって開発スタイルもプロジェクト構成も異なりますので、テンプレートをそのまま使うのではなく、自社で頻度の高い作業から型を作り、段階的に広げていくことをおすすめします。

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• Claude Codeでバグ調査・修正を体系化する方法｜エラーログ解析から本番障害対応まで
• Claude Codeのサンドボックス設定｜ファイルシステム・ネットワークの安全な制限方法
• Claude Codeのメモリ・コンテキスト管理
• Claude Codeのカスタムコマンド
• Claude Codeチートシート