RAG（Retrieval Augmented Generation）は導入が進んでいますが、運用で最も難しいのは「改善したつもり」が頻発する点です。embedding モデルを変えた、chunk サイズを変えた、reranker を追加した。どれも良さそうに見えるのに、ユーザー満足は上がらない。このギャップを埋めるのが評価基盤です。

本記事では、RAG を継続改善するための評価パイプラインを、データセット設計から CI 統合まで具体的に解説します。

RAG評価で見るべき3層

RAG の品質は 1 指標では測れません。最低でも次の3層を分けて評価します。

1. Retrieval層: 正しい文書を取れているか
2. Generation層: 回答が正確で有用か
3. System層: レイテンシ・コスト・安定性

この分離がないと、生成品質低下の原因が retrieval なのか prompt なのか判別できません。

ステップ1：評価データセットを設計する

1-1. 問い合わせカテゴリを分割

例として次の5カテゴリに分けます。

• 定義確認（用語説明）
• 手順質問（How-to）
• 例外対応（エラー解決）
• 比較検討（A vs B）
• 根拠提示（出典必須）

カテゴリごとに難易度と重要度を持たせ、偏りを防ぎます。

1-2. 正解の持ち方

正解は「理想回答1つ」では不十分です。RAGでは表現揺れが自然なので、次を保存します。

• 期待要素（必須ポイント）
• 禁止要素（誤情報、過剰断定）
• 参照すべき文書ID

この形式にすると、自動評価と人手レビューを両立できます。

ステップ2：Retrieval評価を自動化

代表指標:

• Recall@k
• MRR
• nDCG

例えば、正解文書IDを持つ場合は次のように計算します。

1
2
3

def recall_at_k(retrieved_ids, gold_ids, k=5):
    topk = set(retrieved_ids[:k])
    return 1.0 if len(topk.intersection(gold_ids)) > 0 else 0.0

運用では平均値だけでなく、カテゴリ別分布を見ることが重要です。手順質問だけ recall が低い場合、chunk 戦略や見出し抽出に問題がある可能性が高いです。

ステップ3：Generation評価の設計

自動評価では次を推奨します。

• Faithfulness（出典との整合）
• Answer Relevance（質問への適合）
• Completeness（必要要素網羅）
• Safety（禁止事項違反）

LLM-as-a-judge を使う場合、判定プロンプトを固定し、temperature=0 で再現性を確保します。さらに、週次で人手サンプル監査を入れて判定ドリフトを検出します。

ステップ4：System評価（遅延・コスト）

品質改善がコスト爆増を招くと継続できません。次を同時に計測します。

• P50/P95 latency
• 平均 input/output token
• 1回答あたり推定コスト
• timeout率、fallback率

この4指標を CI レポートに含めると、精度改善の副作用を早期に発見できます。

ステップ5：CIへの組み込み

PR ごとに評価ジョブを実行し、閾値を満たさない変更をブロックします。

判定例:

• Recall@5: 0.82 以上
• Faithfulness: 0.90 以上
• P95 latency: 2500ms 以下
• Cost/answer: $0.005 以下

疑似フロー:

1. 変更ブランチでインデックス再構築
2. 評価データセット100件で推論
3. 指標を計算して前回基準と比較
4. 差分レポートをPRコメントに投稿

これで「なんとなく改善」を排除できます。

ステップ6：オンライン評価との接続

オフライン評価だけでは実利用の多様性を拾えません。オンライン指標を接続します。

• ユーザー評価（👍/👎）
• 再質問率（同一セッションで再問い合わせ）
• 人間オペレータ転送率

重要なのは trace_id でオフライン指標と紐づけることです。これにより「オフラインは良いのに本番満足が低い」差分を原因追跡できます。

改善ループの実例

ある社内ヘルプデスクRAGでの改善例:

• 問題: 手順質問で誤回答が多い
• 原因: chunk が短すぎ、手順文脈が分断
• 対策: section-aware chunking + reranker導入

結果:

• Recall@5: 0.74 → 0.88
• Faithfulness: 0.81 → 0.93
• P95 latency: +180ms（許容内）

このように、どの変更がどの指標に効いたかを記録すると、次回改善の再現性が高まります。

よくある失敗

1. 評価データが少なすぎる
   • 20件程度では統計的に不安定。最低100件、理想300件。
2. 単一スコアで判定する
   • 精度だけでコストを見ないと運用破綻。
3. 判定プロンプトを頻繁に変える
   • 指標比較の連続性が失われる。
4. 失敗事例をデータセットへ反映しない
   • 同じ不具合を繰り返す。

90日ロードマップ

• 0-30日: 評価データセット整備、retrieval指標導入
• 31-60日: generation指標 + CIゲート導入
• 61-90日: オンライン評価統合、週次改善会の定着

この順序なら、運用負荷を抑えつつ確実に品質を上げられます。

まとめ

RAG の実力は、モデル選定より評価基盤で決まります。retrieval、generation、system の3層を分離し、CI に組み込むことで、改善の再現性が生まれます。

まずは小さく始めて、失敗ケースを評価データセットに反映し続けてください。評価が回り始めると、RAG は「当たるかどうかの賭け」から「制御可能なプロダクト」へ変わります。

実装例：評価結果をPRコメントに自動投稿する

運用で効くのは、評価結果を開発者が日常的に見る導線を作ることです。GitHub Actions で評価スクリプトを実行し、結果を PR コメントへ投稿します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

name: rag-eval
on: [pull_request]
jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: uv sync
      - run: uv run python scripts/run_rag_eval.py --dataset evalset_v3.json --out report.json
      - run: uv run python scripts/post_pr_comment.py report.json

この仕組みがあると、レビュー段階で「この変更は Faithfulness を 0.04 落とすが latency は改善」という会話ができ、意思決定が定量化されます。

評価データセットの更新運用

評価セットを固定しすぎると、現実の問い合わせ変化に追従できません。次のルールを推奨します。

• 月1回、実ユーザー失敗ケースを20件追加
• 四半期ごとに古いケースを棚卸し
• 重要カテゴリ比率を維持（例: 手順質問30%以上）

この更新を怠ると、指標が良くても体感品質が落ちる「評価腐敗」が起きます。

A/Bテストとの接続

大きな変更（embedding刷新、reranker導入）は、オフライン評価だけでなくオンライン A/B を併用します。

• A群: 現行パイプライン
• B群: 新パイプライン
• 比較指標: 👍率、再質問率、回答時間、コスト

2週間程度の観測で統計差が出るケースが多く、主観ベースの議論を減らせます。

まとめ（定着のポイント）

RAG 改善を継続する鍵は、評価を「一回の検証」ではなく「開発フローの標準」にすることです。CI コメント、データセット更新、A/B テストを回すことで、品質向上が偶然ではなく再現可能な活動になります。

補足

評価結果は経営指標とも接続できます。問い合わせ解決率やサポート工数削減と紐づけることで、RAG 改善が事業価値にどう効いたかまで説明可能になります。

LLMアプリは「動く」だけでは本番品質になりません。運用を始めると、次のような問題が必ず発生します。

• 昨日まで 1.2 秒だった応答が突然 4 秒台になる
• コストが月末に急増したが、どの機能が原因かわからない
• 回答品質が落ちたと言われるが、どのプロンプト変更が影響したか追えない
• リトライ回数や外部API待ちの偏りが可視化されていない

この課題を解く鍵が「可観測性（Observability）」です。本記事では OpenTelemetry を軸に、LLM アプリの監視をゼロから構築する実装を、実際に運用で使える粒度で説明します。

なぜ APM だけでは LLM を見切れないのか

従来の Web アプリ監視（CPU、HTTP レイテンシ、エラーレート）だけでは、LLM 特有の故障点が見えません。理由は、LLM の品質とコストが「入力テキスト」と「推論設定」に強く依存するためです。

少なくとも次の軸が必要です。

1. Prompt 可視化: システム/ユーザー/ツール呼び出しの構成
2. Token 可視化: input/output token、モデル別単価、キャッシュヒット率
3. 推論経路可視化: retrieval → rerank → generation の各ステップ時間
4. 品質シグナル: hallucination 率、参照文書一致率、ユーザー評価

つまり、HTTP 1 本のログでは不十分で、トレース単位で LLM 実行を分解する必要があります。

アーキテクチャの全体像

最初に、実装対象を次の構成とします。

• API: FastAPI
• LLM: OpenAI / Azure OpenAI（抽象化）
• RAG: pgvector + reranker
• Observability: OpenTelemetry SDK + OTLP Exporter + Grafana Tempo/Loki/Prometheus

処理フローは次の通りです。

1. リクエスト受信時に trace_id を生成
2. Retrieval、Rerank、Generate をそれぞれ span 化
3. 各 span に token、model、temperature、cache_hit を attribute として記録
4. 失敗時は exception をイベントとして保存
5. レスポンス時にコスト推定を metrics として送信

ステップ1：OpenTelemetryの初期設定

まずは Python で最小セットを導入します。

1

uv add opentelemetry-api opentelemetry-sdk opentelemetry-exporter-otlp opentelemetry-instrumentation-fastapi

次に初期化コードを用意します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# observability.py
from opentelemetry import trace, metrics
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.resources import Resource

resource = Resource.create({
    "service.name": "tech-blog-autopilot-api",
    "service.version": "1.3.0",
    "deployment.environment": "production",
})

provider = TracerProvider(resource=resource)
provider.add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="http://otel-collector:4317", insecure=True))
)
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("llm-pipeline")

ここで重要なのは、service.name を固定することです。デプロイごとに揺れるとダッシュボードが分断され、比較分析ができません。

ステップ2：LLM処理を span で分割する

実運用では「遅い」の原因が retrieval なのか generation なのかで対応が変わります。そこで、処理を細かく span 化します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

from opentelemetry import trace
tracer = trace.get_tracer("llm-pipeline")

def generate_answer(query: str, user_id: str):
    with tracer.start_as_current_span("rag.pipeline") as root:
        root.set_attribute("user.id", user_id)
        root.set_attribute("feature", "support-chat")

        with tracer.start_as_current_span("rag.retrieve") as span_retrieve:
            docs = retrieve_docs(query)
            span_retrieve.set_attribute("retrieved.count", len(docs))

        with tracer.start_as_current_span("rag.rerank") as span_rerank:
            ranked = rerank_docs(query, docs)
            span_rerank.set_attribute("rerank.top_k", 5)

        with tracer.start_as_current_span("llm.generate") as span_gen:
            response = call_llm(query, ranked)
            span_gen.set_attribute("llm.model", response.model)
            span_gen.set_attribute("llm.input_tokens", response.usage.input_tokens)
            span_gen.set_attribute("llm.output_tokens", response.usage.output_tokens)
            span_gen.set_attribute("llm.temperature", 0.2)

        return response.text

この分割で、「retrieval が中央値 70ms → 280ms に悪化」「特定モデルだけ output token が急増」など、運用判断に直結する情報が取得できます。

ステップ3：コストをメトリクス化する

運用現場で最も効くのは、推定コストをリアルタイムに可視化することです。モデル単価表をコードに持ち、1リクエストごとに計算して metrics に送ります。

1
2
3
4
5
6
7
8

MODEL_PRICE = {
    "gpt-4.1-mini": {"in": 0.0000003, "out": 0.0000012},
    "gpt-4.1": {"in": 0.000003, "out": 0.000012},
}

def estimate_cost(model: str, in_tokens: int, out_tokens: int) -> float:
    p = MODEL_PRICE[model]
    return in_tokens * p["in"] + out_tokens * p["out"]

推奨は次の3指標です。

• llm_cost_usd_total（counter）
• llm_tokens_input_total / llm_tokens_output_total（counter）
• llm_latency_ms（histogram）

これを feature、tenant、model のラベルで集計すると、予算統制が一気に楽になります。

ステップ4：品質低下を検知する仕組みを入れる

レイテンシとコストだけでは不十分です。品質監視を最低限でも導入します。

4-1. 自動評価ジョブ

夜間バッチで固定データセット（100問程度）を流し、次を記録します。

• 正答率（正解文との semantic similarity）
• 出典一致率（回答が引用した文書IDの妥当性）
• 禁止事項違反率（PII、コンプラNG）

4-2. 本番フィードバック

UI で 👍 / 👎 を取り、trace_id と紐づけます。こうすると「悪評の大半が temperature=0.9 の実験フラグ経由」など、根因分析が可能です。

ステップ5：運用で効くダッシュボードを作る

実際に使われるダッシュボードは、項目を欲張らない方が強いです。最初は次の 6 つに絞ってください。

1. P50/P95 レイテンシ（全体 + モデル別）
2. リクエスト数とエラー率（HTTP + LLM例外）
3. 日次コスト（全体 + feature別）
4. input/output token 推移
5. retrieval 件数と空振り率
6. ユーザー評価（👍率）

特に P95 とコストは同一画面に置くのがポイントです。高速化で品質が落ちた、または品質改善でコストが跳ねた、というトレードオフが即時に見えます。

よくある失敗と回避策

失敗1：Prompt全文を生で保存して個人情報を漏らす

対策は、PII マスキングを export 前に必ず実行することです。メール、電話番号、住所は正規表現だけでなく、NER ベースで二重防御すると安全です。

失敗2：span属性の命名がバラバラ

llm.input_tokens と input_token_count が混在すると集計不能になります。命名規約をリポジトリに固定し、CI で lint してください。

失敗3：高カーディナリティ地獄

user_id をそのままメトリクスラベルに入れると TSDB が破綻します。ユーザー軸は trace/log に置き、metrics は tenant や plan 程度に抑えます。

導入ロードマップ（2週間）

• Day 1-2: FastAPI + LLM呼び出しに trace 埋め込み
• Day 3-4: token/cost メトリクス送信
• Day 5-6: Grafana ダッシュボード構築
• Day 7-9: しきい値アラート設計（P95、error、cost）
• Day 10-12: 品質評価バッチ導入
• Day 13-14: インシデント演習（意図的劣化を検知できるか）

2週間で「見える化」は十分達成できます。完璧を目指すより、まず計測可能にすることが重要です。

まとめ

LLM運用で本当に困るのは、失敗そのものではなく「失敗の理由が見えない」状態です。OpenTelemetry を使って retrieval、generation、token、cost、品質を一貫して観測できるようにすると、改善サイクルが回り始めます。

可観測性は守りではなく、開発速度を上げるための攻めの基盤です。まずは span を3つに分けるところから始めてください。それだけで、LLM運用の景色が大きく変わります。

はじめに

「この複雑なレポート作成、AIに丸投げできないだろうか？」 「ユーザーからの曖昧な指示を解釈して、コードを書き、テストし、デプロイまで自動化したい。」

AI、特に大規模言語モデル（LLM）の進化に触れたエンジニアなら、一度はこんな夢を描いたことがあるのではないでしょうか。しかし、ChatGPTのような単一のプロンプトで対話するモデルに複雑なタスクを依頼すると、途中で文脈を見失ったり、期待とは異なるアウトプットが出てきたりと、その限界に直面することも少なくありません。

ReAct（Reasoning and Acting）のようなフレームワークを用いてツールを使わせる「シングルエージェント」は大きな進歩でしたが、それでもなお、複雑で多段階のタスクを自律的にこなすには力不足でした。まるで、一人の優秀な新入社員に、いきなり会社の全業務を任せるようなものです。

もし、AIが一人ではなく、「専門家チーム」として協調して働いてくれたらどうでしょう？リサーチ担当、コーディング担当、レビュー担当、そしてプロジェクト全体を管理するマネージャー。それぞれが専門知識を持ち、互いにコミュニケーションを取りながら、一つの大きな目標に向かって自律的にタスクを遂行する。

本記事では、そんな未来を実現する技術として注目を集める**「マルチエージェント・システム」**について、その概念から具体的な実装方法までを深く掘り下げます。特に、この分野を牽引する2大フレームワーク、**Microsoftの「AutoGen」とLangChainの「LangGraph」**に焦点を当て、そのアーキテクチャ、実装のポイント、そして現場で活かすための実践的なTipsを、豊富なコード例とともに解説していきます。

この記事を読み終える頃には、あなたはシングルプロンプトの呪縛から解き放たれ、自律的なAIエージェントチームを編成するための確かな知識とインスピレーションを得ているはずです。

なぜ今、マルチエージェント・システムなのか？

LLMの能力が飛躍的に向上し、GPT-4oのようなマルチモーダル対応モデルが登場する中で、なぜわざわざ複数のエージェントを協調させる必要があるのでしょうか。その理由は、**「シングルエージェントの限界」と「タスクの複雑性への対応」**にあります。

シングルエージェントの限界

従来のシングルエージェントのアーキテクチャは、基本的に一つの「思考の連鎖（Chain of Thought）」に依存しています。これは、直線的な思考プロセスには強いものの、以下のような課題を抱えています。

1. 思考の硬直性: 一つの計画に固執し、途中で問題が発生しても柔軟に軌道修正するのが苦手です。複数の選択肢を並行して検討したり、第三者の視点でレビューしたりといった、人間が行うような複雑な意思決定が困難です。
2. コンテキストの肥大化: タスクが複雑になるほど、プロンプトに含めるべき情報（過去のやり取り、ツールの使用履歴、中間生成物）が増大します。これはAPIコストの増加、処理速度の低下、そしてLLMが重要な情報を見失う「Lost in the Middle」問題を引き起こします。
3. 責任範囲の曖昧さ: 一つのエージェントにあらゆる役割（計画、実行、検証、修正）を詰め込もうとすると、プロンプトが極めて複雑になり、かえって性能が低下します。各ステップで何をすべきかが曖昧になり、幻覚（ハルシネーション）のリスクも高まります。

人間の組織に学ぶ「専門化」と「協調」

これらの課題を解決するヒントは、私たち自身の社会、つまり「組織」にあります。優れた企業は、一人の天才が全てをこなすのではなく、営業、開発、マーケティング、品質管理といった専門部署が互いに連携・協調することで、複雑で大きな目標を達成します。

マルチエージェント・システムは、この組織論をAIの世界に持ち込むアプローチです。

• 専門化 (Specialization): 各エージェントに特定の役割と専門知識を与えます。「コードを書くのが得意なエージェント」「書かれたコードを厳しくレビューするエージェント」「ユーザーとの対話を受け持つエージェント」といったように、責任範囲を限定することで、各エージェントのプロンプトをシンプルかつ高性能に保てます。
• 協調 (Collaboration): エージェント同士がメッセージを交換し、対話することで、問題を解決します。例えば、コーディングエージェントが書いたコードをレビューエージェントがチェックし、修正点をフィードバックする。この対話のループを通じて、生成物の品質をスパイラル状に向上させることができます。
• 自律性 (Autonomy): 全体の目標が与えられると、エージェントチームは自律的にタスクを分解し、役割を分担し、協調してタスクを遂行します。これにより、人間がマイクロマネジメントする必要がなくなります。

このパラダイムシフトは、単なるAIの性能向上ではなく、AIによる問題解決の「方法論」そのものの進化と言えるでしょう。

具体的な解決策：AutoGenとLangGraphによる実装

それでは、実際にマルチエージェント・システムを構築するためのフレームワークを見ていきましょう。ここでは、特に人気の高いAutoGenとLangGraphを取り上げ、それぞれの思想と実装方法を解説します。

1. AutoGen：対話による自律的タスク解決

AutoGenは、Microsoft Researchが開発したフレームワークで、エージェント間の対話を中心に据えた設計が特徴です。複数のエージェント（ConversableAgent）を定義し、それらが互いにチャットを繰り返すことで、タスクが進行していきます。

AutoGenのアーキテクチャ

AutoGenの基本的な登場人物は以下の通りです。

• AssistantAgent: LLMを搭載した標準的なAIエージェント。与えられた役割（例：「あなたはPythonの専門家です」）に基づいて発言やコード生成を行います。
• UserProxyAgent: 人間の代理人として振る舞う特殊なエージェント。他のエージェントからコードを受け取ると、それを実際に実行しようと試みます。実行結果（成功、失敗、エラーメッセージ）を次のメッセージとして相手に返すことで、対話のループが生まれます。また、人間の入力を促し、介入（Human-in-the-Loop）を可能にします。
• GroupChatManager: 3体以上のエージェントが参加するグループチャットを管理し、次に誰が発言するかを制御します。

実装例：コード生成＆実行タスク

ここでは、「あるURLから株価データを取得し、それをプロットして画像ファイルとして保存する」というタスクを、2体のエージェントで解決する例を見てみましょう。

1. セットアップ

1

pip install "pyautogen[retrievechat]"

2. 設定ファイルの準備

プロジェクトのルートに OAI_CONFIG_LIST という名前でJSONファイルを作成し、APIキーを設定します。

1
2
3
4
5
6

[
    {
        "model": "gpt-4o",
        "api_key": "sk-..."
    }
]

3. Pythonコード

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

import autogen

# LLMの設定を読み込む
config_list = autogen.config_list_from_json("OAI_CONFIG_LIST")
llm_config = {"config_list": config_list}

# 1. アシスタントエージェント（コーダー）の定義
coder = autogen.AssistantAgent(
    name="Coder",
    llm_config=llm_config,
    system_message="あなたは優秀なPythonプログラマーです。Pythonコードを生成し、問題を解決します。コードは ```python ... ``` の中に記述してください。"
)

# 2. ユーザープロキシエージェント（コード実行者・人間の代理）の定義
user_proxy = autogen.UserProxyAgent(
    name="UserProxy",
    human_input_mode="NEVER",  # 人間の入力を介さず自動で進行
    max_consecutive_auto_reply=10,
    is_termination_msg=lambda x: x.get("content", "").rstrip().endswith("TERMINATE"),
    code_execution_config={
        "work_dir": "coding",  # コードを実行する作業ディレクトリ
        "use_docker": False,  # Dockerを使わない場合はFalse (True推奨)
    },
    system_message="あなたはコードの実行者です。Coderから提案されたコードを実行し、その結果を報告します。問題があればエラーを伝えてください。"
)

# タスクの定義と対話の開始
task = """
yfinanceとmatplotlibを使って、過去1年間のテスラ(TSLA)の株価を取得し、
終値を折れ線グラフでプロットしてください。
グラフは 'tsla_stock_price.png' という名前でファイルに保存してください。
"""

user_proxy.initiate_chat(
    coder,
    message=task
)

実行プロセスの解説

このコードを実行すると、user_proxyが最初のタスクをcoderに投げます。

1. coder: タスクを理解し、yfinanceとmatplotlibをインストールする必要があると考え、それらを使ったPythonコードを生成して返信します。
2. user_proxy: coderから受け取ったコードブロックを検出し、codingディレクトリ内でそのコードを実行します。
3. （成功した場合）: コードが正常に実行され、tsla_stock_price.pngが生成されます。user_proxyは実行結果（標準出力など）をcoderに報告します。
4. coder: 成功報告を受け、タスクが完了したと判断し、「TERMINATE」という終了キーワードを含むメッセージを返します。
5. user_proxy: 「TERMINATE」を検知し、対話を終了します。

もし途中でエラー（例：ライブラリがインストールされていない）が発生すれば、user_proxyはそのエラーメッセージをcoderに伝えます。するとcoderは「ライブラリをインストールしてください」といった修正案や、エラーを解決するための新しいコードを提案し、対話が続行されます。この試行錯誤のループこそが、AutoGenの強みです。

2. LangGraph：グラフによる状態遷移ワークフローの制御

LangGraphは、人気のLLMフレームワークLangChainから派生したライブラリで、状態遷移グラフ（Stateful Graphs）としてエージェントのワークフローを定義します。対話の自律性に重きを置くAutoGenとは対照的に、LangGraphはワークフローの制御性に優れています。

LangGraphのアーキテクチャ

LangGraphの中心的な概念は以下の通りです。

• State: グラフ全体で共有される状態オブジェクト。辞書やPydanticモデルで定義し、各ステップの出力がこのStateに蓄積されていきます。
• Nodes: グラフのノード（節点）。Python関数として定義され、それぞれが特定の処理（エージェントの呼び出し、ツールの実行など）を担当します。各ノードは現在のStateを受け取り、更新したStateの一部を返します。
• Edges: ノード間の繋がり（辺）。どのノードの次にどのノードを実行するかを定義します。
• Conditional Edges: 条件付きの辺。現在のStateに基づいて、次に進むべきノードを動的に決定します。これにより、ループや分岐を持つ複雑なワークフローが実現できます。

(出典: LangChain Blog)

実装例：リサーチタスクのワークフロー

ここでは、「あるテーマについてWebでリサーチし、複数の視点から記事を作成し、それをレビューして最終的なレポートを生成する」というワークフローをLangGraphで構築してみましょう。

1. セットアップ

1

pip install langgraph langchain langchain_openai duckduckgo-search

2. Pythonコード

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119

import os
from typing import TypedDict, Annotated, List
from langchain_core.messages import BaseMessage
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, END
from langchain_community.tools import DuckDuckGoSearchRun

# 環境変数にAPIキーを設定
# os.environ["OPENAI_API_KEY"] = "YOUR_API_KEY"

# ツール（Web検索）の準備
search_tool = DuckDuckGoSearchRun()

# LLMモデルの定義
model = ChatOpenAI(temperature=0, model="gpt-4o")

# --- 1. グラフの状態 (State) を定義 ---
class AgentState(TypedDict):
    topic: str
    search_results: str
    draft: str
    review: str
    revision_count: int

# --- 2. グラフのノード (Nodes) を定義 ---

# リサーチャーエージェント
def researcher_node(state: AgentState):
    print("--- ノード: Researcher ---")
    topic = state["topic"]
    # LLMに検索クエリを考えさせる
    query_generation_prompt = f"「{topic}」について調査するための、効果的な検索クエリを3つ考えてください。"
    query_response = model.invoke(query_generation_prompt)
    queries = query_response.content.strip().split('\n')
    
    results = ""
    for query in queries:
        print(f"検索中: {query}")
        results += search_tool.run(query) + "\n\n"
        
    return {"search_results": results}

# ライターエージェント
def writer_node(state: AgentState):
    print("--- ノード: Writer ---")
    topic = state["topic"]
    search_results = state["search_results"]
    prompt = f"""
    以下の検索結果を基に、「{topic}」に関するブログ記事のドラフトを作成してください。
    
    検索結果:
    {search_results}
    """
    draft = model.invoke(prompt).content
    return {"draft": draft}

# レビューアーエージェント
def reviewer_node(state: AgentState):
    print("--- ノード: Reviewer ---")
    topic = state["topic"]
    draft = state["draft"]
    prompt = f"""
    あなたは優秀な編集者です。以下の「{topic}」に関するブログ記事のドラフトをレビューしてください。
    改善点があれば具体的に指摘し、問題がなければ「PERFECT」とだけ回答してください。
    
    ドラフト:
    {draft}
    """
    review = model.invoke(prompt).content
    revision_count = state.get("revision_count", 0) + 1
    return {"review": review, "revision_count": revision_count}

# --- 3. 条件付きの辺 (Conditional Edge) を定義 ---
def should_continue(state: AgentState):
    print("--- 条件分岐 ---")
    if state["revision_count"] > 3:
        print("最大修正回数に達しました。")
        return "end"
    if "PERFECT" in state["review"]:
        print("レビューをパスしました。")
        return "end"
    else:
        print("修正が必要です。")
        return "continue"

# --- 4. グラフを構築 ---
workflow = StateGraph(AgentState)

# ノードを追加
workflow.add_node("researcher", researcher_node)
workflow.add_node("writer", writer_node)
workflow.add_node("reviewer", reviewer_node)

# エッジを追加
workflow.set_entry_point("researcher")
workflow.add_edge("researcher", "writer")
workflow.add_edge("writer", "reviewer")

# 条件付きエッジを追加
workflow.add_conditional_edges(
    "reviewer",
    should_continue,
    {
        "continue": "writer", # 修正が必要ならライターに戻る
        "end": END
    }
)

# グラフをコンパイル
app = workflow.compile()

# --- 5. グラフを実行 ---
inputs = {"topic": "2024年の生成AIのトレンド", "revision_count": 0}
for output in app.stream(inputs):
    for key, value in output.items():
        print(f"ノード '{key}' の出力:")
        print("---")
        print(value)
    print("\n" + "="*30 + "\n")

実行プロセスの解説

このコードは、以下のような明確なワークフローを実行します。

1. researcher: 与えられたトピックに基づいてWeb検索を実行し、結果をStateに保存します。
2. writer: researcherが収集した情報をもとに、記事のドラフトを作成し、Stateに保存します。
3. reviewer: writerが書いたドラフトをレビューします。
4. should_continue (条件分岐):
   • レビュー結果が「PERFECT」なら、ワークフローは終了（END）します。
   • 修正点があれば、writerノードに処理を戻し、ドラフトの修正を促します（ループ）。
   • ループが3回を超えた場合も、無限ループを避けるために処理を終了します。

このように、LangGraphは処理の流れを明示的にグラフとして定義するため、デバッグが容易で、ビジネスロジックのような複雑なフローを堅牢に実装するのに適しています。

メリットとデメリット、そしてツールの比較

マルチエージェント・システムは強力ですが、銀の弾丸ではありません。導入にあたっては、その利点と課題を理解することが重要です。

マルチエージェント・システムのメリット

• 高度な問題解決能力: 複雑なタスクを専門家チームのように分業・協調して解決できる。
• 堅牢性と自己修正: レビューやフィードバックのループを組み込むことで、生成物の品質を向上させ、エラーから自律的に回復できる。
• モジュール性と拡張性: 新しい役割を持つエージェントをノードや対話者として追加するのが比較的容易。
• プロセスの透明性: エージェント間の対話ログや状態遷移を追跡することで、AIが「どのように」その結論に至ったのかを理解しやすくなる。

マルチエージェント・システムのデメリットと課題

• 設計の複雑性: どのような役割のエージェントが必要か、どのようなワークフローや対話プロトコルを設計するかが成功の鍵となり、高度な設計能力が求められる。
• 制御の難しさ: 特に自律性の高いシステムでは、エージェントが無限ループに陥ったり、意図しない方向にタスクを進めたりするリスクがある。
• コストの増加: 複数のエージェントが何度もLLM APIを呼び出すため、シングルエージェントに比べてトークン消費量とコストが大幅に増加する可能性がある。
• レイテンシーの増大: エージェント間の通信やLLMの呼び出しが重なるため、最終的な結果を得るまでの時間が長くなる傾向がある。

LangGraph vs AutoGen：どちらを選ぶべきか？

結論として、「厳密なワークフローを構築したいならLangGraph」「エージェントの自律的な協調に任せてみたいならAutoGen」という使い分けが考えられます。

現場で使える実践的なTips

マルチエージェント・システムを本番環境で運用するには、いくつかの工夫が必要です。

1. スモールスタートを心がける: 最初から10体のエージェントチームを作るのではなく、まずは2〜3体のコアな役割のエージェントから始め、徐々に拡張していきましょう。
2. 役割（Role）のプロンプトを磨き込む: 各エージェントのsystem_messageは、その性能を決定づける最も重要な要素です。「あなたは何者で、何が得意で、何をしてはいけないのか」を可能な限り明確に定義してください。
3. 強力なマネージャー/オーケストレーターを置く: LangGraphのグラフ定義そのものや、複数のエージェントを統括するマネージャーエージェントの設計は非常に重要です。タスクの分解、進行管理、最終的な成果物の統合といった役割を担わせましょう。
4. コスト管理戦略を立てる:
   • モデルの使い分け: 簡単なタスク（要約、分類など）には安価なモデル（例: GPT-3.5 Turbo, Claude 3 Sonnet）を使い、高度な推論やコーディングが必要な場面では高性能モデル（例: GPT-4o, Claude 3 Opus）を使うハイブリッド構成を検討します。
   • サーキットブレーカー: APIコールの回数や対話のターン数に上限を設け、無限ループによるコスト増大を防ぎます。LangGraphの例で示したrevision_countがこれにあたります。
5. 人間参加のループ (Human-in-the-Loop) を組み込む: 全てを自動化するのではなく、重要な意思決定ポイント（例：生成したコードの実行前、顧客へのメール送信前）では、必ず人間の承認を求めるステップをワークフローに組み込みましょう。AutoGenのUserProxyAgentは、このための優れた仕組みを提供しています。
6. ロギングとトレーサビリティ: エージェント間の全てのやり取りや状態の変化を詳細にログとして記録します。LangSmithのようなツールを使うと、複雑なエージェントの挙動を可視化し、デバッグを大幅に効率化できます。

まとめ

私たちは今、AI開発における大きな転換点に立っています。単一のLLMに完璧な答えを求める「シングルプロンプトの時代」は終わりを告げ、多様な能力を持つAIエージェントが協調して複雑な問題を解決する**「マルチエージェント協調の時代」**が幕を開けようとしています。

この記事では、その中核技術であるマルチエージェント・システムの概念と、それを実現するAutoGenとLangGraphという二つの強力なフレームワークについて解説しました。

• AutoGenは、エージェント間の「対話」を通じて、自己修正的なループを生み出し、探索的なタスクを自律的に解決します。
• LangGraphは、「状態遷移グラフ」としてワークフローを明示的に定義することで、複雑なビジネスプロセスを堅牢かつ制御可能に実装します。

これらの技術は、まだ発展途上であり、コストや制御性の面で課題も残されています。しかし、そのポテンシャルは計り知れません。もはや私たちの仕事は、単に賢いAIを一つ作ることではなく、いかにして「優秀なAIチーム」を設計し、編成し、マネジメントするかという、より高度な次元へとシフトしています。

2026年に向けて、この流れはさらに加速していくでしょう。ぜひ、この記事をきっかけに、まずは簡単な2エージェントシステムから、あなたの身の回りの課題解決に挑戦してみてください。そこに、次世代のAIアプリケーション開発の未来が広がっているはずです。

皆さん、こんにちは！テクノロジーの進化は本当に早いもので、Googleから最新のAIモデル「Gemini 3.1 Pro」が正式に発表されました。

このニュースは世界中のエンジニアを驚かせており、テック系コミュニティの聖地とも言えるHacker Newsでは、投稿からわずか数時間で882ポイントという異例の高評価を獲得しました。これほどまでに注目されているのは、単なるスペックアップを超えた「実用性の進化」があるからです。

「AIの進化が早すぎて追いつけない……」と感じている初心者エンジニアの方も多いかもしれませんが、安心してください。この記事では、Gemini 3.1 Proの何がすごいのか、そして今日からどうやって使いこなすのかを、どこよりも噛み砕いて解説します！

Gemini 3.1 Proとは？

Gemini 3.1 Proは、Googleが開発した「Gemini」シリーズの最新鋭モデルです。従来のGemini 3の長所を引き継ぎつつ、特に「推論（考える力）」と「文脈の理解（記憶力）」が大幅に強化されています。

エンジニアにとってのGemini 3.1 Proは、例えるなら**「プロジェクトの全コードを記憶し、複雑なバグの修正案を即座に提案してくれる、超優秀な先輩エンジニア」**のような存在です。

なぜ「Pro」なのか？

Googleのモデルには「Ultra」「Pro」「Flash」などのラインナップがありますが、Proモデルは「性能」と「コスト・速度」のバランスが最も優れています。開発者がAPIを使ってアプリケーションに組み込む際、最も選ばれているのがこのProシリーズなのです。

ここがすごい！Gemini 3.1 Proの3つの進化点

従来のモデルと比べて、具体的にどこが変わったのでしょうか？注目すべき3つのポイントを挙げます。

1. 「熟考型」の推論プロセス

Gemini 3.1 Proには、人間が難しい問題を解くときにじっくり考えるような「System 2 Thinking」に近い仕組みが導入されました。これにより、これまでは間違えやすかった複雑な数学の問題や、高度な論理パズル、さらには大規模なシステムのデバッグにおいて、圧倒的に正確な回答を返せるようになっています。

2. 200万トークンの超長大コンテキスト

「トークン」とは、AIが一度に扱える情報の単位です。Gemini 3.1 Proは、最大で200万トークンという驚異的な量を一度に読み込むことができます。 これは、「厚辞苑数冊分のテキスト」や「数万行のソースコード全体」を丸ごとAIに読み込ませて、その内容について質問できることを意味します。「あの関数の定義、どこにあったっけ？」と探す手間は、もう過去のものになるかもしれません。

3. ハルシネーション（もっともらしい嘘）の劇的な減少

AIが自信満々に嘘をつく現象「ハルシネーション」が、Gemini 3.1 Proでは大幅に抑えられています。特に関数呼び出し（Function Calling）の正確性が増しており、外部ツールやデータベースと連携させた際の信頼性が向上しました。

【実践】PythonでGemini 3.1 Proを動かしてみよう

それでは、実際にAPIを使ってGemini 3.1 Proを操作してみましょう。初心者の方でも、以下の3ステップで簡単に始められます。

1. ライブラリの準備

ターミナルで以下のコマンドを実行し、最新のSDKをインストールします。

1

pip install -U google-generativeai

はじめに

「自社の膨大なマニュアルやナレッジベースの内容を、ChatGPTのように対話形式で手軽に引き出したい」 「開発中のAIチャットボットに、社内規定や顧客との過去のやり取りを正確に回答させたい」 「でも、機密情報を含む自社データを、外部のAIサービスに学習データとして渡すのはセキュリティ的に絶対に避けたい」

AI、特に大規模言語モデル（LLM）の活用を検討する多くのエンジニアや開発担当者が、このような課題に直面しているのではないでしょうか。LLMは非常に強力ですが、その知識は特定の時点までのものであり、自社の独自データについては何も知りません。

この課題を解決するために「ファインチューニング」を検討するかもしれません。しかし、ファインチューニングには大量の教師データと高い計算コストが必要な上、情報の更新があるたびにモデルを再学習させるのは現実的ではありません。さらに、AIがもっともらしい嘘をつく「ハルシネーション」という問題も依然として残ります。

本記事では、これらの課題をエレガントに解決する技術として、今、AIエージェント開発の現場でデファクトスタンダードとなりつつある**RAG（Retrieval-Augmented Generation：検索拡張生成）**というアプローチを徹底的に解説します。

RAGは、LLMに自社データを「学習」させるのではなく、必要な情報を「検索」して外部から与えることで、LLMの能力を最大限に引き出す画期的な手法です。そして、その中核を担うのが**Vector DB（ベクトルデータベース）**です。

この記事を読み終える頃には、あなたは以下のことを理解し、自社のAIエージェント開発に活かすための一歩を踏み出せるようになっているはずです。

• LLMが抱える根本的な課題（知識のカットオフ、ハルシネーション）
• なぜファインチューニングだけでは不十分なのか
• RAGがどのようにしてこれらの課題を解決するのか、その具体的な仕組み
• RAGの心臓部であるEmbeddingとVector DBの役割
• PythonとLangChainを使ったRAGの基本的な実装方法

それでは、AIエージェント開発の新たな扉を開く、RAGとVector DBの世界へご案内します。

なぜRAGとVector DBが重要なのか？ LLMの限界と従来の課題

RAGの重要性を理解するためには、まずLLMが単体で抱える限界を知る必要があります。

LLMが抱える3つの大きな壁

1. 知識のカットオフ（Knowledge Cut-off） GPT-4のような最先端のLLMでさえ、その知識は学習データが収集された特定の日時で止まっています。例えば、GPT-4の初期モデルは2021年9月までの情報しか持っていません。そのため、それ以降の出来事や、新製品の情報、最新の社内規定について質問しても、答えることができません。ビジネスの世界では情報の鮮度が命であり、この「知識の壁」は致命的な欠点となります。

2. ハルシネーション（Hallucination：幻覚） LLMは、事実に基づかない情報を、あたかも真実であるかのように生成することがあります。これをハルシネーションと呼びます。特に、学習データに含まれていない専門的な内容や、社内情報のようなクローズドなドメインについて質問された場合に、この現象は顕著になります。顧客サポート用のAIが誤った製品情報を伝えたり、社内アシスタントが架空の規定を案内したりする事態は、企業の信頼を著しく損なうリスクをはらんでいます。

3. 情報セキュリティとプライバシー 自社の機密情報や顧客の個人情報を扱う場合、それらを外部のLLM提供企業のサーバーに学習データとしてアップロードすることには、非常に大きなセキュリティリスクが伴います。一度学習データとして取り込まれてしまうと、他のユーザーへの回答に利用されてしまう可能性もゼロではなく、データのコントロールを失うことになります。

従来の解決策「ファインチューニング」とその限界

これらの課題を解決するアプローチとして、以前は「ファインチューニング」が主流でした。これは、既存の学習済みモデルに対して、自社データを含む追加の教師データセットを与えて再学習させる手法です。

ファインチューニングは、LLMに特定の文体や口調を真似させたり、特定のタスク（例えば、要約や感情分析）への性能を特化させたりするのには有効です。しかし、「知識を注入する」という目的においては、いくつかの大きな課題があります。

• 高いコスト: ファインチューニングには、大量の高品質な教師データ（質問と回答のペアなど）の準備と、モデルの学習を実行するための高価な計算リソース（GPU）が必要です。
• 知識の更新が困難: 新しい情報（例えば、週次レポートや新しいマニュアル）を追加したい場合、その都度ファインチューニングをやり直す必要があります。これは時間的にも金銭的にも非効率です。
• 透明性の欠如: ファインチューニングされたモデルが、なぜその回答を生成したのか、どの情報を根拠にしているのかを追跡することは非常に困難です。ハルシネーションが起きた場合の原因究明も難しくなります。

そこで登場したのが、**RAG（検索拡張生成）**です。RAGは「学習」ではなく「検索」というアプローチで、これらの問題を根本から解決します。

具体的な解決策：RAGの仕組みとVector DBの役割

RAGは、その名の通り「検索（Retrieval）」でLLMの知識を「拡張（Augmented）」し、回答を「生成（Generation）」するアーキテクチャです。LLMを「非常に優秀だが記憶喪失のコンサルタント」、Vector DBを「完璧な記憶力を持つ外部の専門図書館」に例えると分かりやすいでしょう。

コンサルタント（LLM）は、質問を受けるたびに、まず図書館（Vector DB）へ行って関連資料を調べ（検索）、その資料を読み込みながら（コンテキストとしてプロンプトに含める）、質問に対する的確な回答を生成します。

この仕組みにより、LLMは常に最新かつ正確な情報に基づいて回答できるようになり、ハルシネーションを劇的に抑制できます。

RAGの全体像と処理フロー

RAGのシステムは、大きく2つのフェーズに分かれています。

1. データ準備フェーズ（Indexing）: 事前に自社ドキュメントを検索可能な状態にして、Vector DBに保存しておくフェーズ。
2. 実行フェーズ（Retrieval & Generation）: ユーザーからの質問を受け取り、Vector DBから関連情報を検索して、LLMが回答を生成するフェーズ。

この流れを図で示すと以下のようになります。

graph TD
    subgraph "データ準備フェーズ（Indexing）"
        A[ドキュメント群<br>PDF, TXT, Markdown, etc.] --> B(Load<br>ドキュメント読み込み);
        B --> C(Split<br>テキストを適切なサイズに分割);
        C --> D(Embed<br>分割したテキストをベクトル化);
        D --> E[Vector DB<br>ベクトルと元のテキストを保存];
    end

    subgraph "実行フェーズ（Retrieval & Generation）"
        F[ユーザーからの質問] --> G(Embed<br>質問をベクトル化);
        G --> H{Vector DB<br>類似ベクトル検索};
        E --> H;
        H --> I[関連性の高い<br>テキストチャンク（コンテキスト）];
        F & I --> J(Prompt<br>質問とコンテキストを結合し<br>プロンプトを作成);
        J --> K[LLM (e.g., GPT-4)<br>回答生成];
        K --> L[ユーザーへの回答];
    end

それでは、このフローの各要素を詳しく見ていきましょう。

構成要素①: Embedding - テキストを「意味」のベクトルに変換する魔法

RAGを理解する上で最も重要な概念が**Embedding（エンベディング、埋め込み）**です。

人間は「犬」と「猫」が似ていて、「犬」と「車」はあまり似ていないことを直感的に理解できます。しかし、コンピュータは単なる文字の羅列としてしか認識できません。Embeddingは、この「意味の近さ」をコンピュータが扱えるように、テキストを高次元のベクトル（数値の配列）に変換する技術です。

例えば、以下のように変換されます（次元数は簡略化しています）。

• 犬: [0.8, 0.1, 0.3, ...]
• 猫: [0.7, 0.2, 0.4, ...]
• 車: [-0.5, 0.9, -0.1, ...]

このベクトル空間上では、意味的に近い単語や文章は、その距離も近くなります。OpenAIのtext-embedding-ada-002（1536次元）や、様々なオープンソースのモデルがこの変換を行うために利用されます。

RAGでは、事前にドキュメントの各部分（チャンク）をベクトル化しておき、ユーザーの質問も同じモデルでベクトル化します。そして、質問のベクトルと最も近いベクトルを持つドキュメントチャンクを探すことで、質問に最も関連性の高い情報を特定するのです。

構成要素②: Vector DB - 意味で検索する次世代のデータベース

Embeddingによって得られた大量のベクトルデータを効率的に保存し、高速に「意味の近さ（類似度）」で検索するための専用データベースがVector DBです。

従来のRDB（リレーショナルデータベース）がWHERE user_id = 123のように完全一致でデータを検索するのに対し、Vector DBは「このベクトルに最も近いベクトルを探して」という**近似最近傍探索（Approximate Nearest Neighbor, ANN）**を得意とします。

代表的なVector DBには以下のようなものがあります。

• Chroma: ローカル環境で手軽に試せるオープンソースのVector DB。プロトタイピングに最適。
• FAISS: Facebook (Meta) AIが開発した、ベクトル類似検索に特化したライブラリ。
• Pinecone, Weaviate, Qdrant: クラウドネイティブなマネージドサービスとして提供されることが多く、スケーラビリティや高度な機能（メタデータフィルタリングなど）が特徴。

Vector DBは、ベクトル化されたドキュメントチャンクと、その元となったテキスト本文のペアを保存します。検索時には、質問ベクトルに類似したベクトルを持つチャンクを複数個見つけ出し、その元テキストをLLMへのコンテキストとして渡します。

RAGの実装ステップ（PythonとLangChainによるコード例）

それでは、実際にPythonのフレームワークLangChainを使って、簡単なRAGシステムを構築してみましょう。LangChainは、LLMアプリケーション開発における一連の流れを抽象化し、簡単に実装できるようにしてくれる便利なツールです。

ここでは、架空の「社内副業規定.pdf」というドキュメントの内容について回答するAIエージェントを作成します。

前提: PDFファイルinternal_rules.pdfが手元にあるとします。内容は以下のようなものです。

第5条（副業・兼業）

1. 社員は、会社の許可を得た上で、副業または兼業を行うことができる。
2. 副業を希望する社員は、所定の申請書を人事部に提出し、事前の承認を得なければならない。
3. 会社の競合他社での業務や、会社の信用を損なう可能性のある業務は許可されない。

ステップ1: 環境構築と準備

まず、必要なライブラリをインストールし、OpenAIのAPIキーを設定します。

1

pip install langchain openai chromadb pypdf tiktoken

1
2
3
4

import os

# 環境変数にOPENAI_API_KEYを設定
os.environ["OPENAI_API_KEY"] = "YOUR_OPENAI_API_KEY"

ステップ2: ドキュメントの読み込み (Load)

LangChainのPyPDFLoaderを使って、PDFファイルを読み込みます。

1
2
3
4
5
6
7

from langchain.document_loaders import PyPDFLoader

loader = PyPDFLoader("internal_rules.pdf")
documents = loader.load()

print(f"ドキュメントを {len(documents)} ページ読み込みました。")
# 出力例: ドキュメントを 1 ページ読み込みました。

ステップ3: テキストの分割 (Split/Chunking)

LLMが一度に処理できるテキスト量（コンテキストウィンドウ）には限りがあるため、また、検索精度を向上させるために、読み込んだドキュメントを小さなチャンクに分割します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

from langchain.text_splitter import RecursiveCharacterTextSplitter

# テキスト分割の設定
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,  # チャンクの最大文字数
    chunk_overlap=50   # チャンク間のオーバーラップ文字数
)

# 分割の実行
split_docs = text_splitter.split_documents(documents)

print(f"ドキュメントを {len(split_docs)} 個のチャンクに分割しました。")
# 出力例: ドキュメントを 3 個のチャンクに分割しました。

chunk_sizeとchunk_overlapはRAGの性能を左右する重要なパラメータです。chunk_overlapを設けることで、文の途中でチャンクが分断され、文脈が失われるのを防ぎます。

ステップ4: EmbeddingとVector DBへの保存 (Embed & Store)

分割したチャンクをEmbeddingモデルでベクトル化し、Chroma DBに保存します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

from langchain.embeddings.openai import OpenAIEmbeddings
from langchain.vectorstores import Chroma

# Embeddingモデルのインスタンス化
embeddings = OpenAIEmbeddings()

# Chroma DBにドキュメントを読み込み、ベクトル化して保存
# persist_directoryを指定すると、DBがディスクに永続化される
vectordb = Chroma.from_documents(
    documents=split_docs,
    embedding=embeddings,
    persist_directory="./chroma_db"
)

print("Vector DBの準備が完了しました。")

このコードを実行すると、./chroma_dbというディレクトリが作成され、ベクトルデータが保存されます。

ステップ5: 検索と生成 (Retrieve & Generate)

いよいよ、作成したVector DBを使って質問応答チェーンを構築し、実際に質問をしてみます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

from langchain.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA

# LLMモデルのインスタンス化
llm = ChatOpenAI(model_name="gpt-4", temperature=0)

# Vector DBをRetriever（検索機）として使用するQAチェーンを作成
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",  # 最もシンプルなチェーンタイプ
    retriever=vectordb.as_retriever()
)

# 質問を実行
question = "社員が副業を始めるには、どのような手続きが必要ですか？"
response = qa_chain.run(question)

print(f"質問: {question}")
print(f"回答: {response}")

実行結果の例:

質問: 社員が副業を始めるには、どのような手続きが必要ですか？
回答: 社員が副業を始めるには、所定の申請書を人事部に提出し、事前の承認を得る必要があります。

見事に、PDFの内容に基づいた正確な回答が生成されました。これはLLMが元々持っていた知識ではなく、私たちがVector DB経由で提供した情報に基づいています。これがRAGの力です。

RAGのメリットとデメリット

RAGは非常に強力な技術ですが、万能ではありません。そのメリットとデメリットを正しく理解し、ファインチューニングとの使い分けを考えることが重要です。

RAGのメリット

1. ハルシネーションの劇的な抑制: LLMは与えられたコンテキスト（検索結果）に基づいて回答を生成するため、事実に基づかない情報を捏造する可能性が大幅に低下します。
2. 知識の更新が容易かつ低コスト: 新しい情報やドキュメントの更新があった場合、モデル全体を再学習する必要はありません。Vector DB内の該当データを追加・更新するだけで、即座に知識を最新の状態に保てます。
3. 透明性と解釈可能性: RAGシステムでは、LLMがどのドキュメントチャンクを参考にして回答を生成したのかを追跡できます。これにより、ユーザーに出典を提示することが可能となり、回答の信頼性が向上します。
4. 高いセキュリティ: 自社の機密情報を外部のLLMに学習させる必要がありません。データは自社で管理するVector DB内に保持し、実行時に必要な情報だけをプロンプトの一部としてLLMに渡すため、データ漏洩のリスクを最小限に抑えられます。

RAGのデメリットと課題

1. 検索精度への依存: RAGの性能は、検索コンポーネントの精度に大きく依存します。ユーザーの質問に対して関連性の低いドキュメントしか検索できなかった場合、当然ながら回答の質も低くなります（Garbage In, Garbage Out）。
2. Chunking戦略の難しさ: テキストをどのように分割するか（chunk_size、chunk_overlap、分割単位など）は、試行錯誤が必要な職人芸的な側面があります。ドキュメントの構造を無視した不適切なChunkingは、検索精度を著しく低下させます。
3. システム構成の複雑化: LLM単体で完結せず、データローダー、テキストスプリッター、Embeddingモデル、Vector DBなど、複数のコンポーネントを組み合わせたパイプラインを構築・運用する必要があります。
4. レイテンシの増加: ユーザーからのリクエストごとに「検索」というステップが挟まるため、LLM APIを直接呼び出す場合に比べて、応答に時間がかかる可能性があります。

RAG vs ファインチューニング：どちらを選ぶべきか？

RAGとファインチューニングは対立するものではなく、補完関係にあります。目的によって使い分けるのが賢明です。

使い分けの指針:

• 事実に基づいた正確な知識を扱いたい場合は、まずRAGを検討します。
• LLMの**振る舞い（口調、文体、思考プロセス）**を特定の形に変えたい場合は、ファインチューニングが有効です。
• 両方を組み合わせる、つまりファインチューニングしたモデルをRAGの生成器（Generator）として使用することで、特定のスタイルで、かつ正確な情報に基づいた回答を生成する、という高度なアプローチも可能です。

現場で使える実践的なTips

基本的なRAGの実装は比較的簡単ですが、実運用で高い性能を出すためにはいくつかの工夫が必要です。

1. 高度なChunking戦略: 単純な固定長分割ではなく、ドキュメントの構造を活かしましょう。MarkdownであればMarkdownHeaderTextSplitter、ソースコードであればCodeSplitterなど、LangChainには様々なスプリッターが用意されています。これにより、意味のあるまとまりでテキストを分割でき、検索精度が向上します。

2. Embeddingモデルの選定: OpenAIのモデルは高性能ですが、コストがかかります。Hugging Faceで公開されているオープンソースのモデル（例: intfloat/multilingual-e5-largeなど日本語性能が高いもの）をセルフホストすることで、コストを抑えつつ、特定のドメインに特化した性能を得られる場合があります。

3. ハイブリッド検索（Hybrid Search）: Vector Search（意味検索）は万能ではありません。特定の製品名や型番、人名といった固有名詞を含むクエリには、従来のキーワード検索（BM25アルゴリズムなど）の方が強い場合があります。この2つを組み合わせたハイブリッド検索を実装することで、検索の網羅性と精度を両立させることができます。多くのマネージドVector DBサービスがこの機能を提供しています。

4. Retrieverのチューニング:

   • 検索ドキュメント数（k）の調整: retriever=vectordb.as_retriever(search_kwargs={"k": 5}) のように、一度に検索するチャンク数を調整します。多すぎるとノイズが増え、少なすぎると必要な情報が欠落します。
   • Re-ranking: 最初に多めにチャンクを検索（例: k=20）し、その後、より軽量で高速なCross-Encoderモデルなどを使って、質問との関連性を再計算し、上位のチャンク（例: top 5）だけをLLMに渡す手法です。ノイズを減らし、コンテキストの質を高めるのに非常に有効です。

5. メタデータフィルタリング: ドキュメントをVector DBに保存する際に、作成日、カテゴリ、著者などのメタデータを一緒に格納します。これにより、「2024年以降に作成された、“技術部"カテゴリのドキュメントの中から検索する」といった、より高度な絞り込み検索が可能になります。これは実用的なアプリケーションを構築する上で必須の機能です。

まとめ

本記事では、AIエージェント開発における必須知識として、RAG（検索拡張生成）と、その中核をなすVector DBの基礎について、仕組みから具体的な実装例、実践的なTipsまでを網羅的に解説しました。

RAGは、LLMに自社のデータを「学習」させるのではなく、必要な情報をリアルタイムに「検索」して与えることで、LLMの持つハルシネーションや知識の陳腐化といった課題を解決し、ビジネスの現場で安全かつ効果的に活用するための強力なパラダイムです。

その心臓部であるEmbeddingとVector DBは、非構造化データであるテキストを「意味」で扱えるようにする革新的な技術であり、これからのAIアプリケーション開発においてますます重要性を増していくでしょう。

今日学んだことをまとめると、以下のようになります。

• LLMの限界を克服するため、RAGは「検索」と「生成」を組み合わせる。
• Embeddingがテキストを意味的ベクトルに変換し、Vector DBがそれを高速に検索する。
• LangChainのようなフレームワークを使えば、RAGパイプラインを効率的に構築できる。
• RAGは知識の注入に、ファインチューニングは振る舞いの調整に適している。
• 実用的な性能を出すには、Chunking、Hybrid Search、Re-rankingなどの高度なテクニックが鍵となる。

RAGはまだ発展途上の技術であり、日々新しい手法が提案されています。しかし、本記事で解説した基礎をしっかりと理解していれば、その進化にキャッチアップしていくことは十分に可能です。

まずは、あなた自身のPCで、身近なドキュメントを使って小さなRAGシステムを構築してみてください。自分のデータに基づいてAIが的確な回答を生成する体験は、きっと新たなインスピレーションを与えてくれるはずです。この記事が、あなたのAIエージェント開発の第一歩となることを願っています。