Amazon SageMaker JumpStartの使い方｜SDK v3移行とデプロイ費用【2026年版】

Amazon SageMaker JumpStartは、公開・商用の学習済みモデルをカタログから選び、数行のコードで推論エンドポイントまで立ち上げられる機能です。ただし2026年8月時点で、この機能をめぐる前提は2024年頃の解説記事から3か所ずれています。サービス名がAmazon SageMaker AIへ変わったこと、Python SDKがv3で作り直されてJumpStartModelクラスごと消えたこと、そしてワンクリックで作られるのが従量課金ではなく時間課金のエンドポイントであることです。ここでは実際にSDKを両系統インストールして挙動を確認し、東京リージョンの公開単価を引いたうえで、選定からファインチューニング、Bedrockとの使い分けまでを整理します。SageMaker本体の構造とPython SDK v3の破壊的変更はSageMakerとは？SageMaker AIへの改称とPython SDK v3移行を実装手順で解説で整理しています。

まとめ

JumpStartは学習済みモデルの配布とデプロイ自動化を担う機能で、モデルやソリューションの利用自体に追加料金はかかりません。課金対象は裏で動くトレーニングインスタンスと推論インスタンスの時間です。ここが最大の落とし穴で、東京リージョンでml.g5.2xlargeの推論エンドポイントを1つ放置すると、時間単価2.197ドルが積み上がって月額1,581.84ドルになります。

実装面の分岐点はSDKの世代です。v2系（2.257.6）ではJumpStartModelとJumpStartEstimatorが現役ですが、v3系（3.18.0）ではこの2クラスが存在せず、JumpStartConfigとModelBuilder・ModelTrainerの組み合わせに置き換わりました。v2はimport時に非推奨警告を出す一方、v3はPyPIの成熟度分類子がAlphaのままです。既存プロジェクトは当面v2で維持し、新規に書き始めるコードはv3、いずれも検証環境でimportとデプロイを通してから移す進め方が現実的です。

そして最初のデプロイが止まる原因の大半は、コードではなくアカウント側にあります。GPUインスタンスのサービスクォータとゲートモデルのEULA同意です。以下、この順に見ていきます。

SageMaker JumpStartの現在地とカタログ規模

まず名前の整理が必要です。AWSのドキュメントは「On December 03, 2024, Amazon SageMaker was renamed to Amazon SageMaker AI.」と明記しており、機械学習の構築・学習・デプロイを担ってきた従来のAmazon SageMakerは2024年12月3日付でAmazon SageMaker AIになりました。同じ箇所で「この名称変更は既存の各機能名には適用されない」とも断っているので、JumpStartという機能名自体は変わっていません。現在「Amazon SageMaker」と言うとき、それはデータ・分析・AIを束ねた統合プラットフォームの名前を指し、その中核体験がAmazon SageMaker Unified Studioです。2024年以前の記事にある「SageMakerのJumpStart」という表現は、現在の呼び方ではSageMaker AIのJumpStartになります。Amazon SageMakerとGitHubの連携手順｜3経路の設定とPAT権限のように、コンソールの導線がSageMaker AI配下へ移った前提で読み直す必要がある領域は他にもあります。

基盤モデルのカタログ規模は公式ドキュメントに明記があり、2026年7月29日時点でオープンウェイトモデルが436本、AWS Marketplaceでの購読が前提の商用モデルが121本です。JumpStartが提供するのは基盤モデルだけではなく、同じページには組み込みアルゴリズムが135本、従来型の機械学習アルゴリズムが11本と別枠で並びます。カタログ全体の本数を語るときはこの内訳を混ぜないでください。またこの表は静的で、ドキュメント自身が「最新の情報はAPIかStudioのモデルハブで確認せよ」と断っています。実際のカタログはSageMakerの公開ハブから直接引けます。

import boto3

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

models, next_token = [], None
while True:
    params = {"HubName": "SageMakerPublicHub", "HubContentType": "Model"}
    if next_token:
        params["NextToken"] = next_token
    resp = sm.list_hub_contents(**params)
    models.extend(resp["HubContentSummaries"])
    next_token = resp.get("NextToken")
    if not next_token:
        break

print(len(models))

ListHubContentsの必須パラメータはHubNameとHubContentTypeの2つで、HubContentTypeが取り得る値はModel、Notebook、ModelReference、DataSet、JsonDocです。公開ハブにはModelとは別にModelReferenceの項目も並ぶため、上のコードのようにModelだけを数えた件数と、Studioの画面で見えるモデル数は一致しません。個別モデルの対応インスタンスや既定インスタンスを知りたいときはdescribe_hub_contentでHubContentDocumentを取り、SupportedInferenceInstanceTypesとDefaultInferenceInstanceTypeを読みます。この2つは後述するクォータ申請の対象を決める入力になります。

SDK v2とv3で別物になったJumpStartの呼び出し方

2026年のJumpStart実装で最も事故になりやすいのがここです。SageMaker Python SDKはv3系（初版3.0、2025年11月20日）で大きく作り直され、JumpStartの入口が丸ごと差し替わりました。既存記事のコードをそのまま動かすと、SDKの版によって成功とModuleNotFoundErrorに分かれます。以下のリリース日はいずれもPyPIの記録（UTC）です。

v2系のJumpStartModelとJumpStartEstimator

v2系の最新は2.257.6（2026年8月10日リリース）で、必要Pythonは3.9以上、PyPIの成熟度分類子はDevelopment Status :: 5 - Production/Stableです。デプロイは次の形です。

from sagemaker.jumpstart.model import JumpStartModel

model = JumpStartModel(model_id="huggingface-text2text-flan-t5-xl")
predictor = model.deploy()   # ゲートモデルは deploy(accept_eula=True)

print(predictor.predict("What is Southern California often abbreviated as?"))

ここで押さえるべきは、v2をimportした時点で次の警告が出るようになったことです。実際に2.257.6をインストールしてimport sagemakerを実行すると、標準エラーにSageMakerV2DeprecationWarningとして「You are using the SageMaker Python SDK v2, which is on path of deprecation. v3 is the actively developed major version.」が表示されます。CIのログを汚す場合は環境変数SAGEMAKER_SUPPRESS_V2_WARNING=1で抑止できますが、抑止はあくまで表示を消すだけで、移行が要らなくなるわけではありません。

v3系のJumpStartConfigとModelBuilder・ModelTrainer

v3系の最新は3.18.0（2026年7月30日リリース）で、必要Pythonは3.10以上です。パッケージ構成も変わり、sagemaker本体はコードを持たないメタパッケージになって、実体はsagemaker-core、sagemaker-train、sagemaker-serve、sagemaker-mlopsの4つに分割されました。JumpStartのクラスは、この4パッケージのwheelを全走査してもJumpStartModel・JumpStartEstimatorの定義が1件も見つかりません。v3環境でsagemaker.jumpstart.modelをimportするとModuleNotFoundError: No module named 'sagemaker.jumpstart'になります。代わりの書き方はこうです。

from sagemaker.core.jumpstart.configs import JumpStartConfig
from sagemaker.serve import ModelBuilder

config = JumpStartConfig(
    model_id="huggingface-text2text-flan-t5-xl",
    accept_eula=True,
)
builder = ModelBuilder.from_jumpstart_config(jumpstart_config=config)
builder.build()
endpoint = builder.deploy()

v2ではdeploy()の引数だったEULA同意が、v3ではJumpStartConfigのフィールドへ移りました。既定値はFalseなので、ゲートモデルを扱うなら明示が要ります。JumpStartConfigが持つフィールドはmodel_id、model_version、hub_name、hub_content_name、accept_eula、training_config_name、inference_config_nameの7つです。build()はモデルオブジェクトを返しますが、そのままdeploy()へ進むなら受け取る必要はありません。

学習側はModelTrainerが担当します。ここは公式ドキュメントが二重に実装とずれている箇所なので注意してください。まず本文は「Run estimator.fit()」と書いていますが、3.18.0の実装にModelTrainer.fitは存在せず、正しいメソッドはtrain(input_data_config, wait, logs)です。さらにコード例のほうも、input_data_configにチャネル名をキーにした辞書を渡しています。実際の型注釈はOptional[List[Union[Channel, InputData]]]で、trainはvalidate_callで包まれているため、辞書を渡すとValidationError: Input should be a valid list でpydanticが弾きます。動く形はリストです。

from sagemaker.core.jumpstart.configs import JumpStartConfig
from sagemaker.core.training.configs import InputData
from sagemaker.train import ModelTrainer

config = JumpStartConfig(model_id="huggingface-textgeneration1-gpt-j-6b")
trainer = ModelTrainer.from_jumpstart_config(jumpstart_config=config)
trainer.train(input_data_config=[
    InputData(channel_name="train", data_source="s3://your-bucket/train/"),
    InputData(channel_name="validation", data_source="s3://your-bucket/validation/"),
])

つまりv3への移行では、ドキュメントの散文もコード例も鵜呑みにできません。移行時は必ず手元でシグネチャと型注釈を確認してください。

v2とv3のどちらを使うかの判断

結論を先に言うと、2026年8月時点では既存プロジェクトをv3へ急いで動かす理由は薄いと考えます。理由は3つあります。

1つ目は成熟度の表示です。3.18.0のPyPI分類子はDevelopment Status :: 3 - Alphaのままで、同時期にリリースされた2.257.6は5 - Production/Stableで、対照は明確です。AWS側がv2を非推奨経路と宣言しながら、後継の分類子はAlphaに据え置かれている状態が続いています。

2つ目は手元で再現できる不具合です。リージョンを設定していない環境でfrom sagemaker.serve import ModelBuilderを実行すると、import自体がNoRegionError: You must specify a region. で失敗します。原因はsagemaker/ai_registry/air_hub.pyの31行目にあるboto3.client("sagemaker")で、クラス本体＝モジュール読み込み時に評価される位置に書かれているためです。AWS_DEFAULT_REGIONを与えれば通ります。同じ条件でv2のJumpStartModelのimportは成功しました。リージョンをコード内で明示的に渡す設計のCIや、静的解析だけを回すジョブでは、これだけで落ちる構造です。

3つ目は移行情報の不足です。リポジトリの移行ガイドはJumpStartの2クラスを「REPLACED」と分類していますが、v2のサポート終了日は書かれていません。期限が示されていない以上、本番を動かしている側が先に動く必要はありません。新規に書き始めるコードはv3で、既存の資産はv2で維持しつつ、検証環境でv3のimportとデプロイを通してから移す進め方が安全です。

表の「import時のリージョン要求」は3.18.0で実測した挙動であり、将来の版で修正される可能性があります。移行前に自分の版で再現するか確かめてください。

最初のデプロイが止まる2つの関門

よくある導入記事はモデル選択からデプロイ成功までを一直線に描きますが、新しいアカウントで同じ手順を踏むと、コードに問題がなくてもデプロイが失敗します。原因はほぼこの2つです。

インスタンスのサービスクォータ

AWS一般リファレンスのService Quotas一覧には、ml.g5.2xlarge for endpoint usageの既定値が「Each supported Region: 0」、調整可否が「Yes」と記載されています。0ということは、そのままではそのインスタンスタイプでエンドポイントを1台も作れないという意味です。同じページは「The default quotas in this page are based on new accounts.」と断っており、あくまで新規アカウント基準の値なので、判断はService Quotasで自分のアカウントの実値を見てから行います。

aws service-quotas list-service-quotas \
  --service-code sagemaker \
  --query "Quotas[?contains(QuotaName, 'g5.2xlarge for endpoint usage')].[QuotaCode, Value]" \
  --output text

ここで返る値が0なら、デプロイ前に引き上げ申請が必要です。申請対象は「endpoint usage」「training job usage」「notebook instance usage」のように用途別に分かれているので、推論だけ通してファインチューニングで再び止まる例が珍しくありません。学習まで行う予定なら、前節のdescribe_hub_contentで確認した既定インスタンスについて、推論と学習の両方を同時に申請しておくと手戻りが減ります。

ゲートモデルのEULA同意

公開モデルのうち一部は非公開のS3バケットに置かれた「ゲートモデル」で、EULAへの同意なしにはアクセスできません。同意はSDKから行いますが、既定の挙動は「ユーザーがEULAに同意すれば、そのユーザーはモデルにアクセスでき、ファインチューニングのトレーニングジョブも作成できる」というものです。つまり個々の開発者の同意だけで学習まで走ります。

組織としてゲートモデルの学習利用を制限したい場合は、IAM側で条件キーsagemaker:DirectGatedModelAccessがtrueのときのsagemaker:CreateTrainingJobを明示的にDenyします。特定モデルだけ許可したいなら、プライベートなキュレーテッドハブを作って対象モデルを登録する運用になります。ライセンス条件そのものはモデルごとに違うため、商用利用の可否はdescribe_hub_contentで取れるライセンス表記ではなく、提供元の原文を確認してから判断してください。

東京リージョンの実費とエンドポイント放置の損失

公式の料金ページは「There is no additional charge for using JumpStart models or solutions.」と明記しています。JumpStartそのものは無料で、請求されるのは手動で作った場合と同じトレーニングインスタンスと推論インスタンスの時間です。ワンクリックデプロイという言葉から従量課金を連想すると、ここで見誤ります。作られるのはリアルタイム推論エンドポイントで、リクエストがゼロでも起動している限り課金されます。

AWS Price List APIから取得した東京リージョン（ap-northeast-1）の推論インスタンス単価は次のとおりです。取得したデータの発行時刻は2026年8月10日18時46分（UTC）です。

720時間換算は24時間30日で稼働させた場合の額です。検証のつもりで立てたml.g5.2xlargeのエンドポイントを消し忘れると、1か月で1,581.84ドルが計上されます。JumpStartのROIを議論する際に効くのはモデルの精度差ではなく、この「動かしていない時間にいくら払っているか」です。

単価表から読める実務的な判断が2つあります。1つは世代の選び直しです。ml.g5.2xlargeとml.g6.2xlargeはvCPU8・メモリ32GiB・GPU1基と数字の上では同じ構成ですが、時間単価は2.197ドルと1.7723ドルで、g6系のほうが約19%安く済みます。対象モデルのSupportedInferenceInstanceTypesにg6系が含まれているなら、既定インスタンスをそのまま使わずg6系を指定するだけで月あたり305.78ドル下がる計算です。ただし搭載GPUはg5がA10G、g6がL4で世代が違い、スループットはモデルと推論精度によって上下します。単価だけで置き換えず、自分のモデルでレイテンシとスループットを実測してから決めてください。

もう1つはサイズの選び方です。ml.g5.xlargeの2.043ドルとml.g5.2xlargeの2.197ドルは、vCPUが4から8へ倍増しているのに単価差が7.5%しかありません。SageMakerのホスティング単価はGPU枚数で大きく段差が付き、同じGPU枚数の中ではvCPUとメモリの差が価格に反映されにくい構造です。xlargeで足りるか迷う程度なら、2xlargeを取っておくほうが費用対効果は高くなります。常時稼働が要らない検証用途なら、リアルタイム推論ではなくサーバーレス推論や非同期推論を選ぶほうが桁で安くなります。

自前データでのファインチューニング設定

学習済みモデルをそのまま使うだけなら前節までで足りますが、社内の用語や商品名を扱わせるならファインチューニングが要ります。JumpStartのファインチューニングには、ドメイン固有の文章をそのまま食わせるドメイン適応と、プロンプトと応答の組を与えるインストラクションチューニングの2系統があり、どちらを取るかはハイパーパラメータinstruction_tunedで切り替えます。

ハイパーパラメータはモデルごとに違うため、値を手で書き始める前に既定値を引くのが確実です。以下はv2系（2.257.6）の書き方で、v3系ではfrom sagemaker.core import hyperparameters になります（v3でfrom sagemaker import hyperparametersと書くとImportErrorです）。

from sagemaker import hyperparameters

model_id = "huggingface-textgeneration1-gpt-j-6b"

hp = hyperparameters.retrieve_default(model_id=model_id, model_version="*")
hp["epoch"] = "3"
hp["instruction_tuned"] = "True"
hp["per_device_train_batch_size"] = "4"

hyperparameters.validate(model_id=model_id, model_version="*", hyperparameters=hp)

共通で指定できる主なパラメータはepoch、learning_rate、instruction_tuned、per_device_train_batch_size、max_input_length、validation_split_ratioです。検証データを別チャネルで渡さない場合はvalidation_split_ratioが学習データからの分割比になります。値は0から1の間で、分割の再現性を取るならtrain_data_split_seedも固定します。

GPUメモリが足りずに学習が落ちるときに効くのが、LoRA関連と量子化のパラメータです。lora_rは低ランク行列のランク（内部次元）で、上げるほど学習する追加パラメータが増えます。lora_alphaはスケーリング係数で、一般にlora_rの2倍から4倍を取ります。lora_dropoutに指定するのはLoRA層のドロップアウト率です。なおAWSのドキュメントはlora_rにもlora_alphaと同じ「重み更新のスケール係数」という説明を当てていますが、LoRAの定義上スケーリングを決めるのはlora_alphaをlora_rで割った値であり、lora_r自体はランクです。ドキュメントの説明文をそのまま読むとチューニングの方向を取り違えます。加えてint8_quantizationを有効にすると8ビット精度でモデルを読み込み、enable_fsdpでFully Sharded Data Parallelによる分散学習に切り替わります。パラメータ数の大きいモデルを1台のGPUインスタンスに載せたい場合は、インスタンスを上位に変えて単価を跳ね上げる前に、この2つを先に試す価値があります。

日本語での実運用を想定するなら、英語中心の基盤モデルをファインチューニングするより、日本語で事前学習されたモデルをカタログから選ぶほうが早いことが多いです。JumpStart上での具体的な手順はSageMaker JumpStartのELYZA日本語モデル｜4つのmodel_idと入力上限の実測【2026年版】で扱っています。

BedrockとJumpStartの使い分け

「AWSで生成AIを使う」という要件に対して、JumpStartとAmazon Bedrockのどちらを選ぶかは、モデルの良し悪しではなく課金単位と運用責任の所在で決まります。Bedrockはトークン単位の従量課金で、エンドポイントという概念を利用者が管理しません。JumpStartはインスタンス時間の課金で、エンドポイントのサイズもスケーリングも消し忘れも利用者の責任です。

この違いから、判断は次のように整理できます。トラフィックが読めない、あるいは断続的にしか来ない用途はBedrockが有利です。前節の表のとおり、リクエストがなくても月1,500ドル規模が積み上がる構造をJumpStartは避けられません。逆に、Bedrockが提供していないオープンウェイトモデルを使いたい、モデルの重みに自社データを焼き込みたい、VPC内に閉じた推論経路が要る、といった要件ではJumpStartを選ぶことになります。

この2つは排他ではありません。JumpStartでデプロイしたモデルをAmazon Bedrockに登録すると、Bedrock側のAgentsやKnowledge Basesから同じモデルを呼べます。移行にはIAMロールへのAmazonBedrockFullAccessの付与が推奨されており、自前でポリシーを書くならsagemaker:InvokeEndpointなどに条件キーaws:CalledViaLastがbedrock.amazonaws.comであることを求める形です。なおこの管理ポリシーが与えるのはBedrock APIへの権限だけなので、マネジメントコンソールから操作するにはS3の参照権限を別途足す必要があります。

ただし、前段で挙げた「VPC内に閉じた推論経路が要る」という要件とこの経路は両立しません。ドキュメントは「By default Amazon SageMaker JumpStart disables network access for the models that you deploy. If you’ve enabled network access, you won’t be able to use the model with Amazon Bedrock.」と明記しています。ネットワークアクセスを有効にしてデプロイしたモデルはBedrockに登録できず、使いたければデプロイし直しになります。ネットワーク分離とBedrock連携のどちらを取るかは、エンドポイントを作る前に決めてください。Bedrock側のRAG構成そのものはAmazon BedrockでRAGを実装する手順｜Managed Knowledge Baseのboto3実装と東京リージョンの制約【2026年版】にまとめています。

なお、JumpStartで作ったモデルを本番へ載せる段になると、どの版を昇格させたかを追う仕組みが別途必要になります。JumpStartは版管理までは面倒を見ないため、モデルレジストリとは？モデル版管理と本番昇格の設計・採用判断を実装者目線で解説【2026年版】で扱っている登録と承認のフローを合わせて設計してください。

よくある質問

SageMaker JumpStartとは何ですか？

Amazon SageMaker AIに含まれる機能で、学習済みの基盤モデルや機械学習モデルをカタログから選び、数行のコードまたはStudioの画面操作で推論エンドポイントの作成やファインチューニングまで実行できます。2026年7月29日時点の公式ドキュメントでは、オープンウェイトモデル436本と商用モデル121本が掲載されています。

AWS Jump Startとは何ですか？

綴りが近い別物が複数あるため注意が必要です。本記事が扱うのはAmazon SageMaker AIの機能であるSageMaker JumpStartで、機械学習モデルのカタログとデプロイ自動化を指します。英単語としてのjump startは「弾みをつける」「起動を助ける」という意味で、AWSのパートナー支援プログラム名などにも使われるため、検索時はSageMakerを付けて絞り込むのが確実です。

SageMaker JumpStartの利用に料金はかかりますか？

JumpStartのモデルやソリューションの利用自体に追加料金はありません。課金されるのは裏で起動するトレーニングインスタンスと推論インスタンスの時間で、これは手動で作成した場合と同額です。東京リージョンのml.g5.2xlargeは時間あたり2.197ドルで、24時間30日の稼働に換算すると1,581.84ドルになります。使い終わったエンドポイントの削除を運用に組み込んでください。

JumpStartModelがImportErrorになるのはなぜですか？

SageMaker Python SDKのv3系を使っている可能性が高いです。v3.18.0にはJumpStartModelとJumpStartEstimatorのクラス定義が存在せず、sagemaker.jumpstart.modelのimportは「No module named ‘sagemaker.jumpstart’」というModuleNotFoundError（ImportErrorのサブクラス）になります。v3ではJumpStartConfigとModelBuilder（学習はModelTrainer）の組み合わせに置き換わっているため、コードを書き換えるか、v2系の2.257.6を明示的にインストールしてください。

デプロイがクォータ不足で失敗する場合はどうしますか？

Service Quotasで対象インスタンスタイプの値を確認し、0または不足していれば引き上げを申請します。クォータは「endpoint usage」「training job usage」のように用途別に分かれており、推論だけ申請すると学習の段階で再び止まります。使用予定のインスタンスについては、推論と学習の両方をまとめて申請しておくのが確実です。

関連記事

• SageMaker JumpStartのELYZA日本語モデル｜4つのmodel_idと入力上限の実測【2026年版】
• Amazon BedrockでRAGを実装する手順｜Managed Knowledge Baseのboto3実装と東京リージョンの制約【2026年版】
• モデルレジストリとは？モデル版管理と本番昇格の設計・採用判断を実装者目線で解説【2026年版】
• Amazon SageMakerとGitHubの連携手順｜3経路の設定とPAT権限