# LLMとは — AI Agentを支える大規模言語モデルの役割と限界

> LLMの基本構造、TokenとContext、生成AIやAI Agentとの違い、Webシステムへ組み込む際の運用判断を整理します。

Canonical URL: https://labs.eastbraver.com/guides/llm
Published: 2026-07-01
Updated: 2026-07-24
Category: field-guide
Tags: llm-inference, software-engineering, frontier-model

LLMはLarge Language Modelの略です。大量のデータから言語のパターンを学び、与えられた入力に続くTokenを予測しながら、文章やコードを生成します。

チャット画面を見ていると、画面も検索も会話履歴も、すべてLLMが動かしているように感じるかもしれません。[生成AI](/guides/generative-ai)の中でも、LLMが担当するのは主に言語とコードを扱うモデル部分です。

実際には、検索・Tool・権限・ログ・UIはモデルの外側にあります。LLMは中心に置かれることが多い。ただし、**LLMと、それを使ったシステム全体は別のもの**です。ここは最初に分けておきたいところです。

## LLMが繰り返しているのは、次のTokenの予測

[Transformerを提案した論文](https://arxiv.org/abs/1706.03762)は、Attentionを中心に系列を扱う構成を示しました。現在のLLMには異なる構成や学習手法もありますが、Transformerは多くの言語モデルを理解する起点になります。

LLMへ渡した文章は、そのまま文字列として処理されるのではなく、Tokenという単位へ分割されます。モデルは入力Tokenと、それまでに生成したTokenをもとに、次に続くTokenの確率分布を計算します。これを繰り返して応答を作ります。

### LLMの逐次Token生成

InputまたはPromptはTokenizeされ、Language Modelが次のTokenの確率分布を計算します。選択したTokenをContextへ加えて処理を反復し、終了条件を満たした時点でOutputを返します。

- InputまたはPromptをTokenへ分割します。
- Language Modelが次Tokenの確率を計算し、1つを選択します。
- 続行する間は選択Tokenを加えてModel計算へ戻ります。
- 終了条件を満たしたら生成済みTokenをOutputとして返します。

*Tokenizeから次Token選択を反復してOutputへ至る流れ*

この仕組みでは、もっともらしい文章を生成できることと、その内容が事実であることは同じではありません。

LLMはデータベースのように正解を検索して返しているわけではなく、入力に続く出力を生成しています。自然に読める回答ほど、その違いを忘れやすい気がしています。

## 似た用語を分けると、LLMの担当範囲が見えてくる

| 用語 | 主な意味 | LLMとの関係 |
| --- | --- | --- |
| Language Model | 言語の系列を扱うモデル | LLMを含む広い分類 |
| LLM | 大規模な学習とパラメータを持つ言語モデル | 文章・コード生成の中心 |
| Foundation Model | 幅広い用途へ適応できる基盤モデル | LLM以外の形式も含む |
| Generative AI | 文章・画像・音声などを生成する仕組み | LLMを利用する場合がある |
| AI Agent | 目標に応じて判断と実行を進めるシステム | LLMを判断部分に利用する場合が多い |

[Foundation Modelsの報告](https://arxiv.org/abs/2108.07258)では、広いデータで学習され、多様な下流用途へ適応するモデルを基盤モデルとして整理しています。LLMと基盤モデルは重なる部分が大きいものの、完全な同義語ではありません。

[GPT-3の論文](https://arxiv.org/abs/2005.14165)は、追加の勾配更新を行わず、Instructionや少数の例を入力へ含めることで複数のタスクへ適応する性質を示しました。現在のチャット型LLMでも、PromptとContextを使ってモデルの振る舞いを変える考え方につながっています。

[AI Agent](/guides/ai-agent)は、LLMの出力だけでは完結しません。モデルが次の処理を選び、[Tool](/guides/tool)を呼び、結果を受け取って続行や停止を判断する。そこまで含めて実行ループです。

## Webエンジニアはモデルの前後まで設計する

Webアプリケーションから[LLM API](/guides/llm-api)を一度呼ぶだけなら、実装はそれほど難しくありません。本番へ入れるとなると、モデル名と[Prompt](/guides/prompt-and-instruction)だけでは決めきれないことが増えます。

- どのデータをContextへ含めるか
- 入力と出力をどこまで保存するか
- 個人情報や秘密情報を送信してよいか
- 最大Token数と利用料金をどう制限するか
- Timeout、Rate limit、再試行をどう扱うか
- 期待する形式で返らない場合にどう検証するか
- モデル更新時の回帰をどう確認するか

モデルAPIは外部サービスです。ネットワーク障害もRate limitもあり、同じ入力でも出力が一致するとは限りません。

既存のAPI連携と同じように失敗を扱いながら、生成結果の揺れまで前提にする。従来のWebシステムと接続するときに難しいのは、この二つを一緒に扱うところだと思います。

### Context window

一度のモデル呼び出しで扱えるToken量には上限があります。[Context](/guides/context)には、System Instruction、会話履歴、検索結果、Tool定義、Tool結果、生成する出力が入り、同じ予算を使います。

上限が大きくても、関係のない履歴をすべて渡した方がよいとは限りません。費用とレイテンシが増え、古い情報や相反する指示も混ざります。

必要なContextを選ぶ。長い処理では、要約・分割・外部状態への退避も検討します。入るから全部入れる、は避けておきたい構成です。

### Samplingと出力の揺れ

Temperatureなどの設定で出力の選び方を調整できるAPIがあります。ただし、値を下げれば業務処理が完全に決定的になるわけではありません。モデルや提供基盤の更新、入力の差、並列処理によって結果は変わり得ます。

厳密な形式が必要なら、[Structured Output](/guides/structured-output)やSchema validationを使います。金額計算・権限判定・在庫更新のように決定的であるべき処理は、LLMへ文章で任せずコード側に残します。

### 学習済み知識と外部データ

LLMが学習時に得た知識は、現在の業務データや最新情報を保証しません。必要に応じて[RAG](/guides/rag)で根拠となる文書を渡す、Toolで現在の状態を取得する、回答へ出典を付けるといった構成を取ります。

それでも、取得した情報を読み違える可能性は残ります。検索できた。だから正しく判断できた。とは限りません。ここも分けて評価します。

## よくある誤解

### パラメータ数が多ければ、常に優れたLLMになる

モデルの性能は、学習データ・学習方法・推論方法・利用するタスクによって変わります。公開されたパラメータ数だけで、品質・速度・コスト・安全性までは判断できません。

### Context windowが大きければ、すべての資料を渡してよい

入力できる量と、モデルが必要な情報を正しく使えることは別です。関連性の低い情報を減らし、重要な指示や根拠が埋もれないようにします。

### LLMが自然に答えたので、内容も正しい

文章の自然さは事実性の保証になりません。根拠が必要な用途では、参照元の提示、計算や照合の外部化、人間による確認を組み合わせます。

### LLMへ業務ルールを書けば、必ず守られる

Instructionはモデルの振る舞いを調整しますが、強制力のある認可やValidationではありません。拒否すべき操作は、API・Policy・Toolの実装側で止めます。

### LLMを使えばAI Agentになる

一度の入力へ文章を返すだけなら、LLMを使ったアプリケーションです。目標に応じた実行ループ、Tool利用、状態、停止条件を持つ場合にAI Agentとして扱います。

## EastBraver Labsの判断基準

EastBraver Labsでは、LLMを賢さのランキングだけでは選びません。

まず、対象業務の評価セットを用意し、品質・レイテンシ・Token使用量・費用を同じ条件で比較します。モデル名を固定して終わりではなく、Model IDやVersion、Prompt、評価結果を記録し、更新時に戻せるようにします。

LLMへ任せるのは、曖昧な入力の解釈、文章の生成、候補の整理といった確率的な処理です。権限判定、金額計算、整合性維持、取り消せない更新はコード側で強制します。

モデルが間違えない前提には置かない。間違えたときに検知し、影響を限定できる構成を選びます。

## 関連記事

- [AI Agent 時代に、エンジニアは何を設計する人になるのか](/blog/ai-development-20260706)
- [低コストAIモデル競争が加速](/digest/ai-digest-20260701)
- [ローカル推論更新とAI運用の検証課題](/digest/ai-digest-20260713)

## 検証範囲

- 一次情報: 研究論文 / 設計面からの分析
- ローカル検証: 概念を整理するGuideなので、コードは動かしていません
- 実運用: 本番運用の実績については、このGuideでは触れていません

## 変更履歴

- 2026-07-24: Mermaid図にテキスト等価物を追加
- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-01: 初版公開