Prophetの使い方｜Pythonの時系列予測を実測、ARIMAとも比較

Prophet は「データを3つの部品の足し算として表す」考え方で予測します。部品ごとに図で見られるので、なぜその予測になったのかを説明しやすいのが特徴です。

flowchart TD
    D["ds 日付 と y 値"] --> F["fit<br>Stan で推定"]
    F --> G["トレンド<br>g"]
    F --> S["季節性<br>s"]
    F --> H["祝日<br>h"]
    G --> Y["yhat = g + s + h<br>予測区間つき"]
    S --> Y
    H --> Y

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（2 CPU・メモリ 8GB）の上で、作業場所に作った venv（Python 3.13.18、システムの pandas 3.0.5・NumPy 2.5.3・matplotlib 3.11.2・SciPy 1.18.1 を共有）に、pip で prophet 1.5.0（cmdstanpy 1.3.0・同梱の CmdStan 2.37.0・holidays 0.107）と statsmodels 0.15.0 を入れて実行しました。データは自作の日次売上のような時系列（2023年1月1日〜2026年6月30日の1,277行。トレンドの変化・曜日・年の季節性・日本の祝日・外れ値を含む）と、比較用のランダムウォークです。図は matplotlib で PNG に保存して中身を目で確かめました。保守状況・版の履歴・既定値・推奨の手順は Prophet の公式ドキュメント（facebook.github.io/prophet）と GitHub の README・リリースノート、PyPI のメタデータで確かめています。Windows・macOS でのインストールは公式ドキュメントの記述の範囲です。図は mermaid 11.16.0 で描画を確かめました（確認日 2026年10月29日）。

Prophetとは（Metaの時系列予測ライブラリと仕組み）

この節では、Prophet が何をするライブラリで、どんな考え方で予測しているのかが分かります。

Prophet は、Meta（旧 Facebook）の Core Data Science チームが公開した、時系列データの予測ライブラリです。 2017年にオープンソースになり、Python と R の両方で使えます。ライセンスは MIT です。統計の専門家でなくても、ビジネスの担当者が「それらしい予測」を短いコードで出せることを目指して作られました。

時系列予測では昔から、AR・ARMA・ARIMA のような統計モデルが使われてきました。精度は出せますが、次数（p・d・q）を決める・定常性を確かめるなど、扱うには統計の知識が要ります。LSTM のような深層学習は表現力が高い一方、データ量と調整の手間が大きくなります。Prophet はその間にあり、「曜日と季節で波があり、祝日で跳ねる」という業務データによくある形を、最初から部品として持っているのが特徴です。

予測式：トレンド＋季節性＋祝日＋誤差

Prophet の論文「Forecasting at Scale」（Taylor・Letham）では、予測を次の足し算で表します。

y(t) = g(t) + s(t) + h(t) + ε(t)

g(t) : トレンド（長い期間の伸び。変化点で傾きが変わる折れ線、または上限のあるロジスティック曲線）
s(t) : 季節性（週・年などの周期。フーリエ級数＝sin と cos の重ね合わせで表す）
h(t) : 祝日・イベントの効果（指定した日だけ足し引きされる）
ε(t) : 説明できない誤差

係数の推定には、確率的プログラミング言語 Stan を使います。Python 版は CmdStan（Stan のコマンドライン版）を cmdstanpy から呼び出しており、手元の出力にも cmdstanpy - INFO - Chain [1] start processing の行が出ます。

Prophetのメンテナンス状況と版（2026年10月29日時点）

この節では、Prophet の開発が続いているのか、今どの版を使えばよいのかが分かります。

Prophet は v1.4.0 から保守モード（maintenance mode）です。 GitHub の README には、受け付けるのは不具合の修正・依存ライブラリの更新・R 版を Python 版にそろえる変更だけで、新機能の予定は無いと書かれています。開発の終了ではなく、モデルの形がこの版で固まった、と読むのが正確です。

手元で入った 1.5.0 の PyPI のメタデータは Requires-Python: >=3.10、依存は cmdstanpy・numpy・matplotlib・pandas・holidays（0.25 以上 1 未満）・tqdm でした。README の本文には「v1.1 からの最低は Python 3.7」という以前の記述も残っていますが、実際に入る条件はメタデータの 3.10 以上です。

新しい手法を使いたい場合は NeuralProphet・statsforecast・TimesFM などが候補になります。

Prophetのインストール（pip・venv・cmdstan）

この節では、Prophet を Python に入れる手順と、入れたときの大きさが分かります。

今の Prophet は C++ のコンパイラが無くても pip だけで入ります。 1.1 から、Stan のモデルをビルド済みの状態で wheel に同梱しているためです。手元では venv を作って次の順に入れました。仮想環境そのものの作り方は、関連記事「Python venvの使い方｜作成・有効化コマンド早見表と有効化できない時の直し方」で扱っています。

import すると、次の1行が出ました。対話的な図（plotly）を使わないなら、そのままで動きます。使うなら pip install plotly を足します。

Importing plotly failed. Interactive plots will not work.

容量の多くは pandas・NumPy・matplotlib などの依存です。既存のライブラリを使える環境なら、python -m venv --system-site-packages で作った venv に入れると、手元では prophet と statsmodels を足しても 106MB に収まりました。

Windows・Mac で入れるとき

GitHub の README のリリースノートでは、1.1 からビルド済みの配布物を PyPI に置き、1.1.5 で macOS arm64（Apple M1・M2）向けの wheel を追加したと書かれています。手元では Linux しか動かしていないため、Windows・Mac の手順は README の記述の範囲です。自分で CmdStan を用意したい場合だけ、環境変数 PROPHET_REPACKAGE_CMDSTAN=False を付けてソースから入れます。その場合、Windows では cmdstanpy.install_cxx_toolchain で C++ のコンパイラ（mingw-gcc など）を用意し、Linux ではインストールに4GB以上、使うときに2GB以上のメモリを勧めています。

Prophetの使い方：fitとpredictの最小コード

この節では、CSV を読み込んで90日先を予測し、図を保存するまでの最小のコードと、その実行結果が分かります。

使い方は「ds と y の表を作る → Prophet() を作って fit → 未来の日付を作って predict」の3段です。 scikit-learn と同じく fit と predict の形なので、機械学習のライブラリに慣れていれば迷いません。

import pandas as pd
from prophet import Prophet

df = pd.read_csv("sales.csv")          # 列は ds（日付）と y（値）
m = Prophet()                          # 既定：線形トレンド＋週と年の季節性
m.fit(df)

future = m.make_future_dataframe(periods=90)   # 学習した期間＋90日の日付
fc = m.predict(future)
print(fc[["ds", "yhat", "yhat_lower", "yhat_upper"]].tail())

m.plot(fc).savefig("plot.png")                 # 実績の点と予測の線
m.plot_components(fc).savefig("components.png")  # トレンド・曜日・年

手元の1,277行（2023年1月1日〜2026年6月30日）で動かした結果です。

import 2.48 s prophet 1.5.0
14:42:29 - cmdstanpy - INFO - Chain [1] start processing
14:42:29 - cmdstanpy - INFO - Chain [1] done processing
fit 0.24 s
future (1367, 1) 2023-01-01 2026-09-28
predict 0.2 s
        ds   yhat  yhat_lower  yhat_upper  trend  weekly  yearly
2026-09-24 1600.7      1462.0      1734.2 1648.6   -54.3     6.5
2026-09-25 1601.5      1461.8      1727.3 1648.7   -50.2     3.0
2026-09-26 1784.2      1646.6      1926.6 1648.9   136.1    -0.7
2026-09-27 1814.2      1679.4      1945.2 1649.0   169.7    -4.6
2026-09-28 1554.8      1406.7      1688.2 1649.1   -85.7    -8.6

3年半の日次データの学習は0.24秒、予測は0.2秒でした。 土曜（09-26）・日曜（09-27）の yhat が高く、月曜（09-28）が低いのは、weekly の列の値（＋136.1・＋169.7・−85.7）がそのまま足されているためです。yhat は trend＋weekly＋yearly の合計（祝日を入れていない場合）になっています。

入力データの形

• ds：日付か日時。pandas が読める形（YYYY-MM-DD や YYYY-MM-DD HH:MM:SS）。手元の pandas 3.0 では CSV から読んだ ds は文字列の型（str）でしたが、Prophet が中で日付に変換しました。
• y：数値。欠けている日（NaN）があっても学習でき、その日の予測値も出ます。
• 日次でなくても使えます。月次なら make_future_dataframe(periods=12, freq="MS") のように freq を合わせます。

pandas で列名をそろえる・日付に変換する操作は、関連記事「pandasの使い方 逆引き81選｜pandas 3.0の実行結果つき」で扱っています。

予測結果の見方：yhat・予測区間・plot_components

この節では、predict が返す19列のうち、どれを見ればよいかと、図の読み方が分かります。

まず見るのは yhat（予測値）と yhat_lower・yhat_upper（予測区間）の3列です。 手元の predict の戻り値は19列ありました。

['ds', 'trend', 'yhat_lower', 'yhat_upper', 'trend_lower', 'trend_upper',
 'additive_terms', 'additive_terms_lower', 'additive_terms_upper',
 'weekly', 'weekly_lower', 'weekly_upper', 'yearly', 'yearly_lower', 'yearly_upper',
 'multiplicative_terms', 'multiplicative_terms_lower', 'multiplicative_terms_upper', 'yhat']

予測区間の幅は「トレンドがこの先も同じくらいの頻度・大きさで変わる」と仮定して作られます。 区間を出すために既定で1,000回のシミュレーションをしており、要らなければ Prophet(uncertainty_samples=0) で省けます。手元では fit と predict の合計が0.28秒になり、戻り値から yhat_lower の列が消えました。区間の幅は interval_width=0.95 のように変えられます。

plot_components で部品を見る

plot_components の図は、上からトレンド・曜日（weekly）・年（yearly）の3段でした。自作データで仕込んだ形がどう見えたかを並べます。

年の図の「5月初めの山」は、仕込んでいない形です。祝日を入れていないため、ゴールデンウィークの上振れを年の季節性が吸い込んでいました。 次の節で祝日を入れると、この山は小さくなります。図の作り方や日本語の文字化けの直し方は、関連記事「matplotlibの使い方と日本語文字化け対策｜OS別・Colab・3.12対応」で扱っています。

Prophetに日本の祝日を入れる（add_country_holidays・独自イベント）

この節では、日本の祝日と自社のイベントを Prophet に教える方法と、それで誤差がどれだけ減ったかが分かります。

日本の祝日は m.add_country_holidays(country_name="JP") の1行で入ります。fit より前に呼びます。 祝日の一覧は Python の holidays パッケージから取られます（公式ドキュメントの説明）。

m = Prophet()
m.add_country_holidays(country_name="JP")
m.fit(train)
print(len(m.train_holiday_names), list(m.train_holiday_names)[:6])

18 ["New Year's Day", 'Coming of Age Day', 'Foundation Day', "Emperor's Birthday", 'Vernal Equinox Day', 'Showa Day']

学習期間に出てきた日本の祝日は18種類で、名前は英語で入っていました（振替休日も別の名前として数えられます）。

祝日を入れる前と後の誤差

2026年4月30日までの1,216日で学習し、5月1日〜6月30日の61日（ゴールデンウィークを含む）を予測して、実際の値との差を比べました。MAE は誤差の絶対値の平均、MAPE は誤差の割合の平均、coverage は実際の値が予測区間（80%）に入った割合です。

祝日を入れただけで、ゴールデンウィーク4日間の誤差は206.5から29.3に下がりました。 予測の中身を見ると、5月3日〜6日に holidays の列が＋217〜＋277 足され、実際の値（2,087・1,821・1,916・1,915）にほぼ重なっています。年の季節性に吸い込まれていた5月の山も、5月3日の yearly の値が127.3から73.0に減り、山の位置が仕込んだ6月に戻りました。

自社のセール・キャンペーンを入れる

国の祝日以外のイベントは、holiday・ds の2列（必要なら lower_window・upper_window・prior_scale）の表を Prophet(holidays=表) に渡します。未来の予定日も同じ表に入れておくと、その日の予測が上がります。 公式ドキュメントも「過去と未来の両方の発生日を含める」としています。

camp = pd.DataFrame({
    "holiday": "campaign",
    "ds": pd.to_datetime(["2024-03-15", "2025-09-10", "2026-06-12"]),  # 最後は未来の予定
    "lower_window": 0,
    "upper_window": [1, 0, 0],     # 2024-03-15 は翌日まで効く
})
m = Prophet(holidays=camp)
m.add_country_holidays(country_name="JP")
m.fit(train)

        ds  campaign   yhat
2026-06-11       0.0 1687.5
2026-06-12    1360.3 3045.0

過去2回のキャンペーンから効果を＋1,360と学び、予定日の6月12日の予測に足しています。回数が少ないイベントは効果の推定がぶれやすいので、区間の幅も合わせて見ます。

Prophetの外れ値の扱い：消すか、イベントとして入れるか

この節では、外れ値（急な跳ね上がり・落ち込み）を Prophet に渡すとどうなるかと、正しい消し方が分かります。

公式ドキュメントの推奨は「外れ値は取り除く」で、その日の y を NaN（欠損）にします。 行ごと消すのではなく、日付は残して値だけ空にします。Prophet は欠損があっても学習でき、その日の予測値も出します。

import numpy as np
outliers = pd.to_datetime(["2024-03-15", "2024-03-16", "2024-11-05", "2024-11-06", "2025-09-10"])
train.loc[train["ds"].isin(outliers), "y"] = np.nan

手元のデータには、キャンペーンの急増（2,600〜2,900）とシステム障害の急減（40・55）を5日だけ入れてあります。そのまま学習させたときの変化点の図では、2024年3月のキャンペーンの直後に大きな変化点が置かれていました（delta −0.0439）。外れ値を NaN にすると、上位の変化点は2025年2月・3月・5月（仕込んだ2025年4月の鈍化の前後）に移りました。

表の C と D を見ると、外れ値を消すと coverage（区間に入った割合）が93.4%から85.2%、祝日も入れると73.8%に下がりました。 外れ値が残っていると「誤差が大きいデータ」と見なされて区間が広がり、狙いの80%より多く入ってしまいます。消したあとの値は80%に近く、区間が正しい幅に戻ったと読めます。公式ドキュメントも、外れ値は不確実性の区間を広げ、季節性の推定をゆがめる、と説明しています。

Prophetの変化点（トレンドの曲がり角）とchangepoint_prior_scale

この節では、Prophet がトレンドの曲がり角をどう見つけ、その柔らかさをどう決めるかが分かります。

Prophet は既定で、学習期間の最初の80%に25個の変化点の候補を等間隔に置き、そのうち本当に傾きを変える必要のあるものだけを使います。 どれだけ自由に曲げるかは changepoint_prior_scale（既定 0.05）で決まり、大きいほど曲がりやすく、小さいほど直線に近くなります。

n_changepoints 25 2023-02-11 2025-10-17
cp 2025-02-17 -0.0916
cp 2025-03-27 -0.0684
cp 2025-05-05 -0.0525

候補は2023年2月11日〜2025年10月17日に置かれ、傾きの変化（delta）が大きかったのは、仕込んだ2025年4月1日の鈍化の前後3か所でした。図に変化点を重ねるには from prophet.plot import add_changepoints_to_plot を使います。

changepoint_prior_scale を変えたときの誤差

0.001 まで小さくすると、トレンドの鈍化を追えず誤差が59.4に増えました。 0.01〜0.5 はほぼ同じで、このデータでは既定値のままでよい結果です。公式ドキュメントも、調整するならまずこの値で、0.001〜0.5 を対数の間隔で試すことを勧めています。大きくするほど fit の時間も延びました。

そのほかの設定の試し打ち

• seasonality_mode="multiplicative"（季節の振れ幅が全体の大きさに比例する形）：MAE 42.1。このデータは足し算で作ってあるので、既定の additive のほうがよい結果でした。売上が伸びるほど週末との差も広がるデータなら、こちらを試します。
• holidays_prior_scale=1（祝日の効果を控えめにする）：MAE 37.7 で変わらず。既定は10で、公式は「ほとんど正則化しない値」と説明しています。

調整の順番をまとめると次のようになります。

1. 1データを整える列名 ds・y、外れ値を NaN、タイムゾーンを外す
2. 2祝日・イベントを入れるadd_country_holidays と自社イベントの表
3. 3交差検証で今の誤差を測る比べる基準を先に作る
4. 4changepoint_prior_scale を振る0.001・0.01・0.1・0.5
5. 5seasonality_prior_scale と seasonality_mode0.01〜10、足し算か掛け算か
6. 6説明変数を足す将来の値が分かるものだけ

Prophetの交差検証：cross_validationとperformance_metricsで誤差を測る

この節では、Prophet に付いている交差検証の機能で、「何日先の予測がどれくらい外れるか」を測る方法が分かります。

時系列の交差検証は、過去のある日（cutoff）までで学習し、その先を予測して答え合わせする、を時期をずらして繰り返します。 Prophet では cross_validation がこれを自動でやります。

from prophet.diagnostics import cross_validation, performance_metrics

def main():
    m = Prophet()
    m.add_country_holidays(country_name="JP")
    m.fit(df)
    cv = cross_validation(m, initial="730 days", period="90 days",
                          horizon="60 days", parallel="processes")
    pm = performance_metrics(cv, rolling_window=0.1)
    print(pm)

if __name__ == "__main__":   # parallel="processes" ではこの形が要る
    main()

• initial：最初の学習期間（既定は horizon の3倍）
• period：cutoff をずらす間隔（既定は horizon の半分）
• horizon：何日先まで予測するか

手元では cutoff が2025年2月5日・5月6日・8月4日・11月2日・2026年1月31日・5月1日の6回になり、359行の予測が返りました。horizon ごとの誤差は次のとおりです（外れ値は NaN にしたデータ）。

6回の時期をならしても、祝日ありのほうが MAE が48.1から35.3に下がりました。 既定のモデルで「6日先」の誤差が大きいのは、cutoff の直後にゴールデンウィークや祝日が来る回（2026年5月1日など）があり、祝日を知らないモデルが大きく外したためです。1回だけの答え合わせではこの差が偶然かどうか分からないので、交差検証で確かめます。

performance_metrics が返した列は horizon, mse, rmse, mae, mape, mdape, smape, coverage でした。rolling_window は「何割の予測をまとめて1行にするか」で、既定の0.1なら10%ずつ、1にすると全体で1行になります。図にするには plot_cross_validation_metric(cv, metric="mape") を使います。

parallel の速さと注意

2 CPU の環境で cutoff 6回程度だと、1回目はプロセスを立ち上げる時間が上回り、かえって遅くなりました。 cutoff が多い・データが長いときに効く設定です。また Linux では forkserver、Windows・macOS では spawn でプロセスを作るため（prophet/diagnostics.py の実装）、スクリプトの直下に処理を書いていると次のエラーで止まりました。上のコードのように if __name__ == "__main__": の中から呼びます。

RuntimeError:
        An attempt has been made to start a new process before the
        current process has finished its bootstrapping phase.

        This probably means that you are not using fork to start your
        child processes and you have forgotten to use the proper idiom
        in the main module:

            if __name__ == '__main__':
                freeze_support()

ProphetとARIMA・移動平均の精度と時間の比較

この節では、同じデータで Prophet・ARIMA・移動平均・ナイーブ予測を比べたとき、どれが当たったかと、かかった時間が分かります。

「Prophet が常に強い」わけではありません。 データの形が変わると順位が入れ替わります。3種類のデータで、最後の61日を予測して比べました。ARIMA は statsmodels 0.15.0 の ARIMA と SARIMAX を使い、次数は固定（自動選択はしていません）です。

1. 売上のようなデータ（季節性・祝日・変化点あり）

曜日の波を持たない ARIMA(1,1,1) と移動平均は、7日前の値をそのまま使う季節ナイーブにも負けました。週の季節性を入れた SARIMA は大きく良くなりましたが、祝日を知らないためゴールデンウィークで外し、Prophet が最も小さい誤差でした。SARIMA の学習では次の警告も出ています。

ConvergenceWarning: Maximum Likelihood optimization failed to converge. Check mle_retvals

2. ランダムウォーク（株価のような、季節性の無いデータ）

規則の無いデータでは、Prophet の誤差はナイーブの約4倍でした。 Prophet は過去の傾きの流れと季節の形を未来へ伸ばすため、偶然の上下まで「傾向」として先へ延ばしてしまいます。明日の値の最良の予測が「今日の値」であるデータには、ARIMA やナイーブのほうが合います。

3. 短いデータ（学習が60日だけ）

学習が60日だけだと、Prophet の誤差は3年分で学習したとき（37.7）の約2倍になり、季節ナイーブとの差は小さくなりました。既定では履歴が2年（730日）未満だと年の季節性が自動で外れ、祝日も数回しか出てこないためです。

深層学習の LSTM で時系列を扱う方法は、関連記事「LSTMとは｜仕組み・3つのゲート・RNNとの違いをPythonで実演」で扱っています。Prophet のトレンドの考え方の土台になっている「直線を当てはめる」計算は、関連記事「最小二乗法とは｜公式・手計算の例とPythonでの求め方を実例で解説」で扱っています。

Prophetの説明変数・上限（logistic）・季節性の追加

この節では、気温のような説明変数を足す方法、上限のある指標の予測、独自の季節性の足し方が分かります。

説明変数（add_regressor）

売上に効く外の数字（気温・広告費など）は add_regressor で足せます。ただし、予測したい未来の日の値も渡す必要があります。 公式ドキュメントは「説明変数は過去と未来の両方で分かっていなければならない」としています。

m = Prophet()
m.add_regressor("temp")           # fit の前に
m.fit(train)                      # train に temp 列が要る
fc = m.predict(test[["ds", "temp"]])   # 未来の temp も要る

from prophet.utilities import regressor_coefficients
print(regressor_coefficients(m))

regressor regressor_mode  center  coef_lower  coef  coef_upper
     temp       additive  19.269       5.749 5.749       5.749

気温が1度上がると8増える、と仕込んだデータで、推定された係数は5.749でした。気温は年の季節性と同じ形で動くため、効果の一部を yearly が受け持ったためです。 説明変数と季節性が似た動きをするときは、係数をそのまま「1度で何個売れる」と読まないようにします。

未来の値が分からない説明変数には、1.4.0 で入った add_regressor("temp", regressor_predictor=True) が使えます。説明変数そのものを別の Prophet で予測して埋める機能で、手元では未来の気温を渡さずに predict でき、MAE は54.5（本当の気温を渡したときは52.3）でした。

上限のある指標（growth="logistic"）

会員数・普及率のように上限がある指標は、既定の直線のトレンドだと上限を突き抜けます。cap 列で上限を渡すと、ロジスティック曲線で頭打ちになります。

linear 365日後の予測 7267.0
logistic 365日後の予測 5000.0

上限5,000に近づいていく自作データで、直線のトレンドは365日後に7,267と上限を超え、logistic は5,000に収まりました。logistic では、学習の表にも未来の表にも cap 列が要ります。

独自の季節性（add_seasonality）

週・年以外の周期は m.add_seasonality(name="monthly", period=30.5, fourier_order=5) のように足します。既定のフーリエ次数は週が3、年が10です（公式ドキュメント）。手元の m.seasonalities も {'yearly': (365.25, 10), 'weekly': (7, 3)} でした。ソースコードの set_auto_seasonalities では、履歴が2年以上あれば年、2週間以上で間隔が7日未満なら週、間隔が1日未満（時間ごとのデータなど）なら1日の周期（daily）が自動で入ります。履歴が2年未満なのに年の季節性を有効にすると、警告が出る作りです。

モデルの保存

学習したモデルは prophet.serialize の model_to_json・model_from_json で JSON に保存できます。手元の1,277行のモデルは200,737バイトでした。公式ドキュメントは「pickle で保存しない」とし、Stan のバックエンドがうまく pickle できないことを理由に、この JSON の方法を勧めています。

Prophetのよくあるエラー（ds/y・タイムゾーン・cmdstan）

この節では、Prophet でよく出るエラーの原文と、それぞれの直し方が分かります。

エラーの多くは「入力の表の形」と「呼ぶ順番」です。 すべて手元で起こした原文です。

cmdstan（Stan の実行ファイル）が動かないとき

Prophet は fit のたびに、同梱の Stan のモデル（prophet_model.bin）を別のプロセスとして実行します。このファイルを実行できないと、まず Newton 法に切り替えて再挑戦し、それでも駄目なら RuntimeError で止まります。 手元で実行権限を外した複製を読み込ませると、次のように出ました。

14:45:00 - cmdstanpy - INFO - Chain [1] start processing
Optimization terminated abnormally. Falling back to Newton.
14:45:00 - cmdstanpy - INFO - Chain [1] start processing
RuntimeError Failed with error [Errno 13] Permission denied: '.../prophet/stan_model/prophet_model.bin'

Permission denied なら、site-packages を実行できない場所（noexec でマウントされた領域など）に置いていないか、ウイルス対策ソフトに止められていないかを確かめます。Optimization terminated abnormally だけが出て結果が返る場合は、データの桁が極端・y がほぼ一定などで最適化が収束しにくかったという意味で、外れ値の除去や scaling="minmax" を試します。

Prophetが向くデータ・向かないデータ（判断表）

この節では、手元のデータに Prophet を使うべきか、別の手法にすべきかを判断する基準が分かります。

Prophet を業務で使う前に、次の点を確かめておくと失敗が減ります。

• 1季節ナイーブの誤差を先に出した7日前・前年同日の値をそのまま使った誤差が、比べる基準になる
• 2外れ値とイベントを分けた二度と起きない値は NaN、また起きるものは holidays の表へ
• 3交差検証で複数の時期を見た1回の答え合わせでは、祝日の有無などの偶然で結果が変わる
• 4予測区間の coverage を見た80%の区間に実際の値がおよそ80%入っているか
• 5plot_components で形を確かめた仕込んでいない山や谷があれば、祝日や外れ値の入れ忘れを疑う

データベースの中で前週比・移動平均を出して基準を作る方法は、関連記事「SQLのLAG・LEADと累計の書き方｜前月比・移動平均のコピペ集」で扱っています。

よくある質問

Q. Prophet とは何ですか？ A. Meta（旧 Facebook）が公開した時系列予測のライブラリです。データをトレンド・季節性・祝日の効果の足し算として表し、日付 ds と値 y の2列から未来を予測します。Python と R で使え、ライセンスは MIT です。

Q. fbprophet と prophet の違いは？ A. 同じライブラリで、1.0 から名前が prophet に変わりました。今は pip install prophet と from prophet import Prophet を使います。fbprophet を import すると、手元では ModuleNotFoundError になりました。

Q. Prophet の開発は終わったのですか？ A. 終わってはいませんが、v1.4.0 から保守モードです。不具合の修正と依存の更新だけを受け付け、新機能の予定は無いと README にあります。2026年10月29日時点の最新は 1.5.0（2026年10月5日公開）です。

Q. Prophet は無料で、仕事に使えますか？ A. MIT ライセンスのオープンソースなので、無料で業務にも使えます。著作権表示とライセンス文を残す条件があります。

Q. Prophet と ARIMA はどちらが精度が高いですか？ A. データによります。手元では、季節性と祝日のある売上データで Prophet が MAE 37.7、SARIMA が 56.9、ランダムウォークでは Prophet が 73.4、ARIMA が 18.3 でした。必ず同じデータで比べて選びます。

Q. 日本の祝日はどう入れますか？ A. m.add_country_holidays(country_name="JP") を fit の前に呼びます。自社のセールなどは holiday・ds の列を持つ表を Prophet(holidays=表) に渡します。

Q. データはどれくらいあればよいですか？ A. 年の季節性を学ばせるなら、少なくとも1年分、できれば2年分以上あると安定します。手元では、学習60日だけのときの誤差が3年分のときの約2倍になりました。

Q. 予測区間（yhat_lower・yhat_upper）は何％の区間ですか？ A. 既定は80%で、interval_width で変えられます。トレンドの変化の不確かさをシミュレーションして作るため、外れ値が残っていると広がります。

Q. Windows で入りますか？ A. README では、1.1 からビルド済みの配布物が PyPI にあり、pip で入るとされています（手元では Linux で確かめました）。自分の CmdStan を使うためにソースから入れる場合だけ、C++ のコンパイラが要ります（cmdstanpy.install_cxx_toolchain）。

まとめ

• Prophet は ds と y の2列から、トレンド＋季節性＋祝日の足し算で予測するライブラリ。1.5.0 は pip だけで入り、3年半の日次データの学習は0.24秒でした。
• 日本の祝日は add_country_holidays("JP") の1行。ゴールデンウィークの誤差が206.5から29.3に、全体の MAE が52.1から41.4に下がりました。
• 外れ値は y を NaN に、また起きるイベントは holidays の表に。外れ値を残すと変化点が引っ張られ、予測区間も広がりました。
• 精度は cross_validation で複数の時期を見て判断する。parallel="processes" には if __name__ == "__main__": が要ります。
• Prophet が常に勝つわけではない。季節性のある売上では最良でしたが、ランダムウォークではナイーブの約4倍の誤差でした。v1.4.0 から保守モードである点も踏まえて選びます。

参考・出典

確認日はいずれも 2026年10月29日です。

• Prophet 公式ドキュメント「Quick Start」：https://facebook.github.io/prophet/docs/quick_start.html
• Prophet 公式ドキュメント「Installation」：https://facebook.github.io/prophet/docs/installation.html
• Prophet 公式ドキュメント「Additional Topics」（モデルの保存）：https://facebook.github.io/prophet/docs/additional_topics.html
• Prophet 公式ドキュメント「Trend Changepoints」：https://facebook.github.io/prophet/docs/trend_changepoints.html
• Prophet 公式ドキュメント「Seasonality, Holiday Effects, And Regressors」：https://facebook.github.io/prophet/docs/seasonality,_holiday_effects,_and_regressors.html
• Prophet 公式ドキュメント「Outliers」：https://facebook.github.io/prophet/docs/outliers.html
• Prophet 公式ドキュメント「Diagnostics」：https://facebook.github.io/prophet/docs/diagnostics.html
• GitHub「facebook/prophet」README（保守モードの告知・リリースノート）：https://github.com/facebook/prophet
• PyPI「prophet」：https://pypi.org/project/prophet/
• Taylor ほか「Forecasting at scale」（PeerJ Preprints 2017）：https://peerj.com/preprints/3190/
• statsmodels「statsmodels.tsa.statespace.sarimax.SARIMAX」：https://www.statsmodels.org/stable/generated/statsmodels.tsa.statespace.sarimax.SARIMAX.html
• Python ドキュメント「multiprocessing」（メインモジュールの安全なインポート）：https://docs.python.org/3/library/multiprocessing.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。