「楽天市場で売上は立っているが、利益が残らない」「BASEで始めたが、やりたい施策がことごとく実装できない」——こうした行き詰まりの先に、多くのEC事業者がShopifyへの移行を検討します。しかし移行は、カートを乗り換えるだけの作業ではありません。移行とは、これまで外部プラットフォームに預けていた「顧客との関係」と「販売の設計権」を自社に取り戻す事業判断です。本記事では、移行の定義から、データ移管の可否、SEOを落とさない設計、費用構造、そして移行すべきでないケースまでを、実務レベルで解説します。
Shopifyへの移行とは何か
この定義で重要なのは「引き継ぎながら」と「主導権を移す」の2点です。単にデータをコピーして新しいサイトを立ち上げるだけなら、それは移行ではなく新規出店です。既存の売上・顧客・検索流入という資産を毀損せずに移すからこそ移行と呼べます。逆に言えば、この3つの資産のどれかを大きく失う移行は、技術的には完了していても事業的には失敗です。
まず前提として、移行には性質の異なる2つのパターンがあることを整理しておきます。
① モールからの移行（楽天・Amazon・Yahoo!）
顧客リストがモール側に帰属しているため、顧客データを持ち出せないのが最大の制約。実質的には「ゼロから自社顧客基盤を作り直す」に近く、モールは残したまま並行運用するのが定石です。
② ASPカートからの移行（BASE・STORES・MakeShop等）
独自ドメインで運用していれば顧客データもURLも自社資産。CSVで顧客・商品・注文を出力でき、301リダイレクトも設定可能。技術的な難易度は高いが、資産の引き継ぎ率は高くなります。
③ Shopify内でのリプレイス
Shopifyのまま、テーマ・アプリ構成・情報設計だけを作り直すケース。データ移管は不要ですが、URL構造とアプリ依存の棚卸しが論点になります。
この3つを混同したまま「移行」という一語で議論すると、見積もりも工数も的外れになります。制作会社に相談する前に、自社がどのパターンなのかを必ず確定させてください。
用語解説：この記事で使う専門用語
| 用語 | 意味 |
|---|---|
| ASPカート | Application Service Provider型のカートシステム。BASE、STORES、MakeShop、カラーミーショップなど、月額課金でネットショップ機能を借りる形態。 |
| 301リダイレクト | 旧URLから新URLへ「恒久的に移転した」とブラウザと検索エンジンに伝える転送設定。検索評価の大半を引き継げる唯一の正規手段。 |
| ハンドル（handle） | Shopifyにおける商品・コレクション・記事のURL識別子。旧サイトのURL構造と揃えるか否かが移行設計の分岐点になる。 |
| コレクション | Shopifyの商品グルーピング機能。一般的なECの「カテゴリ」に相当するが、条件による自動振り分け（自動コレクション）が可能。 |
| メタフィールド | Shopify標準項目にない独自データ（成分表、サイズ詳細、産地など）を商品や顧客に持たせる拡張領域。移行時の受け皿として重要。 |
| LTV | Life Time Value。1人の顧客が取引期間全体でもたらす利益の総額。モール依存からの脱却を判断する際の中心指標。 |
| CVR | Conversion Rate。訪問者のうち購入に至った割合。移行前後で必ず比較すべき指標。 |
なぜ今、Shopifyへの移行が起きているのか（業界構造の話）
移行の相談が増えている背景には、個社の事情を超えた構造変化があります。感情論ではなく構造で捉えると、判断を誤りにくくなります。
構造①：モール手数料の逓増
モールの手数料は、システム利用料・決済手数料・ポイント原資・広告費を合算すると、実質的に売上の15〜30%規模に達することが珍しくありません。売上が伸びるほど固定費ではなく変動費として利益を圧迫します。
構造②：顧客データの非保有リスク
モールでは購入者のメールアドレスや購買履歴を自由に活用できません。「売った相手が誰か分からない」状態では、リピート施策もLTV改善も設計不能になります。
構造③：広告費の高騰と自社チャネルへの回帰
新規獲得単価が上昇し続ける中、既存顧客への再販が利益の主戦場になりました。再販にはメール・LINE・会員制度といった自社チャネルが必須で、それはモール上では作れません。
構造④：ASPカートの機能上限
BASEやSTORESは立ち上げの速さが強みですが、定期購入・複雑な会員ランク・海外多通貨・在庫連携などで上限に当たります。売上の伸びが、カートの仕様で頭打ちになる局面が訪れます。
つまり移行とは、「手数料の変動費を減らし、顧客資産を自社に蓄積し、施策の自由度を回復する」ための構造転換です。逆に言えば、この3つのいずれにも困っていない事業者は、移行を急ぐ必要がありません。ここは正直にお伝えしておきます。
移行プロジェクトの全体像：5つのフェーズ
移行は「作る」工程よりも「決める」工程と「検証する」工程が長くなります。実務上は次の5フェーズで進行します。
現状棚卸しと移行方針の確定
現行サイトの商品数・バリエーション数・カテゴリ構造・URL一覧・会員数・注文件数・使用中の外部連携（在庫管理、受注管理、会計、物流）をすべて洗い出します。ここで漏れたものは、後工程で必ず追加費用として跳ね返ります。
情報設計とデータマッピング
旧サイトの各項目をShopifyのどの器（商品、バリエーション、コレクション、メタフィールド、タグ）に入れるかを1対1で対応表にします。この対応表が移行の設計図であり、ここの精度が移行品質の8割を決めます。
構築とデータ投入
テーマ実装、アプリ選定、決済・配送設定を進めながら、商品・顧客・注文データを投入します。データ投入は必ず「テスト環境で全件 → 検証 → 本番」の順で行い、いきなり本番投入はしません。
リダイレクト設計と切替（カットオーバー）
旧URL→新URLの301リダイレクト表を作成し、DNS切替と同時に適用します。切替は受注が少ない曜日・時間帯を選び、切り戻し手順を用意した上で実行します。
監視と回復
Search Consoleのインデックス状況、404発生数、CVR、検索流入を毎週定点観測します。移行直後は一時的に順位が揺れるのが正常であり、この期間に慌てて設計を触ると回復が遅れます。
全体でおよそ3〜6か月。商品数が数千点規模、あるいは基幹システムとの連携がある場合は6か月以上を見込みます。「1か月で移行したい」という要望は、ほぼ確実にPHASE 1と2を省略することになり、それは移行事故の直接原因になります。
データ移管の実務：何が移せて、何が移せないか
移行相談で最も誤解が多いのがここです。「全部移せます」と言う会社は信用しないでください。技術的に移せないものは確実に存在します。
| データ種別 | ASPカートから | モールから | 実務上の注意 |
|---|---|---|---|
| 商品基本情報（名称・価格・説明文） | ◎ 移管可 | ◎ 移管可 | HTMLタグの混入・文字化けの整形が必要。旧カート独自タグは無効化される。 |
| 商品画像 | ◎ 移管可 | ○ 取得可 | モール画像は横幅制限で低解像度なことが多く、再撮影・再取得が必要な場合あり。 |
| バリエーション（サイズ・色） | △ 要再設計 | △ 要再設計 | Shopifyは1商品あたりオプション3軸まで。旧サイトが4軸以上なら構造の作り替えが必須。 |
| 顧客情報（氏名・住所・メール） | ○ 移管可 | × 移管不可 | モールは顧客がプラットフォームに帰属。同意なき持ち出しは規約違反かつ法的リスク。 |
| 顧客パスワード | × 移管不可 | × 移管不可 | ハッシュ化のため技術的に不可能。全会員にパスワード再設定案内が必須。 |
| 注文履歴 | ○ 移管可 | △ CSV出力分のみ | 参照用として取り込む形。旧注文に対する返品処理は旧環境で完結させるのが安全。 |
| ポイント残高 | △ アプリ次第 | × 移管不可 | Shopify標準にポイント機能はなく、外部アプリの仕様に依存。残高の扱いは事前に顧客告知が必要。 |
| 定期購入の継続契約 | × ほぼ不可 | × 不可 | 決済情報を跨いで移せないため、既存定期顧客には再登録依頼が発生。最大の離脱ポイント。 |
| レビュー・口コミ | △ アプリ次第 | × 移管不可 | モールのレビューは資産として持ち出せない。移行の見えないコスト。 |
| SEO評価（被リンク・順位） | ○ 301で大半継承 | × 継承不可 | モールのURLは自社管理外のためリダイレクト不可。自社ドメインでの再構築が必要。 |
⚠️ 見落とされがちな最重要リスク：定期購入とパスワード
定期購入（サブスク）を運用している事業者の移行は、難易度が一段跳ね上がります。決済トークンをプラットフォーム間で移すことは原則できないため、既存の定期顧客に「再登録」をお願いすることになります。ここで何割が戻ってくるかが、移行の成否そのものです。
同様に、パスワードは技術的に移管できません。全会員に再設定を依頼する導線と、その期間の問い合わせ増加を運用計画に織り込んでおく必要があります。この2点を見積書に書いていない制作会社は、移行の実務経験が浅いと判断して差し支えありません。
移行で最も失敗するポイント：SEOの引き継ぎ設計
「移行したら検索流入が半分になった」——これは移行事故の典型で、原因のほぼすべてがURL設計とリダイレクトの不備です。
なぜ順位が落ちるのか
検索エンジンは、URLという住所単位でページの評価を蓄積しています。移行によって住所が変わったとき、「旧住所と新住所が同じページである」と明示的に伝えなければ、蓄積された評価はゼロから再スタートします。この橋渡しをするのが301リダイレクトです。
厄介なのは、Shopifyには固有のURL構造がある点です。商品は /products/ハンドル、カテゴリは /collections/ハンドル という形式に固定され、旧サイトのURL構造をそのまま再現することは基本的にできません。つまりShopify移行では、URLが変わることが前提であり、リダイレクトは「やったほうがいい施策」ではなく「やらなければ必ず損失が出る必須工程」です。
リダイレクト設計の実務手順
- 旧URLを全件抽出するSearch Console、サイトマップ、アクセス解析、クロールツールの4つを突き合わせます。1つの情報源だけでは必ず漏れます。特に「検索流入はあるがサイトマップに載っていない古いページ」が抜けがちです。
- 流入・被リンクで優先順位をつける全URLを同じ熱量で扱う必要はありません。直近12か月の検索流入上位、被リンクを獲得しているページ、コンバージョンに寄与しているページを最優先で対応します。
- 1対1で新URLに対応させる迷ったときに全部トップページへ飛ばすのは最悪手です。検索エンジンはこれを「該当ページが消えた」と解釈し、評価を引き継ぎません。対応するページがなければ、最も近い上位カテゴリへ飛ばします。
- 切替と同時に適用する「あとで入れます」は事故のもとです。旧サイト停止とリダイレクト適用は同時に行い、切替直後に主要URLを手動で検証します。
- 4〜12週間、定点観測するSearch Consoleの「カバレッジ」で404の急増を監視し、漏れが見つかり次第追加します。順位は一時的に揺れますが、設計が正しければ多くのケースで数週間から数か月で回復傾向に入ります。
⚠️ モールからの移行では、SEOは引き継げません
楽天市場やAmazonの商品ページURLは、当然ながら自社の管理下にありません。リダイレクトを設定する権限がないため、モールで積み上げた検索評価は自社サイトに引き継げないのが構造的な事実です。
したがってモールからの移行は「引っ越し」ではなく「自社ドメインでの新規立ち上げ」として計画し、初年度は集客をゼロベースで設計する必要があります。ここを楽観視した計画が、移行後の売上低迷の最大の原因です。
移行にかかる費用と期間の構造
移行費用は「サイトを作る費用」ではなく、「決める費用 + 作る費用 + 移す費用 + 検証する費用」の合算です。この分解ができていない見積もりは、後から必ず追加が発生します。
| 費用区分 | 内容 | 変動要因 |
|---|---|---|
| 要件定義・情報設計 | 現状棚卸し、データマッピング表の作成、URL設計 | 商品数、カテゴリの複雑さ、外部連携の本数 |
| デザイン・テーマ実装 | 既存テーマのカスタマイズ、またはオリジナル実装 | 既存テーマ活用かフルスクラッチか。ここが最も差が出る |
| データ移管 | 商品・顧客・注文の抽出、整形、投入、検証 | 商品点数×バリエーション数。ここは点数に比例して素直に増える |
| アプリ選定・設定 | 定期購入、レビュー、ポイント、在庫連携等 | 必要機能の数。月額費用が継続的に発生する点に注意 |
| リダイレクト設計 | 旧URL抽出、対応表作成、適用、検証 | 旧サイトのページ数。数千URLなら独立した工程になる |
| 切替後の監視・改善 | インデックス監視、404対応、CVR検証 | 期間の長さ。最低でも4週間は契約に含めるべき |
| Shopify月額利用料 | プラン料金 + 決済手数料 | プラン、売上規模、決済手段 |
費用が跳ね上がる要因は、実務上ほぼ次の4つに集約されます。①バリエーション構造が3軸を超える、②定期購入がある、③基幹システムとのリアルタイム在庫連携がある、④旧サイトの商品データが整っていない（表記ゆれ・画像欠損・説明文のHTML崩れ）。とりわけ④は見積もり時に見えにくく、着手後に発覚して揉める最大の原因です。相見積もりを取る際は、自社の商品CSVを1ファイル開示した上で見積もりを依頼してください。それだけで見積もり精度は大きく変わります。
関連する支援メニュー
- ECサイト構築支援｜移行設計から実装、切替後の監視までを一貫して担当します。
- ECコンサルティング｜そもそも移行すべきかの判断、移行後の売上設計から伴走します。
- EC運用代行｜移行後の商品登録・受注・広告運用の実務を巻き取ります。
- 物流支援｜移行に伴う配送設定・在庫連携・3PL選定を整理します。
【独自視点】移行は「引っ越し」ではなく「事業構造の再定義」である
ここが、他の移行記事があまり言語化していない部分です。
多くの移行プロジェクトは「今あるものを、そのまま新しい家に運ぶ」という引っ越しの比喩で語られます。しかしこの比喩こそが、移行を失敗させる元凶だと私たちは考えています。
なぜ「そのまま移す」と失敗するのか
旧サイトの構造は、旧プラットフォームの制約に最適化された形をしています。BASEのカテゴリ構造は、BASEの機能上限の中で「これしかできなかった」結果です。楽天の商品ページが情報過多なのは、楽天の検索アルゴリズムとユーザー行動に最適化した結果です。
それをそのままShopifyに持ち込むと、何が起きるか。制約は消えたのに、制約に合わせて歪めた形だけが残ります。楽天式の縦長ページをShopifyでそのまま再現し、「Shopifyにしたのに売れない」と嘆く事例は、この構造で説明できます。
移行を「棚卸しの機会」として設計する
私たちは移行案件で、必ず次の3つを問い直します。これは技術要件ではなく、事業設計の問いです。
問い①：この商品数は、本当に必要か
移行費用は商品点数にほぼ比例します。売上の8割を生んでいない死蔵SKUを移すために費用を払う合理性はあるのか。移行は、商品ラインの整理を経営判断として実行できる数少ないタイミングです。
問い②：このカテゴリ構造は、誰のためのものか
多くのカテゴリ構造は、社内の管理都合（仕入先別、担当者別）で作られています。顧客の探し方と一致していないなら、移行時に作り直すべきです。構造を変える最後の機会が移行です。
問い③：移行後、誰が何を運用するのか
最も軽視される問いです。高機能な仕組みを作っても、運用できる人がいなければ半年で形骸化します。「今の体制で回せる範囲」から逆算して仕様を決めるのが、実は最も再現性が高い設計手法です。
ボトルシップが一貫して掲げている考え方は「ECは戦術ではなく設計で決まる」です。移行はまさにこの思想が最も試される場面です。どのアプリを入れるか、どのテーマを買うかという戦術の議論の前に、「何を扱い、誰に、どういう順路で買ってもらうのか」という設計の議論を終わらせておく。それができているプロジェクトは、移行後の伸びが明確に違います。
逆説的ですが、移行で最も価値が高いのは、実装ではなくPHASE 1とPHASE 2です。ここに十分な時間と費用を割いたプロジェクトは、実装フェーズが驚くほどスムーズに進み、結果的に総費用も抑えられます。ここを削ったプロジェクトは、実装フェーズで仕様変更が多発し、費用も期間も膨らみます。
よくある誤解
誤解①「Shopifyにすれば売れるようになる」
Shopifyはカートであって集客装置ではありません。プラットフォームを変えても、集客の総量は自動的には増えません。モールの検索流入を失う分、移行直後はむしろ露出が減ります。集客設計とセットでなければ、移行は売上を下げます。
誤解②「モールをやめて自社サイトに一本化すべき」
実務上の最適解は多くの場合並行運用です。モールは新規接点として残し、Shopifyでリピートと利益を作る。役割を分けるのが定石で、いきなりモールを閉じるのは売上の自傷行為になりがちです。
誤解③「データは全部そのまま移せる」
前述の通り、パスワード・定期購入・モール顧客・レビューは移せません。「移せないものリスト」を最初に確定させることが、移行計画の出発点です。
誤解④「テーマを買えば安く済む」
テーマ費用は総費用の一部にすぎません。費用の主戦場はデータ移管・リダイレクト・アプリ設定・検証です。テーマの価格で移行費用を判断するのは、引っ越し費用を段ボール代で見積もるようなものです。
誤解⑤「順位が下がったら移行は失敗」
移行直後にインデックスが揺れ、順位が一時的に変動するのは正常な挙動です。判断は4〜12週間の推移で行うべきで、切替2週間で慌てて設計を戻すと、かえって回復を遅らせます。
誤解⑥「移行は制作会社に任せれば終わる」
データの正誤判断、商品整理、顧客への告知は発注側にしかできません。移行は共同プロジェクトであり、社内の担当者を1名専任で立てられるかが成否を分けます。
移行を判断するためのチェックリスト
次の項目のうち、4つ以上に当てはまるなら移行の検討価値があります。2つ以下なら、現行環境の改善が先です。
- 手数料が利益を圧迫しているモール手数料・決済手数料・広告費の合計が、粗利の3割を超えている。
- 顧客に直接アプローチできない購入者にメールやLINEを送る手段がなく、リピート施策が打てない。
- やりたい施策が実装できない会員ランク、定期購入、セット販売、多通貨など、現行カートの仕様で断念した施策が3つ以上ある。
- データが分断している受注・在庫・顧客が別々のツールに散在し、手作業の転記が発生している。
- 売上の単一チャネル依存が高い1つのモールに売上の7割以上を依存しており、規約変更が経営リスクになっている。
- ブランド体験を作りたい明確な理由がある単価・世界観・ストーリーで選ばれる商材であり、モールの価格比較文脈が不利に働いている。
- 移行を担当できる社内リソースがある3〜6か月にわたり、意思決定と確認作業に関与できる担当者を確保できる。
⚠️ 移行を「やめておくべき」ケース
次に該当する場合、私たちは移行をおすすめしません。①月商が数十万円規模で、まだ商品の売れ筋が定まっていない ②社内に移行を担当できる人が1人もいない ③現行サイトの売上が右肩上がりで、特に困っていない ④「なんとなくShopifyが良さそう」以上の理由がない。
移行は数か月の時間と相応の費用を投じるプロジェクトです。その投資対効果が説明できないなら、同じ予算を広告や商品開発に回したほうが利益は出ます。移行しないという判断も、正しい経営判断です。
よくある質問（FAQ）
Q1. 移行中、売上を止めずに進められますか？
はい。旧サイトを稼働させたまま、Shopify側をテスト環境で構築するのが標準的な進め方です。売上が止まるのは切替（カットオーバー）当日の数時間から半日程度に限定できます。切替は受注の少ない曜日・時間帯を選び、必ず切り戻し手順を用意した上で実行します。
Q2. 会員に何を、いつ告知すべきですか？
最低でも切替の2週間前に、①サイトリニューアルの予定日、②パスワードの再設定が必要であること、③ポイント残高の扱い、④定期購入がある場合は再登録の手順、の4点を告知します。切替当日にも再度案内を出し、切替後1週間は問い合わせ増加を見込んだ体制を組んでください。この告知設計の丁寧さが、移行後の顧客離脱率を直接左右します。
Q3. 楽天やAmazonをやめる必要はありますか？
ありません。多くの成功事例は並行運用です。モールを新規顧客との出会いの場、Shopifyをリピートと利益を作る場として役割分担させるのが実務的な最適解です。同梱物やフォローメールでモール購入者を自社サイトへ誘導する導線設計が、並行運用の要になります。
Q4. 商品数が多い場合、どう進めるのが安全ですか？
全件を一度に移すのではなく、売上上位の主力商品から段階的に移す方式を検討します。ただし段階移行はURL設計とリダイレクトが複雑になるため、期間の短縮と引き換えに設計負荷が上がります。商品数が数千点規模なら、まず売上に寄与していないSKUを整理し、移す対象そのものを減らすほうが費用対効果は高くなります。
Q5. 制作会社を選ぶとき、何を確認すべきですか？
最低限、次の4点を質問してください。①移せないデータを具体的に説明できるか、②リダイレクト設計が見積もりに独立項目として入っているか、③切替後の監視期間が契約に含まれているか、④過去の移行案件で、切替後の検索流入がどう推移したかを説明できるか。この4つに具体的に答えられない会社は、移行実務の経験が浅い可能性があります。
まとめ
この記事の要点
- Shopify移行とは、商品・顧客・注文・検索評価を引き継ぎながら、販売チャネルの主導権を自社に移す事業プロセスである。単なるカートの乗り換えではない。
- 移行には3類型ある。モールからの移行は顧客データもSEOも引き継げず、実質的に新規立ち上げ。ASPカートからの移行は資産を引き継げるが技術難易度が高い。
- 移せないものが必ずある。パスワード、定期購入契約、モールの顧客・レビューは移管不可。この「移せないものリスト」の確定が移行計画の出発点。
- SEOの成否は301リダイレクト設計で決まる。旧URLの全件抽出、1対1の対応付け、切替と同時適用、4〜12週間の定点観測が必須工程。
- 費用は商品点数・バリエーション構造・定期購入の有無・データの整備状況で決まる。テーマの価格で総額を判断してはいけない。
- 移行の本質は棚卸しである。旧環境の制約に合わせて歪んだ構造をそのまま移すと、制約だけが残る。商品数・カテゴリ構造・運用体制を問い直す機会として設計すべき。
- 移行しない判断も正しい。困っていない、担当者がいない、理由が曖昧——このいずれかなら、同じ予算を広告や商品開発に回したほうが利益は出る。
100文字要約：Shopify移行とは、商品・顧客・SEO評価を引き継ぎつつ販売の主導権を自社に移す事業プロセス。パスワードや定期購入は移管不可で、301リダイレクト設計と移行前の構造棚卸しが成否を分ける。
