# 特徴量探索のワークフロー > 特徴量探索のワークフロー - エンドツーエンドの本番機械学習には、反復可能なフレームワークを使用します。これには、複数のテーブルにわたる時間認識の特徴量エンジニアリング、トレーニングデータセットの作成 > 、モデル開発、および本番デプロイが含まれます。 This Markdown file sits beside the HTML page at the same path (with a `.md` suffix). It summarizes the topic and lists links for tools and LLM context. Companion generated at `2026-07-27T18:44:30.229163+00:00` (UTC). ## Primary page - [特徴量探索のワークフロー](https://docs.datarobot.com/ja/docs/api/dev-learning/accelerators/model-building-tuning/afd-e2e.html.md): Full documentation for this topic (Markdown sidecar). ## Documentation content [GitHubでこのAIアクセラレーターにアクセス](https://github.com/datarobot-community/ai-accelerators/blob/main/use_cases_and_horizontal_approaches/Automated_Feature_Discovery_template_ML_pipeline/End-to-end%20Automated%20Feature%20Discovery%20Production%20Workflow.ipynb) このアクセラレーターは、エンドツーエンドの本番機械学習向けの反復可能なフレームワークの概略を示します。 これには、複数のテーブルにわたる時間認識の特徴量エンジニアリング、トレーニングデータセットの作成、モデル開発、および本番デプロイが含まれます。 複数のソースからトレーニングデータを構築するのが一般的ですが、特に、多くの時間認識特徴量を作成する必要がある場合は、このプロセスでは時間がかかり、エラーが発生しやすくなることがあります。 - イベントベースのデータは、 小売業や銀行業での顧客との取引、医療機関への来院、製造の生産ラインデータなど、すべての垂直型産業で存在します。 - ほとんどの分類および連続値のユースケースでは、この情報を親（エンティティ）レベルで要約する必要があります。 たとえば、不正、解約、購買傾向を予測する場合、履歴ウィンドウでの顧客の取引に関するサマリー統計が望ましいことがあります。 この場合、データサイエンティストの観点からは実践面での多くの考慮事項が生じます。トレーニングには、どれ程前の時点まで遡るのが適切でしょうか。そのトレーニング期間内において特徴量に適したウィンドウはどれでしょうか。30日間でしょうか、15日間でしょうか、それとも7日間でしょうか。さらに、特徴量エンジニアリングでは、どのデータセットと特徴量を検討する必要があるでしょうか。これらの概念的な質問に答えるには、ドメインの専門知識や、ビジネスSMEとの相談が必要になります。 実際には、特にMVPステージでは、以前に作成された特徴量に限定するか、ドメインの専門知識からいくつかの新しいアイデアを追加することが一般的です。 - 特徴量ストアは、以前のユースケースで有効であった特徴量をすばやく試す際に役立ちます。ただし、ここでは、以前に生成されたラグ特徴量が将来のすべてのユースケースでうまく適応することを前提としています。 - ほとんどの場合、評価や検討を行っていない重要なインタラクションが常に存在します。 複数の戦術的な課題も生じます。 一般的な課題には、次のようなものがあります。 - データセット間で時間形式の一貫性がないので（分、日など）、ターゲットリーケージを回避するために正しく処理する必要があります。 - テキストデータとカテゴリーデータのエンコーディングは、複数のテーブルにわたるさまざまな計画対象期間で集約し、一般的に面倒である上にエラーが発生する傾向があります。 - 複雑さに応じて、本番環境向けに強化されたデータパイプラインの作成には数週間かかることがあります。 - 微妙な欠点は、特に顧客/患者/人間に関して、データの短期および長期的な影響が重要であることで、それらの影響は時間の経過とともに変化します。 どのラグ特徴量を作成するかを事前に把握することは困難です。 データがドリフトして動作が変化すると、デプロイ後に完全に新しい特徴量が必要になる可能性があり、プロセスを最初からやり直すことになります。 これらすべての課題は、MVPプロセスにリスクをもたらします。 最良のシナリオでは、過去の特徴量が新しいユースケースでシグナルをキャプチャし、モデルが「十分に優れている」場合、新しいデータセットへのさらなる探索が制限されます。 最悪のケースでは、特徴量が新しい信号をキャプチャしないため、ユースケースは追求する価値がないと判断します。 最終的には、モデルを改良する方法を理解するのに苦労することがあります。 サイクルタイムを大幅に短縮して、関連するデータセットにわたって特徴量を探索して検出できるとしたらどうでしょうか。 このノートブックは、以下の処理を行うためのテンプレートを提供します。 - SnowflakeにデータをロードしてDataRobotのAIカタログに登録する。 - Snowflakeを使用して複数の履歴時間ウィンドウとデータセットにわたる時間認識特徴量を設定して構築する（任意のデータベースに適用可能）。 - すべてのデータ型に対して複数の特徴量エンジニアリングアプローチとアルゴリズムを構築して評価。 - インサイトを抽出し、最適な特徴量エンジニアリングとモデリングのパイプラインを特定。 - ローカルで予測をテスト。 - 最良のパフォーマンスを発揮するモデルとすべての特徴量エンジニアリングをDockerコンテナにデプロイし、REST APIを公開する。 - Snowflakeからスコアリングし、Snowflakeに予測を書き戻す。