越境ECチームが本当に困るのは ChatGPT のアカウント不足ではなく、5本の業務線がそれぞれ半自動な状態です。サポートは Helpdesk でコピペ、仕入れは表計算、広告は ROAS 監視、倉庫は ERP から出荷、AS はメールとマーケットプレイスチケットの往復。これらを AI Agent で監査可能な一本のパイプラインにするには、(1) 統一イベントバス（注文・メッセージ・広告指標をイベント化）、(2) ドメイン別 Agent と明確なツール権限、(3) 人間承認ゲート（返金・価格変更・出品停止・大きな予算変更）の三つです。
以下はゼロから本番までの順序：アーキテクチャとデータ契約、5つの Agent（サポート・仕入れ・広告・受注・AS）、オーケストレーション、可観測性、コンプライアンス。例は Shopify + Amazon Seller + Meta/Google Ads。Webhook + キュー + 任意の LLM でも可。ゲートウェイを 24/7 稼働させるなら、固定リージョンの Cloud Mac で cron とローカルスクリプトを動かし、業務 API は各プラットフォーム公式のままにします。
総合アーキテクチャ：イベントバス・オーケストレータ・ツール層
すべての API を一つの「スーパー Agent」に入れない。保守しやすいのは 薄いオーケストレーション + 厚いツール です：
- イベントバス：Kafka、Redis Streams、SQS、Postgres の
outboxなど。入站を JSON Schema に統一（order.created、ticket.opened、ads.campaign.overspend）。 - オーケストレータ：イベント種別で Agent Worker にルーティング；受注単位の状態機械（返信待ち → 出荷待ち → 例外 → 完了）。
- ドメイン Agent：各 Agent は自ドメインのツールのみ（サポートは KB、受注は WMS）；読み取り専用の顧客プロファイルを共有。
- 承認キュー：返金・価格変更・出品停止・予算が閾値超は
pending_approvals；Slack/飞书カード承認後に実行。
データと認証情報：単一の正を固定
Agent が誤回答するのは多くの場合データ分岐。リリース前に最低限：
- 商品マスタ：SKU、バリエーション、通関申告、禁輸国—ERP/PIM が正、ストア管理画面は読み取り同期。
- 受注状態：マーケットプレイス注文 ID ↔ 内部
order_id↔ 追跡番号のマッピング表；Agent はマッピング層のみ照会。 - 顧客タイムライン：メール、サイト内メッセージ、WhatsApp、マーケットプレイスメッセージを同一
customer_idに。 - 秘密情報：Shopify Admin API、Amazon SP-API、Meta Marketing API のトークンは Vault/KMS；実行時に短期トークン交換—プロンプトに書かない。
各 Agent の出力を構造化（intent、confidence、proposed_actions[]）。自由文は人間向け、オーケストレータは JSON のみ解析し再生・監査可能に。
サポート Agent：マルチチャネル意図・KB・エスカレーション
入力：Gorgias、Zendesk、Shopify Inbox、Amazon Buyer-Seller Messaging などの webhook。ツール：政策 KB（返品日数・保証）、物流照会、チケットメモ。方針：
- 意図分類：物流照会 / 欠品 / 品質 / キャンセル / レビュー威嚇—各意図にアクション白名单。
- RAG KB はバージョン管理：政策変更でバージョンを上げ、旧スレッドに新規則を混ぜない。
- 低信頼度や感情激化 →
escalate_to_human、Agent が取得済みの注文事実を添付。
返信言語は買い手のストア言語に合わせる；多言語でも構造化意図は一つ、言語ごとに Agent を分けない。
仕入れ Agent：シグナル・スコア・人間プール
仕入れ Agent は「出品承認」ではなく情報圧縮：トレンド、競合価格、粗利、コンプライアンスリスクを決裁カードに。
- シグナル：マーケットトレンド、第三者売上推定、広告ライブラリ、簡易特許・商標検索（最終は弁護士）。
- スコア：ルール + LLM 要約；
score、risks[]、suggested_moq。 - 人間プール：スコアが閾値超は「仕入れ会議」ボード；Agent は競合比較表を書くが発注書は自動作成しない。
広告 Agent：クリエイティブ・入札・異常時の遮断
広告は最も予算を燃やす領域。権限は読み多く書き少なく：
- 読み取り監視：毎時キャンペーン spend、CTR、ROAS；急増・CTR 急落は
ads.anomaly。 - 提案モード：「予算削減 / 素材差し替え / オーディエンス拡大」カード—既定は予算自動変更なし。
- 自動モード（任意）：ROAS > 目標かつ spend < 日上限のみ ±5% 微調整；増額は承認必須。
- 文案は別ジョブ：headline + primary text を3セット；人間が選んで Meta/Google に投入。
受注 Agent：フルフィルメント・例外・照合
order.paid、inventory.low、shipment.exception を監視：
- 住所検証（郵便番号、離島追加料）、ブラックリスト、重複注文。
- 倉庫ルーティング：在庫・SLA・頭程コスト；欠品は分割出荷またはサポート Agent が購入者に通知。
- 追跡番号をストア・マーケットプレイスに書き戻し；例外は AS 準備チケット。
- 日次照合：マーケットプレイス精算 ↔ 決済ゲートウェイ ↔ ERP 売掛、差異が閾値超でアラート。
AS Agent：RMA・返金・プラットフォーム紛争
AS はサポートと顧客タイムラインを共有するがツールはより敏感：
- RMA：返品期間・開封・越境返送可否—
approve_rma提案、実行は承認後。 - 返金：一部 / 全額 / 送料の段階を政策表に；Agent は金額提案のみ。
- 紛争：Amazon A-to-z、PayPal dispute—証拠パック（配送証明、チャット、政策スクショ）を人間が提出。
オーケストレーション：n8n / 自前FSM / Agent フレームワーク
| 方式 | 向くケース | 注意 |
|---|---|---|
| n8n / Make | 10人未満、Webhook 多、スピード重視 | 複雑な状態機械はスパゲッティ—JSON を Git 管理 |
| Temporal / 自前FSM | 長い受注フロー、信頼できるリトライ | 開発コスト高、受注/AS コア向き |
| LangGraph 等 | 単一ドメインの多段推論 | ドメイン間はイベントバス、一つのグラフに全部載せない |
| OpenClaw 等多チャネルゲートウェイ | 承認・告警を Telegram/Slack に | ゲートウェイはメッセージとツールルーティング、業務状態は自社 DB |
推奨：1週目 n8n で「新規チケット → 注文照会 → 草稿返信」；2–3週目 受注状態機械をコードへ；4週目 広告の読み取り監視。
可観測性・コスト・セキュリティ基線
- トレース：各呼び出しに
trace_id、モデル、トークン、ツール名、承認発火。 - 再生：入力イベント + 構造化出力を保存し紛争時に「政策通り」と証明。
- コスト：サポート分類は小モデル、文案は大モデル；仕入れ/広告ダイジェストはバッチ。
- コンプライアンス：GDPR/個人情報の最小化；偽レビュー・順位操作禁止—アクション白名单は法務が読める形で。
4週間ロードマップ
- 1週目：イベント schema + 受注/顧客マッピング；サポートは読み取り照会 + 草稿（人間送信）。
- 2週目：受注 Agent の自動倉庫ルート + 追跡書き戻し；例外は AS 準備へ。
- 3週目：仕入れ日報 + 広告異常アラート；Slack/飞书で承認フロー。
- 4週目：AS の RMA 提案 + 照合差異アラート；エンドツーエンド trace と週次 ROAS/CSAT。
FAQ
構造化 FAQ はページ JSON-LD にあります。要約：一つの Agent で全部？、Shopify と Amazon の共通サポート？、広告の完全自動？、プロンプト注入対策、オーケストレーションの稼働場所。