本ページからは以下が分離・移管済み:
- Agentic AI 業界標準アーキテクチャ → アーキテクチャ進化
- BPO モデル段階構造 → プロダクトロードマップ
- 競合分析（Sierra / Gorgias 等）→ 競合ベンチマーク
- 3 階層 SoR の設計思想 → プロダクト概要 戦略的ビジョン
設計参考メモ（外部参照）
Identity Resolution（Treasure AI 参考、2026-05-06〜07 議論）
Hatanaka 起点で「CS対応含めて顧客ごとのパーソナライズするうえでは、トレジャーデータを徹底的に分析する価値あり」との問題提起から、Treasure AI（旧 TreasureData）の Identity Resolution アーキテクチャを 設計の参照点 として整理。
Identity Resolution とは:
複数チャネル（メール / Webチャット / Instagram DM / LINE 等）に散らばった「同じ人のデータ」を 1 つの顧客プロフィールに統合するプロセス。これがないと同じ顧客からの問い合わせをチャネルをまたいで別人として扱ってしまう。
設計原則（Treasure AI のアーキテクチャを参照）:
| マッチ種別 | 精度 | BreX での用途 |
|---|---|---|
| 決定論的（メール・注文番号・電話番号等の確定識別子） | 99%+ | CS エージェントの返答・個人データ参照・返金処理 |
| 確率論的（IPアドレス・行動パターン・ブラウザフィンガープリント等） | 85-95% | 分析・レコメンドのみ（返答には使わない） |
「確定していないと物理的に個人データにアクセスできない」設計にすることで、別人に個人情報を見せる障害を構造的に防ぐ。
現時点の方針（2026-05-07 議論で整理）:
- トリガー設計 — 注文番号を確定トリガーとして使う。EC文脈で最も自然、かつログイン強制よりCS離脱率が低い
- データ品質前提 — Identity Resolution の精度はEC事業者側の顧客データ品質に依存するため、Phase 1 のターゲットは「メール・注文番号が整備されている事業者」に絞る
- ID グラフは BreX が持たない — Phase 1〜2 では Shopify など EC事業者側の ID に乗っかる。BreX はエージェント層に集中（個人情報保護法対応コスト・事業者の心理的ハードル回避）
- データモデルだけ Phase 1 から織り込む — 実装は後回しでよいが、「顧客ID で会話履歴を管理する」構造は最初から設計に入れる。後からマルチチャネル追加時のリアーキテクチャを防ぐ
BreX 固有の差別化（GEO 連動）:
顧客ID で統合された全チャネル履歴は GEO（AI Visibility）の最適化素材になる。Identity Resolution の精度が GEO の品質に直結する（断片化したノイズだけ学習する vs 統合された顧客文脈で学習する）。
参考:
- Treasure AI Identity Resolution: https://www.treasure.ai/blog/identity-resolution
- TD Connected World 2025 基調講演: https://www.treasuredata.co.jp/learn/tdcw2025keynote1/
- 補足: Treasure AI（旧 TreasureData）は 2026-04-20 に
treasuredata.com→treasure.aiに変更し「CDP」→「Agentic Experience Platform」へ転換中。Engage Studio で CDP+MA+マルチチャネル実行を統合しており、競合化の可能性も観察対象（pending-decisions に追加検討）
出典: 2026-05-06〜07 Hatanaka × Hanatsuka（Slack #general スレッド ts=1778054869.136499）+ Brex AI 整理
CWC long-running agents（Anthropic 公開、2026-05-07 議論）
Anthropic が Code with Claude 2026 イベントで公開した「長時間実行エージェント向けハーネス設計パターン集」（anthropics/cwc-long-running-agents）。CS Agentic AI Phase 1 の実装にあたり、設計の裏付け および 未カバー領域の補強 として参照する。
すでに BreX 設計でカバーできているもの:
- Default-FAIL Contract — 「本人確認 → Shopify API 実行」の順序ゲーティングは同じ思想（Phase 1 機能要件）
- Fresh-Context Evaluator — Phase 2 以降の Dual-Model Validation と同型
- Agent-Maintained Handoff — Phase 1 の単発チャット完結では不要（返品・交換が多発する Phase 2 以降で関係してくる）
設計に明示されていないギャップ（Phase 1 で補強候補）:
| パターン | 何が足りないか |
|---|---|
| Default-FAIL の実装 | プロンプト指示だけで本人確認前 API 実行を防いでいる。middleware / フックでコードレベルから強制する設計が未記述（LLM の確率的挙動依存になっている） |
| Kill-switch | 本番稼働中のエージェントを緊急停止する仕組みが未設計。誤キャンセル連発時に「システム全体を落とす」以外の手段がない |
| Steer（実行中の方針変更） | 自然言語ポリシーで近いことはできるが、エージェントが動いている最中にリアルタイム介入する手段が未設計 |
判断: Kill-switch は Phase 1 から必要（誤動作時のリスク対策）。AGENT_STOP 相当のフラグファイル + middleware 検査の最小実装を Phase 1 PRD に組み込み候補。Default-FAIL のコードレベル強制も Phase 1 実装フェーズで詰める。
開発パイプラインへの応用:
CS Agentic AI を Claude Code で開発する際は、cwc の commit-on-stop.sh / kill-switch.sh / steer.sh / Evaluator サブエージェント パターンがそのまま使える。
出典: 2026-05-07 Hanatsuka × Brex AI（Slack #general スレッド ts=1778114505.839199）
ゼロパーティデータ
活用構想
AIチャットボットを通じてゼロパーティデータ（顧客が自発的に提供する情報）を取得し、商品提案の質を高める。
- 顧客側は意図せず、事業者側は意図してデータを取れる仕組み
- 参考: Forbes — The Rise Of Zero-Party Data
出典: 2026-03-12 Yabumoto, Hatanaka（Slack #general スレッド）
技術設計検討（2026-04-07）
Hatanakaからの問い: ゼロパーティデータをどう貯める設計か？
- RDBにそのまま格納するか、ベクトルDBに格納するか
- アプリケーションレイヤーよりミドルウェアレイヤーの設計が地味だがわかりにくく、差別化のカギ
出典: 2026-04-07 Hatanaka（Slack #general スレッド）
CS自動化の方向性（2026-04-03〜04 林さんMTG由来）
AI×CS自動化
- 住所変更・キャンセル等の定型処理: Shopify API + Flow（RPA）+ カスタムアプリで自動完結
- 夜間・休日対応: 物流稼働前の深夜帯にAIが即時回答・処理 → 離脱防止 + 翌朝CSスタッフ負担軽減
- ハイブリッド運用: 確信度の高いものだけAI自動処理、不安な要素は人間にトスアップ
- 「助けてください」モード: 従来の「お困りですか？」ではなく、AI側が困っている逆アプローチでユーザーの善意を引き出しデータ収集
組織横断のブリッジ機能
- CS蓄積の「負の情報（要望・不満）」をAIが分析・要約 → マーケ・商品開発へ「内部施策提案」としてフィードバック
- 部署間依頼のハレーション防止（AIが最低限情報を整える「潤滑油」）
- BIツールに代わるAI自律分析（異なるセグメント間の相関、「お宝データ」の自動発見）
出典: 2026-04-03〜04 Hatanaka（Slack #general — 林さんMTG議事録、EC運営AI活用議事録）
事業計画関連の議論（2026-04-08〜13）
品質テスト方針
- E2Eテストは開発都度実施（本番環境で動いているかレベル）
- AI回答精度は短期では主観評価、中長期でテストセット+目標値の精度検証システム構築
- 精度系はR&D的要素を含むため愚直に取り組む必要あり
IP（知的財産）関連
- 意匠: ハードではないため不要
- 商標: プロダクト名が有名になりそうなタイミングで。来年予算に特許事務所への依頼を検討
- 特許: 今すぐは不要
- R&D専門担当を将来的に置きたい → KayamaがEC特化のAIモデル開発の可能性
出典: 2026-04-08〜13 Hatanaka, Hanatsuka（Slack #general スレッド + Notion 4/13 Weekly MTG議事録）
技術調査メモ
- チャットボット論文 — PDF（2026-01-21 Hanatsuka）
- HumanLM論文（Stanford大学、2026-03） — ユーザーシミュレーションで「内面からの模倣」を実現。arXiv
- プロンプトレビュー手法 — プロンプトをレビューし目的・意図の把握をチェック（2026-03-12 Hatanaka）
- Appier AIQUA — FOインターナショナルが導入。EC向けAIパーソナライゼーション。https://www.appier.com/ja-jp/products/aiqua
- Gemma 4 推論コスト調査（2026-04-21） — TakumuからKayamaへ依頼。Gemma 4をGCP上のサーバーで動かすと月次サーバーコストはどれくらいか。GCPで動作可能性は確認済み。CS Agentic AIで簡易タスク的な用途に使えるかを検討中。 model card
- 楽天API仕組み調査（2026-04-25〜、Hanatsuka担当） — 林さんからの依頼。楽天から送られてくる受注データをOMSに取り込む前に、楽天APIを叩いてログイン情報経由で受注データを抜けるかの仕組み調査。「OMSに取り込む前にエラーデータの確認や修正」をAIで実現したいというニーズ起点。
- 住所バリデーションPoC（2026-04-29、Yu Kayama担当） — Google Address Validation API でマキシム郵便エラー対応の実装可能性を検証。10件のテスト住所でAPI判定・エージェント応答を実行。結論「住所に関する部分でエージェント対応は十分可能」。郵便番号記載ミス検知の精度が最大の論点。詳細は
customers/maxim/partnership.md「4/29 住所バリデーションPoC」セクション。 - ネクストエンジン（OMS）アカウント取得（2026-04-28、Hanatsuka） — マキシム他で利用されるOMSの実物を触れる環境を確保。マキシム鳥観図/フローと突き合わせて理解を進める用途。
- 日本郵便 LP API（2026-04-29、Hanatsuka 共有FYI） — https://lp-api.da.pf.japanpost.jp/ 住所バリデーション/正規化の代替候補API。本格採用検討は未着手。
市場インサイト（プロダクト方針に影響したもの）
エージェンティックコマース（2026-03-25 セミナー）
- AIが商品の検索・比較・購入まで代行する「エージェンティックコマース」が台頭
- Google AIモード導入後: 1日の検索数が倍増、クエリは従来の3倍長く深い質問に
- Walmart (Sparky): 顧客単価35%向上。楽天トラベル: 受注単価26%向上
- UCP/ACP: 米国先行、日本はまだ未対応（審査制）。準備は必要
- BreXへの示唆: GEO対策は地道にやり続ける必要あり。UCP決済が日本に来たときにすぐ展開できるよう準備
出典: 2026-03-25 Notion MTG議事録 — Notion
Shopify利用規約 — AIエージェントへの言及（2026-03-23）
Shopifyのデフォルト利用規約にAIエージェントの記載あり:
- エージェントはHTTP/HTTPSリクエストでエージェントであることを明示する必要あり
- 人間の行動パターンの模倣やCAPTCHA回避は禁止
- 人間かコンピュータかを問われた場合は正直に回答する必要あり
出典: 2026-03-23 Yabumoto（Slack #general）
VOCデータ統合 — 金子氏ヒアリングからのインサイト（2026-03-24）
FOインターナショナルのヒアリングで、VOCデータの統合と活用が最大の課題として浮上:
- 顧客の声が複数チャネルに散在 → 連携・統合されず商品開発やMDに活かせていない
- チャットボットでのVOC収集 → データ統合 → AI分析 → 施策提案の流れが最も価値を感じる部分
出典: 2026-03-24 Notion MTG議事録 — Notion
企業規模別攻め方（2026-03-25）
| 企業規模 | 戦略 |
|---|---|
| 大企業（年商100億以上） | 既存ツールのリプレイスではなく隙間を埋めるツール導入から |
| 中堅企業（10億〜100億） | PDCA一気通貫系でリプレイス。パーツごとに導入 |
| SMB（年商10億以下） | 中堅向けの複雑機能を省いて激安に。SMBの成長と共にBreXも成長 |
出典: 2026-03-25 Hatanaka（Slack #general）
競合分析フレームワーク（5項目）
- 攻めるマーケットをずらす — 「リテラシーの低さ」「特有の商習慣」も切り口に
- 攻める機能をずらす — 競合が「やってなくて」「やりたがらない」が「課題がある」部分
- 攻める金額をずらす — ROI可視化しやすいプライシング
- 価値実感までの時間短縮 — 5分〜10分でWow!
- 既存市場に寄生して市場を拡大 — Shopifyアプリストア等
出典: 2026-03-07 Hatanaka（Slack #general スレッド）