前回の記事はこちら：
はじめに
前回の記事「Chromebookとスマホだけで冷蔵庫管理アプリを作ってみる -環境構築・詰まりポイント編-」では、Phase 1として「レシート撮影 → Gemini解析 → Supabase保存」までの核心ロジックが動くところまでを紹介しました。
今回はPhase 2、実際に冷蔵庫の中身を確認する画面（ダッシュボード）を作った話と、その過程で出てきた詰まりポイント・設計判断をまとめます。
この記事はこんな方におすすめ
- 前回記事を読んでくれた方
- Supabaseにテーブル列を追加しながら開発を進めたい方
- AIに読み取らせたデータの「粒度」で悩んだことがある方
- AI駆動でUIデザインまで作ってみたい方
実際に作ったもの
Phase 2で実装したのは、次の4つです。
- 賞味期限の推定ロジック：カテゴリごとの目安日持ち日数から、購入日基準で残り日数を計算する部品を実装
- 冷蔵庫一覧ページ：保管食材と即食食材を分けて表示し、保管食材だけ優先度（そろそろ消費／まだ余裕あり）を表示
- 個数管理：レシートから個数も読み取り、1個ずつ「消費」できるボタンを実装
- 非食品の判定：レジ袋などをtypeで分類し、一覧には出さず、金額データとしては保持
トップページと冷蔵庫一覧ページを行き来できる共通ナビゲーションも作り、今後ページが増えても対応できる形にしました。
ハマりポイント集
複数ファイル同時編集でのコピペミス
ナビゲーションを共通化する際、import Nav from "..."という行を、うっかりJSXの中（画面表示部分）に貼り付けてしまい、構文エラーでビルドが失敗しました。
Parsing ecmascript source code failed
というエラーが出て、原因を探ったところ、importはファイルの一番上に書くべきなのに<main>タグの中に紛れ込んでいました。さらに同時にもう1ファイルも編集していたため、関数の途中の行が欠けてコードの形が崩れてしまうという二重のミスも重なりました。
複数ファイルを同時に触るときほど、1ファイルずつ保存→確認を挟んだ方が結局早い、という学びでした。
同名ファイルで迷子になった話
app/page.tsx（トップページ）とapp/fridge/page.tsx（冷蔵庫一覧）、両方とも同じ「page.tsx」という名前で、どちらを編集しているのか分からなくなる場面がありました。
これはファイル構成をAIに丸投げして、自分では特に意識していなかったことが根本の原因です。同じファイル名だと混乱するなんて当たり前なんですが笑。
あとから振り返って気づいたのですが、「ファイル名は役割が分かるようにしてほしい」「同名ファイルを作るときは事前に教えてほしい」といったことを、最初にAIへ一言伝えておけば防げた混乱でした。次回以降は、ファイル構成に関する希望も先に伝えておこうと思います。
設計判断：レジ袋は「除外」でいいのか
Geminiにレシートを読み取らせていると、レジ袋のような食材ではない項目まで一緒に読み込まれてくることに気づきました。最初は単純に「除外」しようとしたのですが、一呼吸置いて考え直しました。
- 冷蔵庫の中身一覧には出したくない（食材ではないので）
- でも家計簿機能（食費の合計を出す予定）には含めたい（実際に払った金額なので）
「除外」してしまうとデータごと消えて家計簿の金額もズレてしまうので、Geminiの分類にnon_food（非食品）という区分を追加し、一覧表示だけ出し分けるという設計に落ち着きました。データは残しつつ、見せ方だけ制御する、というのが今回の解決策です。
AIに「除外して」と一言で頼むのは簡単ですが、その後ろにある「このデータを最終的に何に使うか」を考えないと、後で困る設計になりかねないと実感した場面でした。
デザインの方向性：レシート風UI
機能が一通り揃ったタイミングで、見た目も整えました。正直デザインに強いこだわりがあったわけではなく、「見やすくなればいい」くらいの温度感でAIに任せたところ、こういう提案が返ってきました。
- よくあるカード＋丸角＋影のSaaSアプリ風ではなく、紙のレシートの明細っぽい見た目
- 点線区切りでアイテムを並べる（レシートの罫線を意識）
- 金額や個数だけ等幅フォントにして、レシートの印字っぽさを出す
- 見出しは明朝、本文はゴシックで温かみを出す
- 状態表示は🟢/⚠️のような絵文字ではなく、色付きの左ボーダー＋短いラベルに統一
「レシートを撮って管理するアプリ」というコンセプト自体をUIのトーンにも落とし込んだ提案で、任せてみたら想像より馴染みが良かったです。
まとめ
Phase 2では、機能を作ること自体よりも「AIに読み取らせたデータをどう分類し、どう見せるか」という設計判断に時間を使った回でした。レジ袋の扱いのように、一見小さな判断でも後々の機能（家計簿）に響いてくるので、都度立ち止まって考える価値があると感じています。
もう一つ実感したのは、最初は仕組みも用語もほとんど分かっていなかったのに、機能を追加したり修正したりを繰り返すうちに、なんとなく「今、自分が何をやっているのか」が見えてくるということです。知識として学んでから作り始めたわけではなく、手を動かしながら後から理解が追いついてくる感覚でした。
次はPhase 3、期限が近い食材を使ったレシピ提案と、食費・食品ロス額を可視化する家計簿機能に進む予定です。
次回の記事はこちら：