トークンとコンテキストウィンドウ：AIが文章を読む仕組み

AI の言語モデルは、文字や単語を読んでいるわけではありません。読んでいるのはトークンです。トークンとはテキストの小さなかたまりで、単語まるごとのこともあれば、単語の一部のこともあります。そしてモデルが一度に受け取れるトークンの数には限りがあり、この上限をコンテキストウィンドウと呼びます。この2つの考え方で、AI ツールの料金体系がなぜああなっているのか、長いチャットがなぜ初めの指示を忘れはじめるのか、正しく綴ったばかりの単語の文字数をなぜモデルが数えられないことがあるのかが説明できます。

AI におけるトークンとは

モデルがプロンプトを見る前に、トークナイザーというプログラムが、決まった語彙の中からテキストを断片に分割し、各断片を数値に変えます。モデルはその数値だけを扱い、返答も同じように1トークンずつ書いていき、アプリがそれをテキストに戻します。

語彙は大量のテキストから学習されるので、よく使われる単語は1トークンになりやすく、まれな単語はなじみのある複数の断片に分けられます。英語では、空白がうしろの単語の先頭にくっつくことがよくあります。たとえば英語の文はおおよそ次のように分割されます。

Token ization isn 't magic .

この分割はあくまで説明のための例です。モデルファミリーごとに独自のトークナイザーがあり、同じ文でも分割される断片の数が変わります。多くの提供元がトークナイザーのツールやトークン数を数える API を公開しているので、実際の数はそこで確かめられます。

画像、音声、ファイルも、モデルが受け付ける場合はトークンに変換されます。添付したスクリーンショットが、文章と同じ予算の一部を使うのはこのためです。

1単語は何トークンか

英語のテキストでは、1トークンあたりおよそ4文字、つまり1単語のだいたい4分の3という目安が広く使われています。この見積もりでは、1,000 トークンはおよそ750語で、3,000語の記事はおよそ4,000 トークンになります。

この比率は内容によって変わります。

• 英語以外の言語は、同じ意味でもより多くのトークンを使うことがよくあります。トークナイザーは英語の比重が大きいデータで学習されているため、英語の単語はコンパクトなトークンになる一方、日本語、韓国語、アラビア語、ヒンディー語など多くの言語の文章はより多くの断片に分割されます。差はトークナイザーによって異なり、新しいものでは縮まっていますが、なくなってはいません。
• コードは、インデント、括弧、演算子、長い識別子にトークンを使うので、ファイルの語数から想像するより多くのトークンがかかることがよくあります。
• 数字、URL、珍しい文字列（ID やハッシュなど）は、小さなトークンにたくさん分割されがちです。

トークンが重要な理由

コスト。 API はトークン単位で課金され、送るトークンとモデルが書くトークンで料金が分かれています。チャットでは新しいメッセージのたびに会話全体が送り直されるので、長い会話は短い会話よりメッセージあたりのコストが高くなります。

上限。 モデルには、1回のリクエストで読み書きするものすべてに対するコンテキストウィンドウがあり、さらに1回の返答の長さに別の上限があることもよくあります。API ではその上限を自分で設定でき、Anthropic の API では設定が必須です。max_tokens は必須のパラメータです。

速度。 返答はトークンを1つずつ続けて生成するので、返答が長いほど、それに比例して完成までに時間がかかります。

文字単位のタスク。 モデルは magic のような単語を5つの文字ではなく1つか2つの単位として見ているので、個々の文字に依存するタスク（文字数を数える、単語を逆から書く、ちょうど何文字の単語を探す、など）は見た目より難しくなります。新しいモデルの多くはこうしたタスクを以前よりうまくこなしますが、文字が重要なときは答えを確認するか、まず単語を1文字ずつ書き出すようモデルに頼んでください。

コンテキストウィンドウとは

コンテキストウィンドウとは、1回のリクエストでモデルが考慮できるトークン数の上限です。モデルの作業記憶だと考えてください。モデルが返答を書くために使えるものは、すべて一度にこの中に収まっていなければなりません。含まれるのは次のものです。

• システムプロンプト（アプリ自身の指示とあなたの指示）
• それまでの会話（すべてのユーザーメッセージとすべての返答）
• 添付ファイル、貼り付けた文書、検索やツールの結果
• 書いている途中の返答

ウィンドウの外にあるものは、モデルにとって存在しません。モデルが調べに行けるような裏の記憶はありません。コンテキストウィンドウの大きさはモデルによって大きく異なり、どんどん大きくなっているので、記事に書かれた数字を当てにせず、使っているモデルの提供元のドキュメントを確認してください。

モデルはリクエストとリクエストのあいだに何も保持しません。チャットで記憶のように見えるものは、アプリが毎回会話全体を送り直しているだけです。チャットアプリのメモリ機能も同じ仕組みで、アプリがあなたについてのメモを保存したり過去のチャットを検索したりして、見つけたものを新しいチャットのコンテキストに入れています。

チャットが長くなると起きること

会話がコンテキストウィンドウを超えると、何かを削るしかありません。アプリによって、いちばん古いメッセージが削られる、古い部分が要約に置き換えられる、チャットが上限に達したので新しく始めるよう伝えられる、のいずれかになります。どの場合も、最初のメッセージで出した指示を含め、初めのほうの詳細が答えに影響しなくなることがあります。

ウィンドウがいっぱいになることだけが問題ではありません。モデルの目の前にある素材が多いほど見落とす余地も増え、長いチャットでは、初めのほうの決定がそのあとに言われたすべてのことと競い合います。症状としては、前に決めた制約を無視した答え、すでに直したバージョンに戻ってしまうコード、却下したアイデアを繰り返すモデルなどがあります。

コンテキストウィンドウの中でうまくやる方法

タスクごとに新しいチャットを始める。 明確な最初のメッセージで始めた新しいチャットのほうが、いくつもの話題をさまよった長いチャットより、たいていうまくいきます。

要約を引き継ぐ。 チャットの中に役立つ決定が積み重なってきたら、新しいチャットに貼り付けるための要約を書いてもらい、そちらで続けます。下の空欄を自分の作業に合わせて埋めてください。

新しいチャットで続ける

EditCopy

Fill in成果物文字数

このチャットが長くなってきました。作業を続けるために新しいチャットに貼り付けられる要約を書いてください。含める内容は、目的、決めたこととその理由、データベースのスキーマの現在の版、未解決の疑問点です。データベースのスキーマそのものを除いて、要約は400字以内にしてください。

Try it

Example replyReplies vary between models and runs.

目的：小さな図書館アプリ用のデータベースを SQLite で作る。

決めたこと：

• 貸出は専用のテーブルにし、貸出履歴をすべて残す。
• returned_at が空の貸出がない本を貸出可能とみなす。

現在のスキーマ：

CREATE TABLE books (id INTEGER PRIMARY KEY, title TEXT NOT NULL, author TEXT NOT NULL);
CREATE TABLE members (id INTEGER PRIMARY KEY, name TEXT NOT NULL, email TEXT UNIQUE);
CREATE TABLE loans (
  id INTEGER PRIMARY KEY,
  book_id INTEGER NOT NULL REFERENCES books(id),
  member_id INTEGER NOT NULL REFERENCES members(id),
  loaned_at TEXT NOT NULL,
  returned_at TEXT
);

未解決の疑問点：

• 延滞料金は必要か？
• 同じ本の複数の冊数を管理すべきか？

タスクに必要なものだけを貼り付ける。 リポジトリ全体ではなく、バグのある関数とそれを呼び出しているコード。40ページの契約書すべてではなく、問題になっている条項。素材が少なければ、見落とす余地も少なくなります。

長い素材のあとに質問を置き、大事なことを繰り返す。 長い文書を貼り付けるときは、そのあと、末尾で質問し、重要な制約もそこで繰り返します。そうすると、モデルが書きはじめる位置のすぐ近くに指示が来ます。

1通に収まらない長さの文書は分割する。 アプリによっては、モデルのウィンドウにはもっと入る場合でも、1通のメッセージに貼り付けられる量を制限しています。文書を分けて送ればメッセージの上限は回避できますが、コンテキストウィンドウは回避できません。どの部分もウィンドウに数えられます。すべて送り終えるまで返答しないよう、最初にモデルに伝えてください。

各部を送る質問する

EditCopy

Fill in全部数質問

これから長い文書を3回に分けて送ります。各部を受け取るたびに「第N部を受け取りました（全3部）」とだけ返し、それ以外は何も書かないでください。私が質問するまで、要約も回答もしないでください。 第1部（全3部）： """ [第1部を貼り付け] """

Try it

Example replyReplies vary between models and runs.

第1部を受け取りました（全3部）

必要なときはトークンを数える。 API を使って開発しているなら、送る前に数えましょう。OpenAI のオープンソースライブラリ tiktoken は OpenAI のトークナイザーでテキストをトークン化でき、Anthropic の API にはトークン数を数えるエンドポイントがあります。ある提供元のトークナイザーで数えた値は、別の提供元にとっては目安にすぎません。

import tiktoken

enc = tiktoken.get_encoding("o200k_base")  # one of OpenAI's tokenizers
tokens = enc.encode("Tokenization isn't magic.")
print(len(tokens))
print([enc.decode([t]) for t in tokens])

モデルを中心にアプリを作るときは、ウィンドウに何をどの順番で入れるかを決めること自体が1つの設計課題になります。それはコンテキストエンジニアリングで扱っています。大きな仕事を、それぞれ無理なく収まるステップに分ける方法はプロンプトチェーンで紹介しています。1通のメッセージが入力全体の中にどう収まるかはプロンプトとはを参照してください。