基礎知識

LLMの仕組みとは。大規模言語モデルの動作原理と実務での使い方

生成AIの中核にあるのがLLMです。仕組みを知ると、なぜ誤った答えを出すのか、どう使えばよいのかが理解できます。この記事では、原理から実務での扱い方までを整理します。

LLMとは何か

LLM（大規模言語モデル）は、膨大な文章を学習し、次に来る言葉を予測する仕組みです。

動作の原理は、意外なほど単純です。与えられた文章に続く言葉として、最も確からしいものを1語ずつ選んでいきます。これを繰り返すことで、文章が生成されます。

「意味を理解している」わけではなく、膨大な文章のパターンから、統計的にありそうな続きを出しているという説明が実態に近くなります。

この性質を知っておくと、限界の理由が分かります。事実と異なる内容を自信ありげに出すのは、正しさではなく確からしさで選んでいるためです。

扱う単位と文脈の長さ

LLMは文章を、トークンという単位に分けて扱います。単語よりやや細かい区切りで、日本語では1文字が1〜2トークンになることが多くあります。

この単位が費用に直結します。APIの料金は、入力と出力のトークン数で計算されます。長い文章を渡すほど費用が増えます。

コンテキストウィンドウは、一度に扱える長さの上限です。この範囲を超えた情報は考慮されません。

実務上の意味は2つあります。長い文書を扱う場合は分割が必要になること、そして会話が長くなると初めのほうの内容が失われることです。

自社データを使う3つの方法

LLMに自社の情報を扱わせる方法は、大きく3つあります。

• プロンプトに含める／指示と一緒に情報を渡す。最も簡単だが、量に限界がある
• RAG／必要な情報を検索して取り出し、それを渡して答えさせる。現在の主流
• ファインチューニング／モデル自体を追加学習させる。費用と手間が大きい

実務では2つ目のRAGが最も多く採用されます。社内文書を検索できる状態にしておき、質問に関連する部分だけを取り出して渡す方式です。

利点は、情報を更新しやすいことです。文書を差し替えれば、すぐ反映されます。学習し直す必要がありません。

3つ目が必要になるのは、文体や形式を固定したい場合など、限られた場面です。

誤った出力が起きる理由

事実と異なる内容を出す現象は、仕組みから生じます。

確からしい続きを選んでいるだけで、事実を確認していません。学習データに存在しない情報を問われると、それらしい形の答えを組み立てます。

減らす方法はいくつかあります。根拠となる情報を一緒に渡す（RAG）、分からない場合はそう答えるよう指示する、出力の形式を制限する、人が確認する工程を残す。

ただし、完全になくすことはできません。この前提で設計する必要があります。

影響が大きい用途ほど、人の確認を挟む設計が必要です。社内の下書き生成なら誤りは修正できますが、顧客への回答を自動送信する設計は危険です。

費用の考え方

LLMを組み込む場合の費用構造を整理します。

従量課金が基本です。処理した量に応じて費用が発生します。

入力と出力で単価が異なり、出力のほうが高いのが一般的です。長い回答を生成させるほど費用が増えます。

モデルによって単価が大きく違います。高性能なものほど高額です。用途に応じて使い分けることで、費用を抑えられます。

実務で注意すべきは、利用量の予測が難しいことです。想定より使われれば費用が膨らみます。上限の設定と監視が必要になります。

見積もりでは、運用費用を開発費用と分けて示すべきです。

モデルの選び方

複数の選択肢がある中で、判断の基準を整理します。

性能。複雑な推論が必要か、単純な分類で足りるか。用途に対して過剰な性能は費用の無駄になります。

データの扱い。入力した情報が学習に使われるかどうか。機密情報を扱う場合、契約条件の確認が必須です。

提供の場所。国外のサーバーを経由するか。社内規程や業界の規制に関わります。

継続性。モデルは更新され、古いものは提供が終了します。切り替えが発生する前提で設計しておく必要があります。

1つのモデルに固定しない設計が、実務上は安全です。

この領域で働くには

LLMを扱う仕事に必要なものを整理します。

プログラミングはPythonが中心です。ただし、モデルを自作する必要はほとんどありません。既存のモデルを呼び出し、周辺を作る仕事が大半です。

実際に求められるのは、検索の設計と評価の設計です。RAGでは、適切な情報を取り出せるかが精度を決めます。そして、出力が良いか悪いかを測る基準を作る必要があります。

業務理解も欠かせません。何を正解とするかは、業務を知らなければ定義できません。

この領域は変化が速く、半年前の常識が変わることもあります。学び続ける前提が必要です。

指示の書き方

同じモデルでも、指示の与え方で出力の質が変わります。実務的な要点を挙げます。

• 役割を与える／どの立場で答えるかを指定する
• 形式を指定する／箇条書き、表、文字数。曖昧だと毎回異なる形になる
• 例を示す／望ましい出力の例を1〜2件与えると、精度が上がる
• 手順を分ける／複雑な作業は段階に分けて指示する
• 制約を明示する／使ってよい情報の範囲、答えられない場合の対応

最後の項目が実務では重要です。「与えた資料に書かれていないことは答えない」と指示するだけで、事実と異なる出力が大きく減ります。

ただし、指示の工夫で解決できる範囲には限界があります。根本的にはデータの与え方の問題である場合が多くあります。

業務利用時の注意

企業で使う場合に確認すべき点を整理します。

入力が学習に使われるか。サービスや契約形態によって異なります。業務利用では、学習に使われない条件を選ぶのが原則です。

データの所在。処理がどの国のサーバーで行われるか。規制や社内規程に関わります。

入力してよい情報の範囲。顧客情報、未公開情報、個人情報。線引きを社内で決めておく必要があります。

出力の権利関係。生成された内容の扱い。既存の著作物に似た出力が生じる可能性もあります。

これらは技術ではなく運用の設計です。導入前に決めておかないと、使いながら問題が表面化します。