LangChainによるAIエージェント開発とPythonでのプロンプト管理

LangChain開発の「動く」を「使える」に変える評価指標とPython実装ガイド

この記事は急速に進化する技術について解説しています。最新情報は公式ドキュメントをご確認ください。

2026年2月26日更新 2026年3月20日約11分で読めます

文字サイズ:

LangChain開発の「動く」を「使える」に変える評価指標とPython実装ガイド

なぜ多くのAIエージェントは「動く」のに「使えない」のか？

「デモ環境では完璧に動いていたのに、本番データを入れた途端に使い物にならなくなった」

AI開発の現場で、これほど頻繁に耳にする嘆きはありません。特にLangChainを用いてReAct（Reasoning and Acting）パターンのエージェントを構築する場合、このギャップは顕著に現れます。

実務の現場において、PoC（概念実証）で止まってしまうプロジェクトの多くは、この「評価基準の曖昧さ」に起因する傾向があります。

機能要件と非機能要件のギャップ

従来のシステム開発であれば、テストコードを書いて assert result == expected が通れば合格でした。しかし、LLM（大規模言語モデル）は確率的に挙動が決まるため、同じ入力でも出力が変わることがあります。

さらに厄介なのが、AIエージェント特有の複雑さです。単なるチャットボット（一問一答）とは異なり、エージェントは「思考（Thought）→ 行動（Action）→ 観察（Observation）」というループを自律的に回します。このプロセスのどこかで一つでも判断を誤ると、最終的なアウトプットは大きく崩れてしまいます。

チャットボット: ユーザーの質問に答えるだけ（評価対象は回答のみ）
エージェント: ツールを選び、引数を生成し、結果を解釈して次の行動を決める（評価対象はプロセス全体）

多くの開発現場では「なんとなく良さそうな回答が返ってきた」という主観的な感覚で開発を進めてしまいがちですが、これでは本番環境で発生するコーナーケース（稀なケース）やハルシネーション（もっともらしい嘘）に対応できません。

「なんとなく良さそう」が招く本番トラブルのリスク

定量的な合格ラインを持たずにデプロイすることは、目隠しをして高速道路を走るようなものです。例えば、RAG（検索拡張生成）システムにおいて、検索結果に正解が含まれているのにLLMがそれを無視して回答を作成してしまうケースや、逆に検索結果が的外れなのにLLMが自信満々に嘘をつくケースがあります。

これらを防ぐためには、エンジニアリングの視点で「品質を数値化」し、コードベースで管理する必要があります。本記事では、曖昧な「良さそう」を確実な「使える」に変えるための、具体的なKPI設計と実装手法について体系的に解説します。

AIエージェントの成功を測定する3次元KPIフレームワーク

AIエージェントを評価する際、単一の指標（例えば正答率だけ）を見るのは不十分です。AI導入を成功に導くためには、実行品質、効率性、堅牢性という「3次元のKPIフレームワーク」の活用が有効です。

1. 実行品質（Accuracy / Faithfulness）

ユーザーが求める回答を正しく返せているか、という最も基本的な指標です。しかし、LLMにおいては「正しさ」を分解する必要があります。

Faithfulness（忠実性）: 生成された回答が、与えられたコンテキスト（検索結果など）に忠実に基づいているか。コンテキストにない情報を勝手に捏造していないかを測ります。
Answer Relevance（回答の関連性）: ユーザーの質問に対して、的確に答えているか。見当違いな回答をしていないかを測ります。
Context Precision（コンテキスト適合率）: RAGにおいて、検索システムが上位に持ってきたドキュメントの中に、本当に必要な情報が含まれているかを確認します。

2. 効率性（Latency / Token Cost）

ビジネスで利用する以上、コストと速度は無視できません。特にGPT-4のような高性能モデルを使用する場合、エージェントが思考ループを繰り返すたびにトークン課金が発生します。

Latency（応答速度）: ユーザーが質問してから回答が表示されるまでの時間。特に「最初のトークンが表示されるまでの時間（TTFT）」はUXに直結します。
Token Cost（トークンコスト）: 1回のトランザクションあたりにかかるコスト。入力トークンと出力トークンの比率を監視し、ROI（投資対効果）が見合うかを判断します。

3. 堅牢性（Error Rate / Hallucination）

予期せぬ入力やエラーに対する強さです。

Tool Selection Accuracy（ツール選択正解率）: エージェントが適切なツール（Web検索、DBクエリ、計算機など）を選択できたか。
Parsing Error Rate（パースエラー率）: LLMが出力したJSONや特定のフォーマットを、システム側が正しく解析できなかった割合。これが高いとエージェントは動作停止します。

これらの指標をダッシュボードで可視化し、「品質は向上しているか？」「コストは適正か？」を常にモニタリングできる状態にすることが、本番運用の第一歩です。

PythonとLangChainによる評価パイプラインの実装手法

AIエージェントの成功を測定する3次元KPIフレームワーク - Section Image

KPIを定義したら、次はそれをどうやって測定するかです。毎回人間がチャット履歴を読んで採点するのは現実的ではありません。そこで登場するのが、「LLM-as-a-Judge（審査員としてのLLM）」というアプローチです。

LLM-as-a-Judge：AIによる自動評価の仕組み

これは、開発中のモデル（例えばGPT-3.5）の出力を、より高性能なモデル（例えばGPT-4）に評価させる手法です。「この質問とコンテキストに対して、この回答は適切ですか？ 1〜5点で採点し、理由も述べてください」というプロンプトを審査員LLMに投げます。

LangChainには、このためのモジュールが標準で用意されています。

from langchain.evaluation import load_evaluator
from langchain_openai import ChatOpenAI

# 評価対象のLLMと審査員LLMを定義
eval_llm = ChatOpenAI(model="gpt-4-turbo", temperature=0)

# 評価基準（正しさ）を設定
evaluator = load_evaluator("labeled_criteria", llm=eval_llm, criteria="correctness")

# 評価の実行
result = evaluator.evaluate_strings(
    input="日本の首都は？",
    prediction="東京です。",
    reference="東京"
)

print(result)
# Output: {'reasoning': '回答は正確であり、参照情報と一致しています。', 'score': 1, 'value': 'Y'}

このように、数行のコードで自動テストが可能になります。

Ragasなどの評価ライブラリを活用したスコアリング

さらに高度な評価を行うには、RAG専用の評価フレームワークであるRagas（Retrieval Augmented Generation Assessment）の活用を強く推奨します。Ragasは先ほど紹介したFaithfulnessやContext Precisionなどの指標を計算するためのロジックがあらかじめ実装されています。

Pythonでの実装イメージは以下のようになります。

from datasets import Dataset
from ragas import evaluate
from ragas.metrics import (
    faithfulness,
    answer_relevancy,
    context_precision,
)

# 評価用データの準備
data = {
    'question': ['LangChainとは何ですか？'],
    'answer': ['LangChainはLLMアプリケーションを構築するためのフレームワークです。'],
    'contexts': [['LangChainは、言語モデルを利用したアプリケーション開発のためのフレームワークです...']],
    'ground_truth': ['LLMアプリ開発用フレームワーク']
}
dataset = Dataset.from_dict(data)

# 評価の実行
results = evaluate(
    dataset = dataset,
    metrics=[
        context_precision,
        faithfulness,
        answer_relevancy,
    ],
)

print(results)

このスクリプトをCI/CDパイプラインに組み込むことで、コードやプロンプトを変更するたびに自動的に品質スコアが算出されるようになります。「修正したらスコアが落ちた」というデグレ（リグレッション）を即座に検知できるのです。

カスタムEvaluatorの実装コード例

ビジネス特有のルールがある場合は、カスタムEvaluatorを作成します。例えば、「回答には必ず『ご不明点はサポートまで』という文言を含めること」というルールがある場合、正規表現やシンプルなPython関数でチェック機構を実装し、それをLangChainのチェーンに組み込みます。

重要なのは、評価コードもプロダクトコードの一部として管理するという意識です。

プロンプト管理とバージョンごとのパフォーマンス比較

PythonとLangChainによる評価パイプラインの実装手法 - Section Image

プロンプトエンジニアリングは、もはや「職人芸」ではなく「工学」です。コードと同様にバージョン管理を行い、どのバージョンのプロンプトが最も高いスコアを出したかを記録する必要があります。

プロンプト変更が指標に与える影響の追跡

「プロンプトを少し丁寧にしたら、回答は良くなったがトークン数が倍になった」というトレードオフは頻繁に起こります。これを防ぐためには、プロンプトの変更履歴と評価結果を紐づけて管理する必要があります。

ここで役立つのが、LangSmithのようなLLM開発プラットフォームです。LangSmithを使えば、実行されたトレース（処理の追跡）をすべて記録し、特定のプロンプトバージョンでの実行結果を一覧化できます。

Gitライクなプロンプトバージョン管理

プロンプトをPythonコードの中にハードコード（直接記述）していませんか？これはアンチパターンです。プロンプトは外部ファイルや管理システム（LangChain Hubなど）で管理し、バージョンタグを付けるべきです。

v1.0: 基本的な指示のみ
v1.1: Few-Shotプロンプト（例示）を追加
v1.2: CoT（Chain of Thought）思考ステップを追加

このように管理し、それぞれのバージョンに対して先ほどのRagasなどでテストを実行します。

A/Bテストによる最適プロンプトの選定

開発環境でのテストだけでなく、本番環境の一部トラフィックを使ってA/Bテストを行うことも有効です。例えば、ユーザーの10%には「v1.2」のプロンプトを適用し、残りの90%には安定版の「v1.0」を適用します。ユーザーからのフィードバック（Good/Badボタンなど）や、その後のコンバージョン率を比較することで、実環境で最も効果的なプロンプトを科学的に選定できます。

【事例】トークンコスト30%削減と回答精度90%超を両立した評価運用

ここで、カスタマーサポート用AIエージェントにおける一般的な改善事例を紹介します。

導入前の課題：高コストかつ不安定な挙動

導入初期のプロジェクトでは、GPT-4をフル活用した結果、月間のAPIコストが予算を圧迫するケースがよく見られます。また、回答精度も定性的な評価に留まり、誤回答によるリスクを恐れて本番公開に踏み切れないことが少なくありません。

適用した評価指標と改善サイクル

まず、以下の3つのKPIを設定することが推奨されます。

回答正解率: 過去の問い合わせログから作成した「ゴールデンデータセット（正解集）」に対する一致率。
ハルシネーション率: 架空の機能やURLを案内していないか。
トークンコスト: 1解決あたりの平均コスト。

評価パイプラインを構築して現状を測定すると、正解率が伸び悩み、コストが想定を上回るケースがあります。分析を進めると、エージェントが無駄な「思考ステップ」を繰り返し、トークンを浪費していることが判明することが多いです。

施策：プロンプトの最適化とモデルの蒸留

そこで、以下の対策を実施します。

プロンプトの構造化: 曖昧な指示を排除し、必要なツールを即座に選べるようFew-Shot（使用例）を追加。
モデルの切り替え: 複雑な推論が必要な部分のみGPT-4を残し、定型的な回答生成や単純な検索には軽量モデル（GPT-3.5-turboやGPT-4o-mini相当）を使用。

評価指標を見ながら微調整を繰り返すことで、正解率が90%以上に向上し、トークンコストが30%程度削減される事例も存在します。「精度を上げるとコストも上がる」という思い込みは、適切な評価とチューニングによって覆すことが可能です。

最終的なROIと運用フェーズでの監視体制

このような成果を定量的に示すことで、経営陣への説明も論理的に進み、本番リリースへと繋がりやすくなります。運用フェーズにおいても、LangSmithなどを用いて日次でスコアを監視し、回答精度が一定水準を下回った場合はアラートを発報してエンジニアがログを確認する、といった運用フローの確立が重要です。

結論：継続的な改善サイクルの確立に向けて

評価用データの準備 - Section Image 3

AIエージェント開発において、「動く」ことと「実務で使える」ことの間には大きな溝があります。この溝を埋める確実な方法は、客観的な評価指標（KPI）を持ち、それを自動化されたパイプラインで継続的に計測することです。

評価駆動開発（EDD）のすすめ

テスト駆動開発（TDD）と同様に、評価駆動開発（Evaluation Driven Development: EDD）のアプローチが有効です。

まず評価基準（KPIとテストデータ）を作る。
とりあえず動くプロンプトとコードを書く。
評価を実行し、スコアを確認する。
スコアを上げるためにプロンプトやモデルを改善する。
3に戻る。

このサイクルを回すことで、エンジニアは客観的なデータに基づき、自信を持ってリリース判断を行えるようになります。

次に目指すべき自動化のステップ

まずは手元のPythonスクリプトで評価を試すところから始めてみてください。LangChainやRagasを使えば、今日からでも実装可能です。そして、徐々にCI/CDへの組み込みや、LangSmithのようなプラットフォーム活用へとステップアップしていくことを推奨します。

開発したAIエージェントが、真にビジネス課題を解決し、ROI最大化に貢献するシステムとなるよう、これらの実践的なアプローチを活用していくことをお勧めします。

LangChain開発の「動く」を「使える」に変える評価指標とPython実装ガイド - Conclusion Image

コメントは1週間で消えます

コメントを読み込み中...