PromptAtlasリソース · 日本語

プロンプトのバージョン管理·履歴・比較・復元の方法

良いプロンプトは、一度で完成することはほとんどありません。言い回しを直し、条件を足し、例を差し替える。ところが三回いじった頃には、出力は最初より悪くなっているのに、戻る手段がない、ということが起こります。バージョン管理を使えば、意味のある変更ごとにスナップショットが保存されます。今の内容と以前の内容を比較し、実際にうまくいっていた版に戻し、どの編集が効いたのかを当てずっぽうではなく確かめられます。

使うタイミング

  • うまく動いていたプロンプトを変えたら品質が落ちてしまい、先週使っていた言い回しにそっくり戻したいとき。
  • 共有しているプロンプトを複数人で編集していて、誰がいつ何をなぜ変えたのかがわかる履歴が必要なとき。
  • システムプロンプトの二つの言い回しを試していて、片方を上書きせず両方の版を並べて残しておきたいとき。
  • モデルの更新(たとえばClaude 3.5から新しい版へ)で挙動が変わり、元の版を残したままモデル別の版を分岐させたいとき。
  • 素早く試行錯誤していて、また実験を始める前に「ここまでは大丈夫」という基準点にラベルを付けておきたいとき。

避けたいミス

  • うまくいっている版をその場で上書きしてしまう。新しい言い回しを古いものに貼り付けた瞬間、実際に機能していた表現は消えます。後悔してからではなく、意味のある編集をする前にスナップショットを保存しましょう。
  • プロンプト本文だけを管理し、その周りの文脈を残さない。モデル、temperature、埋めた{variables}はすべて結果の一部です。各版と一緒に記録しないと、そのスナップショットは再現できません。
  • 「プロンプト改善」のような曖昧なメモを書く。六つ版が進むと、どの変更でJSON出力が直ったのか判別できなくなります。何かを変えたという事実だけでなく、何をなぜ変えたのかを書きましょう。
  • 一打鍵ごとに新しい版を作ってしまう。履歴がノイズだらけになります。区切りは本当の節目(試した言い回し、出荷した修正)で付け、カンマを一つ動かすたびに付けないこと。

コピーできるプロンプト

01
変更履歴(チェンジログ)の項目を書く

あなたはバージョン管理されたプロンプトライブラリを保守するプロンプトエンジニアです。以下の私のプロンプトの旧版と新版を比較し、新版のチェンジログ項目を一つ書いてください。旧版:{old_prompt}。新版:{new_prompt}。直前の版が{last_version}だったことを踏まえ、セマンティックバージョニングによる版ラベル、一行の要約、変更点の箇条書き、そしてこのプロンプトを再利用している人にとって破壊的変更かどうかの注記、という形式でまとめてください。120語以内で、事実のみを書き、変更を称賛しないこと。

02
二つの版の挙動の違いを説明する

あなたはプロンプトのQAレビュアーです。ここに同じプロンプトの二つの版があります。版A:{version_a}。版B:{version_b}。どちらも次の入力で動かすとします:{test_input}。実際には実行せず、モデルの出力がAとBでどう違うかを予測してください。形式、トーン、詳しさの度合い、そして片方だけが課してもう片方が外している制約に注目します。違いはAspect・版A・版Bの三列の表で示してください。最後に、{use_case}向けにはどちらの版を出荷するほうが安全か、その理由を一文で述べて締めくくること。

03
上げるべき版番号を判断する

あなたはセマンティックバージョニング(MAJOR.MINOR.PATCH)でプロンプトを管理しています。現在の版は{current_version}です。行った変更はこちら:{change_description}。次のルールでMAJOR・MINOR・PATCHのどれを上げるか判断してください。MAJORは出力の形や挙動が既存ユーザーにとって壊れる形で変わる場合、MINORは後方互換を保ったまま新機能を追加した場合、PATCHは挙動を変えない言い回しや明確さの修正の場合です。返答は新しい版番号、上げる種類、一文の根拠のみにすること。

04
保存前にプロンプトの変更をレビューする

あなたは共有プロンプトへの変更を承認する慎重なレビュアーです。新しい版として保存する前に、以下の編集をレビューしてください。現在の版:{current_prompt}。変更案:{new_prompt}。編集の目的:{goal}。互いに矛盾するようになった指示、うっかり削除された制約、もう解決されない{placeholders}、述べられた目的を超えたスコープの拡大がないか確認します。判定はAPPROVEかREQUEST CHANGESのどちらかを出力し、続けて重要度順に並べた問題点の短い箇条書きを示してください。REQUEST CHANGESの場合は、各問題を解決する最小限の修正案を提示すること。

05
プロンプトの版にリグレッションテストを用意する

あなたは、今後の版がひそかに壊れないようリグレッションテストを用意しています。プロンプトはこちら:{prompt}。その役割は:{intended_behavior}です。今後のどの版も必ず通すべきテストケースを6つ作ってください。それぞれに短い名前、投入する入力、そして出力に何が含まれていなければならないか(または決して含まれてはならないか)を示す合格条件を書きます。通常のケース、{variables}が欠けているエッジケース、そしてプロンプトに出力形式を崩させることを狙った1ケースを含めること。ケースは番号付きリストで返してください。

PromptAtlasでの保存方法

  1. 仕事やチャネルごとにフォルダを作る。
  2. 後で検索できる明確なタグを付ける。
  3. 変わる要素を変数にする。
  4. 有用な試行を消さず、より良い版を保存する。
  5. 必要なときにライブラリをエクスポートする。

よくある質問

プロンプトのバージョン管理とは何ですか?

プロンプトのバージョン管理とは、変化していくプロンプトの履歴を保存しておくことです。意味のある編集ごとにスナップショットができ、それを閲覧・比較・復元できます。コードのバージョン管理という考え方を、プロンプトの言い回しに応用したものです。

ただコピーを保存するのと、バージョン管理は何が違うのですか?

コピーを保存するとバラバラなファイルが増えるだけですが、バージョン管理は一本の時系列になります。管理ツールはスナップショットを一つのプロンプトに紐づけ、版どうしの差分を示し、なぜ変えたかを記録し、「prompt-final-v3-本当に最終.txt」を探し回らずワンクリックで復元できます。

プロンプトにセマンティックバージョニング(v1.2.0)を使うべきですか?

使ってもよく、他の人がそのプロンプトに依存している場合は役立ちます。簡単な目安として、挙動が壊れる変更でメジャー番号、機能を追加したらマイナー番号、言い回しの微調整でパッチ番号を上げます。個人用なら、日時と短いラベルで十分なことがほとんどです。

プロンプト本文のほかに何を記録すべきですか?

想定したモデルと設定、何をなぜ変えたかの短いメモ、できれば入力例と実際に得られた出力を記録しましょう。その文脈があるからこそ、何か月か経って戻ってきたときに、なぜ古い版がそういう挙動をしたのかを理解できます。

プロンプトライブラリを作る

うまくいくプロンプトを保存し、変数を追加し、バージョンを残し、数秒で見つけましょう。

無料で始める