菜单
登山対象の山の天気を、てんくらの登山指数 (A/B/C) ・気象庁の麓の天気・Open-Meteo の山頂標高指定の数値予報・標高差からの推定で判断する手順。 「○○山の天気」「登山の天気」「明日山に登れるか」「登山指数」「山頂の気温」などを聞かれた際に使う。 てんくらの登山指数は無料のサーバ HTML から取得でき、気象庁の麓・登山口周辺の気象と Open-Meteo の山頂標高指定の数値予報を併せて判断する。 山頂のピンポイント気象数値そのものは保証されないため、指数・麓の天気・数値予報・推定で総合判断し、その限界をユーザに伝える。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
指定ユーザ (主に自分自身) の Bluesky の情報を公開 API から取得する手順。直近の投稿内容・関心トピック・フォローしている人・フォローされている人を把握したい際に使う。「最近何を投稿したか」「旅行の写真を見たい」「誰をフォローしているか」「フォロワーは誰か」などが対象。フォロー先の傾向から関心分野を推し量る用途にも使う。 AT Protocol の公開 AppView (public.api.bsky.app) を認証なしで叩く。投稿は app.bsky.feed.getAuthorFeed、プロフィールと各種件数は app.bsky.actor.getProfile、フォロー/フォロワーは app.bsky.graph.getFollows / getFollowers を使う。画像はダウンロード後に ffmpeg でリサイズして表示する。 対象は公開情報のみ。いいね一覧など認証必須のデータの取得や、投稿・フォローの作成/削除はできない。
Discord の REST API を curl で叩いてサーバ (ギルド) を操作する手順。メッセージの送信・取得・検索、リアクション付与、スレッドの作成・名前変更、チャンネルやメンバーの一覧・検索が対象。「Discord にメッセージを送る」「チャンネルの発言を読む」「スレッドを立てる」「スレッド名を変える」「メンバーを検索する」などで使う。 bot トークンを Authorization の Bot ヘッダで渡し、 https://discord.com/api/v10 を叩く。トークンは環境変数 DISCORD_BOT_TOKEN から取る。メッセージ検索の API は bot に無いため、履歴を取得して jq でフィルタする。 対象は bot トークンで操作できる範囲のサーバ機能。レート制限 (429) は自前で Retry-After を見て待つ。ユーザ DM や OAuth が要る操作、Gateway (リアルタイム受信) は扱わない。
JARTIC (日本道路交通情報センター) が公開する渋滞「予測」データを取得する手順。ゴールデンウィーク・お盆・年末年始・行楽期の高速道路の渋滞予測、ピーク日時、◯◯祭りなどイベント周辺の一般道渋滞と迂回路を聞かれた際に使う。 `www.jartic.or.jp` の JSON を curl で取得し、路線名・年月・都道府県を `jq` で絞り込む。返るのは将来の予測であって現在の実況交通量ではない。今この瞬間の交通量・渋滞長を求められた場合はこの手順では取得できない。
指定の道路・エリアの現在の交通量を JARTIC 交通量 API (国土交通省) から取得する手順。「国道◯号の今の交通量」「◯◯付近の混雑」など、特定の道路や地点の最新交通量を聞かれた際に使う。 地名・道路名を国土地理院ジオコーディングで緯度経度へ変換し、WFS 2.0.0 GetFeature を BBOX と時間コードで叩く。対象は高速自動車国道と一般国道のみで、県道・市道は取得できない。
指定テーマの最新ニュースを優先ソースから N 件集め、各記事をタイトル・要約・公開日・個別 URL の形にまとめて返す手順。「バイクの最新ニュースを集めて」「セキュリティ分野の注目記事を要約して」「最近の登山界隈の動きをまとめて」のように、特定テーマの新着記事を収集して要約したい際に使う。 優先ソースに RSS/Atom があればフィードを先に取得し、無ければ一般 Web 検索で補う。期間と除外リストでフィルタし、件数分を選んで各記事を要約する。 出力はタイトル・要約・公開日・個別 URL の中立フォーマット。Discord 等への整形・投稿は呼び出し側で行う前提で、この skill には含めない。
ユーザの登山履歴・各山行のタイム・ペース、および登山計画 (予定行程) をヤマレコ (yamareco.com) から取得する手順。登山計画の所要時間予測や、過去実績からのペース倍率の集計、ヤマレコに登録済みの計画の予定行程・距離・累積標高の確認を求められた際に使う。 山行リスト・計画リストは API、個別山行および個別計画の詳細は公開設定のもののみ HTML から抽出する。
| name | mountain-weather |
| description | 登山対象の山の天気を、てんくらの登山指数 (A/B/C) ・気象庁の麓の天気・Open-Meteo の山頂標高指定の数値予報・標高差からの推定で判断する手順。 「○○山の天気」「登山の天気」「明日山に登れるか」「登山指数」「山頂の気温」などを聞かれた際に使う。 てんくらの登山指数は無料のサーバ HTML から取得でき、気象庁の麓・登山口周辺の気象と Open-Meteo の山頂標高指定の数値予報を併せて判断する。 山頂のピンポイント気象数値そのものは保証されないため、指数・麓の天気・数値予報・推定で総合判断し、その限界をユーザに伝える。 |
登山対象の山の天気を、登山指数・麓の気象・山頂標高指定の数値予報・標高差からの推定で総合的に判断する手順。
山頂のピンポイントな気象数値そのものは一般に保証されないが、判断材料となる指標は無料で取得できる。
| ソース | 取得方法 | 中身 | 山頂相当か |
|---|---|---|---|
てんくら (tenkura.n-kishou.co.jp) | fetch-index script (無料のサーバ HTML) | 登山指数 A/B/C (今日・明日は時間帯別、約 1 週間分)、気圧面ごとの気温・風 | 山ごとの独自指数 (山頂を含む予報ベース) |
| 気象庁 (JMA) | curl + jq (無料の JSON) | 麓・登山口を含む細分区の天気・風・降水確率、麓のアメダス地点の気温 | 麓・地域レベル |
Open-Meteo (api.open-meteo.com) | fetch-openmeteo script (無料の JSON API) | 山頂標高指定の気温・湿度・風・突風・降水・降水確率・凍結高度・天気コード (1 時間ごと、最大 7 日) | 標高補正済みの NWP (数値予報) 値 |
判断の主軸はてんくらの登山指数とし、気象庁で麓の実データを、Open-Meteo で山頂標高指定の数値予報を併せて見る。
wind_gusts_10m) やてんくらの気圧面風と比べて強い側を採る。山の気象判断は安全に直結する。指数・気温・天気を実際より楽観的に (良い指数・暖かい・穏やか) 報告した結果、ユーザが軽装・強行で入山して事故った場合の被害は甚大である。次のガードレールを必ず守る。
登山指数 (A/B/C) の取得・抽出は scripts の fetch-index に、山コードの検索は find-mountain に集約してある (後述)。kad.html ・ kasel.html を手で curl ・ iconv ・ grep して自前パースしない。この禁止は登山指数・気温・風の抽出に限る。山の同定のために kad.html の標高・近隣市町村の表記を手で確認するのは可 (次節)。
登山指数はてんくらの公式定義で「登山をするための快適さを、山頂や山麓の気象条件から気象学的知見を用いてレベル値で表現した指数。降水量・風速・雲量などを総合的に考慮して独自計算したもの」とされる。数値の気象要素そのものでなく指数として出すのは、気象業務法により無料での山の天気予報の掲載が禁じられているためで、指数は山頂の予報から算出した目安にすぎず、山頂の実況気象そのものではない。
指数の性質は運営元への取材記事 (https://yamahack.com/4594) で次のとおり補強されている。読み違えると楽観に倒れるので判断に織り込む。
対象の山の名前から、てんくらの山コード (kad.html?code= の数値) を find-mountain で引く。skill 内のキャッシュ (assets/tenkura-mountains.json。全 9 地域の山リスト kasel.html から生成済み) を検索するのでネットワーク不要。
# $SKILL_DIR はこの skill のディレクトリ (配布先では .claude/skills/mountain-weather)
# -q はタスクランナーのバナー抑止 (出力を jq 等で機械処理するため。全 scripts 共通)
deno task -q --cwd "$SKILL_DIR/scripts" find-mountain --name=旭岳
# => {"matches": [{"code": "01150010", "name": "大雪山・旭岳", "ba": "hk", "pref": "北海道"}, ...]}
検索は部分一致。0 件のときは exit 1 で止まるので、--update でキャッシュを取り直してから再判断する (山リストの更新頻度は低いが、新規追加・改名はありうる)。--update はスクリプトが各エントリの ba echo を照合し、CDN キャッシュによる別地域の混入を弾く。
pref はコード先頭 2 桁の都道府県。地域は ba (hk 北海道/th 東北/kk 関東・甲信/hr 北陸/tk 東海/kn 近畿/cg 中国/sk 四国/ks 九州・沖縄)。
同名の山が複数あることがある (例: 別の山域の同名峰。「旭岳」は北海道と福島県の両方に居る)。pref や標高で対象を確定する。find-mountain の出力は標高を持たないので、同県に同名の山頂候補が複数あるときは kad.html (https://tenkura.n-kishou.co.jp/tk/kanko/kad.html?code=<code>&type=15) を取得し、ページ表記の標高・近隣市町村で確定する (Shift_JIS。iconv で UTF-8 化して見る)。一意に定まらなければユーザに確認する。憶測で 1 つに決めない。候補をユーザに提示するときは、pref ・ code を識別キーとして列挙し、通称への変換は推測しない。
リストには山頂以外の地点も混じる (赤岳鉱泉 赤岳山荘 旭岳石室 など)。名前が 山荘 ・ 小屋 ・ ヒュッテ ・ 石室 ・ 鉱泉 ・ 温泉 などの施設語で終わる項目は山頂候補と分けて扱う。同じ山に 富士山山頂 ・ 富士山北麓5合目 ・ 富士山吉田口8合目 のように複数の地点エントリがあるときは、山頂の気象判断には 山頂 を含むエントリを主に使う。 合目 ・ 北麓 ・ 登山口 ・ 施設語・ルート名などのエントリは登山口側のクロスチェック用で、山頂の指数・気温には使わない。対象の山に 山頂 エントリが無く施設・登山口エントリしか無いときは、最も山頂に近い 1 つ (施設語で終わらない山名そのものの項目) を採り、山頂の値は推定である旨を強めに添える。
登山カテゴリ (type=15) は find-mountain のキャッシュ生成に固定してある。観光・桜など別カテゴリの地点は混ざらない。
県境・独立峰の山はてんくらのエントリが登山口と別の県・別の ba に入ることがある (例: 富士山は ba=kk ・コード先頭 19 = 山梨だが登山口は静岡)。 ba は省略でき code + type=15 で直に引けるので、コードが分かれば ba に依存しない。
リスト (kasel) の CDN キャッシュによる別地域の混入は、find-mountain --update がエントリの ba echo 照合で機械的に弾く。手で kasel.html を取得して照合する必要はない。
山のコードが決まったら fetch-index で取得する。ba は不要で code と type=15 (既定) だけでよい。
# --code は前節 find-mountain で引いた対象の山のコード (下の 01150271 は別の山 = 青山の例。必ず引き直す)
deno task -q --cwd "$SKILL_DIR/scripts" fetch-index --code=01150271
スクリプトは取得・Shift_JIS デコード・キャッシュ照合・検証・抽出を一括で行い、今日・明日 (時間帯別) と週間の登山指数・気温・風を JSON で出力する。内部動作 (デコード・キャッシュ回避の突き合わせ・検証) は scripts/README.md。
出力の tables[] は tit_day 見出し 1 つ = 1 テーブル。kind が timeband (今日・明日、時刻列) か weekly (週間、日付列) か。各テーブルは次を持つ。
columns: 時刻 (00,03,...) または日付 (7/5(日),...)。index: 各列の登山指数 A/B/C (mnt1/2/3.gif→A/B/C。A が登山に適、C が不適)。null は過去時間帯 (表示なし) か予報範囲外 (週間の最も先)。欠測ではないので補完しない。指数と時刻・日付は同じ列インデックスで対応する。levels: 気圧面 (hPa) ごとの temp (℃) と wind (dir 16 方位・ms m/s)。過去・範囲外は null。出力を読むときの判断 (呼び出し側の責務)。
levels[].hPa を都度読む。ハードコードしない)。高度の目安は 950hPa が約 500m、925hPa が約 760m、850hPa が約 1500m、800hPa が約 2000m、700hPa が約 3000m、600hPa が約 4400m。この早見表は概算のフォールバックにすぎない。各気圧面の高度は levels[].alt (例: 高度3100m付近) に実値が入るので、実値が正本。早見表と食い違えば実値を採る。次の 3 ケースは排他で、どれか 1 つだけが当てはまる。 (a) 山頂が表示中の最下面より低い → 山頂標高に最も近い気圧面の値を使う。 (b) 山頂が表示 2 面の間に挟まれる → その 2 面を内挿した値と、直下の面から逓減率で山頂高度まで外挿した値の両方を算出し、寒い側を採る (どちらか一方に決め打ちしない)。 (c) 山頂が表示中の最上面よりさらに上 → 最上面を基点に「4. 山頂気温の概算」の逓減率で山頂まで再外挿する。いずれも確証が持てなければ寒い側 (高い気圧面 = 低い気温) に倒す。timeband) は 3 時間ごと、週間 (weekly) は当日 9 時予想の単一値。ユーザが「週間」「今週」を求めた場合は両方を統合して提示する (週間だけでは当日・翌日が欠ける)。対象日が weekly 部にしかないとき (今日・明日より先) は、てんくらの指数・気温については当日 9 時予想の単一値で日内変動が取れない旨を必ず添える (この限界はてんくらのデータに限る。気温・天気・風の日内変動そのものは Open-Meteo の 1 時間値で補える。風は突風 wind_gusts_10m を強い側の照合に使う。登山指数の時間変化だけはどのソースでも補えない。この書き分けを回答に反映する)。timeband の複数列 (時間帯) を 1 つの代表値に縮約するときは、登山の行動想定時間帯の列を採る (時刻が未指定なら日中を既定とする)。ただし対象の山に夜間・早朝行動が慣行的な場合 (富士山のご来光登山など) は、その冷える時間帯も安全側の代表に含めるか、行動時間帯をユーザに確認する。日中だけを見て夜間の寒さを落とさない。その範囲では指数の悪い列・気温の寒い列・風の強い列を安全側で選ぶ。山頂気温の内挿・外挿は同一時刻の鉛直 2 点で行う (別々の時刻の最寒値を混ぜない)。行動時間帯の各時刻で山頂気温を出し、その中で最も寒い時刻を安全側の代表として採る。時間帯で振れが大きいとき (例: 夕方に指数が C へ急落する) は最悪の時間帯を必ず併記し、良い時間帯だけで代表させない。推定気温は単一の点でなく、寒い側を下限とする幅で示す (内挿値〜逓減率を大きめに取った外挿値のレンジ。代表値は最寒側)。細かい方式選択 (逓減率 0.6〜1.0 のどこ、内挿か外挿か) は運用判断でよく、常に寒い側に倒して幅で伝えれば足りる。heading (今日7/3(金) 等) で確定する。先頭 = 今日と決め打ちしない (夜遅くは今日分が落ち先頭が明日になる)。grep -A/-B/-C) で取らない。日付行と指数行は別々の <tr> で、行近接は指数行の先頭列を別日と取り違える (例: grep -A5 '7/3' が 7/1 の指数を 7/3 の指数と誤読する)。スクリプトはこれを列インデックスで対応づけている。スクリプトを使わず自前で解析する場合も、必ず列位置 (日付行の N 列目と指数行の N 列目が同じ日) で取る。fetch-index が exit 1 で停止したら値を捏造しない。停止理由 (登山指数 0 件 = type 誤りや HTML 構造変化、code 不一致 = CDN が別ページを返した、テーブル抽出 0 件) を報告し、必要なら scripts・skill を更新する。code= と alt="登山指数" で取得物を照合し、cache-bust の 2〜3 回取得で CDN の別版・古い版 (日付ヘッダ・指数 gif・気圧面の fingerprint 不一致) を弾く。それでも title・近隣市町村名が対象の山と合うかは最終的に人が確認する。別の山・別県のデータを山頂判断に使うのは危険。heading と columns の並びが妥当か確認し、ずれを疑ったらユーザに提示して確認する。scripts/cli/parse.ts とこの skill を更新する。てんくらの指数に加え、麓・登山口周辺の実データ (天気・気温・降水確率) を気象庁から取る。気象庁の予報は気象台 (都道府県) 単位で、その中の細分区 (北部・南部・山沿いなど) に分かれる。
DANGER (実行): forecast の取得から照合・値の抽出までを 1 つの Bash 呼び出しにまとめる。エージェントのシェルはコール間で cwd・変数・mktemp -d のパスが失われるため、取得と抽出を別の Bash 呼び出しに分けると一時ファイルを見失って取り直しになる。実行時は mktemp -d で作った 1 つのディレクトリを使い、forecast 取得・照合・抽出を同一コマンド内で連結する。細分区・office の解決はネットワーク不要の find-area (次節) で先に済ませてよい。
どの細分区かは地理勘で決めず、登山口の市町村名から決定的に引く。find-area が skill 内のキャッシュ (assets/jma-area.json。気象庁 area.json から生成済み) を使い、class20s (市町村・地区レベル) → class15s → class10 (細分区) → office (気象台) の parent 連鎖を辿る。ネットワーク不要。
# 登山口の市町村・地区名 (例: 富士宮市、松本市乗鞍上高地) から細分区と気象台を引く
deno task -q --cwd "$SKILL_DIR/scripts" find-area --municipality=富士宮市
# => {"matches": [{"class20": {"name": "富士宮市", ...}, "class10": {"code": "220030", "name": "東部"}, "office": {"code": "220000", "name": "静岡県"}}]}
0 件のときは exit 1 で止まる。より広い市名・近隣地名で引き直し、市町村合併等でキャッシュが古い可能性があれば --update で取り直す。
細分区名は都道府県ごとに異なる (北部・南部、内陸・沿岸、南部山沿い・北部平野部など)。固定の名前を決め打ちせず、必ず上の方法で登山口の市町村から細分区を引く。
class20s の地区名は細かい (例: 松本市乗鞍上高地)。登山口に対応する地区語で引くと精度が上がる。市町村名でヒットしないときは、より広い市名や近隣地名で引き直す。
てんくらが表示する「近隣市町村」は山頂位置基準で選ばれ、登山口と一致しないことがある。気象庁の細分区・アメダスは必ず登山口の実所在地から独立に引き、ソース間で地点が違えば回答に明記する。
登山口が複数県にまたがる山 (例: 富士山の吉田口 = 山梨と富士宮口 = 静岡) でルートが未指定の場合は、主要登山口を複数併記するか、ユーザにルートを確認する。1 つの登山口に決め打ちしない。
山沿い・内陸の区分がある県では、山に近い区を優先する。平野部の天気は山と乖離しやすい。
北海道は気象台が複数に分かれるので、登山口を管轄する office を選ぶ。
# mktemp -d で実行ごとに一意なディレクトリを作る (固定パスは並行タスクと衝突する。「注意」参照)
tmpdir=$(mktemp -d)
curl -sS 'https://www.jma.go.jp/bosai/forecast/data/forecast/200000.json' -o "$tmpdir/forecast.json"
配列は 2 要素で [0] が 3 日予報、[1] が週間予報。[0].timeSeries は 3 本あり区分単位が異なる。
| timeSeries | 内容 | 区分単位 |
|---|---|---|
[0] | 天気 weathers ・天気コード weatherCodes ・風 winds | 細分区 (class10) |
[1] | 降水確率 pops | 細分区 (class10) |
[2] | 気温 temps (最低・最高) | アメダス観測地点 (麓の地点) |
天気・降水確率は細分区単位だが、気温だけはアメダス地点単位で粒度が違う。気温を細分区から探すと空振りする。3 日予報の temps は timeDefines の 00 時が最低・09 時が最高に対応するのが通例だが、位置に意味を決め打ちせず、週間予報側の tempsMin/tempsMax と突き合わせて解釈を確認する。
# 天気・風 (細分区コードで絞る。例: 中部 200020)
jq '.[0].timeSeries[0].areas[] | select(.area.code == "200020") | {area: .area.name, weathers, winds}' "$tmpdir/forecast.json"
# 降水確率
jq '.[0].timeSeries[1].areas[] | select(.area.code == "200020") | {area: .area.name, pops}' "$tmpdir/forecast.json"
# 気温 (アメダス地点。登山口に最も近い地点を名前で選ぶ)
jq '.[0].timeSeries[2].areas[] | {name: .area.name, temps}' "$tmpdir/forecast.json"
timeSeries の timeDefines で必ず確認する。配列の index に意味を決め打ちしない (取得時刻によって入る要素が変わる)。[0] 内でも系列ごとに終端日が揃わない (深夜取得では weathers に翌日があっても pops/temps が当日までのことがある)。目的日の値が timeDefines に無ければ週間予報 [1] へフォールバックし、県単位・遠隔地点の参考値である旨を必ず併記する。フォールバック要否は抽出後にしか分からないため、初回の同一コマンド内で 3 日予報 [0] の weathers・weatherCodes・winds・pops・temps と、週間予報 [1] の weatherCodes・pops・temps を無条件に抽出しておく (後から要ると分かって取り直さない。[0] の weathers・weatherCodes は後述の天気コード和名照合にも使うため必ず初回リストに含める)。publishingOffice と areas[].code の先頭桁が要求した office と一致するか確認し、不一致なら (キャッシュ等で別府県を掴んでいる) 取り直す。別県の予報を山頂判断に使うと危険。取り直すときはクエリ文字列 (例: ?_=1) を付けるか -H 'Cache-Control: no-cache' で CDN キャッシュを回避する。[1]) は粒度が落ちる。 weather・降水確率が細分区ではなく office (県) 単位、気温がアメダス少数地点になり、登山口近傍の細分区・地点が得られないことがある。時間粒度も落ち、降水確率・天気は日単位の代表値になる (時間帯別は取れない)。その場合は県単位・遠い地点・日単位の値だと明記して参考扱いにする (地点粒度と時間粒度の両方の低下を併記する)。最寄りアメダスの目的日の値が取れないときは、同地点の当日・直近日の値を「別日の参考」とラベルして添えてよい (目的日の値の代用にはしない)。3 日予報と週間予報の両方に同一日・同一対象の値があって食い違う場合も、ソース間の食い違いと同じ原則 (危険側を採り両方併記) で扱う。publishingOffice・area.code が正しい県でも、気温 timeSeries[2] のアメダスだけ別県が混入することがある (office・code 照合では気温の県跨ぎを検出できない)。気温地点名が対象県の地点か照合し、県外の地名が出たらキャッシュを回避して取り直す。別県の気温で山頂を概算するのは危険。[0].timeSeries[0].weathers (日本語文字列) で同コードの意味を確認する。週間部だけに出るコードが [0] に無いときは、コードの百の位 (2xx = くもり系・3xx = 雨系・4xx = 雪系) で安全側 (降水・降雪あり前提) に解し、ピンポイントの和名は断定しない。weathers/weatherCodes に雷 (「雷」の語・コードの一部) が出たら、時間帯と併せて必ず強調する。ピンポイントの天気マークに出ていなくても、周辺の細分区・広域の概況に雷傾向があれば急変の兆候として扱う。山頂の緯度・経度・標高を指定した数値予報を Open-Meteo (api.open-meteo.com) から取る。キー不要・非商用無料の JSON API で、elevation に山頂標高を渡すと 90m DEM ベースの標高補正が適用された値が返る。取得・検証は scripts の fetch-openmeteo に集約してある (内部動作は scripts/README.md)。
# 例は富士山頂 (3776m)
deno task -q --cwd "$SKILL_DIR/scripts" fetch-openmeteo --lat=35.3606 --lon=138.7274 --elevation=3776
--lat ・ --lon ・ --elevation (いずれも必須。標高は山頂の m)。--days は任意 (既定 3、最大 7)。timezone は Asia/Tokyo、風速単位は m/s に固定してある。hourly[]) で、気温・湿度・風速・突風・降水量・降水確率・凍結高度 (freezing_level_height)・天気コードを持つ。単位は units に入る。elevation が指定値と一致することを検証する。不一致・HTTP エラー・error: true のレスポンスは exit 1 で停止する。停止したら値を捏造せず理由を報告する (取得失敗時は止めて報告する原則)。https://cyberjapandata2.gsi.go.jp/general/dem/scripts/getelevation.php?outtype=JSON&lon=<経度>&lat=<緯度>) に候補座標を渡し、返る標高が対象の山頂標高と数十 m 以内で一致することを確認してから使う。大きくずれる座標は山頂を指していない。レスポンスの latitude/longitude はモデル格子に丸めた値が返るが、elevation は指定値がそのまま echo される (これを検証に使う)。weather_code は WMO コードの数値のまま出る (スクリプト側で和名変換しない)。大まかな系列 (0〜3 = 晴れ〜くもり、45/48 = 霧、5x = 霧雨、6x = 雨、7x = 雪、8x = にわか、95 以上 = 雷雨) で安全側に読み、細かい和名の断定はしない。95 以上 (雷) が出たら時間帯と併せて必ず強調する。freezing_level_height (凍結高度) が山頂標高を下回る時間帯は山頂付近が氷点下になりうる。防寒・凍結・降雪のリスクとして必ず伝える。逆に凍結高度が山頂より上でも、直接値の temperature_2m が氷点下ならそちらを採って氷点下として扱う。直接値と派生指標が食い違うときは常に寒い・危険側を採る。降水の相 (雨か雪か) は weather_code を正とし、凍結高度は補助に留める。両者が矛盾するとき (凍結高度が山頂より上なのに雪コードが出る等) は雪・凍結側 (危険側) で伝える。weather_code が食い違うとき (量 0 なのに確率が高い等) も危険側で読む。確率が高ければ量 0 でも「降りうる」前提で伝え、雨具・行動打ち切りの判断材料に含める。wind_speed_10m は地形加速が載らず過小になりうるため参考値に留め (「限界をユーザに伝える」参照)、wind_gusts_10m は強い側の照合に使う。体感補正・行動判断は各値の強い側を採る。山頂気温は前節 Open-Meteo の標高指定値を主とする。山頂標高そのもので補正した 1 時間ごとの値が取れるため、気圧面からの内挿・外挿や麓からの概算より直接的である。ただし数値予報の生値であり山頂の実測ではない (「限界をユーザに伝える」参照)。てんくらの気圧面気温と食い違えば寒い側を主に置く。この比較は同一時刻の値同士で行う (てんくら週間部の 9 時単一値と比べるなら Open-Meteo も同日 9 時の値を使う。行動時間帯の代表値の選定はその後に別途行う)。単一時刻でしか比較できない場合、その時刻で観測した乖離を他時刻へ定数として展開しない。乖離の事実は「他の時刻も同程度ずれる可能性がある」という幅の悪い側の注記としてのみ反映する。Open-Meteo が正常に取れているとき、気圧面からの内挿・外挿はクロスチェック専用で、回答の主数値には使わない。提示する幅は主ソース内の不確実性 (時間帯の振れ・逓減率の幅) で構成し、ソース間の乖離が大きいときは乖離を幅に混ぜて広げず、寒い側ソースの値を代表・幅として他ソースの値は「別ソースでは X ℃」と注記で併記する。「乖離が大きい」かの判定は標準逓減率 (0.6) での推定値と主ソース値の差で測り、迷ったら閾値の議論で止まらず寒い側を代表にする。クロスチェックの計算は行動時間帯内の代表 1〜2 時刻で足りる (全時刻分は不要)。行動時間帯の既定と安全側の列の選び方は「1.」の timeband 縮約規則と共通で、Open-Meteo の 1 時間値の縮約にも同じ規則を適用する。乖離を検出したら比較できていない時刻も「同程度ずれる可能性」として幅の悪い側の注記に反映し、代表に採った時刻が比較できた時刻と異なるときはその旨 (比較は 9 時のみ等) を添える。
Open-Meteo が取得できない場合 (API 停止・ネットワーク断・fetch-openmeteo が検証不一致で停止した場合) は、次の標高差からの概算にフォールバックする。てんくらが上空の気温を出すが、取れない場合や麓のデータしかない場合も同様に標高差から概算する。いずれも推定であり山頂の実測ではない。危険側に倒し、下振れに丸めない。なお、てんくらの上空気温は参照気圧面の値 (例: 800hPa は約 2000m) で、山頂標高より低いことがある。その場合はてんくら上空気温を基点に、下式で山頂標高まで再外挿する。
標高が 100 m 上がるごとに気温は約 0.6 度下がる (気温逓減率)。
山頂気温の概算 = 麓の気温 - 0.6 × ((山頂標高 - 基点標高) / 100)
https://www.jma.go.jp/bosai/amedas/const/amedastable.json、地点名 kjName・標高 alt) で引ける。引けないときは 0m とみなしてよいが、その簡略化と向き (山頂側の概算が涼しく出る) を回答に明記する。pref・標高・慣行) から安全側に仮確定して進め、採った仮定と識別キー (code・pref 等) を回答に必ず明記する。複数の解釈が同程度に成り立つ場合は全候補を併記する。deno task -q で行う。-q が無いとタスクランナーのバナー行が stdout に混ざり、jq 等での機械処理が壊れる。forecast.json) は mktemp -d で実行ごとに一意なディレクトリを作りその中へ置く (固定パスは並行タスクに上書きされ、別対象のデータを掴む事故が起きる)。後続の jq も同じ絶対パスを参照し、照合と値の抽出は同一コマンド内で行う。山コード検索 (find-mountain)・区域解決 (find-area)・てんくら取得 (fetch-index)・Open-Meteo 取得 (fetch-openmeteo) は script が一括で行うので一時ファイルを手で持たない。find-mountain・find-area が --update しても 0 件/fetch-index が登山指数 0 件で停止/fetch-openmeteo が elevation 不一致で停止/forecast の構造が変わる等) は値を捏造しない。処理を止めて報告し、scripts・skill を更新する。