Amazon SageMaker JumpStartの使い方｜Studioの手順・SDK v3移行と東京の費用【2026年11月】

Amazon SageMaker JumpStartは、公開モデルや商用モデルをカタログから選び、Studioの画面操作か数行のPythonで推論エンドポイントやファインチューニングまで進められる機能です。2024年頃の導入記事と比べると、2026年11月時点では前提が4つ変わっています。サービス名がAmazon SageMaker AIになったこと、Python SDKのv3でJumpStartModelクラスが消えたこと、2026年3月13日にカタログの一部モデルが掲載から外されたこと、そしてStudio Classicに新規で入れなくなったことです。この記事ではStudioでのデプロイと後片付けの手順、SDKの書き方、東京リージョンの時間単価、日本語モデルの選び方を、Python 3.12でSDK v2・v3のimportとAPI定義を確認した結果、および公式ドキュメントに沿って整理します。AWS上でのデプロイ・学習完了を実測した記事ではありません。SageMaker全体の構成とSDK v3の破壊的変更そのものはSageMakerとは？SageMaker AIへの改称とPython SDK v3移行を実装手順で解説で扱っています。

まとめ

JumpStartの利用そのものに追加料金はかかりません。請求されるのは学習・推論インスタンスの利用時間と、商用モデルを選んだ場合のAWS Marketplaceのソフトウェア料金やストレージなどの関連料金です。作られるリアルタイム推論エンドポイントは、リクエストが0件でも起動している限り課金されます。東京リージョンのml.g5.2xlargeは1時間2.197ドル、放置すると30日で1,581.84ドルです。試したら同じ日のうちにエンドポイント・エンドポイント設定・モデルの3つを消す、これが最初に身につけるべき手順です。

最初のデプロイ前に確認するのは、新規アカウントでは0になっているGPUインスタンスのサービスクォータと、ゲートモデルのEULA同意の2点です。SDKはv3（3.28.0）とv2（2.257.7）で入口が別物で、v2は2027年7月6日にサポートが終わります。新規コードはv3で書き、既存のv2コードもそれまでにv3へ移す計画を立ててください。

SageMaker JumpStartで選べるモデルとカタログの規模

AWSのドキュメントは「On December 03, 2024, Amazon SageMaker was renamed to Amazon SageMaker AI.」と書いており、従来のSageMakerは2024年12月3日からSageMaker AIです。名称変更は既存の機能名には及ばないため、JumpStartという名前は残っています。コンソールの導線がSageMaker AI配下へ移った影響は、Amazon SageMakerとGitHubの連携手順｜3経路の設定とPAT権限のような周辺機能にも出ています。

公式のモデル一覧は2026年7月29日時点で、オープンウェイトの基盤モデル436本、AWS Marketplaceでの購読が前提の商用モデル121本を載せています。同じページには基盤モデルではない組み込みアルゴリズム135本と従来型の機械学習アルゴリズム11本が別タブで並ぶので、合計を語るときに混ぜないでください。オープンウェイト側にはOpenAIのgpt-oss-20b・gpt-oss-120b、MetaのLlama 4 Scout・Maverick、Qwen3系も入っています。

一方で、2026年3月13日に一部のモデルが全リージョンで掲載から外されました。ドキュメントは「Existing endpoints for delisted models will remain functional.」と断っており、稼働中のエンドポイントは止まりませんが、古い記事のmodel_idで新しく立てようとすると見つからないことがあります。一覧表は静的なので、最新の状態は公開ハブをAPIで引いて確かめます。

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))

個別モデルの対応インスタンスはdescribe_hub_contentでHubContentDocumentを取り、SupportedInferenceInstanceTypesとDefaultInferenceInstanceTypeを読みます。ここで分かった既定インスタンスが、後で述べるクォータ申請の対象になります。

Studioの画面でJumpStartのモデルをデプロイする手順

コードを書かずに試すならStudioが最短です。なお2023年11月30日以前のStudioはStudio Classicに改称され、ドキュメントには「no longer available for onboarding」とあります。新しく始める人が使うのは現行のStudioで、旧画面の「JumpStart」ボタンを探す古い手順書は当てはまりません。

Modelsページでのモデル選択

• Studioを開き、Homeの「Explore models」か、左パネルの「Models」を選ぶ
• SageMaker Modelsページでモデル名を検索するか、提供元・用途で絞り込む
• モデルカード右上の「Deploy」「Fine-tune」「Customize」「Evaluate」から目的の操作を選ぶ（モデルによって出ない操作がある）

EULA同意が必要なモデルは、デプロイ前に同意の確認が出ます。自社で絞り込んだモデルだけを見せたい場合は、プライベートハブ（キュレーテッドハブ）のタブに登録したモデルが同じ操作で使えます。

インスタンスとデプロイ構成の選定

「Deploy」を押すと、エンドポイント名、インスタンスタイプ、初期インスタンス数、最大インスタンス数を入力する画面になります。JumpStartのモデルではそのモデルが対応するインスタンスだけが表示されるので、選べない型を指定して失敗することはありません。主要なLLMでは「Performance」パネルから用途と最適化の方向（Cost optimized・Throughput optimized・Latency optimized・Balanced）を選べ、P50レイテンシや最初のトークンまでの時間（TTFT）の事前計測値を見比べて構成を決められます。IAMロール・VPC・ネットワーク分離にはモデルと互換する初期値が入っており、変更して互換性が崩れると警告が出てデプロイできません。

エンドポイントの状態がInServiceになったら、Studioのエンドポイント画面かSDKのpredictで推論を試せます。試し終えたら、「エンドポイントの後片付けと東京リージョンの費用」の章にある削除手順までを1回の作業として終えてください。

Python SDK v2とv3で変わったJumpStartの書き方

SageMaker Python SDKはv3で作り直され、JumpStartの入口が差し替わりました。PyPIでは2026年10月30日公開の3.28.0が最新で、v2系はメンテナンスモードのまま10月7日に2.257.7が出ています。どちらの環境かで同じコードが動いたりModuleNotFoundErrorになったりします。

v2系のJumpStartModelによるデプロイ

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?"))

2.257.7はimport sagemakerの時点でSageMakerV2DeprecationWarningを出し、「v3 is the actively developed major version.」と表示します。環境変数SAGEMAKER_SUPPRESS_V2_WARNING=1で表示は消せますが、移行が要らなくなるわけではありません。

v3系のJumpStartConfigとModelBuilderによるデプロイ

3.28.0のsagemaker本体はコードを持たないメタパッケージで、実体はsagemaker-core・sagemaker-serve・sagemaker-train・sagemaker-mlopsの4つです。v3でsagemaker.jumpstartをimportすると「sagemaker.jumpstart was removed in the SageMaker Python SDK v3. Use ModelBuilder (JumpStart models).」というメッセージで止まります。書き換え後の形は次のとおりです。

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()

EULA同意はdeploy()の引数からJumpStartConfigのフィールドへ移り、既定値はFalseです。Studioの「Performance」パネルと同じデプロイ構成は、builder.list_deployment_configs()で一覧し、set_deployment_config(config_name=..., instance_type=...)で選べます。

学習はModelTrainer.from_jumpstart_config()が担います。公式の解説ページはtrain()にInputDataのリストを渡す例を載せています。ただし同ページのfrom sagemaker.train.configs import InputDataは、3.28.0では移設済みの互換シムで、importするとDeprecationWarningが出ます。下のコードは移設先のsagemaker.core.training.configsから取っています。ModelTrainerにfitは無く、trainのinput_data_configはリスト型なので、辞書を渡すと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/"),
])

v2のサポート期限を踏まえたv3移行判断

AWSがPyPIに掲げるライフサイクル表では、v3は2025年11月19日に一般提供となり、v2は2026年7月6日からメンテナンスモード、2027年7月6日にサポート終了です。メンテナンスモードのv2に入るのは重大なバグ修正とセキュリティ修正だけで、新機能・API更新・新リージョン対応はありません。v3のPyPI分類子が3 - Alphaのままなのは表示の食い違いで、移行を先送りする根拠にはなりません。既存のv2資産は、移行ガイドで「REPLACED」とされたJumpStartの2クラスから順に書き換え、2027年7月までに検証環境でデプロイと学習を通しておきます。移行で詰まりやすいのはimport時のリージョンで、3.28.0でもリージョンを設定していない環境ではfrom sagemaker.serve import ModelBuilderがimportの時点でNoRegionErrorになります。原因はsagemaker/ai_registry/air_hub.pyの36行目で、モジュール読み込み時にboto3.client("sagemaker")が評価されるためです。CIでもSDKを実際にimportする検査では、AWS_DEFAULT_REGIONなどによるリージョン設定が必要です。ソースを解析するだけの検査には、このimport時の制約は当てはまりません。

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

既定0のインスタンスクォータ

AWS一般リファレンスではml.g5.2xlarge for endpoint usageの既定値が「Each supported Region: 0」です。同じページは「The default quotas in this page are based on new accounts.」と断っているので、自分のアカウントの実値をService Quotasで見てから判断します。

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

クォータは「endpoint usage」「training job usage」のように用途別です。推論だけ申請するとファインチューニングで再び止まるので、学習まで行うなら両方をまとめて申請しておくと手戻りがありません。

ゲートモデルのEULA同意と学習権限

一部の公開モデルは非公開のS3バケットに置かれたゲートモデルで、EULAに同意しないと使えません。既定の挙動では、同意したユーザーはそのままファインチューニングのトレーニングジョブも作れます。組織として学習利用を止めたいなら、条件キーsagemaker:DirectGatedModelAccessがtrueのときのsagemaker:CreateTrainingJobをIAMで明示的にDenyし、許可するモデルだけをプライベートハブに登録します。

エンドポイントの後片付けと東京リージョンの費用

料金ページは「There is no additional charge for using JumpStart models or solutions.」と明記し、学習と推論のインスタンス時間を手動作成時と同額で請求するとしています。商用モデルは、これにAWS Marketplaceのソフトウェア料金が加わります。AWS Price List APIから取得した東京リージョン（ap-northeast-1）の推論インスタンス単価は次のとおりです（2026年10月29日発行のデータ）。

既定インスタンスの費用はモデルごとに異なるため、デプロイ前に対応インスタンスと時間単価を確認します。東京の公開マニフェストでは、gpt-oss-20bの既定がml.g7e.2xlargeで、置いておくだけで30日4,389.77ドルです。逆にml.g5.2xlargeとml.g6.2xlargeはvCPU・メモリ・GPU枚数が同じで、g6のほうが約19%安くなります。対象モデルの対応インスタンスにg6系があれば指定し直す価値がありますが、GPUはA10GとL4で世代が違うため、レイテンシは自分のモデルで測ってから決めてください。

「検証だけならサーバーレス推論」という助言は、GPUを必要とするLLMのデプロイには当てはまりません。サーバーレス推論はGPUに対応していないからです。アイドル時の課金を0にしたいなら、推論コンポーネントで構成したエンドポイントでMinInstanceCountを0にし、0台までスケールインさせる方法があります。推論コンポーネントを最小コピー数0でスケーリング対象に登録し、0台からの復帰にはステップスケーリングポリシーとCloudWatchアラームを組み合わせます。ただし0台からの起動には数分かかり、その間の呼び出しはエラーになります。リアルタイム推論とバッチ推論の費用設計の違いはオンライン推論とは？バッチ推論との違いと遅延・コスト設計を実装目線で解説【2026年版】で整理しています。

次のコードは、ProductionVariantsのModelNameにモデルを指定し、設定とモデルを他のエンドポイントと共有していない検証用構成を対象にします。推論コンポーネントを使う構成では、コンポーネントが参照するモデルと削除手順を別途確認してください。課金を止めるのはdelete_endpointで、残る2つは定義の後始末です。エンドポイントだけ消すと一覧からは見えなくなりますが、設定とモデルはアカウントに残ります。

import boto3

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

# 起動中のエンドポイントを一覧し、消し忘れを洗い出す
pages = sm.get_paginator("list_endpoints").paginate()
for ep in (ep for page in pages for ep in page["Endpoints"]):
    print(ep["EndpointName"], ep["CreationTime"])

endpoint_name = "your-endpoint-name"
desc = sm.describe_endpoint(EndpointName=endpoint_name)
config_name = desc["EndpointConfigName"]
config = sm.describe_endpoint_config(EndpointConfigName=config_name)
model_names = [v["ModelName"] for v in config["ProductionVariants"] if "ModelName" in v]

sm.delete_endpoint(EndpointName=endpoint_name)          # 削除を開始
sm.get_waiter("endpoint_deleted").wait(EndpointName=endpoint_name)
sm.delete_endpoint_config(EndpointConfigName=config_name)
for name in model_names:
    sm.delete_model(ModelName=name)

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

JumpStartのファインチューニングには、ドメインの文章をそのまま学習させるドメイン適応と、指示と応答の組を与えるインストラクションチューニングがあり、ハイパーパラメータinstruction_tunedで切り替えます。値はモデルごとに違うので、既定値を引いてから書き換えます。以下はv2の書き方で、v3では1行目をfrom sagemaker.core import hyperparametersにします。

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)

model_version="*"は最新版に解決されますが、学習スクリプトの依存に脆弱性が登録されている版は使えません。2026年11月1日にmeta-textgeneration-llama-3-1-8b-instructで同じ呼び出しをすると、VulnerableJumpStartModelErrorが「transformers==4.43.1」などの該当パッケージを挙げて止まりました。エラーが勧めるとおり、SDKを更新するか、より新しいモデルへ切り替えます。

GPUメモリが足りないときに効くのはLoRAと量子化の設定です。lora_rは低ランク行列のランク、lora_alphaはスケーリング係数で、更新の大きさはlora_alphaをlora_rで割った値で決まります。AWSのドキュメントはlora_rにもlora_alphaと同じ「スケール係数」の説明を当てているので、そのまま読むと調整の方向を誤ります。既定値もモデルで大きく違い、meta-textgeneration-llama-3-2-1bはr=8・alpha=32、huggingface-llm-mistral-7bはr=64・alpha=16でした。「alphaはrの2倍」のような一律の目安で上書きせず、引いた既定値から動かします。Llama系ではint8_quantizationとenable_fsdpも用意されており、インスタンスを上位に変える前に試す価値があります。

日本語モデルを選ぶときの確認点

日本語の業務で使うなら、英語中心のモデルを調整するより日本語で学習済みのモデルを選ぶほうが早く済みます。ただしJumpStartに載っている日本語特化モデルは世代が古めです。東京リージョンの公開マニフェストで現役（deprecated=false）なのは、ELYZAのLlama 2系4本、サイバーエージェントのCALM2-7B-Chat、rinna、東京工業大学（現・東京科学大学）のSwallow-7B、Stability AIのJapanese StableLMで、後継のcalm3-22b-chatは非推奨（deprecated=true）になっていました。

ELYZAを選ぶなら、判断の軸はパラメータ数よりfast版かどうかです。4本とも仕様ファイルで入力がMAX_INPUT_LENGTH=2048トークン、入出力の合計が4096トークンに設定されています。fast版はモデルカードのとおり語彙を32,000から45,043へ増やしたモデルで、両者のtokenizer.jsonで日本語4サンプル（計332文字）を数えると、通常版389トークンに対しfast版は214トークン（55.0%）でした。今回の4サンプルの比率を単純換算すると、2,048トークンは通常版で約1,700文字、fast版で約3,200文字に相当します。ただし文章やプロンプトのテンプレートによって変わるため、実際の入力をトークナイズして上限を確認します。13Bにしても文脈長は同じ4,096トークンなので、長い文書を入れたいという理由なら月7,403.76ドルの13Bではなく7Bのfast版を選びます。語彙拡張の仕組みはトークナイザーとは？BPE・WordPiece・Unigramの違いと日本語での実装判断を解説【2026年版】で解説しています。

新しい日本語モデルが要件なら、Hugging Faceの重みを自前のコンテナでSageMakerに載せるか、マネージドなAPIを使う経路になります。モデル選定から本番の推論基盤まで一括で任せたい場合は、生成AI開発・AI受託開発として要件定義から支援しています。

BedrockとJumpStartを使い分ける基準

JumpStartとAmazon Bedrockの選択は、モデルの性能より課金単位と運用責任で決まります。Bedrockのテキストモデルをオンデマンドで利用する場合は、主に入出力トークン数に応じて課金され、推論インスタンスを利用者が管理する必要はありません。Provisioned Throughputなど、時間単位で課金される提供形態もあります。JumpStartはインスタンス時間の課金で、サイズもスケーリングも消し忘れも利用者の責任です。トラフィックが読めない用途はBedrock、Bedrockに無いオープンウェイトモデルを使いたい、学習処理や推論コンテナ、インスタンス構成を自分で制御したい、という要件ならJumpStartを検討します。自社データによるファインチューニングやAWS PrivateLink経由のプライベート接続はBedrockにもあるため、それだけでは選定理由になりません。Bedrock側の始め方はAmazon Bedrockの使い方｜APIキー発行からPython呼び出し・東京で使えるモデルと料金【2026年10月】にまとめています。

両者は排他ではありません。JumpStartでデプロイしたモデルのうち、Studioのモデルカードに「Bedrock Ready」と表示されるものはBedrockに登録でき、登録後はAgentsやKnowledge Basesなどから呼べます。IAMロールにはAmazonBedrockFullAccessの付与が推奨され、自前で書くなら条件キーaws:CalledViaLastにbedrock.amazonaws.comを求める形です。ただし「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連携を使う可能性があるなら、エンドポイントを作る前に決めておきます。RAG構成はAmazon BedrockでRAGを実装する手順｜Managed Knowledge Baseのboto3実装と東京リージョンの制約【2026年版】、本番へ載せるときの版管理はモデルレジストリとは？モデル版管理と本番昇格の設計・採用判断を実装者目線で解説【2026年版】を参照してください。

よくある質問

SageMaker JumpStartとは何ですか？

Amazon SageMaker AIの機能で、学習済みの基盤モデルや機械学習モデルをカタログから選び、Studioの画面かPython SDKで推論エンドポイントの作成やファインチューニングまで進められます。2026年7月29日時点の公式一覧では、オープンウェイトモデル436本と商用モデル121本が載っています。

AWS JumpStartとは何ですか？

一般には、Amazon SageMaker AIのSageMaker JumpStartを指します。英語のjump startは「弾みをつける」という意味で、AWSのパートナー向け施策などにも使われる語なので、検索ではSageMakerを付けると目的の情報にたどり着けます。

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

JumpStart機能自体の追加料金はありません。ただし商用モデルの製品料金や関連リソースの料金が別途発生する場合があります。学習・推論インスタンスにも時間料金がかかり、東京リージョンのml.g5.2xlargeは1時間2.197ドル、30日の連続稼働で1,581.84ドルになります。試した後はエンドポイント・エンドポイント設定・モデルの3つを削除してください。

No module named ‘sagemaker.jumpstart’ や ‘sagemaker.core’ が出るのはなぜですか？

SDKの版とコードの世代が食い違っています。v3（3.x）の環境でv2のコードを動かすとsagemaker.jumpstartが見つからず、v2（2.x）の環境でv3のコードを動かすとsagemaker.coreが見つかりません。pip show sagemakerで版を確かめ、コードをその世代の書き方に合わせるか、版を指定してインストールし直します。

SageMaker JumpStartを始めるには何が必要ですか？

Studioから始める場合は、AWSアカウント、SageMaker AIのドメインとユーザープロファイル、必要なIAM権限、使用するインスタンスのサービスクォータを確認します。SDKから使う場合はStudioのドメインは必須ではありませんが、IAM権限と使うインスタンスのクォータは同じく必要です。新規アカウントではml.g5.2xlargeのエンドポイント用クォータが0なので、Service Quotasで引き上げを申請してから、Studioのモデル一覧で目的のモデルを選んでデプロイします。

関連記事

• SageMakerとは？SageMaker AIへの改称とPython SDK v3移行を実装手順で解説
• Amazon Bedrockの使い方｜APIキー発行からPython呼び出し・東京で使えるモデルと料金【2026年10月】
• Amazon BedrockでRAGを実装する手順｜Managed Knowledge Baseのboto3実装と東京リージョンの制約【2026年版】
• モデルレジストリとは？モデル版管理と本番昇格の設計・採用判断を実装者目線で解説【2026年版】
• Amazon SageMakerとGitHubの連携手順｜3経路の設定とPAT権限