Wayfairが、OpenAIのモデルを商品カタログの属性補正とサプライヤー(仕入先)サポートに組み込み、月4.1万件のチケット処理を自動化した、という事例です。
「3,000万点規模のEC、うちには関係ない」と思った方、ちょっと待ってください。 この事例の本質は規模ではなく、「商品マスタの整備」と「外部窓口の自動化」を同時に回した運用設計にあります。
僕が注目したのは、最大70%自動化という数字よりも、「チケット三層構造(triage / co-pilot / auto-pilot)」の組み立て方です。 全自動を最初から狙わずに、まず振り分けから入っているところが、中小ECでも真似しやすい構造です。
EC運営の課題
3,000万点の商品マスタを抱えるWayfairに限らず、EC・卸売の現場ではこんな構造的な課題があります。
- 商品属性タグ(色・素材・サイズ・カテゴリ)に欠落や誤りが大量にある
- 検索・レコメンドの精度低下に直結するが、人手で直しきれない
- 仕入先(サプライヤー)からの問い合わせが日々大量に届く
- 「カテゴリの修正依頼」「在庫情報の更新」など、定型に近いのに人で受けている
カタログ品質と問い合わせ対応は、別チームでバラバラに回されがちですが、 両方とも「商品データを正しく持つ」という同じ問題の裏表です。 Wayfairはここを同時に攻めた、というのが他社事例との違いです。
OpenAIをどう導入したか
公開情報(OpenAI公式事例ページ、2026-03-11)の範囲では、以下の構成です。
- 対象: 約3,000万点の商品カタログと、サプライヤーサポート窓口
- 使ったもの: OpenAIのモデル + 社内ツール「Wilma」へのエージェント機能追加
- アプローチ: 2024年に小規模リリースから開始 → 本番運用へ段階拡大
- チケットの三層構造:
- Triage(振り分け): 受信したチケットを読み、不足コンテキストを補完して担当チームへ自動ルーティング
- Co-pilot(支援): 担当者の作業を横でサポート
- Auto-pilot(自動化): 定型ワークフローでは人手を介さず処理
ポイントは「いきなり全部auto-pilotにしない」ことです。 振り分けと下書きの段階から入り、運用の中で自動化レンジを広げています。
月4.1万件自動化の内訳と実態
OpenAI公式事例で報告された主要な数値は以下です。
- カタログ補正: 100万点超の主要商品で250万件のタグを補正(今後6ヶ月で4倍見込み)
- サプライヤーサポート: 月4.1万件のチケットを自動化
- 自動化率: 一部ワークフローで最大70%
- 処理時間と再オープン率: いずれも改善
注意点として、「全チケットの70%が自動化された」わけではありません。 特定の定型ワークフローに限って最大70%、というのが正確な読み方です。
それでも、月4.1万件という数字の裏にある「サプライヤーが待たされる時間」が削れている事実は大きいです。 EC運営の現場感覚では、ここが詰まると検索品質・在庫精度の両方に効いてきます。
中小企業で再現するなら
ここからが本題です。年商5億規模のEC・卸売事業者で同じ思想を取り入れるならどう削るか。
構成
| 項目 | Wayfair | 中小EC(年商5億・社員30名) |
|---|---|---|
| 対象 | 3,000万点カタログ+サプライヤー窓口 | 1〜10万点カタログ+サプライヤー/カスタマー窓口 |
| ツール | OpenAIモデル+自社ツール「Wilma」 | ChatGPT Enterprise(2026年4月時点 約60USD/人月、要最新確認) or Claude for Work + 既存問い合わせ管理ツール(Zendesk等) |
| 月額費用 | (非公開) | 推定 月3〜10万円(利用者3〜5名+API従量分) |
| 初期費用 | (非公開・社内開発) | 推定 80〜200万円(商品データ整備+プロンプト設計+問い合わせ分類のテンプレ化) |
| 体制 | 社内開発チーム | 既存EC担当+外部支援月10〜20時間 |
| 期間 | 2024年から段階拡大 | 3〜6ヶ月でPoC→本番運用 |
評価軸スコア
| 評価軸 | スコア |
|---|---|
| ROI(投資対効果) | ★★★★☆ |
| 再現性(中小企業) | ★★★☆☆ |
| 難易度(低いほど簡単) | ★★★☆☆ |
(難易度=数字が小さいほど簡単)
スコア根拠は以下です。
- ROIが高いのは、サプライヤー対応と検索品質改善が売上(GMV)に直結しやすいため
- 再現性は中程度。商品マスタが整理されていないと、AIに渡せるデータが揃わない
- 難易度は中程度。ノーコードでは完結せず、商品データの構造化とプロンプト設計が必須
前提条件・必要データ
- 商品マスタがCSV/データベースで構造化されている(Excel手作業のままではNG)
- 過去の問い合わせ履歴とFAQが300件以上ある(分類学習の材料として)
- 自動化したい問い合わせの定型パターン(在庫・配送・カテゴリ修正等)が言語化できる
- 「最終確認は人間が行う」運用が組める(完全auto-pilotから入らない)
失敗条件・適用しないケース
- 商品マスタがExcelシート手管理のままで、構造化に半年以上かかる
- 問い合わせ件数が月100件未満(自動化のリターンが薄い)
- ブランド対応の質を均一にする運用ルールがない(AIで返答ブレが拡大する)
- いきなり「auto-pilotで全自動」を目指して、triage/co-pilotの段階を飛ばす
「OpenAIを入れればサポートが7割減る」わけではありません。
商品データ整備→問い合わせの分類・テンプレ化→triageから自動化開始→co-pilot→auto-pilotへ段階拡張、という4ステップを踏んで初めて、Wayfairと同じ思想が中小ECで動き出します。
特に最初の「商品データ整備」を飛ばすと、サポート自動化の精度が出ません。 カタログ品質とCS自動化はセットで設計するのが、この事例から学べる一番の点だと思います。
出典・参考
市野
愛知県岡崎市でAI活用支援を手がける一人社長。 中小企業の現場でAIを実装してきた経験から、他社事例を「うちで再現するには」の視点で読み解いて発信中。
