8-2 LLMアプリケーション設計
Designing LLM Applications
1. LLMの活用パターン
1.1 基本的な活用パターン
LLMは汎用的な言語理解・生成能力を持つため、様々な用途に活用できる。 ただし、すべてのタスクにLLMが適しているわけではない。 従来のルールベースや機械学習が適切な場合もあり、 コストと効果のバランスを考慮して選択する必要がある。
| パターン | 説明 | 例 |
|---|---|---|
| テキスト生成 | 文章の作成、要約、翻訳 | 記事作成、メール下書き |
| 質問応答 | 質問に対する回答生成 | カスタマーサポート、FAQ |
| 分類 | テキストのカテゴリ分け | 感情分析、トピック分類 |
| 情報抽出 | テキストから構造化データを抽出 | 固有表現抽出、データ変換 |
| コード生成 | プログラムコードの生成・補完 | 開発支援、自動化 |
| 推論・計画 | 複雑な問題の分解と解決 | エージェント、意思決定支援 |
1.2 LLMの限界
LLMには強力な能力がある一方で、限界も存在する。 これらの限界を理解し、適切な対策を講じることが重要である。 特にハルシネーション（事実と異なる情報の生成）は、 ビジネスアプリケーションで深刻な問題となりうる。
| 限界 | 説明 |
|---|---|
| ハルシネーション | 事実と異なる情報を生成する |
| 知識の古さ | 学習データ以降の情報を持たない |
| 推論の不安定性 | 同じ質問でも異なる回答をする場合がある |
| コンテキスト長の制限 | 処理できるテキスト量に上限がある |
| 計算コスト | APIコスト、レイテンシ |
LLMは自信を持って誤った情報を生成することがある。 重要な判断に使用する場合は、必ず人間によるレビューや、 外部データソースとの照合を行うべきである。
2. アーキテクチャの選択
2.1 主要なアーキテクチャパターン
LLMアプリケーションのアーキテクチャは、要件に応じて選択する。 最もシンプルなのはAPI直接呼び出しだが、 より高度な要件にはRAGやエージェントアーキテクチャが必要となる。 複雑なアーキテクチャほど開発・運用コストが高くなるため、 必要最小限の構成から始めることが推奨される。
| パターン | 概要 | 適用場面 |
|---|---|---|
| API直接呼び出し | LLM APIをそのまま使用 | シンプルな生成タスク |
| RAG | 外部知識を検索して参照 | 最新情報、社内データ活用 |
| ファインチューニング | モデルを追加学習 | 特定ドメインへの特化 |
| エージェント | 外部ツールを呼び出して行動 | 複雑なタスクの自動化 |
@startuml !theme plain skinparam backgroundColor #FEFEFE skinparam defaultFontName Noto Sans JP title LLMアーキテクチャパターン rectangle "API直接呼び出し" as Direct #DBEAFE rectangle "RAG" as RAG #D1FAE5 rectangle "エージェント" as Agent #FEF3C7 rectangle "ユーザー" as User #E0E7FF rectangle "LLM API" as LLM #DBEAFE rectangle "知識ベース" as KB #D1FAE5 rectangle "ツール群" as Tools #FEF3C7 User --> Direct : プロンプト Direct --> LLM LLM --> User : 応答 User --> RAG : 質問 RAG --> KB : 検索 KB --> LLM : 関連情報 LLM --> User : 応答 User --> Agent : タスク Agent --> LLM : 計画 LLM --> Tools : 呼び出し Tools --> LLM : 結果 LLM --> User : 最終結果 note bottom of Direct シンプル・低コスト end note note bottom of RAG 最新情報・独自データ end note note bottom of Agent 複雑なタスク・自律実行 end note @enduml
図1: LLMアーキテクチャの比較
2.2 選択の指針
アーキテクチャの選択は、データの鮮度要件、カスタマイズの必要性、 コスト、レイテンシ要件などを総合的に判断する。 多くの場合、まずシンプルな構成で検証し、 必要に応じて複雑な構成へ移行するアプローチが有効である。
| 要件 | 推奨パターン |
|---|---|
| 最新情報が必要 | RAG |
| 社内データを活用 | RAG |
| 特定の文体・形式 | ファインチューニング or プロンプト |
| 外部システム連携 | エージェント |
| コスト重視 | API直接 + キャッシュ |
3. プロンプトエンジニアリング
3.1 プロンプトの構成要素
プロンプトエンジニアリングは、LLMから望ましい出力を得るための 入力の設計技術である。適切なプロンプト設計により、 同じモデルでも出力品質が大きく変わる。 プロンプトは通常、指示、コンテキスト、入力データ、出力形式の指定で構成される。
| 要素 | 説明 | 例 |
|---|---|---|
| 指示（Instruction） | 何をすべきかの説明 | 「以下の文章を要約してください」 |
| コンテキスト | 背景情報、制約条件 | 「あなたは法律の専門家です」 |
| 入力データ | 処理対象のデータ | 要約対象の文章 |
| 出力形式 | 期待する出力の形式 | 「JSON形式で出力」 |
3.2 主要なプロンプト技法
プロンプトの書き方には、いくつかの確立された技法がある。 タスクの複雑さに応じて適切な技法を選択する。 シンプルなタスクではZero-shotで十分だが、 複雑な推論が必要な場合はChain-of-Thoughtが有効である。
| 技法 | 説明 | 適用場面 |
|---|---|---|
| Zero-shot | 例なしで指示のみ | シンプルなタスク |
| Few-shot | 数個の例を提示 | 形式の指定、スタイル統一 |
| Chain-of-Thought | 推論過程を段階的に | 複雑な推論、計算 |
| ReAct | 思考と行動を交互に | ツール使用、エージェント |
プロンプトはコードと同様にバージョン管理すべきである。 変更履歴を追跡し、性能の変化を記録する。 Gitでの管理や、専用のプロンプト管理ツールの活用が推奨される。
4. RAG（Retrieval-Augmented Generation）
4.1 RAGの概要
RAGは、外部の知識ベースから関連情報を検索し、 それをLLMに与えて回答を生成する手法である。 LLMの知識の古さやハルシネーションの問題を軽減でき、 社内ドキュメントなど独自のデータを活用できる。
@startuml !theme plain skinparam backgroundColor #FEFEFE skinparam defaultFontName Noto Sans JP title RAG（Retrieval-Augmented Generation） rectangle "ドキュメント" as Doc #DBEAFE rectangle "チャンク分割" as Chunk #DBEAFE rectangle "埋め込み" as Embed #DBEAFE rectangle "ベクトルDB" as VDB #D1FAE5 rectangle "ユーザー質問" as Q #FEF3C7 rectangle "クエリ埋め込み" as QE #FEF3C7 rectangle "類似検索" as Search #FEF3C7 rectangle "LLM" as LLM #FEE2E2 rectangle "回答" as A #FEE2E2 Doc --> Chunk : 分割 Chunk --> Embed : ベクトル化 Embed --> VDB : 格納 Q --> QE : ベクトル化 QE --> Search VDB --> Search : 検索 Search --> LLM : 関連チャンク Q --> LLM : 質問 LLM --> A : 生成 note right of Doc インデックス作成 （事前処理） end note note right of Q 検索・生成 （リアルタイム） end note @enduml
図2: RAGの基本アーキテクチャ
4.2 RAGのコンポーネント
RAGシステムは、インデックス作成パイプラインと検索・生成パイプラインで構成される。 各コンポーネントの品質が最終的な回答品質に影響する。
| コンポーネント | 役割 |
|---|---|
| ドキュメントローダー | PDF、Webページなどからテキスト抽出 |
| テキスト分割 | 適切なサイズのチャンクに分割 |
| 埋め込みモデル | テキストをベクトルに変換 |
| ベクトルストア | ベクトルの保存と類似検索 |
| リトリーバー | クエリに関連するチャンクを検索 |
| LLM | 検索結果を基に回答を生成 |
5. エージェント
5.1 エージェントとは
エージェントは、LLMが外部ツールを呼び出しながら タスクを自律的に遂行するシステムである。 検索、計算、API呼び出しなどのツールを組み合わせ、 複雑なタスクを分解して実行する。 ただし、自律性が高い分、予測不可能な動作のリスクもある。
| コンポーネント | 役割 |
|---|---|
| プランナー | タスクを分解し、実行計画を立てる |
| ツール | 外部機能（検索、計算、APIなど） |
| メモリ | 会話履歴、中間結果の保持 |
| 実行エンジン | 計画に基づきツールを実行 |
エージェント設計の注意点
エージェントは強力だが、制御が難しい。 無限ループ、過剰なAPI呼び出し、意図しない操作などのリスクがある。 人間による監視、実行回数の制限、危険な操作の禁止など、 適切なガードレールを設置することが重要である。
[1] Lewis, P. (2020). RAG: Retrieval-Augmented Generation.
[2] Anthropic. Claude Documentation.