天候データのクレンジング手順とは？欠測・異常値への実務対応を解説

天候データを分析に組み込む場面では、「気温と売上を突き合わせても想定した相関が出ない」「前年と今年の降水量を比べると不自然な差が生じる」といったつまずきが頻繁に起こります。原因の多くは分析モデルではなく、入力となる観測データの整形不足にあります。分析の前に、観測データそのものを検証と比較に耐える状態へ整えていきます。

天候データは公的機関が公開しているため、そのまま使える整備済みのデータだと誤解されがちです。実際には欠測とゼロ値の混在、観測地点の移転、日界のずれといった固有の制約を抱えています。これらを処理しないまま分析へ渡すと、精度が落ちるだけでなく結論そのものが反転しかねない点が問題です。

本記事では、天候データのクレンジングを8つの手順に分解し、実務で判断に迷いやすい論点を具体的に解説します。必要な観測要素と時間粒度の定義から、欠測と異常値の扱いを社内ルールへ落とし込む方法まで順に取り上げます。手を動かす前の設計図として活用してください。

天候データのクレンジングとは

天候データのクレンジングは、単なる欠損値の穴埋め作業ではありません。観測の仕組みに由来する制約を理解したうえで、分析目的に合う形へ整える一連の設計作業です。ここでは対象となる工程の範囲、一般的な手法との違い、実務で扱う観測要素の3点を押さえます。

天候データのクレンジングが指す範囲：観測値の補正から分析用データへの整形まで

天候データのクレンジングは、大きく3つの工程に分かれます。観測値そのものの妥当性を判定する工程、複数ソースを突き合わせて表記を揃える工程、そして分析ツールが読み込める形へ整形する工程です。気象庁の過去データ検索からCSVを取得すると、1つのセルに数値と品質を示す記号が混在した状態で出力されます。この記号を残したまま数値型へ変換すると読み込みエラーが起こるため、最初に分離する処理を挟みます。CSVはShift_JISで出力されるため、読み込み時に文字コードを指定する手当ても同時に必要です。

範囲の線引きで迷いやすいのが、平年値との差分計算や体感温度の算出をどこに含めるかという点です。クレンジングは観測された事実を正しく再現するところまでで区切り、指標の計算は分析工程へ渡す設計が扱いやすくなります。この線引きを曖昧にすると、補正済みの値と派生指標が同じ列に混ざり、後から検証できない状態に陥ります。工程の境界は、着手前に1枚の図として書き出しておきましょう。図に書き出す要素は、入力ファイル・処理内容・出力ファイルの3つで十分に機能します。

一般的なデータクレンジングとの違い：時系列・観測地点・観測手法に起因する制約

顧客マスタや購買履歴のクレンジングでは、重複レコードの統合や表記ゆれの吸収が中心になります。天候データではこれに加えて、時間軸の連続性と観測地点の同一性という2つの制約が加わります。ある地点の気温が3時間だけ欠けている場合、前後の値から補完するのか、その日全体を欠測扱いにするのかで集計結果が変わるのです。判断基準を決めずに作業を始めると、担当者ごとに異なる結果が生まれます。判断基準は文章ではなく、欠測が何時間までなら補完するという数値の形で決めておきます。

もう1つの違いは、値の正しさを外部から検証しにくい点です。売上データなら伝票と突き合わせれば真値に辿り着けますが、観測値には照合先がありません。そのため誤りを取り除くという発想よりも、どういう条件で採用し、どういう条件で除外したかを記録する運用が現実的です。採用条件と除外条件を1枚のルール表にまとめておけば、第三者が結果を検証する場面にも耐えられます。一般的な手法との対比を確認したい場合は、下記の記事もあわせて参照してください。

データクレンジングとは？意味と代表手法を解説！

対象となる主な観測要素：気温・降水量・日照時間・風向風速・積雪深

実務で扱う観測要素は、アメダス（AMeDAS）が観測する気温・降水量・風向風速・日照時間・積雪深が中心です。要素ごとに欠測の意味とゼロの意味が異なるため、同じ補完ロジックを一律に適用してはいけません。降水量のゼロは降らなかったという事実ですが、日照時間のゼロは夜間や悪天候など複数の状況を含みます。積雪深に至っては、無雪期に観測自体を行わない地点も存在するのです。要素ごとの前提を揃えないまま処理を共通化すると、どこかで必ず矛盾が表面化します。

要素ごとの性質を一覧に整理すると、処理方針を判断しやすくなります。実際の設計では、この一覧を社内の観測要素定義書として残し、新しい要素を追加するたびに行を足す運用が有効です。単位や欠測時の扱いを個人の記憶に頼ると、担当者が交代するたびに解釈が揺れ、過去の集計と数値が合わない事態を招きます。作成にかかる工数は5要素程度なら2〜3時間で、後工程の手戻りを考えれば十分に回収できる投資です。定義書は表計算ソフト1枚で十分で、凝った管理ツールを用意する必要はありません。

天候データの品質が低下する主な要因

品質低下の原因は、観測側の事情と利用側の処理の両方に分散しています。原因を特定せずに補完だけを進めると、見た目は整っていても実態とかけ離れたデータが出来上がるのです。ここでは実務で遭遇頻度の高い5つの要因を、判別方法とあわせて整理します。

欠測とゼロ値の混在：降水量・日照時間で判断を誤りやすい箇所

降水量の列に並ぶ0という数値には、2つの意味が混ざっています。1つは降水が観測されなかったという実測結果、もう1つは観測装置が停止していたためデータが存在しないという欠測です。気象庁のCSVでは後者が空欄や記号で表現されますが、システム間で受け渡す過程で0に置き換わる事故が起こります。受領したファイルの0の件数が前年同月と比べて不自然に多い場合は、疑ってかかりましょう。確認は月次の受領作業に組み込み、集計結果を1枚の表として残す運用にします。

判別の実務手順はシンプルです。月別に0の出現率を集計し、降水日数の平年値と突き合わせる流れになります。降水量が0の日が全体の9割を超える月があれば、欠測がゼロに変換された可能性が高いと判断できます。日照時間についても同様で、冬季の日本海側なら0の連続は自然ですが、太平洋側で1週間続くのは不自然です。実務では、平年並みの降水日数の半分を下回る月を要確認として抽出する運用が現実的です。地域の気候特性を前提に置いてから閾値を決めてください。

観測地点の移転・統合・廃止：長期時系列の連続性が途切れる

観測地点は固定されているように見えて、実際には移転や統合が繰り返されています。移転前後で標高が10m変われば気温は0.06度ほどずれ、周囲の建物状況が変われば風速の観測値も変化します。10年以上の時系列を扱う分析では、この不連続が気候の傾向として誤って解釈される事故が起こりがちです。地点コードが同じでも、中身の連続性は保証されていません。移転の有無は観測地点情報の備考欄に記載されているため、確認自体は数分で終わります。

確認手順としては、気象庁が公開する観測地点情報の一覧で、対象地点の設置期間と移転履歴を先に取得する流れです。移転日が判明したら、その前後60日間の日平均気温を比較し、系統的な段差が出ていないか確認してください。段差が0.5度以上あれば、補正するか期間を分けて分析するかの判断が必要です。廃止地点については、代替地点との重複観測期間があるかどうかを必ず調べます。重複期間があれば両地点の差の平均を補正値として使えるため、履歴確認は最優先で行います。

観測粒度と日界のずれ：10分値・毎正時値・日別値で集計基準が異なる

天候データには10分値、毎正時値、日別値、月別値といった複数の粒度が存在し、それぞれ集計の基準が異なります。特に注意すべきは日界、つまり1日の区切り方です。日別値は0時から24時までで集計されますが、自社の売上データが営業日ベースで深夜2時を区切りとしている場合、両者を単純に結合すると数時間分のずれが生じます。このずれは平均気温では見えにくく、降水量のような積算値で顕在化します。結合を始める前に、双方のデータで1日の定義を文書に書き出して突き合わせてください。

粒度を選ぶ判断基準は明快です。時間帯別の来店分析なら毎正時値、日単位の需要予測なら日別値を使います。10分値は風速の瞬間的な変化を見る場合に限り、データ量が日別値の144倍になる点を考慮してください。1地点1年分でも約5万行に達するため、検証段階では対象地点を3つ程度に絞ると作業が進みます。粒度の異なるデータを混在させたまま結合する設計は避けましょう。粒度の選定は最初に1度決めれば済むため、要件定義の段階で結論を出しておきます。

品質情報や利用可否フラグの見落とし：信頼性の低い値が残存する

気象庁の過去データには、数値の隣に品質情報と均質番号という2つの補助項目が付いています。品質情報は8が正常値、5が準正常値、1が資料不足値といった具合に、値の信頼度を段階で示す仕組みです。この列を無視して数値だけを抜き出すと、信頼度の低い値が正常値と同じ重みで平均に混ざります。ダウンロード画面で品質情報の表示設定を外してしまう操作ミスが、現場では最も多く発生します。取得直後に品質情報の列が存在するかを確認する手順を、受領チェックに加えてください。

運用ルールとしては、品質情報が8の値のみを分析対象とし、5以下は欠測として扱う方針が扱いやすくなります。ただし観測開始直後の地点や山間部では5の比率が高く、この基準では対象データが半減する場合もあるのです。利用可否の閾値は、対象期間の品質情報の分布を集計してから決めてください。採用基準を変えた場合は、変更した日と理由を必ず記録に残す運用としてください。品質評価の考え方そのものを整理したい方は、下記の記事が参考になります。

データ品質とは？品質評価項目や品質を向上させるための実務的対策を解説

複数ソース統合時の不整合：単位・時刻表記・地点コードの不統一

気象庁、民間気象会社、自社設置のセンサーを併用すると、単位と時刻表記の不統一が必ず問題になります。降水量がmmとcmで混在したり、時刻がJSTとUTCで混ざったりする事例は珍しくありません。海外ベンダーのAPIから取得した値は、気温が華氏で返る設定がデフォルトになっている点にも注意が必要です。取り込み直後に各列の最小値と最大値を確認するだけで、単位の取り違えは大半を検出できます。検出した不整合は、単位換算の処理を1か所にまとめて修正する構成が保守しやすいです。

地点コードの不統一も同様に厄介です。気象庁の観測所番号、市区町村コード、ベンダー独自IDが混在すると、結合キーが作れません。統合前に地点マスタを1つ作成し、すべてのソースをそのマスタのIDへ変換してから結合する順序を守ります。マスタには緯度経度と標高、観測開始日を含めておくと、後の距離計算や妥当性チェックに再利用できるのです。作成工数は20地点程度で半日が目安です。マスタは1つに絞り、ソースごとの独自コードは対応列として保持してください。

天候データをクレンジングすることで解決できること

クレンジングは手間のかかる工程ですが、投じた工数は分析結果の形で回収されます。ここでは実務で効果が現れやすい4つの領域を取り上げ、どの処理がどの成果に結びつくのかを対応づけて説明します。効果を先に把握しておくと、社内で工数を確保する際の説明材料としても使えるはずです。

需要予測の精度向上：説明変数としての天候データが正しく機能する

天候データを説明変数として投入したのに予測精度が上がらない場合、モデルではなく入力データの整形を疑う価値があります。欠測が0で埋まっていれば、モデルは雨が降らなかった日として学習してしまいます。日界がずれていれば、前日の降水が当日の説明変数として扱われる状態になるのです。この2点を修正するだけで、決定係数が0.05から0.15程度改善した事例は少なくありません。修正の効果は、決定係数よりも誤差の分布を見るほうがはっきり確認できます。

効果を確認する手順も決めておきましょう。クレンジング前後のデータで同じモデルを学習させ、テスト期間の平均絶対誤差を比較します。この検証は半日程度で終わりますが、以降の改善方針を大きく左右する情報が得られます。差が5%未満なら天候以外に主要因があると判断し、変数選択の工程へ戻る流れが効率的です。検証結果は日付とデータの版数を添えて残し、次回の比較にそのまま使えるようにします。予測モデルの設計そのものを見直したい場合は、下記の記事も参考になります。

店舗開発における売上予測とは？精度を上げるポイントを徹底解説

売上・来店データとの比較分析：気象条件による変動要因を切り分けられる

売上が前年比で10%落ちたとき、その原因が施策なのか天候なのかを切り分けられる状態は、意思決定の質を大きく変えます。天候データが整っていれば、気温と降水量を条件に揃えた同質日どうしを比較でき、施策の効果だけを取り出せます。同質日の定義は、日平均気温の差が2度以内かつ降水の有無が一致する日、といった具合に数値で決めておくのが実務的です。定義を文書化しておけば、部門をまたいだ議論でも前提の食い違いが起きません。

実際の作業では、店舗と観測地点の対応表を先に用意します。最寄り地点を機械的に割り当てると、直線距離では近くても山を挟んで気候が異なる地点が選ばれてしまうのです。距離が20kmを超える場合や標高差が200m以上ある場合は、担当者が個別に判断する運用が現実的です。対応表には割り当ての理由を書く列を1つ足しておくと、後から見直す際の手掛かりになります。対応表の初版作成は20拠点程度なら1日で終わり、以降は拠点の増減に応じて追記するだけで維持できます。

異常気象時の実績評価：外れ値と実際の極値を区別して扱える

統計的な外れ値検出をそのまま適用すると、猛暑日や記録的大雨といった実際に起きた極値が除外されます。しかし異常気象時の実績は、リスク評価や需給計画の観点でむしろ最も価値のあるデータです。除外すべきは観測エラーであり、極値ではありません。区別の判断には、同一地点の過去30年の記録と近隣地点の同時刻の値という2つの材料を使います。両者を切り分ける仕組みを持てば、災害時の売上変動や稼働停止の影響を定量的に振り返れるのです。

判断の具体例を挙げます。ある地点で日最高気温が40度を記録した場合、近隣3地点の同日の値が38度前後であれば実際の高温と判断できます。一方で近隣地点が25度なら、センサーの故障を疑う根拠になるのです。この近隣比較は表計算ソフトでも実装でき、対象地点の緯度経度から半径50km以内の地点を抽出する処理を組めば自動化できます。抽出処理は一度作れば毎月の更新でも再利用できます。近隣地点が3つ取れない離島や山間部では、過去の同時期の値との比較に切り替える運用が現実的です。

分析結果の再現性確保：処理ルールの統一により担当者間の差異がなくなる

同じ元データを渡しても担当者ごとに集計結果が違う、という相談は頻繁に受けます。原因のほとんどは、欠測の扱いと日界の解釈が明文化されていない点にあります。Aさんは欠測日を除外して月平均を出し、Bさんは前後の値で補完してから平均を出す、といった差が積み重なるのです。月平均気温で0.3度、月降水量で10mm以上の差が生まれることも珍しくありません。差の大きさを一度測っておくと、ルール整備の必要性を社内で説明しやすくなります。

再現性を担保する最小構成は、処理ルールを記した文書と、実行可能なスクリプト1本の組み合わせです。文書には欠測の判定条件、補完手法、異常値の閾値、除外した場合の記録方法を明記します。スクリプトはPythonのpandasでもSQLでも構いませんが、入力ファイルと出力ファイルのパスを引数化しておくと運用しやすくなります。整備の初期工数は10人日前後を見込んでおきましょう。文書とスクリプトは同じ場所で管理し、更新の際は両方を同時に見直します。

天候データのクレンジングの進め方

ここからは実際の作業手順を8つの段階に分けて説明します。順序には理由があり、特に標準化を統合より前に置く点は崩さないでください。各段階で決めるべき内容と、判断に使う基準を具体的に示します。

STEP1：利用目的から必要な観測要素・地点・時間粒度を定義する

最初に決めるのは、取得するデータの範囲です。とりあえず全要素を全地点分という進め方は、処理時間と保管コストを膨らませるうえ、品質確認の対象も広がりすぎます。日別売上との相関分析が目的なら、日平均気温・日降水量・日照時間の3要素と、店舗最寄りの観測地点だけで足ります。要素を絞ると、後の欠測確認や異常値判定にかけられる時間が増えるのです。要素を1つ増やすたびに、品質確認と補完設計の工数が2割ほど積み上がる感覚で見積もります。

定義書に落とし込む際は、目的と要件を1対1で結びつけて書きます。気温が必要かという問いではなく、日別来店数の説明変数として日平均気温を使うと書けば、後から粒度を変更する判断も容易になるのです。対象期間についても、直近3年なのか10年なのかで観測地点の移転を考慮する必要性が変わるのです。更新の頻度についても、日次なのか月次なのかで自動化に投じるべき工数が大きく変わります。定義の際に埋めておきたい項目を確認してください。

• 分析の目的と、天候データを使う具体的な場面
• 必要な観測要素と、その単位
• 対象地点の一覧と、選定した理由
• 時間粒度と、集計の日界
• 対象期間と、更新の頻度

STEP2：データソースと取得範囲を確定し、実測値と予報値を区別する

天候データの入手経路は、気象庁の過去データ検索、気象業務支援センターの配信、民間気象会社のAPIの3つが代表的です。無償で使える気象庁のデータは1回のダウンロードで取得できる項目数に上限があり、地点数と期間の組み合わせによっては複数回に分ける必要があります。10地点10年分の日別値なら、5回程度に分割する想定で作業計画を立ててください。有償APIは取得上限が緩い一方、月額数万円からの費用が発生する点を比較材料に含めます。

見落としやすいのが、実測値と予報値の混在です。民間APIでは同じ取得先から両方が返る仕様が多く、日付だけでは判別できません。取り込み時に実測と予報を示す列を必ず作り、値の出所を保持します。過去の予測精度を検証する場面では予報値も貴重な資料になるため、削除せず分離して保管しましょう。予報値には発表時刻を示す列を必ず持たせ、いつの時点で出された予報かを判別できるようにしてください。取得方法の全体像は下記の記事が参考になります。

データ収集の重要性と技術的方法&よくある課題と対応策を解説

STEP3：品質情報をもとに各観測値の利用可否を判定する

取得したデータの品質情報を集計し、利用可否のフラグを付与します。この判定を最初に済ませておくと、以降の標準化や補完の対象が明確になり、無駄な処理を減らせます。実務では品質情報が8の値をそのまま採用し、5の値は分析要件に応じて採用可否を切り替える設計が扱いやすいです。1以下は原則として欠測へ倒し、後段の補完対象として扱う運用が標準的です。品質情報の分布は地点別と年別のクロス集計で確認でき、10地点10年分でも作成に数分しかかかりません。

判定結果は上書きせず、元の値を残したまま別列として持たせてください。品質情報が5の値を後から採用する判断に変えた場合、元データを再取得せずに済みます。列の構成は、観測値・品質情報・利用可否フラグ・判定日の4列を基本形にすると管理が安定します。判定の基準を変更した際は、判定日を更新して履歴を追えるようにしておくのです。判定に使った基準の版数を列として持たせると、過去の集計との差分も説明できます。運用が固まるまでは、判定結果を月次で見直す時間を確保してください。

STEP4：単位・日時表記・地点コードを標準化する

標準化では、単位・日時・コードの3系統を順に揃えます。単位は降水量をmm、気温を摂氏、風速をm/sに統一し、変換した場合は変換係数を記録に残してください。日時はISO 8601形式の文字列で保持し、タイムゾーンをJSTに固定します。表計算ソフトで開くと日付が自動変換されて桁が欠ける事故が起きるため、中間ファイルはCSVではなくParquetかTSVを推奨します。単位変換を行った列には、変換前の値を残した列を並べて保持してください。

地点コードは、気象庁の観測所番号を主キーに据える方法が最も安定します。市区町村コードは合併で変わり、ベンダー独自IDは仕様変更のリスクを抱えているためです。標準化のルールは対応表として1ファイルにまとめ、バージョン番号を付けて管理します。10地点30項目程度なら、初回の整備に2〜3人日を見込んでおくと現実的です。対応表を更新した際は版数を上げ、どの版で処理したかを出力ファイルに記録します。前処理全体の設計を知りたい方は下記が参考になります。

データプレパレーションとは？ETLとの違いから成功ポイントまで徹底解説

STEP5：重複レコードを除去し、地点と時刻をキーに統合する

重複は、同じ期間を2回ダウンロードした場合や、複数ソースを縦に結合した場合に発生します。除去の前に、重複の中身が完全一致なのか値が異なるのかを必ず確認してください。値が異なる重複は、ソースの優先順位を決めて残す側を選びます。優先順位は気象庁の実測値、自社センサー、民間APIの補完値といった順で明文化しておくと、判断が属人化しません。優先順位を書いた表は、参照するソースが増えるたびに行を追加して最新の状態に保ってください。

統合のキーは、地点コードと観測日時の2列で構成します。この2列で一意にならない場合は、粒度の異なるデータが混ざっている証拠です。件数の検算も忘れずに行いましょう。10地点365日分なら3,650行になるはずで、これを超えるなら重複、下回るなら欠落を疑います。検算は結合の前後で1回ずつ実施し、差分が出た地点を先に調べる手順が効率的です。件数が合わない場合は、統合前のソース単位で行数を出し直すと原因を特定しやすいです。統合作業の考え方は下記の記事にまとまっています。

データ統合とは？統合の目的や初心者向けの進め方を解説

STEP6：欠測値の補完方針を決めて適用する

補完手法の選択は、欠測の長さと観測要素の性質で決まります。1時間から3時間の短い欠測なら前後の値を使った線形補間が有効ですが、24時間を超える欠測に同じ手法を当てると実態から大きく外れた値になるのです。気温のように連続的に変化する要素は補間が効きやすく、降水量のように不連続な要素は近隣地点の値を採用する方法が適しています。要素ごとに手法を変える前提で設計してください。補完手法を要素ごとに書き分けた設計書があれば、担当が変わっても同じ結果を再現できます。

補完した値には必ず補完フラグを立て、実測値と同じ列に混ぜたまま放置しない運用が鉄則です。フラグがあれば、補完値を除外した集計と含めた集計の両方を後から出せます。この使い分けができないと、精度検証の場面で補完の影響を分離できません。補完率が月あたり10%を超える地点は、そもそも分析対象から外す判断も選択肢に入れましょう。補完の実行前後で月合計を比較し、差が想定の範囲に収まっているかを確認します。主な補完手法の比較を下記に整理します。

STEP7：異常値の判定基準を設け、処理内容を記録に残す

異常値の判定は、統計的な基準と物理的な基準の2つを併用します。統計的な基準としては、同月同地点の過去30年の値から平均と標準偏差を求め、3シグマを超える値を候補として抽出する方法が使いやすいです。物理的な基準は、日最低気温が日最高気温を上回る、降水量が負の値になるといった、あり得ない組み合わせの検出を指します。後者は例外なく誤りと判断できるのです。物理的な基準はスクリプトの冒頭でまとめて検査し、該当した行を即座に隔離します。

抽出した候補をすべて除外してはいけません。近隣地点との比較で同じ傾向が出ていれば、それは実際の極値です。判断の結果は、日時・地点・元の値・判定結果・根拠の5項目でログに残してください。このログがあると、半年後になぜこの日のデータがないのかと聞かれた際に即答できます。ログは日付付きのファイルとして保存し、上書きせずに追記していく形が扱いやすいです。判定件数が月10件を超える場合は、基準そのものの見直しを検討します。外れ値の可視化手法は下記の記事が参考になります。

箱ひげ図とは？外れ値の見方やExcelでの作成方法まで徹底解説

STEP8：クレンジング結果を検証し、処理ルールを手順化する

検証は3つの観点で行います。件数が想定どおりか、欠測率と補完率が許容範囲か、そして主要な統計量が平年値と大きく乖離していないかです。月平均気温が平年値から3度以上ずれている月があれば、処理のどこかに誤りがある可能性が高いと考えます。この確認は集計表を1枚作るだけで済み、所要時間は30分程度に収まります。乖離が見つかった月は、元データまで遡って処理の途中経過を確認してください。検証結果の集計表は毎回同じ形式で保存し、前回分と並べて比較できるようにします。

検証を通過したら、処理内容を手順書に落とし込みます。手順書には実行順序、各処理のパラメータ、判断が必要な箇所と基準、実行者と実行日を記載してください。スクリプト化できる部分はコードに寄せ、判断が必要な部分だけを人が見る構成にすると、月次更新の工数を初回の2割程度まで圧縮できます。判断が必要な箇所には、迷った際に誰へ相談するかまで書いておくと、担当者が変わっても運用が止まりません。手順書の点検項目は次のとおりです。

• 入力ファイルの形式と取得元が明記されているか
• 欠測と異常値の判定基準が数値で書かれているか
• 補完手法と適用条件が要素ごとに整理されているか
• 出力ファイルの列定義と型が固定されているか
• 実行ログの保存先が決まっているか

天候データのクレンジングで押さえておきたい実務ポイント

手順どおりに進めても、天候データ特有の落とし穴でつまずく場面があります。ここでは相談を受ける頻度が高い5つの論点を取り上げ、判断の指針を示します。いずれも一度ルール化してしまえば、以降は迷わず処理できるものばかりです。

欠測とゼロ値の区別：降水量・日照時間の集計は分けて扱う

月降水量を求める際は、欠測を含む月の扱いを決めておく必要があります。気象庁の統計では、欠測が一定日数を超えた月の値は資料不足として扱われます。自社集計でも同じ考え方を採用し、日別値の欠測が月内で3日を超えたら月合計を算出しない、といった基準を設けてください。基準を設けずに合計すると、欠測分だけ降水量が過小に出るのです。有効日数と欠測日数を出力ファイルの列として残しておけば、後から基準を変えても再集計できます。

日照時間の集計はさらに注意が必要です。0時間の日には、悪天候で日照がなかった日と観測休止日の両方が含まれます。月別の日照時間を出す場合は、有効日数で割った1日あたりの平均を併記すると比較可能性が保たれます。降水量と日照時間を同じ処理関数で扱う設計は避けたほうが安全です。共通化を優先した結果、片方の要素で誤った集計が混入する事故は繰り返し起きています。処理関数は要素ごとに分け、共通化は単位変換など安全な部分にとどめてください。

風向データの扱い：方位は角度データのため単純平均が成立しない

風向は0度から360度で表現されますが、この値を単純に平均してはいけません。北寄りの風が続いた日に350度と10度を平均すると180度、つまり南風という誤った結果が出るのです。風向の平均を求める場合は、東西成分と南北成分に分解してから合成するベクトル平均を使います。表計算ソフトでもsin関数とcos関数で実装でき、行数が数万件でも数秒で計算が終わります。計算結果の妥当性は、卓越風向が周辺の地形と矛盾していないかで確認してください。

実務では、風向を16方位のカテゴリとして扱うほうが便利な場面も多くあります。需要予測の説明変数に使うなら、角度のままより北寄りや南寄りといった区分のほうがモデルに乗せやすいです。判断基準は明快で、風向の連続的な変化を追う分析なら角度、条件分けや集計が目的ならカテゴリを選びます。静穏時の風向は欠測ではなく0として記録される点にも注意してください。角度とカテゴリの両方を列として持たせておくと、後から手法を変える際に再計算が不要になります。

気温データの段差検知：観測環境の変化による系統的なずれを疑う

観測環境の変化は、値の分布に段差として現れます。周囲に建物が建った、樹木が伐採された、測器が更新されたといった事情で、平均気温が0.3度から0.5度ほど系統的にずれる事例が報告されているのです。この種のずれは1日ごとの値を見ても気づけません。移動平均や近隣地点との差分をグラフにして初めて見えてくる性質のものです。段差を見逃したまま長期のトレンドを語ると、結論そのものが誤った方向へ進みます。検知の作業は年1回、対象地点をまとめて点検する形で組み込むと負担が小さくなります。

検知の実務手順は、対象地点と近隣地点の日平均気温の差を時系列に並べ、365日移動平均を引くところから始めるのが基本です。差の移動平均が0.3度以上ジャンプしている時点があれば、その前後で観測環境が変わった可能性を疑ってください。該当時点が見つかったら、観測地点情報の履歴と照合します。原因が特定できた場合は、期間を分けて分析するか、差分の平均値で補正する対応を選びます。補正を選んだ場合は、補正量と算出の根拠を必ずログへ残してください。

実測値と推計値の分離：データの出所を示す項目を必ず保持する

民間気象会社が提供するメッシュ気象データは、観測点の実測値を空間的に内挿した推計値を含みます。1kmメッシュの気温は、実際にその地点で測った値ではない点に注意が必要です。推計値は面的な分析に便利ですが、精度検証の場面で実測値と混同すると評価そのものが成立しなくなります。データの出所を示す列を最初から設計に含めておく必要があるのです。推計値の精度は内挿に使われた観測点からの距離で変わるため、提供元の仕様書で算出方法を確認します。

出所の管理は、データリネージの考え方をそのまま適用できます。列としては、データ提供元、取得日時、加工処理の識別子、実測か推計かの区分の4つを持たせる構成が実用的です。加工処理の識別子は手順書のバージョン番号と一致させておくと、どのルールで処理された値かを後から辿れます。この設計を後付けするのは手間がかかるため、初期段階で決めてください。既存データへ後から列を足す場合でも、区分が不明な行は不明のまま残してください。

自社データとの結合：拠点と観測地点の対応づけルールを先に決める

拠点と観測地点の対応づけは、直線距離だけで決めないほうが安全です。距離が近くても、間に山地があれば気候区分が異なる場合があります。対応づけの判断基準としては、直線距離20km以内、標高差200m以内、同一の気候区分という3条件を満たすかどうかを確認する方法が実務的です。3条件を満たす地点がなければ、複数地点の加重平均を検討します。加重には距離の逆数を使う方法が扱いやすく、表計算ソフトの数式だけでも実装できます。ただし加重の算式は、対応表と同じ場所に記録しておいてください。

対応表は拠点マスタとは別ファイルで管理し、拠点の新設や閉鎖に合わせて更新する運用にします。同じ拠点に複数の観測地点を割り当てる設計も可能ですが、集計ロジックが複雑になるため最初は1対1から始めてください。1対1で精度が不足すると判断してから多対1へ拡張する順序なら、変更の影響範囲を把握しやすくなります。対応表の見直しは年1回を目安に実施しましょう。見直しの際は、拠点の移転や観測地点の廃止がなかったかをあわせて確認します。

天候データのクレンジングでよくある失敗パターン

ここまでの手順を踏んでも、判断を1つ誤れば成果物の信頼性は損なわれるのです。実際の現場で繰り返し発生している5つの失敗を、原因と回避策の組み合わせで整理しました。着手前に目を通し、自社の進め方と照らし合わせてください。

欠測をゼロで補完し、降水量の実績を過小評価する

最も頻度が高い失敗です。気象庁のCSVを表計算ソフトで開き、空欄を一括で0に置換した時点で発生します。欠測を0で埋めると、その日は降水なしとして扱われ、月合計も年合計も実際より小さくなるのです。降水日数を条件に使った分析では、雨の少ない年という誤った特徴が抽出されます。台風の時期に観測装置が停止した年ほど、この誤りの影響は大きく出ます。被害の大きい年ほどデータが欠けやすいという性質を、前提として押さえてください。

回避策は2つあります。1つは受領時点で空欄と0の件数をそれぞれ数え、記録として残す方法です。もう1つは、補完を実行する関数の中で0への置換を行わない旨をコメントとして書き残す方法になります。表計算ソフトでの手作業を廃し、スクリプト経由に統一するだけでも発生率は大きく下がります。作業を統一する初期コストは1〜2人日で、失われるデータの価値を考えれば安い投資です。置換の履歴が残る形にしておけば、誤りが起きても遡って復元できます。

標準化より先に地点統合を行い、別地点のデータが混在する

地点コードの標準化を後回しにして統合すると、別の地点のデータが同一地点として結合される事故が起こります。市区町村コードをキーにした場合、1つの市に複数の観測地点があると、どちらの値が採用されたか分からなくなるのです。合併で市域が変わった年をまたぐと、さらに追跡が困難になります。この事故は結合後の件数チェックだけでは検出できません。件数は一致するのに中身が別地点という状態が、この失敗のやっかいな点です。標準化を省略して得られる時間は、せいぜい半日程度にすぎません。

回避策は手順の順序を守ることに尽きます。標準化を終えてから統合へ進む原則を、手順書の冒頭に明記してください。検証としては、統合後のデータで地点コードごとの緯度経度がすべて一意になっているかを確認します。1つの地点コードに2組以上の緯度経度が紐づいていれば、異なる地点が混ざっている証拠です。この確認はSQLの集計句1行で実行でき、数十万行でも数秒で結果が返ります。一意性の確認は、統合処理の最後に自動で走らせる構成にしておきます。

実際に発生した極値を外れ値として除外してしまう

外れ値の自動除外を処理の流れに組み込むと、猛暑日や記録的豪雨のデータが静かに消えていきます。異常気象の影響を分析したい場面で、肝心のデータが存在しないという事態に陥るのです。除外処理は実行ログを残さない実装になっていることが多く、消えたことに気づくまで時間がかかります。半年後の分析で初めて発覚する例も見てきました。除外の実装がどこに入っているかを、着手の時点で洗い出しておいてください。既製の前処理ライブラリでは、初期設定で外れ値を落とす仕様になっている場合もあります。

自動除外は候補の抽出までにとどめ、最終的な採否は人が判断する構成に切り替えてください。判断の材料は、近隣地点の同日同時刻の値と、気象庁が公表する記録的な現象の情報です。両方が同じ傾向を示していれば実際の極値と確定できます。候補件数は10地点1年分で数十件程度に収まるため、月1回の確認作業として運用に組み込めます。確認作業の担当者と実施日をあらかじめ決めておく点が、運用を形骸化させないコツです。判断に迷った候補は保留として残し、次回の確認へ回してください。

補完・除外の判断根拠を残さず、分析結果を検証できなくなる

この日のデータだけ他の年と傾向が違うと指摘されたとき、根拠の記録がなければ答えようがありません。処理から時間が経つほど、当時の判断を思い出すのは難しくなります。記録の欠落は、分析結果そのものへの信頼低下に直結するのです。外部への報告資料に使うデータであれば、なおさら説明責任が問われます。実際に、根拠を示せずに分析をやり直した事例も珍しくありません。根拠を残す作業そのものは、1件あたり数十秒で終わる程度の負担です。

記録の形式は、1行1判断のログテーブルが最も扱いやすいです。列は日時、地点コード、観測要素、元の値、処理内容、判断根拠、実行者の7つを基本とします。判断根拠は自由記述で構いませんが、近隣3地点も同水準のため採用といった具合に、具体的な理由を書いてください。ログの追記はスクリプトの中で自動化し、手作業の入力に頼らない設計にします。ログは分析結果と同じフォルダに置き、報告資料とあわせて保管してください。保管期間は、分析結果を参照しうる期間より1年長く設定しておくと安心です。

一度きりの処理で終わり、更新データに同じルールを適用できない

初回のクレンジングを表計算ソフトの手作業で終わらせると、翌月のデータで同じ処理を再現できません。列の並びが少し変わっただけで手順が崩れ、結果として毎月異なるルールが適用されます。時系列分析では、過去と現在で処理ルールが違うこと自体が致命的な問題になるのです。更新頻度が高いデータほど、この失敗の代償は大きくなります。手作業に戻らないよう、初回の時点から自動化を前提に組み立ててください。処理の再現性は、分析の正しさと同じ水準で扱うべき品質要件です。

対策は、初回から再実行を前提に設計することです。入力ファイルのパスと対象期間を引数化し、同じスクリプトで毎月実行できる形にします。処理結果は日付付きのフォルダへ出力し、過去の実行結果を上書きしない構成にしてください。月次更新にかかる時間は、この形にできれば10地点規模で30分以内に収まります。初期の作り込みに5〜10人日かかりますが、3か月ほどで回収できる計算です。実行のたびにログを残し、前回との差分を確認する習慣も一緒に組み込みます。

天候データのクレンジングの活用事例

実際にクレンジングへ手を入れた組織が、どこで効果を得たのかを4つの例で紹介します。いずれも特別なツールを導入したわけではなく、処理ルールの見直しが成果に結びついた事例です。自社の状況に近いものから読み進めてください。

小売業：日別売上と気温データの結合基準を統一し需要予測を改善した例

全国に120店舗を展開する小売企業では、日別売上と気温の相関分析が店舗ごとにばらつくという課題を抱えていました。調べたところ、店舗側の売上は営業日ベースで翌2時までを当日として集計し、気温は0時から24時の日別値を使っていました。この日界のずれが、夏季の夕方以降に売上が伸びる業態で特に影響していたのです。ずれの存在は、売上の高い日と最高気温の日が1日ずれる形で現れていました。気づいたきっかけは、店舗担当者からの体感と数字が合わないという指摘でした。

対応として、気象データを毎正時値で取得し直し、店舗の営業日定義に合わせて再集計するルールへ変更しました。作業工数は設計と実装で合わせて8人日です。変更後は相関係数が0.42から0.61へ改善しました。現在は週次の発注計画に気温予報を組み込む運用が定着しています。日界の照合は他業態でも有効なため、天候データを扱う際の初期チェック項目として加えてください。小売業のデータ分析全般については、下記の記事が参考になるはずです。

小売業のデータ分析で何がわかる？目的・やり方・費用をわかりやすく解説

飲食チェーン：欠測補完ルールの標準化で来店予測の再現性を確保した例

店舗数40の飲食チェーンでは、来店客数予測の結果が担当者によって食い違う状態が続いていました。原因は欠測の扱いにあり、ある担当者は欠測日を除外し、別の担当者は前日の値をコピーして埋めていたのです。同じ月の平均気温で0.4度の差が生じ、予測値にも数%の開きが出ていました。どちらの処理も間違いではありませんが、揃っていないこと自体が問題でした。予測の根拠を経営層へ説明する場面で数字の違いを問われたことが、見直しの契機です。

見直しでは、欠測日は補完せず除外し、月内の欠測が3日を超えた月は集計対象から外すルールに統一しました。ルールは1ページの手順書にまとめ、四半期ごとに見直す運用です。統一後は、誰が実行しても同じ予測値が再現されるようになりました。予測精度そのものは大きく変わっていませんが、数字の裏付けを説明できる状態になった点が現場では評価されています。手順書は新任担当者への引き継ぎ資料としても機能し、教育時間の短縮にもつながった点が副次的な効果です。

建設業：降水量データの時間粒度を揃え作業可否判断に活用した例

屋外作業の可否判断に気象データを使う建設会社では、日別の降水量だけでは判断できないという課題がありました。1日で10mmの降水でも、朝に集中したのか夜間だったのかで作業計画への影響は大きく異なります。そこで毎正時値を取得し、作業時間帯である8時から17時の降水量を別途集計する処理を追加したのです。日別値のみを見ていた時期は、実際には作業可能だった日を中止と判断する例が月に2件から3件発生していました。

実装で問題になったのは、毎正時値の欠測でした。作業時間帯の10時間のうち2時間が欠測している場合、残り8時間の合計をそのまま使うと降水量を過小評価してしまうのです。対応として、欠測が2時間を超える日は判断保留とし、現地の目視確認へ回すルールを設けました。この運用により、天候を理由とした作業中止の判断根拠が記録として残るようになっています。保留となる日は年間で10日前後に収まっており、運用上の負担は小さいままです。

エネルギー業：観測地点の変更履歴を補正し長期需要分析を実現した例

電力需要の長期分析を行うエネルギー企業では、20年分の気温データを使った分析で不自然な傾向が出ていました。特定の年を境に平均気温が0.6度上昇しており、当初は都市化の影響と解釈されていたのです。実際には対象地点が移転しており、標高と周辺環境の変化が原因でした。地点コードは変わっていなかったため、データ側からは気づけない状態が続いていました。解釈の誤りに気づいたのは、近隣の別地点のデータと突き合わせて傾向が一致しないと分かった段階でした。

対応では、観測地点情報の履歴を照合して移転日を特定し、移転前後60日の重複観測データから補正値を算出しました。補正値を移転前の期間へ適用した結果、不自然な段差は解消しています。この作業に要した期間は約3週間です。長期時系列を扱う分析では、地点の履歴確認を最初の工程に組み込む方針へ改めました。履歴確認は10地点でも1日あれば終わるため、手戻りを防ぐ効果は費用対効果に見合います。同じ確認手順は、他の観測要素にも横展開できる汎用性があるのです。

まとめ：天候データのクレンジングは「出所」と「欠測の扱い」の定義から始まる

天候データのクレンジングで最初に決めるべきは、値の出所を記録する仕組みと、欠測をどう扱うかという2点です。この2つが定まれば、標準化も統合も補完も一貫したルールで進められます。逆にここが曖昧なまま作業を始めると、後から検証できないデータが積み上がっていきます。出所と欠測の2点だけは、着手前に文書として固めておいてください。

着手前に確認しておきたい項目を、点検リストとして整理しました。自社の進め方と1つずつ照らし合わせてみてください。

• 分析目的から必要な観測要素と時間粒度を定義したか
• 実測値と予報値、実測値と推計値を区別する列を持たせたか
• 品質情報をもとに各観測値の利用可否を判定したか
• 標準化を統合より前に実施する順序になっているか
• 欠測と異常値の判断根拠をログとして残しているか
• 同じ処理を翌月も再実行できる形になっているか

すべてに問題なしと答えられる状態であれば、分析工程へ進んで差し支えありません。1つでも空欄が残るなら、その項目から着手してください。整備には初期で10人日前後、月次の運用で30分程度を見込んでおくと計画が立てやすくなります。

「これから天候データの活用に取り組みたいけれど、何から手をつけたらいいかわからない」「データ専門家の知見を取り入れたい」という方は、データ領域の実績豊富な弊社、データビズラボにお気軽にご相談ください。

貴社の課題や状況に合わせて、天候データの活用に向けた取り組みをご提案させていただきます。

データビズラボの実績無料相談・お見積り