広告レポート用プロンプトの版管理｜改善前後を比較できる残し方
広告レポートのプロンプト管理では、文章の修正後に出力が本当に良くなったかを判定できる状態が必要です。新しい版の文章が読みやすく見えても、入力データや実行条件まで変わっていれば、差がプロンプトによるものか判断できません。評価する箇所や採用基準が毎回違えば、見落とした劣化も残ります。
そこで、入力データ版・プロンプト版・実行条件・評価対象・評価基準・採用理由・戻す条件を一組で変更台帳に残します。入力と実行条件をそろえ、先に決めた評価基準で旧版と候補版を必要な回数比べ、採用理由を差分に結び付け、想定外の出力が出たときの復帰条件まで決める。この形なら、比較結果を根拠に採否を決められます。
ただし、台帳に項目を増やすだけでは足りません。どの条件なら採用し、どの条件なら旧版へ戻すのかを、レポート業務で確認できる言葉にする必要があります。
広告レポートのプロンプト管理で版だけを残しても比較できない
プロンプト本文に版名を付けても、その版へ渡した入力データや利用したモデル版、生成設定が特定できなければ再比較できません。「要約が良くなった」という記録も、判断した箇所と採用基準が曖昧なため、担当者によって評価が変わります。プロンプト、入力、実行条件、評価対象、評価基準、判断を一組にして版管理の単位とします。
2026年9月29日時点で、NIST AI Risk Management Framework 1.0のMEASURE機能は、AIシステムについて導入前と運用中に定期的なテストを行い、性能ベンチマークと比較し、結果を正式に報告・文書化する測定プロセスを扱っています。同資料のMEASURE 2.1と2.3では、テストセット、指標、評価に用いたツールを記録し、導入環境に近い条件で定性的または定量的に測定して、結果を文書化するよう示しています。
同資料は、特定分野や特定ユースケースに限定されない任意利用の枠組みで、広告レポート専用の規則ではありません。以下ではNISTの項目を必須要件として転用せず、広告代理店のレポート業務へ落とし込んだ「運用上の提案」として扱います。
変更台帳は七つの判断材料を一行にそろえる
一回の修正を一行として、少なくとも次の七項目を同時に記録します。中心になるのは「いつ、誰が変えたか」よりも、比較と復帰に必要な条件です。
| 判断材料 | 台帳に残す内容 | 記入時の問い |
|---|---|---|
| 入力データ版 | 比較に使った入力を識別できる名称や保存先 | 旧版と候補版へ同じ内容を渡したか |
| プロンプト版 | 旧版と候補版を区別できる版名、変更箇所 | 旧版から何を変えた版なのか特定できるか |
| 実行条件 | 利用サービス、モデル名・版、取得できる生成設定、ツールの有無、実行日時 | プロンプト以外の条件をそろえたか |
| 評価対象 | 見出し、要約、示唆候補など、今回判定する範囲 | どこを見て採否を決めるか |
| 評価基準 | 採用条件、許容しない誤り、維持項目、判定者 | 何を満たせば採用できるか |
| 採用理由 | 旧版との差と、その差を採用できる根拠 | 観察した差を具体的に説明できるか |
| 戻す条件 | 旧版へ戻す出力上の条件と、戻す版 | 運用中に何が起きたら採用を取り消すか |
この表は運用上の提案です。七項目を一連の判断としてつなぐと、「入力と実行条件をそろえて対象箇所を評価した結果、基準を満たしたため候補版を採用し、この状態なら旧版へ戻す」という筋道が残ります。空欄を埋める作業にとどめず、前後の項目が対応しているかを確認します。
入力データ版には、比較に使った入力を後から取り違えないための識別子を記します。データの内容そのものを台帳へ複製する欄ではありません。プロンプト版には全文に加えて、旧版からの変更箇所が分かる情報を添えます。実行条件には、サービス名、モデル名と版、temperature・top-P・top-K・seedなど取得できる生成設定、外部ツールの有無を残します。入力、指示、実行条件を分けることで、何を変えた比較なのかを追いやすくなります。
評価対象と実行条件を固定して変更前後を比べる
一度の比較でレポート全体を漠然と眺めると、表現の滑らかさに注意が寄り、別の箇所の劣化を見逃しやすくなります。変更の目的に合わせて評価対象を先に限定します。たとえば、事実の要約を直した場合は要約部分、示唆候補の指示を直した場合は示唆候補を評価対象にします。これらは変更と判定範囲を結ぶための例で、評価項目を網羅する一覧ではありません。
比較時は、旧版と候補版へ同じ評価用入力データを渡し、利用サービス、モデル版、取得できる生成設定、ツールの有無をそろえます。入力または実行条件を変える場合は、プロンプト変更と混ぜず、別の比較として台帳に行を分けます。ただし、生成AIは同じ条件でも出力が変わり得ます。利用中のサービスが再現性を保証しない場合は、1回ずつの出力差をプロンプトだけへ帰属させず、複数の代表入力と必要な実行回数を先に決め、同じ評価基準で傾向を判定します。
2026年9月29日時点のGoogle Cloud公式資料では、temperature、top-P、top-K、seedなどの値が出力へ影響し、temperatureを0にしてもわずかな変動があり得ると説明されています。seedを固定しても決定的な出力は保証されず、モデルや生成設定を変えれば同じseedでも応答が変わり得ます。だから、固定できる条件を台帳へ残し、固定しても残るばらつきは反復比較で扱います。
評価結果は「問題なし」だけで終えず、対象ごとに観察した差を残します。たとえば次のように、出力から確認できる状態として書きます。
- 変更意図に沿う差：指定した評価対象に必要な内容が出ている
- 維持すべき点：旧版で満たしていた条件が候補版でも保たれている
- 想定外の差：対象外の箇所に影響が及んでいる
- 判定保留：入力、実行条件、評価対象、評価基準のいずれかがそろわず比較できない
判定保留を設けると、比較条件が欠けたまま採用へ進むことを避けられます。候補版の品質に結論を出せない状態として扱い、入力、実行条件、評価対象、評価基準をそろえてから再判定します。
採用理由を評価結果に結び付ける
「読みやすくするために修正した」は変更意図を表しています。採用理由には、固定した評価対象で旧版と候補版を比べ、どの差を採用可能と判断したかを書きます。意図と結果を別々に記録すれば、狙いに対して出力が伴ったかを確かめられます。
採用判断には、次の決定表を使えます。これも運用上の提案であり、実際の評価対象は各社のレポート様式と確認責任に合わせて具体化します。
| 比較条件 | 評価対象の結果 | 維持すべき点 | 判断 | 台帳に残す理由 |
|---|---|---|---|---|
| 入力データ版と実行条件が同じ | 変更意図に沿い、評価基準を満たす | 保たれている | 候補版を採用 | 対象箇所の差と、維持を確認した点 |
| 入力データ版と実行条件が同じ | 変更意図に沿うが、評価基準を満たさない | 保たれていない | 不採用または修正 | 改善と引き換えに失われた条件 |
| 入力データ版と実行条件が同じ | 想定外の差があり、評価基準を満たさない | 判断できない | 不採用または確認継続 | 想定外の影響が出た箇所 |
| 入力データ版または実行条件が異なる | 評価基準を満たすか判定できない | 判断できない | 判定保留 | 同条件で再比較する必要があること |
2026年9月29日時点で、NIST AI RMF 1.0のMEASURE 4.3は、関係者との協議と利用文脈に関連する現場データに基づき、測定可能な性能の改善または低下を特定し、文書化するよう示しています。決定表はこの考え方を踏まえつつ、広告レポートの変更差分をチーム内で説明できる形にしたものです。
採用理由の粒度がそろうと、担当者が変わっても過去の判断を読み直せます。レポート生成そのものの確認工程を整える場合は、AIで広告レポートの下書きを作る際の進め方も合わせて整理すると、生成と版管理の境目を置きやすくなります。
戻す条件は採用後に決めない
候補版の採用時点で、旧版へ戻す条件と戻し先を記録します。問題が起きてから「重大なら戻す」と決めても、何を重大とするかで判断が割れます。戻す条件は、運用中の出力を見て該当の有無を判断できる言葉にします。
たとえば、「品質が下がったら戻す」では比較できません。「採用時に維持すると決めた評価対象が満たされない」「採用時にはなかった想定外の差が、確認対象に現れる」のように、採用判断で使った項目と対応させます。条件に該当したら、台帳に記録した旧版へ戻し、その出力を新しい評価記録として残します。原因の確認と旧版への復帰を分ければ、原因の特定を待つ間も、想定と合わない版を使い続けずに済みます。
2026年9月29日時点で、NIST AI RMF 1.0のMANAGE 2.4は、意図した用途と整合しない性能または結果を示すAIシステムを置き換え、切り離し、または停止する仕組みを設けて適用し、その責任を割り当てて理解されるようにすることを示しています。ここで示されているのは特定のプロンプトへの必須手順ではありませんが、復帰条件と担当を事前に明らかにする根拠になります。
また、2026年9月29日時点のNIST Generative AI Profileは、インシデントの記録・分析などの文書化に加え、定期的な情報共有、変更管理記録、版履歴、メタデータが、生成AIインシデントへ対応し管理する関係者を支援し得るとしています。これは推奨的な記述であり、変更台帳の七項目を直接指定するものではありません。変更台帳では、この考え方をプロンプトの採用と復帰を追える履歴へ具体化します。
台帳を更新する手順と担当の境界
変更台帳は比較の前後で分けて更新します。修正後の一括記入では、評価対象や戻す条件が実際の出力に引かれて変わるおそれがあるためです。
- 修正前に、比較へ使う入力データ版、旧プロンプト版、モデル版などの実行条件を固定する。
- 変更意図に対応する評価対象、採用条件、許容しない誤り、旧版で維持すべき点、代表入力ごとの実行回数を決める。
- 候補版を保存し、旧版との差分を特定する。
- 同じ入力データ版と実行条件で両方を必要な回数生成し、評価対象の差と傾向を記録する。
- 事前に決めた評価基準と決定表で採用、不採用、判定保留を選び、結果に結び付けた理由を書く。
- 採用する場合は、戻す条件と戻し先の旧版を記録する。
- 運用中に条件へ該当したら旧版へ戻し、発生した差と対応を新しい行に残す。
この順序なら、評価対象、評価基準、戻す条件が結果を見た後の後付けになりません。最終的な提出・納品の判断は人が行い、AIの出力をそのまま確定稿とは扱わない前提も、担当の境界として共有します。チーム全体の確認項目や引き継ぎまで広げる場合は、広告運用を標準化するための整理方法が接続先になります。
個別のレポートに加え、定例や企画を含めたAI活用の役割分担を整えるなら、広告代理店のAI・DX推進で決める業務境界と台帳の責任者を対応させます。プロンプトを直す人、比較を確認する人、採用を決める人、復帰を実行する人を明確にしておけば、版履歴があっても誰も戻せない状態を避けられます。
劣化を検知できる管理は「戻せる採用記録」になる
修正による劣化は、新旧のプロンプトを保存し、入力データ版と実行条件をそろえ、同じ評価対象と評価基準で必要な回数を比較して見つけます。採用理由を実際の差へ結び付け、維持できなかった条件や想定外の差を戻す条件にします。
台帳の一行を見て、入力データ版、旧版と候補版、モデル版と生成設定、評価した箇所、評価基準、採用した差、復帰の条件が連続して読めるかを確認してください。どれかが欠けている場合は判定保留とし、同じ入力と実行条件、共通の評価基準をそろえます。すべてがつながった時点で採用すれば、その修正は比較と説明ができ、必要な条件で旧版へ戻せる変更として残ります。
次に読む