特徴量エンジニアリング：MLモデルの品質を左右する意思決定

月曜の朝にリリースした新しい機械学習モデルがあります。しかし昼休みを迎える頃には、アナリストたちが誤検知の対応に忙殺されていました。優先度の高い異常値が見落とされる一方で、ごくありふれたケースが次々とエスカレーションされている状況です。事前検証では完璧だったはずのモデルが、なぜ本番環境でこれほど崩れてしまったのか、誰も説明できません。

原因は、必ずしもアルゴリズムの性能不足にあるとは限りません。データの表現方法に問題があった可能性があります。たとえば、取引金額を生の値のまま読み込ませていたため、その顧客にとってその金額がどれほど異常かをモデルが察知できなかったのかもしれません。あるいは、意図しない誤解を生むような形でカテゴリ変数をエンコードしてしまった可能性もあります。モデル自体は正確なデータで学習していたとしても、データ内に潜む本質的なシグナルが適切にモデルへ届いていなかったのです。

生データを機械学習モデルが正しく理解できる入力値へと変換する、それこそが特徴量エンジニアリングの役割です。

これには、欠損値の穴埋め、カテゴリ変数のエンコーディング、数値のスケーリングといった基本的なデータ前処理だけでなく、モデルに何を、どう見せるべきかというデータ表現に関する高度な意思決定が含まれます。この意思決定の精度こそが、モデルにどれだけの有用なシグナルを届けられるか、そして実際の運用環境に直面した際にどれほどのパフォーマンスを発揮できるかを大きく左右するのです。

特徴量エンジニアリングとは、ドメイン知識を活用し、機械学習モデルがより正確な予測を行えるように、生データから入力変数（特徴量）を作成、変換、選択するプロセスです。

特徴量には、トランザクション金額やアカウントの経過日数などのソース列を直接使用するものもあれば、派生データもあります。派生データの例としては、過去90日間の顧客の平均注文額、過去1時間の認証失敗回数、あるいは単独では情報量が少なくても組み合わせることで意味を持つ2つの指標の比率などが挙げられます。

特徴量エンジニアリングは、生データとモデルトレーニングの間に位置します。チームはソースシステムからシグナルを抽出し、モデルで使用できる入力形式に変換します。そして、どの入力が検証パフォーマンスを向上させるかを評価し、承認されたロジックを特徴量パイプラインや特徴量ストアに組み込んで再利用します。モデルに必要な特徴量を決定することは、そのドメインについてモデルが何を理解しなければならないかを決定することでもあります。

特徴量エンジニアリングは、ビジネス上の課題に対するチームの理解をモデルに組み込む作業であるため、データサイエンティスト、データエンジニア、ドメインエキスパート間のコラボレーションが不可欠です。適切に実行されれば、機械学習のライフサイクルにおいて最もインパクトの大きい（効果的な）取り組みの1つとなります。

モデルの品質は、その入力データによって決まります。アルゴリズムの選択、ハイパーパラメータのチューニング、またはコンピュートをどれほど行っても、最初から特徴量セットに存在しなかったシグナルを回復することはできません。特徴量エンジニアリングは、その上限が設定されるプロセスであり、MLライフサイクルの他のどの段階よりも、チームがモデルの品質を直接的に制御できるプロセスです。

その上限を決定づける要素の1つが、データの表現方法です。同じ基礎データでも、表現が異なれば、モデルには問題の根本的に異なる全体像が提示されます。製品の使用状況データに基づいて構築されたチャーンモデルを例に挙げます。過去30日間の生のログイン数は、顧客がどれだけアクティブであったかをモデルに伝えます。しかし、実際にチャーンを予測するのは、多くの場合、そのアクティビティの変化です。60日前の半分の頻度でログインしている顧客は、常にその頻度でログインしている顧客とは状況が異なります。基礎となるデータは同じです。回数ではなくトレンドとして表現されると、生の値だけでは得られないシグナルが伝達されます。

Pedro Domingos氏の基礎的な論文『A Few Useful Things to Know About Machine Learning』では、「表現」がこの分野における中心的な問題の1つとして特定されています。この観察は現在でも当てはまります。利用可能な特徴量が問題の構造を捉えていない場合、どのようにチューニングされていても、アルゴリズムが処理できる情報は少なくなります。

特徴量エンジニアリングは、汎化性能にも影響を与えます。データ内の真の永続的なパターンを反映する特徴量でトレーニングされたモデルは、新しい顧客、新しい製品、または異なるオペレーティング環境に遭遇したときに、正確な予測を生成する可能性が高くなります。トレーニング期間中にターゲットと偶然相関関係にあった特徴量（ただし付随的な理由によるもの）でトレーニングされたモデルは、本番環境での劣化が早くなります。

エージェント型MLで特徴量エンジニアリングを簡素化する方法について、動画をご覧ください。

特徴量エンジニアリングは通常、解決すべき予測課題を特定し、そこから逆算して必要なデータを整理していく形で進められます。たとえば、需要予測を行うチームとサポートチケットの自動分類を行うチームでは、同じ顧客データ、製品データ、時系列データを使っていても、必要となるシグナルは全く異なります。

実践的なプロセスは、主に以下のステップで構成されます。

1. 課題とデータの理解：予測対象、モデルが支援する意思決定の内容、およびレイテンシー、説明可能性、データアクセス権限などの制約条件を明確にします。
2. 生データの探索と分析：データの分布、欠損値、外れ値、相関関係、カテゴリ変数のカーディナリティ、時系列のパターンなどを精査します。
3. 特徴量の作成と変換：比率、ローリングウィンドウ、カウント、フラグ、交互作用項、正規化された数値など、様々な派生指標を生成します。
4. 特徴量の有効性評価：統計的検定、モデルによる重要度スコア、ドメインエキスパートのレビュー、検証結果などを通じて、どの特徴量が予測に有効なシグナルを持っているかを判断します。
5. モデルのパフォーマンスによる検証：適切な比較実験を行ってモデルの学習と検証を進め、データリーケージ、過学習、および学習データと本番データ間の不整合をモニタリングします。

このプロセスは何度も反復して行われます。データサイエンティストは、比率、カウント、移動集計、ラグ特徴量、フラグ、カテゴリエンコーディング、交互作用項などを試作し、それらの入力がホールドアウトデータの精度向上に寄与するかをテストします。

すぐに高い効果を発揮する特徴量もあれば、データリーケージを引き起こしたり、時間の経過とともに変化しすぎたり、推論時に取得できないデータに依存していたりするために不採用となる特徴量もあります。

また、特徴量の生成ロジックは散乱、肥大化しやすいため、厳格な管理が必要です。 たとえば、ノートブック上で検証された計算ロジックが、学習パイプラインで再構築され、さらにリアルタイム推論用に書き直された場合、同じ概念を指しているにもかかわらず、3つのプロセスでわずかに異なる値が算出されてしまう危険性があります。

こうした仕様のブレを防ぐために存在するのが、再現可能な特徴量パイプラインや特徴量ストアです。これらを導入することで、モデル構築時に使用した特徴量の定義を正しく保持し、バッチ推論、リアルタイム推論のいずれにおいても一貫したデータを供給できるようになります。

特徴量エンジニアリングでは、多種多様な手法が用いられます。生データをモデルに入力できる状態に整える手法もあれば、既存の項目を組み合わせて新たなシグナルを抽出する手法もあります。最適な手法の組み合わせは、データの種類、使用するアルゴリズムのタイプ、そしてモデルが支援する意思決定の内容によって異なります。

欠損値の補完と外れ値の処理

欠損値を処理する際は、まずその背景や理由を正しく解釈する必要があります。データが存在しない理由には、値が不明、入力が任意、意図的な非開示、収集時点での取得不能、あるいはそもそも該当項目が存在しないなど、様々なケースが考えられます。

欠損値を補完する手法としては、平均値、中央値、最頻値、固定値の代入や、モデルによる推測値の埋め込みなどが用いられます。多くの場合、チームは補完と同時に欠損していたかどうかを示すフラグも追加します。これにより、値が存在しないこと自体が持つ重要な意味をモデルに学習させることができます。

同様に、外れ値の扱いにも慎重な判断が求められます。たとえば、突出して高額な取引データがある場合、それが不正利用なのか、大口の法人購入なのか、単なる入力ミスなのかによって対応が変わります。具体的なアプローチとしては、しきい値によるクリッピング、分布の歪みを抑えるデータ変換、明らかなエラー値の削除、あるいはモデルが検知すべき重要なシグナルとして極端な値をあえて残す、といった方法が挙げられます。

このように外れ値をどう扱うかは、モデルにどのような現実世界を再現・学習させるかを決める、データ表現上の重要な意思決定となります。

スケーリングと正規化

スケーリングは、数値特徴量のスケールを揃え、大きさの違いによってモデルの挙動に歪みが生じるのを防ぐ処理です。代表的な手法として、値を特定の固定区間に収めるMin-Maxスケーリング、データの平均値と標準偏差を用いて偏りを揃えるZスコア標準化、そして平均値の代わりに中央値と四分位範囲（IQR）を用いることで外れ値の影響を抑えるロバストスケーリングなどがあります。

スケーリングに対する感度は、使用するアルゴリズムのタイプによって異なります。線形モデル、ニューラルネットワーク、および距離ベースのアルゴリズムは、特徴量のスケール差による影響を強く受けます。一方、決定木などのツリーベースモデルは基本的にスケーリングの影響を受けにくいですが、共通の特徴量セットを複数のモデルや後続のシステムで使い回す場合は、前処理を一元的に標準化しておくのが一般的です。

カテゴリ変数のエンコーディング

ほとんどの機械学習モデルでは、カテゴリ変数を数値に変換して表現する必要があります。カテゴリの種類数（カーディナリティ）が少ない場合に用いられる最もシンプルな手法がワンホットエンコーディング（各カテゴリの有無を0/1で表す手法）です。小・中・大のように順序に意味がある場合は順序エンコーディングを用いて順序関係を保持します。一方、ラベルエンコーディングはカテゴリに連番の整数IDを割り当てますが、元々順序が存在しないデータに対して誤って順序関係を学習させてしまうリスクがあります。

特に注意が必要なのが、加盟店IDや製品SKU、地域コードといったカーディナリティが極めて高いフィールドです。種類数が数千以上に及ぶ場合、ワンホットエンコーディングを適用するのは現実的ではありません。こうしたケースでは、カテゴリの値を予測ターゲットの統計量に置き換えるターゲットエンコーディング（平均エンコーディング）が有効です。ただし、この手法を適用する際は、検証用データの情報が漏れ出さないよう、交差検証などの厳格な手順を踏む必要があります。

変換、ビニング、離散化

データ変換は、特徴量の分布やターゲットとの関係性を調整するために行われます。代表的な手法である対数変換は、売上高、セッション滞在時間、口座残高などのように、極端に大きな値が一部に偏っているデータの影響を和らげるのに効果的です。また、Box-Cox変換などの手法は、データが正規分布に従うことを前提とするモデルに適した状態へ数値を変換できます（ただし、Box-Cox変換を適用するには数値がすべて正の値である必要があります）。

ビニング（離散化）は、連続値をいくつかの区間に区切ってグループ化する手法です。たとえば、生の年齢の代わりに年代、登録からの正確な日数ではなく利用期間の区分、取引金額の代わりに支出ランクをモデルの入力として渡します。ビニングを行うことで、モデルが特定のパターンを学習しやすくなるほか、金融や医療など厳格な説明責任が求められる分野においてモデルの挙動を説明しやすくなるというメリットがあります。特に、法的な基準値、製品プランの価格境界、臨床検査の基準値など、業界や業務上のしきい値が最初から明確に存在する場合は、生の数値データをそのまま使うよりも、それらのしきい値に合わせてビニングした方が、よりビジネス価値の高い特徴量を作ることができます。

特徴量の作成

特徴量の作成は、ドメイン知識が最も直接的に活きるプロセスです。

• 小売の需要予測モデル：直近の販売ペース、在庫状況、プロモーションの実施タイミング、近隣イベントの開催状況といった特徴量が有効です。
• セキュリティ（不正検知）モデル：ログイン失敗の頻度、新規デバイスのスコア、短時間での不可能な移動の検知フラグ、アカウントの平常時からの行動乖離度などが求められます。
• 顧客ヘルス（Churn予測等）モデル：プロダクトの利用傾向、カスタマーサポートとのやり取りパターン、契約ステータスの変更履歴などが鍵となります。

また、複数のフィールドを組み合わせて相互作用を捉えるクロス特徴量（特徴量の掛け合わせ）も強力です。たとえば地域×製品カテゴリや、チャネル×顧客セグメント、時間帯×デバイスタイプといった組み合わせが挙げられます。

さらに、一部のアルゴリズムで非線形な関係性を表現するための多項式特徴量や、タイムスタンプから構造化データを抽出する時系列特徴量も重要です。時系列特徴量には、時刻、曜日、直前のイベントからの経過時間、移動平均、ラグ値、周期的なパターンを表現するための周期エンコーディングが含まれます。

次元削減

データセットの特徴量が非常に多い場合や、ノイズ・強度の相関が含まれる場合、次元削減手法を用いることで有用な情報を保持したまま特徴量空間を圧縮できます。代表的な手法である主成分分析（PCA）は、相関のある多数の数値特徴量を、より少数の成分に集約、変換します。また、オートエンコーダーなどのディープラーニング手法を使えば、より複雑な入力データからコンパクトな表現を学習させることも可能です。

一方で、最大のトレードオフとなるのがモデルの解釈可能性です。特徴量を圧縮することで計算効率やモデル精度が向上するケースがある反面、変換後の成分がビジネスや業務の専門家にとって何を意味するのかを直感的に説明することが難しくなります。

そのため、厳格な倫理基準や法的規制が伴う高リスクなユースケースにおいては、この透明性の低下が深刻なリスクとなり得ます。チームは、次元削減によって得られるパフォーマンス上のメリットと、失われる説明性とのバランスを慎重に見極める必要があります。

これらの用語は、機械学習（ML）のワークフローにおいて連続するプロセスであるため、セットで使われることがよくあります。それぞれの役割の概要は以下の通りです。

特徴量エンジニアリング

特徴量エンジニアリングとは、生データからモデルに入力するデータを整える一連の作業を指します。具体的には、新たな特徴量の生成、数値の変換、欠損値の処理、カテゴリ変数のエンコーディング、次元削減、そして学習に使用する特徴量の選定まで、多岐にわたる工程を含んでいます。以下で紹介するその他の要素は、この大きな枠組みの中に含まれる具体的な工程、またはそれを補強、拡張する技術です。

特徴量選択

特徴量選択とは、用意された多数の特徴量の中から、実際にモデルへ入力すべき最適な特徴量を絞り込む作業です。具体的には、情報が重複している特徴量、値が不安定な特徴量、予測ターゲットとの相関が低い特徴量、実務での説明が難しい特徴量、あるいは運用時にリアルタイム取得できない特徴量などを除外していきます。

適切な選択を行うことで、過学習を防ぎ、モデルの計算効率を高めることができます。さらに、運用面でも大きなメリットがあります。安定した理解しやすい少数の特徴量で構築されたモデルは、多数の弱い指標や重複する指標に依存するモデルよりも、本番環境でのモニタリングや外部監査がはるかに容易になります。

代表的なアプローチには、以下の3つがあります。

• フィルター法： 統計的な指標を用いて、モデル学習前にあらかじめ特徴量の絞り込みを行う手法。
• ラッパー法： 特徴量の組み合わせを変えながら実際にモデルを学習させ、予測精度をもとに最適な組み合わせを探索する手法。
• 組み込み法： L1正則化（Lasso）の係数や決定木モデルの「特徴量重要度」など、モデルの学習過程（内部アルゴリズム）で自動的に重要な特徴量を選別する手法。

特徴量抽出

特徴量抽出とは、生データや複雑なデータから機械学習モデルが扱いやすいデータ構造を導き出す作業です。

• タイムスタンプ（日時）： 曜日、月、あるいは基準となるイベントからの経過時間などを算出します。
• フリーテキスト（自然言語）： 単語の出現頻度、感情分析スコア、または高次元のベクトル埋め込みに変換します。
• 画像データ： 画像認識モデルの中間層から、エッジ、テクスチャ、あるいは学習済みの特徴表現を抽出します。

実務において、特徴量抽出は特徴量の作成と大きく領域が重なります。両者の違いは焦点の置き方にあります。抽出が非構造化データなどの生の入力から有効な構造を取り出すこと自体を指すのに対し、特徴量エンジニアリングは、それらの情報をモデル学習用に最適化する一連のプロセス全体を指します。

特徴量ストア

特徴量ストアとは、特徴量の定義、事前計算されたデータ値、および関連するメタデータを一元管理する中央リポジトリです。導入することで、プロジェクト間での特徴量の再利用を促進し、データパイプラインの重複開発を削減できます。さらに最大のメリットとして、トレーニング時と推論時で全く同じ特徴量定義を保てるため、仕様の乖離を防ぐことができます。

データ拡張とは、既存の学習データに変換を加えて人工的なバリエーションを生み出し、トレーニングデータの量と多様性を増やす手法です。正解ラベルを変えることなくデータの幅を広げられるため、主に画像認識や自然言語処理（NLP）で頻繁に用いられます。

具体的な手法はデータ形式によって異なります。画像データでは反転、回転、クロップ、明るさ調整、位置のシフトなどを適用し、テキストデータでは同義語への置換や言い換え、意図的なノイズ追加などを行います。また、表形式データでクラスの不均衡がある場合は、SMOTEなどの手法を用いて少数派クラスの疑似データを生成することが一般的です。

データ拡張を行う際に最も重要な判断基準は、変換を加えても、そのデータが元の意味を保持できているかという点です。たとえば、ECサイトの製品分類において商品画像を回転させてもその商品であることに変わりはありません。しかし、製造業の欠陥検知モデルでは、画像上の向き自体が欠陥の種類を示す重要な情報になっている場合があります。

データ拡張は、モデルに耐性を持たせたいデータの変化やノイズを再現する場合にはきわめて有効ですが、予測に不可欠な本来のシグナルを打ち消してしまう場合は逆効果となります。

埋め込みとは、データ内の相互関係や構造を捉えた高次元の数値ベクトル（密ベクトル）で表現する手法です。一般的なエンコーディング手法では捉えきれない高度な情報を表現できるため、テキスト、画像、レコメンデーション、あるいはユニーク数の多いカテゴリデータを扱うワークフローで幅広く活用されています。

たとえば商品IDという数値そのものにはビジネス上の意味はありませんが、埋め込みを用いることで、商品の説明文、同時購入の傾向、見た目の特徴、閲覧履歴などに基づいて、類似した商品をベクトル空間上で近い位置に配置できるようになります。同様にテキストの埋め込みも、意味的に近いフレーズ同士を近くに配置できるため、検索、テキスト分類、レコメンデーション、そして検索拡張生成（RAG）などの用途で極めて有用です。

埋め込みは、特徴量エンジニアリングにおいて少し特殊な役割を担っています。手作業で作成した特徴量と同様に後続のモデルへ渡す特徴量として機能する一方で、ドメイン知識をもとに人間が定義するのではなく、大規模なデータセットから特徴表現を自動的に学習させるという異なるアプローチを取るためです。

そのため実際の開発現場では、コンテンツの特徴や個体の識別情報には学習済みの埋め込みを使い、ユーザーの行動履歴、時間経過、利用コンテキストなどの動的なシグナルには人間が作成した特徴量を使うといったように、両者を組み合わせたハイブリッドなMLシステムが多く構築されています。

自動化された特徴量エンジニアリングとは、生データから候補となる大量の特徴量をソフトウェアによって自動作成する手法です。代表的なライブラリであるFeaturetoolsなどは、Deep Feature Synthesis（深層特徴合成）といったアルゴリズムを用いて、リレーショナルデータベースのように複数の関連するテーブルにまたがる特徴量を体系的に生成します。また、AutoML（自動化された機械学習）システムでも、モデル構築の一環としてデータ変換、エンコーディング、交互作用特徴量などの自動生成が行われます。

こうした自動化技術は、探索すべき特徴量の候補が膨大な場合や、繰り返し発生するデータ変換処理の効率化に大きな効果を発揮します。移動集計、日付データからの指標抽出、カテゴリエンコーディング、テーブル単位のサマリー計算など、手作業で1つずつコーディングすると膨大な時間がかかる作業を、一瞬で処理することが可能です。

ただし、特徴量エンジニアリングの主導権を握るべきなのは、依然として人間のドメイン知識です。自動生成された膨大な特徴量の中から、どれを実際のモデルに採用すべきかは、業務の専門知識を持つメンバーによるレビュー、検証、そしてガバナンスの観点をもとに慎重に判断する必要があります。

本番環境での特徴量エンジニアリングには、変換コード以上のものが必要です。チームには、ソースデータへのガバナンスが効いたアクセス、大規模なデータセットに対応するスケーラブルな処理能力、再利用可能な特徴量定義、信頼性の高い特徴量の鮮度、およびトレーニングデータから展開されたモデルへの明確なパスが必要です。

Snowflakeは、ガバナンスが効いたデータ上でエンドツーエンドのMLを実現する統合機能セットであるSnowflake MLを通じてこのワークフローをサポートし、特徴量エンジニアリング、モデルトレーニング、および推論をカバーします。

Snowparkを使用すると、チームはPythonまたはSQLで特徴量変換を記述し、データを外部環境に移動することなく、データの近くで実行できます。Snowflake特徴量ストアは、マネージド特徴量定義と特徴量ビューを提供し、チームがSnowflake内で特徴量パイプラインを作成、マテリアライズ、取得、および管理できるようにします。特徴量ビューは、生データをモデル対応の特徴量に変換するPythonまたはSQLパイプラインをカプセル化でき、Snowflakeマネージド特徴量ビューは、定義されたスケジュールで自動的にリフレッシュできます。

ダイナミックテーブルは、SQLで定義された変換を最新の状態に保つ必要がある増分的な特徴量パイプラインをサポートします。Snowflakeはダイナミックテーブルをパイプラインとして管理し、依存関係を追跡してリフレッシュを調整することで、ダウンストリームのテーブルが入力の一貫したスナップショットを反映できるようにします。ダイナミックテーブルは、データの鮮度を指定するターゲットラグや、サポートされている変換パターンの増分リフレッシュもサポートしています。

本番環境のMLでは、Snowflake特徴量ストアをSnowflakeモデルレジストリと併用できます。レジストリは、モデルのバージョン、メトリクス、メタデータを保存および管理し、Python、SQL、またはREST APIエンドポイントを介した推論をサポートし、ロールベースのアクセス制御（RBAC）を通じてモデルへのアクセスを管理します。

特徴量エンジニアリングは、実際のモデリングが始まる前に行われる準備作業として説明されることがあります。しかし、このような捉え方では、この作業の重要性と実際の作業内容が見落とされてしまいます。変数の表現方法、欠損値の処理、カテゴリのエンコード、またはラグ特徴量の構築に関するすべての決定は、モデルが動作するドメインについて何を理解できるかを決定するものです。

本番環境のスケールの場合、表現に関する決定事項は増大します。特徴量は複数のモデル間で再利用され、異なるチームによって再構築され、さまざまな環境で再計算されます。探索からトレーニング、推論に至るまで、これらの定義の一貫性を保つことは、モデルの品質に直接的な影響を与えます。

これが、特徴量エンジニアリングとMLOpsが密接に関連している理由です。特徴量エンジニアリングはモデルが何を学習するかを決定し、MLOpsはモデルが開発から本番環境に移行する際に、それらの特徴量の定義が一貫性、可観測性、信頼性を維持できるように支援します。