Shopify Sidekickは、デフォルトの状態ではすべてのサードパーティ製Shopifyアプリ（外部プラグイン）のデータを自動的に参照したり、アプリ間を自律的にオーケストレーション（統合制御）したりすることはできません。 基本設定のSidekickは、商品カタログ、注文履歴、顧客プロファイル、ディスカウント設定、ShopifyQLによる分析データなど、Shopifyの「ネイティブストアデータ」の範囲内でのみ動作します。ただし、サードパーティ製アプリの開発者が公式の**Sidekick App Extensions（Sidekick アプリ拡張機能）**を実装している場合、またはアプリのデータがShopifyのネイティブなメタフィールド（Metafields）やタグに保存されている場合は、Sidekickを介してそのデータを参照し、操作を誘導することが可能です。
定期購入（サブスクリプション）、カスタマーサポート（CSツール）、外部在庫管理（ERP）、MAツールなど多様なSaaSを組み合わせている中〜大規模マーチャントにとって、Sidekickの正確なデータアクセス範囲とオーケストレーションの限界を把握しておくことは不可欠です。
コアデータの境界線：Sidekickがアクセスできる4つの階層
ストア管理画面におけるSidekickのデータアクセス権限は、以下の4つのレイヤーに明確に分類されます。
| データ層 | Sidekickのアクセス可否 | 実現メカニズム | 具体的な活用例 |
|---|---|---|---|
| 第1層：Shopifyネイティブコア | 完全・直接（双方向の読み書き） | ネイティブAdmin API / GraphQLデータモデル | 総売上の集計；顧客セグメントの作成；割引コードの発行；下書き注文の修正 |
| 第2層：ネイティブ構造内のアプリデータ | 間接的に完全対応（自動連携） | ShopifyネイティブのMetafields、Metaobjects、Tags | ERP同期ステータスタグの確認；カスタムアプリが記録したメタフィールドの分析 |
| 第3層：Sidekick拡張対応アプリ | スコープ制限・セッション承認制 | Sidekick App Extensions（tools および intents） | メルマガ配信の成果確認；設定変更画面へのディープリンクと下書き作成 |
| 第4層：未対応/外部独立SaaS | アクセス不可（完全なデータ分離） | なし（外部SaaSの独自データベース内に隔離） | 外部CSツールの問い合わせ履歴参照；外部3PLの入出荷ログ確認；Meta広告費の算出 |
1. ネイティブストアデータ（直接アクセス）
Sidekickは、Shopify管理画面の標準オブジェクトに対して完全なアクセス権を持ちます。
- 商品カタログ、バリエーション、在庫数、コレクション
- 注文履歴、フルフィルメント状況、返金履歴、下書き注文
- 標準ディスカウント、ギフトカード、顧客セグメント
- ShopifyQLを用いたカスタムレポートの生成、Shopify Balanceの口座情報確認
2. ネイティブ構造に保存されたアプリデータ（「見えない架け橋」）
多くの優れたShopifyアプリは、独自の外部データベースにのみデータを保持するのではなく、主要なフラグや属性をShopifyのメタフィールド（Metafields）、メタオブジェクト（Metaobjects）、あるいは**タグ（Tags）**として書き戻す設計を採用しています。
- これらのデータは物理的にShopifyのコアデータベースに存在するため、アプリ側がSidekick専用の拡張機能を開発していなくても、Sidekickはそれらの値をネイティブデータと同様に読み取り、検索し、更新できます。
- 具体例： 予約注文アプリが未発送注文に
PreOrder-Batch-Aというタグを付与し、発送予定日をメタフィールドに記録している場合、マーチャントが「バッチAの未発送予約注文は何件ありますか？」とSidekickに尋ねれば、Sidekickは正確に件数を集計して回答します。
3. Sidekick App Extensionsを導入したアプリ（管理されたアクセス）
アプリが独自のサーバーにのみデータを保持している場合（例：メール配信サービスの到達率、外部チケット管理システムの満足度スコアなど）、アプリ開発者がSidekick App Extensionsを構築していない限り、Sidekickはそのデータを閲覧できません。
- データ拡張（Data Extensions）： 外部アプリ内のデータをSidekickから検索・要約できるようにします（ポイント残高の照会やキャンペーン成果の確認など）。
- アクション拡張（Action Extensions）： Sidekickからアプリ内のアクションを起動します。
admin.app.intent.link（文脈を引き継いだアプリ全画面への遷移）やadmin.app.intent.render（管理画面内でのモーダル表示）により、Sidekickが設定変更の下書きを提示し、マーチャントの承認を促します。 - 厳格な制限： Shopifyの仕様により、1つのアプリにつき最大5つのインテント（Intents）と20のツール（Tools）に制限されており、AIの誤動作を防ぐ設計となっています。
4. 拡張機能を持たない外部SaaS（完全な隔離）
開発者がSidekick拡張機能を公開していないアプリや、Shopifyの枠外にあるエンタープライズツール（外部NetSuite ERP、Salesforce CRM、Google / Meta広告管理画面など）に対して、Sidekickは一切アクセスできません。広告費と連携させた総合ROAS（Blended ROAS）の算出や、外部ツールのチケット調査をSidekickに依頼することは不可能です。
オーケストレーションと自動化の違い：SidekickはShopify Flowではない
多くの運用担当者が「AIによる統合制御」を期待しますが、Sidekickとバックグラウンド自動化ツールではアーキテクチャの役割が根本から異なります。
[ マーチャントの対話指示 ] ──► [ Sidekick（対話型AIアシスタント） ]
│
┌──────────────────────────┴──────────────────────────┐
▼ ▼
[ 即時タスクの実行 / 下書き確認 ] [ 自然言語から自動化ロジックを生成 ]
(人間のクリック承認が必須) │
▼
[ Shopify Flow 自動化エンジン ]
│
(24時間365日の完全自動トリガー)
│
┌─────────────────────────────────┴─────────────────────────────────┐
▼ ▼
[ アプリA：在庫管理 ] [ アプリB：CRM/メール ]
Sidekickの本質：人間の承認を前提とする対話型Copilot
- セッション依存： Sidekickは管理画面のサイドバーを開いて対話している間のみ動作します。チャットを閉じるとその処理コンテキストは終了します。
- ヒューマンインザループ（Human-in-the-Loop）： Sidekickがマーチャントの許可なく、複数のアプリを跨いで勝手にデータを書き換えることはありません。在庫変更や価格改定などの操作は、必ず「下書き（Draft）」として提示され、人間の最終確認を要求します。
- セッション単位の認証： 拡張機能を持つアプリのデータを参照する際も、その会話スレッド内でのマーチャントによる明示的な許可が必要です。
Shopify Flowの本質：24時間稼働するイベント駆動型自動化エンジン
- 「返品アプリで申請が発生したら、ERPで在庫を確認し、Klaviyoで交換手続きメールを自動送信する」といった無人でのアプリ間連携には、Shopify Flowが適しています。
- SidekickとFlowの相乗効果： SidekickはFlowと競合するのではなく、Flowの設計支援を行います。「購入金額が5万円以上の顧客にVIPタグを付け、ロイヤルティアプリに通知するFlowを作成して」とSidekickに指示すれば、Sidekickがワークフローの骨組みを作成し、実際の無人実行はShopify Flowが担います。
セキュリティ、権限管理、データガバナンス
中〜大規模ブランドやShopify Plusマーチャントにとって、AIの導入には厳格なセキュリティ要件が伴います。Sidekickには以下の保護機能が組み込まれています。
- スタッフ権限の厳格な継承（RBAC）： Sidekickはログイン中のスタッフアカウントの権限に厳密に従います。財務情報や顧客の個人情報（PII）の閲覧権限がないスタッフに対して、Sidekickがそれらのデータを勝手に出力することはありません。
- 一時的なアプリ認可： サードパーティ製アプリへのアクセス許可は会話セッション内に限定され、バックグラウンドで永続的なデータ収集パイプラインが勝手に作られることはありません。
- ストア単位のデータ分離： ストア固有のデータは現在の環境内でのみ処理され、競合他社が利用する公開基盤モデルの学習データとして流用されることはありません。
- 下書き優先の安全設計： 大量更新や設定変更は必ずプレビュー形式で提示され、自然言語の解釈違いによる誤操作を未然に防ぎます。
現場のEC責任者・エンジニアに向けた推奨アクション
Sidekickの強みを活かしつつ、データの断絶を避けるための実践的なステップは以下の通りです。
1. アプリのデータ保持構造を確認し、ネイティブ保存を優先する
アプリの選定や自社開発においては、重要な業務ステータスや属性をShopifyのメタフィールド、メタオブジェクト、タグに書き戻す仕様のものを優先してください。これにより、追加の開発を行わなくてもSidekickから直接検索・活用できるようになります。
2. 主要SaaSベンダーにSidekick App Extensionsの対応を要請する
定期購入やレビュー、CS管理などの基幹アプリについて、ベンダーがSidekick App Extensions（特に admin.app.intent.link や admin.app.intent.render）をサポートしているか確認し、対応を働きかけましょう。
3. 「対話はSidekick、無人実行はFlow」と明確に使い分ける
Sidekickのチャット画面で定型的なバッチ処理を再現しようとすべきではありません。日常のインサイト分析、コンテンツ作成、Flowのワークフロー設計はSidekickに任せ、複数システム間の常時バックグラウンド連携はShopify Flowに委託してください。
4. 総合的な全社分析には独立したBI環境を維持する
Shopifyの売上、広告媒体（Meta/Google）の広告費、外部3PLの物流コストなどを網羅した統合分析が必要な場合、Sidekickを単一のデータウェアハウスとして期待するのは適切ではありません。BigQueryや専用のEC分析ツールによるデータパイプラインを維持し、Sidekickは管理画面内での迅速な意思決定と実行アシスタントとして活用するのが理想的です。