この記事はLITALICO Engineers Advent Calendar 2025 カレンダー2 の 11日目の記事です
はじめに
生成AIを業務で使っていると、「プロンプトの書き方で結果が変わる」ことを実感される方が多いのではないでしょうか。
こんな経験はありませんか？
- 同じ質問でも、聞き方を変えるとAIの回答の質が変わる
- チームメンバーによってAIから得られる結果にばらつきがある
- 良い結果が出たプロンプトを他の人に共有したいが、どう説明すればよいか分からない
この記事では、プロンプトの品質を客観的に評価する手法について、実際に検討・検証した内容をご紹介します。
まだまだ模索段階ですが、データに基づいてプロンプトを改善していく方法を、みなさんと一緒に探っていけたらと思っています。
なぜプロンプト評価が重要なのか
客観的な評価ができると、以下のようなメリットがあります：
- 🔄 再現性の向上: チーム全体で同じ基準でプロンプトを評価
- 📈 継続的改善: データに基づいた改善サイクルの確立
- 👥 組織での共有: プロンプト品質の基準を組織全体で統一
- 💰 コスト最適化: 効果とコストのバランスを定量的に判断
📋 評価を始める前の準備
プロンプト評価には「正解データ」が必要です。完璧を目指さず、小さく始めて徐々に拡張していきましょう。
📅 推奨スケジュール
| 期間 | やること | 目標数 |
|---|---|---|
| Week 1 | 頻出質問の正解データ作成 | 5-10個 |
| Week 2-3 | 実際に評価して不足を発見 | 追加5個程度 |
| Month 1 | 月末振り返りとケース追加 | 合計20個程度 |
| 継続 | 段階的な拡張 | 月10-15個追加 |
1. 正解データ（期待する出力）の準備
プロンプトの評価を行う前に、まず「正解となるデータ」を用意する必要があります。これは、プロンプトに対してAIがどのような回答をすれば「良い回答」と判断できるかの基準となるものです。
具体例：
- 質問: 「この商品レビューの感情を分析してください：『配送が早くて助かりました。商品も期待通りでした。』」
- 期待する正解: 「ポジティブ」または「肯定的」
- AIの実際の回答: 「この商品レビューは肯定的な感情を示しています」
普段の運用で正解データを効率的に収集する方法
正解データの作成は大変に感じるかもしれませんが、日常業務の中で段階的に蓄積していく方法があります：
方法1: 既存の業務成果物を活用
例：カスタマーサポートの場合
- 過去の優秀な回答事例を正解として収集
- ベテランスタッフの対応記録から良い例を抽出
- 社内マニュアルの模範回答を正解データとして利用
方法2: 段階的な蓄積
週1回、10分程度の時間を使って：
1. その週に実際に受けた質問を3-5個ピックアップ
2. チームで「理想的な回答」を簡単に合意
3. 蓄積していくことで1か月で20-30個の正解データが完成
方法3: ユーザーフィードバックの活用
- AI回答に対するユーザーの「良い」「悪い」評価を記録
- 「良い」評価を得た回答を正解データの候補とする
- 月次でレビューして正解データセットに追加
方法4: 専門知識の段階的な文書化
- 新人研修や説明の際に作成した回答例を活用
- FAQ作成時の回答を正解データとして再利用
- 社内勉強会で議論した「ベストプラクティス」を記録
2. テストケースの作成
様々なパターンの入力に対して、期待する出力を定義したテストケース集を作成します。
例：商品レビュー分析の場合
テストケース1:
入力: "配送が遅れてがっかりしました"
期待する出力: "ネガティブ"
テストケース2:
入力: "普通の商品でした"
期待する出力: "ニュートラル"
テストケース3:
入力: "とても満足しています！"
期待する出力: "ポジティブ"
効率的なテストケース作成のコツ
パターン1: 実際の問い合わせログから抽出
- 過去1か月の問い合わせから代表的なパターンを10-15個選択
- 頻出する質問タイプごとに1-2個ずつピックアップ
- 簡単なもの・複雑なもの・境界線上のケースをバランスよく選択
パターン2: エッジケースの意図的な追加
- 「判断が難しい」ケースを意識的に含める
- 「よくある間違い」を引き起こしそうな入力を追加
- 短すぎる入力・長すぎる入力・曖昧な表現を含める
パターン3: チームメンバーとの協力
月1回のミーティングで：
1. 各メンバーが「今月困った質問」を2-3個持ち寄り
2. その場で期待する回答をチームで合意
3. 30分程度で10-15個の新しいテストケースが完成
テストケース管理のスプレッドシート例：
| 入力 | 期待する出力 | 難易度 | カテゴリ | 作成日 | メモ |
|------|------------|--------|----------|--------|----- |
| "配送遅れました" | "ネガティブ" | 簡単 | 配送 | 2024/11/24 | よくある苦情パターン |
| "まあまあかな" | "ニュートラル" | 普通 | 評価 | 2024/11/24 | 曖昧な表現の境界ケース |
| "○○について教えて" | "詳細説明" | 難しい | 情報提供 | 2024/11/24 | 抽象的な質問への対応 |
継続的な正解データの改善
月1回のレビュー会議で確認すること：
- 精度の低いテストケース: AIが頻繁に間違えるケースを分析
- 曖昧な正解: チームメンバー間で判断が分かれる正解を再定義
- 新しいパターン: 最近増えてきた問い合わせの傾向を正解データに反映
- 実用性の確認: 作成した正解データが実際の業務に即しているかを確認
正解データの品質を保つためのチェックポイント：
- ✅ 複数人が同じ判断をするか？
- ✅ 実際の業務で求められる回答レベルか？
- ✅ 新人でも理解できる明確さか？
- ✅ 組織のポリシーや方針に沿っているか？
🎯 評価の基本概念
AIの回答と正解を比較する3つの方法があります：
1. 完全一致（Exact Match）
「文字通り完全に同じ」かどうか
| 正解 | AI回答 | 判定 | 理由 |
|---|---|---|---|
| ポジティブ | ポジティブ | ✅ | 完全に同じ |
| ポジティブ | 肯定的 | ❌ | 意味は同じだが文字が違う |
2. 部分一致（Partial Match）
「キーワードが含まれている」かどうか
| 期待キーワード | AI回答 | 判定 |
|---|---|---|
| 満足 | お客様は商品に満足されています | ✅ |
| 満足 | お客様は商品を評価しています | ❌ |
3. セマンティック類似度
「意味が近い」かどうかをAI技術で判定
| 正解 | AI回答 | 判定 | 類似度 |
|---|---|---|---|
| ポジティブ | 肯定的な感情 | ✅ | 0.92 |
| 商品が良い | 製品の品質が高い | ✅ | 0.88 |
客観的評価手法の案
1. 定量的評価指標案
精度・性能指標
基本的な評価指標として、以下のようなメトリクスを検討してみました。
生成AIの性能を示す指標で、既に広く使われている下記の指標を組み合わせることで、客観性を確保しながら比較しやすくすることで、チーム内でコミュニケーションを取り改善活動ができるのはないかと考えています。
各指標の使い分けについて：
- 事実抽出・分類: 「この文書から会社名を抽出して」「このレビューは良い評価？悪い評価？」など、正解が明確な作業
- 文書生成・要約: 「議事録を要約して」「報告書を書いて」など、創作的な文章作成
- 創作・クリエイティブ: 「キャッチコピーを考えて」「物語を書いて」など、独創性が重要な作業
- コード生成: 「この処理をするプログラムを書いて」など、プログラミング関連
- 多言語対応: 複数の言語で同じ品質を保てるかの確認
| 用途・目的 | 推奨評価指標 | 重要度 |
|---|---|---|
| 事実抽出・分類 | Exact Match, F1 Score | 高 |
| 文書生成・要約 | BLEU, ROUGE, Semantic Similarity | 高 |
| 創作・クリエイティブ | Human Evaluation, Diversity Metrics | 中 |
| コード生成 | Execution Success, Code Quality Metrics | 高 |
| 多言語対応 | Cross-lingual Consistency | 中 |
今回は、私が検証した一例で、完全一致（Exact Match）、部分一致（Partial Match）、セマンティック類似度（Semantic Similarity）の組み合わせの例を示します。
実際の計算例：
10個のテストケースでプロンプトを評価した場合
- 完全一致：3個 → 完全一致率 30%
- 部分一致：7個 → 部分一致率 70%
- セマンティック類似度：平均0.85 → 意味的には85%の精度
このように数値で表すことで、プロンプトの改善前後や、複数のプロンプト候補の比較が可能になります。
def calculate_accuracy_metrics(responses, expected_outputs):
"""基本的な精度指標を計算"""
metrics = {
'exact_match': 0,
'partial_match': 0,
'semantic_similarity': []
}
for response, expected in zip(responses, expected_outputs):
# 完全一致
if response.strip().lower() == expected.strip().lower():
metrics['exact_match'] += 1
metrics['partial_match'] += 1
# 部分一致（キーワードベース）
elif any(keyword in response.lower() for keyword in expected.lower().split()):
metrics['partial_match'] += 1
# セマンティック類似度（文埋め込みを使用）
similarity = calculate_semantic_similarity(response, expected)
metrics['semantic_similarity'].append(similarity)
total_count = len(responses)
return {
'exact_match_rate': metrics['exact_match'] / total_count,
'partial_match_rate': metrics['partial_match'] / total_count,
'avg_semantic_similarity': sum(metrics['semantic_similarity']) / total_count,
'semantic_similarity_std': np.std(metrics['semantic_similarity'])
}
コスト効率指標
生成AIの利用では、コスト管理も考慮したいポイントの一つです。多くの生成AIサービスは従量課金制（使った分だけお金がかかる仕組み）のため、プロンプトが長すぎたり、必要以上に複雑だったりすると、コストが膨らんでしまいます。
コストに影響する要因：
- プロンプトの長さ: 長い指示文ほど処理コストが高い
- 生成される回答の長さ: 長い回答を求めるほどコストが高い
- 使用するAIモデル: 高性能なモデルほど一般的にコストが高い
- 実行回数: 同じプロンプトを何度も実行する場合の総コスト
理想的なのは「低コストで高品質な結果を得られるプロンプト」です。そのため、品質とコストの両方を見て総合的に判断することが重要になります。
class CostEfficiencyEvaluator:
def __init__(self):
self.pricing = {
'gpt-4': {'input': 0.03, 'output': 0.06}, # per 1K tokens
'gpt-3.5-turbo': {'input': 0.001, 'output': 0.002}
}
def evaluate_cost_efficiency(self, prompt_results):
"""コスト効率の評価"""
total_cost = 0
successful_results = 0
for result in prompt_results:
# コスト計算
input_cost = (result.input_tokens / 1000) * self.pricing[result.model]['input']
output_cost = (result.output_tokens / 1000) * self.pricing[result.model]['output']
result_cost = input_cost + output_cost
total_cost += result_cost
# 成功判定
if result.quality_score > 0.8: # 品質閾値
successful_results += 1
return {
'total_cost': total_cost,
'avg_cost_per_request': total_cost / len(prompt_results),
'cost_per_success': total_cost / max(successful_results, 1),
'success_rate': successful_results / len(prompt_results)
}
2. A/Bテスト手法
A/Bテストとは、複数の異なるプロンプト（AパターンとBパターン）を同じ条件で試して、どちらがより良い結果を出すかを統計的に比較する手法です。
具体例：
パターンA: "この文章を要約してください。"
パターンB: "この文章の要点を3つのポイントでまとめてください。"
同じ文章に対してAとBの両方を試し、どちらがより分かりやすく、正確で、使いやすい要約を作れるかを数値で比較します。複数のプロンプトバリエーションを統計的に比較してみる手法としてA/Bテストは活用できると考えています。
class PromptABTester:
def __init__(self):
self.test_cases = []
self.results = {}
def add_test_case(self, input_data, expected_output, metadata=None):
"""テストケースを追加"""
self.test_cases.append({
'input': input_data,
'expected': expected_output,
'metadata': metadata or {}
})
def run_ab_test(self, prompt_variants, ai_client):
"""A/Bテストを実行"""
results = {}
for variant_name, prompt_template in prompt_variants.items():
variant_results = []
for test_case in self.test_cases:
start_time = time.time()
# プロンプト実行
formatted_prompt = prompt_template.format(**test_case['input'])
response = ai_client.generate(formatted_prompt)
end_time = time.time()
# 評価
quality_score = self.evaluate_response_quality(
response.text,
test_case['expected']
)
variant_results.append({
'response': response.text,
'quality_score': quality_score,
'response_time': end_time - start_time,
'token_usage': response.usage,
'cost': self.calculate_cost(response.usage, response.model)
})
results[variant_name] = variant_results
return self.analyze_ab_results(results)
def analyze_ab_results(self, results):
"""A/Bテスト結果の統計分析"""
analysis = {}
for variant_name, variant_results in results.items():
quality_scores = [r['quality_score'] for r in variant_results]
response_times = [r['response_time'] for r in variant_results]
costs = [r['cost'] for r in variant_results]
analysis[variant_name] = {
'quality': {
'mean': np.mean(quality_scores),
'std': np.std(quality_scores),
'confidence_interval': self.calculate_confidence_interval(quality_scores)
},
'performance': {
'avg_response_time': np.mean(response_times),
'response_time_std': np.std(response_times)
},
'cost': {
'avg_cost': np.mean(costs),
'total_cost': sum(costs),
'cost_per_success': self.calculate_cost_per_success(variant_results)
}
}
# 統計的有意性の検定
analysis['statistical_significance'] = self.calculate_statistical_significance(results)
return analysis
3. 専門家による正解データの利用
専門家による正解データとは、その分野の専門家が「この場合の正解はこれ」と事前に決めておいたデータセットのことです。
例：カスタマーサポートの場合
- 質問: 「返品したいのですが、どうすればいいですか？」
- 専門家が決めた正解: 「返品ポリシーを確認して、返品フォームの記入と商品の梱包方法をご案内する」
- AIの実際の回答: 「返品をご希望でしたら、まず弊社の返品ポリシーをご確認ください..."
このように、専門家が事前に「正解」を定義しておくことで、AIの回答がどの程度その正解に近いかを客観的に測定できます。専門家のみなさんによる正解データセットを参考にした評価手法も検討、検証してみました。
class GoldStandardEvaluator:
def __init__(self, gold_standard_path):
self.gold_standard = self.load_gold_standard(gold_standard_path)
self.evaluators = {
'exact_match': self.exact_match_evaluator,
'semantic_similarity': self.semantic_similarity_evaluator,
'structural_accuracy': self.structural_accuracy_evaluator,
'domain_specific': self.domain_specific_evaluator
}
def load_gold_standard(self, path):
"""専門家による正解データの読み込み"""
with open(path, 'r', encoding='utf-8') as f:
return json.load(f)
def evaluate_prompt(self, prompt_template, ai_client, metrics=['exact_match', 'semantic_similarity']):
"""プロンプトの包括的評価"""
results = []
for test_item in self.gold_standard:
# プロンプト実行
formatted_prompt = prompt_template.format(**test_item['input'])
response = ai_client.generate(formatted_prompt)
# 各評価指標での評価
item_scores = {}
for metric in metrics:
score = self.evaluators[metric](response.text, test_item['expected'])
item_scores[metric] = score
results.append({
'input': test_item['input'],
'expected': test_item['expected'],
'actual': response.text,
'scores': item_scores,
'metadata': {
'tokens_used': response.usage,
'model': response.model,
'timestamp': datetime.now().isoformat()
}
})
return self.aggregate_results(results, metrics)
def aggregate_results(self, results, metrics):
"""結果の集計と統計分析"""
aggregated = {}
for metric in metrics:
scores = [r['scores'][metric] for r in results]
aggregated[metric] = {
'mean': np.mean(scores),
'median': np.median(scores),
'std': np.std(scores),
'min': np.min(scores),
'max': np.max(scores),
'percentiles': {
'25': np.percentile(scores, 25),
'75': np.percentile(scores, 75),
'90': np.percentile(scores, 90)
}
}
return {
'summary_statistics': aggregated,
'detailed_results': results,
'total_samples': len(results),
'evaluation_timestamp': datetime.now().isoformat()
}
4. 継続的モニタリング
継続的モニタリングとは、実際にプロンプトを本番環境で使い始めた後も、その性能を定期的にチェックし続けることです。
なぜ必要なのか：
- AIモデルの更新: 生成AIサービス側でモデルが更新されると、同じプロンプトでも結果が変わる可能性がある
- 利用パターンの変化: 実際の利用者からの質問や要求が、テスト時に想定していたものと異なる場合がある
- 品質の劣化検知: 時間が経つにつれて、何らかの要因で品質が下がっていないかを確認したい
モニタリングする項目の例：
- 回答の品質スコア（日々の平均値）
- レスポンス時間（AIが回答するまでの時間）
- コスト（1回あたりの利用料金）
- 利用者からのフィードバック（良い/悪いの評価）
製品上でのプロンプトの性能を考える上では、リリース後も継続的に監視する必要があると考えています。
class ProductionPromptMonitor:
def __init__(self, monitoring_config):
self.config = monitoring_config
self.metrics_store = MetricsStore()
self.alert_manager = AlertManager()
self.baseline_metrics = {}
def set_baseline(self, prompt_id, baseline_data):
"""ベースライン性能の設定"""
self.baseline_metrics[prompt_id] = {
'avg_quality_score': baseline_data['quality']['mean'],
'avg_response_time': baseline_data['performance']['avg_response_time'],
'avg_cost': baseline_data['cost']['avg_cost'],
'success_rate': baseline_data['success_rate']
}
def monitor_execution(self, prompt_id, execution_data):
"""個別実行の監視"""
current_time = datetime.now()
# メトリクス記録
metrics = {
'prompt_id': prompt_id,
'timestamp': current_time,
'quality_score': execution_data.get('quality_score'),
'response_time': execution_data.get('response_time'),
'cost': execution_data.get('cost'),
'success': execution_data.get('success', False),
'user_feedback': execution_data.get('user_feedback'),
'error_info': execution_data.get('error_info')
}
self.metrics_store.store(metrics)
# 異常検知
self.detect_anomalies(prompt_id, metrics)
def detect_anomalies(self, prompt_id, current_metrics):
"""異常値の検出とアラート"""
if prompt_id not in self.baseline_metrics:
return
baseline = self.baseline_metrics[prompt_id]
anomalies = []
# 品質スコアの劣化チェック
if current_metrics['quality_score'] < baseline['avg_quality_score'] * 0.8:
anomalies.append(f"品質スコア劣化: {current_metrics['quality_score']:.3f} < {baseline['avg_quality_score'] * 0.8:.3f}")
# レスポンス時間の悪化チェック
if current_metrics['response_time'] > baseline['avg_response_time'] * 1.5:
anomalies.append(f"レスポンス時間悪化: {current_metrics['response_time']:.2f}s > {baseline['avg_response_time'] * 1.5:.2f}s")
# コスト増加チェック
if current_metrics['cost'] > baseline['avg_cost'] * 1.3:
anomalies.append(f"コスト増加: ${current_metrics['cost']:.4f} > ${baseline['avg_cost'] * 1.3:.4f}")
if anomalies:
self.alert_manager.send_alert(prompt_id, anomalies)
def generate_performance_report(self, prompt_id, time_range_hours=24):
"""性能レポートの生成"""
end_time = datetime.now()
start_time = end_time - timedelta(hours=time_range_hours)
metrics_data = self.metrics_store.query(
prompt_id=prompt_id,
start_time=start_time,
end_time=end_time
)
if not metrics_data:
return None
# 統計計算
quality_scores = [m['quality_score'] for m in metrics_data if m['quality_score'] is not None]
response_times = [m['response_time'] for m in metrics_data if m['response_time'] is not None]
costs = [m['cost'] for m in metrics_data if m['cost'] is not None]
success_count = sum(1 for m in metrics_data if m['success'])
report = {
'prompt_id': prompt_id,
'time_range': {'start': start_time, 'end': end_time},
'execution_count': len(metrics_data),
'quality': {
'avg_score': np.mean(quality_scores) if quality_scores else None,
'score_trend': self.calculate_trend(quality_scores),
'score_distribution': np.histogram(quality_scores, bins=10) if quality_scores else None
},
'performance': {
'avg_response_time': np.mean(response_times) if response_times else None,
'p95_response_time': np.percentile(response_times, 95) if response_times else None,
'response_time_trend': self.calculate_trend(response_times)
},
'cost': {
'total_cost': sum(costs) if costs else 0,
'avg_cost_per_execution': np.mean(costs) if costs else None,
'cost_trend': self.calculate_trend(costs)
},
'reliability': {
'success_rate': success_count / len(metrics_data),
'error_count': len(metrics_data) - success_count,
'error_types': self.analyze_error_types(metrics_data)
}
}
return report
実践的な評価フレームワーク
包括的評価システム
1つの評価だけで完璧な状態を目指すのは難しいと考え、上記で挙げた評価を包括的にまとめました
class ComprehensivePromptEvaluator:
def __init__(self, config):
self.config = config
self.ab_tester = PromptABTester()
self.gold_evaluator = GoldStandardEvaluator(config['gold_standard_path'])
self.cost_evaluator = CostEfficiencyEvaluator()
self.monitor = ProductionPromptMonitor(config['monitoring'])
def full_evaluation_pipeline(self, prompt_variants, test_phase='development'):
"""完全な評価パイプライン"""
results = {
'evaluation_phase': test_phase,
'timestamp': datetime.now().isoformat(),
'prompt_variants': list(prompt_variants.keys())
}
# フェーズ1: A/Bテスト
print("フェーズ1: A/Bテスト実行中...")
ab_results = self.ab_tester.run_ab_test(prompt_variants, self.config['ai_client'])
results['ab_test'] = ab_results
# フェーズ2: ゴールドスタンダード評価
print("フェーズ2: 専門家による正解データ評価中...")
gold_results = {}
for variant_name, prompt_template in prompt_variants.items():
gold_results[variant_name] = self.gold_evaluator.evaluate_prompt(
prompt_template,
self.config['ai_client']
)
results['gold_standard'] = gold_results
# フェーズ3: コスト効率分析
print("フェーズ3: コスト効率分析中...")
cost_results = {}
for variant_name in prompt_variants.keys():
variant_executions = self.extract_execution_data(ab_results[variant_name])
cost_results[variant_name] = self.cost_evaluator.evaluate_cost_efficiency(variant_executions)
results['cost_efficiency'] = cost_results
# フェーズ4: 総合分析
print("フェーズ4: 総合分析中...")
results['comprehensive_analysis'] = self.synthesize_results(results)
# フェーズ5: 推奨事項生成
results['recommendations'] = self.generate_recommendations(results)
return results
def synthesize_results(self, evaluation_results):
"""複数の評価結果を統合分析"""
synthesis = {}
for variant_name in evaluation_results['prompt_variants']:
# 各評価軸のスコア正規化
ab_quality = evaluation_results['ab_test'][variant_name]['quality']['mean']
gold_quality = evaluation_results['gold_standard'][variant_name]['summary_statistics']['semantic_similarity']['mean']
cost_efficiency = 1 / evaluation_results['cost_efficiency'][variant_name]['cost_per_success']
# 重み付き総合スコア算出
weights = self.config.get('evaluation_weights', {
'quality': 0.4,
'consistency': 0.3,
'cost_efficiency': 0.3
})
overall_score = (
ab_quality * weights['quality'] +
gold_quality * weights['consistency'] +
min(cost_efficiency, 1.0) * weights['cost_efficiency']
)
synthesis[variant_name] = {
'overall_score': overall_score,
'quality_score': (ab_quality + gold_quality) / 2,
'cost_efficiency_score': cost_efficiency,
'ranking_factors': {
'ab_test_quality': ab_quality,
'gold_standard_consistency': gold_quality,
'cost_efficiency': cost_efficiency
}
}
# ランキング生成
ranked_variants = sorted(
synthesis.items(),
key=lambda x: x[1]['overall_score'],
reverse=True
)
synthesis['ranking'] = [variant for variant, _ in ranked_variants]
return synthesis
def generate_recommendations(self, evaluation_results):
"""評価結果に基づく改善推奨事項"""
analysis = evaluation_results['comprehensive_analysis']
recommendations = []
best_variant = analysis['ranking'][0]
best_scores = analysis[best_variant]
# パフォーマンス改善提案
if best_scores['quality_score'] < 0.8:
recommendations.append({
'category': 'quality_improvement',
'priority': 'high',
'description': 'プロンプトの品質スコアが低いため、より具体的な指示や例示の追加を検討してください',
'specific_actions': [
'出力フォーマットの明確化',
'具体例の追加',
'制約条件の明示'
]
})
# コスト最適化提案
if best_scores['cost_efficiency_score'] < 0.5:
recommendations.append({
'category': 'cost_optimization',
'priority': 'medium',
'description': 'コスト効率が低いため、プロンプト長の最適化やモデル選択の見直しを検討してください',
'specific_actions': [
'プロンプト長の短縮',
'軽量モデルでの代替可能性検証',
'キャッシュ機能の活用'
]
})
# 一貫性改善提案
consistency_variance = np.var([
scores['quality_score'] for scores in analysis.values()
if isinstance(scores, dict) and 'quality_score' in scores
])
if consistency_variance > 0.1:
recommendations.append({
'category': 'consistency_improvement',
'priority': 'medium',
'description': 'プロンプト間の品質のばらつきが大きいため、標準化を検討してください',
'specific_actions': [
'プロンプトテンプレートの標準化',
'共通パターンの抽出',
'ガイドライン文書の作成'
]
})
return recommendations
検証時に意識したこと
1. 段階的評価の実施
# 開発段階での簡易評価
def quick_evaluation(prompt, test_cases, ai_client):
"""開発段階での簡易評価"""
results = []
for test_case in test_cases[:10]: # 小さなサンプルで高速評価
response = ai_client.generate(prompt.format(**test_case['input']))
quality = simple_quality_check(response.text, test_case['expected'])
results.append(quality)
return {
'avg_quality': np.mean(results),
'sample_size': len(results),
'confidence': 'low' if len(results) < 20 else 'medium'
}
# 本格評価前の中間評価
def intermediate_evaluation(prompt, ai_client, evaluator):
"""中間段階での詳細評価"""
return evaluator.evaluate_prompt(
prompt,
ai_client,
metrics=['exact_match', 'semantic_similarity']
)
# 本番前の最終評価
def final_evaluation(prompt_variants, ai_client, full_evaluator):
"""本番前の包括的評価"""
return full_evaluator.full_evaluation_pipeline(
prompt_variants,
test_phase='pre_production'
)
2. 継続的改善のサイクル
一度に改善が難しいため、検証段階でも継続的改善のサイクルを実施しました
class PromptImprovementCycle:
def __init__(self, evaluator, monitor):
self.evaluator = evaluator
self.monitor = monitor
self.improvement_history = []
def continuous_improvement_loop(self, initial_prompt, improvement_iterations=5):
"""継続的改善サイクル"""
current_prompt = initial_prompt
current_performance = None
for iteration in range(improvement_iterations):
print(f"改善サイクル {iteration + 1}/{improvement_iterations}")
# 現在の性能評価
performance = self.evaluator.evaluate_prompt(current_prompt)
if current_performance is None:
current_performance = performance
# 改善が見られない場合は終了
if not self.is_improvement(performance, current_performance):
print("改善が見られないため、サイクルを終了します")
break
# 改善候補の生成
improvement_candidates = self.generate_improvement_candidates(
current_prompt,
performance
)
# 候補の評価
best_candidate = self.select_best_candidate(improvement_candidates)
# 履歴記録
self.improvement_history.append({
'iteration': iteration + 1,
'prompt': current_prompt,
'performance': performance,
'improvement_applied': best_candidate['improvement_type']
})
current_prompt = best_candidate['prompt']
current_performance = performance
return {
'final_prompt': current_prompt,
'final_performance': current_performance,
'improvement_history': self.improvement_history
}
まとめ
プロンプトチューニングの客観的評価は、生成AIを効果的に活用する上で役立つ技術の一つかもしれません。この記事でご紹介した手法が少しでもお役に立てれば幸いです
期待できそうな効果
- 品質の見える化: プロンプトの性能を数値で確認できる
- 継続的改善: データを参考に一緒に改善していける
- コスト最適化: 効果とコストのバランスをみんなで考えられる
- 組織での共有: チーム全体で品質基準を共有できるようにしたい
実装で考慮したいポイント
- 段階的導入: 簡易評価から始めて徐々に詳細化していく
- 指標の選び方: 用途に合わせて評価指標を検討する
- 継続的な確認: 本番環境での性能を時々チェックする
- 改善の輪: 評価結果をみんなで共有して改善に活かす
今後の展開
プロンプト評価の分野は発展途上で、今後みなさんと一緒に以下のような方向を探っていけたらと思います
- 自動化の検討: 評価プロセスの自動化を進めてみる
- 新しい評価指標: より使いやすい評価指標を一緒に考える
- 専門分野への対応: 業界・用途に特化した評価手法を模索する
- リアルタイム調整: 実行時の動的なプロンプト調整も面白そう
生成AIの活用が進む中で、客観的な評価手法があると組織としても心強いですね。この記事の内容が少しでも参考になり、みなさんのプロンプト品質向上のお役に立てれば嬉しいです。
LITALICOにおける実践的な可能性
私の所属するLITALICOでは、非エンジニアの方々が豊富で深いドメイン知識を持っています。例えば、発達支援の児童発達支援管理責任者 ※1、就労移行支援のジョブコーチ ※2、教育現場のスクールソーシャルワーカー ※3など、それぞれが長年の経験と専門性を蓄積しています。
これらの知識は、技術者だけではカバーしきれない領域の深い洞察を含んでいます。プロンプトエンジニアリングでAIと組み合わせることで、より温かいサービス提供につながっていけたらいいなと思っています。
具体的な活用例：
- 児童発達支援管理責任者 → 「この子の特性と成長段階を考慮した個別支援計画の提案」
- ジョブコーチ → 「利用者の強みと市場ニーズを踏まえた最適な就労先の分析」
- スクールソーシャルワーカー → 「学習者の理解度に応じたカリキュラムの動的調整」
こんなふうに、現場の専門知識をプロンプトに組み込むことで、お一人お一人に合わせたサポートの質が向上するかもしれません。AIの汎用性と人間の専門性が一緒になることで、LITALICOのミッション実現に向けた新しい価値をみんなで作っていけるといいなと思います。
脚注
※1: 子どもの発達段階や特性に合わせて支援計画をつくり、指導内容の振り返りや改善をおこなう責任者
※2: 不登校や家庭内でのトラブルにアプローチできるソーシャルワークの専門家
※3: 働くことに必要なスキルや生活リズム等、障害に配慮しながらアドバイスやトレーニングをおこなう専門家
他にも家族多くの専門家がLITALICOや障害福祉分野で活躍されています、より詳細は、しごと図鑑をご覧ください