Context Window

トークンとは何ですか？中国語・英語・コードはそれぞれどのくらいのトークンを「消費」しますか？

トークンはLLMがテキストを処理するための基本単位です——「文字」でも「単語」でもなく、モデルのトークナイザーがテキストを切り分けたセグメントです。トークン効率は言語によって大きく異なり、APIコストとContext Window使用効率に直接影響します。

英語のトークン効率が最も高い：英語は平均1トークンあたり約4文字で、一般的な英語の単語は通常1トークンです（the・agent・wallet）。英語：約750単語 ≈ 1,000トークン。

中国語のトークン効率は低い：各漢字は通常1-2トークンです（Claudeのトークナイザーは中国語の圧縮が英語より効率が悪い）。繁体字中国語：約500-600文字 ≈ 1,000トークン。（同じ情報を中国語で書くと、英語の約1.3-1.5倍のトークンを消費します）

コードは最もトークンを消費する：インデント・括弧・引用符・セミコロン——これらの記号は各々トークンを占有し、長い関数名はより多くのトークンを消費します。100行のPythonは500-800トークンを消費する可能性があります。

SVGは驚くほどトークンを消費する：SVGコード（<rect x="30" y="40" width="100" fill="#333">のようなタグ）はトークナイザーに非常に不親切です——各属性値・引用符・座標が独立したトークンです。中程度に複雑なSVGは2,000-5,000トークンを消費する可能性があります。

Context Windowが満杯になると何が起こりますか？どのような処理戦略がありますか？

Context Windowが上限に近づくと、モデルには異なる処理戦略があります——どれも理想的ではありません——これが「Context Windowの管理」がAgentエンジニアリングの核心的課題の一つである理由です。

ハードトランケーション：最もシンプルですが最悪のアプローチ——最初のContextコンテンツを直接切り捨て、最新のNトークンのみをモデルに渡します。結果：Agentは初期の会話と意思決定コンテキストを「忘れ」、すでに実行した操作を繰り返したり、早期に設定された重要な制約を忘れたりします。

スライディングウィンドウ要約：Context使用率が70%を超えると、自動的に要約圧縮をトリガー——LLMを使って最初のNラウンドの会話を高密度な要約に圧縮し、元の会話を要約に置き換えます。適切なシナリオ：決定結果のみを記憶する必要がある長時間稼働のDeFi Agent。

RAG外部化（Retrieval-Augmented Generation）：長期情報をContext Windowの外のベクターデータベースに移し、各推論前に「最も関連性の高いKチャンク」のみをContextに取得します。最も柔軟なアプローチですが、ベクター検索のレイテンシとエンジニアリングの複雑さを導入します。

タスク分解：大量のContextを必要とする長いタスクを複数の独立した短いタスクに分割し、各タスクは独立したクリーンなContextを持ちます。OrchestratorがサブタスクのI/Oを調整し、単一タスクのContextが過度に長くなるのを防ぎます。

DeFi Agentへの実践的推奨：「スライディングウィンドウ要約 + 構造化DB長期メモリ」の組み合わせが最も一般的です。

Claude・GPT-4o・GeminiのContext Windowサイズの違いは何ですか？モデル選択時にこの次元をどのように考慮しますか？

主流モデルのContext Window（2026年中頃時点）：

Claude Sonnet（Anthropic）：200Kトークン ≈ 約15万英語単語または約10万漢字。ほとんどのDeFi Agentタスクに十分で、数時間の操作履歴+現在のタスク+ツール返却を1つのContextに収められます。

GPT-4o（OpenAI）：128Kトークン。Claudeより小さく、長時間稼働のAgentは上限に達しやすく、より積極的なContext管理戦略が必要です。

Gemini 1.5 Pro（Google）：1Mトークン——主流モデルの中で最大。理論上はDeFiプロトコルのコードベース全体を分析のために入れられますが、トークンが多いほどAPIコストが高く、「干し草の中の針問題」（100万トークンの中から最も重要な数行を見つける）は未解決のエンジニアリング課題として残っています。

モデル選択時のContext Window考慮事項：

大きければ大きいほど良いわけではありません。 AgentタスクがContextごとに20K-50Kトークンを使用している場合、200Kから1Mへのアップグレードはほとんどパフォーマンスに影響しませんが、APIコストが大幅に増加する可能性があります。

継続稼働のDeFi Agentの場合：200Kトークン（Claude Sonnet）は通常十分です；スライディングウィンドウ要約と組み合わせることで無期限に延長できます。Context Windowサイズよりも推論能力とTool Useサポートの質を優先してください。

「Context Windowが大きい = Agentがより賢い」は本当ですか？Context WindowサイズとAgentパフォーマンスの関係は何ですか？

これは最も一般的な誤解の一つです。Context WindowサイズとAgentパフォーマンスの関係はほとんどの人が思うよりも複雑です：

Context Windowサイズが実際に影響すること：タスクに関連するすべての情報を1つのContextに収められるか（長いドキュメント・長い会話履歴）；単一会話でAgentが「記憶」できる情報量；一回限りの大規模分析タスクの実現可能性（完全なコントラクトコードベースの分析）。

Context Windowサイズが影響しないこと：モデルの推論深度（複雑な問題の推論品質）——推論品質は主にモデル自体のトレーニングによって決まり、Context Windowサイズではありません。200Kトークンの Claude Sonnetは、より多くの情報を「見る」ことができても、複雑なマルチステップDeFi戦略問題について1Mトークンの弱いモデルよりも優れた推論を行う可能性があります。

「Lost in the Middle」問題：研究によれば、Context Windowに大量のテキストがある場合、モデルはContextの始まりと終わりの情報に注目する傾向があり、重要な情報が中間にあっても無視します。単にContext Windowを大きくしても、モデルがより多くの情報を「より良く活用する」保証はありません。

実践的推奨：モデル選択時は、Context Windowサイズよりも推論能力・Tool Useサポートの質・価格を優先してください。