Amazon Forecastレビュー【2026年】新規受付は終了、時系列予測の選び方

Amazon Forecastは、AWSが提供してきた時系列予測のマネージドサービスです。2019年8月に提供が始まり、需要予測や在庫計画を、機械学習の知識なしで回せることを売りにしていました。ただし2026年10月28日時点で、新規の利用者は受け付けていません。AWSは2024年7月29日で新規顧客の受付を終え、既存の利用者はこれまでどおり使えると案内しています。この記事は、終了したサービスを無理に勧めるものではありません。公式に何が告知され、当時の料金がどう組み立てられていたかを整理し、いま予測を始めるなら何を選ぶかを考える材料にします。実際の予測精度は未検証です。

結論から。Amazon Forecastは新規の受付を終えている

最初に現況を書きます。Amazon Forecastは、新規の利用者を受け付けていません。公式ドキュメントの冒頭には「Amazon Forecast is no longer available to new customers」とあり、既存の利用者はこれまでどおり使えると続きます。AWSのブログでは、新規顧客の受付を終えた日を2024年7月29日としています。2026年10月28日に確認した範囲で、この状態は変わっていません。

「サービス終了」と「新規受付の停止」は別の話です。既存の利用者は使い続けられ、AWSは安全性、可用性、性能の改善を続けると説明しています。一方で、新しい機能を追加する予定はないとも明記しています。つまり、いまから契約することはできず、使い続けている人にも将来の機能追加は約束されていない、という状態です。この違いは、これから予測の仕組みを作る人にとって決定的です。

面白いのは、製品ページが今も通常の見た目で残っていることです。トップページには需要予測や在庫最適化の利点が並び、無料利用枠の案内もあります。告知はドキュメントとブログの側にあります。検索で製品ページだけを見て「まだ使える」と判断すると、契約の段階で止まります。クラウドのサービスは、製品ページより先にドキュメントの冒頭を見るのが安全です。

「新規受付の終了」は、何を意味するか

新規の受付が閉じると、新しく使い始める道はなくなります。一方で、すでに動いている予測の仕組みは止まりません。この非対称さが、判断を難しくします。社内にForecastで組んだ需要予測があるなら、それは今日も動いています。動いているものを壊す理由はありませんが、次の改修のときに選択肢が減っている、という理解になります。新しく作る側から見ると、最初から別の道具を選ぶのが合理的です。

AWSは移行のための材料も出しています。移行先はAmazon SageMakerの中のCanvasという位置づけです。ブログでは、Forecastの使い方をCanvasへ移すためのワークショップと、学習用データを変換するノートブックが案内されています。移行が「自力で読み替える」だけの話ではなく、手順として用意されている点は評価できます。移行の実務については後の節で整理します。ここでは、このサービスが何をしていたのかを押さえておきます。道具を知らないまま移行先を選ぶと、同じつまずきを繰り返します。

何ができたサービスだったのか。時系列予測の用語を整理

Forecastが引き受けていたのは、時系列データの予測です。売上や出荷数、来客数、人員の必要数といった、時間の並びに沿って記録された数値を渡すと、先の数値を返します。利用者は機械学習の手順を知らなくてもよく、データを整えて渡すことに集中できる、という設計でした。この「手順を隠す」姿勢が、当時の売りでした。

用語は三つだけ押さえれば足ります。データセット、予測子、予測です。データセットは入力の置き場、予測子は学習済みのモデル、予測はその出力です。データセットは三種類に分かれ、対象の時系列、関連する時系列、品目の属性を別々に用意します。この三層の設計が、移行のときに一番の障害になります。

具体例で考えると分かりやすいところです。商品1,000種類を50店舗で売るなら、対象の時系列は5万本になります。関連する時系列には、その商品の価格や天候を入れます。品目の属性には、色やサイズ、カテゴリを入れます。三つを別々に保つことで、属性を直しても過去の予測が崩れにくくなる利点がありました。その代わり、三つの表を同じ粒度で揃える作業が利用者に残ります。

中身の仕組みも公開されています。複数のアルゴリズムを並列に学習させ、成績の良いものを組み合わせて一つの予測子にする、という手順です。欠損値の補完方法も複数用意され、祝日や天気指数といった外部データを組み込めます。天気指数は、季節商品の需要を読むときに効く発想です。このあたりの設計は、予測を専門にしない担当者でも回せるように作られていました。

予測は幅で出ます。これを分位数と呼びます。中央値だけを出せば1本の線ですが、上側と下側を含めると3本になります。在庫の計画なら、売れ残しを避けたいのか、機会損失を避けたいのかで見る線が変わります。この考え方は、ほかの予測の道具に移っても同じように必要です。Forecastを離れるときも、この概念だけは持ち出したほうがいいと考えます。

分位数を増やすと、費用も増える

料金の設計は分位数と直結しています。予測データポイントは、時系列の数と分位数の数と、予測する時点の数を掛けたものとして数えられます。つまり分位数を3本にすれば、料金の対象も3本分になります。予測の期間を延ばせば、時点の数が増えて同じように増えます。精度を上げるために幅を厚く見るほど、請求も厚くなる。予測の解像度と費用は、同じつまみで動くという構造でした。

料金は四つの軸で決まる。当時の単価を読み解く

料金は四つの軸で決まっていました。データの取り込み、予測子の学習、生成した予測データポイント、そして予測の説明です。月額の固定費も最低利用額もなく、使った分だけ増える形でした。一つの請求の中に四つの単位が混ざるため、総額を読むには内訳を追う必要があります。

予測データポイントは段階料金です。最初の10万までが1,000あたり2ドル、次の90万までが0.80ドル、その次の4,900万までが0.20ドル、それを超えると0.02ドルになります。予測の説明も同じ形で、最初の5万までが2ドル、次の95万までが0.80ドル、その次が0.25ドル、1,000万を超えると0.15ドルです。量を出すほど単価が下がる設計で、大規模な小売や物流を想定していたことが読み取れます。

無料枠の期間は2か月です。ほかのAWSのサービスにある12か月の枠とは違い、短く設定されていました。予測の検証は、データの準備に時間がかかります。準備を終えてから枠が始まるわけではないため、慣れていないと枠を使わずに終わるか、逆に一気に使い切るかのどちらかになりがちです。この短さは、試す敷居を下げるどころか、判断を急がせる方向に働いていたと感じます。

学習の時間には注意が要ります。公式の説明では、請求の対象は実際の経過時間ではなく、使ったインスタンスの時間です。複数のインスタンスを並列で動かして学習するため、時計で測った時間より請求上の時間が長くなります。「3時間回したから3時間分」ではない、という点は見積もりで誤解しやすいところでした。

この試算例が示しているのは、費用の大半が予測データポイントで決まるという事実です。取り込みと学習は合わせて1ドル余りで、残りは予測の生成です。だから節約するなら、予測の期間と分位数を絞るのが効きます。データを軽くするとか、学習を短くするといった努力は、費用への影響が小さい。この優先順位は、予測の道具を選ぶときに必ず役に立ちます。

表示は地域・支払い周期・為替で変わるため、契約前に公式サイトの料金表を確認してください。新規の受付は終了しているため、これから契約する用途では使えません。既存の利用者も、請求の内訳と為替の影響は定期的に確認しておくほうが安全です。

費用が膨らむのは、どこか

膨らむ場所は三つです。時系列の組み合わせ数、分位数の本数、予測する時点の数です。商品と店舗の組み合わせが増えれば、その分だけ予測の対象が増えます。分位数を3本にすれば、対象の数がそのまま3本に増えます。予測の期間を1年先まで延ばせば、時点の数が増えます。どれも業務の要求から決まる数字なので、費用を下げるには要求の側を調整するしかありません。予測の費用は、精度の要求と期間の要求でほぼ決まるというのが当時の構造でした。

評価できる点（公開情報からの判断）

• 手順を隠してくれる設計。アルゴリズムの選択と組み合わせを自動で試すため、利用者はデータの準備に集中できる
• 予測を幅で出せる。分位数を使えば、在庫の持ち方を上側と下側で切り替えて考えられる
• 予測の理由を説明する機能があった。どの属性が結果に効いたかを確認できる
• 祝日や天気指数などの外部データを、設定だけで組み込めた
• 料金の4軸と段階表が公開され、自社の条件で試算できた

設計としては、よく出来ていたと考えます。予測の専門家がいない組織でも、データを整えて渡せば一定の水準に到達する。この一点に価値がありました。アルゴリズムを自分で選び、特徴量を作り、交差検証を回す。この工程を丸ごと引き受ける道具は、当時は多くありませんでした。予測の民主化という言葉が似合う作りだったと読めます。

分位数を最初から扱えた点も見逃せません。予測を1本の線で出す道具は多くありますが、幅で出す道具は限られます。発注の判断は「売れる見込み」ではなく「最悪どこまで振れるか」で決まることが多い。その要求に正面から応えていました。移行先を選ぶときも、この性質があるかどうかは確認したいところです。

気になった点・条件付きの評価

• 新規には提供していない。これから予測を始める人が選べない時点で、レビューの対象としては終わっている
• 新機能の追加予定がない。改善は続くが、機能は増えないと明記されている
• 4軸の従量課金で、月の請求を読むのに内訳の把握が要る
• 学習の時間はインスタンス時間で数えられ、実際の経過時間と一致しない
• データセットが三種類に分かれ、前処理の設計が重い
• 移行にはデータ形式の変換が要る。公式の変換用ノートブックがあっても、確認の作業は残る
• 予測精度は未検証。当時の出来をこの記事で評価することはできない

一番の短所は、サービスとしての寿命です。新規の受付が閉じた道具を、これから選ぶ理由はありません。どれだけ設計が良くても、次の改修で機能が増えない前提を受け入れることになります。これは道具の出来の問題ではなく、選ぶ側の事情です。「良い道具だった」と「いま選ぶべき道具だ」は別の判断だという、分かりやすい例になっています。

二つ目は、料金の読みにくさです。4つの単位が同じ請求に並ぶため、最初の月に何にいくら払ったのかが分かりにくい。特に学習の時間は、並列で動くインスタンスの分だけ増えます。予測データポイントは、時系列と分位数と時点の積です。この掛け算を頭の中で追えないと、見積もりは外れます。慣れるまでは、公式の試算例を自分の数字に置き換えて確かめるのが早道でした。

三つ目は、前処理の重さです。対象の時系列、関連する時系列、品目の属性を別々のデータセットとして用意します。慣れた人には整理された設計ですが、初めて触る人には手間です。CSVを一つ渡せば終わりの道具に慣れていると、ここで止まります。移行先でデータセットが1つになる、という変更は、この手間を減らす方向の改善です。移行の話は、単なる置き換えではなく、この設計の整理でもあります。

四つ目は、情報の鮮度です。これは短所というより条件の話になります。画面や手順は、告知の前後で変わっている可能性があります。移行を調べるときは、日付の新しい公式ドキュメントを先に読むのが安全です。古い手順をなぞって画面が見つからない、という時間の使い方が一番もったいありません。

向き不向きの見極め

いま向く人は、既にForecastで動かしていて、そのまま使い続けたい人だけです。動いているものを急いで移す必要はありません。一方で、これから需要予測を始める人、予測の精度を上げたい人、機能の追加を期待したい人には向きません。移行を考えるべきなのは、次の改修の予定があるとき、新しいデータ形式に対応したいとき、担当者が替わるときです。「動いているから残す」と「いつか移る」を、同時に決めておくのが現実的な落としどころだと考えます。

移行先をどう選ぶか。SageMaker Canvasという答え

AWSが示している移行先は、Amazon SageMaker Canvasです。コードを書かずにモデルを作る道具で、時系列予測の機能も持っています。公式の説明では、データセットが1つで済み、モデルを配備して呼び出す形になります。Forecastのように、まず予測を作ってから問い合わせる、という二段構えではありません。

画面で完結する点も、Canvasの性格です。Forecastは設定項目が多く、コンソールとAPIの両方を行き来する必要がありました。Canvasはモデルを作るところから配備までを画面でたどれます。ただし、画面でできることとAPIでできることの差は確認しておくべきです。自動化する段階になって、画面にしかない機能があると止まります。この確認は、契約の前でもできます。

AWSの発表では、Canvasのほうがモデル構築と予測が速く、費用も抑えられると説明されています。ただしこれは提供元の主張で、条件の選ばれた比較です。自社のデータで同じ結果になるとは限りません。この種の説明は、判断の出発点にはなっても、結論にはなりません。実際に自社の時系列を一つ持っていって、同じ期間で予測を出し、誤差を見る。その一手間を省くと、あとで後悔します。

移行の実務で残る作業は三つあります。データの変換、予測の呼び出し方の変更、そして結果の受け取り方の変更です。データの変換は、公式のノートブックがある程度助けてくれます。呼び出し方の変更は、プログラムの書き換えになります。Amazon Q Developerのような補助を使えば、この書き換えの下書きは作れます。結果の受け取り方は、後続の集計や発注の処理に影響します。三つ目の作業が見えにくく、日程を狂わせます。

判断の分かれ目。残すか、移すか

分かれ目は、次の改修がいつ来るかです。半年以内に予測の対象を増やす予定があるなら、その機会に移すのが効率的です。当分の改修予定がないなら、無理に動かす必要はありません。もう一つの分かれ目は、予測を誰が触るかです。データの担当者が画面で完結させたいならCanvas、プログラムに組み込みたいなら別の選択肢になります。道具の優劣ではなく、次の変更の予定で決めるのが、この場面の正しい順序だと考えます。

これから予測を始めるなら。選択肢の整理

新しく予測を始める場合、選択肢は大きく三つです。マネージドの予測機能を使う、ノートブックで自分で組む、表計算の延長で済ませる。どれが良いかは、予測の対象数と、更新の頻度で決まります。対象が数十で、月に一度の見直しなら、表計算でも足ります。対象が数千を超え、毎日更新するなら、仕組みを持つほうが安くなります。

表計算の延長で始めるなら、Smartsheetのような表の道具に予測の機能を足す形があります。ノートブックで組むならDeepnoteのように、Pythonの環境を用意せずに済む道具があります。どちらも、Forecastが隠していた手順を、自分で持つことになります。手順を持つのは手間ですが、その分だけ中身が見えます。どの段階で仕組みに任せるかは、対象の数が増えたときに考えれば間に合います。

生成AIは、予測そのものより周辺で効きます。ChatGPTやClaudeに、予測結果の読み方を文章にさせたり、外れた理由の仮説を並べさせたりする使い方です。GeminiやDeepSeekも同じ用途で使えます。数字を出すのは予測の道具、数字を説明するのは生成AI、という分担です。逆に、生成AIに数字を出させると、根拠のない値が混ざります。ここは役割を分けたほうが安全です。

仕組みに任せるか、自分で持つか

予測の道具を選ぶとき、判断が割れるのがこの一点です。マネージドの機能は、手順を隠してくれる代わりに、中身が見えません。自前で組むと、中身は見えるが、手順を自分で持つことになります。Forecastは前者の極端な例でした。どちらが優れているかではなく、予測を誰が説明する必要があるかで決めるのが実務的です。「なぜこの数字なのか」を社内外に説明する場面があるなら、中身が見える側を選ぶほうが後で楽になります。

検証の順序

検証は四段で進みます。予測したい対象を一つ決める。過去の実績を、予測に使える形で揃える。同じ期間で二つの方法の予測を出し、誤差を比べる。そして、その誤差が業務の判断に耐えるかを見る。三段目までは技術の話で、四段目が事業の話です。誤差が小さくても、発注の単位より細かければ意味がありません。予測の良し悪しは、誤差ではなく発注の判断で決まるという見方を忘れないでください。

運用に移したあとは、更新の自動化を考えます。データの取り込み、学習、予測の生成、結果の配布。この流れを手で回すと、忙しい月に止まります。Makeのような連携の道具で、定期的に流す形にしておくと、止まりにくくなります。手順と担当は、Notion AIのような社内の置き場に残しておくと、担当が替わっても回ります。予測の仕組みは、作るより維持するほうが長い時間を使います。

よくある質問

まとめ

主な参照元：AWS公式のAmazon Forecast製品ページおよび料金ページ（2026年10月28日確認）、Amazon Forecast開発者ガイド「What Is Amazon Forecast?」（同日確認）。新規受付の終了日、既存利用者の扱い、移行の案内は出典：AWS Machine Learning Blog「Transition your Amazon Forecast usage to Amazon SageMaker Canvas」（2026年10月28日確認）。実機検証は未実施。予測精度は未検証。