3行まとめ

この記事はトークン節約という文脈で取り組んだ、コンテキストエンジニアリング・ハーネスエンジニアリングの話です
作業に必要十分な情報だけをClaude に与える設計が、トークン節約だけでなくClaudeのアウトプットの質にも寄与します
Claude Max 20xプランでもトークンが足りなくなった私の試行錯誤を紹介します

はじめに

Claude Max 20xプランを契約しているのに、思ったよりすぐトークン使用枠の上限に達してしまう。
同じ悩みを持つ人もいるのではないでしょうか。

私は Claude Code で複数エージェントを並列に回しながら、「投資分析」や「個人開発」を行っています。
（Claude Code を利用したスクラム開発の紹介記事はこちら↓）

投資分析と個人開発を複数ターミナルで並列に動かしていると、5時間のトークン使用枠を2時間足らずで使い切ってしまいます。
さすがにこれは厳しい。でも、お財布事情的にこれ以上Anthropicにお布施するのも避けたい。

そこで、Claude のトークン消費を抑えるために試行錯誤したので、その内容をまとめました。
厳密な効果測定はできていないですが、全ての施策を行った結果、今のところ5時間の使用枠を時間内に使い切ってしまうことは起きなくなりました。

前提：何がトークンを溶かしていたのか

まず前提として、Claude のトークン消費は「会話本文」だけで決まりません。

実際には、以下のようなものがトークン消費の要因になります。

コンテキストやrules
MCP や各種ツール設定
長く伸びたセッション（=会話履歴）
大量ファイルの探索や読み込み
JupyterNotebook や画像のような、巨大になりやすいファイルの操作
agents / skills 定義の冗長な説明

つまり、トークン節約とはClaude のコンテキスト構成と作業フローの設計をすることと捉えるべきです。
これはトークン節約だけでなく、Claudeのアウトプットの質を向上させることにも繋がります。

今回やったこと8選

サマリ

以下の施策を行いました。一つずつ説明していきます。

No.	施策	解決した課題
1	`.claude/`を整理整頓した	Claude設定が重く、オーバーヘッドが増加していた
2	“原始人”的な会話を導入した	意味を持たない日本語表現がトークンを消費していた
3	`jupytext`でJupyter操作を軽量化した	ClaudeにとってJupyterNotebookは重かった
4	セッションの長さを最適化した	長いセッションを引きずることでトークン消費が増えていた
5	ローカルLLMでナレッジをRAG化した	Claudeが大量のファイルを読む構成になっていた
6	エージェントの役割に応じたモデルを選択した	単純な作業に高性能なモデルを使っていた
7	sandbox設定を導入した	Claudeが見る必要のない上位ディレクトリまで見に行く挙動があった
8	`.claudeignore` をちゃんと設定した	読まなくていいファイルを読んでいた

1. `.claude/`を整理整頓した

試しに入れたまま放置していたプラグインや MCP を見直し、必要最低限まで絞りました。
特に ルートの Claude 設定（~/.claude/）は極力軽くし、共通で使うもの以外は各作業リポジトリ内の設定へ寄せました。

rules は自動で読み込まれるため、配置場所や pathsフロントマターの設計が重要です。

---
paths:
  - "**.py"
---
# Python開発ルール
> .pyファイルを操作するときだけ読ませるルールをここに書く

また、agents / skills も断捨離しました。
少なくともフロントマターを整えて、Claude が毎回すべてを読まなくても済む状態にしておきたいところです。

これだけでも、「とりあえず色々 Claude に突っ込んでいる」状態からは大きく改善できます。

2. “原始人”的な会話を導入した

次に導入したのが、「原始人」的な会話手法です。

詳細は上の記事を見て欲しいですが、意味を保ったまま無駄な表現を削るアプローチです。

私は以下を、全エージェントに読ませる rules として導入しました。

# 出力トークン圧縮

全出力に適用。

## 削除対象

- 敬語・丁寧語 → 体言止め・用言止め（です/ます/ございます 禁止）
- クッション言葉（えーと/まあ/ちなみに/一応/基本的に）
- 前置き（ご質問ありがとうございます等）
- ぼかし（〜かもしれません/〜と思われます/おそらく）
- 冗長助詞（〜することができる → 〜できる）
- 冗長接続（〜ということになりますので → だから）
- 自明な助詞（が/の/を/に/で/は — 意味通じるなら省略）
- 形式名詞（設定を変更すること → 設定変更）
- 補助動詞（動いている → 動作中）
- 意味重複（同義語の近接繰り返し → 片方削除）
- 自明な述語（文脈から推測可能な動詞・形容詞）
- 情報水増し（聞かれたことだけ答える。網羅的列挙・補足・例コード自発生成 禁止）

## 許可テクニック

- 体言止め・用言止め
- 短い同義語置換（大規模な → 大きい）
- キーワード列挙（助詞省略しスペース区切り）
- 漢字連結で助詞省略（高負荷時に高速 → 高負荷時高速）
- 和語→漢語化（速く動作 → 高速動作）
- 格助詞「で」→漢字連結（Dockerで起動 → Docker起動）
- 接続助詞 → 矢印「→」代替

## 適用除外

- コード・コミットメッセージ・PR本文
- ユーザーへの破壊的操作の確認（安全弁: 通常の丁寧な日本語に復帰）

また、アウトプットだけでなく、以下のようなインプットも同様に圧縮しました。

コンテキストや rules
agents / skills 定義
設計書などのドキュメント類

3. `jupytext`でJupyter操作を軽量化した

投資分析では JupyterNotebook(.ipynb) を並列に作成させることが多いのですが、これがトークンを大量に消費していました。

そこで調べてみると、.ipynb をそのまま扱うのはClaudeにとって重い作業になりやすいことが明らかになりました。
.ipynb の中身に matplotlib のグラフなどが base64 エンコードされた画像として含まれるケースが多いためです。
そのためファイル1つが非常に大きくなりやすく、さらに Claude Code はセッション内で同じファイルを繰り返し操作するので、消費がどんどん膨らみます。

そこで、Claude には .ipynb ではなく .py だけを触らせる構成に変えました。
jupytextを使って.ipynbと.pyを同期することで、人間は.ipynbを、Claudeは.pyを扱うようにしたんです。

フローは次の通りです。

Claude が .py を編集する
jupytext --sync で .ipynb に反映する
ユーザーが JupyterLab 側で実行・閲覧する

この 2 の手順を hooks で自動化し、Claude が .py を編集するたびに .ipynb に反映されるようにしました。

私の環境では、この変更は1回のJupyter操作あたり「約94%のトークン削減」効果があるとClaudeは評価していました。（本当か？）
効果はNotebookの内容次第で変わるはずですが、やったことの内容から考えても少なくない効果があることは明らかです。

Claude に markdown やコード以外のファイルを操作させている場合は、無駄なトークンを消費していないか疑ってみる価値があります。

4. セッションの長さを最適化した

セッションが長引くほど、過去のやり取り全体が後続のコストに乗ってきます。
そのため、文脈や作業の切れ目では積極的に /clear してセッションをリセットするようにしました。

また、長期フローを一つのSkillで実行していた箇所は、複数Skillに分割しました。
Skill間は以下のような中間成果物で情報を受け渡し、その際にセッションをリセットする設計にしました。

作業計画書
ディベートサマリ
次工程向けの引き継ぎファイル

作業計画書の作成はもともとは作業中にClaudeの記憶が薄れることへの対処として入れた施策ですが、その作成タイミングでSkillとセッションを切り替える設計も追加したことでトークン節約の面でも効果を出すことができました。

5. ローカルLLMでナレッジをRAG化した

Claude に大量のファイルを読ませなくても、必要な知識だけ自然言語で引き出せるように、ローカル LLM を使って RAG を構築しました。
以下がその時の記事です。

狙いは、Claude が探索のために大量のファイルを読む状況を減らすことです。

たとえば、複数のドキュメントから現在の設計を把握するタスクがあるとします。
このとき、Claude にすべてのドキュメントを読ませるのではなく、次のようなフローにします。

事前にローカル LLM 側でドキュメントをベクトル化しておく
Claude からは、設計把握に必要な質問だけをローカルLLMに投げる
ローカル LLM が関連ドキュメントを検索して回答する
Claude はその回答をもとに設計を把握する

このようにすると、Claude が毎回大量のドキュメントを探索する必要がなくなります。

RAG だけでなく、こうした単純な作業をローカル LLM に任せる設計は、Claude のトークン節約に有効だと感じています。

6. エージェントの役割に応じたモデルを選択した

すべての作業に高性能なモデルを使う必要はありません。
単純な整形、分類、要約、検索補助のような作業は 軽量モデル（Haiku, Sonnet） に寄せてしまっても性能に大差ないと感じています。

7. sandbox設定を導入した

これはもともとセキュリティ文脈で導入したものですが、結果としてトークン節約にも効いていそうなので紹介します。

.claude/settings.json に sandbox設定を入れると、Claude が無駄に上位ディレクトリまで見に行こうとする挙動をしなくなります。
その結果、探索範囲が狭まり、不要なファイルや文脈に触れにくくなります。

8. `.claudeignore` をちゃんと設定した

最後は基本ですが、読まなくてよいファイルを .claudeignore にちゃんと入れました。
以下のようなサイズが大きいけど読む意味のないファイル群は最初からClaudeの目に入らないようにしましょう。

大きなデータファイル
参照不要なビルド成果物

まとめ

Claude のトークン節約のために始めた必要十分な情報のみを与える設計は、昨今のコンテキストエンジニアリング・ハーネスエンジニアリング文脈の取り組みと非常に類似したものになりました。

Anthropic公式の記事では、AIエージェントの質を高める方法を以下のように説明しています。

"good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome"
（適切なコンテキストエンジニアリングとは、望ましい結果が生じる確率を最大化する、信号強度の高いトークンの最小限の集合を見出すことを意味する。）
"Regardless of how you decide to structure your system prompt, you should be striving for the minimal set of information that fully outlines your expected behavior."
(システムプロンプトをどのように構成するにせよ、期待される動作を完全に説明できる最小限の情報セットを目指すべきです。)

トークンが足りなくなるという状況は、裏を返せばコンテキストや運用フローを見直す余地も大きい可能性があり、そこに取り組むことが回り回ってAIエージェントのアウトプットの質を引き上げることになるかもしれません。

おわりに

"原始人"アプローチの延長で、一時期ネットで話題になった偽中国語的なアプローチを試してみるのも面白いかなあ。

私：是system試験全部通過？
Claude：Yes. 以下結果要約。請FB。

とか会話できたらめっちゃトークン節約できそうですよね〜。