「プロンプトを少し直しただけです」「ナレッジを差し替えただけです」「モデルのマイナーバージョンが上がっただけです」。障害の振り返りで、こうした説明を何度も耳にします。しかも、どれも嘘ではありません。それぞれの変更は、担当チームのレビューを通った正しい変更です。
本連載では、これまで資産ごとに版管理を扱ってきました。指示資産のPromptOps、参照資産のナレッジ運用、能力資産のツール運用、モデル運用、ガードレール運用です。ところが本番のAIエージェントで起きる事故の多くは、別々のチームが行った「それぞれ正しい変更」が同じ週に重なったときに起きます。プロンプトの改修と、ツールのスキーマ変更と、ガードレールの閾値調整が同じ日に入ると、どれが原因なのか誰にも切り分けられなくなります。
筆者はネットワークのNOC/TACで長年、メンテナンスウィンドウ、作業手順書（MOP）、変更凍結、変更諮問委員会（CAB）といった変更管理の仕組みの中で仕事をしてきました。ルーターの設定変更とファームウェア更新を同じ夜に入れない、という規律は、AIエージェントの運用にもそのまま当てはまります。本稿では、この規律をChangeOps（変更管理）としてAgentOpsに持ち込みます。
想定読者は、AIエージェントを本番で運用している開発・運用チーム、プラットフォームチーム、情報システム部門、そしてAIガバナンスの責任者です。
本稿の位置づけ
本稿は、既存の記事と次のように役割を分けています。
| 記事 | 扱う範囲 | 本稿との違い |
|---|---|---|
| デプロイ運用（9/2） | 1つのリリースを安全に出す方法（カナリア、シャドー） | 本稿は、複数の資産にまたがる変更全体を統制します |
| PromptOps／ナレッジ／ツール／モデル／ガードレール運用 | 資産ごとの縦割りの版管理 | 本稿は、それらを横断する変更カレンダーと、変更同士の衝突を扱います |
| インシデント運用（9/5） | 障害が起きた後の対応 | 本稿は、障害の主な原因になる変更を事前に管理する側です |
| エスカレーション運用（HumanOps） | 人間の承認者という資源の運用 | 本稿の変更承認（CAB）も、その承認者の負荷を前提に設計します |
デプロイ運用が「1本の矢をどう安全に放つか」だとすると、ChangeOpsは「何本の矢が、いつ、同じ的に向かっているか」を把握する仕組みです。
なぜ”個別には正しい変更”が重なって事故になるのか
AIエージェントの振る舞いは、プロンプト、モデル、ツール、ナレッジ、ガードレールの組み合わせで決まります。どれか1つが変わるだけでも、出力の傾向は変わります。複数が同時に変わると、問題は次の3つの形で現れます。
1. 原因が切り分けられない
品質指標が悪化したとき、直前に3つの変更が入っていれば、どれを戻せばよいのかがわかりません。結局、全部を戻すか、1つずつ戻して様子を見ることになり、復旧が遅れます。ネットワーク運用でいう「同一ウィンドウに複数作業を詰め込んだ結果、切り戻しの判断ができない」状態です。
2. 相互作用で初めて壊れる
プロンプトは「ツールAの結果を必ず引用せよ」と指示し、同じ日にツールAの出力フォーマットが変わった。ガードレールの閾値を緩めた日に、より積極的に回答するモデルへ切り替えた。こうした組み合わせは、それぞれのテストでは問題が出ません。各チームのステージング環境には、相手の変更がまだ入っていないからです。
3. “誰が変えたか”の記録が分散している
プロンプトはGit、ナレッジはCMS、モデルはベンダー側の自動更新、ガードレールは管理画面の設定、ツールは別チームのAPI。変更の記録が5か所に散らばっていると、障害時に「直近24時間で何が変わったか」を答えるだけで30分かかります。
まず棚卸し——”変更対象”を1つの台帳にまとめる
最初にやるべきことは、AIエージェントの振る舞いに影響する変更対象を、資産の種類を問わず1つの台帳に載せることです。ポイントは、自社が意図しない変更（ベンダー側のモデル更新、外部APIの仕様変更など）も台帳に含めることです。
| 変更対象 | 変更の例 | 変更の発生源 | 見落としやすい点 |
|---|---|---|---|
| プロンプト | システムプロンプト、Few-shot例、出力形式の指示 | 自社 | 「文言の微修正」が軽く扱われがち |
| モデル | モデルの切り替え、バージョン更新、温度などのパラメータ | 自社／ベンダー | エイリアス指定（latest等）による暗黙の更新 |
| ツール | ツール定義、スキーマ、権限、MCPサーバーの追加・更新 | 自社／他チーム／外部 | 他チーム管理のAPIの仕様変更 |
| ナレッジ | RAG文書の追加・削除、埋め込みモデルやチャンク設定の変更 | 自社（業務部門を含む） | 業務部門による文書差し替えが変更として扱われない |
| ガードレール | フィルタの閾値、ブロックリスト、承認ゲートの条件 | 自社（セキュリティ部門） | 管理画面からの即時変更に履歴が残らない |
| 実行基盤 | SDK・フレームワークの更新、タイムアウト、リトライ設定 | 自社 | ライブラリ更新に伴う既定値の変化 |
台帳には最低限、変更ID、対象、内容、申請者、承認者、実施日時、影響範囲、ロールバック方法、検証結果を記録します。これが後述する変更カレンダーと衝突検知の土台になります。
規律1：変更を”標準・通常・緊急”の3区分に分ける
すべての変更に同じ重さの承認を求めると、承認者が疲弊し、変更が台帳を通らずに入るようになります。ITILの変更管理と同じく、リスクに応じて3区分に分けます。
| 区分 | 定義 | AIエージェントでの例 | 承認 | 実施タイミング |
|---|---|---|---|---|
| 標準変更 | 手順が確立し、リスクが低く、事前承認済みの型 | FAQ文書の誤字修正、ブロックリストへの語句追加、評価セットで合格済みの定型的な文言修正 | 事前承認（型の承認）。都度の承認は不要 | 随時（ただし凍結期間を除く） |
| 通常変更 | 影響評価とレビューが必要な変更 | システムプロンプトの構造変更、モデル切り替え、新ツールの追加、ガードレール閾値の変更 | 変更レビュー（軽量CAB）で承認 | 変更ウィンドウ内 |
| 緊急変更 | 障害やセキュリティ事案への即時対応 | プロンプトインジェクション発覚時の緊急遮断、暴走ツールの無効化 | 緊急承認者1名＋事後レビュー | 即時 |
標準変更を”育てる”
運用の成熟度は、標準変更の割合に表れます。同じ種類の通常変更が問題なく5回続いたら、手順と検証方法を固定して標準変更に昇格させる、といったルールを決めておくと、承認の負荷が下がり、台帳を迂回する動機もなくなります。
緊急変更は”事後に必ず通常化”する
緊急変更は、承認を後回しにする代わりに、48時間以内の事後レビューを義務づけます。緊急で入れた変更を戻すのか、恒久化するのかをそこで決めます。緊急変更が放置されると、誰も意図を説明できない設定が本番に残り続けます。
規律2：変更カレンダーと凍結期間を運用する
資産ごとの変更を1枚のカレンダーに載せます。これだけで「同じ日に3チームが変更を予定している」ことが一目でわかります。
変更ウィンドウを決める
- 通常変更のウィンドウ：例として火〜木曜の午前。利用が少なく、担当者が揃っていて、翌日も監視できる時間帯を選びます。
- 金曜午後・連休前は避ける：問題が週末に顕在化すると、監視と切り戻しの体制が手薄になります。
- 1ウィンドウあたりの変更数に上限を設ける：同一エージェントに対しては、1ウィンドウ1変更を原則にします。
凍結期間（チェンジフリーズ）を宣言する
次のような期間は、標準変更を含めて変更を止めます。緊急変更のみ例外とします。
- 決算期、繁忙期、大型キャンペーンなど業務上の重要期間
- 年末年始・大型連休とその前後
- 大規模な通常変更の直後（観測期間として数日間）
- インシデント対応中で、原因が確定していない期間
最後の項目は特に重要です。障害の原因調査中に別の変更が入ると、事象の再現性が失われます。NOCでは当たり前の運用ですが、AIエージェントの現場では「調査と並行して改善のプロンプト修正を入れてしまう」ことがよく起きます。
ベンダー側の変更もカレンダーに載せる
モデルの提供終了（廃止）予定日、API仕様の変更予定日、SDKのサポート終了日など、外部起因の変更も予定としてカレンダーに書き込みます。モデルの指定はエイリアスではなく固定のバージョンで行い、更新を自社の変更として計画的に取り込むのが原則です。
規律3：同時変更の衝突を検知する
カレンダーは「見える化」ですが、人が見落とすことを前提に、衝突を機械的に検知する仕組みを入れます。
衝突の3つの型
| 型 | 内容 | 例 |
|---|---|---|
| 時間の衝突 | 同じエージェントに対する変更が、同一ウィンドウまたは観測期間内に重なる | 月曜にモデル更新、火曜にプロンプト改修（モデル更新の観測期間中） |
| 依存の衝突 | 変更対象どうしに依存関係がある | プロンプトが参照するツールの出力スキーマを、ツールチームが変更 |
| 共有資産の衝突 | 複数のエージェントが共有する資産の変更 | 共通ナレッジベースや共通ガードレールの変更が、全エージェントに同時に波及 |
検知の実装
- 依存関係マップ：エージェントごとに、使っているプロンプト、モデル、ツール、ナレッジ、ガードレールを構成情報（構成管理DBに相当）として記録します。
- 申請時チェック：変更申請が登録されたとき、依存関係マップをたどって、同じ影響範囲で予定されている他の変更を自動で列挙します。
- 観測期間のロック：通常変更の実施後、一定期間（例：72時間）は同じ影響範囲への通常変更の申請を保留にします。
- 共有資産の変更は”全員に通知”：共有ナレッジや共通ガードレールの変更は、影響を受けるすべてのエージェントの担当者に事前通知します。
依存関係マップは、ツール運用やナレッジ運用の記事で作った資産台帳を突き合わせれば作れます。新しく台帳をつくる必要はなく、既存の縦割りの台帳を横につなぐのがChangeOpsの役割です。
規律4：ロールバック条件つきの作業手順書（MOP）を書く
通常変更には、実施前に作業手順書（MOP：Method of Procedure）を用意します。ネットワークのMOPと同じく、最も大事なのは「どうなったら戻すか」を事前に数値で決めておくことです。実施中に「もう少し様子を見よう」と判断が揺れるのを防ぎます。
MOPの構成
| 項目 | 記載内容 |
|---|---|
| 変更の目的と範囲 | 何を、なぜ、どのエージェントに対して変えるか |
| 事前確認 | 現行版の識別子（プロンプト版、モデルバージョン等）、ベースラインの指標値、凍結期間・衝突がないことの確認 |
| 実施手順 | 番号付きの手順。カナリア比率と段階の進め方 |
| ロールバック条件 | 例：タスク成功率がベースラインから3ポイント以上低下、ガードレール発動率が2倍以上、エスカレーション件数が1.5倍以上、のいずれか |
| ロールバック手順 | 戻す対象と手順、所要時間の見込み。実施前にステージングで一度戻せることを確認 |
| 変更後検証 | 確認する指標、評価セット、観測期間 |
| 体制と連絡先 | 実施者、確認者、判断者、エスカレーション先 |
“戻せない変更”を見分ける
AIエージェントの変更には、元に戻しにくいものがあります。
- ナレッジの削除：元の文書や埋め込みを保管しておかないと復元できません。
- 埋め込みモデルの変更：インデックス全体の再構築が必要で、戻すにも時間がかかります。旧インデックスを並行保持しておきます。
- エージェントが既に実行した外部操作：送信済みのメールや登録済みのデータは、設定を戻しても取り消せません。
- ベンダーが廃止したモデル：戻し先がもう存在しない場合があります。
こうした変更は、MOPで「ロールバック不可」と明記し、通常より慎重な段階展開と長めの観測期間を設定します。
規律5：変更後検証と”変更起因障害率”で運用を測る
変更は、入れた時点ではなく検証が終わった時点で完了とします。
変更後検証のステップ
- 直後確認（〜1時間）：エラー率、レイテンシ、ガードレール発動率がベースラインの範囲内か。
- 短期観測（〜72時間）：タスク成功率、エスカレーション件数、ユーザーの再質問率や低評価率。
- 評価セットの再実行：変更前と同じ評価セットを流し、回帰がないかを確認。
- 台帳のクローズ：検証結果を台帳に記録し、変更を「完了」にする。
ChangeOpsのKPI
| 指標 | 定義 | 見方 |
|---|---|---|
| 変更起因障害率 | 障害やロールバックにつながった変更の数 ÷ 全変更数 | DevOpsの研究（DORA）でいう「変更失敗率」に相当。資産別・区分別に分けて見る |
| 変更起因インシデント比率 | 原因が変更だったインシデントの数 ÷ 全インシデント数 | 高ければ、変更管理を強化する余地が大きい |
| 台帳外変更の件数 | 事後に発見された、台帳を通らない変更 | ゼロが目標。発生したら仕組み側の問題として扱う |
| 標準変更の比率 | 標準変更 ÷ 全変更 | 高いほど運用が成熟している |
| 緊急変更の比率 | 緊急変更 ÷ 全変更 | 高すぎる場合は、計画不足か品質問題のサイン |
| 平均ロールバック時間 | ロールバック判断から復旧までの時間 | MOPのロールバック手順が機能しているかの指標 |
インシデント運用の振り返りで「原因：変更」と判定されたものは、必ず該当する変更IDと紐づけます。これにより、「どの資産の、どの区分の変更が事故を起こしやすいか」が数字で見えるようになります。
運用サイクル——いつ、何を見るか
| 頻度 | 内容 | 参加者 |
|---|---|---|
| 毎日 | 当日・翌日の変更予定と衝突の確認、実施中の変更の観測状況 | 運用担当 |
| 週次 | 軽量CAB：翌週の通常変更の承認、衝突の調整、前週の変更の検証結果 | 各資産の担当者、運用責任者 |
| 月次 | 変更起因障害率などKPIのレビュー、標準変更への昇格判断、台帳外変更の再発防止 | 運用責任者、AIガバナンス担当 |
| 四半期 | 凍結期間の計画、ベンダーのモデル廃止予定の取り込み、変更区分の見直し | 運用責任者、事業部門 |
CABは重い会議にする必要はありません。週1回30分、カレンダーを画面に出して「来週、同じエージェントに2つ以上の変更が載っていないか」を確認するだけでも、効果は大きいです。
よくある落とし穴
- 「プロンプトの修正は変更ではない」扱い：文言の修正こそ、最も頻繁で、最も台帳を通らない変更です。標準変更として型を決め、記録だけは必ず残します。
- モデルのエイリアス指定：「latest」などの指定では、ベンダー側の更新がそのまま自社の本番変更になります。変更カレンダーのどこにも載らない変更が生まれます。
- 業務部門によるナレッジ差し替え：文書の更新は業務の一部として行われるため、変更として認識されません。少なくとも共有ナレッジは台帳の対象にします。
- ロールバック手順の”机上だけ”：手順書に書いてあっても、実際に戻したことがなければ、戻せるかどうかはわかりません。
- 障害調査中の”ついでの改善”：調査中の変更は原因の切り分けを不可能にします。凍結を宣言します。
- CABの形骸化：承認が通過儀礼になると、HumanOps編で扱った「ラバースタンプ化」と同じ状態になります。差し戻し率を見て、機能しているかを確認します。
ChangeOps チェックリスト
| 領域 | 確認項目 |
|---|---|
| 台帳 | プロンプト、モデル、ツール、ナレッジ、ガードレール、実行基盤の変更が1つの台帳に記録されている |
| 台帳 | ベンダー側・他チーム側の変更予定も台帳とカレンダーに載っている |
| 区分 | 標準・通常・緊急の定義と承認ルートが決まっている |
| 区分 | 緊急変更に48時間以内の事後レビューが義務づけられている |
| カレンダー | 変更ウィンドウと、1ウィンドウあたりの変更数の上限が決まっている |
| カレンダー | 凍結期間（業務上の重要期間、インシデント調査中など）が宣言・共有されている |
| 衝突検知 | エージェントごとの依存関係マップがあり、申請時に衝突を自動で列挙できる |
| 衝突検知 | 通常変更の後に観測期間のロックがある |
| MOP | 通常変更にはロールバック条件を数値で記したMOPがある |
| MOP | ロールバック手順を事前にステージングで実行している |
| MOP | ロールバック不可の変更が識別され、慎重な展開計画がある |
| 検証 | 変更後検証が終わるまで変更を「完了」にしない |
| KPI | 変更起因障害率、台帳外変更の件数、標準変更の比率を月次で見ている |
| 連携 | インシデントの原因判定が変更IDと紐づいている |
よくある質問（Q&A）
Q1. 小規模なチームでも、ここまでの変更管理が必要ですか？
すべてを最初から揃える必要はありません。まずは「1枚の変更カレンダー」と「同じエージェントに1日1変更」のルールだけで始めてください。小規模なチームほど、1人が複数の資産を同時に触りやすく、変更の重なりが起きやすいため、最小限の規律でも効果が出ます。
Q2. プロンプトの小さな修正まで承認を通すと、開発が遅くなりませんか？
そのために標準変更の区分があります。評価セットで合格したことを条件に、定型的な修正は事前承認の型として扱い、都度の承認は不要にします。求めるのは「承認」ではなく「記録」です。記録さえあれば、障害時に変更を追跡できます。
Q3. ベンダーがモデルを更新するのは止められません。どう管理すればよいですか？
モデルはエイリアスではなく固定のバージョンで指定し、新しいバージョンへの移行を自社の通常変更として計画します。ベンダーが公表する廃止予定日は変更カレンダーに書き込み、余裕をもって移行のMOPを準備します。
Q4. デプロイ運用でカナリアリリースをしていれば、変更管理は不要では？
カナリアは1つの変更を安全に出す手段で、変更同士の衝突までは防げません。2つの変更がそれぞれカナリアを通過しても、両方が揃った状態で初めて問題が出ることがあります。ChangeOpsは、カナリアを含むデプロイの上位で、変更の組み合わせとタイミングを統制します。
Q5. 変更起因障害率は、どのくらいを目標にすればよいですか？
一律の目標値より、自社のベースラインからの推移を見ることをおすすめします。まず3か月計測し、資産別・区分別にどこが高いかを特定してください。特定の資産の通常変更だけが高いなら、その資産のMOPや変更後検証に改善の余地があります。
まとめ——変更は”個別”ではなく”組み合わせ”で管理する
本稿の要点は、次の3つです。
1. すべての変更を1つの台帳とカレンダーに載せる。資産ごとの縦割りの版管理を横につなぎ、ベンダー側の変更も含めて「いつ、何が変わるか」を一望できるようにします。
2. 変更の重なりを、ルールと仕組みの両方で防ぐ。変更区分、変更ウィンドウ、凍結期間、衝突検知、観測期間のロックによって、「個別には正しい変更が重なって事故になる」状況を事前に避けます。
3. 戻す条件を先に決め、結果を数字で測る。ロールバック条件つきのMOPと変更後検証、変更起因障害率によって、変更管理そのものを改善できる運用にします。
ネットワークの運用者が長年守ってきた「一度に一つ、戻せる形で、記録を残して変える」という原則は、AIエージェントの時代にもそのまま通用します。変更を管理できたとき、エージェントは初めて”説明できる本番”になります。
関連記事
- 【AgentOps・エスカレーション運用（HumanOps）編】”人間に回せば安全”で終わらせない
- 【AgentOps・デプロイ運用編】カナリア・シャドーによる安全なリリース
- 【AgentOps・インシデント運用編】障害発生時の対応と振り返り
- 【AgentOps・PromptOps編】指示資産の版管理
- 【AgentOps・モデル運用（ModelOps）編】
- 【AgentOps・ガードレール運用（GuardrailOps）編】
コメント