Y Combinator 日本語図鑑

事業概要

プロダクト

• EC事業者の受注データと配送状況を取り込み、出荷を手配する。
• 追跡番号を照合し、遅延や不着の荷物を抽出して通知する。
• 返品依頼を受け取り、返品可否と返金手続きの案内を返す。
• 顧客の問い合わせ文を読み、回答案と処理手順を生成する。
• 輸送手段の候補を比較し、費用と納期の見積りを提示する。

技術アーキテクチャ（推定）

• 顧客の受注管理や基幹システムから連携で注文・返品データを取得するとみられる。
• 配送事業者の追跡情報を公開情報や連携経由で取得し、状態表記を正規化する。
• 問い合わせ文を大規模言語モデルで分類し、注文番号や顧客IDと名寄せする。
• 返品可否や返金額は事前に定義した業務ルールで判定し、判断根拠を残すと推定。
• 処理結果は顧客の既存システムへ書き戻し、実行履歴を保管するとみられる。

収益モデル

• EC事業者が月額または契約単位で利用し、実行した業務範囲に応じて課金されるとみられる。
• 導入時の構築費用や連携設定の対価を別途取る形態も考えられる。
• 価格は非公開。

差別化

• 受注から返品までの処理履歴が蓄積し、判定精度の改善につながる。
• 物流と顧客対応を一つの実行主体で扱い、業務の受け渡しを減らす。
• 配送事業者やEC基幹システムとの連携設定が導入後の移行障壁になる。

日本展開時のリスク

• 輸送を手配する場合、貨物利用運送事業の登録要件に関わる可能性がある。
• 顧客情報を預かるため、委託先監督と安全管理措置の説明が求められる。
• 受注管理や在庫管理の国内製品と連携する接続方式の作り込みが要る。
• 配送事業者との関係や電話対応の慣行が自動化の範囲を制限しうる。
• 創業直後で導入実績が乏しく、障害時の責任分界の合意が難しい。

日本での競合

• 国内のEC事業者は受注管理と顧客対応を別々の製品で運用している。
• ネクストエンジンやロジザードが受注・在庫・出荷の基幹を握る。
• 顧客対応はZendeskなど外部製品が担い、物流は事業者ごとに分立する。
• 複数業務を横断して実行する同型の製品は国内で確認できない。
• 既存基幹との連携と個人情報の扱いが参入時の主な障壁になる。

主要プレイヤー

• ネクストエンジン — ECの受注・在庫管理。
• ロジザード — 在庫管理と倉庫管理。
• ハコベル — トラックのマッチングと物流管理。
• Zendesk Japan — 問い合わせ管理とサポート業務。