Amazon Forecastとは？新規受付終了後の移行先と実装判断【2026年版】

Amazon Forecastは、時系列データをCSVで渡すだけで需要や在庫の将来値を返してくれるAWSのマネージド予測サービスです。ただし2024年7月29日をもって、新規顧客への提供は終了しました。すでにアカウントで使っている場合だけ継続でき、AWSは移行先としてAmazon SageMaker Canvasを案内しています。本記事では、Forecastが何を引き受けるサービスなのか、6つの組み込みアルゴリズムと3種のデータセットという設計、予測データポイント単位の課金構造、そしてSageMaker AI側のAutoML V2へ移す際のAPI対応までを、実装と費用の観点で並べます。

まとめ：新規受付終了後の移行先とForecastを継続できる条件

結論から。これから時系列予測をAWSで組む案件で、Amazon Forecastを新規に契約する道はありません。2024年7月29日以降、新規顧客の受付は閉じています。

新規案件の第一候補はAmazon SageMaker Canvasと、その裏側で動くSageMaker AIのAutoML V2です。Forecastが持っていた6つのアルゴリズムはそのままモデル候補として引き継がれており、予測の質を落とさずに移れます。UIで完結させたいならCanvas、パイプラインに組み込むならCreateAutoMLJobV2を直接叩く構成になります。

既存利用者が急いで移る必要はありません。AWSはセキュリティと可用性の改善を続けると明言しており、サンセット期日も公表されていないためです。ただし新機能は今後いっさい載りません。移行の合図になるのは、予測頻度や分位点の要件が変わってForecast側の仕様で足りなくなった時点です。

Amazon Forecastの定義｜時系列予測をマネージドで完結させる仕組み

まず何を引き受けるサービスなのか。公式ドキュメントの定義から確かめます。

Forecastが扱う3種のデータセットと予測期間・分位点の設定

AWSはForecastを「統計アルゴリズムと機械学習アルゴリズムを用いて高精度な時系列予測を提供するフルマネージドサービス」と定義しています。基盤にあるのは、Amazon.comが自社の時系列予測に使ってきた技術です。機械学習の経験は前提にされていません。

入力は3種類のデータセットに分かれます。1つ目がターゲット時系列で、アイテム識別子・タイムスタンプ・予測したい値の3列が骨格。2つ目が関連時系列で、価格や販促フラグのように予測値と相関する変数を置きます。3つ目がアイテムメタデータで、商品の色やブランドといった時間に依存しない属性を渡す枠です。

この3つをデータセットグループとしてまとめ、予測器を学習させ、予測を生成する。工程はこの3段構えで、いずれもAPI・CLI・Python SDK・コンソールから実行できました。返る予測は単一の点ではなく分位点で、在庫を切らしたくない場面では上側の分位点を採るという使い分けができます。

データ要件の考え方はAmazon Personalizeのレシピ選定とデータ要件と同じ型で、先にスキーマを決めてから学習へ入る流れになります。

6つの組み込みアルゴリズムとAutoMLが選ぶモデルの適用場面

Forecastは6つのアルゴリズムを内蔵しています。統計手法のARIMAからニューラルネットワークのCNN-QRやDeepAR+までが同じ土俵に並ぶ構成。決められないときはAutoMLを指定し、データセットに合う組み合わせをサービス側に探させます。

使い分けの分岐は系列数です。100系列を下回る単純なデータならARIMAかETSで足り、数百系列を超えてアイテムメタデータも渡せるならCNN-QRかDeepAR+へ寄せます。NPTSには標準・季節・気候値・季節気候値の4変種があり、間欠需要の在庫予測で効きます。

関連時系列の受け取り方には差があります。将来値のない履歴だけの関連時系列を受け取れるのはCNN-QRだけ。前方参照ぶんを渡す構成ならCNN-QR・DeepAR+・Prophetの3つが候補です。アイテムメタデータを見るのはCNN-QRとDeepAR+のみ、ハイパーパラメータ探索が回るのもこの2つに限られます。Prophetの内部仕様はProphetの仕組みと使い方にまとめました。

天気インデックスと祝日カレンダーによる組み込み特徴量の効かせ方

Forecastには特徴量を自前で作らずに足せる仕掛けがあります。ひとつが天気インデックスで、対象地点の気象データを特徴量として取り込む機能。小売や飲食のように天候で需要が動く領域では、これだけで誤差が縮む場面があります。

対応するのはCNN-QR・DeepAR+・Prophetの3つ。ARIMA・ETS・NPTSでは効きません。天候を効かせたいなら、この時点でアルゴリズム候補が絞られます。

もうひとつが欠損値の補完です。ターゲット列や数値列の欠けをサービス側の補完方式で埋められるため、前処理で全期間を埋め直す作業を省けました。加えて説明可視化の機能があり、どの特徴量が予測に効いたかを見られます。ただしこちらは別課金です。

2024年7月29日の新規顧客受付終了と2026年7月時点の提供状況

ここが本記事の主題です。告知の中身を条文の粒度で押さえます。

AWS公式ドキュメントの告知文が示す既存顧客と新規顧客の線引き

開発者ガイドの各ページ冒頭には、いまも同じ一文が出ます。「Amazon Forecastは新規顧客には利用できなくなりました。Amazon Forecastの既存のお客様は、通常どおりサービスを引き続き使用できます」という告知です。新規受付が閉じたのは2024年7月29日でした。

既存顧客への約束は具体的です。AWSはセキュリティ・可用性・パフォーマンス改善への投資を続けると述べています。一方で新機能の追加は予定していないと明記されました。

動いている予測器が止まる話ではなく、止まったのは開発です。この線引きを押さえれば、検討すべきは「いつ移るか」だけに絞られます。

AWSのメンテナンス・サンセット・全面停止という3段階の位置づけ

AWSはサービスのライフサイクルを3段階で定義しています。Maintenanceは新規オンボードができず、既存利用は継続でき、機能追加を行わない状態。Sunsetは通常12か月ほどの期限が示され、その日にAWSが運用とサポートを終える段階。Full Shutdownはポートフォリオから完全に外れる最終段階です。

この区分に照らすと、Forecastはメンテナンス相当の扱いにあります。新規受付が閉じ、既存顧客のサポートが続き、機能追加が止まっているという3条件が一致するためです。

参考になるのが同じAWSのAIサービスで先を行く事例で、Amazon Kendraの新規受付終了と移行先の判断は2026年6月30日にメンテナンスモードへ移り、7月30日から新規受付を止めました。告知の書き方も移行先の指名の仕方も、Forecastのときと同じ型でした。

「サービス終了」と検索される背景と、終了期日が未公表である事情

キーワードを調べると「amazon forecast サービス終了」「amazon forecast 終了」という検索が実際に立っています。既存利用者が期日を探している状況が透けて見えます。

結論として、終了期日は公表されていません。2026年6月30日公開のサービス提供状況アップデートでは11サービスがメンテナンスへ移行し、5サービスにサンセット予定が示されましたが、その一覧にForecastの名前はありませんでした。

読めるのは2点。新規受付停止から2年たってもサンセット段階へ進んでいないこと。進む場合もAWSの慣例どおり12か月ほどの猶予が示される見込みで、いま慌てて書き換える段階ではないと判断できます。

Amazon Forecastの3つの課金軸と無料枠｜予測数・学習時間・取り込み

費用はインスタンス時間ではなく、生成した予測の量で決まります。

予測データポイント単価の4段階と学習時間・データ取り込みの単価

課金軸は3つです。生成した予測データポイント数、学習に要した時間、そして取り込んだデータ量。予測データポイントの単価は使用量に応じて4段階に下がります。

単価の落ち方が急です。最初の10万ポイントと5,000万超では100倍の差があり、小規模な検証は単価の最も高い帯に留まるため1件あたりの体感コストは高くつきました。

1万系列を日次で回した場合の概算費用とSageMaker側との差

試算します。1万アイテムを28日先まで日次で予測し、分位点を3つ取ると、生成される予測データポイントは1万×28×3で84万。単価表に当てはめると最初の10万ぶんが200 USD、残り74万ぶんが592 USDで、予測生成だけで792 USDになります。

ここへ学習時間と取り込みが乗ります。学習が月10時間で2.4 USD、取り込みが5GBで0.44 USD。予測を週次で回すなら生成分が4倍に膨らむ計算です。

移行先の課金構造はここが変わります。SageMaker側は予測データポイント単位ではなく、AutoMLジョブが使った計算リソースの時間で課金されます。AWSの移行ガイドも、この違いを費用面の改善点として挙げていました。予測本数が多く分位点も多い構成ほど、移行の金額的な効果は大きく出ます。

無料枠の数値が公式ページ間で揃っていない点と見積もりでの読み方

無料枠は最初の2か月間だけ使えます。料金ページの表記では、月あたり予測データポイント10万・ストレージ10GB・学習時間10時間まで。

ただし開発者ガイド側の記述は「月10,000件の時系列予測」で、料金ページの10万データポイントと数値が揃っていません。見積もりを起こす際は、単価が明示されている料金ページ側を根拠に採ったうえで、無料枠は検証1〜2回ぶんと割り切るのが安全です。

SageMaker AI AutoMLへの移行｜6アルゴリズムの継承とAPI実装

移行先の中身を確かめます。乗り換えても予測手法は変わりません。

Forecastの6アルゴリズムがAutoMLのモデル候補に残った経緯

AWSが指名した移行先はAmazon SageMaker Canvasです。ノーコードのUIで時系列予測モデルを作れるサービスで、裏側ではSageMaker AIのAutoMLが動きます。

ここが移行判断の要点になります。AutoMLは6つのモデル候補を学習し、スタッキングアンサンブルで束ねて1つの予測モデルを作る設計。この6候補はForecastの組み込みアルゴリズムと同じ系譜で、AlgorithmsConfigのAutoMLAlgorithmsで部分集合も指定できます。公式ドキュメントの例ではcnn-qr・prophet・arimaの3つが列挙されていました。

予測の返り方も同じです。分位点はP1からP99の範囲で、既定はp10・p50・p90の3つ。自前で指定する場合は0.01刻み以上で最大5つまで。Forecastで組んでいた分位点の設計をそのまま持ち込めます。

移行ガイドが挙げる改善点は3つ。ベンチマークで学習が最大50%高速化し予測生成も平均最大45%速くなること、学習済みモデル本体と検証データや指標へ直接アクセスできる透明性、そして計算リソース時間ベースの課金です。

CreateAutoMLJobV2で指定する予測頻度・期間・分位点の上限

時系列予測はAutoML REST APIのv2からしか呼べません。CreateAutoMLJobV2にTimeSeriesForecastingJobConfigを渡す形です。必須項目は予測頻度・予測期間・列マッピングの3つ。

"AutoMLProblemTypeConfig": {
  "TimeSeriesForecastingJobConfig": {
    "ForecastFrequency": "D",
    "ForecastHorizon": 28,
    "ForecastQuantiles": ["p10", "p50", "p90"],
    "TimeSeriesConfig": {
      "TargetAttributeName": "demand",
      "TimestampAttributeName": "timestamp",
      "ItemIdentifierAttributeName": "item_id"
    },
    "HolidayConfig": [{"CountryCode": "JP"}]
  }
}

予測頻度は整数と単位の組み合わせで書きます。有効範囲は分が1から59、時が1から23、日が1から6、週が1から4、月が1から11、年が1のみ。1時間ごとなら60分ではなく1時間と書く決まりで、上位の単位と重なる指定は通りません。

予測期間の上限は2つの条件のうち小さい方です。500タイムステップか、データセットのタイムステップ数の4分の1。加えてAWSは、将来1点あたり履歴3〜5点を推奨しています。日次で7日先を予測するなら、学習データは21日から35日ぶん以上。ここを満たさないと季節性を拾えません。

祝日はHolidayConfigに2文字の国コードを渡すだけで、250か国超のカレンダーが特徴量として足されます。目的指標の既定はAverage Weighted Quantile Loss。最良候補をそのままエンドポイントへ自動デプロイする設定も用意されています。

3種のデータセットを1つへ統合する移行手順と欠損補完の設定方法

移行の実作業はデータ整形に集まります。Forecastで3つに分かれていたターゲット時系列・関連時系列・アイテムメタデータを、1つのデータセットへ統合する工程です。Canvas UIのデータフローで結合するか、AWSが公開しているPythonスクリプトを回します。

統合後の設定で対応するのが集約と補完です。集約はTransformationsのAggregationで指定し、既定は合計。平均・先頭・最小・最大も選べますが、対象はターゲット列だけ。日次データに週次の予測頻度を指定した場合、この設定に従って週単位へまとめられます。

欠損補完は列ごとに方式を書きます。系列の途中を埋めるmiddlefill、末尾側を埋めるbackfillなどを指定し、固定値で埋めるなら値を持つパラメータを併記する形式です。Forecast側の補完設定をそのまま写せる粒度になっています。

データ量が30GBを超える場合は、EMR Serverlessへ自動で処理を逃がす設定を足すようAWSが推奨しています。取り込み側の設計はデータパイプラインの構成要素と設計判断で整理した考え方が使えます。アルゴリズム自体の選び分けは需要予測アルゴリズムの選び方と実装手順に実装例つきでまとめました。

新規案件での経路選択と、既存Forecast利用者が移行を急ぐ条件

ここから先は判断です。条件を切って言い切ります。

マネージドAutoMLで足りる条件｜データ量と精度要件からの線引き

Forecastが選べない以上、実際の分岐は「SageMakerのマネージドAutoMLで足りるか、自前で組むか」に移ります。マネージド側で足りるのは、次の3条件が揃うときです。系列数が数十から数万に収まること。予測頻度が分単位から年単位の定義済み粒度で表せること。そして分位点3〜5本で意思決定できること。

この3条件を満たすなら、迷わずCanvasかAutoML V2を選んでください。6アルゴリズムのアンサンブルが自動で回り、モデル選定に時間を使わずに済みます。まずCanvasで精度の当たりを付け、運用に載せる段階で同じ設定をCreateAutoMLJobV2へ移す進め方が手戻りの少ない順序です。

設計から実装まで任せたい場合はAI予測分析開発・需要予測開発でご相談ください。予測モデルだけでなく、発注や人員配置の意思決定へどう繋ぐかまで含めて設計します。

既存のForecast環境を当面そのまま置いてよい構成と移行の合図

既存利用者が急いで移すべきか。判断軸は依存度です。

そのまま置いてよいのは、天気インデックスやNPTSの気候値変種といったForecast固有の機能に乗っており、かつ予測本数が月10万ポイントを下回る構成。この規模なら単価の高い帯でも月200 USD前後で収まり、書き換え工数のほうが高くつきます。セキュリティ更新は続くのですから、動いているものを止める理由はありません。

移行の合図は3つあります。予測本数が増えて月の請求が数百USDを超えてきたとき。モデル本体や検証データを見て精度を追い込む必要が出たとき。そして分位点や予測頻度の要件が変わり、既存の予測器では表現できなくなったとき。いずれかに触れた時点で、統合済みデータセットを作る作業から着手してください。

マネージドな自動予測を見送って自前実装へ振るべき3つの場面と条件

第一に、予測ロジックについて説明責任を負う領域です。アンサンブルで束ねたモデルは、どの候補がどう寄与したかを条文レベルで示せません。需要計画の根拠を社内監査へ出す要件があるなら、単一モデルで係数を開示できる構成へ切り替えるべき場面です。

第二に、系列数が数十本以下で季節性も明確なケース。ARIMAやProphetを直接回せば学習は数秒で終わり、AutoMLで6候補を回す計算コストのほうが割高になります。

第三に、データウェアハウス側に予測機能が揃っている場合。SQLだけで予測と異常検知を回すML関数の使い方で扱った型なら、データを外へ出さずパイプラインの本数も増やさずに済みます。

よくある質問

Amazon Forecastの検討時に実際に検索されている質問へ、2026年7月時点の公開情報をもとに答えます。

Amazon Forecastは今から新規に使い始められますか？

できません。AWSは2024年7月29日をもってAmazon Forecastの新規顧客への提供を終了しており、開発者ガイドの各ページにも同じ告知が出ています。すでに使っているアカウントであれば、これまでと同じように予測器の学習も予測の生成も続けられます。これから時系列予測を組むなら、AWSが移行先として案内しているAmazon SageMaker Canvas、またはSageMaker AIのAutoML V2を使ってください。

Amazon Forecastはサービス終了するのですか？

終了の期日は公表されていません。新規受付が閉じただけで、既存顧客に対してはセキュリティ・可用性・パフォーマンスの改善が続く状態です。2026年6月30日に公開されたAWSのサービス提供状況アップデートでも、サンセット予定として名前が挙がった5サービスにForecastは含まれていませんでした。AWSの慣例ではサンセット段階に入ると12か月ほどの期限が示されるため、告知が出てから移行計画を立てる時間は残ります。

Amazon Forecastの料金はどのくらいかかりますか？

課金軸は生成した予測データポイント数・学習時間・取り込みデータ量の3つです。予測データポイントは最初の10万ぶんが1,000あたり2.00 USDで、使用量が増えるほど4段階で単価が下がり、5,000万超では1,000あたり0.02 USDになります。学習は1時間0.24 USD、取り込みは1GB0.088 USD。1万アイテムを28日先まで分位点3本で予測すると84万ポイントとなり、生成だけで約792 USDという規模感です。無料枠は最初の2か月間のみ使えます。

ForecastからSageMakerへの移行はどこから手を付けますか？

データセットの統合からです。Forecastで3つに分かれていたターゲット時系列・関連時系列・アイテムメタデータを1つのCSVへまとめます。Canvas UIのデータフローで結合するか、AWSが公開しているPythonスクリプトを使う2通り。統合後に予測頻度と予測期間、分位点を設定してAutoMLジョブを起動します。予測期間の上限は500タイムステップかデータセット長の4分の1のいずれか小さい方なので、既存の予測期間がここに収まるかを先に確認しておくと手戻りが減ります。

Amazon Forecastのアルゴリズムはどれを選ぶべきでしたか？

系列数で分かれます。100系列を下回る単純なデータならARIMAかETS、数百系列を超えてアイテムメタデータも渡せるならCNN-QRかDeepAR+が候補でした。間欠需要にはNPTS、季節性が強く履歴も数季節ぶんあるならProphetが向きます。将来値のない関連時系列を渡せるのはCNN-QRだけという制約もありました。SageMaker側のAutoMLへ移った後は、同じ系譜の6候補が自動で比較されるため、この選定作業自体を手放せます。

関連記事

• 需要予測アルゴリズムの選び方と実装手順：時系列と機械学習の手法をPythonの実装例つきで比べています
• Prophet（Meta）とは：Forecastが内蔵していたアルゴリズムを単体で掘り下げました
• Amazon Kendraとは：同じ型で新規受付を終えたAWSサービスの移行判断です
• Amazon Personalizeとは：レシピ選定とデータ要件の考え方が予測設計にも効きます
• 需要予測とは：手法とシステム導入の進め方を事業側の視点で整理しています