Claudeプロンプトの変更管理：改善したつもりで壊さないための評価

プロンプト以外の条件も記録する

出力に影響するのは指示文だけではありません。モデル、入力資料の版、ツール定義、検索条件、生成時の設定も含めて識別します。これらが同時に変わると、改善の理由を一つの文の変更に帰すことができません。

初回から巨大な管理基盤を作る必要はありません。識別子、変更の目的、評価に使った入力、判定結果、戻す先を残す小さな記録でも、会話履歴だけで運用するより再現しやすくなります。

狙った改善と守る動作を分ける

保留の不足を改善するなら、資料不足の入力を追加します。同時に、答えがある普通の質問で保留しすぎていないかも確認します。一方を改善するともう一方が悪化する場合、どの場面の影響を優先するかを業務側で決めます。

一度の応答だけで細かな優劣を決めないことも大切です。生成の揺れと仕様変更の影響を区別するために、重要ケースは繰り返して観察し、評価結果に不確実さがあることを記録します。

戻せる単位で公開する

変更した指示と、それに対応する出力スキーマやツール定義がずれると、戻したつもりでも以前の動作になりません。関連する設定を一つのリリース単位として扱い、失敗時に何を戻すかを先に定めます。評価を通った版と、実際に公開した版を照合してください。

変更の効果と生成の揺れを切り分ける

同じ入力でも出力が揺れる場合、一回だけの新旧比較では偶然を改善と誤認するかもしれません。重要な入力を複数回確認し、必須条件の違反が安定して減ったかを観察します。回数を増やせば十分ということでもなく、入力の種類が偏っていないかを合わせて確認します。使用したモデルや設定を固定して比較した結果と、同時に変更した結果を区別します。

変更後に問題が出たときは、元へ戻す単位が揃っているかを確かめます。プロンプトだけを旧版へ戻し、検索資料やツールの定義が新しいままなら、評価済みの状態には戻っていません。更新の目的、影響する設定、評価対象の入力、公開された版を一つの記録へ結び付けることで、修正の説明と復旧の判断を同じ根拠で行えます。

具体例で考える

架空の変更で「必ず回答する」を「資料がなければ保留する」へ変えます。

狙い：根拠のない断定を減らす。
守る動作：資料内に明確な答えがある質問には答える。
比較：回答可能／資料不足／矛盾資料の三群。
公開記録：指示と資料セットの版を固定。

資料不足の群だけ改善しても成功とは限りません。通常群で回答できなくなった場合は、保留条件が広すぎる可能性があります。群別の結果を残すことで、平均点に隠れた後退を発見できます。

確認課題と合格の目安

最近の指示変更に、狙い、維持条件、比較入力、戻す先を追記してください。

• 変更した要素を特定できる。
• 改善対象以外の代表例も確認している。
• 評価した版と公開した版を区別できる。