モデルをアップグレードする前にプロンプトを反復改善する

このビデオのデモは2026年8月に収録されたものです。Claude Haiku 4.5、Claude Sonnet 5、Claude Opus 5で実行されました。新しいモデルでは結果が異なります。各レッスンのデモはそれぞれ別のevalの実行結果であるため、そのスコアとコストは他のレッスンのものとは一致しません。

evalのスコアが低いということは、モデルが多くのケースで誤った答えを出したことを示しますが、モデルとプロンプトのどちらに原因があるかまでは教えてくれません。

切り替えた後に送るすべてのリクエストの価格が上がるため、まずプロンプトを確認しましょう。プロンプトの変更は数分で済み、すぐに変更をテストできます。

架空のエンジニアリングコンサルティング会社Meridianには、月次プロジェクトレポートから3つのフィールド、すなわちプロジェクトID、スケジュールステータス、最大のリスクを抽出する1つのプロンプトがあります。そのevalは50件のテストケースで構成され、それぞれがレポートと期待される答えのペアです。

Claude Sonnet 5とClaude Opus 5は50件すべてに正解しました。Claude Haiku 4.5は3つのうち最も安価ですが、正解率は84%にとどまり、Meridianがモデルを使用する前に求める正解率の下限である90%に届きませんでした。

より大きなモデルに費用をかける前に、Meridianは5つのステップに取り組みます。

1. 失敗したケースを読み、共通点を見つける。
2. 根拠のない答えに対する修正方法を選ぶ。
3. プロンプトに変更内容を書き込む。
4. 3つすべてのモデルで50件のケースをすべて再実行する。
5. すべての列を確認し、アップグレードするかどうかを決める。

失敗したケースを読み、共通点を見つける

失敗したケースを、レポートの種類と誤ったフィールドごとに分類しましょう。 スコアは失敗の数を数えるだけで、その理由までは説明してくれません。失敗した内容を読むことで、何がどのように間違ったのかがわかり、それによってモデルとプロンプトのどちらに原因があるかがわかります。

Meridianの50件のケースは、典型的なレポート30件、複数のプロジェクトを扱うレポート10件、リスク欠落ケース10件(レポートにリスクセクションがないもの)で構成されています。次の表は、旧プロンプト(Meridianが最初に使っていたもの)でHaiku 4.5がどのような結果になったかを示しています。

旧プロンプトを使ったHaiku 4.5は、50件中8件で失敗しました。

8件の失敗のうち5件はリスク欠落ケースで、すべてtop_riskに関するものです。本来はすべてnullが返されるべきところ、モデルは毎回リスクを挙げる文を書いていました。ケースr045はその一例です。

許可証については通常の注記があるだけで、レポート自体も問題は予想されないと述べているにもかかわらず、モデルはそれを最大のリスクとして選んでしまいました。

旧プロンプトのtop_riskの行は「or null」で終わっており、nullを許容してはいたものの、それがどのような場合に当てはまるかはモデルに伝えていませんでした。失敗が1つの種類のレポートと1つのフィールドに集中している場合、通常は共通の原因があり、ここではプロンプトに抜け落ちがありました。

根拠のない答えに対する修正方法を選ぶ

根拠のない答えを減らすための5つの標準的な方法から修正方法を選びましょう。 文書に裏付けのない答えは「根拠のない答え」と呼ばれ、ハルシネーションとも呼ばれます。以下の最初の3つは、ハルシネーションを減らすための基本的な手順です。

1. 「わからない」と言わせる。 文書に答えが含まれていない場合にモデルが何を返すべきかを伝えます。Meridianの場合はそれがnullです。
2. 答える前に引用させる。 モデルにまず答えの根拠となる文を抜き出させ、その文をもとに答えさせます。
3. 文書に基づいて引用で裏付けさせる。 モデルが答えた後、各主張を裏付ける引用を見つけさせ、裏付けられない主張は取り下げさせます。そうすれば、残った主張を人が確認できます。
4. 検証パスを追加する。 最初のリクエストが出した答えをチェックすることを目的とした2回目のリクエストを送ります。
5. 外部知識を制限する。 文書のみから答えるようモデルに指示し、学習で得た知識は使わないように伝えます。

Meridianは最初の2つを使います。1つ目はステップ1で見つかったギャップをまさに埋めるものだからです。2つ目は、すべての答えをレポート内の文と一致させるものです。どちらもMeridianが既に持っているプロンプトに1、2行を加えるだけで済みます。

プロンプトに変更内容を書き込む

nullが正しい答えとなる場合をプロンプトに明記し、答えの前に引用を求めましょう。 以下のボックスには、両方の変更を加えたMeridianの新しいプロンプトが入っています。それぞれの役割を果たす行を見つけてください。注記で何が変わったかがわかります。

再びケースr045を見てみましょう。モデルは今、リスクを示す文を指し示す必要があり、レポート自身の言葉にはそうした文は見当たりません。「チームは更新に関して問題が生じるとは想定していない。」レポートにそのような文がない場合、新しいプロンプトは何を返すべきかを指定しています。<source>none</source>、続いてnullです。

コードにも1つ新しい役割が加わります。引用が応答の先頭に来るようになったため、テキスト全体はもはや有効なJSONではなく、json.loadsをそのまま適用すると失敗します。閉じタグ</source>の後に続く部分だけを解析してください。

answer = json.loads(text.split("</source>")[-1])

3つすべてのモデルで50件のケースをすべて再実行する

同じ50件のケースと同じ3つのモデルのまま、新しいプロンプトでevalを再実行しましょう。

旧プロンプトと新プロンプトそれぞれでHaiku 4.5が正解したケースの割合。

5件の根拠のない答えはいずれも返ってこなくなり、Haiku 4.5は正解率の下限を上回るスコアになりました。

次の表では、実行コストは1つのモデルが50件のケースをすべて処理する価格であり、完了タスクあたりのコストはそれを正解数で割ったものです。

2026年8月の標準価格で、50件のケースに対する正解率90%の下限に対する、新プロンプトを使った3つすべてのモデルの結果。現在の価格を参照してください。

どのモデルも今では下限をクリアしているため、完了タスクあたりのコストで選ぶことになり、Haiku 4.5のコストが最も低くなります。

すべての列を確認し、アップグレードするかどうかを決める

修正しようとした列だけでなく、両方の実行結果のすべての列を確認しましょう。 ある種のケースに役立つ変更が別のケースを壊すこともあるため、変更のたびにそれを確認してください。

根拠のない答えの数と、正解から誤りに転じたケースがないかを数えます。Meridianは正解を1件も失いませんでした。

schedule_statusで失敗していた3件の典型的なケースは今回は通過しましたが、そのフィールドの行には何の変更も加えられていませんでした。モデルは同じケースに対しても実行ごとに異なる答えを出すことがあるため、スコアを信用する前に、すべての設定を2回以上実行してください。

スコアが動いている間はプロンプトの変更と再実行を続けましょう。正解率の下限に届かないままスコアが動かなくなったときは、モデルにその能力が欠けているということであり、そのときがアップグレードすべきタイミングです。

まとめ

1. まずは失敗したケースを、レポートの種類と誤ったフィールドごとにグループ分けして読むことから始めます。
2. 文書に答えがない場合に何を返すべきかを明記し、答えの前に引用を求めることで、プロンプトの抜け落ちを修正します。
3. 同じケースを2回以上再実行し、根拠のない答えが減り、正解が誤りに転じないことを確認します。
4. プロンプトの変更でスコアが動かなくなった場合にのみ、より大きなモデルへアップグレードします。