prompt-optimize

プロンプト最適化ループ

プロンプト向けの進化的オプティマイザー（OpenEvolve / AlphaEvolve スタイル）です。最適化対象は、ユーザーのシステムに入力されるプロンプトです。フィードバック信号は、ユーザー自身の評価コマンドが出力するスカラー指標です。各イテレーションでは品質向上を目的とした編集を1つ提案し、評価を再実行して、指標が改善した場合に限り編集を採用します。これを繰り返して、より高いスコアを目指してプロンプトを進化させます。評価はループが実行するものの編集はしないブラックボックスのオラクルです。そのため、数値を不正に操作するのではなく、本当に重要な要素に沿って最適化できます。

使用する場合

ユーザーがプロンプトと、そのプロンプトを使ったシステムを採点するコマンドを用意しており、スコアを上げるためにプロンプトを改善したい場合に使用します。通常は各ラウンドで、プロンプトの最大の弱点を診断し、それに対処するオペレーターを1つ適用します。評価のフィードバックが別の方向を示している場合は、そちらに従ってください。何もない状態からプロンプトを作成する場合、重みやハイパーパラメーターを調整する場合、比較するスコアなしで手動編集を1回だけ行う場合には適していません。

セットアップ

バインディングを対話形式で解決します。作業ディレクトリに loop.run.yaml がある場合は読み込み、値を1行で確認して、ループに進みます。ない場合は、Claude Code（AskUserQuestion ツールを利用可能）の場合、各バインディングの値として考えられるものを推定し、推奨値として提示します。それ以外のホストでは、それぞれを引用符付きのプレーンテキストの質問として尋ねます。その後、loop.run.yaml（形式：examples/run.example.yaml）を書き込み、ほかのファイルを作成する前に値を確認します。

バインディング	意味	デフォルト	推定方法
<prompt_file>	最適化するプロンプト — ループが進化させる成果物	—	作業ディレクトリをスキャンし、評価で読み込まれるプロンプト／テンプレートファイルを探す
<eval_cmd>	必須。 現在の <prompt_file> を採点するコマンド。指標を出力します（出力形式については以下を参照）。ブラックボックスとして扱い、編集はしません	—	ユーザーに尋ねる。eval／score／bench スクリプトを探す
<objective>	maximize または minimize と、指標が測定する内容を説明する1行	maximize	ユーザーに尋ねる
<target>	早期終了するための任意のスコア	—	ユーザーに尋ねる。指定がなければ未バインドのままにする
<sandbox_root>	プロンプトのスナップショットと台帳を保存する場所	./sandbox	—
<budget>	最大イテレーション数	10	—
<patience>	改善しないイテレーションが連続で N 回続いたら停止する（プラトー）	3	—

評価の出力形式。 <eval_cmd> は最終行に、JSON オブジェクト {"score": <number>, "feedback": "<optional notes/errors>", ...any extra metrics...} または数値のみを出力する必要があります。<objective> が minimize でない限り、スコアは高いほど優れています。feedback フィールドがある場合は、最も有益なシグナルです。次の編集を決める際に、AlphaEvolve のアーティファクトのサイドチャネルのように読み取ってください。

評価はユーザーの環境で実行されます。 <eval_cmd> は推論エンドポイントや、ユーザーがインストールした任意のツールを呼び出す場合があります。ループはシェル経由でコマンドを実行し、最終行を読み取るだけです。プロンプトを実行するのがあなた自身である場合（別のエンドポイントを使わない対話型開発の場合）は、まずユーザーの評価用入力に対して現在のプロンプトを実行し、出力を <eval_cmd> が読み込む場所に書き込んでから、<eval_cmd> を実行して採点します。

ループ

このチェックリストをコピーして、項目にチェックを付けてください。

• イテレーション 0 — ベースライン：<eval_cmd> を <prompt_file> に対して実行し、そのスコアを現在のベストとして記録し、プロンプトのスナップショットを保存します。
• 最新のスコア、評価フィードバック、履歴から、プロンプトの最大の弱点を 1 つ診断します。
• 対象を絞った編集を 1 つ（ツールキットのオペレーターを 1 つ）<prompt_file> に適用します。
• 測定：<eval_cmd> を再実行し、最後の行から新しいスコアを読み取ります。
• 指標が改善した場合は維持します（評価が確率的な場合は、余裕を持たせます）。それ以外の場合は、ベストのスナップショットに戻します。
• 台帳に行を追加します。行き詰まった場合は、以前の高スコアのバリアントから分岐します。<target>、プラトー（<patience>）、または <budget> に達したら停止します。

イテレーション 0 — ベースライン。 <eval_cmd> を実行し、そのスコアをベストとして記録して、<prompt_file> を <sandbox_root>/iter0/ にスナップショットとして保存し、履歴（各行に {iter, edit, score, feedback}）を開始します。

その後、停止条件（目標、プラトー、または予算）に達するまで、次の手順を繰り返します。

1. 診断します。 最新のスコア、<eval_cmd> のフィードバック、最近の履歴から、プロンプトの現在の最大の弱点、つまり指標を最も下げている可能性が高い要因を 1 つ挙げます。

2. 対象を絞った編集を 1 つ行います — その弱点に対処するツールキットのオペレーターを選びます。

   • 明確さ — 曖昧さ、矛盾、漠然とした表現を取り除きます。
   • コンテキスト — タスクに必要な、不足しているドメイン知識、定義、背景情報を補います。
   • 具体性 — 指示を具体的にし、出力形式を明確に定め、「良い」状態を定義します。
   • 構成 — プロンプトを手順やセクションに分けて順序立て、短いチェックリストを追加します。
   • 例 — 望ましい入力 → 出力の例を 1 つまたは 2 つ追加します。
   • 分解 — 複雑な指示を、順序が明確な複数の手順に分割します。
   • ガードレール — エッジケースと避けるべきことを明記します。

   指標への効果を特定できるよう、イテレーションごとに変更は 1 つだけにします。

3. 測定します。 編集したプロンプトを <sandbox_root>/iter<N>/ にスナップショットとして保存し、<eval_cmd> を実行して、最後の行から新しいスコアを読み取ります。

4. 維持するか、元に戻します。 <objective> に従って指標が改善した場合は維持します（評価が確率的な場合は、ノイズだけで維持と判断しないよう、小さなマージンを設けます）。それ以外の場合は、<prompt_file> を直前のベストのスナップショットに戻します。どちらの場合も、履歴に {edit, score, feedback} を追加します。

5. 局所最適から抜け出します。 数回のイテレーションでスコアが改善しない場合は、細かな調整を続けるのをやめ、以前の高スコアのスナップショットから分岐するか、より大きな構成変更（異なる分解方法や、新しい例のセット）を試します。同じ局所的な山を登り続けるより、多様性を優先します。

停止時には、ベストのプロンプトを <prompt_file> に復元し、スコアの推移、指標が変化した編集（および変化しなかった編集）、最終的なプロンプトを報告します。

台帳

<sandbox_root>/ledger.tsv にタブ区切りで記録し、テキストにカンマは使用しません。ヘッダー：

iter	score	status	edit

status は {baseline, keep, revert} のいずれかです。例（指標 = タスクの正解率、最大化）：

iter	score	status	edit
0	0.42	baseline	original prompt
1	0.61	keep	specificity: define each output label and the exact output format
2	0.61	revert	examples: add 3 few-shot demos — no metric gain
3	0.78	keep	context: add the domain rules the task assumes but never states

最後のイテレーションとは限らないため、ベストのイテレーションを報告します。

制約

• 指標はユーザーのものです。 <eval_cmd>、そのデータ、またはその採点方法は編集しないでください。そうするのはプロンプトの改善ではなく、数値を不正に操作することになり、このループには評価だけが唯一のグラウンドトゥルースです。
• プロンプトだけを最適化し、タスクの意図を維持します。 改善するのはタスクの指示方法であり、依頼内容ではありません。実際の使用に支障をきたすような評価上の癖を利用するよう、プロンプトを調整しないでください。
• イテレーションごとに編集は 1 つだけとし、1 つのサンプルではなく <eval_cmd> 全体を再実行して指標を比較します。これにより、スコアの変化をその 1 つの編集に帰属させられます。
• 最後ではなく、ベストのバリアントを報告します。 サンドボックスは自己完結型であり、../ による外部への移動は禁止です。
• 続行するかどうかを尋ねるためにループを中断しないでください。目標、プラトー、または予算に達するまで実行します。

停止条件

• 目標 — スコアが <target> に到達します（設定されている場合）。
• 停滞 — <patience> 回連続で、最良スコアを更新するイテレーションがありません（改善しなかったイテレーションはすべて待機回数にカウントされ、採用するとリセットされます）。
• 予算 — <budget> 回のイテレーションに到達します。