AIのトークン節約術｜コストを抑えるプロンプトの書き方2026

結論から言うと、対話が長引くAIセッションでは、送信されるトークンの大半が「前回までの前提を読み直すためだけ」に使われている。会話ログが伸びるほど、AIは同じ文脈を毎ターン律儀に読み返すことになり、コストと応答速度の両方が犠牲になる。トークン節約は倹約の話ではなく、AIを実務でストレスなく使い倒すための設計スキルだ。

なぜトークンを気にする必要があるのか

トークン管理を怠ると、請求書より先に体感速度で損をする。入力トークンが積み上がるほど、モデルが応答を生成し始めるまでの時間は伸びる。API従量課金なら金額に跳ね返るし、Claude Codeのようなサブスクリプション型ツールでも、セッションあたりの利用可能量を先に使い切ってしまえば、その日はもう使えない。

影響は3つの軸に分かれる。コスト（従量課金の請求額）、速度（Time to First Tokenの遅延）、上限（コンテキストウィンドウとレート制限）だ。多くの人はコストだけを気にするが、実務でボトルネックになりやすいのは速度と上限の方だ。長いCLAUDE.mdを読み込ませたまま何十ターンも会話を続けているセッションは、後半になるほど一手ごとの待ち時間が伸びていく。

Claude Sonnet 5は2026年8月31日まで1メガトークンあたり入力$2・出力$10の導入価格で提供されている（9月1日以降は$3/$15に移行予定、Claude公式料金ページより）。この価格自体は安くなっているが、無駄なコンテキストを送り続ければ、単価が下がった恩恵はそのまま相殺される。単価交渉ではなく、送る量を減らす設計の方が効くという話だ。

トークンはどこで溶けているのか

節約を考える前に、内訳を知る必要がある。見落とされがちなのは、会話の「本題」よりも「前置き」の方が重い、という事実だ。

システムプロンプトとCLAUDE.mdの重さ

CLAUDE.mdやカスタムシステムプロンプトは、セッションを開始するたびに毎回まるごと読み込まれる。500行のCLAUDE.mdを書いてしまうと、1ターン目の「こんにちは」に返信するだけで、すでに数千トークンを消費している計算になる。ここは見落としがちだが、会話が1往復で終わるような軽い作業でも、この固定費は必ず発生する。

会話履歴の複利的な増加

Claude Codeのようなエージェント型ツールは、基本的に会話履歴全体を毎回モデルに送り直す。10ターン目のやり取りには、1〜9ターン目の内容がすべて乗っている。これは複利で効いてくる。/clearを使わずに1つのセッションで別タスクに乗り換えると、無関係な過去の文脈を延々と払い続けることになる。

ツール結果とMCPの出力

ファイル読み込みやWeb検索、MCPサーバー経由のAPI呼び出しの結果も、そのままコンテキストに積まれる。もったいないと感じるのが、数千行のログファイルをそのまま読ませて「エラー箇所だけ教えて」と聞くようなケースだ。必要なのは数行なのに、支払っているのは全文の分量になる。定番のMCPサーバーを闇雲に全部つないでおくと、ツール定義そのものが常時コンテキストを圧迫することもある。用途別に必要なものだけ選ぶ意識が要る。MCPのツール定義や大量ログの扱いを絞ったら、次に効くのがプロンプトキャッシュだ。

プロンプトキャッシュで入力コストを最大90%削る

同じ前提（CLAUDE.md、長いシステムプロンプト、参照ドキュメント）を毎回律儀に送っているなら、それはもう損だ。Anthropic公式ドキュメントは、キャッシュへの書き込みは通常の入力単価の1.25倍(5分キャッシュ)または2倍(1時間キャッシュ)かかる一方、キャッシュを読み込む側は通常単価のわずか0.1倍で済み、レイテンシも2倍以上短縮すると説明する。

5分キャッシュと1時間キャッシュの使い分け

対話が途切れ途切れになる作業には1時間キャッシュ、短時間で連続してやり取りする作業には5分キャッシュが向く。Claude Codeは内部でこの仕組みを自動的に使っているため、利用者が明示的に設定する場面は多くない。ただしAPIを自前で叩いてツールを組む場合は、キャッシュ対象をプロンプトの先頭側（変化しない部分）に寄せる設計を自分で意識する必要がある。順序を間違えると、キャッシュが毎回無効化されて効果が出ない。

CLAUDE.mdを「太らせない」書き方

キャッシュを効かせる設計まで固めたら、次はキャッシュに乗せる中身そのもの――CLAUDE.md――を軽くする番だ。CLAUDE.mdは短いほど強い。行数を増やして網羅性を上げるほど、皮肉にも読まれなくなっていく。これは人間のドキュメントと同じ力学だ。

禁止リストではなく許可リストで書く

「〜してはいけない」を並べたルールは、例外処理のたびに行数が増えていく。逆に「これだけをする」という許可リスト形式にすると、同じ意図を短い行数で表現できる。

# NG: 禁止リスト型（膨張しやすい）
- テストを書かずにコミットしてはいけない
- console.logを残したままpushしてはいけない
- any型を使ってはいけない（ただしvendor/配下は除く）
- 未使用のimportを残してはいけない
- ...（例外が出るたびに行が増える）

# OK: 許可リスト型（短く保ちやすい）
このプロジェクトの唯一の型チェックコマンド:
  npm run typecheck && npm run lint
このコマンドが通ることだけを完了条件とする。

許可リスト型は「何をすれば合格か」だけを書くため、例外のたびにルールを追記する必要がない。結果としてファイル自体が太りにくい。

詳細情報はSkillsやサブエージェントに逃がす

頻度の低い作業手順（デプロイ手順、特定フレームワークの規約など）まで、CLAUDE.mdに常時読み込ませておく必要はない。必要なときだけ呼び出されるSkillやサブエージェントの定義側に移すと、通常のセッションで払う固定費が下がる。CLAUDE.mdは「毎回必要な最小限」、Skillsは「必要なときだけの詳細」という役割分担で設計する。ゼロから設計を組み直す場合は役割ごとにペルソナを分ける設計や、設定ファイルの書き方そのものの整理から見直すと、後からの圧縮がしやすくなる。

会話中のコンテキスト管理コマンド

CLAUDE.mdを削っても、会話が長引けば結局コンテキストは膨らむ。そこを手動で締めるのが/clearや/compactの役目だ。セッションを長く使い続けるなら、手動でコンテキストを整理する習慣が要る。Claude Code公式ドキュメントが案内する通り、そのための専用コマンドがある。

いちばん効果が大きいのは/clearだ。古いコンテキストを残したまま新しいタスクを始めると、関係ない情報に毎回トークンを払い続けることになる。タスクの切れ目で/clearを打つ。これだけで会話が長く続くセッションの消費量は大きく変わる。

サブエージェントに「重い調査」を任せる設計

手動でのリセットはメインの会話にしか効かない。大量のファイルを読ませる調査そのものを別枠に逃がすのがサブエージェントだ。サブエージェントは独立したコンテキストウィンドウで動くため、どれだけ大量の情報を読み込んでも、メインの会話には要約結果しか返ってこない。

独立コンテキストウィンドウの仕組み

たとえば「このリポジトリ全体からAPI呼び出し箇所を洗い出して」という調査を、メインの会話で直接やらせると、読み込んだファイルの中身がそのままメインのコンテキストに積み上がる。サブエージェントに委譲すれば、ファイルを何十個読もうと、その中身はサブエージェント側のコンテキストで完結し、メイン側には結論だけが届く。サブエージェントは、棚卸しを頼む倉庫番のようなものだ。棚を何段も見て回っても、戻ってくる報告は「在庫はあと3個」の一行で済む。

モデルを役割で使い分ける

全部を最上位モデルにやらせる必要はない。単純な検索・ファイル探索はHaiku級、通常の実装作業はSonnet級、設計判断や難しいレビューだけをOpus級に回す。役割ごとにモデルを分けると、同じ作業量でも合計コストは下がる。

業務別・節約プロンプトの型

ここまでの原則を、よく使う3つの業務パターンに落とし込む。プロンプトエンジニアリングの基本を押さえた上で、さらに「送る量」を絞る視点を加える形だ。議事録以外の例文は業務別プロンプトレシピ集にまとめてある。

長いログ調査は「範囲指定」を先に書く

エラーログを丸ごと貼るのではなく、対象範囲と欲しい出力形式を先に指定する。範囲を絞る一文があるだけで、AIはログ全体を精読する必要がなくなり、応答も的確になる。

直近のエラーログから、HTTP 500が発生した箇所だけを
タイムスタンプ・エンドポイント・エラーメッセージの3列で
表にまとめて。500以外の行は無視してよい。

コードレビューは「差分だけ」を渡す

ファイル全体を貼ってレビューを頼むと、変更していない部分まで読み込ませることになる。差分（diff）だけを渡し、影響範囲の判断が必要なときだけ追加でファイルを読ませる、という順序にすると無駄が減る。

この差分だけレビューして。
バグの可能性がある箇所のみ指摘し、
スタイルの好みレベルの指摘は不要。
git diff HEAD~1 の出力を貼り付け:
（ここにdiffを貼る）

議事録・要約は出力フォーマットを固定する

要約系のタスクは、出力フォーマットを毎回説明し直すたびに、数百トークンが目に見えず消えていく。Claude Codeの基本設定に慣れてきたら、頻出フォーマットはCLAUDE.mdやSkillに1回だけ定義しておき、本文側の指示は「このフォーマットで要約して」の一言に短縮する。

節約しすぎて事故るパターン

ここまでの削り方を全部実践すると、今度は削りすぎる方向に振れる人が出てくる。削りすぎは精度事故につながる。トークン節約は目的ではなく手段だ。ここを取り違えると本末転倒になる。

具体的には次のようなケースで事故が起きやすい。/compactを多用しすぎて重要な決定事項まで要約時に欠落する、差分だけ渡してレビューを頼んだ結果、呼び出し元との整合性チェックが漏れる、サブエージェントに丸投げしすぎてメイン側が全体像を把握できなくなる、といった具合だ。節約は「不要な情報を削る」ことであって、「必要な情報まで削る」ことではない。

よくある質問

プロンプトキャッシュは自動で効くのか

Claude Codeなどのエージェント型ツールは、多くの場合、内部で自動的にキャッシュを活用する。自前でAPIを叩く場合は、変化しない部分をプロンプトの先頭にまとめる設計を自分で行う必要がある。

CLAUDE.mdは何行までに抑えるべきか

絶対の基準はないが、数百行を超えたあたりから読み込みコストの遅延が明確に現れる。頻度の低い情報はSkillsや別ドキュメントに逃がし、常時必要な最小限だけを残す方針が扱いやすい。

/clearと/compactはどちらを使えばいいか

タスクが完全に切り替わるなら/clear。同じタスクを継続しながら履歴だけ軽くしたいなら/compact。迷ったら、次の作業に過去の文脈が要るかどうかで判断する。

定期実行するバッチ処理でも節約は効くか

効く。定期実行の自動化フローでは同じテンプレートのプロンプトを繰り返し送ることが多く、プロンプトキャッシュとの相性が特によい。バッチAPIとの併用でさらに単価を下げられる場面もある。

まとめ

トークン節約の本質は、AIに「毎回何を読み直させるか」を設計することに尽きる。CLAUDE.mdを許可リスト型で圧縮し、繰り返す前提はプロンプトキャッシュに乗せ、重い調査はサブエージェントへ逃がす。この3つを押さえるだけで、体感の速度と請求額は目に見えて変わる。