LLMの実際の仕組み

大規模言語モデル（LLM）は、シーケンス内の次のトークンを予測するように訓練されたニューラルネットワークである。テキストを数値ベクトルに変換し、アテンション機構を使って各トークンが他のトークンからコンテキストを収集できるようにし、語彙全体の確率分布からサンプリングすることで1トークンずつ出力を生成する。「トークンを予測し、それを追加し、次を予測する」というこの単一のメカニズムこそが、ChatGPT、GitHub Copilot、Claude、Geminiを動かすエンジンの全体像だ。それ以外の要素は、スケール、訓練手順、そしてその上に積み重ねられたエンジニアリングに過ぎない。

これらのツールを日常的に使いながらも内部の仕組みを覗いたことがない方にとって、「自信満々な誤答」「会話の冒頭を『忘れる』チャット」「少し言い換えただけで大きく変わる出力」「“strawberry”の文字数を数えられない」といった挙動は、単なる気まぐれではない。これらはすべて、モデルのメカニズムから直接生じる現象だ。本記事では、そのメカニズムの正確なメンタルモデルを提供する。具体的には、トークンとエンベディング、トランスフォーマーのアテンション層とフィードフォワード層、3段階の訓練フェーズ、テキスト生成の実際のサンプリング方法、そしてタイトルの「実際の」という言葉が正そうとしている誤解について解説する。

LLMの本質：次トークン予測

大規模言語モデルは、その核心において、「トークンのシーケンスが与えられたとき、次に来るトークンは何か？」という1つの問題を繰り返し解いている。これを語彙全体（数万通りのトークン候補）にわたる分類問題として定式化し、それぞれの確率を出力する。モデルは1つを選んでシーケンスに追加し、全体を再び実行する。テキスト生成とは、停止条件が満たされるまでこのループを回すことに他ならない。

この捉え直しこそが重要な洞察だ。「コールバックをデバウンスする関数を書いて」というのは、モデルが答えを検索するコマンドではない。モデルがトークンごとに続きを生成するプロンプトだ。なぜなら、訓練データの中で、そのようなプロンプトに似たシーケンスの後には、動作するコードに似たシーケンスが続いていたからだ。モデルは、入力を受け取って続きを生成するエンジンなのだ。

これを大規模に機能させたアーキテクチャがトランスフォーマーだ。Vaswaniらによる2017年の論文Attention Is All You Needで発表された。ChatGPTの「GPT」はGenerative Pre-trained Transformerの略だ。トランスフォーマー以前のモデルはテキストをほぼ左から右に処理しており、文中で離れた単語同士を結びつけることが苦手だった。アテンション機構により、モデルはすべてのトークンを他のすべてのトークンと並列に照合できるようになり、これが品質と訓練速度の両方を飛躍的に向上させた。

トークンとエンベディング：テキストが数値になるまで

モデルがプロンプトを処理する前に、テキストをトークンに分割する。これは単語でも文字でもなく、サブワードの塊だ。各トークンは数値にマッピングされる。トークンは完全な単語（" the"）、単語の断片（"ing"）、1文字、または句読点になりうる。このトークン化のステップはチャットUIでは見えないが、失敗のパターン全体を説明するものだ。

モデルは個々の文字ではなくサブワードトークンを読み取るため、単語の文字数を数えるよう求めることは、テキストの表現方法に逆らうことになる。これが、文字数カウントやスペルタスクが、モデルの全般的な流暢さから予想されるよりも頻繁に失敗する理由だ。モデルは”strawberry”の3つの”r”を「見る」ことはない。見えるのは、トークンの塊を表すいくつかの不透明な整数IDだけで、文字の情報はそこに埋め込まれてしまっている。

OpenAIのオープンソースtiktokenトークナイザーを使うと、この動作を実際に確認できる：

# pip install tiktoken
import tiktoken

enc = tiktoken.get_encoding("cl100k_base")
ids = enc.encode("strawberry")
print(ids)                       # a short list of integer token IDs
print([enc.decode([i]) for i in ids])  # the sub-word chunks, not letters

実行すると、いくつかの整数IDが得られ、それぞれが複数文字の塊にデコードされる。10個の個別の文字ではない。モデルはそれらのIDを処理する。文字を数えるには、トークン化の過程で失われた情報が必要になるため、モデルは近似的に処理し、頻繁に誤った結果を返す。

各トークンIDは次にエンベディングにマッピングされる。エンベディングとは、高次元の「単語空間」にトークンを配置する長い数値のリスト（ベクトル）だ。その空間では、類似した単語がクラスターを形成する。catはdog、kitten、petの近くに位置し、その幾何学的構造が意味をエンコードする。古典的なデモンストレーションはword2vec（Mikolovら、2013年）から来ており、ベクトル演算が関係性を捉えることを示した。おおよそbiggest − big + small ≈ smallest、Paris − France + Italy ≈ Romeが成り立つ。同じベクトルは訓練テキストに含まれる人間のバイアスも引き継ぐ。これがdoctor − man + womanがnurseに近づきうる理由だ。エンベディングは手作業で構築されるのではなく、訓練中に学習される。

トランスフォーマーの内部：アテンション層とフィードフォワード層

トランスフォーマーは同一の層を積み重ねた構造で、各層は2つの処理を順番に行う。アテンションステップでは、トークンが他のトークンからコンテキストを収集し、フィードフォワードステップでは、モデルが重みに蓄積された知識を各トークンに個別に適用する。最先端のモデルはこれらの層を数十層積み重ね、各層でトークンの表現を少しずつ精緻化していく。初期の層は文法や曖昧さといったローカルな構造を処理し、後の層は「誰が誰に何をしたか」「その文章は何について書かれているか」といった高次の意味を追跡する。

アテンションはマッチングサービスのように機能する。 各トークンに対して、モデルはクエリベクトル（「私は何を探しているか？」）とキーベクトル（「私は何を提供できるか？」）を生成する。すべてのクエリをすべてのキーと照合し、一致する箇所でトークン間の情報が流れる。「When John gave the book to Mary, she thanked him」という文では、アテンションが「she」と「Mary」、「him」と「John」を結びつけるメカニズムであり、後の層がそれを利用できるようにする。1つの層では、ヘッドと呼ばれる複数のアテンション操作が並列に実行され、それぞれが異なる種類の関係を追跡するよう学習する。

フィードフォワードステップは、学習された事実が存在する場所だ。アテンションが関連するコンテキストを収集した後、フィードフォワードネットワークは各トークンを個別に処理し、訓練中に吸収したパターンに基づいてそれを変換する。役割分担は明確だ。アテンションは目の前のプロンプトから情報を取得し、フィードフォワード層は訓練コーパスから学習した情報を提供する。モデルが「The capital of Poland is」の続きに「Warsaw」を生成するとき、その事実はフィードフォワードの重みから来ており、プロンプトの内容からではない。

アテンションの背後にある線形代数と正確な数式については、オリジナルのトランスフォーマー論文が一次資料だ。「照合し、コンテキストを収集し、蓄積された知識を適用する、これを多くの層にわたって繰り返す」というメンタルモデルだけで、挙動について十分に推論できる。

LLMの訓練方法：事前訓練、ファインチューニング、RLHF

訓練は3段階で行われる。通常のテキストの次の単語がそれ自体のラベルになる自己教師あり事前訓練、人間が書いたプロンプトと応答のペアによる指示ファインチューニング、そして人間のフィードバックによる強化学習（RLHF）だ。各段階で異なる種類のモデルが生まれる。

事前訓練は自己教師ありだ。正しい次の単語がすでにテキストの中に存在するため、訓練シグナルは無料で事実上無制限に得られる。インターネット上のすべての文がラベル付きの例になる。モデルはランダムな重みから始まり、最初は予測が非常に悪く、数千億の例を通じて予測誤差を減らすように重みを調整することで改善していく（この調整の数学的仕組みは誤差逆伝播法であり、他の資料で詳しく解説されている）。2020年のスケーリング則の論文（Kaplanら）は、モデルの精度がモデルサイズ、訓練データ量、計算量に対してべき乗則で向上することを発見した。これが、ますます大きなモデルを構築することを正当化した経験的な結果だ。

純粋に事前訓練されたモデルは単なる補完器に過ぎない。「あなたの名前は何ですか？」と聞くと、「あなたの苗字は何ですか？」と続けるかもしれない。それが不親切だからではなく、そのような続きが確率的に自然だからだ。指示ファインチューニングとRLHFがこれを修正する。生のモデルをアシスタントに変えるパイプラインはInstructGPTの論文（Ouyang ら、2022年）で示された。これは2022年11月30日に公開研究プレビューとしてリリースされたChatGPTの直接の基盤となった研究だ。現在のほとんどのチャットモデルはこのパイプラインの何らかの変種で訓練されているが、正確なレシピは非公開だ。

数値について2点補足する。よく引用されるGPT-3の数値、つまり1,750億パラメータ、96層、12,288次元のエンベディング、50,257トークンの語彙は、2020年のGPT-3論文に由来し、現在の仕様ではなく具体的な例として有用だ。最先端のラボは最新モデルのパラメータ数を公表しなくなっている。現行のGPT-5シリーズ、Claude Opus/Sonnet/Haiku、Gemini 3.xラインには公式のパラメータ数は存在しない。現在のモデルについての「X兆パラメータ」という主張は噂として扱うべきだ。

生成の仕組み：サンプリング、温度、そして出力が確率論的な理由

LLMがテキストを生成する際、予測ループを1トークンずつ実行し、計算した確率分布から次のトークンをサンプリングする。単純に「答え」を出力するわけではない。以下がそのループの擬似コードだ：

tokens = tokenize(prompt)
while not done:
    logits = model.forward(tokens)        # one score per vocabulary token
    probs  = softmax(logits / temperature) # convert scores to probabilities
    next_token = sample(probs)             # pick one, weighted by probability
    tokens.append(next_token)
    if next_token == END_OF_TEXT:
        break
output = detokenize(tokens)

temperatureパラメータは、スコアがどのように確率に変換されるかを制御する。デフォルトでは、LLMは決定論的ではなく確率論的だ。温度がゼロより高い場合、モデルは最も確率の高いトークンを常に選ぶのではなく分布からサンプリングするため、同じプロンプトでも異なる回答が返ってくる可能性がある。温度が0の場合、モデルは貪欲になり、常に上位のトークンを選ぶ。これはほぼ決定論的であり、コードや情報抽出に適している。温度が高いほど分布が平坦になり、確率の低いトークンが選ばれやすくなり、出力がより多様になる。temperatureパラメータはOpenAI APIリファレンスとAnthropic Messages APIリファレンスに記載されており、どちらもリクエストごとに設定できる。

これが、ChatGPTで同じプロンプトを再実行すると毎回異なる回答が返ってくる理由であり、APIで再現可能な出力が必要な場合に「温度を0に設定する」ことが標準的なアドバイスとなっている理由だ。

LLMに関するよくある誤解

LLMの動作に関する直感的な思い込みの中には、誤っているものがある。それぞれの誤った思い込みは、開発者がツールを誤用したり、失敗を誤読したりすることにつながる。本記事のタイトルにある「実際の」という言葉は、それらを正すためにある。

データベース検索ではない。 LLMは答えをデータベースで検索しない。検索すべき事実のテーブルは存在しない。毎ステップで語彙全体に対する確率分布を新たに計算し、1トークンを選んでそれを繰り返す。パラメータを「知識ベース」と捉えることは誤解を招く。重みがエンコードするのは統計的な規則性であり、インデックス化されたレコードではない。

事前に答えを知っているわけではない。 モデルは書く前に答えを知らない。各トークンはそれ以前のすべてのトークンに基づいて選ばれるため、読み手が目にする「推論」は全体として検索されるのではなく、左から右へと生成される。これが、モデルが自信満々な文を書き始めながら行き詰まってしまう理由だ。読み上げられる計画があるのではなく、計算された続きがあるだけだ。

LLMがそのように振る舞う理由

このメカニズムを理解すれば、これらのツールの日常的な挙動は謎ではなくなる。それぞれが、学習された確率に基づく次トークン予測の直接的な結果だ。

ハルシネーション。 ハルシネーションはシステムに後付けされたバグではなく、統計的にもっともらしいテキストを生成するよう最適化されたモデルのデフォルト挙動だ。モデルは「正しいこと」ではなく「正しく聞こえること」に対して報酬を受ける。ある事実について強いシグナルがない場合でも、訓練データでは自信に満ちたテキストが支配的であるため、モデルは自信に満ちたトーンで最もそれらしい続きを生成する。存在しない関数名や架空の引用は、モデルが訓練されたとおりのことをしている結果だ。

コンテキストウィンドウ。 コンテキストウィンドウは、モデルが一度にアテンションを向けられる固定数のトークンだ。その制限を超えたものはモデルからは見えなくなる。これが、長い会話でモデルが最初の内容を「忘れる」理由だ。2026年6月時点では、最先端のモデルはおよそ100万トークンのウィンドウに収束している。Gemini 3.5 Flashは1,048,576入力トークンを処理し、Claude Opus 4.8はデフォルトで100万トークンのウィンドウを備え、GPT-5シリーズはAPI経由で100万トークンのウィンドウを提供する。大きいが、それでも固定だ。会話やコードベースがそれを超えると、最も古いトークンはモデルが見られる範囲の外に落ちてしまう。

プロンプトの感度、Chain-of-Thought、Few-Shot。 プロンプトの正確な言い回しが確率分布を変化させ、したがって答えも変わる。出力はそれ以前のトークンからトークンごとに計算されるからだ。同じ特性が、プロンプトのテクニックが機能する理由でもある。Few-Shotプロンプティング（解いた例を示す）は、続けてほしいパターンでコンテキストを初期化する。Chain-of-Thoughtプロンプティング（「ステップバイステップで考えて」）が機能するのは、モデルが生成したテキスト自体が次に読む入力の一部になるからだ。中間ステップが、最終的な答えを一度のジャンプで出力させるのではなく、モデルが積み上げられるワーキングメモリとして機能する。

グラウンディングとRAG。 検索拡張生成（RAG）は関連ドキュメントをプロンプトに直接配置することで、モデルが損失の多いフィードフォワードの重みからではなく、目の前のテキストへのアテンションから事実を取得できるようにする。これが、ウェブ検索やドキュメントをコンテキストに持つモデルが具体的な情報についてより正確な理由だ。「訓練から思い出す」という負担を「プロンプトから読み取る」に移行しており、アーキテクチャはこちらをはるかに確実に行える。

「確率論的なオウム」という問い

次トークン予測が真の理解に相当するのか、それとも洗練された模倣に過ぎないのかは、未解決の論争中の問いだ。懐疑的な見方は2021年の論文On the Dangers of Stochastic Parrots（Bender、Gebruら）で明確に示された。この論文は、意味に根ざすことなく統計的な確率で訓練テキストを組み合わせるモデルは、知性よりもオウムに近いと主張した。対立する見方は、テキストを十分に予測するには、それが描写する世界の圧縮された使用可能なモデルが必要だというものだ。本記事で説明したメカニズムは確立されているが、この解釈は未解決であり、ツールをうまく使うためにこれを解決する必要はない。

必要なのはメカニズムのモデルだ。トークンが入力され、アテンション層とフィードフォワード層が多くのトランスフォーマー層にわたってそれらを精緻化し、1トークンずつ確率分布が出力される。このイメージを持っておけば、次にCopilotが存在しないメソッドを作り出したり、ChatGPTが会話の3ターン目で矛盾したりしたとき、機械のどの部分がそれを生み出したかが正確にわかる。そして同様に重要なことに、どのプロンプトの変更や検索ステップがそれを修正するかもわかるだろう。

よくある質問

LLMにおけるトークンと単語の違いは何ですか？

トークンはサブワードの塊であり、単語ではありません。トークナイザーはテキストを、完全な単語、'ing'のような単語の断片、1文字、または句読点になりうる断片に分割し、それぞれを整数IDにマッピングします。一般的な単語は1トークンになる場合がありますが、珍しい単語は複数に分割されることがあります。モデルは常にこれらのトークンIDを処理し、生の単語や文字を処理することはありません。これが、文字数カウントのような文字レベルのタスクが、テキストの表現方法に逆らうことになる理由です。

コンテキストウィンドウを大きくするとLLMの精度は向上しますか？

直接的には向上しません。コンテキストウィンドウを大きくすることで、モデルが一度により多くのトークンにアテンションを向けられるようになるだけで、推論や記憶の能力が向上するわけではありません。関連情報が必要な箇所から遠くにある場合は品質が低下することがあり、無関係なテキストをプロンプトに多く含めるとシグナルが希薄になる可能性があります。利点は、より少ない初期トークンがウィンドウの外に落ちることで、長い会話やドキュメントの「忘れ」が減ることです。

温度を0に設定すると、LLMは常に同一の出力を返しますか？

温度0にすると生成が貪欲になり、常に最も確率の高いトークンを選択するため、特定のモデルとプロンプトに対してほぼ決定論的になります。実際には、並列ハードウェアにおける浮動小数点演算の非決定性、モデルのバージョン変更、プロバイダー側のルーティングなどの要因により、APIコール間での完全な再現性は常に保証されるわけではありません。コードや情報抽出で一貫した出力が必要な場合は温度0が適切な設定ですが、厳密な保証ではなくほぼ決定論的なものとして扱うべきです。

検索拡張生成（RAG）はなぜハルシネーションを減らすのですか？

RAGは関連ドキュメントをプロンプトに直接配置することで、モデルが損失の多いフィードフォワードの重みからではなく、目の前のテキストへのアテンションから事実を取得できるようにします。アーキテクチャは訓練中に学習した拡散したパターンを想起するよりも、プロンプトから情報を取得する方がはるかに確実に行えます。これにより、タスクが「この事実を思い出す」から「この事実を読む」に移行します。これが、ドキュメントやウェブ検索結果をコンテキストに持つモデルが具体的な情報についてより正確に答えられる理由です。ただし、与えられた情報を誤読したり誤用したりする可能性は依然として残ります。