Machine Learning: プロジェクト設計 — SalesPredict エンドツーエンド計画ガイド
最終更新:2026-08-26
始まりが良ければ半ば成功 — システム設計がプロジェクトの成否を分けます。構築を始める前に、まず青写真を描きましょう。
1. 学べること
- 要件分析:ビジネス目標(MAPE < 10% での月次売上予測)、ユーザーストーリー、主要指標の定義
- データアーキテクチャ:データソース(注文/ユーザー/商品/ログ)→ データレイク → 特徴量ストア
- モデルアーキテクチャ:ベースライン(LinearRegression)→ 高度なモデル(XGBoost)→ ディープラーニング(MLP)への進化ロードマップ
- デプロイアーキテクチャ:MLflow 実験管理 + FastAPI 推論サービス + Docker コンテナ化 + モニタリングとアラート
- プロジェクトスケジュールとチーム連携:Alice(データエンジニアリング)、Bob(MLエンジニアリング)、Charlie(バックエンド/DevOps)の役割分担
2. スタートアップチームの実話
(1) 課題:いきなりコードを書いた結果、3回の全面書き直しに
Bob はチームにすぐコーディングを始めさせました。2週間後、データソースの設計に欠陥があることがわかり、やり直しになりました。4週間後、モデルアーキテクチャがオンライン予測に対応していないことに気づき、また変更が必要になりました。8週間後、デプロイ計画にモニタリングが含まれていないことが判明し、再度リファクタリングを余儀なくされました。設計のないプロジェクトでは、すべてのステップが「想定外」になります。
(2) システム設計という解決策
システム設計とは、「何を作るか」と「どう作るか」を事前に考え抜くことです — 要件 → データ → モデル → デプロイ → モニタリングと、各ステップに明確な計画を立てます。
PYTHON
# Project design as code
project_config = {
"name": "SalesPredict",
"goal": "Monthly revenue prediction MAPE < 10%",
"data_sources": ["orders", "users", "products", "ad_logs"],
"model_pipeline": "LinearRegression → XGBoost → MLP",
"deployment": "FastAPI + Docker + MLflow",
"team": {"Alice": "Data Engineering", "Bob": "ML Engineering", "Charlie": "DevOps"},
}
(3) 効果:設計を先行させ、開発中の手戻りゼロを達成
Bob が1週間かけてシステム設計を行った結果、8週間の開発期間中に手戻りは一切なく、納期通りに完了しました。設計に費やした時間はプロジェクト全体のわずか10%でしたが、50%以上の手戻りリスクを回避できたのです。
3. 要件分析
(1) ビジネス目標の定義
▶ サンプル:要件定義書テンプレート
PYTHON
# Requirements as structured config
requirements = {
"business_goal": "Predict next month's revenue per product category",
"success_metrics": {
"primary": "MAPE < 10% for monthly revenue prediction",
"secondary": ["MAE < 50k USD per category", "Prediction latency < 100ms"],
},
"user_stories": [
"As Bob (Operations), I want monthly revenue predictions so I can optimize inventory",
"As Alice (US Manager), I want USD-denominated predictions for the US market",
"As Charlie (EU Manager), I want EUR-denominated predictions for the EU market",
"As CFO, I want prediction confidence intervals for budget planning",
],
"constraints": {
"data_latency": "Daily batch update by 6:00 AM",
"prediction_sla": "API response < 100ms p95",
"model_retraining": "Weekly automated retraining",
"compliance": "GDPR for EU user data",
},
"scope": {
"in_scope": ["3 market regions", "5 product categories", "Monthly & weekly predictions"],
"out_of_scope": ["Real-time per-order prediction", "Image-based product classification"],
},
}
出力:
TEXT
📖 参照専用
# Executed successfully
| 項目 | 定義 | SalesPredict の目標 |
|---|---|---|
| 主要指標 | モデルパフォーマンスの KPI | MAPE < 10% |
| ビジネス指標 | ビジネス価値の測定基準 | 在庫コスト20%削減 |
| SLA | サービスレベル合意 | API < 100ms p95 |
| データ鮮度 | データ更新頻度 | 日次バッチ |
| コンプライアンス | 法規制上の制約 | GDPR(EUデータ) |
4. データアーキテクチャ
(1) データソースとデータフロー
graph TB
ORDERS[Orders DB<br/>Transaction Data] --> ETL[ETL Pipeline<br/>Daily Batch]
USERS[User Profiles] --> ETL
PRODUCTS[Product Catalog] --> ETL
ADLOGS[Ad Platform Logs] --> ETL
ETL --> DATALAKE[Data Lake<br/>S3 / GCS]
DATALAKE --> FEATURE[Feature Store<br/>Engineered Features]
FEATURE --> TRAIN[Training Pipeline]
FEATURE --> SERVE[Serving Layer<br/>Online Features]
SERVE --> API[Prediction API]
▶ サンプル:データソース定義
PYTHON
data_sources = {
"orders": {
"source": "PostgreSQL (production DB)",
"fields": ["order_id", "user_id", "product_id", "amount_usd", "order_date", "category"],
"volume": "~500k rows/month",
"latency": "T+1 (next day available)",
},
"users": {
"source": "CRM System",
"fields": ["user_id", "region", "segment", "register_date", "lifetime_value"],
"volume": "~50k active users",
"latency": "T+1",
},
"ad_spend": {
"source": "Google Ads + Facebook Ads API",
"fields": ["date", "channel", "campaign", "spend_usd", "impressions", "clicks"],
"volume": "~10k rows/month",
"latency": "T+2",
},
"product_catalog": {
"source": "PIM System",
"fields": ["product_id", "category", "price_usd", "margin_pct", "launch_date"],
"volume": "~5k products",
"latency": "Weekly update",
},
}
出力:
TEXT
📖 参照専用
# Executed successfully
(2) 特徴量ストアの設計
| 特徴量グループ | 特徴量数 | 更新頻度 | ストレージ |
|---|---|---|---|
| RFM 特徴量 | 12 | 日次 | Parquet(オフライン)+ Redis(オンライン) |
| 広告特徴量 | 8 | 日次 | Parquet |
| 時間特徴量 | 6 | リアルタイム計算 | コードロジック |
| カテゴリ特徴量 | 5 | 週次ディメンションテーブル | Parquet |
| 集計統計量 | 10 | 日次 | Parquet |
5. モデルアーキテクチャ
(1) モデル進化ロードマップ
▶ サンプル:モデルアーキテクチャ定義
PYTHON
model_architecture = {
"stage_1_baseline": {
"model": "LinearRegression + Pipeline",
"expected_r2": "0.72-0.78",
"expected_mape": "12-15%",
"purpose": "Establish baseline, validate data pipeline",
"timeline": "Week 1-2",
},
"stage_2_advanced": {
"model": "XGBoost + Feature Engineering",
"expected_r2": "0.85-0.89",
"expected_mape": "8-10%",
"purpose": "Production model, meet MAPE < 10% target",
"timeline": "Week 3-5",
},
"stage_3_deep_learning": {
"model": "MLP / LSTM (time series)",
"expected_r2": "0.87-0.92",
"expected_mape": "7-9%",
"purpose": "Incremental improvement, capture temporal patterns",
"timeline": "Week 6-8",
},
}
出力:
TEXT
📖 参照専用
# Executed successfully
| ステージ | モデル | MAPE | 学習時間 | 優先度 |
|---|---|---|---|---|
| ステージ 1 | LinearRegression | 12-15% | 1分未満 | P0 |
| ステージ 2 | XGBoost | 8-10% | 約5分 | P0 |
| ステージ 3 | MLP/LSTM | 7-9% | 約30分 | P1 |
(2) 評価戦略
PYTHON
evaluation_strategy = {
"cv_method": "TimeSeriesSplit(n_splits=5)",
"primary_metric": "MAPE",
"secondary_metrics": ["MAE", "RMSE", "R2"],
"business_alignment": {
"MAPE_10pct": "Prediction error within 10% of actual revenue",
"MAE_50k": "Average absolute error less than 50k USD per category",
"cost_of_error": "1% MAPE ≈ 100k USD annual inventory waste",
},
"ab_testing": {
"duration": "3 weeks",
"metric": "Revenue prediction MAPE vs actuals",
"sample_size": "All categories, all markets",
},
}
6. デプロイアーキテクチャとチームの役割
(1) デプロイアーキテクチャ
graph TB
CLIENT[Client Apps] --> NGINX[Nginx Load Balancer]
NGINX --> API1[FastAPI Worker 1]
NGINX --> API2[FastAPI Worker 2]
API1 --> MODEL[MLflow Model Registry<br/>Production Model]
API2 --> MODEL
API1 --> REDIS[(Redis Cache)]
API2 --> REDIS
MODEL --> MLFLOW[MLflow Tracking<br/>Experiment History]
MLFLOW --> MONITOR[Monitoring Stack<br/>Prometheus + Grafana]
MONITOR --> ALERT[Alert Manager<br/>Drift Detection]
ALERT --> RETRAIN[Retraining Pipeline<br/>Airflow/Dagster]
RETRAIN --> MLFLOW
(2) チームの役割
▶ サンプル:リスク管理台帳
PYTHON
risk_register = {
"data_quality": {
"risk": "Raw data has >5% missing values in key features",
"probability": "High",
"impact": "Critical - model trained on biased data",
"mitigation": "Automated data quality checks in ETL pipeline",
"owner": "Alice",
},
"model_overfitting": {
"risk": "XGBoost overfits on small category samples",
"probability": "Medium",
"impact": "High - poor generalization to new markets",
"mitigation": "TimeSeriesSplit CV, regularization, early stopping",
"owner": "Bob",
},
"api_latency": {
"risk": "Prediction API exceeds 100ms SLA under load",
"probability": "Medium",
"impact": "Medium - user experience degradation",
"mitigation": "Redis cache for hot queries, Nginx rate limiting",
"owner": "Charlie",
},
}
出力:
TEXT
📖 参照専用
# Executed successfully
▶ サンプル:プロジェクトスケジュール
PYTHON
project_schedule = {
"Week 1-2: Data & Baseline": {
"Alice": "ETL pipeline, data lake setup, data quality checks",
"Bob": "EDA, feature engineering, LinearRegression baseline",
"Charlie": "Dev environment, MLflow setup, CI/CD pipeline",
},
"Week 3-5: Advanced Model": {
"Alice": "Feature store, online serving layer, data monitoring",
"Bob": "XGBoost training, hyperparameter tuning, model evaluation",
"Charlie": "FastAPI scaffold, Docker setup, load testing",
},
"Week 6-8: Deep Learning & Deploy": {
"Alice": "Real-time features, data drift detection",
"Bob": "MLP/LSTM experiments, A/B test design",
"Charlie": "Production deployment, monitoring dashboard, alerting",
},
"Week 9-10: Launch & Monitor": {
"Alice": "Data pipeline monitoring, feature validation",
"Bob": "Model monitoring, retraining pipeline",
"Charlie": "A/B test execution, gradual rollout, on-call setup",
},
}
出力:
TEXT
📖 参照専用
# Executed successfully
| 役割 | 担当者 | 責任範囲 | 成果物 |
|---|---|---|---|
| データエンジニアリング | Alice | ETL/データレイク/特徴量ストア | データパイプライン + 特徴量 |
| MLエンジニアリング | Bob | 特徴量エンジニアリング/モデル学習/評価 | 最適モデル + 実験ログ |
| バックエンド/DevOps | Charlie | API/デプロイ/モニタリング | 本番サービス + モニタリング |
❓ よくある質問
Q 要件分析はどの程度詳しく行うべきですか?
A 最低限、以下の4点を含めるべきです — 1) 定量化された KPI を伴う明確なビジネス目標;2) ユーザーストーリー(誰が何を使って何をするか);3) 制約条件(レイテンシ/コンプライアンス/予算);4) スコープの境界(対象範囲と対象外)。曖昧な要件は手戻りの最大の原因です。
Q ベースラインモデルは本当に必要ですか?
A 絶対に必要です。ベースラインはパフォーマンスの下限を確立し、データパイプラインの妥当性を検証します。ベースラインがなければ、XGBoost の改善がモデル由来なのか、データパイプラインの修正によるものなのかを判断できません。
Q チームは何人必要ですか?
A 機械学習プロジェクトには最低3人必要です — データ担当1名、ML担当1名、DevOps担当1名です。フルスタックの1人でも不可能ではありませんが、効率が落ち、知識の単一障害点が生じます。重要なのは人数ではなく、3つの役割がすべてカバーされていることです。
Q データとモデル、どちらを先に進めるべきですか?
A データが先です。汚いデータ + 良いモデル = 無意味な結果、です。最初の1〜2週間は信頼性の高いデータパイプラインの構築に費やし、その後にモデルを学習させましょう。データの問題は早期に発見するほど、修正コストが低くなります。
Q 設計フェーズにはどのくらいの期間をかけるべきですか?
A プロジェクト全体の約10〜15%が目安です。8週間のプロジェクトであれば、設計に1週間かけるのは妥当です。設計不足による手戻りのコストは、設計に追加で1週間かけるコストを遥かに上回ります。
Q 設計が実際に実行されることをどう担保しますか?
A 設計文書には以下を含めるべきです — 1) 明確な成果物と受け入れ基準;2) コードテンプレート/スキャフォールディング;3) テスト戦略;4) マイルストーンチェックポイント。各マイルストーンで設計が正しく実行されていることを検証します。
📖 まとめ
- 要件分析の3本柱:定量化された目標(MAPE < 10%)、ユーザーストーリー、制約条件(レイテンシ/コンプライアンス)
- データアーキテクチャ:データソース → ETL → データレイク → 特徴量ストア → 学習用とサービング用の2系統
- モデルアーキテクチャの進化:LinearRegression(ベースライン)→ XGBoost(主力モデル)→ MLP/LSTM(漸進的改善)
- デプロイアーキテクチャ:FastAPI + Redis キャッシュ + Nginx ロードバランシング + MLflow モデル管理 + Prometheus モニタリング
- チームの役割:Alice(データエンジニアリング)+ Bob(MLエンジニアリング)+ Charlie(DevOps)の3職種による連携
- 設計を先行させ、開発中の手戻りゼロを実現 — 設計に10%の時間をかけることで50%の手戻りを回避
📝 練習問題
- 基礎(難易度 ⭐):自分の機械学習プロジェクトの要件定義書を作成してください。ビジネス目標、成功指標、スコープの境界を含めること。ヒント:第3章の要件定義書テンプレートを参考にしてください。
- 応用(難易度 ⭐⭐):SalesPredict の完全なデータアーキテクチャ図(Mermaid)を描き、すべてのデータソース、ETLステップ、ストレージ方式を明示してください。ヒント:第4章のデータアーキテクチャ図を参考にしてください。
- 挑戦(難易度 ⭐⭐⭐):機械学習プロジェクトをエンドツーエンドで設計してください — 要件 → データ → モデル → デプロイ → モニタリング → チーム — そして実行可能なプロジェクト計画(タイムラインと成果物を含む)を作成してください。ヒント:第3〜6章のすべての設計要素を組み合わせてください。