自分のプロンプトは何トークン？

言語モデルは文字や単語をそのまま読むのではなく、トークンを読みます。トークンとは、学習データから得られた固定の語彙表に従ってテキストを分割して生まれる断片のことです。

よく使われる単語は通常1トークンですが、珍しい単語は複数の断片に分割されます。空白は通常、直後のトークンの先頭に付加されるため、同じ単語でも文頭に来るかどうかで数え方が変わることがあります。

GPT-4oのトークナイザーで実測すると、unbelievable という単語は単独で置かれた場合、un + bel + ievable の3トークンになります。ところが実際に文中に現れる形、つまり先頭にスペースを付けた unbelievable は1トークンです。これは先頭スペースの規則が働いているためで、モデルが学習したエントリーはスペース付きの形なのです。実際の文章では、この単語はほぼ必ずその形で出現するからです。the や international も同じ振る舞いをし、スペースを含めてそれぞれ1トークンです。

これがトークン数を予測しにくく感じさせる理由です。この単位は言語学的なものではなく、統計的なものです。学習コーパス内での出現頻度が、1トークンになるか4トークンになるかを決めています。

以下は英語の文章を、GPT-4oのトークナイザーで、会話調の文章から技術的なリファレンスまでさまざまな文体にわたって実測した結果です。いずれも英語についての数値であり、日本語には当てはまりません。

• 1トークン ≈ 4.3〜5.9文字
• 1トークン ≈ 0.75〜0.95単語
• 1,000単語 ≈ 1,050〜1,350トークン
• 標準的な1ページ（約500単語）≈ 530〜680トークン

文体による違いは、たいていの目安が認めているよりずっと大きく効きます。くだけた会話調の文章はこの範囲の下限近く、1,000単語あたり約1,060トークンです。よく使われる少数の語彙を繰り返し使い、その一つひとつが1トークンに収まるからです。密度の高い技術的な文章 — 当サイトのガイド類もこれに当たります — は上限近くの約1,310トークンで、専門用語が細かく分割されるためです。よく見かける「1,000単語あたり1,300トークン」という単一の数値は、この範囲の中央ではなく技術的な文章側の端にあたるので、普通の文章では2割ほど多めに見積もることになります。とはいえコンテキストウィンドウの予算を立てるうえでは、外すなら安全な方向です。

また、普通の文章から離れるとこの目安はすぐに崩れます：

コンテンツの種類	目安
英語の文章	文体によって1トークンあたり0.75〜0.95単語
コード	同じ文字数の文章に対して約1.2倍、同じ内容を両者で書き分けた場合はおよそ1.5倍
長いキーを持つJSON	非常に多い — 句読点や引用符も個別のトークン
中国語・日本語・韓国語	1文字あたり約0.6〜0.7トークン — 1文字につき1トークン未満だが、同じ文字数の英語が消費する量の数倍
キリル文字・デーヴァナーガリー・アラビア文字	同じ内容で英語の約1.4〜1.6倍
URLやハッシュ値	非常に多い — ランダムな文字列はトークン化が苦手
連続する空白	高くつくどころか安い — バイトペアエンコーディングが長い連続をまとめるため、連続するスペース40個は1トークン

多言語間の差は実在しますが、俗説で語られるほど大きくはありません。当サイトの英語ページとそのプロによる翻訳版を実測したところ、日本語版のコストは英語の約1.7倍、韓国語は約1.5倍、中国語は約1.2倍、ヒンディー語は約1.6倍、アラビア語は約1.4倍でした。旧来の cl100k_base トークナイザーでは同じ組み合わせがそれぞれ2.3倍、2.3倍、1.7倍、4.7倍、2.9倍で、「英語の2〜3倍」という広く繰り返されてきた数字はここから来ています。当時は事実でしたが、新しい語彙表がその差をほぼ埋めました。

各モデルファミリーは独自の語彙表を持つ独自のトークナイザーを使っているため、同じテキストでもトークン数は異なります。

GPTモデルはバイトペアエンコーディングの一種を使います。GPT-4世代では cl100k_base、新しいモデルでは o200k_base です。Claudeは別の語彙表を持つ別のトークナイザーを使っています。LlamaやMistralなどのオープンモデルも、それぞれ独自のものを採用しています。

語彙表の違いが最も大きく出るのはコードと非英語テキストなので、トークン数の差もそこで最も大きくなります。

実務上これは次のことを意味します：

• あるトークナイザーのカウントは、他のモデルにとっては推定値にすぎません。
• 課金に関して正確な数値が得られるのは、プロバイダー自身のトークナイザーだけです。
• 上限ぴったりに合わせるのではなく、余裕を持って予算を立てましょう。

トークンカウンターではGPT-4oのカウントとClaudeの推定値を並べて表示します。GPT-4oの数値は実際のトークナイザーによるカウントですが、Claudeの数値は意図的にそうではありません。Anthropicはブラウザ内で実行できるトークナイザーを公開していないため、1トークンあたり3.5文字という文字数ベースの推定値を出しています。英語の文章では、この推定値はGPT-4oのカウントより22〜50%高く出ます（一般的な文章ではおよそ3分の1）。したがってこの差は、2つのモデルファミリー間の実測された違いではなく、推定の幅として読んでください。それでも、プロンプトが上限に余裕で収まっているのか、ギリギリなのかを判断するにはこの2つで十分です。正確な数値が必要な場面では、プロバイダー自身のカウンターを使ってください。

コスト。 APIの料金はトークン単位で、入力と出力は別々に価格設定され、出力のほうが数倍高いのが一般的です。システムプロンプトを2倍にすれば、すべての呼び出しでそのコストが2倍になります。テスト中は見えず、大量利用で初めて響いてくる種類のコストです。

コンテキスト制限。 コンテキストウィンドウにはすべてが含まれます。システムプロンプト、会話履歴、検索で取得した文書、現在のメッセージ、そして応答用に確保された領域です。長い会話が失敗するのは、個々のメッセージが長いからではなく、履歴が蓄積するからです。

切り捨て。 入力が上限を超えると、何かが削除されます。多くの場合、警告なしに、そして最も古い内容から失われます。「指示を忘れた」ように見えるモデルは、実際には指示が切り捨てられただけということがよくあります。

検索用のチャンク分割。 埋め込み用に文書を分割する際の単位は文字ではなくトークンです。文字数で区切られたチャンクはサイズが不揃いになり、文の途中で切れたチャンクは検索精度が下がるため、検索パイプラインには文や段落の構造を尊重する分割ツールが必要です。当サイトのテキスト分割ツールはそれには当たりません。最大2,000文字の固定サイズでチャンクに切り、単語が途中で切れないよう直近の空白位置で区切るだけなので、チャンクが文の途中で終わることがあります。長い文書をコンテキストウィンドウや貼り付けの文字数制限に通すために使ってください。検索用の埋め込みチャンクを作る用途には向きません。

効果の高い削減方法を、おおよその順番で：

1. 会話履歴を整理する。 長い会話では、これが他のすべてを圧倒します。古いやり取りをそのまま再送するのではなく、要約して送りましょう。
2. 重複する指示を削る。 同じルールを3通りに繰り返しても、守られる確率が3倍になるわけではありません。そのルールのコストが確実に3倍になるだけです。
3. 書式のゴミを取り除く。 不可視文字、連続する空白、装飾的な区切り線はすべてトークン化されます。もっとも、一つひとつのコストは思われているより安く、バイトペアエンコーディングが長い連続をまとめるため、連続するスペース40個は1トークン、ハイフン40個の区切り線は2トークンで、その上の文の13トークンには及びません。それでも純粋な無駄には違いなく、セクションごとに区切り線が入る文書では積み重なります。不可視文字を削除で目に見えないものを除去できます。
4. 構造化プロンプトではJSONのキーを短くする。 {"n": ...} と {"customer_full_name": ...} の差は、1,000件のレコードに掛け算すると非常に大きくなります。
5. 関連する抜粋だけを送る。 関連する3段落を検索して送るほうが、文書全体を貼り付けるより優れており、安いだけでなく回答の質も向上するのが普通です。

効果がないのは、普通の句読点を削除したり、冠詞を省いたり、電報のような文体で書いたりすることです。削減効果はわずかで、出力品質への悪影響のほうが大きくなります。