生成AIへ長い資料を渡したとき、「まだ文字数には余裕があるはずなのに受け付けられない」「会話の最初に決めた条件を忘れたように見える」と感じることがあります。この疑問を解く鍵が、トークンとコンテキストウィンドウです。
トークンは、AIが文章を読むときの細かな単位です。コンテキストウィンドウは、そのトークンを一度に置ける作業机の広さに当たります。文字数と同じものではなく、入力資料だけで机を全部使えるわけでもありません。この2点を押さえると、長文を渡す前の見積もりと、情報を落としにくい依頼の作り方が分かります。
1. 文字数とトークン数は同じではない
人間は文章の長さを「何文字」「何語」で考えますが、生成AIは文章をトークンへ分割して処理します。トークンは、1文字の場合もあれば、単語全体や単語の一部、句読点、空白に対応する場合もあります。どこで区切るかは、利用するモデルとトークナイザーという分割器によって変わります。
たとえば「AIを仕事で使う」は9文字です。しかし、AIが必ず9個の単位として読むわけではありません。「AI」「を」「仕事」「で」「使う」のようなまとまりに見える場合も、さらに細かく分かれる場合もあります。この区切りは仕組みをつかむための模式例であり、特定モデルの実測結果ではありません。
英語には「1トークンは約4文字」という目安が案内されることがあります。ただし、OpenAIの公式説明も、この目安は英語向けであり、英語以外では文字に対するトークンの比率が高くなることがあると注意しています。日本語の記事を、英語向けの換算式だけで正確に見積もることはできません。
トークン数が重要なのは、主に次の2場面です。
- モデルが一度に扱える情報量の上限を確かめるとき
- APIの利用量や費用を見積もるとき
文章を短く見せるために空白を消しても、必ずトークンが減るとは限りません。反対に、見出しや箇条書きを加えると少し増えることはありますが、指示の境界が明確になり、回答の取り違えを減らせる場合があります。トークン数だけでなく、情報の読みやすさも一緒に考えることが大切です。
回答もトークン単位で順番に生成される
生成AIは完成した回答を倉庫から一度に取り出すのではなく、入力とそれまでに生成した内容をもとに、次のトークンの候補を計算して一つずつ文章を伸ばします。前半で選んだ表現も後続の予測材料になるため、長い回答では途中から論点がずれたり、最初の誤りが後半へ引き継がれたりすることがあります。
この性質から、トークン数は処理量の目安にはなっても、回答の賢さや正しさの点数にはなりません。長い出力ほど正確とも、上限内の情報をすべて同じ強さで使えるとも限らないため、必要な条件を整理し、区切りごとに検査します。
2. 日本語はどう分割されるのか
日本語は英語のように単語の間へ空白を置かないため、見た目だけで分割数を予測しにくい言語です。同じ漢字を含む文でも、前後の表現や採用された語彙によって区切りが変わり得ます。モデルや世代が変われば、同じ文章のトークン数が変わることもあります。
次の3つは、いずれも人間には短い表現です。
生成AI
生成AIを使う
生成AIを仕事で安全に使う
文字数は順に増えますが、トークン数が同じ比率で増えるとは限りません。「生成AI」が一まとまりになるのか、「生成」と「AI」に分かれるのか、それより細かくなるのかは、対象モデルの分割器で確かめる必要があります。
正確に知りたい場合は、サービスの公式トークン計測機能か、対象モデルに対応した公式の計測方法を使います。APIでは、送信前の計測機能に加え、応答の利用量情報に入力トークン数と出力トークン数が返ることがあります。画面型のチャットサービスでは内訳が表示されないこともあるため、文字数からの換算は「余裕を持った概算」として扱います。
たとえば、GoogleのGemini APIには、指定したモデルの分割器で入力を数える models.countTokens があります。AnthropicのToken Counting APIも、メッセージ、システム指示、ツール、画像、PDFを含む入力を、生成前に数えられます。ただし、Anthropicは事前の計測値が実際の入力トークン数とわずかに異なる場合があると説明しています。計測結果も完全な固定値ではなく、対象モデルと実行時の利用量表示を組み合わせて確認するのが安全です。
大切なのは、「日本語は常に1文字1トークン」と固定しないことです。モデルが未定の段階では正確な換算率を置かず、実際に使うモデルが決まってから短い代表文を測るほうが確実です。
3. コンテキストウィンドウは情報を置く箱
コンテキストウィンドウとは、モデルが1回の処理で参照できる情報の範囲です。短期記憶や作業机にたとえると理解しやすいでしょう。机の上に置かれていない資料は、その場の回答には利用できません。
この箱には、今送った質問だけが入るわけではありません。一般的には、会話履歴、添付した文章、システム側の指示、ツールの定義や実行結果なども入力側の情報になります。利用者からは見えない情報が含まれる場合もあるため、「上限まで丸ごと自分の資料を入れられる」とは考えないほうが安全です。
コンテキスト上限は全モデル共通ではありません。同じサービス内でもモデルごとに異なり、仕様変更で更新されます。また、「入力できる最大量」と「生成できる最大出力量」が別に示されるサービスもあります。記事に固定された数値を覚えるより、使用時に公式のモデル仕様ページを見る習慣が役立ちます。
この記事に対応する容量メーターでは、コンテキストの箱を「指示」「会話履歴」「資料」「回答用の余白」の4区間として考えます。実際の内訳はサービスによって異なりますが、何かを追加すれば、そのぶん別の用途に使える余白が減るという関係は同じです。
4. 入力と出力の合計で考える
コンテキストを見積もるときの基本形は、次の式です。
必要な枠 = 入力トークン + 生成する出力トークン
GoogleのGemini API公式資料は、コンテキストウィンドウを入力トークンと出力トークンの合計上限として説明しています。OpenAIの公式説明でも、モデルには入力と出力を合わせた最大トークン制限があるとされています。ただし、製品やAPIによって入力上限、出力上限、合計上限の示し方は異なるため、利用するサービスの仕様を優先してください。
仮に上限が10,000トークンのモデルへ9,800トークンの資料を入れたとしても、200トークンを超える回答を同じ枠から生成できるとは限りません。実際には指示や会話履歴の分も必要です。この「回答用の空席」を先に確保しておくことが、長文依頼の重要なコツです。この数値は計算を説明するための仮例であり、特定製品の上限ではありません。
APIの料金も、入力と出力を分けて示す方式が一般的です。OpenAI、Google、Anthropicの公式資料はいずれも、入力トークンと出力トークンを利用量や料金の区分として扱っています。単価はモデル、キャッシュ利用、処理方式などで変わるため、この記事では固定価格を掲載しません。費用を試算するときは、入力と出力を別々に計算し、その時点の公式料金を使います。
見積もりに含める情報のまとめ
| 区分 | 主な内容 | 見落としたときの影響 | 確認方法 |
|---|---|---|---|
| 入力 | 質問、指示、会話履歴、添付資料 | 上限超過や入力費用の増加 | 送信前の公式トークン計測機能 |
| システム・ツール情報 | サービス側の指示、ツール定義、実行結果 | 利用者が見積もった余白との差 | API仕様と実行後の利用量表示 |
| 出力 | 回答本文、構造化データ、場合によっては推論用トークン | 回答が途中で止まる、出力費用が増える | 最大出力の仕様と実行後の利用量表示 |
| キャッシュ | 再利用された入力トークン | 同じトークン数でも料金区分が変わる場合がある | 利用量のキャッシュ内訳と最新料金表 |
この表は各社に共通する考え方を整理したものです。項目名や課金対象はAPIごとに違うため、実際の計算では利用する製品の仕様を優先してください。
5. 長文で情報が落ちるのはなぜか
長い資料で情報が落ちる原因は、大きく2種類に分けられます。
1つ目は、上限を超えて箱に入らないことです。サービスによってはエラーになり、別の設定では古い会話から自動的に切り詰められることがあります。OpenAIのResponses API公式リファレンスでは、自動切り詰めを選ぶと、コンテキストを超えた場合に会話の先頭側から項目を落とす動作が説明されています。冒頭に書いた重要条件が消えれば、AIが途中から約束を忘れたように見えます。
2つ目は、上限内でも重要情報が大量の文章に埋もれることです。箱に入っていることと、すべての記述が同じ強さで回答へ反映されることは別問題です。重複する指示、古い条件、関係の薄い資料が混ざるほど、どれを優先すべきか分かりにくくなります。これは「長文なら必ず失敗する」という意味ではありません。必要な資料だけを選び、重要条件を明示することで改善できます。
長い会話を続けるときは、過去の全発言をそのまま積み上げるより、決定事項、未決事項、次にすることを短く整理して新しい依頼へ渡す方法が有効です。依頼の骨格はAIへの作業依頼を設計する方法で整理できます。回答に事実確認が必要な場合は、AIの下書きを検品する工程も組み合わせてください。
6. トークンを節約しながら精度を保つ
節約は、単に文章を削ることではありません。判断に必要な情報を残し、重複と無関係な情報を減らす作業です。
- 目的、成果物、制約、参考資料を見出しで分ける
- 同じ条件を言い換えて何度も書かない
- 長い資料は、必要な章や該当箇所だけを渡す
- 会話が長くなったら、確定事項を短い引継ぎメモにする
- 大きな資料は工程ごとに分け、各回の出力を次の入力へ使う
- 回答の長さや形式を先に指定し、不要な出力を抑える
- 実行ログや検索結果は、必要な部分だけ残す
ただし、背景を削りすぎると、AIは不足部分を推測してしまいます。固有名詞、対象期間、判断基準、してはいけないことは優先して残します。形式だけのあいさつや重複説明より、誤解したときの損失が大きい条件へトークンを使う考え方です。
一度で巨大な成果物を作らせるより、「構成を決める」「章ごとに作る」「最後に整合性を確認する」と分けたほうが、各回で参照すべき情報を絞れます。AI利用の費用を含めて計画するときは、料金だけでなく完了までの再試行や確認時間も含めて比べます。
7. 自分の文章をどう見積もるか
最も確かな方法は、実際に使うモデルの公式計測機能で数えることです。モデルが未定なら、次の順序で概算します。
- 入力を、指示、会話履歴、添付資料、ツール結果に分ける
- 代表的な日本語文を対象モデルの計測機能で測る
- その比率を資料全体へ当てはめ、概算値を出す
- 必要な回答の長さを別に見積もる
- システム側の情報や誤差に備え、上限ぎりぎりを避ける
APIを使う場合は、実行後に返る利用量情報を記録すると、次回から見積もりが現実に近づきます。「記事1本」「会議録30分」「コード100行」など、自分がよく扱う単位ごとに入力と出力の実績を残すと便利です。
最後に確認したいのは、最大トークン数だけではありません。目的に不要な情報が混ざっていないか、重要条件が資料の中へ埋もれていないか、回答用の余白を残したかを見ます。コンテキストが大きいモデルでも、整理された入力の価値は変わりません。
8. よくある質問
日本語1文字は何トークンですか?
固定の換算率はありません。同じ日本語でもモデルと分割器によって結果が変わるため、「1文字=1トークン」と決めず、対象モデルの公式計測機能で確認してください。
コンテキストウィンドウが大きければ、長文を全部覚えられますか?
上限内の情報を参照できる範囲は広がりますが、すべての記述が同じ強さで回答へ反映されるとは限りません。重要条件を短く明示し、無関係な資料や古い指示を減らすことも必要です。
トークン上限を超えるとどうなりますか?
製品や設定によって異なります。エラーで受け付けられない場合もあれば、古い会話などが切り詰められる場合もあります。自動切り詰めの有無と、どの情報から除かれるかを公式仕様で確認してください。
入力を短くすれば、必ず回答精度は上がりますか?
必ずしも上がりません。重複や無関係な部分を削るのは有効ですが、目的、対象期間、判断基準、禁止事項まで削ると誤解が増える可能性があります。短さよりも、判断に必要な情報が整理されていることを優先します。
トークン数は送信前に確認できますか?
APIによっては確認できます。Googleの models.countTokens やAnthropicのToken Counting APIのような公式機能があります。対応状況と計測対象はサービスごとに違うため、実際に使うモデルを指定して数えてください。
一次情報メモ(確認日: 2026-07-23)
- OpenAI「What are tokens and how to count them?」: トークンの定義、非英語で比率が変わること、入力・出力等の利用量区分、合計上限を確認。https://help.openai.com/en/articles/4936856-what-are-tokens-and-how-to-count-them
- OpenAI API Reference「Responses streaming」: 上限超過時の自動切り詰めと、入力・出力・合計トークンの利用量項目を確認。https://platform.openai.com/docs/api-reference/responses-streaming/response/refusal/delta
- Google AI for Developers「Understand and count tokens」: トークン化の定義、入力・出力トークンが費用に関係することを確認。https://ai.google.dev/gemini-api/docs/tokens
- Google AI for Developers「Long context」: コンテキストウィンドウの定義と、長い入力の扱い方を確認。https://ai.google.dev/gemini-api/docs/long-context
- Anthropic「Pricing」: 入力、出力、キャッシュを別区分で計算する料金体系と、モデルによってトークナイザーが異なる例を確認。https://platform.claude.com/docs/en/about-claude/pricing
- Google AI for Developers API Reference「Counting tokens」:
models.countTokensが指定モデルで入力を分割し、合計トークン数を返すことを確認。https://ai.google.dev/api/tokens - Anthropic「Token counting」: 送信前にシステム指示、ツール、画像、PDFを含む入力を数えられることと、実際の入力数とは小さな差が生じ得ることを確認。https://platform.claude.com/docs/en/build-with-claude/token-counting
個別モデルのコンテキスト上限、最大出力、料金は更新されるため、利用時に各社のモデル仕様・料金ページで再確認してください。
次に読む記事
- 基礎の全体像は生成AIの仕組み
- 処理段階の区別はAIの学習と推論の違い
- 情報取得との違いは生成AIと検索エンジンの違い
執筆: テック羅針盤編集部。方法: 各社の一次資料を照合し、固定値ではなく見積もり手順として整理。最終確認日: 2026-08-23。広告・アフィリエイト: なし。