特徴量管理：Feature Store or Parquet設計
導入 ― なぜ特徴量管理が重要か？
製薬・医療分野の機械学習プロジェクトでは、特徴量（features） の管理がモデル精度以上に重要になる場面があります。
例えば：
- ADMET予測で用いる 分子指紋や物理化学的記述子
- 医療画像から抽出した CNN特徴量ベクトル
- 電子カルテ（EHR）から得られる 患者属性・診断情報
これらがプロジェクトごとに点在すると、以下の課題が生じます。
- どのバージョンの特徴量で学習したか不明
- チームごとに前処理が異なり、再現できない
- 規制当局からの監査対応が困難
こうした課題を解決する仕組みが 特徴量管理（Feature Management） です。
選択肢1：SageMaker Feature Store
AWSが提供する SageMaker Feature Store は、フルマネージド型の特徴量管理サービスです。
利点
- 統一的なAPIで管理
オンライン（リアルタイム推論）とオフライン（学習用バッチ）の両方に対応 - スキーマ管理
データ型・ID・タイムスタンプを基盤で統制 - バージョニング
いつ・誰が・どのデータを利用したか追跡可能 - セキュリティ
IAMやKMS暗号化によるアクセス制御が可能 - MLOpsとの親和性
Model RegistryやPipelineと組み合わせやすい
コスト
- ストレージ料金（S3に近い水準）
- リクエスト料金（Put/Get/BatchGet API利用時に課金）
- 頻繁なオンライン推論アクセスがある場合、コストが増大しやすい
適用例（製薬・医療R&D）
- ADMET予測モデルで使用する特徴量を オンラインAPI で呼び出し → Webアプリに即時反映
- 複数プロジェクトで共通利用する分子指紋・記述子を 一元管理
選択肢2：Parquet + Glue/Athena 設計
一方で、より低コストでシンプルな設計も可能です。
S3に Parquet形式 で保存し、Glueカタログでスキーマを定義、Athenaでクエリする構成です。
利点
- コスト効率
追加のAPI課金なし、S3のストレージ料金のみ - シンプルな設計
OSSツール（Spark, Pandas, Polars）から直接アクセス可能 - 柔軟性
プロジェクトごとに異なる特徴量スキーマを気軽に定義できる
制約
- オンライン推論非対応（基本はオフライン利用のみ）
- スキーマ統制が弱い
Glueカタログ上の管理は可能だが、強制力はない - バージョニング手作業
S3のフォルダ階層やファイル命名規則でバージョン管理する必要あり
適用例（製薬・医療R&D）
- 大規模化合物データセット（数千万件の分子指紋）をバッチ処理
- 医療画像から抽出した特徴量ベクトルを バッチ学習にのみ利用
スキーマ管理とバージョニング戦略
特徴量管理において特に重要なのは 「どのデータで学習したかを再現できること」 です。
スキーマ管理
- 統一的な命名規則：
feature_<データタイプ>_<説明>- 例：
feature_fp_morgan1024,feature_desc_logP
- 例：
- データ型の明示：float32 / int64 / string などを必ず定義
- メタデータ付与：作成日時、担当者、元データセットID
バージョニング
- SageMaker Feature Storeの場合
- APIで自動的にタイムスタンプが保存されるため、追跡容易
- Parquet + Glue/Athenaの場合
- S3フォルダ階層で管理
s3://bucket/features/admet/v1/s3://bucket/features/admet/v2/
- Glueカタログで「最新バージョン」を指すViewを定義
- S3フォルダ階層で管理
まとめ
- リアルタイム推論やチーム横断の標準化が必要なら → SageMaker Feature Store
- コスト最優先 & オフライン利用が中心なら → Parquet + Glue/Athena
製薬・医療の研究現場では、規制対応や再現性の要求が強いため、最終的にはFeature Storeが望ましいケースが多いですが、PoC段階ではParquet設計で十分な場合もあります。
弊社では、製薬・医療研究向けに 特徴量管理からモデル運用までのMLOps基盤構築 を支援しています。
- Feature Store導入設計
- Parquetベースの低コスト特徴量管理
- 規制対応を見据えた監査ログ設計