← 概念辨析に戻る

Concept Contrast Fable

コンテキストウィンドウとコンテキスト長:一方は何を入れられるかを管理し、他方はどれだけ入れられるかを管理する

先に結論:製品ドキュメントや調達リストでは、コンテキストウィンドウとコンテキスト長がしばしば互換的に使われる。しかし予算評価やアーキテクチャ設計では、ウィンドウはモデルが長い会話を理解できるかという能力そのものを表し、長さは具体的な数字である。この二つの言葉を混用すると、見積書の数字と実際に動かせるシナリオがしばしば一致しなくなる。

製品ドキュメントや調達リストでは、コンテキストウィンドウとコンテキスト長がしばしば互換的に使われる。しかし予算評価やアーキテクチャ設計では、ウィンドウはモデルが長い会話を理解できるかという能力そのものを表し、長さは具体的な数字である。この二つの言葉を混用すると、見積書の数字と実際に動かせるシナリオがしばしば一致しなくなる。

寓話

閲覧室の机と本棚

公文書館の閲覧室には大きな机があり、研究員はその日に使う巻宗を机に広げ、一冊読み終えると次に替える。机の存在により、研究員は毎回書庫へ戻らずに済む——これは部屋で最も重要な設計である。

新館長が就任すると、各机の側面にラベルを貼らせ、机の上に同時に何冊の巻宗を置けるかを書かせた。この数字は使い勝手がよく、研究者は席を予約する時まずラベルを見て、今日最大どれだけ資料を広げられるか把握できた。

問題は翌年の購買シーズンに起きた。行政部が各科室に需要を記入させる表を配ったが、欄は「閲覧室配置」の一つだけだった。ある者は「大きな机が必要」と書き、ある者は「十二冊の巻宗を置ける必要がある」と書いた。購買部は「十二冊」という数字で同じ机を統一購入した結果、二つの研究グループはそんなに資料を広げる必要はなかったが、地図や図面を置くためにより広い天板が必要だった。机の長さは足りたが幅が足りず、地図は折って見るしかなかった。

事後の振り返りで初めて、書桌と天板容量が調達表で同じものとして扱われていたことがわかった。書桌は機能である。研究者が部屋で直接作業できるようにする。天板容量は数字である。今のこの机に同時に何冊置けるか。数字は表に載せやすいが、機能こそが机をどんな形にすべきかを決める。

2年目の表は2行に分かれた。1行目は「閲覧室のデスクトップ機能は必要か」、2行目は「必要なデスクトップ容量はおよそどのくらいか」と問う。2つの問いは2種類の予算に対応する。機能予算はその能力を持つかどうかを決め、容量予算は同時にどれだけの情報量を処理できるかを決める。

ある科室の記入方法は意外だった。ある法律チームは一行目に「はい」、二行目には「四冊」とだけ書いた。彼らが求めたのは大容量ではなく、安定したデスク照明と、机の上でスキャナーを広げる空間だった。容量の数字ばかり尋ね続けていれば、このニーズは永遠に浮かび上がらない。

後に文書館は内部ルールを一つ出した。閲覧室に関わる購入申請は、一行目に機能——机があるか、座席がいくつあるか——を書き、二行目に容量——各机に材料をどれだけ置けるか、電源は足りるか——を書く。機能と容量を分けて記録すれば、購入は一つの数字に振り回されない。

コンテキストウィンドウ

モデルが単一の推論で受け取り参照できる入力情報の範囲であり、アーキテクチャ能力の一種である——ウィンドウの有無が、モデルが長文を処理できるかどうかを決める。

コンテキスト長

コンテキストウィンドウの具体的な数値は、通常トークン数で計量され、「どれだけ入れられるか」を表す。同じモデルでも版や設定によって長さが異なることがある。

物語の対応

  • 閲覧室の机そのもの:コンテキストウィンドウは、一つの機能として存在する
  • 机に何冊の文書ファイルを置けるか:コンテキスト長は、機能の具体的な容量数値である
  • 購買が「十二冊入る」と聞いて机を統一購入:長さだけ問い窓の形を問わず設定がミスマッチ
  • 地図グループに必要なのは長さではなく幅:窓の構造能力が必要で、token 上限ではない場面もある

Agent プロジェクトに落とし込む

技術選定をするとき、要件文書ではコンテキストウィンドウ機能とコンテキスト長を分けて書く。まず「モデルが長コンテキスト能力を備えているか」を確認し、次に「現行バージョンがサポートする token 上限が業務文案の長さ要件を満たすか」を確認する。見積もりと負荷テストはどちらも、機能カバー範囲と容量上限の二つの数字を同時に提示すべきである。

京ICP备2026014272号