プロンプトのバージョン管理｜変更理由と評価結果を一緒に残す

プロンプトのバージョン管理では、テンプレートの差分に加え、テンプレート版、モデル識別子、評価セット識別子、変更理由、評価実行と結果、配備判断を一つのリリース記録に紐付けます。一行を一つの配備判断として固定することで、初めて「どの組み合わせを、なぜ出したか」を追跡できます。

実行条件は、必要な識別子と変更理由がそろい、所定の評価セットで結果を確認できることです。ただし、何を合格とするか、誰が承認するかは用途とリスクで変わります。そこで先に台帳の形を固定し、判断表でリリース候補・保留・切り戻し候補を分けます。

プロンプトのバージョン管理は「組み合わせ」を記録する

テンプレートだけに版番号を付けても、出力を再確認できるとは限りません。同じテンプレート名でも、組み合わせたモデルや評価に使った入力群が異なれば、配備時の判断根拠は別物です。逆に、モデルを更新してテンプレートを変えなかった場合も、評価を経ずに「プロンプト変更なし」と扱えば、リリース単位の確認が抜けます。

ここで管理対象を二つに分けます。

• プロンプト資産：テンプレート本文、変数、テンプレート版、利用するモデル識別子
• リリース記録：プロンプト資産に評価セット、評価実行、結果、変更理由、配備判断を加えた記録

前者は再利用する資産の保存、後者は本番へ出す組み合わせの判断です。この区別を置くと、プロンプトの書き方を改善する作業と、変更を安全に配備する管理を混ぜずに済みます。

2026年9月21日時点で、NIST AI RMF Playbookは、システム変更について、変更理由と、変更をどのように実施・テスト・配備したかを含むデータベースの維持をSuggested Actionsとして挙げています。同じく、継続的改善のための版履歴情報とメタデータの維持も挙げています。ここでの根拠はSuggested Actionsであり、この後に示す台帳項目は原典所定の分類・義務ではありません。

この一般原則をプロンプト運用へ適用するなら、本文の差分に加えて「変更したもの」「確かめたもの」「出したもの」を同じリリースへ結び付ける必要があります。

リリース記録に残す項目

次の台帳は、出典の一般原則を基にした実務上の提案であり、原典所定の分類・義務ではありません。

各項目は、埋めたうえで相互参照できる状態にします。評価結果だけが共有フォルダにあり、台帳から対象のテンプレート版を特定できなければ、後から同じ判断をたどれません。テンプレート版があっても、変更理由が「改善」の一語なら、何を確かめる評価だったかが曖昧になります。

判断表でリリース可否を分ける

次の判断表も、出典の一般原則を基にした実務上の提案で、原典所定の分類・義務ではありません。具体的な評価のしきい値と承認者は、用途・リスクに応じて組織が定めます。

「評価済み」という印だけでは、リリース候補になりません。評価セットと評価実行を特定でき、その実行が対象のテンプレート版とモデルに結び付いていることが条件です。「切り戻し候補」は自動復元の命令を意味しません。配備後の問題を該当版へ紐付け、修正と復元のどちらを検討するかを判断可能にする分類です。

たとえば、回答形式を安定させるためテンプレートを変更したなら、変更理由には対象の形式と変更箇所を残します。評価セットは、その形式を確認する入力群の識別子で固定します。結果への参照は、対象テンプレート版とモデル識別子を含む評価実行につなぎます。どれかが欠ければ、結果が良さそうに見えても保留です。この条件の役割は判断根拠の取り違えを避けることにあり、品質保証には別途の基準が要ります。

製品固有の版管理と組織の台帳を分ける

製品に版管理機能があっても、それだけでリリース記録が完成するとは限りません。2026年9月21日時点のGoogle Cloud公式Prompt managementでは、PromptDataのmodelは必須属性で、プロンプトリソース配下にcreate_versionで版を作成し、prompt_idとversion_idを指定して特定版を取得できます。適用範囲はGoogle Cloud製品に限られ、他製品の機能や項目は各公式仕様での確認が必要です。

また、同日時点のGoogle Cloud公式View and interpret evaluation resultsの例では、評価タスクにデータセットと指標を与え、評価時にモデルと実験実行を指定します。結果には集約指標、入力・応答・説明・行単位の指標結果を含む表、実験名と実験実行名のメタデータが含まれます。これも同製品における要素の例です。

したがって、製品内ではテンプレートとモデルの識別に使える機能を利用し、評価セット、評価実行、変更理由、承認判断は組織のリリース台帳で明示的に紐付ける、という分担が現実的です。この分担は、確認できた製品要素とNISTの変更記録原則を基にした実務上の提案です。利用製品が異なる場合は、機能名の一致よりも、台帳に必要な識別子を取得できるかを確かめます。

評価する時点もリリース条件に含める

評価セットを一度作って終わりにすると、どの変更で再評価するかが担当者の判断に委ねられます。NIST AI RMF Playbookは2026年9月21日時点で、AIライフサイクルの主要段階において、システム影響と更新頻度に結び付けてTEVV（試験・評価・検証・妥当性確認）を定期的に適用することをSuggested Actionsとして挙げています。

この原則から、リリース台帳には「何を評価したか」と「この変更で再評価が必要か」を判断する入口を置けます。テンプレート、モデル識別子、評価セットのいずれを変更した場合も、新しいリリース記録を起こします。再評価の頻度や範囲は一律に決めず、用途への影響と更新の頻度を踏まえて組織が定めます。

AI導入全体の役割や判断点が未整理なら、先にAI導入の進め方を整理するガイドで課題定義から定着までの流れをそろえると、台帳の承認者を置きやすくなります。検証用の構成を本番へ移す境界を決める場合は、AI PoCから本番運用へ進める条件も合わせて確認できます。

運用開始時に決める三つの条件

台帳を作る前に、少なくとも次の条件を合意します。

• 識別条件：テンプレート版、モデル、評価セット、評価実行を何の識別子で固定するか
• 判定条件：評価結果のどこを見て、誰がリリース候補または保留とするか
• 復元条件：配備後の問題をどう該当リリースへ結び付け、修正と復元を誰が検討するか

この三つが決まれば、リリース記録は配備判断を再現する索引になります。具体的なしきい値や承認者が未定の状態では、台帳の項目を増やしても実行条件は完成しません。

プロンプトのバージョン管理は、テンプレート版・モデル・評価セットを同じリリースへ結び付け、変更理由と該当する評価結果から配備可否を判断できる状態で始めます。まず一つの変更を判断表へ通し、識別できない項目は保留にする。その運用を課題定義、実装、定着までつなげたい場合は、FDE型支援の無料相談・AI活用診断で、自社の用途とリスクに合う台帳と承認条件を整理できます。

FDE・AI実装ガイドへ戻る