Unquant

Opening your workspace…

Unquant

コンテキストウィンドウが重要な理由と262Kが役立つ場面

コンテキストウィンドウは、モデルが1回のリクエストを処理する際に使える作業記憶の全体です。今の会話についてモデルが把握している情報は、すべてここに収まっています。その外にある出来事は、モデルにとっては起きなかったも同然です。

解説2分で読めます2026年10月1日更新

数値が表すもの

262,144トークン(262K)のコンテキストウィンドウは、およそ20万語の文書を一度に記憶できる容量です。小説1冊、コードリポジトリの主要ファイルすべて、数か月にわたるロールプレイの履歴などが収まります。すべてのプロンプト、応答、貼り付けた文書、ツールの実行結果が、この領域を共有します。いっぱいになると、何かを要約するか、切り詰めるか、忘れる必要があります。しかも、どの情報を落としたかをモデルが教えてくれるわけではありません。

大容量のコンテキストが役立つ場面

  • 長編ロールプレイ。 キャラクターの一貫性を保てるかどうかは、記憶にかかっています。64Kのコンテキストでは40章前の約束を忘れてしまいますが、262Kなら第1幕で交わした結婚の誓いが第12幕でも生き続けます。長く続く物語形式のロールプレイでは、品質を最も大きく左右する要素です。
  • リポジトリ全体を扱うコーディング。 関連するファイルをすべて保持できるエージェントは、局所的なパターン照合に頼らず、ファイルをまたぐ動作を推論できます。その結果、編集するファイルの取り違えや、存在しないAPIを使ってしまうミスが減ります。
  • 文書分析。 契約書、証拠開示資料、研究資料群など、文書全体がコンテキストに収まれば、相互参照を要約で落とすことなく、実際に確認できます。
  • エージェントの反復処理。 ツール呼び出しとその結果は、毎回コンテキストを消費します。エージェントの作業では、チャットよりもはるかに速くコンテキストが埋まります。タスクの途中で履歴が切り詰められると、エージェントは作業の筋道を見失ってしまいます。

2つの落とし穴:上限と品質低下

公称のコンテキスト容量が実質的に役立たなくなる原因は2つあります。1つ目は、明示されていないリクエスト単位の上限です。プランには262Kと書かれていても、APIが32Kを超えるリクエストを拒否する場合があります。「すべてのプランで、毎回のリクエストにコンテキストの全容量を使えますか」と具体的に確認しましょう。(UnquantのGLM-5.3-Flashでは可能です。全プランで262,144トークンすべてを使え、リクエスト単位の追加の上限はありません。)

2つ目は、コンテキストが長くなるにつれて生じる品質低下です。262Kトークンを受け付けられるモデルでも、序盤の細かい情報を見失うことがあります。長い会話の序盤に具体的な情報を入れ、終盤でその内容を尋ねて、自分で確かめてみましょう。

コンテキスト容量と料金の関係

多くのプロバイダーは、コンテキスト容量そのものをプランによって分けています。安いプランは32Kで、高いプランなら全容量を使える仕組みです。これは形を変えた従量課金です。Unquantの主力モデルGLM-5.3-Flashは、最も安いプランからすべてのプランで262Kの全容量を提供し、プラン間の違いは同時ストリーム数だけです。Qwen 3.8 Flash Nextのプランは、入門向けのRoleplayから64K → 262Kと段階的に容量が増え、Pro以上では全容量を使えます。

用途別の容量の目安

  • 気軽なチャット、短編小説: 64Kで十分です。1回のセッション全体が余裕をもって収まります。
  • 長期にわたるロールプレイ、中編小説ほどの長さの作品: 128K〜262Kなら、物語の展開全体を記憶に保持できます。
  • 複数ファイルのコーディング、エージェント、文書作業: 262Kを選びましょう。タスク途中のコンテキストの切り詰めが、失敗の原因になります。

詳しく知るには

モデルのページでは各モデル本来のコンテキスト容量を、料金ページではプランごとに利用できる容量を確認できます。

続けて読む