「100万トークンのコンテキストウィンドウがある」という言葉は、まるで何でも解決するかのように使われます。そうではありません。私はこれを遠回りな方法で学びました。コードベース全体を1つの Claude 呼び出しに詰め込んで、エージェントが良くなるどころか悪くなるのを目の当たりにしたのです。コンテキストが多いことは無料ではなく、常に良いとも限りません。コンテキストウィンドウとは実際何なのか、そして大きな数字がいつ助けになり、いつ害になるかを説明します。
ウィンドウとは実際何か
コンテキストウィンドウは、モデルが1回のリクエストで注目できるトークンの最大数です——送信するすべてのもの（システムプロンプト、ツール、完全なメッセージ履歴、ファイル）と、生成するすべてのものを合わせた数です。現在の Claude モデルでは、入力ウィンドウは大きいです：Opus 4.6、4.7、4.8はすべて100万トークンのコンテキストで動作し、Sonnet 4.6も100万、Haiku 4.5は20万です。出力は別途制限されます——Opusモデルでは最大12.8万トークン、SonnetとHaikuでは6.4万トークン。
これらが2つの異なる制限であることに注意してください。入力制限に達すると stop_reason: "model_context_window_exceeded" が返されます。要求された出力制限に達すると stop_reason: "max_tokens" が返されます。これらは異なる意味を持ち、異なる修正が必要なので、両方のブランチを処理してください。人々は常にこれらを混同し、max_tokens を上げても助けにならない理由を不思議に思います——問題が入力側にあったからです。
なぜトークンは単語ではないのか
予算計算に重要なメカニズムの確認です。モデルは単語を見ません；トークナイザーが生成するサブワードのチャンクであるトークンを見ます。英語の文章は単語の約4分の3に対して1トークンで動作します。コードはより密にトークン化されます。英語以外のテキストはさらに密です。
つまり、Claude のトークン数を tiktoken で推定することはできません——それはOpenAIのトークナイザーで、平文では15〜20%、コードではそれ以上 Claude を過小評価します。本当の数字が必要なら、推論を実行するのと同じモデルIDで count_tokens エンドポイントを呼び出してください。トークナイザーはモデル固有です。Opus 4.8とFable 5は同じものを共有します；古いモデルは異なる計算をします。間違ったモデルで測定した予算を使い回さないでください。
誰も警告しない部分：ウィンドウを埋めると品質が下がる
これが直感に反する部分です。100万トークンを詰め込めるからといって、そうすべきという意味ではありません。非常に長いコンテキストの中央に埋もれた情報に対してモデルの注目がより不安定になり、ノイジーなコンテキストはモデルが現在のステップに必要なシグナルを薄めます。同じタスクで、クリーンな2万トークンのコンテキストを持つエージェントが40万トークンの同じエージェントを上回るのを見てきました。40万では、注目していたものの95%が12ステップ前の古いツール出力だったからです。
だから目標は詰め込む量を最大化することではありません。コンテキストを関連性のある状態に保つことです。100万トークンの上限は、真に大きな単一の入力——一度に分析が必要なリポジトリ全体、長いドキュメント、深い調査のトレース——のための安全マージンです。決して片付けなくていいというライセンスではありません。
コンテキストを関連性のある状態に保つ3つのツール
それぞれ異なる問題を解決します；何が問題かによって選んでください。
コンテキスト編集は剪定します。設定したしきい値に基づいてトランスクリプトから古いツール結果と思考ブロックをクリアします。クリアされたコンテンツは削除され、置き換えられません。古いツール出力が死重で、会話の構造を失わずにスリムなトランスクリプトが欲しいときにこれを使います。長いループでツール呼び出しの精度を高く保つのに正しい選択です。
コンパクションは要約します。会話がウィンドウ制限に近づくと、APIはサーバー側で以前の履歴を要約ブロックに凝縮します。本当に上限に達しそうで続けなければならないときに使います。1つの重要なgotcha：毎ターン完全な response.content をメッセージに追加してください——コンパクションブロックはそこにあり、テキストだけ抽出して追加すると、コンパクションの状態が静かに失われてすべてが壊れます。
メモリはセッションをまたいで永続化します。他の2つは1つの会話の中で動作します；メモリはプロセス再起動後も生き残るエージェントが読み書きするファイルです。状態がセッションを超える必要がある場合——好み、蓄積された学習、継続中のメモ帳——それはメモリであり、コンテキストではありません。そして正直なところ、Opus 4.8のようなモデルは、物事を書き留める場所を与えられ、次回確認するよう伝えられると、明らかに良い働きをします。
長期実行エージェントの多くは3つすべてを使います。編集は死んだターンを剪定し、コンパクションは上限近くで捕まえ、メモリはラン間で重要なものを保持します。
私がうまく使ってきた予算ヒューリスティック
コンテキストには3つのゾーンがあると考えてください。凍結されたプレフィックス（システムプロンプト、ツール）——安定を保ち、決して変わらず、ボーナスとしてキャッシュされます。ワーキングセット——現在のステップにモデルが実際に必要とする最近のターン。そして末尾——現在の質問やツール結果。ワーキングセットが多くのターンでモデルが参照していないものでいっぱいになり始めたとき、それが編集またはコンパクションへのキューです。あるトークン数に達したときではありません。関連性が下がったときです。
もう1つの実用的なメモ：大きな出力。Opusモデルで12.8万トークンの出力上限に近い何かを要求する場合、リクエストをストリームしなければなりません。非ストリームの呼び出しは高い max_tokens でSDKのHTTPタイムアウトに達します——リクエストが待機中に死んでしまいます。ストリーミングヘルパーを使って最終メッセージを取り出してください。
100万トークンのウィンドウは本物の機能で、時にはまさに必要なものです。しかし、スキルはそれを埋めることではありません。スキルは、コンパクトで関連性のある3万トークンのコンテキストが膨れ上がった60万トークンのコンテキストを上回るときを知ること——それが、エージェントを構築してきた私の経験では、ほとんどの時です。