あなたのプラットフォーム。同じチーム。
エージェントは特定カートに書かれていません。仕事——ページ、分析、可視性、リテンション、運用——はどこでも同じで、違うのは接続方法だけです。
プラットフォームページがある理由：実際の質問は「AI エージェントは有用か」ではなく「自分のスタックで実際に何ができるか」だからです。答えは正直にプラットフォームで異なります：Shopify は最深のネイティブ接続、WooCommerce とヘッドレスは git 経由の完全なページ作業、マーケットプレイスは出品レベルの作業。以下の各ページは、何が接続され、各エージェントがそこで何をでき、何ができないかを正確に記述します。
Shopify
最深の接続：カタログ・テーマ・注文、ドラフト優先の公開。
詳しく見る →WooCommerce
分析・SEO・メールはフル対応——ページ作業は WordPress スタック経由。
詳しく見る →BigCommerce
大規模カタログ向けプラットフォームでの、カタログ SEO・ファネル分析・ライフサイクルメール。
詳しく見る →Adobe Commerce
Magento 級の複雑さに向けた、カタログと性能の規律。
詳しく見る →Wix
「作って終わり」を卒業した Wix ストアの発見可能性と転換。
詳しく見る →Squarespace
デザイン主導の Squarespace ストアに成長の規律を——可視性、ファネル、メール。
詳しく見る →Amazon セラー
マーケットプレイス第一のセラーへ：出品品質、レビューシグナル、外部の引用可能資産。
詳しく見る →Etsy セラー
出品の発見可能性、物語のあるコピー、そしてマーケットプレイスの外の資産。
詳しく見る →ヘッドレスコマース
git で働き、CI を尊重し、エッジを一級の面として扱うエージェント。
詳しく見る →B2B・卸売
転換が問い合わせで、買い手が企業である RFQ 駆動サイト。
詳しく見る →プラットフォームで変わるもの、変わらないもの
分析、検索可視性、メール、エッジ性能はどこでも同じに動きます——GA4、GEOly AI、Klaviyo、Cloudflare はページを誰がレンダリングするか気にしません。変わるのは Builder の公開方法：ネイティブのストア接続か、git ワークフローか、プラットフォームのコンテンツ画面か。
マルチチャネルは例外でなく標準
成長中の事業者の多くは、主ストアに 1〜2 のマーケットプレイスを足して運営します。エージェントはメモリ層を共有するため、同じ商品事実・発見・キャンペーンロジックがチャネル横断で通用し、ストアページと出品が乖離しなくなります。
よくある質問
最も深く対応するのは？
Shopify——ネイティブ接続でカタログ・テーマ・注文へ。ヘッドレスと git ベースの構築が続きます。Builder が通常の開発フローで働けるからです。
自分のプラットフォームがない。使えますか？
ストアが GA4 を公開し、Cloudflare の背後にあり、または git でデプロイできるなら、チームの大半はすでに動きます。スタックを教えてください。何が動き何が動かないか正確に答えます。
2 つのプラットフォームを同時に扱えますか？
扱えます——それが使う強い理由の 1 つです。1 つの共有メモリ層が「ストア＋マーケットプレイス」で商品事実と発見を一貫させます。手作業のプロセスが崩れるのはまさにそこです。
後でプラットフォームを変えたら全部やり直し？
いいえ。発見、監査履歴、作業パターンは共有メモリ層にあり、プラットフォーム接続にはありません。移行は Builder の向き先を変えるだけで、残りは引き継がれます。