気象庁の天気予報を読むスキルを作ったら、公開データの奥が思ったより深かった【kurashi-skill Day 2】

前回、日本の暮らしに特化したAgent Skill集「kurashi-skill」を30日間の公開開発で作ると宣言した。

今日はその2日目、jma-weatherの話。気象庁の公開JSONから天気予報を取ってくるスキルだ。正直に言うと、これは宣言の前に仕込んであった5本のうちの1本なので、ライブの制作記ではなく「なぜこう作ったか」の話になる。

作る前に、GitHubを漁った

スキルを書き始める前に、まず既存のOSSを探した。車輪の再発明はしたくない。

気象庁のデータを扱うリポジトリは、あるにはある。Rで気象庁のデータを落とすjmastats、防災情報のXML電文を型付きで読むjmaxml、テロップ番号から天気画像を合成するjma-weather-images。どれも作りは真面目で、僕も参考にした。

ただ、執筆時点でどれも数十スター規模の個人プロジェクトだ。しかもライブラリであって、AIエージェントがそのまま読んで動ける形のものではない。カーリル(図書館)やふるさと納税の計算あたりを調べても、だいたい同じ景色だった。日本の生活データは公開されているのに、その手前の「エージェントへの渡し方」だけが誰も作っていない。

だったら、そこを作ればいい。

気象庁は静かな優良データ源だった

あらためて言うまでもないが、気象庁は、ユーザー登録なしで機械可読な気象・防災データを公開している。APIキーなし、アカウントなし、curl 一本で予報が取れる。2026年の時点でこれはかなりありがたい。

jma-weatherの中身は、やっていること自体は素朴だ。

1. エリアコードを決める
2. 予報JSONを取得する
3. 必要な時刻・地点の値を読む

# 全国のエリア定義が1つのJSONにまとまっている
curl -s https://www.jma.go.jp/bosai/common/const/area.json

# 東京(130000)の予報。天気・降水確率・気温
curl -s https://www.jma.go.jp/bosai/forecast/data/forecast/130000.json

スキルというのは大げさで、実態は「エージェントへの行動手順書」だ。迷子にならないための地図と、踏んだら痛い地雷の場所が書いてある。

地図の読み方: centers → offices → class10s

最初の罠がエリアコードだ。area.jsonは入れ子構造で、centers(管区気象台)の下にoffices(地方の予報単位)、その下にclass10sとかclass15sとか細かい地域がぶら下がっている。

予報APIが食うのはofficesのコードだけだ。東京なら130000。細かい地域のコードをそのまま予報APIに投げると404で死ぬ。「東京の天気を聞いただけなのに404」という不可解な事態の原因は、だいたいこれ。SKILL.mdには「404が返ったらまず階層を疑え」と書いた。

よく使うコードは表にして収録してある。札幌は014100、大阪は270000、那覇は471000。大阪が270000で那覇が471000というのは、並べてみると気象庁の管区の歴史を感じられてちょっと面白い。

週間予報はどこ? という罠

予報JSONのレスポンスは配列で、普通は2要素入っている。1つ目が短期(天気・降水確率・気温)、2つ目が週間だ。

ここで「週間予報だけ欲しいから週間用のエンドポイントは……」と探すと負けだ。別エンドポイントはない。週間分はいつも同じレスポンスの2要素目に入っている。僕は最初これで30分溶かしたので、SKILL.mdには最初の方に大きめに書いた。

気温の配列は、見た時間で意味が変わる

いちばん嫌な罠がこれ。temps配列は、発表時刻によって最低気温と最高気温が入る枠が入れ替わる。朝に取ったときと夕方に取ったときで、同じインデックスが違う意味を持つ。

対処は地道で、timeDefines(時刻の枠の定義)と突き合わせて「この枠は何の値か」を確認するしかない。SKILL.mdにもそう書いた。華麗な解決ではないが、確実な解決だ。

天気コードの話もついでに書いておく。先頭3桁が大分類で、100番台が晴れ、200番台がくもり、300番台が雨、400番台が雪。末尾2桁で「時々」「のち」「一時」みたいな変化を表す。細かい条件を自分で解釈するより、weathersの文字列(「晴れ 時々 くもり」みたいなやつ)をそのまま使う方が確実、というのが今の結論だ。

守りの部分が一番大事

このスキルでいちばん行数を割いたのは、実は取得方法じゃなくて失敗時の振る舞いだ。

• すべて気象庁の発表データそのまま。加工しない。発表時刻(reportDatetime)を必ず一緒に伝える
• curlには必ず-m 30くらいのタイムアウトを付ける。応答がないまま待ち続けない
• 壊れたJSON(HTMLのエラーページとか)が返ったら失敗として扱う。古いキャッシュを「最新」として渡さない
• どうにもならなかったら「気象庁のサイトで障害が起きている可能性があります。公式サイトを確認してください」と言う。推測で予報をでっち上げない

最後のやつは少し大げさに聞こえるかもしれないが、天気は釣りの予定から防災まで直結する。エージェントが「たぶん晴れです」と捏造するのは、黙って落ちるより悪い。

なお、警報・注意報や地震情報はjma-weatherの担当外にしてある。そっちはbosai-alertという別スキルが既にリポジトリにいて、気象庁の防災XMLの方を見ている。責務を分けたのは、予報と警報では更新頻度も緊急度も違うからだ。

おわりに

作ってみて分かったのは、「公開されている」と「そのまま使える」の間には思ったより距離がある、ということだ。気象庁のデータは無料で機械可読で、でも読み方の知識は暗黙知として散らばっている。その暗黙知をSKILL.mdという形に固めておくと、エージェントが初見でも迷わず動ける。

kurashi-skillは引き続き公開開発中。リポジトリはこちら → https://github.com/tahodev/kurashi-skill

誰かの明日の傘の判断にでも使われたら嬉しい。