ひとことで言うと
公開されている基盤モデルと、サードパーティの商用モデルを、「そのまま置ける形」に配線した状態で並べたカタログです。選んで Deploy を押すと、モデルは SageMaker AI のエンドポイント として自分のアカウントに立ちます。
要するに、家電量販店の「設置工事込み」の売り場です。製品（モデル）を作っているのは各メーカーで、保証書と使用条件（ライセンス・EULA）もメーカーのもの。JumpStart がやるのは陳列と、自宅への搬入・据付（コンテナ・インスタンス種別・推論設定の事前検証）です。据え付けた後の電気代（インスタンス課金）は自分持ちで、そこが Bedrock と決定的に違います。
なぜ生まれたか
オープンウェイトのモデルを自分でホストしようとすると、モデルそのものより周辺の配線で止まります。どの推論コンテナを使うのか、推論スクリプトの入出力の形は何か、どのインスタンス種別なら重みが載るのか、重みを S3 のどこに置くのか。モデルごとに検証しないと分からず、しかも1つ選ぶたびに一からやり直しでした。
JumpStart は、この配線をモデルごとに検証済みの組として持つことでその手間を消しました。さらに、公開モデルにはライセンスの受諾という機械的でない手続きが付いて回るため、それを API の引数（accept_eula）として仕組みに埋めています。
| 時期 | 何が起きたか |
|---|---|
| 2023-11-30 | 従来の Studio 体験が Studio Classic に改称。JumpStart の導線が新旧2系統になった（Classic は新規オンボード不可・移行推奨） |
| 2026-03-13 | カタログから一部モデルを全リージョンで delist。 ただし delist されたモデルの既存エンドポイントは動作し続ける（削除ではなく、カタログからの取り下げ） |
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| FM の下見・比較 | Studio の Models ランディングでプロバイダ／ユースケースで絞り、Evaluate で評価する | D1 |
| 低コードでのデプロイ | Studio の UI から Deploy。複雑な設定なしにエンドポイントを立てる | D2 |
| コードからのデプロイ | JumpStartModel(model_id=...).deploy(accept_eula=True) | D2 |
| ファインチューニング | JumpStartEstimator(...).fit(accept_eula=..., {"train": ..., "validation": ...}) | D1 |
| 組織で使えるモデルの限定 | 管理者がプライベートハブ／キュレーテッドハブを作り、承認済みモデルだけを見せる | D1 |
| 部門・アカウントをまたいだ共有 | AWS RAM でプライベートモデルハブをクロスアカウント共有する | D1 |
| ソリューションの雛形 | ソリューションテンプレートとサンプルノートブック（SageMaker AI と他サービスを繋いだ構成） | D2 |
試験でどう問われるか
JumpStart は主役では出ません。「Bedrock か、自前ホスティングか」の分岐で後者を選んだときの実装手段として、選択肢の中に混ざります。加えて、ライセンスとモデルの見せ方の統制という、Bedrock 側では別の仕組みになる論点を持っているので、そこだけは JumpStart が正解になります。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| Bedrock か JumpStart か | Bedrock に無いモデルを使う／重みを自分で保持する／推論を自分のインスタンス上で完結させる → JumpStart（＝SageMaker AI のエンドポイント） | 「インフラを管理したくない」「利用量に応じた課金がよい」と書いてあるのに JumpStart を選ぶ |
| 「承認したモデルしか使わせない」 | 組織のガバナンス要件 → プライベートキュレーテッドハブ（管理者が対象モデルを絞り、利用者はそこからしか選べない） | Guardrails（あれは入出力の検閲であって、カタログの統制ではない）／IAM でモデルIDを1つずつ拒否する案 |
| 部門ごとに使えるモデルを変える | ハブをチーム・ユースケース・セキュリティ要件ごとに分け、RAM でクロスアカウント共有 | アカウントを分けてモデルを重複コピーする案 |
| カスタマイズの手段選択 | 公式の推奨順は ①プロンプトエンジニアリング → ②ファインチューニング（重みが変わる）→ 知識を足すだけなら RAG（再学習なし） | 「社内文書の最新情報を反映したい」にファインチューニングを選ぶ（正解は RAG 側） |
| ライセンスの扱い | EULA が要るモデルは、デプロイ時／学習時に明示的な受諾が必要 | 「AWS がライセンスを一括で引き受けるので確認は不要」 |
| 低コード要件 | ML の設定に踏み込めない利用者にモデルを配りたい → Studio 経由の JumpStart デプロイ | ModelBuilder や CloudFormation（どちらもコード側の経路） |
1問拾える境目: ファインチューニングで EULA を受諾したモデルは、その後デプロイするときに EULA を再受諾する必要がありません。公式の理由がそのまま覚え方になります——ファインチューニングによって元のモデルの重みが変わっているからです。「fine-tune 済みモデルのデプロイで EULA を再受諾する」という選択肢は外れます。
実務でどう使うか
accept_eulaの既定値はNoneです。 明示的にTrueを渡さないと、EULA が必要なモデルはデプロイもファインチューニングも通りません。SageMaker Python SDK v2.198.0 以降の書き方で、それ以前はpredictor.predict(payload, custom_attributes="accept_eula=true")という別経路でした。古いノートブックを持ち込むとここで詰まります- すべてのモデルで
Fine-tune/Customize/Deploy/Evaluateが揃っているわけではありません。 モデル詳細カードで出るアクションが違うので、「このモデルで評価まで回す」前提の設計は、実物を見てから決めます - サードパーティコンテンツのライセンス確認責任は利用者側にあります（公式が明記）。プロプライエタリモデルの提供元の連絡先は、AWS Marketplace の各モデルページの Support タブにあります
- カタログにモデルが並んでいることを前提に IaC を書かない。 2026-03-13 に一部モデルがカタログから取り下げられた前例があります。既存エンドポイントは動き続けますが、新しく同じ
model_idを引く再構築は通らなくなります - プライベートハブは管理者が SageMaker Python SDK で作ります。 利用者側は Studio か Python SDK から、そのハブのモデルを通常の JumpStart モデルと同じ操作で使えます
コストの効き方が Bedrock と逆です。JumpStart のデプロイは、押した瞬間から SageMaker AI のエンドポイントとしてインスタンス時間の課金が始まります。トークン単価ではないので、使わなくても止まりません。「試しに大きいモデルを Deploy して放置」が、この経路で最も高くつく操作です。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon Bedrock | Bedrock はエンドポイントを持たず、API とトークン課金で借りる。JumpStart は自分のエンドポイントが立ち、インスタンス時間で払う |
| SageMaker AI | JumpStart は SageMaker AI の入口であって別サービスではない。デプロイの結果は SageMaker AI のエンドポイントそのもの |
| SageMaker Model Registry | JumpStart は他人が作った既製モデルのカタログ。Registry は自分が作ったモデルの版と承認の管理。方向が逆 |
| Bedrock Guardrails | Guardrails は入出力の中身を検閲する。キュレーテッドハブはそもそも何を選べるかを絞る。「使わせない」の層が違う |
| ModelBuilder / CloudFormation | どちらも SageMaker AI へのデプロイ経路だが、自分のモデルを細かく設定する用（ModelBuilder）と、大規模な運用自動化用（IaC）。JumpStart は既製モデルを低コードで置く用 |
想起チェック
Q1. 「Bedrock に無いオープンウェイトモデルを使いたい」以外に、JumpStart が正解になる典型条件は？
組織が使える基盤モデルを承認済みのものに限定したいときです。管理者がプライベートキュレーテッドハブを作り、利用者はそこからしか選べなくなります。Guardrails は入出力の検閲なので、この要件には答えていません。
Q2. ファインチューニング時に EULA を受諾しました。その後デプロイするとき、再受諾は必要ですか。
不要です。 ファインチューニングによって元のモデルの重みが変わっているため、と公式が理由を明記しています。
Q3. 「社内ドキュメントの最新の内容を回答に反映したい」。JumpStart のカスタマイズ手段として何を選びますか。
RAG です。公式のカスタマイズの順序は「まずプロンプトエンジニアリング、足りなければファインチューニング（重みが変わる）、再学習なしで知識ライブラリの情報を使いたいなら RAG」。最新情報の反映はファインチューニングの仕事ではありません。
Q4. JumpStart でモデルをデプロイした後、課金は何に対して発生しますか。
SageMaker AI のエンドポイントのインスタンス時間です。トークン単価ではないので、リクエストが来なくても立っている限り課金が続きます。ここが Bedrock との最大の違いです。