その修正、本番へ出してよいか――AI更新を差分で審査する

金曜夕方、問い合わせ対応AIの回答が少し硬いという指摘を受け、担当者がシステムプロンプトを一行直しました。モデルもAPIも変えていないため、そのまま本番へ反映したくなる場面です。しかし、その一行が回答拒否の条件を弱めたり、後段のツール呼び出しを増やしたりするなら、変更の影響は文章表現にとどまりません。

AIシステムの変更管理で難しいのは、更新の大きさをコードの差分量で測れないことです。本稿の立場は明確です。モデル、指示、データ、権限、後処理を別々の変更単位として記録し、変えた部分から影響が届く範囲だけを再評価するべきです。 全件を毎回試験する運用でも、担当者の感覚だけで軽微変更とみなす運用でもありません。

「モデルを替えたか」だけでは変更を捉えられない

AIセーフティ・インスティテュート（AISI）の検討報告は、モデル単体の評価だけでは、RAGの検索結果、外部ツール、権限・データフロー、ログやフィルタなどの運用設定に起因する事故を捉えきれないと整理しています。また、評価条件としてモデルの版、プロンプト、データ、設定、実行ログと、OK・NGの判断根拠を記録する必要性にも触れています。[2]

したがって、変更台帳の行を「AIを更新した」と一括りにしてはいけません。最低でも次の五つに分けます。

1. モデル：提供モデル、版、推論パラメータ、フォールバック先
2. 指示：システムプロンプト、テンプレート、出力形式、拒否条件
3. 知識：RAGの文書、分割方法、検索条件、ランキング
4. 権限：参照範囲、実行可能なツール、承認者、利用者ロール
5. 後処理：入力検査、出力フィルタ、構造化変換、業務システムへの書込み

たとえば検索文書を追加しただけでも、古い規程が上位に出るようになれば回答は変わります。権限設定を狭めただけでも、根拠文書が見つからず、もっともらしい補完が増える可能性があります。変更名ではなく、入力から業務上の結果まで、どこへ影響が伝わるかを見ます。

差分審査は「変更」「影響」「判定」の三段で行う

変更を再現できる状態にする

まず、変更前後の識別子を残します。プロンプト本文を台帳へ貼り付ける必要はありません。版管理された参照先、モデル名、検索インデックスのスナップショット、権限設定、後処理コードの版を一組として固定します。AISIは、同じ入力でも出力が変動し得るため、一項目一回の試験では評価できない場合があり、反復実行や判定根拠の提示が必要だと指摘しています。[2]

ここで必要なのは、すべての会話を永久保存することではありません。あとから「何を変え、どの条件で試し、誰が何を根拠に通したか」を追える最小限の証跡です。本文や個人情報を含むログの保存設計は、変更台帳とは分けて扱います。

影響範囲から試験を選ぶ

次に、変更ごとに壊れ得る振る舞いを列挙します。プロンプトの語調変更なら、通常回答だけでなく、拒否、引用、構造化出力も対象です。検索データの更新なら、追加文書への質問だけでなく、既存文書との競合、権限外文書の混入、根拠なし回答を確認します。ツール権限の変更なら、成功率より先に、実行前承認、対象範囲、重複実行、停止後の状態を見ます。

デジタル庁の政府向けガイドライン第2.0版は、2026年6月の改定で、生成AIモデルのメジャーアップデートや大規模な追加学習に関する考慮事項を追加しました。[1] ただし実務では、再評価の要否を「メジャー」という名称だけで決めると、プロンプトや検索設定の変更を取りこぼします。提供者の更新区分は情報の一つであり、自社業務への影響判定そのものではありません。

判定者と戻し方を先に決める

合否は、開発担当者だけで閉じないようにします。技術側は再現性、権限、性能、ロールバックを確認し、業務側は回答が実際の判断や手続に使えるかを確認します。高い影響を持つ変更では、リスク管理や情報管理の担当者も判定に加えます。

NISTのAIリスクマネジメント枠組みは、導入後の監視に、利用者からの入力、異議申立てや上書き、廃止、インシデント対応、復旧、変更管理を含めています。また、継続的改善をAIシステムの更新へ組み込むことを示しています。[3] 変更審査はリリースを止める会議ではなく、改善を本番へ安全に運ぶための短い経路として設計する必要があります。

すべての変更を同じ重さで扱わない

運用を三段階に分けると、統制と速度を両立しやすくなります。

• 軽微：表示文言や、出力に影響しない監視設定。自動試験と担当者確認で反映します。
• 標準：プロンプト、検索文書、ランキング、出力形式。関連する回帰試験と業務担当者の承認を必要とします。
• 重大：モデル切替、ツール追加、権限拡大、自動書込み、学習や大規模な知識更新。限定利用、停止条件、ロールバック確認を含めます。

区分は変更したファイル名ではなく、誤った場合の影響で決めます。顧客への表示だけで終わるのか、社内判断へ使うのか、外部システムを更新するのかで重さは変わります。小さな差分でも、権限や自動実行へ届くなら重大です。

一方、探索段階の社内デモで、出力が業務判断にも外部処理にも使われず、評価者が毎回内容を確認するという場合には、重い承認フローには向きません。変更履歴と最低限の試験を残し、利用範囲が広がる時点で審査を引き上げます。

失敗しやすい運用

第一は、最新モデルへ替えたときだけ再評価する運用です。検索、指示、権限の変更が審査外になります。第二は、毎回すべての評価セットを回す運用です。費用と待ち時間が膨らみ、現場が正式な更新手順を避け始めます。第三は、平均点だけを比較する運用です。拒否すべき入力や特定部署の文書など、件数は少なくても影響の大きい失敗が平均に埋もれます。

弱い案に共通するのは、変更と試験の対応関係が見えないことです。必要なのは巨大なチェックリストではなく、「この差分が、この振る舞いを変え得るため、この試験を行った」という追跡可能性です。

実務への示唆

推奨1：変更台帳を五つの単位で始める。 モデル、指示、知識、権限、後処理のうち、何を変えたかを一つ以上選びます。

推奨2：影響先から試験を逆算する。 通常回答、拒否、根拠、構造、ツール実行、権限のどこへ届くかを記録し、該当試験だけを選びます。

推奨3：判定とロールバックを同じチケットに置く。 承認者、合格条件、戻す版、停止条件が空欄なら、本番反映を保留します。

推奨4：月次で区分を見直す。 軽微として扱った変更が障害や問い合わせにつながったなら、次回から審査段階を一つ上げます。AI変更管理は固定規程ではなく、運用結果から精度を上げる仕組みです。

参考資料

1. デジタル庁「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン（第2.0版）」
2. AIセーフティ・インスティテュート「AIセーフティ評価環境 検討タスクフォース 調査報告書」
3. NIST AI Risk Management Framework Core

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-09-24。