MLA-C01 Domain 3 完全攻略 — デプロイとオーケストレーションで 22% を取る

MLA-C01 の Domain 3「Deployment and Orchestration of ML Workflows」は配点 22% と 4 ドメインで最小だが、合否への影響はその数字以上に大きい。推論エンドポイントの 4 方式、IaC、コンテナ、CI/CD。ここは AWS インフラの一般知識と ML 固有の知識が交差する領域であり、SAA-C03 取得者には最大の得点源、インフラ未経験者には最大の難所になる。本記事は公式試験ガイドの Task 3.1〜3.3 に準拠し、「学習済みモデルを本番に届けて回し続ける」ための判断基準を体系化する。

試験全体の地図は AWS MLA-C01 完全攻略入門（2026-06-15 公開）、前段のモデル開発は MLA-C01 Domain 2 完全攻略（2026-06-17 公開）を参照してほしい。

Domain 3 の全体像 — 「届ける」と「回す」の 22%

公式試験ガイドの 3 タスク構成を押さえる。

Domain 3 の出題は一貫して「要件文の数語からアーキテクチャを逆引きさせる」スタイルだ。「断続的なトラフィック」「ペイロードが大きい」「夜間にまとめて処理」。これらのフレーズがそれぞれ特定のエンドポイント方式を指す合図になっており、合図と方式の対応表を頭に入れているかどうかで解答時間が桁違いに変わる。まずはその対応表から作っていこう。

Task 3.1 — 推論エンドポイント 4 方式の選び分け

Domain 3 の最重要論点が、SageMaker の推論方式 4 種の使い分けだ。公式ドキュメントが明記する制約と適性を一覧にする。

要件文との対応はほぼ機械的に決まる。「ユーザー操作に即応」ならリアルタイム。「日中に数回しか呼ばれない社内ツール」ならサーバーレス——インスタンスを常時立てる料金が無駄になるからだ。「動画 1 本を解析して結果は後で通知」なら非同期。「月次で全顧客のスコアを再計算」ならバッチ変換。数値上限も決め手になる。ペイロードが数百 MB ある時点でリアルタイムとサーバーレスは脱落し、非同期かバッチの二択に絞られる。

4 方式は固定の選択ではなく、サービスの成長に合わせて移行するものでもある。立ち上げ期の社内 PoC はサーバーレスで始め、利用が定常化したらリアルタイムに移し、データが溜まったら月次のバッチ変換で再スコアリングを併設する。こうしたライフサイクル視点を持っておくと、「現在の構成の何が要件に合わなくなったか」を問う形式の出題にも対応できる。またサーバーレス推論には、しばらく呼ばれていない状態からの初回呼び出しで起動の待ち時間が発生し得るという特性がある。「断続的だが、呼ばれた瞬間の応答は厳格」という要件は、サーバーレスでは満たしにくい——この程度の機微まで読めると、選択肢の罠を踏まなくなる。

コンピュートの選択も Task 3.1 の範囲だ。学習と推論それぞれについて、CPU か GPU か、プロセッサファミリ、ネットワーク帯域まで含めて要件から選ぶ。推論は学習より小さな計算で済むことが多く、学習用の GPU インスタンスをそのまま推論に流用するのは典型的な過剰設計だ。さらにエッジデバイスでの推論にはモデルを最適化する SageMaker Neo が名指しされている。Domain 2 で扱ったプルーニングや圧縮といった軽量化手法が、ここでエッジ配置という目的と結びつく。

デプロイ先は SageMaker だけではない — マルチモデルと代替ターゲット

試験ガイドは、デプロイターゲットとして SageMaker AI エンドポイントのほかに Kubernetes、Amazon ECS、Amazon EKS、AWS Lambda を明示的に挙げている。既存のコンテナ基盤に推論を載せたい組織、軽量モデルをイベント駆動で動かしたい場面など、SageMaker エンドポイントが常に唯一解ではないという前提で選択肢が組まれる。

SageMaker 内部にも構成の幅がある。1 つのエンドポイントに複数モデルを載せるマルチモデルデプロイ、推論パイプラインを構成するマルチコンテナデプロイ。呼び出し頻度の低いモデルが多数ある場合に、モデルごとにエンドポイントを立てるのではなく相乗りさせてコストを下げる、という判断が典型的な出題文脈だ。

コンテナの選択——AWS 提供のビルド済みコンテナを使うか、カスタマイズするか——も知識項目に含まれる。フレームワークが標準対応の範囲なら提供コンテナで済み、特殊な依存関係があるなら独自コンテナ（BYOC）に進む。この段階構造は Domain 2 の「組み込みアルゴリズム → スクリプトモード → BYOC」というエスカレーション経路の続きとして覚えると整理しやすい。

オーケストレーターの選択も Task 3.1 のスキル項目だ。ML パイプライン専用に設計された SageMaker Pipelines と、汎用ワークフローエンジンの Apache Airflow。SageMaker 内で完結する ML ワークフローなら前者、既存の Airflow 資産や ML 以外のジョブも混ざる全社基盤なら後者、という軸で判断する。

Task 3.2 — IaC: CloudFormation と CDK の使い分け

インフラをコードで管理する IaC は、Task 3.2 の中核だ。試験ガイドは AWS CloudFormation と AWS CDK を名指しし、それぞれのトレードオフとユースケースを問う。

CloudFormation はテンプレート（宣言的な定義ファイル）でリソースを記述する基盤サービスであり、CDK は TypeScript や Python といったプログラミング言語でインフラを記述して CloudFormation テンプレートに合成する上位レイヤーだ。宣言的な構成管理に徹したいなら CloudFormation、ループや条件分岐を使った抽象化・再利用をコードの表現力で行いたいなら CDK。チームのスキルセット（インフラ担当か、アプリ開発者か）が要件文のヒントになる。

スタック間の連携を含むコンピュートリソースの自動プロビジョニングがスキル項目として明記されている点も見逃せない。学習用スタック、推論用スタック、ネットワークスタックを分割し、出力値を相互参照させる構成は実務の定石であり、「環境を再現可能にせよ」という MLOps の要請そのものだ。オンデマンドとプロビジョンドの違い、スケーリングポリシーの比較という知識項目も、この文脈に束ねて理解する。

IaC が ML で特に重要になる理由は、環境の数にある。開発・検証・本番の 3 環境に加え、実験ごとに使い捨ての学習環境が立っては消える。手作業のコンソール操作でこれを管理すれば、環境差分による「検証では動いたのに本番で壊れる」が必ず起きる。テンプレートから環境を再生成できる状態にしておくことは、Domain 2 の Model Registry によるモデルの再現性と対になる「インフラの再現性」であり、両者が揃って初めて ML システム全体の監査可能性が成立する。出題でも「手順書による手動構築」が誤答選択肢として置かれる構図を想定しておきたい。

コンテナ戦略 — ECR / ECS / EKS / BYOC

コンテナ関連は語彙の整理が得点に直結する。コンテナイメージの保管庫が Amazon ECR、AWS ネイティブのコンテナ実行基盤が Amazon ECS、Kubernetes のマネージドサービスが Amazon EKS。そして SageMaker に独自コンテナを持ち込む方式が BYOC（Bring Your Own Container）だ。

試験ガイドのスキル項目は「コンテナの構築と維持」であり、単なる用語の知識ではなく運用フローを問う。推論コードと依存関係を Dockerfile にまとめ、イメージをビルドして ECR にプッシュし、SageMaker エンドポイントや ECS / EKS から参照する。この一連の流れを順序付け（ordering）形式で並べさせる出題は、いかにもありそうな題材だ。

VPC 内での SageMaker エンドポイント構成もスキル項目に明記されている。インターネットに出さずに推論を完結させたい規制業種の要件は、Domain 4 のセキュリティ（VPC・サブネット・セキュリティグループ）と直結する論点であり、ここで布石を打っておくと Domain 4 の学習が軽くなる。

ECS と EKS の選び分けは、組織の運用成熟度を軸に読む。AWS に最適化されたシンプルな運用で十分なら ECS、Kubernetes のエコシステムや既存のマニフェスト資産・マルチ環境での可搬性を重視するなら EKS。どちらが優れているかではなく、チームが何をすでに持っているかで決まる、という相対的な判断が問われる。SageMaker AI SDK によるモデルのデプロイとホスティングもスキル項目に含まれており、コンソール操作だけでなくコードからのデプロイ経路を把握しているかが、エンジニア向け Associate 試験らしい確認ポイントになっている。

オートスケーリング — 何をトリガーに伸縮させるか

SageMaker エンドポイントのオートスケーリングは、Task 3.2 で最も実務色の強い論点だ。試験ガイドは、スケーリングの判断指標としてモデルレイテンシ、CPU 使用率、インスタンスあたりの呼び出し数（invocations per instance）を名指しする。トラフィックの増加にどの指標で気づき、どの粒度で台数を増やすか。需要ベースだけでなく時間ベース（業務時間に合わせた事前スケール）も知識項目に含まれる。

指標の選び方には一段深い判断がある。CPU 使用率は汎用的だが、推論の負荷が GPU やメモリに偏るモデルでは負荷の実態を映さないことがある。インスタンスあたりの呼び出し数はトラフィック量を直接捉え、モデルレイテンシはユーザー体験そのものを捉える。「ユーザーへの応答時間を一定に保ちたい」という要件ならレイテンシ基準、「リクエスト数の急増に追従したい」なら呼び出し数基準、という対応で読み分ける。どの指標でも、スケールアウトには新インスタンスの起動時間がかかるため、急峻なスパイクには事前スケールや余裕を持ったしきい値設定で備える、という時間軸の感覚も問われ得る。

コスト効率の文脈では、Spot インスタンスの動的活用、エンドポイントの背後に Lambda を置く構成、EC2 インスタンスの直接利用といった選択肢が、保守性・拡張性・コスト効率のベストプラクティスとしてガイドに列挙されている。「夜間はトラフィックがほぼゼロになる」という要件文を見たら、サーバーレス推論への切り替えかスケジュールベースのスケールインを想起する——この反射を作っておきたい。

なお、オートスケーリングの一般論は AWS SAA-C03 回復性設計 完全攻略（2026-06-02 公開）で扱った内容と地続きだ。SAA-C03 学習済みなら、「対象が EC2 から SageMaker エンドポイントに変わっただけ」という見立てで差分学習に絞れる。

Task 3.3 — CI/CD: CodePipeline / CodeBuild / CodeDeploy

ML ワークフローの自動化を担うのが AWS の Code 系サービス群だ。役割分担を一言ずつで固定する。パイプライン全体の流れを定義するのが CodePipeline、ビルドとテストを実行するのが CodeBuild、デプロイを実行するのが CodeDeploy。試験ガイドは 3 サービスの機能とクォータ、ステージ構成のトラブルシューティングまでをスキル項目に含めている。

バージョン管理は Git が前提で、Gitflow や GitHub Flow といったブランチ運用の流儀がデプロイフローの起点として登場する。さらに CI/CD パイプラインに自動テスト——ユニットテスト、統合テスト、エンドツーエンドテスト——を組み込むスキルも明記されている。モデルの学習コードも推論コードもソフトウェアである以上、テストなしのデプロイはあり得ない、という思想が Domain 3 全体を貫いている。

ML の CI/CD が通常のソフトウェアと違うのは、バージョン管理の対象がコードだけでなくデータとモデルにも広がる点だ。同じコードでも学習データが変われば別のモデルが生まれる。だからこそ、コードは Git、モデルは Model Registry、データは取得時点とともに記録、という三層の来歴管理が要る。テストも同様で、コードのユニットテストに加えて「新モデルの評価指標がベースラインを下回っていないか」という品質ゲートをパイプラインに組み込む発想が、ML 固有の CI/CD 設計として問われる。

ML 固有の要素として重要なのが再学習機構の組み込みだ。EventBridge のルールで学習ジョブや推論ジョブを起動し、SageMaker Pipelines や CodePipeline と連携させてモデルの再構築を自動化する。Domain 4 で扱うドリフト検出が「再学習の引き金」となり、Task 3.3 のパイプラインが「引き金を受けて動く本体」となる。この連結が MLOps の核心であり、ドメインをまたいだ統合問題の頻出構図だ。

デプロイ戦略 — ブルー/グリーン・カナリア・リニア

新しいモデルを本番に出す瞬間のリスク管理が、デプロイ戦略の論点だ。試験ガイドはブルー/グリーン、カナリア、リニアの 3 戦略とロールバックを名指しする。

ブルー/グリーンは新旧 2 系統を並走させ、切り替えを一括で行う方式。問題があれば旧系統に即時で戻せるが、2 系統分のリソースが必要になる。カナリアはトラフィックのごく一部だけを新系統に流して様子を見てから全量を切り替える方式。リニアは新系統への配分を段階的に一定割合ずつ増やしていく方式だ。「影響範囲を最小にしながら検証したい」ならカナリア、「切り替えとロールバックを瞬時に行いたい」ならブルー/グリーン、という要件対応で覚える。

3 戦略の選択は、リスク許容度とコストの交換条件として整理できる。ブルー/グリーンは検証期間中 2 系統分のコストを払う代わりに、切り戻しが一瞬で済む。カナリアとリニアは追加コストを抑えながら、問題の影響を一部のトラフィックに閉じ込める代わりに、全量到達までの時間が長い。「決済のような事故が許されない処理」「とにかく早く全ユーザーへ届けたい新機能」——要件文のこうした語感から、どの交換条件を受け入れるかを読み取る。ロールバックは戦略におまけで付くものではなく、アラームと連動して自動で発火するよう設計しておくべきものであり、「問題発生時に手動で切り戻す」が誤答側に置かれる構図も想定しておく。

Domain 2 で登場したシャドーバリアント——本番トラフィックの複製を新モデルに流して比較する手法——も、この文脈に置き直すと役割が明確になる。シャドーは「ユーザーに結果を返さずに検証する」段階であり、カナリアは「一部ユーザーに実際に返しながら検証する」段階。検証の深度が一段違う。バージョニングとロールバック戦略はデプロイのベストプラクティスとして Task 3.1 の知識項目にも挙がっており、Domain 3 の中で二重に問われ得る。

頻出論点チェックリスト — 本番想定の自己診断

以下に根拠付きで即答できるかを確認してほしい。

• 断続的なトラフィックでアイドル課金を避けたい推論方式は（→ サーバーレス推論）
• 1 GB 近いペイロードを 30 分かけて処理する方式は（→ 非同期推論）
• 常設エンドポイント不要の一括推論は（→ バッチ変換）
• エッジデバイス向けにモデルを最適化するサービスは（→ SageMaker Neo）
• プログラミング言語でインフラを記述して CloudFormation に合成する選択肢は（→ AWS CDK）
• コンテナイメージの保管場所は（→ Amazon ECR）
• パイプライン定義 / ビルド・テスト / デプロイ実行の 3 役は（→ CodePipeline / CodeBuild / CodeDeploy）
• 一部トラフィックだけ新モデルに流して検証する戦略は（→ カナリア）

8 問中 6 問以上なら Domain 3 は得点圏だ。特に推論 4 方式は、数値上限（25 MB / 4 MB / 1 GB）まで含めて即答できる状態に仕上げてほしい。

まとめ — デプロイは「選択の連続」、オーケストレーションは「自動化の設計」

Domain 3 の 22% は、推論エンドポイント 4 方式の対応表、IaC とコンテナの語彙、Code 系 3 サービスの役割分担、そして 3 つのデプロイ戦略に集約される。いずれも「要件文の合図 → 構成の選択」という型で出題されるため、本記事の対応表をそのまま反射にまで落とし込めば、最小配点のドメインを最短時間で確保できる。

次は最後のドメイン、Domain 4「監視・保守・セキュリティ」（24%）。デプロイしたモデルを観測し、守り、低コストで維持する領域へ進む。全体の学習設計は AWS MLA-C01 完全攻略入門（2026-06-15 公開）の 8 週間ロードマップを参照のこと。

参照

• MLA-C01 試験ガイド Domain 3（公式）
• SageMaker 推論オプション（公式ドキュメント）
• SageMaker 非同期推論（公式ドキュメント）
• AWS Certified Machine Learning Engineer – Associate 公式ページ

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.