ツール連携と検索精度向上 -- Function Calling, RAG, 出力検証の3本柱で実務レベルのLLM活用を組み立てる
LLMの使い方は大きく3つに分類できます。単純な方から順に、直接生成、RAG（検索拡張生成）、エージェント。プロジェクトの要件によってどのパターンが適切かが変わります。
向いている場面: 一般的なQ&A、文章生成、翻訳、コード生成など、外部データの参照が不要なタスク
向いている場面: 社内ナレッジ検索、最新情報の参照、根拠付き回答が必要な場面
向いている場面: 複雑な調査、マルチステップの業務自動化、コード修正の自動化
3つのパターンは排他的ではありません。エージェントの中でRAGを使う、直接生成の結果をツールで検証する、といった組み合わせが実務では一般的です。
Function CallingはLLMが「この場面ではこのツールを呼ぶべき」と判断し、必要なパラメータを生成する仕組みです。LLMがツールを直接実行するのではなく、「何を呼ぶか」を指示するだけで、実際の実行はアプリケーション側が行います。この分離がセキュリティ上の重要なポイントになります。
| 観点 | OpenAI（Function Calling） | Anthropic（Tool Use） |
|---|---|---|
| 定義方法 | tools配列にJSON Schemaで関数を定義 | tools配列にinput_schemaで定義 |
| 呼出形式 | tool_callsオブジェクト | tool_useコンテンツブロック |
| 並列呼出 | 対応（parallel_tool_calls） | 対応（複数tool_useブロック） |
| 強制実行 | tool_choice: "required" | tool_choice: {type: "any"} |
| ストリーミング | 対応 | 対応 |
| 結果返却 | roleを"tool"にしてtool_call_idと紐付け | tool_resultコンテンツブロック |
RAGは「検索して、注入して、生成する」の3ステップに見えますが、実際にはその前後に複数の工程があります。全工程を把握しておくことで、ボトルネックの特定と改善が速くなります。
チャンク分割はRAGの精度に直結します。「どう切るか」で検索結果が変わり、最終回答の品質が変わります。3つの戦略を比較します。
| 戦略 | 方法 | チャンクサイズ目安 | 利点 | 欠点 |
|---|---|---|---|---|
| 固定長分割 | 文字数やトークン数で機械的に分割 | 500-1000 tokens | 実装が容易 均一なチャンクサイズ | 文脈が途中で切れる可能性があります |
| セマンティック分割 | 意味の区切り（段落、セクション）で分割 | 可変（段落単位） | 文脈保持 意味的にまとまった単位 | チャンクサイズが不均一になりやすいです |
| 再帰的分割 | 複数の区切り文字を優先度付きで適用 | 500-1500 tokens | バランス 文脈保持とサイズ制御を両立 | パラメータ調整が必要です |
オーバーラップとは隣接チャンク間で重複させるトークン数のことです。文脈が途切れるのを防ぐ効果があります。オーバーラップ率はチャンクサイズの15-25%が目安です。
Embeddingモデルの選定はRAGの検索精度に直接影響します。英語中心のモデルと日本語対応モデルで性能差が出るため、対象言語を考慮して選びます。
| モデル | プロバイダー | 次元数 | 日本語対応 | 料金目安 | 特徴 |
|---|---|---|---|---|---|
| text-embedding-3-large | OpenAI | 3072 | 良好 | $0.13 / 1M tokens | 高精度、次元数を削減可能（Matryoshka） |
| text-embedding-3-small | OpenAI | 1536 | 普通 | $0.02 / 1M tokens | コスト重視、小規模プロジェクト向き |
| embed-multilingual-v3.0 | Cohere | 1024 | 良好 | 無料枠あり / 有料プランあり | 100言語以上対応、多言語検索に強いです |
| multilingual-e5-large | Microsoft（OSS） | 1024 | 良好 | 無料（自社ホスト） | Hugging Faceで公開、自社デプロイ可 |
| intfloat/multilingual-e5-large-instruct | intfloat（OSS） | 1024 | 良好 | 無料（自社ホスト） | 指示文付きEmbedding、検索精度向上 |
日本語のRAGでは text-embedding-3-large が安定した選択肢です。コストを抑えたい場合は multilingual-e5系のOSSモデルを自社ホストする方法もあります。
ベクトルDBはEmbeddingを格納・検索する専用データベースです。プロジェクトの規模、運用形態、既存インフラとの相性で選びます。
| DB名 | 形態 | スケーラビリティ | フィルタリング | 料金 | 適合場面 |
|---|---|---|---|---|---|
| Pinecone | マネージド | 高（サーバーレス対応） | メタデータフィルタ対応 | 従量課金（Free Tierあり） | 本番環境、運用負荷を下げたい場合 |
| Weaviate | OSS / マネージド | 高 | GraphQL、ハイブリッド検索 | OSS無料 / Cloud有料 | ハイブリッド検索が必要な場合 |
| Qdrant | OSS / マネージド | 高 | 豊富なフィルタ条件 | OSS無料 / Cloud有料 | 高度なフィルタリングが必要な場合 |
| pgvector | PostgreSQL拡張 | 中 | SQLによるフィルタ | PostgreSQLの費用のみ | 既存PostgreSQLがある場合 |
| ChromaDB | OSS | 低-中 | 基本的なフィルタ | 無料 | PoC、ローカル開発、小規模プロジェクト |
ベクトル検索だけでは取りこぼしが発生します。キーワードの一致が重要な場面もあれば、ユーザーの質問が曖昧で検索がうまくいかない場面もあります。3つのテクニックで精度を底上げします。
Step 1だけで十分な精度が出ることも多いです。Step 2, 3は精度が足りない場合に段階的に追加します。全部盛りにするとレイテンシとコストが跳ね上がるので、要件に応じて判断してください。
LLMが事実に基づかない情報を生成してしまうHallucination。完全にゼロにはできませんが、対策を重ねることでリスクを大幅に下げられます。4つの防御層で対処します。
| リスクレベル | 例 | 推奨対策 |
|---|---|---|
| 低 | 社内雑談Bot、アイデア出し | Grounding のみ |
| 中 | 社内FAQ、技術文書検索 | Grounding + Citation |
| 高 | 契約書レビュー、医療情報、金融判断 | 全4層 + 人間による最終確認 |
RAGの品質を「なんとなく良い」で終わらせません。定量的に測定して改善サイクルを回すための3つの指標を押さえます。
| ツール / 手法 | 概要 | 特徴 |
|---|---|---|
| RAGAS | RAG専用の自動評価フレームワーク | 月間40万DL超、2000万以上の評価実行[RAGAS公式]。Faithfulness, Answer Relevancy等を自動算出。OSSで無料利用可 |
| Maxim AI | エンタープライズ向けAI評価プラットフォーム | 2026年の評価ツールランキングでトップ評価[Maxim AI]。品質モニタリングとコスト最適化を統合 |
| LangSmith | LangChain公式のトレーシング・評価ツール | RAGパイプラインのネスト実行ステップ可視化、プロンプトのバージョン管理、A/Bテストに強いです |
| Arize Phoenix | LLMオブザーバビリティプラットフォーム | トレーシング、評価、Embeddingの可視化をカバー。OSS版あり |
| DeepEval | LLMテスティングフレームワーク | pytestライクなインターフェースで14以上の評価メトリクスを提供。CI/CD統合が容易 |
| 人間評価 | 担当者が手動で回答品質を採点 | 最も信頼性が高いです。スケールしませんが、自動評価の校正に必須です |
| LLM-as-a-Judge | 別のLLMに回答品質を判定させます | スケーラブルです。ただし判定モデル自身のバイアスに注意が必要です |
Context Recallが低い場合は検索段階（チャンク分割やEmbeddingモデル）に問題があります。Faithfulnessが低い場合はプロンプトの指示やGrounding設計に問題があります。指標を見てどこを直すべきかを判断します。