プロンプト、モデル、ワークフローを一つのAIリリースとして管理する

AIのリリースは、モデルのエンドポイントやプロンプト文字列だけではなく、利用者へ届く動作を左右する構成全体です。モデルだけを旧版へ戻しても、変更後のプロンプト、ツール定義、権限、検索設定、再試行経路が本番に残れば、試験済みの状態には戻りません。そこで完全な候補に一つのリリースIDを与え、評価した同じ候補を段階展開し、停止時には互換性を確認した既知の良好な一式へ切り替えます。

一つのAIリリースには何を含めるべきか

一つのAIリリースには、提供動作、権限、リスク、費用、遅延、可観測性を実質的に変え得る実行時依存関係を含めます。NISTはAIライフサイクルと構成要素の相互依存性を示し、Google Cloudも本番MLをモデル以外の構成、検証、メタデータ、配信基盤、監視まで含む仕組みとして説明しています。境界はサービス固有ですが、障害後に別々の履歴をつなぎ直さなくて済む粒度が実務上の目安です。

• プロンプト、解決済みモデル識別子、温度や出力長などの実効推論設定
• ツールスキーマ、実行権限、承認規則、ポリシー、ガードレール
• 検索・コンテキスト設定、ワークフローコード、入出力スキーマ、実行時依存関係、動作に影響する環境バインディング
• 評価データ、採点器、ルーブリック、判定基準。通常は配信経路で実行しなくても、昇格判断を変える保証資産として版を付ける

動作スタックをリリースマニフェストへどう束ねるか

動作スタックは、変更できない候補マニフェストに解決済みの版と実効設定を記録して束ねます。「production」や「latest」は移動する参照先にすぎないため、その時点で指していた版、コミット、成果物ダイジェストまたは内容ハッシュを保存します。秘密情報そのものではなく、承認済み接続、データ参照、機能フラグ、ルーティング制約も記録します。動作に影響する項目を変えた場合は、展開途中でも新しい候補です。

• releaseId、作成時刻、所有者、対象サービス、状態、停止条件、ロールバック責任者、以前の既知の良好な版
• 例のsupport-assistant-r18では、p-42、m-2026-07と推論設定、t-9、policy-12、wf-a71、reply-6、実行時依存関係ロックを固定
• eval-23と採点器の版、評価結果、承認は候補へリンクし、配信割合や展開時刻は候補を変更せず昇格記録へ追加
• support-assistant-r17は、新しい任意の期限項目とエスカレーション項目との互換性を確認してから復元先に指定

提供動作、またはその動作を許可する証拠を変え得るものには、リリース記録上の解決済み識別子が必要です。

候補を進めるかどうかは、どの証拠で決めるか

候補を進める判断には、完全な候補を対象にした業務固有の証拠を使います。リリースノートには変更の意図、変更した依存関係、影響する利用場面と接続面、権限・可観測性の変化、既知の制約、残余リスク、展開責任者、互換性を確認した復元先を記載します。評価データ、採点器、ルーブリック、判定基準にも版を付け、結果を現行版と比較します。一つの平均点が良くても、重大な契約違反、権限逸脱、安全上の問題、重要セグメントの後退があれば承認しません。

同じ候補を本番へどう段階展開するか

本番へは、評価済みの同じ候補を、影響を限定した段階から順に進めます。実行可能なら最初にシャドー処理または副作用を起こさない再生を行い、書き込みツールや重要操作は無効化するか隔離します。その後、社内利用者、固定された本番コホート、拡大公開、全トラフィックへ進みます。各段階では候補ID、コホート規則、配信割合、観察期間、結果、進行・保留・却下の判断を展開イベントとして残します。

1. 書き込みを止めた代表的リクエストの再生で、現行版と完全なトレースを比較する
2. 社内利用へ限定し、外部操作の承認を維持したまま運用経路を確認する
3. 固定コホートで業務品質、安全性、ツール動作、信頼性、遅延、費用を現行版と比較する
4. 必要な観察と標本がそろった場合だけ拡大し、候補の構成自体は変更しない
5. 全体公開後もリリースID付き監視を続け、復元先を定めた期間保持する

配信割合、必要な標本、観察時間に万能な値はありません。サービスのリスク、トラフィック量、障害の検出遅延、対応能力から決めます。計画済みの露出増加は同じ候補の展開イベントにできますが、プロンプト、モデル設定、権限、検索設定、ワークフロー、スキーマ、依存関係、動作を変える環境接続を変えた時点で別候補です。

いつ停止し、ロールバックで何を復元するか

安全・ポリシー違反、許可されていないツール動作、契約破壊、深刻な信頼性障害は、露出前にハードストップとして定義します。その他の品質、遅延、費用の悪化にはサービス固有の基準を置き、曖昧な兆候は自動復元ではなく保留と調査に回せます。停止時に戻すのはモデル単体ではなく、スキーマ、状態、ツール契約、ルーティング、移行、プロバイダー提供状況との互換性を確認した既知の良好なリリース一式です。復元手順は事前に演習します。

• 停止理由、最初の検知時刻、対象リリース、コホート、影響したリクエストと外部操作IDを記録する
• 既知の良好な一式へ将来のトラフィックを戻し、契約、権限、主要経路を再確認する
• 完了済みの送信、書き込み、承認、タスク作成は、権限を定めた別の手順で封じ込め、照合、訂正、通知または補償を行う

ロールバックは将来の処理経路を制御する操作であり、すでに外部システムで完了した行為を消去しません。たとえば作成済みCRMタスクが不正または不完全なら、まず操作経路を止め、リリースID付きトレースから対象タスクIDを特定し、承認済みのCRM訂正手順を実行します。復元と是正を分けることで、技術的な切り戻しを業務上の原状回復と取り違えずに済みます。

後からAIリリースを再構成できる記録とは何か

後から再構成できる記録とは、実効構成、評価証拠、展開経過、判断を一つのリリースIDでたどれる記録です。不変の候補マニフェスト、解決済み識別子とパラメータ、環境バインディング、互換性確認、評価資産の版と結果、承認、展開イベント、配信状況、トレース、所見、ロールバック、最終判断を保持します。アプリケーションのトレースIDと、利用可能ならプロバイダー要求IDも関連付けます。

• 生成、ツール呼び出し、引き継ぎ、ガードレール、時刻、結果を、処理したリリースへ帰属できるようにする
• すべてのプロンプト、ツール入力、モデル出力、顧客データを無条件に保存せず、識別子と統制された証拠を残す
• 固定識別子と設定による構成再現性、証拠と承認による判断再現性を目標にする
• 確率的またはホスト型AIについて、同一出力の再生を保証しない

まずは、不変の候補、版を付けた保証証拠、段階展開の判断、互換性を確認した復元先を識別できる最小限のリリースパケットから始めます。機密データの扱い、重大な権限、規制対象業務、保存義務、外部操作の是正が変わる場合は、組織のセキュリティ、プライバシー、法務、記録管理、リスク、業務領域の有資格者へ判断を委ねます。この運用方法自体が、それらの要件を決定するものではありません。