この記事の音声は準備中です。
音声の一覧・再生リストへバージョニング・デプロイ・モデル更新追従
この記事の目的
Agent システムの「バージョン」を構成する要素(コード・プロンプト・ツール定義・モデル・judge)を特定して再現可能に管理し、段階的リリースと即時ロールバックの仕組みを設計できるようになります。避けて通れないイベントであるモデル更新(ベンダーの新版リリースと旧版の廃止)に、慌てず追従する手順を持てるようになります。
対象読者
- Agent を継続的にリリースする体制(デプロイ・ロールバック)を設計するエンジニア
- 「モデルの新バージョンが出た/使用中のモデルの廃止予定が出た」に対応する計画を立てたいテックリード
前提知識
- Agent 評価の基礎 — リリース判断の根拠となる評価
- 回帰テストと CI 組み込み — 変更時に何を回すか
本文
概要: Agent の「バージョン」はコードだけではない
Agent の挙動は、次の組み合わせで決まります。
| 構成要素 | 変わると何が起きるか |
|---|---|
| アプリケーションコード | 通常のソフトウェアと同じ |
| プロンプト(システムプロンプト・テンプレート) | 1 行の変更が挙動全体に効く |
| ツール定義(名前・説明文・スキーマ) | ツール選択の傾向が変わる |
| モデル(ID・バージョン) | コード変更ゼロで全挙動が変わる |
| 生成パラメータ・各種設定 | 出力の安定性・傾向が変わる |
| 評価側(データセット・judge プロンプト) | 「品質の物差し」自体が変わる |
バージョニングの目的は、この組み合わせ全体を「ある時点の挙動」として再現可能にすることです。「先週は正しく動いていた」を調査するには、先週どの組み合わせで動いていたかが分かり、それを再現できる必要があります。
詳細: プロンプトはコードと同じ管理に載せる
- プロンプト・ツール定義・設定はコードと同じリポジトリに置き、変更はレビューと回帰テストプロンプト・ツール・モデルの変更で既存の品質が壊れていないかを、評価データセットの再実行と前回比較で検知するテスト。(回帰テストと CI 組み込み)を通します
- 実行時に「どのバージョンのプロンプト・モデルで生成した応答か」をトレースに記録します(可観測性とトレーシング)。これがないと、障害調査で「当時の構成」を特定できません
- 管理画面や DB でプロンプトを直接編集できる仕組みは、迅速に見えて履歴・レビュー・テストのすべてを迂回します。緊急時の変更もフラグ切り替え(後述)で行い、直接編集は避けます
詳細: モデルはスナップショットにピン留めする
多くのベンダーは、モデルを「特定バージョンを指すスナップショット ID」と「最新版を指すエイリアス」の両方で提供します。本番はスナップショットへのピン留めが原則です。エイリアス参照は、ベンダー側の更新でこちらのリリースと無関係に挙動が変わることを意味し、変化の検知すらできません。
ピン留めには期限があります。ベンダーは旧モデルの廃止(deprecation)スケジュールを公表するため、モデル更新は「いつかやる改善」ではなく期限付きの計画タスクとして扱います。
詳細: 段階的リリースとロールバック
Agent の変更は評価スイートだけでは影響を測り切れないため(実トラフィックの分布はスイートより広い)、本番投入は段階的に行います。
| 段階 | 仕組み | 分かること |
|---|---|---|
| シャドー実行 | 本番トラフィックを新旧両構成で処理し、ユーザーには旧の結果だけを返す | 実トラフィックでの差分(コスト 2 倍とのトレードオフ。副作用のあるツールはシャドー側で実行しない設計が必要) |
| カナリアリリース | 数 % のトラフィックだけ新構成に向ける | 実ユーザー影響の限定的な確認。品質シグナル・技術メトリクスを新旧で比較する |
| 全量リリース | 全トラフィックを切り替える | — |
前提として、構成の切り替えがデプロイなしでできる(機能フラグ・設定参照)ことが重要です。これはそのままロールバック手段になります — プロンプト・モデル・ツール定義のどれが原因でも、旧構成へフラグ 1 つで戻せる状態を保ちます。旧構成は新構成の安定を確認するまで削除しません。
設計判断: モデル更新の標準手順
モデル更新(新版への移行・廃止対応)は、次の手順を標準にします。
- 新モデルで全評価スイートを実行します。judge のモデルも変えるなら、先に judge 自体を人手ラベルで再検証します(LLM-as-a-Judge)
- 差分を分析します。集計値でなく「新たに落ちたケース」を読みます
- プロンプトを再調整します。旧モデルの癖を補うための強い表現が、新モデルでは過剰に効くことがあります(Agent 向けプロンプト設計)
- シャドー → カナリア → 全量で段階的に切り替えます
- 旧モデルへのロールバック経路を廃止期限まで維持します
実務での注意点
アンチパターン
- プロンプトを管理画面・DB で直接編集する → 何がいつ変わったか追えず、レビューも回帰テストも通らない。「昨日から挙動が変」の原因調査が不可能になる → コードと同じリポジトリ・レビュー・CI に載せる
- エイリアス参照で本番運用する → ベンダー側の更新で無告知に挙動が変わり、こちらの変更履歴に何も残らない → スナップショットにピン留めし、更新は計画タスクとして実施する
- ロールバックがデプロイのやり直し → 障害時の復旧が遅れ、その間の被害が拡大する → フラグでの即時切り替えを用意し、旧構成を一定期間保持する
- 廃止アナウンスを追っていない → 期限直前の強制移行になり、評価・再調整の時間がないまま新モデルへ切り替える羽目になる → 廃止スケジュールの定期確認を運用タスクにする(ROADMAP の定期メンテナンスと同様の考え方)
チェックリスト
- プロンプト・ツール定義・設定がコードと同じリポジトリでレビュー・CI を通っている
- トレースから任意の応答の生成時構成(プロンプト・モデルのバージョン)を特定できる
- 本番のモデル指定がスナップショット(ピン留め)になっている
- 構成の切り替え・ロールバックがデプロイなしでできる
- シャドー実行時に副作用のあるツールが二重実行されない設計になっている
- モデル更新の標準手順(評価 → 差分 → 再調整 → 段階リリース)が文書化されている
- 利用モデルの廃止スケジュールを定期確認する運用がある
関連トピック
- 回帰テストと CI 組み込み — 「何が変わったら何を回すか」の評価側
- プロンプト資産の管理とバージョニング — 資産管理・変更ワークフローの日常運用側(本記事はリリース・ロールバックの機構側)
- Agent 向けプロンプト設計 — モデル更新時の再チューニング
- 可観測性とトレーシング — バージョン情報の記録先
- インシデント対応 — ロールバックが必要になる場面の対応全体
- LLM-as-a-Judge — 物差し側(judge)の更新手順
- モデル間の違いと移行(横断比較) — モデル更新・乗り換え時のプロンプト面の書き直し
- MLOps と LLMOps の統合 — バージョニングを既存 ML 基盤・組織にどう束ねるか
参考資料
- Model deprecations(Anthropic docs) — モデル廃止のスケジュールと移行推奨の例(アクセス日: 2026-07-05)