カサいる？の服装アドバイスを作るとき、最初のコードは単純だった。気温をそのまま受け取って「25℃は過ごしやすい気温です。軽めのジャケットやカーディガンがおすすめです」という固定文を返すだけ。
でも使ってみると、それだけでは「今日の自分の通勤」の判断にならないとすぐわかった。
何が足りなかったか
服装の判断に必要な情報は気温だけではない。いくつかの要素を整理した。
最高気温だけでなく最低気温も必要
→ 朝と夕方の気温差が10℃以上ある日は全然違う判断になる
季節感も必要
→ 同じ25℃でも5月（まだ春）と9月（残暑）では感じ方が違う
傘判定との連携も必要
→ 雨が降るなら濡れることを前提にした服装になる
これらの要素を組み合わせて処理する関数 getClothingSuggestion() を設計した。複数の気象データを受け取り、服装ラベルと短いアドバイス文を返すアプリ内のローカル関数だ。
6段階の気温区分を設けた理由
最初は気温の数値を直接条件分岐に使っていたが、アドバイスの安定感に欠けた。25℃と26℃で微妙に違う文章が出たり、境界付近の挙動がちぐはぐになる。
安定させるために気温を6つのカテゴリに区分した。
30℃以上 → 「暑い」（熱中症への言及あり）
25〜29℃ → 「夏日」（日差し・熱対策）
20〜24℃ → 「過ごしやすい」（基本の春秋スタイル）
15〜19℃ → 「肌寒い」（重ね着を推奨）
8〜14℃ → 「寒い」（アウター必須）
8℃未満 → 「極寒」（コート・マフラー）
気温の数値ではなくカテゴリ名をロジックの入力にすることで、近い気温でも一貫したトーンのアドバイスが出るようになった。
寒暖差アラートの仕組み
朝と夕方の気温差が10℃以上の場合、getClothingSuggestion() 内で「寒暖差フラグ」を立てる。このフラグが立つと、アドバイス文に「朝はXでも夕方はY」という構造の一文が付加される。
「朝半袖で出て夕方凍える」という失敗を防ぐための仕組みだが、コードとしては非常にシンプルだ。「問題のある条件」をフラグとして明示し、フラグに応じてテンプレートを切り替えるだけ。シンプルなルール設計でも、ユーザーの体験上は十分に機能する。
設計で悩んだのは、「どこまでコードのルールで書いて、どこから自由なアドバイス文にするか」という境界だった。最終的には気温カテゴリ×傘判定×寒暖差フラグの組み合わせで出力を決め打ちにしている。パターン数は限られるが、毎朝の通知として読む文章には「安定した言葉」の方が向いていると判断した。
気温の数字を「言葉」に変換することは、見かけよりも少し複雑だった。でもそのひと手間が、「数字を読んで自分で考える」よりも楽な朝をつくっていると思っている。