私がいつも見かけるパターンがあります。開発者がプロンプトを書き、そこそこな出力が出ると、ある語を少し直してもう一度実行し、別の語をさらに直してまた実行します。30分後には、プロンプトは矛盾だらけになり、出力はわずかに良くなった程度です。
これはプロンプトの微調整です。生産的に感じます。でも違います。
代替案はフィードバックループです——準備に5分かかるだけです。
What's Wrong With Tweaking
微調整はランダムウォークによる最適化です。何か一つ変えて結果を観察し、直感で「より良いか」を判断します。問題点：
- ベースラインがない。 バージョン12がバージョン3より良いかどうかは分かりません。バージョン3の出力を保存していないからです。
- 基準がない。 「より良い」の定義がありません。短いほうが良いのでしょうか？ より詳細？ より正確？ 動いているターゲットを最適化していることになります。
- 再現性がない。 モデルは確率的です。同じプロンプトでも、実行のたびに異なる結果が出ます。たまたま良い出力が出たからといって、そのプロンプトが良いとは限りません。
The Feedback Loop (5-Minute Setup)
Step 1: Define "Good"
プロンプトに触る前に、「良い出力」がどのようなものかを書き出してください。具体的に：
## Acceptance Criteria
- 出力が有効なJSONであること
- 箇条書きがちょうど3つ含まれること
- 各箇条書きは20語未満であること
- マーケティング表現（「革命的」「画期的」など）がないこと
- すべてを要約するのではなく、主な不満を捉えていること
これには60秒かかるだけで、手探りで迷子になるのを防げます。
Step 2: Create 3 Test Inputs
実際のユースケースを表す入力を3つ選びます。おもちゃの例ではなく、本物のデータです：
inputs/
input-1.txt # 短いフィードバック：1つの不満
input-2.txt # 長いフィードバック：複数の問題
input-3.txt # エッジケース：ポジティブなフィードバック（不満なし）
Step 3: Run All Three, Score Against Criteria
3つすべての入力に対してプロンプトを実行します。各出力について、受け入れ基準と照合します：
input-1: ✅ JSON ✅ 3 bullets ✅ under 20 words ✅ no marketing ✅ main complaint
input-2: ✅ JSON ❌ 4 bullets ✅ under 20 words ✅ no marketing ✅ main complaint
input-3: ✅ JSON ✅ 3 bullets ✅ under 20 words ❌ "amazing" ❌ no complaint to find
これで、何が壊れているのかがはっきり分かりました：箇条書き数の強制と、ポジティブ・フィードバックのエッジケースです。
Step 4: Fix What Failed
失敗した点に対処するようにプロンプトを変更します。「良くして」ではなく、箇条書き数の問題を直します：
Return EXACTLY 3 bullet points. Not 2, not 4.
If the feedback is positive with no complaints, return:
[{"point": "No actionable complaints identified"}]
Step 5: Re-Run, Re-Score
3つすべての入力をもう一度実行します。基準に照らしてチェックしてください。すべて合格なら完了です。新たに何かが壊れたら、その部分を直します。
Why This Works
フィードバックループは、直感を情報に置き換えます。「うーん、なんか良さそう」ではなく、「3入力中2入力がすべての基準に合格」という形で得られます。
さらに、副次的に評価用セット（eval set）も構築されます。次にモデルが更新されたり、プロンプトを変更したりしたとき、同じ3つの入力を実行して、退行（回帰）が起きていないかを確認できます。これで無料の回帰テストが手に入りました。
The Time Math
| アプローチ | 費やした時間 | 確信度 |
|---|---|---|
| 30分かけて微調整 | 30分 | 低い（「良くなった気がする？」） |
| フィードバックループ | 10分のセットアップ + 繰り返し1回につき5分 | 高い（基準に対する合否） |
フィードバックループはより速いうえに、再利用可能なテスト基盤を提供します。
Practical Tips
- 30個ではなく3個から始める。 追加はいつでもできます。3つで、ほとんどの問題を見つけるのに十分です。
- プロンプトより先に基準を書く。 本当に欲しいものについて考えることを強制してくれます。
-
プロンプトの各バージョンを保存する。 たとえば
prompt-v1.md\、prompt-v2.md\。後で差分（diff）を取りたくなるはずです。 - 重要なときはループを自動化する。 このプロンプトが本番で動くなら、テスト入力をCIで実行するスクリプトにしてしまいましょう。
The One-Liner
手作業でプロンプトの微調整に5分以上かけているなら、それはプロンプトの問題ではありません——プロセスの問題です。ループを作りましょう。
プロンプトのテスト環境はどうしていますか？ 人々は評価（eval）を回しているのか、それとも主に直感で進めているのか、気になります。
