🦑

プロンプト改善が何倍も楽になる、プロンプト改善の自動化も行える評価ツール「Opik」を試す

musoukun

2026/06/29に公開

 TL;DRAIの出力を採点するツール（LLM評価ツール）はいくつもありますが、Opikというツールは採点に加えて、GEPA というしくみでプロンプトを自動で良くするところまで含んでいます。
この記事では、文章を意味で分類する処理を題材に、Opik での採点のやり方と、プロンプトの自動改善のやり方を紹介します。

 プロンプトの評価ツールにはいろいろあるプロンプト評価ツールとは、AIに何かを処理させたとき、その出力が決めたルールを満たしているかを自動で点数や合否にして残しておく道具です。
※代表的なのは、Langfuseなどがありますね。
これらのツールは主に、モデルやプロンプトを変えたあとに「前より良くなったか」を比べるために使います。
多くのツールは「採点する」ところまでが中心です。
点数や合否は出ますが、悪かったプロンプトを直すのは人が1個ずつ手で書き換える形になります。

 Opikは自動改善ができる今回試した Opik は、採点だけでなく
「プロンプトを自動で書き換えて良いものを探すしくみ（GEPA）」　まで含んでいるのが特徴です。この記事では、採点のやり方と自動改善のやり方を順番に見ていきます。
今回は、Opik で採点を動かし、さらにプロンプトの自動改善を実際に動かしてみるとどうなるかを試してみました。

 「文章を意味で分類する処理」で試してみる題材にしたのは、複数の文章を、その意味をもとに

いくつかの分類（カテゴリ）に分けて、それぞれの分類に短い名前を付ける処理です。
採点したい項目は2つにしました。
分類の名前は10文字以内になっているか（文字数はいったん仮で決めた値）
分類の名前が体言止め（名詞で言い切る形）になっているか

 プロンプトの評価テストケースを登録して採点し、結果を一覧で見る、という流れは画面でそろっています。実験ごとに、合格率（Pass rate）が100%かどうか、1回あたりのコスト、処理時間が表に並びます。

 プロンプトの採点方法採点の方式は大きく2つあります。

コードで数える方式 … 「文字数が10文字以内か」のように、答えがはっきり決まる項目を、コードで点数にします。

AIに文章で判断させる方式（G-Eval） … 「分け方が意味的に妥当か」のように、言葉で判断する項目を、AIが点数や合否で返します。
この2つはどちらか一方を選ぶものではなく、1回の評価でまとめて並べられます。実際、1つの項目に、コードで数える採点（文字数・件数・体言止め）と、AIに採点させる採点（llm_judge）が同時に出ました。
なお Opik のテスト画面には Test Suites と Experiments という2つの入口があり、用途が違います。
Test Suites … 決めた重要なケースが壊れていないかを、合否で毎回チェックするためのもの（回帰テスト）。どのケースのどのルールが落ちたか分かるので、直す手がかりになります。

Experiments … データセット全体の品質を数値で測り、モデルやプロンプトの版を横並びで比較するためのもの。全体としてどれくらい良いか、前の版より上がったかを数字で追えます。

採点方式（コードで数える/AIに判断させる）はどちらの入口でも使え、Test Suites の実行結果も Experiment として記録されます。

 プロンプトの自動改善Opik には GEPA というプロンプトの自動改善のしくみが入っています。人が1個ずつ手で書き換えなくても、プロンプトの言い回しを自動で何通りも試して、良いものを探してくれます。設定は画面から入力でき、APIやコマンドからも呼び出せます。

 左メニューのOptimization runsから設定を行うPromptの自動改善を行う場合はOptimization runsから以下の設定画面を開きます。

※各項目は画像参照


 GEPAとはGEPA は「Genetic-Pareto（ジェネティック・パレート）」の略で、プロンプトを自動で書き換えて良くしていく手法のひとつです。論文で提案されたもので、いくつかの評価ツールに取り込まれています。

 普通の改善と違う点ふつうの自動改善は、採点の数字（点数や合否）だけを見て、当たりが出るまで書き換えを試します。
GEPA が違うのは、点数だけでなく「どこで・なぜうまくいかなかったか」という手がかり（実行の記録やエラーの内容、AIの考えた筋道）を文章として読み取り、そこを狙って書き換える点です。やみくもに変えるのではなく、原因に当たりを付けて直していくイメージです。
もうひとつの特徴は、いろいろな書き方を残して試すことで、特定のケースだけに強い偏ったプロンプトになりにくくしています。

 利用したプロンプト改善の採点方法採点方法は以下のような例があります。
「正解と一致するか」のほか、AIに採点させる方式（G-Eval）
コードで点数を計算する方式（label_len_metric）
が選べます。
今回は、分類の名前の文字数をコードで1文字ずつ数える採点方法（label_len_metric）で回しました。

 プロンプトの自動改善文字数の達成率が 0% から 100% に上がりました。処理時間は 37.2秒 → 38.1秒（+2%）、1回あたりのコストは $0.0019 → $0.0026（+37%）と少し増えています。
改善後のプロンプトは、元のプロンプトとの差分（消した部分・足した部分）が色分けで見えます。人が文面を書き換えなくても、採点が上がるようにプロンプトが書き換わっていきました。

 採点方法を選ぶのが重要な理由先ほど記載した採点基準に関して、ここの設定によって、自動改善が効くかどうかが大きく変わります。

 改善がうまくいかない例「10文字以内か」を AI に採点させる方式（G-Eval）で試しました。
ところが9ステップ回しても採点は10%のまま横ばいで、プロンプトは良くなりませんでした。
実データを確認すると、各ラベルは実際には4〜5文字（すべて10文字以内）なのに、G-Eval はどの出力にも同じ約0.1（10%）を返していました。つまり採点が出力を正しく測れておらず、ほぼ一定値しか出していなかったということです。
こうなると「どこを直せば点が上がるか」の手がかりが無いため、それを頼りに直す自動改善も空回りして、横ばいになります。
数える項目（文字数・件数）は、AI に判断させるより、コードで1文字ずつ数える採点にするほうが確実でした。
文字数・件数のように数える項目 → コードで点数を計算する方法。G-Eval（AI採点）は不向き
体言止めか、中身が良いか、のように言葉で判断する項目 → G-Eval が向く

 まとめものさしを項目に合わせることが、自動改善をきちんと効かせる前提でした。

最近はDSPyで使われている、ACEっていうプロンプトの改善手法もかなり良いみたいですよね。