LLMアプリ開発の技術選定ガイド — RAG・Agent・ファインチューニング

LLM（大規模言語モデル）を活用したアプリケーション開発が急速に普及しています。しかし、「RAGを使うべきか、ファインチューニングすべきか」「LangChainとLlamaIndexのどちらを選ぶべきか」など、技術選定で迷うケースが多いのではないでしょうか。

本記事では、LLMアプリ開発で直面する主要な技術選定ポイントを体系的に解説します。

アーキテクチャパターンの選び方

LLMアプリケーションの実装アプローチは、大きく3つに分類できます。

1. RAG（Retrieval-Augmented Generation）

概要: 外部データソースから関連情報を検索し、LLMに文脈として渡して回答を生成するパターンです。

適しているケース:

• 社内ドキュメントやFAQに基づく質問応答
• 最新情報を反映した回答が必要な場合
• データが頻繁に更新される場合

メリット:

• モデル自体を再学習する必要がない
• データの追加・更新が容易
• ハルシネーション（幻覚）を抑制しやすい

デメリット:

• 検索精度がシステム全体の品質を左右する
• チャンキング（文書分割）戦略の設計が重要
• レイテンシが増加する

2. AIエージェント

概要: LLMが自律的にツール（API、DB、外部サービス）を選択・実行しながらタスクを完遂するパターンです。

適しているケース:

• 複数ステップの業務プロセス自動化
• 外部システムとの連携が必要な場合
• ユーザーの意図に応じて柔軟に対応する必要がある場合

メリット:

• 複雑なタスクを自律的に処理できる
• ツールの追加で機能を拡張しやすい
• 人間に近い判断・行動が可能

デメリット:

• 実行コストが高い（複数回のLLM呼び出し）
• デバッグ・テストが複雑
• 予期しない動作のリスク管理が必要

3. ファインチューニング

概要: 既存のLLMを自社データで追加学習し、特定のタスクに特化させるパターンです。

適しているケース:

• 特定のドメイン知識が必要な場合（医療、法律など）
• 出力フォーマットを厳密に制御したい場合
• 推論コストを下げたい場合（小さいモデルで高精度を実現）

メリット:

• 特定タスクで高い精度を実現できる
• 推論時にコンテキストを渡す必要がない
• レスポンスが速い

デメリット:

• 学習データの準備に工数がかかる
• データの更新にはモデルの再学習が必要
• 学習環境（GPU）のコストが発生

判断フローチャート

自社データに基づく回答が必要？
├─ Yes → データは頻繁に更新される？
│        ├─ Yes → RAG
│        └─ No → 出力フォーマットの厳密な制御が必要？
│                 ├─ Yes → ファインチューニング
│                 └─ No → RAG
└─ No → 複数ステップの自律的な処理が必要？
         ├─ Yes → AIエージェント
         └─ No → プロンプトエンジニアリングで対応

LLMモデルの選定

主要モデルの比較

| モデル | 強み | 適用シーン | コスト感 | |--------|------|-----------|---------| | GPT-4o | バランスの取れた性能 | 汎用的なタスク全般 | 中 | | Claude 3.5 Sonnet | 長文処理・コード生成 | ドキュメント分析・開発支援 | 中 | | Gemini 1.5 Pro | マルチモーダル・長コンテキスト | 画像+テキストの複合タスク | 中 | | GPT-4o mini | コスト効率 | 大量処理・分類タスク | 低 | | Claude 3 Haiku | 高速・低コスト | リアルタイム応答・大量処理 | 低 |

選定の判断基準

1. 精度要件: 高精度が求められる場合はGPT-4oやClaude 3.5 Sonnet
2. コスト: 大量処理にはGPT-4o miniやClaude 3 Haiku
3. レイテンシ: リアルタイム応答には小型モデル
4. コンテキスト長: 長文処理にはClaude（200Kトークン）やGemini（1Mトークン）
5. マルチモーダル: 画像処理が必要ならGPT-4oやGemini

フレームワークの選定

LangChain vs LlamaIndex

| 観点 | LangChain | LlamaIndex | |------|-----------|------------| | 主な用途 | エージェント・チェーン構築 | RAG・データ検索 | | 学習曲線 | やや高い | 比較的低い | | 柔軟性 | 高い（カスタマイズ自由） | RAGに特化 | | エコシステム | 豊富なインテグレーション | データコネクタが充実 | | 推奨シーン | 複雑なワークフロー・エージェント | RAG中心のアプリケーション |

実務上の使い分け:

• RAG中心のシステム → LlamaIndex
• エージェント + ツール連携 → LangChain
• 両方必要 → LangChainをベースにLlamaIndexのインデックスを組み込む

ベクトルデータベースの選定

| DB | 特徴 | 適用シーン | |----|------|-----------| | Pinecone | フルマネージド、スケーラブル | プロダクション環境 | | Weaviate | オープンソース、ハイブリッド検索 | セルフホスト環境 | | ChromaDB | 軽量、開発者フレンドリー | PoC・小規模プロジェクト | | pgvector | PostgreSQL拡張 | 既存PostgreSQL環境 |

インフラ・デプロイの選択肢

クラウドAIサービスの活用

各クラウドプロバイダーのAIサービスを活用することで、インフラ管理の負荷を軽減できます。

• AWS: Amazon Bedrock（マルチモデルAPI）、SageMaker（モデルホスティング）
• Google Cloud: Vertex AI（モデルガーデン）、Cloud Run（推論API）
• Azure: Azure OpenAI Service（GPTモデル）、Azure AI Studio

推論APIのデプロイパターン

1. APIプロキシ型: 自社APIサーバーからLLM APIを呼び出す（最もシンプル）
2. セルフホスト型: オープンソースモデルを自社環境でホスティング
3. ハイブリッド型: メインはAPI利用、機密データはセルフホスト

技術選定のチェックリスト

LLMアプリ開発の技術選定で確認すべき項目をまとめます。

• [ ] 要件定義: 入力データの種類・量・更新頻度は明確か
• [ ] アーキテクチャ: RAG / エージェント / ファインチューニングの使い分けは妥当か
• [ ] モデル選定: 精度・コスト・レイテンシのバランスは適切か
• [ ] データ管理: 学習データ・検索データの品質管理体制はあるか
• [ ] セキュリティ: 機密データの取り扱い方針は明確か
• [ ] コスト試算: 月間のAPI呼び出し回数とコストを試算したか
• [ ] 評価指標: 精度・応答速度の目標値を設定したか
• [ ] 運用体制: モデル更新・データ更新のフローは設計したか

まとめ

LLMアプリ開発の技術選定は、「正解が一つ」ではなく、ビジネス要件・技術要件・コスト要件のバランスで決まります。

まずはPoCで小さく試し、実際のデータと業務で検証した上で本番環境の技術スタックを確定するのが最も確実なアプローチです。

BlueAIでは、自社プロダクトでのLLMアプリ開発経験をもとに、お客様に最適な技術選定をサポートしています。