はじめに
最近、AIエージェント関連の書籍が多く日本語訳され始め、オライリーなどからも多くの書籍が出版されるようになりました。
何冊か読んでいく中で、必ず毎回簡単に説明の入る単語や技術が出てきており、個人的にはかなりの部分を読み飛ばしてしまっているんですが、何度も出てくるということは現代においてAIエージェント関連の知識の基本と言えるのではないかと思い、まとめておくことにしました。
思ったより長くなってしまったのでモデル編と活用編に分けて書きます。まずはモデル編です。
『生成AIデザインパターン』（Valliappa Lakshmanan、Hannes Hapke 著、オライリー・ジャパン）の内容やその他調査をもとにまとめています。
1. LLM（Large Language Model）
そもそもLLMとは何か、という話をしておきます。
本題に入る前に、言葉を3つだけ揃えておきます。生成AI、LLM、基盤モデルです。この3つはニュースでも技術記事でもほぼ同じ意味で使われていますが、厳密には包含関係にあります。
生成AIは一番広い言葉で、テキスト・画像・音声・動画といった新しいコンテンツを作り出すモデルの総称です。分類や予測をする従来のMLモデルと区別するための呼び名だと思ってください。
**LLM（大規模言語モデル）**はそのうちテキストを扱うものです。「言語モデル」自体は昔からある概念で、文脈が与えられたときに次に来る語の確率分布を返す関数のことを指します。スマートフォンの予測変換も、小さな言語モデルです。これに「大規模」がつくのは、パラメータ（モデル内部の数値の数）が数十億から数千億、学習データが数兆トークンという桁になったからで、2017年に発表されたTransformerというアーキテクチャがこの規模化を可能にしました。Transformerの中核は、文脈中のどの語に注目すべきかを学習する「アテンション」という仕組みで、長い文脈を並列に処理できることが以前の方式との決定的な違いでした。
基盤モデルは視点が少し違います。2021年にスタンフォード大学の研究グループが提案した言葉で、特定のタスクのためではなく汎用に事前学習され、多くの下流タスクに転用できるモデルを指します。LLMは基盤モデルの代表ですが、画像生成モデルやマルチモーダルモデルも基盤モデルです。「何ができるか」ではなく「どう作られ、どう使われるか」に注目した呼び名なので、開発者の視点に近いのはこちらです。本記事では、文脈に応じてLLMと基盤モデルを使い分けますが、指しているものはほぼ同じだと読んでください。
AIで雑に作成した図ですが、下記のような関係にあります。
図の右側が、LLMの動作を最も素朴に描いたものです。入力されたテキストをトークン列として受け取り、次のトークンの確率分布を計算し、そこから1つ選んで末尾に足し、また最初から同じことを繰り返す。この「自分の出力を次の入力に含める」やり方を自己回帰と呼びます。
一見単純です。ですが、この図には後で効いてくる仕掛けが2つ埋まっています。
一つは、モデルが「答え」を持っているわけではなく「確率分布」を持っているという点です。「今日の天気は」の続きとして、モデルは晴れ41%、雨28%と考えているだけで、どれを選ぶかは別の工程が決めます。もう一つは、選ばれたトークンが次の入力になるという点です。途中で一つ変なトークンを選ぶと、以降の生成はその変なトークンを前提に進みます。もっともらしい嘘が最後まで一貫して語られるのは、この構造のせいです。
デモは簡単、本番は難しい
基盤モデルのAPIを触った人なら、最初の30分で味わう高揚感を知っているはずです。数行のプロンプトで、自然言語の問い合わせに答えるボットができてしまう。
そして数週間後、同じ人が別の顔をしています。返ってくる答えが日によって違う。存在しない機能を自信満々に説明する。社内の最新ドキュメントの内容を知らない。「たまに変な答えをする」を、本番環境でどう扱えばいいのかがわからない。
『生成AIデザインパターン』はこのギャップから書き起こされています。同書が挙げる本番環境での壁は大きく4つで、ハルシネーション（もっともらしい誤情報）、非決定性（同じ入力に違う出力）、知識カットオフ（学習時点以降を知らない）、そしてエンタープライズの制約（社内データや規制）です。デザインパターンとは、この4つに対する先人の解答集だと言えます。
従来の機械学習では、解きたい問題ごとにデータを集め、モデルを学習させ、デプロイしていました。これに対して、GPT・Claude・Gemini・Llamaのような学習済みの基盤モデルをAPI経由で呼び出し、その上にアプリケーションを組み立てる。このアプローチを、同書はChip Huyenの『AIエンジニアリング』に倣ってAIエンジニアリングと呼びます。
図にすると、違いは開発フローの「始まり」にあります。
従来のMLは、データが集まるまで何も始まりません。『実践 AIエージェント開発』（Michael Albada 著、オライリー・ジャパン）は、この状況を「MLエンジニアを雇い、データを集め、モデルをデプロイしなければ何も作れなかった」時代として描き、大規模事前学習モデルの登場を「事前学習革命」と呼んでいます。ホストされたモデルを一回呼ぶだけで、多くのユースケースで十分な品質が手に入るようになったからです。
一方で、AIエンジニアリングには「学習」の工程がありません。代わりに、モデルを選び、プロンプトを設計し、自分のタスクで評価し、足りない部分をパターンで補強するという、ソフトウェア工学寄りのループになります。
では、初心者は最初にどこまでを目指せばいいのでしょうか。「エージェント」という言葉が流行っているので、自律的に動くものを作らないと勉強したことにならない気がする。私も最初はそう思っていました。
これについては、Anthropicが2024年末に公開した「Building effective agents」の立場が参考になります。同記事は、LLMアプリケーションでは可能な限り単純な解決策から始め、必要になったときだけ複雑さを足すことを推奨しており、多くのアプリケーションでは検索とプロンプト内の例で補強した単一のLLM呼び出しで十分だと述べています。エージェントを作るのは、柔軟性が本当に必要になってからでいい。
ただ、この立場も2年前のものとなり、書籍の書かれたタイミングと現状では多少ギャップがあるかなと感じています。
モデルとの対話：プロンプトの正体
チャット画面に文章を打ち込むとき、私たちは一つのテキストを送っているように感じます。ですが、アプリケーションを作る側から見ると、プロンプトは複数の部品からできています。
最も単純なプロンプトは、インストラクション（指示）だけで構成されます。「この文章を要約して」がそれです。モデルは指示に従い、要求された形式で応答を返します。テキストだけでなく、画像や音声を入力・出力に含められるマルチモーダルなモデルも今では珍しくありません。
もう少し複雑なプロンプトになると、指示に加えてコンテキストが入ります。コンテキストとは、生成の際にモデルに使ってほしい情報や、モデルに演じてほしい役割です。「あなたは小売業に詳しいマーケターです」という役割も、「以下は当店の返品ポリシーです」という資料も、どちらもコンテキストです。
API経由で呼び出す場合、この構造がもう一段はっきりします。
主要なAPIは、プロンプトをシステムプロンプトとユーザプロンプトに分けて受け取ります。システムプロンプトは開発者が設定するもので、モデルの全体的な振る舞い（役割、口調、禁止事項）を定めます。ユーザプロンプトはリクエストごとに変わる動的な部分で、今回のタスクに関する具体的な指示と、その材料となるコンテキストが入ります。
GoogleがKaggleで公開しているプロンプトエンジニアリングのホワイトペーパー（Lee Boonstra, 2024）は、この構造を別の角度から整理しています。同書は「システムプロンプティング」「ロールプロンプティング」「コンテキスチュアルプロンプティング」を区別し、それぞれが全体の文脈、人格、タスク固有の情報を担うと説明しています。名前は違いますが、図の3層と対応していることがわかります。
ここまで読んで、「結局、全部文字列を連結して送っているだけでは」と思った方は正しいです。モデルにとっては最終的に一つのトークン列です。それでもシステムとユーザを分ける設計になっているのは、多くのモデルが学習段階で「システム側の指示を優先する」ように訓練されているからで、この分離を守るとモデルの挙動が安定しやすくなります。
呼び出し方は大きく3通りあります。
ベンダが提供するSDKやAPIを直接使う LLMに依存しないフレームワーク（LangChain、PydanticAIなど）を通して使う。モデル名の文字列を変えるだけでプロバイダを切り替えられる Ollamaなどでモデルを手元のマシンにダウンロードし、ローカルで動かす
どれを選んでも送るものの構造は変わりません。最初はベンダのAPIを直接触るのが、何が起きているか一番わかりやすいと思います。
モデルはどう作られているか
「プロンプトを送ると答えが返る」という理解で、実務の8割は回ります。ただ、残りの2割で必ず用語につまずくので、基盤モデルがどう作られているかを一度だけ見ておきます。
最初につまずくのはトークンです。
料金表には「100万トークンあたり何ドル」と書いてあります。LLMは文字や単語ではなく、トークンという短い文字列の単位でテキストを扱います。「トークン化」は語彙にない固有名詞も部分文字列の組み合わせで表現できる仕組みで、BPE（Byte Pair Encoding）という手法が広く使われています。
ここで、日本語で開発する人が知っておくべき事実があります。同じ意味の文章でも、日本語は英語よりトークン数が多くなるのです。
実際に確かめてみました。OpenAIが公開しているトークナイザ（tiktoken）で、同じ内容の日本語と英語の段落を数えた結果です。
| トークナイザ | 日本語（116文字） | 英語（268文字） | 日本語÷英語 |
|---|---|---|---|
| cl100k_base（GPT-4世代） | 121トークン | 49トークン | 約2.5倍 |
| o200k_base（GPT-4o世代） | 84トークン | 49トークン | 約1.7倍 |
日本語はほぼ1文字1トークン、英語は1トークンあたり5文字強でした。新しいトークナイザで日本語の効率は改善していますが、それでも同じ意味を伝えるのに英語の1.7倍のトークンを消費します。トークンはコストであり、コンテキストウィンドウの消費量であり、応答速度でもあります。日本語のプロンプトは、英語の感覚より短めに設計する必要があるわけです。
料金表の次に読めなくなるのは、モデルカードや発表記事に並ぶ「SFT」「RLHF」といった略語です。これらは全部、モデルが作られる工程の名前です。
現在の基盤モデルは、おおむね3段階で作られます。
1つめは事前学習です。Web規模の巨大なテキスト（DeepSeek-V3の場合は14.8兆トークン）を使い、「文脈が与えられたとき次のトークンは何か」だけをひたすら学びます。この段階を終えたものがベースモデルで、言語の統計的構造は知っていますが、質問に答える気はありません。「東京の人口は」と入れると、質問の続きを生成してくることがあります。
2つめは教師ありファインチューニング（SFT）です。人間が書いた「指示と模範回答」のペアで追加学習し、指示に従って答えるという形式を教えます。ここで使うデータは量より質で、専門家に理想の回答を書かせる企業もあります。
3つめは選好チューニングです。モデルの出力を2つ並べて人間に「どちらが良いか」を選ばせ、好まれる方に寄せていきます。人間のフィードバックによる強化学習（RLHF）がその代表です。この3段階の構成は、OpenAIが2022年に発表したInstructGPTの論文で示された流れがほぼそのまま業界標準になったものです。
ここまで読むと、「LLMは次のトークンを予測しているだけ」という有名な説明が、正確には第1段階の話だったことがわかります。私たちがAPI越しに触っているのは第3段階を通過したモデルで、「人間に好まれる答え方」まで含めて訓練されています。
そして2025年、この3段階に例外が現れました。DeepSeek-R1です。
DeepSeekの研究チームは、ベースモデルに対してSFTを飛ばし、「答えが合っているか」「形式を守っているか」という機械的に検証できる報酬だけで強化学習を直接かけました。すると、途中で自分の推論を見直したり検証したりする振る舞いが、教えていないのに自然に現れたと報告されています（この結果は2025年9月にNature誌に掲載されました）。人間が推論の手順を書いた例題を大量に用意しなくても推論能力が育つ、というのは当時の常識を覆す発見でした。
もう一つ、実務で頻繁に出てくる言葉が蒸留です。大きなモデルの出力を教師データにして小さなモデルを訓練し、能力の大部分を保ったまま軽量化する手法です。DeepSeek-R1も1.5Bから70Bまでの蒸留版が公開されており、後述する「蒸留版」というカテゴリの語源になっています。
モデルの選び方
「どのモデルを使えばいいですか」は、AIの勉強を始めた人が最初に聞く質問で、そして答えが最も早く古くなる質問です。個別のモデル名を覚えるより、全体かんを知っておくといいと思います。
『生成AIデザインパターン』は基盤モデルを4つのカテゴリに分けています。
フロンティアモデルは、各社のフラッグシップです。推論・知識・マルチモーダルのすべてで最高性能ですが、コストが高く、ローカルでは動きません。
蒸留版は、フロンティアモデルを軽量化したもので、Gemini Flash、Claude Sonnet、GPTのminiシリーズなどが該当します。要約や定型的な生成では十分な性能を、はるかに低いコストと速い応答で提供します。
オープンウェイトモデルは、Llama、Mistral、DeepSeek、Qwenのように重み（パラメータ）が公開されているモデルです。自前でホストできて、自社データでファインチューニングもできます。代わりに動かすための知識とGPUが必要です。
ローカル実行可能モデルは、その中でも手元のマシンで動くサイズのものです。データが外に出ないので完全なプライバシーが確保でき、APIの従量課金もありません。能力はクラウドのモデルに劣ります。
4つ並べたところで、身も蓋もない疑問が残ります。で、どれから始めればいいのか。
『実践 AIエージェント開発』の答えは明快で、まず主要プロバイダの最新汎用モデルをそのまま使え、です。初期設定のままで多くの用途をカバーできるので、性能あたりのコストを極限まで詰める作業は、規模や制約がそれを要求してからでいい。同書は、単純な問い合わせは小型モデルに、複雑な推論は大型モデルに振り分ける「動的ルーティング」が広がっていることも紹介しており、将来はほぼ確実に複数モデルを併用する時代になると見ています。
オープンウェイトを検討するときの目安も同書にあります。おおむね140億パラメータまでなら24GBのVRAMを持つコンシューマ向けGPU1枚で動き、それを超えるとA100のようなサーバ向けGPUが欲しくなる。この線を知っておくと、「ローカルで試せる範囲」の見当がつきます。
残る問題は、そもそも「性能が高い」をどう測るかです。
リーダーボードは何を測っているのか
『生成AIデザインパターン』は、学術ベンチマークは飽和しておりハックも可能なので、現在最も受け入れられている評価法は人間によるブラインドのペア比較だとして、LMArena（arena.ai）を紹介しています。2つのモデルの回答を匿名で並べ、人間がどちらが良いかを投票し、チェスと同じEloレーティングで順位をつける仕組みです。
これは確かに、選択式問題の正答率より実感に近い指標です。ただ、2025年4月にCohere Labsやスタンフォード大学などの研究者が発表した「The Leaderboard Illusion」という論文は、この仕組みの歪みを指摘しました。一部の大手プロバイダが非公開の変種を多数テストして最良のものだけを公開している、対戦データの配分がプロバイダ間で大きく偏っている、といった内容です。Arena側は反論を公開しており、争点は今も残っています。
ここで大事なのは、どちらが正しいかではありません。順位表には必ず、そのベンチマークの作り方に由来する偏りがある、ということです。スタンフォードのHELMのように多面的な評価を目指す取り組みもありますが、それでも「自分のタスク」を測ってはくれません。
結局、「まず最新汎用モデルで始める」という順序論は、この文脈で読むと別の意味を帯びてきます。最初に選ぶモデルは暫定でいい。本当に必要なのは、自分のユースケースの入出力を数十件集めて、モデルを差し替えたときに良くなったか悪くなったかを言えるようにしておくことです。前編の図1に「評価：自分のタスクで測る」と書いたのは、そのためです。
まとめ
前編で見てきたのは、次の3点です。
- LLMは次のトークンの確率分布を返す関数であり、その出力を自分の入力に足しながら進む。答えではなく確率を持っている
- AIエンジニアリングは学習工程を持たない。基盤モデルを選び、プロンプトを設計し、自分のタスクで評価するループになる
- プロンプトはシステムプロンプト・コンテキスト・インストラクションの層構造で、モデルは事前学習・SFT・選好チューニングの3段階で作られている
- モデルの4分類とリーダーボードの限界を踏まえると、最初の選択は暫定で構わず、差し替えを判断できる評価データの方が資産になる
冒頭の「デモは簡単、本番は難しい」に戻ると、4つの壁のうち知識カットオフとエンタープライズの制約は、前編の内容だけでも輪郭がつかめたはずです。学習時点で知識が固定され、社内データは学習に含まれていない。だからコンテキストとして渡す必要がある。
ただ、非決定性については、今回は記載していません。同じプロンプトを送っても答えが揺れるのはなぜか。設定で止められるのか。止めたとして、それは本当に「止まった」と言えるのか。
後編はこれらをまとめる予定です。
参考文献
- Valliappa Lakshmanan, Hannes Hapke 著、中田秀基 訳『生成AIデザインパターン』オライリー・ジャパン、2025
- Michael Albada 著、鈴木駿・高山洪銘・山下正浩 訳『実践 AIエージェント開発』オライリー・ジャパン、2025
- Chip Huyen 著『AIエンジニアリング』オライリー・ジャパン、2025
