コールセンターのプロンプト変更履歴　誰が何を変えたか追える運用

米国国立標準技術研究所（NIST）のAIリスクマネジメントフレームワークに付属するプレイブックのGOVERN編は、組織の方針が変更管理を扱い、AIシステムの実質的な変更を伝達して確認を取る仕組みを含むことを確かめるよう、提案行動の一つに挙げている。コンタクトセンター（コールセンター）に引き寄せると、AIの応答を決めるプロンプトを誰かが直したとき、その事実が運用チームに伝わり、記録に残っている状態である。では、先週あなたのセンターのAIが誤案内をしたとして、その前後にプロンプトと参照ナレッジのどちらが、いつ、誰の手で変わったのかを、今から特定できるだろうか。本稿の立場を先に書く。誤答の追跡に要るのはプロンプト単体の履歴ではなく、プロンプトの版・参照ナレッジの版・評価結果の3つを同じ変更の記録に束ねる形式であり、ツール選びはその形式が決まった後でよい。

プロンプトとナレッジを作って終わりにしないという運用の全体像は、プロンプト運用の総論で扱った。FAQの更新を誰が担当しどう承認するかという体制の決め方は、FAQ更新体制の記事に譲る。本稿はその間にある、変更の履歴と再現性だけに絞る。記録項目はいずれも編集部（相原ことは）の実務設計案であり、何をどこまで記録するかは自社の管理規程で決める前提である。

製品の側には、履歴のための部品がすでに入り始めている。Amazon Bedrockのプロンプト管理の版機能では、作業中の下書きをある時点で固めたスナップショットを版として作り、番号が1から順に振られる。版の詳細画面を開けば、その版のプロンプト本文と設定を後から確認できる。部品はある。それでも誤答の調査が行き詰まるのは、版の番号と「なぜ変えたか」「変えて何がどうなったか」がつながっていないセンターが多いからだ、というのが本稿の問題設定である。

ソースコードの変更管理と比べると、プロンプトの難しさが際立つ。コードなら、壊れた変更は自動試験が機械的に落として教えてくれることが多い。プロンプトは同じ入力でも出力が揺れるうえ、悪くなったかどうかの判定に人の目が要る。だから版を残すだけでは足りず、その版をどう評価したかまで一緒に残さないと、後から「どの変更が効いたか」を再現できない。単純な比較には留保も要る。コードの試験文化は数十年かけて整ったもので、プロンプト運用にそのまま移植できるわけではない。

プロンプトと参照ナレッジの版を残す

最初の記録項目は、回答を作った材料の組み合わせである。目指す状態は、過去のある回答について「プロンプト第N版と、その時点の参照ナレッジの組で作られた」と1行で言えることだ。

料理のレシピにたとえると分かりやすい。味が変わった原因は、レシピの改訂かもしれないし、仕入れた材料が変わったせいかもしれない。レシピ帳だけ繰っても原因は絞れない。プロンプトがレシピ、参照ナレッジが材料。生成AIの回答はこの2つの組で決まるので、片方だけの履歴では誤答の原因を切り分けられない。

編集部の提案は、変更のたびに通し番号（変更ID）を1つ発行し、プロンプトの版番号と、参照ナレッジ側で動いたファイルの一覧・更新日時を同じ行に書くことだ。ナレッジ側に版機能がなければ、取り込み（インデックス更新）を実行した日時の記録で代用する。ここが起点になる。