はじめに

前回は、ML ワークロードのセキュリティとして、

IAM
KMS
VPC
VPC Endpoint
CloudTrail
CloudWatch Logs

について整理しました。

今回は、このシリーズの最後として、AWS 上で機械学習を運用するうえで重要な
コスト最適化 について整理します。

機械学習では、モデルの精度だけを見ていると、コストが大きくなりすぎることがあります。

特に SageMaker では、

Training Job
Hyperparameter Tuning
Endpoint
Batch Transform
Processing Job
Feature Store
Data storage
Monitoring

など、さまざまな箇所でコストが発生します。

そのため、実務では

精度
処理時間
レイテンシー
運用しやすさ
コスト

をバランスよく考える必要があります。

本記事では、

ML ワークロードでコストが発生するポイント
Training コスト
Endpoint コスト
Batch Transform
Serverless Endpoint
Spot Training
Auto Scaling
インスタンスタイプ選定
実務や試験での見られ方

を、初心者にも分かりやすく整理します。

🎯 対象読者

SageMaker のコスト最適化を整理したい方
Training と Endpoint のコストの違いを理解したい方
AWS の AI / ML 系資格を勉強している方
SageMaker を実務で使うときのコスト感を知りたい方
精度だけでなく運用コストも意識したい方

🧩 まず結論：SageMaker のコストは「学習」と「推論」を分けて考える

SageMaker のコストを考えるときは、まず以下の2つに分けると分かりやすいです。

Training コスト = モデルを作るためのコスト
Inference コスト = モデルを使うためのコスト

もう少し整理すると、以下のようになります。

種類	代表例	コストが発生する場面
学習コスト	Training Job、Tuning Job	モデルを学習するとき
推論コスト	Endpoint、Batch Transform	学習済みモデルで予測するとき
データ処理コスト	Processing Job、Data Wrangler	データ前処理や特徴量作成
ストレージコスト	S3、Feature Store	データやモデルを保存するとき
監視コスト	Model Monitor、CloudWatch	本番運用を監視するとき

まずは、

どこでコストが発生しているのか

を分けて考えることが大切です。

💰 ML ワークロードでコストが発生する主な場所

SageMaker を使う場合、コストはモデル学習だけではありません。

以下のようなポイントでコストが発生します。

項目	内容
Training Job	学習用インスタンスの利用時間
Hyperparameter Tuning	複数の Training Job の実行
Processing Job	前処理や評価処理の実行
Endpoint	推論用インスタンスの常時稼働
Serverless Endpoint	リクエスト量や実行時間に応じた推論
Batch Transform	一括推論ジョブの実行
S3	訓練データ、モデル成果物、推論結果の保存
Feature Store	Online / Offline Store の利用
Model Monitor	監視処理やログ保存
CloudWatch	ログやメトリクスの保存

特に注意したいのは、Endpoint は常時稼働になりやすい という点です。

Training Job は学習が終われば終了しますが、Endpoint は削除しない限り稼働し続ける構成になることがあります。

🏋️ Training コストとは？

Training コストは、
モデルを学習するために使うコンピューティングリソースのコスト です。

SageMaker Training Job では、指定したインスタンスタイプと実行時間に応じてコストが発生します。

一言で言うと、以下です。

Training コスト = インスタンス単価 × 学習時間

たとえば、大きなインスタンスを長時間使うと、当然コストは高くなります。

📌 Training コストを左右する要素

Training コストは、主に以下の要素で変わります。

要素	説明
インスタンスタイプ	CPU / GPU / メモリ量によって単価が変わる
学習時間	長く学習するほどコストが増える
データ量	データが大きいほど処理時間が長くなりやすい
モデルの複雑さ	大きなモデルほど計算量が増える
ハイパーパラメータチューニング	複数の学習ジョブを実行するためコストが増える
再学習頻度	頻繁に学習するとコストが増える

Training コストを最適化するには、
単に安いインスタンスを選ぶだけでなく、学習時間や試行回数も意識する必要があります。

🧪 Training コスト最適化の考え方

Training コストを抑えるためには、以下のような方法があります。

方法	説明
適切なインスタンスを選ぶ	必要以上に大きいインスタンスを使わない
小さいデータで先に検証する	いきなり全データで試さない
不要な特徴量を減らす	学習時間やノイズを減らす
Early Stopping を使う	改善しなくなったら学習を止める
チューニング回数を制限する	探索範囲を広げすぎない
Spot Training を使う	中断を許容できる学習でコストを抑える

実務では、最初から大規模に学習するのではなく、
小さく試してから本番規模で実行することが重要です。

🎯 Hyperparameter Tuning のコスト

Hyperparameter Tuning は、モデル性能を改善するために有効です。

しかし、複数の Training Job を実行するため、コストが増えやすいです。

たとえば、1回の Training Job が 1,000円かかるとして、
50通りの設定を試すと、単純計算で 50,000円かかる可能性があります。

もちろん実際の料金は構成によりますが、考え方としては以下です。

Tuning コスト = Training Job のコスト × 試行回数

そのため、チューニングでは以下を意識します。

探索範囲を広げすぎない
重要なハイパーパラメータから試す
最大試行回数を設定する
早期終了を使う
小規模データで傾向を確認する
Bayesian Optimization など効率的な探索を使う

チューニングは「たくさん試すこと」ではなく、
目的に合った設定を効率よく探すこと が重要です。

⚡ Spot Training とは？

Spot Training は、
SageMaker Managed Spot Training を使って、余剰キャパシティを利用し、Training コストを抑える方法 です。

一言で言うと、以下です。

Spot Training = 中断を許容できる Training を安く実行する方法

Spot Training は、通常のオンデマンドインスタンスよりコストを抑えられる可能性があります。

ただし、Spot は中断される可能性があるため、
すべての学習に向いているわけではありません。

✅ Spot Training が向いている場面

Spot Training は、以下のような場面に向いています。

場面	理由
学習が中断されても再開できる	Spot 中断に対応しやすい
コストを大きく抑えたい	通常より安く実行できる可能性がある
長時間の Training	削減効果が大きくなりやすい
実験や検証	本番緊急処理より柔軟に扱える
チェックポイントを保存できる	中断後に再開しやすい

特に、チェックポイントを保存できる学習処理では、Spot Training が使いやすくなります。

⚠️ Spot Training の注意点

Spot Training では、中断に備えることが重要です。

注意点は以下です。

注意点	説明
中断される可能性がある	余剰キャパシティがなくなると止まる場合がある
チェックポイントが重要	途中経過を保存しておくと再開しやすい
緊急性の高い処理には不向き	必ず一定時間内に終わる保証は弱い
再実行設計が必要	中断されても困らない設計にする

試験では、

Training コストを削減したい
中断を許容できる
チェックポイントを保存できる

という文脈で Spot Training が候補になります。

🌐 Endpoint コストとは？

Endpoint コストは、
学習済みモデルをリアルタイム推論用にデプロイしている間に発生するコスト です。

Real-time Endpoint は、低レイテンシーで予測を返すために便利ですが、
構成によってはインスタンスが常時稼働します。

一言で言うと、以下です。

Endpoint コスト = 推論用リソースを起動している時間のコスト

Training Job は終われば停止しますが、Endpoint は消し忘れるとコストが続く点に注意が必要です。

📌 Endpoint コストを左右する要素

Endpoint コストは、主に以下で変わります。

要素	説明
インスタンスタイプ	大きいインスタンスほど高くなりやすい
インスタンス数	複数台にするとコストが増える
稼働時間	起動している時間が長いほどコストが増える
Auto Scaling	需要に応じて台数を調整できる
リクエスト数	負荷が増えるとリソースが必要になる
モデルサイズ	大きなモデルほど高性能リソースが必要になりやすい

Endpoint は本番サービスに直結しやすいため、
コストだけでなくレイテンシーや可用性も考える必要があります。

🔁 Auto Scaling とは？

Auto Scaling は、
リクエスト量や負荷に応じて推論用リソースを自動で増減する仕組み です。

一言で言うと、以下です。

Auto Scaling = 必要なときだけリソースを増やし、不要なときは減らす

たとえば、昼間はアクセスが多く、夜間は少ないサービスを考えます。

昼間：リクエストが多い → インスタンス数を増やす
夜間：リクエストが少ない → インスタンス数を減らす

このようにすることで、性能を保ちながら無駄なコストを抑えやすくなります。

✅ Auto Scaling が向いている場面

場面	理由
リクエスト量が変動する	負荷に合わせてリソースを調整できる
ピーク時だけ負荷が高い	常に最大構成にしなくてよい
コストを抑えたい	低負荷時にリソースを減らせる
一定のレイテンシーを保ちたい	負荷増加時にスケールできる

ただし、Auto Scaling を設定していても、
スケールアウトには一定の時間がかかる場合があります。

そのため、急激なアクセス増加があるサービスでは、余裕を持った設計が必要です。

🧩 Serverless Endpoint とコスト

Serverless Endpoint は、
リクエスト頻度が少ない、または変動するリアルタイム推論に向いています。

Real-time Endpoint のように常時インスタンスを起動し続ける構成より、
アクセスが少ない場合にコスト効率がよくなる可能性があります。

一言で言うと、以下です。

Serverless Endpoint = 少量・不定期アクセスでコストを抑えやすい推論方式

ただし、Day 11 でも整理したように、コールドスタートには注意が必要です。

非常に低いレイテンシーが常に求められる場合は、
Real-time Endpoint の方が適していることがあります。

📦 Batch Transform とコスト

Batch Transform は、
大量データをまとめて推論するための仕組み です。

リアルタイム Endpoint のように常時稼働する必要はありません。

必要なときだけ Batch Transform Job を実行し、
処理が終わればリソースも終了します。

一言で言うと、以下です。

Batch Transform = まとめて処理し、常時稼働コストを避けやすい

たとえば、毎晩1回だけ全顧客のスコアを計算する場合、
Endpoint を常に起動しておくより Batch Transform の方が合うことがあります。

🧭 Endpoint と Batch Transform のコスト比較

観点	Endpoint	Batch Transform
実行形態	常時稼働しやすい	必要なときだけジョブ実行
向いている場面	即時応答	一括処理
コスト注意点	使っていない時間もコストが出る場合がある	大量処理時の実行時間に注意
結果	すぐ返す	S3 に保存
例	Web API、ローン審査	夜間の顧客スコアリング

覚え方は以下です。

リアルタイム性が必要 → Endpoint
まとめて処理でよい → Batch Transform

🧱 インスタンスタイプ選定

SageMaker では、用途に応じてインスタンスタイプを選ぶ必要があります。

大きすぎるインスタンスを選ぶとコストが無駄になります。
小さすぎるインスタンスを選ぶと、処理が遅くなったり、メモリ不足になったりします。

選定時の観点

観点	確認すること
CPU / GPU	GPU が本当に必要か
メモリ	データやモデルがメモリに収まるか
学習時間	小さいインスタンスで遅すぎないか
推論レイテンシー	要求される応答時間を満たせるか
コスト	過剰スペックになっていないか
スループット	必要なリクエスト数を処理できるか

特に、GPU は高価になりやすいため、
本当に GPU が必要な処理なのかを確認することが重要です。

🪣 ストレージコスト

ML ワークロードでは、S3 などのストレージにもコストが発生します。

保存対象には以下があります。

元データ
前処理済みデータ
特徴量データ
モデル成果物
推論結果
ログ
評価結果
モニタリング結果

データを無期限に保存し続けると、ストレージコストが増え続けます。

対策

方法	説明
不要データを削除する	使わなくなった中間ファイルを消す
ライフサイクルポリシーを使う	古いデータを低コストストレージへ移動する
保存期間を決める	ログや一時データを無期限にしない
重複データを減らす	同じデータを何度も保存しない

特に、実験を繰り返すと中間ファイルやモデル成果物が増えやすいので注意が必要です。

📊 Monitoring コスト

Model Monitor や CloudWatch を使った監視も重要ですが、
ログやメトリクスを保存し続けるとコストが発生します。

もちろん、監視をしないのは危険です。

重要なのは、必要な監視を行いつつ、
不要なログや過剰な保存を避けることです。

観点	説明
監視頻度	必要以上に高頻度にしない
ログ保存期間	無期限保存にしない
メトリクス	必要なものを選ぶ
アラート	本当に対応が必要なものに絞る

監視は「多ければ多いほどよい」ではなく、
運用上意味のある監視を設計することが大切です。

☁️ AWS 試験での見られ方

AWS の AI / ML 系試験では、コスト最適化は以下のような文脈で問われやすいです。

「Training コストを抑えたい」

この場合は、以下を考えます。

適切なインスタンスタイプ
Spot Training
Early Stopping
チューニング回数の制限
不要な特徴量の削減

「中断を許容できる学習を安く実行したい」

この場合は Spot Training が候補です。

Managed Spot Training
checkpoint
再開可能

「アクセスが少ないリアルタイム推論を安くしたい」

この場合は Serverless Endpoint が候補になります。

少量アクセス
不定期アクセス
常時稼働を避けたい

「大量データをまとめて推論したい」

この場合は Batch Transform が候補です。

夜間バッチ
一括予測
S3 入出力

「リクエスト量に応じて Endpoint の台数を調整したい」

この場合は Auto Scaling を考えます。

負荷に応じて増減
ピーク時にスケールアウト
低負荷時にスケールイン

👨‍💻 実務目線で見ると

実務では、ML のコスト最適化は単に「安くする」ことではありません。

本当に重要なのは、以下のバランスです。

必要な精度
必要なレイテンシー
必要な可用性
運用負荷
コスト

たとえば、非常に重要な本番 API では、多少コストが高くても Real-time Endpoint を安定稼働させる必要があるかもしれません。

一方で、毎晩1回だけ実行する予測処理であれば、Batch Transform の方が合理的です。

また、実験段階では大規模な GPU インスタンスを使う前に、
小さいデータや小さいインスタンスで試す方が安全です。

コスト最適化は、性能を犠牲にして安くすることではなく、
目的に対して過剰なリソースを使わないこと だと考えると分かりやすいです。

🧠 ここは特に覚えたいポイント

覚え方 1

Training コスト = モデルを作るためのコスト
Inference コスト = モデルを使うためのコスト

覚え方 2

Spot Training = 中断を許容できる Training を安く実行する方法

覚え方 3

Endpoint = 即時応答だが、常時稼働コストに注意

覚え方 4

Serverless Endpoint = 少量・不定期アクセス向け

覚え方 5

Batch Transform = 大量データをまとめて処理し、常時稼働を避けやすい

覚え方 6

Auto Scaling = リクエスト量に応じて Endpoint リソースを増減する

✅ まとめ

今回は、SageMaker のコスト最適化について整理しました。

重要なポイントは以下です。

SageMaker のコストは、Training、Inference、Processing、Storage、Monitoring に分けて考える
Training コストは、インスタンスタイプ、学習時間、データ量、チューニング回数に影響される
Hyperparameter Tuning は有効だが、試行回数が増えるとコストも増える
Spot Training は、中断を許容できる学習でコスト削減に役立つ
Endpoint はリアルタイム推論に便利だが、常時稼働コストに注意が必要
Serverless Endpoint は、少量・不定期アクセスの推論に向いている
Batch Transform は、大量データをまとめて予測する場合に向いている
Auto Scaling は、負荷に応じて Endpoint リソースを増減する仕組み
インスタンスタイプは、性能とコストのバランスで選ぶ必要がある
ストレージやログの保存期間もコストに影響する

ML ワークロードでは、精度だけでなく、
どの構成なら必要な性能を満たしながら無駄なコストを抑えられるか を考えることが重要です。

📌 シリーズまとめ

ここまでの 18 日間では、AWS の機械学習系資格や実務で重要になる内容を整理してきました。

Day 1：機械学習の全体像
Day 2：過学習・未学習・bias / variance
Day 3：データ分割と cross validation
Day 4：Confusion Matrix
Day 5：accuracy / precision / recall
Day 6：F1 Score
Day 7：データ前処理
Day 8：SageMaker の全体像
Day 9：Data Wrangler と特徴量作成
Day 10：Training とハイパーパラメータチューニング
Day 11：SageMaker の推論方式
Day 12：Model Monitor と Data Drift
Day 13：Feature Store
Day 14：SageMaker Pipelines と MLOps
Day 15：Model Registry
Day 16：SageMaker Clarify
Day 17：ML ワークロードのセキュリティ
Day 18：SageMaker のコスト最適化

このシリーズを通して、単にサービス名を覚えるのではなく、

どの場面で何を使うのか
なぜその評価指標を見るのか
モデルをどう学習・デプロイ・監視・改善するのか
安全性とコストをどう考えるのか

を整理してきました。

AWS の機械学習系資格では、個別サービスの知識だけでなく、
データ準備から学習、評価、デプロイ、監視、セキュリティ、コストまでを一連の流れで理解すること が重要です。

以上で、18 日間の AWS Machine Learning 学習メモシリーズを一区切りとします。