【AWS re:Invent 2025】Amazon SageMaker AI で AI モデル開発ライフサイクルを効率化する方法

こんにちは、アジャイル事業部のみちのすけです。re:Invent 2025 に現地参加しています!

この記事は re:Invent 「Streamline AI model development lifecycle with Amazon SageMaker AI (AIM364)」のセッションレポートです。

Amazon の Khushboo Srivastava さん(Senior Product Manager Technical External Services)と Bruno Pistone さん(Sr. WW Specialist SA – GenAI)、そして顧客事例として KOHO Financial の Manikandan Paramasivan さん(Senior Staff Architect – Data and ML/AI)が、Amazon SageMaker AI を使った AI モデル開発ライフサイクルの効率化について紹介しました。

概要

セッションでは、Amazon SageMaker Studio を中心とした、エンドツーエンドの AI/ML 開発ワークフローが語られました。特に印象的だったのは、KOHO Financial が SageMaker AI を導入して年間コストを 98% 削減($1.5M → $26K)、レイテンシを 15ms に抑えながら 1 日 100 万件のトランザクションを処理しているという具体的な成果です。

こんな方におすすめ

• AI/ML 開発環境の統一を検討している方
• データ準備からモデルのデプロイまでを一貫して管理したい方
• SageMaker Studio、HyperPod、Training Jobs の使い分けを知りたい方
• GenAI プロジェクトのコスト最適化に興味がある方
• スタートアップや中規模チームで AI/ML 基盤を構築したい方

登壇者

• Khushboo Srivastava さん(Senior Product Manager Technical External Services, Amazon)
• Bruno Pistone さん(Sr. WW Specialist SA – GenAI, Amazon Web Services)
• Manikandan Paramasivan さん(Senior Staff Architect – Data and ML/AI, KOHO Financial)

GenAI が変革するビジネス環境

Khushboo さんから、現在の GenAI 市場動向について説明がありました。

IDC の予測では GenAI への世界的な支出は 2028 年までに $202 billion に達し、年間成長率は 29% とのこと。また、89% の企業 が GenAI イニシアチブを進めており、77% の組織 が 13 billion パラメータ以下のモデルを選択しているそうです。

AI への投資が加速していることが数字からも明確ですね。

企業が直面する ML 開発の課題

企業が ML 開発で直面している主な課題として、以下が挙げられました:

1. バラバラな ML ツール: 各フェーズで異なるツールを使用し、ツールの管理に時間を取られる
2. チーム間の孤立: データサイエンティスト、AI 開発者、ビジネスチームがサイロ化
3. ガバナンスの複雑さ: プロジェクト拡大に伴いセキュリティとコンプライアンスがボトルネックに
4. インフラ管理: LLM のトレーニングに適切なインフラの可用性と管理が必要

特にスタートアップや中規模チームでは、リソースが限られているため課題がより深刻ですね。

ML ワークフローと GenAI ワークフローの類似性

Bruno さんから、従来の ML と GenAI のワークフローが類似していることが説明されました。両方とも、データ準備 → モデル選択 → コンピュートクラスタでの実行 → 評価・デプロイ という共通ステップを踏みます。

既存の ML プラットフォームを GenAI にも活用できるのは効率的ですね。

Amazon SageMaker Studio の全体像

これらの課題に対応するため、Amazon は Amazon SageMaker Studio を提供しています。

SageMaker Studio は、エンドツーエンドの ML 開発プラットフォーム として設計されており、データサイエンティストが以下のことを一箇所で行えます:

• モデルの構築、デプロイ、ファインチューニング
• AI ワークフローの管理とモニタリング

IDE の選択肢

データサイエンティストは、好みの IDE を選択 できます:

• SageMaker Studio(独自の統合環境)
• JupyterLab
• Code Editor(オープンソース VS Code ベース)

データ準備

• SageMaker Studio Notebooks でデータ準備
• データ生成と準備のための スクリプト記述
• 大規模な Spark ワークフローのための 組み込み EMR 接続

モデルの選択とファインチューニング

• 基盤モデルのハブ から選択
• 事前構築済みの基盤モデルを選択可能
• 好みの ファインチューニング手法 を選択(例:強化学習)
• 独自モデル を持ち込んでゼロからトレーニングすることも可能

デプロイとモニタリング

• 本番環境への 視覚的なインターフェース でエンドポイントをデプロイ
• すべてのエンドポイント、モデルを 単一のペインで管理・モニタリング

SageMaker Studio は、複数の SageMaker AI サービス を単一のプラットフォーム内で提供しているのが大きな特徴ですね。

また、MLflow を使った実験の実行、SageMaker Pipelines を使ったパイプラインの構築 も可能で、ドラッグ&ドロップで簡単にパイプラインを構築することも、Studio Notebooks でコードを書くこともできます。柔軟性がかなり高いと思います。

SageMaker Studio の採用事例

現在、数万の顧客 が Amazon SageMaker AI を使用しており、いくつかの企業名が紹介されました:

• 3M
• Coinbase
• Intuit
• Domino’s
• その他多数

これだけ多くの企業が採用しているというのは、信頼性と実績の証ですね。

実践デモ: データ準備からデプロイまで

Bruno さんから、SageMaker AI を使った実践デモがありました。

デモのアーキテクチャ

プラットフォーム管理者 として、プライベートネットワーク環境に HyperPod(EKS オーケストレーション)をデプロイし、トレーニングとデプロイ両方に使用。SageMaker Studio と Amazon FSx for Lustre でデータを共有します。

データサイエンティスト は、Studio から好みの IDE(JupyterLab/Code Editor)を選択し、共有 FSx にデータを保存。HyperPod CLI や kubectl でジョブを送信し、タスクガバナンス機能でモニタリングします。

ワークフローの流れ

1. データ準備: 34B パラメータモデルを選択し、推論とツール呼び出し能力を向上させるためデータセットをフォーマット。S3 と FSx に保存
2. トレーニング: マニフェストファイルで GPU タイプやインスタンス数を定義し、kubectl で HyperPod にデプロイ。MLflow でメトリクスをモニタリング
3. デプロイ: モデルを S3 にコピーし、マニフェストファイルでデプロイ設定を記述。エンドポイントが In Service になったら利用可能
4. テスト: SageMaker Python SDK でモデルをテストし、推論能力が向上していることを確認

データ準備の方法

データ準備には複数のアプローチがあります:

1. インタラクティブ: JupyterLab Notebook で直接準備
2. 大規模分散処理: EMR サーバー(セルフマネージドまたは Serverless)に接続し、Spark で分散処理
3. プログラマティック: SageMaker Processing でパイプラインの一部として実行

プロジェクトの規模に応じて選択できるのは良いですね。

モデルのトレーニングとカスタマイズ

ビジネス目標に基づいて、3 つのカスタマイズ手法から選択できます:

1. Continued Pre-training: 業界特有の用語を学習させる(ヘルスケア、金融など)。次のトークンを予測するタスク
2. Supervised Fine-tuning: 新しいタスクを教える、または既存タスクの能力を向上。ラベル付きデータセット(ユーザー・アシスタントのやり取り)を使用
3. Post-training / Preference Alignment: 強化学習で人間らしい回答を生成。良い例と悪い例の両方を提供

プロジェクトの要件に合わせて選択できるのは良いですね。

SageMaker AI でのトレーニング方法

SageMaker HyperPod

デモで使用したのは、Amazon SageMaker HyperPod を使ったセルフマネージドクラスタ でした。

HyperPod は、最大限のリソース制御 を目的とした、レジリエントで自己オーケストレーション型のインフラです:

• クラスタを完全に制御
• Amazon EKS または Slurm でオーケストレーション可能
• タスクガバナンス と組織化のための高度な機能(定義したポリシーに基づいてタスクの実行を整理)

SageMaker Training Jobs

クラスタを管理したくなく、ML 部分により集中したい場合は、SageMaker Training Jobs を使用できます:

• フルマネージド、レジリエント なインフラ
• 大規模でコスト効果的なトレーニング

Training Jobs では、コードをプロトタイピングし、ジョブを送信したいときに API を呼び出す だけです:

• インスタンスタイプと数を指定
• SageMaker AI がすべてを処理
  • インフラを立ち上げ
  • ジョブを実行
  • 完了後にインフラを停止

オンデマンド方式 なので、ジョブが実行されている時間だけ支払います。

予測可能なワークロードの場合(いつ、どれだけのインスタンスを使用するかが分かっている場合)は、Flexible Training Plans や Spot Instances などのオプションもあり、事前に容量を予約できます。

HyperPod と Training Jobs の使い分けができるのは、チームの運用スタイルやプロジェクトの要件に応じて柔軟に選択できるという点で、かなり良いと思います。

オブザーバビリティの重要性

デモで見たように、オブザーバビリティは非常に重要です。

HyperPod でのオブザーバビリティ

SageMaker Studio では、タスクガバナンス機能 を使用できます:

• 実行中のタスクを分析
• カスタムポリシーを定義して特定のタスクを優先(例:チーム別、優先度別)

Training Jobs でのオブザーバビリティ

Training Jobs でも同様のことができます:

• トレーニングジョブに使用されるクラスタに関連するメトリクスを分析
• AWS Batch との接続を使用してジョブの実行をオーケストレーション

リアルタイムでクラスタの状況や実行中のジョブを把握できることは、トラブルシューティングやリソースの最適化において非常に重要だと思います。

どのモデルを使うべきか: HyperPod Recipes

「どのモデルを使うべきか?」という質問に対する答えとして、昨年の re:Invent 2024 で Amazon SageMaker HyperPod Recipes がリリースされました。

HyperPod Recipes は、オープンソースモデル用の事前設定されたパラメータセット です:

• Deepseek、Meta Llama、Mistral などのオープンソースモデル
• Amazon Nova モデル のカスタマイズ(今年のニューヨークサミットから)

Recipe とは?

Recipe は、モデルに関連する事前設定されたパラメータのコレクション です:

• 使用したい Recipe を指定するだけ
• コードを書く必要がない
• SageMaker AI がワークロードの実行を処理

Recipe の利用方法

Recipe は SageMaker Training Jobs と SageMaker HyperPod の両方で利用可能です:

• Training Jobs: SageMaker Python SDK を使って使用したい Recipe を指定
• HyperPod: HyperPod CLI を使ってジョブを送信

これは、モデル選択とトレーニングの設定を大幅に簡素化してくれるので、特に初心者にとってはかなり助かる機能だと思います。

モデルのデプロイメント

デプロイメントに関しても、2 つのオプションがあります。

SageMaker Managed Inference

フルマネージドアプローチを維持したい場合は、SageMaker Managed Inference を使用できます:

• フルマネージドのリアルタイムエンドポイント
• 自動スケーリング: リクエストのスパイクに基づいてスケールアップ/ダウンするポリシーを定義可能

HyperPod でのデプロイ

トレーニングワークロードに使用したクラスタの利用を最大化したい場合は、同じ HyperPod クラスタ を再利用できます:

• デモで見たように、トレーニングとデプロイの両方に同じクラスタを使用
• クラスタのリソースを最大限に活用できる

簡単デプロイ機能

今年のニューヨークサミットから、SageMaker Studio から直接オープンソースモデルをデプロイ できる機能が追加されました:

• 文字通り数クリックで完了
• Studio インターフェースから直接オープンソースモデルをデプロイ
• アカウント内で稼働している HyperPod クラスタを選択

これは、デプロイの敷居を大幅に下げてくれる機能で、特にチームの生産性向上に貢献すると思います。

SageMaker Studio の最近のリリース

提供される IDE

SageMaker Studio は 3 つの IDE を提供:JupyterLab(Web ベース)、Code Editor(VS Code ベース)、RStudio(R 言語用)。チームの多様なスキルセットに対応できますね。

主要な新機能

ローカル IDE からのリモートアクセス

ローカル Visual Studio Code から SageMaker Studio spaces に接続可能。SageMaker のコンピュートリソースを活用しつつ、セキュリティコントロールも維持されます。

Trusted Identity Propagation (TIP)

AWS Identity Center 経由でログインしたユーザーのアイデンティティを、下流の AWS サービス(Redshift、EMR、SageMaker など)全体に伝播。CloudTrail でアクセスを監査でき、きめ細かなアクセス制御が可能です。規制の厳しい業界では必須の機能ですね。

Amazon Nova のカスタマイゼーション

SageMaker Studio から直接 Amazon Nova モデル(Micro、Light、Pro)をカスタマイズ可能。事前構築済みノートブックで Supervised Fine-tuning や強化学習を実行できます。

HyperPod 上での IDE とノートブック

HyperPod クラスタに Amazon SageMaker Spaces アドオン をインストールすることで、IDE とノートブックを HyperPod 上で実行可能。トレーニングと推論に同じクラスタを使い、GPU を複数の Spaces で共有できます。リソース効率が大幅に向上しますね。

デモ: HyperPod 上での Spaces の実行

Khushboo さんから、HyperPod 上で Spaces を実行するデモがありました。

セットアップの流れ

1. アドオンインストール: HyperPod クラスタに Amazon SageMaker Spaces アドオンをインストール(Quick Install または Custom Install)
2. テンプレート作成: アプリケーションタイプ、イメージ、ストレージ、GPU/CPU/メモリ、ライフサイクル設定を定義
3. Namespace 設定: サービスアカウントとランタイムロールを割り当て
4. ユーザー管理: ユーザーとグループを作成し、サービスアカウントを割り当て

データサイエンティストの利用

HyperPod CLI で Space を作成・管理:create、list、describe、stop、start、update、logs、delete コマンドを使用。Web UI URL または VS Code 接続 URL で IDE にアクセスできます。

開発からトレーニング、デプロイまでを同じクラスタで行えるのは、リソース効率化という点で魅力的ですね。

顧客事例: KOHO Financial

KOHO Financial の Manikandan Paramasivan さんから、KOHO での SageMaker 活用事例が紹介されました。

KOHO について

KOHO は 2014 年設立のカナダのフィンテック企業 で、200 万人以上の顧客 にバンキング、クレジット、ライフスタイル製品を提供。従業員数は 約 230 人 と小規模ながら、エンタープライズ規模のソリューションを構築しています。

直面していた課題

1. ベンダーコスト: リアルタイム不正検知だけで 年間 $1.5 million。API 呼び出しベースの課金でコストが爆発的に増加
2. パフォーマンス: 50ms 以内 に不正判定とレスポンスが必要
3. セキュリティ: 規制された金融機関として、データを VPC 内に留める必要
4. 統合 ML プラットフォーム: データアクセスからデプロイまでを単一 IDE で完結させたい

規制の厳しい金融業界でセキュリティとパフォーマンスを両立するのは難しいですね。

SageMaker Studio の導入と成果

KOHO は 2023 年に SageMaker Studio をコア基盤 として採用。現在 20 人以上のデータサイエンティストと ML エンジニア が 4 チーム(不正リスク、信用リスク、マーケティング、プラットフォーム)で使用しています。

開発環境: 内部 SSO からチーム固有の Studio ドメインにアクセスし、個別の JupyterLab 環境が自動プロビジョニング。Terraform で管理され、新メンバーは単一 PR でオンボード可能です。

本番環境アーキテクチャ: SageMaker Studio で開発し、AWS Managed Airflow で MLOps パイプラインをオーケストレーション。SageMaker Processing/Training Jobs でモデルを構築し、Model Registry で管理。リアルタイムサービングには SageMaker Endpoints を使用。すべて VPC 内にデプロイされ、Studio から一元管理できます。

驚異的な成果

コスト削減: 年間 $1.5M → $26K(98% 削減)
パフォーマンス: 1 日 100 万件以上のトランザクション を 平均 15ms で処理(50ms の要件を大幅にクリア)
モデル精度向上: 誤検知と紛争クレームが減少し、顧客満足度が向上

他ユースケースへの展開: ローンのアンダーライティング、ユーザーチャーン予測、LTV などのマーケティング、アンチマネーロンダリングレポート生成、マーチャントカテゴリゼーション、顧客フィードバック分析にも活用。

GenAI/LLM: JumpStart 経由で基盤モデルにアクセスし、プロトタイピング、プロンプトテスト、モデル比較、ファインチューニングを実施。価値が証明されたら EKS や Bedrock にデプロイ。

98% のコスト削減は驚異的ですね。SageMaker を活用することで、ベンダーロックインを回避し、自社でコントロールできる形で ML/AI 基盤を構築できることが明確に分かりました。

まとめ

SageMaker Studio は、データ準備からデプロイ、モニタリングまでを一箇所で行えるエンドツーエンドのプラットフォームです。HyperPod(セルフマネージド)と Training Jobs(フルマネージド)の使い分けができ、HyperPod Recipes でコードなしにモデルをカスタマイズ可能。JupyterLab、Code Editor、RStudio から選択でき、ローカル IDE からのリモート接続もサポートされています。

KOHO Financial の事例では、98% のコスト削減($1.5M → $26K) と 15ms の低レイテンシで 100 万件/日の処理 を実現。スタートアップサイズのチーム(230 人)でエンタープライズ規模のソリューションを構築できることが証明されました。

正直、SageMaker のエコシステムがここまで統合され、柔軟になっているとは思いませんでした。HyperPod 上で IDE とノートブックを実行できる新機能は、リソース効率化という点で魅力的ですね。GenAI の導入が加速する中、SageMaker Studio のような統合プラットフォームの重要性は今後さらに高まると感じました。

参考リンク

• Amazon SageMaker AI 公式サイト
• SageMaker Studio ドキュメント
• SageMaker HyperPod ドキュメント
• セッション動画