公開更新 AWS

SageMakerとは？SageMaker AIへの改称とPython SDK v3移行を実装手順で解説

SageMakerとは？SageMaker AIへの改称とPython SDK v3移行を実装手順で解説

Amazon SageMakerは、AWSが提供するフルマネージドの機械学習サービスです。学習用のインスタンスで訓練を回し、できたモデルを推論エンドポイントとして公開するまでを、サーバーの構築なしに進められます。ただし2024年12月3日に名前の付け替えがあり、いま「SageMaker」で出てくる情報は、旧来のサービスを指すものと統合プラットフォームを指すものが混ざっている。この記事では、その切り分け、Python SDK 3.21.0で Estimator が非サポートになった破壊的変更と書き換えコード、学習と推論を動かす最小の手順、無料利用枠と課金単位、Vertex AIやAzure Machine Learningへ寄せるべき場面までを、公式ドキュメントを出典として整理しました。

まとめ：SageMakerが指す対象は2つ、実装で触るのはSageMaker AI側

AWSの開発者ガイドには、2024年12月3日にAmazon SageMakerがAmazon SageMaker AIへ改称されたと明記されています。同じ日に、データ・分析・AIを束ねる次世代のプラットフォームとして、新しい「Amazon SageMaker」が別に立ち上がった。つまり現在は、機械学習の学習と推論を担う従来のサービスが「SageMaker AI」、その上位にあるデータ基盤込みの傘が「SageMaker」という二層構造になっています。

学習ジョブを投げてエンドポイントを作る作業で触るのは、下の層のSageMaker AIです。改称でAPIの名前空間が変わることはなく、sagemaker というAPI名前空間、AWS CLI、AWS::SageMaker のCloudFormationリソースはすべて従来どおり動きます。既存のIaCコードを書き換える必要はありません。

一方で、コード側には別の断層が来ています。Python SDKがメジャーバージョンを上げ、Estimator・Model・Predictor とフレームワーク別のクラス群がv3では非サポートになりました。ネット上のサンプルの大半はv2前提なので、そのまま貼ると ImportError で止まる。新規に書くなら ModelTrainer と ModelBuilder、既存資産を動かすなら pip install sagemaker==2.* でv2に固定する2択です。

2024年12月の改称でSageMakerという語が指す対象が2つに分かれた

用語を先に整理しておくと、以降のドキュメント読みが速く進みます。

SageMaker AIへの改称で変わらなかったAPI名前空間とIAMポリシー

改称は表示名の変更にとどまります。開発者ガイドには、後方互換のために据え置かれた対象として、AWS CLIコマンド、AmazonSageMaker 接頭辞のマネージドポリシー、sagemaker を含むサービスエンドポイント、AWS::SageMaker 接頭辞のCloudFormationリソース、AWSServiceRoleForSageMaker のサービスリンクロール、コンソールURL、ドキュメントURLが列挙されています。

実務上の意味は明確です。Terraformの aws_sagemaker_endpoint もboto3の boto3.client("sagemaker") も、改称の前後で書き換えは要りません。変わったのは、コンソールとドキュメントに表示される名前だけです。

次世代SageMakerが束ねるLakehouseとUnified Studioの範囲

上位の傘となった新しいAmazon SageMakerは、開発者ガイドの記述では次の要素で構成されます。機械学習の枠を超えてデータ分析側まで取り込んだ形です。

構成要素 担当する範囲
SageMaker AI（旧SageMaker） MLモデルと基盤モデルの構築・学習・デプロイ
SageMaker Lakehouse S3やRedshiftへの統一アクセス
Data and AI Governance DataZone基盤のカタログで統制
SQL Analytics RedshiftによるSQLでの分析
SageMaker Data Processing AthenaやEMR、Glueでの前処理
SageMaker Unified Studio 分析とAIを1つに束ねた開発環境
Amazon Bedrock 生成AIアプリケーションの構築とスケール

データ側の入り口となるLakehouseはAmazon SageMaker Lakehouseの概要と基本的な特徴で扱っています。本記事が対象にするのは、表の1行目にあたるSageMaker AIの範囲です。

SageMaker AIの学習・推論・ノートブックの機能構成を実装単位で確認する

最小構成で回すなら押さえる箱は3つです。データを触るノートブック、訓練を回す学習ジョブ、結果を公開する推論エンドポイント。

ノートブック・学習ジョブ・推論エンドポイントという3つの課金単位

3つは独立したインスタンスの上で動き、独立して課金されます。1つのサービスとして捉えると請求の読み方を誤るため、別々に数えてください。

ノートブックはJupyter環境で、開いている間ずっとインスタンス料金が掛かる。学習ジョブは CreateTrainingJob の呼び出しで一時的にインスタンスが立ち上がり、スクリプトが終了すると自動で落ちます。使った分だけの秒課金です。推論エンドポイントは常時起動で、リクエストの有無に関わらず時間課金が続きます。止め忘れが最も痛いのは、このエンドポイントになります。

組み込みアルゴリズムと持ち込みコンテナのどちらで始めるかの判断

学習の実体はコンテナです。SageMaker AIはXGBoostや線形学習器などの組み込みアルゴリズムをコンテナイメージとして用意しており、データのS3パスとハイパーパラメータを渡すだけで訓練が始まります。表形式データの分類や回帰なら、この経路が最短。

PyTorchやTensorFlowで書いた自前のコードを回す場合は、AWSが管理するフレームワークコンテナに訓練スクリプトを渡します。依存ライブラリが特殊で既製のイメージに収まらないときだけ、自前のDockerイメージをAmazon ECRへ置いて指定してください。学習済みモデルを持ってくる用途ではAmazon SageMaker JumpStartの使い方｜SDK v3移行とデプロイ費用のJumpStart経路も選べます。

Python SDK v3をインストールしてEstimator廃止の影響範囲を確かめる

ここからが、既存コードを持つ人には本題です。SDKのメジャーが上がり、v2の中心にあったクラスがv3では消えました。

sagemaker 3.21.0の導入手順と対応Pythonバージョンの確認

PyPIのsagemakerパッケージで公開されている版は3.21.0（2026年8月25日公開）でした。READMEでは動作検証済みのPythonとして3.10・3.11・3.12が挙げられており、メタデータ上も3.10以上が必須です。3.9以下では入りません。

# 仮想環境を分けてから入れる
python -m venv .venv && . .venv/bin/activate

# v3を入れる場合
pip install "sagemaker>=3.21.0"
python -c "import sagemaker; print(sagemaker.__version__)"

# 既存のv2コードを動かし続ける場合はメジャーを固定する
pip install "sagemaker==2.*"

v3は単一パッケージではなく、sagemaker-core・sagemaker-train・sagemaker-serve・sagemaker-mlops の4つに分割されています。公式の移行ガイドには、必要な機能だけを個別に入れる指定も示されている。推論しか使わないコンテナイメージなら sagemaker-core と sagemaker-serve だけを入れる形にすると、イメージサイズを削れるでしょう。

# 用途ごとに必要なサブパッケージだけを入れる
pip install sagemaker-core sagemaker-train sagemaker-serve sagemaker-mlops

v2からv3へ置き換えが必要になったクラスと代替クラスの対応表

移行ガイドが示す対応関係は次のとおりです。フレームワーク別のクラスが1本に統合されたのが最大の変更点で、PyTorch や TensorFlow を import している箇所はすべて書き換えの対象になります。

v2のクラス v3での代替 用途
Estimator ModelTrainer 学習ジョブ全般
PyTorch・TensorFlow ほか ModelTrainer と image_uris フレームワーク別の学習
Model ModelBuilder モデルのデプロイ
Predictor sagemaker-core経由のエンドポイント 推論の呼び出し
HuggingFaceModel ModelBuilder HuggingFaceモデルの推論

import文も変わります。from sagemaker.estimator import Estimator は from sagemaker.train import ModelTrainer に、from sagemaker.model import Model は from sagemaker.serve import ModelBuilder に、イメージURIの取得は from sagemaker.core import image_uris になります。学習コードをリポジトリで管理する場合の連携設定はAmazon SageMakerとGitHubの連携手順｜3経路の設定とPAT権限にまとめました。

移行前にv2固有のimportが残る参照箇所を洗い出す進め方

影響範囲は機械的に洗えます。次の検索を掛け、ヒットしたファイルを移行対象のリストにしてください。ノートブック（.ipynb）にも同じパターンが埋まっているため、拡張子を絞らずに走らせます。

# v2固有のimportが残っている箇所を洗い出す
grep -rn "from sagemaker.estimator\|from sagemaker.model\|from sagemaker.predictor" . \
  --include="*.py" --include="*.ipynb"

# フレームワーク別クラスの利用も対象になる
grep -rn "sagemaker.pytorch\|sagemaker.tensorflow\|sagemaker.huggingface" . \
  --include="*.py" --include="*.ipynb"

ヒットが数十を超えるなら、SDKをいきなり上げずv2固定で運用を続け、新規のコードからv3へ寄せる進め方が現実的です。SDKのバージョンは学習ジョブのコンテナ内にも入るため、requirements.txt側の固定も忘れずに揃えてください。

ModelTrainerで学習ジョブを投げるコードをv2から書き換える

v3の設計は、引数をずらりと並べるクラスベースから、役割ごとの設定オブジェクトを組み立てる形へ変わりました。

EstimatorのパラメータをCompute・SourceCodeへ分解する

v2の Estimator は、インスタンス種別も出力先もハイパーパラメータも1つのコンストラクタに渡す作りでした。v3では計算資源が Compute、訓練スクリプトの場所が SourceCode、入力データが InputData と、目的別のオブジェクトに分かれます。移行ガイドが示す前後のコードを並べると差が掴めるでしょう。

# v2（Estimator・v3では非サポート）
from sagemaker.estimator import Estimator
from sagemaker.inputs import TrainingInput

estimator = Estimator(
    image_uri="123456789012.dkr.ecr.us-west-2.amazonaws.com/my-training-image",
    role="arn:aws:iam::123456789012:role/SageMakerRole",
    instance_count=1,
    instance_type="ml.m5.xlarge",
    volume_size=30,
    output_path="s3://my-bucket/output",
    hyperparameters={"epochs": 10, "batch_size": 32},
)
estimator.fit(TrainingInput("s3://my-bucket/train"))
# v3（ModelTrainer）
from sagemaker.train import ModelTrainer
from sagemaker.train.configs import SourceCode, Compute, InputData

compute = Compute(
    instance_type="ml.m5.xlarge",
    instance_count=1,
    volume_size_in_gb=30,
)
source_code = SourceCode(
    source_dir="./src",
    entry_script="train.py",
)
model_trainer = ModelTrainer(
    training_image="123456789012.dkr.ecr.us-west-2.amazonaws.com/my-training-image",
    role="arn:aws:iam::123456789012:role/SageMakerRole",
    source_code=source_code,
    compute=compute,
    hyperparameters={"epochs": 10, "batch_size": 32},
)
train_data = InputData(channel_name="train", data_source="s3://my-bucket/train")
model_trainer.train(input_data_config=[train_data])

引数名も揃っていません。image_uri が training_image、volume_size が volume_size_in_gb、fit() が train() です。単純な置換では通らないため、1本ずつ手で移す前提で見積もってください。

フレームワーク別クラスをimage_urisでのイメージ取得に置き換える

PyTorch や TensorFlow のクラスは、内部でフレームワーク版に対応するコンテナイメージを解決していました。v3ではその解決を image_uris.retrieve で明示的に行い、得られたURIを ModelTrainer に渡します。V3ドキュメントの学習ページにフレームワーク別の書き方が載っています。

# v3でPyTorchのフレームワークコンテナを使う
from sagemaker.train import ModelTrainer
from sagemaker.train.configs import SourceCode, Compute
from sagemaker.core import image_uris

training_image = image_uris.retrieve(
    framework="pytorch",
    region="ap-northeast-1",
    version="1.12.0",
    py_version="py38",
    instance_type="ml.p3.2xlarge",
    image_scope="training",
)

model_trainer = ModelTrainer(
    training_image=training_image,
    source_code=SourceCode(source_dir="./src", entry_script="train.py"),
    compute=Compute(instance_type="ml.p3.2xlarge", instance_count=1),
    hyperparameters={"epochs": 10, "lr": 0.001},
)

フレームワーク版とPython版の組み合わせは、イメージが用意されているものだけが通ります。retrieve が例外を返すなら、指定した版のイメージがそのリージョンに無いということなので、対応版を落として試してください。

ModelBuilderでモデルをデプロイしエンドポイントへ推論リクエストを送る

学習が終わったら、モデルを推論エンドポイントとして公開します。v2の Model と deploy() は、v3では ModelBuilder に集約されました。

InferenceSpecでイメージとモデルデータを指定してデプロイする

移行ガイドでは、推論用イメージとS3上のモデルデータを InferenceSpec にまとめ、ModelBuilder へ渡してから deploy() を呼びます。インスタンス種別と台数はデプロイ時の引数です。

# v3（ModelBuilder）
from sagemaker.serve import ModelBuilder
from sagemaker.serve.configs import InferenceSpec

inference_spec = InferenceSpec(
    image_uri="123456789012.dkr.ecr.us-west-2.amazonaws.com/my-inference-image",
    model_data_url="s3://my-bucket/model.tar.gz",
)

model_builder = ModelBuilder(
    inference_spec=inference_spec,
    role="arn:aws:iam::123456789012:role/SageMakerRole",
)

predictor = model_builder.deploy(
    instance_type="ml.m5.large",
    initial_instance_count=1,
)

デプロイの完了までは数分掛かり、ステータスが InService になって初めて呼び出せます。Creating の間にリクエストを投げると失敗するため、CI上で連続実行する場合はステータスのポーリングを挟んでください。

boto3から推論エンドポイントを呼び出して応答を確かめる手順

SDKを介さず推論を呼ぶ経路も用意しておくと、アプリ側の実装が軽くなります。エンドポイント名さえ分かっていれば、boto3の sagemaker-runtime クライアントから直接叩け、SDKのバージョン差の影響も受けません。

import boto3
import json

runtime = boto3.client("sagemaker-runtime", region_name="ap-northeast-1")

response = runtime.invoke_endpoint(
    EndpointName="my-endpoint",
    ContentType="application/json",
    Body=json.dumps({"instances": [[5.1, 3.5, 1.4, 0.2]]}),
)

print(json.loads(response["Body"].read().decode("utf-8")))

アプリケーション側はこの形にしておき、SageMakerのSDKは学習とデプロイのパイプラインにだけ置く。役割を分ければ、SDKのメジャー更新が本番のリクエスト経路へ波及しません。呼び出し元のIAMロールには sagemaker:InvokeEndpoint の許可が要ります。

課金単位と無料利用枠を押さえてエンドポイントの消し忘れを防ぐ手順

請求は使ったインスタンスの時間で積み上がります。検証で失敗しやすいのは、学習ジョブではなく推論エンドポイントの側です。

2か月間の無料利用枠に含まれる時間数とインスタンス種別の確認

SageMaker AIの料金ページには、利用開始から2か月間の無料枠が用途別に示されています。時間数がそれぞれ独立している点に注意してください。

用途 無料枠の内容
Studioノートブック・ノートブックインスタンス ml.t3.medium を250時間
学習（トレーニング） m4/m5.xlarge を50時間
リアルタイム推論 m4/m5.xlarge を125時間
サーバーレス推論 オンデマンドの推論時間を150,000秒
Feature Store 読み書き各1,000万・25GB

250時間は一見多く見えますが、ノートブックを開きっぱなしにすると10日ほどで枠を使い切る計算になる。触らない時間帯にインスタンスを止める運用を、検証の初日から入れておいてください。

常時起動の推論エンドポイントを止め忘れたときの請求額の増え方

リアルタイム推論のエンドポイントは、リクエストがゼロでも起動している限り課金されます。ml.m5.large 相当を1台立てたまま1か月放置すれば、720時間ぶんの時間課金がそのまま乗る。学習ジョブが自動で落ちるのとは挙動が違います。

検証が終わったら、その場で消してください。削除はCLIから1行。エンドポイントの構成も別リソースとして残るので併せて片付けます。

# 起動中のエンドポイントを一覧して消す
aws sagemaker list-endpoints --region ap-northeast-1 \
  --query "Endpoints[].[EndpointName,EndpointStatus]" --output table

aws sagemaker delete-endpoint --endpoint-name my-endpoint --region ap-northeast-1
aws sagemaker delete-endpoint-config --endpoint-config-name my-endpoint-config --region ap-northeast-1

トラフィックが断続的で応答の遅れを許せるなら、サーバーレス推論もあります。料金ページの記述では処理に使った計算容量がミリ秒単位で課金され、データ処理は1GBあたり0.016ドル。常時起動の時間課金が消える代わりに、コールドスタートの待ち時間が入ります。

本番でエンドポイントを常時動かす段階になったら、Savings Plansの検討に入ります。料金ページには、Studio・処理・学習・推論といった機能へ自動適用され、最大64%のコスト削減になると記載されています。ただし1年または3年の利用コミットが前提なので、購入は構成が固まってからにしてください。

SageMakerを採用してよい条件とVertex AIへ寄せるべき場面の線引き

どの案件でSageMakerを選び、どこでは選ばないのかを言い切っておきます。

データがAWS上にある場合にSageMakerを選ぶべき3つの条件

採用してよいのは、次の3つが揃うときです。第1に、学習データの置き場がすでにAmazon S3で、IAMによる権限管理が組まれていること。アクセス制御をそのまま流用できるため、他クラウドのML基盤を持ち込むより工数が小さくなります。

第2に、モデルを常時オンラインで提供する必要があり、推論の台数が読めること。エンドポイントの時間課金はコストを予測しやすく、Savings Plansで単価も下げられます。第3に、学習と推論をIaCへ載せる予定があること。AWS::SageMaker のCloudFormationリソースが揃っているので、他のAWSリソースと同じコードベースで管理できます。

逆に3条件のいずれも当てはまらないなら、無理に寄せないでください。単発のモデル検証を回すだけなら、ノートブック環境を自前で立てるほうが速く済みます。

Vertex AIやAzure Machine Learningへ寄せたほうがよい場面

データウェアハウスがBigQueryにあるなら、Google Cloud側へ寄せる判断が立ちます。学習データを別クラウドへ持ち出す転送コストと、権限設計を二重に持つ運用負荷が消えるためです。機能の対応関係はVertex AIとは？Google CloudのAI開発プラットフォームの機能・料金とSageMaker/Azure MLとの違いを実装者目線で解説で整理しています。

認証基盤がMicrosoft Entra IDで業務データがAzure上にある組織も同様で、この場合はAzure Machine Learningのほうが権限まわりの設計が短く済みます。判断材料はAzure Machine Learningとは？料金・できること・SageMakerとの違いと導入判断にまとめました。分岐点は「学習データがどのクラウドに置かれているか」の一点で、ML機能の細かな優劣より先にここで決まります。

SDK移行と推論基盤の設計を外部の開発会社へ任せる場合の依頼範囲

SDK v2で書かれた学習コードが数十本ある、推論エンドポイントのコストが読めないまま本番へ進めない、という段階で手が止まることがあります。移行の影響範囲を洗い出す作業と、推論構成をサーバーレスと常時起動のどちらに置くかの試算は、実装前に片付けておきたい部分です。当社では機械学習モデル開発として、学習パイプラインの構築から推論基盤の設計・運用まで請けています。既存コードのv3移行だけを切り出した相談も承ります。

よくある質問

導入検討でよく挙がる質問を、公式ドキュメントの記述に沿って整理しました。

SageMakerとSageMaker AIは別のサービスですか？

元は同じサービスです。2024年12月3日に、従来のAmazon SageMakerがAmazon SageMaker AIへ改称されました。同じ日にAWSが発表した次世代のAmazon SageMakerは、SageMaker AIやLakehouseを束ねる上位のプラットフォームで、こちらは別の対象を指します。学習や推論を扱う文脈の「SageMaker」は、改称後の名前ではSageMaker AIのこと。API名前空間は sagemaker のまま据え置かれています。

SDKをv3へ上げると既存の学習コードは動かなくなりますか？

動きません。Estimator・Model・Predictor とフレームワーク別のクラスはv3では非サポートで、import の時点で失敗します。既存コードを触らずに済ませたいなら pip install "sagemaker==2.*" でメジャーバージョンを固定してください。移行するなら ModelTrainer と ModelBuilder への書き換えが要ります。引数名も変わっているため、置換ではなく1本ずつの移植になる。

無料利用枠だけでモデルの学習まで試せますか？

試せます。料金ページの記載では、利用開始から2か月間、ml.t3.medium のノートブックが250時間、m4.xlarge または m5.xlarge の学習が50時間ぶん無料です。表形式データを組み込みアルゴリズムで学習する規模なら、この枠に収まるでしょう。ただしGPUインスタンスは対象外で、ml.p3系を使った時点で課金が始まります。

推論エンドポイントの費用を抑える方法はありますか？

リクエストが断続的ならサーバーレス推論へ寄せる手があります。料金ページでは処理に使った計算容量がミリ秒単位で課金され、データ処理は1GBあたり0.016ドルと示されている。常時起動の時間課金が消えるぶん、待ち時間は増えます。検証段階では、使い終わったエンドポイントを aws sagemaker delete-endpoint で毎回消す運用が最も効きます。

学習用のコンテナイメージは自前で用意する必要がありますか？

多くの場合は不要です。XGBoostなどの組み込みアルゴリズムはAWS側でコンテナが用意されており、S3のデータパスとハイパーパラメータを渡すだけで学習が始まります。PyTorchやTensorFlowで書いたコードも、AWSが管理するフレームワークコンテナに訓練スクリプトを渡す形で回せる。自前のDockerイメージが要るのは、依存ライブラリが既製のイメージに収まらない場合に限られます。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.07.21　テックブログ Apache Tomcatの脆弱性一覧【2026年10月】最新版11.0.27・10.1.61・9.0.123とCVE-2026-59083ほかの影響確認・対応手順
  2. 2026.10.22　テックブログ Tomcatバージョン一覧とサポート期限【2026年10月】9.0系は2027年3月末で終了・9.1系と11.0系への移行判断
  3. 2026.10.21　テックブログ NEC委託先の不正アクセスとは｜顧客システム暗号化・情報漏えいの経緯と委託元が点検する正規アカウント
  4. 2026.05.15　テックブログ scrcpyの最新版は5.0｜ハードウェアデコード対応とインストール・使い方【2026年10月】
  5. 2026.10.21　テックブログ ふるさとチョイス不正アクセスで445万件流出：対象確認・パスワード変更と再開時期

RELATED POSTS 関連記事

一覧へ戻る

目次