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

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

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

反復ステップ

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

Eval (評価) を自動化する

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

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "ruff check $CLAUDE_PROJECT_DIR" }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "echo Done" }
        ]
      }
    ]
  }
}

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

LLM-as-Judge

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

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{
        "type": "command",
        "command": "prettier --write $CLAUDE_PROJECT_DIR && eslint --fix $CLAUDE_PROJECT_DIR"
      }]
    }]
  }
}

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

Anti-pattern (やりがち失敗)

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

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

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

Eval を Claude に手伝ってもらう

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