モデルデプロイとは？本番へ出す6工程と段階公開・切り戻しの判断基準を解説【2026年版】

モデルデプロイは、学習を終えた機械学習モデルを本番の業務で使える状態まで運び、問題が出たら元へ戻せるようにしておく工程です。精度が出たモデルでも、前処理のズレや切り戻し手順の不在で本番に出せないまま止まる例は珍しくありません。この記事では、学習完了から本番稼働までの6工程、再現性を固定する3項目、配置形態の3類型、シャドーとカナリアの使い分け、出してよい条件の数値化、切り戻しの単位、自動化に踏み込む順序までを実装の解像度で整理します。推論APIの内部構成やランタイムの比較は扱いません。

まとめ｜モデルデプロイの成否を決める工程の順序と切り戻しの設計

結論を先に置きます。デプロイで最初に決めるのはツールではなく、切り戻しの単位です。モデルだけを戻せばよいのか、前処理コードごと戻すのか、学習パイプラインまで巻き戻すのか。ここが曖昧なまま本番へ出すと、障害の最中に「何を戻せば直るのか」を議論する羽目になります。

次に固定するのが再現性の3項目、すなわち前処理コードの共有・依存の版・成果物に紐づくメタ情報です。学習サービングスキューの大半はこの3つの取りこぼしから生まれます。段階公開は、いきなりカナリアへ行かずシャドーを1段挟む形が扱いやすく、応答を返さないまま本番トラフィックの複製で差分だけを見られます。

自動化は後回しでかまいません。モデルが1〜2本の段階でパイプライン基盤を組むと、運用対象だけが増えて回収できないためです。モデルが5本を超えるか、担当者ごとに手順が食い違い始めた時点で型づくりへ移ってください。

モデルデプロイの定義と、学習完了から本番稼働までの6工程の全体像

用語の輪郭を先に固めます。デプロイは配備という行為そのものを指し、そのあと動き続ける仕組みはサービングと呼び分けられます。

デプロイ・サービング・リリースの用語の線引きと責任範囲の分け方

3語は入れ子の関係にあります。デプロイは「学習済みの成果物を本番の実行環境へ運び、呼び出せる状態にするまで」の工程。サービングは「呼び出しに応え続ける仕組み」で、推論APIの内部構成やスケールの設計がここに入ります。リリースは「その新しい版を利用者へ見せる」判断で、配備とは別のタイミングで行えます。

配備と公開を分けられる点が、この線引きの実利です。新しい版を本番環境へ置いておき、トラフィックはまだ流さない。この状態を作れると、切り替えの所要時間が数分から数秒へ縮みます。推論APIの構成とランタイムの選び方はモデルサービングの構成とランタイム選定で扱うため、本記事は運ぶ工程だけに絞ります。

学習完了から本番稼働までの6工程と、各工程で残す成果物の一覧

工程は6つに分かれます。評価ゲート（オフライン指標が基準を満たすか）、パッケージング（前処理と依存ごと梱包）、レジストリ登録（版を採番して保管）、承認（人が出す判断を記録）、段階公開（シャドーからカナリアへ）、切り戻し確認（戻せることを事前に実演）。

1. 評価ゲート：評価スクリプトの出力と、判定に使ったデータセットの版
2. パッケージング：モデル本体・前処理コード・依存定義を含むイメージまたは成果物一式
3. レジストリ登録：版番号、学習コードのコミットハッシュ、学習データの版
4. 承認：誰がいつ何を根拠に許可したかの記録
5. 段階公開：シャドー期間の差分レポートと、カナリア配分の変更履歴
6. 切り戻し確認：旧版へ戻す操作の実演ログ

6番目を工程に入れている点が実務上の分かれ目です。切り戻しは障害時に初めて試すものではなく、公開前に一度通しておく作業と考えてください。手順書に書いてあるだけで実演していない切り戻しは、たいてい本番で動きません。

データサイエンティストと運用側の責任境界を切る2つの接点の決め方

境界は2か所に置きます。1つ目は成果物の受け渡し規約で、保存形式・置き場所・版の付け方をあらかじめ合意しておく形。2つ目は推論の入出力仕様で、入力の型と欠損時の扱い、出力のスキーマを文書として固定します。

この2点さえ決まっていれば、学習側と配備側が別チーム、別会社であっても引き渡しは成立します。曖昧なまま進むと、配備側が本番用の前処理を書き直すことになり、次に述べるズレの温床になるでしょう。運用サイクル全体の考え方はMLOpsの仕組みと導入判断に整理があります。

本番へ出す前に固定する再現性の3項目と学習サービングスキューの防止

デプロイ後に精度が落ちる原因の多くは、モデルではなく周辺の環境差にあります。固定すべき対象は3つです。

学習サービングスキューが起きる2つの発生源と前処理コードの共有

Google Cloud のMLOps解説は、この現象の発生源を明示しています。データサイエンティストが学習済みモデルを引き渡したあと、配備を担当する側が低レイテンシ提供のために本番側で特徴量を作り直す。この作り直しが1つ目の発生源です。

2つ目は集計期間のズレです。学習時は過去30日の平均を一括で計算していたのに、推論時は直近7日分しか参照できていない、という食い違いは頻出します。防ぎ方は単純で、前処理を学習と推論で同一のコードとして共有し、パラメータだけを外から渡す構造にします。

共有できない事情がある場合は、学習用データセットから抜いた100件程度を本番の前処理へ通し、学習時の特徴量と数値が一致するかを配備前に突き合わせてください。桁が違う、欠損の埋め方が違う、といったズレはこの照合で大半が見つかります。

依存の固定範囲｜Python版・ライブラリ・CUDA版の3層の押さえ方

依存は3層で考えます。Python本体の版、ライブラリの版、そしてGPUを使う場合のCUDAとドライバの版。上2層だけ固定してGPU側を放置すると、ノードを入れ替えた瞬間に読み込みが失敗する事故が起きます。

MLflowで保存したモデルには、MLmodel という定義ファイルとあわせて python_env.yaml・requirements.txt・conda.yaml が同梱され、推論側で環境を復元できます。ただし復元できるのは上2層まで。3層目まで固定するなら、依存を焼き込んだコンテナイメージごと配ってください。

モデル成果物に紐づける5つのメタ情報と、監査での再現要求への備え

成果物に付けておく情報は5つに絞れます。学習データの版、学習コードのコミットハッシュ、評価指標の実測値、学習を実行した日時、承認者。これだけあれば「半年前のこの予測はどのモデルが出したのか」に答えられます。

金融や医療のように説明責任が求められる案件では、この5項目が契約上の要求になります。後から付け直すのは現実的ではないため、レジストリへ登録する時点で必須項目として揃えてください。学習側の記録設計を含む製品選定はMLOpsツールの選定基準にまとめています。

デプロイ形態の3類型｜イメージ同梱・レジストリ参照・端末組み込み

モデルをどこに置いて配るかで、起動時間と差し替えの手間が変わります。類型は3つです。

3類型の比較｜差し替え頻度と起動時間で分かれる配置方式の選び方

イメージ同梱はモデルファイルをコンテナイメージへ焼き込む形、レジストリ参照は起動時にオブジェクトストレージから取得する形、端末組み込みはスマートフォンや装置側へモデルを配布する形になります。

選び分けの軸は差し替え頻度です。月1回以下ならイメージ同梱で困りません。週1回以上入れ替えるなら、そのたびに再ビルドして配布するコストが効くため、レジストリ参照へ寄せてください。保存形式をフレームワーク非依存の形へ変換しておくと配置先を後から選び直せます。変換の仕組みはONNXによるモデル変換と推論で扱っています。

端末やエッジへモデルを配る場合の版管理と、回収できない前提の設計

端末組み込みだけは前提が異なります。配ったモデルを即座に引き戻せません。アプリストア経由なら審査で数日、産業装置なら現地作業まで待つことになります。

そのため端末側には、サーバから無効化できる仕組みを先に入れておきます。版番号を問い合わせる仕掛けを持たせ、問題のある版が判明したら「この版は使わず既定値へ落とす」と指示を返す。回収ではなく無効化で凌ぐ設計です。配る前の検証は厚めに取ってください。

段階公開の設計｜シャドー・カナリア・A/Bの使い分けとリリース判定

いきなり全トラフィックを新しい版へ向ける運用は、モデルに限っては割に合いません。段階を踏む手段は3つあり、目的が異なります。

シャドーデプロイで確認する3つの差分と、実施期間の決め方の基準

シャドーは、本番が受けたリクエストの複製を新しい版へも流し、その応答は利用者へ返さない方式です。Amazon SageMaker はこれをシャドーテストとして2022年11月30日に提供開始し、レイテンシとエラー率の差分をダッシュボードで比較できる形にしています。

見る差分は3つに絞れます。旧版と新版の予測がどれだけ一致するか、予測値の分布がどう変わったか、応答時間とエラー率が悪化していないか。1つ目の一致率は、下がっていること自体は問題ではありません。下がり方が想定と違う場合に調べる、という使い方をします。

期間は、業務の周期を1つ以上またぐ長さが目安です。曜日で入力が変わる業務なら最低1週間、月末に処理が集中するなら月末を含めた期間。2〜3日で切り上げると、平日しか見ずに週末の挙動を落とします。

カナリアの配分比率を上げる判断基準と、オフライン指標が外れる理由

カナリアは、新しい版へ少量のトラフィックを実際に流す段階です。5パーセントから始め、業務指標が悪化しなければ25、50、100と上げていきます。トラフィック配分をどう設定するかは基盤側の話題のためサービング基盤での版の切り替えへ譲り、ここでは上げる判断そのものを扱います。

判断に使うのはオフラインの精度指標ではなく業務指標です。理由は入力分布の差にあります。評価用データセットは過去の期間から切り出したもので、いま届くリクエストとは母集団が違う。検証データでF1が0.02改善していても、本番の直近データでは劣化する逆転が普通に起こります。

推薦ならクリック率、不正検知なら見逃しと誤検知の両方、需要予測なら発注量の誤差。この業務指標が横ばい以上であることを確認してから比率を上げてください。アプリ側を無停止で入れ替える手順はゼロダウンタイムデプロイの設定順序にまとめており、モデルの切り替えと同じ日に重ねないほうが切り分けは楽です。

A/Bテストまで踏み込む場面と、そこまで要らない場面の判断の線引き

ここは言い切ります。A/Bテストが要るのは「どちらが業務上優れているか」を統計的に主張する必要がある場面だけです。旧版に既知の不具合があって置き換える、学習データを最新化しただけ、といったケースでA/Bを組むのは過剰になります。

必要判断は3点で足ります。判定に使う業務指標が金額や件数で定義できるか、必要なサンプル数が現実的な期間で集まるか、負けたときに旧版へ戻す合意があるか。1日の対象イベントが数百件の業務では有意差が出るまでに数か月かかるため、シャドーとカナリアで止めるのが妥当です。

リリース判定ゲートと切り戻しの単位｜出してよい条件を数値で決める

「良さそうなので出します」を排除する仕掛けが判定ゲートです。条件は事前に数値で書き、判定の場では満たすか満たさないかだけを見ます。

本番へ出す前に満たす4条件と、判定条件を数値で書き下す手順の型

4条件はこう置きます。オフライン指標が現行版の実測値を下回らないこと、シャドー期間で応答時間の95パーセンタイルが現行版の1.2倍以内に収まること、切り戻し操作を実演済みであること、承認者の記録が残っていること。

数値の決め方には型があります。目標値を新しく発明せず、現行版の直近30日の実測をそのまま基準に据える。これで「現行より悪くしない」という最低限の約束が数値になります。新しい版に上振れを期待する条件をここへ混ぜると、判定が主観に戻ります。

公開後にどの指標を追い続けるかは別の設計で、しきい値の決め方まで含めてモデルモニタリングの指標としきい値設計で扱っています。ゲートは出す瞬間の判定、モニタリングは出したあとの継続監視、と役割を分けて持ってください。

切り戻しの単位の決め方｜モデルのみ・前処理込み・パイプライン込み

戻す範囲は3段階で考えます。モデルの重みだけを旧版へ戻す、前処理コードごと旧版の組み合わせへ戻す、学習パイプラインの実行結果まで巻き戻す。所要時間は順に、数秒、数分、数時間から数日と大きく開きます。

単位を決める基準は「前処理を触ったかどうか」の一点です。重みだけを差し替えた更新なら、戻すのも重みだけで済みます。前処理を1行でも変えていれば、モデルと前処理はセットで戻さないと組み合わせが壊れる。この判定を機械的に行うため、登録する版に前処理コードのコミットハッシュを含めてください。

モデルレジストリでの版の指し方｜ステージからエイリアスへの移行

配備先の指し方にも変化がありました。MLflow ではモデルステージ（Staging・Production・Archived）が 2.9.0 で非推奨となり、後継としてエイリアスとタグが導入されています。最新の v3.15.1（2026年8月3日公開）のドキュメントはステージの記述が消え、champion のようなエイリアスで配備対象を指す前提へ置き換わりました。

固定ステージをやめた効果は、環境が3つ以上ある現場で出ます。検証・ステージング・本番に加えて社内デモ環境がある構成では、4つの固定ステージでは足りません。エイリアスなら環境ごとに名前を付けられ、切り替えは付け替えだけで済みます。切り戻しも同じ操作の逆向きで表現できるため、手順が1つに揃うわけです。

自動化の範囲と手動で残す承認工程｜MLOpsレベルで見る投資の順序

デプロイの自動化は、どこまでやるかを段階で捉えると投資の順序を間違えにくくなります。

MLOpsレベル0から2で自動化される範囲と、先に手を付ける工程

Google Cloud はMLOpsの成熟度を3段階で定義しています。レベル0はデータ分析から学習・検証まで全工程が手動。レベル1はMLパイプラインを自動化し、トリガーに基づく継続的な再学習を成立させる段階。レベル2はCI/CDを整え、パイプラインの実装そのものを継続的に本番へ配信する段階です。

先に手を付けるのは学習の自動化ではなく配備の再現性です。レベル1に相当する再学習の自動化を入れても、出す工程が手作業のままなら、再学習が回るほど手作業が増えるだけ。パッケージングと切り戻しを固めてから、その上流を自動化してください。

人の承認を残す2工程と、自動で流してよい工程の切り分け方の基準

自動化してよいのは、判断を伴わない工程です。テスト実行、イメージのビルド、レジストリへの登録、シャドー環境への配備、差分レポートの生成。ここは人が介在しても品質が上がりません。

手で残すのは2つ。1つはカナリアの比率を上げる判断で、業務指標の解釈が要るため自動判定に置き換えにくい領域です。もう1つは本番トラフィックを100パーセント切り替える最終承認。この2点まで自動化すると、深夜に誰も気づかないまま劣化した版が全量へ広がります。判断の記録を残す意味でも、人の操作として残してください。

再学習の自動化まで踏み込む条件と、手動の再学習で足りる場面の目安

再学習の自動化に投資が見合うのは、更新頻度が月1回を超える場合です。四半期に1度しか学習し直さないモデルなら、パイプラインを組む工数より手で回すほうが安く済みます。

もう1つの条件が、再学習の引き金を数値で定義できるかどうか。「入力分布の乖離が基準を超えたら」「直近30日の誤差が基準を超えたら」と書けるなら自動化できます。「なんとなく精度が落ちた気がしたら」の段階で組むと、引き金の調整に時間を取られ続けるでしょう。LLMを組み込んだ系では追う対象がトレースと評価・コストへ移るため、勘所はLLMOpsでの評価とコスト管理の側で整理しています。

採用判断｜デプロイ基盤を作らずに手動で回してよい場面の下限条件

ここも判断を言い切ります。多くの現場で、専用のデプロイ基盤は要りません。

手動デプロイのままでよい3条件と、基盤づくりへ移る合図の見極め

手順書と手作業のままで足りるのは、次の3条件が揃う場合です。本番で動かすモデルが2本以下、更新が四半期に1回程度、そして推論結果の遅延が業務上許容される。

移る合図も3つあります。モデルの本数が5本を超えたとき、担当者ごとに配備手順が食い違い始めたとき、切り戻しに30分以上かかった障害が起きたとき。どれか1つでも当てはまったら、まずパッケージングと切り戻しの2工程だけを型にしてください。全工程を一度に自動化しようとすると、たいてい途中で止まります。

失敗パターン｜モデル1本の段階でパイプライン基盤を組む判断の危うさ

典型的な失敗は、PoCで作ったモデル1本を本番へ出すタイミングで、将来を見越したMLパイプライン基盤を先に組んでしまうケースです。オーケストレーション、レジストリ、監視、再学習トリガーまで揃えると、運用対象が一気に4〜5系統へ増えます。

結果として起きるのは、モデルの改善に手が回らなくなる事態です。基盤の版上げと障害対応で工数が消え、予測精度は初版のまま数か月が過ぎる。順序が逆で、まず単一コンテナの推論APIとして出し、切り戻しを実演しておく。本数が増えてから型を作るほうが、投資の回収は早まります。

デプロイ工程の型づくりに投じる初期工数と、回収できる規模の目安

型づくりの初期工数は、パッケージングの標準化とレジストリ導入、切り戻し手順の整備までで、既存のCI環境がある前提なら2〜4人週が目安です。回収できるかは年間の配備回数で見てください。年12回を超えるなら、1回あたりの手作業と事故対応の削減で吸収できます。

逆に年数回の配備しかない規模では、型づくりより手順書の精度を上げるほうが効きます。判断に迷う場合は、直近1年で何回モデルを差し替えたか、そのうち何回切り戻したかを数えるところから始めてください。機械学習モデル開発では、モデルの構築から本番配備と運用設計までを含めた相談を受け付けています。配備と切り戻しの工程まで見積の範囲に入っているかを、委託先を選ぶ判断材料にしてください。

よくある質問

モデルデプロイの設計でよく挙がる質問に、工程の判断という観点から答えます。

モデルデプロイとモデルサービングは何が違いますか？

デプロイは学習済みの成果物を本番の実行環境へ運び、呼び出せる状態にするまでの工程を指します。サービングは、その後リクエストへ応え続ける仕組みです。時間軸で分けると理解しやすく、デプロイは版を出す瞬間まで、サービングは出したあとの定常運用にあたります。担当も分かれ、デプロイ側はパッケージングと切り戻しを、サービング側はレイテンシとスケールを見ます。

デプロイしたモデルはどのくらいの頻度で更新すべきですか？

入力データの変化の速さで決まります。ユーザーの行動を予測する系は月1回程度、設備の異常検知のように物理現象が相手なら四半期に1回でも成立します。頻度をカレンダーで固定するより、入力分布の乖離や業務指標の劣化を引き金にするほうが無駄が出ません。引き金を数値で定義できない段階では、まず月次で様子を見る運用から始めてください。

シャドーデプロイとカナリアリリースはどちらを先に行いますか？

シャドーが先です。シャドーは新しい版の応答を利用者へ返さないため、失敗しても業務への影響が出ません。ここでレイテンシとエラー率、予測分布の差分を確認し、問題がなければカナリアで実トラフィックを5パーセント流します。両方やる余裕がない場合、影響範囲の大きい業務ならシャドーを優先し、社内向けで戻すのが容易ならカナリアだけでも回ります。

モデルの旧版はどのくらいの期間残しておくべきですか？

成果物と稼働インスタンスを分けて考えます。稼働中の旧版インスタンスは新版の業務指標が安定するまでが目安で、日次で判断できる業務なら1週間程度。成果物のほうは、その版が出した予測に問い合わせが来たときに再現できる必要があるため、業務上の保存義務に合わせます。学習データの版と学習コードのコミットハッシュも同じ場所へ紐づけて保管してください。

クラウドのマネージド機能だけでモデルデプロイは完結しますか？

配備の操作自体は完結しますが、判定と切り戻しの設計は自前で決める必要があります。マネージドサービスが提供するのはエンドポイントの作成、トラフィック配分、シャドーテストといった機能であり、「どの数値を満たしたら出してよいか」「何を戻せば直るか」は業務ごとに違うためです。判定ゲートの条件を書き下す作業だけは省けません。

関連記事

• モデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準：配備したあと動かし続ける基盤の設計
• モデルモニタリングとは？ドリフト検知の指標としきい値設計：公開後に追う指標としきい値の決め方
• MLOpsとは？機械学習の運用を支える仕組みと導入判断：運用サイクル全体と導入の判断軸
• MLOpsツール比較｜実験管理・パイプライン・監視の主要スタックと選定基準：レジストリを含む製品の選び方
• LLMOpsとは？MLOpsとの違いとトレース・評価・コスト管理：LLMを組み込んだ系での運用の違い