役割と範囲
設計から実装まで全面的に担当し、その後も継続的に開発しています。テナント分離（スーパー管理者、テナント管理者、テナントユーザー）を備えたマルチテナント PIM プラットフォームで、すべての変更が公開前にレビューされるドラフト／公開ワークフローと、変更前後のスナップショットを伴う完全な監査ログを持ちます。
- Shopify ファーストの同期に加え、NetSuite ERP との連携、および ChannelEngine 経由での Amazon その他マーケットプレイスへの出力。
- タイトル、説明文、SEO テキスト、翻訳の AI による補完——生成されたコンテンツは公開前にレビュー工程を通ります。
- 製品チームがチャットでカタログを検索・操作できる内蔵の RAG アシスタント：商品データに対するベクトル検索と、ユーザーの承認を要するアクション向けのツール呼び出し。
- マーケットプレイスのページ上の商品をそのまま補完キューへ投入できる、独立した Chrome 拡張機能。
- EU GPSR 対応モジュール、キーワードボリューム検証付きの SEO モジュール、そしてリトライ付きキューで動くバックグラウンドタスク（ベクトル同期、情報補完、スケジューラ）。
成果
- 主要市場で 3,400 点超の稼働商品と、Amazon などマーケットプレイス上の数百件の追加リスティングへの出力フロー。
- カテゴリ URL を黙って上書きしていた AI 翻訳パイプラインをロールバックし、リダイレクトを作成してすべてを監査証跡に記録する版へ置き換えました。
- NetSuite と紐づくたびに AI コンテンツと Shopify 側の変更が上書きされる同期の不具合を、毎回手作業で直すのではなく構造的に解決しました。
- 8か月の継続開発で 350 コミット超——一度きりの納品ではなく、品揃えとともに育つシステムです。
アーキテクチャ
NestJS のバックエンドと Next.js 14（App Router）のフロントエンドからなる Turborepo モノレポで、Prisma のデータベースパッケージと型定義を共有しています。pgvector 拡張を有効にした PostgreSQL が商品データと埋め込みの両方を保持するため、ベクトル検索と通常のクエリが同一データベース上で動きます。バックグラウンド処理（ベクトル同期、AI 補完、マーケットプレイス同期）は自動リトライと指数バックオフを備えた Redis ベースのキューで実行し、UI と切り離しているため、マーケットプレイス同期が遅くてもプラットフォーム全体は止まりません。
モデル選定
内蔵の RAG アシスタントは意図的にマルチプロバイダ構成です。タスクごとに異なるモデルを使い分け（日常的なチャットには安価なモデル、複雑な補完作業には Claude や GPT の上位モデル）、モデル別にトークン単価を記録することで、会話あたりのコストがブラックボックスにならず可視化されます。生成されたコンテンツ（タイトル、説明文、翻訳）は必ずレビュー工程を通ります——モデルが提案し、人が承認する。他プロジェクトで価格ロジックを言語モデルに直接通さないのと同じ理由です。
コストとレイテンシ
- 会話あたりのトークンコストをモデル別に記録しているため、高価なモデルは既定ではなく、意図的かつ可視的に使われます。
- バックグラウンドタスク（ベクトル同期、情報補完）は最大3回のリトライと指数バックオフを伴って非同期に実行され、マーケットプレイスの一時的な障害が即データ損失につながらないようにしています。
- ベクトル検索と通常の商品クエリは同一の PostgreSQL インスタンス（pgvector）で動くため、別立てのベクトルデータベースとその同期層が不要になります。
学んだこと
AI 翻訳パイプラインは、翻訳が再生成されるたびにカテゴリ URL を警告なく上書きしていました。一見 SEO には良さそうでも、既存の外部リンクを壊してしまいます。過去の URL を復元し、リダイレクトを追加し、こうした変更を公開前に可視化する監査証跡を組み込むことで解決しました。2つ目の不具合は、商品が NetSuite に紐づいた時点で、NetSuite の同期のたびに AI 生成コンテンツと Shopify 側の変更が上書きされること。単発の事故ではなく構造的なパターンだったため、毎回手作業で直すのではなく同期の向きを見直して解決しました。3つ目はより小さいものの示唆的で、翻訳パイプラインが「RVS」（ステンレス鋼）のような素材の略語を誤訳していた件です。モデルが業務知識を推測してくれることに頼らず、用語集に明示的なルールを置いて解決しました。