AIのトークンとは？文字数・料金との関係を解説

AIのトークンは、モデルが文章などの入力や出力を処理するときに使う分割単位です。

文字数や単語数とは一致せず、言語やtokenizerによって分割が変わります。日本語の文字数を固定倍率でトークン数へ換算することはできません。

APIではトークン数が利用量や料金、コンテキスト上限に関係します。料金を見積もるときは、実際のリクエストで入力と出力を分けて計測します。

トークンは処理用の単位

OpenAIのHelpでは、tokenは一文字ほど短い場合も、単語全体ほど長い場合もあり、languageとcontextで分割が変わると説明されています。

日本語の文字数から固定換算しない

英語では「1 token ≈ 4 characters」という目安がありますが、tokenizationはlanguageとencodingで異なります。日本語の文字数から固定倍率で正確に計算しません。

入力と出力を分けて見る

promptや会話履歴として送るものがinput token、modelが生成するresponseがoutput tokenです。APIでは別単価になっている場合があります。

キャッシュされた入力を確認する

同じcontextを再利用する仕組みではcached tokenとして別categoryで計測され、通常inputより低いrateが設定されるservice / modelがあります。

トークン数と料金の関係

API pricingはmodelごとにinput / outputなどのtoken単価が決まる方式が一般的です。長いpromptと長いresponseを大量に使うほどcostが増えます。

コンテキスト上限と利用量

inputとoutputにはmodelごとのcombined limitがあります。長大なdocumentを入れると、remaining outputや他contextの余地が減ります。

会話履歴やツール結果も入力になる

retrievalしたchunk、tool result、system instructionなど、modelへ実際に渡されるtextはinput tokenへ影響します。visibleなuser promptだけがtoken対象ではありません。

実際のリクエストで計測する

文字数だけで概算せず、providerのtokenizerやSDKを使います。OpenAIではTokenizer toolやtiktokenによる確認方法が案内されています。

実際の請求までつなぐ計算例

計算の出発点は、token数だけでなく、その数字がどのリクエストの何を表すかです。たとえば、社内FAQへ回答するAPIを考えます。利用者の質問、毎回送る共通指示、検索で取得したFAQ断片が入力になり、回答が出力になります。検索結果を追加すれば入力は増え、回答を詳しく指定すれば出力も増えます。実測で「質問だけ」の数を見ても、本番で必要な費用は見積もれません。

手順は、実際のリクエストを組み立て、利用先のtoken count機能で入力を測り、同じ設定で複数の代表質問を実行し、usageから出力を読むことです。最後に現行の料金表へ入力と出力を別々に当てはめます。表が100万単位なら、その単位に揃えてから単価を掛けます。値を丸める場合でも計算途中では丸めず、合計後に表示用の桁へ整えると、小さな差が積み重なるのを防げます。

月間費用は、一件の平均だけでなく件数の分布を使います。短い質問が大半でも、長い履歴や複数回の検索が必要な質問が一定割合あれば、その群を分けて計算します。たとえば「通常」「長文」「検索追加」の三群に分け、各群の件数、入力の実測、出力の実測、再試行の割合を記録します。群ごとの総額を足し、利用量に応じた他の課金がある場合は別項目として加えます。ここで作る数値は自社データから取り、記事のために架空の月額料金を設定しません。

Usageを使った確認表

表は横にスクロールできます

確認欄	記録する内容	見つけられる問題
request_id	リクエストを識別する値	再実行や障害との照合
model	実際に呼んだモデル	料金表の選択違い
input tokens	APIが返す入力数	履歴・検索結果の増加
output tokens	APIが返す出力数	回答長や再試行の増加
cache usage	提供側が返す区分	キャッシュ前提の誤見積り
tool calls	検索・実行の回数	最終回答以外の処理増加
success	Reader Jobの合格条件	失敗分の再処理費用
latency	利用者が待った時間	品質と速度の交換条件

実際に存在しないusage項目を無理に作らず、利用中のAPIが返す項目に合わせます。ログには問い合わせ本文や秘密情報をそのまま保存しないでください。調査に必要な識別子と件数だけで十分かを先に決めます。個人情報を含む可能性がある入力は、計測用データを作る段階で匿名化し、アクセスできる人と保存期間も定めます。

数え方を変える前に確認すること

入力を短くする施策を行う前に、どの部分を減らすのか特定します。共通指示が毎回重複しているなら、APIの状態管理やキャッシュの対象にできるかを調べます。検索結果が多すぎるなら、検索条件や取得件数を見直します。ただし、関連する根拠を落として回答が不正確になるなら、節約として成功とは言えません。削減前後で同じ評価ケースを実行し、正しさ、根拠の提示、取りこぼし、費用を並べて比べます。

出力を短くする場合は、必要な結論、根拠、次の行動が残るようにします。文字数上限だけを厳しくすると、例外条件や注意点が消えることがあります。回答形式を短くしてもReader Jobが完了するかを判定し、短縮で失敗が増えたケースを確認してください。品質基準を通過しない処理の費用を安くしても、実務上のコストが下がったとは限りません。

APIと月額サービスを混同しない

APIは、呼び出したモデルと利用量に基づいて課金される方式が一般的です。一方、利用者向けチャット画面の月額プランは、利用回数や機能、混雑時の制限など別の条件で提供されることがあります。チャット画面で表示した文章のトークン数へAPI単価を掛けても、その人の月額請求額にはなりません。利用しているのがAPIか、月額サービスか、第三者アプリの独自課金かを先に確かめます。

月額サービスの制限は、トークン数ではなくメッセージ数、一定時間内の利用量、機能ごとの上限として説明されることもあります。プランの名称だけで上限や価格を断定せず、契約中のサービスと地域の公式プラン情報を確認してください。変動する料金や制限を記事に掲載する場合は、確認日と一次情報を示し、変更されたときに更新できるようにします。

読者が次に確認する項目

APIの費用が知りたい人は、まず利用中のモデルと料金単位を特定し、入力と出力のusageを実リクエストで取得します。次に、会話履歴、検索結果、ファイル、ツールのどれが入力を増やしているかを見ます。キャッシュを使う場合は、usageの区分と適用条件を確認します。最後に、自分の利用件数を掛けた月間予測と、実績の請求を照合します。

モデルが変わったとき、長文機能を追加したとき、検索件数やsystem指示を変えたときは、同じ見積もりを再評価してください。API提供側の価格改定だけでなく、利用者の入力分布やアプリの構成が変わることでも費用は変わります。前回の一件だけを見て「この文章は何円」と固定せず、いつ、どのモデル・条件で測った値かを一緒に記録するのが実務的です。

参考にする公式情報

OpenAI APIの入力token数計測は、Responses API形式に沿って入力を確認するための手段です。文字だけを対象とするtokenizerとの違いを踏まえて使います。料金はモデルと処理区分により異なるので、公開時点の料金表を使い、記事へ固定価格を埋め込まない方針にします。Prompt cachingも、読み取り・書き込みの条件と料金がモデル別であるため、機能説明だけから節約率を決めないでください。

料金見積もりを検証する小さなテスト

予算を決めるときは、まず5〜10件程度の代表的なリクエストを集め、短い質問だけでなく、長い履歴、複数の検索結果、回答を再生成するケースも含めます。全利用を予測できる数ではありませんが、どの条件が入力や出力を増やすかを把握できます。同じ内容を同じモデル・設定で実行し、入力、出力、ツール利用、処理時間、Reader Jobの合否を一行ずつ残します。

たとえば、検索結果を増やしたときに入力が増えた一方で正答率が変わらなければ、取得件数を減らす候補になります。回答を短くしたとき費用が減っても、根拠や次の手順が欠けたなら採用しません。変更は一度に一つにし、同じ評価ケースで前後を比較します。こうすると「tokenを減らす」こと自体ではなく、必要な品質を保ったまま費用を下げられたかを判断できます。

記録する数値には、モデル名、API名、料金表を確認した日を添えます。モデルや課金方式を変更した場合は、以前のテストを新しい条件へそのまま流用せず、代表ケースを取り直します。入力仕様が更新された場合も、画像やツール情報が追加されていないかを確認してください。

AIものさしの判断

tokenはAIの「文字数」ではなく、model内部でtextを扱う分割単位です。

料金を見るときはinput / output / cachedなどの区分と、利用modelの単価を確認します。

特に日本語では英語の文字数換算をそのまま使わず、実tokenizerで計測するのが確実です。