SageMaker

SageMaker とは

Amazon SageMaker AI は、機械学習モデルの構築・学習・デプロイを一続きに行えるマネージドサービスである。Jupyter ノートブックでの実験から、推論エンドポイントの本番運用まで同じサービス内でつながる。

名前の扱いに注意がいる。2024 年 12 月 3 日、それまで機械学習サービスの名前だった Amazon SageMaker は Amazon SageMaker AI へ改称され、Amazon SageMaker という名前はデータ・分析・機械学習を束ねた上位プラットフォームの総称になった (2026 年 8 月時点)。一方で API 名前空間の sagemaker、CLI コマンド、AWS::SageMaker で始まる CloudFormation リソース、AmazonSageMaker で始まる IAM 管理ポリシー名は後方互換のため据え置かれている。コードや権限設定に現れる SageMaker は従来どおりの機械学習サービスを指し、公式資料やコンソールの SageMaker は上位プラットフォームを指す場合がある。この二重性を知らないまま社内資料を読み合わせると、同じ単語で別の話をしてしまう。

SageMaker の主要機能

SageMaker AI は機械学習の工程ごとに部品が分かれている。実験は SageMaker Studio で行い、学習は Training ジョブへ切り出して分散学習やスポットインスタンスを使う。学習済みモデルはリアルタイム推論のエンドポイント、またはバッチ推論の Batch Transform に回す。工程の自動化は Pipelines、特徴量の共有は Feature Store、モデルのバージョン管理は Model Registry、本番モデルの入力データやモデル品質のずれの監視は Model Monitor が担う。表形式データからの自動モデル構築は Autopilot だが、その画面は 2023 年 11 月 30 日以降 SageMaker Canvas 側へ移っているので、UI から探すときは Canvas を見る。

紛らわしいのが開発環境の名前である。SageMaker Studio は SageMaker AI の統合開発環境で、SageMaker Unified Studio は次世代 SageMaker のプラットフォーム全体 (データ処理・分析・機械学習) を 1 つの画面から扱う環境であり、別物である。「Studio が開けない」という相談は、どちらの Studio の話かを先に確かめないと噛み合わない。

Bedrock との使い分け

Bedrock との使い分けは、モデルを自分で持つかどうかで決まる。

観点	SageMaker AI	Bedrock
用途	カスタムモデルの学習・デプロイ	基盤モデル (LLM) の利用
モデル	自前で学習	Claude, Nova 等のプロバイダーモデル
インフラ	GPU インスタンスの管理	サーバーレス
コスト	インスタンス時間課金	トークン課金
推奨	独自データでの学習が必要	テキスト生成、要約、分類

境界は用途そのものより運用負荷で引く。基盤モデルを SageMaker AI のエンドポイントへ自前でデプロイすることもできるが、その瞬間から GPU インスタンスの選定・スケール・入れ替えは自分の仕事になる。Bedrock 側はそれを持たない代わりに、モデルの内部を触る自由もない。

SageMaker Endpoints

推論の受け口は 4 通りある。リアルタイムエンドポイントはインスタンスを立てたままにするので応答時間が最も安定する代わりに、リクエストが無い時間も課金される。Serverless Inference はリクエストが無い間エンドポイントを 0 まで縮めるため待機コストが消えるが、しばらく無通信だったあとの初回呼び出しには計算リソースの起動待ち (コールドスタート) が入る。Asynchronous Inference は受け付けたリクエストをキューへ入れて順に処理する方式で、最大 1 GB の入力や 1 時間規模の処理時間を扱えて、処理待ちが無い間はインスタンス数を 0 まで縮小できる。結果を後で受け取ってよいなら、エンドポイントを持たない Batch Transform が最も素直である。

Serverless Inference には構造上の制約がある。割り当てるメモリは 1024 MB から 6144 MB の 6 段階で、GPU・Multi-Model Endpoints・Model Monitor・VPC 構成といったリアルタイム推論向けの機能は使えない (2026 年 8 月時点)。1 エンドポイントの最大同時実行数は 200、1 リージョンで持てるサーバーレスエンドポイントは 50 が上限である。GPU が要る画像モデルや、コールドスタートを許容できない画面直結の推論は、最初からリアルタイム推論を選ぶ。コールドスタートだけを抑えたいなら Provisioned Concurrency でエンドポイントを温めておけるが、温めた分は課金されるので待機コストゼロという利点は薄れる。

Lambda + Bedrock vs SageMaker

Lambda + Bedrock と SageMaker AI のどちらに寄せるかは、扱うデータの型でおおよそ決まる。

ケース	推奨
テキスト生成、要約、翻訳	Lambda + Bedrock
画像分類、物体検出	SageMaker Endpoints
カスタムモデルの学習	SageMaker Training
表形式データの予測	SageMaker Autopilot

判断の順番は「基盤モデルの API で解けるか」を先に見て、解けない場合に「独自データでの学習が必要か」を見る。API を呼ぶだけで足りる用途に GPU エンドポイントを立てると、成果が出る前に待機時間の課金が積み上がる。

コスト最適化

学習ジョブは Managed Spot Training でオンデマンド比 最大 90% の削減になる。削減率は固定値ではなく、課金対象時間と実行時間の比 (1 - 課金時間 / 実行時間) で決まるので、中断が少ないインスタンスタイプや時間帯ほど大きくなる。前提として中断は起こるものなので、チェックポイントを Amazon S3 へ書き出して再開できるようにしておく。チェックポイントを持たない組込みアルゴリズムやマーケットプレイスのアルゴリズムは、待ち時間の上限 (MaxWaitTimeInSeconds) が 3600 秒に制限される。

推論側の待機コストは、前節のサーバーレスや非同期の選択で削る。小さなモデルを多数抱えている場合は Multi-Model Endpoints で 1 つのエンドポイントへ同居させ、インスタンス費用を分け合う手がある。ただし共有する推論コンテナは 1 つなので、フレームワークが揃ったモデル群でしか使えず、メモリに載っていないモデルへの初回リクエストは読み込み待ちが入る。

見積もりで最も外しやすいのは止め忘れである。学習ジョブは終われば課金も止まるが、リアルタイムエンドポイントと開発用のノートブックインスタンスは、誰も使っていなくても立っている限り時間課金が続く。検証で作ったエンドポイントを削除する手順を運用に組み込むだけで、無駄な請求の大半は消える。