「ChatGPT APIの料金表に『100万トークン○○ドル』と書かれているが、自社の利用量がいくらになるのかピンとこない」「開発会社の見積書に『月間トークン数の試算』という項目があったが、何をどう確認すればよいかわからない」——LLMを使ったシステムを発注・運用するなかで、こうした場面に直面する方は少なくありません。
トークンはLLMのコストと処理上限を決める基本単位です。文字数でもバイト数でもないため、日常的な感覚と少しずれており、「思ったより高くなった」「想定よりコンテキストが入らない」といったトラブルにつながりやすい論点でもあります。
本記事では、トークンとは何か・どのように料金や処理上限と結びつくのか・自社利用量をどう試算するか・コストを抑えるための基本的な考え方を、エンジニア向けの細かい実装よりもビジネス上の判断材料に重きを置いて解説します。読み終えたあとには、開発会社の見積書や利用量レポートを読み解き、自社のコストを自分で試算できるようになります。
社内で ChatGPT を使い始めるための実践ガイド――ルール策定・安全なプロンプト設計・部門展開テンプレート付き
この資料でわかること
ChatGPT・生成 AI の社内展開を担当しているが「何から始めれば良いか分からない」情シス・総務・DX 推進担当者に対し、ルール策定・安全な利用環境整備・部門展開のロードマップを一気通貫で提示し、「自社で着手できる」という確信と具体的なアクションプランを持ってもらうこと。
こんな方におすすめです
- 社内ChatGPTの利用ルールを策定したい方
- 情報漏洩リスクを回避しながらAIを展開したい方
- 部門別のプロンプト活用例を知りたい方
入力いただいたメールアドレスにPDFをお送りします。
トークンとは？LLMが文章を扱うときの基本単位
トークン（token）とは、LLM（大規模言語モデル）が文章を処理する際に使う「文字をまとめた小さな単位」のことです。LLMは文章をそのまま読んでいるわけではなく、内部では一度トークンに分解してから処理しています。
トークンは「文字」とも「単語」とも違う
トークンは、文字（1文字ずつ）でも単語（スペース区切り）でもありません。LLMの開発元が独自に決めた辞書に基づいて、よく出てくる文字列をひとまとめにした「断片」です。
たとえば英語の場合、apple のような短い単語は1トークンで表現されることが多い一方、internationalization のような長い単語は inter national ization といった複数のトークンに分割されることがあります。日本語の場合は、ひらがな1文字が1トークンになることもあれば、漢字1文字が複数トークンに分割されることもあります。
ざっくりとした目安としては、英語は1トークン＝約4文字／約0.75単語、日本語は1トークン＝約0.5〜1文字程度と覚えておくと、初期の試算で大きく外しにくくなります。
「トークナイザー」がモデルごとに違う
文章をトークンに分割する仕組みを「トークナイザー（tokenizer）」と呼びます。重要なのは、トークナイザーはLLMごと・シリーズごとに異なるという点です。同じ文章でも、OpenAIのGPTシリーズとAnthropicのClaudeシリーズでは、トークン数が一致しません。
そのため「日本語1,000文字を入力した場合のトークン数」も、利用するモデルによって変わります。正確な数値が必要な場面では、各社が提供しているトークナイザーツール（OpenAIのTokenizerなど）で実際に数えるのが確実です。
LLMの利用は「入力トークン＋出力トークン」で課金される
LLM APIの料金は、ほとんどの場合「入力トークン×単価」と「出力トークン×単価」の合計で計算されます。
- 入力トークン: ユーザーが送った質問・指示文・前提情報・会話履歴・参照ドキュメントなど、モデルに渡すすべての文字列
- 出力トークン: モデルが返す回答文
特に注意すべきは、入力には「これまでのやり取り」も毎回まるごと含まれる点です。チャットを長く続けるほど、毎回の入力トークンが膨らみ、料金が増えていきます。
LLM全体の概要については LLMとは？発注者がAI開発を依頼する前に知っておくべき基礎知識 も合わせてご覧ください。
なぜLLMはトークン単位で処理するのか
「文字単位ではなくトークン単位で処理する」と聞くと、技術的なこだわりのように感じるかもしれません。しかし、トークンを使うことには明確な理由があり、これを理解しておくと、料金体系や処理上限の意味が腹落ちしやすくなります。
計算量を抑えるための「ちょうどよい単位」
LLMは膨大な数の文章を学習して文脈を理解する仕組みになっています。もし1文字ずつ処理していると、1つの文を処理するのに必要な計算量が膨大になり、応答に時間がかかります。一方、単語単位だと、世界中の言語の単語をすべて辞書に登録する必要があり、現実的ではありません。
そこで、頻出する文字列をひとまとめにし、出現頻度の低い長い単語は分割するという折衷案が「トークン」です。計算量と語彙の表現力のバランスが取れた単位として、現代のLLMで広く採用されています。
多言語を同じ仕組みで扱うため
英語・日本語・中国語・コードなど、多様な入力をひとつのモデルで扱う必要があります。文字単位や単語単位だと言語ごとに仕組みが分かれてしまいますが、トークンであれば「文字種を問わず断片に分けて処理する」という共通の枠組みで扱えます。これがLLMの多言語対応を支えています。
結果として「料金」と「上限」がトークンに連動する
トークンは計算上の単位であるため、LLMの利用コスト（GPUの稼働時間や処理量）はトークン数とほぼ比例します。そのため、API料金もトークン課金になっていますし、「一度に処理できる最大量＝コンテキストウィンドウ」もトークン数で表現されます。
つまり、トークン数の感覚を持っているかどうかが、そのままコスト感覚と「どれくらいの情報を一度に渡せるか」の感覚に直結します。
日本語と英語でトークン数はどう違うのか
LLMを日本語で使う場合に押さえておきたいのが、英語よりもトークン消費が多くなりやすいという特徴です。これは料金とコンテキストウィンドウの両方に影響します。
日本語は英語よりトークンを多く消費する傾向がある
多くのLLM（特にOpenAIのGPTシリーズなど）は、英語データを中心にトークナイザーが学習されています。そのため英語のほうが「効率よく」トークン化され、同じ意味の内容でも日本語のほうがトークン数が増える傾向があります。
おおよその目安として、以下のように考えると初期試算で大きく外しにくくなります。
言語 | 1トークンあたりの文字数の目安 | 1,000文字あたりのトークン数の目安 |
|---|---|---|
英語 | 約4文字（約0.75単語） | 約250トークン |
日本語 | 約0.5〜1文字 | 約1,000〜2,000トークン |
プログラムコード | 約3〜4文字 | 約250〜350トークン |
※モデル・トークナイザーによって幅があるため、正確な数値は各社のツールでの実測を推奨します。
同じ予算でも処理できる情報量が変わる
たとえば「100万トークンあたり3ドル」というモデルを日本語と英語で使う場合、英語であれば約400万文字相当を処理できますが、日本語では約50万〜100万文字相当しか処理できません。コストパフォーマンスとしては、日本語は英語の3〜4倍程度かかるイメージです。
これは「日本語向けに割高な料金が設定されている」のではなく、トークン数の差によって発生する自然なコスト差です。発注時には、英語の事例で算出された費用感をそのまま日本語に当てはめないように注意してください。
日本語に強いモデル・最適化されたトークナイザーも増えている
近年は日本語向けに最適化されたモデルや、多言語をより均等に扱うトークナイザーも増えています。「日本語の利用量が大きい」「日本語コストを抑えたい」という要件がある場合は、開発会社に「このモデルは日本語のトークン効率がどの程度か」を確認するとよいでしょう。
API料金とトークンの関係を具体例で理解する
ここからは、具体的な数値で料金感を掴んでいきます。実際の単価はモデル・提供会社・改定タイミングによって変わるため、ここでは「考え方」と「概算の手順」を中心に説明します。
入力と出力で単価が異なるのが一般的
LLM APIの単価は、入力と出力で別々に設定されているのが一般的です。多くの場合、出力トークンのほうが入力トークンより数倍高く設定されています。
区分 | 単価のイメージ（モデルにより数倍〜10倍以上の差） |
|---|---|
入力トークン | 比較的安い |
出力トークン | 入力よりも高い（多くの場合数倍） |
そのため「長い質問を送っても回答が短い処理」と「短い質問に対して長文を生成する処理」では、トークン数が同じでもコストが大きく異なります。
月間コストの概算手順
たとえば「社内の問い合わせチャットボットを作りたい」というケースで、月間コストを概算してみます。
- 想定される1リクエストあたりの平均トークン数を見積もる
- 入力: 質問文＋システムプロンプト＋関連社内情報の参照 → 例: 2,000トークン
- 出力: 回答文 → 例: 500トークン
- 想定される月間リクエスト数を見積もる
- 例: 1日100件×営業日20日 = 月2,000リクエスト
- 月間トークン数を計算する
- 入力: 2,000トークン × 2,000リクエスト = 400万トークン
- 出力: 500トークン × 2,000リクエスト = 100万トークン
- 単価をかける
- 入力単価が「100万トークンあたり3ドル」、出力単価が「100万トークンあたり15ドル」と仮定すると
- 入力: 400万 × 3ドル = 12ドル
- 出力: 100万 × 15ドル = 15ドル
- 合計: 月27ドル（およそ4,000円程度）
このように、ボリュームが小さいうちはAPI利用料は数千円〜数万円規模に収まることも多くあります。一方で、利用量や同時接続数が大きくなると、月数十万円〜数百万円規模になるケースもあります。
想定外のコスト増加が起きやすい3パターン
事前の概算と実際の請求がずれやすい代表的なパターンを押さえておくと、運用後のトラブルを減らせます。
- 会話履歴の累積: チャット形式のシステムでは、過去のやり取りをすべて毎回入力に含める実装になっていると、後半のリクエストほど入力トークンが膨らみます。
- 長文ドキュメントの参照: RAG（社内文書を参照する仕組み）で長いドキュメントをそのまま添付すると、1リクエストあたりのトークンが想定の数倍になりがちです。
- 再生成・自動リトライ: ユーザーが「もう一度生成」を多用したり、エラー時に自動で複数回再試行する設計になっていると、見た目以上にトークンを消費します。
LLMをAPIで組み込む際の全体像については LLM API連携開発の完全ガイド｜既存システムへの組み込み方・費用・セキュリティを解説 も参考にしてください。
コンテキストウィンドウ（最大トークン数）の意味
「コンテキストウィンドウ」はトークンに関するもうひとつの重要な概念です。これは料金ではなく「一度に扱える情報量の上限」に関わる話です。
入力と出力の合計に対して上限がかかる
コンテキストウィンドウとは、モデルが一度のリクエストで扱える最大トークン数のことです。多くのモデルでは、入力トークンと出力トークンの合計がこの上限を超えないように設計されています。
たとえばコンテキストウィンドウが「128,000トークン」のモデルでは、入力で12万トークンを使ってしまうと、残り8,000トークン分しか出力できません。長文ドキュメントをすべて入力に詰め込むと、肝心の回答が途中で切れる事態も起こり得ます。
「ウィンドウが大きいほど良い」とは限らない
最近では数十万〜数百万トークン規模のコンテキストウィンドウを謳うモデルも登場しています。これにより「マニュアル全文をそのまま渡して質問する」といった使い方も技術的には可能になりました。
ただし、ウィンドウが大きいほどよいとは限らないことには注意が必要です。
- 入力トークンが多いほど料金は線形に増加します
- 入力が長くなるほど応答時間（レイテンシ）が伸びます
- 入力が長すぎると、モデルが重要箇所を見落としやすくなる傾向も知られています
そのため実務では、「全部入れる」よりも「必要な部分だけを検索して渡す」（RAGなど）の方が、コスト・速度・精度のいずれの観点でも有利になることが多くあります。
発注時に必ず確認したい3つのトークン上限
LLMを使ったシステムを発注する際、以下の3つの上限を開発会社に確認しておくと、後の手戻りを防ぎやすくなります。
- モデル全体のコンテキストウィンドウ: 利用予定モデルの最大トークン数
- 1リクエストあたりの想定入力トークン: システム設計上、最大でどれくらい入力に含める想定か
- 1リクエストあたりの想定出力トークン（max_tokens）: 出力をどこまで許容するか
これらが事前に整合していないと、「テストでは動いたのに、本番のドキュメントだと長すぎてエラーになる」「想定よりトークンが膨らみ請求額が跳ね上がる」といった問題が発生します。
トークンを意識したコスト最適化の基本
トークンの仕組みが分かれば、コスト最適化の方向性も見えてきます。実装の細部はエンジニアの領域ですが、発注者・運用担当者として知っておくと意思決定の解像度が上がる、代表的な3つの考え方を整理します。
1. プロンプトを短く・必要な情報だけにする
最も即効性のある施策が、入力プロンプトの圧縮です。
- システムプロンプト（モデルへの指示文）に冗長な説明を入れない
- 過去の会話履歴を全件保持せず、最新のN件＋要約だけ渡す
- 参照ドキュメントは全文ではなく、関連箇所のみ抽出して渡す
「全部入れたほうが安心」という発想は、トークンの世界ではコスト増・精度低下の両方につながりやすい点に注意してください。
2. 用途ごとにモデルを使い分ける
LLMの提供各社は、高性能だが単価の高い「上位モデル」と、軽量で安価な「廉価モデル」をシリーズで用意しています。
- 高い精度や複雑な推論が必要な場面では上位モデル
- 単純な分類・要約・タグ付けなど、難易度の低い処理は廉価モデル
このように用途ごとに使い分けるだけで、システム全体のトークン課金額が大きく下がるケースは少なくありません。発注時に「どのモデルをどの処理で使う想定か」を確認することをおすすめします。
3. キャッシュ・バッチ処理を活用する
各社のAPIでは、同じプロンプトの再利用に対する「プロンプトキャッシュ」や、即時応答が不要な大量処理向けの「バッチ処理」など、コストを抑える仕組みが提供されています。
- プロンプトキャッシュ: 同じシステムプロンプトを繰り返し使う場合に、入力トークンが大幅割引される
- バッチ処理: 数時間以内の応答で十分な大量処理向けに、料金を割り引いて提供される
社内向けのナレッジ検索や、夜間バッチでのデータ整形のような用途では、これらを活用するとコストを半分以下に抑えられる場合もあります。仕様の詳細はモデルや提供会社によって異なるため、開発会社と相談して採用可否を判断するとよいでしょう。
まとめ
本記事では、LLMの「トークン」について、コストと処理上限の判断材料となる観点を中心に解説しました。
- トークンとは: LLMが文章を処理するときの基本単位。文字でも単語でもなく、モデルごとの辞書に基づく断片
- 料金との関係: ほとんどのLLM APIは「入力トークン×単価＋出力トークン×単価」で課金される。出力単価は入力単価より高めに設定されているのが一般的
- 日本語の特徴: 日本語は英語よりトークン消費が多くなりやすく、英語事例の費用感をそのまま流用すると過小見積もりになりやすい
- コンテキストウィンドウ: 入力と出力の合計に対して上限がかかるトークン数。大きければよいわけではなく、コスト・速度・精度のバランスで判断する
- コスト最適化の基本: プロンプト圧縮／用途別モデル使い分け／キャッシュ・バッチ活用の3つを、用途と要件に応じて組み合わせる
トークンは技術的な細部のように見えて、LLM活用の費用対効果を左右する重要な経営指標でもあります。発注時にはAPI料金だけでなく「想定月間トークン数」「コンテキストウィンドウ」「コスト最適化の方針」を開発会社に確認し、自社の利用量で長期的に成立するシステムを設計してください。
社内で ChatGPT を使い始めるための実践ガイド――ルール策定・安全なプロンプト設計・部門展開テンプレート付き
この資料でわかること
ChatGPT・生成 AI の社内展開を担当しているが「何から始めれば良いか分からない」情シス・総務・DX 推進担当者に対し、ルール策定・安全な利用環境整備・部門展開のロードマップを一気通貫で提示し、「自社で着手できる」という確信と具体的なアクションプランを持ってもらうこと。
こんな方におすすめです
- 社内ChatGPTの利用ルールを策定したい方
- 情報漏洩リスクを回避しながらAIを展開したい方
- 部門別のプロンプト活用例を知りたい方
入力いただいたメールアドレスにPDFをお送りします。
