AIエージェントの変更を安全に出すには？モデル・プロンプト・道具を版管理する
AIエージェントは、アプリのコードを変えていなくても挙動が変わる。モデル、プロンプト、道具の説明、検索索引、ガードレール、実行上限のどれかを更新すれば、選ぶ道具や回答が変わり得る。本番で問題が起きたときに戻せるよう、これらを一つの実行構成として版管理する必要がある。
例えば、問い合わせ対応エージェントのモデルだけを新しくした架空の場面を考える。回答が自然になっても、返金依頼で確認道具を一つ飛ばすようになれば、その変更は成功とは言えない。モデル名だけでなく、同時に使ったプロンプト、道具Schema、評価データ、上限設定まで分からなければ原因を切り分けられない。
実行構成を一つの版として記録する
少なくとも、モデルと固定された版、プロンプトの版、道具定義の版、経路制御、検索索引またはデータの版、ガードレール、主要な上限を記録する。一回のトレースへ構成IDを付ければ、同じ不具合がどの版で起きたかを集計できる。
モデルの別名が常に同じ挙動を指すとは限らない。OpenAIのAPI資料は、モデルのsnapshotを固定すると特定の版へロックできる一方、snapshot間では同じメッセージでも動作が変わり得るため、固定版と評価の利用を勧めている。固定すれば永遠に更新しなくてよいわけではない。更新日と移行期限を管理し、次の版を評価してから切り替えるための基準になる。
プロンプトは管理画面だけで直接書き換えず、変更内容と理由を追える場所で版管理する。道具の説明や引数Schemaもプロンプトと同じくモデルの判断へ影響するため、別の設定として見落とさない。
一度に複数の要素を変えない
モデル、プロンプト、検索方式を同時に変えて品質が下がると、原因が分からない。まず現在の構成で評価の基準値を取り、一つの変更を加え、同じデータで比較する。どうしてもまとめて変える場合は、組み合わせ全体を新しい構成IDとして扱い、途中の構成を推測で再現しない。
OpenAIのモデル選択資料は、目的に対する評価データセットを作り、性能を測る流れを示している。正答率だけでなく、前の記事で扱った道具選択、危険な操作、遅延、費用も変更前後で比べる。平均が上がっても、承認を飛ばす例が一件増えたなら安全性の基準を満たさない。
不具合を直した入力は回帰テストへ追加する。評価データ自体にも版を付け、都合のよい例だけを後から外さない。自動採点の基準や採点モデルを変えた場合も、製品の改善と採点方法の変化を区別する。
本番と同じ条件で影の実行をする
新しい構成へ利用者の操作権限をすぐ渡さず、現在の本番入力を複製して影の実行を行う方法がある。新構成の回答や道具の提案は記録するが、外部への書き込みは実行しない。現行構成との差分を確認し、評価データでは見つからなかった実入力の問題を探す。
影の実行では、個人情報の利用目的、保存範囲、費用を確認する。同じ入力を別モデルへ送ることが許可されているとは限らない。書き込み道具を模擬する場合も、本物の送信先や認証情報へ到達できない構成にする。
最終回答の文章が違うだけで失敗と判定せず、必要な事実、禁止事項、道具の経路、構造化出力を比較する。生成文の完全一致は、正しい別表現まで拒否しやすい。
小さな範囲から段階的に公開する
事前評価を通過しても、本番の全入力を再現できるわけではない。新構成を一部の利用者や少量の処理だけへ出し、旧構成を対照として指標を比べる。Google SRE Workbookは、カナリアを変更の部分的かつ時間限定の展開と評価として定義し、問題がなければ展開を進める方法を説明している。
割り当ては会話の途中で版が変わらないよう、利用者やセッション単位で固定する。新構成の割合、観察時間、合格指標、停止条件を展開前に決める。エラー率や危険な道具の呼び出しが基準を超えたら、自動で拡大を止める。小さな母数では偶然の差が大きいため、件数と期間を見ずに一件の成功だけで全面展開しない。
ロールバックは設定を戻すだけでは終わらない
旧構成をすぐ選び直せるよう、直前のモデル、プロンプト、道具定義、経路制御を残す。展開中に問題を検出したら、新規セッションを旧構成へ戻し、進行中の処理を安全に停止する。Google SREの資料は、変更で問題が起きたとき、修正を急いで追加するより既知の安定版へ戻す方が障害時間を短くできると説明している。
ただし、エージェントがすでに外部状態を変えた場合、構成を戻すだけでは元に戻らない。誤送信や削除、公開、決済は個別に影響を調べ、補償操作または人の対応が必要になる。状態Schemaや検索索引を変更した場合も、旧構成が新しいデータ形式を読めるかを事前に確かめる。
ロールバック手順自体を定期的に試す。旧版へ切り替えられても、認証情報が失効していたり、旧道具が廃止されていたりすれば復旧できない。
変更後に見る指標を先に決める
公開後は、最終回答の評価、道具別エラー率、承認拒否率、上限到達率、遅延、トークン、費用を構成ID別に見る。利用者からの訂正や再質問が増えていないかも確認する。新構成だけ悪化した指標があれば展開を止め、該当トレースを評価データへ戻す。
モデル提供側の廃止予定や変更履歴も監視する。廃止直前に慌てて別名へ置き換えず、候補の版を固定し、評価、影の実行、段階展開を順に行う。移行期限は運用タスクとして管理し、担当者の記憶だけに置かない。
AIエージェントの変更管理で大切なのは、新しいモデルへ早く替えることではない。何を変えたかを再現でき、少ない影響で実入力を確かめ、問題があれば既知の安定版へ戻せる状態を作ることだ。