WEB問題集
ある企業のデータ サイエンス チームが、Azure Machine Learning で実験用の学習ジョブを多数実行しています。コストを抑えつつ、需要に応じて自動でスケールさせたいと考えています。学習ジョブ用のコンピューティングとして最も適切なものはどれですか。
解説
【正解: B】の理由
Azure Machine Learning のコンピューティング クラスターは、最小ノード数を 0 に設定して自動スケールを構成すると、ジョブが投入されたときにのみノードが起動し、アイドル状態では 0 ノードまでスケールインします。これにより未使用時の課金を避けながら、需要の増減に応じて複数の学習ジョブを並列実行でき、コストの予測性とスケーラビリティを両立できます。最大ノード数で上限を設けつつ、キューに応じて自動的にスケールアウトするため、手動でのサイズ調整も不要です。多数の実験を回す MLOps の学習基盤として標準的に推奨される構成です。
【他選択肢が違う理由】
- A: 固定サイズのクラスターはアイドル時もノードが起動し続けて課金が発生するため、コストを抑えたい要件に合いません。
- C: コンピューティング インスタンスは個人の開発やノートブック実行向けの単一 VM であり、多数のジョブを自動スケールで並列実行する用途には適しません。
- D: ローカル コンピューティングは手元のマシンで実行するため、チームでの共有・スケール・管理ができず本番的な学習基盤には不向きです。
【参考】
あるチームが複数のパイプラインで学習を実行しています。すべてのジョブで同じ Python パッケージとシステム ライブラリを使い、依存関係の更新を学習コードを変更せずにバージョン管理したいと考えています。どのアセットを使うべきですか。
解説
【正解: A】の理由
Azure Machine Learning の環境 (Environment) アセットは、ジョブ実行時の Python パッケージ・システム ライブラリ・Docker イメージなどの依存関係をまとめて定義し、バージョン管理できるアセットです。学習コードと分離して環境をバージョン管理できるため、すべてのパイプラインで同一の再現可能なランタイムを共有でき、依存関係の更新を新しい環境バージョンとして管理できます。キュレーション済み環境を利用するか、独自の Conda 定義や Docker から作成でき、ジョブ間の再現性とトレーサビリティを確保する MLOps の基礎となります。
【他選択肢が違う理由】
- B: データ アセットは学習データを参照・バージョン管理するもので、ランタイムの依存関係を定義するものではありません。
- C: モデル アセットは学習済みモデルを登録・バージョン管理するもので、実行時の依存関係を管理する用途ではありません。
- D: コンピューティング ターゲットはジョブを実行する計算リソースであり、Python パッケージなどの依存関係を定義するものではありません。
【参考】
あるプラットフォーム チームが、Azure Machine Learning ワークスペースと関連リソースを再現可能かつ宣言的にプロビジョニングしたいと考えています。手作業を避け、構成をコードとして Git で管理します。最も適した方法はどれですか。
解説
【正解: B】の理由
Bicep は Azure リソースを宣言的に定義する Infrastructure as Code (IaC) 言語です。ワークスペースや関連リソース (ストレージ・Key Vault・Application Insights 等) を Bicep テンプレートとして記述すれば、Git でバージョン管理でき、同じ構成を環境間で再現可能かつ反復可能にデプロイできます。手作業を排除してレビューや CI/CD パイプラインに組み込めるため、構成のドリフトを防ぎ、監査可能性とガバナンスを確保できます。MLOps では基盤リソースを IaC で管理することが、再現性のある運用の出発点となります。
【他選択肢が違う理由】
- A: Azure portal の手動作成は再現性がなく、構成をコードとしてバージョン管理・自動化できないため要件に合いません。
- C: ノートブックからの対話的作成は手順が属人化しやすく、宣言的に構成を管理する IaC の要件を満たしません。
- D: Azure CLI のコマンドを手作業で 1 つずつ実行する方法は命令的で、構成全体を宣言的に定義して再現・バージョン管理する IaC の利点を十分には得られません。
【参考】
ある企業の社内ポリシーで、長期的なシークレット (接続文字列やキー) の保存が禁止されています。Azure Machine Learning のジョブが Azure Storage や他のリソースへ安全に認証する必要があります。認証方式として最も適切なものはどれですか。
解説
【正解: B】の理由
マネージド ID は Microsoft Entra ID が管理する ID で、長期的なシークレットを保存・管理せずに Azure リソースへ認証できる仕組みです。Azure ML のワークスペースやコンピューティングにシステム割り当てまたはユーザー割り当てのマネージド ID を構成し、対象リソースに必要なロール (例: Storage Blob Data Reader) を付与すれば、キーや接続文字列を扱わずに安全にアクセスできます。資格情報のローテーションやプロビジョニングが自動化され、シークレット漏えいのリスクを排除できるため、長期シークレット禁止のポリシーに準拠した運用を実現できます。
【他選択肢が違う理由】
- A: アカウント キーをコードに埋め込むのは長期シークレットの保存に当たり、漏えいリスクが高くポリシーに反します。
- C: SAS トークンの長期発行・共有も長期的なシークレットの管理が必要となり、禁止ポリシーに合いません。
- D: ユーザー名とパスワードを構成ファイルに保存するのは資格情報の平文保存であり、安全性とポリシーの両面で不適切です。
【参考】
ある組織が Azure Machine Learning ワークスペースを複数チームで共有し、最小特権でアクセスを管理してガバナンスを効かせたいと考えています。適切な手法を 2 つ選択してください。
解説
【正解: A / C】の理由
ワークスペースを複数チームで安全に共有し最小特権を実現するには、Azure RBAC の組み込みロール (例: AzureML Data Scientist) をユーザーに割り当てて職務に応じた権限を与え、加えて Microsoft Entra ID のセキュリティ グループにロールを割り当ててグループ単位でアクセスを管理するのが適切です。前者は役割ベースの最小特権を、後者は人事異動に強くスケーラブルな権限管理を実現します。ロールはワークスペースのスコープに限定して付与することで影響範囲を抑えられ、両者を組み合わせることで監査可能で統制の効いたアクセス管理を実現できます。
【他選択肢が違う理由】
- B: マネージド ID はアプリやコンピューティングが他リソースへ認証するためのワークロード ID であり、ユーザーのアクセス権限を管理する手段ではないため適切ではありません。
- D: 単一のサービス プリンシパルの資格情報を全チームで共有すると、誰が操作したか追跡できず最小特権と監査性を損なうため不適切です。
- E: サブスクリプション スコープで所有者ロールを割り当てると権限範囲が広すぎ、ワークスペース単位の最小特権という要件に反します。