プレイブック

データ準備からデプロイ、監視まで、機械学習ライフサイクル全体のための集中型コラボレーションプラットフォームが必要である。

→Azure Machine Learning ワークスペース。

理由: これは、コンピューティング、データストア、環境、実験追跡、モデルレジストリ、エンドポイントなど、必要なすべてのコンポーネントを統合する基盤となるサービスです。

リファレンス↗

StorageやACRなどの依存リソースを含むすべてのMLワークスペーストラフィックがAzureプライベートネットワークに留まり、パブリックインターネットに公開されないようにする必要がある。

→Azure MLワークスペースをマネージド仮想ネットワークで構成し、ワークスペースとそのすべての依存リソース（Storage、Key Vault、ACR）にプライベートエンドポイントを使用する。

理由: プライベートエンドポイントはAzureサービスへのセキュアでプライベートな接続を提供し、トラフィックがパブリックインターネットを経由しないようにします。マネージドVNetはMLコンピューティングのこの構成を簡素化します。

リファレンス↗

MLソリューションは厳格なデータレジデンシー規則に準拠し、すべてのデータとコンピューティングが特定の地理的地域（例：欧州連合）内に留まることを保証する必要がある。

→必要な地理的地域内のリージョンに、Azure MLワークスペース、関連するすべてのストレージアカウント、およびコンピューティングリソースを作成する。データ抜き出しを防ぐためにネットワーク分離を使用する。

理由: Azureリソースは作成されたリージョンにバインドされます。これにより、物理的なデータロケーションのコンプライアンスが保証されます。ネットワーク分離（マネージドVNet）は、データがこの境界外で処理されるのを防ぎます。

コスト割り当てタグの要求、VMサイズの制限、診断ログの送信の義務付けなど、すべてのMLワークスペースで組織の標準を適用する必要がある。

→Azure Policyを使用して、リソースの作成と構成に関するルールを適用および強制する。

理由: Azure Policyはスケーラブルで集中型のガバナンスを提供します。非準拠のリソースが作成されるのを防ぎ、手動での監視なしに一貫した標準を保証します。

リファレンス↗

コードや構成に資格情報（アカウントキー、SASトークン）を保存せずに、MLワークスペースからAzure Storageのデータにアクセスする。

→IDベースの認証を使用してデータストア接続を作成する。ワークスペースのマネージドID（またはユーザー/コンピューティングID）に、ストレージアカウントに対する適切なRBACロール（例：Storage Blob Data Reader）を付与する。

理由: これはAzure ADを使用して認証する、資格情報不要のゼロトラストパターンであり、セキュリティを向上させ、資格情報管理を簡素化します。

複数のチームが異なるセキュリティレベル（例：PIIと匿名化されたデータ）のプロジェクトに取り組んでいる。リソースの分離を提供する必要がある。

→各セキュリティ境界に対して個別のAzure MLワークスペースを作成する。PIIプロジェクト用のワークスペースは、機密性の低いプロジェクト用のワークスペースよりも厳格なネットワーク分離を持つべきである。

理由: ワークスペースは主要なセキュリティおよび分離境界です。セキュリティレベルで分離することは、データ漏洩を防ぎ、適切な制御を適用するためのベストプラクティスです。

開発/実験活動を本番グレードのモデルトレーニングおよびデプロイから分離し、干渉を防ぎ、安定性を確保する必要がある。

→開発環境と本番環境用に個別のAzure MLワークスペースを使用する。

理由: これにより、本番リソース、データ、およびモデルが実験作業から分離され、本番MLOpsパイプラインの安定性と明確なガバナンスが提供されます。

断続的に実行され、コスト削減を最優先するMLトレーニングジョブ用のコンピューティングをプロビジョニングする。

→低優先度VM、最小ノード数0、およびオートスケーリングが構成されたAzure MLコンピューティングクラスターを使用する。

理由: 低優先度VMは、中断可能なワークロードに大幅なコスト削減をもたらします。最小ノード数0は、クラスターがアイドル状態のときに費用が発生しないことを保証します。

リファレンス↗

個々のデータサイエンティストによる対話型ノートブック開発と、より大規模な無人トレーニングジョブの実行の両方のためにコンピューティングをプロビジョニングする必要がある。

→対話型開発用にCompute Instance（ユーザーごとに1つ）をプロビジョニングする。バッチトレーニングジョブ用にCompute Clusterをプロビジョニングする。

理由: Compute Instanceは、対話型作業に最適化されたシングルユーザーの永続的なVMです。Compute Clusterは、バッチジョブに最適化されたオートスケーリングのマルチノードリソースです。

特定のPythonパッケージバージョンを含むすべてのソフトウェア依存関係をキャプチャすることにより、MLトレーニングの実行が再現可能であることを保証する。

→conda環境YAMLファイルまたはDockerfileを使用してAzure ML Environmentを定義する。この環境をトレーニングジョブで使用するために登録およびバージョン管理する。

理由: 環境は、ランタイムのバージョン管理され、再利用可能な仕様です。これにより、環境がコンピューティングから分離され、その環境バージョンでの実行が常に同一であることが保証されます。

特徴量エンジニアリングロジックはトレーニングと推論の間で一貫している必要があり、特徴量は複数のモデルやチーム間で再利用可能である必要がある。

→Azure ML Managed Feature Storeを使用して特徴量を定義、計算、提供する。

理由: 特徴量ストアは一貫性（トレーニングと提供のスキューの防止）を保証し、特徴量の発見と再利用を可能にし、オフライン（トレーニング用）とオンライン（低レイテンシー推論用）の両方のストレージを提供します。

比較と再現性のために、コードバージョン、ハイパーパラメーター、メトリック、モデルアーティファクトを含むすべてのML実験を体系的に追跡する。

→Azure MLにネイティブに統合されているMLflowを使用する。自動ログ記録を有効にするか、トレーニングスクリプトで明示的な`mlflow.log_*`コマンドを使用する。

理由: MLflowは、実験追跡のための標準化されたオープンソースフレームワークを提供します。Azure MLはマネージドMLflow追跡サーバーとして機能し、実行を比較するためのUIを提供します。

リファレンス↗

クラスの不均衡が深刻なデータセット（例：詐欺検出）で分類モデルをトレーニングしており、マイノリティクラスでのパフォーマンスが低い。

→トレーニングデータにSMOTE（Synthetic Minority Over-sampling Technique）などの手法を適用する。Precision-Recall AUCやF1スコアなど、不均衡に影響されないメトリックを使用してモデルを評価する。

理由: 単純な精度だけでは誤解を招きます。SMOTEは合成のマイノリティサンプルを作成してモデルの学習を助け、PR-AUC/F1スコアはポジティブクラスのパフォーマンスを正確に測定します。

トレーニング時間が長く、コンピューティング予算が限られているモデルの最適なハイパーパラメーターを見つける必要がある。

→ベイズサンプリングと早期終了ポリシー（例：BanditまたはMedian Stopping）を持つスイープジョブを使用する。

理由: ベイズサンプリングは探索空間をインテリジェントに探索し、有望な領域に焦点を当てます。早期終了はパフォーマンスの低い実行を早期に停止し、大幅なコンピューティング時間とコストを節約します。

AutoMLを使用して時系列予測モデルを構築する。

→AutoMLジョブを`task='forecasting'`で構成し、`time_column_name`を指定し、`forecast_horizon`を設定する。

理由: タスクを「予測」として指定することで、AutoMLはラグ特徴量生成、季節性検出、時間認識型交差検定など、時系列固有の手法を適用できるようになります。

トレーニング時間を短縮するために、複数のコンピューティングノードの複数のGPUにまたがる大規模な深層学習モデルをトレーニングする。

→GPU対応ノードを持つコンピューティングクラスターを使用する。コマンドジョブで`distribution`プロパティ（例：`type: "PyTorch"`、`process_count_per_instance: <# GPUs>`）を構成する。

理由: Azure MLはノードの設定と通信を管理することで分散トレーニングを簡素化します。`distribution`構成は、分散トレーニングプロセスをどのように起動するかをAzure MLに伝えます。

リファレンス↗

異なるパラメーターで再利用できる多段階のMLワークフロー（例：データ準備、トレーニング、評価）を自動化する。

→各ステップのコンポーネントを使用してAzure MLパイプラインを定義する。パイプライン入力を使用してワークフローをパラメーター化する。

理由: コンポーネントベースのパイプラインはモジュール性と再利用性を促進します。また、自動ステップキャッシュ（再利用）をサポートしており、入力が変更されていないステップを再実行しないことで時間を節約します。

トレーニングセットでは非常に良いパフォーマンスを示すが、検証セットではパフォーマンスが悪いモデル。トレーニングと検証の損失曲線が乖離していることで示される。

→これは過学習の典型的な兆候です。正則化（例：ドロップアウト、L2）の適用、データ拡張の使用、早期終了の実装、またはモデルの複雑さの軽減によって緩和する。

理由: トレーニングと検証のパフォーマンスのギャップは、モデルが汎化するのではなく、トレーニングデータを記憶していることを示します。正則化手法は、汎化を改善するために複雑さにペナルティを課します。

低優先度（スポット）VMで実行されている長時間実行トレーニングジョブは、中断されて進行状況が失われるリスクがある。

→トレーニングスクリプト内でチェックポイントを実装し、モデルとオプティマイザの状態を定期的に`./outputs`ディレクトリに保存する。

理由: `./outputs`ディレクトリはAzure MLによって自動的に永続化されます。チェックポイントを保存することで、中断時に最後に保存された状態からジョブを再開でき、進行状況を維持し、コストを節約できます。

組織には、特定のMLアルゴリズムのみを本番環境で使用できるというポリシーがある。AutoML実行中にこれを強制する必要がある。

→AutoML構成で、`blocked_models`パラメーターを使用して、承認されていないアルゴリズムを探索空間から明示的に除外する。

理由: これにより、AutoMLをガバナンスポリシーに合わせ、非準拠モデルの選択を防ぐ直接的で強制可能な方法が提供されます。

リアルタイムの低レイテンシー（<100ms）予測と高可用性のためにモデルをデプロイする。

→モデルをAzure ML Managed Online Endpointにデプロイする。

理由: マネージドオンラインエンドポイントは、リアルタイム推論に最適化されたフルマネージドサービスであり、オートスケーリング、ロードバランシング、ブルー/グリーンデプロイ、および組み込みの監視機能を提供します。

リファレンス↗

大量のデータ（数百万レコード）を非同期的にスコアリングし、コスト効率を優先する。

→モデルをAzure ML Batch Endpointにデプロイする。

理由: バッチエンドポイントは、大規模なデータセットのハイスループットな非同期スコアリング用に設計されています。アイドル時にゼロにスケールダウンするスケーラブルなコンピューティングクラスターを使用でき、コストを最適化します。

リスクを最小限に抑えながら新しいモデルバージョンをデプロイする。新しいバージョンにトラフィックを徐々に移行し、容易なロールバックを可能にする必要がある。

→2つのデプロイ（例：古いモデルには「blue」、新しいモデルには「green」）を持つ単一のマネージドオンラインエンドポイントを使用する。トラフィック分割を使用して、各デプロイに送られるリクエストの割合を制御する。

理由: このブルー/グリーンデプロイパターンにより、安全でダウンタイムなしのロールアウトが可能です。完全に切り替える前に、新しいモデルをライブトラフィックの小さな部分で検証できます。

モデルを依存関係とアーティファクトとともに、標準化されたフレームワーク非依存の方法でデプロイ用にパッケージ化する。

→MLflowモデル形式を使用する。モデルを登録するときに、conda.yamlまたはrequirements.txtファイルと必要なコードアーティファクトを含める。

理由: MLflowは、Azure MLがネイティブに理解する標準的なモデルパッケージング規則を提供します。これにより、Azure MLが必要な環境を自動的に構築できるため、デプロイが簡素化されます。

デプロイされたモデルは、予測リクエストごとに大きな補助ファイル（例：大きな特徴量抽出器）を読み込むため、レイテンシーが高い。

→ファイル読み込みロジックをスコアリングスクリプトの`run()`関数から`init()`関数に移動する。

理由: `init()`関数はコンテナが起動するときに一度だけ実行されます。ここでアセットを読み込むことで、すべての`run()`呼び出しでグローバルに利用可能になり、リクエストごとの冗長な読み込みを回避します。

リアルタイムエンドポイントが変動するトラフィック（高ピーク、低谷）を経験している。費用対効果の高い方法でパフォーマンスを維持する必要がある。

→マネージドオンラインエンドポイントデプロイでオートスケーリングを構成する。最小インスタンス数と最大インスタンス数を設定し、CPU使用率またはリクエストレイテンシーに基づいたスケーリングルールを定義する。

理由: オートスケーリングは、トラフィック負荷に合わせてコンピューティングインスタンスの数を自動的に調整し、ピーク時のパフォーマンスを確保し、閑散時のコストを節約します。

モデルのデプロイには、デフォルトのAzure MLイメージには存在しない特定のシステムライブラリ、カスタムCUDAバージョン、またはカスタム推論サーバーが必要である。

→Azure MLベースの推論イメージを拡張するカスタムDockerfileを作成し、必要な依存関係を追加し、ビルドしてAzure Container Registryにプッシュする。デプロイ環境でこのイメージを参照する。

理由: ベースイメージを拡張することで、ランタイム環境を完全に制御できると同時に、Azure MLのサービスインフラストラクチャとの互換性を維持できます。

コードまたはデータの変更によってトリガーされる、再トレーニング、評価、デプロイを含むエンドツーエンドのMLライフサイクルを自動化する。

→Azure DevOpsまたはGitHub ActionsをAzure ML CLI v2と統合してCI/CDパイプラインを作成する。パイプラインには、デプロイ前に新しいモデルとベースラインを比較する品質ゲートを含めるべきである。

理由: このMLOpsパターンはMLワークフローを自動化し、一貫性、品質、迅速な反復を保証します。品質ゲートはモデルのパフォーマンス低下を防ぎます。

入力データ分布の変化により、本番モデルのパフォーマンスが低下している。重大なドリフトが検出されたときにモデルを自動的に再トレーニングする必要がある。

→エンドポイントでAzure MLデータドリフトモニターを構成する。Azure Logic AppまたはAzure Functionをトリガーし、それが再トレーニングパイプラインを開始するアラートを設定する。

理由: これにより、手動介入なしに、変化するデータパターンに対応してモデルの関連性を自動的に維持する閉ループMLOpsシステムが作成されます。

新しくデプロイされたモデルバージョンが本番環境で欠陥があることが判明した。以前の安定したバージョンに迅速に戻す必要がある。

→ブルー/グリーンデプロイを使用している場合、トラフィックの100%を安定したデプロイに戻す。または、モデルレジストリから以前のモデルバージョンを再デプロイするようにエンドポイントを更新する。

理由: トラフィックシフトは瞬時のロールバックを提供します。レジストリからバージョンを再デプロイすることも、既知の良好な状態を復元するための高速で信頼性の高い方法です。

デプロイされたモデルの運用状態（レイテンシー、エラー）と予測品質（データドリフト、精度）の両方を監視する必要がある。

→運用メトリックのためにエンドポイントでApplication Insights統合を有効にする。モデル品質メトリックのためにAzure MLデータ収集とデータドリフト監視を構成する。

理由: この2つのアプローチは、モデルの健全性の完全なビューを提供します。App Insightsはシステムパフォーマンスを追跡し、データ収集/ドリフト監視はモデルの予測パフォーマンスを追跡します。

クライアントからの形式が不正な、または予期しない入力データにより、モデルエンドポイントが失敗している。

→スコアリングスクリプトの`run()`関数内に​​入力検証ロジックを実装する。データ型、範囲、構造を確認し、無効なリクエストに対して意味のあるエラー（例：HTTP 400）を返す。

理由: サーバー側の検証は、モデルをクラッシュから保護し、APIコンシューマーに明確で即時のフィードバックを提供することで、サービスをより堅牢にします。

デバッグ、コンプライアンス、またはステークホルダーの信頼のために、複雑な「ブラックボックス」モデルが特定の予測を行う理由を理解する必要がある。

→Azure MLのResponsible AIダッシュボードを使用してモデルの説明を生成する。ローカル（個々の予測）の説明にはSHAPを使用し、全体的なモデル動作にはグローバル特徴量重要度を使用する。

理由: SHAP値は、特定の予測に対する各特徴量の影響を帰属させるための堅牢なモデル非依存の方法を提供し、規制およびデバッグシナリオにとって重要です。

ローン承認などの決定に使用されるモデルは公平であり、保護された人口統計グループを差別しない必要がある。

→Responsible AIダッシュボードの公平性評価を使用して、機密性の高い特徴量全体で公平性メトリック（例：人口統計学的パリティ、均等化オッズ）を分析する。不均衡が見つかった場合は、後処理の閾値調整などの緩和策を適用する。

理由: 公平性評価は、グループ間のモデルの動作の定量的な証拠を提供します。緩和策は、公平な結果を保証するためにバイアスを修正するのに役立ちます。

LLMは事実を幻覚させることなく、特定のプライベートな会社の文書に基づいて質問に答える必要がある。

→Retrieval-Augmented Generation (RAG) パターンを実装する。Azure AI Searchを使用して文書のベクトルインデックスを作成する。クエリ時に、関連する文書チャンクを検索し、プロンプトのコンテキストとしてLLMに渡す。

理由: RAGはLLMの応答を事実に基づいた最新の情報に根拠付け、幻覚を大幅に減らし、元のトレーニングデータにはない知識を使用できるようにします。

LLMは、特定のガイドライン、トーン、および出力形式（例：JSON生成）を一貫して遵守する必要がある。

→詳細なシステムプロンプトエンジニアリングを使用する。明確なペルソナ、明示的なルールと制約、および望ましい入力/出力ペアのフューショット例を提供する。

理由: 適切に作成されたシステムプロンプトは、ファインチューニングのコストと複雑さなしにLLMの動作を誘導する最も直接的で効果的な方法です。

RAGベースのLLMアプリケーションの品質を測定する必要がある。

→Groundedness（回答はコンテキストによって裏付けられているか？）やRelevance（回答はユーザーの質問に答えているか？）など、RAGに特化した評価メトリックを使用する。

理由: ROUGEのような標準的なNLPメトリックは不十分です。GroundednessとRelevanceは、RAGの核となる課題、すなわち幻覚の防止と有用な回答の提供を直接測定します。

LLMアプリケーションが本番環境での使用には遅すぎるか高価である。

→ルーターを実装して、より単純なタスクにはより小さく安価なモデル（例：GPT-3.5-Turbo）を使用する。繰り返しクエリに対して応答キャッシュを有効にする。プロンプトの長さを最適化する。

理由: タスクに適したサイズのモデルを使用することが最も効果的なコスト削減策です。キャッシュは冗長なAPI呼び出しを排除し、直接コストとレイテンシーを削減します。

LLMアプリケーションは、企業ネットワークから離れたり、モデルトレーニングに使用されたりしてはならない機密データを処理する。

→プライベートエンドポイントでAzure OpenAIサービスをデプロイする。プロンプト/完了データをログに記録しないようにリソースを構成する。

理由: プライベートエンドポイントはネットワーク分離を保証します。ログなしオプションは、厳格なコンプライアンス要件を満たす追加のデータプライバシー層を提供します。

Azure AI Studioで開発されたプロンプトフローを、高可用性でスケーラブルな本番エンドポイントとしてデプロイする必要がある。

→プロンプトフローをAzure ML Managed Online Endpointとしてデプロイする。

理由: これにより、開発から本番へのシームレスなパスが提供され、従来のMLモデルに使用されるのと同じ堅牢なインフラストラクチャ（オートスケーリング、ロードバランシング、監視）が活用されます。

ユーザー向け生成AIアプリケーションは、有害な、攻撃的な、または安全でないコンテンツの生成または処理から保護される必要がある。

→プロンプトと完了の両方の深度防衛モデレーションのために、組み込みのAzure OpenAIコンテンツフィルターとAzure AI Content Safetyサービスの両方を使用する。

理由: 多層防御は重要です。組み込みフィルターはベースラインを提供し、専用のContent Safetyサービスはより詳細な制御とマルチモーダル機能を提供します。

会話型AIチャットボットは、複数のユーザーのやり取り間でコンテキストを維持する必要がある。

→LLMはステートレスです。アプリケーションは会話履歴（例：セッションまたはデータベース）を管理し、履歴の関連部分をLLMへの各新しいプロンプトに含める必要がある。

理由: 各API呼び出しで明示的にコンテキストを提供することが、ステートレスなLLMが会話を「記憶する」唯一の方法です。

最適なLLMパフォーマンスをもたらすプロンプトを見つけるために、さまざまなプロンプトを体系的にテストする必要がある。

→プロンプトフローのバリアントを使用する。ノードに複数のプロンプトバージョンを定義し、評価データセットに対して一括テストを実行してパフォーマンスメトリックを比較する。

理由: バリアントは、手動での試行錯誤を超えて、体系的な最適化へのデータ駆動型アプローチをプロンプトエンジニアリングに提供します。

本番環境のLLMアプリケーションの運用健全性と応答品質の両方を監視する必要がある。

→運用テレメトリ（レイテンシー、エラー率、トークン使用量）にはApplication Insightsを、応答品質（Groundedness、Relevance）を評価するには評価フローを使用した定期的なバッチ評価ジョブを組み合わせる。

理由: LLM監視には、システムパフォーマンスと生成コンテンツの品質の両方の追跡が必要です。この組み合わせにより、アプリケーションの健全性の全体的なビューが提供されます。