大規模言語モデル
だいきぼげんごもでる
膨大なテキストで訓練され、続きを予測することで文章の理解・生成を行う巨大なモデル。
概要
大規模言語モデル（LLM: Large Language Model）は、インターネット規模の膨大なテキストで訓練され、「与えられた文章の続きとして最も自然な次のトークン（語の断片）を予測する」ことを繰り返して文章を生成するモデルです。ChatGPTやClaudeの中身がこれで、構造としてはTransformerのデコーダを何百層も積み上げた巨大なニューラルネットワークです。
驚くべきは、この「次の1トークンを当てる」という単純な訓練目標だけから、翻訳・要約・プログラミング・推論といった多様な能力が生まれることです。文章の続きを高精度で予測するには、文法・事実知識・論理・文脈の意図を内部に取り込まざるを得ない — その副産物として、タスクごとの専用訓練なしに幅広い仕事をこなす汎用性が獲得されました。
エンジニアにとってLLMは「賢いチャット相手」であると同時に、API経由で呼び出してアプリケーションに組み込む部品でもあります。自然言語という曖昧な入力を扱えるコンポーネントが登場したことで、ソフトウェアの設計語彙そのものが拡張されつつあります。
なぜ生まれたか
かつての自然言語処理は、翻訳なら翻訳モデル、感情分析なら感情分析モデルと、タスクごとにラベル付きデータを集めて専用モデルを訓練するのが常識でした。ラベル付けは人手のかかる高価な作業で、データ量がモデルの性能の天井になっていました。一方、ラベルのない生のテキストならウェブ上に事実上無尽蔵にあります。「次のトークンを当てる」という訓練は、どんな文章もそのまま正解付き問題として使える — 人手のラベル付けが不要な自己教師あり学習であることが、規模の壁を破る鍵になりました。
これを実用にしたのがTransformerの並列学習可能な構造とGPUクラスタの計算力です。2020年のGPT-3は、モデルを大きくしデータを増やすほど性能が伸び続けるというスケール則を実証し、さらに「例をいくつか見せるだけで未知のタスクをこなす」文脈内学習という予想外の能力を示しました。個別タスクの専用モデルを作る時代から、一つの巨大な汎用モデルを皆で使う時代への転換点です。
詳細
訓練の三段階 — 予測機をアシスタントに仕立てる
LLMの構築は大きく三段階に分かれます。第一段階の事前学習（pre-training）では、数兆トークン規模のテキストで「次のトークン予測」をひたすら学習します。これは機械学習としては桁外れの規模で、数か月と莫大な計算費用がかかります。この時点のモデル（ベースモデル）は博識ですが、質問に答えるのではなく「続きを書く」だけの存在です。
第二段階の指示チューニング（instruction tuning）では、「指示と模範回答」のペアを使ったファインチューニングで、指示に従って応答する振る舞いを教え込みます。第三段階のRLHF（人間のフィードバックによる強化学習）では、モデルの複数の回答に人間が優劣を付け、その好みを報酬としてモデルを調整します。有害な出力を避け、丁寧で役立つ応答を返す「アシスタントらしさ」は、主にこの段階で作られます。事前学習が知識と能力を、後の二段階が振る舞いを決める、と整理できます。
コンテキストウィンドウ — モデルの作業記憶
LLMには、一度に処理できるトークン数の上限「コンテキストウィンドウ」があります。モデルは訓練後に重みが固定されており、会話を通じて何かを記憶することはありません。チャットで文脈が通じているように見えるのは、毎回それまでの会話全体を入力として渡し直しているからです。ウィンドウを超えた分は単純に見えなくなるため、長い文書の扱いには要約や分割が必要になります。外部の知識をコンテキストに動的に注入するRAGや、意味の近さで関連文書を探す埋め込みとベクトルDBの組み合わせは、この制約を補うための定番構成です。
ハルシネーション — 本質に根ざした限界
LLMは事実と異なる内容を、もっともらしい文体で自信満々に生成することがあります。これをハルシネーション（幻覚）と呼びます。重要なのは、これがバグではなく仕組みの帰結であることです。モデルは「真実を述べる」よう訓練されたのではなく「もっともらしい続きを生成する」よう訓練されており、知識にない問いに対しても統計的に自然な文章を組み立ててしまいます。存在しない論文の引用や実在しないAPIの関数名は典型例です。RAGによる根拠の注入、出典の要求、人間による検証工程など、ハルシネーションを前提とした設計がLLM活用の基本姿勢になります。
API経由で使う — チャット補完の往復
アプリケーションからは、通常プロバイダのAPIをチャット補完（chat completion）形式で呼び出します。system（アプリ側が設定する役割・制約）、user（ユーザーの発言）、assistant（モデルの過去の応答）という役割付きメッセージの配列をJSONで送り、続きとなる応答を受け取る形式です。前述のとおりサーバ側は状態を持たないため、会話の継続にはメッセージ履歴を毎回すべて送り直します。
料金は入出力のトークン数に対する従量課金が一般的で、履歴を送り直す構造上、会話が長くなるほど1往復あたりのコストは増えます。生成が完了するまで待たずに1トークンずつ受け取るストリーミングは、体感速度を大きく左右する実務上の定番です。また、どんな指示を与えるかで出力の質が大きく変わるため、プロンプトエンジニアリングがLLMを部品として使いこなすための隣接スキルになります。モデル自身に外部ツールの呼び出しを計画させるツール使用（function calling）やエージェントへと、活用の形は急速に広がり続けています。