Claudeのトークン数・コンテキスト長と上限の対処法

トークンとコンテキスト長──Claudeの「作業机の広さ」

Claudeは文章を「トークン」という小さな単位に区切って処理します。日本語ではおおよそ1〜2文字が1トークンに相当することが多い、と考えてください。そして、Claudeが一度に見渡せるトークンの総量には上限があり、これをコンテキスト長（コンテキストウィンドウ）と呼びます。

例えるなら「作業机の広さ」です。机の上に載っている書類（今までの会話・渡した資料）は全部見ながら作業できますが、机の広さを超えた分は載せられません。Claudeのコンテキスト長は業界でも大きい部類で、書籍1冊分を超える文章を一度に扱えるモデルもありますが、それでも無限ではありません。

上限に近づくと何が起きるか

• 古いやり取りを参照できなくなる──会話の序盤で決めた前提を、終盤で忘れたような応答になる
• 長文の貼り付け・アップロードがエラーになる──一度に渡せる量を超えている
• 応答の質が下がる・遅くなる──机の上が書類で一杯の状態では、必要な情報を探すのも大変になる、というイメージです
• 会話の上限に達した通知が出る──その会話ではそれ以上続けられなくなる場合があります

「Claudeが急にバカになった」と感じる場面の少なくない割合が、実はこのコンテキストの問題です。故障ではなく仕組みなので、対処法を知っていれば回避できます。

実践的な対処法

1. 会話を「1作業1会話」で区切る──1つの会話を延々と使い続けるより、作業の区切りで新しい会話を始める方が、品質もスピードも安定します
2. 引き継ぎメモを作らせてから新しい会話へ──長い会話を離れる前に「ここまでの決定事項と前提を箇条書きにまとめて」と頼み、そのまとめを新しい会話の冒頭に貼ります。これで机の上を「要点だけ」に整理した状態で再スタートできます
3. 資料は必要な部分だけ渡す──100ページの資料で使うのが第3章だけなら、第3章だけを渡します。全部渡すと机が埋まるだけでなく、関係ない情報に引きずられる原因にもなります
4. 繰り返し使う資料はProjectsへ──毎回貼り直すより、プロジェクトの知識として置いておく方が管理しやすくなります
5. 長文処理は分割して段階的に──長大な文書の要約は、章ごとに要約→要約同士を統合、という2段階にすると上限を回避しながら品質も保てます。詳しくは長文整理の基本で扱っています

開発者向け：APIでのコンテキスト管理

API利用では、コンテキスト長はコストに直結します。毎リクエストで長い前提資料を送り続ける設計は、上限だけでなく料金面でも不利です。繰り返し使う部分にはキャッシュの仕組みを活用し、会話履歴は要約して圧縮するなどの設計が定石です。基本はClaude APIの基本で整理しています。