Skip to Content
Docs10. LLM 基礎LLM はどうやってテキストを生成するか
初級llm-foundationsstreamingstructured-output更新: 2026-10-04この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

LLM はどうやってテキストを生成するか

この記事の目的

LLM の出力が「次の 1 トークンの予測を繰り返した積み上げ」であることを理解し、温度(temperature)などの推論パラメータを設計判断として扱えるようになります。あわせて、実務で毎日直面する性質 — 出力が毎回揺れる・ストリーミングLLM の応答を生成と同時に逐次受信・表示する方式。Agent の体感品質を左右する基本技術。できる・出力が長いほど遅く高い — がすべてこの 1 つの仕組みから導けることを掴みます。

対象読者

  • LLM API は使えるが、パラメータを「おまじない」のまま使っているエンジニア
  • 非決定性・出力切断など LLM 特有の挙動を、仕組みから説明できるようになりたい人

前提知識

  • LLM API(チャット補完 API)を呼び出した経験(このライブラリ共通の前提)
  • ライブラリ内の前提ドキュメントはありません — 本記事が 10 章(LLM 基礎)の最初の 1 本です

本文

概要: たった 1 つのループ

本記事が扱う自己回帰型 LLM の基本動作は、「これまでのトークンを条件に次の 1 トークンの確率分布を計算し、そこから 1 つ選んで末尾に足す」を、停止条件まで繰り返すことです。これを自己回帰生成(autoregressive generation)と呼びます。実装ではキャッシュや投機的デコーディング下書きモデルの複数トークンを本命モデルでまとめて検証する推論高速化。貪欲法では一致する接頭辞を採用し、確率的生成では受理確率と棄却時の補正分布を用いる。これらを正しく実装し、同じ生成条件を適用する方式では本命の分布を保てる。速度改善は下書きの受理率と検証費用に依存する。を使う場合もあります。トークン(token)はモデルが扱うテキストの単位です(詳細はトークナイザとトークン経済)。

LLM はどうやってテキストを生成するか: 概要: たった 1 つのループの図LLM はどうやってテキストを生成するか: 概要: たった 1 つのループの図
LLM はどうやってテキストを生成するか: 概要: たった 1 つのループの図
図を元の大きさで表示

図の中をスクロールして読めます。キーボードでは図の領域へ Tab で移動し、矢印キーを使います。読み終わったら、この見出しをもう一度選ぶと閉じます。

LLM はどうやってテキストを生成するか: 概要: たった 1 つのループの図LLM はどうやってテキストを生成するか: 概要: たった 1 つのループの図

長い推論も、コードも、丁寧な謝罪文も、モデルにとってはすべて「次の 1 トークン」の連続です。この単純さを知っていることが、以降のすべての実務判断の土台になります。

次トークン予測という実体

モデル本体は、状態を持たない関数です — 「ここまでのトークン列」を受け取り、「語彙中の各トークンが次に来る確率」を返します。知識も推論らしき振る舞いも、この形式の中に押し込まれています。ここから 2 つの実務的な帰結が出ます。

  • 自分の出力が、以降の生成の入力になる: 生成の途中経過は文脈として確定し、モデルはそれを「取り消せません」。序盤で方向を誤ると後半も引きずられます。逆に、結論の前に考察を書かせると精度が変わるのは、書いた考察が次トークンの予測条件に加わるからです(プランニングと推論)
  • 「途中でやめて考え直す」は起きない: 見かけ上の自己修正(「すみません、訂正します」)も、確定済みの文脈の上に続きを生成しているだけです。やり直しをさせたければ、呼び出し側が文脈を作り直す必要があります

サンプリングと温度

確率分布から次の 1 トークンを「選ぶ」方法がサンプリングで、ここに主要な推論パラメータが集まっています。

方法・パラメータ意味実務での使いどころ
貪欲法(最大確率を常に選ぶ)揺らぎ最小。反復・単調に陥ることがある温度 0 指定が近い挙動
温度(temperature)分布の尖り具合。低いほど高確率トークンに集中、高いほど平坦化設定を受け付けるモデルでは分類・抽出は低め、多様性は中〜高を評価候補にする
top-p(累積確率での足切り)確率上位から累積が指定値に達する候補集合を作り、そこからサンプリング候補の裾を切る調整。安全性や正確性を保証する設定ではない

温度設定を受け付けるモデルでは、後続をコードで処理する分類・抽出は低温度、多様性に価値がある出力は高めを評価候補にします。一部の最新モデルは temperature / top_p / top_k の非既定値を 400 エラーで拒否します。低温度の推奨は採用モデルの仕様を確認してから適用し、非対応モデルでは設定を省略してプロンプト・構造化出力LLM の出力を JSON Schema などの機械可読なスキーマに従わせる技術。後続の処理がコードである出力(分類・抽出・スコア)に使う。と評価で扱います。

「同じ入力で違う出力」になる理由

LLM の非決定性には 2 つの層があります。

  1. サンプリングの確率性: 温度が 0 より大きければ、同じ分布からでも選ばれるトークンは毎回変わりえます。これは意図された挙動です
  2. 実装レベルの揺らぎ: 温度を 0 にしても、並列計算の丸め誤差やサービス側の実装要因により、完全に同一の出力は一般に保証されません。確率が拮抗した 2 つのトークンは、ごくわずかな計算差で入れ替わり、その 1 トークンの違いが以降の生成を分岐させます

「1 回通ったテスト」だけでは品質を保証できません。 評価を複数ケース・複数回で設計します(Agent 評価の基礎)。自由文の回帰テストプロンプト・ツール・モデルの変更で既存の品質が壊れていないかを、評価データセットの再実行と前回比較で検知するテスト。では意味や要件への適合も評価します。一方、分類ラベル・集計値・必須のツール引数は完全一致を成功条件にでき、その成功率を複数回の実行で測ります(回帰テストと CI 組み込み)。

停止とストリーミング

生成の停止には、例えば次の種類があります。API ではツール要求・拒否・継続可能な停止なども別に表現されるため、採用先の停止理由に対応づけます。

  • 自然停止: モデルが「応答の終わり」を意味するトークンを選ぶ
  • 停止シーケンス: 開発者が指定した文字列が現れたら打ち切る
  • 上限打ち切り: 最大出力トークン数(max_tokens)に達して強制終了する

上限で打ち切られると、JSON の構文が壊れたり、構文は有効でも必要な結果が欠けたりします。停止理由(finish reason)と出力の検証をせず後続へ流すと、不完全な結果を成功扱いしかねません(構造化出力、Agent ループ)。

また、1 トークンずつ順に確定していく仕組みだからこそ、生成と同時に配信するストリーミングが自然に成立します(ストリーミングと Agent の UX 実装パターン)。生成時間とコストは出力トークン数にほぼ比例するため、「出力を短く設計する」ことがレイテンシとコストの双方に効く最適化になります(レイテンシ最適化、コスト管理)。

この理解が効く場面

  • 構造化出力: スキーマ強制は「その位置で選べるトークンを制約する」仕組みで実現されるのが主流です。だから形式は保証できても、内容の正しさは保証されません(構造化出力)
  • 評価設計: 非決定性が仕様だと分かっていれば、単発の成否ではなく分布(合格率・ばらつき)で品質を測る設計になります(Agent 評価の基礎)
  • レイテンシ・コスト: 出力長比例の構造を知っていれば、「不要な説明を書かせない」「要約を返させる」といった出力側の設計が最初の最適化になります
  • パラメータの設計: 温度・top-p を「試して良かった値」ではなく「タスクの性質から選んだ値」として文書化できます

実務での注意点

アンチパターン

  • 自由文の表現まで温度 0 で固定されると期待する → 意味が同じ言い換えでも回帰失敗になる → 自由文は意味や要件で評価し、分類ラベル等の一致が必要な出力とは基準を分ける
  • 1 回のデモ成功で品質を判断する → サンプリングの揺らぎで次の実行は失敗しうる → 複数ケース・複数回の評価で分布を見る
  • 停止理由を確認せず出力を後続処理に流す → 上限打ち切りの壊れた JSON・尻切れ応答が静かに下流を壊す → finish reason のチェックをコードに入れる
  • 分類・抽出タスクを高めの温度のまま運用する → 同じ入力への判定が揺れて信頼を失う → 設定可能なモデルでは低温度を評価し、非対応モデルでは設定を省略して複数回評価する

チェックリスト

  • 応答の停止理由(自然停止/打ち切り)をコードで確認している
  • 採用モデルが温度・サンプリング設定を受け付けるか確認し、対応する設定だけを記録している
  • 非決定性を前提にした評価(複数ケース・複数回・合格率)がある
  • 出力トークン数がレイテンシ・コスト要件に収まるよう出力側を設計した

関連トピック

参考資料

TODO・未確認事項

なし

セクション概要トークナイザとトークン経済