(リビングを見渡しながら)…うちさ、キャンプ道具一式 / ワインセラー97本 / 生ハム塊 / 月曜のパワポ150枚原稿 でだいぶ部屋が圧迫されてるけど、それでもまだ 新しい趣味 入れたいんだよな。最近 ベランダのトマト 始めたじゃない?あれ楽しいんだけど、その分 キャンプ道具がさらに納戸の奥 に押し込まれてさ、もう 何が入ってるかも思い出せない。
(これ、頭の中も同じだ。月曜は パワポ案件A / クライアントBの提案 / 部下C評価面談 / D社飲み / 妻の誕生日プラン / トマト水やり で頭が常に 満杯。新しい案件が1つ入ると、古い案件の細部 がポロッと抜けて、月曜に部下から「金曜の指示」を聞かれてもピンとこない。家の納戸と頭の容量、構造的に同じなんだよなぁ。)
赤崎さん、月曜の朝会の前に金曜の案件の 方針確認 したいんですが、お時間1分いいですか?
(あ、これ 納戸の奥 に押し込まれた件だ…ちょっと思い出すから3分くれ)…これ、LLM で言うと コンテキストウィンドウ の話だよな。Claude Opus 4.7 が 200K(拡張1M)、GPT-4 Turbo が 128K って、「一度に抱えられる量」 が決まってる。私の頭は 200K より遥かに小さい から、トマト1本入れただけで何かが押し出される。
- コンテキストサイズ(コンテキストウィンドウ)= AI が一度に抱えられる「短期記憶容量」。プロンプトと応答とこれまでの会話が、全部このひと枠に収まる必要がある。
- ここを超えると古い情報から押し出されて消える。長い相談の途中で「最初に言ったこと、忘れてない?」が起きるのはこのため。
- イメージは机の上に一度に広げられる書類の枚数。机が広いほど多くを見渡せるが、はみ出した書類は引き出しに戻される(具体的な数の目安は本文で)。
パラメーター数 (#010) が LLM の 「脳の重み」 だとすれば、コンテキストサイズは LLM の 「短期記憶容量」。両者は別物。GPT-4 級の巨大モデルでも、コンテキストを超えた入力は受け付けない。「頭は良いが、一度に読める長さが決まってる」 状態。
「Claude 200K」、「GPT-4 128K」、「Gemini 1M」 — クライアントが LLM を選ぶ時、コスト感の次に必ず聞かれる指標。なぜそんなに気にするのか、本当に大きい方がいいのか、そこに切り込む。
定義 — プロンプト+応答+履歴、全部の合計上限
コンテキストサイズの正体はシンプル: 「あなたの入力(プロンプト) + LLM の出力(応答) + 過去の会話履歴」を全部足したトークン数の上限。
例えば Claude Opus 4.7 の 200K(拡張1M)というのは、標準で 200,000 トークン、拡張枠で 1,000,000 トークンの意味。日本語の場合、200K でざっくり 15万文字 ≒ 文庫本1.5冊分。これに収まる長さなら一度に処理できる、超えると 古い部分から自動で切り捨てられる(または API がエラーを返す)。
図1がコンテキストの正体。読み方の手順は次の4ステップ:
- LLM はまず文章を 1個ずつトークンに分解 する(トークン(#003))
- 各トークンを 1本の縦長ベクトル に変換する(埋め込み(#002))
- それを 左から右へ、入力順に並べる
- 並んだ 縦ベクトルの 「本数」 = LLM が今抱えているトークン数 = コンテキスト
つまり「横方向 = トークン数」とは 「スケール軸」 の話ではなく、「縦ベクトルが何本並んでいるか」 という本数のこと。一番右の ??? が 「次に予測する1語」 の枠で、これも含めて全部この長方形領域に収まる必要がある。Claude Opus 4.7 の 200K とは、この縦ベクトルを横に最大 200,000 本まで並べられる、という意味になる。
本記事の理解の核 — 新しい1語を生成するたびに、この長方形は右に1列ずつ伸びていく。上限に達したら、左端から1列ずつ切り捨てられる。これが「長い会話の途中で AI が最初の指示を忘れた」という現象の正体。
具体的にどんな構成で消費されるか:
- システムプロンプト(裏側で設定された AI の役割定義)= 数百〜数千トークン
- あなたのプロンプト本文(質問、添付PDFやコード含む)= 場合により数千〜数十万トークン
- 過去のチャット履歴(同じ会話の中での過去のやり取り)= 増え続ける
- LLM の応答(これから生成する出力)= まだ書かれてないが、上限の中に予約席が必要
全部足して 200K を超えそうになると、古い履歴から消えていく。「長い会話の途中で AI が最初の指示を忘れた」 現象の正体がこれ。
2026年現在の主要モデル早見表
| モデル | コンテキスト | 文庫本換算(日本語) | 主な特徴 |
|---|---|---|---|
| GPT-3.5 Turbo | 16K | 約12,000字 | 2023年初期の標準 |
| GPT-4(初代) | 8K / 32K | 約6,000 / 24,000字 | 2023年当時の上限 |
| Claude 2 | 100K | 約75,000字 | 2023年に長文枠を切り拓いた |
| GPT-4 Turbo | 128K | 約96,000字 | 2024年汎用主力 |
| Claude 3.5 Sonnet | 200K | 約150,000字 | 2024年長文処理の定石 |
| Claude Opus 4.7 | 200K / 1M(拡張) | 150,000 / 750,000字 | Anthropic 現行フラッグシップ(2026) |
| Claude Sonnet 4.6 | 200K / 1M(拡張) | 150,000 / 750,000字 | Opus 4.7 と同等の長文枠、軽量寄り |
| Claude Haiku 4.5 | 200K | 約150,000字 | 軽量・低レイテンシ・低コスト |
| Gemini 1.5 Pro | 1M(100万) | 約750,000字 | 長編小説まるごと、動画/音声も対応 |
| Gemini 1.5 Pro(実験版) | 2M | 約1,500,000字 | 業界最大、専門用途 |
| Llama 3.1 | 128K | 約96,000字 | OSS、ローカル運用可 |
2023年は 8K〜32K が主流だったが、2024〜2026年で 桁が2つ上がる 急成長。Gemini 1.5 の 1M は、Google が AI 開発で得た 長距離アテンション技術 の結晶。各モデルが 「自社の特徴」 として最優先で訴求 する指標になっている。
なぜ「無限に大きい」じゃダメなのか — 二乗の壁
素朴な疑問: 「コンテキストを 100M にしたら全部解決じゃないの?」 答えは「計算コストが二乗で爆発するから」。
アテンション (#030) は、すべてのトークンが すべてのトークンを見る 仕組み。トークン数を N とすると、計算量は N² に比例する。N=1,000 なら 100万回の計算、N=100,000 なら 100億回。N=1,000,000 なら 1兆回。
- コンテキスト 10倍 → 計算コスト 100倍
- コンテキスト 100倍 → 計算コスト 10,000倍
- コンテキスト 1,000倍 → 計算コスト 1,000,000倍
これが 二乗の壁。Google の Gemini 1.5 が 1M を実現したのは、この二乗を 巧妙に近似する技術(Sparse Attention、Ring Attention 等) の研究が前進したからで、決して 「GPU を増やせば自動で大きくなる」 わけではない。
もう1つの副作用: 長くなるほど 「注意の集中力」 が薄まる。10万トークンの中から特定の1文を正確に拾う精度(Needle in a Haystack)は、長くなるほど落ちる傾向。「大きいコンテキスト = 自動で賢い」 ではなく、「使い切れる賢さ」 には限界 がある。
コンサル感覚 — クライアントが本当に必要なサイズはいくらか
本記事の核心メッセージは 「コンテキストサイズは 「短期記憶容量」、用途次第で必要量がまったく違う」。これを実務で意識するメリット:
① 大半の業務は 32K で足りる: クライアントが「Claude の 200K を使いたい」と言ってきた時、実際の入力長を測ると 4〜16K しか使ってないケースが大半。本当に長文処理が必要なのは 契約書レビュー / 議事録要約 / 長尺PDF分析 のような特殊用途。汎用問い合わせなら 32K 以下のモデルで コストが半額以下 に。
② 「長くしたら賢くなる」 は誤解: 200K のモデルに 200K 投げ込むと、中盤の情報が読み飛ばされやすい(中央部精度の低下、Lost in the Middle 現象)。関連する箇所だけ抽出して 32K に絞る 方が、精度もコストも勝る。RAG(検索拡張生成)の発想の根拠もここ。
③ チャット履歴の管理: 長い会話を続けると、最初の指示が消える。業務 AI で 「重要指示は毎回プロンプト先頭に再注入する」 設計がプロの定石。Claude のような長コンテキストでも、本当に変えたくない指示は システムプロンプト(別枠)に置く。
昨夜、リビングで気づいたんだよ。千葉のマンションの納戸容量 と、俺の 頭の中の同時保持容量 と、AI の コンテキストウィンドウ が、全部同じ構造だって。新しいの入れたら古いのが押し出される。…まあ、今朝になったらどれが押し出されたか思い出せないんだけど。
あら、赤崎さんのお宅、まだ キャンプ道具 残ってましたのね。私の実家は 母 が容量管理に厳しくて、北欧雑貨も IKEA の POÄNG 椅子も 「1年使わなかったら処分」 ルールで、結局5脚全部消えました。頭の中の 「私のラインじゃない案件」 も同じく1週間で処分 いたしておりますわよ、ホホ。
(大蔵さんの 「1週間で処分」 は、FIFO(先入れ先出し)型のコンテキスト管理 ですね。一方、赤崎さんの 「新趣味で押し出される」 は、新しい関心が優先度を持つLRU(最近使った順)型。LLM 側は通常 古いものから切り捨てる FIFO 型 なので、構造的には大蔵さんの方が近いです。…って解説するとまた長くなるから、相槌だけ打とう。)
フッ、コンテキストか。私の 世田谷の独身オーディオルーム は レコード200枚超、ベルリンフィル盤200枚、推し配信録音、雑誌バックナンバー、ケーブル予備…と物量はあるが、収納設計が完璧 なので押し出される物はない。これは 長コンテキスト + 高精度 の理想形だ。赤崎の千葉マンションは 容量 200K でも収納設計が雑なのが Lost in the Middle ということだな。
(御託さん、人のマンションをディスりながら自分の世田谷オーディオ自慢に持っていったのすごい。…まあ、確かに 「容量より整理」 が本質ってのは正論。私も新婚で 妻の整体院グッズ + 自分のアイコス周辺 + 韓ドラのDVDセット でリビングが圧迫されてきたから、他人事じゃない。)
応用 — RAG とコンテキスト圧縮
本記事の余談として、コンテキストサイズに関する実務的なテクニック:
- RAG(Retrieval-Augmented Generation): 大量のドキュメントをコンテキストに丸ごと入れず、必要な箇所だけ検索して入れる 設計。100万トークンの社内資料から関連3,000トークンだけを抽出して LLM に渡す。長コンテキストの代替手段として実務で主流。
- Context Compression: 過去の会話履歴を 要約してから保持 するテクニック。50ターンの会話を 500トークンの要約に圧縮すれば、コンテキストを節約しながら継続性を維持。
- Chunking 戦略: 長文を複数の塊に分けて、それぞれを別の LLM 呼び出しで処理し、結果を統合する設計。コンテキスト上限を超える長文を扱う標準テク。
- Prompt Caching: Anthropic / OpenAI が提供する機能、長いシステムプロンプトを キャッシュして再利用。長コンテキスト時代の必須コスト最適化。
コンサル感覚: クライアントが「LLM を導入したが応答が遅い・コストが高い」と相談してきた時、最初に 「プロンプトの実トークン数」 を測る。8割はここで 「無駄に長い」 問題が発覚する。プロンプトを 1/3 に圧縮するだけで、コストも速度も劇的に改善する。