Claude Codeの出力を35%短くしたら、むしろ情報量が増えた——そんな逆説的な実験結果を見て、「これ、自分の運用でも起きてるな」と思った。私はここ1ヶ月、Claude Codeに読ませるタスク台帳を意図的に「全文を読ませない」設計にしている。今回は自分の環境の実測値を出しながら、この逆説を検証してみる。
きっかけになった実験
参考にしたのは jqit_suwa さんの記事。Claude Codeの「Concise」出力スタイルを検証したもので、claude -p --output-format json で同じ3問（Pythonのリスト重複除去・gitコミットメッセージ修正・npm testの失敗対応）をDefaultとConciseで実行し、3問平均で比較していた。
結果は文字数が35%減（697字→456字）、出力トークンが20%減（891→711）。ここまでは「短くなった」だけの話だが、面白いのはここから先で、git コマンドの回答例では、Conciseの方が --no-edit や --author といったオプションが2つ多く提示された。削られたのは説明文（2文→1文）で、実質的な情報（選択肢そのもの）はむしろ増えていたという。
「出力を削っても中身は減らない、むしろ増えることがある」——これは出力側だけでなく、入力側（コンテキストとして何を読ませるか）でも同じことが言えるのでは、と思って自分の運用を見直した。
私の環境で起きていたこと
私はClaude Codeに「秘書」役をやらせていて、タスク管理を1本のMarkdown台帳（tasks.md）で回している。ここに全タスクの優先度・期限・進捗メモを溜め込んでいく運用にしていたが、7月中旬にセッションのトークン消費を分析したところ、次のような内訳になっていた。
前提として、環境はClaude Code CLI + Markdown台帳のみで、専用のプロジェクト管理ツールは使っていない。個人〜小規模のタスク管理が対象なので、大規模チームで既にIssueトラッカー等を使っている場合は事情が変わる可能性がある。
| 読み込み対象 | 実測サイズ | 推定トークン | 備考 |
|---|---|---|---|
| tasks.md（全文） | 約163KB | 約46,500 | 台帳の中で最大レバー |
| handoff.md（引き継ぎメモ） | 約76KB | 約21,700 | 追記型で膨張していた |
| MCPツール定義 | 約64KB | 約16,400 | 常時100ツール超をロード |
| ペルソナ・設定ファイル | 約24KB | 約7,000 | 据え置き |
※トークン数は「日本語はバイト数÷3.5」の概算換算（正確なトークナイザ実測ではなく傾向を見るためのもの）。
毎ターン、セッションを開くたびにこの合計約9万トークン分がまるごと再送されていた。tasks.mdだけを見ると、内訳は「完了タスクの溜め込み」ではなく、未完了タスク1件ごとに数百〜千字の設計メモがぶら下がっていることが主因だった。完了分を退避しても11%しか減らず、根本的な対策にはならなかった。
対策: 「全文を読ませない」ルールに変えた
やったことはシンプルで、CLAUDE.md（Claude Codeがセッション起動時に読む設定ファイル）に、タスク台帳の読み方そのものを制約するルールを1本追加しただけだ。
## Working Memory Restore（トークン節約ルール）
- セッション起動時に tasks.md を全文読み込みしない。
- 代わりに、1タスク=1行に圧縮した「スリム索引」だけを読む。
- 特定タスクの詳細メモが必要になった時だけ、該当行をピンポイントで読む:
`grep "\[T-042\]" tasks.md`
索引の生成自体は、タスク台帳の各行から必要なフィールドだけ抜き出す簡単なスクリプトで自動化している。実際に使っているものを簡略化すると、こんな形になる。
// tasks.md（Markdownのタスク台帳）から1行索引を生成する
const fs = require('fs');
const lines = fs.readFileSync('tasks.md', 'utf8')
.split('\n')
.filter(line => /^- \[ \] \[T-\d+\]/.test(line)); // 未完了タスクのみ対象
const index = lines.map(line => {
const id = line.match(/\[T-(\d+)\]/)[1];
const priority = (line.match(/優先:(\S+)/) || [])[1] || '未設定';
const due = (line.match(/期限:([^|]+)/) || [])[1]?.trim() || '未設定';
const summary = line
.replace(/^- \[ \] \[T-\d+\]\s*/, '')
.split('|')[0]
.slice(0, 40);
return `T-${id} | 優先:${priority} | 期限:${due} | ${summary}`;
});
fs.writeFileSync('tasks-index.md', index.join('\n'));
セッション起動のたびにこのスクリプトで索引を再生成し、Claude Codeが最初に読むのは索引ファイルだけにする。詳細な設計メモが必要な時は、grep で該当タスクの行だけをピンポイントで読ませる。
Before/Afterを実測してみた
7月時点の試算だと、この一手（索引化）だけで削れる量は約35,000トークン。当時の毎ターン合計（約9万〜10万トークン）に対して**約35%**を占めていたレバーだった。数字だけ見ると、参考記事の「35%削減」とほぼ同じ割合になっているのは偶然だが、面白い符合だと思う。
その後1ヶ月ほど運用を続けた今日、あらためて実測してみた。
| サイズ | 推定トークン | |
|---|---|---|
| tasks.md（全文・今の実体） | 616KB | 約176,000 |
| tasks-index.md（実際に読ませている索引） | 52KB | 約14,700 |
| 削減率 | 約92% |
台帳の実体（tasks.md）はこの1ヶ月でむしろ肥大化している。追記型の運用なので、タスクが増えるほど中身は太っていく。それでも起動時にClaude Codeが読むのは索引ファイルだけなので、実際の消費量は「全文を読んでいたら発生していたはずの量」に対して約92%減っている計算になる。台帳が育つのと、毎ターンのコストが増えるのを切り離せたのが、この運用でいちばん効いたポイントだった。
「情報は減っていないか」を確認する
トークンを削るだけなら、情報を捨てているだけかもしれない。ここが今回いちばん確認したかったところだ。
索引の1行フォーマットは「T-番号 | 優先度 | 期限 | PJ | 内容の要約」に固定してある。これは以前、CLAUDE.mdが500行を超えて肥大化し、指示の優先度が曖昧になって応答が遅くなった経験があり、そのときに「ドキュメントにも構造化・優先度付けが要る」と学んだのを、タスク管理にもそのまま当てはめた形だ。
固定フォーマットにしてから気づいたのは、優先度と期限を省略すると索引だけでは判断できず、結局もとの台帳を開き直す羽目になるということ。要約文だけを短くするのは自由だが、判断に直結する項目（優先度・期限・所属プロジェクト）だけは削ってはいけない、と早い段階で線引きした。逆に言えば、それ以外の設計経緯や背景メモは思い切って索引から外しても、日々の「今日どのタスクをやるか」の判断は一切鈍らなかった。
以前、別の場面でLLMのAPI利用料が想定より膨らんでいたことがあり、原因を調べたら不要に長いプロンプトや重複したコンテキスト送信だったことがある。プロンプトの共通部分をシステムプロンプトに集約し、キャッシュ可能な応答をローカルに持たせただけで、トークン使用量はまとまった割合まで落ちた。あのときの学びは「コスト最適化は“何を送るか”の設計が9割」というものだったが、今回のタスク索引化もまったく同じ構造だった。削るべきは「量」ではなく「読ませる範囲」だった。
まとめ
| Before | After |
|---|---|
| tasks.md全文を毎ターン読み込み | 1行索引だけを読み、詳細は必要な時だけgrep |
| 台帳が育つほどコストが増える | 台帳が育ってもコストはほぼ一定 |
| 優先度・期限が長文メモに埋もれる | フォーマット固定で優先度・期限が必ず先頭に来る |
参考記事の「出力を短くしたら情報が増えた」は出力側の話だったが、私の場合は入力側（コンテキスト設計）でも同じ現象が起きた。tasks.mdは実測で92%読み込みを減らしても、判断に必要な情報（優先度・期限・所属）は一切減らしていない。結局のところ、削って良いのは「量」であって「構造」ではない、というのが今回いちばんの収穫だった。
同じようにMarkdown台帳でタスクやメモを運用している人がいたら、「索引に残す項目」と「詳細に追いやる項目」の線引きをどう決めているか気になるところだ。
今回はタスク台帳（tasks.md）側の圧縮までを書いた。次はhandoff.md（引き継ぎメモ）側にも同じ考え方を適用する予定で、こちらは追記型でさらに肥大化しやすいので、別の工夫が要りそうだと思っている。Claude Codeや業務自動化まわりで試したことを不定期に書いているので、続きが気になる方はフォローをどうぞ。