レッスン5：イテレーション設計——プロンプトの評価と改善サイクル

このレッスンで学ぶこと

プロンプト評価セット（test set）の作り方を理解する
量的指標（精度・再現率・合意率・コスト・レイテンシ）と質的レビューを使い分ける
A/B 比較とプロンプトの履歴管理の運用を学ぶ
エラー分析と原因の分類を実施できる
LLM-as-a-Judge の限界と適切な使い方を区別できる

前回までのレッスンで、プロンプトの基本骨格と出力制御を扱いました。今回は、本コースの中心テーマである「評価とイテレーション」に入ります。「設計→評価→分析→改善」のサイクルを回し続けることが、プロンプトエンジニアリングを「実践」として成立させる核心です。本レッスンは、そのサイクルを実務で運用する手順を学びます。

なぜ「評価」が中核なのか

LLM のプロンプトは、書いた瞬間にうまく動くこともあれば、思わぬ場面で破綻することもあります。「動いた／動かなかった」の経験を、運用に再現性のある形で蓄積するには、評価が不可欠です。

flowchart LR
  W[書く<br/>プロンプト設計] --> E[評価<br/>評価セットで測る]
  E --> A[分析<br/>失敗の原因分類]
  A --> I[改善<br/>プロンプト修正]
  I --> W

サイクルを回さないと、

「うまくいったプロンプト」がモデル更新で動かなくなる事故
「失敗の原因」が個人の感覚に依存し、共有・改善できない
複数のプロンプトを並行管理するときに「どれが良いか」の判断ができない
新しい技法を試したとき、「効果があったか」を客観的に判定できない

ことが起きます。本レッスンは、これらを防ぐ運用を扱います。

💡 ポイント 「プロンプトを書く時間」と「プロンプトを評価する時間」は、現場では半々くらいが理想と言われます。書く時間ばかり増やしても、評価で測らないと改善が空回りします。

プロンプト評価セット（test set）の作り方

評価セットは、プロンプトの良し悪しを測る「テスト問題集」です。実務での設計手順を整理します。

①代表的な入力を 30〜100 件集める

業務で扱う入力の分布を反映する形で集めます。実データから抽出するのが基本で、可能なら 30〜100 件を用意します。少なすぎると精度の差が偶然に見えるため、最低 30 件が経験的な目安です。

②難度・パターンの分散を確保する

易しい例：標準的なケース
中程度：少しひねりのある現実的なケース
難しい例：エッジケース、過去にバグった事例

③期待出力を人手で用意する

「この入力に対しては、こう返してほしい」という正解（または許容範囲）を、人手で用意します。これが評価の基準になります。

④失敗事例を蓄積する

運用していて「これが動かなかった」事例は、評価セットに必ず追加します。失敗事例の蓄積が、評価セットを成長させる原動力です。

⑤評価セットを「育てる」運用にする

評価セットは一度作って終わりではなく、運用しながら継続的に拡張するものです。月次・四半期で見直し、新しいパターンや失敗事例を反映します。

📝 補足 評価セットは「機密性が高い」リソースです。自社の顧客データや独自の業務知識を含むため、外部に漏れないよう管理が必要です。一方、社内では透明に共有し、エンジニア・PM・現場担当者が同じセットを見て判断できる状態が望ましいです。

量的指標と質的レビュー

評価セットでプロンプトを測るとき、「量的指標」と「質的レビュー」の両方を使います。

量的指標の代表例

指標	説明	適するタスク
精度（accuracy）	正解と一致した割合	分類、抽出
再現率（recall）	取りこぼしの少なさ	抽出、検索
適合率（precision）	余計を含めない正しさ	抽出、検索
F1 スコア	再現率と適合率の調和平均	抽出全般
合意率	人間評価者との一致率	主観評価が必要なもの
コスト（円／回）	API 利用料金	すべて
レイテンシ（秒）	1 回の応答時間	すべて

質的レビュー

数値では捉えにくい品質を、人が直接見て判定します。

出力の自然さ・読みやすさ
ユーザーから見た「使えるか」感
不適切な表現や誤解を招く表現の有無
「正解はあっているけど、何か気持ち悪い」場面の検出

両者の組み合わせ

量的指標で「全体の傾向」を、質的レビューで「個別の質感」を捉えます。量だけでは「数字は良いのに使えない」現象を見落とし、質だけでは「全体的にどうか」がわかりません。

💡 ポイント 量と質は対立するものではなく、相補的に使います。100 件の評価セットで「精度 85%、レイテンシ 2.3 秒、コスト 0.3 円」とわかった上で、サンプリングした 20 件を人が直接読んで「主観的にどうか」を確認する、というのが典型的な運用です。

A/B 比較とプロンプトの履歴管理

複数のプロンプト案を比較するときの基本動作です。

A/B 比較の基本

プロンプト A とプロンプト B を、同じ評価セットで実行
同じ量的指標（精度、コスト、レイテンシ）で並べる
失敗事例の重複・差分を見る
主要指標と、副次指標（コスト、レイテンシ）のトレードオフを確認

プロンプト履歴管理の方法

バージョン管理：プロンプトを Git で管理する（テキストファイルとして）
専用ツール：プロンプト管理に特化した SaaS（LangSmith、Helicone、PromptLayer など、2026 年 6 月時点で複数存在）
簡易管理：スプレッドシートに「プロンプト ID／日付／評価結果／変更点」を記録

何を記録するか

項目	内容
プロンプト本体	全文（システムプロンプト・ユーザープロンプトの両方）
バージョン	v1.0、v1.1 など
評価結果	量的指標の値
失敗例	評価セット中の失敗ケース
変更点	前バージョンからの差分
適用環境	本番／ステージング／実験
モデル	Claude Opus 4.7、GPT-5.5 など

⚠️ 注意 「最新のプロンプトだけ」を管理していると、「3 か月前のバージョンの方が良かった」と判明したときに復元できません。バージョンを切ってアーカイブする運用は、最初は面倒に感じても、半年後に必ず役立ちます。

エラー分析と原因の分類

評価で失敗したケースをただ「失敗」と数えるだけでは、改善に繋がりません。原因を分類し、対策を打ちやすい形にする作業——エラー分析——が重要です。

よくあるエラーの分類

分類	内容	主な対策
指示の曖昧さ	プロンプトの指示が解釈の余地を残している	明示化、禁止事項の追加
文脈不足	判断に必要な情報がプロンプトに渡されていない	文脈追加、RAG 連携（レッスン 8）
ハルシネーション	事実にない情報を生成	「不明な場合は不明と回答」指示、検証ロジック追加
形式エラー	出力形式がスキーマに従わない	Structured Outputs、XML タグ、リトライ
推論不足	多段階推論で途中の段階を飛ばす	Chain-of-Thought、Self-Consistency（レッスン 6）
モデルの限界	そのモデルでは精度が頭打ち	より上位モデル、reasoning モデルへ切替

分類の運用

失敗事例 1 件ずつに、原因タグを付けていきます。すると、

どの原因が最も多いか
どの対策に優先順位を付けるべきか
改善後の効果がどの原因に効いたか

が、定量的に追えるようになります。

📝 補足 エラー分析は、コードのバグ修正と発想が似ています。「動かない」だけでは直せないので、再現条件・原因の特定・対策の検証、というサイクルを回します。プロンプトでも同じです。

LLM-as-a-Judge

評価セットの「人手の正解」を用意するのが大変な場合、別の LLM に判定を任せる「LLM-as-a-Judge」が広く使われるようになっています。

中核の発想

評価用のプロンプトを別に作り、別の LLM（または同じ LLM）に「この出力は正しいか」「どちらの出力が良いか」を判定させる

主な使い方

単独評価：「この出力を 1〜5 で評価してください」
ペア比較：「A と B のどちらが良いか」を選ばせる
ルーブリック評価：複数の基準に分けて点数化

LLM-as-a-Judge の利点

人手評価より早く・安価で大量に評価できる
評価セットを大規模化できる
A/B 比較が頻繁に回せる

LLM-as-a-Judge の限界

判定 LLM 自身がハルシネーションを起こす
判定にバイアスがある（位置バイアス：A/B で前者を好む傾向、長さバイアス：長い回答を好む傾向など）
判定モデルが変わると、評価結果も変わる
人手評価との一致率（agreement）を測定しないと、信頼性がわからない

⚠️ 注意 LLM-as-a-Judge は便利ですが、「判定 LLM の判定が常に正しい」と信用するのは危険です。最低でも、人手評価との一致率を一度測り、「90% 一致するから自動評価でも実用に耐える」のように根拠を持って使うのが運用の基本です。位置バイアス対策には、ペア比較で A/B を入れ替えて 2 回実行する、などの工夫が知られています。

イテレーションサイクルの実例

ここまでの要素を組み合わせた、典型的なイテレーションサイクルを紹介します。

1 週目：ベースライン

プロンプトの初版（v1.0）を作成
30 件の評価セットを用意
量的指標（精度・コスト・レイテンシ）を測定
失敗事例にエラー分類タグを付ける

2 週目：技法の追加

失敗の多い原因に対して対策を 1 つ追加（例：Few-shot 例を 5 個追加）
v1.1 として記録
同じ評価セットで再測定
v1.0 と v1.1 を A/B 比較

3 週目：別の角度から

別の対策（例：XML タグでの構造化）を試す
v1.2 として記録、A/B 比較
失敗パターンが変わったか確認

4 週目：評価セット拡張

新しい失敗事例を評価セットに追加（30 → 50 件）
既存バージョンを新セットで再評価
ベースラインを最新版に更新

このサイクルを回し続けることで、プロンプトの品質が継続的に磨かれていきます。

💡 ポイント 「イテレーションを回す」というと大げさに聞こえますが、実際は「週に 1〜2 時間、評価セットでプロンプトを試す時間を持つ」だけで、長期的には大きな差になります。継続が鍵です。

講師の現場メモ：50 件の評価セットで変わった話

私（西脇）が SaaS スタートアップで AI 機能を担当していた頃、最初のプロンプト改善は完全に「感覚」でした。「うまく動かないらしい」「あ、この対策で良くなった気がする」を繰り返していました。

転機は、エンジニアの一人が「ちゃんと評価セットを作りませんか」と提案したことでした。最初は「そんな時間ない」と思いました。実データから 50 件の代表例を選び、人手で正解を用意するのに、3 人で 2 日かかりました。

評価セットができてから、私たちのプロンプト改善の景色は完全に変わりました。

「これで良くなったはず」と思っていた変更が、実は精度を下げていた、とわかる
「全体的にどうか」だけでなく「どの種類の入力で失敗しているか」が見える
失敗の 60% が同じ原因（指示の曖昧さ）だったとわかり、対策の優先順位が付く
A/B 比較で「v1.5 より v1.3 の方が良かった」が客観的に判定でき、巻き戻せる
半年後、モデル更新で挙動が変わったとき、評価セットを再実行するだけで影響範囲がわかる

最大の発見は、「評価セットがあると、プロンプトを書くこと自体が変わる」ことでした。「これを書いたら評価セットで何点取れるだろう」と想像しながら書くようになり、漠然とした改善ではなく、具体的なターゲットを持って改善するようになりました。

3 人で 2 日の投資が、その後 1 年半の運用で、何倍にも返ってきた感覚があります。本コースが評価セット作りに 1 レッスンを割くのは、この経験が背景にあります。本コースを学ぶ皆さんも、ぜひ 30 件でいいので、自分のタスクの評価セットを作るところから始めてみてください。

まとめ

このレッスンでは、以下のことを学びました。

評価セット（test set）：代表入力 30〜100 件と期待出力。難度の分散、失敗事例の蓄積、運用しながら育てる
量的指標：精度・再現率・適合率・F1・合意率・コスト・レイテンシ
質的レビュー：数値で捉えにくい品質を人が直接判定。量と質を相補的に使う
A/B 比較とプロンプト履歴管理：バージョン管理、評価結果、失敗例、変更点を記録
エラー分析の分類：指示の曖昧さ／文脈不足／ハルシネーション／形式エラー／推論不足／モデル限界
LLM-as-a-Judge：人手評価より早く・安価。バイアス（位置・長さ）と判定モデル依存性に注意、人手評価との一致率を測ってから使う
イテレーションサイクル：週次のリズムで「書く→評価→分析→改善」を回す

次のレッスンでは、本レッスンの「評価」を土台に、高度な推論パターン——Self-Consistency、Tree of Thoughts、Reflexion、Self-Refine——を学びます。reasoning モデル時代の使い分けにも触れます。

確認クイズ

このレッスンの理解度をチェックしましょう。