なぜLLMは答えられるのか？トークンとコンテキストとは何か？

はじめまして。エンジニア歴4ヶ月、WEELでFastAPIを用いたAIアプリケーション開発に取り組んでいる瀬戸口です。

これまで私は、AIアプリを開発していながらAIやLLMをどこか「魔法のようなもの」として扱ってきました。

しかし実際に学んでいくと、LLMの本質はあくまで**「ドキュメント補完」**であり、魔法でも万能の知能でもなく、明確な仕組みに基づいて動いていることを理解しました。

この記事では、私自身が学んだ LLMの基本原理 を整理し、

• 「なぜLLMは答えられるのか」
• 「トークンやコンテキストとは何か」
• 「LLMが抱える限界と、それを補う仕組み」

といった点を解説していきます。

これらを理解しておくことで、業務におけるAI活用や制御をより効率的に行えるようになると感じています。

LLMの本質は「ドキュメント補完」

今の生成AIはさまざまな用途に使用されており魔法のように感じます。

しかしその本質はとてもシンプルで、「テキストの続きを補う（補完する）」 という仕組みにすぎません。

LLMの基本原理

例えば「フランスの首都は…」と入力すると、モデル内部では次の単語の確率が計算されます。

• 「パリ」 → 90%
• 「ロンドン」 → 5%
• 「東京」 → 3%

もっとも確からしい単語を選んで返すだけ。

つまりLLMは、「次に来るトークン（単語や記号のかたまり）が何か」 を統計的に予測して文章を繋いでいるのです。

トークンとトークナイザー

LLMが文章を扱うときの最小単位が トークン です。トークンとは、単語や記号、文字のまとまりのこと。

例えば次の文はGPT4oではこのようなトークンに分けられます。

• 「[猫]」 → 1トークン
• 「[かわ][いい][猫]」 → 3トークン
• 「[The] [cat] [is] [cute]」 → 4トークン

LLMは文章をそのまま理解できないので、まず 文章 → トークン → 数値（ID、ベクトル） に変換してから処理をします。

この分割を行うのがトークナイザーです。

トークナイザーはモデル毎に固定でテキストを必ず同じルールでトークン列に変換するので、同じ文章なら必ず同じトークン列になります（曖昧さがない）。

コンテキストと制御

LLMは万能に会話を覚えているわけではなく、「どこまで入力や履歴を保持できるか」＝コンテキスト という制限があります。

コンテキストとは

コンテキスト = 会話履歴も含めた入力全体をテキストとして処理できる長さのことです。

文章は長すぎると処理できないため、トークンに分けて「どこまで覚えておけるか」が決まっています。

コンテキストウィンドウ

モデルには「最大トークン数（ウィンドウサイズ）」が設定されています。

それを超えると古い部分は切り捨てられるか要約される。

この枠を超えると、古い会話は切り捨てられるか、要約されて圧縮されます。

つまり「AIが急に忘れた」ように見えるのは、ウィンドウから溢れたからなのです。

Temperature

LLMが次のトークンを選ぶときの“ランダムさの強さ”を調整するパラメータです。

値は0.0〜2.0 の範囲で設定できます。

• 0.0 → 一番確率の高い単語だけを選ぶ（答えが安定しやすい、計算や事実回答に向く）
• 1.0 → 確率分布に従って選ぶ（創造的な文章に向く）
• 2.0 → ランダム性がさらに強まり、予測不能な文になりやすい

※GPT-5ではデフォルトが 1固定 と言われています。

LLMの限界を補う仕組み

LLMは強力ですが 限界 があります。

• 知識の限界：学習時点までの情報しか知らず、最新情報や特定の内部データにはアクセスできない
• 実行力の欠如：計算やAPI呼び出しのような「外部の処理」を直接は行えない

こうした弱点を補うために生まれた代表的な仕組みが Function Calling やRAGです。

Function Calling

LLMが「外部の処理を実行できない」という限界を補う仕組みです。

APIや関数を呼び出せるようにすることで、LLMは単なる回答生成にとどまらず、実際のアクションを起こせるエージェントとして使えるようになります。

Function Callingの仕組み

1. ユーザーが質問する

   例：「東京の天気を教えて」

2. LLMが関数呼び出しを提案

   モデルは「これは天気APIを使うべき」と判断し、ツール呼び出しのリクエストを返す。

3. 外部関数を実行

   アプリケーション側で実際に天気APIを叩いて結果を取得する。

4. 結果をLLMに渡す

   取得した天気データをLLMに渡し、ユーザーに自然な文章で回答を生成させる。

計算、検索、DBアクセス、API利用など「LLM単体ではできない処理」を組み込むことができ、外部サービスと組み合わせることで「答えるAI」から「行動できるAI」に進化させることができます。ただし、外部APIへの依存やセキュリティリスクが増すため、設計と管理には注意が必要です。

RAG

外部データベースや検索システムから情報を取得して、その情報をもとに生成する手法です。

学習済みの情報しか知らないLLMに、最新情報や専門的な知識を与えることができます。

RAGの仕組み

1. ユーザーから質問を受け取る

   例：「社内の勤怠規則を教えて」

2. 検索

   ベクトル検索や全文検索を使って、外部データベースやドキュメントから関連情報を取り出す。（例：全文検索で「勤怠」を含む部分を探す、またはベクトル検索で「勤務時間に関する規則」を意味的に検索する）

3. コンテキストに埋め込む

   取り出した情報をLLMの入力プロンプトに追加する。（例：

   以下の規則を参考に答えてください:
   
   第3条 勤怠管理
   1. 出勤・退勤時は必ずシステムに打刻すること。
   2. 遅刻・早退は上長に事前申請すること。
   
   

   ）

4. 生成

   LLMが外部情報を参照しながら、ユーザーに回答を生成する。

最新の情報や社内文書を参照でき、ハルシネーション（嘘）を減らせますが、検索精度に依存するため関連情報が取れないと正しい回答ができないなどのデメリットもあります。

まとめ

魔法のように見える生成AIも、その本質はシンプルな補完マシンです。仕組みを理解すればこそ、私たちは安心してAIを使いこなし、実務に活かせるようになります。