AI導入前のトークン量見積もり方法 — コストを事前に計算する手順

AIエージェントやチャットボットが消費する token 量は、使用シーンのテキスト量とモデルの単価が決まれば、PoC 前に計算できます。本記事は、AI導入コスト事前計算を任されたシステム担当者・企画担当者向けに、前提条件の確認から Step1(入力・出力のテキスト量想定)、Step2(トークン数への変換)、Step3(1 リクエスト当たりの消費量計算)、Step4(月額コスト算出)までの手順を示します。読み終えると、自社の想定利用シーンから月額コストを自分で算出し、PoC の予算判断に反映できるようになります。

トークン量の計算は、使用するモデルと料金体系、利用シナリオの単位を先に固定しないと数値がぶれます。同じ処理量でもモデル選定や単位設計が違えば見積もり結果が変わるため、計算に入る前にこの 2 点を確定させる必要があります。

LLM の選定と料金表の確認は、トークン見積もりの最初の作業です。モデルごとに入力トークン・出力トークン・キャッシュ済み入力のそれぞれで単価が異なり、同じ処理量でも選んだモデルによって月額コストが数倍変わることがあります。見積もりに入る前に、次の 4 点を確定させる必要があります。

• 使用するモデル名（バージョン込み。モデルは廃止や後継モデルへの移行が告知されることがあるため、採用時点の対象モデルを明記する）
• 入力トークン・出力トークンそれぞれの単価（多くのプラットフォームでは「1M（百万）トークンあたり」の表記になっている）
• プロンプトキャッシュなど、同一コンテキストを再利用した場合の割引単価の有無
• 地域向けの加算や契約形態による料金差の有無

トークン の単価は料金表が更新されるたびに変わるため、見積もり資料には参照した日付と該当モデルの料金表のリンクまたはスクリーンショットを残しておくと、後から単価が変わった際の差分比較がしやすくなります。複数モデルを比較する場合は、単価だけでなく後述するトークン化効率も合わせて確認する必要があります。モデル選定の初期段階でこれらを確定させないと、Step4 で算出する月額コストの前提自体が崩れてしまいます。

処理量の単位設計は、1 リクエストに含まれるテキストをすべて数え上げることから始めます。チャット形式のやり取りでは、system プロンプト、ユーザー発言、過去の会話履歴、RAG で検索結果として挿入する文書チャンク、ツール呼び出しの定義文まで、送信されるテキストすべてがトークンとして課金対象になります。利用シナリオごとにこれらの構成要素を洗い出し、「1 リクエストで送られる全テキスト」を定義しておく必要があります。

具体的には、利用シナリオを以下の単位に分けて整理します。

• 単純な一問一答型チャットボット: system プロンプト＋ユーザー発言＋出力のみ
• RAG を使う検索併用型: 上記に加えて検索チャンク（Top-K 件数とチャンクサイズ）
• few-shot で例示を含む型: 上記に加えて例示文のトークン量
• マルチターン対応のエージェント型: 上記に加えて過去の会話履歴の累積分

この段階で単位を誤ると、Step3 の 1 リクエスト当たりの計算や Step4 の月額コスト算出がすべて狂います。RAG を使う場合はチャンクサイズと Top-K 数を先に仮決めしておき、few-shot を使う場合は例示文の件数を確定させておくと、後続のトークン数計算がスムーズになります。シナリオが複数ある場合は、シナリオ別に単位を分けて個別に見積もる必要があります。

1 リクエスト分のトークン消費は、送信する文字量と返ってくる文字量の両方で決まります。入力側はシステムプロンプトやユーザー発言の文字数、出力側は想定する応答の長さを、利用シナリオ別に数値として書き出す必要があります。

システムプロンプト の文字数見積もりは、固定文と可変文を分けて数えることから始めます。システムプロンプトは会話中ずっと同じ内容が毎リクエストに付与されるため、1 回だけ文字数を数えれば済みますが、ユーザー発言は問い合わせ内容によって長さが変わるため、短い発言と長い発言の両方で想定文字数を出しておく必要があります。

具体的には、次の 3 つを別々に数値化します。

• システムプロンプトの固定文字数(役割定義・出力形式の指示・禁止事項などを含む全文)
• ツール呼び出しを使う場合のツール定義文(関数名・引数の説明文を含む)の文字数
• ユーザー発言の想定文字数(想定される最短・最長・平均的な問い合わせ文で分ける)

RAG を使うシナリオでは、この段階ではチャンク本体の文字数は数えず、検索結果を挿入する枠があることだけを記録しておきます。チャンクサイズと件数は Step3 で加算する対象であり、ここで重複して数えると後続の計算が二重になります。few-shot 例示を使う場合は、例示文も固定文字数として同じ扱いで数えておきます。

文字数を数える際は、実際の問い合わせ文面を複数パターン用意し、最短・最長・平均の 3 パターンをそれぞれ文字数カウントすると精度が上がります。システムプロンプトについても、出力形式の指示や禁止事項を変更する予定がある場合は、変更後の文面で数え直す必要があります。この段階ではまだトークン数への変換は行わず、文字数の集計だけを完了させておくと、Step2 での変換作業が整理しやすくなります。

応答トークンの見積もりは、入力側の文字数集計とは別に扱う必要があります。応答の長さはモデルとプロンプトの指示内容によって大きく変動するため、固定文字数として扱わず、問い合わせの種類ごとに想定レンジを分けておきます。

具体的には、次の 3 パターンで応答の長さを分けて記録します。

• 一問一答で短い回答を返す設定(FAQ 回答や定型応答など)
• 説明や要約を含む中程度の回答(手順説明や複数項目の列挙を含む応答)
• 長文生成を伴う回答(文書作成支援やレポート生成など)

出力設定で最大トークン数を制限している場合は、その上限値も合わせて記録しておきます。複数の回答候補を生成する設定にしている場合は、生成数に応じて出力トークンが増える点も見積もりに含める必要があります。

この段階で正確な平均応答文字数を推定するのは難しいため、代表的な問い合わせ文でサンプル実行を行い、実際の応答文字数を計測する方法が確実です。PoC 前の設計段階でこの計測を済ませておくと、Step2 でのトークン変換作業の精度が上がります。PoC 設計全体の進め方は AI 導入の PoC 設計ガイド で扱っています。

文字数とトークン数は 1 対 1 で対応せず、言語や文字種によって変換比率が変わります。英語の目安である 1 トークン ≒ 4 文字をそのまま日本語に当てはめると誤差が大きく、BPEトークナイザーによる実測が必要です。

日本語と英語では、同じ文字数でもトークン数が異なります。英語はラテン文字が中心で、単語単位やその一部がそのままトークンとして扱われることが多く、1 トークンあたりの文字数が比較的大きくなります。一方、日本語や中国語、韓国語のような非ラテン文字の言語では、1 トークンに対応する文字数が少なくなる傾向があり、同じ文字数でもトークン数が多くなりやすい構造です。

この違いが生まれる理由は、トークナイザーの語彙がどの言語のコーパスを中心に構築されているかに依存します。BPEトークナイザーは頻出する文字列の組み合わせを語彙として登録しますが、学習データで英語の出現頻度が高いほど、英語の単語やサブワードが 1 トークンにまとまりやすくなります。日本語のひらがな・カタカナ・漢字は文字の組み合わせパターンが多様なため、同じ語彙サイズでも 1 文字単位に近い分割になりやすく、結果としてトークン消費が増えます。

この差は使用するエンコーディング（cl100k_base や o200k_base など）によっても変わるため、固定の換算比率を当てはめて計算するのは避けるべきです。日本語中心の問い合わせを想定する場合は、英語の目安である 1 トークン ≒ 4 文字をそのまま適用せず、実際の問い合わせ文で変換後のトークン数を確認する必要があります。

トークン数の実測には、換算比率の推測ではなく BPEトークナイザーを直接動かす方法を使います。OpenAI のモデルであれば tiktoken ライブラリ、Hugging Face 系のモデルであれば tokenizers ライブラリを使うと、対象モデルのエンコーディングに基づいた正確なトークン数が得られます。

実測の手順は次の通りです。

1. 対象モデルに対応するエンコーディング名を確認する（例: o200k_base や cl100k_base）
2. Step1 で集計した文字数データ(システムプロンプトの固定文、ユーザー発言の最短・最長・平均パターン、応答サンプル)をそれぞれ用意する
3. トークナイザーにテキストを渡し、返ってきたトークン数をパターンごとに記録する

このコードを、システムプロンプト・ユーザー発言・応答サンプルのそれぞれに対して実行し、文字数とトークン数の対応表を作っておくと、Step3 以降の計算で文字数から推測し直す必要がなくなります。オンラインの Tokenizer ツールでも同じ確認ができますが、件数が多い場合はライブラリで一括処理する方が効率的です。

対応表は問い合わせ文のパターン別に残し、システムプロンプトの文面を変更した際には同じ手順で数値を取り直す運用にしておくと、見積もりの前提がずれません。

1 リクエストのトークン消費量は、system プロンプト・ユーザー発言・RAG チャンク・few-shot 例・生成トークンをすべて合算した値です。単発の一問一答と、履歴を保持するマルチターン会話では累積の仕方が異なるため、分けて計算する必要があります。

RAG を組み込むリクエストでは、system プロンプトとユーザー発言に加えて、検索で取得したチャンクがそのまま入力トークンに加算されます。加算分は「チャンクサイズ × Top-K 件数」で決まるため、チャンクサイズを大きくすれば 1 件あたりのトークンは増え、Top-K を増やせば件数分だけ比例して増えます。この 2 つの変数は精度とコストのトレードオフになっており、Top-K を絞りすぎると関連文書を取り逃がし、増やしすぎると入力トークンが膨らんで月額コストを圧迫します。

計算例：チャンクサイズが 300 トークン、Top-K が 5 件の場合、RAG による加算分は 300 × 5 = 1,500 トークンです。これに system プロンプトとユーザー発言のトークン数を加えたものが、RAG 構成時の入力トークン総量になります。

few-shot 例を併用する場合は、この加算分にさらに例示文のトークン数が積み重なります。チャンクがコンテキストウィンドウの上限に近づく場合は、要約や関連度フィルタで挿入量を絞る設計が必要です。チャンク設計の最適化は Adaptive RAGとは？クエリ主導の動的検索でコストと精度を両立する方法 で扱っています。

会話履歴を保持するマルチターン設計では、1 回のやり取りごとに過去の発言と応答がすべて次のリクエストに再送されます。単発の一問一答と違い、ターン数が増えるほど入力トークンが積み上がっていく点が、累積計算で押さえるべき要点です。

計算例：system プロンプトが 200 トークン、1 ターンあたりユーザー発言 50 トークン・応答 150 トークンとした場合、3 ターン目のリクエストでは「system 200 + (50+150) × 2 ターン分の履歴 + 3 ターン目のユーザー発言 50」が入力トークンに積み重なります。ターンを重ねるほどこの履歴分が線形に増え、コンテキストウィンドウの上限に近づくと、古い発言を要約するか直近 N 件だけを残すスライディングウィンドウの運用に切り替える判断が求められます。

見積もりの段階では、想定する平均ターン数とセッション継続率を仮決めし、「1 セッションあたりの累積トークン量」を単発型のリクエスト単価とは別枠で計算しておくと、両者を混同しません。1 セッション中に話題が切り替わるケースが多いシナリオでは、履歴を保持する範囲をどこで切るかによって累積量が大きく変わるため、切り替え検知の有無も見積もりの前提に含めておく必要があります。履歴を要約で圧縮する設計を採る場合は、圧縮後の平均トークン数を実測し直してから月額コストへ反映します。

1 リクエスト分のトークン消費量が確定すれば、あとは想定リクエスト数と単価を掛け合わせるだけで月額コストが求まります。ただし平常時の数値だけでは、アクセスが集中する時間帯のコストや API 側の制限を見落とします。

月額コストは「1 リクエスト当たりのトークン消費量 × 月間リクエスト数 × 単価」で算出します。入力トークンと出力トークンは単価が異なるため、合算せず別々に計算してから合計する点が計算のポイントです。

計算例:入力トークンが 1 回あたり 1,800 トークン(system プロンプト＋ユーザー発言＋ RAG チャンク加算分)、出力トークンが 1 回あたり 300 トークン、月間リクエスト数が 50,000 回とします。この場合、入力コストは「入力トークン数（1,800）× 月間リクエスト数（50,000）÷ 1,000,000 × 入力単価」、出力コストは「出力トークン数（300）× 月間リクエスト数（50,000）÷ 1,000,000 × 出力単価」という式でそれぞれ計算し、両者を合計すると月額コストになります。単価は利用するモデルの公式料金ページを参照してください。

マルチターン設計の場合は、1 セッションあたりの累積トークン量にセッション数を掛けてから単価計算に進みます。単発型とマルチターン型が混在するシステムでは、シナリオ別に月額を分けて算出し、最後に合算すると内訳が追いやすくなります。

キャッシュ済み入力の単価が設定されているモデルでは、system プロンプトなど再利用される固定部分をキャッシュ対象として分離し、通常単価とキャッシュ単価を分けて計算すると実コストに近づきます。シナリオごとの月額を一覧化しておくと、どの構成要素がコストの大部分を占めているかを自社データで検証できます。

月額コストの計算は平均リクエスト数を使いますが、実際のアクセスは時間帯によって大きく偏ります。平常時の RPS(1 秒あたりのリクエスト数)だけで予算を組むと、営業時間帯や特定イベント時のアクセス集中を見落とし、API 側のレート制限に抵触したり、想定外のバースト分のコストが予算を超えたりします。

見積もりでは、平常時 RPS とピーク時 RPS を分けて記録し、両方で月額換算を出しておきます。モデルやプランによってはピーク帯のバースト利用で単価が変わる場合があるため、料金表でバースト時の扱いも確認しておくと計算の前提が崩れません。

計算例:平常時は 1 時間あたり 2,000 リクエスト、ピーク時間帯(1 日 2 時間)は 1 時間あたり 8,000 リクエストとします。1 日のリクエスト数は、平常時 22 時間分で 44,000 件、ピーク 2 時間分で 16,000 件、合計 60,000 件です。この合計をもとに月額コストを算出し、さらにピーク 2 時間分だけを取り出して単価計算すると、ピーク帯が月額全体の何割を占めるかが分かる仕組みです。

この比率が高いシナリオでは、キャパシティ上限に達する時間帯を先に特定し、スロットリングや非同期処理への切り替えを PoC の要件に含める判断材料になります。平常時の単価だけで予算化すると、ピーク帯の超過分が想定外の追加コストとして現れる点に注意が必要です。

見積もり誤差は、計算式の間違いより「数え忘れ」から生まれることが多く、送信テキストの一部を見落としたまま単価計算に進むと、実際の請求額が想定を大きく上回ります。固定費として扱える要素と、割引で圧縮できる要素を分けて見直すことが、誤差を縮める実質的な手段です。

システムプロンプトやツール定義のトークンを見落とす失敗は、見積もりの対象をユーザー発言と応答だけに限定してしまうケースで起こります。システムプロンプトは会話中ずっと同じ内容が毎リクエストに付与される固定分であり、文面が長い場合は 1 回あたりの入力トークンの大半を占めることもあります。この固定分を数え漏れたまま単価計算に進むと、月額コストの実測値が見積もりより高くなります。

ツール呼び出しを使う構成では、関数名・引数の説明文・返り値の型情報まで含むツール定義文もリクエストごとに送信され、入力トークンへ加算されます。ツールの数が増えるほどこの加算分は積み重なり、複数のツールを登録している AIエージェントでは、ユーザー発言よりツール定義文の方がトークン消費量が大きくなる場合もあります。登録するツールが多い構成では、使われていないツールの定義まで毎回送信していないか確認しておく判断が有効です。

見落としを防ぐ手順としては、Step1 で文字数を数える段階からシステムプロンプトの固定文とツール定義文を別枠の項目として扱い、Step3 の 1 リクエスト計算に必ず合算する運用にしておきます。文面やツール構成を変更した際は、その都度トークン数を数え直す手順も合わせて決めておくと、見積もりの前提がずれにくくなります。

プロンプトキャッシュを見積もりに含めない失敗は、システムプロンプトのような固定部分を毎回フルプライスで計算してしまうケースで起こります。同一のコンテキストを繰り返し送信する構成では、プラットフォームによってキャッシュ済み入力に通常より低い単価が適用される仕組みがあり、この割引を無視すると月額コストを実際より高く見積もることになります。固定のシステムプロンプトやツール定義文、RAG で毎回同じ文書を参照する構成は、キャッシュ対象になりやすい部分です。

反対に、履歴を要約や圧縮で縮める設計をしている場合は、圧縮後の実際のトークン量で再計算せず、圧縮前の想定値のまま月額を見積もってしまう失敗もあります。要約処理そのものにも入力・出力トークンが発生するため、圧縮によって本体の送信量が減っても、要約呼び出し分のコストを見落とすと相殺されてしまいます。

見積もりの段階では、キャッシュ対象になる固定部分とキャッシュ対象外の可変部分を分けて記録し、料金表にキャッシュ単価の項目があるかを確認してから月額計算に反映する手順を取ります。要約や圧縮を導入する場合は、圧縮前後のトークン数を両方実測し、圧縮処理自体のコストも含めて比較する必要があります。モデル別のキャッシュ・圧縮の具体的な実装パターンは LLMコスト最適化ガイド で扱っています。

見積もり結果は、PoC の検証項目に数値として組み込んでから初めて意味を持ちます。算出した月額コストをそのまま承認材料にするのではなく、代表的な問い合わせサンプルで実測したトークン数と、見積もり時の想定値を比較する工程を PoC の実施計画に含めます。

比較の結果、実測値が想定値を大きく上回った場合は、原因がシステムプロンプトの肥大化、RAG のチャンク設計、マルチターンでの履歴累積のどこにあるかを特定し、該当する設計変数を調整したうえで再計算します。複数モデルを比較する PoC では、単価だけでなく実測トークン数も含めた月額を並べ、どのモデルが総コストで優位かを判断します。

ピーク時の RPS を反映した月額も PoC の予算枠に含めておくと、本番移行時にレート制限やコスト超過で計画が崩れる事態を避けられます。見積もりに使った前提条件(モデル・単価・単位設計)は PoC 報告書に残し、本番データで再計測した際に差分を追えるようにしておきます。

トークン数を実測するツールの選び方と、モデル変更がコストに与える影響の 2 点を取り上げます。

トークン数を正確に測るツールはあります。OpenAI のオンライン Tokenizer は文面を貼るだけで手早く確認でき、件数が多い場合は tiktoken ライブラリで一括処理するのが実用的です。Hugging Face の tokenizers ライブラリも、対象モデルに対応したエンコーディングであれば実測に使えます。いずれも文字数からの推測ではなく、対象モデルのエンコーディングで直接計測する点が共通しています。

モデルごとの単価は料金表に明記されているが、単価の差分だけでは総コストを判断できません。同じテキストでもモデルが変わればトークナイザーの語彙構成が異なり、トークン数自体が増減するため、単価の違いだけでは比較の材料として不十分です。単価とトークン化効率の両方を確認してから比較する必要があります。

トークン量の見積もりは、前提条件の確定から始まり、Step1 で入力と出力のテキスト量を想定し、Step2 で文字数をトークン数へ変換し、Step3 で 1 リクエスト当たりの消費量を計算し、Step4 で想定利用回数から月額コストを算出するという順序で進めます。この流れの中で、システムプロンプトやツール定義文の数え漏れ、キャッシュ・圧縮による削減効果の見落としが誤差の主な原因になるため、固定分と可変分を分けて記録する習慣が精度を左右します。算出した数値は承認材料としてそのまま使うのではなく、代表的な問い合わせサンプルでの実測値と比較し、差分が出た設計変数を特定したうえで PoC の予算枠と検証項目に組み込む必要があります。モデル・単価・単位設計といった前提条件も記録に残し、本番データで再計測した際に差分を追えるようにしておきます。まずは自社の想定利用シーンを 1 つ選び、Step1 から文字数の集計を始めてみてください。