フレームワーク活用ガイドひとことで言うと#
機械学習モデルに入力する特徴量（Feature）を、生データからビジネス知識を活かして設計・生成する技術。「どんなアルゴリズムを使うか」よりも「どんな特徴量を作るか」の方がモデル精度に大きく影響する。データサイエンスの最も職人的で価値の高いスキル。
押さえておきたい用語#
- 特徴量（Feature）
- 機械学習モデルに入力する個々の変数のこと。年齢、購入回数、ログイン頻度などがこれにあたる。
- リーケージ（Data Leakage）
- 予測時点では知り得ない未来の情報が学習データに混入してしまう現象のこと。精度が不自然に高くなるが、実運用では使えない特徴量になる。
- ターゲットエンコーディング（Target Encoding）
- カテゴリ変数を、そのカテゴリごとの目的変数の平均値で置き換える変換手法のこと。カーディナリティの高いカテゴリ変数に有効。
- 特徴量重要度（Feature Importance）
- モデルの予測に各特徴量がどれだけ貢献しているかを示す指標のこと。ランダムフォレストやLightGBMで算出でき、特徴量選択の根拠になる。
特徴量エンジニアリングの全体像#
こんな悩みに効く#
- 機械学習モデルを作ったが、精度が期待ほど上がらない
- 生データをそのままモデルに入れているが、もっと良い変数がある気がする
- ドメイン知識はあるが、それをモデルにどう活かすかわからない
基本の使い方#
まず、手元のデータとモデルの予測対象（ターゲット変数）を深く理解する。
やること：
- 各カラムの分布を確認: ヒストグラム、基本統計量
- ターゲットとの相関を確認: 散布図、相関係数
- 欠損値とカーディナリティの確認: どの程度欠損しているか、カテゴリ変数の値は何種類か
- ドメイン知識のインプット: ビジネス担当者に「何がこの結果に影響しそうか」をヒアリング
この段階で「使えそうな生データ」と「追加で取得すべきデータ」を整理する。
生データを機械学習モデルが扱いやすい形に変換する。
| 変換手法 | 内容 | 例 |
|---|---|---|
| 数値の変換 | 対数変換、標準化、正規化 | 年収をlog変換して歪みを補正 |
| カテゴリのエンコーディング | One-Hot、Label、Target Encoding | 都道府県を47個のダミー変数に |
| 日付の展開 | 年、月、曜日、祝日フラグに分解 | 購入日を曜日・月末フラグに |
| 欠損値の処理 | 中央値補完、フラグ変数追加 | 欠損自体が情報を持つ場合もある |
| ビニング | 連続値をカテゴリに区切る | 年齢を「10代」「20代」「30代」に |
ポイント: 変換はターゲットとの関係性を保つ or 強化することが目的。
生データにはない新しい特徴量を生成する。ここが特徴量エンジニアリングの真価。
代表的な手法：
| 手法 | 内容 | 例 |
|---|---|---|
| 集約特徴量 | グループごとの平均・合計・カウント | 顧客ごとの過去3ヶ月の購入回数 |
| 差分・比率 | 2つの変数の差や比率 | 前月比売上成長率 |
| 時間窓特徴量 | 直近N日/週/月の集約値 | 過去7日のログイン回数 |
| 交互作用特徴量 | 2変数の掛け合わせ | 「年齢×年収」で経済力を表現 |
| テキスト特徴量 | テキストから数値を抽出 | レビューの文字数、感情スコア |
| 外部データの結合 | 天候、経済指標などを追加 | 購入日の天気、気温 |
ドメイン知識がここで差をつける。「何がこの結果に影響するか」を知っている人が作る特徴量は、自動生成では得られない精度をもたらす。
作った特徴量すべてを使うのではなく、有効なものを選択する。
特徴量選択の方法：
- 相関フィルタ: ターゲットとの相関が低い特徴量を除外
- 特徴量重要度: ランダムフォレストやLightGBMの重要度で評価
- 再帰的特徴量削減（RFE）: 重要度の低い特徴量を1つずつ除外して検証
- SHAP値: 各特徴量のモデルへの貢献を可視化
検証のサイクル：
- 特徴量を追加/変更 → 2. モデルを学習 → 3. バリデーションスコアを確認 → 4. 改善されたか判断
このサイクルを繰り返すことで、最適な特徴量セットを見つける。
具体例#
状況: 月間有料会員5万人のECサイト。解約予測モデルを構築したが、生データだけでのAUC（予測精度指標）は0.72。目標は0.85以上。
生データ（元の特徴量）: 会員歴（月数）、性別、年代、都道府県、プラン種別
特徴量エンジニアリングで追加した特徴量:
| 特徴量 | 種別 | 作り方 |
|---|---|---|
| 過去30日のログイン回数 | 集約 | ログデータから算出 |
| 過去30日の購入金額 | 集約 | 購買データから算出 |
| 直近購入からの経過日数 | 差分 | 現在日 - 最終購入日 |
| 前月比ログイン増減率 | 比率 | 今月ログイン数 / 先月ログイン数 |
| 決済エラー回数 | カウント | 決済ログから算出 |
| 会員歴×ログイン頻度 | 交互作用 | 長期会員なのにログインが少ない→危険信号 |
結果: AUC: 0.72 → 0.88（目標達成）。最も効いた特徴量は「前月比ログイン増減率」。ログイン回数の絶対値より変化率の方が解約を予測する力が強かった。
生データの5変数で0.72だった精度が、ドメイン知識を活かした特徴量追加で0.88に到達。「どんなデータがあるか」ではなく「どんな特徴量を作るか」がモデル精度を決める。
状況: 賃貸物件5,000件のデータで賃料予測モデルを構築中。生データ（面積、築年数、駅距離、階数）だけではMAPE（平均誤差率）が18%で、実用には物足りない。
追加した特徴量:
| 特徴量 | 発想 | 効果 |
|---|---|---|
| 最寄り駅の乗降客数 | 外部データ結合 | 駅の「格」を反映 |
| 築年数×面積 | 交互作用 | 古くて広い物件は単価が下がりやすい |
| 同一駅の平均賃料 | 集約 | エリアの相場感を反映 |
| 半径500m以内のコンビニ数 | 外部データ | 生活利便性の代理変数 |
| 最上階フラグ | 二値化 | 最上階プレミアムを反映 |
結果: MAPE: 18% → 9.5%。特に「最寄り駅の乗降客数」の寄与が大きく、単一の特徴量追加でMAPEが3ポイント改善。
不動産の賃料は「立地の質」に大きく依存するが、生データの「駅距離」だけではその情報が不十分。駅の乗降客数という外部データが「駅の格」を表現し、精度を大幅に改善した。
状況: 工場の生産設備50台のセンサーデータ（温度、振動、圧力、回転数）から故障予測モデルを構築。生データの精度はF1スコア0.58で、誤検知が多く現場で信頼されていない。
追加した特徴量:
| 特徴量 | 種別 | 根拠 |
|---|---|---|
| 過去1時間の温度上昇率 | 時間窓 | 急激な温度上昇は異常の前兆 |
| 振動の標準偏差（過去24h） | 集約 | 振動のバラつきが故障の予兆 |
| 前回メンテナンスからの稼働時間 | 差分 | 熟練工の経験則を変数化 |
| 温度×振動 | 交互作用 | 両方が高いとき危険度が急上昇 |
| 過去30日の異常アラート回数 | カウント | 小さな異常の蓄積が大故障につながる |
結果: F1スコア: 0.58 → 0.82。誤検知率が45%→12%に低減し、現場の信頼を獲得。
熟練工が「温度が上がってきて振動も増えたら危ない」と言っていた暗黙知を「温度×振動」の交互作用特徴量として形式知化。ドメイン知識をデータで表現することが、特徴量エンジニアリングの本質。
やりがちな失敗パターン#
- リーケージ（データ漏洩）に気づかない — 予測時点では知り得ない未来の情報を特徴量に含めてしまうと、モデルの精度が不自然に高くなる。「この特徴量は予測時点で取得可能か？」を必ず確認する
- 特徴量を作りすぎる — 大量の特徴量を投入すると過学習のリスクが上がる。特徴量選択で有効なものだけに絞ることが重要
- ドメイン知識なしで自動化に頼る — 自動特徴量生成ツール（featuretools等）は便利だが、ドメイン知識に基づく特徴量には勝てないことが多い。ビジネス担当者とのコミュニケーションを怠らない
- 訓練データとテストデータで変換を分けない — 訓練データ全体の統計量でテストデータを変換すると情報漏洩になる。fit_transformは訓練データのみ、テストデータにはtransformのみ適用する
まとめ#
特徴量エンジニアリングは、機械学習モデルの精度を決定づける最も重要なプロセス。「アルゴリズムの選択」よりも「特徴量の設計」の方が精度に大きく影響する。ドメイン知識を活かして生データから新しい変数を生み出し、モデルに「世界の見方」を教える作業。まずは「何がこの結果に影響するか」を考え、それをデータで表現することから始めよう。