1 前処理パイプラインの概要
前処理パイプラインは、データを機械学習モデルや統計解析の入力として扱う以前に、収集から整形、品質確認、変換、整備までを段階的に実行する処理群の総称である。単発の前処理スクリプトではなく、手順と処理を連結した一連の流れとして設計・運用される点に特徴がある。
この枠組みの中心目的は、欠陥やばらつきを抑え、再現性の高いデータ状態を確保することにある。たとえば、欠損の存在や単位の混在、文字表現の揺れ、カテゴリの不一致といった問題は、学習結果の不安定さや評価の歪みの原因になり得る。そこで、入力を一定の基準に沿って整え、以後の工程が前提条件を満たした入力を受け取れるようにする。
1.1 目的と期待される効果
前処理の目的は、解析の土台となるデータを「仕様どおりにする」こと、そして「手戻りを減らす」ことの二方面に整理できる。前者は欠損や型不整合を吸収し、後者は手順の標準化により人手依存の変動を抑えることを指す。
期待される効果としては、(1) 学習や推定の再現性向上、(2) 評価指標の解釈可能性の増大、(3) 障害対応を含む運用の安定化、(4) 品質改善の取り組みが継続できる仕組み化、が挙げられる。結果として、モデル改善の議論が「データ由来の失敗」と切り分けやすくなる。
1.2 基本構成要素
前処理パイプラインは、入力取得、前処理ステップ、出力データと利用先、という骨格で捉えられる。加えて、実運用ではログやメタデータ管理、失敗時の方針なども構成要素として扱う。
全体像を分解すると、データを取り込み、検査し、変換し、保存し、その後段の工程が必要とする形に整えるまでが範囲に入る。どの段階でも「何が」「いつ」「どの設定で」行われたかが追えることが望ましい。
1.2.1 入力データ取得
入力取得では、データの存在確認、取得範囲の特定、参照元の信頼性評価が行われる。たとえば、ファイルの場合は到達時刻やファイル名規約の確認、ストリーミングの場合はイベント時刻の扱いを決める。
また、取り込むデータのスキーマや型の情報を把握し、以後の処理が前提とする形式に合わせるための下準備も行う。入力のバージョンが混在する場合は、統合前に同一性の判定を設けることが重要になる。
1.2.2 前処理ステップ
前処理ステップは、品質の検査と改善、表現の統一、特徴量や教師データの整備、分割の実行などから構成される。ステップごとに目的と入出力仕様を定義し、依存関係が明確になるように配置する。
実装上は、列単位の処理、行単位の処理、データ集合全体を用いる処理（分布推定やスケーリングなど）を区別して扱うと破綻を防ぎやすい。特に集合全体を参照する工程では、学習用と評価用を分けるタイミングを誤ると、評価の信頼性が損なわれる。
1.2.3 出力データと利用先
出力は、学習用入力、検証用入力、テスト用入力、場合によっては中間成果物や監査用の集計に分かれる。利用先は、学習ジョブ、ハイパーパラメータ探索、統計モデルの推定、あるいは可視化やレポーティングなどである。
出力形式は、保存仕様（ファイル形式、パーティション、圧縮）、データ辞書（列の意味、単位）、再利用性（次のパイプラインで同じ変換を再適用できるか）を含めて設計する。これにより、後工程が前処理の前提を理解しないままでも使える状態を目指す。
1.3 関連する概念との違い
前処理パイプラインは、データ前処理そのものを拡張した概念として位置づけられる。単なる前処理はある工程の実行に留まりがちであるのに対し、パイプラインは「連結された手順」と「運用を含む管理」を強く意識する。
また、ETL（抽出・変換・格納）とも近いが、前処理パイプラインは最終目的が解析・学習の入力品質に直結する点で焦点が異なる。さらに、データガバナンスとも関連するが、前処理パイプラインは実行可能なデータ変換と検査の具体的手順に比重がある。
2 前処理の設計方針
前処理設計は、対象データの実態と、最終的に必要な入力仕様の両方を踏まえて行う。方針を定めずに個別の課題を順に潰すと、後で整合性の崩れが顕在化し、修正コストが増える。
設計では、品質要件、形式要件、再現性、効率性といった観点を同時に満たす必要がある。特に分割や変換の順序は、モデルの評価を左右するため最初期から意思決定しておく。
2.1 データ要件の定義
要件定義では、どの程度の欠損が許容されるか、分布の偏りがどこまで許されるか、整合性がどう検証されるかを明文化する。ここが曖昧だと、前処理の判断が属人的になり、再現性が崩れやすい。
また、型やスキーマだけでなく、単位や表現形式といった意味論も要件として扱うことで、後段の工程が解釈に迷う事態を減らせる。
2.1.1 品質基準（欠損率、分布、整合性）
品質基準は、欠損の頻度、外れ値の許容範囲、値域の妥当性、カテゴリの網羅性などを数値化したものとして定める。欠損率が高い列は学習に不利になりやすいが、一律に削除するのではなく、補完の可能性や欠損の生成機構を考慮する。
分布の基準には、中央値や分散だけでなく、歪度や裾の厚み、離散値の出現比率の安定性などが関わる。整合性は、参照キーの一致、日付の順序、相互に矛盾する項目の検出などにより検査される。
2.1.2 形式要件（型、スキーマ、単位）
形式要件には、各列のデータ型、必須列の有無、列の並び、スキーマの更新方針が含まれる。たとえば、数値列が文字列として格納されていると、変換の失敗が連鎖するため、初期段階で型判定と変換規則を定める。
単位の要件は見落とされやすいが重要である。温度が摂氏と華氏で混在している、金額が税抜・税込で混在しているといったケースでは、スケーリングの前に統一が必要になる。
2.2 再現性とバージョン管理
再現性は、同じ入力に対して同じ出力を得る性質として定義できる。前処理では、ランダム要素、外部統計量、時間依存の要因が入りやすいため、設計段階で抑制策を組み込む。
加えて、バージョニングにより、過去の実験がどの前処理版に依存していたかを後から追跡できるようにすることが重要になる。
2.2.1 処理手順の固定化
処理手順の固定化には、変換規則の順序、パラメータの決定方法、乱数の初期化、サンプリング方式の指定が含まれる。たとえば、欠損補完で推定を行う場合、その推定対象の範囲やモデルの学習タイミングを固定する。
また、ライブラリの更新による挙動差を抑えるため、環境情報の固定（依存バージョン、実行環境の指定）を組み合わせると安定性が高まる。
2.2.2 入力・コード・設定の履歴管理
履歴管理では、入力データの版、前処理コードの版、設定ファイルの版を紐づけて記録する。生成物の保存時にメタデータとして残し、監査やデバッグに利用できるようにする。
さらに、複数の実験が同一の入力でも異なる前処理設定で実行される場合に備え、差分が追える形式で管理することが望ましい。これにより原因究明が容易になる。
2.3 計算効率とスケーラビリティ
前処理はデータ量に比例して計算コストが増えるため、設計時に効率性の見積もりが必要である。特に特徴量生成や分布推定は、全量走査を伴うことがある。
また、データが継続的に到着する場合には、パイプラインを伸縮できる形にしなければならない。そのため、ストリーミングとバッチの方針を使い分ける。
2.3.1 ストリーミング処理の考え方
ストリーミング処理では、到着したデータを順次処理し、遅延や欠損を考慮しながら中間状態を更新する。窓（ウィンドウ）を設けることで、計算量を制御しつつ、一定期間の統計を用いた変換が可能になる。
一方で、学習用と評価用の境界や、将来データを参照してしまう危険に注意が必要である。状態更新の規則を明確化し、参照期間を固定しておくことが重要になる。
2.3.2 バッチ処理との使い分け
バッチ処理は、所定の範囲をまとめて変換し、再現性の確保と管理の簡潔さに利点がある。全量に基づく統計推定が必要な工程では、バッチのほうが自然に設計できる。
一方、即時性が要求される用途ではストリーミングが適する。実務では、同一パイプライン内に両者を併用し、日次バッチで品質を確定し、間に挟む形で軽量な前処理を行うなどの構成が採られることがある。
3 実装パターンとステップ例
ここでは、実務で頻出する前処理ステップを、目的別に整理して例示する。実装はツールやデータ形式に依存するが、判断基準と出力仕様を明確にする点は共通である。
各ステップは単独でも成立するが、パイプラインとして連結する際には、順序関係と依存する統計量の出どころを意識して設計する必要がある。
3.1 データクリーニング
データクリーニングは、欠損、外れ、重複、矛盾といった「観測上の欠陥」を扱う工程である。ここでの改善は、後続の変換や学習に直接影響するため、検査と修正の両方を行う設計が望ましい。
また、修正によって失われる情報の扱いを明確にし、補完の前提が破られた場合に備えることが重要になる。
3.1.1 欠損値の扱い（削除・補完）
欠損の扱いは、大きく削除と補完に分かれる。削除は簡潔だが、欠損率が高い場合は学習データを大きく減らし、推定の不安定さにつながる。
補完では、列の性質に応じて代表値代入、分布に基づく推定、モデルによる予測補完などが用いられる。補完値の根拠をログに残し、補完対象の選別条件が変更されると結果が変わる点を管理する。
3.1.2 外れ値の検出と対処
外れ値は、測定誤り、入力ミス、特殊な実例など多様な原因を持つ。単に極端な値を除くと、稀ながら重要なパターンを捨てる可能性があるため、検出と理由付けを分けて考える。
対処には、クリッピング、ロバストなスケーリング、エラー値の除外、モデル側での頑健化がある。検出手法は分布に依存するため、基準を固定し、閾値の更新はバージョンとして記録する。
3.1.3 重複排除と整合チェック
重複排除は、同一レコードの重複や、同一対象に対する複数記録の重複を整理する作業である。キーの定義や、同一性判断の条件を明確にしないと誤削除が起きやすい。
整合チェックでは、関係する列間の矛盾、日付と時刻の順序、参照キーの存在確認などを行う。矛盾が見つかった場合は、修復可能か、あるいは排除すべきかをルール化する。
3.2 データ変換・正規化
変換・正規化は、入力の表現を統一し、学習アルゴリズムが扱いやすい形に整える工程である。特に型の不一致や表記ゆれは、特徴量生成以前に解消するのが望ましい。
この節では、型統一、スケーリング、表記の揺れの統合を扱う。
3.2.1 型変換と表現の統一
型変換では、数値の文字列化、論理値の表記揺れ、時刻のフォーマット違いなどを統合する。日付や時刻はタイムゾーンやフォーマットを含めて統一し、変換失敗を検出できるようにする。
表現の統一では、欠損を示す表記（空文字、特定の記号、null相当）を同一の欠損として扱うことで、後続の工程が迷わないようにする。
3.2.2 スケーリング（標準化・正規化）
スケーリングは数値特徴量の尺度を揃える作業である。標準化は分布の平均と分散に基づき、正規化は範囲やノルムに基づくなど、適用方法が異なる。
重要なのは、スケーリング用の統計量を学習データ側で推定し、それを検証やテストへ同じ変換として適用する点である。これにより評価での情報混入を回避する。
3.2.3 記法統一（文字列、カテゴリ）
文字列では、大文字小文字、前後の空白、区切り記号の差異などを正規化する。カテゴリでは、表記ゆれ（別名、略称、誤字）を統合し、未知カテゴリの扱い方も決める。
未知カテゴリを削除すると情報が失われることがあるため、特別ラベルへの割当や確率的表現などの方針を選ぶ。方針は目的タスクと評価設計に依存する。
3.3 特徴量エンジニアリング
特徴量エンジニアリングは、モデルが利用しやすい形へデータを再表現する作業である。単純な整形に留まらず、意味のある派生量の生成を含む。
ここでの設計は、再現性と検証可能性が重要になる。派生のルールが曖昧だと、後で性能の変化要因を特定しにくい。
3.3.1 生成特徴量（集計、派生）
生成特徴量では、集計（合計、平均、件数）や派生（差分、比率、経過時間）を作る。時系列では移動平均や変化率が典型で、表やログでは直近N件の要約が使われることがある。
生成の際には、計算対象期間の境界を誤らないことが重要である。未来情報に触れると不適切な利得が生じるため、参照時点を厳密に扱う。
3.3.2 エンコード（カテゴリ、順序）
カテゴリのエンコードでは、ワンホット、ターゲットエンコード、順序付けを前提とした表現などが選択される。順序の意味が妥当でないカテゴリに順序を付けると、学習が誤った関係を捉える。
順序カテゴリでは、ランキングやスコアとしての扱いを検討するが、未知値の扱いや外れ値の影響も合わせて設計する必要がある。
3.3.3 次元削減と特徴選択
次元削減や特徴選択は、学習効率や汎化性能の改善を狙う工程である。次元削減には主成分分析のような線形手法や埋め込みのような非線形手法がある。
特徴選択は、相関や重要度に基づいて特徴を絞ることで解釈性を高める場合が多い。これらの処理は学習データに基づく必要があり、推定の際に評価データを参照しない設計が必須となる。
3.4 ラベル・教師データの整備
教師データの品質は、学習の上限を規定する。ラベル整合性の検証、付与プロセスの品質管理、時間の整合といった観点が必要になる。
ラベル処理は、入力特徴量よりも「誤りの影響が大きい」ことが多く、丁寧な検査が求められる。
3.4.1 ラベル整合性の検証
ラベル整合性の検証では、ラベルの形式（型、値域）、存在率、重複の有無、対象との対応関係を確認する。たとえば、予測対象のイベントとラベルの付与時刻が矛盾しないかをチェックする。
また、ラベルのクラス分布が想定と大きく異なる場合は、データ処理の段階での取り違えを疑う。異常検知の仕組みを組み込むと検出が早まる。
3.4.2 事前ラベル付けの品質管理
事前ラベル付けでは、人手や自動付与の誤差、曖昧さ、基準のブレを管理する必要がある。注釈者間の一致度を確認したり、ガイドラインを更新することで品質を改善できる。
自動付与の場合は、弱い教師の作成過程やモデルの更新に伴うラベル変動を監視する。ラベルの版管理を行い、学習の再現性を確保する。
3.5 データ分割とサンプリング
データ分割は、学習・検証・テストの役割を分ける作業である。単に乱択で分けるだけでなく、時間依存性や層化、不均衡を考慮することが重要になる。
分割設計は、評価の妥当性に直結するため、前処理パイプラインの要である。
3.5.1 学習・検証・テスト分割
学習・検証・テスト分割では、相互に重複しないデータ集合を作る。ランダム分割では、分布の偏りが大きいとクラス比が崩れるため、層化が有効になる場合がある。
時系列データでは、未来側が学習に影響しないよう順序を保持した分割が求められる。グループ化（同一ユーザや同一デバイスの分離）も必要になることがある。
3.5.2 不均衡データへの配慮
不均衡では、少数クラスが十分に学習されず、性能評価が見かけ上よく見える場合がある。前処理では、学習データ側のサンプリング調整や、重み付けの設計が関わる。
過剰サンプリングやアンダーサンプリングを行う場合、重複が評価側に影響しないよう境界を守る。さらに、分割後に適用される手法か、分割前に適用されるべきかを切り分けて考える必要がある。
4 品質保証と運用
前処理が品質を担保するには、計測と監視、失敗時の挙動を含む運用設計が不可欠である。ここではテストと検証、監視とアラート、ログと監査、そして復旧方針を扱う。
品質保証は「間違いが起きたときに気づける」ことと、「起きた後に影響を抑えられる」ことの両立を目指す。
4.1 テストと検証（データ品質）
データ品質のテストは、スキーマ整合、値域、欠損率、重複率、分布の変化などを対象に行う。関数レベルの単体テストに加え、パイプライン全体の整合性検証が必要になる。
検証では、期待される統計量レンジを基準として異常を検知する。完全に同一の値を求めるのではなく、許容幅を持たせることで運用の柔軟性を確保する。
4.2 監視とアラート
監視は、パイプラインが「動いたか」だけではなく、「期待どおりに動いたか」を確認する仕組みである。データ量の急減や欠損率の跳ね上がりは、後段の性能劣化に直結するため早期検知が重要になる。
アラートでは、閾値を適切に設定し、誤検知の抑制と重要度の区別を行う。
4.2.1 データドリフト検知
データドリフト検知では、時間経過に伴う分布変化を監視する。前処理の入力分布が変わると、補完やエンコード、外れ値処理の挙動が変化し得るため、影響の把握が必要になる。
検知手法としては、統計距離や特定特徴の分布比較、カテゴリ頻度の変化率などが用いられる。ドリフトが見つかった場合の対応（再学習、前処理再調整、設定の見直し）まで決めておくと運用が安定する。
4.2.2 処理失敗時の通知
処理失敗時の通知は、検出から復旧までの時間を短縮するために重要である。失敗の原因（入力欠落、型変換の例外、外部依存の不通）を分類し、必要な担当者へ適切に通知する設計が望ましい。
通知には再実行の可否や影響範囲の見積もりを含めると、運用者が判断しやすくなる。自動リトライを行う場合は、無限ループを防ぐ制約も同時に整備する。
4.3 ログ・メタデータ・監査
ログとメタデータは、再現性と原因究明のための情報基盤である。処理開始時刻、対象データの識別子、適用した設定、変換結果の概要などを体系的に記録する。
監査の観点では、データの扱いが規約に沿っているか、誰がいつ変更したかを追跡できることが求められる。
4.3.1 トレーサビリティ
トレーサビリティは、出力がどの入力とどの変換に基づくかを追える性質である。中間データを保存するかどうかはコストと設計判断だが、少なくともメタ情報として依存関係を残すことが重要になる。
問題が起きた際に、特定の入力ロットや特定の設定に限定して影響範囲を調査できると、復旧の速度が上がる。
4.3.2 生成物(中間データ)の管理
生成物管理では、中間データのライフサイクル（保存、更新、削除）を決める。どのステップの出力を後で参照する価値があるかを見極め、保管コストと調査効率のバランスを取る。
さらに、生成物のフォーマットや粒度を統一すると、後続の実行や比較が容易になる。保存時にはバージョンと整合する識別子を付与する。
4.4 エラー処理とリカバリ
エラー処理では、失敗を単に停止するだけでなく、影響を局所化し、可能な範囲で復旧する方針を定める。パイプラインの信頼性は、復旧の設計に左右される。
リカバリ戦略は、再実行、部分実行、代替データへの切替などを組み合わせて決める。
4.4.1 リトライ設計
リトライ設計では、どの種類の失敗が再試行で解消するかを判定する。ネットワーク一時障害や一時的な外部サービス不通はリトライの対象になり得るが、入力品質の不備は再試行しても改善しない。
リトライ回数、待機時間の増加、失敗ログの保持といった制御を設けることで、無駄な負荷を抑えつつ復旧可能性を高める。
4.4.2 フォールバック戦略
フォールバック戦略は、主要処理が失敗した場合に備えた代替ルートである。たとえば、重い特徴量生成が失敗した場合は軽量な集計に切り替える、または特定列のみ除外して処理を継続する、といった設計が考えられる。
ただし、フォールバックは評価の比較可能性を損なう恐れがあるため、適用時の記録を必ず残し、後段がその違いを認識できるようにする。
5 パイプラインの自動化と統合
自動化と統合により、前処理は手作業に依存せず、継続的な学習や更新に対応できるようになる。運用頻度が上がるほど、人的介入の削減は効果を発揮する。
また、学習や推論との接続を整えることで、前処理の結果が一貫した形でモデルへ渡る。
5.1 ワークフロー管理
ワークフロー管理では、ジョブの依存関係、実行順序、並列化、失敗時の分岐を定義する。例えば、入力取得が失敗した場合には前処理を走らせない、品質検査で閾値超過なら中断する、といった制御を行う。
実行ログと成果物を一元管理し、スケジュール実行やイベント駆動の両方を支える設計が望ましい。
5.2 パイプラインの再利用性
再利用性は、同じ前処理部品を別のタスクやデータセットへ適用できる性質である。スケーリングやカテゴリ正規化のような共通処理をモジュール化し、設定で差し替えられる形にする。
再利用には、入出力の契約（列名、型、意味、例外条件）を明文化することが重要である。契約が曖昧だと、別用途へ移植した際に隠れた不整合が起きる。
5.3 他工程（学習・推論）との接続
他工程との接続では、前処理で学習した統計量やエンコード規則を推論時にも再現適用できるようにする。学習と推論で変換の仕様が一致していないと、入力分布が崩れ推定性能が低下する。
さらに、推論用の前処理は遅延要件を満たす必要があるため、オンライン処理に向く軽量化やキャッシュ戦略も検討対象になる。
6 よくある落とし穴
落とし穴は、設計と実装の境界で起きやすい。ここでは頻出する3点を整理し、避けるための考え方を示す。
回避策は「技術的対処」だけでなく、「順序を誤りにくい設計」によって達成されることが多い。
6.1 データ漏えいと前処理の境界
データ漏えいは、評価や未来の情報が学習側へ混入することで生じる。前処理で分布推定や補完を全データに対して行うと、評価側の統計が混ざり不正確な成果につながる。
境界を守るために、分割後に適用すべき変換と分割前に適用すべき変換を分類し、パイプラインの構造で強制することが有効である。
6.2 学習時のみ適用される変換の事故
学習時のみの変換には、ターゲットを用いるエンコードや、学習データに基づく選択・削減が含まれる。これらを推論時にも同じ形で適用できない場合、事故が起きやすい。
対処としては、学習時に推定されたパラメータ（辞書、埋め込み、統計量）を保存し、それを推論時に固定して適用する設計を採ることが基本になる。
6.3 スキーマ変更への脆弱性
入力スキーマが変わると、列の欠落や型の変化で処理が破綻する。特に外部データ連携では、供給側の変更が予告なく起きることがある。
脆弱性を減らすには、スキーマ検査を早い段階で行い、必要に応じて移行ルールや互換層を用意する。どの変更が致命的で、どれが許容範囲かを定義しておくと運用が安定する。
7 事例（用途別の具体）
用途別の例では、データの性質に合わせて前処理設計が変わる点を示す。目的タスクが同じでも、データ形式によって最適な手順は異なり得る。
以下の事例は代表的な方向性であり、実データでは検査指標や閾値を調整して適用する。
7.1 時系列データの前処理
時系列では、欠損が「観測の途切れ」と「実際の不在」のどちらを意味するかを整理する必要がある。時間軸の欠損補完を行う場合は、補完方法と影響範囲を明示する。
特徴量としては、移動窓の集計や遅延特徴（過去値）を作り、参照時刻を厳密に扱う。分割は未来が学習へ混ざらないよう順序を保持し、評価期間を固定することが多い。
7.2 画像・音声データの前処理
画像では、サイズの統一、画素値の正規化、欠損のない入力の確保が基本になる。データ増強は学習時のみに適用するのが一般的で、推論時とは区別する。
音声では、サンプリング周波数やビット深度の統一、スペクトログラム作成、無音区間の扱いなどが論点になる。特徴抽出器のパラメータを保存し、再現できる形で管理することが重要である。
7.3 テキストデータの前処理
テキストでは、正規化（表記揺れの吸収）、トークン化、語彙の整備、欠損や特殊記号の扱いが中心になる。カテゴリというより連続的な文字列を扱うため、前処理の設計はモデル側の仕様と密接に関わる。
さらに、クラス分類ではラベルの整合性検証が重要で、注釈基準のブレが性能に影響する。語彙外（未知語）の扱いも方針化する必要がある。
7.4 需要予測・分類などタスク別の工夫
需要予測では、時間特徴の生成（曜日、祝日、季節性の近似）や、過去履歴からの派生量がよく用いられる。外れ値や欠測の影響が強いため、ロバストな前処理が有効になる場面がある。
分類では、クラス不均衡への配慮が重要になり、分割時の層化や重み付けに加えて、入力表現の安定化（カテゴリ正規化、文字列の揺れ抑制）を徹底することが成果に結びつきやすい。
8 成果指標と評価方法
前処理の効果は、データ品質の改善と最終性能の両面から評価される。前処理だけを見ても判断できないため、測定指標を複数用いるのが一般的である。
また、改善サイクルでは、変更の寄与を切り分ける手法が重要になる。
8.1 データ品質指標
データ品質指標としては、欠損率、分布の安定度、整合性違反件数、重複率、外れ値率などが挙げられる。指標は列別・対象単位別に集計し、どこで悪化しているかを特定しやすくする。
品質指標の基準値を定め、合否判定や段階的な警告につなげると、運用の意思決定が早くなる。
8.2 モデル性能への影響測定
前処理が性能に与える影響は、同一モデル・同一分割条件で比較することで測定しやすい。指標には精度だけでなく、再現率、適合率、校正誤差、損失関数の変化など、タスクに応じたものを選ぶ。
また、学習速度や安定性（学習曲線のばらつき）も評価対象になる。前処理の変更が学習の収束挙動を変える場合があるため、単発のスコアだけで判断しない方がよい。
8.3 改善サイクル（アブレーション）
改善サイクルでは、前処理の構成要素を段階的に除去または変更し、どの部分が性能に寄与したかを調べる。これはアブレーション（寄与の切り分け）に相当する。
寄与が見えても、データ分布の変化や運用条件が変われば効果が変動することがあるため、異なる時期やデータロットでの再検証も行う。さらに、品質指標の変化と性能指標の変化の関係を記録すると、次の改善に活かしやすい。