Claude Codeのコンテキスト管理について（2026年5月）
今回は、Claude Codeのコンテキスト管理を2026年5月時点の仕様についての備忘録です。なお、初っ端から免責で恐縮ですが、この記事の情報が正しいかど うか、最新かどうかはご自身で判断をお願いします。
基本的に、AIに直接聞けばこの手の最新情報はすぐに取得できるのと、この工程をSKILLSに組み込んで自律的に最適化する方法で更新される場合がありますが、このブログではその変化も含めて筆者の趣味でスクラップしているものになりますので、その点ご了承ください。
4月時点で同じテーマの記事を書きましたが、この1~2ヶ月でOpus 4.7のリリース、自動メモリ機能の標準化、スキルとサブエージェントの役割整理、プロンプトキャッシュのTTL変更など、運用に関わる変更がいくつか入りました。
前回記事と内容が一部重複しますが、現時点での品質基準と判断ルールを体系立ててまとめ直したものです。あくまで筆者の環境（macOS 26.3.x）での運用に基づく内容のため、お使いの環境やバージョンによって異なる場合があります。
この記事のターゲット
4月時点の記事を読んだうえで使い方のヒントを得たい方
Claude Codeの応答品質を安定させる運用基準を整理したい方
自動メモリ・スキル・サブエージェントなど機能の使い分けを知りたい方
コンテキストウィンドウの新しい運用基準
Claude Codeのコンテキストウィンドウにはメッセージだけでなく、Claudeが読み込んだファイルの中身、コマンドの出力、システムプロンプト、CLAUDE.md、MCPツールの定義、これらすべてが入ります。
コンテキストが埋まるほど応答品質は下がります。 現時点では、2026年4月16日にGAとなったOpus 4.7が1Mトークンのコンテキストウィンドウに対応していま す（最大出力は128Kトークン）。長尺コンテキストでも追加プレミアム料金は発生しません。1M対応のSonnet 4.6と並んで、長期的な作業を1セッション内で扱える幅が広がりました。
自動圧縮（auto-compaction）の発動閾値は、Anthropic公式のクックブックに記載のあるとおり、使用率83.5%です。200Kウィンドウなら約167Kトークン、残り約33Kがバッファとして確保される計算になります。ここまで放置すると圧縮の質が下がるため、能動的に動くほうが結果が安定します。実運用での目安は次のとおりです。
使用率 | 推奨アクション |
0〜50% | 通常作業 |
50〜70% | 区切りのよいタイミングで |
70〜83% | カスタム指示付きで |
83%以上 | 自動圧縮の前に進捗を |
/compact
/compact には残してほしい情報を指定できます。たとえば /compact 認証モジュールと現在のテスト失敗に集中 のように書くと、関係ない情報を省いて要約してくれます。
4月版では「85〜95%で /compact」と書きましたが、自動圧縮の発動が83.5%だと分かった以上、その前に手動で動くほうが情報の取捨を自分でコントロールできる、というのが体感としての改善点です。
/context
/context は今どのくらい使っているかの内訳を表示します。システムプロンプト、システムツール、カスタムエージェント、メモリーファイル、スキル、 メッセージ、空き、自動圧縮バッファ、それぞれが何トークン使っているかを確認できるので、削れる部分の見極めに役立ちます。
自動メモリ（auto memory）が標準化した
Claude Codeは現在、永続的なメモリを ~/.claude/projects/<project>/memory/ に保存します。
会話をまたいで参照されるため、ユーザーの好みやプロジェクト固有の決定を覚えてもらえます。 公式に明文化されている仕様として、MEMORY.md がインデックスファイルになっており、会話開始時に最初の200行または25KBまで（先に達した方）が自動で読み込まれます。
この制約があるため、MEMORY.md 自体は簡潔なインデックスに留め、詳細はトピックごとの個別ファイル（debugging.md、api-conventions.md のような）に分散させるのが基本です。 実装上、メモリは用途別に何種類かに分類して運用されます。Anthropicが提供する自動メモリの実装では、次のような分類が使われています。
user
ユーザーの役割・好み・知識レベルなど
feedback
過去の指摘から学んだルール（やってほしくないこと、やってほしいこと）
project
プロジェクト固有の決定・締め切り・関係者など、コードからは読み取れない文脈
reference
外部システム（LinearやSlackなど）へのポインタ
逆に、メモリに保存すべきでない情報もあります。例えば、コードを読めば分かること、git log や git blame で取れること、CLAUDE.mdに書いてあること、その会話だけの一時的な状態など はメモリから除外します。
永続メモリの肥大化は、起動時のコンテキスト消費に直結するためです。 ポイントとして、相対日付は絶対日付に変換して保存します。「昨日決めた」ではなく「2026-05-05に決定」と書いておくと、時間が経った後でも判断材料として残ります。
CLAUDE.mdの階層構造とDynamic Context Priming
CLAUDE.mdは複数のスコープで階層的に読み込まれます。現時点での構成は次のとおりです。
スコープ | 場所 | 用途 |
組織管理ポリシー |
| 全ユーザー共通 |
プロジェクト共有 |
| チームで共有するルール |
ユーザー全体 |
| 個人の全プロジェクト共通 |
ローカル個人 |
| 個人かつこのプロジェクト限定 |
CLAUDE.md内で @path/to/file と書くと、そのファイルの内容を展開できます。共通の文体ルールやコーディング規約を別ファイルに切り出して再利用する運用に向きます。
ネストされたCLAUDE.md（サブディレクトリ配下のもの）は、関連ファイルが参照されたタイミングでオンデマンドに読み込まれます。常に全部読まれるわけではないため、コンテキストを節約しながらモジュール固有のルールを当てられます。サブディレクトリにCLAUDE.mdを置いておくと、そのディレクトリ内のファイルを @ 参照しただけで関連ルールが自動的に適用される、というのがDynamic Context Primingの基本です。
@ でファイル参照する際の操作は3月時点と同じです。Tabキーで補完、@file.ts:15-30 のように行範囲を指定可能、Shiftを押しながらドラッグ&ドロップでも追加できます。Claudeに自力で探させるよりトークン効率がよい、という基本方針も変わりません。
スキル、サブエージェント、コマンドの使い分け
.claude/commands/ は後方互換のために残っていますが、新規はスキル（.claude/skills/）で実装するのが推奨されています。両者が同じコマンド名を作成した場合はスキル側が優先されます。
スキルとサブエージェント（Taskツール）の使い分け基準は次のように整理できます。
軸 | スキル | サブエージェント |
コンテキスト | メイン会話に注入 | 独立した別コンテキスト |
仕事量 | 小規模・定型ワークフロー | 大規模・探索的 |
結果の可視性 | 会話に残る | 要約レポートのみ受け取る |
並列実行 | 不可 | 可能（複数同時に起動可） |
トリガー | descriptionで自動 or | 親から明示的に委譲 |
調査や広範囲の探索のように、メインの会話を汚したくない仕事はサブエージェントに委任します。組み込みのサブエージェントタイプには Explore（読み取り専用の探索、Haikuで実行）、Plan（コンテキスト解析後に戦略を提示）、general-purpose（探索と修正の両方に対応）があり、用途で選びます。広範な検索が3クエリ以上必要なら Explore を選ぶ、というのが実運用の目安です。
複数セッションを協調させるAgent Teamsも実験的に使えるようになりました。共有タスクリストとピアツーピアメッセージングで複数のClaudeを並列に動かす形ですが、まだ試験段階のため、デフォルト構成で必要になることは少ないと思います。
スキル（SKILL.md）の記述ルールと制約
スキルを自作するときに把握しておくべき具体的な制約をまとめます。これは公式ドキュメントの「Skill authoring best practices」に準拠した内容です。
サイズ・命名の上限
SKILL.md本体
500行以下が推奨。これを超える場合は
references/やscripts/に分割する
description フィールド
上限1,024文字
description + when_to_use の合算
1,536文字以内に収める
name フィールド
64文字以下、小文字・ハイフン・数字のみ
anthropicやclaudeなどの予約語は使用不可
これらの上限は、複数スキルの description が起動時に常時ロードされる仕様に由来します。description の合算がコンテキストの約1%（デフォルト8,000文字）に収まるよう設計されているため、1スキルあたりの制限が定められている、という背景です。
コンテキストへの読み込み（Progressive Disclosure）
スキルは段階的にコンテキストに読み込まれます。
起動時：全スキルの
descriptionとwhen_to_useのみが事前ロード呼び出し時：SKILL.md本体が1回だけ注入され、以降そのまま会話に残る
参照ファイル読み込み時：SKILL.md内のリンク（
[ref.md](ref.md)）をClaudeが読みに行ったときだけロードスクリプト実行：スクリプト本体はロードされず、実行結果のみがコンテキストに入る
つまり、参照ファイルやスクリプトは使われた分だけコンテキストを消費します。読み込まれない参照ファイルは0トークン、スクリプトの中身は何行あっても0トークン、という設計です。詳細な手順書や辞書は外部ファイルに切り出しておくのが効率的です。
frontmatterで使える主なフィールド
フィールド | 用途 |
| スキル名（必須相当、省略時はディレクトリ名） |
| 自動トリガーの判定信号（必須） |
| descriptionの補足。「いつ呼ぶか」を具体的に |
|
|
| スキル内で使えるツールを限定（例: |
| サブエージェントとして独立コンテキストで実行 |
|
|
| このスキルの実行時だけ別モデルを使う |
| 推論量を |
| パターンマッチで自動トリガー条件を限定 |
破壊的な操作（デプロイ、外部API呼び出しなど）を含むスキルは disable-model-invocation: true を必ず付けて、明示的な /slash 呼び出しでしか起動しないようにします。これは公式が推奨している運用です。
descriptionの書き方
descriptionは「自動トリガーの唯一の信号」と公式ドキュメントに明記されています。書き方の基本は次のとおりです。
三人称で書く
「Processes Excel files...」のような書き方
「I help you...」「You can use...」は避ける
キーワード優先
最初の句に「何ができるか」「いつ使うか」を両立させる
具体例を入れる
「PDF」「フォーム」「マージ」のような呼び出されたいキーワードを盛り込む
例として公式ドキュメントには次のような記述があります。
「Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.」
Plan ModeとAdaptive Thinking
Plan Modeは、編集を伴わない計画立案モードです。複数ファイルにまたがる変更や、設計が固まっていない作業の前に使うと、いきなりコードを書き始める失敗を防げます。逆に、単一ファイルの修正やバグの一行修正にはPlan Modeは過剰です。
Opus 4.7はAdaptive Thinkingのみが有効で、Opus 4.6以前にあったextended thinking budgets（事前に思考予算を割り当てる方式）は削除されています。Adaptive Thinkingは問題の難しさに応じて思考量を自動調整する方式で、API側で thinking: {"type": "adaptive"} を指定して有効化します。
Claude Code内でも明示的に深い思考を求めたいときは、引き続き ultrathink が利用可能です。2026年3月に再導入されて以降、現時点でも有効なキーワードとして残っています。 難しい設計判断のときには ultrathink を、軽い修正なら何も指定せず標準動作に任せる、という使い分けは現在も通用します。
Document & Clearパターンと大規模タスクの分解
会話に収まりきらない大きな作業の進め方は、3月版から方向性は変わりません。途中で進捗を .md ファイルに書き出し、/clear でリセットしてから新しいセッションでそのファイルを @ 参照する。このDocument & Clearパターンは5月時点でも有効です。 公式に推奨されている4フェーズの流れもおさらいしておきます。
Explore：ファイルを読ませる。「コードはまだ書かなくていい」と伝える
Plan：実装の計画を立てさせる
Code：計画のうち1〜2項目ずつ実装
Commit：コミットしてドキュメントを更新し、
/clearでリセット
1回のセッションで使うコンテキストは50%以内に収まるように分割する、という目安も維持しています。/resume でのセッション再開は4月のアップデートで高速化されたため、長期作業で意図的にセッションを切 る運用がやりやすくなりました。
ファイル除外とセキュリティの再整理
3月版では「.claudeignore は公式にサポートされていない」と書きました。5月時点では、対応自体は一部入ったものの、実運用では信頼できない状態です。.claudeignore で除外したはずのファイルが読み込まれた、という報告が2026年1月以降に複数あります。 機密ファイルへのアクセスを確実に遮断したい場合は、settings.json の permissions.deny で明示的にブロックします。3月版で紹介した記述に加え、絶対パス指定を推奨する流れになっています。
絶対パス指定の場合は // から始めるのがポイントです。permissions.deny に書いた設定は他の許可設定で上書きできないため、確実な防御策になります。シリーズ記事1で説明している settings.json の5スコープと同じ仕組みです。 機密ファイルが多いリポジトリでは、サンドボックス機能（sandbox.enabled: true）でOSレベルの隔離を併用する選択肢もあります。
自動化機能：/loopと/schedule
3月版にはなかった項目として、定期実行・スケジュール実行の機能があります。
/loopコマンド: 同じプロンプトを定期的に繰り返し実行。間隔は秒（s）・分（m）・時間（h）・日（d）で指定でき、再帰的タスクは作成から7日後に自動的に期限切れになる/scheduleコマンド: クラウドで動くRoutines（GitHubトリガーや定期実行など）を登録。セッション内の一回限りリマインダーは自然言語で「3時に〜してほしい」と指示する形でも登録できる
/loop 5m のように間隔 を指定すると、その間隔でプロンプトが再実行されます。デプロイの監視、定期監査、長時間ビルドの完了通知などに使えます。
注意点として、AnthropicのプロンプトキャッシュのデフォルトTTLは5分です。これは2026年3月の仕様変更で1時間から5分に短縮された値で、現状もデフォルトのままです。1時間TTLの拡張キャッシュは追加料金（書き込みは2倍、読み込みは0.1倍）で利用できます。
/loop の間隔を5分前後にすると、毎回キャッシュミスでフルコンテキストを読み直すことになりやすいので、短時間で確認したいなら4分以内、長めに待つなら20〜30分以上、というのが実用的な目安です。
まとめ
3月時点と比べて、コンテキスト管理の運用基準そのものが少しずつ変わってきています。今回の整理で押さえておきたいポイントは次の4つです。
自動圧縮の発動閾値（83.5%）を意識し、その前に手動で
/compactまたは/clearを入れる習慣をつける自動メモリが標準化し、
MEMORY.mdの200行・25KB制限を踏まえたインデックス運用が前提になったスキル機能には descriptionの1,024文字、SKILL.md本体500行といった具体的な上限があり、参照ファイルやスクリプトに分割する設計が前提
.claudeignoreへの過信は禁物で、permissions.denyで//始まりの絶対パス指定による明示的な遮断が現実的
コンテキスト管理は依然として、Claude Codeの運用で最も効果の出やすい改善ポイントです。/clear と /compact を習慣にし、メモリーとCLAUDE.mdを階層的に整理する運用が、応答品質の安定に効い てきます。本記事の内容も、ぜひ日々の運用に取り入れてみてください。
