Sidekick / 新機能

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

Sidekick が改善点を見つけ、変更のドラフトを作り、AI がシミュレートした買い物客で今のストアフロントと比べる。実際の買い物客で試すわけではなく、反映するかどうかは提案を確認したうえでマーチャントが決める。

このページの構成
  1. そもそも何ができるのか(30秒で理解)
  2. 仕組み図解 : 提案が届くまでの流れ
  3. シミュレーションの対象になる変更
  4. AI シミュレーション vs 実際の A/B テスト
  5. 利用条件
  6. マーチャント側の流れ(3ステップ)
  7. 技術者が押さえるべき5つのポイント
  8. 業務に活かせる3つのユースケース
  9. 提案で使える1行サマリ

1そもそも何ができるのか

Sidekick が 「改善点の特定 → 変更ドラフトの作成 → AI シミュレーションで現状と比較」 までやってくれる。
マーチャントは結果付きの提案を確認し、反映するかどうかを自分で決めるだけ。

見つける

ストアフロントで改善できそうな箇所を Sidekick が特定する。

ドラフトを作る

変更内容をドラフト版として作成。いきなり本番には出ない。

vs

AI で比べる

AI がシミュレートした買い物客を使い、現在のストアフロントと比較する。

2仕組み図解 : 提案が届くまでの流れ

① 改善点を特定 Sidekick が ストアフロントを確認 ② ドラフト作成 テーマ変更として 変更版を用意 ③ AI シミュレーション 現在 vs ドラフト AI の買い物客で比較 ④ マーチャント確認 提案された変更を レビュー ⑤ 反映するか マーチャントが 判断して適用 ①〜③ は Sidekick が担当 / ④⑤ はマーチャントの判断
「AI がシミュレートした買い物客」で比較するので、実際の来訪者にドラフトが見えることはない。
シミュレーションの具体的な手法、評価指標、提示される結果の形式は記事に記載なし。

3シミュレーションの対象になる変更

Sidekick がシミュレーションにかける変更は、次の 2 条件を満たすもの。

条件 1

ストアフロントのテーマ変更としてテストできる

テーマ側の変更として表現できる改善が対象。

条件 2

カート追加の行動に影響しそう

add-to-cart(カート追加)に影響すると見込まれる変更が選ばれる。

テーマ変更で表現できない改善や、カート追加以外の指標(購入完了・客単価など)に関わる変更がどう扱われるかは記事に記載なし。

4AI シミュレーション 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 テストでもないと明記されている。結果は「事前の当たり付け」として扱うのが妥当。

DRAFT

4. 本番に出る前にドラフトで止まる

Sidekick はドラフト版を作り、マーチャントの確認を経て適用される。ドラフトがテーマ管理上どう保存されるか(未公開テーマ等)は記載なし。

API ?

5. API・テーマ開発フローとの関係は記載なし

API での操作、Git 連携しているテーマとの衝突、カスタムテーマでの挙動などは記事に記載がない。テーマをコードで管理している案件では、Sidekick が作ったドラフトを適用する前に差分を確認する運用を決めておく必要がある。

8業務に活かせる3つのユースケース

AI
USE CASE 1

本番 A/B テストの前に「試す価値のある案」を絞り込む

課題
ストアフロント改善案はたくさん出るが、流入の少ないストアでは実際の A/B テストで全部を検証する余裕がない。
打ち手
Sidekick の AI シミュレーションで現状と比べた案を先に見て、手応えのあるものだけを実際の検証や本番反映に回す。
効果
実際の来訪者を使う前に案を絞り込め、検証にかける時間と流入を節約できる。
技術メモ
シミュレーションはライブ A/B テストではないと明記されている。売上インパクトの根拠にするなら、反映後の実測とあわせて見る。
USE CASE 2

制作会社がいない小規模ストアの「改善のきっかけ」に

課題
社内に UI/UX の担当者がおらず、何を直せばカート追加が増えるのか分からないまま、ストアフロントが手つかずになっている。
打ち手
Sidekick に改善点の特定とドラフト作成を任せ、マーチャントは提案を確認して反映するかを判断するだけにする。
効果
専門知識がなくても、比較結果付きの具体的な改善案から始められる。
技術メモ
反映前に必ず提案の中身を確認するフローになっている。ブランド表現に関わる変更かどうかは人が判断する。
diff
USE CASE 3

受託案件で、Sidekick の提案をレビュー付きで運用に組み込む

課題
クライアントが Sidekick の提案を独自に適用すると、制作会社が管理しているテーマとの整合が取れなくなるおそれがある。
打ち手
「Sidekick の提案は適用前に制作側がドラフトを確認する」というルールを運用保守契約に入れ、確認済みのものだけ反映する。
効果
AI による改善提案のスピードを活かしつつ、テーマの品質と管理状態を保てる。
技術メモ
ドラフトの保存形式や Git 連携テーマでの扱いは記事に記載なし。導入時に検証用ストアで挙動を確認しておく。

9提案で使える1行サマリ

「Sidekick が改善点の特定からドラフト作成、AI の買い物客での比較までを担う新機能。
実際の来訪者には見せずに、カート追加に効きそうなテーマ変更を事前に見極められる。
ライブ A/B テストではないので、最終判断と実測はマーチャント側で。」