6月24日、Confluentが「How to Eliminate Training-Serving Skew in MLOps (2026)」と題した記事を公開した。MLOpsにおいてモデルの学習時と推論時でフィーチャーの値がずれる「トレーニング・サービングスキュー」を、統一ストリーミングアーキテクチャで根本から解消する方法について詳しく紹介されている。DoorDashの実例では二重パイプライン構成によるフィーチャー値のミスマッチが最大35.7%に達していたと報告されており、Netflixの試算ではアーキテクチャ刷新によって同等のデータパリティを46分の1のコストで実現できるという。MLの精度問題がインフラ構造に起因していた、という示唆に富む事例だ。
トレーニング・サービングスキューとは何か
機械学習モデルを本番環境で運用する際、学習に使ったフィーチャー（特徴量）と実際の推論時に渡されるフィーチャーの値が異なってしまう現象をトレーニング・サービングスキューと呼ぶ。
この問題の根本原因は、いわゆるラムダアーキテクチャにある。ラムダアーキテクチャとは、バッチ処理（例：Apache Spark）とストリーム処理を別々のパイプラインで管理する設計だ。学習用データはバッチパイプラインで生成し、推論用フィーチャーはストリーミングパイプラインで計算するため、両者のロジックやコードベースが乖離していく。
これは「ひそかに精度を蝕む」問題だ。DoorDashのエンジニアが調査したところ、この二重パイプライン構成によるフィーチャー値のミスマッチは**最大35.7%**に達していたと報告されている。
コストも二重になる。Netflixが試算した例が象徴的だ。Kafkaのリテンションを30日に延ばして履歴データをバックフィルしようとすると年間約9,300万ドルのコストがかかる。一方、同じ変換ロジックをIcebergデータレイクからカッパアーキテクチャでリプレイすれば年間わずか200万ドルで済む。同等のデータパリティを、46分の1のコストで実現できる。
カッパアーキテクチャが解決策になる理由
カッパアーキテクチャ（Kappa Architecture）は、バッチレイヤーを廃止し、全データをイベントストリームとして統一的に扱う設計思想だ。
核心となる考え方は「フィーチャー・アズ・コード」である。Apache Flinkでフィーチャー変換ロジックを一度だけ定義すれば、そのロジックが学習用のバッチ処理にも、推論用のリアルタイム処理にも同一のコードで使われる。「過去30日間のユーザークリック数を集計する」処理が、学習データ生成時も本番推論時も全く同じロジックで動く——これがスキューを構造的に排除する。
リプレイ（過去データの再処理）も2モードで対応できる。
- 短期・低レイテンシ： KafkaのトピックオフセットをリワインドしてKafkaのInfinite Storage（コールドデータをオブジェクトストレージに自動ティアリング）から再生する
- 大規模・長期： Apache IcebergまたはDelta Lakeに蓄積されたカラムナー形式のデータから直接リプレイする（スキャンコスト面で有利）
具体的なリファレンスアーキテクチャ
データフローは以下の7ステップで整理される。
- ユーザーのアプリ操作が生のインタラクションイベントとして、パーティション分割されたKafkaトピックにパブリッシュされる
- Flinkがイベントを消費し、イベントタイム（サーバー到着時刻ではなく、イベント発生時刻）でウォーターマークを付与しながら処理する
- Flinkがスライディングウィンドウ集計を実行し、フィーチャーベクトルを更新する
- 計算結果をデュアルライト（オフライン経路とオンライン経路の2経路に同時書き込み）する
- オフライン経路： Confluent Tableflow（KafkaトピックのデータをApache Icebergテーブルへ自動マテリアライズするConfluentのマネージド機能）を通じてIcebergまたはDelta Lakeテーブルに書き込む（学習用）
- オンライン経路： Redisクラスターのキャッシュをリアルタイムに更新（推論用）
- 推論ゲートウェイがRedisからシングルデジットミリ秒でフィーチャーを取得してスコアリングを実行する
デュアルライトは2経路への同時書き込みによってリアルタイムと履歴データを同期し続ける設計だが、オンライン経路（Redis）とオフライン経路（Iceberg）の間で書き込みタイミングや障害によって一時的な不整合が生じうる点には注意が必要だ。Flinkのexactly-once処理セマンティクス（後述）がこのリスクを最小化するが、2フェーズコミットのスコープはKafka-Flink間に限られるため、Redisへの書き込みを含む完全なトランザクション保証が必要なユースケースでは、アーキテクチャ上の追加検討が求められる。
ポイントは、FlinkがSQL関数（ML_PREDICTでリモートモデル呼び出し、AI_COMPLETEでLLM呼び出し）を使ったストリーム内ML推論もネイティブサポートしている点だ。フィーチャー計算と推論を同一Flinkジョブ内で実行でき、余分なネットワークホップを排除できる。
Confluentによれば、Tableflowを使ったブロンズ/シルバーパイプラインの構築は、自前で組む場合と比べてエンジニアリング工数とコンピュートコストを30〜50%削減できるという。
本番グレードで必要な3つの分散システム課題
イベントタイム処理（学習データリーケージの防止）
処理時刻ではなくイベント発生時刻でウィンドウを切ることが必須だ。ネットワーク遅延でイベントが到着した場合、処理時刻基準だと間違ったウィンドウに振り分けられ、未来データの漏洩（リーケージ）が起きる。
Flinkはウォーターマークによってこれを解決する。ウォーターマークは「ある時刻までのイベントは全て観測済み」という宣言であり、決定論的なリプレイを可能にする。
スライディングウィンドウのステート管理（メモリ枯渇の防止）
スライディングウィンドウ集計は「書き込み増幅」を引き起こす。1つのイベントが複数の重複ウィンドウに属するため、膨大な中間ステートが必要になる。Flinkはこれをディスクへのスピルと増分チェックポイントで対処する。
Exactly-Once処理（フィーチャー正確性の保証）
クラッシュからの再起動時に二重カウントが発生すると、「過去1時間のトランザクション頻度」のようなフィーチャーが狂う。KafkaとFlinkは分散2フェーズコミットプロトコルで連携し、全オペレーターのチェックポイントが成功した場合のみKafkaシンクがトランザクションをコミットする仕組みで、これを防止する。
ツールチェーン全体像
Confluentのプラットフォームが担うのは上流パイプラインだ（Kafka取り込み、Flink処理、スキーマレジストリによるガバナンス、Tableflowによるオフラインマテリアライズ）。オンラインフィーチャーストアとモデルサービングゲートウェイは含まれない。Redisや DynamoDB、Aerospike等のKVストア、SageMaker・Vertex AI・KServe等の推論エンドポイントと組み合わせて使う構成だ。
デプロイ形態は4つをサポートしている。Confluent Cloud（フルマネージド）、Confluent Platform（オンプレミス）、WarpStream（BYOC：ユーザーの自社クラウド環境にエージェントを展開するKafka互換サービス）、およびそのハイブリッド構成だ。これら全環境で、Confluentが開発した高性能ストレージエンジンであるKoraエンジンと同一のFlinkランタイムが動作するため、環境をまたいでもフィーチャーロジックの一貫性が保たれる。
スキューを構造的に排除するための条件は明確だ。単一の変換ロジック（Flink）、イベントタイム処理、exactly-once保証、そしてIcebergを介したオフライン/オンライン経路の統一——この4点が揃って初めて、二重パイプラインの置き換えが成立する。
詳細はHow to Eliminate Training-Serving Skew in MLOps (2026)を参照していただきたい。
