目次
2023年に 32Kトークン で「広い」と言われたコンテキストウィンドウは、2026年5月時点で 100万トークン(1M) が業界標準になった。Claude Opus 4.7、Claude Sonnet 4.6、GPT-5.5、Gemini 3.1 Pro、DeepSeek V4-Pro——フロンティアの主要モデルが全部 1M 対応。Gemini 3.1 Ultra は 2M に到達した。
「100万トークン」とは、日本語で 新書 8〜10冊分、ソースコードなら 数万行。1セッションでこれだけ「視界に入れていられる」時代になった。だが、その容器を本当に最後まで使い切れているモデルは——実は1つだけだ。独立ベンチマーク(多針 NIAH、後述)で 1M 全域を保てるのは Gemini 3 Deep Think モードのみ。他のモデルは 200〜400K あたりから精度が崩れる、というのが2026年の正直な現場感覚だ。
私の率直な評価を先に書く: 容器の大きさだけ見て選ぶ時代は終わった。重要なのは「実効コンテキスト × コスト × 戦略性」の3点で、ここで Anthropic が 1Mフラット価格という独自の手を打ったのが今年の注目点だ。本記事では、コンテキストとは何かの定義から、主要モデル比較、なぜ大きいだけでは不十分なのか、コスト構造の違い、そして個人〜小規模チームが今日から効かせられる節約5手まで、独立ベンチの実数値を交えて整理する。
3年で容器は 250倍 に膨らんだ
— 1M が「贅沢品」から「前提」になった年表
だが「対応」と「最後まで読めている」は別。多針NIAH ベンチで1M全域を保てるのは Gemini 3 Deep Think のみ、
他は 200〜400K で精度が崩れ始める(Digital Applied, Zylos 2026)。
1. 1M対応モデルが5つ並んだ年——でも「全部読めている」のは1つだけ
2026年4月、OpenAI が GPT-5.5 を発表した瞬間、Web 上では「ついに OpenAI も 1M」と歓声が上がった。同じ月、Google は Gemini 3.1 Ultra で 2M を解禁。Anthropic は前年から Claude Opus 4.6 で 1M フラット価格を導入済、4.7 ではそれを継続強化した。DeepSeek の V4-Pro も 1M。フロンティアモデル5社が、揃って「100万トークン以上」と書ける状態になった。
これは大事件のはずだった。2023年に 32K で「広い」と感動していた頃から、わずか3年で 30倍以上。容器の大きさ競争はゴールに見えた。
ところが、独立評価機関の Digital Applied と Zylos Research が2026年に行った 多針 Needle-in-a-Haystack(NIAH)テスト——「長文の中に複数の事実を埋め込み、AI に全部正しく取り出させる」測定——では、こんな結果が出た。
- Gemini 3 Deep Think: 1M 全域で公称通りの精度を維持
- Claude Opus 4.7 / GPT-5.5 / DeepSeek V4-Pro: 200〜400K あたりから精度が下がり始める
つまり「1M対応」と謳っていても、本番ワークロード相当の条件で 1M を使い切れるのは1モデルだけ。他のフロンティアモデルでも、複数の情報を統合させようとすると 200〜400K で疲れが見え始める。これが2026年の現実だ。
誤解しないでほしい。これは「Claude や GPT がダメ」という話ではない。1Mを完全に使い切る用途は、実はそれほど多くない。300K(≒新書2〜3冊分)まで安定して読めれば、ほとんどのコーディング・リサーチ・要約タスクは完結する。問題は「1M対応」という数字だけ見て選ぶと、判断軸を見誤ることだ。
2. コンテキストとは何か——容器と中身を分けて理解する
用語を整理しておく。コンテキスト周辺で 3つの言葉が混ざりがちだ。
トークン・ウィンドウ・コンテキスト
要は 「ウィンドウ=容器のサイズ」「コンテキスト=中身」「トークン=単位」。
容器が大きくても、中身が雑なら答えも雑になる。
もうひとつ、「コンテキスト」と「メモリ」を混同しないこと。コンテキストはそのセッション内のみで、チャットを閉じれば消える。一方、ChatGPT Memory や Claude Memory のような セッションを跨いで覚える機能は別物だ。メモリの中身も最終的にはコンテキストへ注入されるが、ユーザーから見れば 永続的な記憶 vs 一時的な作業領域という違いがある。
3. 主要モデル一覧——2026年5月、容器のサイズ
定義がはっきりしたところで、各社の現行モデルが提示している「容器のサイズ」を並べる。すべて公式仕様(2026年5月時点)から。
| モデル | 入力上限 | 出力上限 | 備考 |
|---|---|---|---|
| Claude Opus 4.7 | 1,000,000 | 128,000 | 標準価格でフラット1M、beta header 不要 |
| Claude Sonnet 4.6 | 1,000,000 | 64,000 | 同上のフラット価格 |
| Claude Haiku 4.5 | 200,000 | 64,000 | 軽量モデル、1Mは非対応 |
| GPT-5.5 | 922,000 | 128,000 | API合計1M、272K超で入力単価2倍に |
| GPT-5.4 | 1,000,000 | 128,000 | 同じく長文サーチャージあり |
| Gemini 3.1 Pro | 1,000,000 | 65,535 | Vertex AI / AI Studio で利用 |
| Gemini 3.1 Ultra | 2,000,000 | 65,535 | 2M対応、現状唯一の市販2Mモデル |
| Grok 4 | 256,000 | 32,000 | xAI公式仕様、フロンティア中では控えめ |
| DeepSeek V4-Pro | 1,000,000 | 96,000 | オープン系で最大級 |
表だけ見ると「Gemini Ultra が最強、以上」で終わりそうだが、ここで 1つ太字にしておきたい事実がある。Anthropic は Opus 4.6 / 4.7 と Sonnet 4.6 で「1M をフラット価格で提供」している点だ。OpenAI が GPT-5.5 で 272Kトークンを超えると入力単価を2倍にするのと対照的だ。これは単なる料金設計ではなく、「長文ワークロードをどう扱うか」の戦略的な違いを表している。詳細はコスト章で後述する。
個人的には、Claude Opus 4.7 を 長文系の主力にしている。理由は3つ——フラット価格、200K帯までの精度の安定、Anthropic のドキュメント品質。ただ300K を超えるような巨大文書では Gemini 3 Deep Think を選ぶ。用途で使い分けるのが2026年の正解だ。
4. 「大きいほど良い」が成立しない3つの理由
前章のスペック表は容器の物理的サイズを示しただけだ。では、宣言された容器を本当に使い切れているのか。結論から書くと、Gemini 3 Deep Think 以外は厳しい。理由は3つある。
理由①: Lost in the Middle(真ん中で迷子)
2023年に Stanford 大が発見し、以後どの世代のモデルでも繰り返し再現されている現象だ。AIは入力の 冒頭と末尾を強く重視し、中央部分(30〜70%の位置)を軽く扱う。100Kトークンの中盤に置いた重要情報は、冒頭・末尾に置いたときより 5〜15ポイント低い精度でしか取り出されない。
体感としては、「長いPDFを丸ごと貼って『○○の数字は?』と聞くと、ちょうど真ん中あたりの数字を取り違える」。これがLost in the Middleだ。Stanford の最初の論文(2023)以来3年、フロンティアモデルでも完全には解消されていない。
理由②: Context Rot(文脈の腐敗)
会話を続けるほど、初期に出した指示が薄まっていく現象。「敬語で答えて」と冒頭で指定したのに、20往復後にはタメ口に戻っている——あれがContext Rotだ。
原因は2つ。① 初期指示が会話履歴の中で相対的に古く・軽く扱われる。② 長くなった履歴のせいでアテンションが分散し、特定のトークンを参照しにくくなる。Anthropic は2026年に 「コンテキストエンジニアリング」という概念で、この問題への対処を意識的なスキルとして取り組み始めている。
理由③: 公称コンテキスト ≠ 実効コンテキスト
2026年の最新ベンチ(多針NIAH、本番ワークロード相当)では、こうなっている。
実効コンテキスト(複数情報の統合精度)
出典: Digital Applied「Long-Context Retrieval 2026」 / Zylos Research「LLM Context Window Management 2026」。
単針NIAH(1つの情報だけ取り出す)では全モデルが1Mを通過するが、複数事実の統合では差が出る。
「Claude Opus 4.7 がダメ」ではない点を改めて強調する。200〜400Kでも新書2〜3冊分に相当する。ほとんどの実務(コードレビュー、長文記事執筆、議事録要約、リサーチ統合)はこの範囲で完結する。問題なのは「1Mあるんだから1M投げ込めばいいでしょ」という使い方で、それは Gemini Deep Think 以外ではうまくいかない、ということだ。
5. コストの罠——OpenAI は272K超で2倍、Anthropic はフラット
前章で「実効では200〜400K」と書いた。そこにもう1つ重なる罠が「長文を投げると課金が跳ねる」。これは Anthropic と OpenAI で対極的な戦略が出ている。
| モデル | 標準入力単価 | 長文時の追加 |
|---|---|---|
| Claude Opus 4.7 | $5.00 / 1M tokens | 1M全域フラット、追加なし |
| Claude Sonnet 4.6 | $3.00 / 1M tokens | 同上、追加なし |
| GPT-5.5 | $5.00 / 1M tokens | 272K超で入力単価2倍、出力1.5倍 |
| GPT-5.4 | 同程度 | 同じく長文サーチャージあり |
具体的に試算する。500Kトークンの文書を投げて50Kの応答を1回もらうケース——大型コードベース全体や年次レポートを一気に要約する典型ケース。
- Claude Opus 4.7: $5.00 × 0.5 + $25.00 × 0.05 = $3.75
- GPT-5.5(272K超でサーチャージ適用): $10.00 × 0.5 + $45.00 × 0.05 = $7.25
1回あたり $3.50 の差。1日100回叩くと月 $10,500 のずれ。エージェントを動かし続けるチームには月数十万円のオーダーで効く。「AIのトークン・セッションコスト節約」でも触れた構造だ。
6. 節約の5手——個人開発者がすぐ効く順
「容器は1Mあるが実効は300K、しかも長く使うと金がかかる」——ここまでで分かった。では現場でできる対策は何か。私が日常的に使っていて効果が大きい順に5つ並べる。
コンテキスト節約の優先順位
/compact や新セッション開始。
5つの中で 最大効果は ①「セッションを切る」。チャットを切るだけでハルシネーション体感が目に見えて減る。
④ は API 開発者向け、UI(claude.ai / ChatGPT)からは自動でやってくれる範囲。
個人的なベストプラクティスは 「①と②を徹底するだけで体感の精度が大きく変わる」こと。Claude Code を使うときも、長い1セッションで続けるよりも、論点が変わるたびに /compact や新規セッションでリセットする方が、最終的なアウトプットの質が安定する。
まとめ
本記事のポイントを整理する。
- コンテキストウィンドウ = 1回のやり取りでAIが扱える最大トークン数。容器のサイズ
- 2026年5月時点、Claude Opus 4.7 / Sonnet 4.6 / GPT-5.5 / Gemini 3.1 Pro / DeepSeek V4-Pro が 1M 対応、Gemini 3.1 Ultra は 2M
- 独立ベンチ(多針NIAH)では Gemini 3 Deep Think だけが 1M 全域を保持、他は 200〜400K で精度が落ち始める
- コストは Anthropic はフラット、OpenAI は272K超でサーチャージ。戦略の差が明確
- 節約は 「セッションを切る・抜粋・末尾再掲・キャッシュ・アドレス明示」の5手、特に①②が効く
容器が大きくなったのに、結局やっていることは 「何を渡し、何を渡さないか」の取捨選択だ。2026年のAI活用スキルは、もはや「全部詰める力」ではない。必要なものだけを正しく渡し切る判断力こそが、長く使えるスキルになる——というのが、1年で5モデルが1Mを宣言した今年の、私の結論だ。
FAQ
OpenAI は tiktoken ライブラリ、Anthropic は公式SDKに countTokens() 相当のAPIがある。日本語1文字 ≒ 1〜1.5トークン、英語1単語 ≒ 1.3トークンが目安。コードはトークナイザの種類で変わるので、長文を投げる前に実測するのが安全だ。
コンテキストはセッション内のみで、チャットを閉じれば消える。メモリ(ChatGPT Memory / Claude Memory)はセッションをまたいで覚え続ける別機構。メモリの中身も内部的にはコンテキストの一部として注入されるが、ユーザーから見れば永続 vs 一時の違いがある。
RAGは「コンテキストに必要な情報だけを動的に取得して載せる」仕組み。1Mウィンドウがあっても全部詰めると重く・遅く・高くなるので、検索で関連箇所だけ抜くRAGは現在も主流。詳しくはRAGとは何かを参照。
学習時の主な系列長と推論時の系列長のミスマッチ、アテンション機構の位置エンコーディングの限界、複数情報の統合に必要な計算量の急増などが重なる。「対応」と「全域で精度維持」は別の問題だ。
する。MCPは必要なときだけツール経由で情報を取りに行く仕組みなので、最初から全部コンテキストに載せる必要がなくなる。ファイル全文を貼る代わりに「読みに行く」発想に切り替えるイメージだ。