入力トークンとは？

「プロンプトトークン」は通常、同じ意味です。ただし、この名称は誤解を招くことがあります。アプリケーションやAPIによって追加された情報も、プロンプトに含まれる場合があるためです。

メッセージだけでなく、リクエスト全体

チャットボックスに「最新のレポートを要約して」と入力する場面を考えてみましょう。この文は入力の一部です。アプリケーションは、さらに次のような情報も送信することがあります。

• アシスタントの役割や動作を定める指示；
• 過去のユーザーメッセージとアシスタントメッセージ；
• レポートそのもの、またはレポートから検索・取得した文章；
• モデルが呼び出せるツールの定義；
• ツールから返された結果；そして
• 役割、メッセージの境界、または生成開始位置を示すマーカー。

これらはすべて入力トークンになる可能性があります。正確な対象は、アプリケーション、API、モデル、利用可能な機能によって異なります。

このことから、入力トークンには明確な境界があります。入力トークンとは、1つのリクエストにおける役割によって定義されるものです。あるターンでモデルが出力として生成したテキストも、アプリケーションが会話履歴として送り返す場合、次のターンでは入力になります。

リクエストが入力トークンになるまで

インターフェースからモデルに至る流れは、次のようになります。

system instructions ─┐
conversation history ├─> request formatting ─> tokenizer ─> input token IDs ─> model
documents and tools  ┤
current message ─────┘

まず、アプリケーションがリクエストのコンテキストを組み立てます。単純なAPI呼び出しには、1つのプロンプトしか含まれないことがあります。一方、本番環境のアシスタントは、指示、履歴、取得した文書、ツールのスキーマ、その他のコンテンツを追加する場合があります。

次に、サービスがその情報を選択されたモデル向けに整形します。チャットモデルは、色付きのメッセージ吹き出しによる画面上の会話記録を受け取るわけではありません。チャットテンプレート、またはそれに相当する内部形式で構成されたシーケンスを受け取ります。vLLMのチャットAPIドキュメントでは、この手順が明示されています。構造化されたメッセージは、モデルのチャットテンプレートを使ってテキストプロンプトに変換されます。

その後、トークナイザーが整形済みのシーケンスをトークンIDに変換します。Hugging Faceのトークナイザーリファレンスが示すように、この処理には正規化、テキストの断片への分割、断片のIDへの対応付け、特殊トークンの追加などが含まれることがあります。モデルごとにトークナイザーやテンプレートが異なるため、画面上で同じテキストに見えても、入力数が同じになるとは限りません。

最後に、モデルがそのトークン列を処理し、生成を開始します。応答の使用量メタデータには、プロバイダーがそのリクエストをどのように計上したかが示されます。

具体例

あるアプリケーションが、次のような例示的なリクエスト内訳を報告したとします。

• システム指示：36トークン
• ツール定義：74トークン
• 会話履歴：160トークン
• 現在のユーザーメッセージ：12トークン
• メッセージの整形と特殊トークン：15トークン

このリクエストには297入力トークンが含まれます。現在のメッセージは12トークンにすぎませんが、リクエスト全体では297トークンです。

ここで、応答に60個の生成トークンが含まれていたとします。この60個は、このリクエストにおける出力トークンです。次のターンでは、アプリケーションがこの回答を履歴に含めることがあります。その場合、同じテキストが次のリクエストの入力数に加算されます。

キャッシュは、繰り返し使用される入力の処理方法や価格を変えますが、入力としての概念上の役割を変えるものではありません。297個の入力トークンのうち200個が再利用可能なプレフィックスに由来する場合、プロバイダーはその200個をキャッシュ済み入力として別に報告したり、別料金にしたりすることがあります。それでも、それらはモデルに提供されたコンテキストです。たとえばAnthropicは、キャッシュを利用するリクエストを複数の使用量フィールドに分けています。一方、OpenAIはキャッシュ済み入力を独立した入力カテゴリとして公開しています。フィールド名がinput_tokensだからといって、それが合計全体だと決めつけず、必ず現在のフィールド定義を確認してください。

入力トークンの数え方

概算段階では、モデルに対応したトークナイザーを使ってプレーンテキストのトークン数を見積もれます。ただし、同じメッセージテンプレート、ツールの整形、特殊トークン、メディアのエンコード、プロバイダー側で追加される情報まで適用しない限り、APIの完全なカウントを確実に再現することはできません。

完全なリクエストについては、利用可能であればプロバイダーのトークン数計測エンドポイントを使用してください。Anthropicのトークン数計測エンドポイントは、メッセージ、システムプロンプト、ツール、画像、PDFを受け付けます。Googleのトークンガイドも、生成後に返される使用量とは別に、事前計算による入力数を区別しています。OpenAIのトークン数計測に関するガイダンスでは、リクエストの構造やテキスト以外の入力が完全なカウントに影響する可能性が説明されています。

事前計算によるカウントは、容量とコストの見積もりとして扱ってください。リクエスト後は、その呼び出しが実際にどのように計算され、課金されたかを記録するものとして、プロバイダーの使用量レスポンスを保存します。

入力トークンが重要な理由

コスト

多くのAPIでは、入力、キャッシュ済み入力、出力に別々の料金が設定されています。役立つコスト内訳は次のとおりです。

input cost =
  uncached input tokens × uncached input rate
  + cached input tokens × cached input rate

料金やカテゴリは変わるため、アプリケーションのロジックに価格を直接書き込むのではなく、プロバイダーの最新の料金ページを使用してください。長いシステム指示、繰り返し送信される大きなツール定義、大量に取得された文章、増え続けるチャット履歴によって、ワークロードの中で入力が最大の部分になることがあります。

利用可能なコンテキスト

入力トークンはモデルのコンテキスト内の領域を占有します。モデルやAPIの上限ルールによっては、入力が増えるほど応答に使える領域が減ります。したがって、コンテキストを追加しても容量が増えるわけではありません。他の指示、根拠となる情報、会話のターンと、モデルの注意やトークン予算を奪い合うことになります。

応答時間

モデルは最初の出力トークンを生成する前に、入力を処理しなければなりません。一般に、入力が大きいほどプロンプト処理の作業量も増えます。利用可能なキャッシュ済みプレフィックスを再利用すれば、この作業を減らせる場合がありますが、キャッシュの動作や効果はプロバイダーによって異なります。

測定

入力トークン数を使うと、文字数や単語数よりも有用なレベルでリクエストを比較できます。過大なツールスキーマ、文章を送りすぎる検索・取得システム、ターンごとに増え続ける会話履歴などを発見できます。

よくある誤解

「入力トークンは自分が入力した単語である」

入力した語句は、目に見える部分にすぎません。モデル向けのリクエストには、指示、履歴、文書、ツール、メディア、整形情報も含まれることがあります。

「1単語は1入力トークンに相当する」

トークンは、単語、単語の一部、句読点、その他のモデル固有の単位になることがあります。トークンの境界はトークナイザーによって異なります。AIにおけるトークンとは？では、この基礎となる単位を説明しています。

「キャッシュ済みトークンは、もはや入力トークンではない」

キャッシュ済みトークンは、再利用される入力です。キャッシュによって計算量、価格、使用量フィールドは変わることがありますが、キャッシュ済みプレフィックスも引き続きリクエストのコンテキストに加わります。

「アシスタントメッセージは常に出力トークンである」

生成された時点では出力です。しかし、アシスタントメッセージが後続のリクエストの履歴に含まれる場合、その後続リクエストでは入力になります。入力と出力はテキストの永続的な種類ではなく、リクエストにおける側面を表します。

「ローカルのトークナイザーで課金用のカウントが得られる」

テキスト部分については近いカウントを得られる場合があります。しかし、チャットテンプレートのマーカー、ツールスキーマ、添付ファイル、プロバイダー側の整形を見落とす可能性があります。課金記録には、APIがリクエスト後に返す使用量を使用してください。

入力トークンをより広いシステムの中で捉える

入力トークンは、リクエストにおけるモデルの開始シーケンスです。出力トークンはそのシーケンスの後に生成され、キャッシュ済み入力トークンは入力に対する処理・課金上の細分類です。これらを合わせることで、APIレスポンスや料金ページに示されるトークン内訳の大部分を説明できます。

重要なのは、組み立てられたリクエストを測定する習慣です。短いユーザーメッセージなのに予想外に大きなカウントになった場合は、トークナイザーを疑う前に、システム指示、履歴、取得した情報、ツール、整形情報を確認してください。

次に進むには

実際のAPIレスポンスを1つ調べ、入力の合計に影響する使用量フィールドをすべて特定してください。次に、同じリクエストについてプロバイダーの事前計算ツールを実行し、その見積もりと最終的な使用量を比較します。トークンの境界自体が分かりにくい場合は、まずAIにおけるトークンとは？から始めてください。続いて出力トークンとは？に進み、その後入力トークン、出力トークン、推論トークンの違いを使って、3つの課金カテゴリを比較してください。