0.はじめに
こんにちは。今回は、AWSが提供する「Machine Learning Lens（ML Lens）」を実際のMLシステム設計に適用し、設計内容をレビューしてみた際の気づきを整理します。
詳細な設計レビュー内容はブログ公開できないですが、MLシステムを作るうえでLensとはなにか？それを使って何が気づけたかをまとめることで活用しやすくなることを狙っています。
1. AWS Machine Learning Lensとは？
以下の引用を私なりに解釈したものを整理しています。また図なども引用させてもらいました。Machine Learning Lens
そもそも、AWSにはAWS Well-Architected Frameworkという6つの柱（設計原則）があります：
- 運用上の優秀性（Operational Excellence）
- セキュリティ（Security）
- 信頼性（Reliability）
- パフォーマンス効率（Performance Efficiency）
- コスト最適化（Cost Optimization）
- 持続可能性（Sustainability）
これらをMLシステムに適用するためのレンズが「Machine Learning Lens」と解釈しています。Lensでは、MLシステムのライフサイクルに沿った6つのステージが定義されており、それらがライフサイクルとなっていると表現されています。
やや抽象的ですが、つまり各ステージごとに設計原則を意識して検討しようねってことと解釈しています。
ステージ：
- Business goal identification（ビジネスゴールの特定）
- ML problem framing（機械学習問題の定義）
- Data processing（データ処理）
- Model development（モデル開発）
- Deployment（デプロイ）
- Monitoring（モニタリング）
Lifecycle architecture（ライフサイクルアーキテクチャ全体像）
それぞれのステージにおいて考慮すべきベストプラクティスが整理されています。以下の図がわかりやすいかと思いますが、各ステージに対して以下のように設計原則に倣って検討ポイントが整理されています。
つまり膨大な観点があります。
具体的には、ステージ6個に対して、設計原則が6個、以下のように1ステージ、1設計原則で複数の項目があることから、全量105個(2025.7.1現在)の観点がありました。
ざっくり説明
詳細については記事を読むとより理解が深まります。以下は部分抜粋になります。
-
ビジネスゴールの特定
- MLOE-01: ビジネスニーズに沿ってML導入を検討し、適用領域（CV/NLP/強化学習など）ごとに人材育成を進めることが重要とされています
- MLOE-02: 分類、回帰、クラスタリングなど、アルゴリズムの選定前にタスクの種類を明確にして、説明ができる状態とする
-
MLSEC-01: MLライフサイクル全体を通して必要なすべてのソフトウェアとMLライブラリについて、プライバシー契約とライセンス契約を確認する必要がある
-MLPER-01: ビジネスステークホルダーからのガイダンスに基づき、ビジネスユースケースに関連する主要業績評価指標（KPI）を策定します。KPIはビジネス価値と直接結びつき、許容可能なモデルパフォーマンスを導き出す必要があります。
- ML問題定義
2. ML Lensを用いた設計レビュー結果（事例紹介）
以下は、AWS Machine Learning Lensを用いた設計レビューを実施し、満足している点と改善点を整理した事例となります。
✅ Business goal identification（ビジネスゴールの特定）
満足している点
- データ活用の背景・目的が明示されている
- 将来的なクラウド展開、マネージドサービス活用、運用自走化の方針が整理済
- データ提供元の業務的な目的と連携した設計方針を採用している
改善点
- ML導入によるKPI（精度・コスト削減など）の定量化が不足
- ただしPJ特性上定量化自体が難しかった
- ML導入の効果検証（ROI、業務指標との関連など）が明記されていない
- これも同様に設定が難しかった
✅ ML problem framing（機械学習問題の定義）
満足している点
- 検出器の構成を明確に整理している(SageMakerの活用)
- パイプライン構成情報を整理している(SageMaker Pipelinesの活用)
- 評価指標（mAP等）に基づくモデル検証を実装
改善点
- 暗号化に対する設計が弱い
- 内部向け利用ということもあり、設計が不十分
- モデル選定基準やトレードオフ（性能 vs リソース）に関する記述がない
- カスタムモデルも提供されているため、そことの比較をしてもよかった
✅ Data processing（データ処理）
満足している点
- データ前処理の機能群を押さえ、漏れなく基盤実装できていた
- S3, DynamoDB, ECS/Fargateなどモダンでスケーラブルな構成 参考
- ラベル管理がもれなく出来ている(項目策定という観点で)
改善点
- データ・正解ラベルのバージョン管理・更新履歴管理が不明確
- 特徴量加工の標準化・再利用設計の明文化が不足
- ともに運用周りの設計が弱い
✅ Model development（モデル開発）
満足している点
- トレーニングの項目がもれなく検討されている 参考
- SageMaker Pipelines＋Experiments＋Registryによる構成で管理されている
- 評価のプロセスも問題なく実装できている 参考
- 推論時のインスタンスタイプ最適化ができている
改善点
- レポート化などダッシュボード以上の可視化が弱く、監査関係が対応できていない
- 分散学習まで手が回らずできていない
- 転移学習時のフローの整備が弱い
✅ Deployment（デプロイ）
満足している点
- CodePipeline＋ECRの構成で管理
- 展開時のメトリクス監視機能の導入
改善点
- シャドーデプロイ、A/Bテストなどリリース戦略の設計がない
- ハードウェアレイヤ(SageMakerNeo)の検討がされていない
- 推論エンドポイント化する設計思想が考慮されていない
- SageMakerの場合、モデルをサーバに配置するサービングも選択できうる
✅ Monitoring（モニタリング）
満足している点
- 監視データをデータベースに集約し、Kibana/Grafanaダッシュボードで可視化
- Mlflowなどの実験管理ツールでの可視化も実装
- 統計量収集や推論頻度などモニタリング単位も網羅
- 再学習のためのデータモニタリング、タグ管理なども実装
改善点
- ドリフト検知の閾値・アラート設定が未明確、再訓練指標が設定できていない
- アクセス者のポリシー最適化が不十分(最小権限にできていない)
- コスト監視はできているが、閾値や運用ルールが弱い
3. まとめ
AWS Machine Learning Lensは、単なるインフラ設計だけでなく、MLワークロードの価値創出や運用性、効率、セキュリティまで網羅的に見直すきっかけをくれます。
特にビジネス観点やデータサイエンスの観点では私自身がインフラエンジニアであったこともあり、検討における気づきを得ることができました。また、手薄であった運用周りは改善の余地が多分にあることも気づきとなりました。
MLシステムに関わる方は、ぜひ一度一読したうえで、自身のアーキテクチャにもLensを当ててみてください。