Claude Code の1応答あたりの文脈を476kから115kへ ― handoff → /clear → pickup と「判断役に読ませない」の実測

株式会社Good Labでエンジニアをしている コータロー です。
日々、Java・SQL・Gitなどの技術情報や、新人エンジニア向けの学習ノウハウ、
AI活用についての情報を発信しています。

Good Labについて気になった方は、コーポレートサイトもぜひご覧ください。
▶コーポレートサイト

はじめに

Unity のゲーム開発で、1つのセッションを長く使い続けていました。その頃、利用制限がいつもより早くかかるように感じていました。

作業は Opus でしていました。Opus は文脈（コンテキスト）を長く保てます。その分、1回の応答で読み込むトークンが大きくなり、余計にトークンを消費しやすい環境になっていました。

利用制限が内部でどう計算されているかは公開されていません。なので「制限がこう減る」とは言えません。ただ、公式ドキュメントの「長いセッションで使用量が増える理由」には、次のように書かれています。

Claude Code sends your full conversation with every request, ... so a one-line question in a session that has been open all day still draws usage for the whole conversation.
（Claude Code はリクエストのたびに会話全体を送る。…なので、一日中開いているセッションでは、1行の質問でも会話全体ぶんの使用量がかかる）

そこで、会話を区切って引き継ぐ仕組みを作り、前後の会話記録を集計しました。この記事では、その仕組みのコードと数字をそのまま載せます。

この記事の結論は2つです。

1. 会話を長くしない（区切って、メモで引き継ぐ）
2. 判断する役に読ませない（調べる作業と判断を分ける）

	導入前	導入後
1応答の文脈（平均）	476k	115k
1応答の文脈（中央値）	455k	107k

「1応答の文脈」＝ 1回の応答で読み込んだ入力トークン（input_tokens + cache_creation_input_tokens + cache_read_input_tokens）。数字の条件と注意点は後の「3. 実測」に書きます。

1. なぜ長いセッションは重いのか（短く）

• Claude Code は応答のたびに、それまでの会話全体を入力として送ります。ツールを1回使うたびにもリクエストが発生します
• 会話の大半はプロンプトキャッシュから読まれます。それでも、読み込む量そのものは会話の長さに比例して増えます
• Opus 4.7 以降などのモデルは、既定で 1M トークンの文脈で動きます。公式ドキュメントによると、自動コンパクト（古い履歴の要約）が走るのは既定で約 967K トークンの手前です

私の導入前のセッションでは、1応答の文脈が最大 966k に達していました。ちょうど自動コンパクトが走る手前まで、会話を積み上げていたことになります。

2. handoff → /clear → pickup の仕組み

流れはこうです。

1. 文脈が12万トークンを超えると、フックが「区切りましょう」と知らせる
2. /handoff（スキル）で、作業メモ docs/作業メモ.md に続きを書く
3. /clear で会話を空にする
4. /pickup（スキル）で作業メモを読み、続きから再開する

ここで出てくる部品は3種類です。役割が違うので区別しておきます。

部品	種類	役割
context-guard.py	フック（UserPromptSubmit）	プロンプト送信時に文脈の大きさを測り、しきい値を超えたら知らせる
handoff / pickup	スキル	作業メモを書く／読む手順。/handoff /pickup で呼び出す
unity-checker	サブエージェント	コンパイル・テストなどの確認を別の文脈で行い、結論だけを返す

ファイルの配置は次のとおりです。

<作業フォルダ>/
├── .claude/
│   ├── settings.json
│   ├── hooks/context-guard.py
│   ├── skills/
│   │   ├── handoff/SKILL.md
│   │   └── pickup/SKILL.md
│   └── agents/unity-checker.md
├── <プロジェクトA>/docs/作業メモ.md
└── <プロジェクトB>/docs/作業メモ.md

以下のコードは実際に使っているファイルです。個人の絶対パスだけを $CLAUDE_PROJECT_DIR や <作業フォルダ> に置き換えています。

2-1. settings.json

.claude/settings.json

{
  "env": {
    "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "200000"
  },
  "hooks": {
    "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/context-guard.py",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

（実物の env には Unity CLI 用の変数も入っていますが、この記事とは関係がないので省きました）

• CLAUDE_CODE_AUTO_COMPACT_WINDOW は、自動コンパクトが走るまでの文脈の大きさ（トークン数）です。設定できる範囲は 100000〜1000000 で、200k のような書き方は不可です。整数で書きます。この設定で、1M のモデルでも 20万トークンで自動コンパクトが走るようになります
• 環境変数で指定すると、/autocompact コマンドや autoCompactWindow 設定より優先されます。環境変数を使わずに "autoCompactWindow": 200000 と書く方法もあります
• フックの timeout の単位は秒です
• $CLAUDE_PROJECT_DIR は、セッションを始めたプロジェクトのルートです。フックのコマンドに環境変数として渡されます

自動コンパクトの位置（20万）とフックのしきい値（12万）を分けているのには理由があります。コンパクトは会話全体を読んで要約するので、それ自体が大きなリクエストです。公式ドキュメントにも、続きが要らず新しく始めたいなら /clear はコストがかからない、とあります。なので、まずフックで「区切る」ことを促し、自動コンパクトは保険にしています。

2-2. フック: context-guard.py

.claude/hooks/context-guard.py

#!/usr/bin/env python3
"""UserPromptSubmit フック: 文脈が大きくなったら /handoff を促す。

会話記録の最後の呼び出しの入力トークン（キャッシュ分を含む）を読み、しきい値を超えていたら
モデルに知らせる（additionalContext）。本人にも systemMessage で見せる。
失敗しても何もしない（プロンプトを止めない）。
"""
import json
import os
import sys

WARN_TOKENS = 120_000
TAIL_BYTES = 4 * 1024 * 1024


def last_context_tokens(path):
    size = os.path.getsize(path)
    with open(path, "rb") as f:
        f.seek(max(0, size - TAIL_BYTES))
        lines = f.read().decode("utf-8", errors="ignore").splitlines()
    for line in reversed(lines):
        try:
            o = json.loads(line)
        except ValueError:
            continue
        if o.get("type") != "assistant" or o.get("isSidechain"):
            continue
        u = (o.get("message") or {}).get("usage") or {}
        total = sum(u.get(k) or 0 for k in ("input_tokens", "cache_creation_input_tokens", "cache_read_input_tokens"))
        if total:
            return total
    return 0


def main():
    try:
        data = json.load(sys.stdin)
        path = data.get("transcript_path") or ""
        if not os.path.isfile(path):
            return
        tokens = last_context_tokens(path)
    except Exception:
        return
    if tokens < WARN_TOKENS:
        return
    k = tokens // 1000
    print(json.dumps({
        "systemMessage": f"文脈が {k}k トークンです。区切りが良ければ /handoff → /clear → /pickup",
        "hookSpecificOutput": {
            "hookEventName": "UserPromptSubmit",
            "additionalContext": (
                f"現在の文脈は約{k}kトークン（目安12万超）。今の依頼を終えたら、返答の最後に1行で "
                "「/handoff → /clear → /pickup <プロジェクト名> で区切るのがおすすめです」と本人に伝えること。"
            ),
        },
    }, ensure_ascii=False))


if __name__ == "__main__":
    main()

ポイントは4つです。

• 何を測るか: フックには標準入力で transcript_path（会話記録 jsonl のパス）が渡されます。その末尾から、最後の assistant 応答の usage を探します。入力の3項目の合計を「いまの文脈」とみなします
• サブエージェントの応答は除く: isSidechain が真の行はサブエージェント側の応答なので飛ばします。これを数えると、メインの会話の大きさを見誤ります
• 2つの出力の使い分け: systemMessage は人（自分）に見せる警告です。hookSpecificOutput.additionalContext は Claude の文脈に入ります（system reminder として渡され、チャットの発言としては表示されません）。人にもモデルにも知らせるために両方出しています
• 失敗してもプロンプトを止めない: 例外はすべて握りつぶし、何も出力せずに終了コード0で抜けます

なお公式ドキュメントには、フックが動いた時点では transcript_path に直近のやり取りがまだ入っていない場合がある、と書かれています。なので、これは厳密な「いまの値」ではありません。目安として使っています。

2-3. フックを偽の会話記録で動かしてみる

しきい値の上下で出力が変わるかを、偽の会話記録で確かめました。

• below.jsonl: 最後の応答の文脈が 12 + 2,488 + 96,000 = 98,500（しきい値未満）
• above.jsonl: メインの応答が 8 + 3,792 + 132,000 = 135,800。その後ろに、小さなサブエージェントの応答（isSidechain: true、合計 10,005）を置きました

cat > below.jsonl <<'EOF'
{"type":"user","message":{"role":"user","content":"続けて"}}
{"type":"assistant","isSidechain":false,"message":{"id":"msg_1","usage":{"input_tokens":12,"cache_creation_input_tokens":2488,"cache_read_input_tokens":96000,"output_tokens":300}}}
EOF
cat > above.jsonl <<'EOF'
{"type":"user","message":{"role":"user","content":"続けて"}}
{"type":"assistant","isSidechain":false,"message":{"id":"msg_2","usage":{"input_tokens":8,"cache_creation_input_tokens":3792,"cache_read_input_tokens":132000,"output_tokens":300}}}
{"type":"assistant","isSidechain":true,"message":{"id":"msg_3","usage":{"input_tokens":5,"cache_creation_input_tokens":1000,"cache_read_input_tokens":9000,"output_tokens":120}}}
EOF
for f in below above; do
  echo "--- $f"
  echo "{\"hook_event_name\":\"UserPromptSubmit\",\"transcript_path\":\"$PWD/$f.jsonl\",\"prompt\":\"続けて\"}" \
    | python3 .claude/hooks/context-guard.py
  echo "exit=$?"
done

実行結果です（macOS、Python 3.9.6）。

--- below
exit=0
--- above
{"systemMessage": "文脈が 135k トークンです。区切りが良ければ /handoff → /clear → /pickup", "hookSpecificOutput": {"hookEventName": "UserPromptSubmit", "additionalContext": "現在の文脈は約135kトークン（目安12万超）。今の依頼を終えたら、返答の最後に1行で 「/handoff → /clear → /pickup <プロジェクト名> で区切るのがおすすめです」と本人に伝えること。"}}
exit=0

• しきい値未満では何も出しません（プロンプトはそのまま通ります）
• しきい値を超えると JSON を出します。135,800 // 1000 = 135 なので「135k」です
• 末尾のサブエージェントの応答（10,005）は無視され、その前のメインの応答で判定されています

2-4. スキル: handoff

.claude/skills/handoff/SKILL.md

---
name: handoff
description: 会話を /clear する前に、続きから再開するための作業メモをプロジェクトの docs/作業メモ.md に書く
---

会話を `/clear` する前の引き継ぎです。次の手順で作業メモを書いてください。

1. 対象プロジェクトを決める（今の会話で触っていた `<作業フォルダ>/<プロジェクト>`）。引数で渡されたらそれを使う
2. `<プロジェクト>/docs/作業メモ.md` があれば読む
   - **「## いまの作業」より前（プロジェクトの説明・構成・よく使うコマンド・決定事項）は消さない**。今回変わった点だけ直す
   - 無ければ新しく作る。プロジェクトの説明・構成・よく使うコマンドを短く書く
3. 「## いまの作業」の節を**丸ごと書き直す**（前回分は残さない）。中身:
   - 最終更新の日時
   - 目的（何を作っている／直しているか）
   - 終わったこと
   - 次にやること（最初の1コマンドまで）
   - 未コミット・未確認のもの（git 管理していないプロジェクトは「確認していないもの」）
   - ハマった点・やってはいけないこと
4. 長さの上限: 「## いまの作業」は40行、ファイル全体は150行。超えたら古い記述を削って詰める
5. 同じプロジェクトを別のセッションも触っているなら、`docs/作業メモ_<テーマ>.md` に分ける

書き終えたら、本人に次の3行だけ伝える:

```
作業メモを書きました: <パス>
次: /clear → /pickup <プロジェクト名>
```

効いているのは次の2点です。

• 「## いまの作業」は追記ではなく丸ごと書き直す。追記にすると、作業メモが会話記録の縮小版になって膨らみ続けます
• 行数の上限（節40行・全体150行）。次の会話の最初に読み込む量に、上限をかけています

2-5. スキル: pickup

.claude/skills/pickup/SKILL.md

---
name: pickup
description: /clear した後に、プロジェクトの docs/作業メモ.md を読んで続きから再開する
---

`/clear` 後の再開です。

1. 引数でプロジェクト名が渡されたら `<作業フォルダ>/<プロジェクト>/docs/作業メモ.md` を読む
   - 渡されなければ `ls -t <作業フォルダ>/*/docs/作業メモ*.md` で一覧を出し、どれを続けるか本人に聞く
2. git 管理しているプロジェクトなら `git status --short | head -20` で未コミットの状態を確かめる
3. 本人に5行以内で伝える: 目的／終わったこと／次にやること
4. 本人が「続けて」と言ったら「次にやること」から始める。メモに無いファイルを先回りして読み込まない（必要になったときに必要な範囲だけ読む）

大事なのは 4 の「メモに無いファイルを先回りして読み込まない」です。これがないと、再開直後に関係しそうなファイルを片っ端から読み、文脈がすぐに膨らみます。それでは /clear した意味がなくなります。

スキルは本文が呼び出されたときだけ読み込まれます（ふだん文脈に載っているのは description だけです）。なので、この手順を CLAUDE.md に書くより、毎回の読み込み量は小さく済みます。

2-6. サブエージェント: unity-checker（確認役）

コンパイル・テスト・ログ確認は出力が長くなりがちです。これをメインの会話でやると、ログがそのまま文脈に積もります。そこで、確認専用のサブエージェントに任せています。サブエージェントは自分の文脈で作業し、メインには結果だけが戻ります。

.claude/agents/unity-checker.md（抜粋）

---
name: unity-checker
description: Unity プロジェクトのコンパイル・テスト・ビルド・ログ確認・スクショ点検を代わりに行い、結論だけを短く返す。呼ぶ条件：①コードを直した後の recompile / test / build の確認 ②Console や Editor.log でエラーを探す ③スクショ3枚以上で「崩れ・はみ出し・表示されていない物」を点検する。コードの修正はしない。見た目の良し悪し（色・雰囲気・演出の方向）の判断には使わない。呼ぶときは「プロジェクトのパス」と「何を確かめたいか」をプロンプトに含めること。
model: sonnet
effort: medium
tools: Bash, Read, Grep, Glob
maxTurns: 30
---

あなたは Unity プロジェクトの確認係です。呼び出し元（メインの会話）は、あなたの出力をそのまま文脈に積みます。
**長い出力を返すと、あなたを使う意味がなくなります。** 結論だけを短く返してください。

## やること

- ファイルを変更しない（Edit / Write は持っていない。Bash でもファイルを書き換えない）
- 依頼された確認だけを行う。ついでの改善提案はしない

（よく使う Unity CLI のコマンド一覧とスクショ点検の手順は省略）

## 返し方（この形を必ず守る。全体20行以内）

```
結果: 成功 / 失敗 / 一部失敗
- エラー: <ファイル:行> <内容を1行>（最大5件。それ以上は「ほか N 件」）
- テスト: 合格 N / 失敗 N（失敗したテスト名と理由を1行ずつ）
- スクショ: <ファイル名> <問題を1行>（問題がなければ「問題なし」）
次の一手: <原因の見立てを1〜2行。分からなければ「不明」>
```

ログやコードを丸ごと貼らない。引用が必要なら該当の1〜3行だけにする。

• model: sonnet: 確認作業に Opus は要らないので、Sonnet で動かします
• effort はこのサブエージェントが動くときの推論の深さ、maxTurns は止まるまでのターン数の上限です
• tools に Edit / Write を入れないことで「確認専用」にしています
• 返し方のテンプレートが一番効きます。サブエージェントの出力はメインの文脈に積まれます。なので、ここが長いと、別の文脈に分けた意味が半分なくなります

導入してから、このサブエージェントは23回呼び出されました。

3. 実測: 1応答の文脈 476k → 115k

3-1. 集計の条件

• 対象: Unity 関係の全セッションの会話記録（~/.claude/projects 配下の jsonl）
• メインの会話（isSidechain でない）の assistant 応答だけを数える。message.id で重複を除く
• 1応答の文脈 ＝ input_tokens + cache_creation_input_tokens + cache_read_input_tokens
• 導入前: 10/14〜10/17 の仕組みを入れるまで。導入後: 10/17 の導入から 10/18 まで

	導入前	導入後
応答数	4,676	約1,900
1応答の文脈 平均	476k	115k
中央値	455k	107k
最大	966k	265k（※）
入力のうちキャッシュ読込の割合	99.0%	97.7%

※ 集計スクリプトをそのまま流すと、導入後の最大は 958k と出ます。これは、切り替え直後の約1分間に、導入前から開いていたセッションが返した応答5件です。これを除くと 265k でした。

セッション単位で見ると、差はもっとはっきりします。

	導入前	導入後
セッションの使い方	3本を並行して約23時間続けた	約1日で23本に区切った
1本あたりの入力の累計	158M〜246M トークン	多くは数M〜20M（最も多い1本で約37M）
セッション内の最大の文脈	958k〜966k	多くは 110k〜220k（最大 265k）

導入後の約1日で、/handoff は17回、/clear は22回、/pickup は19回使いました（10/18 時点）。

この数字の読み方（注意点）

• 料金が4分の1になったわけではありません。 入力の97〜99%はキャッシュ読込です。API の料金表では、キャッシュ読込は通常の入力より大幅に安くなっています（Opus 5.5 なら通常の入力単価の5%）。言えるのは「1回の応答で読み込む文脈が約4分の1になった」ことです
• 条件を揃えた比較ではありません。 導入前と導入後では、作業の内容が違います
• 利用制限の計算方法は公開されていないので、「制限に何%効いたか」はこの数字からは言えません

3-2. 測り方

集計に使ったスクリプトを、汎用にしたものです。フォルダ名に含まれる語と、区切りの日時を渡します。

measure_context.py

#!/usr/bin/env python3
"""~/.claude/projects 配下の会話記録から、1応答あたりの「文脈」の大きさを前後で比べる。

使い方: python3 measure_context.py <フォルダ名に含まれる語> <区切り日時> [集計開始日時]
例:     python3 measure_context.py unity 2026-10-17T13:21 2026-10-14
日時は会話記録の timestamp（UTC の ISO 形式）と文字列で比べる。
"""
import glob
import json
import os
import statistics
import sys

KEYS = ("input_tokens", "cache_creation_input_tokens", "cache_read_input_tokens")


def load(keyword):
    seen = {}  # message.id -> (timestamp, 文脈, キャッシュ読込)
    pattern = os.path.expanduser(f"~/.claude/projects/*{keyword}*/*.jsonl")
    for path in glob.glob(pattern):
        with open(path, encoding="utf-8", errors="ignore") as f:
            for line in f:
                if '"assistant"' not in line:
                    continue
                try:
                    o = json.loads(line)
                except ValueError:
                    continue
                # サブエージェント側の応答（isSidechain）は除き、メインの会話だけを見る
                if o.get("type") != "assistant" or o.get("isSidechain"):
                    continue
                m = o.get("message") or {}
                u = m.get("usage") or {}
                total = sum(u.get(k) or 0 for k in KEYS)
                mid = m.get("id")
                # 1つの応答が複数行に分かれて記録されるので message.id で重複を除く
                if total and mid and mid not in seen:
                    seen[mid] = (o.get("timestamp", ""), total, u.get("cache_read_input_tokens") or 0)
    return list(seen.values())


def report(label, rows):
    if not rows:
        print(f"{label}: 応答なし")
        return
    ctx = [r[1] for r in rows]
    cache_rate = sum(r[2] for r in rows) / sum(ctx) * 100
    print(f"{label}: 応答 {len(ctx):,} / 平均 {statistics.mean(ctx) / 1000:.0f}k"
          f" / 中央値 {statistics.median(ctx) / 1000:.0f}k / 最大 {max(ctx) // 1000}k"
          f" / キャッシュ読込 {cache_rate:.1f}%")


def main():
    keyword, cut = sys.argv[1], sys.argv[2]
    start = sys.argv[3] if len(sys.argv) > 3 else ""
    rows = [r for r in load(keyword) if r[0] >= start]
    report("前", [r for r in rows if r[0] < cut])
    report("後", [r for r in rows if r[0] >= cut])


if __name__ == "__main__":
    main()

私の環境での実行結果です（2026-10-18）。

前: 応答 4,676 / 平均 476k / 中央値 455k / 最大 966k / キャッシュ読込 99.0%
後: 応答 1,905 / 平均 115k / 中央値 107k / 最大 958k / キャッシュ読込 97.7%

導入後の応答数は、作業を続けている間は増えていきます（集計した時点で 1,900〜1,907）。平均と中央値は変わりませんでした。

message.id で重複を除いているのには理由があります。会話記録では、1つの応答が複数行に分かれて記録されることがあります。私の記録で試したところ、assistant の行 7,014 行に対して、message.id は 3,153 種類でした。重複を除かないと、応答数も合計も水増しされます。

4. 調べる作業と判断を分ける

2つ目の原則は「判断する役に読ませない」です。

私は、後戻りのコストが大きい判断だけを最上位モデル（Fable 5.1）に頼んでいます。2026-09-05 に、その頼み方で消費がどれだけ違うかを比べました。

頼み方	トークン	ツール実行	所要時間
ファイルを読ませた（アプリの画面評価）	203,133	31回	6分15秒
整理済みの事実だけ渡した（ポートフォリオの配分判断）	53,346	0回	76秒

題材が違う2件の比較です。同じ依頼を2通りで頼んだ結果ではありません。

ファイルを読ませると、上位モデルは自分で探索を始めます。31回のツール実行は、その分の文脈です。

やり方

• 事実を集める作業は、メインの会話か下位モデルにやらせる
• 判断だけを上位モデルに頼む
• プロンプトの冒頭で、読みに行かないよう明示する。出力の字数にも上限を切る

プロンプトの冒頭はこういう形にしています（テンプレート）。

ファイルもリポジトリも読まないでください。事実はすべてこのプロンプトにあります。
回答は800字以内で、結論 → 理由（3点まで） → 確認が要る点、の順に書いてください。

## 判断してほしいこと
<1〜2行>

## 事実
- <数字や状態を1行ずつ。要約しすぎない>

裏面: 切り分けると落ちるもの

この方法には弱点があります。これも書いておきます。

1. 機械的な列挙に切り分けると、出なくなる指摘がある。
09-02 に、ファイルを読ませて画面評価をしてもらいました。そこで出た最重要の指摘は「アプリのコア価値の機能が、導線上ほぼ見つからない」でした。この指摘は、「この画面はメニューの2番目」「この表示はホームの6番目」という事実を並べただけでは出ません。画面を読みながら判断していたから出た指摘です。導線や体験のように、全体を見ないと分からないものは、読ませた方がいい場面があります。

2. 判断材料は要約しすぎない。
配分判断では、転換率を2つ別々に渡しました（32.6% と 8.9%）。だから「片方は露出が足りない、片方はページが足りない」と切り分けた答えが返ってきました。合算した 7.1% だけを渡していたら、この切り分けは出なかったはずです。

つまり、事実は「整理」はしても「圧縮」はしない、という線引きです。

5. 補足

• 確認役のサブエージェントには結論だけ返させる: 2-6 の返し方テンプレートのとおりです。別の文脈に分けても、戻ってくる出力が長ければメインは膨らみます
• モデルの使い分け: 普段は Opus、軽い作業（確認役など）は Sonnet、後戻りのコストが大きい判断だけ Fable にしています
• CLAUDE.md には書き写さず、参照先だけ書く: CLAUDE.md はセッションの開始時に毎回読み込まれます。他のファイルの内容を書き写すと、その分が毎回の文脈に乗ります。なので「正は○○」と参照先だけ書き、中身は必要なときに読ませます

CLAUDE.md（書き方の例）

## 作業の続き
- いまの作業は `<プロジェクト>/docs/作業メモ.md` が正。ここには書き写さない

• 実装を Codex に任せる: 実装作業そのものを Codex CLI に移して、Claude Code 側のトークンを節約する方法もあります。運用ルールは「Claude CodeとCodex CLIの使い分け」に書きました
• CLAUDE.md の書き方全般は「CLAUDE.md 完全ガイド」にまとめています

まとめ

• 会話を長くしない: 12万トークンでフックが知らせます。/handoff で作業メモに書き、/clear で空にし、/pickup で再開します。1応答の文脈は平均 476k → 115k になりました
• 作業メモは「いまの作業」を毎回丸ごと書き直し、行数に上限を切ります。再開時は、メモに無いファイルを先回りして読ませません
• 判断する役に読ませない: 事実の収集と判断を分け、上位モデルには事実だけを渡します。比較した2件では、トークンは 203k → 53k、ツール実行は 31回 → 0回でした
• ただし、全体を見ないと出ない指摘もあります。判断材料は、整理はしても圧縮しすぎないようにします
• 数字は「1回の応答で読み込む文脈」の話です。料金も利用制限も、そのまま4分の1になったとは言えません

参考

• Manage costs effectively（Claude Code 公式）
• Hooks reference（Claude Code 公式）
• Extend Claude with skills（Claude Code 公式）
• Create custom subagents（Claude Code 公式）
• Model configuration（自動コンパクトの位置・1M コンテキスト / Claude Code 公式）
• Environment variables（CLAUDE_CODE_AUTO_COMPACT_WINDOW / Claude Code 公式）
• Commands（/clear・/compact・/context / Claude Code 公式）
• Pricing（プロンプトキャッシュの料金 / Claude Platform 公式）

---

@kotaro_ai_lab
AI活用や開発効率化について発信しています。フォローお気軽にどうぞ！