Claude Codeで積算温度を出す — 気象庁の気温データから収穫時期の目安へ

積算温度は、起点の日から毎日の日平均気温を足していった合計です。作物の成熟は日数よりも温度の積み重ねに左右されるため、「出穂後に何℃分たまったら刈り取りを考える」という形で収穫時期の目安に使われます。気象庁の「過去の気象データ・ダウンロード」から日別の気温をCSVで取れば、この合計は短いスクリプトで出せます。

Claude Codeに任せるのは、CSVの読み込みと積算のスクリプトを書き、手計算できる小さなデータで検算するところまでです。収穫日そのものは決めさせません。積算の目標値は品種と地域の栽培指針に書かれた数字を使い、出てきた日付は目安として扱います。

積算温度は何を足した値か

鳥取県の水稲の生育情報では、収穫適期を「出穂後に日平均気温を積算した値」で予測しています。同じ資料に載る数値は次のとおりです。

ここから読み取れる決まりごとは3つあります。

• 起点は出穂後です。暦の1月1日からの合計ではなく、作物ごとの起点日を決めて数えます
• 足すのは日平均気温です。最高気温や最低気温ではありません
• 目標は1点でなく幅です。品種と標高によって下限・上限が違います

同じ県の資料には「有効積算気温」という別の数値も並びます。基準温度を差し引いた計算に基づく値と見られますが、基準温度は掲載ページに書かれていません。日平均気温をそのまま足す積算と混ぜると数字が合わなくなるので、どちらの指針の数字を使うのかを先に決めておきます。

県の予測は、アメダスの実測値と1か月予報値から1kmメッシュごとの日平均気温を推定し、それを積算して収穫時期を出しています。気象庁のCSVで作るのは、これの「観測点1か所・実測値だけ」の簡易版です。圃場の標高や地形による違いは入らないため、答えは目安にとどまります。

気象庁のサイトで日別の気温を取る

過去の気象データ・ダウンロードのページは、地点・項目・期間を選んでCSVを落とす形式です。ページの表示にはJavaScriptを使います。ここで効いてくるのが、表示オプションの選び方です。ダウンロードファイルの形式の説明ページには、オプションごとにCSVの中身が変わると書かれています。

積算に使うなら、次の3つを選んでおくと後工程が楽になります。

1. 項目は日別値の日平均気温を選ぶ
2. 「利用上注意が必要なデータは値を表示する」を選び、品質情報を残す
3. 「観測環境などの変化にかかわらず、すべての期間の値を表示する」を選び、均質番号を残す

品質情報と均質番号を落とした状態でCSVを取ると、欠けた日や観測環境が変わった日を後から見分けられません。さらに、「CSVファイルのデータ仕様はすべて数値で格納」を選ぶと、品質情報は値とは別の列に入ります。5) や 4] のように記号が付いた値を文字列処理で剥がす手間が要らなくなります。

CSVの構造と、品質情報・均質番号の意味

説明ページによると、CSVは次の並びです。

• 1行目はダウンロードした時刻
• 2行目は空行
• 3〜5行目が表題行(地点名、項目名、現象なし情報・品質情報・均質番号の別)
• 6行目からがデータ行

データ行には、観測値に続けて品質情報と均質番号が付きます。品質情報の値は次のように定義されています。

準正常値(5)の基準は、必要な資料数が全体の80%とされています。つまり日平均気温が5でも、その日の観測の欠けは2割以内です。積算には使えますが、何日あったかは数えておく価値があります。4・2・1の日は、その日の気温をそのまま足すと合計が崩れます。

均質番号は、観測環境の変化を表す番号です。説明ページは、値そのものに意味はないが、異なる均質番号の値同士は単純に比較できないと書いています。番号はCSVを取得するたびに古い期間から1、2と振られるため、期間を分けて取った複数のCSVをつなぐときは、番号が別の意味になる点にも注意が要ります。

なお、官署の気温やアメダスの項目には「現象なし情報」の列が付かない、とも書かれています。気温のCSVでは品質情報と均質番号の2列を見れば足ります。

積算ルールをCLAUDE.mdに書く

CLAUDE.mdは、プロジェクトのルートに置くmarkdownファイルで、Claude Codeがセッションの開始時に読みます。積算のルールを書いておくと、毎回同じ扱いでスクリプトを書かせられます。

# 積算温度の計算ルール
- 入力は気象庁「過去の気象データ・ダウンロード」の日別値CSV
  (日平均気温。品質情報と均質番号を表示するオプションで取得)
- 表題は5行(1行目: 取得時刻、2行目: 空行、3〜5行目: 表題行)。データは6行目から
- 起点日は引数で受け取る。起点日を含めるかは「含める」で固定する
- 積算に使う品質情報は 8 と 5 のみ。4・2・1 の日は足さずに日付を一覧で報告する
- 欠けた日を前後の平均などで補完しない。補完するかどうかは人が決める
- 均質番号が期間の途中で変わっていたら、積算を止めて警告する
- 目標値の下限・上限は引数で受け取る。コード内に品種ごとの数字を埋め込まない
- 結果は「目標到達日(下限・上限)」と「使った日数・除いた日数」を併記する
- 元のCSVは編集しない。結果は別ファイルに書く

「補完しない」「均質番号が変わったら止める」の2行が、この作業の核です。足りない日を黙って埋めると、合計はそれらしく出ますが根拠のない数字になります。

スクリプトを書かせて実行する

ルールを置いたら、Claude Codeに次のように依頼します。

claude -p "CLAUDE.mdのルールに従い、accum.pyを作って。
引数はCSVのパス・起点日・下限・上限。
文字コードはCSVの実物を確認して決めること。
作成後、tests/ に合成データで検算するテストも書いて実行して"

文字コードを指定せず「実物を確認して」と頼むのは、取得したファイルのエンコードに合わせるためです。以下は、Claude Codeが書くスクリプトの一例で、日付が先頭の1列、続いて気温・品質情報・均質番号が並ぶ形を想定しています。実際の列の並びはオプションの選び方で変わるので、表題行を見せて合わせさせます。

import sys
import pandas as pd
 
OK_QUALITY = {8, 5}  # 正常値・準正常値のみ積算に使う
 
def load(path, encoding):
    df = pd.read_csv(path, header=None, skiprows=5, encoding=encoding)
    df = df.iloc[:, :4]
    df.columns = ["date", "temp", "quality", "homog"]
    df["date"] = pd.to_datetime(df["date"])
    return df
 
def accumulate(df, start, lo, hi):
    d = df[df["date"] >= pd.Timestamp(start)].copy()
    if d["homog"].nunique() > 1:
        raise SystemExit("均質番号が途中で変わっています。積算を止めます")
    bad = d[~d["quality"].isin(OK_QUALITY)]
    good = d[d["quality"].isin(OK_QUALITY)].copy()
    good["cum"] = good["temp"].cumsum()
    reach = lambda x: good.loc[good["cum"] >= x, "date"].min()
    return reach(lo), reach(hi), len(good), bad["date"].dt.date.tolist()
 
if __name__ == "__main__":
    path, start, lo, hi, enc = sys.argv[1:6]
    r_lo, r_hi, used, skipped = accumulate(load(path, enc), start, float(lo), float(hi))
    print(f"下限到達: {r_lo.date() if pd.notna(r_lo) else '未到達'}")
    print(f"上限到達: {r_hi.date() if pd.notna(r_hi) else '未到達'}")
    print(f"使った日数: {used} / 除いた日: {skipped}")

実行例は次のとおりです。出穂日を8月10日、目標を910〜1110℃とした場合の呼び出し形です。

python accum.py data.csv 2026-08-10 910 1110 cp932

下限・上限は引数で渡します。ひとめぼれの910〜1110℃は鳥取県の資料にある数字で、他の地域や品種にそのまま使えるわけではありません。自分の産地の栽培指針の数字に差し替えてください。

検算:手で計算できるデータで合わせる

スクリプトが出した日付が正しいかは、答えが分かるデータで確かめます。Claude Codeに合成CSVを作らせ、期待値を手計算で決めてテストさせます。

• 起点日以降の10日間、日平均気温をすべて25.0℃にする。3日目の積算は75℃、10日目は250℃になる。下限を250℃にすると到達日は10日目になる
• 途中の1日だけ品質情報を1(欠測)にする。その日は足されず、250℃への到達が1日遅れ、除外日の一覧にその日付が出る
• 均質番号を途中で2に変える。スクリプトが止まり、警告が出る

3つ目まで通れば、品質情報と均質番号のルールがコードに反映されている証拠になります。実データの結果は、表計算ソフトで同じ期間を足した値とも突き合わせます。Claudeが出した合計だけを信じず、別の経路で一度合わせておくのが安全です。

起点日と観測点を決めるときの注意

県の資料は、予測は目安であり、地形、かんがい水温などの圃場条件、水管理、施肥などの栽培条件で誤差が出ると注意しています。気象庁のCSVで作る簡易版は、もっと粗い見積もりです。次の点が誤差の元になります。

将来の分については、鳥取県の資料でも、予測の一定の日付以降は平年値(直近30年)を使っていて今後変動する可能性が高い、と断っています。過去データだけで「今日までにたまった温度」は出せても、「いつ目標に届くか」の先読みは別の材料が要ります。ここをClaudeに推測で埋めさせない、とCLAUDE.mdに一行足しておくと安全です。

前年や平年と並べて「早いか遅いか」を見る

到達日が1つ出ても、それが例年より早いのか遅いのかは分かりません。鳥取県の資料も、予測を昨年同時期の予測と比べて「同程度〜4日程度早い傾向」といった書き方をしています。同じスクリプトを前年のCSVにも当てれば、同じ起点日・同じ目標値での到達日を並べられます。

Claude Codeには、年ごとの結果を1枚の表にまとめさせます。このとき、起点日は年ごとの出穂日を使い、暦の同じ日付に固定しません。均質番号はCSVの取得ごとに1から振り直されるので、年ごとに別のCSVを取るなら、番号の値そのものでなく、期間内で番号が変わったかどうかだけを見ます。

記録として残す形にする

出力は、日付の一覧と合計だけでは後から検証できません。次の項目を結果ファイルに併記させます。

• 使ったCSVの観測点名と取得期間
• 起点日と、起点日を含めたかどうか
• 下限・上限の数字と、その出典(どの指針か)
• 積算に使った日数と、除いた日の一覧
• 均質番号の確認結果

収穫の判断は、数字が出た後に圃場を見て決めます。積算温度で「そろそろ」を知り、実際の刈り取りは穂や籾の状態で決める、という使い分けです。ここを自動化しないことで、数字の誤差が収穫の失敗に直結するのを避けられます。

よくあるつまずき

数字が合わないときは、次の順に疑います。

1. 表題行の数を間違えて、1行ずれて読んでいる(先頭5行の読み飛ばしを確認)
2. 文字コードが合わず列名が壊れている(CSVの実物で確かめる)
3. 品質情報の列を数値として読んでおらず、フィルターが効いていない
4. 起点日を含める・含めないが、手計算の側と食い違っている

CSVの定型処理は他のログ解析にも通じます。同じく数値ログを扱う手順は温度ログの逸脱区間を洗い出す記事にあります。気象庁のデータを別の形で使う例としては、防災情報XMLから警報を社内通知にする記事が参考になります。基準期間との差で変化を探す考え方は、振動データのFFT解析でも使っています。

まとめ

積算温度は日平均気温の合計という単純な計算なので、難しいのはコードより入力の扱いです。気象庁のCSVは、品質情報と均質番号を残して取れば、欠けた日と観測環境の変化を自分で見分けられます。補完しない、均質番号が変われば止める、という2つの決まりをCLAUDE.mdに書き、合成データで検算してから実データに当てる。この順番を守れば、出てくる日付は根拠を説明できる目安になります。