800ページの契約書全体をモデルに読み込ませました。モデルは答えました——そして、その1つの質問の請求額は、先月のAPI支出全体を上回っていました。モデルはコンテキストウィンドウを「処理」したのです。しかしあなたの予算は処理しきれていません。
Long-contextはLLMスタックの中で最も誇大広告された機能であり、その誇大広告は「RAGは死んだのか？」という、ほぼ完全に的外れな議論を生み出しました。1Mトークンのウィンドウは本物です：Geminiは2Mクラスのウィンドウを、Claudeは1Mを出荷し、MoonshotのKimi K3は2026年7月に1Mでローンチ、DeepSeekのV4 Proは1Mコンテキストと384K出力を備えています。ただし物理法則は変わりません：トークンは金がかかり、アテンションは距離とともに劣化し、「詰め込めるか」は「詰め込むべきか」と同じ問いでは決してありませんでした。
本ガイドは議論が飛ばしている部分を扱います：コスト計算（フルコンテキスト vs キャッシング vs RAG）、1Mトークンのウィンドウを使い物にするワークフローパターン（map-reduce、コンパクション、スライディングウィンドウ、レイヤードコンテキスト）、そして「雰囲気」ではなく数字で議論を終わらせるlong-context vs RAGの判断フレームワークです。
Long-Context APIが2026年に提供するもの
要点：1Mのウィンドウは今やフロンティア全体の標準です——差別化要因はウィンドウサイズではなく、コスト、キャッシュ挙動、アテンション品質です。
2026年のラインナップ：Geminiの2Mクラスのウィンドウ、Claudeの1M GA、Kimi K3の1M（コンテキストと価格の両方で期待値を塗り替えたオープンフラッグシップ）、1MコンテキストのDeepSeek V4 Pro、そして400,000以上のGPTクラスのファミリーです。モデルカタログが、統合エンドポイントを通じてプロバイダーごとの現在の上限を追跡します。
ウィンドウサイズからは見えない3つのこと：
- フルウィンドウでのトークンあたりコスト。 フロンティアレートでの1Mトークンの入力は、質問1回あたりの実際のコストです——正確な数字はプロバイダーとティアに依存し、それが第3セクションのポイントです。
- キャッシュ価格。 ほとんどのプロバイダーはキャッシュされた入力トークンを基本レートのおよそ10分の1に割引します——業界全体で文書化されたキャッシュの慣例——これにより、反復的なlong-contextワークロードの経済性は完全に変わります。
- 深部でのアテンション品質。 「ウィンドウは1M」はモデルが1Mを受け入れることを意味し、1Mを均等に使うことを意味しません。深部での検索型の劣化は現実であり、以下のワークフローパターンが存在するエンジニアリング上の理由です。
なぜ「1Mトークン」は「1Mの有用トークン」ではないのか
要点：ウィンドウサイズは天井であり、品質の約束ではありません——コスト曲線は線形ですが、アテンション曲線は線形ではありません。
マーケティングの背後にある3つの現実：
- コストは線形に、痛みを伴ってスケールします。 ウィンドウ内のすべてのトークンは、貢献したかどうかに関係なく課金されます。ドル規模のレートでの1Mトークンの質問は、ドル規模の質問です——繰り返せますが、繰り返せなくなる日が来ます。
- アテンションは距離とともに劣化します。 モデルファミリーを横断する証拠は一貫して、モデルが長いコンテキストの中央よりも最初と最後をよく使うことを示しています——「lost in the middle（真ん中で迷子）」は十分に文書化されたパターンです。詰め込むことは理解することではありません。
- キャッシュが形を変えます。 キャッシュ価格が約0.1倍なら、2回目以降のフルウィンドウの質問は安価です——安定して反復されるlong-context（同じ文書に何度もクエリを投げる）が報われ、一度きりのフルコンテキスト読み込みは割高になります。
設計上の帰結：long-contextは再利用可能な資産——繰り返しクエリする安定したコーパス——として最も効果を発揮し、質問ごとの賭けとしては最も不向きです。
コスト計算：フルコンテキスト vs キャッシュ vs RAG
要点：同じコーパスへの反復クエリでは、通常cache-then-RAGが勝ちます。一度きりの文書全体への質問では、フルコンテキストが正直です。それ以外のすべては、数字を計算しましょう。
具体的な形での比較——500,000トークンのコーパス、10の質問：
| アプローチ | コストのドライバー | 典型的な相対コスト |
|---|---|---|
| 毎回フルコンテキスト | 500Kトークン×10 | フル入力価格の10倍 |
| キャッシュ＋フルコンテキスト | キャッシュ入力で約0.1倍 | フル入力価格の約1倍 |
| RAG（top-k検索） | 5Kトークン×10＋インデックス | フル入力1回分の数分の一 |
構造的な結論：反復クエリではRAGが桁違いのコスト優位に立ち、同じコーパスが頻繁にクエリされる場合にはキャッシュがフルコンテキストを競争力のあるものにし、フルコンテキストが完全に勝つのは一度きりの深掘り読解の質問だけです。 品質は別の曲線をたどります——検索は見逃すことがあり、フルコンテキストは埋没させることがある——だからこそ判断フレームワークが存在するのです。
数字はプロバイダーとコーパスに依存します。本シリーズのキャッシングガイドがキャッシュの仕組みを扱っており、以下の計算例は自社のレートを当てはめるための型です。
1Mトークンワークフローの構築方法
要点：4つのパターン——map-reduce、コンパクション、スライディングウィンドウ、レイヤードコンテキスト——そして設計ルールは「必要のないトークンには決して支払わない」です。
- Map-reduce。 コーパスを分割し、チャンクを処理し、結果を統合します。「文書全体に対する回答」の主力パターンです：各チャンクは小さく、並列性は自然に得られ、最終的な統合は要約のみを読みます。コストはフルウィンドウではなくチャンク数に比例します。
- コンテキストコンパクション。 次のターンの前に中央を圧縮します——要約し、重要な事実を抽出し、冗長性を捨てます。コンパクションは、エージェントが二次関数的なコストなしにマルチターンのコンテキストを保持する方法です。「エージェントが覚えている」と「エージェントがトランスクリプト全体を持ち歩く」の違いです。
- スライディングウィンドウ。 直近のNトークンを保持し、あふれた分を要約します。会話やストリームでは、ウィンドウはアクションに追随します——インタラクティブなコストを上限内に保つパターンです。
- レイヤードコンテキスト。 高速パスとフルパス：日常的なターンには要約、必要なときにはオンデマンドで全文を検索——custom routingが高速/フルの判断を機械的にします。レイヤリングは、「1Mコンテキスト」を請求書ではなく能力にする本番パターンです。
共通するテーマ：すべてのパターンは、重要なトークンにだけ支払うための方法です。 チャット補完エンドポイントが仕組みを処理し、パターンが経済性を決定します。
選び方：Long Context vs RAG vs ハイブリッド
要点：問いは「RAGは死んだか」ではなく「自分のクエリパターンは何か」です——判断フレームワークは3つの質問であり、信仰ではありません。
- コーパスは静的で、繰り返しクエリされるものですか？ キャッシュ＋RAGです——一度インデックス化し、クエリごとに検索し、安定したプレフィックスをキャッシュします。
- 質問は大きな文書に対する一度きりの深掘り読解ですか？ フルコンテキストです——検索が見逃すであろう正直なユースケースであり、コストは質問の希少性によって制限されます。
- 長時間続くエージェントの会話ですか？ レイヤードコンテキストです——要約と検索と上限付きウィンドウの組み合わせで、完全な履歴は決して使いません。
本シリーズのRAGガイドとの関係は競合ではなく補完です：あちらのガイドは検索の内部——チャンキング、ハイブリッド検索、リランキング——を担い、本ガイドはコンテキストウィンドウの経済性とワークフローパターンを担います。両方ともほとんどの本番システムに当てはまり、ハイブリッドは妥協ではなく標準です。
よくある失敗
要点：4つの罠——3つはコスト型、1つは品質型——それぞれが「1Mウィンドウ」の誇大広告の実態です。
- デフォルトでフルコンテキスト。 ウィンドウがあるから、すべてを詰め込む——キャッシュ設計も検索もない線形コストの罠です。本ガイドの予算表が存在するのは、この失敗がデフォルトだからです。
- エージェントループにコンパクションがない。 すべてのターンで完全な履歴が追加され、20ターン目には、エージェントはこれまで話したすべてのコストを支払っています。長時間稼働するエージェントにとって、コンパクションは任意ではありません。
- ドリフトするキャッシュキー。 キャッシュ倍率はプレフィックスがバイト単位で安定している場合にのみ適用されます——動的なヘッダー、タイムスタンプ、セクションの並び替えはヒット率をゼロにし、約0.1倍を1倍に変えます。キャッシングガイドが仕組みを解説し、規律を守るのはあなた自身です。
- ウィンドウの中央を無視したベンチマーク。 コンテキストの最初と最後だけで「1Mトークンを処理できた」をテストする——lost-in-the-middleパターンは生き残り、中央をサンプリングしない評価セットは間違った物語を語ります。
FAQ
1MトークンのコンテキストはRAGを置き換えられますか？
大きな文書への一度きりの深掘り読解には、はい——それが正直なユースケースです。コーパスへの反復クエリには、いいえ：コスト計算（フル入力の10倍 vs 検索サイズ）がRAGを答えにし、キャッシュが橋渡しになります。決めるのはマーケティングではなく3つの質問のフレームワークです。
1Mトークンのクエリの実際のコストはいくらですか？
クエリごとにフロンティアレートでのフル入力——正確な数字はプロバイダーとティアに依存します。約0.1倍のキャッシュヒットがあれば、同じコーパスへの反復クエリはコストを大幅に下げます。本ガイドの表が型であり、あなたのプロバイダーページが数字です。
コンテキストコンパクションとは何ですか？
ターン間で会話やコーパスを圧縮することです——要約し、重要な事実を抽出し、冗長性を捨てる——エージェントが完全な履歴ではなく意味を持ち運ぶようにします。長時間稼働するエージェントを手頃な価格に保つパターンであり、数ターンを超えたら譲れません。
キャッシュ価格は本当に約0.1倍ですか？
業界の慣例として、キャッシュヒットの倍率は基本入力価格のおよそ10分の1で、プロバイダーを横断して一貫して文書化されています。ただしバイト単位で安定したプレフィックスにのみ適用されます——だからこそ、キャッシュキーの規律はすべてのlong-contextデプロイにおけるコストを左右する隠れた要素なのです。
1Mトークンのウィンドウを提供しているプロバイダーはどこですか？
現行世代ではGemini（2Mクラス）、Claude（1M）、Kimi K3（1M、オープンフラッグシップ）、DeepSeek V4 Pro（1Mコンテキスト）です——前述のモデルカタログが、1つのエンドポイントを通じた現在の提供状況のリファレンスになります。
検索ではなくフルコンテキストを使うべきなのはいつですか？
検索が見逃すであろう一度きりの深掘り読解——契約レビュー、単一文書の分析、コーパス全体の推論——であり、クエリが十分に稀で、コストがパターンではなくイベントになる場合です。繰り返されるものにはすべて、キャッシュまたは検索を使いましょう。
まとめ
Long-context LLM APIは物理法則ではなくコスト計算を変えました：1Mウィンドウはフロンティア全体で標準となり、現在の差別化要因はキャッシュ挙動、深部でのアテンション品質、そして請求額を健全に保つワークフローパターンです。コーパス全体の質問にはmap-reduce、エージェントにはコンパクション、ストリームにはスライディングウィンドウ、本番にはレイヤードコンテキスト——そして「RAGは死んだか」の議論を数字に置き換える3つの質問のフレームワークです。ウィンドウは能力であり、パターン次第でそれが予算内に収まります。
判断フレームワークはスプレッドシートの問題です。TokSpan APIキーを取得して——計算をテストするための$5分の無料クレジット付き（クイックスタート）——自社のコーパスで3つのアプローチすべてを価格試算してみましょう。