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

プロンプトの反復改善 (Iterative Improvement)

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

反復ステップ

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

Eval (評価) を自動化する

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

def eval_prompt(prompt_template: str, cases: list[tuple[str, str]]) -> float:
    correct = 0
    for inp, expected in cases:
        out = run_claude(prompt_template.format(input=inp))
        if expected.strip() in out:
            correct += 1
    return correct / len(cases)

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

LLM-as-Judge

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

基準:
- 事実性: 0-2
- 簡潔性: 0-2
- 形式遵守: 0-2

質問: {q}
理想: {gold}
出力: {pred}

採点を JSON で返してください: {"factuality": x, "concision": y, "format": z, "comment": "..."}

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

Anti-pattern (やりがち失敗)

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

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

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

Eval を Claude に手伝ってもらう

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