Claude の長い会話が重くなる前に — トークン消費を抑える4つの実践テクニック

Claude と長時間やりとりしていて、ふと「使用制限まであと少し」という表示に気づいたとき、思わず画面を閉じたくなる気持ちはよくわかります。私も一日に何度も経験しています。

ですがこの「残り少ない」状態、多くの場合は会話側の工夫で避けられます。原因はほとんどが「1つの会話を長く引きずりすぎる」ことによる、過去のやりとりの累積トークン消費です。モデルは返信するたびに、それまでの会話全文を再読み込みしているので、会話が長くなるほど1往復あたりのコストが雪だるま式に増えていくのです。

ここでは実際の開発現場で私が使っている、会話を軽く保つための4つのテクニックをご紹介します。どれも新しい機能を使う必要はなく、今日から運用に取り入れられるものばかりです。

テクニック1: トピックが変わるタイミングで新しい会話を開く

最も効果が大きく、最も忘れがちな基本です。

Claude の会話は、見た目には連続していても、内部では毎回「それまでの全履歴を再送信」しています。つまり、午前中に CSS の相談を10往復した後、午後から全く関係ない API 設計の話に切り替えても、その API 設計の返信には午前中の CSS のやりとり全部が含まれています。

私のルールはシンプルで、話題が変わる瞬間に新しい会話を始めます。目安は次のとおりです。

• 別のファイル・別の機能の話に移るとき
• 1時間以上中断した後に再開するとき
• 返信が明らかに遅くなってきたと感じたとき

「前の文脈を覚えていてほしい」気持ちはよくわかります。ですが、本当に必要な文脈は次のテクニック2で持ち込めば十分です。

テクニック2: 「前回の決定事項」を3行でまとめて新セッションに渡す

新しい会話を開くとき、前の会話から「結論だけ」を持ち込むのが効率的です。

たとえばコードレビューの続きをしたいなら、次のような短い要約を最初に貼り付けます。

前回の会話で決まったこと:
- 認証は Auth0 ではなく自前の JWT で実装
- トークン有効期限は 2時間 / リフレッシュは 30日
- エラーログは Cloudflare Logpush で BigQuery に転送
 
今日はこの前提のもと、ログ欠損対策の実装を相談したいです。

この3〜5行だけで、数百行のやりとりを「再読み込み」しなくて済みます。返信速度も体感で明らかに変わります。

私はこの要約を、前の会話の最後に Claude 自身に書いてもらうようにしています。「この会話の結論を3行でまとめてください。次のセッションの冒頭に貼れる形式で」と頼むだけで、かなり実用的な要約が返ってきます。

要約に「却下した案」を1行足す

引き継ぎ要約で最も抜け落ちやすいのは、決定そのものではなく 決定に至らなかった選択肢 です。

新しい会話に「JWT で実装」とだけ渡すと、Claude は善意で Auth0 を再提案してきます。そこでまた同じ検討をやり直すことになり、せっかく短くした会話がまた膨らんでいく。私は何度もこの往復を無駄にしました。

対策は1行足すだけです。

検討して見送った案: Auth0（月額と依存関係の重さが見合わないため）

理由を短く添えておくと、Claude はその判断基準を引き継いだうえで別の角度から提案してくれます。要約の目的は文字数を削ることではなく、判断の履歴を圧縮して渡すこと。そう捉え直してから、引き継ぎの失敗がほとんどなくなりました。

テクニック3: 長文の添付は「該当箇所だけ」を抜き出す

PDF や長いソースコードを丸ごと添付する前に、ひと手間加えると会話が何倍も軽くなります。

たとえば 200 ページの技術仕様書から特定の API の挙動を調べたいとき、全体を添付するのではなく、以下の手順を踏みます。

1. まず目次だけをコピーして Claude に相談する
2. 関連しそうな章番号を Claude に教えてもらう
3. その章だけを抜き出して改めて添付する

この手間はたった2〜3分ですが、消費トークンは10分の1以下になることも珍しくありません。コードも同様で、ファイル全体ではなく「関数1つだけ」を貼り付けるほうが、Claude の回答精度も上がる傾向があります。

文脈が足りなければ Claude の方から「この関数が呼ばれる側のコードも見せてください」と聞いてくれるので、必要なときに必要な分だけ渡すスタンスで十分です。

テクニック4: Projects の「カスタム指示」を使い回す

Claude Pro の Projects 機能を使うと、毎回繰り返す前置きをプロジェクト側に設定できます。これが地味に効きます。

私の場合、アプリ開発用の Project には次のような指示を設定しています。

- 対象プラットフォーム: iOS 18.0+ / Android 14+
- UI フレームワーク: SwiftUI / Jetpack Compose
- 日本語ユーザー向けアプリなので、UI文言は必ず日本語で提案する
- コードには必ず日本語のコメントを付ける
- エラーハンドリングは try-catch より Result 型を優先する

この 5 行を毎回の会話に手入力する代わりに、Project 側に一度書いておけば、同じプロジェクト配下の全会話で自動適用されます。結果として各会話の「入力プロンプト」が短くなり、累積トークンも減ります。

プロジェクトを分ける目安は「別人が引き継ぐとしたら別資料を渡すかどうか」です。副業のアプリごと、取引先ごと、個人ブログと仕事用、といった単位で分けておくと、後からも探しやすくなります。

どれくらい効くのか — 累積入力トークンの試算

「なんとなく軽くなる」では習慣として続きません。数字にしてみます。

前提を単純化して、1往復あたり利用者の入力が 200 トークン、Claude の返信が 600 トークンとします。モデルは毎回それまでの全履歴を読み直すので、n 往復目の入力トークンは「それ以前の全履歴 + 今回の入力」になります。

往復数が3倍（20→60）になると、累計は9倍を超えます。二次関数的に伸びるので、体感が「少し重い」に変わった時点では、すでにコストは序盤の何倍にもなっています。

では同じ 60 往復を、20 往復ずつ3つの会話に分けたらどうなるか。テクニック2の要約を 150 トークンとして引き継ぐ前提で計算すると、累計は 1,428,000 → 474,000 トークン。およそ3分の1です。40 往復を2つに分けた場合でも 632,000 → 315,000 と半分になります。

手元で条件を変えて確かめられるよう、試算に使ったコードも置いておきます。

U, A = 200, 600  # 1往復あたりの入力 / 返信トークン
 
def total_input(turns, carry=0):
    """turns 往復ぶんの累計入力トークン。carry は引き継ぎ要約のトークン数"""
    total, history = 0, carry
    for _ in range(turns):
        history += U
        total += history   # モデルはここまでの全履歴を読み直す
        history += A
    return total
 
single = total_input(60)
split = total_input(20) + 2 * total_input(20, carry=150)
print(single, split, f"{split / single:.0%}")  # 1428000 474000 33%

U と A をご自身の使い方に合わせて変えてみてください。個人開発でコードを長く貼る場面が多い私の場合は U が跳ね上がるので、テクニック3の効きがさらに大きくなります。

なお、これはあくまで会話の構造から導いた試算であり、Claude Pro の使用制限がこの数字どおりに消費されるという意味ではありません。プランごとの内部的な計算方法は公開されていません。それでも「長い会話ほど1往復が高くつく」という傾向の大きさをつかむには、十分な目安になると考えています。

それでも会話を分けにくいときは

すべての作業がきれいに区切れるわけではありません。数日にわたるリファクタリングのように、文脈そのものが成果物である場合もあります。

そういうときは、会話ではなく 会話の外側に記憶を置く ようにしています。

• 決定事項は会話ではなくファイルに書き、Projects のナレッジに置く
• 設計メモは Claude に Markdown で出力してもらい、リポジトリに docs/ として commit する
• 次の会話では「ナレッジの設計メモを前提に」と一言添えて始める

会話は流れていくものですが、ファイルは残ります。長い会話を維持しようとするより、外に置いた記憶を毎回参照させるほうが、結果として速く安く、そして引き継ぎにも強い。この切り替えは、個人開発で複数のアプリを並行して見ている私にとって、いちばん効いた発想の転換でした。

どれから始めるか

4つ全部を一度に取り入れる必要はありません。私の経験では、次の順番で導入すると負担なく習慣化できます。

1. まずはテクニック1（話題が変わったら新会話）を1週間続ける
2. 慣れてきたらテクニック2（3行要約の引き継ぎ）を追加
3. Projects をすでに使っている方はテクニック4から始めてもOK
4. テクニック3は必要になったタイミングで

テクニック1だけでも、多くの方は使用制限まで到達する頻度が目に見えて下がるはずです。

より深く Claude の内部動作やコンテキスト設計を学びたい方は、Claude のコンテキストエンジニアリング実践ガイド 2026 も合わせてお読みください。

次にやること

今日の会話が少し長引いていると感じたら、まずは Claude に「この会話の結論を3行でまとめて」と頼んでみてください。そのまま新しい会話を開いて要約を貼り付ければ、テクニック1と2を同時に実践したことになります。2分ほどで終わる習慣ですが、効果は翌日から実感できるはずです。