プロンプトの反復改善とEval

最初から完璧なプロンプトは書けません。測定 → 改善 のループを回します。 これは ソフトウェア開発のテスト駆動開発 (TDD) とよく似た考え方です。

反復ステップ

1. タスクを定義: 何が「成功」か明文化する。
2. テストケースを 10〜30 件作る: 入力と理想出力のペア。
3. 初期プロンプトで実行: 失敗ケースを観察する。
4. 失敗パターンを分類: 抜け漏れ・形式違反・幻覚など。
5. プロンプトを修正: 失敗パターンに対応する指示を追加。
6. 再測定: 改善とリグレッションを確認。

Eval (評価) を自動化する

簡単な eval は Python でも書けます。

wzxhzdk:0

本格的には Anthropic Workbench, promptfoo, LangSmith, Inspect などのツールが使えます。

LLM-as-Judge

採点が難しいタスク (要約の品質など) では、別の Claude (高性能モデル) に 採点役 をさせます。

wzxhzdk:1

判定モデルは 被評価モデルと別 にするのが望ましい (Opus が Sonnet を採点するなど)。

Anti-pattern (やりがち失敗)

• プロンプトを 1 回見ただけで OK 判定: 入力データの分布を見ていない。
• 巨大化した system prompt: 矛盾する指示が混在し性能が落ちる。
• モデルが悪いと早合点: 多くの場合プロンプト側に改善余地がある。
• 境界条件を忘れる: 空入力・極端に長い入力・想定外の言語など。
• Eval なしでデプロイ: 後から劣化に気付けない。

「プロンプトを書く」 = 「仕様書を書く」

良いプロンプトは 明確な仕様書 に近づきます。 だから、プロンプト改善はソフトウェア設計のスキルそのものです。

Eval を Claude に手伝ってもらう

テストケース作成は Claude に頼むのが効率的です。

あなたが第 2 章で書いてきたプロンプト (例: 営業時間 JSON 化、メール分類) のうち 1 つを選び、 5 件のテストケース (入力 + 理想出力) を作って Goldset とし、現状のプロンプトの正答率を測定してください。

形式例:

ケース 1:
  入力: ...
  期待: ...
  実際: ...
  判定: ✓/✗