AI エージェントのトークン代を節約するには、どうすればよいでしょうか。

1 つの方法は、プロンプトキャッシュを上手に使うことです。プロンプトキャッシュは、前の問い合わせと先頭が同じ部分を提供元のサーバーに保存しておき、次から安く読む仕組みです。Claude Sonnet 5.5 では、キャッシュから読む部分の料金は通常の入力の 0.05 倍です（プロンプトキャッシュとは）。

では、キャッシュを上手に使うには、どうすればよいでしょうか。その手段の 1 つが compact です。compact（コンテキスト圧縮）は、それまでの会話の履歴を AI が書いた要約に置き換えて、同じ会話を続ける機能です。毎ターン送る履歴が短くなり、キャッシュに載せる量も小さくなります。ただし、使い方によっては、かえって費用が増えます。IT連携マップ編集部が Claude Code で測ると、費用は 57% 減ることも、2.75 倍に増えることもありました。

先に結論

作業が一段落して、キャッシュの保持時間より長く中断する前に compact する（Claude Code では、再開後の費用が 57% 減）
compact の使いすぎも損（間をあけずに続けている間の毎ターンの compact は 2.75 倍）
Context の used が 75% 以上なら compact する（Claude Code の Context は 1M トークン。このあと 2 ターン以上続くとき・試算）
自動コンパクト（auto-compact）は有効のままにする（Claude Code は、端末で開いたまま中断すると約 54 分で自動で要約する）
compact で会話の原文が圧縮されるため、回答の質が落ちる可能性もある（回答の質は今回は測っていない）

全データと測り方、製品ごとの条件は、IT連携マップのガイド「compact とは」にまとめています。

1. compact を使うと、節約できるのか？

節約できるのは、作業が一段落して、キャッシュの保持時間（Claude Code のサブスクリプションは約 1 時間）より長く中断する前に compact したときです。

上の図は、約 5.4 万トークンの会話を 65 分あけて再開したときの費用を、料金の区分ごとに分けたものです。前のターンと同じ部分はキャッシュから入力の 0.05 倍で読まれ、新しい部分はキャッシュへ入力の 2 倍で書き込まれます。この 40 倍の差が、費用を分けました。

compact しないで再開すると（$0.182）: キャッシュが消えているので、履歴を全部キャッシュへ書き直し、費用のほとんどがこの書き込みになりました。
作業が一段落したときに compact すると（$0.078・57% 減）: 書き直すのは短い要約だけで済みました。
作業を再開してから compact すると（$0.155・15% 減）: 消えた履歴を通常の入力の料金で読み直すので、少ししか減りませんでした。
端末で開いたまま置くと（$0.171）: Claude Code がキャッシュの消える少し前に自動で compact し、要約が無い場合の見積もりの 32% で済みました。

つまり compact が効くのは、長い履歴のキャッシュへの書き直しを、短い要約の書き込みに替えられるとき です。段ごとの数は、ガイドの「タイミング別の費用の内訳」にあります。

正確に読むために、2 つの点を補います。

自動コンパクトで、どれだけ減るか: 同じ自動コンパクトを測った suwa_nobu さんの記事では、費用は閉じて再開した場合の約 1 割でした。編集部は 32% でした。違いの原因は、比べた相手（編集部は見積もり、その記事は実測）、会話の大きさ（編集部は約 14.4 万トークンで、既定の条件の 20 万トークンを 10 万トークンに下げて測った。その記事は約 21 万トークン）、要約の後に Claude Code が付け直すツールなどの一覧の大きさです。詳しくはガイドの「作業を中断している間の自動コンパクトの測定」へ。
保持時間の条件: 1 時間保持になるのは、プランの利用枠の中のメインの会話だけです。compact の要約の呼び出しやサブエージェントは 5 分保持で、API キーで使うときと、利用枠を超えて usage credits で払うときは、メインの会話も 5 分保持です。今回の測定の会話は、全部 1 時間保持でした。確かめ方と、使い方ごとの保持時間はガイドの「キャッシュの保持時間」へ（@Skillselion さんのコメントからヒントをいただき、IT連携マップ編集部が公式の説明と測定の記録で確かめた結果です。ありがとうございました）。

では、こまめに compact すれば、もっと安くなるのでしょうか。

2. compact の使いすぎに注意！

間をあけずに作業を続けている間に compact すると、費用は増えます。同じ会話を、間をあけずに 10 ターン続け、/compact の回数だけを変えると、作業の区切りで 1 回の compact でも費用は 22% 増、毎ターンの compact では 2.75 倍 になりました。

毎ターン compact すると、10 ターン目に送る量は 3 分の 1 になりましたが、費用は 2.75 倍 になりました。増えた $0.428 の内訳は、キャッシュへの書き込み +$0.198、要約の本文の出力 +$0.161、キャッシュを使わない入力 +$0.088 です。キャッシュから読む料金は $0.019 しか減りませんでした。

理由は、1 節の費用の前提のとおりです。作業を続けている間は、履歴はキャッシュから入力の 0.05 倍で読まれるので、送る量を減らしても費用はほとんど下がりません。一方、compact するたびに、要約の本文を出力（$10／1M トークン）で書き、その要約を次のターンでキャッシュへ入力の 2 倍の料金で書き直します。回数を変えた測定の全部の数は、ガイドの「回数を変えた測定の数」にあります。では、いつ compact を使えばよいのでしょうか。

3. いつ compact を使えば良いか？

Context の used（会話の大きさ）	compact した方が安いのは（試算）	元が取れるまで（試算）	compact の費用（試算）	1 ターンで安くなる額（試算）
5%（5 万トークン）	このあと 20 ターン以上続けるとき	19.1 ターン	$0.0594	$0.0031
10%（10 万トークン）	このあと 8 ターン以上続けるとき	7.9 ターン	$0.0644	$0.0081
25%（25 万トークン）	このあと 4 ターン以上続けるとき	3.4 ターン	$0.0794	$0.0231
50%（50 万トークン）	このあと 3 ターン以上続けるとき	2.2 ターン	$0.1044	$0.0481
75%（75 万トークン）	このあと 2 ターン以上続けるとき	1.8 ターン	$0.1294	$0.0731

試算の前提（測った値）: 約 5.4 万トークンの会話の /compact 1 回 — 履歴をキャッシュから読む分のほか、固定の分 $0.0242（要約の本文の出力 1,875 トークンなど）・次のターンのキャッシュへの書き直し $0.0302・要約の後の 1 回の入力 18,891 トークン。大きな会話では要約も長くなり、ターン数はこれより増える可能性がある

compact を使うのは、作業が一段落して 1 時間以上あける前と、Context の used が大きく、そのあとも同じ作業を続けるときです。後者の目安は、上の表の 2 列目のとおりです。たとえば used が 75% なら、このあと 2 ターン以上続けるときは compact した方が安く、あと 1 ターンで作業を終えるときは compact しない方が安く済みます（試算）。

used は、Claude Code の Context の欄に出る、コンテキストウィンドウ（1M トークン）のうち使っている割合です。間をあけずに作業を続けるとき、compact の費用（要約の呼び出しと、要約のキャッシュへの書き直し）は、その後のターンで読む量が減る分で取り戻します。used が大きいほど、1 ターンで安くなる額が大きいので、早く元が取れます。上の表は、測った値から計算した試算です。

状況	compact するか
作業が一段落して、1 時間以上あける	する。キャッシュが消える前に要約しておくと、再開したときの費用が 57% 減
used が 25% 以上で、同じ作業をこのあと 4 ターン以上続ける	作業の区切りで 1 回する。used が 75% なら 2 ターン以上で元が取れる（試算）。自動コンパクトが作業の途中で働くのも防げる
あと 1 ターンで作業を終える	しない。表のどの used でも、元が取れるまで 1.8 ターン以上かかる（試算）
used が 10% 以下で、同じ作業をまだ続ける	しない。元が取れるまで 7.9〜19.1 ターンかかる（試算）。毎ターンの compact は 2.75 倍
作業が終わって、別の作業を始める	compact より `/clear` か新しい会話。前の作業の履歴は、次の作業には要らない
作業を始めたばかり	しない。まだ要約する履歴が無い

試算は、約 5.4 万トークンの会話で測った 1 回の compact（要約の本文の出力 1,875 トークン、要約の後の 1 回の入力 18,891 トークン）を元にしています。大きな会話では要約も長くなるので、実際のターン数はこれより多くなる可能性があります。試算の式は、ガイドの「元が取れるまでのターン数の試算」にあります。手で打たなくても、Claude Code が自動で compact することもあります。

4. 自動コンパクト（auto-compact）とは？

自動コンパクト	働くとき	止め方・変え方
上限に近づいたとき	会話がコンテキストウィンドウの上限に近づいたとき。1M トークンのコンテキストウィンドウのモデル（Claude Sonnet 5.5 など）は約 967K トークン	`/config` の Auto-compact（`"autoCompactEnabled": false`）で止める。`/autocompact 500k` のように早める（100K〜1M）
作業を中断している間	端末で開いたまま、最後の問い合わせから約 54 分たち、PC がスリープしていないとき。1 時間保持のメインの会話（サブスクリプションで、利用枠の中）で、既定で 20 万トークン以上	`"idleCompaction": false` で止める。`CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS` で会話の大きさの条件を下げる（10 万トークンまで）

自動コンパクト（auto-compact）は、Claude Code が、上の表の 2 つの場合に自分で compact する機能です。compact するタイミングは Claude Code が決めます。作業を中断している間の自動コンパクトは、キャッシュが消える少し前に働くので、編集部の測定では 68% 減 でした。一方、上限に近づいたときの自動コンパクトは、作業の途中で働くことがあります。端末を閉じると、作業を中断している間の自動コンパクトは働きません。Codex と Antigravity も、会話が長くなると自動で要約します（製品ごとの条件）。設定の名前と値は、ガイドの「設定はどこで変えるか」にまとめています。では、Claude Code の画面では、compact するかどうかをどう見分けるのでしょうか。

5. Claude Code の例

Claude Code の画面では、Context の欄で、何がコンテキストを占めているかを見て決めます。会話（Messages）が大きければ compact が効き、指示ファイル（Memory files）が大きければ、compact ではなく AGENTS.md・CLAUDE.md を縮めます。Claude Code デスクトップ版の「Context」の欄（端末では /context）は、コンテキストを何が占めているかを示します。欄の右下の 「Compact session」 ボタンは、名前のとおり会話を要約（compact）するボタンです。端末では /compact と打ちます。

右の画面で compact が効かないのは、指示ファイル（AGENTS.md・CLAUDE.md）が会話の履歴ではなく、要約の後もファイルから読み直されるからです（Claude Code の公式）。編集部は、指示ファイルを 867 KB から 57 KB に要約して縮め、Memory files を 349.4k から 34.9k トークンにしました。最後に、compact を使うときの注意点を見ておきます。

6. compact を使う時の注意点

要約に書かれなかった事は消える: 要約の本文（3,236〜4,006 字・英語）には、書き方の決まりと直した段落が残りましたが、最初に貼った文章（39,875 字）の原文は消えました。要約した会話は、原文の一文を尋ねられて、作り話をせず「書けない」と答えました。消えて困る資料は、会話に貼らずにファイルに置き、要約の後に読ませます（長い資料は貼るか、ファイルで渡すか）。要約で回答の質がどれだけ落ちるかは、今回は測っていません。長い会話で指示に従わなくなるときの直し方は、長い会話で AI エージェントが最初の指示に従わなくなるときにまとめています。
残したい事は指示できる: /compact に続けて残したい事を書くと（例: /compact 認証の不具合の直しに絞って）、要約はその指示に沿って残す事を選びます（Claude Code の公式）。
要約にも費用がかかる: キャッシュが消えた後の要約は、要約の呼び出しだけで 11 セントかかりました（作業が一段落したときなら 3 セント）。
作業を中断している間の要約は、端末を閉じるか、PC がスリープすると働かない: 端末を閉じている間と、PC がスリープしている間は、54 分たっても要約が行われません。長く中断するときは、閉じる前に自分で /compact します（1 節の 57% 減）。
指示ファイルを直したら、compact の後に効く: 要約の後、AGENTS.md・CLAUDE.md はファイルから読み直されるので、書き換えた指示が読まれます。

要約の本文に何が残ったかの採点は、ガイドの「要約すると、何が残り、何が消えたか」にあります。

最後に

compact は、使わなくても、使いすぎても損をします。上の図は、測った 5 つの使い方の費用を、compact しない場合を 100% として並べたものです。キャッシュへの書き込みは、キャッシュから読む料金の 40 倍です。compact が得になるのは、長い履歴の書き直しを短い要約に替えられるとき、つまり作業が一段落して長く中断する前と、Context の used が大きいまま作業を続けるとき（used が 75% なら、このあと 2 ターン以上）です。指示ファイルが大きいときは、compact ではなくファイルを縮めます。

全データと測り方、設定の一覧は、次のガイドで公開しています。

compact の前提になる言葉と、要約で指示が落ちたときの直し方は、次のガイドにまとめています。

今回取り上げた製品とモデルのページ: Claude Code・Claude

関連記事・参考

Settings reference（Claude Code 公式）
― 作業を中断している間の自動コンパクト（idleCompaction）と、自動コンパクト（autoCompactEnabled）の条件と止め方の出典です。
Model configuration（Claude Code 公式）
― 1M トークンのコンテキストウィンドウのモデルが約 967K トークンで自動コンパクトをすることと、/autocompact の出典です。
How Claude Code uses prompt caching（Claude Code 公式）
― 要約がキャッシュに与える影響と、作業の区切りで /compact する勧めの出典です。
Prompt caching（Anthropic 公式）
― キャッシュから読む料金（Claude Sonnet 5.5 は入力の 0.05 倍）と、キャッシュへの書き込みの料金（1 時間保持は 2 倍）の出典です。
「Claude Code の長い会話は、閉じずに席を外したほうが安かった。1時間後に戻った費用は閉じた場合の1割」（Qiita）
― 作業を中断している間の自動コンパクトを、既定の条件のまま約 21 万トークンの会話で測り、端末を閉じて再開すると要約が働かないことも確かめた記事です。本稿の 1 節（作業が一段落したときの /compact）は、その記事が測っていない、中断の前に自分で /compact した場合にあたります。

読者アンケート実施中
このテーマをもっと深掘りしてほしい方は、記事に「いいね」をお願いします。「いいね」の多いテーマから順に追加調査し、結果は新着記事でお知らせします（フォローしていただくと通知が届きます）。