Claude Codeのコンテキスト管理完全ガイド：/context・/compact・CLAUDE.mdの使い分け

Claude Codeで一番もったいない失敗は、モデル性能ではなくコンテキスト運用で詰まることです。会話が長くなるほど、読ませたファイル、コマンド出力、過去の相談が窓を埋めていきます。

/contextで状況を見る、/compactで要約する、/clearで区切る、CLAUDE.mdに永続ルールを移す。この4つを使い分けるだけで、長時間作業の安定感はかなり変わります。

この記事では、初心者にも分かる言葉で、文脈切れを防ぐ実務フロー、Obsidianとの役割分担、失敗例、チーム導入時のチェックポイントまでまとめます。

コンテキストウィンドウを作業机として考える

コンテキストウィンドウとは、Claude Codeがその時点で参照できる作業机の広さです。会話履歴、読んだファイル、ツール結果、CLAUDE.md、Auto memory、読み込まれたrulesやskillsがここに入ります。作業机が散らかると、重要な仕様や制約が見えにくくなります。

入るもの	重くなる原因	対策
Conversation	長い相談と脱線	タスクごとに区切る
Files	巨大ファイルの丸読み	検索して範囲指定
Tool output	長いログと失敗リトライ	要約して保存
Memory	長すぎるCLAUDE.md	rulesやdocsへ分離

/context・/compact・/clear・/memoryの使い分け

/contextは現在の使用量と重い要素を確認するコマンドです。/compactは長い会話を要約して続行するコマンドです。/clearは新しい会話として始める選択で、同じ流れを保ちたいなら/compact、タスクが完全に切り替わるなら/clearが向いています。/memoryはCLAUDE.mdやAuto memoryが読み込まれているかを確認する場所です。

/context all
/compact focus on files changed, failing tests, and next command
/clear
/memory

開始前にコンテキスト予算を決める

実務では、タスク開始時に「目的、触るファイル、完了条件、実行する検証」を先に渡します。逆に、関係ないログや全ディレクトリの丸読みを避けます。Claude Codeに探索させる前に、検索範囲を絞るだけでコンテキスト消費は大きく減ります。

# narrow discovery before asking Claude to read files
rg -n "getUserById|User not found|auth middleware" src tests
git diff --stat
npm test -- --runInBand

長い作業用のコピペランブック

次のランブックは、長い修正や記事制作の前にそのまま貼れる形です。ポイントは、最初に成功条件を書き、途中成果物をファイルへ残し、終盤で検証レシートを作ることです。

## Task brief
- Objective:
- In scope:
- Out of scope:
- Files likely involved:
- Done when:
- Verification commands:

## Handoff receipt
- Changed files:
- Commands run:
- Result:
- Remaining risk:
- Next best action:

compact後に残るもの・消えるもの

compaction後もルートのCLAUDE.mdやAuto memoryは再注入されますが、サブディレクトリのCLAUDE.mdやpath-scoped rulesは、該当ファイルを再び読んだときに戻ります。会話だけで伝えた重要指示は失われやすいので、長期で使うものはCLAUDE.mdへ逃がします。

# CLAUDE.md

## Compact Instructions
- Keep the current business objective and monetization hypothesis.
- Keep changed files, verification commands, deploy state, and blockers.
- Drop raw logs unless a line explains the root cause.
- If article work is in progress, preserve slug, locale list, and quality gaps.

実例3つ：開発・記事・収益導線

1. 大規模リファクタでは、調査をsubagentや別セッションへ出し、メイン会話には要約と変更判断だけを戻すと、実装中の文脈が汚れません。
2. 記事制作では、ネタ帳や検索メモはObsidian、公開ルールと品質ゲートはCLAUDE.md、最終本文はMDXに分けると、PV改善のPDCAが回しやすくなります。
3. 問い合わせ導線の改善では、アクセス分析、仮説、修正、検証を1つの短いチケットにし、完了後にレシートを残して次回の起点にします。

よくある失敗と回避策

1. 失敗例1: /compactすれば何でも残ると思い込む。実際には会話履歴は要約されるため、細かい制約は落ちます。残したいルールはCLAUDE.mdかファイルにします。
2. 失敗例2: 調査で大量のファイルを読ませてから実装に入る。実装時には古い調査ログが窓を占有します。調査結果を短いメモへ圧縮してから進めます。
3. 失敗例3: Auto memoryをチーム共有ドキュメントだと思う。Auto memoryは基本的にローカルな学習メモなので、共有したい規約はリポジトリのCLAUDE.mdへ書きます。

Obsidianとの役割分担

毎日の作業に落とすなら

おすすめは、作業開始時に三つだけ確認することです。まず /context で今の窓が重くないかを見る。次に、今回の成功条件を一文で書く。最後に、終わったらどの検証コマンドを実行するかを決めます。この三つがないまま走り始めると、途中で話題が増えて判断が散らばります。

長い調査が必要なときは、調査と実装を同じ文脈に詰め込まないほうが安定します。調査結果を docs/handoff-YYYY-MM-DD.md のような短いファイルにまとめ、実装セッションではそのファイルと対象コードだけを読ませます。これで、古い検索結果や不要な候補が実装判断に混ざりにくくなります。

記事運用でも同じです。流入キーワード、読者の悩み、内部リンク候補はObsidianや分析メモに置きます。MDXを書くセッションには、今回のslug、読者像、必須リンク、品質ゲートだけを渡します。コンテキストを細くするほど、導入文やCTAの改善に集中できます。

会話が長くなったら、いきなり続行せずに「いま残すべき事実」を一度ファイルへ落とすのが安全です。たとえば変更ファイル、未解決の判断、失敗したコマンド、次に試すコマンドを5行で保存します。その後に /compact すれば、要約の質も上がり、次の指示がぶれにくくなります。

逆に、完全に別タスクへ移るなら /clear を使います。前の作業で読んだログやコードは、新しい意思決定にはノイズになることが多いです。Claude Codeを長時間使うほど、良い指示を書く力だけでなく、良いタイミングで文脈を捨てる力が効いてきます。

特にマネタイズ目的のサイト運用では、アクセス分析、記事改善、営業導線、広告確認が混ざりやすいです。全部を一つの会話で抱えると、本文品質の判断と収益施策の判断が干渉します。記事を書くセッション、分析するセッション、デプロイするセッションを分けるだけでも、判断の精度は上がります。

初心者ほど、コンテキスト管理を難しく考えすぎなくて大丈夫です。まずは「読むファイルを絞る」「終わったら検証結果を残す」「別タスクなら切る」の三つだけで十分です。この三つを守るだけで、Claude Codeは同じ能力でもかなり扱いやすくなります。

慣れてきたら、作業の最後に一行で次回の入口を書く習慣を足します。次に読むファイル、まだ怖い点、次の検証コマンドが残っていれば、翌日のセッションはすぐ再開できます。これは自動投稿や毎日改善のような継続運用で特に効きます。

私はこの運用を、記事改善バッチのような反復作業で特に重視します。前回の分析結果を全部持ち越すのではなく、次に直すslug、狙う検索意図、確認するコマンドだけを残すほうが、本文の質も検証速度も上がります。

つまり、コンテキスト管理は節約術ではなく品質管理です。Claude Codeに読ませる情報を選ぶほど、提案、実装、記事本文、CTAの一貫性が上がります。迷ったら、いま必要な情報だけを残す、で十分です。これだけで失敗率は十分に下がり、再開も速くなります。

この考え方は、CLAUDE.mdのベストプラクティス、トークン最適化、プロンプト設計とセットで効きます。ナレッジ管理まで含めるならClaude CodeとObsidian連携も読み、チーム導入は教材と相談ページから相談してください。

置き場所	向いている情報
CLAUDE.md	毎回必要な短い規約
Obsidian	長い調査、仮説、記事ネタ
MDX / docs	公開本文、仕様、引き継ぎ
Auto memory	ローカルな好みと繰り返し学習

この記事で確認したこと

この記事では、公式のcontext window、commands、memoryページを確認し、/cost中心の古い説明ではなく、/usage、/context、/compact、/memoryを使い分ける説明に更新しました。 Official references: context window, commands, memory, and common workflows.