トークンとは、LLM（大規模言語モデル）が文章を処理する最小単位で、語や語の一部の「かたまり」です。LLMは文章を文字のままではなく、このトークンの列に分けてから扱います。生成AIの料金・入力できる量の上限・処理の重さは、すべてこのトークン数で数えます。AI検索対策で「AIに渡せる情報量」や「どこに要点を置くか」を考えるとき、必ず基準になるのがこのトークンです。
トークン（token）は、英語で「しるし・単位」を意味する語で、LLMの文脈では「モデルが文章を扱う際の最小の処理単位」を指します。人間は文章を「文字」や「単語」で捉えますが、LLMはそのどちらでもなく、独自の分割ルールで区切った「トークン」という単位で捉えます。この分割を行う仕組みをトークナイザー（tokenizer＝トークン化器）と呼び、文章を入力するとトークンの列に変換し、モデルの出力を人間が読める文章に戻す役割も担います。
トークンの区切り方は「1文字＝1トークン」でも「1単語＝1トークン」でもありません。よく使われる語はまとめて1トークンに、珍しい語や複雑な語は複数のトークンに分割される、という中間的な方式（サブワード分割＝単語をさらに細かい断片に分ける方式）が一般的です。たとえば英語の一般的な単語は1トークンに収まることが多い一方、専門用語や造語は複数トークンに割れます。日本語は文字種が多く1文字あたりの情報量が大きいため、英語より1文字あたりのトークン消費が多くなる傾向があります。この「言語によってトークンの消費効率が違う」点は、日本語でAI検索対策を行ううえで見落とせません。
トークンがAI検索対策で重要なのは、それが3つの実務上の制約すべての「数える単位」だからです。第一に料金。生成AIのAPI利用料は、多くの場合「入力トークン数」と「出力トークン数」に応じた従量課金です。長い文章を処理させれば、そのぶんトークンが増え、費用も増えます。第二に入力上限。AIが一度に扱える情報量（コンテキストウィンドウ）はトークン数で上限が決まっており、これを超える情報は渡せません。第三に処理の重さ。扱うトークンが増えるほど、応答に時間もかかります。
AI検索の内部では、ユーザーの問いに答えるために、Webから集めた複数の文書をLLMに渡します（RAG）。このとき渡せる文書量はトークン数で制限されるため、AIは限られたトークン枠の中に収まる情報しか一度に見られません。ここに、AIO対策の実務的な示唆があります。自社ページが仮にAIに取得されても、要点が文章の後半に埋もれていたり、冗長で1ページのトークン消費が大きかったりすると、限られた枠の中で要点まで届かず、引用されにくくなります。「少ないトークンで要点が伝わる」構造にすることが、そのままAIに読み取られやすさへ直結します。
さらに、AIO対策の効果測定やコスト管理の観点でも、トークンは基準単位になります。当ラボが複数のAI検索サービスに同じ問いを繰り返し投げて引用のされ方を観測する際、その調査コストはトークン数で積み上がります。どのモデルを何問・何回観測するかという設計は、トークン単価と処理量の掛け算で費用が決まるため、トークンの理解なしには研究予算の設計もできません。トークンは、対策の効き方（引用されやすさ）と、対策・観測のコストの、両面をつなぐ共通の物差しなのです。
LLMが文章を扱う流れの中で、トークンがどう使われるかを順に見ます。入力から出力まで、トークンは一貫して処理の基本単位です。
- 入力の分解: ユーザーの文章を、トークナイザーがトークンの列に分割する（例: 文章→複数のトークン片）
- 数値化: 各トークンを、モデルが計算できる番号（ID）に変換します。LLMは実際にはこの番号列を処理している
- 予測: モデルが「次に来るトークン」を確率で予測し、1トークンずつ出力を決める
- 生成の繰り返し: 出力したトークンを踏まえて次のトークンを予測、を繰り返して回答トークン列を作る
- 文章への復元: 出力トークン列を、トークナイザーが人間の読める文章に戻す
ここで押さえたいのは、料金や上限で数える「トークン数」が、入力側と出力側の両方に発生する点です。長い質問文（入力トークン）を投げれば入力側が増え、長い回答（出力トークン）を求めれば出力側が増えます。多くのサービスでは、入力トークンと出力トークンで単価が異なります。AI検索の内部でRAGを行う場合、取得した文書はすべて入力トークンとして数えられるため、「たくさんの文書を渡す＝入力トークンが増える＝費用と処理が重くなる」という関係になります。この構造が、AI検索が無制限に文書を取り込めない根本理由でもあります。
なぜ文字でも単語でもなく、トークンという中間的な単位を使うのかにも触れておきます。文字単位だと、扱う単位が細かすぎて長い文章を処理するのに膨大な計算が必要になります。逆に単語単位だと、世の中のあらゆる単語・造語・専門用語を辞書に持たねばならず、知らない単語（未知語）に対応できません。よく使う語はまとめ、珍しい語は既知の断片に分割するサブワード方式は、この両極端のあいだで「計算量」と「未知語への強さ」を両立させる折衷案です。だからこそ、同じ意味の文でも、使われている語の珍しさによってトークン数が変わってくるのです。
この仕組みは、AI検索対策の細かな判断にも影響します。たとえば、独自の商品名や造語を多用したページは、その語が複数トークンに分割されるため、同じ情報量でもトークン消費が増えがちです。一般的で分かりやすい言葉で要点を書くことは、読者にとって理解しやすいだけでなく、トークン効率の面でもAIに扱われやすくなる、という副次的な利点があります。逆に、意味の薄い装飾的な語や定型的な前置きを重ねると、そのぶんトークンを浪費し、限られた枠の中で肝心の要点が後ろへ押しやられます。トークンの理解は、こうした「どの言葉を選び、どこに置くか」という文章設計の判断に、具体的な根拠を与えてくれます。
トークン数の「桁感」を掴むための目安を示します。区切り方はモデルごとのトークナイザーで異なり、下記はあくまで概算です。正確な数は各社の数え方で確認してください。
文章とトークン数の関係（概算の目安）| 対象 | 概算のトークン感 | 補足 |
|---|
| 英語の一般的な単語 | 約1トークン | 珍しい語・専門語は複数トークンに割れる |
| 日本語のテキスト | 1文字あたり1トークン前後 | 英語より1文字あたりの消費が多くなりやすい |
| 短いメール1通 | 数百トークン規模 | 内容量で大きく変わる |
| 長文記事1本 | 数千トークン規模 | RAGで渡すと入力トークンとして加算される |
横にスクロールできます
この目安から分かるのは、日本語のコンテンツは英語より1文字あたりのトークン消費が大きくなりやすい、という点です。つまり、同じ入力上限（コンテキストウィンドウ）でも、日本語のほうが「入る文字数」は少なくなりがちです。日本語でAI検索対策を行う場合、限られたトークン枠の中に要点を収める工夫が、英語圏以上に効いてきます。冗長な言い回しを避け、結論と根拠を前に置く書き方は、読みやすさだけでなく、トークン効率の面からもAIに拾われやすさへつながります。
実務でトークン数を意識する典型的な場面を挙げておきます。第一に、AIを使ったツールを自社で作るときです。処理する文章が長ければ、そのぶんトークン課金がかさむため、事前に量を見積もる必要があります。第二に、RAGで自社の資料をAIに渡すときです。一度に渡せる量には上限があるので、資料を適切な大きさに分割し、関連する部分だけを選んで渡す設計が要ります。第三に、AI検索での引用のされやすさを高めるときです。冗長な1ページはトークンを浪費し、要点が窓の後ろへ押しやられるため、簡潔に要点を前へ置く書き方が効きます。これらはいずれも、トークンという単位を理解していないと勘所を外す判断です。
- 入力トークン: AIに渡す質問文・文脈・RAGで取り込む文書。ここが増えると費用と処理が増える
- 出力トークン: AIが生成する回答。長い回答を求めるほど増えます。入力と単価が異なることが多い
- コンテキスト上限: 入力＋出力の合計トークンが、モデルの上限を超えられない
トークンを軸に見ると、「なぜRAG（検索拡張生成＝外部文書を取り込んでから答えを作る手法）が必要で、なぜそれにコストがかかるのか」が一本の線でつながります。LLMは学習時点までの知識しか内部に持たないため、最新・固有の情報は外部から入力トークンとして与える必要があります。ところが入力できる量にはコンテキストウィンドウ（＝一度に扱えるトークン上限）という天井があり、渡した文書はすべて入力トークンとして課金対象になります。つまり「たくさんの文書を渡して精度を上げたい」という要求と、「トークンの上限とコストを抑えたい」という制約が正面から衝突します。RAGが「全文書を渡す」のでなく「関連する文書だけを選んで渡す」設計になっているのは、このトークンをめぐる矛盾を解くためです。
この関係はAIO対策の打ち手を具体化します。RAGが限られたトークン枠に収まる文書だけを選ぶ以上、自社ページは「少ないトークンで要点が伝わる」ほど枠の中に収まりやすく、要点まで読まれやすいです。冗長で1ページのトークン消費が大きいページは、同じ枠を奪い合う競合ページに押し出されて要点が届かず、引用の材料になりません。トークン効率を高めることは、費用の節約であると同時に、限られた窓の中で自社の要点をAIの視野へ入れる競争力そのものだ、と捉えると腑に落ちます。
もう一つの注意点は、「トークンを節約すること自体が目的ではない」ことです。トークン効率は重要ですが、要点を削って短くしすぎ、根拠や出典まで落としてしまえば、AIに引用される材料を失います。目指すべきは「無駄なトークンを減らしつつ、引用の材料となる結論・数値・出典は確実に残す」バランスです。トークンは制約であって、コンテンツの価値そのものではありません。制約の中で価値を最大化する、という視点を持つことが実務では大切です。
トークン数を厳密に予測できない、という点にも注意が必要です。同じ文章でも、モデルごとにトークナイザーが異なるため、トークン数は変わります。あるモデルで測ったトークン数を、別のモデルのコストや上限の計算にそのまま使うことはできません。とくに日本語は、モデルによって分割の効率差が出やすく、思ったより多くのトークンを消費して上限に達したり、費用が想定を上回ったりすることがあります。コストや入力上限がシビアに効く場面では、必ず実際に使うモデルの数え方でトークン数を確認し、余裕を見て設計する――この慎重さが、後からの予算超過や処理エラーを防ぎます。
- 単位を理解する: 料金・入力上限・処理量はすべてトークンで数える、と前提を押さえる
- 日本語の消費を織り込む: 日本語は英語よりトークン消費が多い前提で、要点を前に・簡潔に置く
- 要点を前方に置く: 限られたトークン枠でAIに要点が届くよう、結論・根拠を冒頭に配置する
- 冗長さを削る: 意味のない前置き・繰り返しを減らし、引用の材料は残したままトークンを圧縮する
- 正確に数える: コストや上限の判断が必要なときは、対象モデルの数え方でトークン数を確認する
トークンと文字数は同じですか。
違います。トークンはよく使う語をまとめ、珍しい語を分割する単位で、文字数とは一致しません。おおまかに日本語は1文字あたり1トークン前後、英語は1トークンあたり数文字が目安です。
なぜトークンで料金を数えるのですか。
LLMは文章をトークン単位で処理するため、処理量＝トークン数になるからです。入力トークンと出力トークンそれぞれに応じた従量課金が一般的です。
日本語はトークンで不利ですか。
1文字あたりのトークン消費が英語より多くなりやすいため、同じ上限でも入る文字数は少なくなりがちです。だからこそ日本語では、要点を前に簡潔に置く設計がより効きます。
AI検索対策でトークンをどう活かせばよいですか。
限られたトークン枠でAIに要点が届くよう、結論・数値・出典を冒頭に置き、冗長な表現を削ることです。トークン効率と引用されやすさは同じ方向を向いています。
