Phase 1 1分サマリ
- 期間
- 〜2026-06-30
- プロダクト
- 暫定「BreX Shop Agent」（正式名は別途、pending-decisions #5）
- ターゲット
- Shopify EC事業者（PoC: ボルダリング用品EC 6〜7月 → 5社限定無料展開 → 8月 App Store クローズドβ）。マキシムは Shopify 未使用のため業務理解パートナー扱い
- 位置付け
- シグナル収集に最適化した最小実装 — Phase 2 以降のスコープを Phase 1 顧客のサインから決める
- コアスコープ
- 9 機能（チャットウィジェット、認証、注文操作、WISMO、返品/交換受付、ナレッジ管理、ポリシー設定）+ 軽量アーキテクチャ。GEO 連携・ダッシュボードは Phase 2 以降
- 明示的に含まないもの
- 複雑処理を分業する「考えるレイヤー」、AI 回答の二重検証、長期記憶、運用代行（BPO）、LINE、課金システム本体、GEO API 連携 等
マイルストーン
2026-05
マキシム CS業務体験（神戸1週間）→ 業務知見を仕様に反映（業務理解パートナー扱い）
+ Shopify Partner Account 登録・開発ストア準備（Hanatsuka）
2026-06
Phase 1 開発（確度の高い機能から先行着手、走りながら削ぎ落とし）
+ ボルダリング用品EC へのテスト導入準備
2026-07
ボルダリング用品EC でテスト導入・事例化・プロダクトブラッシュアップ
2026-08
Shopify App Store クローズドβ公開（招待制・unlisted） + マネタイズ検討
実装方針: 5月のCS業務体験で確度判断を待たず、現状デザイン範囲をベースラインとして実装着手し、走りながら削ぎ落とす。確度の高い機能（C-* ウィジェット基盤・Shopify OAuth・注文照会・WISMO）から先行着手し、CS業務体験の知見を順次反映する。
マキシム協業の詳細は マキシム協業（customers/maxim/partnership.md） 参照（業務理解パートナー、Shopify 未使用のため直接 PoC 顧客ではない）。
Phase 1 Done 定義
以下を全て満たした時点で Phase 1 完了とみなし、Phase 2 着手判断に進む。
プロダクト Done
- 9 機能（チャットウィジェット / 顧客認証 / 配送先変更 / 注文キャンセル / 注文内容確認 / WISMO / 返品・交換リクエスト受付 / ナレッジ管理・学習 / 自然言語ポリシー設定）すべて Shopify 開発ストアで E2E 動作
- 10 対応シナリオ × 各 3 ケース以上の自動テスト合格
- エスカレーション基盤がメール送信完了まで動く
事業 Done
- ボルダリングEC で 1 ヶ月本番運用、AI 完了率 70% 以上
- 5 社限定無料展開で 3 社以上が継続意思表示
- Shopify App Store クローズドβ公開達成（招待制・unlisted）
データモデル / システムアーキテクチャ等の開発設計レベルの「Done 詳細」は 開発意思決定・各 customer/* の「実装仕様」セクション・今後拡張する開発設計ドキュメントで定義する。本セクションは全体設計レベルの判定基準のみ。
Phase 1 で実現する体験
顧客側
ECサイトの右下にチャットウィジェットが表示。顧客が「注文をキャンセルしたい」と入力 → AIが本人確認（Shopify OAuth ログイン）→ Shopify注文データを即座に引き当て → 確認 → Shopify APIでキャンセル実行（決済確定前のみ）→ 完了通知。所要時間約30秒。人間は一切介在しない。
| 顧客の入力 | AIがやること |
|---|---|
| 「注文キャンセルしたい」 | Shopify OAuth ログイン → Shopify APIで注文キャンセル（決済確定前のみ自動。決済済みは事業者へエスカレーション）→ 完了通知 |
| 「届け先を変更したい」 | Shopify OAuth ログイン → 新住所ヒアリング → Shopify APIで配送先更新 → 完了通知 |
| 「荷物いつ届く？」 | Shopify OAuth ログイン → 追跡番号取得 → 現在ステータス回答 |
| 「注文内容を確認したい」 | Shopify OAuth ログイン → 商品・数量・金額・ステータス一覧表示 |
| 「返品したい」「交換したい」 | Shopify OAuth ログイン → 対話形式で理由・希望対応をヒアリング → 構造化リクエストを Shopify returnRequest で受付 → 事業者へ通知（最終判断は事業者） |
| AIが対応できない問い合わせ | 「担当者に引き継ぎます」→ メアド確認（認証済みなら登録メアドを提示）→ 事業者にメール通知 |
事業者側
Shopifyアプリストアからインストール → チャットウィジェット自動設置 → 管理画面で自社ポリシーを日本語で記述（例:「注文確定後24時間以内ならキャンセル可」）→ AI 稼働開始。会話ログ画面で AI 完了 / エスカレーションの状況を確認できる。
KPI ダッシュボードは Phase 1 では提供しない（Phase 2 以降）。Phase 1 では会話ログ画面（A-1）で AI 完了 / エスカレーションの状況を確認する。
対応シナリオ
EC CS の標準 8カテゴリ（キャンセル・注文内容変更・返品交換・配送・情報変更・決済・アカウント・その他）のうち、Phase 1 で AI が能動的にハンドルするシナリオ をまとめる。対象外シナリオは L3 単純エスカレーション（事業者にメール通知）で処理する。
対応の 4 段階
| 段階 | 内容 |
|---|---|
| L1: 情報照会のみ | Read only、API 実行なし |
| L2: 完全自動完了 | Shopify OAuth ログイン → API 実行 → 完了通知（顧客との対話で完結） |
| L3: 単純エスカレーション | AI が対応不可と判断 → 「担当者に引き継ぎます」+ メアド取得 → 事業者通知 |
| L4: 構造化リクエスト申請 | AI がヒアリング → 構造化記録 → 事業者通知。判断・処理は事業者が実施 |
Phase 1 で対応するシナリオ
| カテゴリ | シナリオ | 段階 | 担当機能 |
|---|---|---|---|
| キャンセル | 全部キャンセル（決済確定前） | L2 | 注文キャンセル |
| 注文内容 | 既存注文の閲覧 | L1 | 注文内容確認 |
| 配送先住所変更 | L2 | 配送先変更 | |
| 返品・交換 | 店舗都合返品（不良品・誤送）リクエスト申請 | L4 | チャットでヒアリング → 構造化 → 事業者通知。最終判定は事業者 |
| 自己都合返品（7日以内）リクエスト申請 | L4 | 同上 | |
| 交換リクエスト申請 | L4 | 希望商品・サイズをヒアリング | |
| 配送関連 | 配送状況確認（WISMO） | L1 | WISMO |
| 追跡番号取得 | L1 | 追跡番号 API、配送ステータス取得まで | |
| 登録住所 | 会員情報の住所変更 | L2 | Shopify Customer API |
| その他 | CS関連 Q&A対応（営業時間・会員登録・ポイント・メルマガ停止・店舗情報等のFAQ） | L1 | ナレッジベース照会。Sales関連（商品・サイズ・成分等）は対象外 |
| エスカレーション基盤 | AI 不可と判断 → メール通知 | L3 (基盤) | チャットウィジェット内で実装 |
つまり Phase 1 で AI が能動的にハンドルするのは 10 シナリオ（L1: 4 / L2: 3 / L4: 3）+ エスカレーション基盤。残りは L3 単純エスカレーションで事業者にメール通知。
返金処理を Phase 1 から外す意義: 返金は金銭が動く処理で、AI 誤動作時の責任範囲・顧客トラブル時の対応コストが大きい。Phase 1 はシグナル収集に最適化しているため、リスクの大きい操作は事業者に任せる。Phase 2 以降に AI 回答の二重検証を入れた上で、決済済みキャンセル + 返金 を L2 化する。
L4 を Phase 1 から含める意義: 返品・交換はマキシムの主要 CS 業務の 3 割程度を占める。Phase 1 で「対象外」と切ると AI から漏れすぎる。リクエスト申請レベルまでは AI が受け付けて構造化することで、事業者の判断負荷を大きく軽減。Phase 2 以降に画像判定・期限管理・在庫連動等を追加して完全自動化（L2）へ段階的に進化。
対象外シナリオを含む完全版マトリクス・5月 CS 業務体験で確認したい項目は tmp/2026-05-16-phase1-scenario-matrix-detail.md に退避。phase1.html では「対応するシナリオ」のみ簡潔に掲載。
Phase 1 で含むもの
9 機能
| 機能 | 説明 |
|---|---|
| チャットウィジェット | 基盤、SDK/タグ1行で導入 |
| 顧客認証 | Shopify Customer Account API による OAuth ログイン。BreX 側で magic link を発行する独自実装はしない |
| 配送先変更 | Shopify API |
| 注文キャンセル | Shopify API、決済確定前のみ自動実行。返金実行は Phase 2 |
| 注文内容確認 | Shopify API |
| WISMO | Where Is My Order — 配送状況確認、追跡番号 API |
| 返品・交換リクエスト受付 | L4 構造化リクエスト申請、Shopify returnRequest mutation で受付 |
| ナレッジ管理・学習 | Help Center / SOP / Guidance アップロード、過去チケットの扱い（後述） |
| 自然言語ポリシー設定 | 管理画面で日本語記述 |
ダッシュボード（KPI 表示）は Phase 1 では提供しない。 ニーズが見えてから Phase 2 以降に追加。Phase 1 では会話ログ画面（A-1）で AI 完了 / エスカレーションの状況を確認する。
軽量アーキテクチャ要素
- Skill 切替の基礎設計 — Phase 1 は CS Support Skill のみ実装するが、Phase 2 で Shopping Assistant を追加できるよう拡張ポイントを設計しておく
- ナレッジソース方針の実装 — 過去チケットをモデル学習ではなくナレッジ抽出素材として扱う（後述「ナレッジソース方針」）
営業・運用
- ボルダリング用品EC でのテスト導入（6〜7月、Shopify ストア、招待制）— Phase 1 の最初の本番接続
- 5社限定無料展開（Phase 1 後半〜Phase 2、シグナル収集目的）
- Shopify App Store クローズドβ公開（8月、招待制 unlisted app）
マキシムは Shopify 未使用のため Phase 1 の PoC 顧客ではなく、業務理解パートナー（マキシム協業（customers/maxim/partnership.md））として CS 業務知見を提供する役回り。
Phase 1 で含まないもの
スコープクリープ防止のため、以下は Phase 1 では実装しない。Phase 1 顧客から得るシグナル（同じ問い合わせが頻発する、複雑処理が連鎖する 等）に応じて Phase 2 以降で順次追加する（詳細トリガー条件は tmp/2026-05-16-phase1-phase2-triggers.md）。
アーキテクチャ系
| 要素 | 何をするものか | Phase 1 で入れない理由 |
|---|---|---|
| 複雑処理を分業する「考えるレイヤー」 (Planner / Reasoning Layer) |
顧客の長文・複数要望を、AI が「これは何の処理か」「順番にどう実行するか」と段取りを立ててから動く仕組み。たとえば「キャンセルしてついでに別の商品を送ってほしい」のような複合リクエストを分解する | Phase 1 はシナリオを単純なものに絞っているので不要。複雑リクエストが頻発するシグナルが見えたら Phase 2 で追加 |
| AI 回答の二重検証 (Dual-Model Validation) |
AI が出した回答を、別の AI モデルに「これは正しいか / 規約違反していないか」と二重チェックさせる仕組み | Phase 1 のシナリオ範囲では誤情報リスクが低い。返金処理など金銭が動く処理を入れる Phase 2 以降で必要になる |
| 長期記憶 (Memory / 永続コンテキスト) |
「この人は前回もこの件で問い合わせてきた」「この人はリピーター」など、過去の対話を AI が継続的に覚えている仕組み | Phase 1 は単発の問い合わせ完結を想定。リピーター対応・Shopping 機能を入れる Phase 2 以降で必要 |
| 計画途中での軌道修正 (アダプティブ・リプラン) |
AI が立てた処理計画の途中で「在庫切れだった」「API エラーが返ってきた」などの例外が出たとき、計画自体を組み直す仕組み | Phase 1 のシナリオは例外が出にくい単純処理に絞っている。例外多発のシグナルが見えたら Phase 2 で追加 |
機能拡張系
| 要素 | 何をするものか | Phase 1 で入れない理由 |
|---|---|---|
| Shopping Assistant | 商品提案・サイズ提案・比較・レコメンドを AI がする機能（プレセールス接客） | Phase 1 は CS 領域に集中。顧客から商品相談ニーズが見えたら Phase 2 で追加 |
| LINE / マルチチャネル対応 | Web チャットウィジェット以外（LINE / メール / 電話）からの問い合わせに対応 | Phase 1 は Shopify チャットウィジェット 1 チャネル。LINE ニーズが見えたら Phase 2 で追加。メール / 電話は Phase 3 以降 |
| GEO API 連携 | geo-check（AI Visibility 診断ツール）の API を呼び出して、管理画面に「GEO 診断」タブを表示 | geo-check 側の API 化が Phase 1 中に間に合うかは独立判断。Phase 1 はコア CS 機能に集中、GEO 連携は Phase 2 で組み込む（geo-check 自体は独立プロダクトとして継続） |
運用代行（BPO）系
| 要素 | 何をするものか | Phase 1 で入れない理由 |
|---|---|---|
| 休日代行 | 土日祝の CS 対応を BreX 側オペレーターが代行 | Phase 2 から準備、PMF 確認後に運用開始（採算が立つ規模になってから） |
| 一次回答代行 24/7 | 平日昼も含む一次回答の完全代行 | Phase 3 以降 |
| 完全代行 | 事業者は CS 部門ゼロ、BreX が全部やる | スケール後 |
マネタイズ系
- 課金システム本体 — Phase 1 はマキシム無償 + 5社限定無料展開、Phase 2 で実装
- 具体料金体系 — マキシム業務体験で実数把握後（pending-decisions #3）
3 階層 SoR の本格機能
- パターン検出・改善提案（L2 ナレッジ層: 同じ問い合わせ繰り返しを検出、未定義ケースを通知）— Phase 2
- プロセス版管理 / 改善履歴 / 判断ロジックの版管理（Phase 3 以降）
- Phase 1 は L2 ナレッジ層の 入口レベル（ポリシー設定、Help Center / SOP のアップロード）まで。L1 対話 SoR の蓄積は Phase 1 から開始
- 戦略フレーム詳細は プロダクト概要 戦略的ビジョン 参照
ナレッジソース方針
過去チケット（顧客対応ログ）は AI モデルの学習データに直接使わない。 代わりに「ナレッジ管理画面に登録すべき情報を抽出するための素材」として扱う。
過去チケット ├── AI が解析 → ナレッジ候補（FAQ / SOP / ポリシー）を抽出 → 事業者承認 → A-2 画面のナレッジに反映 ├── 古いポリシー検出 → 「これ古くないですか？」と事業者に提案 └── AI モデル自体の学習データには使わない（過去対応のミスをそのまま継承させない）
AI が学習する情報源（ナレッジ管理画面に登録されたもの）:
- 事業者の Help Center 記事
- SOP（業務手順書、Excelマニュアル等）
- 自然言語ポリシー（管理画面で記述）
- 事業者が承認したナレッジ項目（過去チケットから AI が抽出して、事業者が OK を出したもの）
AI が学習しないもの:
- 過去の顧客対応ログ（生）
- 個別の顧客情報
理由
- 過去対応の誤り・古いポリシー・属人性を「正解」として継承させない
- データプライバシー（個人情報保護法・GDPR）リスク低減
- Gorgias 3.0 / Sierra / Alhena が採用する現代設計と整合
- BreX 独自の打ち出し: 過去チケットを「捨てる」のではなく「ナレッジ抽出素材」として中間活用