Machine Learning: プロジェクト設計 — SalesPredict エンドツーエンド計画ガイド

最終更新:2026-08-26

始まりが良ければ半ば成功 — システム設計がプロジェクトの成否を分けます。構築を始める前に、まず青写真を描きましょう。

1. 学べること


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) データソースとデータフロー

100%
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) デプロイアーキテクチャ

100%
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) マイルストーンチェックポイント。各マイルストーンで設計が正しく実行されていることを検証します。

📖 まとめ


📝 練習問題

  1. 基礎(難易度 ⭐):自分の機械学習プロジェクトの要件定義書を作成してください。ビジネス目標、成功指標、スコープの境界を含めること。ヒント:第3章の要件定義書テンプレートを参考にしてください。
  2. 応用(難易度 ⭐⭐):SalesPredict の完全なデータアーキテクチャ図(Mermaid)を描き、すべてのデータソース、ETLステップ、ストレージ方式を明示してください。ヒント:第4章のデータアーキテクチャ図を参考にしてください。
  3. 挑戦(難易度 ⭐⭐⭐):機械学習プロジェクトをエンドツーエンドで設計してください — 要件 → データ → モデル → デプロイ → モニタリング → チーム — そして実行可能なプロジェクト計画(タイムラインと成果物を含む)を作成してください。ヒント:第3〜6章のすべての設計要素を組み合わせてください。

← 前へ:本番環境のモニタリングとモデルドリフト | 次へ:プロジェクト開発 →

Web-Tutorial.com

Web-Tutorial 技術チーム

複数の開発者によって共同維持されているプログラミングチュートリアルプラットフォーム。各チュートリアルは専門分野の開発者が執筆・レビューしています。正確で信頼性の高いコンテンツを目指しています — 問題を見つけた場合はお知らせください。

100%