1. 結論
  2. Polaris採用の理由
  3. 将来のカート拡張に備えた設計
  4. ユーザーが触れる戦略上の含意
  5. Phase 3以降の展開計画（Plan C）
CS Agentic AI 事業者向け管理画面のUIライブラリ選定と、将来の他カート拡張に備えたアーキテクチャ方針をまとめたもの。

結論

Phase 1 では Shopify Polaris を採用。ただし将来のカート拡張（Shopify Plus / ecbeing / ebisumart 等、Phase 3 以降）に備えて、業務ロジック層とUI層を分離した設計にする。

Polaris採用の理由

  1. 時間を買える — Phase 1 納期（〜6/30）が短い中、コンポーネント完成品としての価値が大きい
  2. 品質の地味な部分が担保される — アクセシビリティ・レスポンシブ・i18n等の検証コストはAI開発でも省けない
  3. Shopify アプリストア審査 — Polaris は事実上の合格基準
  4. 学習コストゼロ — 事業者は既に Shopify 管理画面に慣れているので、操作を学ぶ必要がない
  5. 独自性はウィジェット側で出す — 差別化が必要なのは顧客側のチャットウィジェット。事業者向け管理画面は Shopify に溶け込むのが正解

将来のカート拡張に備えた設計

将来的に Shopify 以外のカート（ecbeing / ebisumart / 独自EC）にも展開する可能性がある。その時に管理画面を作り直さないために、以下のアーキテクチャ原則を守る:

原則: 業務ロジックとUIの分離（Container/Presenter パターン）

Container 層

データ取得、状態管理、業務ロジック。Polaris に依存しない。

Presenter 層

UI表示のみ。Polaris コンポーネントはこの層にだけ閉じ込める。

効果

  • 拡張時は Presenter 層だけ書き換えればよい（業務ロジックは流用可能）
  • ecbeing/ebisumart 版は独自 UI ライブラリで実装、Shopify 版は Polaris、と並列展開できる
  • AI 開発のおかげで「分離設計」自体のコストは低い（人間が手で書くより速い）

やってはいけないこと

  • Polaris コンポーネントを業務ロジックファイルに直接 import する
  • Polaris 固有の props をデータ構造に含める
  • Polaris のテーマシステムに業務的な意味を載せる

ユーザーが触れる戦略上の含意

  • Phase 1〜2 は Shopify 特化、UI も Shopify 流に揃えてストア体験を最大化する
  • Phase 3 で他カート対応が始まる時、UI はそのカートの慣習に合わせる（独自 UI で「Polaris 風に揃える」のではなく、ecbeing なら ecbeing の管理画面に溶け込ませる）
  • これにより「カートを乗り換えても操作感が変わらない」ではなく、「どのカート上でも自然に感じる」体験を提供する

Phase 3以降の展開計画：埋め込み版と独立SaaS版の併走（Plan C）

Phase 3 で Shopify 以外のカート（ecbeing / ebisumart / 独自EC）に拡張する際、管理画面の実体は1つのまま、配信モードを2つ持つ方針で展開する。

配信モード

Shopify 事業者

App Store からインストール → Shopify 管理画面内に埋め込み起動 → Shopify OAuth 完了済みで即使える（Phase 1〜2 の体験を維持）

非 Shopify 事業者

app.brex.co にアクセス → 自前 ID でログイン → 接続先カート（ecbeing / ebisumart / 独自）を選択 → API キー等で接続 → 独立 SaaS として利用

1コードベース・自動分岐の実装方針

同じアプリで両モードを動かす。window.top !== window.self 等で埋め込み/独立を検知し、以下を自動分岐:

項目Shopify 埋め込み時独立 SaaS 時
認証ソースShopify OAuth自前ID（メール + パスワード / SSO）
トップバーShopify 管理画面が親、自前 topbar 非表示BreX 自前 topbar（ロゴ・ショップ名・ユーザーメニュー）
ルーティングShopify App BridgeHTML5 History API
課金Shopify Billing APIStripe等
UI ライブラリPolaris独自 UI or カート側の慣習に合わせる

アプリストア配布と独立アクセスの併存

Shopify 事業者も「独立 SaaS 版 URL」に直接アクセスできるようにしておく（App Store が主導線だが、URL でもログイン可能）。これにより Shopify メンテナンス時の代替動線、複数ショップ運用事業者の利便性向上にもつながる。

なぜPlan Cか（他案との比較）

案Shopify 事業者非 Shopify 事業者評価
A（現 Phase 1-2）Shopify 埋め込みのみ提供せずPhase 1-2 ではこれで十分
B独立 SaaS のみ独立 SaaSApp Store 集客導線を失う・学習コスト発生
CShopify 埋め込み（独立 URL も可）独立 SaaSPhase 3 以降のあるべき姿

App Store 配布ルートは日本の Shopify 事業者にとって最大の集客導線。これを手放さずに、非 Shopify 展開の受け皿も持てるのが Plan C の強み。

Phase 1〜2 での準備

Phase 1〜2 で Shopify 埋め込み版を作る段階から、UI アダプタ層を意識した設計にしておく:

  • Shopify App Bridge 依存コードを1つのモジュールに集約
  • トップバー等の「埋め込み環境前提のUI」は条件分岐可能な形で実装
  • 認証ハンドリングを抽象化（AuthProvider インターフェース等）

これにより Phase 3 で独立 SaaS モードを追加する際、既存コードの大半を流用できる。