LLM（大規模言語モデル）とは
LLM（Large Language Model、大規模言語モデル）は、ChatGPT・Claude・Gemini などの中身に当たります。OpenAI の Why language models hallucinate や Anthropic の Building effective agents が前提にしている通り、LLM はトークンの並び方を確率で予測する装置です。これを誤解して「LLM は社内データを覚えている」と思い込むと、PoC のスコープを大きく外します。
LLM はトークン（単語より少し小さい単位）の次の並びを確率で予測することで文章を生成します。事前学習で大量テキストの「らしさ」を学習しているだけで、社内の最新情報や顧客固有データは持っていません。事実根拠は RAG・検索・ツール利用で別途渡す前提で設計します。
01.まず結論：LLMはトークン予測器
LLM が「すごい」と言われるのは、3 つの要素が同時に起きているからです: (1) パラメータが数十〜数千億に達した、(2) 事前学習のデータが膨大になった、(3) Transformer により長い文脈を扱えるようになった。この 3 つの結果として、汎用的な言語タスクが 1 つのモデルで実用水準に達しました。
ただし、LLM の中身が変わらない以上、限界も変わりません。学習時点までの知識しかない、確率予測なので確信が低くてももっともらしく答える、コンテキストウィンドウ（一度に読める長さ）を超えるとそこで打ち切られる、といった性質は今も同じです。
02.LLMの学習工程
大量のテキストで次のトークン予測を学習。汎用知識と言語能力を獲得
「指示と模範回答」のペアで応答スタイルを揃える
人間の好みや安全基準で出力を整え、評価ベンチで品質確認
プロンプト＋文脈を入力し、次のトークンを順に予測して回答を生成
導入判断では、左 3 つ（学習）はモデルベンダー側、一番右（推論）が自社の運用領域だと覚えると整理が楽です。
事前学習：次のトークンを予測する
事前学習は、ウェブ・書籍・コードなどから集めた大量のテキストを使い、「ある文脈の次にどのトークンが来やすいか」を学習する工程です。学習データのサイズは数兆トークン規模で、計算には GPU/TPU クラスタが数週間〜数ヶ月稼働します。社内データだけで事前学習することは現実的ではなく、汎用 LLM を出発点にするのが 2026 年現在の前提です。
指示チューニング：望ましい応答に揃える
事前学習だけだと「ウェブの続きをそのまま予測する」モデルになってしまい、人間の指示に従う動きにはなりません。そこで、人間が作った「指示と模範回答」のペアでさらに学習させ、応答スタイルを揃えます。これが指示チューニング（instruction tuning）です。Claude や ChatGPT の対話的な振る舞いはこの工程で作られます。
RLHF と評価：安全性と好ましさを学習
最後に、人間が複数の応答を比較して好ましい方を選ぶデータを使い、安全性や好ましさを反映させます。これが RLHF（Reinforcement Learning from Human Feedback）です。あわせて MMLU、HumanEval、SWE-bench などの評価ベンチで品質を測り、リリース可否を判断します。
2025 年以降は、chain-of-thought（中間推論）を学習過程に組み込んだ「推論モデル」（Claude 4 系、GPT-5、Gemini 2.5 など）が主流になりました。回答前に内部で推論ステップを踏む設計で、コードや数学のタスクで精度が大きく向上しています。
03.トークンと文字の関係
LLM は文字を直接扱わず、トークンと呼ばれる単位を扱います。トークンは単語や部分文字列で、日本語の場合は「1 文字＝1 トークン」とは限りません。ひらがな・カタカナ・漢字・記号で 1 トークンが含む文字数が変わります。
| 対象 | 目安 | 備考 |
|---|---|---|
| 英語 | 1 単語 ≒ 1〜2 トークン | ペース把握は単語数で十分 |
| 日本語 | 1 トークン ≒ 0.5〜1 文字（モデル依存） | 見積もりは「文字数 × 1.5〜2 = トークン数」が目安 |
| コード | 言語・記号で大きく変動 | JSON や YAML はトークン化のコストが高い |
同じ意味の文章でも、日本語は英語より多くのトークンになる傾向があります。API 料金やコンテキストウィンドウの見積もりを「文字数」で見積もると過小になりがちなので、運用上は「文字数 × 1.5〜2」で概算するのが安全です。OpenAI の tokenizer や Anthropic の token counter で実測することもおすすめです。
04.コンテキストウィンドウとは
コンテキストウィンドウは、LLM が「1 回の推論で読み込める長さ」のことです。プロンプト・添付ファイル・前のやり取り・ツール出力など、入力すべてがここに収まります。2026 年現在の主要モデルは 100k〜1M トークンまで対応し、書類数十ページ単位を一度に扱えます。
| モデル世代 | コンテキストウィンドウの目安 | BtoB での扱い |
|---|---|---|
| 2023 年前後（GPT-3.5） | 4k〜16k トークン | 短文 Q&A、要約程度。長文資料は分割必須（過去の話） |
| 2024 年（Claude 3 / GPT-4o） | 100k〜200k トークン | 中規模文書（10〜30 ページ）の一括処理 |
| 2025 年〜（Claude 4 系 / Gemini 2.5） | 200k〜1M トークン | 数十〜数百ページの資料を文脈に直接渡せる |
コンテキストウィンドウが広くなっても、入れた情報の真ん中あたりは精度が落ちる現象（ Lost in the Middle）が知られています。長文を全部入れれば良いとは限らず、業務で重要な情報は冒頭か末尾に置く、検索（RAG）で関連箇所だけ抽出して渡す、といった設計が必要です。
05.推論コストの読み方
BtoB で LLM を使うときに最初に効くのが推論コストです。料金はモデル提供各社で異なりますが、共通して「入力トークン × 単価 + 出力トークン × 単価」のシンプルな構造です。出力単価は入力単価より高く設定されているのが一般的で、出力を不必要に長くしないことが料金抑制の基本です。
| コスト要素 | 効くポイント | 削減の打ち手 |
|---|---|---|
| 入力トークン | プロンプト、添付資料、前ターン履歴 | プロンプト最適化、RAG で必要範囲だけ抽出 |
| 出力トークン | 回答の長さ・冗長さ | 出力フォーマット指定、最大トークン数の上限設定 |
| モデル選択 | Opus / Sonnet / Haiku（Claude 系）など | 難しいタスクだけ上位モデル、定型処理は小型モデル |
| キャッシュ | 繰り返し参照する文脈 | Prompt caching を有効化（対応モデル） |
BtoB の見積もりでは、(a) 1 回の処理あたりの平均トークン数、(b) 月間処理回数、(c) モデル単価、を表にして概算します。実測の前にざっくり 1 桁目を合わせるだけで、PoC スコープを現実的に切れます。
06.過去のLLMと現在のLLM
LLM は 2018 年以降の歴史でも進化が早く、「初期 LLM のイメージ」のまま設計してしまうと現在の最適解と合わなくなります。本章では、過去の LLM と現在の LLM の境目を時系列で示します。
オレンジで強調した行は、現在の LLM 像に直結する転換点（ChatGPT 公開・推論モデル登場・業務エージェント前提化）。
LLM ファミリーごとの詳しい年表は別記事で扱っています。
Claude・Claude Code 進化の年表
Claude シリーズの世代更新とコンテキストウィンドウ拡張の歴史。
ChatGPT・GPT モデル進化の年表
GPT-2 から GPT-5 までの LLM 大型化と能力変化。
OpenAI Codex 進化の年表
コード生成 LLM の進化と GPT 系列との関係。
BERT / GPT-2 / GPT-3：研究主体の時代
2018〜2022 年の LLM は、研究・開発者向けのモデルでした。BERT はファインチューニング前提、GPT-3 は API で個別開発者が試す段階で、業務で「AI に書かせる」発想が一般化していない時期です。コンテキストウィンドウも 2k〜4k トークンと小さく、「文書を丸ごと入れる」運用は現実的ではありませんでした。
この時期の LLM 設計（自前ファインチューニング、特化モデル開発）は、現在のスタイル（汎用 LLM＋プロンプト＋RAG＋エージェント）とは前提が異なります。古い書籍やブログ記事の LLM 設計を参考にする場合は、いつ書かれたかを必ず確認してください。
ChatGPT 以降：対話と業務利用の本格化
2022 年 11 月の ChatGPT 公開を境に、LLM は対話 UI で誰でも使えるツールになりました。2023 年に GPT-4、Claude、Gemini、Llama などが相次いで登場し、企業導入の検証が本格化します。コンテキストウィンドウも 100k〜200k トークンに広がり、議事録や仕様書を直接渡せるようになりました。
推論モデル・マルチモーダル・長文化（現在）
2025 年以降は、(1) 推論モデル化（Claude 4 系、GPT-5、Gemini 2.5 が chain-of-thought を学習に組み込み）、(2) マルチモーダル化（テキスト＋画像＋音声＋動画）、(3) 長文コンテキスト（1M トークン）、の 3 つが標準になりました。コードや業務調査のタスクで人間の専門家に近い水準が出始めており、AI エージェント設計の前提が変わっています。
BtoB で LLM を使うときは、この 3 つを前提に設計します。古いブログで「LLM は長文が苦手」「画像は扱えない」と書かれていても、2026 年 5 月時点ではほぼ過去の話です。
AIとは｜機械学習・深層学習・LLM・AIエージェントの階層を整理
LLM が AI のどの層に位置するかは別記事で詳しく整理しています。
AIエージェントとは｜AIアシスタント / ワークフロー / エージェントの定義と境界
LLM を使った業務エージェントの定義と境界は別記事で整理しています。あわせてご覧ください。
07.よくある質問（FAQ）
LLM は社内データを覚えていますか？
覚えていません。LLM は事前学習で公開テキストの「らしさ」を学習しているだけで、社内の最新情報や顧客個別データは持ちません。社内情報を扱うには RAG や検索ツール、Function Calling で都度文脈として渡す前提で設計します。
コンテキストウィンドウが広いほど性能は良くなりますか？
必ずしも良くなりません。窓が広くなっても、入れた情報の真ん中あたりは精度が落ちる現象（Lost in the Middle）が確認されています。重要情報は冒頭か末尾に置く、検索で関連箇所だけ抽出して渡す、といった設計が現実的です。
日本語のトークン数はどう見積もればよいですか？
概算では「文字数 × 1.5〜2」が目安です。Claude や GPT は日本語を英語よりトークン消費が大きいトークナイザで扱うため、文字数ベースで見積もるとコストもコンテキストも過小評価になりがちです。実測は各社の tokenizer や token counter ツールでも確認できます。
ファインチューニングはまだ必要ですか？
用途によります。文体・分類ルール・特化フォーマットを揃えたい場合はファインチューニングが有効ですが、社内文書の最新情報を答えさせたいだけならファインチューニングより RAG が運用しやすいです。詳細は「ファインチューニング・RAG・プロンプトの使い分け」の別記事で整理予定です。
LLM はどのくらいの頻度で進化していますか？
2024 年以降、Anthropic・OpenAI・Google・Meta などの主要各社は四半期〜半年単位で世代を更新しており、コンテキスト長やマルチモーダル能力もそれと並行で拡張されています。2026 年 5 月時点では、推論モデルとマルチモーダル、業務エージェント前提のモデル設計が主流です。
08.まとめ
LLM はトークンを予測する確率的な装置です。事前学習＋指示チューニング＋RLHF で作られ、推論時はプロンプトと文脈を入力に次のトークンを順に出力します。社内データの保管庫ではないので、最新情報や顧客固有データは RAG・検索・ツール利用で別途渡す前提で設計します。
BtoB の見積もりで効くのはトークンとコンテキストウィンドウです。日本語は英語よりトークン数が多くなりがちで、コンテキストウィンドウは広いほど良いとは限らない（Lost in the Middle）ことを押さえると、PoC の設計がブレません。2026 年現在の主流は、推論モデル・マルチモーダル・長文コンテキストが揃ったモデル群です。
LLM の社内活用設計を見直しませんか
AI 活用や AI エージェント導入のご相談、PoC、伴走支援をご検討の方は、お気軽にお問い合わせください。
