Token Limit

トークン上限とは、一回の対話呼び出しにおいて、入力（あなたが提供するデータや指示）と出力（Claudeが生成する返答）を合わせた総量に固定の上限があることを指す。この上限の計算単位はトークンであり、文字数ではない。一つのトークンはおおよそ中国語の文字の何分の一か、英単語の断片に相当し、言語によって換算比率も完全には同じではない。これは一般に理解されている「ファイルが大きすぎてアップロードに失敗する」こととは違う種類の失敗だ。アップロードの失敗は通常、ファイルが上限を超えたことを知らせる明確なエラーメッセージを伴う。トークン上限を超えた場合、多くのケースでは「上限を超えました」という直接的なエラーは表示されない。代わりに、内容が完全に処理される前に切り捨てられたり、求められた出力の一部が空き容量不足のために省略・簡略化されたりする。この種の失敗ははるかに静かで、見過ごされやすい。

この制限が存在するのは、一回の呼び出しを処理するには入力と出力をすべて同じ演算空間に収める必要があり、その空間自体に物理的な容量の境界があるからだ。これは設計者が意図的に設けた敷居ではなく、計算リソースが必然的にもたらす制約である。この制限が見落とされやすいのは、日常のほとんどのタスク（短い手紙、ちょっとした対話）が上限からまだ遠く、その存在をわざわざ意識することがないからだ。しかしタスクの規模が大きくなると（長いレポートを丸ごと貼り付ける、非常に詳細な分析を求める、複数の文書を一回の呼び出しに重ねる）、その境界にどんどん近づいていく。さらに厄介なのは、あなた自身が「今回のタスクの内容量が大きい」となかなか感じ取れない点だ。あなたが見ているのは内容の意味的な重みだが、モデルが数えるのは分割された後のトークン数であり、両者の直感は完全には一致しないため、気づかないうちに上限へ近づいてしまいやすい。

実務では二つの判断点がある。第一に、事前の見積もりだ。一回で処理しようとする内容が明らかに大きい場合（数十ページを超える文書、構造が複雑で大量の細部を要する分析の依頼など）、この呼び出しが上限に近づく可能性を予想し、能動的に分割を検討する。長い文書をいくつかの段落に分けて別々に処理する、あるいは prompt chaining を使ってタスクを先に要約してから統合するという複数段階の流れに分割するといった具合で、すべてを一度に詰め込んで運任せにするのではない。第二に、事後の照合だ。出力結果が想定より短く見える、あるいは元々求めていた細部が抜けている場合、最初に疑うべきは「Claudeが忘れた」ではなく、「今回の入力と出力の合計が既に上限に近づいているか、あるいは超えているか」だ。タスクをより小さく分割して再実行し、分割前後の出力の完全性を比較してみる。分割後の内容が明らかにより完全であれば、それは確かに上限による切り捨てが原因であり、モデル自体の判断ミスではないと確認できる。

あなたにとって、トークン上限を理解する本当の価値は、出力が不完全だったときに疑いの方向を正しく容量制限へと向けられる点にある。モデルが「十分賢くない」あるいは「何かを見落とした」と誤解し、決して解決しない指示の言い回しの修正を何度も繰り返して時間を無駄にすることがなくなる。この判断の方向を間違えるコストは小さくない。根本原因が内容量の大きさにあるなら、指示の言葉遣いをどれだけ調整しても問題は解決せず、本当にすべきなのは内容を分割することだ。注意すべきは、タスクによって「内容量が大きい」ことへの敏感度が異なる点だ。単純な質疑応答の対話では上限にまず届かないが、長文書の分析、大量のデータ集約、極めて詳細な出力を求めるタスクは知らぬ間に境界へ近づきやすい。この種のタスクでは、書き始める前に十秒かけて内容の規模を見積もる方が、事後のデバッグより通常時間を節約できる。