Prophet(Meta)とは|時系列予測ライブラリの仕組み・使い方と2026年の開発状況
Prophetは、Facebook(現Meta)のCore Data Scienceチームが2017年に公開した時系列予測ライブラリです。日本語の解説記事では「開発が止まったライブラリ」と書かれることも増えましたが、これは半分だけ正しい。公式リポジトリは2025年10月から2026年1月にかけてv1.2.0からv1.3.0までを続けて出しており、pandas 3.0とNumPy 2.4への対応も済んでいます。一方で、モデル本体の新機能はもう増えません。この記事では、加法モデルの仕組みと最小コードに加え、公式が明言した開発方針と、その事実を踏まえた「2026年にProphetを選ぶ基準」まで一次情報で整理します。
まとめ
Prophetは時系列をトレンド+季節性+休日効果+ノイズに分解する加法モデルで、日付列 ds と値列 y の2列を fit() して predict() するだけで予測が出ます。ライセンスはMIT、導入は pip install prophet の一行で、v1.1以降はビルド済みバイナリが配布されるためStanのコンパイルは不要です。最新版はv1.3.0(2026年1月27日リリース、pandas 3.0・NumPy 2.4対応)。ただし公式は2023年の方針表明で「Stanモデル本体にはこれ以上変更を加えない」と述べ、最先端の予測を求める人にはNeuralProphetやNixtlaのstatsforecastを勧めています。つまりProphetは枯れた実務ツールとして使い、精度の限界を感じたら乗り換えるのが正しい付き合い方です。以下、仕組み・使い方・パラメータ・他手法との比較を順に見ていきます。
Prophetとは|Metaが公開した時系列予測ライブラリ
Prophetは、Metaが自社の需要予測ニーズから生み出し、オープンソースとして公開した予測ツールです。手法の詳細はSean J. TaylorとBenjamin Lethamによる論文「Forecasting at scale」(The American Statistician 72巻1号 37-45ページ、2018年)にまとまっています。PythonはPyPI、RはCRANで配布され、ライセンスはリポジトリのLICENSEファイルのとおりMITです。商用利用も改変も可能で、著作権表示を残せば足ります。
設計思想は「統計の専門家でなくても、業務データの予測を回せること」。定常性の検定やパラメータの次数決定といった前処理を要求せず、既定値のまま動かしても実務で使える水準の予測を返します。読み方は「プロフェット」。英単語の prophet(預言者)と綴りは同じですが、検索意図としては別物です。
加法モデル(GAM)の構造
Prophetは時系列を成分の足し合わせで表す一般化加法モデル(GAM)です。基本式は次の形になります。
y(t) = g(t) + s(t) + h(t) + ε_t
g(t) はトレンド、s(t) は季節性、h(t) は休日・イベント効果、ε_t は誤差です。季節性はフーリエ級数で近似され、波の数(fourier_order)が大きいほど細かい周期の形まで表現できます。トレンドは growth 引数で切り替えでき、既定の linear(線形成長)のほか、上限に向けて鈍化する logistic、トレンドを持たせない flat の3種類が実装されています(forecaster.py の Prophet.__init__)。飽和のあるサービス利用者数なら logistic、水準が動かない在庫回転のような系列なら flat が候補になります。
トレンドの折れ曲がり(変化点)は自動検出されます。既定では学習期間の最初の80%(changepoint_range=0.8)に25個(n_changepoints=25)の候補点を置き、そこから実際に効く点を選ぶ仕組みです。末尾20%に候補を置かないのは、直近のノイズを過剰にトレンド転換と解釈して予測が暴れるのを避けるためです。
向くデータと向かないデータ
力を発揮するのは、週次・年次の明確な季節性があり、数シーズン分の履歴がある日次・週次データです。小売の売上、Webサイトの流入、来店者数などが典型例になります。逆に、秒・分単位の高頻度データ、季節性のないランダムウォークに近い系列、履歴が1年に満たないデータでは精度が出ません。年次季節性を推定するには最低でも2周期=2年程度の履歴が要る、と考えておくと判断を誤りません。
2026年のProphet|開発終了ではないが、新機能も増えない
ここが多くの日本語記事で曖昧なままの論点です。結論から書くと、Prophetは保守されているが進化はしない。この2つは矛盾しません。
公式リポジトリのメンテナは2023年の方針表明で「基盤となるStanモデルにこれ以上の変更を加える予定はない」と明言し、あわせて「予測分野の最先端を求めるなら、NeuralProphetやNixtlaのstatsforecastといったパッケージを試してほしい」と書いています。つまりモデルの表現力はここで固定されました。一方で、依存ライブラリ追従・祝日データ更新・ビルド周りの保守は続いています。
直近リリースの変更点
GitHubのリリース履歴が示す実績は次のとおりです。「2023年で止まっている」という前提でバージョンを固定しているなら、更新の余地があります。
| バージョン | 公開日 | 主な内容 |
|---|---|---|
| v1.2.0 | 2025-10-19 | CmdStanを最新版へ更新 |
| v1.2.1 | 2025-10-21 | CmdStan同梱まわりの修正 |
| v1.2.2 | 2026-01-25 | CRANポリシー適合・祝日データ再生成 |
| v1.3.0 | 2026-01-27 | pandas 3.0・NumPy 2.4 対応 |
実務上いちばん効くのはv1.3.0です。Pandas 3.0やNumPy 2系へ移行した環境では、古いProphetがバージョン上限で弾かれて依存解決に失敗します。PyPI上のv1.3.0が要求する依存は cmdstanpy>=1.0.4、pandas>=1.0.4、numpy>=1.15.4、holidays>=0.25,<1 などで、Stanのコンパイル環境は不要です(v1.1でPyStan2からcmdstanpyへ切り替わり、ビルド済みバイナリがPyPIから配布されるようになりました)。同じv1.1で最低Pythonバージョンは3.7以上になっています。
それでもProphetを選ぶ基準
公式が乗り換えを勧めている以上、「とりあえずProphet」は思考停止です。選ぶ理由は次の3点に絞られます。①予測の根拠を人に説明する必要がある(成分分解の図をそのまま会議に出せる)、②系列が数十〜数百本で、1本ずつ短時間で回したい、③キャンペーンや祝日の効果を明示的に入れたい。逆に、最高精度が要件で説明責任が薄いバッチ予測、あるいは分単位の高頻度データなら、Prophetを起点にする必然性はありません。GMOインターネットグループの技術ブログが公開したTimesFM・Prophet・SARIMAの比較実験では、合成データと航空旅客数データの両方でProphetがTimesFM(Googleの時系列基盤モデル)よりMAEで良い結果を出しています。基盤モデルが常に勝つわけではない、という点は押さえたうえで、要件から逆算して選んでください。
インストールと最小コード
Pythonはpipで一行です。旧パッケージ名 fbprophet はv1.0で prophet に改名されており、いま pip install fbprophet を実行すると2020年で更新の止まった別パッケージが入ります。from fbprophet import Prophet と書いてある古い記事のコードは、そのまま動かさないでください。
pip install prophet
入力は、日付列 ds と予測対象の値列 y を持つpandasのDataFrameだけです。ds は YYYY-MM-DD 形式の日付かdatetime、y は数値。欠損日があっても事前の穴埋めは不要で、外れ値はNaNに置き換えれば学習から除外されます。
import pandas as pd
from prophet import Prophet
df = pd.read_csv("data.csv") # 列は ds, y の2列
m = Prophet()
m.add_country_holidays(country_name="JP") # 日本の祝日効果を追加
m.fit(df)
future = m.make_future_dataframe(periods=90) # 90日先まで
forecast = m.predict(future)
print(forecast[["ds", "yhat", "yhat_lower", "yhat_upper"]].tail())
add_country_holidays() に国コードを渡すと、依存する holidays パッケージの祝日表がそのまま休日効果として組み込まれます。日本の小売・来店データでは祝日効果の有無が予測に効くため、fit() の前に必ず検討する引数です。可視化はMatplotlibベースのメソッドが用意されています。
m.plot(forecast) # 実測・予測・予測区間
m.plot_components(forecast) # トレンド・週次・年次・休日効果に分解
Rで使うときの落とし穴
R版は install.packages('prophet') で入りますが、公式READMEは「CRAN版はかなり古く、最新のバグ修正と祝日データを得るには最新リリースの導入を推奨する」と警告しています。祝日データが古いまま日本の祝日効果を使うと、直近の祝日変更が反映されません。R側で実務に使うなら、GitHubのリリースから入れるのが安全です。
install.packages('remotes')
remotes::install_github('facebook/prophet@*release', subdir = 'R')
予測結果の読み方|yhatと予測区間
predict() が返すDataFrameで実際に見るのは、点推定の yhat と予測区間の yhat_lower/yhat_upper です。区間の既定は80%(interval_width=0.80)で、95%区間が欲しければ Prophet(interval_width=0.95) と指定します。
ここで誤解が多いのが区間の中身です。Prophetの既定は mcmc_samples=0、すなわちフルベイズ推定ではなくMAP推定(事後確率最大の点推定)で動いており、この場合予測区間に含まれるのはトレンドの不確実性と観測ノイズだけで、季節性の不確実性は含まれません。季節性まで含めた区間が必要なら mcmc_samples=300 のように指定してMCMCを回しますが、計算時間は桁で増えます。「区間が思ったより狭い/広い」と感じたら、まずこの前提を確認してください。
plot_components() の分解図は、成分ごとの寄与を読むためのものです。トレンド成分が右肩上がりなら基調は成長、週次成分の山が週末にあれば週末需要、年次成分の谷は閑散期。加えて、検出された変化点が実際の出来事(サイトリニューアル、価格改定、需要ショック)と対応しているかを突き合わせると、予測を信じてよいかの判断がつきます。
精度を上げる主要パラメータ
既定値のままでも動きますが、外すと精度が伸びない引数は限られています。効く順に挙げます。
changepoint_prior_scale(既定0.05):トレンド変化への追従度です。予測が過去の凸凹に反応して暴れるなら下げ(0.01など)、直近の明確な転換に追従できていないなら上げます(0.1〜0.5)。実務でいちばん触る引数です。
m = Prophet(changepoint_prior_scale=0.1)
m.fit(df)
seasonality_mode(既定additive):売上のように「規模が大きくなるほど季節変動の振れ幅も大きくなる」データでは、加法ではなく乗法季節性が正解です。成長中のECの日次売上で予測がずれるとき、真っ先に疑う設定です。
m = Prophet(seasonality_mode="multiplicative")
m.add_seasonality(name="monthly", period=30.5, fourier_order=5)
m.fit(df)
add_regressor:キャンペーン実施フラグや気温など、外部要因を回帰項として加えます。将来分の値も埋める必要があるため、「予測時点で確定している変数」しか使えない点に注意してください(気温を使うなら気象予報値を入れることになります)。
m = Prophet()
m.add_regressor("promo")
m.fit(df) # df に promo 列を含める
future = m.make_future_dataframe(periods=90)
future["promo"] = 0 # 将来分の promo も埋める
forecast = m.predict(future)
交差検証によるチューニング効果の測定
パラメータを変えたら、感覚ではなく時系列交差検証で確かめます。cross_validation() は学習期間を initial、予測の刻みを period、予測期間を horizon で指定し、過去に遡って「その時点で予測していたら当たったか」を再現します。
from prophet.diagnostics import cross_validation, performance_metrics
cv = cross_validation(m, initial="730 days", period="90 days", horizon="30 days")
metrics = performance_metrics(cv) # mae, rmse, mape などを算出
print(metrics.head())
指標はMAE・RMSE・MAPEなどが並びます。売上のように水準が桁で違う系列を比較するならMAPE、外れ値の影響を抑えたいならMAEを見るのが基本です。initial は年次季節性を学習させるため2年(730日)以上を確保してください。
ARIMA・深層学習・基盤モデルとの使い分け
Prophetの立ち位置は「解釈しやすい強いベースライン」です。各手法の性格を比べると選びやすくなります。
| 観点 | Prophet | ARIMA / SARIMA | 深層学習(LSTM等) | 基盤モデル(TimesFM等) |
|---|---|---|---|---|
| 前処理・前提知識 | 少ない | 定常性・次数決定が必要 | 多い | 少ない(ゼロショット) |
| 複数季節性 | 自動 | 手動 | 学習で獲得 | 学習済み |
| 外部変数 | 容易 | 限定的 | 容易 | モデル依存 |
| 解釈性 | 高い | 中 | 低い | 低い |
| 必要データ量 | 数シーズン | 数シーズン | 多い | 少なくても可 |
定常性の仮定と次数設計が前提のARIMA/SARIMAに対し、Prophetは非定常データや複数季節性をそのまま扱えます。統計モデルの体系的な整理は時系列分析の手法と使い分けにまとめています。深層学習は系列本数とデータ量が揃ったときに効き、基盤モデルは学習なしで予測できる手軽さが武器ですが、前述の比較実験のようにProphetを下回るケースもあります。手順としては、Prophetで解釈可能なベースラインを作り、その誤差を上回れる手法だけを次に試す——これが遠回りに見えていちばん速い進め方です。Scikit-learn系の回帰モデルを使う場合も、比較対象としてProphetの数値を持っておくと判断が早くなります。
よくある質問(FAQ)
Prophetの読み方は?「fbprophet」とは違う?
読み方は「プロフェット」です。パッケージ名はv1.0で fbprophet から prophet へ改名されており、中身は同じ系譜のライブラリです。現在の導入コマンドは pip install prophet、インポートは from prophet import Prophet になります。
Prophetは開発終了したのですか?
終了していません。最新のv1.3.0は2026年1月27日にリリースされ、pandas 3.0とNumPy 2.4に対応しています。ただし公式は「Stanモデル本体には今後変更を加えない」と表明しているため、モデルの新機能は増えません。保守は続くが進化はしない、という状態です。
無料で使える?商用利用は可能?
リポジトリのLICENSEはMITライセンスです。著作権表示とライセンス文を残せば、商用利用・改変・再配布いずれも可能です。
ARIMAとどちらを使うべき?
複数季節性・休日効果・欠損への強さが要るならProphet、定常な系列で古典的な統計モデルを厳密に組みたいならARIMA/SARIMAです。迷ったらProphetでベースラインを作り、精度が足りなければARIMAや基盤モデルと比較するのが実務的です。
どれくらいのデータ量が必要?
年次季節性を捉えるには2年以上、週次季節性だけなら数か月でも動きます。履歴が1年未満だと年次成分の推定が不安定になるため、yearly_seasonality=False で切ったほうが素直な予測になることもあります。
複数の商品・店舗をまとめて予測できる?
Prophetは1系列につき1モデルが基本です。多数の系列は系列ごとに学習させる構成にし、本数が多いならSparkやDaskで並列化します(PyPI版には parallel extraとしてdask連携の依存が用意されています)。
予測区間が広すぎるときは?
まず学習データの期間を確認し、外れ値をNaNに置き換えて再学習します。それでも広い場合、既定のMAP推定では区間がトレンドの不確実性に強く引かれるため、変化点の感度(changepoint_prior_scale)を下げると狭まることがあります。狭められない場合は、データ自体のばらつきが大きいと判断し、点推定ではなく区間を前提にした意思決定へ切り替えてください。
関連記事
- 時系列分析の手法と使い分け|ARIMAから機械学習・Python実装まで
- Pandasとは?できること・使い方とPandas 3.0の変更点を解説
- Matplotlibとは?Pythonでグラフを描く使い方を入門から実践まで解説
- Scikit-learnとは何か?基本的な概要と特徴
- NumPyとは?読み方・インストール・基本的な使い方をPythonで解説
- Amazon Forecastとは?新規受付終了後の移行先と実装判断:Prophetを組み込みアルゴリズムとして持っていたAWSのマネージド予測サービスの現況です。