EC-CUBE から Shopify + Next.js への移行: 日本のeコマースガイド 2026

日本で EC-CUBE ストアを運営していて、自ホストの PHP モノリスの保守に悩んでいるのであれば、あなたは一人ではありません。私たちは過去2年間、EC-CUBE（バージョン 2.x、3.x、4.x）から Next.js で構築したヘッドレス Shopify ストアフロントへの移行を支援してきた日本のeコマース企業が複数あります。その全てが移行後に同じことを言いました：「もっと早くやっておけばよかった」

しかし、実はこの移行は非常に複雑なのです。EC-CUBE は日本の商取引文化に深い根を持っています。住所のフリガナフィールド、日本の決済方法（コンビニ決済、キャリア決済、Pay-easy 経由の銀行振込）、日本郵便のゾーン別送料計算など、様々な機能を扱っています。Shopify に切り替えるだけでは済みません。戦略が必要です。

このガイドは、2024年に初めて EC-CUBE 移行を行った際に、あればよかったと思う戦略ドキュメントです。

目次

• 2026年に EC-CUBE から移行する理由
• EC-CUBE アーキテクチャの理解
• 日本のeコマースに Shopify Plus + Next.js が適している理由
• 移行前の監査と計画
• データ移行戦略
• 日本の決済方法への対応
• 配送とフルフィルメントのマッピング
• Next.js ストアフロントの構築
• SEO 移行と URL の保持
• 日本特有の UX 考慮事項
• パフォーマンスベンチマーク: EC-CUBE vs ヘッドレス Shopify
• タイムライン コスト期待値
• FAQ

2026年に EC-CUBE から移行する理由

EC-CUBE はほぼ20年間、日本のeコマースの中核を担ってきました。Lockon Co., Ltd.（現在の EC-CUBE Co., Ltd.）によって開発され、選択肢が限られていた時代に日本市場を支配していました。しかし、状況は劇的に変わりました。

企業を遠ざかるようにしている要因は以下の通りです：

セキュリティ保守が悪夢である。 EC-CUBE 2.x は数年前にサポート終了に達しましたが、驚くほど多くのストアがそれを実行し続けています。EC-CUBE 4.x でも継続的なパッチが必要です。2024年だけでも、EC-CUBE 4 に3つの重大なセキュリティ勧告がありました。その中には、数千のストアに影響を与えた SQL インジェクション脆弱性（CVE-2024-22345）も含まれています。自ホストしている場合、それはあなたが修正する問題です。

PHP ホスティングコストは上昇し続けている。 EC-CUBE を日本の VPS または専用サーバー上で実行（通常 Sakura Internet、XSERVER、または AWS Tokyo）することは、インフラストラクチャ、SSL 証明書、データベース保守、サーバー監視のコストを意味します。典型的な中規模 EC-CUBE ストアは、ホスティングと保守だけで月額 ¥50,000～¥200,000 を費やしています。

プラグインエコシステムが縮小している。 EC-CUBE プラグインマーケットプレイスは開発者を失い続けています。多くの人気のある決済プラグインや配送プラグインは、EC-CUBE 4.2 以上向けに更新されていません。ストアが第三者のプラグインに依存している場合、古いバージョンに固定され、アップグレードパスがない可能性があります。

モバイルパフォーマンスが悪い。 ほとんどの EC-CUBE テーマはレスポンシブだが重い時代に設計されています。私たちが監査した EC-CUBE ストアの平均 Lighthouse スコアは、モバイルで 25～40 の周辺です。Core Web Vitals が日本での Google ランキングに直接影響する場合、これではダメです。

EC-CUBE アーキテクチャの理解

移行できるようになる前に、あなたが何から移行しているのかを理解する必要があります。EC-CUBE のアーキテクチャはバージョンによって大きく異なります：

機能	EC-CUBE 2.x	EC-CUBE 3.x	EC-CUBE 4.x
フレームワーク	カスタム PHP	Silex（Symfony マイクロ）	Symfony 4/5
データベース	PostgreSQL/MySQL	PostgreSQL/MySQL	PostgreSQL/MySQL
テンプレートエンジン	Smarty	Twig	Twig
プラグインアーキテクチャ	フック/オーバーライド	イベントベース	Symfony バンドル
ORM	カスタム	Doctrine	Doctrine
API	なし（カスタムビルド）	制限付き REST	REST + 制限付き GraphQL

データベーススキーマは興味深い（そして厄介な）場所です。EC-CUBE は製品データ、顧客データ、注文履歴を正規化されているが EC-CUBE 固有のスキーマで保存します。dtb_product、dtb_product_class、dtb_customer、dtb_order テーブルが抽出する必要がある基本的なものです。

EC-CUBE 4.x は Doctrine エンティティを使用しており、データ抽出をやや簡潔にします。しかし、2.x を使用している場合、エンコード問題（Shift-JIS または EUC-JP レガシーデータはまだ一般的）を伴う生 SQL エクスポートに備えてください。

日本のeコマースに Shopify Plus + Next.js が適している理由

率直に言いたいのです：Shopify が唯一の選択肢ではありません。commercetools、Medusa、または新しい日本プラットフォーム BASE や STORES.jp のような他のプラットフォームに移行できます。しかし、中規模から大規模の日本eコマース事業の場合、ヘッドレス Next.js フロントエンドと組み合わせた Shopify Plus は心地よい甘い場所を打ちます。

Shopify の日本でのプレゼンスが成熟している。 東京オフィスを開設し、日本語の完全なサポートを開始してから、Shopify は日本特有のギャップのほとんどに対応しました。Shopify Payments は現在ネイティブで JCB カードをサポートしています。管理インターフェイスは完全に現地化されています。そして、ここが重要ですが、Shopify Plus は食品と飲料の 軽減税率 を含む日本の税計算をサポートしています。

Next.js はパフォーマンスエッジを提供します。 Next.js で構築されたヘッドレスストアフロント（Shopify Storefront API または Hydrogen の基礎となるデータレイヤーを使用）により、エッジから静的およびサーバーレンダリングされたページを配信できます。Next.js Shopify ビルドでは、モバイルでのLighthouse パフォーマンススコアが定期的に 90 以上になります。これは EC-CUBE の典型的な 30 台のスコアから大きな飛躍です。

Storefront API は複雑さに対応します。 Shopify の Storefront API（このライティング時点での 2025-04 版）はメタフィールド、ローカライズされたコンテンツ、多通貨、カスタム製品オプションをサポートしており、EC-CUBE の柔軟性を複製するために必要なすべてです。

特定のストアに Next.js ベースのヘッドレスアーキテクチャ が意味があるかどうかを評価している場合、答えはほぼ常にカタログサイズとカスタマイズニーズに帰着します。100 製品未満で単純なバリアント？標準 Shopify テーマは問題ないかもしれません。複雑な製品構成、大規模なカスタマイズ、または複数のストアフロント？ヘッドレスに進みます。

移行前の監査と計画

コードの1行にも手を付ける前に、この監査を完了してください：

1. カタログ複雑度マッピング

EC-CUBE ストアのすべての製品タイプ、バリアント構造、カスタムフィールドを文書化します。EC-CUBE の dtb_product_class テーブルは、Shopify のバリアントモデル（製品あたり 100 バリアント制限と 3 オプション制限を持つ）に 1:1 でマップされない複雑なバリアント組み合わせを保持できます。

3つ以上のオプションタイプ（例えば、サイズ、色、材料、刻印）を持つ製品がある場合、Shopify の Combined Listings 機能（2024年に開始）を使用するか、メタフィールドとラインアイテムプロパティを使用して製品アーキテクチャを再構成する必要があります。

2. 顧客データインベントリ

EC-CUBE は以下を含む豊富な顧客データを保存します：

• 姓名（ファミリー名/名前、別々のフィールド）
• フリガナ（名前用のフリガナ）
• 郵便番号（オートアドレス入力付き）
• 顧客あたり複数の配送住所
• ポイント残高（ポイント）
• 詳細な注文ステータス追跡を伴う購入履歴

Shopify の顧客モデルは、名前フィールドと複数アドレスをネイティブに処理します。ただし、ポイント/ロイヤルティプログラムには、Smile.io のようなサードパーティソリューション、またはカスタムメタフィールドベースのシステムが必要です。

3. 統合インベントリ

EC-CUBE ストアが接続するすべての外部システムを一覧表示します：

• 決済ゲートウェイ（GMO Payment Gateway、SB Payment Service、PAY.JP）
• 配送 API（ヤマト運輸、佐川急便、日本郵便）
• 会計ソフトウェア（弥生会計、freee、MoneyForward）
• 在庫/ERP システム
• メールマーケティング（Mailchimp、SendGrid、または Benchmark Email のような日本サービス）

4. URL 構造ドキュメント

EC-CUBE ストアのすべての URL をエクスポートします。これは SEO 移行に重要です。EC-CUBE のデフォルト URL パターンは次のようになります：

/products/detail/{product_id}
/products/list?category_id={id}
/mypage/
/cart/

すべてのリダイレクトマップが必要です。

データ移行戦略

使用する移行パイプラインは以下の通りです：

製品データエクスポート

EC-CUBE 4.x の場合、Doctrine の CLI ツールを使用するか、JSON として製品をエクスポートするための Symfony コマンドを作成できます：

// EC-CUBE 4.x product export command
$products = $this->productRepository->findAll();
$exportData = [];

foreach ($products as $product) {
    $variants = [];
    foreach ($product->getProductClasses() as $class) {
        $variants[] = [
            'sku' => $class->getCode(),
            'price' => $class->getPrice02IncTax(),
            'stock' => $class->getStock(),
            'class_category1' => $class->getClassCategory1()?->getName(),
            'class_category2' => $class->getClassCategory2()?->getName(),
        ];
    }
    
    $exportData[] = [
        'id' => $product->getId(),
        'name' => $product->getName(),
        'description' => $product->getDescriptionDetail(),
        'variants' => $variants,
        'images' => array_map(fn($img) => $img->getFileName(), $product->getProductImages()->toArray()),
    ];
}

EC-CUBE 2.x の場合、生 SQL を見ています：

SELECT 
    p.product_id,
    p.name,
    p.main_comment,
    pc.product_code,
    pc.price02,
    pc.stock
FROM dtb_product p
JOIN dtb_product_class pc ON p.product_id = pc.product_id
WHERE p.del_flg = 0 AND pc.del_flg = 0;

文字エンコーディングに注意してください。EC-CUBE 2.x データベースが EUC-JP を使用している場合、どこかにインポートする前に UTF-8 に変換します：

mysqldump --default-character-set=eucjpms your_db | iconv -f EUC-JP -t UTF-8 > export_utf8.sql

Shopify へのインポート

Shopify Admin API（REST または GraphQL）を使用して、プログラムで製品を作成します。GraphQL の productCreate ミューテーションはあなたの最良の友人です：

mutation productCreate($input: ProductInput!) {
  productCreate(input: $input) {
    product {
      id
      title
      variants(first: 100) {
        edges {
          node {
            id
            sku
          }
        }
      }
    }
    userErrors {
      field
      message
    }
  }
}

エクスポートされた EC-CUBE データを読み込み、Shopify 製品を作成する Node.js または Python の移行スクリプトを構築します。レート制限を含めます -- Shopify API には REST で毎秒 2 リクエストの制限、GraphQL には コストベースの制限があります。

顧客移行

Shopify の API 経由の顧客インポートは良好に機能しますが、パスワードを移行することはできません。すべての顧客は移行後にパスワードをリセットする必要があります。移行を説明し、パスワードリセットリンクを提供する、よく作られたメール（もちろん日本語で）を送信します。

顧客データ自体の場合、EC-CUBE フィールドを Shopify にマップします：

EC-CUBE フィールド	Shopify フィールド	注記
name01（姓）	last_name	日本語用に反転
name02（名）	first_name	日本語用に反転
kana01（セイ）	metafield	ネイティブフリガナフィールドなし
kana02（メイ）	metafield	ネイティブフリガナフィールドなし
email	email	直接マッピング
point	metafield またはロイヤルティアプリ	カスタムハンドリングが必要
addr01（都道府県）	province	Shopify プロビンスコードにマップ
addr02（市区町村）	city + address1	連結が必要な場合がある

注文履歴

履歴注文の移行はオプションですが、顧客サービスの継続性のために推奨されます。Shopify の Order API を使用して、完了した注文の "financial_status": "paid" および "fulfillment_status": "fulfilled" で注文を作成します。

日本の決済方法への対応

ここが複雑な場所です。日本の消費者は、Western eコマースでは標準ではない特定の支払いオプションを期待しています。

Shopify Payments は日本のクレジットカード、JCB、Visa、Mastercard、American Express をサポートしています。Shopify Plus の処理料は 3.25%～3.4% + 取引あたり ¥0 です。

他の支払い方法の場合：

決済方法	Shopify 上のソリューション	注記
コンビニ決済（コンビニエンスストア）	KOMOJU、GMO Payment Gateway アプリ	日本のオンライン注文の約15%に不可欠
代引き（着払い）	Shopify ネイティブ COD	ビルトイン、うまく機能
銀行振込（銀行振込）	手動支払い方法	Shopify ネイティブがサポート
キャリア決済（キャリア決済）	KOMOJU	docomo、au、SoftBank
PayPay	PayPay for Shopify アプリ	日本で最も人気の QR 決済
Amazon Pay	Amazon Pay アプリ	日本での高採用
後払い（今買って後で支払う）	Paidy、atone	日本で非常に人気

KOMOJU は特別な言及に値します。これは日本の Shopify ストア向けの事実上の決済ゲートウェイになっており、単一の統合を通じてコンビニ決済、銀行振込、キャリア決済などをサポートしています。Shopify Plus 統合は堅牢であり、大きな問題は経験していません。

配送とフルフィルメントのマッピング

EC-CUBE は通常、ヤマト運輸、佐川急便、日本郵便向けのプラグインを使用します。これらのプラグインは、配送ラベルの生成、追跡番号の統合、配達時間スロットの選択（配達時間指定）を処理します。

Shopify では、いくつかのオプションがあります：

• Ship&co -- すべての主要な日本の配送業者と統合する日本で構築された配送アプリ。正しい形式でラベル印刷を処理します。
• Shopify Shipping -- 2025年現在、日本の配送業者サポートは制限されていますが、改善されています。
• カスタム Carrier Service API -- 複雑なゾーンベースの価格設定がある場合、独自の配送料金計算機を構築します。

配達時間スロット選択（午前中、12-14時、14-16時など）は日本の顧客にとって重要です。これには、Shopify Plus のカスタムチェックアウト拡張、または 配送日時指定 のようなサードパーティアプリのいずれかが必要です。

Next.js ストアフロントの構築

フロントエンドの場合、App Router と Server Components を持つ Next.js 15 を使用します。典型的なスタックは以下の通りです：

Next.js 15（App Router）
├── Shopify Storefront API（GraphQL）
├── next-intl（日本語 i18n 向け）
├── Tailwind CSS 4
├── Framer Motion（アニメーション）
└── Vercel（デプロイ、東京地域エッジ）

Next.js で日本のストアフロントを構築する際に学んだいくつかのこと：

フォント最適化

日本語のウェブフォントは重いです。Noto Sans JP 標準のみで約1.8MBです。next/font を subsets で使用し、可変フォントを検討してください：

import { Noto_Sans_JP } from 'next/font/google';

const notoSansJP = Noto_Sans_JP({
  subsets: ['latin'],
  weight: ['400', '500', '700'],
  display: 'swap',
  preload: true,
});

さらに良いことに、重要でないテキストで font-display: optional を使用し、フォールバック用のシステムフォントスタックを提供します："Hiragino Kaku Gothic ProN", "Hiragino Sans", Meiryo, sans-serif。

製品ページ用の Server Components

Server Components でデータを取得して、クライアント側のローディング状態を排除します：

// app/products/[handle]/page.tsx
export default async function ProductPage({ params }: { params: { handle: string } }) {
  const product = await shopifyFetch({
    query: PRODUCT_QUERY,
    variables: { handle: params.handle },
  });

  return (
    <div>
      <ProductGallery images={product.images} />
      <ProductDetails product={product} />
      <AddToCartButton variantId={product.variants[0].id} />
    </div>
  );
}

すべてのヘッドレス Shopify ストアフロント](/capabilities/nextjs-development) をこのパターンで構築し、従来の Liquid テーマまたは Hydrogen に対するパフォーマンス差は目立ちます。

SEO 移行と URL の保持

これは移行プロジェクトで私を夜間に目覚めさせる部分です。日本のeコマースストアは、長年にわたり蓄積された SEO 価値を持つことがあり、悪い移行は数ヶ月間のオーガニックトラフィックを落とす可能性があります。

リダイレクト戦略

完全なリダイレクトマップを作成します。すべて。シングル。URL。Next.js の next.config.js リダイレクトを静的パターンに使用します：

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/products/detail/:id',
        destination: '/products/:handle',
        permanent: true,
      },
      {
        source: '/products/list',
        destination: '/collections/:collection',
        permanent: true,
      },
    ];
  },
};

動的リダイレクト（EC-CUBE 製品 ID を Shopify ハンドルにマッピング）の場合、ミドルウェアまたはデータベースまたは KV ストアに保存されたリダイレクト検索テーブルを使用します。

構造化データ

EC-CUBE ストアは、適切な構造化データをめったに持っていません。Product、BreadcrumbList、Organization、FAQPage スキーマを実装するこの機会を利用してください。日本の Google SERP は大いにリッチ結果を特徴としています。

日本の SEO 特性

• タイトルタグを日本語で30字以下に保つ（英語のような60ではなく）
• メタ説明：80-120 日本語文字
• マルチ言語ページがある場合、適切な hreflang タグを確認
• サイトマップを Google Search Console と Bing Webmaster Tools の両方に送信（Bing は日本での有意な市場シェアを持つ）

日本特有の UX 考慮事項

日本のeコマース UX は、Western 開発者がしばしば見落とす文化的な違いがあります：

• 情報密度 -- 日本の消費者はページに表示される多くの製品情報を期待します。オーバーミニマイズしないでください。
• 信頼シグナル -- 配送ポリシー、返品ポリシー、会社情報を目立つように表示します。日本の買い物客は徹底的に調査します。
• 郵便番号オートフィル -- 郵便番号 → 住所オートコンプリートを日本郵便 API または zipaddress.js のようなライブラリを使用して実装します。
• 敬語 -- UI コピーで適切な敬語（敬語）を使用します。カジュアルな言語は失礼に感じることができます。
• LINE メッセージング統合 -- LINE は日本で月間 9,600 万のアクティブユーザーを持っています。LINE Login と LINE 通知を統合します。

パフォーマンスベンチマーク: EC-CUBE vs ヘッドレス Shopify

2025年Q1に日本のファッション小売業者（約3,000 SKU）の移行から実データを取得しました：

メトリック	EC-CUBE 4.2（移行前）	Next.js + Shopify（移行後）	改善
Lighthouse パフォーマンス（モバイル）	34	92	+170%
LCP	4.8 秒	1.2 秒	-75%
FID/INP	380ms	45ms	-88%
CLS	0.24	0.02	-92%
Time to First Byte	1.8 秒	0.18 秒	-90%
ページウェイト（製品ページ）	3.2MB	680KB	-79%
コンバージョン率	1.8%	2.9%	+61%
月間ホスティングコスト	¥180,000	¥45,000	-75%

コンバージョン率の改善だけで、3ヶ月以内に移行全体の費用を支払いました。すべてのプロジェクトがこのような劇的な数字を見るわけではありませんが、このレベルのパフォーマンス改善は一貫して針を動かします。

タイムライン コスト期待値

この移行に何が必要かについて現実的になりましょう：

ストアサイズ	製品数	タイムライン	予算範囲（¥）
小	<500	8～12週間	¥3,000,000-5,000,000
中	500-5,000	12～20週間	¥5,000,000-12,000,000
大	5,000+	20～32週間	¥12,000,000-25,000,000+

これらの範囲には、デザイン、開発、データ移行、QA、起動サポートが含まれます。経験豊富なチームと協力していることを前提としています。チームが日本のeコマース移行を行ったことがない場合、学習曲線の両方のタイムラインと予算に 30～50% を追加します。

ヘッドレス CMS およびコマース開発プラクティス 経由して、このスペクトラム全体でプロジェクトを処理します。詳細について話し合いたい場合は、お問い合わせ ください。正直な評価をさせていただきます。

移行後の月間進行中のコストは通常次のようになります：

• Shopify Plus：$2,300/月（約 ¥345,000）
• Vercel Pro：チームメンバーあたり $20/月
• KOMOJU：トランザクション料金のみ
• Ship&co：月額基本 ¥2,000
• 合計：約¥380,000-450,000/月対同等の機能を持つ自ホスト EC-CUBE の月額 ¥400,000-800,000

プロジェクト価格設定の構成方法に関する透明な見方については、価格設定ページ を確認してください。

FAQ

EC-CUBE 2.x から直接 Shopify + Next.js に移行できますか？

はい、ただし EC-CUBE 2.x の移行は、古いデータベーススキーマ、潜在的な Shift-JIS/EUC-JP エンコーディング問題、および最新 ORM の欠如により、より複雑です。データの清掃と変換に追加の時間を予算してください。まず中立形式（UTF-8 の CSV または JSON）にエクスポートしてから、Shopify のインポートスクリプトを構築することをお勧めします。

EC-CUBE から移行する際に Google ランキングを失いますか？

リダイレクトを適切に処理すれば、そうではありません。すべての URL に対して 301 リダイレクトを実装し、XML サイトマップを保持し、タイトルタグとメタ説明を一貫性のある状態に保ちます。Google が再クロールしても一時的な変動（2～4週間）を期待してください。ただし、ランキングは回復し、通常は Core Web Vitals スコアの向上により改善されます。

Shopify は軽減税率を含む日本の税計算をサポートしていますか？

はい。Shopify は食品と飲料の 軽減税率 を含む日本の消費税システム（標準 10% に対して 8% の軽減税率）をサポートしています。製品コレクションあたりの税率を構成でき、Shopify は請求書適格受領書要件（インボイス制度）を含む計算を処理します。

Shopify に移行した後、EC-CUBE のポイントシステムをどのように処理しますか？

Shopify には、EC-CUBE の組み込みポイント機能と同等の単語システムはありません。最適なオプションは Smile.io（日本語をサポート）、LoyaltyLion、またはカスタムソリューション（Shopify メタフィールドとサーバーレス関数を使用）です。既存のポイント残高の場合、顧客レコード上のメタフィールドとして移行し、Next.js チェックアウトに償却フローを構築します。

Hydrogen は Shopify ストアフロント用の Next.js より優れていますか？

状況によって異なります。Hydrogen（Remix 上に構築された Shopify の React フレームワーク）は Shopify と緊密に統合され、組み込みのコマース プリミティブを提供します。ただし Next.js は大規模なエコシステム、より多くのコミュニティリソース、Vercel でのより良い Edge Runtime サポート、コマースバックエンドを交換する場合の柔軟性が増しています。日本のeコマース特性については、Next.js のミドルウェア機能と i18n ルーティング は利点を与えます。両方で構築しており、ほとんどのプロジェクトの場合 Next.js を好みます -- Next.js 開発機能 を参照してください。

移行中に EC-CUBE と新しい Shopify ストアを並列実行できますか？

完全にでき、推奨します。移行中に両方のシステムを同時に実行します。DNS またはリバースプロキシを使用してトラフィックを段階的にシフトします。これにより、注文が正しく流れる、決済が適切に処理される、在庫が完全にカットオーバーする前に同期されたままであることを検証できます。

EC-CUBE のメールマガジン（メールマガジン）機能はどうですか？

EC-CUBE には、多くのストアが依存する組み込みメールニュースレターシステムがあります。加入者リストを Klaviyo（Shopify との優れた統合を持つ）のような専用メールマーケティングプラットフォーム、または Benchmark Email や SendGrid などの日本語サポートとテンプレートが必要な場合は、に移行します。移行は簡単です -- EC-CUBE の dtb_customer テーブルからメールアドレスと同意日付をエクスポートし、新しいプラットフォームにインポートします。

実際のデータ移行にどのくらいの時間がかかりますか？

移行スクリプト実行自体は通常高速です -- ほとんどのストアでは数時間です。時間のかかる部分は、移行スクリプトの構築とテスト、データ整合性の検証、エッジケースの処理です（画像がない製品、顧客のメールアドレスが無効な形式、カスタムステータスの注文）。3,000 製品と 50,000 顧客を持つストアの場合、2～3週間の移行開発とテスト時間を期待してください。