この連載では、AIエージェントを「作って動かす」段階から、「運用として回し続ける」段階へと視点を移してきました。②評価で品質の測り方を、③観測でシステムの見える化を、④コストでユニットエコノミクスを、⑤メモリで長期記憶のライフサイクルを、⑥権限で最小権限の規律を積み上げてきました。第7回のテーマは、第六要素「デプロイ」です。
従来のソフトウェアでは、「テストが緑（グリーン）になった＝安全にリリースできる」という等式が、おおむね成り立ってきました。しかしAIエージェントでは、この等式が崩れます。エージェントは非決定的で、同じ入力でも出力が揺れます。さらに厄介なことに、プロバイダはあなたに知らせず基盤モデルを更新することがあります。つまり「テストは緑、本番は別物」——ステージングで通ったものが、本番では静かに壊れているという事態が、構造的に起こり得ます。
本記事では、この落とし穴を運用設計で塞ぐための5つの規律を扱います。(1)「何がリリースか」の再定義、(2) カナリア／シャドー／段階的自律というプログレッシブデリバリー、(3) 本番相当で採点するオンライン評価ゲート、(4) サイレントなモデル更新に備えるバージョンのピン留め、(5) 状態を持つエージェントを壊さず戻すロールバック設計。想定読者は、エージェントを本番投入する立場にあるエンジニアリングリーダー、SRE／プラットフォーム担当、そしてAIプロダクトの品質に責任を負う方々です。
なぜ今、「デプロイの運用規律」なのか
2026年、エージェントを構成する要素は、それぞれ独立に、しかも別々の速度で変わり続けています。プロンプトはプロダクトチームが週に何度も書き換え、基盤モデルはプロバイダ側で予告なく差し替わり、ツール（関数）の定義はAPI仕様の変更で動き、メモリスキーマはデータ設計の都合で進化します。この4つが非同期に動く世界では、「デプロイ」という言葉が指すものが、そもそも曖昧になっています。
従来のWebアプリのデプロイは、基本的に「コードの入れ替え」でした。コードは決定的で、同じコードは同じ振る舞いをします。だからCIが緑なら本番に出せた。ところがエージェントでは、コードを1行も変えなくても振る舞いが変わり得ます。モデルが更新されれば、プロンプトの解釈が変わり、ツールの呼び出し方が変わり、出力形式が微妙にずれる。この非対称性を理解しないままデプロイを回すと、「リリースしていないのに壊れた」「リリースは成功したのに事故になった」という、従来型の運用感覚では説明できない障害に直面します。
既存記事との棲み分け
混同を避けるために、関連トピックとの守備範囲を整理しておきます。「本番投入前テスト完全ガイド」が扱うのは品質保証の実装、すなわちテスト手法そのものです。カナリアリリースは連載③（PoCが死ぬ理由）の中で一要素として触れました。③はオブザーバビリティ、つまり「動いているものをどう見るか」でした。
本記事⑦は、⑤メモリ・⑥権限と同じ系譜、すなわち「運用としてのデプロイの規律」に集中します。テストのやり方ではなく、テストを通ったあと本番に出すまでのプロセスをどう設計するか。②③④⑤⑥で積み上げてきた要素を「デプロイ」という軸で束ね直す結節点——それが⑦の役割です。
第1の規律：「何がリリースか」を再定義する
最初にやるべきは、リリースの単位（デプロイの原子）を定義し直すことです。従来は「コードのバージョン」がリリース単位でした。エージェントでは、次の4つがそれぞれ独立に変わるリリース対象です。
| リリース対象 | 変わる主な理由 | 変わったときのリスク |
|---|---|---|
| プロンプト（システム／指示文） | プロダクト改善、表現の微調整 | 意図せぬ挙動変化、ガードレールの緩み |
| モデル（基盤モデルのバージョン） | 自社更新、またはプロバイダのサイレント更新 | 出力形式・推論品質の変化、回帰 |
| ツール定義（関数・API仕様） | 連携先の仕様変更、新機能追加 | 呼び出し失敗、副作用の誤爆 |
| メモリスキーマ（記憶の構造） | データ設計の進化、項目追加 | 過去の記憶との不整合、参照エラー |
ここで重要なのは、これら4つの組み合わせ全体を、ひとつのバージョンとして固定・記録するという発想です。「プロンプトv12 × モデルgpt-x-2026-05 × ツール定義v4 × メモリスキーマv3」という組を、ひとつのリリース識別子で管理する。これをリリースマニフェストと呼ぶことにします。マニフェストがあって初めて、「今、本番で動いているのは正確に何か」を言い当てられ、事故時に「何を戻せばいいか」が確定します。
逆に言えば、プロンプトだけをこっそり書き換える、モデルだけが勝手に更新される、といった「マニフェストを経由しない変更」を禁じることが、デプロイ規律の出発点です。すべての変更は、マニフェストのバージョンを上げる形でしか本番に届かない——この一貫性が、以降のすべての仕組みの土台になります。
第2の規律：プログレッシブデリバリー（段階的に出す）
非決定的なシステムを一気に全量入れ替えるのは、賭けです。プログレッシブデリバリーとは、新しいマニフェストを少しずつ、観測しながら、いつでも戻せる形で本番に浸透させていく考え方です。エージェントでは、これを3つの層で組み合わせます。
カナリアリリース（トラフィックを絞って出す）
新マニフェストを、まず全トラフィックの1〜5%にだけ流します。残りは旧マニフェストが処理し続ける。新旧を並走させ、後述のオンライン評価ゲートとオブザーバビリティ（③）で、新の品質・コスト・エラー率を旧と直接比較します。問題がなければ段階的に比率を上げ（5%→25%→50%→100%）、異常が出れば即座に0%へ戻す。「全ユーザーに影響が出る前に、小さく失敗を検知する」のが狙いです。
シャドーデプロイ（本番トラフィックの写しで採点する）
シャドーは、さらに慎重な方法です。新マニフェストに本番と同じ入力を流しますが、その出力はユーザーには返しません。ユーザーに返るのはあくまで旧マニフェストの結果で、新は「影（シャドー）」として裏で同じ仕事をし、その結果だけを記録・採点します。ユーザーへの影響ゼロで、本番相当の入力分布に対する新バージョンの挙動を丸ごと検証できる。副作用のない読み取り系エージェントや、大きなモデル更新の事前検証で特に有効です。
注意点として、シャドー実行が外部に副作用を起こすツール（決済、メール送信、DB書き込みなど）を呼ぶと、影のはずが現実を二重に動かしてしまいます。シャドーモードでは副作用系ツールをドライラン（実行せずに記録のみ）に切り替える仕組みが前提になります。
段階的自律（エージェントに渡す裁量を段階的に上げる）
エージェント特有の第3の軸が、自律度そのものを段階的に上げることです。新しいマニフェストをいきなり「完全自動実行」で出すのではなく、次のように裁量を刻みます。
| 段階 | エージェントの権限 | 人間の関与 |
|---|---|---|
| ① 提案のみ | 行動案を出すだけ、実行しない | 人間が全件実行 |
| ② 承認付き実行 | 実行するが、着手前に承認を求める | 人間が全件承認 |
| ③ 事後確認 | 自動実行し、結果を通知 | 人間が抜き取り監査 |
| ④ 完全自律 | 低リスク操作は自動、高リスクのみ承認 | 例外時のみ介入 |
新マニフェストは①または②から入れ、実績が積み上がるにつれて段階を上げます。トラフィック比率（カナリア）と自律度（段階的自律）は直交する2つのダイヤルであり、両方を同時に絞ることで、リスクを二重に抑えられます。ここで効いてくるのが⑥で扱った権限の設計です——自律度を上げるとは、エージェントに与える権限スコープを広げることに他ならず、段階的自律とJust-in-Time権限は同じコインの裏表です。
第3の規律：オンライン評価ゲート（出す前に本番相当で採点する）
プログレッシブデリバリーの各段階に、自動の合否判定（ゲート）を置きます。ここが②評価と直結する部分です。②で構築したゴールデンセット（正解と評価基準の集合）を、リリース前の関門として使い回すのです。
従来のCIゲートは「テストが全部パスしたか（緑か赤か）」の二値でした。エージェントのオンライン評価ゲートは、非決定性を前提にしきい値ベースの合否で判定します。たとえば次のような基準です。
- 品質スコア：ゴールデンセットに対する評価スコアが、旧マニフェスト比で許容範囲内か（例：−2%以内）。
- 回帰の不在：以前に修正したはずの既知の失敗ケースが、再発していないか。
- コスト：1リクエストあたりのトークン消費・課金額が予算内か（④の予算ガードレールと連動）。
- レイテンシ：応答時間の分布（p95など）が悪化していないか。
- 安全性：ガードレール違反率・ツール誤爆率が上限を超えていないか。
肝は、このゲートを「テスト環境」ではなく「本番相当のデータ分布」で回すことです。合成テストだけで緑になっても、本番の入力分布は違います。だからこそシャドーデプロイでゲートを回す価値が高い——本番と同じ入力に対する新バージョンの採点結果を、ユーザーに影響を出さずに得られるからです。ゲートが緑なら次の段階へ、赤なら昇格を止めて自動ロールバック。この「評価をデプロイの関門に組み込む」設計が、「テストは緑、本番は別物」の落とし穴を実質的に埋めます。
第4の規律：サイレントなモデル更新へのバージョンピン留め
エージェント運用に特有で、最も見落とされがちなのがこれです。多くのモデルAPIでは、gpt-latest のようなエイリアスを指定すると、プロバイダの都合で実体のモデルが予告なく差し替わります。あなたは何もデプロイしていないのに、ある朝から出力の質が変わっている。これがサイレント更新です。
対策の基本は、バージョンのピン留め（pinning）です。latest や汎用エイリアスではなく、gpt-x-2026-05-01 のように日付・世代まで固定した具体的なバージョン識別子を本番で指定します。これでモデルは、あなたがマニフェストを更新するまで固定されます。モデルの変更を、他の変更と同じく意図的なリリースイベントに格下げ（＝マニフェスト経由に強制）できるわけです。
ただしピン留めしたバージョンは、いずれプロバイダに廃止（デプリケート）されます。そこで併せて必要なのが、次の2つの監視です。第一に廃止スケジュールの追跡——ピン留め中のモデルのサポート終了日を把握し、余裕をもって次バージョンへの移行をカナリアで検証する。第二にサイレント更新の検知——万一エイリアス運用が残っている箇所があっても気づけるよう、同一の入力に対する出力を定点観測し、説明のつかない品質変化（ドリフト）が起きたら警報を上げる。⑤メモリで扱ったドリフト監視の発想が、そのままモデル挙動の監視に転用できます。
第5の規律：状態を持つエージェントのロールバック設計
最後に、事故が起きたときに安全に戻すための設計です。ステートレスなWebアプリなら、ロールバックは前のコンテナに切り替えるだけで済みます。しかしエージェントは状態（ステート）を持ちます——会話履歴、長期メモリ、実行中のタスク、そして「すでに現実世界で起こしてしまった副作用」。ここでロールバックが一気に難しくなります。
難しさの正体は、コードは戻せても、状態は戻せないことがあるという点です。3つのレイヤーに分けて設計します。
| レイヤー | ロールバックの論点 | 設計の勘所 |
|---|---|---|
| コード／マニフェスト | 前バージョンへ切り替える | マニフェスト単位で即時切替。カナリア比率を0%に戻すのが最速のロールバック |
| メモリスキーマ | 新スキーマで書いた記憶を、旧が読めるか | スキーマ変更は後方互換で行う。旧バージョンが新データを無視できる設計にし、破壊的変更は避ける（⑤と連動） |
| 副作用 | すでに送信・決済・書込みした行為は戻せない | 戻せない前提で、補償トランザクション（打ち消し操作）を用意。ツール実行を監査ログに残し、影響範囲を特定できるようにする |
特にメモリスキーマは要注意です。新マニフェストがメモリに新形式で書き込んだあと旧マニフェストへ戻すと、旧は新形式を読めず参照エラーを起こしかねません。だからスキーマ変更は常に後方互換（旧バージョンが壊れない形）で先行導入し、書き込み形式の切り替えはその後にする、という順序が鉄則になります。これは⑤メモリで論じたライフサイクル設計の、デプロイ側からの写像です。
副作用については、「ロールバックできない」ことを受け入れた上で、影響の可逆性でツールを分類しておくのが実務的です。可逆（読み取り、下書き作成）なツールは自律度を上げやすく、不可逆（決済、外部送信、削除）なツールは段階的自律の上位段階でも人間の承認を残す。⑥の権限設計と組み合わせ、「戻せない操作ほど、出す速度を落とす」という原則を貫きます。
運用チェックリスト
ここまでの5つの規律を、リリースの前・最中・後で確認できるチェックリストにまとめます。
| フェーズ | 確認項目 |
|---|---|
| 出す前 | プロンプト・モデル・ツール定義・メモリスキーマを1つのマニフェストとして固定・記録したか |
モデルは日付・世代までピン留めされているか（latest を使っていないか） | |
| 出す最中 | カナリア比率と自律度の2つのダイヤルを絞って段階投入しているか |
| 各段階にオンライン評価ゲート（品質・回帰・コスト・レイテンシ・安全性）を置いたか | |
| 出した後 | サイレント更新・ドリフトを検知する定点観測が回っているか |
| マニフェスト即時切替・スキーマ後方互換・副作用の補償という3層のロールバックが準備できているか |
Q&A
Q1. カナリアリリースだけやっておけば十分ですか。
不十分です。カナリアはトラフィックを絞る手段ですが、エージェントでは自律度という第2の軸があります。低比率でも高リスク操作を完全自動で回せば事故は起こり得ます。トラフィック比率と自律度は独立に絞るべき2つのダイヤルです。
Q2. シャドーデプロイは常にやるべきですか。
効果は高いですが、副作用のあるツールを呼ぶエージェントでは注意が必要です。影のはずの実行が決済やメール送信を二重に起こさないよう、シャドーモードでは副作用系ツールをドライランに切り替える仕組みが前提です。それがなければ、読み取り系・大規模モデル更新の検証に限定して使うのが安全です。
Q3. モデルを latest で運用してはいけないのですか。
本番では避けるべきです。latest はプロバイダの都合で実体が差し替わり、あなたが何もしていないのに挙動が変わります。日付・世代まで固定したバージョンをピン留めし、モデル更新を意図的なリリースイベントとして扱ってください。
Q4. オンライン評価ゲートのしきい値は、どのくらい厳しくすべきですか。
一律の正解はありません。旧マニフェストとの相対比較を基本にし、「回帰の不在」は厳格に、「品質スコア」は許容幅を持たせる、といった濃淡をつけるのが実務的です。②で作ったゴールデンセットと評価基準を、そのまま関門のしきい値に流用するのが出発点です。
Q5. ロールバックすれば元通りになりますか。
コードとマニフェストは戻せますが、状態は戻せないことがあります。特に「すでに現実世界で起こした副作用」は取り消せません。ロールバックは万能ではないという前提で、後方互換なスキーマ設計と、打ち消し操作（補償トランザクション）をあらかじめ用意しておくことが重要です。
まとめ
エージェントのデプロイは、「テストが緑になった」ことをゴールにはできません。非決定性と、プロバイダによるサイレントなモデル更新があるからです。だからこそ、デプロイを一度きりのイベントではなく、継続的な運用規律として設計し直す必要があります。
本記事の骨子は5つです。第一に、プロンプト・モデル・ツール定義・メモリスキーマを束ねたリリースマニフェストで「何がリリースか」を確定する。第二に、カナリア・シャドー・段階的自律というプログレッシブデリバリーで小さく出す。第三に、②評価のゴールデンセットをオンライン評価ゲートとして本番前の関門にする。第四に、モデルをピン留めしてサイレント更新を意図的なリリースに格下げする。第五に、状態を持つエージェントを壊さない3層のロールバックを用意する。
「リリースが事故になる」を防ぐとは、出す速度を落とすことではなく、出す速度を状況に応じて制御できる状態を作ることです。②評価・③観測・④コスト・⑤メモリ・⑥権限で積み上げてきた要素は、この「デプロイ」という軸の上で、ひとつの運用体系として束ねられます。次回以降で、最後のピースであるインシデント対応へと進みます。
関連記事・参考リンク
- 【AgentOps⑥・権限】Just-in-Timeアクセスと最小権限の運用規律（段階的自律の土台となる権限設計）
- 【AgentOps⑤・メモリ】長期記憶のライフサイクル運用とドリフト監視（スキーマの後方互換・ドリフト検知）
- 【AgentOps④・コスト】ユニットエコノミクス設計とトークン予算ガードレール（評価ゲートのコスト基準と連動）
コメント