MLA-C01 Vol3｜SageMakerエンドポイント・推論オプション【D3ドメイン88問対策】

1. はじめに — D3「モデルのデプロイ・推論」とは

本記事は「AWS MLA-C01試験対策」シリーズの Vol3 です。
全体像は Vol0 ロードマップ、データ準備は Vol1、モデル開発は Vol2 で解説しています。未読の方は先にお読みください。

ここから扱うのは試験の第3ドメイン、D3「モデルのデプロイ（Deployment and Orchestration）」 です。
公式試験ガイドにおける出題比率は 22% で、65問換算なら約14問を占めます。
Vol2 で学習したモデルを、いよいよ 本番環境で提供（デプロイ）し、予測（推論）を返す 工程です。
このドメインで最も問われるのは、4つの推論オプションの使い分け と MLOps（ML運用自動化）パイプライン の理解です。

1-1. D3の出題範囲を一望する

D3 はデプロイから運用自動化まで、大きく次の6テーマで整理できます。

D3 は Vol2 までの「モデルを作る」工程と異なり、作ったモデルを安定して届ける 工程です。
ソフトウェアの世界に DevOps があるように、ML の世界にも MLOps があり、デプロイ・監視・再学習を自動化して品質を保ちます。
本記事はその入り口として、まず推論方式の選択を固め、続いて運用自動化とデプロイ戦略へと進みます。

2. 推論オプション全体像 — 4つの方式の使い分け

SageMaker には目的の異なる 4つの推論オプション があり、その使い分けが D3 の最頻出テーマです。
なぜ4つも方式があるのでしょうか。
それは推論の要件が用途によって大きく異なるからです。
ECサイトの「おすすめ商品」はミリ秒で返す必要がありますが、月次の需要予測は一晩かけて一括処理すれば十分です。
レイテンシ・コスト・データ量のトレードオフに応じて最適な方式を選ぶ――これが D3 で繰り返し問われる本質です。
まず全体像を1枚の図で把握しましょう。

4オプションの特徴を表で整理します。

3. リアルタイム推論 — エンドポイント設定とAuto Scaling

3-1. リアルタイムエンドポイントの仕組み

リアルタイム推論とは、リクエストの都度すぐに予測結果を返す 方式です。
SageMaker は学習済みモデルを エンドポイント（常時起動するHTTPS API） としてデプロイします。
アプリケーションはこのエンドポイントにデータを送ると、ミリ秒単位で予測が返ってきます。
常時インスタンスが起動しているため低レイテンシですが、その分アイドル時もコストが発生します。

エンドポイントは内部で モデルサーバー がリクエストを受け、モデルアーティファクト（Vol2 で学習・登録したモデル）をロードして推論します。
構成は「エンドポイント設定（インスタンスタイプ・台数・バリアント）」と「モデル」を分けて定義するため、モデルだけを差し替える、台数だけ増やす、といった柔軟な運用ができます。
レイテンシ要件が厳しいAPI、たとえばユーザー操作に即応する不正検知やレコメンドでは、このリアルタイム推論が基本の選択肢になります。

3-2. Auto Scaling（自動スケーリング）

トラフィックの増減に応じてインスタンス数を自動調整するのが Auto Scaling です。
InvocationsPerInstance（インスタンスあたりの呼び出し数）などのメトリクスをターゲットに設定し、負荷が上がればスケールアウト、下がればスケールインします。
「昼間はアクセスが多く夜間は少ない」といった変動に対し、コストと性能を両立できます。
ターゲット追跡スケーリングの設定は、たとえば次のように指定します。

# インスタンスあたり毎分70リクエストを目標にスケール
target_tracking = {
 "TargetValue": 70.0,
 "PredefinedMetricSpecification": {
  "PredefinedMetricType": "SageMakerVariantInvocationsPerInstance"
 },
 "ScaleInCooldown": 300,
 "ScaleOutCooldown": 60,
}

3-3. プロダクションバリアントとA/Bテスト

1つのエンドポイントには、複数のモデルを プロダクションバリアント（production variant） として配置し、トラフィックを割り振れます。
たとえば既存モデル90%・新モデル10%という比率でトラフィックを振り分ければ、本番環境で A/Bテスト ができます。
新モデルの性能が確認できたら、徐々に比率を上げて切り替えます。
この仕組みは、後述するカナリアデプロイの基盤にもなります。

4. バッチ変換・非同期推論・サーバーレス推論

4-1. バッチ変換（Batch Transform）

バッチ変換は、常時起動するエンドポイントを持たず、S3 上の大量データをまとめて推論する方式です。
処理が終わるとインスタンスは自動停止するため、定期的な大量予測でコスト効率に優れます。
「毎晩、全顧客の解約予測を一括で出したい」といったシナリオの定番解です。
大きな入力ファイルを分割して複数インスタンスに並列処理させることもでき、数百万件規模の予測も現実的な時間で完了します。
リアルタイム推論のように低レイテンシは得られませんが、1件あたりの推論コストを最小化 できる点が最大の利点です。

4-2. 非同期推論（Asynchronous Inference）

非同期推論は、リクエストを 内部キューに入れて順次処理 し、結果を S3 に出力する方式です。
1件あたりの処理に時間がかかる、あるいは入力データが大きい（最大1GB）場合に向きます。
リクエストがないときはインスタンスを ゼロまで縮小 できるため、コストも抑えられます。
「大きな画像や動画を推論したいが、即レスポンスは不要」という場面で選びます。

4-3. サーバーレス推論（Serverless Inference）

サーバーレス推論は、リクエストが来たときだけ自動でリソースを起動し、アイドル時の課金が発生しない 方式です。
インスタンス管理が不要で、トラフィックに応じて自動スケールします。
「アクセスが読めない・断続的で、アイドルコストを払いたくない」場面に最適です。
ただし起動時に コールドスタート の遅延が生じる点には注意が必要です。
コールドスタートを抑えたい場合は Provisioned Concurrency（プロビジョンド同時実行） で一定数のインスタンスを温めておく選択肢もあります。

5. Inference Components — 複数モデルのリソース効率化

近年追加された Inference Components（推論コンポーネント） は、1つのエンドポイントに 複数のモデルを効率よく同居 させ、それぞれに必要なリソース（CPU/GPU/メモリ）を割り当てる仕組みです。
モデルごとに個別のエンドポイントを立てると、アイドルなインスタンスが増えてコストが膨らみます。
Inference Components を使えば、1つのエンドポイントのリソースを複数モデルで共有 し、利用率を最大化できます。
さらにモデル単位でのスケーリング（必要なモデルだけ増やす）も可能です。
「多数のモデルを低コストで運用したい」という課題に対する新しい答えです。

具体的には、各 Inference Component に「必要なCPUコア数・メモリ・GPU(アクセラレータ)数」を指定し、エンドポイントの空きリソースに パズルのように敷き詰めて 配置します。
人気のあるモデルだけコピー数を増やし、使われないモデルはゼロまで縮小する、といった柔軟な制御ができます。
従来の「1モデル=1エンドポイント」と比べ、GPU の利用率を大幅に高められるのが利点です。

6. Multi-model Endpoint vs Multi-container Endpoint

複数モデルを1エンドポイントに載せる仕組みには、目的の異なる2方式があります。

「同じ型のモデルが何百個もある」なら MME、「異なる種類のモデルを少数まとめたい」なら Multi-container、という使い分けです。

なお Multi-container Endpoint には2つの呼び出しモードがあります。
コンテナを個別に指定して呼ぶ 直接呼び出し（Direct） と、複数コンテナを順に通す シリアル推論パイプライン（Serial Inference Pipeline） です。
後者は「前処理コンテナ → 推論コンテナ → 後処理コンテナ」のように、複数ステップを1エンドポイント内でつなぎたいときに使います。

7. MLOpsパイプライン — SageMaker Pipelines・Model Registry

モデルのデプロイを手作業で行うと、ミスや再現性の欠如が問題になります。
そこで MLOps（機械学習版のDevOps） として、学習からデプロイまでを自動化します。

7-1. SageMaker Pipelines

SageMaker Pipelines は、ML ワークフロー（前処理→学習→評価→登録→デプロイ）を 一連の自動パイプライン として定義・実行するサービスです。
各ステップを有向グラフ（DAG）でつなぎ、条件分岐（例: 「精度が基準未満なら登録しない」）も組めます。
コードでパイプラインを定義するため、再現性とバージョン管理 が確保されます。
たとえば「前処理 → 学習 → 評価 → 評価指標が0.9以上なら Model Registry へ登録、未満なら停止」という品質ゲートを組み込めば、基準を満たさないモデルが本番候補に混じることを自動で防げます。
手作業のデプロイでは避けられない「うっかり低品質モデルを出す」事故を、仕組みで排除できるのが MLOps の本質です。

7-2. Model Registry と承認フロー

SageMaker Model Registry は、学習したモデルを バージョン管理し、承認ステータスを付けて管理 する仕組みです。
「評価に合格したモデルだけを Approved にし、本番デプロイは承認済みモデルに限る」という ガバナンス（統制） を実現します。
これにより、品質を満たさないモデルが誤って本番に出る事故を防げます。

7-3. SageMaker Projects と CI/CD

SageMaker Projects は、MLOps のテンプレートを提供する仕組みです。
CodePipeline・CodeBuild・CodeCommit と連携し、コードのコミットを起点に学習〜デプロイまでを自動実行する CI/CD を構築できます。
「モデルのコードを更新したら自動で再学習・評価・デプロイまで回したい」という継続的デリバリーのシナリオで登場します。
Pipelines が ML ワークフロー単体を定義するのに対し、Projects はそれを リポジトリ・ビルド・デプロイのパイプラインに組み込んだ全体像 として提供します。両者の役割の違いを押さえましょう。

7-4. Step Functions との連携

より複雑な分岐や他サービス連携が必要な場合は、AWS Step Functions でワークフローをオーケストレーションする選択肢もあります。
SageMaker 内で完結するなら Pipelines、AWS の多サービスをまたぐ複雑な制御なら Step Functions、という整理です。

8. デプロイ戦略 — Blue/Green・Canary・Shadow

新しいモデルへ切り替える際、いきなり全トラフィックを移すのはリスクがあります。
学習時の評価で高精度でも、本番の実データでは想定外の挙動を示すことがあるからです。
そこで、影響範囲を限定しながら段階的に切り替える デプロイ戦略 が問われます。
各戦略は「切替の速さ」と「リスクの低さ」のトレードオフで整理できます。

SageMaker のエンドポイント更新では、これらの戦略を デプロイガードレール（Deployment Guardrails） として設定できます。
新モデルへの移行中に CloudWatch アラーム（エラー率の急増など）が発火したら、自動で旧モデルへロールバック する仕組みです。
「デプロイ後に問題が起きたら自動で切り戻したい」という設問では、このデプロイガードレールと自動ロールバックが答えになります。

9. SageMaker Neo・エッジデプロイ

クラウドだけでなく、エッジ（端末側）でモデルを動かす場面も出題されます。

• SageMaker Neo — 学習済みモデルを 特定のハードウェア向けに最適化（コンパイル） し、推論を高速化・軽量化するサービス。同じモデルを各種デバイス（クラウド/エッジ）向けに変換できます。
• エッジデプロイ — IoT デバイスや工場の端末など、ネットワークが不安定だったり低レイテンシを要したりする 環境でモデルをローカル実行します。Neo で最適化したモデルを配布するのが定番です。

「IoTデバイス上で低レイテンシ推論したい」「モデルを各種ハードに最適化したい」というシナリオでは Neo が答えになります。

Neo の価値は、学習に使ったフレームワーク（TensorFlow/PyTorch等）に縛られず、ターゲットのハードウェアに合わせて実行を最適化 できる点にあります。
同じモデルを、クラウドの GPU 向けにも、エッジの ARM チップ向けにも変換でき、推論速度の向上とメモリ使用量の削減を同時に実現します。
エッジ側では AWS IoT Greengrass と組み合わせ、ネットワークが切れても端末単体で推論を続けられる構成が定番です。

10. まとめ — Vol4「監視・保守・セキュリティ」へ

本記事では、MLA-C01 の D3「モデルのデプロイ・推論」を、推論オプションから MLOps・デプロイ戦略まで体系的に整理しました。
D3 は出題比率22%と決して小さくなく、特に推論4オプションの使い分けは合否を分ける頻出論点です。
シナリオから「レイテンシ要件・トラフィック特性・データ量」を読み取り、最適な方式を即答できるよう繰り返し演習しておきましょう。

モデルを本番提供できたら、最後はそれを 安定して運用し続ける 工程です。
Vol4「監視・保守・セキュリティ・コスト」（D4/24%・公開中） では、Model Monitor によるドリフト検知、IAM/KMS によるセキュリティ、Savings Plans によるコスト最適化を解説します。

知識をインプットしたら、必ず問題演習でアウトプットしましょう。
CertTrend LMS には MLA-C01 の出題範囲を網羅した 400問のオリジナル問題 を収録し、D3 の各論点を本番形式で診断できます。
正答理由だけでなく すべての誤答がなぜ誤りか を AWS 公式ドキュメントに基づいて解説しているため、「わかったつもり」を確実に解消できます。