相談事例 /
北関東
創業90年の老舗百貨店、決済義務化でECが止まる寸前 ─ EC-CUBE 2.13系を4.2系へ移行し、EMV 3-Dセキュア対応とカゴ落ち68%→41%を108日で実現した事例
課題
北関東で創業90年超の老舗百貨店のEC（年商2.8億円）。サイトはEC-CUBE 2.13系で、PHP5.6・MySQL5.6のまま放置され、改修元の制作会社は2024年に廃業。2025年3月末のEMV 3-Dセキュア義務化で、決済代行SBPSから「3Dセキュア2.0非対応カートは取扱停止」と予告され、4月以降カード決済が止まる状態だった。加えて商品8万SKU・画像4万点、LCP4.8秒でスマホのカゴ落ち率68%、外商の掛け払い・店頭ポイント連携・のし対応という百貨店固有の業務が2.13系へ作り込まれていた。
解決策
Shopify Plusへの全面移行は外商掛け払い・店頭ポイント連携・のし対応の再現コストが高く断念。ecbeing等のパッケージは初期1,500万円超で過剰と判断し、EC-CUBE 4.2系（PHP8.1）への移行を選択。旧DBのUTF-8/CP932混在による機種依存文字の化け200件超を手修正し、古い形式の旧パスワードは初回ログイン時の再設定導線へ切り替え。8万SKUをCSV正規化、画像4万点をWebP/AVIF変換しCloudflare R2＋Imagesで配信、検索をMeilisearchへ分離、決済をSBPSのEMV 3DS対応APIへ差し替えた。
成果
スマホのカゴ落ち率は68%→41%、決済エラー由来の離脱は月420件→30件、LCPは4.8秒→1.9秒へ改善。移行後3か月のEC売上は前年同月比22%増。提案から本番切替まで108日で、お歳暮商戦の2か月前にカットオーバーを完了。保守不在で放置されていたサイトが再び売れる状態に戻った。
北関東で創業90年を超える老舗百貨店からの相談でした。店舗の外商が売上の柱で、ECは10年前に立ち上げた別動隊。それでもEC年商は2.8億円まで育ち、お中元・お歳暮の時期には全社売上の無視できない比率を占めていました。
そのECが、2025年の春に「使えなくなる」と通告されたのです。
既存サイトはEC-CUBE 2.13系。10年前に当時の制作会社が独自改修を重ねたもので、土台はPHP 5.6、MySQL 5.6、さくらのVPS上で動いていました。改修した制作会社は2024年に事業を畳み、保守の引き継ぎもないまま放置されていた状態です。
引き金はカード決済の本人認証義務化でした。クレジットカード・セキュリティガイドラインで、EC事業者は2025年3月末までにEMV 3-Dセキュア（本人認証2.0）へ対応することが事実上の必須要件になります。決済代行のSBPS（ソフトバンク・ペイメント・サービス）からは「3Dセキュア2.0に対応しないカートは取扱を停止する」という予告が届いていました。2.13系のままでは、4月以降カード決済そのものが止まる。
そもそもEC-CUBE 2.13系は2018年にサポートが終了しています。土台のPHP 5.6も2018年末でセキュリティ更新が切れており、本人認証以前に、放置しているだけで脆弱性が積み上がる構成でした。「2.13のまま3Dセキュアだけ無理やり後付けする」案も一応は検討しましたが、推奨しませんでした。EOLの土台に決済まわりの改修を重ねるのは、数年後に同じ崖からもう一度落ちるだけです。
状況を見にいくと、問題は決済だけではありませんでした。商品は約8万SKU、商品画像は4万点超。トップページのLCP（最大コンテンツの描画）は実測4.8秒で、スマートフォンからのカゴ落ち率は68%に達していました。さらに厄介だったのが、この百貨店ならではの要件です。外商顧客向けの掛け払い、店頭ポイントとの残高連携、のし・包装紙の指定、お届け先を複数に分ける歳暮配送。汎用のECには載っていない業務が、10年かけて2.13系へ作り込まれていました。
掛け払いの仕組みは特に根が深いものでした。外商顧客はECで注文しても即時決済せず、月末に基幹システム側で締めて請求する。この連携が、深夜のcronで動く自作バッチと、手作業のCSV受け渡しの二段構えで成り立っていました。10年のあいだに継ぎ足された処理が各所に散らばり、どの順番で何が動いているのかを誰も完全には把握していない。まずはこのバッチ群を読み解き、注文ステータスの分岐と基幹CSVの仕様書を起こすところから始めました。
最初に検討したのは、いっそShopify Plusへ全面移行する案です。結論から言えば、推奨しませんでした。外商の掛け払いと店頭ポイント連携、のし対応をShopifyのアプリと外部連携で再現すると、毎月のアプリ利用料と作り込みがかさみ、要件の3割は結局スクラッチ開発になる。百貨店の業務をプラットフォームに合わせて捨てる判断は、現場が許しませんでした。
ecbeingやecforceといったパッケージも見積もりを取りましたが、初期1,500万円超。この規模のEC年商に対しては過剰でした。選んだのは、EC-CUBE 4.2系への移行です。既存の業務ロジックを移植しやすく、決済プラグインがEMV 3DSに対応済みで、PHP 8.1で動く。現実的な落としどころでした。
移行で一番時間を食ったのは、華やかな新機能ではなく地味なデータでした。旧DBの文字コードがUTF-8とCP932の混在で、商品説明に「﨑」「髙」などの機種依存文字が紛れており、単純なdump移行では200件以上が文字化け。一件ずつ突き合わせて手で直しました。会員パスワードは旧2.13系が古い形式のハッシュで保存しており、そのまま4.2系へは持ち込めません。ハッシュ方式を移行時に変換できないため、初回ログイン時に全会員へパスワード再設定を促す導線を用意し、外商担当からの一斉案内とセットで進めました。
残りは順当でした。8万SKUの商品マスタはCSVで正規化し直し、税区分とのし可否のフラグを補完。歳暮の食品は軽減税率8%、雑貨は10%が混在するため、ここを商品マスタ側で持たせないと請求書がまた狂います。画像4万点はWebPとAVIFへ一括変換してCloudflare R2へ載せ、Cloudflare Imagesでリサイズ配信に切り替え。サイト内検索はEC-CUBE標準の重いLIKE検索をやめ、Meilisearchへ切り出しました。決済はSBPSのEMV 3DS対応APIへ差し替え。
カットオーバーは一発勝負を避けました。新サイトを別ドメインで先に立て、外商の主要顧客にだけ先行公開して掛け払いと配送指定の動作を実地で確認。問題がないと見極めてから本番ドメインを切り替え、旧URLは商品ページ単位で301リダイレクトを張り、10年ぶんに積み上げた検索評価を落とさないようにしました。SEOの観点では、ここを横着すると移行直後にアクセスが半減します。
提案から本番切り替えまで108日。お歳暮商戦の2か月前にカットオーバーを終える、ぎりぎりの線でした。
効果は数字に出ました。スマホのカゴ落ち率は68%から41%へ。決済エラーが原因の離脱は月420件から30件まで落ち、LCPは4.8秒から1.9秒へ改善。移行後3か月のEC売上は、前年同月比で22%増えました。保守が切れて誰も触れなかったサイトが、また売れる状態に戻った。
移行して終わり、にはしませんでした。EC-CUBE 4系も放っておけば数年で同じEOLの崖が来ます。本番後はセキュリティ更新の適用とプラグインのバージョン追従を月額の保守契約に含め、外商バッチの仕様書も納品物として残しました。次に担当が替わっても、また「誰も読めないサイト」に戻らないようにするためです。
老舗のECリプレイスで難しいのは、技術選定そのものより、長年の業務を「どれを残し、どれを捨てるか」の線引きです。プラットフォームに寄せれば運用は楽になりますが、百貨店の強みである外商と贈答の作法を捨てることになる。そこを残すと決めたから、EC-CUBE 4.2系という選択になりました。正解は事業の形で変わります。
そのECが、2025年の春に「使えなくなる」と通告されたのです。
既存サイトはEC-CUBE 2.13系。10年前に当時の制作会社が独自改修を重ねたもので、土台はPHP 5.6、MySQL 5.6、さくらのVPS上で動いていました。改修した制作会社は2024年に事業を畳み、保守の引き継ぎもないまま放置されていた状態です。
引き金はカード決済の本人認証義務化でした。クレジットカード・セキュリティガイドラインで、EC事業者は2025年3月末までにEMV 3-Dセキュア（本人認証2.0）へ対応することが事実上の必須要件になります。決済代行のSBPS（ソフトバンク・ペイメント・サービス）からは「3Dセキュア2.0に対応しないカートは取扱を停止する」という予告が届いていました。2.13系のままでは、4月以降カード決済そのものが止まる。
そもそもEC-CUBE 2.13系は2018年にサポートが終了しています。土台のPHP 5.6も2018年末でセキュリティ更新が切れており、本人認証以前に、放置しているだけで脆弱性が積み上がる構成でした。「2.13のまま3Dセキュアだけ無理やり後付けする」案も一応は検討しましたが、推奨しませんでした。EOLの土台に決済まわりの改修を重ねるのは、数年後に同じ崖からもう一度落ちるだけです。
状況を見にいくと、問題は決済だけではありませんでした。商品は約8万SKU、商品画像は4万点超。トップページのLCP（最大コンテンツの描画）は実測4.8秒で、スマートフォンからのカゴ落ち率は68%に達していました。さらに厄介だったのが、この百貨店ならではの要件です。外商顧客向けの掛け払い、店頭ポイントとの残高連携、のし・包装紙の指定、お届け先を複数に分ける歳暮配送。汎用のECには載っていない業務が、10年かけて2.13系へ作り込まれていました。
掛け払いの仕組みは特に根が深いものでした。外商顧客はECで注文しても即時決済せず、月末に基幹システム側で締めて請求する。この連携が、深夜のcronで動く自作バッチと、手作業のCSV受け渡しの二段構えで成り立っていました。10年のあいだに継ぎ足された処理が各所に散らばり、どの順番で何が動いているのかを誰も完全には把握していない。まずはこのバッチ群を読み解き、注文ステータスの分岐と基幹CSVの仕様書を起こすところから始めました。
最初に検討したのは、いっそShopify Plusへ全面移行する案です。結論から言えば、推奨しませんでした。外商の掛け払いと店頭ポイント連携、のし対応をShopifyのアプリと外部連携で再現すると、毎月のアプリ利用料と作り込みがかさみ、要件の3割は結局スクラッチ開発になる。百貨店の業務をプラットフォームに合わせて捨てる判断は、現場が許しませんでした。
ecbeingやecforceといったパッケージも見積もりを取りましたが、初期1,500万円超。この規模のEC年商に対しては過剰でした。選んだのは、EC-CUBE 4.2系への移行です。既存の業務ロジックを移植しやすく、決済プラグインがEMV 3DSに対応済みで、PHP 8.1で動く。現実的な落としどころでした。
移行で一番時間を食ったのは、華やかな新機能ではなく地味なデータでした。旧DBの文字コードがUTF-8とCP932の混在で、商品説明に「﨑」「髙」などの機種依存文字が紛れており、単純なdump移行では200件以上が文字化け。一件ずつ突き合わせて手で直しました。会員パスワードは旧2.13系が古い形式のハッシュで保存しており、そのまま4.2系へは持ち込めません。ハッシュ方式を移行時に変換できないため、初回ログイン時に全会員へパスワード再設定を促す導線を用意し、外商担当からの一斉案内とセットで進めました。
残りは順当でした。8万SKUの商品マスタはCSVで正規化し直し、税区分とのし可否のフラグを補完。歳暮の食品は軽減税率8%、雑貨は10%が混在するため、ここを商品マスタ側で持たせないと請求書がまた狂います。画像4万点はWebPとAVIFへ一括変換してCloudflare R2へ載せ、Cloudflare Imagesでリサイズ配信に切り替え。サイト内検索はEC-CUBE標準の重いLIKE検索をやめ、Meilisearchへ切り出しました。決済はSBPSのEMV 3DS対応APIへ差し替え。
カットオーバーは一発勝負を避けました。新サイトを別ドメインで先に立て、外商の主要顧客にだけ先行公開して掛け払いと配送指定の動作を実地で確認。問題がないと見極めてから本番ドメインを切り替え、旧URLは商品ページ単位で301リダイレクトを張り、10年ぶんに積み上げた検索評価を落とさないようにしました。SEOの観点では、ここを横着すると移行直後にアクセスが半減します。
提案から本番切り替えまで108日。お歳暮商戦の2か月前にカットオーバーを終える、ぎりぎりの線でした。
効果は数字に出ました。スマホのカゴ落ち率は68%から41%へ。決済エラーが原因の離脱は月420件から30件まで落ち、LCPは4.8秒から1.9秒へ改善。移行後3か月のEC売上は、前年同月比で22%増えました。保守が切れて誰も触れなかったサイトが、また売れる状態に戻った。
移行して終わり、にはしませんでした。EC-CUBE 4系も放っておけば数年で同じEOLの崖が来ます。本番後はセキュリティ更新の適用とプラグインのバージョン追従を月額の保守契約に含め、外商バッチの仕様書も納品物として残しました。次に担当が替わっても、また「誰も読めないサイト」に戻らないようにするためです。
老舗のECリプレイスで難しいのは、技術選定そのものより、長年の業務を「どれを残し、どれを捨てるか」の線引きです。プラットフォームに寄せれば運用は楽になりますが、百貨店の強みである外商と贈答の作法を捨てることになる。そこを残すと決めたから、EC-CUBE 4.2系という選択になりました。正解は事業の形で変わります。