課題
ランナーにとって毎日の悩みは同じです。
- 今日は走るべきか
- 何を着るべきか
多くの天気アプリは気温や湿度、風速を表示するだけで、意思決定そのものはユーザー任せです。私自身、毎朝頭の中で計算して判断していましたが、外すことも多く、服装ミスや急な雨に悩まされていました。
どう作ったか
WeatherToRun の方針はシンプルです。
「生データを並べる」のではなく、「走る判断を返す」。
複数の気象要素を 1〜100 のスコアに統合し、色付きの評価（"悪い" / "普通" / "良い"）で即判断できるようにしました。
主な実装ポイント:
- 根拠あるスコアリング：温度・風・露点・降水・UV の重みを、ランニングへの影響に基づいて設計。
- Edge 実行：API を Vercel Edge Runtime で動かし、起動遅延を最小化。
- 多層キャッシュ：Edge キャッシュ + クライアントキャッシュ + 座標丸めでヒット率改善。
- 服装の個別最適化：「厚着寄り / 薄着寄り」の好み設定。
- PWA 対応：インストール可能、オフライン時も利用可能。
UI 設計
実装前に手書きで情報設計を行い、最優先情報を明確化しました。
- 走行スコア
- 服装提案
- 補足情報
この順序で、短時間で意思決定できる体験を作りました。
初期ワイヤーフレーム（メインビュー、構造、ユーザーフロー）。
オフライン対応
PWA では「全部キャッシュ」ではなく、リソースに応じた戦略が重要です。
- CacheFirst：静的アセット
- NetworkFirst：manifest
- NetworkOnly：ナビゲーションと RSC payload（整合性重視）
オフライン時には専用ページを表示し、ブラウザ標準エラーを避けました。
本番運用での工夫
障害対策
- 429 や一時的なネットワーク不調に バックオフ付きリトライ
- 天気と AQI でタイムアウトを分け、AQI 失敗時は機能を継続
データ鮮度
低トラフィック時に ISR だけでは更新が遅れるため、30 分ごとに再検証エンドポイントを叩く運用を追加。
revalidateTag('weather')で関連キャッシュを一括更新- stale-while-revalidate で初回表示速度を維持
学び
- ユーザー価値は「情報量」より「判断の速さ」にある
- 信頼性は目に見えないが UX に直結する
- Edge と正しいキャッシュ戦略の組み合わせは強力