Haruto Miyakawa
AIプロダクト

家電ガイド

自分が新人だったとき、商品知識がなくてお客様に迷惑をかけた。その失敗を、新人全員のために先回りして解いたアプリ。

Role
個人開発
体制
個人 (Solo)
種類
AIプロダクト
ステータス
公開PWA
スタック
Next.js, TypeScript,
Supabase, Gemini API 他
なぜ作ったか

家電量販店で働き始めたころ、商品知識が乏しく、お客様に正確な情報をスムーズにご案内できず、ご迷惑をおかけしてしまったことがありました。これは私個人の問題ではなく、新人スタッフのほぼ全員が通る道です。経験を積めばいずれ解決するとはいえ、その「いずれ」までの間にお客様を待たせ続けるのは違う。なら、知識の差を仕組みで先回りして埋められないか——その問いがこのアプリの出発点でした。

どう解いたか

管理者が商品の型番や URL を入力するだけで、AI がメーカーページからスペック・接客トーク・売りポイントを自動抽出し、スタッフのタブレットにリアルタイムで反映されます。スタッフ側は、接客トークの例、専門用語のわかりやすい言い換え、複数機種の横並び比較、そしてお客様の条件を聞きながら最適な一台を絞り込む「おすすめウィザード」を、接客のその場で使えます。新人でも、ベテランの知識を借りながらお客様の前に立てる状態をつくることを狙いました。

スタッフアプリの商品一覧画面。型番・メーカーで絞り込み、複数機種を選んで比較に進める
スタッフアプリの商品一覧画面。型番・メーカーで絞り込み、複数機種を選んで比較に進める
比較画面。複数機種のスペックを軸ごとに横並びにして、違いを一目で確認できる
比較画面。複数機種のスペックを軸ごとに横並びにして、違いを一目で確認できる
おすすめウィザード。お客様の条件を聞きながら回答すると、最適な一台と理由を提示する
おすすめウィザード。お客様の条件を聞きながら回答すると、最適な一台と理由を提示する
役割分担と、これが「最初の一歩」だった意味

個人開発です。そして、これは私が初めて本格的に作ったアプリでした。プログラミングを十分に学んでから着手したのではなく、現場で感じた課題が先にあり、それを解くために Claude Code との協働だけで開発を進めました。型番入力から AI 抽出、Supabase でのデータ連携、管理者アプリとスタッフアプリの二本立てまで——未経験の状態から実用を目指せるところまで到達できたこと自体が、AI と協働する開発スタイルの最初の証明になっています。そして次に述べる「AI に任せる処理と、コードで確定させる処理を切り分ける」という判断を私が初めて下したのも、このアプリでした。つまりこれは、私の技術判断の出発点です。

技術判断とトレードオフ

01AI 抽出とルールベース抽出を切り分けた — AI を過信せず、信頼できる所だけ任せた

最初はスペックの数値抽出も Gemini に任せていました。ところが「公式ページに値があるのに null になる」「非搭載の機能を搭載と誤って出力する」といった幻覚が頻発し、おすすめウィザードのスコアリングが正しく動きませんでした。原因を掘ると、オーブン温度調節範囲: 65〜250・300℃ から オーブン最高温度: 300℃ を取り出すような「ラベルの変換と値の解釈」を LLM に同時にやらせるのが不安定だと分かった。そこで役割を分離しました。数値・フラグといった確定的に決まるスペックはコードのルールベースで抽出し、接客トークや用語解説のような文章生成は Gemini に任せる。AI は万能の魔法ではなく、得意な所だけ使う道具だと割り切った——これが、この後のすべての開発で効く判断の原型になりました。

02AI に Gemini を選んだ — 用途に合わせてモデルを使い分ける

スペック抽出と接客トーク生成には Gemini 2.5 Flash を採用しました。大量の商品ページを処理するこの用途では、コストと速度が効くからです。さらに AI プロバイダーを抽象化し、環境変数ひとつで Gemini とローカル LLM(Ollama)を切り替えられるようにしました。開発中はローカルでコストをかけずに動作確認できます。(後に作った文章エディタ「つむぐ」では、逆に日本語の質を最優先して Claude を選びました。コア機能が何かで、最適な AI は変わる——その使い分けの感覚は、このアプリで AI と向き合った経験から来ています。)

03店頭で使うための PWA と、データを守る RLS

スタッフが店頭の iPad で使うことを前提に、PWA 対応にしました。ホーム画面に追加すればアプリのように起動できます。データ面では Supabase の Row Level Security を使い、書き込みは管理者のみ・スタッフアプリは読み取り専用に制限。強い権限を持つサービスロールキーはサーバーサイドの API でしか使わない構成にして、現場の端末から機密が漏れない設計にしました。

04メーカーごとにバラバラな公式サイトを吸収する多段フォールバック

現実のメーカー公式ページは、スペックの書き方も色展開の載せ方も各社バラバラです。たとえばカラーバリエーションの取得は、テーブル → 定義リスト → カラー選択 UI → 画像の alt テキスト → カラーコードのパターン、という順に複数の戦略で探しにいき、どこかで拾えるようにしました。メーカー公式に構造化されたスペック API があればそれを最優先で使う。「きれいに整ったデータは来ない」という現場の前提に、実装で対応した部分です。

現在地

自分の現場経験から作った、初めての本格的なアプリです。スタッフアプリ・管理者アプリともに継続的にバージョンを重ね、AI 抽出パイプライン・比較・おすすめウィザード・PWA まで実装しました。勤務先での正式採用は検討段階で、まだ本格運用には至っていません。利用実績を誇る段階の作品ではありませんが、現場で自分が感じた具体的な痛みを起点に、初めての開発で「AI をどこで使い、どこで使わないか」という判断にまで踏み込んだ——その意味で、私のものづくりの原点になっている一作です。

技術スタック
NNext.js 16 (App Router)
TSTypeScript 5
~Tailwind CSS v4
SSupabase (PostgreSQL + RLS)
GGemini 2.5 Flash
OOllama
VVercel

ご質問やご依頼など、お気軽にご連絡ください。