Claude Code のコンテキスト劣化を防ぐ：Context Engineering スキル集の使い方
Claude Code を使っていると「なんか最近の回答がおかしい」「さっき言ったことを無視された」という経験はないでしょうか。これは コンテキスト劣化 と呼ばれる現象で、会話が長くなるにつれてモデルのパフォーマンスが下がる問題です。
この記事では、OSS として公開されている Agent Skills for Context Engineering をClaude Code に導入し、劣化を診断・防止する方法を紹介します。
インストール方法
以下のコマンド1つで ~/.claude/skills/ に15個のスキルが追加されます。次のセッションから自動的に認識されます。
cd /tmp && \
git clone --depth=1 https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering.git context-engineering && \
cp -r context-engineering/skills/* ~/.claude/skills/ && \
rm -rf /tmp/context-engineering
スキルの呼び出し方は2通りあります。
- 自動: 会話の文脈からClaude が判断して自動アクティベート
-
手動: チャットに
/context-degradationのように入力
コンテキスト劣化とは
コンテキストウィンドウには U字型のアテンションカーブ があります。先頭と末尾の情報は確実に参照されますが、中間部の情報は10〜40%の精度低下 が起きます。
さらに、コンテキストが増えるほどパフォーマンスは下がりますが、その低下は線形ではありません。
パフォーマンス
↑
100%|████████████████
| ████
| ████
| ████
60%| ████▼▼▼ ← 急落（崖）
+--------------------------------→ コンテキスト量
↑
70%付近で崖
劣化は緩やかに進むのではなく、ある閾値を超えると 急落 します。70%に達してから対処するのでは遅いことが多いです。
5つの劣化パターン
/context-degradation スキルが扱う劣化は5種類に分類されます。
| パターン | 症状 | 原因 |
|---|---|---|
| Lost-in-Middle | 中間部の情報が無視される | U字型アテンションカーブ |
| Poisoning | ハルシネーションが連鎖・繰り返される | 誤情報がコンテキストに残存 |
| Distraction | 無関係な情報で精度が下がる | 関連性の低いコンテキストの混入 |
| Confusion | 別タスクの制約が混入する | タスクの切り替えによるコンテキスト汚染 |
| Clash | 矛盾する正しい情報が競合する | 複数ソースの版違い・視点の違い |
どうやって劣化を検出するか
Step 1: /clear して同じ質問を再送
↓
答えが改善する → コンテキストが原因
変わらない → プロンプト or モデルの問題
Step 2: 問題が継続的か確認
↓
1回だけ → 通常のバラつき（様子見）
3回以上連続 → 劣化を疑う
Step 3: 会話の長さと相関があるか
↓
長くなるほど悪化 → 劣化の可能性が高い
最初から悪い → 別の問題
/context-degradation スキルと /compact コマンドは別物です。
- スキル → なぜ劣化しているかを診断する知識
-
/compact→ 実際にコンテキストを圧縮する操作
4つの最適化戦略
/context-optimization スキルが扱う戦略を優先順位順に紹介します。
1. KV-キャッシュ最適化（コスト最小・リスク最小）
プロンプトの構造を安定させることで推論エンジンのキャッシュを再利用します。
# 安定した順序（キャッシュが効く）
1. システムプロンプト（最も安定）
2. ツール定義
3. 再利用テンプレート・Few-shot例
4. 会話履歴
5. 現在のクエリ（最も動的）
システムプロンプト内に日付や動的情報を入れると、毎回キャッシュミスが発生してコストが増大します。
# NG: キャッシュが効かない
system = f"今日は {today} です。..."
# OK: 動的情報はユーザーメッセージに分離
system = "固定テキストのみ"
user = f"今日は {today}。質問は..."
目標: キャッシュヒット率70%以上 → コスト50%削減・レイテンシ40%削減
2. 観察マスキング（最大の効果）
処理済みのツール出力をコンパクトな参照に置き換えます。
# NG: 生のツール出力をそのまま保持（8,000トークン残存）
response = mcp.notion_get_page(page_id)
# → JSONが丸ごとコンテキストに残り続ける
# OK: 要点だけ残して圧縮（50トークン程度）
raw = mcp.notion_get_page(page_id)
ref_id = store(raw) # フル内容は外部保存
summary = extract_key_points(raw) # 要点を抽出
context += f"[MCP:{ref_id}] {summary}" # コンテキストにはこれだけ
マスキング判断ルール
| 状況 | 対応 |
|---|---|
| 直近1ターン以内の出力 | マスクしない |
| 3ターン以上前の処理済み出力 | マスク対象 |
| デバッグ中のエラー出力 | 解決するまでマスクしない |
| 重複・同一ツールの再実行結果 | 即マスク |
目標: 60〜80%削減・品質影響2%未満
3. コンパクション（70%到達時に実行）
if context_tokens / context_limit > 0.7:
context = compact(context)
# 目標: 50〜70%削減・品質低下5%未満
優先順位: ツール出力 → 古い会話ターン → 取得ドキュメント
コンパクションは 85%以上になってから実行すると失敗しやすい。コンパクション処理自体がコンテキストを消費するため、モデルが圧縮中に重要な情報を落とします。
4. コンテキストパーティショニング（独立タスクの分離）
単一のコンテキストに収まらない場合、サブエージェントに分割します。
オーケストレーター（調整役）
├── サブエージェントA: タスクA専用コンテキスト
├── サブエージェントB: タスクB専用コンテキスト
└── サブエージェントC: タスクC専用コンテキスト
分割にはコーディネーションコスト（システムプロンプト・ツール定義の重複）がかかります。独立したサブタスクが3つ以上ある場合 に効果がでます。
スキル一覧
| コマンド | カテゴリ | こんなときに使う |
|---|---|---|
/context-fundamentals |
基礎 | コンテキストウィンドウ・アテンション機構の概念を理解したいとき |
/context-degradation |
診断 | エージェントの精度低下の原因を診断したいとき |
/context-compression |
最適化 | 長いセッションをハンドオフ要約に圧縮したいとき |
/context-optimization |
最適化 | トークン消費・KVキャッシュを改善したいとき |
/multi-agent-patterns |
アーキテクチャ | 複数エージェントの設計パターンを検討したいとき |
/memory-systems |
アーキテクチャ | エージェントの永続メモリ・検索層を構築したいとき |
/tool-design |
アーキテクチャ | ツール定義の説明文・パラメータ設計を最適化したいとき |
/filesystem-context |
アーキテクチャ | 大きなツール出力をプロンプト外に逃がしたいとき |
/hosted-agents |
アーキテクチャ | サンドボックス・リモート実行環境を設計するとき |
/evaluation |
評価 | エージェントの評価システム・品質ゲートを構築したいとき |
/advanced-evaluation |
評価 | LLM-as-judge・ルーブリック設計を使いたいとき |
/harness-engineering |
運用 | 自律エージェントのリサーチループを設計するとき |
/project-development |
運用 | LLMプロジェクトの全体設計を考えるとき |
/bdi-mental-states |
高度 | BDI認知モデルでエージェントをモデリングするとき |
/latent-briefing |
高度 | マルチエージェント間のKVキャッシュ共有でトークン爆発を抑えたいとき |
実践Tips
セッション管理
| 操作 | コマンド | 効果 |
|---|---|---|
| セッションを切る | exit → claude |
コンテキスト完全リセット |
| 前のセッションを再開 | claude -r |
直前の会話を引き継ぎ |
| その場で圧縮 | /compact |
現在の会話を要約して軽量化 |
| 劣化チェック |
/clear して同じ質問を再送 |
答が改善すればコンテキストが原因 |
タスクの区切りでセッションを分けるのが最も効果的 です。トークン数より「このセッションで何を達成したか」で区切ると使いやすいです。
MCP ツールのトークン削減（Notionの例）
Notion MCP のレスポンスは特に冗長で、1ページで5,000〜15,000トークンになることがあります。
# NG: 取得結果をそのままコンテキストに残す
page = mcp.notion_get_page(page_id) # 5,000トークン
# OK: タイトルとIDだけ保持
page = mcp.notion_get_page(page_id)
context += f"[notion:{page['id'][:8]}] {page['title']}" # 30トークン
| 操作 | 最適化前 | 最適化後 | 削減率 |
|---|---|---|---|
| ページ取得 | ~5,000 tok | ~50 tok | 99% |
| DB検索20件 | ~40,000 tok | ~500 tok | 98% |
| 更新操作 | ~2,000 tok | ~10 tok | 99% |
スキル自体のトークンコスト
スキルは呼び出したときに読み込まれ、その分トークンを消費します。グローバル CLAUDE.md に常時ルールを書くより、必要なときだけ /スキル名 で呼び出す 方がトークン効率がよいです。
まとめ
| やること | 効果 |
|---|---|
| コンテキスト70%でコンパクション | 崖への到達を防ぐ |
| ツール出力を即マスキング | 最大80%削減 |
| システムプロンプトを安定化 | KVキャッシュヒット率70%+ |
| タスク単位でセッションを分ける | コンテキスト汚染を根本防止 |
劣化したら /clear して再送 |
原因の切り分け |
コンテキストエンジニアリングは一度設定すれば終わりではなく、会話の進行とともに継続的に管理するものです。このスキル集を活用して、Claude Code のパフォーマンスを長い会話でも維持してみてください。