本番LLMアプリのモデル移行｜「とりあえず差し替え」と「固定したまま廃止日」を避ける手順

本番で動いているLLMアプリを持っていると、モデルの入れ替えは避けて通れません。新しいモデルが出れば「上げれば良くなるはず」と思いますし、使っているモデルに廃止日が付けば、上げる/上げないの選択肢自体が消えます。それでも現場でよく見るのは、リリース当日にモデルIDを差し替えて出力形式が崩れる壊し方と、怖くて古いモデルにピン留めしたまま廃止日の直前に慌てる詰まり方の2つです。どちらも「移行を1回きりのイベントとして扱っている」という同じ原因から来ています。この記事では、モデル移行を繰り返し回せるプロセスとして組む方法を、各社の公式ドキュメントで裏を取りながら整理します。

二つの失敗パターン#

一つ目は「とりあえず差し替え」です。新モデルの発表を見て、その日のうちにモデルIDだけを書き換えてデプロイする。APIは200を返し、目視で試した数件もそれらしく動くので問題ないように見えます。数日後に「要約が長すぎる」「JSONのパースに失敗する」「請求が増えている」と別々の場所から報告が上がってきて、切り分けに時間を取られます。

Microsoft Foundryのモデル移行ドキュメントは、この性質を端的に書いています。モデルの入れ替えは1行の変更ではなく、別のモデルはトーン・書式・JSONの形・レイテンシ・コスト・ツール呼び出しの挙動を静かに変え、旧挙動に依存した下流のコードを壊しうる、という説明です。エンドポイントが応答を返すこととアプリが正しく振る舞うことは別だ、とも書かれています。

二つ目は「固定したまま廃止日」です。一度チューニングが決まったモデルIDにピン留めし、以降は触らない。安定はしますが、廃止のアナウンスに気づいた時点で残り時間が足りず、検証を省いた駆け込み切り替えになります。同ドキュメントは、廃止期限に迫られて下されるロールバックの判断は着手が遅すぎたサインだ、と指摘しています。

どちらの失敗も、移行のたびにゼロから考えていることが根にあります。廃止情報の受け口・棚卸しの手順・回帰テストのセット・段階切り替えの仕組みを一度作れば、次から作業量が減ります。

移行を6つの段に分けて考える#

工程を分けておくと、どこで詰まっているのかを言語化できます。Microsoft Foundryのドキュメントは、モデル移行を6つのフェーズで説明しています。Foundry固有の機能名を除けば提供元によらず使える枠組みです。

同ドキュメントは、実際の移行は二値ではないとも書いています。ワークロードの一部だけが新モデルで動き、レイテンシに敏感な経路やリスクの高い経路は旧モデルに残ることが数週間続く。一発切り替えではなく、部分展開と部分ロールバックを前提に設計するほうが現実的だ、という整理です。

廃止情報をどこで拾うか#

移行の起点は情報です。まず押さえるべきは、提供元ごとにライフサイクルの用語も通知期間も揃っていない、という事実です。「deprecated」が指す状態が各社で違うため、社内で共通語彙にしないと話が噛み合いません。

各社のdeprecationページ#

一次情報の置き場所は次の4つです(いずれも記事執筆時点で参照できることを確認しています)。

用語と通知期間の違い#

各社の公式ドキュメントに書かれている定義と通知期間を並べると、次のようになります。

OpenAIは通知をメールとドキュメントで行い、大きな変更にはブログ記事も伴うとしています。Microsoftはメールに加えてAzure Service Healthのヘルスアドバイザリで届くとしています。なお、Foundryの「Deprecated」が指す「既存顧客」はサブスクリプション単位で判定されるため、同じテナント配下の新しいサブスクリプションには引き継がれません。

エイリアスとピン留めのどちらを踏むか#

モデルIDを固定のスナップショットにするか自動更新されるエイリアスにするかは、廃止情報の拾い方そのものに関わります。Gemini APIのモデルページには、latestエイリアスは特定のモデルバリエーションの最新リリースを指し、安定版・プレビュー・実験版のいずれにもなりうること、新しいリリースのたびにホットスワップされることが書かれています。そのうえで破壊的変更については、latestの背後にあるバージョンが変わる前にメールで2週間の予告が行われる、とされています。

Azure側では、デプロイのversionUpgradeOptionプロパティで挙動を選べます。公式ドキュメントによれば値はOnceNewDefaultVersionAvailable(新しい既定バージョンが設定されたら上げる)、OnceCurrentVersionExpired(引退時にだけ上げる)、NoAutoUpgrade(自動更新せず、引退時点で動作しなくなる)の3つです。加えて、Standard系はリージョンごとのローリングスケジュールで自動アップグレードされる一方、プロビジョニング済み(PTU)のデプロイは自動アップグレードされず自分で移行する必要がある、と明記されています。

固定スナップショットを選んでも、永久に使える保証はありません。OpenAIのdeprecationsページには、2026年6月11日にgpt-5-2025-08-07やo3-2025-04-16などのスナップショットが非推奨としてアナウンスされ、2026年12月11日にAPIから削除される、という記載があります。ピン留めで得られるのは「勝手に変わらない」ことだけで、「いつまでも使える」ことではありません。

情報を人に届ける仕組み#

ページの場所を知っていることと、担当者に届くことは別です。Foundryの移行ドキュメントも、Discoverフェーズがよく壊れる理由として、廃止情報をバラバラの経路で受け取り気づくのが遅れる点を挙げます。

移行前の棚卸し#

次は「どこで何を呼んでいるか」の把握です。ここを飛ばすと、移行したつもりで残った経路が期限当日に落ちます。

grepだけでは足りない#

コードベースをモデルIDで検索するのは出発点ですが、それだけでは漏れます。実務で見落としがちなのは次のような置き場所です。

• 環境変数やコンフィグファイル、デプロイ時のシークレット
• データベースやフィーチャーフラグに保存された設定(管理画面から変更できるもの)
• バッチジョブ、cron、ワークフロー定義、IaCのテンプレート
• 評価スクリプトや開発用スクリプト(本番ではないが移行時に基準値がずれる)
• SDKやフレームワークの既定モデル(明示していないと既定値が使われる)

課金データ側からも突き合わせる#

実際に呼ばれた記録から逆引きすると漏れが見つかります。Anthropicのmodel deprecationsページには、非推奨モデルの利用を特定する監査手順として、ConsoleのUsageページでExportをクリックし、ダウンロードしたCSVでAPIキー別・モデル別の利用状況を確認する、という3手順が載っています。Azureの場合はModels APIでlifecycleStatusやdeprecation.inference、SKUごとのdeprecationDateを取得できると案内されています。「請求されている単位」と「コード上の呼び出し箇所」を突き合わせると、把握していなかった経路が出てきます。

モデルIDの持ち方を直す#

一つはモデルIDの外出しです。コードに直書きされていると移行のたびにビルドとデプロイが必要になり、カナリアも一部だけの切り戻しもできません。設定として持てば、切り替えは設定変更で済みます。

もう一つは用途ごとの論理名です。呼び出し側はsummarizerやextractorのような役割名を指定し、実際のモデルIDへの対応表を1か所に置きます。こうしておくと「要約だけ新モデル、抽出は旧モデルのまま」という部分移行が自然に表現できます。

三つ目はプロンプトとモデルの結合度です。プロンプトは特定のモデルの癖に合わせて調整されているのが普通なので、モデルIDと紐づけてバージョン管理しておくと移行時に「戻す」判断がしやすくなります。

ゴールデンセットと回帰テスト#

移行の可否を判断する材料は評価です。他の記事と重なるので、移行に固有の論点に絞ります。

先に凍結する#

Foundryの移行ドキュメントは、移行作業を始める前に代表的な入力・期待出力・合意された成功基準の集合を用意し、移行の全期間にわたってそれを固定(freeze)せよ、と繰り返し書いています。途中で変えると旧モデルと新モデルの結果を比較できなくなるからで、結果を比較可能に保つうえでプロセス全体で最も重要な規律だとしています。データセットが記述しているのは候補モデルではなく自分たちのワークロードなので、移行先を決める前に用意できます。

もう一つ先手を打つ必要があるのが本番トレースの記録です。同ドキュメントは、本番のコンテンツ取得はオプトインであり遡及しない(never retroactive)ため記録していないトラフィックは評価できない、として、プロンプト・レスポンス・レイテンシ・トークン数を今から記録し始めるよう勧めています。移行のたびに「代表的な入力が手元にない」で止まるチームは、ここが原因です。

何を測るか#

移行の判断に必要な指標は品質だけではありません。Foundryのドキュメントは、サインオフに対応する3つの次元として品質(評価器やレビュアーのスコア)、レイテンシ(最初のトークンまでの時間とスループット)、コスト(リクエストあたりの入出力トークン費用)を挙げ、旧モデルと新モデルに同一の評価器を同じ凍結データセットで走らせて比較するよう指示しています。ここにもう一段を足すと安全です。

LLM-as-a-Judgeの使いどころと限界#

自由記述の品質を大量に比較したいとき、人手だけでは回りません。FoundryのValidateフェーズでも、ルールベース・参照ベース・LLM-as-judge・人手レビュー・ドメイン固有のフレームワークのいずれかをルーブリックとして使う、と整理されています。移行の文脈でLLM-as-a-Judgeが向くのは、旧出力と新出力を並べて「どちらが良いか」を判定させる対比較です。絶対評価の点数より2出力の比較のほうが安定しやすく、移行の判断そのものが比較だからです。

一方で限界もあります。判定側のモデルにもバイアスがあり、提示順や長さで結果が動きます。移行の判断に使うなら、順序を入れ替えた2回の判定で結論が変わらないかを確認し、判定モデルは移行対象と別に固定してください。移行と同時に判定モデルまで上げると、何が変わったのか分からなくなります。形式順守やスキーマ検証のように機械的に判定できるものは、コードで検査するほうが確実です。

差分レビューの回し方#

順番は決まっています。まず現行構成を一切変えずに新モデルで再生し、旧モデルの結果と並べます。Foundryのドキュメントは、これによって「モデルが変えた挙動」と「自分が入れた変更」を切り分けられベースラインが得られる、と説明しています。ここでプロンプトを直しながら試すと、何が原因なのか分からなくなります。

差分を読むときのコツは2つです。1つは平均値だけを見ないこと。改善した件数と悪化した件数を別々に数えると、平均が横ばいでも中身が入れ替わっている状況に気づけます。もう1つは悪化した件を実物で読むことです。同ドキュメントも、Adaptフェーズでよく壊れる点として、何をなぜ変えたのかを記録していない診断ループの雑さを挙げています。元のプロンプトを保存し、変更点と理由を残してください。

実際に壊れやすい箇所#

以下はAnthropicの公式移行ガイド(Claude Opus 5への移行)に明記されている事例を中心に挙げます。他社のモデルで同じことが起きるという意味ではなく、「モデル世代をまたぐとこういう種類の変化が起きる」というカタログとして読み、実際の移行では自分が使う提供元の移行ガイドを当たってください。

1. パラメータの互換性#

同じパラメータが次の世代で受け付けられなくなることがあります。Anthropicのmodel deprecationsページには、APIパラメータの非推奨としてtemperature・top_p・top_kが挙げられ、Claude Opus 4.7以降のモデルでは既定値以外を設定すると400エラーになる、と記載されています。推奨される代替はこれらを省略してプロンプトで挙動を誘導することです。同ページはさらに、ほとんどのSDKは非推奨パラメータをリクエスト型に残しているが、Python SDK(v1.0以降)はこれらを削除しており渡すとTypeErrorになる、とも書いています。

推論の深さを指定するパラメータも変わります。同社のOpus 5移行ガイドには、thinking: {type: "enabled", budget_tokens: N}という指定はOpus 4.7以降のモデルでサポートされず400を返すため、thinking: {type: "adaptive"}とeffortパラメータの組み合わせに置き換える、という記述があります。加えてOpus 5では、思考を無効化するthinking: {type: "disabled"}はeffortがhigh以下の場合しか使えず、xhighやmaxと組み合わせると400エラーになります。

2. レスポンスの形と出力形式#

出力形式の崩れには、指示の効き方が変わって書式が揺れるパターンと、レスポンスの構造そのものが変わるパターンがあります。

後者の具体例として、Opus 5の移行ガイドは次のように説明しています。Opus 4.8ではthinkingフィールドなしのリクエストは思考なしで動きますが、Opus 5では同じリクエストがadaptive thinkingで動きます。思考が有効だと、レスポンスは最初のtextブロックの前に1つ以上のthinkingブロックから始まることがあります。したがって、content[0].textのように位置でレスポンスを読むコードや、最初のcontent_block_startイベントをテキストとして扱うストリームハンドラは壊れます。対処は、ブロックを位置ではなくtypeフィールドで選ぶことです。

ツール利用のループを回している場合はさらに注意が要ります。同ガイドは、ツール結果を返すときに各アシスタント応答のthinkingブロックを完全かつ未編集のままAPIへ戻すよう指示しており、編集・並べ替え・部分的な削除を行うと400エラーを返す、としています。

構造化出力についても、Foundryの移行ドキュメントは、モデルによって順守の度合いが違うため旧モデルが緩く満たしていたスキーマに明示的な制約を足す必要が出ることがある、と書いています。

3. プロンプトの効き方とツール呼び出しの傾向#

APIの破壊的変更ではないが、プロンプトの見直しが要る類の変化もあります。Anthropicの移行ガイドは、Opus 4.7がOpus 4.6から持ち込んだ挙動差として、応答長がタスクの複雑さに応じて調整されるようになったこと、指示をより字義どおりに解釈し勝手に一般化しなくなったこと、口調がより率直になったことを挙げ、特定の声色や文量に依存しているプロダクトではスタイル指示を評価し直す必要がある、と説明しています。Opus 5については、既定の文量が前世代より長くなるため簡潔さや目標長を明示的に指示すること、旧モデル向けに書いた検証や自己チェックの指示は過剰検証を招くので削除すること、が挙げられています。

ツールを使うアプリでは、呼び出しの頻度と順序が変わることが実害になります。同ガイドは、Opus 4.7がOpus 4.6よりツールを使う頻度が少なく推論をより多く使う傾向がある、と明記し、ツール利用を増やしたい場合はeffortを上げるかプロンプトで使い方を明示する、と案内しています。Opus 5は前世代よりサブエージェントへ積極的に委譲するため、委譲すべき場面を明示するか数に上限を設けるようにも勧めています。Foundryの移行ドキュメントは、この種の回帰は単発のベンチマークでは見えず実際のトレースを再生して初めて表面化する、とも書いています。

4. トークン数と料金#

単価が同じでも請求が変わることがあります。Anthropicの移行ガイドは、Claude Opus 4.7が新しいトークナイザを導入し、テキスト処理時のトークン数が4.7より前のモデルと比べておよそ1倍から1.35倍(内容により最大約35%増)になりうることを明記しています。トークンカウントのエンドポイントも異なる数値を返すため、クライアント側でトークン数を見積もっているコードや文字数との固定比を仮定しているコードは再テストが必要です。

思考トークンの扱いも効いてきます。同ガイドは、思考トークンは思考テキストが返らない場合でも出力トークンとして課金されるため、Opus 4.8で思考なしに動いていたワークロードはOpus 5でリクエストあたりの出力トークンが増えうる、と説明しています。max_tokensは思考とレスポンステキストを合わせた総出力への上限のままなので、ここも見直しが要ります。逆に、Opus 5ではキャッシュ可能な最小プロンプト長が1,024トークンから512トークンに下がった、という有利な変化もあります。

Foundryの移行ドキュメントも、推論トークン・キャッシュされた入力・構造化出力のオーバーヘッドによって単価の経済性が2倍以上動きうると指摘し、定価だけでなく過去のトラフィックに基づいて月額を試算するよう勧めています。

5. 安全フィルタと拒否の挙動#

安全側の挙動が変わると、これまで通っていた正当な用途が弾かれることがあります。Anthropicの移行ガイドは、Opus 4.7でリアルタイムのサイバーセキュリティ関連のセーフガードが追加され、禁止または高リスクの話題に関わるリクエストが拒否につながる場合があると記載しています。ペネトレーションテストや脆弱性調査、レッドチーミングといった正当なセキュリティ業務については、制限の緩和を申請する仕組み(Cyber Verification Program)が案内されています。

実装側では、拒否を例外ではなく想定内の応答として扱う必要があります。同ガイドはstop_reason: "refusal"を扱うこと、サーバー側フォールバック(ベータ)のfallbacks: "default"で拒否されたリクエストを自動再実行できることを挙げています。

6. 機能の欠落とキャパシティ#

新しいモデルのほうが機能が少ない、という状況は起こります。Anthropicの移行ガイドは、Opus 5がOpus 4.7と同じ機能セットをサポートするとしつつ、web fetchツールが利用できないこと、Priority Tierがサポートされないことを例外として明記しています。Foundryのドキュメントも、選んだモデルが自分のリージョンやSKUで使えないことに計画の途中で気づくケースをAssessフェーズの典型的な失敗として挙げ、移行元と移行先を並行して動かせることを確認するよう求めています。並行稼働できなければロールバック経路がありません。レート制限やクォータも旧モデルの実績がそのまま通るとは限らないので、切り替え前に確認してください。

段階切り替えとロールバック設計#

検証を通ったら展開ですが、一度に全部を切り替える必要はありません。

露出のさせ方#

段階の付け方は3種類あります。シャドー実行(ミラー)は、本番の入力を新モデルにも流し、結果はユーザーに返さずログに残して旧モデルの出力と比較します。Foundryのドキュメントは、規制のあるフローでは実顧客のトラフィックに新モデルを露出できないことがあり、その等価物として本番の入力に対して新モデルをオフラインで動かし出力を比較する方法を挙げています。品質の差分を安全に取れる代わりに、推論コストは二重にかかります。

カナリアは、一部のトラフィックだけを新モデルに向けます。内部ユーザーや優先度の低いバッチなど、壊れても被害が限定的な集団から始めます。重み付けのトラフィック分割は、その割合を数字で管理する形です。

Foundryのドキュメントは、2つのデプロイ間の重み付けルーティングは自分のゲートウェイやアプリケーション層で実装するものだと明記しています。同じ文脈で、ロールバック経路(rollback corridor)は旧デプロイを一定期間ウォームなまま残す意図的な選択であり、組み込み型のチームでは30日程度を望むことが多い、とも書かれています。

切り替え基準を先に決める#

判断基準は、結果を見てから決めると必ず甘くなります。段階を上げる前に数値を固定します。

ロールバックは「戻せる」だけでなく「戻す条件」も決めておくのが要点です。先に書いておけば、ダッシュボードを見ながら議論せずに済みます。

移行後の監視と後片付け#

切り替えた直後で終わりではありません。

何を見るか#

Foundryのドキュメントは、Roll outフェーズでよく壊れる点として、オフライン評価が見逃した品質の回帰が本番負荷の下で現れることを挙げています。トラフィックを移したあとは本番トラフィックの一部をサンプリングして継続的に評価し、品質が落ちたらアラートを出す構成が勧められています。現実的に置きたい観測点は次のあたりです。

• 失敗率: APIエラー、スキーマ検証の失敗、タイムアウト、拒否(refusal)を分けて数える
• コスト: 1リクエストあたりの入出力トークンと金額を、移行前の実測値と並べる
• レイテンシ: p50/p95、最初のトークンまでの時間を移行前と比較する
• 品質: サンプリングした本番出力を継続評価する。可能なら旧モデルとの対比較
• ユーザー影響: 再生成の回数、会話の離脱、サポート問い合わせ

数字だけでなく、移行後しばらくはエラーと悪い出力の実物を読む時間を確保してください。分布では見えない壊れ方は実物で見つかります。

旧モデルの後片付け#

Foundryのドキュメントは、Retireフェーズを単なる清掃ではなくガバナンスとして扱うよう書いています。旧デプロイを落としてキャパシティを解放し、評価成果物を保管し、顧客向けドキュメントやサポートのランブックといった下流へ変更を伝える範囲です。後片付けをスキップするとゾンビデプロイが溜まるとも指摘されており、その多くは過去の移行から残った構造的な残骸だ、という説明です。よく抜ける手順としてコミュニケーションが挙げられ、切り替え後もマーケティング資料や製品ドキュメントが古いモデル名を指したままになる例が出ています。

後片付けの時期は、ロールバック経路を閉じてよいと判断できたときです。そして、この移行で集めた本番トレースを次回のゴールデンセットに戻します。同ドキュメントも、新しい本番トレースを戻すことで次の移行が安く始められる、と書いています。

この記事に出てくるライフサイクルの用語・通知期間・パラメータ名・エラー挙動は、いずれも執筆時点(2026年9月)の各社公式ドキュメントの記載に基づきます。提供元のポリシーやモデルの仕様は更新されるため、実際の移行にあたっては必ず現行の公式ドキュメントを確認してください。特定のモデル世代について書かれた挙動差は、他のモデルや他社のモデルに一般化できるものではありません。

よくある質問#

まとめ#

モデル移行は、技術的に難しい作業というより段取りの問題です。難しく見えるのは、廃止のアナウンスが来てから棚卸しと評価セット作りと検証と展開をまとめてやろうとするからで、期限までに終わらない部分が「とりあえず差し替え」か「固定したまま放置」に化けます。逆に、廃止情報の受け口・モデルIDの外出し・凍結したゴールデンセット・カナリアとロールバックの仕組みという4つを平時に作っておけば、移行そのものは無改造の再生と数字の比較に縮みます。移行を毎回の事件ではなく定期的な作業に変えられるかどうかが、LLMアプリを長く運用できるかの分かれ目になります。