MLOps のアーキテクチャ図：学習データから監視されたモデルまで

ノートブックの中のモデルは、システムではありません。Hidden Technical Debt in Machine Learning Systems（Sculley ほか、NeurIPS 2015）の有名な図は、それを箱で示しています。現実の ML システムのうち、ML のコードはごく一部にすぎません。残りはデータ収集、特徴量の抽出、推論の提供、監視、そしてそれらをつなぐ配管であり、本番の問題はそこから生まれます。

MLOps のアーキテクチャ図は、その残りの部分を描きます。この記事では不正検知のスコアリングモデルを例に図を作り、本番のモデルが必ず持つ 2 つのループを説明し、モデルがおかしな振る舞いをしたときに出てくる疑問に図が答えられるよう、何をラベルに書くべきかを挙げます。

2 つのループと 1 つのトリガー

本番のモデルには、学習ループと推論ループがあります。

• 学習ループ。 データを集めて特徴量に変換し、候補モデルの学習に使い、現行モデルと比較して登録します。
• 推論ループ。 リクエストが届くと特徴量を参照し、モデルがスコアを付け、予測を記録します。
• トリガー が 2 つをつなぎます。推論ループの監視、スケジュール、新しいデータのいずれかが学習ループを再び動かします。

Google の MLOps ガイドは 3 つの成熟度レベルを示しています。レベル 0 は手動のプロセス、レベル 1 は継続的な学習のために学習パイプラインを自動化した状態、レベル 2 はパイプライン自体に CI/CD を加えた状態です。計画しているレベルではなく、いまのレベルを描き、手作業の手順には印を付けましょう。

学習と推論のずれ

MLOps の図が最もよく防ぐバグは、学習と推論のずれ（training-serving skew）です。ある特徴量を、学習の SQL ではある方法で、推論のコードでは別の方法で計算してしまうことです。モデルはオフラインでは良く見えるのに本番では悪くなり、誰も理由を説明できません。先ほどの Google のガイドは、特徴量の定義を 1 つにするため、実験、継続的な学習、オンライン推論の唯一の情報源として特徴量ストアを使うことを勧めています。

もう 1 つの典型的なバグは、時間をまたいだリークです。ある決済の学習データの行には、現在の値ではなく、その決済が行われた時点の特徴量の値を使わなければなりません。この時点（point-in-time）の要件を、特徴量ストアから学習パイプラインへのエッジに書いておきましょう。

例：カード決済の不正検知スコアリング

決済 API は、カード決済を承認する前にモデルへ不正スコアを問い合わせます。設計は次のとおりです。

1. イベント。 決済 API はすべての決済を Kafka に発行します。ストリーミングのジョブが、直近 1 時間のカードごとの決済件数のような移動集計の特徴量をオンラインストアに保ちます。同じイベントはデータウェアハウスにも入ります。
2. ラベル。 決済が不正だったかどうかは、数週間から数か月後に届くチャージバックで分かります。チャージバックはデータウェアハウスに読み込まれ、元の決済と結合されます。
3. 特徴量。 特徴量ストアは各特徴量を一度だけ定義し、データウェアハウスからオフラインの値を計算し、最新の値をオンラインストアに書き出します。
4. 学習。 オーケストレーションされたパイプラインが時点を揃えた学習データを作り、データを検証し、候補モデルを学習させ、同じ評価データで本番のモデルと比較し、メトリクスとともに登録します。
5. リリース。 承認されたバージョンをスコアリングのエンドポイントにデプロイします。最初はシャドーモードで、判断には影響を与えずに本番トラフィックのコピーを採点させ、次に一部のトラフィック、最後にすべてのトラフィックに広げます。
6. 監視。 すべてのスコアを特徴量とともに記録します。監視では、入力とスコアの分布を学習データと比較し、ラベルが届くにつれて適合率と再現率を計算します。ドリフトや品質のアラートが再学習を起こします。

図の読み方は次のとおりです。

• 上段は学習。 チャージバックのラベルとイベントの履歴がデータウェアハウスで合流します。特徴量ストアがパイプライン用の学習データを作り、パイプラインが候補をモデルレジストリに登録します。
• 下段は推論。 決済 API はイベントを Kafka に発行し、スコアリングのエンドポイントを同期的に呼び出します。エンドポイントはオンラインストアから特徴量を読み、すべてのスコアを予測ログに書き込みます。
• レジストリからのエッジ は、モデルが本番に入る唯一の道です。ノートブックからコピーしたファイルではなく、常に承認済みのバージョンが使われます。
• 右側は戻りのループ。 監視は予測と遅れて届くラベルを読みます。ドリフトや品質の低下があるとアラートが上がり、学習パイプラインが動き出します。

ラベルに書くこと

• 学習データへのエッジには 時点に関するルール を書きます。
• エンドポイントとレジストリには モデルのバージョンとステージ を書きます。
• 特徴量の参照とスコアリングには レイテンシーの予算 を書きます。決済はその結果を待っているからです。
• ラベルの遅れ。 ラベルが届くまで数週間かかるなら、それを書きましょう。品質をどれだけ早く測れるかはそれで決まります。
• 再学習のトリガー。 スケジュール、ドリフトのしきい値、データ量です。
• 担当者。 データ、特徴量、モデル、エンドポイントは、別々のチームが担当していることがよくあります。

よくある間違い

• 「ML モデル」という 1 つの箱。 インシデントが始まる場所である特徴量ストア、レジストリ、監視ループが隠れてしまいます。
• フィードバックの経路がない。 ラベルが戻ってこなければ、モデルがいつ悪くなったのか誰にも分かりません。
• 本番の経路にノートブックがある。 モデルが推論の提供にたどり着く道は、パイプラインとレジストリだけにすべきです。
• 1 つの特徴量に 2 つの実装がある。 「同じ」値を別々に計算する学習の SQL と推論のコードは、ずれの原因になります。
• ロールバックできない。 前のバージョンをレジストリに残し、エンドポイントがどう切り戻すかを図に描きましょう。
• インフラだけを監視している。 モデルが間違っていても、レイテンシーやエラー率は完璧なことがあります。入力、スコア、結果も監視しましょう。

推論を提供する側は、ごく普通の分散システムの仕事です。Kafka の部分はイベント駆動アーキテクチャの図で、検索を組み合わせた言語モデルのインデックス作成と推論の提供は RAG のアーキテクチャ図で扱っています。

Archboard で作る

1. Google または GitHub でサインインし、図を作成します。
2. ML パックから 特徴量ストア、レジストリ用の モデル、スコアリング用の エンドポイント を追加します。
3. データパックから Kafka、データウェアハウス、オンラインストア用の Redis、予測ログ用の トピック を追加します。
4. DevOps パックから、学習用の パイプライン、モデル監視用の メトリクス のノード、再学習のトリガー用の アラート を追加します。
5. C4 モデルパックから、決済 API 用の コンテナ と、カードネットワークのチャージバック用の 外部システム を追加します。
6. それらをつなぎ、各エッジに運ぶデータを書き、遅れて届くラベルと再学習のトリガーは破線にします。リリースの手順を書いた基本パックの Markdown ブロックを追加します。

この例で使うダイアグラムノードは 13 個で、Free プランの範囲に収まります。MCP で接続した AI エージェントを使えば、パイプラインを説明してノードの配置を任せ、その後でラベルを整えることもできます。

よくある質問

特徴量ストアは必要ですか？ 初日から必要なわけではありません。必要なのは、学習と推論の両方が使う、特徴量ごとに 1 つの定義です。複数のモデルが特徴量を共有するようになったときや、オンラインで新しい特徴量が必要になったとき、それを実現する一般的な方法が特徴量ストアです。

モデルレジストリとアーティファクトストアの違いは何ですか？ アーティファクトストアはファイルを保管します。レジストリはそれに加えて、バージョン、メトリクス、来歴、承認状態を持つので、デプロイの手順がパスではなく承認済みのバージョンを指定できます。

モデルはどのくらいの頻度で再学習すべきですか？ データが意味のある形で変わる頻度に合わせます。まずはスケジュールから始め、監視が整ったらドリフトと品質のトリガーを加え、再学習を実行するたびにその理由を記録しましょう。

ラベルが遅れて届く場合、モデルをどう監視しますか？ 入力の分布、スコアの分布、フラグが立った決済の割合など、いま見えるものを監視し、ラベルが届いた時点で適合率と再現率を計算します。両方の経路を図に描きましょう。

学習と推論はインフラを共有すべきですか？ 特徴量の定義とレジストリは共有できますが、負荷の性質は異なります。特徴量ストアとレジストリで合流する、別々の経路として描きましょう。

無料で始める — 1 シート、クレジットカード不要。