ホーム / 用語集 / コンテキストウィンドウ
コンテキストウィンドウとは？
コンテキストウィンドウとは、LLMが1リクエストで処理できる最大トークン数(入力+出力の合計)のことです。最新モデルでは4 Kから2 Mトークンに及びます。osFoundryのカタログには各モデルのコンテキストウィンドウが記載されています。
詳しく
トークンはテキストをモデルが扱う単位に分割したものです。英語では平均して1トークンあたり3〜4文字ですが、日本語はかな・漢字の混在によりトークン効率が悪く、トークナイザにもよりますが1文字が1トークン以上を消費することも珍しくありません。同じ内容の文書でも、日本語は英語より2倍前後のトークンを使うことがあり、128Kトークンのウィンドウは日本語でおおむね10万字前後が目安になります。
コンテキストウィンドウは入力だけのものではありません。システムプロンプト、会話のこれまでの履歴、RAGで挿入された参照文書、そしてこれから生成される出力が、すべて同じウィンドウを分け合います。チャットが長くなると突然「前の話を忘れる」のは、古いやり取りが上限に収まるよう切り捨てまたは要約されているためです。
公称の上限まで品質が保たれるとは限りません。長い入力では、冒頭と末尾に比べて中間部の情報を拾い損ねやすい傾向(いわゆる lost in the middle)が研究報告として知られています。長文をまるごと渡した要約で後半や中盤が雑になる典型的な症状は、この実効コンテキストの限界から来ています。
ローカル実行では、コンテキスト長はメモリ消費に直結します。モデルは処理中の文脈をKVキャッシュとして保持し、その大きさはコンテキスト長にほぼ比例します。つまり長いコンテキスト設定にするほど、モデルの重みとは別にVRAM/RAMが必要になり、生成速度も落ちます。手元のマシンで長文を扱うときは、量子化レベルと並んでコンテキスト設定を確認することになります。
2026年時点の目安として、クラウドのフラッグシップは100万〜200万トークン級、標準クラスは128K〜400K程度、ローカルモデルは設定次第ですが実用上は8K〜128Kの範囲で運用されることが多い状況です。上限を超える文書を扱うには、分割して渡す、多段で要約する、RAGで関連部分だけを取り出して渡す、といった設計で対処します。
osFoundryでの扱い
osFoundryのナレッジベース+RAGパイプラインは、クエリごとに関連チャンクだけを取得し、コンテキストウィンドウを集中させます。必要であればカタログからより広いウィンドウを持つモデルを選ぶこともできます。
よくある質問
128Kトークンは日本語で何文字ですか?
トークナイザに依存しますが、おおむね10万字前後が目安です。日本語は英語より1トークンあたりの文字数が少なく、同じ内容でもトークン消費が多くなりがちです。
コンテキストウィンドウを超えるとどうなりますか?
超過分は切り捨てられるか、ツール側で古い履歴の要約・削除が行われます。エラーとして知らせてくれるか、黙って欠落するかは実装によります。長い会議録の要約で途中の話題が消えるのは典型的な超過の症状です。
ウィンドウが大きいモデルほど良いのですか?
上限が大きいほど柔軟ですが、長い入力は処理コストと応答時間が増え、中間情報の取りこぼしも起きやすくなります。必要な文脈だけを渡す設計(チャンキングやRAG)のほうが品質が安定することが多いです。
関連用語
関連機能