PromptOps編（”指示資産”）、ナレッジ運用編（”参照資産”）、ツール運用編（”能力資産”）と、エージェントの可変資産を運用対象として扱ってきた。だが、この3つの資産はすべて、ある1つの土台の上に載っている。エージェントの頭脳＝LLMそのものだ。
多くの現場では、モデルは「PoCのときに選んだもの」が、そのまま本番で使われ続けている。選定の瞬間がゴールになっていて、その後の運用は「バージョンをピン留めしておけば安心」で止まっている。しかし2026年のいま、主要ベンダーからは数週間単位で新モデルが出て、旧モデルには廃止（deprecation）期限が付く。ピン留めしたモデルはいずれ提供元の都合で使えなくなるし、エイリアス（例：「latest」系の指定）で呼んでいれば、ある日を境に中身が入れ替わる。
本稿のテーマは、モデルを「一度選んで終わり」の設定値ではなく、版・品質・互換性・廃止のライフサイクルを持つ資産として運用するための規律——ModelOpsである。モデルカタログ、世代交代の評価ゲート、カナリアつきルーティング切替、旧モデルの廃止までを一続きの運用として設計し、”サイレントな精度劣化と互換崩れ”を防ぐ方法を、実務目線で整理する。
1. 本稿の位置づけ——”頭脳”が資産棚の最後の一枚
シリーズの見取り図
- PromptOps編（指示資産）：プロンプトを「設定」ではなく「ソースコード」として版管理する運用規律。
- ナレッジ運用編（参照資産）：エージェントが参照する知識をいつ・何で更新し、どう鮮度を担保するかの運用規律。
- ツール運用編（能力資産）：エージェントが呼ぶツール（MCP／Function）を、版・品質・評価の対象として統制する運用規律。
- 本稿＝モデル運用編（基盤資産）：エージェントの頭脳であるLLMそのものを、評価→カナリア→切替→廃止のライフサイクルで能動的に入れ替える運用規律。
プロンプトもナレッジもツールも、「どのモデルが解釈するか」で振る舞いが変わる。つまりモデルは、他の3資産すべての前提条件だ。ここを運用に載せない限り、残り3つをどれだけ丁寧に版管理しても、土台が静かに動いた瞬間に全体が崩れる。
なお、連載の過去回にもモデルに触れた記事がある。本稿との違いを先に整理しておく。
| 既存記事 | モデルをどう扱ったか | 本稿との違い |
|---|---|---|
| AgentOps④・コスト | タスクの難易度に応じて安いモデル／高いモデルを振り分けるコスト最適化としてのルーティング | 本稿の主題は品質・互換性・世代交代。目的が異なる |
| AgentOps⑦・デプロイ | リリース事故を防ぐためのバージョンのピン留め（静的な固定） | 本稿は新モデルを能動的に評価して乗り換える“攻め”のライフサイクル |
| モデルカスケード／ルーティング層セキュリティ | ダウングレード攻撃など、ルーティング層を狙う攻撃への防御設計 | 本稿は平時の選定・切替・廃止の運用規律。軸が違う |
| AEO×AIエンジン更新ボラティリティ | 外部AIエンジン側の変化を検知・追随する（AEO・供給側の視点） | 本稿は自社が使うモデルを自ら入れ替える内向きの運用 |
一言でいえば、ピン留め（⑦）は「勝手に変わらないようにする」守りの規律、本稿は「変えるべきときに、安全に変えられるようにする」攻めの規律である。両方がそろって、はじめてモデルは運用資産になる。
2. なぜモデルは”選んで終わり”で壊れるのか
モデル起因のトラブルが厄介なのは、ほとんどがエラーにならないことだ。APIはステータス200を返し続け、応答も一見もっともらしい。壊れ方を整理すると次のようになる。
| 壊れ方 | 何が起きるか | エージェント側の見え方 |
|---|---|---|
| エイリアスの指す先の変更 | 「最新版」指定のエイリアスが、提供元の更新で新しいスナップショットに切り替わる | ある日から微妙に言い回し・判断・拒否傾向が変わる |
| サイレントな精度劣化 | 新しい版で、自社タスクに限って精度が落ちる（汎用ベンチマークでは向上していても） | エラーなし。成功率やユーザー評価がじわじわ下がる |
| 互換崩れ | JSON出力の揺れ、ツール呼び出しの引数形式、システムプロンプトの解釈の変化 | パース失敗・リトライ増加・ツールの誤呼び出し |
| 仕様・条件の変化 | コンテキスト長、トークナイザ、料金、レート制限、推論時間の変化 | コスト急増・タイムアウト・長文の切り捨て |
| 廃止期限の到来 | ピン留めしていた版が提供終了になる | 期限直前の駆け込み移行、または突然の呼び出し失敗 |
エイリアスとスナップショット——「固定したつもり」が一番危ない
多くのモデルAPIは、日付や版番号付きのスナップショット名と、それを指すエイリアス名の両方を提供している。エイリアスは便利だが、中身がいつ入れ替わるかは提供元が決める。本番でエイリアスを使っている場合、それは「固定」ではなく提供元に切替タイミングを委ねている状態だ。本番経路は必ずスナップショットで呼び、エイリアスは評価・検証用に限定するのが原則である。
「新しい＝良い」ではない
新モデルは汎用ベンチマークでは前世代を上回ることが多い。しかし、自社のエージェントが解いているのは汎用ベンチマークではなく、自社のプロンプト・自社のナレッジ・自社のツールで構成された固有のタスクだ。前世代に合わせて磨いたプロンプトが新モデルでは過剰指示になったり、推論が丁寧になった結果、出力フォーマットが崩れたりする。乗り換えの判断基準は「世間の評価」ではなく「自社のゴールデンセットでの結果」でなければならない。
3. モデルカタログ——頭脳の台帳をつくる
ツール運用編でツールレジストリをつくったのと同じく、まずは使っているモデルの台帳（モデルカタログ）を唯一の情報源にする。「どのエージェントが、どのモデルの、どの版を、何の用途で呼んでいるか」が即答できない状態では、評価も切替も廃止も始められない。
| 属性 | 意味・なぜ必要か |
|---|---|
| モデルID（スナップショット） | エイリアスではなく実体の版を記録する。変更追跡の起点 |
| 提供者・提供経路 | 直接API／クラウド経由／ローカルLLMの別。経路ごとに廃止スケジュールや仕様が異なる |
| 用途（ロール） | 計画、ツール選択、要約、分類、ガードレール判定など。用途ごとに評価基準が違う |
| 利用エージェント | そのモデルを変えたときの影響範囲（ブラスト半径） |
| 評価ベースライン | 現行版のゴールデンセット結果。新版と比べる基準線 |
| 依存するプロンプト版 | PromptOpsの版と紐づける。モデルとプロンプトは”ペア”で動く |
| 廃止予定日（提供元） | 提供元が公表している提供終了日。移行計画の締め切り |
| 所有者（owner） | 評価・切替・廃止の判断責任者 |
カタログは、スプレッドシートでもYAMLでもよい。重要なのは、ルーティング設定（どのリクエストをどのモデルに流すか）と同じリポジトリで版管理し、変更をレビュー経由にすることだ。
# model-catalog.yaml（例）
- role: planner
model_id: vendor-a/model-x-2026-07-15 # エイリアスではなくスナップショット
provider: vendor-a (direct API)
agents: [support-agent, order-agent]
prompt_version: planner-prompt@v14
baseline:
golden_set: planner-gs@v6
task_success: 0.91
schema_valid: 0.995
provider_deprecation: 2027-01-31
owner: platform-team
- role: guardrail-classifier
model_id: vendor-b/model-s-2026-05-02
provider: cloud-x (managed)
agents: [all]
prompt_version: guard-prompt@v5
baseline:
golden_set: guard-gs@v3
recall_on_attack: 0.97
false_positive: 0.02
provider_deprecation: null
owner: security-team
ここで「用途（ロール）」単位で管理しているのがポイントだ。エージェント単位でモデルを持つと、同じモデルの廃止対応を何十か所で繰り返すことになる。ロール単位にしておけば、「plannerロールのモデルを入れ替える」という1つの変更として扱える。
4. 世代交代の評価ゲート——”乗り換えてよいか”を数値で決める
新モデルが出るたびに「試しに使ってみたら良さそう」で切り替えるのは、PromptOps編で否定した「本番で直接プロンプトを書き換える」のと同じ構造の事故を生む。乗り換えは、オフライン評価のゲートを通過した候補だけが次の段階に進める仕組みにする。
| ゲート | 何を見るか | 通過基準の例 |
|---|---|---|
| ①品質 | ロール別ゴールデンセットでのタスク成功率・正答率 | 現行ベースライン比で劣化なし（許容誤差内） |
| ②互換性 | JSONスキーマ準拠率、ツール呼び出しの引数妥当性、既存プロンプトの指示追従 | スキーマ準拠率・ツール呼び出し妥当率が現行以上 |
| ③安全性 | 拒否すべき要求の拒否率、過剰拒否率、インジェクション耐性の回帰テスト | 攻撃系テストの通過率が現行以上、過剰拒否が増えない |
| ④コスト・レイテンシ | 1タスクあたりトークン数・料金、p95レイテンシ | 予算・SLOの範囲内（改善なら加点） |
重要なのは、4つのゲートすべてを通過して初めて「候補」になることだ。品質が上がってもスキーマ準拠率が落ちるなら、それは本番ではパース失敗として表面化する。「精度は上がったが互換が崩れた」を見逃さないために、互換性を品質と独立したゲートにしておく。
ゴールデンセットは”モデル非依存”につくる
評価データを現行モデルの出力をそのまま正解として作ると、「現行モデルとどれだけ似ているか」を測る評価になってしまい、新モデルが正しく改善していても減点される。ゴールデンセットは業務上の正解（期待される結果）で定義し、文面の一致ではなく、抽出値・判定・ツール呼び出しの正しさといった機械的に判定できる観点を中心に採点する。自由文の品質評価にLLM審査員（LLM-as-a-Judge）を使う場合は、審査員モデル自体もカタログに載せ、評価対象と審査員を同じモデルにしない。
モデルとプロンプトは”ペア”で評価する
プロンプトは、無意識のうちに現行モデルの癖に合わせてチューニングされている。新モデルで評価が落ちたとき、原因が「モデルが悪い」のか「プロンプトが旧モデル向けに最適化されすぎている」のかを切り分ける必要がある。実務では次の2本立てで評価するとよい。
- 現行プロンプト × 新モデル：そのまま差し替えた場合の互換性を測る（回帰の検知）
- 調整済みプロンプト × 新モデル：新モデル向けに調整した場合の到達点を測る（乗り換えの価値の見積もり）
2の結果で乗り換えるなら、それはモデル変更とプロンプト変更の同時リリースになる。PromptOpsの版と紐づけて、カタログ上も「model-x × planner-prompt@v15」というペアで登録する。
5. カナリアつきルーティング切替——少しずつ流し、ダメなら即戻す
オフライン評価は必要条件であって十分条件ではない。本番の入力分布はゴールデンセットより必ず広い。そこで、ルーティング層（モデルゲートウェイ）でトラフィックの一部だけを新モデルに流すカナリアを行う。
| 段階 | 流し方 | 見るもの／次に進む条件 |
|---|---|---|
| ①シャドー | 本番リクエストを新モデルにも複製して流す（応答はユーザーに返さない） | スキーマ準拠率、ツール呼び出しの一致率、トークン数。副作用のあるツールは実行しない |
| ②カナリア（数%） | 低リスクな用途・社内ユーザーから少量を新モデルへ | タスク成功率、エラー・リトライ率、エスカレーション率、ユーザー評価 |
| ③段階拡大 | 10% → 50% と比率を上げる | 各段階で一定期間・一定件数を観測し、ベースラインとの差分が許容内 |
| ④全面切替 | 100%を新モデルへ。旧モデルは即時戻せる状態で待機 | 一定期間の安定を確認後、カタログの現行版を更新 |
# routing.yaml（例）
route: planner
primary: vendor-a/model-x-2026-07-15
candidate: vendor-a/model-y-2026-09-10
canary:
stage: canary
weight: 5 # 新モデルへの比率（%）
cohort: internal-users
sticky_by: session_id # 同一セッション内でモデルが切り替わらないようにする
abort_if:
schema_valid_rate: "< 0.99"
task_success_delta: "< -0.02" # ベースライン比
retry_rate_delta: "> 0.05"
p95_latency_ms: "> 8000"
on_abort: route_all_to_primary
自動ロールバック条件を”先に”決めておく
カナリアの失敗は、始めてから議論すると判断が遅れる。上の abort_if のように、どの指標がどこまで悪化したら自動で旧モデルに戻すかを、切替前に合意しておく。⑦デプロイ編のオンライン評価ゲートと同じ考え方だが、モデル切替では特にスキーマ準拠率とリトライ率が早期の警報として効く。精度劣化は統計的に有意になるまで時間がかかるが、互換崩れは数十件で表に出るからだ。
セッション単位で固定する
マルチターンの会話や長いエージェント実行の途中でモデルが切り替わると、前のターンの前提を新モデルが違う解釈で引き継ぎ、挙動が不安定になる。カナリアの振り分けはリクエスト単位ではなく、セッション（またはタスク）単位でスティッキーにするのが安全だ。
6. 旧モデルの廃止（deprecation）——提供元の期限と、自社の期限
ツール運用編で「増やす規律と同じ強さで減らす規律を回す」と書いた。モデルも同じだ。新モデルに切り替えた後、旧モデルを「念のため」残し続けると、ルーティング設定・評価ジョブ・コスト管理の対象が増え続け、いざ提供元が廃止したときにどこでまだ使われていたか分からない状態になる。
| 段階 | やること |
|---|---|
| ①廃止予告の受信 | 提供元の廃止告知・モデルライフサイクルページを定期監視し、カタログの廃止予定日を更新する |
| ②影響範囲の特定 | カタログとルーティングログから、その版を呼んでいるロール・エージェントを洗い出す |
| ③後継の評価と切替 | 第4章の評価ゲート→第5章のカナリアで後継モデルに移行する |
| ④待機期間 | 切替後も一定期間は即時ロールバック先として旧モデルを残す（期限を決めて） |
| ⑤撤去 | ルーティング設定・APIキーの権限・評価ジョブ・カタログから旧版を削除し、呼び出しゼロをログで確認する |
「自社の期限」を提供元の期限より前に置く
提供元の廃止日を自社の締め切りにすると、評価ゲートやカナリアに十分な時間を取れず、結局「期限が来たから評価を省略して切り替える」ことになる。自社の移行完了期限は、提供元の廃止日から逆算して余裕を持って前倒しに置く。目安として、評価（数週間）＋カナリア（数週間）＋待機期間が収まる長さを確保したい。
クラウド経由・ローカルLLMの廃止にも注意
同じモデルでも、提供元の直接APIとクラウド経由（マネージドサービス）では廃止スケジュールが異なることがある。また、ローカルLLMは「提供元による廃止」はないが、推論ランタイムやドライバの更新、脆弱性対応で自社都合の入れ替えが必要になる。カタログの「提供経路」を分けて持つのはこのためだ。
7. 運用リズム——週次でモデルが出る時代の回し方
新モデルのリリースのたびに全ロールを評価するのは現実的ではない。発表の追跡、評価、切替、棚卸しを頻度の異なるリズムに分けて回す。
| 頻度 | やること | アウトプット |
|---|---|---|
| 週次 | 新モデル発表・廃止告知・料金変更のウォッチ。候補を「評価待ちリスト」に登録 | 評価待ちリスト、廃止予定日の更新 |
| 月次 | 評価待ち候補から優先度の高いものをゲート評価。ロール別に「乗り換える／見送る」を判断 | 評価レポート、切替計画 |
| 四半期 | カタログ全体の棚卸し。未使用モデル・期限の近いモデル・ベースラインの古い評価セットを整理 | 撤去リスト、ゴールデンセットの更新 |
| 随時（トリガー） | 廃止告知、品質の急変、セキュリティ告知を受けたときの臨時評価 | 緊急移行計画 |
筆者はネットワーク機器のTACで長年、OSイメージの推奨版管理やEoL（End of Life）対応に携わってきた。ネットワークの世界では「どのルーターが、どのOSの、どのリリースを動かしているか」を台帳で把握し、推奨版の評価→限定展開→全面展開→旧版のサポート終了対応を回すのは当たり前の運用だ。LLMの世代交代は、そのソフトウェア・ライフサイクル管理と同じ構造を、はるかに速いサイクルで回すものだと捉えると、必要な仕組みが見えやすくなる。
8. ModelOps運用チェックリスト
| 領域 | チェック項目 |
|---|---|
| 台帳 | 全ロールのモデルがスナップショット名でカタログに登録され、所有者と廃止予定日が記載されている |
| 台帳 | 本番経路でエイリアス（最新版指定）を使っていない |
| 台帳 | モデルとプロンプトの版がペアで紐づいている |
| 評価 | ロール別に、業務上の正解で定義されたゴールデンセットがある |
| 評価 | 品質・互換性・安全性・コスト／レイテンシの4ゲートと通過基準が文書化されている |
| 評価 | LLM審査員を使う場合、評価対象と別のモデルで、審査員もカタログ管理されている |
| 切替 | ルーティング層で比率指定のカナリアとセッション単位の固定ができる |
| 切替 | 自動ロールバック条件（abort条件）が切替前に合意されている |
| 切替 | シャドー実行時に副作用のあるツールが実行されない |
| 廃止 | 提供元の廃止告知を週次で監視している |
| 廃止 | 自社の移行期限を提供元の廃止日より前倒しで設定している |
| 廃止 | 旧モデルの撤去時に、ルーティング・権限・評価ジョブ・カタログから削除し、呼び出しゼロを確認している |
9. よくある質問（Q&A）
Q1. バージョンをピン留めしていれば、ModelOpsは不要ではないですか？
ピン留めは「勝手に変わらない」ことを保証しますが、「ずっと使い続けられる」ことは保証しません。提供元の廃止期限が来れば、いずれ移行は避けられません。ピン留めだけで運用していると、移行が常に「期限直前の駆け込み」になります。ピン留めは前提として維持しつつ、計画的に次の版へ移る仕組みを持つのがModelOpsです。
Q2. 新モデルが出るたびに評価するのは、中小規模のチームには重すぎませんか？
すべての新モデルを評価する必要はありません。週次ウォッチで「評価待ちリスト」に積み、月次で優先度の高いものだけ評価すれば十分です。また、評価ゲートは一度自動化すれば、候補モデルIDを差し替えて回すだけになります。最初はロールを1つ（最も重要なもの）に絞り、ゴールデンセットも数十件から始めるのが現実的です。
Q3. コスト編④のモデルルーティングと、本稿のルーティング切替は何が違うのですか？
コスト編のルーティングは「リクエストの難易度に応じて、どのモデルに振り分けるか」という恒常的な振り分けです。本稿のルーティング切替は「あるロールのモデルを旧版から新版へ移す」という一時的な移行プロセスです。同じルーティング層を使いますが、目的も期間も異なります。コスト最適化の振り分け先に入っている各モデルも、本稿のライフサイクル管理の対象になります。
Q4. 汎用ベンチマークで新モデルの方が明らかに高スコアです。それでも自社評価は必要ですか？
必要です。汎用ベンチマークは自社のプロンプト・ナレッジ・ツールの組み合わせを反映していません。実際に多いのは、全体の能力は上がっているのに、出力フォーマットの揺れやツール呼び出しの形式の違いで、自社のパイプラインでは互換が崩れるケースです。汎用スコアは「評価待ちリストに入れる優先度」の判断材料にとどめ、切替判断は自社のゴールデンセットで行ってください。
Q5. ローカルLLMやオープンウェイトのモデルにも同じ運用が必要ですか？
必要です。提供元による強制廃止はありませんが、量子化設定の変更、推論ランタイムの更新、新しいオープンウェイトモデルへの乗り換えなど、自社都合の入れ替えは頻繁に発生します。むしろ「いつでも同じものが使える」安心感から、評価なしで入れ替えてしまう事故が起きやすい領域です。カタログ・評価ゲート・カナリアの仕組みはそのまま適用できます。
10. まとめ——”頭脳”も運用資産として手入れする
モデルは「選んで終わり」ではない。プロンプト（指示資産）・ナレッジ（参照資産）・ツール（能力資産）のすべてを支える基盤資産として、版・評価・切替・廃止のライフサイクルで運用してはじめて、”サイレントな精度劣化と互換崩れ”を防げる。
- 台帳で束ねる——モデルカタログをスナップショット単位・ロール単位で持ち、プロンプトの版とペアで管理する。エイリアスに切替タイミングを委ねない。
- ゲートとカナリアで”安全に変える”——品質・互換性・安全性・コストの4ゲートを通過した候補だけを、自動ロールバック条件つきのカナリアで少しずつ本番に流す。
- 廃止まで回して”手入れ”する——提供元の期限より前に自社の期限を置き、旧モデルを撤去して呼び出しゼロを確認するまでを運用に含める。
新モデルが週次で出る時代、競争力の差は「どのモデルを選んだか」ではなく、「良いモデルが出たときに、どれだけ速く・安全に乗り換えられるか」でつく。その乗り換え能力こそが、ModelOpsが組織にもたらす資産である。
関連記事
- 【AgentOps・PromptOps編】”プロンプトは設定ではなくソースコード”——指示資産を版管理する運用規律
- 【AgentOps・ナレッジ運用編】”覚えさせて終わり”にしない——エージェントが参照する知識ベース（RAGインデックス）の運用規律
- 【AgentOps・ツール運用編】”つないで終わり”にしない——エージェントが呼ぶツール（MCP／Function）という”能力資産”の運用規律
- 【AgentOps⑦・デプロイ】”テストは緑、本番は別物”の落とし穴——エージェント・デプロイのライフサイクル運用規律
- 【AgentOps・フリート編】”1体を運用する”から”群れを運用する”へ——エージェント・フリート管理の運用規律
参考リンク
- OpenAI｜Deprecations（モデル廃止スケジュール）
- Anthropic｜Model deprecations
- Google Cloud｜Vertex AI モデルのバージョンとライフサイクル
- Microsoft Learn｜Azure OpenAI モデルの廃止（retirements）
- NIST｜AI Risk Management Framework
※本記事は運用設計の考え方を一般化して解説したものであり、特定の製品・サービスの動作や安全性を保証するものではありません。記載の設定例は説明用のサンプルです。各モデル・APIの利用にあたっては、提供元の最新の仕様・利用規約・廃止スケジュールをご確認ください。
コメント