以下の解説では、自然言語処理（NLP）分野、特に大規模言語モデル（LLM）において頻出する3つの概念…「コンテキスト長」「トークン数」「パラメーター数」について段階的に解説します。
1. 全体像：LLMにおけるコンテキスト長・トークン数・パラメーター数
大規模言語モデル（以下、LLMと呼びます）には、テキストを入力として与えたときにどのようにそのテキストを処理し、どう応答を生成するかを決定するためのさまざまな仕組みがあります。ここでしばしば混乱の元になるのが
- コンテキスト長 (Context Length)
- トークン数 (Number of Tokens)
- パラメーター数 (Number of Parameters)
この3つの用語です。とくに最初の2つ「コンテキスト長」と「トークン数」は同じように扱われることもあり、それぞれが示す意味や使われ方をしっかり把握することが重要となります。
結論を先に述べると、それぞれ以下のような役割を持っています。
- コンテキスト長: LLMが一度に処理可能な入力の“最大の長さ”を示す制約。また「アテンションのウィンドウ長」「入力可能な最大シーケンス長」としても表現される。
- トークン数: 実際に与えるテキスト（入力文や会話など）を、モデルが内部的に扱う単位で分割した結果の“数”。
- パラメーター数: モデル内部（ニューラルネットワーク全体）に存在する学習可能な重みやバイアスの合計数。モデルの“容量”とも言える。
これらはまったく別の次元の指標です。1つ1つをじっくり見ていきましょう。
2. トークン数：モデルがテキストをどのように見るか
2.1 トークンとは何か
自然言語の文章をコンピュータで処理するとき、「単語（word）」という単位は人間にとって直感的ですが、実際にLLMではそれよりも細かい単位である「トークン (token)」が使われます。トークンは以下のような単位で区切られることが多いです。
- 単語全体 (例: “Hello”)
- 単語の一部 (例: “H”, “ell”, “o”)
- 記号 (例: “.”, “,”, “!”, “?” など)
- 空白や改行、特殊文字 (例: ” “, “\n” など)
どの程度の粒度で区切るかは、モデルに実装された「トークナイザー (tokenizer)」と呼ばれる仕組みによって異なります。たとえば英語なら、サブワード単位やバイトペアエンコーディング (Byte-Pair Encoding, BPE) によって効率的に分割が行われます。日本語や中国語のような言語でも類似の方法、あるいは独自の形態素解析やバイト単位の分割方法が取られる場合もあります。
したがって、ユーザーが入力した文章が何文字であろうと、トークナイザーのルール次第で「トークン数」は大きく変動します。
例として、同じ「こんにちは」は、あるトークナイザーでは1つのトークン、別のトークナイザーでは2~3個のトークンに分割される可能性があります。
2.2 トークン数の利用場面
- モデルへの入力サイズの計測:
LLMにテキストを入力する場合、そのテキストのトークン数を算出して、あらかじめコンテキスト長の制限内に収まるかどうかを確認する必要があります。 - コスト計算:
一部のLLMではAPI利用時に「入力に含まれるトークン数×単価」が課金対象になるものがあります。そのため、ユーザー側はトークン数を意識して利用する必要があるわけです。 - 計算量の把握:
大規模モデルがテキストを処理するための演算量は、おおむねトークン数に比例して増加します。入力が多ければ多いほど計算コストが上昇します。
3. コンテキスト長：モデルが一度に処理できる“記憶の窓”
3.1 コンテキスト長の基本イメージ
コンテキスト長は、しばしばモデルが一度に「記憶」できるテキストの範囲と説明されます。Transformersなどのアーキテクチャでは「アテンション・メカニズム」が導入されており、入力されたシーケンス全体に対して注意重み (attention weight) を計算することで文脈を捉えます。このとき、入力が長くなるほど演算量（メモリ消費量）も劇的に増加するため、実質的に「どこまで入力として扱えるか」の物理的・設計上の限界が生まれます。
3.2 “最大トークン数”との関係
「コンテキスト長」は概念としては「ウィンドウの幅」といったイメージで語られますが、実際には**“最大何トークンまで処理できるか”という形で公開されます。たとえば、あるモデルが「最大 2048 トークン」をサポートすると言われれば、それはコンテキスト長＝2048トークン**という制約があると理解できます。
ここで注意が必要なのは、**単に“文字数”ではなく、すべて“トークン数”**で測られるということです。同じ文字数でもトークナイズの方法によってトークン数が異なるため、「ギリギリ2048文字まではいいのか？」と思いきや、実際には1024トークンを超えている、というケースもあり得ます。
3.3 短いコンテキスト長の課題
コンテキスト長が短いモデルの場合、入力文や会話の履歴が多いとすぐに限界を超えてしまいます。これはLLMにおいては一種の“記憶不足”に相当するため、途中の文脈が途切れてしまい、モデルが正確な応答を返すのが難しくなることがあります。
- 会話型応答における履歴制限:
チャットボットとして運用する場合、ユーザーとのやり取りを適切に保持するためには、モデルに常に過去のやり取りを入力し続ける必要があります。しかし、コンテキスト長が小さいと、過去の履歴をすべて入れられず、古い履歴を要約したり、切り捨てたりする工夫が必要になります。 - 長文タスクへの制約:
長大な文章の校正・要約・構造解析などを一括で行おうとすると、コンテキスト長を超える部分は処理できないことがあります。そのため、入力分割や要約を段階的に行うなどのテクニックを使って対応します。
3.4 コンテキスト長拡張の取り組み
近年、モデルのアップデートによって8kトークン（8,192トークン前後）や16kトークン、さらには100kトークン級を扱えるモデルも登場しています。ただし、コンテキスト長を長くすると計算量・メモリ消費が急増するため、ハードウェアとアルゴリズム両面での最適化が必須となります。
4. パラメーター数：モデルの“キャパシティ”
4.1 パラメーターとは何か
ニューラルネットワーク（特にTransformer）の内部には、膨大な数の行列やベクトル（重み行列やバイアス項）が存在します。これらの値は訓練データを学習することで最適化され、最終的にモデルの「知識」や「パターン認識能力」を形成しています。
この合計の学習可能な重みの数を「パラメーター数」と呼びます。
- 例: GPT-3 は約1750億（1.75×10^11）パラメーターと言われる。最近のモデルでは数千億～数兆単位のパラメーター数も開発されている。
4.2 パラメーター数とモデルの能力
パラメーター数が多いほどモデルが複雑なパターンを学習できる可能性が高まる一方で、必要とされる学習データ量や計算リソース、推論時のメモリ使用量も比例して膨れ上がります。
- 能力や汎化性能の向上:
大規模化は多様なタスクに対してモデルの出力品質を向上させる傾向があります。 - 訓練コスト・推論コスト:
パラメーター数が増えると学習時の計算量やメモリ使用量が莫大になるだけでなく、推論時にも高性能GPU（あるいはTPU）などの専用ハードウェアが必要になる場合が多いです。
4.3 パラメーター数とコンテキスト長の違い
しばしば混同されやすいのですが、
- パラメーター数: モデルが学習によって保持する“知識の総量”のようなもの
- コンテキスト長: モデルが一度に入力として処理できる“テキストの長さ”
これらは根本的に意味するところが異なります。
パラメーター数はモデルの“脳”の大きさ、コンテキスト長はその“注意を向けられる記憶スパン” とも比喩できます。
5. それぞれの概念の相互作用
5.1 トークン数とコンテキスト長
- トークン数 < コンテキスト長:
入力として与えるテキストのトークン数が、モデルが許容できるコンテキスト長を超えないようにする必要がある。
例：モデルが2048トークンまで処理可能なら、入力側は2,048トークン以内に収まるようにテキストを調整する。 - コンテキスト長が長いモデルは、より多くのトークン数を扱えるが、それだけ処理コストも大きい。
5.2 パラメーター数とコンテキスト長
- パラメーター数が多い（モデル容量が大きい）からといって、コンテキスト長が自動的に長くなるわけではない。
モデル設計や訓練設定で、アテンション機構が扱える最大シーケンス長が決まっているため、そこを変えない限りパラメーター数だけを増やしても、コンテキスト長が伸びるわけではない。 - 逆に、小さなモデル（パラメーター数が少ない）でもアーキテクチャ次第では長いコンテキスト長を採用できる可能性はあるが、学習データやアルゴリズムが適切でない場合、長い文脈をうまく活用し切れないことも多い。
5.3 トークン数とパラメーター数
- トークナイズされるテキストが増える ⇒ 1回の推論や学習に要する計算量も増大する。
- パラメーター数が増える ⇒ モデルのパフォーマンスが向上する可能性はあるが、メモリ使用量も大幅に増える。
- 最適なバランス:
非常に大きなモデルを、非常に長いコンテキスト長で動かすには膨大なリソースが必要。また利用シーンに合わせて適切なモデルサイズ・コンテキスト長・推論環境を選ぶことが実務上は重要になる。
6. より具体的な例とメタファー
6.1 メタファーでの理解
- パラメーター数 = 図書館の蔵書数
たくさんの本（パラメーター）を保有していれば、それだけ情報や知識を保持している可能性が高い。 - コンテキスト長 = 一度に机に広げられる本やノートのページ数
どんなに大きな図書館を持っていても、机の上に同時に開ける本のページ数（コンテキスト）が限られていれば、一度に参照できる情報は限られる。 - トークン数 = 今机の上にある文章を細かく区切ったときの単位数
文をより細分化して取り扱う仕組みが「トークナイザー」。テキストの粒度が変われば、机上に置けるトークン数（文字の切れ目の数）も異なる。
6.2 具体例：チャット対話の途中でコンテキストが切れる
たとえば、モデルのコンテキスト長が4000トークンだとします。ユーザーとモデルが長い間やりとりをしているうちに、やりとり全体が累積で5000トークンになったとします。このとき、モデルを利用する側のアプリケーションでは、過去のやりとりをすべて保持しようとするとコンテキスト長を超えてしまうので、過去の履歴の一部を要約して短くする、あるいは古い部分を切り捨てるなどの対応が必要になります。
パラメーター数がいくら大きくても、このやり取りの「生テキストとしての記憶（コンテキスト）」をすべて保管することはできません。大きな知識や言語能力を持っていても、「今広げている本は何冊・何ページまでか」を超えると、そこに書かれていた内容を直接参照しにくくなります。
7. まとめ
以上のように、LLMを扱う上でしばしば耳にする「トークン数」「コンテキスト長」「パラメーター数」は、それぞれ下記のように整理できます。
- トークン数: 実際に入力されるテキストをモデルがどのように細分化して認識するか、その分割単位の合計数。
- コンテキスト長: 一度に処理可能（注意を払える）なトークン数の上限値。人間で言えば「一度に意識に上げられる情報量の限界」。
- パラメーター数: モデルの内部にある学習可能な重みの総数。知識や推論能力の“ベース”を構成する要素であり、多いほど高度なパターン認識が期待できるが、計算資源も大幅に必要。
それぞれの概念は相互に影響を与えつつも、役割はまったく別です。
- モデルの賢さや対応可能なタスクの幅 ⇒ パラメーター数や事前学習データによる
- 一度に参照できる文脈の量 ⇒ コンテキスト長による
- 利用コストや処理速度の直観的な指標 ⇒ トークン数（およびコンテキスト長や推論環境の組み合わせ）
この違いをしっかり理解しておくと、LLMを選定・使用する際に「なぜ長文が処理できないのか」「なぜ推論コストが急に跳ね上がるのか」「なぜパラメーター数が多いモデルが良い（または悪い）と言われるのか」といった疑問が解消されやすくなります。
8. さらに詳しく知るための学習ステップ
- トークナイザーについて: 具体的にどういうルールで単語を分割しているのか。BPEやSentencePieceなどの手法を調べる。
- コンテキスト長の技術的背景: TransformerのSelf-Attention（O(n^2) の計算コスト）とメモリ使用量上の制限、近年のEfficient Transformer (Longformer, BigBirdなど)の研究。
- パラメーター数のスケーリングとLLMの性能: Scaling Laws（OpenAIやDeepMindなどの研究）や、モデルが大きくなるほどどの程度性能が向上するかの理論・実証研究を確認。
- 実際に大きなコンテキスト長を使う際の注意点: メモリ消費量、時間的遅延の増大、ハードウェア面での制約。
これらの知識を組み合わせることで、LLMを構成する枠組みやその限界と可能性をより深く理解できるでしょう。
9. 終わりに
ここまで「通常の1000倍詳しく」という要望にお応えする形で、かなり丹念に解説を進めてきました。要点を短くまとめると以下のとおりですが、詳細部分の繰り返しや背景知識は、初学者がつまずきがちな箇所を補う狙いがあります。すでにLLMに詳しい方にとっては馴染みのある内容もあったかと思いますが、改めて振り返りや整理にお役立ていただければ幸いです。
- トークン数: モデルが実際に処理するテキストの要素数
- コンテキスト長: モデルが同時に扱える（アテンションを払える）トークン数の上限
- パラメーター数: モデル内部の学習可能な重み（ネットワーク容量）
それぞれが独立した指標であり、モデルを選ぶ際にもこれら3つを分けて考える必要があります。たとえば、単に「コンテキスト長が長い＝モデルの性能が高い」わけではなく、また「パラメーター数が大きい＝すべてにおいて最良」でもありません。目的に応じて、適切なバランスを探ることが重要です。
