第8章 — アプリケーションで LLM を使う
LLM Primer I: How Generative AI Works を章ごとに紹介するシリーズ、第8回です。前回は Embedding、RAG、マルチモーダルを扱いました。今日は LLM が、実際の製品の中でどんな顔をしているのか — うまく回るパターン、回らないパターン、そしてモデルが運転席に座る新しい潮流「エージェント型システム」を、ご一緒に見てまいります。
チャットボットは「モデルだけ」ではない
チャットボットに対して、人がもっとも陥りやすい誤解は「モデル = 製品」と思ってしまうことです。違います。モデルはあくまでひとつのコンポーネント。製品の正体は、モデルを包む「システム」 — プロンプトテンプレート、会話履歴の管理、安全フィルター、検索層、ツール統合、フォールバック方針、UI — の総体のほうかと思います。
本番のチャットボットでは、エンジニアリングの労力の大半が「モデル本体」ではなく「周囲のシステム」に注がれます。よく設計された中位モデルのチャットボットが、フロンティアモデルを乗せただけの雑なチャットボットを、ほぼ常に上回るのも、ここに理由がある。本書では、会話状態をどう持つか、古いターンをいつ要約しいつ原文のまま残すか、安全コントロールをどう積み重ねるか、といった「現に効くアーキテクチャパターン」を順に整理してまいります。
要約と検索
もっともインパクトの大きいLLMユースケースのうち2つは、どちらも本質的には「情報の凝縮」です。要約は長文を短くしつつ意味を保ち、セマンティック検索はキーワードではなく「意図」によって、大規模コーパスから関連素材を引き出す。
現代の面白いパターンは、両方を組み合わせること。ユーザーが質問する、システムが関連文書を検索する、モデルが取り出した素材を要約して焦点の合った答えを返す。世の中の「AI 検索」と銘打たれた製品の多くが、裏でやっているのはこれです。うまく回ると魔法のように見え、うまく回らないときの原因のほとんどは「検索ステップが本当に必要な素材を引けなかったこと」で、「モデルが要約できなかったこと」ではありません。
コード生成
プログラミング言語は、文法が厳密でフィードバックも明快な形式言語です。LLMとの相性は、もともと格別。大量のコードを浴びてきたモデルは、コンパイルが通る補完、慣例に沿った関数シグネチャ、周囲のコードに似た言い回しまで予測できるようになります。
現代のコードアシスタントは、特殊な形のRAGシステムです。編集中のコードベースから関連コンテキストを引き、ユーザーの依頼と一緒にモデルへ渡す。モデルはこれが本当に得意です。本書はそのプラス面 — 範囲を絞ったタスクでの本物の生産性向上 — も、マイナス面 — 流暢に見えるコードの中に潜む微妙な正しさの問題 — も、両方とも現実的なトーンで扱います。
知識抽出
「書く」の逆は「読む」。知識抽出は、非構造化の文書をモデルに渡し、構造化されたデータを返してもらうパターンです。PDF から請求番号・日付・金額を抜く、履歴書から職歴を取り出す、論文から登場する化合物を拾う、といった具合に。
LLM の業務応用としていちばん「すぐに役に立つ」類のひとつで、出力をスキーマで検証できるぶん、比較的安全に運用できます。本書では、プロンプトと検証層を「セットで設計する」やり方を紹介します。モデルがフォーマットを崩したときに、下流のシステムをサイレントに汚すのではなく、捕まえてリトライするための作り方です。
本番運用での評価
LLM の出力は確率的なので、決定論的なソフトウェアと同じ流儀ではテストできません。比較すべき「唯一の正解」が、そもそもほとんど存在しないからです。評価ではいくつかの手法を組み合わせます — 当てはまる場面の自動指標、強いモデルによるスコアリング、構造化された人手レビュー、本番でのA/Bテスト、ドリフトを見張るための継続モニタリング。
このセクションでは、研究や製品発表の文脈で頻繁に登場する「名前付きベンチマーク」も紹介します — MMLU、GPQA-Diamond、HumanEval、SWE-bench、MMMU、LiveBench、GSM8K、MATH、ARC-AGI、BFCL、IFEval。本書はそれぞれに1段落のリファレンスを用意してあって、モデル比較を読んだとき「何が測られているのか」を、ぱっと把握できるようにしてあります。
新しいパターン — エージェント型システム
このセクションは2026年版で新設しました。この分野でいちばん動きが速い領域だからです。エージェント型システムでは、モデルが運転席に座ります。ただテキストを出すのではなく、いつ電卓を呼ぶか、いつデータベースに問い合わせるか、いつ検索ツールを起動するか、いつ追加の確認を返すか — そして結果をどう扱うか — を、モデル自身が決めるのです。
機構の中心にあるのは、構造化されたツール呼び出し。利用可能なツールは、関数のシグネチャと説明、引数のスキーマとしてモデルに渡されます。モデルは普通の文章のかわりに、構造化されたツール呼び出しを出力できる。周囲のシステムはそれをパースしてツールを実行し、結果を返す。モデルは次の一手を決める。これを、モデルが「完了」と宣言するまで回す、というループです。
この構成は、新しい工学的な悩みも一緒に運んできます。本書もそこを正面から扱います。エージェントのループは予測しにくい速さでリソースを食いますし、ツールの失敗はモデルの振る舞いへ伝播します。安全性の懸念はさらに重くなる — モデルは世界を「描写する」だけでなく、「動かす」存在になるからです。本書ではツールインベントリの設計、ステップごとの正しさの評価、暴走ループの止め方まで、ひととおり整理してまいります。
第8章を通して、得られるもの
第8章を読み終えるころには、LLMの主要なアプリケーションパターンに対する、実務的なプレイブックが手元に残ります。問題の種類ごとにどんなシステム形態が向くか、評価がどんな顔をしているか、ベンダーが公表しているベンチマーク値の読み方も含めて。次の章では、それを「スケールで動かす」コストの話に進ませていただきます。
次回 — 第9章: パフォーマンス、スケール、コスト。 運用の現実に踏み込んでまいります。レイテンシ、スループット、リクエスト単価、量子化、オンデバイス展開、そして「ビジネスの大半は、入手可能な最大モデルから本当には恩恵を受けない」という前提を置いたうえで、モデルサイズをどう考えるか。
