【Kaggle挑戦記】S4E11 #1：全特徴量を投入して見えた「名前」の怪しい貢献度

KaggleのPlayground Series S4E11「メンタルヘルス予測」に参戦しました。まずはエンジニアとしての定石通り、複雑な加工はせず「まずは動くもの」を目指します。今回はあえて「id以外の全特徴量をぶっ込む」という、力押しのベースライン構築からスタートです。

1. 戦略：全件投入のフルスキャン・アプローチ

「どの変数が有効か？」と悩む前に、LightGBMの処理能力を信じて全データを投入しました。通常なら除外するはずの「Name（名前）」カラムも、あえてそのまま。カテゴリ変数は、LightGBMのcategory型にキャストするだけで、内部的に最適化されるように実装しました。

# 特徴量は全投入（idのみ除外）
X = train.drop(['id', 'Depression'], axis=1)
y = train['Depression']

# 全object型カラムをcategory型へキャスト
cat_cols = X.select_dtypes(include=['object']).columns.tolist()
for col in cat_cols:
    X[col] = X[col].astype('category')

2. リザルト：驚愕のスコアと「ログ」の違和感

Macで実行すること数秒。生成されたsubmission.csvをSubmitした結果、驚きのスコアが返ってきました。

Public Score: 0.94008 / Private Score: 0.93868

いきなり0.94超え。しかし、エンジニアとして「中身」をデバッグせずに喜ぶわけにはいきません。モデルが何を根拠に判断したか（Feature Importance）を確認したところ、奇妙な事実が判明しました。

--- Feature Importance (Top 5) ---

Name : 1308

City : 223

Age : 204

Financial Stress : 174

Profession : 159

3. 考察：なぜ「名前」の貢献度が異常に高いのか？

予測の決め手が、年齢や仕事のストレスを差し置いて「Name（名前）」になっています。バックエンドのロジックとして考えれば、名前の文字列そのものがメンタルヘルスに影響を与えるはずがありません。

考えられる仮説はいくつかあります：

過学習（Overfitting）： モデルが名前をユニークなキーとして認識し、個々のデータを「暗記」してしまった。
データリーク： 名前の付け方や順序に、正解データへのヒントが紛れ込んでいる（システムバグに近い状態）。
プロキシ変数の可能性： 名前が特定の居住地域や年齢層、あるいは家系的な背景を代理してしまっている。

4. まとめ：次回のデバッグ指針

「全部入り」で投げた結果、0.94という高いベンチマークと同時に、「名前という名の巨大なノイズ（あるいは不正解）」を炙り出すことができました。

この「名前」がスコアを不当に押し上げているのか、それとも何か深い意味があるのか。次回は「Name」をdropした状態で再学習を行い、モデルの真の実力をデバッグしてみたいと思います。