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現在)の観点がありました。
Lensの説明
| フェーズ名（日本語） | ID | タイトル（日本語翻訳） | 要点 | リンク |
|---|---|---|---|---|
| ビジネス目標定義フェーズ | MLOE-01 | 責任感とエンパワーメントを備えた適切なスキルを開発する | ML技術の複雑さに対応できる専門人材を採用・育成し、継続的なスキル研修を行う。またチームに責任と権限を与えてモチベーションを高める。モデルにはバイアスが入り得るため、組織全体でAIの倫理的な活用（公平性の確保など）を推進・徹底する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-01.html |
| ビジネス目標定義フェーズ | MLOE-02 | モデルの説明可能性レベルの合意 | 利用ケースに応じて必要なモデルの説明可能性のレベルを事前にビジネス関係者と合意する。その基準を評価指標としてモデル開発全体でトレードオフ判断に用いる。説明可能性を高めれば予測の根拠を理解しやすくなり、監査対応や規制順守、利用者の信頼獲得につながる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-02.html |
| ビジネス目標定義フェーズ | MLOE-03 | モデルがビジネス要件に準拠しているかのモニタリング | モデルは時間とともにデータや環境の変化で劣化するため、定期的にモデルがビジネス要件を満たし続けているか監視する仕組みが必要。許容できない精度低下やドリフトが発生した場合に迅速に検知し対処（再学習・モデル更新、データ拡充など）できるよう、監視指標と対応計画を策定する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-03.html |
| ビジネス目標定義フェーズ | MLSEC-01 | MLに関わるデータ権限・プライバシー・ソフトウェアとライセンス条項の確認 | 機械学習で使用するデータやソフトウェアが適切な権利範囲内か確認する。データ利用に必要な許諾やプライバシー、オープンソースや商用ライセンスの条項をレビューし、組織の法務・セキュリティ方針に反しないことを保証する。また不適切なライセンスの制約がビジネス計画の妨げとならないよう事前に精査する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsec-01.html |
| ビジネス目標定義フェーズ | MLPER-01 | 重要なKPI（主要業績評価指標）の設定 | ビジネス関係者の意見をもとに、当該ビジネス用途に関連する主要な評価指標（KPI）を特定し設定する。KPIはビジネス価値に直結するものとし、モデルの許容最低精度や最大許容エラー率などビジネスが求める水準を定める。これによりモデルの性能目標を明確にし、結果の不確実性によるリスクを管理する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-01.html |
| ビジネス目標定義フェーズ | MLCOST-01 | 投資対効果（ROI）と機会費用の定義 | 機械学習を各ユースケースに適用する際のROI（費用対効果）と機会費用を評価・明確化する。長期的なリソース配分を見据え費用対効果の高い意思決定を行い、ML開発プロセスや必要リソースを事前に把握して将来のリスクや失敗を最小化する。プロジェクトが研究的性質か実装改善目的かを関係者間で合意し、タグ付け等でコストをプロジェクト別に追跡、データやエラーのコスト見積もり、費用便益モデルの策定・更新、リスク評価などを行う。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-01.html |
| ビジネス目標定義フェーズ | MLCOST-02 | マネージドサービスの活用によるTCO削減 | 従量課金型のAWSマネージドサービスを活用して、インフラ管理コストを削減する。Amazon SageMakerのようなマネージドMLサービスを使えば、自前でEC2やKubernetesを管理するよりも大幅に低いTCOでモデルの構築・学習・デプロイが可能。AWSの各種プリビルドAIサービスも組み合わせ、ML専門知識がなくても利用できる高機能APIで共通ユースケース（推薦、画像解析等）を低コストに実現する。また料金モデルを分析し、長時間稼働部分にはSavings Plansなど割引プランを適用してコスト最適化を図る。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-02.html |
| ビジネス目標定義フェーズ | MLSUS-01 | 全体的な環境影響や利点の定義 | ワークロードが組織のサステナビリティ目標にどの程度寄与するか、環境への影響を測定する。機械学習導入によるエネルギー消費や排出削減効果などを定量化し、持続可能性の観点からプロジェクトの価値を評価する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-01.html |
| 機械学習課題定義フェーズ | MLOE-04 | MLに関する役割と責任の確立 | 機械学習プロジェクトに関わる各チーム・担当者の役割、責任、相互連携を明確に定義する。MLプラットフォームは複数の専門領域（データエンジニア、データサイエンティスト、MLエンジニア、MLOpsエンジニア、ドメインエキスパート等）が協働して構築・運用するため、クロス機能チームを編成し、それぞれの担当範囲を決める。組織のビジネス目標達成に向け、各ロールが貢献すべき領域と責務を割り当て、適切なアクセス権限やツールを提供する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-04.html |
| 機械学習課題定義フェーズ | MLOE-05 | MLプロファイルテンプレートの準備 | MLライフサイクル各段階で作成される成果物の情報をまとめる「MLプロファイル」テンプレートを用意し、ワークロードの現状成熟度を評価して改善計画に役立てる。例えばデプロイ段階の項目として、モデルのインスタンスサイズ、更新頻度、デプロイ場所などをテンプレートに含め、各項目にしきい値を設定して成熟度をランク付けする。現状のプロファイルと将来目標のプロファイルを作成し、なぜその構成としたかの根拠を記録して、ビジネス要件を満たす判断を文書化する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-05.html |
| 機械学習課題定義フェーズ | MLOE-06 | モデル改善戦略の策定 | モデル開発に入る前に、モデルの性能を最適化するための改善策を計画しておく。性能向上のために検討すべき施策例として、データの追加収集、クロスバリデーションの実施、特徴量エンジニアリング手法の工夫、ハイパーパラメータのチューニング、アンサンブル手法の活用などがある。事前にこうした改善ドライバーを整理し、モデル開発プロセスで体系的に適用できるようにする。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-06.html |
| 機械学習課題定義フェーズ | MLOE-07 | ラインエージ追跡システムの構築 | リリースごとの変更内容（ドキュメント、環境設定、モデル、データ、コード、インフラなど）を追跡できる仕組みを整える。これにより以前のリリース時点の状態を再現して問題を検証でき、ロールバックや再現性の確保が容易になる。特に規制対応やガバナンス上、データとモデルの系譜（ラインエージ）管理は必須であり、SageMakerのラインエージ追跡機能等を活用して、データ準備からモデルデプロイまでのすべてのステップを記録・追跡する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-07.html |
| 機械学習課題定義フェーズ | MLOE-08 | MLライフサイクル全体でのフィードバックループ確立 | ML開発各段階（実験の成功例、失敗分析、運用上の経験）を共有するフィードバックメカニズムを構築し、次のイテレーションの継続的改善につなげる。モデルドリフトなどに応じて監視・再学習戦略を見直し、データ拡張やアルゴリズム変更など試行錯誤を重ねて最適な結果を追求する文化を醸成する。得られた知見はドキュメント化して組織のナレッジとし、プロセス全体の改善に活用する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-08.html |
| 機械学習課題定義フェーズ | MLOE-09 | 公平性と説明可能性のレビュー | MLライフサイクルの各段階でモデルの公平性と説明可能性に配慮したチェックを行う。例えば、課題定義時にはアルゴリズムが倫理的に問題ないか、データ収集時には訓練データが偏りなく様々な群を代表しているか、モデル開発時には目的関数に公平性制約を組み込む必要があるか、デプロイ時には訓練されていない集団へモデルを適用していないか、モニタリング時には特定ユーザ群に不平等な影響が出ていないか、といった観点で質問リストを作成し確認する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-09.html |
| 機械学習課題定義フェーズ | MLSEC-02 | データの暗号化とマスキング設計 | 個人情報など機密データの保護方法を検討する。フィールド単位の暗号化やデータマスキングを用いて、機械学習に利用する個人情報を保護する。実装にあたっては、特別な取り扱いが必要な属性（氏名、住所等のPII）の項目を洗い出し、これらに暗号化・難読化を適用すべきか監査し、必要なら実施する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsec-02.html |
| 機械学習課題定義フェーズ | MLREL-01 | モデル利用アプリからの変更影響をAPIで抽象化 | MLモデルを利用する他システムへの影響を最小限にするため、モデルはAPI経由で提供し、背後のモデル変更を透過的に行える設計とする。モデル更新時にも既存のサービスに中断や大規模修正を強いないよう、モデルのエンドポイントをAPI Gateway等で公開し、バージョン管理とドキュメント整備を徹底する。またAPI仕様変更時は関係システムに周知し、互換性を確保する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlrel-01.html |
| 機械学習課題定義フェーズ | MLREL-02 | 機械学習マイクロサービス戦略の採用 | 複雑な問題は一体の巨大モデルではなく複数のMLマイクロサービスに分割して解決する戦略を検討する。単一のモノリシックなシステムを避け、小規模なサービス群に機能を分散させれば、一部の障害が全体に波及しにくく、開発を並行化しやすい。AWS LambdaやAWS Fargate等で各モデルを独立デプロイし、必要時のみ実行する構成にすることで、スケーラビリティとメンテナンス性を向上しつつ信頼性を高める。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlrel-02.html |
| 機械学習課題定義フェーズ | MLPER-02 | 用途特化型AI/MLサービス・リソースの活用 | ワークロード全体または一部に、AWSの既存AIサービスや最適化済みMLリソースを利用できないか検討する。あらかじめチューニングされたマネージドサービスのコンポーネント（画像認識APIなど）を使えば、自前で構築するより効率良く高性能を実現できることが多い。ビジネス要件に合わせて自前モデルと既成サービスのバランスを取り、開発負荷を減らしつつ必要な精度を達成する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-02.html |
| 機械学習課題定義フェーズ | MLPER-03 | 適切な評価指標の定義 | モデルの性能を検証・監視するため、ビジネス目標フェーズで設定したKPIに紐づく評価指標を数値で定義する。これらの指標がビジネス側の誤差許容度を反映しているか検証し、必要に応じ調整する。例えば分類問題では適合率・再現率やF1スコア、回帰ではRMSE等、モデルの種類に応じた標準指標を設定し、ビジネス価値に即したカスタム指標も検討する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-03.html |
| 機械学習課題定義フェーズ | MLCOST-03 | 機械学習が適切な解決策かの見極め | 解決すべき課題に対し、単純なルールベース等のML以外の手法で十分対応できないか評価する。ML導入にかかるコストと、採用しない場合の機会損失を天秤にかけ、データサイエンティストの工数やモデル開発期間といったリソースも考慮する。まずは既存の簡易手法でベースライン性能を出し、Autopilot等で試験的にMLモデルを構築・比較するなど、ML採用の価値を検証してから本格導入を判断する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-03.html |
| 機械学習課題定義フェーズ | MLCOST-04 | カスタムモデル vs. 学習済みモデルのトレードオフ分析 | ゼロから自社モデルを構築する場合と既存の学習済みモデルを利用する場合のコスト・メリットを比較検討する。セキュリティや性能要件も踏まえつつ、データサイエンティストの作業工数や必要リソース費用と、AWSマーケットプレイスの学習済みモデルを導入して素早く低コストに機能提供できる利点を評価する。カスタムモデルはニーズに合わせ込みやすい反面開発コストが高く、既製モデルは迅速だが調整の自由度が低い場合があるため、JumpStart等も活用し最適な方針を決定する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-04.html |
| 機械学習課題定義フェーズ | MLSUS-02 | AIサービスおよび学習済みモデルの活用検討 | ワークロードを必ずしもカスタムモデルで開発する必要があるか見直す。API経由で利用できるマネージドAIサービスで代用可能なケースは多く、そうしたサービスを使えばデータ収集・学習・デプロイに伴う自前リソースを用意する必要がない。完全マネージドサービスが適合しない場合も、既存のデータセットやモデルを利用できないか評価し、学習済みモデルを微調整して流用することで、新規に大規模学習を行う際の計算資源消費を削減する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-02.html |
| 機械学習課題定義フェーズ | MLSUS-03 | 持続可能性を考慮したリージョン選択 | ワークロードをデプロイするAWSリージョンを選定する際、ビジネス要件とともに環境持続性の観点も考慮する。例えば再生可能エネルギー比率が高いリージョンやデータセンター効率の良いリージョンを選ぶことで、MLシステム運用による環境負荷を低減できる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-03.html |
| データ処理フェーズ | MLOE-10 | データのプロファイリングによる品質向上 | データセットの分布や統計値、型、パターンなどを事前に分析（プロファイリング）し、元データの内容と品質を評価する。不備のあるデータや外れ値は早期に検出してフィルタリング・修正し、モデル学習に使うデータの質を高める。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-10.html |
| データ処理フェーズ | MLOE-11 | トラッキングおよびバージョン管理機構の構築 | ML開発は試行錯誤が多いため、実験内容やモデルの変遷を記録・管理する仕組みを整える。データ・アルゴリズム・ハイパーパラメータの組合せと結果を全てログに残し、データ処理に関する知見や手順もドキュメント化してバージョン管理する。モデルはレジストリで登録・バージョン管理し、CI/CDでデプロイを自動化することで、将来の再利用や監査に備える。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-11.html |
| データ処理フェーズ | MLSEC-03 | 最小権限アクセスの徹底 | データ、アルゴリズム、コード、ハイパーパラメータ、モデル成果物、インフラなどMLライフサイクル全体のリソースに対し、必要最小限の権限のみを付与する原則を適用する。プロジェクトごとにネットワークやリソースを分離し、役割に応じてアクセス権を制限する。ユーザロールごとのアクセスパターンを定義し、AWS Organizationsとサービスコントロールポリシーでマルチアカウント環境を構築して、開発・テスト・本番を分離しデータ感度やコンプライアンス要件に応じたガバナンスを実施する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsec-03.html |
| データ処理フェーズ | MLSEC-04 | データおよびモデリング環境のセキュリティ確保 | データを保存・処理したりモデル開発を行う全ての環境を保護する。学習用データは暗号化されたストレージに保管し、データ前処理や分析はセキュアなクラウド環境内で実施する。モデル開発用のノートブック等にもIAM認証やネットワーク隔離を施し、不正アクセスを防止する。データ転送時にはTLS暗号化などを用い、静止中・転送中のデータを常に暗号化して機密性を維持する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsec-04.html |
| データ処理フェーズ | MLSEC-05 | 機密データのプライバシー保護 | 学習に使う機密データが漏洩しないよう対策する。まず機密データを特定・分類し、不要なら削除、必要ならマスキングやトークナイズ、PCAなどで匿名化する。機密データの扱いに関するガイドラインを整備し、再利用時の参考にする。Amazon Macie等を使えばS3内のPIIなどを自動検出できるので活用し、検出した機密データは暗号化や隔離保管するなど適切に取り扱う。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsec-05.html |
| データ処理フェーズ | MLSEC-06 | データラインエージの強制 | データの出所や変換履歴を常に追跡・記録し、データの系譜情報を厳格に管理する。アクセス制御や監査ログによりデータの流れを把握できる状態を維持し、必要に応じてどのデータからどんな処理を経て現在のデータになったか証明できるようにする。また訓練データに対して整合性チェックを実装し、データ欠損・破損・改ざんなどを検知して即対応できるようにする。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsec-06.html |
| データ処理フェーズ | MLSEC-07 | 関連データのみの保持 | 開発・テスト・本番といった環境ごとに、ユースケースに必要なデータだけを保管し不要なデータは持たないことで、データ漏洩リスクを下げる。データにライフサイクル管理を適用し、一定期間経過した古いデータや不要データは自動削除するようにする。またプライバシー観点からも、MLに不要な個人情報は事前に削除・マスクしておき、本当に必要なデータだけを扱う。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsec-07.html |
| データ処理フェーズ | MLREL-03 | データカタログの活用 | 複数のデータストアにまたがるデータも、データカタログ技術を用いて一元管理する。高度なデータカタログ（例：AWS Glue Data Catalog）を使えば、ETLプロセスと連携してデータがデータレイクやDWHへ投入される際のメタデータや変換履歴を追跡できる。このアプローチによりデータ処理がより信頼性・効率的になり、様々なデータソースを扱う際も可用性が向上する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlrel-03.html |
| データ処理フェーズ | MLREL-04 | データパイプラインの利用 | データの処理・移動・変換を自動化したデータパイプラインを構築し、手作業によるミスを防いで安定性を高める。SageMakerやGlue、Step Functions等でデータ前処理からモデル入力までの一連の処理をパイプライン化すれば、処理の再現性が確保され障害時のリカバリもしやすくなる。これによりデータ準備工程の信頼性と効率性が向上する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlrel-04.html |
| データ処理フェーズ | MLREL-05 | データ変更管理の自動化 | 訓練データの変更管理をバージョン管理システム等で自動化し、データセットの差分を追跡できるようにする。これにより、あるモデルを再現したい場合に当時使用した正確なデータバージョンを呼び出せるため、障害発生時のモデル復旧や監査が容易になる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlrel-05.html |
| データ処理フェーズ | MLPER-04 | 最新型のデータアーキテクチャの利用 | 急増するデータから最適な洞察を得るため、モダンなデータアーキテクチャを採用する。例えばデータレイク/レイクハウスアーキテクチャを構築してストレージと計算を分離・スケールさせることで、大規模データを効率的に処理できる。AWSのデータ分析基盤（S3、Glue、Athena等）を活用し、将来にわたり拡張可能で効率的なデータ処理環境を整備する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-04.html |
| データ処理フェーズ | MLCOST-05 | マネージドなデータラベリングの利用 | データへのラベル付けには、自動化機能とコスト効率の高い大規模人力ラベラーを提供するマネージドツール（例：Amazon SageMaker Ground Truth）を使う。これによりラベル品質を担保しつつ大量データのアノテーションを安価に行うことができ、必要なときに必要な分だけリソースを投入する柔軟性も得られる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-05.html |
| データ処理フェーズ | MLCOST-06 | データ変換の対話式分析ツール活用 | コーディングなしでデータの前処理や可視化を行えるデータワングラーツール（例：SageMaker Data WranglerやAWS Glue DataBrew）を利用し、対話的にデータをクレンジング・変換する。これにより開発者の手間を削減し、素早くデータ品質を高められるため、分析準備にかかるコストを削減できる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-06.html |
| データ処理フェーズ | MLCOST-07 | マネージドなデータ処理機能の利用 | データ処理やETLにはAWSのマネージドサービスを使い、インフラ管理コストを抑える。例えばAWS Glue（フルマネージドETL）やAmazon EMR（マネージドHadoop/Spark）を使えば、自前でサーバを構築するよりも低コストかつ確実にデータ処理が実行できる。サーバーレスサービスを活用することでリソースの稼働時間を必要最低限にし、TCOを下げる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-07.html |
| データ処理フェーズ | MLCOST-08 | 特徴量の再利用性の確保 | 一度作成した特徴量を複数のモデルやチームで共有・再利用できるようにする。特徴量ストアなどを導入し、特徴量計算結果を蓄積・提供すれば、各プロジェクトで同じ特徴量を重複して計算する必要がなくなる。これにより前処理工数と計算コストを削減し、組織全体の開発効率を高める。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-08.html |
| データ処理フェーズ | MLSUS-04 | アイドルリソースの最小化 | データ処理パイプラインにはサーバーレスやマネージドサービスを採用し、作業が必要なときだけリソースがプロビジョンされるようにする。そうすることで未使用時にサーバを動かし続ける無駄をなくし、エネルギー消費と環境負荷を低減できる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-04.html |
| データ処理フェーズ | MLSUS-05 | サステナビリティ目標に沿ったデータライフサイクル策定 | データ保持に関するポリシーを環境持続性の観点から制定・実行する。不要になったデータは一定期間後に自動アーカイブや削除を行い、長期保存が必要なデータもストレージクラスを変更して消費エネルギーを抑えるなど、データのライフサイクルを管理することで不要な資源消費を減らす。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-05.html |
| データ処理フェーズ | MLSUS-06 | 持続可能なストレージオプションの採用 | 環境負荷の小さいエネルギー効率の良いストレージを利用する。例えばアクセス頻度に応じてS3標準-IAやGlacierなど省電力なストレージクラスを選択し、不要な重複データや未圧縮データを減らす。オンプレから効率的なクラウドストレージへの移行も検討し、データ保存に伴うエネルギー消費を最小化する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-06.html |
| モデル開発フェーズ | MLOE-12 | MLOpsとCI/CDによる運用自動化 | モデルの構築・学習・テスト・デプロイといった一連の工程をMLOpsとCI/CDパイプラインで自動化し、人為的ミスを減らして反復開発を高速化する。自動ビルド・自動テスト・自動デプロイの仕組みにより、コードやデータの更新が円滑に本番環境へ反映され、継続的な機能改善が可能になる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-12.html |
| モデル開発フェーズ | MLOE-13 | 公認ライブラリ利用のためのパッケージ管理パターンの確立 | 外部公開ライブラリを使用する際には、信頼できる承認済みバージョンのみを利用できるようパッケージ管理の仕組みを整える。例えば、社内で検証済みのライブラリを含むコンテナイメージやリポジトリを用意し、開発者がそれを基に環境を構築するようにする。これにより依存ライブラリのばらつきを防ぎ、モデルの再現性とセキュリティを確保する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-13.html |
| モデル開発フェーズ | MLSEC-08 | ガバナンス対応のML環境セキュリティ確保 | 組織のセキュリティ・ガバナンス基準を満たすML開発環境を構築する。例えばSageMaker Studioなどの開発環境をプライベートサブネットに配置し、インターネットアクセスを制限する。アクセスはSSOやMFAで保護し、操作ログをすべて記録して監査可能にする。さらに、環境内のリソースに統一したタグ付けや命名規則を適用し、資産の追跡や権限管理が徹底された統制されたMLプラットフォームを維持する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsec-08.html |
| モデル開発フェーズ | MLSEC-09 | クラスター内ノード間通信のセキュリティ | 分散学習用クラスタなど複数ノードでモデル学習を行う場合、ノード間の通信を保護する。クラスタ内通信は可能な限りプライベートネットワーク上で行い、必要に応じてTLS等で暗号化してデータが盗聴・改ざんされないようにする。またノード間の認証・認可を適切に設定し、信頼できるノード間でのみデータ交換が行われるようにする。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsec-09.html |
| モデル開発フェーズ | MLSEC-10 | データポイズニング攻撃への対策 | モデルの訓練データに悪意ある改ざんや有害なデータが混入される「データポイズニング」攻撃を防ぐ措置を講じる。訓練データ投入前にデータの検証と異常値検出を行い、不自然なパターンや極端な外れ値が含まれていれば除去・修正する。データの出所を複数に分散し、一つのデータソースに依存しないことで、特定ソースへの攻撃の影響を軽減する。またモデル訓練中・後にモデルのロバスト性を評価し、ポイズニングに強いモデルを選択・構築する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsec-10.html |
| モデル開発フェーズ | MLREL-06 | トレーサビリティを備えたCI/CD/CT自動化 | コードの継続的インテグレーション（CI）、モデルの継続的デプロイ（CD）、継続的トレーニング（CT）を自動化し、それぞれのプロセスに追跡可能性を持たせる。新データ到着やコード更新時に自動で再学習・モデル評価・デプロイが実行され、その際使用したデータバージョンやハイパーパラメータなどを記録する。これによりモデルの再現性と変更管理が向上し、信頼性の高いML運用を実現する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlrel-06.html |
| モデル開発フェーズ | MLREL-07 | 学習と推論での特徴量一貫性の確保 | モデルの学習時に適用した特徴量処理を、本番推論時にも同一の方法で適用し、データのズレ（スキュー）を防ぐ。例えば学習時に使用した正規化やエンコーディングの手順・パラメータを保存し、推論システムで再利用する。特徴量ストアを活用し同じ特徴量を訓練・推論で共有するなど、前処理ロジックの一貫性を担保してモデル性能を安定させる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlrel-07.html |
| モデル開発フェーズ | MLREL-08 | 適切なデータでのモデルバリデーション | モデルをリリースする前に、本番環境で遭遇しうるデータを用いてモデルを検証する。検証データは代表性のある最新データで構成し、モデルが求められる精度を満たすか評価する。可能であれば複数のサブグループやシナリオ別にテストして、公平性や偏りもチェックする。これにより、不十分なモデルが本番投入されるのを防ぎ、信頼性を高める。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlrel-08.html |
| モデル開発フェーズ | MLREL-09 | データバイアスの検知と緩和策の実施 | モデル学習に用いるデータやモデル予測に偏りが含まれていないか検出し、必要に応じて緩和策を講じる。SageMaker Clarifyなどでデータセットやモデルの公平性指標を測定し、特定の属性に対する予測バイアスを確認する。偏りが見つかれば、データのリバランスやアルゴリズムの調整、コスト関数に公平性制約を加えるなどしてバイアスを軽減し、公平で説明可能なモデルを目指す。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlrel-09.html |
| モデル開発フェーズ | MLPER-05 | 学習・推論インスタンスの最適化 | モデルのトレーニングや推論に使うインスタンス種類とサイズを最適化する。モデル規模や負荷に見合ったインスタンスタイプを選定し、必要以上に高性能・高コストなマシンの使用を避ける。GPUが必要な場合はその利用を最小限にし、小規模な推論には小さいインスタンスやAWS Inferentiaなど専用チップを使うなど、リソースを適材適所で割り当て、性能とコストのバランスを取る。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-05.html |
| モデル開発フェーズ | MLPER-06 | 性能改善のための代替手段の模索 | モデルの性能向上のため、多角的なアプローチを検討する。一つのアルゴリズムに固執せず、別のモデル手法や特徴量エンジニアリング、アンサンブルの導入など複数の選択肢を試す。またハードウェア面でも分散学習やGPU最適化、精度と速度のトレードオフ検討（量子化・蒸留等）を行い、最適な性能を効率良く達成できるようにする。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-06.html |
| モデル開発フェーズ | MLPER-07 | モデル性能評価パイプラインの確立 | モデルの評価を自動化し、いつでも性能を把握できるようにする。学習後に検証データで各種評価指標（精度、再現率、AUCなど）を算出して記録し、モデルバージョン間で比較できるパイプラインを構築する。これにより性能劣化を見逃さず、継続的にモデル品質を監視できる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-07.html |
| モデル開発フェーズ | MLPER-08 | 特徴量統計量の確立 | モデルが使用する各特徴量について統計情報（平均・分散・分布など）を算出し、保存しておく。訓練時の特徴量統計と新データの特徴量を比較してデータドリフトを検知したり、特徴量の相関・重要度を分析してモデル解釈に役立てる。特徴量ごとのベースラインを持つことで、データ品質やモデル挙動の変化に早期に気付けるようになる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-08.html |
| モデル開発フェーズ | MLPER-09 | 性能トレードオフ分析の実施 | モデルの複数の性能指標間のトレードオフ関係を評価する。例えば精度向上のためにモデルが大型化すると推論遅延やコストが増大する、といった関係を分析し、ビジネス要件に見合ったバランス点を決める。必要に応じて若干の精度低下を許容してでも簡素で高速なモデルを採用するなど、モデル性能とリソース効率の最適点を見極める。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-09.html |
| モデル開発フェーズ | MLPER-10 | 転移学習時の性能問題検出 | 転移学習を利用する際、元モデルからの微調整で生じうる性能上の問題に注意する。微調整後のモデルを検証データで評価し、特定のクラスで精度が著しく悪化していないか、学習済み層と新規層の調整が適切かを確認する。転移学習導入により過学習や予期せぬ挙動が発生していないか監視し、問題があれば学習率の調整や層の固定範囲見直し等で対処する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-10.html |
| モデル開発フェーズ | MLCOST-09 | 最適なインスタンスサイズの選択 | トレーニングに用いるインスタンスのサイズを適切に選ぶ。小さすぎると学習時間が延びコスト増になるが、大きすぎるとリソースが遊休状態となり無駄が出る。モデルとデータ規模に合ったインスタンスを選定し、スケールアウトで対応できる場合は中型インスタンス複数台で効率化するなど、コスト最適なサイズを検討する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-09.html |
| モデル開発フェーズ | MLCOST-10 | マネージドなビルド環境の利用 | 環境構築やパッケージ管理に時間をかけず、AWSのマネージドビルド環境を活用して開発効率とコスト効率を上げる。例えばAmazon SageMakerのビルトインコンテナやAWS CodeBuildを使えば、ライブラリ依存やコンパイル環境をAWS側で管理してくれるため、開発者はモデル実装に集中できる。これにより環境トラブルによる時間ロスを減らし、人的コストを削減する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-10.html |
| モデル開発フェーズ | MLCOST-11 | 小規模実験のローカル学習活用 | データ規模が小さい初期実験段階では、自分のPCや小型インスタンス上でローカルにモデル学習を行い、大規模リソースの利用を控える。SageMakerのローカルトレーニングモード等を使えば、クラウドインスタンスを起動せずにコードやモデルのプロトタイプ検証が可能となる。まず低コスト環境でモデルを検証し、有望であれば大規模リソースに切り替えることで計算資源を無駄遣いしない。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-11.html |
| モデル開発フェーズ | MLCOST-12 | 最適なMLフレームワークの選択 | 問題領域やチームのスキルセットに合った機械学習フレームワークを選ぶ。必要以上に重厚なフレームワークは避け、例えばシンプルな予測にはscikit-learn、ディープラーニングが必要ならPyTorchやTensorFlowなど適切なものを使用する。学習曲線やコミュニティサポートも考慮し、生産性高く開発できるフレームワークを選択することで余分な時間・コストを省く。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-12.html |
| モデル開発フェーズ | MLCOST-13 | オートメーテッドML（AutoML）の活用 | モデル開発にAutoMLを導入して自動化し、コスト削減につなげる。SageMaker Autopilot等を用いれば、アルゴリズム選定やハイパーパラメータ調整を自動で多数試行し、最適モデルを見つけられる。これによりデータサイエンティストの試行錯誤時間を短縮し、計算リソースも効率的に使うことができる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-13.html |
| モデル開発フェーズ | MLCOST-14 | マネージドなトレーニング機能の利用 | モデル訓練にはAmazon SageMakerのようなマネージドトレーニングを使い、分散学習やハードウェア管理をサービスに任せる。必要なときだけコンピューティングリソースを起動し、ジョブ完了後は自動停止するため無駄がない。スポットインスタンスも簡単に利用でき、コストを最大90%削減することも可能。インフラ管理工数が減り、人件費面でも効率が上がる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-14.html |
| モデル開発フェーズ | MLCOST-15 | 分散学習の活用 | モデル訓練を複数マシンに分散して行い、学習時間短縮とコスト最適化を図る。HorovodやSageMakerの分散トレーニングを用いてスケールアウトすれば、一台の大型インスタンスで長時間学習するよりも短時間で結果を得られるため、インスタンス稼働時間の総量を減らせる。時間短縮により新しい実験をより多く実施でき、全体としてコスト効率が向上する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-15.html |
| モデル開発フェーズ | MLCOST-16 | 未使用時リソースの停止 | 開発や訓練で使ったリソースは使い終わったら速やかに停止・削除する。ノートブックインスタンスや学習ジョブ用インスタンスがアイドル状態で放置されないよう、タイマーによる自動停止やジョブ完了後のクリーンアップを設定する。これにより不要な課金を防ぎ、クラウドリソース費用を最小限に抑えられる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-16.html |
| モデル開発フェーズ | MLCOST-17 | 小規模データセットでの学習開始 | 最初から全データで学習を行わず、小さなサンプルデータでモデルを動かしてみて問題点を洗い出す。サンプルでパイプラインやモデルの不備を修正してから本格的な全量学習に移行することで、大規模データで無駄な計算をするリスクを減らす。これにより初期検証コストを低く抑え、効率良く開発を進められる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-17.html |
| モデル開発フェーズ | MLCOST-18 | ウォームスタートとチェックポイントの活用 | ハイパーパラメータチューニングにおいて、過去の結果や途中結果を活かして効率化する。ウォームスタートを使い以前のベストモデルや経験を初期値にすれば検索範囲を絞れる。長時間かかる実験は途中でモデル状態をチェックポイント保存し、中断後に再開可能にすることで、計算のやり直しを減らす。これらによりチューニングにかかる時間と計算コストを削減する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-18.html |
| モデル開発フェーズ | MLCOST-19 | ハイパーパラメータ最適化技術の利用 | ハイパーパラメータ探索にはベイズ最適化など高度な最適化手法を活用し、より少ない試行で最適値を見つける。SageMakerの自動調整機能を使えば非効率な全探索よりも迅速に良い組み合わせを発見できる。多腕バンディットアルゴリズム等で劣る試行を早期停止することで無駄な計算を省き、結果としてリソース使用量とコストを抑える。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-19.html |
| モデル開発フェーズ | MLCOST-20 | 予算設定とタグによるコスト追跡 | MLプロジェクトごとに予算を設定し、AWS Budgetsでコストアラートを構成する。また全リソースにプロジェクトやチーム名などのタグを付与してコストを分類し、Cost Explorerで誰がどれだけ費用を使っているか可視化する。これによりコストの使いすぎを早期に検知でき、どの部分のML作業がコスト増の原因か把握して改善につなげられる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-20.html |
| モデル開発フェーズ | MLCOST-21 | データと計算の近接性の確保 | データの所在地に近い場所でモデルの訓練や処理を行い、余分なデータ転送コストを減らす。例えばデータが保存されているリージョン内で学習用インスタンスを起動し、大量のデータを別リージョンに送らずに済むようにする。データレイクと計算クラスターを同一リージョン・AZに配置することで、ネットワークコストと待ち時間を削減し効率化を図る。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-21.html |
| モデル開発フェーズ | MLCOST-22 | 最適なアルゴリズムの選択 | 問題に対して計算効率の良いアルゴリズムを選ぶことで無駄なリソース消費を抑える。例えば大規模データには線形モデルや分散アルゴリズムを検討し、Deep Learningが不要な場合はより軽量な方法で代替する。AWSの組み込みアルゴリズム（XGBoostやLinear Learner等）は高速でスケーラブルなので活用し、必要以上に複雑な手法を避けてコストを最適化する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-22.html |
| モデル開発フェーズ | MLCOST-23 | デバッグとログの有効化 | モデル学習中の問題をすぐ発見できるよう、デバッガーと詳細ログを有効にしておく。SageMaker Debuggerで学習指標をリアルタイムにモニタし、学習が発散した場合は直ちにジョブを停止する。また推論時もログを取り、エラー発生時に原因を迅速に突き止められるようにする。これらにより不具合修正にかかる時間を減らし、結果的に余計な再実行コストを削減できる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-23.html |
| モデル開発フェーズ | MLSUS-07 | 持続可能な性能基準の設定 | モデルに関して環境への影響も考慮した性能目標を設定する。例えば「推論1回あたりの消費エネルギーをXジュール以下」や「モデルサイズをY MB以内」といった基準を設け、精度や速度と環境負荷のバランスを取る。ビジネス要件を満たしつつ電力消費や炭素排出を抑える性能指標を策定し、開発の指針とする。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-07.html |
| モデル開発フェーズ | MLSUS-08 | 省エネ型アルゴリズムの選択 | 同等のタスクを達成できるなら、計算量が少なくエネルギー効率の高いモデルやアルゴリズムを選ぶ。巨大なニューラルネットを使わず決定木などで十分な場合はそちらを使う、CNNもMobileNetのような軽量版を採用するなど、必要以上にリソース消費の大きい手法は避ける。効率的なアルゴリズム選定により計算負荷を減らし、環境への影響も低減する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-08.html |
| モデル開発フェーズ | MLSUS-09 | 不要な学習生成物のアーカイブ/削除 | モデル学習で生成される中間モデルや古いモデルファイル、ログなど、今後使わない成果物は定期的に削除または低コストの場所へアーカイブする。保存データ量を削減することでストレージリソースの無駄遣いを防ぎ、データセンターのエネルギー消費を抑える。必要な成果物だけを保持する方針を立てて実行し、持続可能性に寄与する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-09.html |
| モデル開発フェーズ | MLSUS-10 | 効率的なモデルチューニング方法の使用 | モデルのハイパーパラメータ調整において、省資源な方法を取り入れる。例えばHyperbandなどで効果の低い試行を早期終了したり、ニューラルアーキテクチャ探索では計算コストの低い代理モデルを使うなどして、探索にかかる計算量を減らす。効率的なチューニングにより電力消費を抑え、環境への負荷軽減を図る。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-10.html |
| モデルデプロイフェーズ | MLOE-14 | デプロイ環境のメトリクス設定 | 本番デプロイしたモデルの稼働環境について、監視すべきメトリクスを設定する。具体的には推論レイテンシやスループット、エラー率、CPU/GPU使用率などを継続的に計測し、閾値を定めてSLAを維持できているか確認する。メトリクスに異常が出た場合は自動通知やスケーリングなどの対処ができるようにし、モデルサービスの安定運用に役立てる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-14.html |
| モデルデプロイフェーズ | MLSEC-11 | 敵対的・悪意ある行為への防御 | モデルの推論APIやデータが攻撃対象にならないように対策する。入力に対しては異常検知を行い、敵対的サンプル（対策のないモデルを欺く入力）を検出してブロックする。推論エンドポイントへのアクセスは認証とレート制限を実施し、過剰なリクエストやパターン異常を検知したら遮断・通知する。モデル出力から推論される機密情報が漏れないようフィルタリングするなど、多層的にモデルとデータを保護する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsec-11.html |
| モデルデプロイフェーズ | MLREL-10 | エンドポイント変更のパイプライン自動化 | モデルエンドポイントの更新（新モデルへの切替）を、自動化されたパイプラインで実施する。モデルのビルドからデプロイまでCI/CDに組み込み、人手ではなく自動手順でBlue/Greenデプロイやカナリアリリースを行うことで、更新時のヒューマンエラーを防ぎ、ダウンタイムを最小化できる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlrel-10.html |
| モデルデプロイフェーズ | MLREL-11 | 適切なデプロイ・テスト戦略の採用 | 本番環境へのモデル展開時には、リスクに応じたテスト・リリース戦略を用いる。たとえば少数のトラフィックで新旧モデルの結果を比較するカナリアテストや、影響を与えない形で新モデルを並行稼働させて結果を検証するシャドーデプロイを実施する。十分な評価を経てから全トラフィックを新モデルに切り替えることで、問題発生時も迅速に旧モデルに戻せる体制を整える。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlrel-11.html |
| モデルデプロイフェーズ | MLPER-11 | クラウド vs エッジでのMLデプロイ評価 | モデルをクラウドにデプロイするか、エッジ（デバイス側）に埋め込むか検討する。低レイテンシが求められネットワーク遅延を避けたい場合やデータ制約がある場合はエッジ推論が有利で、一方で頻繁なモデル更新や大きな計算資源が必要な場合はクラウドデプロイが適している。ユースケースの要求（応答速度、帯域、オフライン要件など）に合わせ、クラウドとエッジのどちらが最適か評価して選択する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-11.html |
| モデルデプロイフェーズ | MLPER-12 | クラウド内の最適なデプロイオプション選択 | クラウド上でモデルをデプロイする際に、多様なオプションから要件に合うものを選ぶ。リアルタイムAPIが必要ならSageMakerエンドポイントやAWS Lambda、バッチ推論ならSageMaker Batch Transform、大規模並列推論にはAWS Inferentia搭載インスタンスなど、それぞれの方式の性能・コスト特性を比較して決定する。適切なデプロイ形態を選ぶことで、必要十分な性能を得つつコスト効率も最適化できる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-12.html |
| モデルデプロイフェーズ | MLCOST-24 | 適切なデプロイオプションの利用 | モデルの使用パターンに応じて、コスト効率の良いデプロイ方法を選択する。例えばリアルタイム推論が頻繁でなければバッチ処理でまとめて実行する、利用頻度の低いモデルは都度起動型のLambdaでホスティングする、一方、高頻度かつ低遅延要件なら専有インスタンスで常駐させるなど、ケースに応じた方式を採用する。これにより過剰なリソース常駐を避け、必要なときに必要なだけリソースを使う形でコストを抑える。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-24.html |
| モデルデプロイフェーズ | MLCOST-25 | コスト効果の高いハードウェアオプション検討 | 推論環境において、性能要件を満たしつつコストの安いハードウェアを検討する。例えばGPUを使わなくてもCPUで十分ならより安価なCPUインスタンスに切り替える、またはAWS Inferentiaのような低コスト高性能な専用チップを利用する。さらにはリザーブドインスタンスやSavings Plansを活用し、必要なハードウェアを割引価格で長期利用することでコスト効率を高める。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-25.html |
| モデルデプロイフェーズ | MLCOST-26 | ホスティングインスタンス群の適正規模化 | 本番ホスティングしているモデル用インスタンス群について、その台数やスペックが適正か定期的に見直す。普段のCPU・メモリ使用率やリクエスト量を分析し、明らかに過剰な余裕がある場合はインスタンス数を削減または小さいサイズに縮小する。逆に負荷が高くスケール不足なら一時的に手動スケールやより大きなインスタンス検討も行い、安定性とコストのバランスを最適化する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-26.html |
| モデルデプロイフェーズ | MLSUS-11 | SLAとサステナビリティ目標の整合 | サービスレベル目標（SLA）を決める際に、持続可能性目標も考慮に入れる。例えば可用性を極限まで高めるには多くの予備サーバが必要だが、それはエネルギー消費増につながる。ビジネス上許容できる範囲で可用性や性能目標を設定し、それに応じてリソースを配分することで、環境負荷とサービス品質のバランスを取る。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-11.html |
| モデルデプロイフェーズ | MLSUS-12 | 高効率シリコンの利用 | 推論環境にはエネルギー効率の高いプロセッサを採用する。AWS Gravitonなどの省電力CPUやAWS Inferentiaのような専用チップは、同じ処理を行うのに必要な電力を削減できる。これらへの移行により、モデル稼働時の電力消費とCO2排出量を減らし、サステナビリティに寄与する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-12.html |
| モデルデプロイフェーズ | MLSUS-13 | 推論向けモデルの最適化 | モデルをデプロイする前に、推論時の効率が上がるよう最適化する。蒸留による軽量モデル化やプルーニング・量子化でモデルサイズを縮小し、推論にかかる計算量とメモリを減らす。こうした最適化により必要インフラを小さくでき、エネルギー消費削減とコスト低減につながる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-13.html |
| モデルデプロイフェーズ | MLSUS-14 | 単一エンドポイントでの複数モデルデプロイ | 一つのエンドポイントサーバで複数のモデルをホストし、リソースの共有によってアイドル時間を減らす。モデル個別に専用インスタンスを立てるよりも、複数モデルを統合運用することでサーバ台数を削減し、エネルギーとコストの効率を向上できる。SageMakerのマルチモデルエンドポイント機能などを活用して実現する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-14.html |
| モデルモニタリングフェーズ | MLOE-15 | モデルの可観測性とトラッキングの有効化 | 本番モデルの挙動を詳細に監視できるようにする。入力データや予測結果、推論に要した時間、モデルの内部状態などをログ・メトリクスとして収集・可視化し、モデルの正常性を常にチェック可能にする。異常検知のアラートを設定し、問題発生時に即座に対応できる体制を整える。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-15.html |
| モデルモニタリングフェーズ | MLOE-16 | 環境間のアーキテクチャ/設定同期とスキュー確認 | 開発・テスト・本番など環境ごとにモデルのアーキテクチャや前処理構成が食い違わないよう整合性を取る。訓練環境での設定を本番推論環境に反映し、ソフトウェアバージョンやパラメータが一致しているか検証する。さらに、訓練データと本番データの統計比較などでデータスキューが生じていないか定期的に確認し、もし差異があれば原因を特定して解消する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mloe-16.html |
| モデルモニタリングフェーズ | MLSEC-12 | 正規の利用者へのみアクセス制限 | モデルの予測APIや結果データは、本来の想定ユーザやサービスだけがアクセスできるよう制限する。不特定多数に公開せず、IAM認証やネットワーク制御で消費者を限定する。例えば推論エンドポイントにVPCエンドポイント経由でのみアクセス可能とし、外部から直接呼び出せないようにする。これにより、データ漏洩や不正利用リスクを低減する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsec-12.html |
| モデルモニタリングフェーズ | MLSEC-13 | 人的データ操作の異常活動監視 | データに対する人間のアクセスや操作を監視し、不審な活動がないかチェックする。データラベラーや開発者が大量にデータをエクスポートする、深夜に繰り返し機密データにアクセスする等の通常と異なる行動が見られた場合にアラートを出す。CloudTrailやCloudWatch Logsでアクセスログを分析し、内部脅威や人的ミスによるデータ漏洩を未然に防ぐ。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsec-13.html |
| モデルモニタリングフェーズ | MLREL-12 | モデルエンドポイントの自動スケーリング許可 | 推論エンドポイントにAuto Scalingを導入し、負荷変動に応じて自動でインスタンス数を増減させる。これによりアクセス急増時にもスケールアウトで高い信頼性を確保し、逆に需要減少時にはスケールインでリソース無駄を省ける。自動スケーリング設定により、モデルサービスの可用性とコスト効率を両立する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlrel-12.html |
| モデルモニタリングフェーズ | MLREL-13 | バージョン管理戦略による復元可能なエンドポイント | 本番エンドポイントにデプロイするモデルは常にバージョン管理し、問題発生時に以前の安定版に即座に戻せるようにする。Blue/Greenデプロイ等を活用して旧バージョンをしばらく残しておき、必要に応じリクエストのルーティングを切り戻せる設計にする。またエンドポイント設定自体もコード管理し、万一の環境障害時も再現可能として信頼性を高める。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlrel-13.html |
| モデルモニタリングフェーズ | MLPER-13 | モデルの説明可能性評価 | 運用中もモデルの予測理由を評価し、説明可能性を監視する。SHAP値などで出力に対する各特徴量の寄与度を定期的に算出し、人間が納得できる形でモデルが動作しているか確認する。もし重要特徴量が変化していたり説明不能な予測が増えた場合、データやモデルに変化が生じた可能性があるため、原因を調査しモデル改善に活かす。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-13.html |
| モデルモニタリングフェーズ | MLPER-14 | データドリフトの評価 | 本番で入力されるデータが訓練時と比べて変化していないか（データドリフト）を評価する。例えば特徴量分布の平均や標準偏差を時間経過で追跡し、統計的に有意な変化が起きていれば通知する。ドリフトが確認された場合、モデルの再学習や特徴量更新の必要性を判断する材料とし、モデル性能維持に努める。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-14.html |
| モデルモニタリングフェーズ | MLPER-15 | モデル性能劣化の監視・検知と対応 | モデルの予測精度が時間とともに低下していないか継続監視し、劣化を検知したら対策を講じる。予測と実際の差分をモニタリングし、あらかじめ定めた閾値を下回るパフォーマンスになった場合にアラートを発する。性能劣化が判明したら、新しいデータでモデルを再訓練するか、モデル構造を変更するといった対応を速やかに行い、ビジネス影響を最小限に抑える。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-15.html |
| モデルモニタリングフェーズ | MLPER-16 | 自動再学習フレームワークの確立 | モデルの再トレーニングを自動で行う仕組みを構築する。例えばモデルモニタリングでドリフトや精度低下を検知した際に、自動的に新データで再学習ジョブを実行し、新モデルをテストした上で本番環境にデプロイするパイプラインを整える。これによりモデルが常に最新状態に保たれ、性能の継続的な維持・向上が図れる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-16.html |
| モデルモニタリングフェーズ | MLPER-17 | 再学習用データ/特徴量更新の検討 | モデルの再トレーニングを行う際、入力データや特徴量セットが最新か見直す。時間とともに新しいデータソースが利用可能になっていれば追加し、逆に不要になった特徴量は除去する。モデル再構築のたびにデータ前処理工程を点検し、より有用な特徴量を加えるか、意味の薄れた特徴量を削ることで、モデルを現状に適した状態にアップデートする。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-17.html |
| モデルモニタリングフェーズ | MLPER-18 | 人間参加型のモニタリング導入 | モデル運用に人間の監視やフィードバックを組み込む。自動モニタリングだけでなく、定期的に専門家がモデルの出力をレビューし、妥当性や倫理面をチェックする。またユーザからのフィードバックを収集し、モデルの誤りケースを分析して改善に活かす仕組みを整える。これにより自動検知では見落とす問題にも対処でき、モデル品質と信頼性を高く維持できる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlper-18.html |
| モデルモニタリングフェーズ | MLCOST-27 | ML活動別の利用状況とコストのモニタリング | 機械学習ワークロード内の各活動（データ準備、学習、推論など）ごとにリソース使用量とコストを追跡する。クラウドのコストレポートやカスタムメトリクスで、学習ジョブにいくら、推論エンドポイントにいくら費用がかかっているか可視化する。これによりコストの主要因を特定し、無駄な支出を抑えるための最適化（例えば高コストな処理を削減・効率化）を実施できる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-27.html |
| モデルモニタリングフェーズ | MLCOST-28 | MLモデルのROI（投資対効果）のモニタリング | 本番稼働中のMLモデルが期待したビジネス価値を生んでいるか定期的に評価する。モデル導入によるコスト削減額や売上増加などの効果を算出し、モデル運用コスト（インフラ費、人件費）と比較してROIを測定する。ROIが低いモデルは原因を分析し、改善するか撤退を検討することで、リソースをより価値の高い取り組みに集中させる。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-28.html |
| モデルモニタリングフェーズ | MLCOST-29 | エンドポイント利用状況の監視とインスタンス規模適正化 | モデルエンドポイントのリクエスト数やCPU/GPU使用率を監視し、現在のインスタンス構成が適切か見直す。利用が少ない時間帯にはインスタンス数を減らすか小さいタイプに切り替え、逆にピーク時間帯にはAuto Scalingでスケールアップできるようにする。継続的に需要と供給を分析してインフラを調整することで、サービス性能を維持しつつコストを最小限にする。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlcost-29.html |
| モデルモニタリングフェーズ | MLSUS-15 | 機材効率の測定 | 使用しているハードウェア資源がどれだけ有効活用されているか測定する。例えばGPUの稼働率やメモリ利用率をモニタリングし、長時間アイドル状態になっていないか確認する。低い稼働率が続く場合、リソース構成が過剰の可能性があるため削減を検討する。機材の効率的な利用を図ることで、不要なエネルギー消費を減らし持続可能性を高める。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-15.html |
| モデルモニタリングフェーズ | MLSUS-16 | 必要時のみ再学習実施 | 機械学習モデルの再訓練は、データドリフトや性能劣化が実際に発生したときなど必要性が生じたタイミングで行うようにする。定期スケジュールで無条件に再学習するのではなく、モデルがまだ適切に機能している場合は再訓練を見送り、リソースとエネルギーの消費を抑える。モデルの健全性をモニタリングし、必要最小限の再学習で最新状態を維持する運用を徹底する。 | https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/mlsus-16.html |
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を当ててみてください。