Sidekick が「AI 検証済み」の ストアフロント改善案を出してくれる

図解 ： Sidekick の「AI 検証済みストアフロント提案」 Sidekick / 新機能 Sidekick が「AI 検証済み」の ストアフロント改善案を出してくれる Sidekick が改善点を見つけ、変更のドラフトを作り、AI がシミュレートした買い物客で今のストアフロントと比べる。実際の買い物客で試すわけではなく、反映するかどうかは提案を確認したうえでマーチャントが決める。 このページの構成 そもそも何ができるのか（30秒で理解） 仕組み図解 ： 提案が届くまでの流れ シミュレーションの対象になる変更 AI シミュレーション vs 実際の A/B テスト 利用条件 マーチャント側の流れ（3ステップ） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何ができるのか Sidekick が 「改善点の特定 → 変更ドラフトの作成 → AI シミュレーションで現状と比較」 までやってくれる。 マーチャントは結果付きの提案を確認し、 反映するかどうかを自分で決めるだけ 。 見つける ストアフロントで改善できそうな箇所を Sidekick が特定する。 ドラフトを作る 変更内容をドラフト版として作成。いきなり本番には出ない。 AI で比べる AI がシミュレートした買い物客を使い、現在のストアフロントと比較する。 2 仕組み図解 ： 提案が届くまでの流れ 「AI がシミュレートした買い物客」 で比較するので、実際の来訪者にドラフトが見えることはない。 シミュレーションの具体的な手法、評価指標、提示される結果の形式は記事に記載なし。 3 シミュレーションの対象になる変更 Sidekick がシミュレーションにかける変更は、次の 2 条件 を満たすもの。 条件 1 ストアフロントのテーマ変更としてテストできる テーマ側の変更として表現できる改善が対象。 条件 2 カート追加の行動に影響しそう add-to-cart（カート追加）に影響すると見込まれる変更が選ばれる。 テーマ変更で表現できない改善や、カート追加以外の指標（購入完了・客単価など）に関わる変更がどう扱われるかは記事に記載なし。 4 AI シミュレーション vs 実際の A/B テスト 項目 Sidekick の AI シミュレーション 実際の A/B テスト（参考） 誰で試すか AI AI がシミュレートした買い物客 実際の来訪者 本番への露出 なし 実際の買い物客ではテストしない ライブで一部の来訪者に表示 位置づけ ライブ A/B ではない と明記 ライブ A/B テスト 変更案の作成 自動 Sidekick がドラフトを作る 自分で用意 反映の判断 マーチャントが確認してから決める 結果を見て自分で決める 追加コスト 記載なし — 5 利用条件 Sidekick を使えること Sidekick の機能として提供される。 対象プラン・地域・言語 記載なし。 詳細は Shopify Help Center を参照するよう案内されている。導入前に、自分のストアの管理画面で Sidekick がこの提案を出すかどうか確認すること。 6 マーチャント側の流れ（3ステップ） 1 Sidekick の提案を受け取る AI シミュレーションで現状と比べた改善案が届く。 2 提案された変更を確認 ドラフトの中身を自分の目でレビューする。 3 反映するかを決める 納得できたら適用。自動で本番に出ることはない。 最終判断はマーチャント側に残る。 Sidekick は提案とドラフトまでで、適用するかどうかは確認してから決める流れ。具体的な UI 操作手順は記事に記載なし。 7 技術者が押さえるべき5つのポイント 1. 変更の単位は「テーマ変更」 シミュレーション対象はストアフロントのテーマ変更として試せるものに限られる。テーマの外（アプリ・チェックアウト等）の変更が対象になるかは記載なし。 2. 評価軸はカート追加 add-to-cart に影響すると見込まれる変更が選ばれる。購入完了率や売上への影響を示すものではない点は区別して扱う。 3. 実ユーザーの検証ではない 実際の買い物客ではテストせず、ライブ A/B テストでもないと明記されている。結果は「事前の当たり付け」として扱うのが妥当。 4. 本番に出る前にドラフトで止まる Sidekick はドラフト版を作り、マーチャントの確認を経て適用される。ドラフトがテーマ管理上どう保存されるか（未公開テーマ等）は記載なし。 5. API・テーマ開発フローとの関係は記載なし API での操作、Git 連携しているテーマとの衝突、カスタムテーマでの挙動などは記事に記載がない。 テーマをコードで管理している案件では、Sidekick が作ったドラフトを適用する前に差分を確認する運用 を決めておく必要がある。 8 業務に活かせる3つのユースケース USE CASE 1 本番 A/B テストの前に「試す価値のある案」を絞り込む 課題 ストアフロント改善案はたくさん出るが、流入の少ないストアでは実際の A/B テストで全部を検証する余裕がない。 打ち手 Sidekick の AI シミュレーションで現状と比べた案を先に見て、手応えのあるものだけを実際の検証や本番反映に回す。 効果 実際の来訪者を使う前に案を絞り込め、検証にかける時間と流入を節約できる。 技術メモ シミュレーションはライブ A/B テストではないと明記されている。売上インパクトの根拠にするなら、反映後の実測とあわせて見る。 USE CASE 2 制作会社がいない小規模ストアの「改善のきっかけ」に 課題 社内に UI/UX の担当者がおらず、何を直せばカート追加が増えるのか分からないまま、ストアフロントが手つかずになっている。 打ち手 Sidekick に改善点の特定とドラフト作成を任せ、マーチャントは提案を確認して反映するかを判断するだけにする。 効果 専門知識がなくても、比較結果付きの具体的な改善案から始められる。 技術メモ 反映前に必ず提案の中身を確認するフローになっている。ブランド表現に関わる変更かどうかは人が判断する。 USE CASE 3 受託案件で、Sidekick の提案をレビュー付きで運用に組み込む 課題 クライアントが Sidekick の提案を独自に適用すると、制作会社が管理しているテーマとの整合が取れなくなるおそれがある。 打ち手 「Sidekick の提案は適用前に制作側がドラフトを確認する」というルールを運用保守契約に入れ、確認済みのものだけ反映する。 効果 AI による改善提案のスピードを活かしつつ、テーマの品質と管理状態を保てる。 技術メモ ドラフトの保存形式や Git 連携テーマでの扱いは記事に記載なし。導入時に検証用ストアで挙動を確認しておく。 9 提案で使える1行サマリ 「Sidekick が改善点の特定からドラフト作成、AI の買い物客での比較までを担う新機能。 実際の来訪者には見せずに、カート追加に効きそうなテーマ変更を事前に見極められる。 ライブ A/B テストではないので、最終判断と実測はマーチャント側で。」 source ： changelog.shopify.com / get-ai-tested-storefront-recommendations-from-sidekick published 2026-10-28