売上の変動を分析していると、曜日や季節、キャンペーンの有無といった社内データで整理できる部分と、それだけでは説明しきれない部分が残ることがあります。「暑い日は飲料が売れる」「連休は動きが違う」といった現場の経験則はあっても、それがどの程度の影響で、予測や発注にどう使えるのかを定量的に示すのは容易ではありません。
こうした場面で、気象や祝日、イベントなど社外のデータを組み合わせる発想が浮かぶのは自然です。需要が天候や行事に左右されやすい商品では、外部データが説明力を高める場合があります。一方で、外部データは「入れれば精度が上がる」ものではありません。商品の特性、データの粒度、期間、入手できる時点によっては、ほとんど改善しない場合もあります。
最初に決めたいのは「どの外部データを取得するか」ではなく、「社内データのどの変動を、どの判断のために説明したいか」です。結論を先に整理すると、外部データの価値は予測精度、変動理由の説明力、判断への活用の3点で評価し、仮説ベースで少数ずつ導入して、時系列を考慮した検証で確認する進め方が現実的です。効果は条件次第であり、改善しない場合もあります。
本記事では、飲料売上に気温・休日・イベント情報を統合する例を使い、外部データの種類、取捨選択の判断軸、導入手順、Pythonによる検証例、Excelでの代替手順、導入前のチェックリストを整理します。本記事で示す数値とコードのデータは、すべて説明用の疑似データです。特定の企業や地域の実績ではありません。
社内データだけでは説明できない売上変動とは何か
社内データとは、過去の売上、曜日、月、全体的な増減傾向(トレンド)、自社の販促や価格変更の記録などを指します。これらだけで作ったモデルや集計値と実績を比べたとき、説明しきれずに残る差を残差(Residual:実績値とモデルの予測値の差)と呼びます。
外部データを検討する手がかりは、残差の大きさそのものよりも、残差がどのような日に偏っているかにあります。残差を日付順に並べたとき、プラスとマイナスが無秩序に散らばっていれば、外部データでも説明しにくい可能性があります。夏季、連休、地域行事の開催日などに偏っていれば、天候や行事の影響を疑う仮説の材料になります。
ただし、残差が大きいことと、外部データで説明できることは別です。欠品による機会損失、価格改定、営業時間の変更、データの入力漏れや集計ルールの変更といった社内要因が先に見つかる場合もあります。外部データの取得に進む前に、これらを一度確認しておくと、手間の無駄を減らせます。
まず試せる確認作業として、直近1〜2年の日次売上から「曜日平均」だけを引いた差を作り、折れ線グラフで日付順に眺めてみてください。夏季や連休に差が偏って見えるかどうかが、最初の判断材料になります。あわせて、横軸に最高気温、縦軸に売上(曜日の影響を除いたもの)をとった散布図を描くと、ある気温を超えたあたりから傾きが変わるかどうかも確認できます。
外部データの価値は何で評価するのか
「外部データを入れて良くなったか」は、次の3つの観点に分けると判断しやすくなります。
- 予測精度:学習に使っていない期間で、誤差が下がるか
- 変動理由の説明力:猛暑の日、連休、イベント日など、条件別に売上の動きを説明できるか
- 判断への活用:発注、在庫、販促、人員配置の判断が実際に変わるか
この3つは別の観点です。精度がわずかに上がっても、発注や人員配置の判断が変わらなければ、実務上の価値は小さい場合があります。逆に、全体の誤差の改善幅が小さくても、特定の条件(たとえば連休初日)での需要の傾向を把握でき、運用が見直せるなら価値がある場合もあります。ただし、これは「精度が上がらなくても問題ない」という意味ではありません。3つを分けて確認し、どれが期待できるのかを事前に決めておくことが重要です。
また、気温と売上が同時に高いことは、気温が売上を直接決めていることを意味しません。夏季は来店客数が増える、販促が夏に集中するなど、別の要因が同時に動いている場合があります。本記事では、気温や休日を「売上と関連が見られる変数」として扱い、因果関係の断定は避けます。
外部データにはどのような種類があるか
売上分析で使われやすい外部データを、一般的な取得先の名称とあわせて整理します。取得先は代表例であり、実際に使う際は各提供元の最新の利用規約と出典表記のルールを確認してください。
| データ種別 | 取得先の一般名称 | 粒度 | 更新頻度 | 主な用途 | 注意点 |
|---|---|---|---|---|---|
| 気象データ | 気象庁の過去の気象データ | 日別・時間別、観測地点 | 日々更新 | 気温・降水量と売上の関連の確認 | 店舗・エリアに近い観測地点を選ぶ。予測に使う場合は実測値ではなく予報値になる |
| カレンダーデータ | 内閣府の国民の祝日情報 | 日 | 年単位 | 祝日・連休の影響の確認 | 給料日や自社の休業日などは自社で定義する必要がある |
| イベント・行事データ | 自治体や主催者の公開イベント情報 | 日・会場 | 不定期 | 地域行事による来客変動の確認 | 形式が統一されておらず収集に手間がかかる。規模の基準を決める必要がある |
| 人口・世帯データ | 政府統計の総合窓口(e-Stat) | 市区町村など | 年次〜数年ごと | 商圏の規模・構成の把握 | 更新頻度が低く、日次の変動の説明には向きにくい |
| 経済指標・物価データ | 政府統計の総合窓口(e-Stat)、各省庁の公表統計 | 月次・四半期 | 月次〜四半期 | 中長期の需要傾向の把握 | 公表までに時間差がある。日次の売上とは粒度が合わない |
粒度(データの細かさ。日別か月別か、地点単位か全国単位か)が日次の売上と合うかどうかは、種類ごとに大きく異なります。人口や経済指標は、日次の変動を説明するというより、エリアの特徴や長期的な傾向を把握する目的で使うほうが適しています。
どの外部データから入れるべきか
外部データは種類が多く、すべてを一度に入れるとかえって検証が難しくなります。優先順位は、期待される説明力(経験則や残差の偏りという根拠があるか)と、取得・維持のコスト(継続的に自動で取得できるか、手作業が必要か)の2軸で考えると整理しやすくなります。
外部データの取捨選択マトリクス(概念図)
観点1:期待される説明力観点2:取得・維持のコスト
概念図であり、各データの位置づけは商品・業種・商圏によって変わります。上記の例が自社に当てはまることを意味するものではありません。
「しない判断」も選択肢です。仮説の根拠が弱く、取得にも手間がかかるデータは、一度見送って社内データの整備を優先するほうが合理的な場合があります。見送りは、将来の再検討を妨げるものではありません。
飲料売上を例にした外部データ導入の進め方
ここでは、日次・エリア単位の飲料売上(疑似データ)に、最高気温、降水量、休日・連休、地域イベントの情報を統合する流れを、7つのStepで整理します。
外部データ導入の7ステップ
仮説から始め、判断への反映と見直しまでを一巡として扱います。
概念図です。実際の工程数や順序は、データの状況や目的によって変わります。
Step 1〜2:残差を確認し、仮説を言語化する
最初に、曜日とトレンドだけを使ったモデル(以下、モデルA)で残差を確認します。夏季、連休、イベント日に残差が偏っていれば、そこが仮説を立てる起点になります。
仮説は「気温を入れてみる」ではなく、「どの条件で、どの方向に変動し、どの判断に関わるか」まで書き下します。たとえば「最高気温が一定以上の日は需要が上振れしやすく、前日の発注量の見直しに関わる」「連休の初日は平日と異なる動きをするため、人員配置の判断に関わる」といった形です。判断との接点が書けない仮説は、検証しても活用につながりにくいため、優先度を下げる目安になります。
Step 3〜4:粒度を揃えて結合し、特徴量を作る
売上が「日次・エリア単位」であれば、外部データもその単位に揃えます。気象データはエリアに近い観測地点の日別値を選び、日付とエリアをキーに結合します。結合後は欠損の有無と、祝日などの日付のずれを必ず確認します。
もう一つ確認したいのが時点です。過去分析では当日の実測の最高気温を使えますが、翌日の発注判断に使うなら、前日までに入手できる予報値でなければなりません。予測時点で入手できない情報が学習に混入する問題をリーク(Leakage:情報漏えいではなく、予測に使えない情報が検証に入り込むこと)と呼びます(Kaufman et al., 2012)。
結合後のイメージを、疑似データで示します。
| date | area | weekday | sales_units | max_temp | precipitation_mm | is_holiday | event_flag |
|---|---|---|---|---|---|---|---|
| 2025-07-19 | エリアA | 土 | 1,610 | 32.5 | 0.0 | 1 | 1 |
| 2025-07-20 | エリアA | 日 | 1,540 | 33.1 | 0.0 | 1 | 0 |
| 2025-07-21 | エリアA | 月 | 1,480 | 31.7 | 0.0 | 1 | 0 |
| 2025-07-22 | エリアA | 火 | 1,120 | 29.8 | 5.5 | 0 | 0 |
| 2025-07-23 | エリアA | 水 | 1,180 | 31.2 | 0.0 | 0 | 0 |
上の表はすべて説明用の疑似データで、実際の企業・地域の実績ではありません。sales_unitsは販売数量、is_holidayとevent_flagは該当する日を1とするフラグです。
続いて特徴量(Feature:モデルに入力する変数)を作ります。ここでは一般的なものにとどめ、最高気温、30℃以上かどうかのフラグ、前日との気温差、休日・連休フラグ、イベントフラグ、曜日を使います。気象庁の定義では、日最高気温30℃以上の日が真夏日、35℃以上の日が猛暑日です。しきい値は商品や地域によって適切な値が異なるため、固定値として決め打ちせず、散布図などで確認してから決めてください。
Step 5〜6:時系列順に分割して比較し、条件別に誤差を見る
学習期間と評価期間は、日付の前半と後半で分けます。ランダムに分割すると、評価対象の日の前後の情報が学習に入り、実運用より良い結果が出やすくなるためです。時系列データでは、将来のデータで過去を予測しない分け方が基本になります(Hyndman and Athanasopoulos, 2021)。
比較は、モデルA(社内データのみ)とモデルB(外部データを追加)を、同じ評価期間・同じ指標で行います。指標には、平均絶対誤差(MAE:Mean Absolute Error、予測と実績の差の絶対値の平均)のように、単位が売上と同じで解釈しやすいものを使うと、現場にも説明しやすくなります。
全体の誤差だけで判断せず、30℃以上の日、休日、イベント日といった条件別の誤差も確認します。全体ではほとんど変わらなくても、特定の条件で改善している場合もあれば、その逆もあります。条件別に見ることで、「どの場面で外部データが役立つか」と「役立たない場面はどこか」を切り分けられます。
Step 7:判断に反映し、運用しながら見直す
検証結果は、発注、在庫、販促、人員配置のどの判断に渡すかを決めて初めて価値になります。いきなり全商品・全エリアに広げず、1商品・1エリアなど小さい範囲で運用し、外部データを使った場合と使わなかった場合の差を確認するのが堅実です。
気温と売上の関係は、商品の入れ替え、価格、競合環境、消費者の行動変化によって変わる場合があります。一度作った結果を固定せず、シーズンごとなど定期的に見直す前提で設計してください。
Pythonで効果を確認する例(疑似データ)
以下は、上記のStep 3〜6を最小限の構成で確認する汎用サンプルです。pandas、numpy、scikit-learnの線形回帰のみを使い、データは乱数で作った疑似データです。実際の分析では、エリアの追加、予報値の利用、より適切なモデルの検討が必要になります。
import numpy as np
import pandas as pd
from sklearn.linear_model import LinearRegression
from sklearn.metrics import mean_absolute_error
# ------------------------------------------------------------
# 1. 疑似データの生成(説明用。実在の企業・地域のデータではない)
# ------------------------------------------------------------
rng = np.random.default_rng(42)
dates = pd.date_range("2024-01-01", "2025-12-31", freq="D")
n = len(dates)
# 気温:年周期の変動にばらつきを加えた疑似値(7月下旬ごろに高くなる)
doy = dates.dayofyear.to_numpy()
max_temp = 18 + 13 * np.sin(2 * np.pi * (doy - 110) / 365) + rng.normal(0, 2.5, n)
# 休日:土日に加え、連休を想定した日付を一部指定
extra_holidays = pd.to_datetime([
"2024-01-01", "2024-05-03", "2024-05-04", "2024-05-05",
"2024-08-12", "2024-08-13", "2024-08-14",
"2025-01-01", "2025-05-03", "2025-05-04", "2025-05-05",
"2025-08-12", "2025-08-13", "2025-08-14",
])
weekday = dates.dayofweek.to_numpy() # 0=月曜 ... 6=日曜
is_holiday = ((weekday >= 5) | dates.isin(extra_holidays)).astype(int)
event_flag = (rng.random(n) < 0.04).astype(int)
# 売上 = ベース + トレンド + 曜日効果 + 気温効果(20℃超で増加)
# + 休日効果 + イベント効果 + ノイズ
weekday_effect = np.array([0, -20, -10, 0, 40, 0, 0])[weekday]
sales = (
1000
+ 0.3 * np.arange(n)
+ weekday_effect
+ 25 * np.clip(max_temp - 20, 0, None)
+ 150 * is_holiday
+ 200 * event_flag
+ rng.normal(0, 60, n)
)
# 社内データと外部データを別テーブルとして用意
internal = pd.DataFrame({"date": dates, "weekday": weekday, "sales": sales.round()})
external = pd.DataFrame({
"date": dates,
"max_temp": max_temp.round(1),
"is_holiday": is_holiday,
"event_flag": event_flag,
})
# ------------------------------------------------------------
# 2. 日付をキーに結合し、欠損を確認する
# ------------------------------------------------------------
df = internal.merge(external, on="date", how="left")
print(df.isna().sum()) # 結合漏れ(欠損)がないかを確認
# ------------------------------------------------------------
# 3. 特徴量の作成
# ------------------------------------------------------------
df["t"] = np.arange(len(df)) # トレンド(経過日数)
df["is_hot"] = (df["max_temp"] >= 30).astype(int) # 30℃以上(真夏日)
wd = pd.get_dummies(df["weekday"], prefix="wd", drop_first=True, dtype=int)
df = pd.concat([df, wd], axis=1)
base_cols = ["t"] + list(wd.columns) # モデルA:社内データのみ
ext_cols = base_cols + ["max_temp", "is_hot", "is_holiday", "event_flag"] # モデルB
# ------------------------------------------------------------
# 4. 日付で前半を学習、後半を評価に分割する
# ランダム分割にしないのは、将来の情報が学習に混入し、
# 実運用より良い結果に見えてしまうのを避けるため
# ------------------------------------------------------------
split_date = pd.Timestamp("2025-04-01")
train = df[df["date"] < split_date]
test = df[df["date"] >= split_date].copy()
# ------------------------------------------------------------
# 5. モデルAとモデルBを学習し、MAEで比較する
# ------------------------------------------------------------
model_a = LinearRegression().fit(train[base_cols], train["sales"])
model_b = LinearRegression().fit(train[ext_cols], train["sales"])
test["pred_a"] = model_a.predict(test[base_cols])
test["pred_b"] = model_b.predict(test[ext_cols])
print("モデルA(社内データのみ) MAE:",
round(mean_absolute_error(test["sales"], test["pred_a"]), 1))
print("モデルB(外部データ追加) MAE:",
round(mean_absolute_error(test["sales"], test["pred_b"]), 1))
# ------------------------------------------------------------
# 6. 評価期間の絶対誤差を条件別に集計する
# ------------------------------------------------------------
test["abs_err_a"] = (test["sales"] - test["pred_a"]).abs()
test["abs_err_b"] = (test["sales"] - test["pred_b"]).abs()
for col in ["is_hot", "is_holiday"]:
print(test.groupby(col)[["abs_err_a", "abs_err_b"]].mean().round(1))
# ------------------------------------------------------------
# 7. 注意点
# ------------------------------------------------------------
# ・疑似データのため、改善幅はあくまで例示であり、実データでの効果を示すものではない
# ・実運用では当日の実測値ではなく、予測時点で入手できる予報値を使う(リーク防止)
# ・気温の効果は折れ線状だが、線形モデルでは max_temp と is_hot の併用で近似している実行すると、モデルAとモデルBの全体のMAEと、30℃以上かどうか、休日かどうかで分けた誤差が表示されます。乱数の設定やライブラリのバージョンによって数値は変わる場合があるため、本記事では結果の数値は掲載しません。結果を読むときは、次の観点で確認してください。
| 評価区分 | 比較する指標 | 確認したいこと | 結果の読み方の例 |
|---|---|---|---|
| 評価期間の全体 | MAE | モデルBで誤差が下がっているか | 差が小さい場合、全体では効果が限定的な可能性がある |
| 30℃以上の日 | 条件別の平均絶対誤差 | モデルAで大きかった誤差が縮小しているか | 縮小していれば、気温を判断に使う価値の手がかりになる |
| 30℃未満の日 | 条件別の平均絶対誤差 | モデルBで悪化していないか | 悪化している場合、変数の追加が逆効果になっている可能性がある |
| 休日・平日 | 条件別の平均絶対誤差 | 休日フラグが休日の誤差に効いているか | 休日の誤差が変わらない場合、他の要因を確認する |
疑似データで改善が見られたとしても、それは「データをそのように作ったから」です。実データで同様の結果になることを示すものではありません。
Excelで代替する場合の手順
コードを使わなくても、仮説の第一段階の確認はExcelで行えます。モデルによる精度比較までは難しい場合でも、「気温帯によって売上の傾向が違うか」は十分に見られます。
- 売上シートに、気象データシートの最高気温をXLOOKUP関数で日付をキーに取り込みます(例:
=XLOOKUP(A2, 気象!A:A, 気象!B:B, "未取得"))。第4引数で「未取得」と表示させると、結合漏れを見つけやすくなります。 - 最高気温から「25℃未満」「25〜30℃未満」「30℃以上」などの気温帯の列を作ります。区分は散布図を見て調整してください。
- ピボットテーブルで、行に気温帯、列に曜日、値に売上の平均と件数を設定します。
- 同じ曜日の中で、気温帯によって平均売上がどう違うかを確認します。休日・イベントのフラグも、同様に行や列へ加えて確認します。
注意点は、件数が少ないセルの平均は不安定になることです。必ず件数も併記し、数日分しかない区分の差は参考程度にとどめてください。また、Excelの集計は「関連の有無」を見る手段であり、外部データを入れた予測が改善するかを確かめるには、前述の時系列順の分割による比較が別途必要です。
効果が出やすいケースと出にくいケース
| 観点 | 効果が出やすいケース | 効果が出にくいケース |
|---|---|---|
| 商品特性 | 天候や行事の影響を受けやすい商品 | 天候や行事の影響が小さい商品 |
| データの粒度 | 日次以上の細かい粒度で売上を把握できる | 月次など粗い粒度で、外部データと粒度が合わない |
| データ期間 | 複数の季節・年にわたる十分な期間がある | 期間が短く、季節や連休が1回ずつしか含まれない |
| 時点の整合 | 予測時点で入手できる予報値などで運用できる | 実測値でしか分析できず、運用に使えない |
ただし、これは「出にくいケースでは外部データが不要」という意味ではありません。たとえば期間が短い場合でも、データを蓄積しながら少しずつ検証を重ねる選択肢があります。また、検証した結果「効果が小さい」とわかること自体が、取得や維持にかけるコストを抑える判断材料になります。
外部データ活用でつまずきやすいポイント
- 予測時点の不整合:分析では当日の実測気温を使えても、運用では予報値になります。予報の誤差も含めて検証しないと、運用時に精度が落ちる場合があります。
- 粒度のずれ:観測地点が店舗や配送エリアから離れている、売上が月次で外部データが日次、といったずれは、関係を弱めて見せる場合があります。
- 期間の偏り:猛暑の年が1回だけ含まれる場合、その年の特殊事情を気温の効果と取り違える可能性があります。複数の季節・年で再現するかを確認してください。
- 変数の入れすぎ:多くの変数を試すほど、偶然の相関が見つかりやすくなります。仮説のある変数に絞って検証する姿勢が有効です。
- 相関と因果の混同:関連が見られても、販促や来店客数の季節変動など、別の要因が背景にある場合があります。
- 利用規約・出典表記:公開データでも、再配布や商用利用、出典の表記に条件がある場合があります。社内利用であっても事前に確認してください。
導入前チェックリスト
外部データの取得に着手する前に、次の項目を確認してください。すべてを完璧に満たしてから始める必要はなく、満たせていない項目を把握したうえで小さい範囲から進める、という使い方を想定しています。
| 確認項目 | 確認する内容 |
|---|---|
| 仮説の言語化 | どの条件で、どの方向に変動し、どの判断に関わるかを文章にできているか |
| 予測時点での入手可否 | 運用時に、前日までなど必要な時点で入手できるデータか(予報値で代替できるか) |
| 粒度の一致 | 売上の日付・エリアの単位と、外部データの単位が揃えられるか |
| 比較対象の有無 | 社内データのみのモデルや集計という、比較の基準があるか |
| 検証方法 | 日付順に学習・評価期間を分け、全体と条件別の誤差を見られるか |
| 判断への接続先 | 発注・在庫・販促・人員配置など、結果を渡す先が決まっているか |
| 利用規約の確認 | 利用条件、出典表記、再配布の可否を確認したか |
まとめ
外部データは、社内データだけでは説明できない売上変動に対する有力な選択肢です。ただし、その価値は仮説、粒度、時点、検証方法、そして意思決定への接続によって決まり、効果が出ない場合もあります。
- 社内データのみのモデルの残差が、どの日に偏っているかを確認する
- 仮説を「条件・方向・関わる判断」まで言語化し、少数の外部データから試す
- 時系列順に学習・評価期間を分け、全体と条件別の誤差を比較する
- 効果が小さければ見送る、条件付きで進めるといった判断も選択肢に入れる
次に確認するのは、自社の売上の残差がどの条件に偏っているか、そしてその偏りが解消されたときにどの判断が変わるか、の2点です。
外部データを含めた分析は、大がかりな仕組みを先に作るよりも、小さな仮説検証(PoC:Proof of Concept、概念実証)から始めるほうが、効果と負担のバランスを確認しやすくなります。RASHINRAでは、外部データを含めた分析が意思決定にどの程度役立つかの確認から支援しています。「説明できない変動がある」「外部データを試すべきか判断したい」という段階でも、お問い合わせいただけます。
何から始めるかが未定の場合はKAMUSHIRUBE(技術・DX相談)、社内の分析人材の育成には調査・研修講師、外部データを取り込むデータ基盤やセキュリティの整備にはKANAMEBAもご活用ください。
参考文献
- Hyndman and Athanasopoulos. 2021. Forecasting: Principles and Practice. OTexts. 3rd edition. https://otexts.com/fpp3/
- Kaufman et al. 2012. Leakage in data mining: Formulation, detection, and avoidance. ACM Transactions on Knowledge Discovery from Data. Vol. 6. Issue 4. pp. 15:1-15:21. https://doi.org/10.1145/2382577.2382579