チリに来て、ゼロから始めました（いつかその話も書きたいと思います）。スペイン語が話せなかった私は、チャイナタウンに目を向けました。そこで、ずっと前に聞いた言葉の意味を本当に理解しました。商品は棚から生えてくるわけではない、ということです。
店主たちとしばらく話すうちに、このあたりの多くの店の運営スタイルが分かってきました。卸と小売を兼ねた実店舗です。
日々、検品、整理、陳列、発送、倉庫管理、補充をこなします。まだ軌道に乗っていない店は、さらに写真撮影、商品情報の入力、オンライン運営、顧客管理まで自分でやらなければなりません。
これはちょうど私の得意分野でした。そこで、卸売の事業が軌道に乗りつつあるのに、オンラインの卸チャネルを開けずに困っていた店と組み、neo-studio プロジェクトを始めました。
以下では、主にプロダクトの視点から紹介します。
S · Situation：雑貨店の「出品」問題
店では本当にいろいろなものを売っています。鍋や食器、靴下、傘、香水、文房具……。入荷のたびに大量の新商品を出品する必要があり、ここでの「出品」にはオンラインも含まれます。
出品作業は、とにかく細かくて面倒です。
- 入力：品番、バーコード、品名（中国語とスペイン語それぞれ）、仕様、ケース入数を、1点ずつ記録します。
- 撮影：カウンターで気軽に撮るので、背景は散らかった机、光も安定しません。そのままではお客様に見せられません。
- 配信：同じ商品を何か所にも入力します。WeChat の友購（Yougou）ショップ、Facebook / Instagram のショップ、自社サイト、そして店内の ERP です。
- ピッキング：スタッフがピッキングリストを見ても商品が見つからないことがあります。リストの写真が小さく、棚の位置情報もないためです。
どの工程も難しくはありませんが、合わせると1回の入荷で何時間もかかります。データはあちこちに散らばり、撮影後にはデータと照らして整理し直す必要があり、価格を1つ変えるだけで何か所も修正することになります。
T · Task：自分に課した目標
欲しかったのは「もっと使いやすいスプレッドシート」ではなく、一連の流れ全体をつなぐことでした。
- 入力が速い：スタッフが自分のスマホでスキャンと撮影をするだけ。複数人で同時に入力でき、専用のバーコードリーダーは不要です。
- 画像がきれい：多くの店には、プロ用の撮影機材も、画像を修正する専門スタッフもいません。そこで AI を使い、カウンターで何気なく撮った写真を、白背景・多角度・仕様とバーコード付きのプロ品質の商品画像に変えることにしました。
- 一度の入力で、どこでも使える：データは一か所だけで管理し、ワンクリックですべての販売プラットフォームに同期します。
- 操作が簡単：スタッフに簡単な研修をするだけで、日常業務に使えるようにします。
- ピッキングの支援：ピッキングリストにバーコードを印刷し、写真が見づらいときはスキャンして商品情報や棚の位置を確認し、拡大して細部を見られるようにします。複数人で一緒にピッキングするときは、他の人が何を見つけたかも分かります。
現実的な制約も2つありました。オーナーの信頼を得るため、データはローカルに置くこと。そして、店で使っている既存の ERP には外部向け API がないことです。
A · Action：どう作ったか
まず全体のアーキテクチャです。下の図はインタラクティブになっていて、各ノードをクリックすると、その役割と使われている技術が表示されます。
主工作台：产品网格、详情抽屉、AI 批量渲染与精调、排版模板编辑、订单与平台同步。任务队列和进度通过 WebSocket 实时推送。
点击节点查看细节 · 节点可以拖动
システム全体は、入力・制作・配信の3つを軸に構成されています。
入力：スマホがバーコードリーダー
スマホ側は独立した React ページで、スタッフは店内のローカルネットワークから HTTPS でアクセスします。
バーコードをスキャンすると品番が自動で入り、写真はそのままアップロードされ、中国語・スペイン語の品名、仕様、ケース入数もまとめて一度に入力できます。複数人が同時に入力でき、入力が終わった商品は PC 側にリアルタイムで表示されます。
制作：何気ない写真から商用画像へ
PC 側は Neo Studio という名前で、メインの作業画面です。
すべての商品がグリッドで表示され、各カードの下にある3つの小さな点は、hero / side / detail の3つのビューのレンダリング状態を表します。
商品を開くと、元の写真、AI が生成した3つのビュー、最終的な合成画像が見られます。
気に入らないビューは、ワンクリックで再生成するか、テキスト指示で微調整できます。
こちらは実際の「再生成」操作の録画です。元の写真を確認してから、ビュー2を再生成します。10秒ほどで新しい画像が返ってきて、合成画像も自動で更新されます。
生成されたビューは、最後にレイアウトテンプレートに従って完成画像に合成されます。テンプレートは、各ビューをどこに置くか、品名と仕様をどう並べるか、バーコードや店のロゴをどこに置くかを定義します。
テンプレート自体もビジュアルに編集できます。
カテゴリごとに別のテンプレートを使えます。たとえば次のものは、メインビューを大きくして、ディテール画像を右側に置いています。
生成の操作は、本質的には2種類だけです。Generate（コンテキストなしの新規生成）と Refine（前回の結果を土台に修正）です。
画面上の「再生成」と「微調整」が、それぞれこの2つに対応します。
微調整の難しさは「前回を覚えていること」にあります。前の画像を単なる参考画像として送っても、モデルはそれが自分が描いたばかりの絵だとは分かりません。
Gemini は画像を返すとき、そのターンの内部状態を表す thought signature を付けてきます。これを前回の会話と一緒に送り返すと、モデルは「これは自分が前に描いたもので、今はそれをベースに直すのだ」と本当に理解し、ゼロから描き直すことがなくなります。
カテゴリごとに、必要な生成プロンプトも違います（傘は開くか閉じるか、香水は箱を付けるか、など）。
こうしたプロンプトは、もう自分で試行錯誤して調整しているわけではありません。AI に調整させています。プロンプトをデータベースに書き込み、レンダリングを実行し、Gemini API で生成画像を直接見て、どこが悪いかを判断し、プロンプトを書き直してもう一周。収束したらコードにアーカイブします。
AI に自分自身の審査員をやらせるわけです。私はこの流れを laag と呼んでいます。
利点は時間の節約ではなく、人手での調整のように、調整しているうちに以前踏んだ落とし穴を忘れてしまうことがなくなる点です。
さらに、カテゴリごとのプロンプトは、事実上、大切なデータ資産になります。将来 SaaS 製品にするなら、大きなデータの参入障壁になるでしょう。
ほかの2つのカテゴリの生成前後の比較です。左は参考画像管理にある元写真、右は自動合成された完成画像です（傘は開いたメインビューと閉じたディテールビュー、キッチン用品には手で使っているシーン画像も加わっています）。
配信：一度の入力で、複数のプラットフォームへ同期
すべてのデータは、ローカルの SQLite という1か所にだけ存在します。
外部プラットフォームごとに、バックエンドに独立した連携レイヤーがあります。友購、Meta の商品カタログ、自社サイトの CMS で、それぞれ1つずつです。
各レイヤーは、ローカルのフィールドをプラットフォームのフィールドに変換し、両側のデータに「ずれ」がないかを記録します。
3つのプラットフォームは性格がまったく違います。友購にはオープン API がないため、データベースを直接読み書きして連携します。商品コードは店の品番が元ですが、品番の一意性は保証されていないため、重複したら商品 ID を接尾辞として自動で付けます（例：r00008_61）。そうしないと、友購側で2つの商品が互いに上書きしてしまうからです。Meta のカタログ API が成功を返しても、それはリクエストを受け取ったというだけです。審査は非同期なので、Facebook / Instagram のショップに実際に表示されるかどうかは、別途審査状況を取得して書き戻す必要があります。自社サイトのログイン状態は1時間で失効する JWT で、リクエストが失敗してから対処するのではなく、50分の時点で先回りして更新しています。
店の ERP には公開インターフェースがないため、店の要望に沿って、ローカルマシン上の業務データに直接つなぎ、さらに Excel の手動インポートをフォールバックとして残しました。連携に問題が起きても、業務は止まりません。
商品のサイズ表記
ここで、データを一か所に集めて入力するメリットが生きてきます。入力の段階で、スタッフが必要なデータをすべて入れているので、別途整理する必要がありません。サイズを表記するときは、入力済みの寸法を画面から直接引き出して、画像にすばやく書き込めます。
ps：私の最初の仕事は構造エンジニアで、主な仕事は CAD や Creo での寸法記入、図面の管理、PLM と Excel のデータ同期でした。今、自分の手でこうしたシステムを作り上げたと思うと、少し誇らしくなります (｡•̀ᴗ-)✧
ピッキング：小さな写真を見て探す日々を終わらせる
卸の注文は、たいてい「どの商品を何ケース」という長いリストです。以前のピッキングリストは文字の行と小さな写真だけで、スタッフはよくリストを見ても商品を見つけられませんでした。
今は、注文がシステムで作成されると、写真、中国語とスペイン語の品名、品番、ケース入数、そしてバーコード付きのピッキングリストをワンクリックで印刷できます。
スタッフの手元にあるのはこの1枚です。左に写真、中央に品名、右にバーコードと数量、最後の列はチェック用に空けてあります。
写真が見づらい商品に出会ったら、スタッフはスマホを取り出してバーコードをスキャンするだけで、商品情報と棚の位置が分かり、拡大して細部も確認できます。
複数人で同じ注文をピッキングするときは、各自がスマホで OK か Falta（欠品）をタップし、ほかの人の画面も同期して更新されます。誰が何を見つけたか、何がまだ足りないかが一目で分かります。
店で動くようにする
最後に、Electron でシステム全体を1つの exe にまとめました。ダブルクリックするとローカルのバックエンドが起動し、バックエンドが PC 側とスマホ側のページを配信します。
店のパソコンには開発環境を一切入れる必要はありません（パッケージ化のときに踏んだ落とし穴は、別の記事で書く予定です）。
さらに MCP Server も作り、商品データベースを AI が呼び出せるツールとして公開しました。商品の検索、一括レンダリングの開始、特定のビューの微調整などです。
日常のメンテナンスでは、多くのことを自然言語で LLM に任せられます。ただ、お客様の支払い能力の都合で、この部分はお客様には開放していません。今のところ、使えるのは開発者だけです。
R · Result：結果
いちばん分かりやすいのは画像です。左はスタッフがカウンターで何気なく撮った写真、右はシステムが自動で生成・合成した完成画像です。白背景、多角度で、容量、品番、バーコード、店のロゴが入っています。
- システムはすでに店で日常的に使われており、オンライン販売チャネルを素早く立ち上げると同時に、実店舗の倉庫管理や補充も支えています。
- 1回の入荷の出品にかかる時間が、数日から数分に短縮されました。
- データは1つだけ管理すればよく、各プラットフォームへの同期もワンクリックです。
- ピッキングは、小さな写真を見て推測する作業ではなくなりました。バーコードのスキャンと複数人の同期で、漏れや間違いが目に見えて減りました。
- 店にデータ資産（商品データベースとカテゴリ別の生成テンプレート）が蓄積され、将来の自社サイトやデータ分析の開発コストが下がります。
- チリで生きていくためのお金を稼げました (๑•̀ㅂ•́)و✧
逃げ道を残しておいてよかった：AI モデルが「期限切れ」になった
ある日、店から「AI の画像生成が急に使えなくなった。再生成を押してもずっと失敗する」と連絡がありました。プロジェクトを開いて調べると、2つの問題が重なっていました。
- モデル名：プロジェクトでは、Gemini の画像モデルのプレビュー版の名前（
-previewで終わるもの）をまだ使っていました。すでに正式版が出ており、プレビュー名はいずれ廃止されるので、すべて正式版の名前に切り替え、モデル名を1か所にまとめて管理するようにしました。 - クォータ：新しいキーに替えたところ、API が 429 を返しました。AI Studio の無料枠では、画像生成モデルのクォータが 0 だったのです。最終的に、バックエンドを Vertex AI（API キーを使う簡易モードで、GCP の課金）に切り替えました。
Vertex に切り替えたことで、連鎖的な問題も出てきました。このプロジェクトでは、商品画像を Gemini の File API にアップロードして 47 時間キャッシュしていましたが、Vertex にはこの API がありません。幸い、キャッシュは「任意」として設計してあり、キャッシュに失敗したら自動的に画像のインライン送信に戻ります。そのため、Vertex のときだけキャッシュをスキップすれば済み、レンダリングのロジックは1行も変更せずに済みました。
同様に、店が使っている EC 向け ERP に問題が起きても、Excel のフォールバックモードが使えます。私のシステムから、ERP が求める形式の Excel を書き出してもらい、それでデータを同期するのです。変更が必要なのは、この互換レイヤーだけです。
次回
この記事は主にプロダクトの視点で書いたもので、技術的な詳細には触れていません。次回以降は、技術面を取り上げます。設計上のトレードオフ、データベース、タスクキュー、そして Electron でのパッケージ化です。