AIのトークンとは？文字数・料金・コンテキストとの関係をわかりやすく解説

AI APIを使い始めると、料金表やエラーメッセージで「トークン」という言葉が出てきます。トークンは、AIが文章を扱うための単位です。人間が文字数や単語数で文章量を見るのに対して、AIモデルは入力文や出力文をトークンに分けて処理します。

トークンを理解していないと、短いつもりのプロンプトで料金が増えたり、長文を渡したときにコンテキスト上限を超えたり、出力の途中で文章が切れたりします。逆に、トークンの考え方を押さえておくと、AI APIのコスト見積もり、長文処理、ログ設計、プロンプト改善がかなり楽になります。

この記事では、AIのトークンとは何か、文字数との違い、入力トークン・出力トークン・キャッシュトークン・推論トークンの違い、料金やコンテキストウィンドウとの関係を、Web開発者向けに整理します。

前提として、LLMそのものの仕組みをまだ整理していない場合は、先に LLMとは？大規模言語モデルの仕組みとAIアプリ開発での使い方 を読むと理解しやすいです。AI全体の地図を見たい場合は、AIとは？エンジニアがWeb開発で押さえるべき基本を解説 も参考になります。

この記事の内容は、2026年7月9日時点のOpenAI公式ヘルプ、OpenAI APIドキュメント、Google for DevelopersのLLM入門をもとにしています。トークン計算、モデルの上限、料金、キャッシュ仕様は変わるため、実装前には必ず公式ドキュメントを確認してください。

結論：トークンはAI APIが入力と出力を数えるための単位

トークンは、AIモデルがテキストを処理するために分割した単位です。英単語そのものになることもあれば、単語の一部、記号、空白、文字に近い単位になることもあります。

OpenAIのヘルプでは、トークンはテキストの部品であり、単語全体だけでなく、単語の一部、句読点、空白などもトークンに含まれることがあると説明されています。Google for DevelopersのLLM入門でも、言語モデルはトークン列を扱い、トークンは単語、サブワード、文字などになり得ると説明されています。

Web開発者にとって大事なのは、次の3つです。

• AI APIの料金は、多くの場合、入力トークンと出力トークンをもとに決まる
• 一度に渡せる文章量は、モデルのコンテキスト上限に左右される
• 文字数だけでは正確なトークン数を判断できない

つまり、トークンは「AIに渡す文章量」と「AIが返す文章量」を測るための実務上の単位です。

見るもの	人間の感覚	AI APIで見る単位
入力文	文字数、単語数、行数	入力トークン
回答文	文字数、段落数	出力トークン
長文の上限	何文字まで入るか	入力と出力を含むコンテキスト上限
料金	1回いくらか	モデルごとのトークン単価

AIのトークンとは？文字数との違い

トークンは、文字数と同じではありません。日本語の1文字が必ず1トークンになるわけでも、英単語1語が必ず1トークンになるわけでもありません。

たとえば、英語では短い単語が1トークンに近いこともありますが、長い単語は複数トークンに分かれることがあります。記号、改行、空白、コードのインデント、JSONのキーや括弧もトークンとして数えられます。

日本語の場合も、ひらがな、カタカナ、漢字、記号、英数字が混ざるため、単純な文字数だけでは正確に見積もれません。特に、次のような入力は見た目以上にトークンが増えやすいです。

• 長いHTMLやMarkdownをそのまま渡す
• JSON、CSV、ログ、コードを大量に貼る
• 過去の会話履歴を毎回すべて送る
• 同じ注意書きや出力例を何度も含める
• 箇条書き、表、URL、記号が多いテキストを渡す

OpenAIのヘルプでは英語テキストの目安として、1トークンはおおよそ数文字、100トークンはおおよそ数十語という考え方が紹介されています。ただし、これはあくまで目安です。日本語、コード、絵文字、URL、モデルごとのトークナイザーでは結果が変わります。

正確に近い値を確認したい場合は、公式のTokenizerやAPIのトークン計測機能を使います。記事やアプリの設計では、文字数の概算だけで判断せず、実際のモデルでトークン数を見ておくのが安全です。

トークンが必要になる場面

トークンの理解が必要になるのは、AIの理論を深く学ぶときだけではありません。AI APIを使うWebアプリでは、かなり早い段階で必要になります。

場面	トークンを意識する理由	確認すること
料金見積もり	入力と出力の量でコストが変わる	モデル単価、平均入力、平均出力
長文要約	一度に渡せる文章量に上限がある	分割、要約、重要部分の抽出
チャット履歴	会話が長くなるほど入力が増える	履歴の圧縮、古い発言の削除
JSON出力	スキーマや例が長いと入力が増える	必要な項目だけに絞る
RAG	検索した資料を詰め込みすぎると上限を超える	検索件数、チャンクサイズ、重複削除
ログ設計	利用量を見ないと改善できない	input/output/total tokensの保存

最初のAIアプリでは、「とりあえず全文を渡す」「履歴を全部残す」「出力を長めにする」といった設計にしがちです。しかし、この設計はトークンが増えやすく、料金、速度、上限エラーの原因になります。

AI APIをアプリに組み込むなら、早い段階で「1リクエストあたりの平均入力トークン」「平均出力トークン」「最大トークン」「月間リクエスト数」を見積もっておくと運用しやすくなります。

入力トークン・出力トークン・キャッシュトークン・推論トークンの違い

トークンは、単に合計数だけを見ればよいわけではありません。APIや料金表では、入力、出力、キャッシュ、推論などに分けて扱われることがあります。

種類	意味	実装での見方
入力トークン	プロンプト、会話履歴、システム指示、参照資料など、モデルに渡す内容	長文、履歴、固定指示が増えるほど増える
出力トークン	モデルが生成する回答の量	長い回答、JSON、コード生成で増える
キャッシュトークン	繰り返し使われる入力の一部がキャッシュとして扱われるもの	同じ長い前置きや資料を何度も送る場合に関係する
推論トークン	一部のモデルで、最終出力の裏側の推論処理に使われるトークン	見える回答文だけでなく内部処理分も利用量に影響する場合がある

OpenAIのヘルプでは、入力トークン、出力トークン、キャッシュトークン、推論トークンという考え方が紹介されています。すべてのモデルやAPIで同じ見え方になるとは限りませんが、利用量を見るときは「合計」だけでなく内訳を見るのが大事です。

特に注意したいのは、出力トークンです。長い回答を許可すると、入力が短くてもコストが増えることがあります。逆に、長文資料を渡す要約アプリでは、入力トークンが大きくなりやすいです。

トークンと料金の関係

AI APIの料金は、一般的にモデルごとのトークン単価をもとに計算されます。料金表では、入力、出力、キャッシュ入力などが分かれていることがあります。

実装前の概算は、次のように考えると整理しやすいです。

概算料金 =
  入力トークン数 × 入力単価
  + 出力トークン数 × 出力単価
  + キャッシュ入力トークン数 × キャッシュ入力単価

実際には、モデル、API、キャッシュ、推論、バッチ処理、無料枠、レート制限などで条件が変わります。この記事では金額の数字は固定しません。最新の単価は、必ずOpenAI API Pricingなど各サービスの公式料金ページで確認してください。

AIアプリのコストを見積もるときは、1回の料金だけでなく、利用パターンで考えます。

項目	例	見積もりで見る理由
1回の平均入力	問い合わせ本文、履歴、固定指示、参照資料	毎回必ず発生するコストを把握する
1回の平均出力	回答文、要約、JSON、コード	長い出力ほどコストが増える
月間回数	ユーザー数 × 1人あたり利用回数	少額に見えても回数で大きくなる
最大ケース	長文資料、長い会話、複雑な指示	上限エラーや急なコスト増を防ぐ

料金を下げる具体策には、短いモデルを使う、出力を短くする、履歴を要約する、検索で必要資料だけ渡す、キャッシュを活かすなどがあります。ただし、コスト最適化そのものは別テーマです。この記事では、まずトークンと料金の読み方を押さえることに絞ります。

トークンとコンテキストウィンドウの関係

コンテキストウィンドウは、モデルが一度のリクエストで扱える文脈の上限です。ここでいう文脈には、入力だけでなく、出力に使う余白も含めて考える必要があります。

たとえば、モデルに長い資料を渡して要約させる場合、資料だけで上限ぎりぎりまで使ってしまうと、回答を生成する余地が足りなくなります。出力が途中で切れたり、期待より短い回答になったりすることがあります。

コンテキスト内で考えるもの:

- システム指示
- 開発者側の固定プロンプト
- ユーザー入力
- 会話履歴
- RAGで取得した参考資料
- 出力に必要な余白

長文を扱うアプリでは、次のような設計が必要になります。

• 渡す資料を検索やフィルタで絞る
• 長文を分割して要約する
• 会話履歴をそのまま送らず、要約して残す
• 出力に必要な最大量を先に決める
• 上限を超えたときのエラー処理を用意する

コンテキストウィンドウの設計は、トークンの次に学ぶと理解しやすいテーマです。この記事では「トークンが上限に影響する」という関係に絞り、細かい長文設計は後続記事で扱います。

Web開発での使いどころ

トークンの知識は、AI APIの裏側だけでなく、UI、DB、ログ、管理画面にも関係します。

たとえば、問い合わせ要約ツールを作る場合、ユーザーは自由に長文を貼り付けます。アプリ側では、文字数制限だけでなく、トークン数の見積もり、長すぎる入力への警告、要約の短さ、利用量ログを考える必要があります。

Webアプリでよくある実装ポイントは次のとおりです。

• 送信前に長すぎる入力を止める
• 過去の会話履歴を一定量で切る
• APIレスポンスのusageを保存する
• ユーザー別、機能別、月別に利用量を集計する
• 管理画面でコスト増の原因を確認できるようにする
• 長文資料は全文ではなく必要部分だけを渡す

JavaScriptでAPIからデータを取得する基本は、JavaScriptでJSONデータを取得する方法 ともつながります。AI APIのレスポンスも、最終的にはJSONとして受け取り、必要な値を取り出してUIやDBへ渡す流れになります。

また、API呼び出しをクライアント側へ直接置くと、APIキー漏洩や不正利用につながります。AI APIを使う場合は、サーバー側を経由する設計が基本です。クライアントとサーバーの役割は、クライアントサーバーとは？Web開発での役割をわかりやすく解説 も参考になります。

最小構成で考える処理の流れ

AI APIを使う最小構成では、リクエストを送って回答を表示するだけでなく、利用量も一緒に見るようにします。

ユーザー入力
  ↓
サーバー側でプロンプトを組み立てる
  ↓
AI APIへ送信する
  ↓
回答本文を受け取る
  ↓
usageからトークン数を取得する
  ↓
回答を表示し、利用量をログに保存する

JavaScriptで考えると、概念的には次のような形です。実際のSDK、モデル名、レスポンス形式は利用するAPIの公式ドキュメントに合わせてください。

const response = await client.responses.create({
  model: process.env.AI_MODEL,
  input: [
    {
      role: "user",
      content: "この問い合わせを3行で要約してください。\n\n" + inquiryText
    }
  ]
});

const answer = response.output_text;
const usage = response.usage;

console.log({
  inputTokens: usage?.input_tokens,
  outputTokens: usage?.output_tokens,
  totalTokens: usage?.total_tokens
});

ログとして保存するなら、最低限次のような項目があると後から見直しやすいです。

{
  "feature": "inquiry_summary",
  "model": "your-model-name",
  "input_tokens": 1200,
  "output_tokens": 180,
  "total_tokens": 1380,
  "created_at": "2026-07-09T12:00:00+09:00"
}

ここで大事なのは、本文だけでなくusageを見ることです。AIの回答品質だけを見ていると、料金や上限の問題に気づくのが遅れます。

実装前に確認すること

AI APIを本番機能に入れる前に、トークンまわりでは次の点を確認しておきます。

• 使うモデルのコンテキスト上限
• 入力、出力、キャッシュ入力などの料金単価
• レスポンスで取得できるusageの項目
• 出力の最大量を制御する設定
• 入力が長すぎるときのエラー処理
• 月間利用量を確認するログや管理画面
• 固定プロンプトとユーザー入力の分け方
• キャッシュを効かせたい場合の入力順序

OpenAIのPrompt Cachingドキュメントでは、繰り返し使う長い入力の先頭部分をキャッシュしやすいよう、静的な内容を前に置き、動的なユーザー入力を後ろに置く考え方が説明されています。キャッシュはコストや速度に影響する場合がありますが、キャッシュされた入力もレート制限などの扱いでは注意が必要です。

ただし、キャッシュを最初から複雑に設計しすぎる必要はありません。まずは、usageを保存して、どの機能でどのくらいトークンを使っているか見える状態にするのが先です。

よくある誤解と注意点

トークンまわりでは、次のような誤解が起きやすいです。

文字数が少なければ必ず安い

文字数が少なくても、記号、コード、JSON、URL、会話履歴、固定プロンプトが多いとトークンは増えます。料金は見た目の短さだけでは判断できません。

入力だけ見ればよい

出力が長い機能では、出力トークンも大きくなります。記事下書き、コード生成、長いJSON出力では、回答の長さも制御する必要があります。

コンテキスト上限まで全文を入れればよい

上限ぎりぎりまで入力を詰めると、出力の余白が足りなくなります。重要部分だけを渡す、要約する、検索で絞るといった設計が必要です。

料金表の数字だけ見れば見積もれる

実際のコストは、ユーザーの入力量、会話履歴、出力の長さ、リトライ、失敗リクエスト、モデル切り替えで変わります。小さく試してログを取り、実測値で見積もりを更新するほうが現実的です。

トークン数はどのモデルでも同じ

トークン化のされ方や上限は、モデルやサービスによって変わります。別モデルへ切り替えるときは、料金だけでなくトークン数、上限、出力品質も確認します。

次に読むべき関連記事

トークンの次は、AIアプリの周辺設計へ進むと理解しやすいです。

• LLMとは？大規模言語モデルの仕組みとAIアプリ開発での使い方: トークンを扱うモデルそのものを理解したい場合
• 生成AIとは？テキスト・画像・コード生成の仕組みを開発者向けに解説: 生成AI全体の中でLLMを位置づけたい場合
• JavaScriptでJSONデータを取得する方法: APIレスポンスを扱う基本を確認したい場合
• JavaScriptの文字列とは？基本的な使い方を初心者向けに解説: 入力文字列の扱いを整理したい場合
• 生成AIの安全な使い方｜情報漏洩・著作権・間違いを防ぐチェックリスト: AI利用時の安全面を確認したい場合

今後、コンテキストウィンドウ、プロンプトエンジニアリング、JSON出力、Structured Outputs、Function Callingの記事を追加していくと、AI APIを使ったWebアプリ設計の流れがつながります。

まとめ

AIのトークンは、AIモデルが入力と出力を扱うための単位です。文字数や単語数と完全には一致せず、モデル、言語、記号、コード、JSON、会話履歴によって数え方が変わります。

AI APIを使うときは、入力トークン、出力トークン、キャッシュトークン、推論トークンの違いを押さえ、料金表だけでなく実際のusageをログに残すことが大事です。また、トークンはコンテキストウィンドウにも関係するため、長文を扱う機能では、全文を詰め込むのではなく、分割、要約、検索、履歴整理を設計します。

最初から完璧なコスト最適化を目指す必要はありません。まずは、1リクエストで何トークン使っているかを見えるようにし、入力、出力、履歴、固定プロンプトのどこで増えているかを確認するところから始めるのがおすすめです。

参考リンク

• OpenAI Help Center: What are tokens and how to count them?
• OpenAI API: Counting tokens
• OpenAI API: Prompt caching
• OpenAI API: Pricing
• OpenAI Platform: Tokenizer
• Google for Developers: Introduction to Large Language Models