ひとことで言うと
同じ課題を解くために学習したモデル群を「モデルグループ」にまとめ、その中の1つ1つを版として登録し、承認ステータスを付けて管理する台帳です。学習の成果物と、承認と、デプロイを1本の線で繋ぎます。
要するに、承認欄が出荷ラインの起動スイッチになっている稟議書です。台帳に版を並べるだけなら普通のカタログですが、Registry の場合、承認欄のステータスを書き換えた瞬間に CI/CD が動き出します。しかも面白いのは差し戻しの挙動で、承認済みの版を「却下」に落とすと、その版が消えるのではなく、残っている承認済みの最新版が改めてデプロイされます——却下がそのままロールバックの操作になっている、ということです。
なぜ生まれたか
モデルは1つ作って終わりではなく、データが増えるたび、ハイパーパラメータを変えるたびに増えます。増えたモデルは S3 に model.tar.gz として並びますが、S3 のオブジェクトは「どの学習から出たか」も「本番に出してよいか」も持っていません。結果、どの重みが本番に載っているのか台帳が別途必要になり、その台帳は必ずズレます。
Registry がやったのは、モデルの版に「承認ステータス」という状態を持たせ、その状態遷移をデプロイの引き金にしたことです。台帳と実際のデプロイが別々に存在してズレる、という構造そのものを消しにいっています。
| その前の不便 | Registry が持ち込んだもの |
|---|---|
| どの重みが本番かを人が覚えている | モデルグループ＋版という構造。さらにモデルグループを Collections でまとめられる |
| 本番に出してよいかがどこにも書かれていない | ModelApprovalStatus（登録時の既定は PendingManualApproval） |
| 承認と実際のデプロイが別作業でズレる | 承認ステータスの変更が CI/CD デプロイを起動する |
| 学習指標・系譜が成果物と切り離される | 学習メトリクスやカスタムメタデータの紐付け、モデルカードの参照、リネージの表示 |
| 学習チームとデプロイチームのアカウントが別 | モデルグループ・ECR・S3・KMS へのクロスアカウントリソースポリシー |
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| 版の登録 | SageMaker Pipelines の RegisterModel ステップ、Boto3 の create_model_package、または Studio から | D1 |
| 承認ステータスの管理 | update_model_package で Approved / Rejected に更新。Studio の Deploy タブからも変更できる | D1 |
| 評価結果による自動承認 | パイプラインの条件ステップでメトリクスを判定し、通ったら承認ステータスを更新する | D1 / D5 |
| デプロイ | 版の ARN を create_model の Containers に ModelPackageName として渡し、エンドポイント設定→エンドポイントの順に作る（SDK では ModelBuilder に版の ARN を渡す経路もあります） | D2 |
| CI/CD 自動デプロイ | MLOps プロジェクトテンプレートを使うと、承認済みの版が自動的に本番へ配備される | D2 |
| チーム間の分離 | 学習アカウントと配備アカウントを分け、リソースポリシーでクロスアカウント登録・配備を許可する | D2 |
| 推論パイプラインの登録 | 2〜15 個のコンテナからなる推論パイプラインを、コンテナと環境変数を指定して1つの版として登録できる | D2 |
| 追跡可能性 | 登録済みモデルからモデルカードの情報とモデルリネージを参照する | D1 |
試験でどう問われるか
Registry も主役では出ません。 ただし3つの中では唯一、試験ガイドのスキル文に名指しで登場します——D1.2 の「SageMaker AI での fine-tuned モデルの配備、LoRA／アダプタ、Model Registry によるバージョン管理とロールバック」がそれです。したがって出方は読めていて、生成AIのシナリオで「モデルを自分でファインチューニングして SageMaker AI に載せる」側に倒れたとき、その版と承認をどう扱うかという形になります。
引っかけの主戦場は「版と承認」という言葉の重なりです。 AIP-C01 には版と承認フローを持つサービスが他にもあり、対象がモデルの重みなのか、プロンプトなのかで正解が入れ替わります。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| ファインチューニング済みモデルの版を管理し、承認された版だけ本番に出したい | Model Registry（モデルグループ＋ModelApprovalStatus） | Bedrock Prompt Management。版と承認フローを持つが、対象はプロンプトであってモデルの重みではない |
| 新しい版に問題があり、直ちに前の版に戻したい | 承認済みの版を Rejected に更新する。MLOps テンプレート配下では、承認済みの最新版を配備する CI/CD が改めて動く | エンドポイントを削除して作り直す案／Rejected にすると本番が空になる、とする選択肢 |
| 評価が閾値を超えたときだけ自動でデプロイしたい | パイプラインの条件ステップで承認ステータスを更新し、その変更が CI/CD を起動する | EventBridge で学習ジョブの完了を拾って無条件にデプロイする案（評価の関門が無い） |
| 学習チームと配備チームが別アカウント | モデルグループ・ECR・S3 へのリソースポリシー＋KMS の grant | IAM ユーザーを配備アカウントに作って共有する案 |
| 既製の基盤モデルを組織で選べるようにしたい | SageMaker JumpStart のプライベートハブ側 | Model Registry。Registry は自分が作ったモデルの版を扱う。方向が逆 |
| Bedrock でカスタマイズしたモデルの版を管理したい | Bedrock 側の管理（Registry の対象外） | Model Registry。SageMaker AI のモデルパッケージが対象 |
| どの学習ジョブからこの本番モデルが出たか監査で示したい | Registry のモデルリネージとモデルカードの参照 | CloudTrail 単体（API 呼び出しの記録であって、成果物の系譜ではない） |
1問拾える境目: 承認ステータスの遷移は4通りあり、3つが CI/CD を起動し、1つだけ何も起きません。PendingManualApproval → Approved は起動、Rejected → Approved も起動、そして Approved → Rejected も起動します（承認済みの最新版を配備し直すため）。何も起きないのは PendingManualApproval → Rejected だけ——もともと配備されていないので、戻す先がありません。「却下は常に何も起こさない」と覚えると、ロールバックの問題を落とします。
実務でどう使うか
登録時の既定は PendingManualApproval です。公式のサンプルコードも create_model_package にこの値を渡しています。登録しただけでは本番に出ない——これが安全側の既定なのですが、裏を返すと、パイプラインで登録するときにここを Approved で書いてしまうと、MLOps テンプレート配下では人の目を一度も通さずに本番へ流れます。パイプラインのコードレビューで最初に見る行です。
- クロスアカウントでは KMS が必須です。 公式が明記しているとおり、クロスアカウントでモデルを配備するには学習時の出力データ設定を KMS キーで暗号化していなければなりません。学習が終わってから気づくと、学習をやり直すことになります。
- 必要なリソースポリシーは1か所ではありません。 モデルグループ、推論イメージのある ECR リポジトリ、モデルが置かれた S3 バケットの3つすべてにポリシーが要り、加えて KMS の grant が要ります。どれか1つ忘れると、失敗するのは配備の直前です。
Rejectedは削除ではありません。 却下した版もモデルグループに残り、あとからApprovedに戻せます。監査の観点では「却下された版が残っていること」自体が記録なので、消しにいかないのが既定の運用です。- カスタムメタデータはキーと値のペアで付けられます。 学習メトリクスも紐付けられるので、「どの版がどの評価で通ったか」を Registry の中で完結させられます。外部のスプレッドシートに逃がすと、承認と記録がまたズレます。
- モデルグループの粒度は「解こうとしている課題」で切ります。 公式の言い方は「特定の課題を解くために学習したすべてのモデルを追跡するモデルグループ」。実験ごとにグループを作ると、版が1つずつ入った空のグループが増えて台帳の意味が消えます。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon SageMaker JumpStart | JumpStart は他人が作った既製モデルのカタログ。Registry は自分が作ったモデルの版と承認。同じ「モデルが並んでいる画面」でも出所が逆 |
| Amazon Bedrock Prompt Management | どちらも版と承認フローを持つが、対象がプロンプトかモデルの重みか。生成AI試験ではこの取り違えが一番起きやすい |
| SageMaker Model Cards | モデルカードはそのモデルの目的・リスク・評価を文書として記録するもの。Registry は版と承認の状態を持つ。Registry からモデルカードの情報を参照できる関係 |
| Amazon SageMaker Model Monitor | Registry はデプロイ前の関門。Model Monitor はデプロイ後の実測。監視で問題が出たら Registry 側の承認を落として切り戻す、という往復になる |
| Amazon ECR | ECR はコンテナイメージ。Registry が管理するのはモデルパッケージ（重み＋推論仕様）で、その中で ECR のイメージを参照している |
想起チェック
Q1. 承認ステータスの4つの遷移のうち、CI/CD デプロイが起動しないのはどれですか。
PendingManualApproval から Rejected だけです。残る3つ（Pending→Approved、Rejected→Approved、Approved→Rejected）はいずれも起動します。Approved→Rejected は、承認済みの最新版を改めて配備するために動きます。
Q2. 「本番の新版に不具合が出たので即座に前の版へ戻したい」。Registry ではどう操作しますか。
問題の版の承認ステータスを Rejected に更新します。 MLOps プロジェクトテンプレート配下では、これが承認済みの最新版を配備する CI/CD を起動します。エンドポイントを作り直す必要はありません。
Q3. シナリオに「版を管理し、承認された版だけを本番で使いたい」とあります。Model Registry と Bedrock Prompt Management のどちらですか。
管理対象で決まります。 モデルの重み（ファインチューニング済みモデル、SageMaker AI に載せるもの）なら Model Registry、プロンプトテンプレートなら Prompt Management です。どちらも版と承認を持つので、文言だけでは決まりません。
Q4. 学習アカウントと配備アカウントを分ける構成で、学習の段階でやっておかないと手遅れになることは何ですか。
学習時の出力データ設定を KMS キーで暗号化しておくことです。クロスアカウント配備の必須条件と公式が明記しており、後から付け替えられないため、気づいた時点で学習のやり直しになります。