3行でいうと

  • OpenAIは、保存して呼び出す方式の「保存プロンプト」を廃止する予定で、代わりにプロンプトをアプリのコードに置き、コードレビュー、テスト、通常のデプロイで出す方法を勧めています。つまり、バージョン管理は、ふつうのソフトの開発のやり方に寄せる、ということです。
  • プロンプトを変えなくても、モデルを替えれば結果が変わります。OpenAIは本番のアプリを特定のスナップショットに固定するよう勧め、両社の文書とも、モデルが変わるときは評価（evals）で確かめ直すように書いています。
  • 回帰テストの道具として、OpenAIは自社のEvals基盤（2026年10月31日に既存のevalsが読み取り専用になり、11月30日に終了予定）の移行先にPromptfooを案内しています。ただしPromptfooは第三者のツールで、この記事では動かしていません。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書を読んでまとめたもので、実際に使って確かめた記録ではありません。情報は2026年10月16日に確認し、10月22日に読み直しました。変わることがあります。

先に結論

何が変わりうるのか

「プロンプトの回帰」の原因は、プロンプトの文章だけではありません。公式の文書から、少なくとも4つが読み取れます。

変わるもの 公式の文書の記載
プロンプトの文章 当然ですが、直せば挙動が変わります
モデルの版 OpenAI：同じ系統でも、スナップショットが違えば結果が違いうる。モデルのバージョンが変わるときは、評価で性能を追うよう勧められている
設定値と周辺の仕様 Anthropicのプロンプトの文書：新しい世代では、これまで通っていた書き方（最後の発話への書き足し〔prefill〕など）が400エラーになることがある
サービス側の処理 Anthropic：IDも重みも同じでも、振り分けや安全のための分類器などの変更で、挙動に小さな差が出うる

Anthropicのプロンプトの文書には、モデルの名前が付いた技法は、そのモデルで測ったものとして、別のモデルに使う前に自分のevalsで確かめ直すように、という趣旨の注意があります（短く引用すると「re-check it against your own evals」）。同じ文書は、Claude 4.6系の例として、以前のモデルでは起動が足りなかったツールが適切に起動するようになり、「迷ったら使え」という指示が過剰に働く、という例も挙げています。つまり、昔の注意書きが、新しいモデルでは逆効果になることがあります。

公式が書く「置き場所」：コードの中、ふつうの開発の流れで

OpenAIの「Prompt engineering」の文書によると、保存したプロンプトを呼び出す方式（reusable prompt objects）は廃止の予定です。2026年6月3日から作成の扱いが弱められ、v1/promptsは2026年11月30日に終了する、と書かれています。そのうえで、保存プロンプトの代わりに、次の方法が勧められています。

保存プロンプトを使っている人向けには、プロンプトをコードに移すための移行ガイド（prompt object migration guide）が案内されています。ガイドの中身は読んでいません。

見立てです。この方向は、プロンプトを「設定」ではなく「ソースコード」として扱う、という考え方だと思います。コードに置けば、Gitのような普通の仕組みで、いつ、誰が、なぜ直したかが残り、前の版に戻せます。一方、これはOpenAIの方針で、Anthropicの文書に同じ記述は見つかりませんでした。Anthropicは、プロンプトのバージョン管理の方法を、僕らが読んだページでは書いていません。

最小の仕組みを、4つの部品で考える

ここからは、公式の考え方を、僕らが4つの部品に整理したものです。

1. 記録する：プロンプトだけでなく「モデルID・設定」も一緒に

プロンプトの版だけを記録しても、結果は再現できません。Anthropicの「Model IDs and versioning」によると、IDは固定された版を指し、そのIDの寿命のあいだ中身は変わらず、エイリアスは指す先が変わりうる、とあります。OpenAIも、本番は特定のスナップショットに固定することを勧めています。ですから、プロンプトの版と、モデルID、設定値は、同じ変更の単位として記録するのが筋だと思います。

2. 問いを集める：テストセットと「成功の基準」

Anthropicの「Create strong empirical evaluations」は、成功の基準を、具体的（Specific）、測れる（Measurable）、達成できる（Achievable）、用途に合う（Relevant）、の4つで書くように勧めています。例として「1万件の投稿で、F1が0.85以上」が挙がっています。

評価の問いの作り方について、同じ文書は次のように書いています。

OpenAIの「Evaluation best practices」も、データは、本番のログ、人が作った例、合成データなどから集め、典型、端、敵対的な例を含めるように、と書いています。ログを残して、あとで試験用の例にする、という勧めもあります。

テストセットの作り方そのものは、別記事「自分用の評価（evals）は10問から始められる」で扱っています。

3. 採点する：コードで測れるものはコードで

Anthropicの文書は、採点の方法を3つに分けています。

方法 公式の評価（要約） 向くもの（僕らの例）
コードによる採点 最も速く、信頼でき、拡張しやすい。ただしニュアンスには弱い 完全一致、特定の語句を含むか
人による採点 最も柔軟で質が高いが、遅く費用が高い。できれば避ける 基準づくり、LLM採点の見直し
LLMによる採点 速く柔軟で、複雑な判断にも向く。ただし、信頼できるか先に試し、そのあと拡大する 口調、文脈の使い方など

LLMに採点させる場合のコツとして、Anthropicは、詳しく明確な基準を書く、出力を「correct」か「incorrect」、または1〜5のような決まった形にする、理由を考えさせる、採点には、答えを作ったモデルとは別のモデルを使うのが一般に最善、と書いています。OpenAIの文書は、位置バイアス（先に出た答えを好む）と冗長さバイアス（長い答えを好む）に注意すること、採点の前に理由を書かせること、人の注釈と安定して一致してから規模を広げること、を挙げています。

4. 回す：変更のたびに、自動で

OpenAIの文書は、評価を「早く、何度も」行うこと、すべての変更で評価を回し、本番を見て、評価の集合を育てていくことを勧めています。避けたい落とし穴として、perplexityやBLEUのような一般的な指標だけに頼ること、本番に似ていないデータ、「雰囲気（vibe）」だけの評価、出荷後に評価を足すことを挙げています。

道具の例：Promptfoo

OpenAIの評価基盤（Evals）は、公式の廃止予定のページによると、2026年10月31日に既存のevalsが読み取り専用になり、11月30日にダッシュボードとAPIが終了する予定です。OpenAIの案内ページ（cookbook）は、移行先としてPromptfooを挙げています。Promptfooは、評価と、攻撃を想定した検査（レッドチーム）のための、オープンソースのコマンドラインツールとライブラリです。設定ファイルをコードと一緒に置き、ローカルでも、自動の検査の仕組み（CI）でも動かせる、と書かれています。

PromptfooはOpenAIとは別の会社のツールで、この記事では動かしていません。ほかにも道具はあります。ここでは、公式文書がまとまって読めたので、例として挙げています。

設定ファイルpromptfooconfig.yamlは、公式の説明によると、次のキーでできています。

公式の説明に沿って、僕らが組んだ最小の例です。公式の例そのままではなく、動作確認はしていません。

# promptfooconfig.yaml（組み立て例。動作確認はしていない。valueの書き方は公式で確認していない）
prompts:
  - file://prompts/summarize_v2.txt
providers:
  - openai:gpt-6-luna
tests:
  - vars:
      input: "（テスト用の入力文）"
    assert:
      - type: contains-json
      - type: llm-rubric
        value: "（採点の基準を、明確な文で書く）"

実行のコマンドは、OpenAIの案内にあるとおり、promptfoo eval -c promptfooconfig.yaml --no-cacheで新しい実行ができ、promptfoo viewで結果を見られます。設定に誤りがあるときは、promptfoo validate config -c promptfooconfig.yamlで確かめられる、とあります。

PromptfooのCIの例（公式のページの要約）

PromptfooのCI/CDのページには、次のような構成が書かれています。

  • 実行：npx promptfoo@latest eval -c promptfooconfig.yaml -o results.json。-oにはJSON、HTML、JUnit XMLが指定でき、複数回指定できます。Node.jsは22.22.0以降（24 LTSを推奨）が前提です。
  • 起動の条件：例では、プロンプトか設定ファイルを変えたプルリクエストで動きます。プロンプトを直したときだけ評価が走る、という設計です。
  • 失敗の扱い：--fail-on-errorでテストの失敗があればビルドを失敗にできます。別の例として、結果の統計から合格率を計算し、95%を下回れば終了コード1にする、という書き方も載っています。
  • キャッシュ：キャッシュの有効期間はPROMPTFOO_CACHE_TTLで決め、例では86400秒（24時間）です。キャッシュのキーは、プロンプトと設定のハッシュで作る例になっています。プロンプトを変えたら、古いキャッシュの結果を使わないようにする狙いだと、僕らは読みました。
  • 実行の記録：--tag key=valueで、git.shaのような情報を付けられます。

変更の前後を比べる専用の機能は、このページには書かれていませんでした。前後を比べるには、それぞれの実行の結果（JSON）を自分で比べることになる、と僕らは読みました。これは推測で、公式の記述ではありません。

よくある失敗

公式の文書に書かれている落とし穴と、そこから考えられる点です。

見立て：最初の一歩

ここからは僕らの見立てです。公式が書いている内容と、僕らの考えは、分けて読んでください。

気をつけること

出典

更新履歴