EC-CUBEに強いレンタルサーバーの選び方｜おすすめ徹底比較

2025年7月25日2026年1月9日

EC-CUBEでネットショップを作ろうと思ったとき、意外と最初につまずくのが「レンタルサーバー選び」です。
同じ“EC-CUBE対応”と書かれていても、実際には 表示速度・安定性・運用のしやすさに大きな差が出ます。

たとえば、こんな悩みはありませんか？

「EC-CUBEが動くサーバーって結局どれ？公式掲載の見方が分からない…」
「PHPやDBの要件がややこしい。契約してから“動かない”は避けたい」
「最初は小規模でいいけど、アクセスが増えたら遅くなるのが怖い」
「バックアップはあるって書いてあるけど、復元が簡単なのか不安」
「注文メールが届かない・管理画面が重い・500エラー…って聞くと心配」
「将来VPSやクラウドへ移るかもしれない。最初から移行しやすい選び方は？」

ECサイトは、ブログや企業サイトと違って 止まる＝売上に直結します。
だからこそ、月額の安さだけで決めてしまうと、後から「もっと早く選び直せばよかった…」となりがちです。

この記事では、EC-CUBE 4系の動作要件（PHP/DB/必須拡張）を押さえたうえで、レンタルサーバー選びで失敗しないための比較軸を整理し、主要候補を横並びで検討できるようにまとめました。

目的別（早く立ち上げたい／低コスト／速度優先／法人・セキュリティ重視／運用を手放したい）に“選び方”が分かる
「対応している」と「快適に運用できる」の違いが分かる
導入手順、運用・セキュリティ、移転の考え方まで一気通貫で理解できる

「EC-CUBEで“長く売れるショップ”を作りたい」人が、最初のサーバー選びで遠回りしないためのガイドとして、ぜひ活用してください。

おすすめ比較のセクションへはこちらからジャンプできます。

まず結論：目的別のおすすめパターン（早見）

はじめに、EC-CUBE（ダウンロード版）で迷いやすいのは 「どこまで自分で運用するか」 です。
同じ“レンタルサーバー”でも、共用サーバーで自力運用するのか、EC特化で運用を手放すのかで、コスト感・難易度が大きく変わります。

早見表（ざっくり）

スクロールできます

目的	まず候補に入れるサービス例	月額の目安	向き・不向き
早く立ち上げたい	ConoHa WING / ロリポップ！	中〜	導入が楽。サーバー設定に時間をかけたくない人向け
低予算で始めたい	さくらのレンタルサーバ / シンレンタルサーバー	低〜	まずは小さく検証したい人向け（要・最低限の技術）
速度・安定性を優先	エックスサーバー / mixhost	中〜	集客が伸びても崩れにくい土台を作りたい人向け
法人・セキュリティ重視	CPI（法人向け）	高め	体制・サポート・運用品質を優先する企業向け
運用を手放したい	ec-cube.co / XServerショップ	低〜高	“サーバー運用”より“売ること”に集中したい人向け

とにかく早く立ち上げたい（自動インストール・手間少なめ）

結論：導入の「迷い」と「作業量」を減らしたいなら、セットアップが強いサービスを選ぶのが近道です。

おすすめ候補（例）

ConoHa WING（WINGパック）：プラン選びが分かりやすく、必要機能が揃いがち
ロリポップ！（ハイスピード等）：初心者でも管理画面が触りやすいタイプ

このパターンが向く人

まずは公開して、商品登録やデザイン調整に時間を使いたい
サーバー用語（PHP、DB、SSLなど）で手が止まりたくない
初期の売上より、立ち上げスピードを優先したい

最低限ここだけチェック（失敗しにくいポイント）

EC-CUBEが要求するPHP/DBのバージョンに対応しているか（※EC-CUBEのバージョンで条件が変わります）
無料SSLが簡単に設定できるか（ECは必須）
バックアップが自動で取れるか／復元しやすいか
将来の移転を見据えて、DBのエクスポートがやりやすいか

料金感のイメージ（目安）

ConoHa WING：WINGパックの月額表示あり（契約期間・キャンペーンで変動）
ロリポップ！：ハイスピードは月額表示あり（契約期間で変動）

ConoHa WING 公式サイト
ロリポップ！公式サイト

あわせて読みたい

ConoHa WING 徹底解説｜ブログ初心者が迷わず選べるレンタルサーバーの教科書「ブログを始めたいけれど、サーバーが多すぎてよく分からない……」「ConoHa WINGって名前はよく聞くけど、本当に初心者向きなの？」「エックスサーバーやシン・レンタル…

あわせて読みたい

ロリポップ！徹底解説｜特徴・料金・速度・他社比較まで一気にわかるガイド「ロリポップ！ってよく聞くけど、安いぶん性能が不安……」「エックスサーバーやConoHa WINGと比べて、どれを選べばいいかわからない」「WordPressブログを始めたいけど…

小規模から始めてコストを抑えたい（低予算・必要十分）

結論：初期は“最低限の要件を満たしつつ、無理に盛らない”がコスパ最強です。
ただしECは「遅い＝売上機会損失」になりやすいので、安さだけで決めないのがコツです。

おすすめ候補（例）

さくらのレンタルサーバ（スタンダード等）：低価格帯から始めやすい
シンレンタルサーバー：キャンペーンを含めると低予算で組みやすいことがある

このパターンが向く人

商品点数が少ない、まずは試験運用（テスト販売）をしたい
広告費をかけず、SEOやSNSでじわじわ育てる想定
将来の増強（プラン変更・移転）も前提で考えられる

コスト重視でも削らない方がいいところ

バックアップの取りやすさ（復元含む）
WAFなどの防御機能（ECは攻撃対象になりやすい）
画像が増えるので、ディスク容量に余裕があるか
管理画面・サポートが自分に合うか（詰むと結局高くつきます）

注意点（初心者がつまずきやすい）

EC-CUBEは「動けばOK」ではなく、更新・保守が現実に必要です。
低予算運用ほど、アップデート作業の時間コストも見込んでおくと安全です。

さくらのレンタルサーバ公式サイト
シンレンタルサーバー公式サイト

あわせて読みたい

さくらのレンタルサーバ徹底解説｜評判・料金・速度・WordPress対応まで丸わかり「エックスサーバーとかConoHa WINGと比べて、さくらって実際どうなんだろう……」「安いって聞くけど、表示速度が遅いサーバーはイヤだな」「WordPressを始めたいけど、…

あわせて読みたい

シンレンタルサーバー徹底解説｜高速表示とコスパを両立したWordPress向けサーバーとは「サーバーはシンレンタルサーバーが良いって聞くけど、正直どこがそんなに違うの？」「エックスサーバーと何が違うのか分からないまま、安いほうを選んでいいの？」「W…

速度と安定性を優先したい（アクセス増にも耐える）

結論：ECで“速さ”は体感品質＝売上に直結しやすいので、伸びる前提なら先に土台へ投資するのが合理的です。

おすすめ候補（例）

エックスサーバー：安定運用・バックアップ・サポートのバランスで選びやすい
mixhost：プランの幅が広く、伸びた後も拡張しやすいタイプ

このパターンが向く人

SEOや広告でアクセス増を狙う（セール時にアクセスが跳ねる）
商品点数が多い／画像が多い／検索や絞り込みが重い想定
「遅いから乗り換え」を避けたい

“速いサーバー”を選んでも、差が出るポイント

画像最適化、キャッシュ設計、不要プラグインの整理など
DBが肥大化しやすいので、運用ルール（ログ・不要データの扱い）も重要
決済・配送など外部連携が増えるほど、障害時の切り分け力が必要

判断の目安（初心者向け）

「まず安く」よりも、「運用が忙しくなる未来」が見えるならこちら
迷ったら、最初から中堅以上の定番どころを選ぶのが安全です

エックスサーバー公式サイト
mixhost 公式サイト

あわせて読みたい

エックスサーバー徹底解説｜メリット・デメリットからおすすめプランまで初心者向けに紹介「エックスサーバー、よく名前は聞くけど、本当に自分に合っているのか分からない……」そんなモヤモヤを抱えたまま、サーバー選びで手が止まっていませんか？「スタンダ…

あわせて読みたい

mixhost徹底解説｜評判・料金・速度・他社比較・アダルト対応まで本音レビュー「mixhostって速いって聞くけど、本当に表示速度は違うのかな？」「エックスサーバーやConoHa WINGと比べて、どっちを選べばいいか決めきれない……」「アダルトOKって書…

法人・セキュリティ重視で選びたい（サポート/体制優先）

結論：社内稟議・監査・顧客情報の扱いを考えると、“安さ”より“安心して運用できる体制”が価値になります。

おすすめ候補（例）

CPI（法人向け）：法人向けの料金設計・オプション体系で、運用体制を組みやすい

このパターンが向く人

企業サイトとしてECを運用（担当が交代しても回る必要がある）
セキュリティ要件がある（ログ管理、証明書、改ざん対策など）
トラブル時に「誰がどこまで対応するか」を明確にしたい

選定のチェックリスト（法人向け）

サポート窓口の範囲（メールだけか、電話/365日対応はあるか）
セキュリティ関連のオプション（証明書、改ざん検知、バックアップ等）
障害時の告知・復旧フローが分かりやすいか
EC-CUBEの保守（アップデート・脆弱性対応）を社内で担うのか外注するのかを先に決める

CPIレンタルサーバー公式サイト

あわせて読みたい

CPIレンタルサーバー徹底解説｜“安心を買うサーバー”「高いけれど安心」と言われる理由「CPIレンタルサーバーって、結局どうなの？」検索すると、こんな声がよく出てきます。「月額が高いけど、その分“本当に安心”なの？」「法人向けって聞くけど、うちみ…

インフラ運用を手放したい（クラウド/EC特化サービス）

結論：サーバー運用より“販売・運営”に集中したいなら、EC向けに設計されたサービスが最短です。
「EC-CUBEを使いたい」が目的でも、“自分でサーバーを見る前提”が必須ではありません。

おすすめ候補（例）

ec-cube.co（クラウド版）：売上規模に応じた料金体系。カスタマイズ前提の運用にも向く
XServerショップ（EC-CUBEベース）：販売手数料がかからない定額型を打ち出しているタイプ

このパターンが向く人

サーバー移転、障害対応、保守に時間を使いたくない
制作会社と連携し、継続的に改善していく想定
EC運営（集客・商品・CRM）に集中したい

選ぶときの考え方（失敗しにくい）

カスタマイズ要件があるか（テンプレ改修、独自機能、外部連携など）
売上が伸びたときの費用の増え方（固定費／従量課金／売上連動）
決済まわり（手数料、使える決済手段、審査）を事前に確認

注意点

便利な反面、「サーバーを自由に触れる」タイプの運用とは発想が変わります。
将来の移行も考えるなら、データの持ち出し（商品/顧客/受注/DB）の考え方だけは早めに押さえておくと安心です。

XServerショップ公式サイト

あわせて読みたい

XServerショップとは｜できること・料金・評判・始め方・他社比較を初心者向けに徹底解説「XServerショップって、名前は聞くけど結局なにができるの？」ネットショップを始めようとして調べ始めたとき、こんな疑問や不安にぶつかりませんか。「BASEみたいに…

EC-CUBEの基礎：どの提供形態を選ぶべきか

EC-CUBEは「同じソフト」でも、どこに置いて・誰が面倒を見るかで難易度とコストが大きく変わります。
初心者の方はまず、次の3択で考えると迷いが減ります。

スクロールできます

選び方	初期コスト	月額コスト	自由度	運用の手間	こんな人向き
ダウンロード版（自分で設置）	低〜	低〜	高い	多い	予算優先・カスタマイズしたい
クラウド版（運用負荷を軽く）	中〜	中〜高	高め（条件あり）	少ない	保守を外出ししたい・成長前提
EC運用特化サービス（EC-CUBEベース）	低〜中	低〜中	中	少ない	早く売りたい・サーバーを触りたくない

迷ったときの目安はこれです。

「まず公開して運営に慣れたい」 → 運用特化サービス / クラウド寄り
「予算を抑えつつ、将来は自由に育てたい」 → ダウンロード版
「保守・セキュリティに自信がない」 → クラウド / 運用特化サービス

自分でサーバーに設置する（ダウンロード版）

ダウンロード版は、EC-CUBEを自社サーバーやレンタルサーバーにインストールして使う方式です。
ソフト自体はオープンソースとして提供され、自分で自由に改変できるのが最大の魅力です。

何が「自分ごと」になるか（初心者がつまずきやすい点）

ダウンロード版は、EC-CUBEの導入だけでなく、次の運用も基本的に自分で担います。

アップデート（本体・プラグイン・依存ライブラリ）
セキュリティ対策（管理画面保護、WAF、権限、脆弱性対応）
バックアップ（取得だけでなく“復元テスト”まで）
障害対応（表示崩れ、500エラー、メール不達などの切り分け）

ここが不安なら、最初から「運用負荷が軽い選択肢」を選ぶのが安全です。

サーバー側で必ず満たす条件（ここだけ覚えればOK）

EC-CUBEはバージョンで要件が変わるため、「使うEC-CUBEのバージョン」→「対応PHP/DB」の順で決めます。

例：EC-CUBE 4.3系の要件（代表例）

Webサーバー：Apache 2.4（必須モジュールあり）
PHP：8.1〜8.3
DB：MySQL 8.0〜8.4 または PostgreSQL 12〜16（要件あり）

さらに、PDO系・OpenSSL・zip・intl・GDなど、必要なPHP拡張も揃っている必要があります。

費用の考え方（「無料」＝「タダで運用できる」ではない）

本体は無料でも、現実のコストは主にここで発生します。

サーバー代（毎月）
ドメイン代（年額）
決済手数料（決済会社との契約次第）
有料プラグイン・テーマ（必要なら）
外注費（保守、開発、デザイン）

コストを抑えるコツ

最初は「必要最小限のプラグイン」で運用し、後から足す
“安いサーバー”より、バックアップ復元が簡単な環境を優先する（復旧が早いほど損失が小さい）

ダウンロード版が向いている人

月額を抑えたい
デザインや機能を独自に作り込みたい
データやソースを「自分の資産」として管理したい
将来的にVPS/クラウドへ移行する可能性がある

運用負荷を減らす（クラウド版）

クラウド版（ec-cube.co）は、ざっくり言うと「EC-CUBEを運用しやすい形で提供してくれる」方式です。
ダウンロード版で自分が抱えがちな、メンテナンス・セキュリティ・サーバ保守の負担を軽くしやすいのが特徴です。

どう楽になるのか

クラウド側で用意されている機能例として、次のようなものがあります。

SSLの標準提供
独自ドメイン対応（初期はサブドメイン提供）
ステージング環境
Git管理や編集履歴、エラーログ取得など（運用で効くポイント）

「サイトを伸ばす」より前に、“止めない・壊さない”の土台を取りに行くイメージです。

料金イメージ（初心者向けにポイントだけ）

クラウド版は、固定費＋条件に応じた月額という考え方になります。
代表的なStandardプランでは、初期費用と月額レンジが公式に示されています（税抜表示・決済手数料は別契約）。

初期費用：70,000円
月額：49,800円〜84,800円（販売額条件による記載あり）

※ここは契約前に「自社の売上見込み」と「月額の増え方」を必ず照らし合わせるのが大事です。

クラウド版が向いている人

セキュリティ・保守に自信がなく、運用を安定させたい
社内に専任エンジニアがいない（もしくはコア業務に集中させたい）
将来的にカスタマイズしつつ、運用の仕組みも整えたい
ダウンロード版からの移行も視野に入れている

注意点（先に知っておくと失敗しにくい）

サーバーを“自由に触る”前提ではないため、やりたいことの実現手段を確認する
既存システム連携がある場合は、ログ取得・検証環境の有無が重要
「クラウドに任せる範囲」と「自社が責任を持つ範囲」を言語化しておく

EC-CUBEベースの“ショップ運用特化”サービスという選択肢

これは「EC-CUBEを土台にしつつ、ネットショップ運営に寄せた形で提供されるサービス」です。
レンタルサーバーに自分で入れるより、ショップ運営のスタートが楽になりやすいのが特徴です。

どんなメリットがある？

代表例として、XServerショップは「販売手数料0円」や「月額固定」などを打ち出しています。
こうしたタイプは、次のような方針の人と相性が良いです。

まずは売り始めたい（構築に時間をかけすぎたくない）
サーバー設定・保守の作業を減らしたい
月額コストを把握しやすい形がいい

ここは必ず確認（“楽そう”で飛びつく前のチェック）

運用特化サービスは便利な反面、サービスごとに設計思想が違います。契約前に次を確認すると安心です。

データの持ち出し：商品・顧客・受注データをどこまで移行できるか
プラグイン/カスタマイズの自由度：どこまで触れるか、制限はあるか
決済の選択肢：使える決済手段、手数料、入金サイクル
トラブル時の責任分界点：サーバー側／アプリ側／外部決済側の切り分け
将来、ダウンロード版や別基盤に移る場合の移行難易度

運用特化サービスが向いている人

技術よりも、まず 商品・集客・運営に集中したい
最初の立ち上げで挫折したくない
“作ること”より“回すこと”を優先したい

公式情報で押さえる：EC-CUBE 4系の動作要件と必須コンポーネント

EC-CUBEは「レンタルサーバーなら何でもOK」ではなく、バージョンごとに必要なPHP/DBが変わるのが特徴です。
まずは 「使うEC-CUBEの系統（4.3 / 4.2 / 4.0・4.1）」を決める → そのうえでサーバー側の条件を照合すると、失敗が激減します。

バージョン別の対応PHP/DB（4.3・4.2・4.0/4.1）

公式ドキュメントの要件を、初心者向けに「選ぶときの観点」が分かる形で整理します。

スクロールできます

EC-CUBE系統	PHP	DB（本番向け）	DB（開発向け）	サーバー側で注意しやすい点
4.3	8.1〜8.3	MySQL 8.0〜8.4 / PostgreSQL 12〜16	SQLite 3.x	共有サーバーだと「PHP 8.2/8.3が選べない」ケースがある
4.2	7.4〜8.1	MySQL 5.7 または 8.0 / PostgreSQL 10〜14	SQLite 3.x	PHP 8.1まで。4.3へ上げるとPHP要件が上がる
4.0 / 4.1	7.3〜7.4（※）	MySQL 5.7.x / PostgreSQL 9.6〜14（※）	SQLite 3.x	“古い前提”が多く、セキュリティ面で要注意

※4.0はさらに細かい差があり、初期の一部は PHP 7.1〜 を前提とする版があります（公式注記あり）。
またMySQLは InnoDB必須、PostgreSQLは pg_settings 参照権限が必須 といった条件もあるため、特に共有サーバーでは「契約前確認」が重要です。

初心者が迷いやすいポイント

SQLiteは“開発用途向け”なので、基本は本番に使わないのが安全です（性能・運用・障害対応の観点）。
公式の要件表は MySQL / PostgreSQL を前提にしています。レンタルサーバー側が「MySQL互換DB」を提供している場合は、公式対応として明記されているかを事前に確認すると安心です。
PostgreSQL運用は、共有環境だと「権限が足りない」問題が起きることがあるので、初心者はまず MySQL寄りで考えると詰まりにくいです。

必須PHP拡張・推奨拡張（キャッシュ系など）

EC-CUBEは「PHPが動く」だけでは足りず、必要な拡張（モジュール）が揃っていないとインストールや運用で止まります。
公式が提示している“必須/推奨”を、用途でまとめると理解しやすいです。

必須（ないと動かない・導入で詰みやすい）

DBドライバ系
- mysqli / pgsql（使うDBに合わせる）
- pdo_mysql / pdo_pgsql / pdo_sqlite（使うDBに合わせる）
- pdo
文字・データ処理系
- mbstring（日本語含む文字処理）
- intl（多言語・フォーマット周りで効く）
- json / xml / libxml（データの読み書き）
セキュリティ・通信系
- OpenSSL（暗号化・外部連携で必須級）
- cURL（外部API通信）
ファイル・圧縮・画像系
- zip / zlib（パッケージ系で必要になる場面が多い）
- fileinfo（ファイル判定）
- GD（画像処理）
実行基盤系
- session / ctype / phar など

さらに Sodium は、4.2系で特定プラグインを使う場合に必要になる、と公式注記があります。
「最初は使わないから不要」と決めつけず、将来入れそうな機能（API連携など）があるなら最初から入っている環境を選ぶのが安全です。

推奨（入れると体感が変わる・運用が安定しやすい）

Zend OPcache：PHP実行を高速化。ECでは“基本入っていてほしい”枠
APCu / WinCache：環境により有効（キャッシュで効く場面あり）
hash：多くの処理で利用される基盤機能

レンタルサーバー選びでの“現実的な確認方法”

初心者が一番ラクなのは、次の順番です。

サービス公式の「PHPバージョン選択」と「モジュール一覧」を確認
不明ならサポートに質問（テンプレ例）
- 「EC-CUBE 4.3を想定。PHP 8.1〜8.3、MySQL 8.0以上、OPcache、intl、GD、zip、Sodiumは利用可能ですか？」
契約後に最終確認（phpinfo()やphp -m など）

推奨スペックの考え方（CPU/メモリ/ストレージ/転送量）

ここは公式が「このCPU/メモリが必須」と厳密に数値指定している項目ではないため、“失敗しない考え方”としてまとめます。
ポイントは、ECの負荷は「アクセス数」だけで決まらないことです。

負荷を押し上げる主な要因

同時アクセス（セール・広告・SNS拡散）
商品点数・画像点数（高解像度が多いと転送量も増える）
絞り込み検索・並び替え（DB負荷が増えやすい）
プラグインの追加（処理が増えがち）
外部連携（決済・配送・在庫・MA）とバッチ処理（Cron）
管理画面での重い操作（CSV一括登録など）

ざっくり目安（初心者向けの現実ライン）

※あくまで「見積もりの起点」です。最終的にはアクセスと機能要件で上下します。

スクロールできます

想定規模	CPU	メモリ	ストレージ	転送量の考え方
小規模（検証〜小さく販売）	1〜2コア相当	2〜4GB	SSD 50GB〜	画像最適化で抑える
中規模（商品点数増・広告運用）	2〜4コア相当	4〜8GB	SSD 100GB〜	CDN検討で体感改善
大きめ（セール・同時アクセス前提）	4コア以上	8〜16GB	SSD 200GB〜	CDN＋キャッシュ設計必須級

“スペックより先に見るべき”現場ポイント

バックアップの世代数と復元のしやすさ（壊れたときの復旧速度が命）
上位プランへ上げやすいか（止めずに伸ばせるか）
DBの性能（ECはDBボトルネックになりやすい）
画像が増えるので、ストレージは「本体＋画像＋ログ＋バックアップ」で余裕を持つ

古いバージョン運用の注意点（更新・脆弱性・移行判断）

ECサイトは個人ブログよりも狙われやすく、「古いまま動かす」こと自体がリスクになりがちです。
初心者ほど、次の考え方で運用すると安全です。

まず押さえるべき基本

“最新版＝最強”ではなくても、「脆弱性対応版」は必須
放置すると、改ざん・情報漏えい・決済悪用のリスクが上がります。
公式は脆弱性情報を公開しているため、自分の利用バージョンが影響範囲かを定期的に確認するのが現実的です。

4.0〜4.1系を使い続けるなら、特に注意

公式ドキュメント側でも、4.0系の特定範囲について注意喚起があります。
さらに公式の脆弱性リストでは、過去に高危険度の情報公開があるため、古い版を固定して運用するのは避けたいところです。

移行判断の目安（初心者向け）

次のどれかに当てはまるなら、“現状維持”より移行計画を優先すると安全です。
- PHPの要件が古く、サーバー側が更新できない
- プラグインが更新停止で、脆弱性リスクが読めない
- 決済・配送など外部連携が増えてきた
- アクセス増で速度問題が出始めた

4.2 → 4.3で意識したいこと

4.3は PHP要件が8.1〜8.3 となるため、サーバー側で対応できないと移行できません。
また、PHPの非推奨警告が“エラー化”して止まるケースがあり得るので、移行時は 検証環境（ステージング） を用意するのが鉄板です。

失敗しないサーバー選定チェックリスト（比較軸の整理）

EC-CUBEのサーバー選びは、「いま動くか」だけでなく “運用し続けられるか” が重要です。
特に初心者の方は、比較の軸を固定しておくと迷いが減り、後戻り（移転・作り直し）も防げます。

まずは全体像として、次の考え方でチェックすると失敗しにくいです。

最低条件：EC-CUBEのバージョン要件（PHP/DB/拡張）を満たす
運用条件：バックアップ、障害対応、セキュリティ、更新のしやすさ
成長条件：アクセス増や機能追加に耐え、移転もしやすい

処理性能：CPU性能・同居ユーザー影響・ディスクI/O

ECサイトの体感速度は、売上に直結しやすいです。
ここで見るべきは「カタログスペック」よりも、混雑時に遅くならないかです。

チェックポイント

CPU（処理能力）
- vCPU数や上位プランの伸びしろ
- 同時アクセス時に処理落ちしにくい設計か
同居ユーザーの影響（共用サーバーの癖）
- 近隣ユーザーの負荷で遅くなる“当たり外れ”が出やすい
- リソース制限（同時接続数、プロセス数、実行時間）の上限が明記されているか
ディスクI/O（DBと画像で効く）
- SSD / NVMe などストレージ種別
- 「DBが重い」「管理画面のCSVが遅い」などのボトルネックになりやすい

初心者向けの判断基準

最初から完璧に見抜くのは難しいので、“遅くなったときの逃げ道” を用意するのが現実的です。
- 上位プランへすぐ切り替えできる
- キャッシュ/CDNなどを後付けできる
- DBのバックアップ・移行が容易（後述）

事前に確認する質問例（そのまま使えます）

「共用環境で、CPU/メモリ/同時プロセスの制限値は公開されていますか？」
「アクセス急増時に制限が発動すると、具体的にどうなりますか（503になる／遅くなる等）？」

データベース：MySQL/PostgreSQLの性能・バックアップ/復元

EC-CUBEはDB依存が強く、DBが弱いと全部が遅く見えることがあります。
さらに本当に重要なのは、障害時に “戻せるか” です。

チェックポイント

DBの種類と扱いやすさ
- MySQL / PostgreSQL の提供状況
- 共有サーバーでの権限や制限（作れるDB数、容量上限など）
バックアップ
- 自動バックアップの有無（毎日/手動など）
- 世代数（何日前まで戻れるか）
- 取得対象（DBだけ／ファイルも含む／両方）
復元（ここが最重要）
- 管理画面から復元できるか
- どの範囲を復元できるか（DBのみ／全体）
- 復元にかかる時間の目安（大容量だと差が出ます）

初心者がやりがちな失敗

「バックアップあるから安心」と思っていたら、復元が難しい／遅い／追加料金だった
DBだけ戻しても、画像や設定ファイルが戻らず サイトが壊れたまま になる

かんたん運用ルール（最低限）

DBバックアップ＋ファイルバックアップをセットで考える
月1回でもいいので、テスト環境で 復元の手順を一度だけ 実施して手順書を残す
- これだけで「詰み」を避けやすくなります

セキュリティ：WAF/SSL/権限管理/監視/ログ

ECサイトは、ブログより攻撃対象になりやすいです。
初心者ほど「自分が狙われるはずがない」と思いがちですが、実際は 自動スキャン が普通に来ます。

チェックポイント

WAF
- 提供の有無（標準かオプションか）
- ルール更新が自動か
- 誤検知したときの除外設定ができるか
SSL（HTTPS）
- 無料SSLの提供（Let’s Encryptなど）
- 証明書更新が自動か（更新ミスでサイト停止しないか）
権限管理
- FTPを使う場合は「ユーザー分け」できるか
- できれば SSH + 公開鍵 を使える環境が安心
監視・ログ
- アクセスログ／エラーログを確認できるか
- ログの保持期間（短すぎると原因追跡が難しい）
- 不正アクセス検知や通知があるか

初心者向けの最低ライン

無料SSL + WAF + 自動バックアップ が揃うと、事故が減ります
EC-CUBE側の更新（本体/プラグイン）と合わせて、サーバー側の防御も二段構えにするのが基本です

運用機能：SSH・Cron・ステージング・Git・自動更新のしやすさ

EC-CUBE運用で「あとから必要になる機能」がここに集まっています。
最初は不要でも、売上や連携が増えると 急に必須 になります。

チェックポイント

SSH
- Composer運用やログ調査で役立つ
- 権限・接続方式（鍵認証）を確認
Cron（定期実行）
- バッチ処理、メール送信、在庫連携、データ整理などで必要になりがち
- 実行間隔、同時実行の制限を確認
ステージング（検証環境）
- 本番を止めずに検証できるか
- 「本番コピー」「限定公開」が用意されているか
Git
- チーム開発、外注、復旧が一気に楽になります
- 使えなくてもよいが、使えると強い
更新のしやすさ
- PHPバージョン切替が管理画面でできるか
- 依存ライブラリ更新の自由度（共有だと制約あり）

初心者向けのおすすめ方針

最初から完璧に揃えるより、「検証環境を作れるか」 を優先すると事故が減ります
外注を混ぜる可能性があるなら、Gitかステージングのどちらかは欲しいです

サポート：問い合わせ導線、障害時の対応、情報公開の透明性

ECは「止まる＝売れない」なので、困ったときに頼れる導線は重要です。
サポートは“気持ち”ではなく、仕組みとして確認します。

チェックポイント

問い合わせ手段
- メールのみ／チャットあり／電話あり
- 対応時間（平日だけか、夜間休日もあるか）
障害時の対応
- 障害情報の告知があるか（ステータスページ等）
- 復旧見込み・原因の共有があるか
透明性
- 仕様、制限、停止条件が明記されているか
- 料金変更や仕様変更の告知が丁寧か

初心者に効く見極め方

「困ったら聞ける」より、「困らない設計になっているか」が大事です
- 例：バックアップ復元が簡単、ログが見られる、WAF/SSLが標準、など

費用：月額だけでなく“伸びた後の総コスト”で見る

月額の安さだけで決めると、成長時に「結局高くつく」ことがあります。
ECは特に、売上が伸びるほど運用コストも増えやすいです。

総コストに入れるべき項目

サーバー月額（上位プランに上げたときの価格）
ドメイン（年額）
バックアップ（復元に追加料金がある場合も）
WAFやCDN（必要になったときの追加費用）
有料プラグイン・テーマ
保守費（外注するなら月額固定になりやすい）
移転費（最悪ケース：移転作業で数万円〜）

初心者向けのコツ

まずは「売上ゼロでも回る固定費」を決める
そのうえで、成長時に どのタイミングで上位プランへ上げるか を先に決める
- 例：管理画面が重い／決済失敗が増える／セールで落ちた、など

拡張性：上位プラン移行、VPS/クラウドへ移る前提の設計

最初はレンタルサーバーで十分でも、いずれ負荷や要件で限界が来ることがあります。
だからこそ、最初から「移る前提」で設計するとラクです。

チェックポイント

上位プランへの移行
- 移行がワンクリックか、作業が必要か
- 料金差が急に跳ねないか
VPS/クラウドへ移行しやすいか
- DBのエクスポートが簡単か（mysqldump等）
- ファイル容量が大きくなっても移行できる導線があるか
- DNS切替やメール設定の自由度があるか
移行しやすい運用設計（自衛策）
- 画像やCSVなど重いファイルは整理ルールを作る
- 設定値はメモ化（環境差分で詰まない）
- 外注やチーム作業のために、手順書を残す

初心者向けの結論

いまの最適解より、「次の段階へ進める作り」 を優先すると後悔が減ります
特に「DB復元」「検証環境」「ログ確認」の3つができると、成長がスムーズです

公式掲載「EC-CUBEが使えるサーバー」情報の読み方（E-E-A-T強化ポイント）

公式の「EC-CUBEが使えるレンタルサーバ」ページは、初心者にとって “候補を絞る地図” としてとても有用です。
ただし、公式掲載＝どの環境でも快適・トラブルなし、という意味ではありません。

ここでは、公式ページを「安全に」「判断ミスなく」読み解くコツを整理します。

公式が案内する区分：オフィシャルパートナー／動作検証済み／利用実績

公式ページには、性質が異なる掲載枠が存在します。まずは“信用度の階段”として理解すると迷いません。

1) オフィシャルパートナー

特徴は 「契約すれば最初から使える」 と説明されている点です。
初心者に嬉しいのは、以下がセットになりやすいこと。

自動インストールや、導入を簡単にする導線がある
SSLやバックアップなど、運用に必要な機能が案内されている
公式ページ上でプランの目安が書かれていることがある（ただし価格は変動し得る）

読み方のコツ：

公式掲載の料金は“入口の目安”。最終判断は提供元の最新ページで確認する
「2系〜4系対応」「2系対応」など、どの世代まで想定されているかもチェックする

2) 動作検証済みレンタルサーバ

公式ページに 「EC-CUBE開発チームがインストール・動作検証を行った」 という説明がある枠です。
“検証済み”という言葉の価値は大きいですが、次の点を押さえるとさらに安全です。

検証は「ある時点・ある条件」での確認になりやすい
具体的なプラン差・制限（SSHやCronなど）は 各社へ問い合わせが推奨されている

読み方のコツ：

「検証済み」＝最低限の動作の安心材料
ただし あなたの運用（プラグイン・決済・連携・アクセス規模） まで保証するものではない

3) EC-CUBE使用レンタルサーバ（利用実績の申告）

公式ページに 「利用できると連絡を受けているが、開発チームでの動作検証は行っていない」 旨が明記されている枠です。
ここは“候補には入るが、最終確認が必須”のゾーン。

読み方のコツ：

公式に載っているから大丈夫ではなく、むしろ
「どのバージョンで」「どの条件で」動くのかを自分で詰める必要がある
事前に「PHP/DB」「必須拡張」「権限」「制限」を確認してから契約する

“対応”と“快適運用”は別：確認すべき項目（バージョン・PHP/DB・権限）

公式掲載の“対応”は、主に 「導入できる（動く）」 という話です。
ECはそこから先、止めずに回すのが本番なので、以下をセットで確認しましょう。

バージョン

まず決めるのはこれです。

使いたいのは EC-CUBE 4.3 / 4.2 / 4.0・4.1のどれか
それにより 対応PHP/DBが変わる
さらに 必須PHP拡張も揃っている必要がある

初心者向けの現実解：

公式の要件表を見て、「サーバー側でPHPのバージョンを選べるか」 を先に確認すると詰まりにくいです。

PHP/DB

“対応”の落とし穴はここです。

サーバーが古くて 必要なPHPに上げられない
MySQLは使えても、バージョンが条件を満たしていない
PostgreSQLを選びたいが、共有環境で 必要な権限が足りない（特に権限・参照周り）

チェックのしかた（テンプレ）：

「EC-CUBE◯系で運用予定。PHP◯.◯が選択可能か」
「DBはMySQL（またはPostgreSQL）で、バージョンは◯以上か」
「必須PHP拡張（intl、GD、zip、cURL、OpenSSL等）が有効か」

権限・制限

“動く”と“運用できる”を分けるのが権限です。特に差が出ます。

ファイル権限（書き込み可能ディレクトリの扱い）
実行制限（処理時間、同時実行、メモリ上限）
メール送信制限（注文メールが届かない・遅延する等の原因になりやすい）
WAFの影響（管理画面の操作や決済連携で誤検知することがある）

初心者はここだけ覚えると安全：

「管理画面で重い操作（CSV、画像大量、在庫連携）をする」＝制限が効きやすい
よって、ログ閲覧・バックアップ復元・サポート導線まで含めて“対応”を判断する

インストール方式の違い（簡単導入／手動導入）と落とし穴

公式掲載でも、サービスごとに導入のされ方が異なります。
初心者の失敗は「インストールの簡単さ」だけで選んで、後から運用で詰まるパターンです。

簡単導入（自動インストール）

メリット

クリック操作中心で、初期構築が速い
DB作成や初期設定がガイドされることが多い

落とし穴（初心者が見落としやすい）

置かれるEC-CUBEの バージョンが固定、または選択肢が少ない
“動く状態”にはなるが、運用に必要な
Cron、SSH、Composer運用が別途必要になることがある
自動インストール後の アップデート方針（どこまで自動／手動）が不明確だと、後で止まりやすい

対策

「インストールできるバージョン」「更新手順」を事前に確認
可能なら 検証環境（ステージング） を作れるサービスを優先

手動導入（自分でアップロード・設定）

メリット

バージョン選択・構成の自由度が高い
本番・検証の構成を自分で作りやすい

落とし穴

PHP拡張や権限でつまずくと、原因特定が難しい
“動くけど遅い”問題が出たとき、どこがボトルネックか分からない（DB / I/O / 制限）

対策（初心者向けの最小セット）

公式のシステム要件で 必須拡張をチェック
「バックアップ取得」だけでなく 復元手順も最初に確認
契約前にサポートへ「EC-CUBEでの運用実績」「制限値」「SSH/Cron可否」を聞く

主要レンタルサーバー比較（候補を横並びに検討）

まず前提として、EC-CUBEは「ECサイト＝止まると売上に直撃」になりやすい仕組みです。
そのためレンタルサーバー選びは、月額の安さだけでなく「復旧のしやすさ」「伸びた後の移行しやすさ」まで含めて判断するのが安全です。

ざっくり比較表（初心者向けの見取り図）

スクロールできます

候補	料金の目安（入口）	強み	注意点（EC-CUBE視点）
エックスサーバー	月額1,000円前後〜	高速・安定、運用機能が揃う	EC-CUBEは手動構築が基本。検証環境で動作確認推奨
ConoHa WING	月額700〜900円台〜（割引前提）	管理画面が分かりやすい、運用機能が豊富	料金が割引設計になりやすいので「更新後」も確認
ロリポップ！	月額600円台〜	低コストでも機能が揃いやすい	EC-CUBEの規模が大きいと上位プラン推奨になりがち
さくらのレンタルサーバ	月額500円台〜	老舗の安定感、長期運用の安心	構築・運用はやや“玄人寄り”になりやすい
mixhost	月額1,000円前後〜（初回割引あり）	cPanelで管理しやすい、高速系プランも選べる	初回割引と通常料金の差・更新後条件を要確認
シンレンタルサーバー	月額500円前後〜（長期）	コスパ良好、運用機能も揃えやすい	EC用途はバックアップ/復元動線を事前に試す
WADAX / CPI など	月額数千円〜（サービスにより差）	法人向け体制・機能を重視しやすい	価格帯が上がる分、要件を決めて“必要な分だけ”選ぶ
その他候補	要件次第	専用/クラウド/VPSで伸び代が大きい	運用負荷が上がるので「管理できるか」が分岐点

表の「料金の目安」は、契約期間・キャンペーンで変動します。最終判断は必ず公式の最新表示で確認してください。

エックスサーバー（高速・安定重視の候補）

向いている人

まずは“失敗しにくい”環境でEC-CUBEを運用したい
ある程度アクセスが伸びても耐えられる土台がほしい

ポイント

標準機能として、ECサイトで重要な Cron（定期実行） や SSH が使えるため、運用の自由度を確保しやすいです。
バックアップの保持期間が明示されているのは安心材料。まずは「復元の手順」を契約直後に一度だけ試すのがおすすめです。

EC-CUBE視点の注意

“簡単インストールでEC-CUBEが入る”タイプではないことが多いため、基本は手動構築（要件確認→アップロード/Composer→DB設定）を想定。
まずはテスト用ドメインで構築→本番に移すと失敗が減ります。

エックスサーバー公式サイト

あわせて読みたい

ConoHa WING（導入の手軽さ重視の候補）

向いている人

管理画面で迷いたくない
バックアップ・セキュリティを“標準で”持ちたい

ポイント

自動バックアップが全プラン標準で、復元も管理画面から進めやすい設計です。
機能一覧として SSH / Cron が明記されており、EC-CUBE運用で必要になりがちな作業（定期処理、ログ確認、デプロイ補助）がやりやすい部類です。
WAFや無料SSLの設定もサポート手順が整備されています。

EC-CUBE視点の注意

料金表示が「通常料金」と「長期割引（WINGパック）」で分かれるため、“初年度だけ安い”に見えないかを確認。
伸びた後に上位プランへ移す可能性があるなら、最初から移行手順（プラン変更・DB移行・DNS切替）を想定して設計すると安全です。

ConoHa WING 公式サイト

あわせて読みたい

ロリポップ！（低コスト帯の候補）

向いている人

できるだけ月額を抑えつつ、必要機能も確保したい
小規模スタートで検証し、売上が立ってから強化したい

ポイント

料金表が分かりやすく、契約期間ごとの月額が見えます。
WAF / SSH / cron など“運用に必要な機能”が公式マニュアルとして整理されています。
バックアップは「無料で提供される範囲」と「有料オプション」を切り分けて考えると混乱しません。

EC-CUBE視点の注意

EC-CUBEは画像・商品点数・受注データが増えるほど重くなりやすいので、最初から上位プラン前提で見積もるほうが現実的なケースがあります。
「バックアップの復元が誰の作業になるか（自分でやる/事業者がやる）」を契約前に確認してください。

ロリポップ！公式サイト

あわせて読みたい

さくらのレンタルサーバ（バランス型の候補）

向いている人

老舗サービスの安定感を重視したい
シンプルに長期運用していきたい

ポイント

EC-CUBEに言及があるプラン案内があり、CMS運用の土台として検討しやすいです。
WAF / SSH / cron / バックアップといった運用要素も公式の情報がまとまっています。

EC-CUBE視点の注意

初心者には、構築よりも「運用・保守（更新・ログ監視・復旧）」が難所になりやすいので、“困ったときに戻せる”設計（バックアップ世代・復元手順の確認）が重要です。

さくらのレンタルサーバ公式サイト

あわせて読みたい

mixhost（高速系プランを検討する候補）

向いている人

cPanelでサーバー管理をまとめたい
高速性を意識したプランを比較して選びたい

ポイント

バックアップ（JetBackupなど）やWAFなど、運用で必要になる機能の案内が見つけやすい部類です。
サイト運用を伸ばしていく前提なら、「復元の手順（画面→どこまで戻せるか）」を先に確認しておくと安心です。

EC-CUBE視点の注意

料金が「初回割引」前提の表示になることがあるため、更新後の月額と、必要なオプション有無をセットで確認してください。

シンレンタルサーバー（コスパ系の候補）

向いている人

コストを抑えつつ、現実的に運用できる機能がほしい
後から上位プランや別基盤へ移ることも見据えたい

ポイント

契約期間ごとの月額が提示され、費用感を計算しやすいタイプです。
バックアップやセキュリティなど、運用に必要な要素は「あるかどうか」ではなく、どれだけ戻せるか（世代/範囲/復元手順）で比較してください。

EC-CUBE視点の注意

本番運用に入る前に、管理画面で
- バックアップ取得
- 復元の導線
- DBの扱い（エクスポート/インポート）
  を一度だけ触っておくと、事故時の復旧が速くなります。

mixhost 公式サイト

あわせて読みたい

WADAX / CPI など（法人・セキュリティ寄りの候補）

向いている人

個人運用ではなく、体制・ルール（権限/監査/運用フロー）を整えたい
“止めない”ための仕組みに投資できる

ポイント

CPIは法人向けサービスとして、WAFやSSH、運用に関わる機能が明示されており、要件に合わせた設計を組みやすいです。
WADAXはサービスのラインナップにより価格帯が変わるため、「EC-CUBEに必要な要件」と「運用体制」から逆算して選ぶと無駄が出にくいです。

EC-CUBE視点の注意

価格が上がる分、必ず「何が増えるのか（バックアップ、セキュリティ、サポート、SLA、運用支援）」を言語化してから契約すると失敗しにくいです。

WADAX 公式サイト
CPIレンタルサーバー公式サイト

あわせて読みたい

WADAX 徹底解説｜“安さ重視”サーバーと何が違う？評価が割れる理由「WADAXって、法人向けで安心って聞くけど……結局、何がそんなに違うの？」レンタルサーバーを探していると、WADAXは“安さ重視”のサービスとは少し毛色が違うため、口コ…

あわせて読みたい

その他候補（自社要件に合えば検討枠）

レンタルサーバーで不安が出やすいのは、だいたい次のタイミングです。

商品点数・画像が増えて表示が重い
セール時にアクセスが集中する
バッチ処理や外部連携が増える
プラグイン/カスタマイズが多く、更新が怖い

この場合は、VPS/クラウド（例：各社VPS、IaaS、マネージド系）を検討枠に入れると伸び代が出ます。
ただし運用負荷も上がるので、「誰が保守するか」を先に決めてからが安全です。

料金帯・プラン選びのコツ（最初の落とし所）

最初のプラン決めで迷ったら、次の順で考えると決めやすいです。

まず「ショップ規模」を仮置き
- 小規模：商品点数少なめ、更新頻度も低め
- 中規模：商品点数・画像多め、ブログ/特集も回す
- 成長前提：広告やSNSで流入を作る、セールを打つ
小規模でも、EC-CUBEは画像とDBで重くなりやすい
→ “最安プラン”より 中位プランからのほうが結果的に移行が減ることがあります
契約期間割引は魅力ですが、最初は「半年〜1年」で様子見 → 手応えが出たら長期、が堅実です

EC-CUBEのバージョン対応（PHP/DBの条件）

サーバー選びで一番大事なのは、ざっくり言うと次の2点です。

EC-CUBEの対象バージョンが要求するPHP/DBに合うか
PHPのバージョンを運用中に上げられるか（将来の更新に耐えるか）

また、同じ「対応」でも差が出やすいので、次を確認してください。

管理画面でPHPのバージョン変更ができるか
DBのバージョンと、文字コード/照合順序の扱い
ComposerやCLIを使う前提の運用ができるか（SSHがあると有利）

バックアップと復元（世代数・復元手順・復元速度）

バックアップは“ある”だけでは不十分で、次の3点セットで見ます。

何をバックアップするか（ファイル / DB / メール）
どれだけ戻せるか（世代数・保持期間）
誰がどう復元するか（ワンクリック / 申請 / 自分で復元作業）

EC-CUBEはDBの比重が大きいので、DB復元のしやすさを最優先に見ると事故が減ります。

セキュリティ（WAF/SSL/アクセス制限/監視）

ECサイトでは、最低限ここまでは押さえたいです。

常時SSL（無料SSLでOK。運用を簡単に）
WAF（誤検知もあり得るので、ON/OFFやログ確認の導線が重要）
管理画面の防御（IP制限、強固なパスワード、二要素認証の活用）
アップデート運用（EC-CUBE本体/プラグイン/テーマの更新方針）

運用に必要な機能（Cron/SSH/ログ/メール到達）

EC-CUBE運用で後から効いてくる“地味に重要な機能”です。

Cron：定期処理・連携・自動化
SSH：ログ確認、デバッグ、デプロイ補助、Composer運用
ログ：障害時の原因特定（アクセス/エラー/メール）
メール：到達率対策（SPF/DKIM/DMARC、送信制限の確認）

クラウド/EC特化も比較に入れるべきケース

レンタルサーバー（共用/マネージド）にEC-CUBEを設置する方法は王道ですが、次のような状況では 「クラウド版」や「EC運用特化サービス」 も最初から比較に入れたほうが、結果的に失敗が減ります。

保守の担当者がいない／忙しくて更新できない（本体・ミドルウェア・セキュリティ周り）
障害時に原因調査や復旧をやり切れる自信がない（ログ、バックアップ復元、切り戻し）
アクセス急増があり得る（セール、SNS、メディア露出）
カスタマイズは必要だが、インフラ運用は手放したい
“止まらない運用”を優先し、費用はある程度許容できる

ポイントは、「最安で始める」より “運用の責任範囲をどこまで自分が持つか” を先に決めることです。

ec-cube.co（クラウド版）の特徴：保守・監視・スケール対応

ec-cube.co は、EC-CUBEをクラウドとして利用する選択肢です。
レンタルサーバーと比べると、サーバー保守や監視の負担を減らす方向に設計されています。

何がラクになるか（初心者が恩恵を感じやすい点）

監視・モニタリング（死活/エラー/リソースなど）をサービス側で実施
障害検知時の対応（緊急度が高い障害時に通知・対応）
バックアップ（アプリケーションファイル・DBダンプを定期取得）
定期メンテナンス（EC-CUBE本体反映やインフラ/ミドルウェア更新が運用として用意されている）
WAF / SSL / 管理画面のアクセス制御など、土台のセキュリティ機構が整っている

“スケール対応”の捉え方

クラウド版は、一般に「自分でサーバーを触って増強する」よりも、
サービス側が用意した枠組みの中で成長を吸収する発想になります。

売上や利用状況に応じた料金体系（一定額＋売上超過分の課金）が設定されている
監視や運用がセットになっているため、ピーク時の不安を減らしやすい

料金イメージ（公式表示を前提に整理）

初期費用：70,000円（税抜）
月額：49,800円〜84,800円（税抜）
売上（販売額）に応じた加算ルールがある（一定ライン超過で加算）
決済手数料は別途（決済は別契約として扱われる想定）

※ここは必ず、申込前に公式の最新表示で再確認してください（改定・条件変更があり得ます）。

注意点（導入前に把握しておくと安心）

自由度は高いが“無制限”ではない
例：インフラの細かなチューニングを自分でやるより、サービス仕様に合わせて運用する考え方になります。
メンテナンスによる停止があり得る
週次は停止なし、月次は停止を伴う更新がある、といった運用ルールが明示されています。
総コストは「月額＋売上連動＋決済周り」で見る
月額だけで比較すると判断を誤りやすいので、売上見込みとセットで試算するのが安全です。

Xserverショップ等：EC-CUBEベースで運用に寄せたサービスの特徴

「EC-CUBEを使いたいけれど、サーバー管理や細かな保守は任せたい」場合に検討しやすいのが、EC-CUBEベースの運用特化サービスです。
代表例として XServerショップは、月額定額・販売手数料0円を打ち出しています。

何が魅力か（レンタルサーバー直設置との違い）

毎月固定の料金で運用しやすい（売上が伸びても“販売手数料が増える”タイプではない）
EC-CUBEの脆弱性対策など、細かなアップデートを任せられる（＝運用負荷の圧縮）
管理画面ベースで、商品登録・受注管理・ページ内容やレイアウト調整などを進められる
条件付きで独自ドメインの永久無料特典が案内されている（対象条件あり）

料金イメージ（公式表示ベース）

月額：1,980円（税込）〜
販売手数料：0円

※初期費用や上位プランの差は、公式の料金ページで必ず最新条件を確認してください。

注意点（“運用に寄せた”サービスならでは）

便利な反面、サービスの設計上 できること/できないことが明確です
例：サーバー内部の自由度、特殊なミドルウェア構成、独自の運用ルールなどは、レンタルサーバー直契約より制約が出やすい傾向があります。
カスタマイズ前提の場合は、先に次を確認すると安全です
- テンプレート/プラグイン導入の自由度
- 検証環境（ステージング相当）の用意
- バックアップ取得と復元の手順
- “どこまでがサポート範囲か”（EC運用そのものは対象外、など条件がある場合）

XServerショップ公式サイト

あわせて読みたい

レンタルサーバーと比べたメリット/デメリット（自由度・責任範囲・コスト）

ここが意思決定の核心です。
初心者ほど「どれが一番いい？」になりがちですが、正解は あなたの体制で変わります。

比較の結論を掴む表

スクロールできます

観点	レンタルサーバーに自分で設置（DL版）	ec-cube.co（クラウド）	EC運用特化サービス（例：XServerショップ）
立ち上げスピード	ふつう（構築手順が必要）	速い寄り（基盤は用意済み）	速い寄り（運用導線が用意されがち）
自由度（設計/運用）	高い（自分で全部決められる）	高いがサービス仕様に従う	中〜高（サービス仕様に依存）
保守・監視の負担	自分の責任が大きい	サービス側が広く担当	サービス側が広く担当
セキュリティ更新	自分で計画して実施	運用として用意される	運用として用意される（範囲は要確認）
バックアップ/復元	サーバー機能＋自分の運用次第	定期バックアップが明示	仕組みの有無/範囲を要確認
コスト構造	月額中心（最初は安い）	月額＋（条件により売上連動）＋決済周り	月額定額で予測しやすい（販売手数料0円を訴求）
伸びた後の移行	自由だが作業は自分	データ移行手順が用意される場合あり	仕様次第（移行性は事前に確認）

迷ったときの判断ルール（実務的）

技術・保守に時間を割ける → まずレンタルサーバー直設置が向きやすい
売上を伸ばすことに集中したい／保守が不安 → ec-cube.co や運用特化サービスを比較に入れる
カスタマイズが重い（基幹連携/独自要件が多い） →
“自由度”だけでなく、「誰が運用責任を持てるか」 を最優先に決める（ここを曖昧にすると破綻しやすい）

導入手順：レンタルサーバーでEC-CUBEを動かす流れ

レンタルサーバーでEC-CUBEを立ち上げるときは、ざっくり次の順で進めると迷いません。

事前準備（ドメイン・SSL・DB・メール・テスト環境）
インストール（自動 or 手動）
初期設定（メール／税／配送／決済）
本番公開前チェック（動作・セキュリティ・バックアップ・復元）

「動いた！」で止めずに、“売上が発生しても壊れない状態” まで持っていくのがゴールです。

事前準備（ドメイン/SSL/DB/メール/テスト環境）

最初にここを固めるほど、インストールがスムーズになり、あとで詰まりにくくなります。

事前準備チェックリスト

スクロールできます

準備するもの	目的	最低限のチェック
ドメイン	本番URLの確定	`shop.example.com` など運用方針を決める
SSL	個人情報保護・決済の前提	無料SSLを有効化、httpsで表示できる
データベース	受注・会員・商品を保存	空のDBを作成、接続情報を控える
メール	注文確認など自動メール送信	送信元メールの用意、SMTP情報を控える
テスト環境	本番を壊さず検証する	`stg.example.com` などサブドメイン推奨

初心者が先に決めておくとラクな「2つの設計」

本番と検証を分ける
- 例：本番 shop.example.com／検証 stg.example.com
- プラグイン導入や税・送料設定の変更を、検証で試してから本番へ
バックアップの“復元”方法を先に確認
- バックアップは「取れるか」より 「戻せるか」 が重要です
- 管理画面で復元できるのか、復元対象はDBだけか/ファイルも戻るかを確認しておきます

自動インストールで始める手順（対応サーバー向け）

「簡単インストール」「クイックインストール」などが用意されているレンタルサーバー向けの進め方です。手順そのものはシンプルですが、“選んだ設定があとから効いてくる” のが落とし穴です。

手順（流れ）

ドメインを設定し、https（SSL） を有効化
サーバーの管理画面で、PHPのバージョンやDBを確認（必要なら変更）
「簡単インストール」からEC-CUBEを選び、インストール先（ディレクトリ）を指定
DBを作成（または選択）し、インストーラに接続情報を入力
管理者アカウントを作成し、インストール完了
管理画面へログイン → 初期設定（メール/税/配送/決済）へ

落とし穴になりやすいポイント

入るEC-CUBEのバージョンが固定されている（または選べる範囲が狭い）
→ 使いたいプラグインが対応しない、という事態が起きがちです
PHPのバージョンが合わず、管理画面で赤字エラーが出る
インストール先のパスが意図と違い、URLが二重になる
- 例：/shop/に入れたつもりが/public_html/shop/shop/になっていた…など
“インストールはできた”が、メールが届かない
- まずはテスト注文で、自分宛に送信されるか確認しましょう 📩

手動インストールの要点（権限・Composer・環境差分）

EC-CUBEはファイル数が多いので、手動導入では「アップロード」と「権限」でつまずきやすいです。
ポイントは、サーバーの制約（権限・実行時間・SSH可否）に合わせてやり方を選ぶことです。

手順（流れ）

EC-CUBEのパッケージを用意する（公式配布のパッケージを使うのが安全）
サーバー上にファイルを展開する
- ZIPをサーバー上で解凍できるなら、そのほうが安定しやすいです
- FTPで大量ファイルを一気に上げると失敗しやすいので注意
ブラウザでインストールURLにアクセスし、インストールウィザードを進める
権限チェック → サイト設定 → メール設定 → DB設定 → DB初期化 → 完了
管理画面にログインし、初期設定を整える

Composerの扱い（初心者向けの現実解）

共有レンタルサーバーは、環境によって Composer実行が難しいことがあります（SSH不可・制限が厳しい等）
その場合は、
- サーバー上では無理にComposerを回さない
- 開発PCや検証環境で依存関係を整え、完成物をアップする
  という運用のほうが安全です
もし「EC-CUBE 4.0/4.1系」を使う場合は、Composerの世代の違いでハマりやすいので、できるだけ新しめの系統での運用を推奨します

環境差分で詰まないコツ

本番と検証で、次の差が出やすいです
- PHPバージョン／拡張モジュール
- DBの種類・バージョン
- メール送信（SMTPの制限や迷惑メール判定）
だからこそ、検証環境は 本番と同じサーバー（同条件） で作るのが堅実です

DB作成〜接続設定でつまずきやすいポイント

DB周りは、エラーが出ても原因が分かりにくいので、最初に“よくある詰まり”を潰しておくと楽です。

ホスト名の勘違い
- localhost なのか、サーバー会社が指定する専用ホスト名なのか
DBユーザーの権限不足
- 作成したはずのDBに接続できない／テーブル作成で失敗する
文字コード・照合順序
- 日本語商品名・住所などを扱うので、DB側の設定は慎重に（迷ったらサーバー推奨に合わせる）
接続情報の管理
- DBパスワードをメールやメモに雑に残すのは危険です
- “誰が見られるか” を意識して保管しましょう

トラブル対応の基本はこれです：

入力値（ホスト名・DB名・ユーザー名）を コピペで揃える
DBは「空のDBを新規作成」してやり直す（初期化が早い）

初期設定で必ず見直す項目（メール、税、配送、決済）

インストール直後の状態は、あくまで「動作確認の初期値」です。
ECとして公開する前に、最低限ここは押さえてください。

メール（最優先）

注文メール・会員登録メールなどが 想定どおり届くか
送信元アドレスが実在し、返信を受けられる状態か
必要ならSMTPを使い、到達性を上げる（迷惑メールに入らない工夫）

テスト方法（おすすめ）

自分でテスト注文 → 受注メールが届くか確認
Gmailなど複数のメールで受信チェックすると安心です 📩

税

税率が現行の運用に合っているか
軽減税率や、将来変更がある場合の扱い（予約設定の考え方）

配送

配送方法（宅配便／メール便など）と送料の設定
地域別送料・条件（一定額以上送料無料など）の方針
決済と配送の組み合わせ（代引きは宅配のみ、など）を運用で破綻しないように

決済

最初は「銀行振込」等の手動決済でもOKですが、実運用ではクレカ等の導入が前提になりがちです
決済手数料・利用条件（金額条件など）を設定し、購入画面の表示を確認

運用フェーズ：速さと安定性を作るサーバー設定

EC-CUBEの体感速度は、だいたい次の順で決まります。

PHP（動的処理の“素の速さ”）
静的配信（画像・CSS・JSの“配り方”）
DB（注文・会員・検索の“詰まり”）
Cron（重い処理を“営業時間外に逃がす設計”）

最初にやるべきことはシンプルで、「遅い箇所を決め打ちせず、計測 → 改善 → 再計測」です。
（体感で触ると、無駄に設定を盛って不安定にしがちです）

PHP最適化（OPcache/メモリ/タイムアウト）

EC-CUBEはページ生成がPHP中心なので、ここが一番“効き”ます。

OPcacheは原則ON（共有サーバーでも最重要）

OPcacheは「PHPのコンパイル結果をメモリに置いて再利用する」仕組みで、ECのように同じ画面が何度も呼ばれる構成と相性が良いです。

OPcacheがOFFだと、アクセスが増えた時に一気に苦しくなりやすい
逆に、ONにするだけで体感が改善するケースも多い

設定できる場合は、まずこの3点を意識してください（値は“目安”でOK）。

メモリ枠（opcacheのメモリ）をケチりすぎない
キャッシュできるファイル数（max_accelerated_files）を不足させない
更新検知（validate_timestamps）の方針を決める
- 本番は「デプロイ時にキャッシュクリア」運用が安定しやすい

メモリは「通常アクセス」と「管理画面作業」で分けて考える

EC-CUBEは管理画面（CSV/画像/プラグイン更新など）で一時的に重くなることがあります。

memory_limit が低いと、特定操作だけ失敗する（画面が白くなる等）
ただし無制限は危険なので、“必要十分”に上げるのが基本です

目安の考え方

まずは現状の上限を確認
管理画面で重い作業（CSV、商品一括更新など）を試す
エラーが出るなら、段階的に上げる（いきなり極端に上げない）

タイムアウトは「伸ばす」より「重い処理を逃がす」

max_execution_time を伸ばせば“とりあえず動く”ことはありますが、ECではおすすめしにくいです。

タイムアウト延長＝ユーザー待ち時間が伸びる
混雑時にタイムアウト待ちの処理が積み上がると、全体が不安定に

基本方針はこれでOKです。

ブラウザで待たせる処理 → なるべく短く
重い処理 → Cronやバッチ（CLI）に分離して非同期化

キャッシュクリアの“正しいやり方”を運用手順に入れる

プラグイン導入やテンプレ更新後に表示が崩れたら、まずキャッシュを疑います。

管理画面からキャッシュ削除できる導線がある
CLIで cache:clear / cache:warmup を使う運用も可能

重要：本番は「キャッシュ削除 → 事前生成（warmup）」までやると初回アクセスが安定します。

画像・静的配信の最適化（キャッシュ/CDN）

EC-CUBEは商品画像が増えるほど、ページそのものより“画像配信”がボトルネックになりがちです。

画像最適化は「サイズ」と「形式」で8割決まる

まずはこの2つだけでOKです。

表示サイズに合わせて画像を用意する（無駄にでかい原画像を配らない）
可能ならWebPなど軽い形式を使う（対応範囲に注意）

チェックのしかた

トップ・カテゴリ・商品詳細で、画像が“重い順”に並べる
一番重い10枚を軽くするだけで体感が変わります

静的ファイルは“長くキャッシュ”、動的ページは“キャッシュしない”

CDNやブラウザキャッシュは強力ですが、ECは混ぜると事故ります。

CSS/JS/画像：長めの Cache-Control でキャッシュさせる
カート/購入/マイページ：キャッシュ禁止（ユーザーごとに内容が違う）

安全な定番パターン

ファイル名にバージョン（ハッシュや更新日時）を付ける
そのうえで静的ファイルは長期キャッシュ
動的ページは private や no-store を明確に

CDN導入が効きやすいケース

次に当てはまるなら、CDN（例：Cloudflare等）を検討する価値があります。

画像点数が多い（商品数が多い、一覧で画像を大量表示する）
地域が分散している（全国からアクセスがある）
セールやSNSで瞬間的にアクセスが増える

注意点

“全部キャッシュ”は危険。静的だけを明確にルール化する
先に「どのURLをキャッシュして良いか」を決めてから設定する

DBメンテナンス（ログ肥大化、インデックス、バックアップ運用）

DBは「遅くなると、復旧も遅い」です。ECは特に “育つほどDBが効く”ので、早めに型を作るのが得です。

ログ肥大化の対策は「増える前提」でルール化

放置すると増えがちなもの（例）

アプリのログ
連携処理の履歴
セッションや一時データ

やることはシンプルです。

何が増えるか把握する
保存期間を決める（例：90日など）
削除・ローテーションをCronで回す

インデックスは“よく使う検索条件”にだけ付ける

インデックスは速くしますが、増やしすぎると更新が重くなります。

まず見る場所

管理画面：受注一覧、会員検索、商品検索
フロント：商品一覧の絞り込み、検索、注文確定までの一連

基本はこれだけ覚えればOKです。

WHERE / JOIN / ORDER BY で頻繁に使う列にインデックスを検討
体感が悪い画面から順に、遅いSQLを特定 → 対応

バックアップ運用は「取得」より「復元」が本番

ECで大事なのは、障害時に“何分で戻せるか”です。

最低限の運用セット

DBバックアップ：毎日（できれば世代保持）
ファイル：毎日（画像やカスタマイズを含む）
復元テスト：四半期に1回でも良いので実施（検証環境に戻して確認）

復元の速さは、売上の損失を左右します。
「戻せること」を“作業手順”として文章化しておくのが強いです。

Cronで回す処理の設計（バッチ/メール/在庫連携など）

Cronは“便利な自動化”ですが、設計が雑だと 静かに本番を壊すので、最初にルールを決めておくのがおすすめです。

Cronに逃がすと安定する典型例

在庫・価格の外部連携
受注データの集計・出力
レポート生成
重いメンテ（ログ削除、バックアップ転送、キャッシュ生成）

「ブラウザで待たせる」処理を減らすほど、ECは安定します。

失敗しないCron設計のルール

同じ処理を二重起動させない（ロックの仕組みを入れる）
標準出力/エラーは必ずログへ（無言で失敗しない）
実行時間の長い処理は、時間帯を分ける（営業時間外へ）
環境変数や実行ユーザーを固定（本番/検証を取り違えない）

Cronは「出力があるとメール送信される」挙動が一般的です。
通知を活かすなら、MAILTOを設定し、失敗を見逃さない形にします。

EC-CUBE側の“バッチの作り方”の考え方

EC-CUBEはCLIコマンド（bin/console）を使った運用が可能なので、

EC-CUBEのコマンドを作る（または既存コマンドを使う）
Cronで定期実行する
実行後に必要ならキャッシュ生成（warmup）

という流れにすると、運用がきれいにまとまります。

セキュリティと継続運用

EC-CUBEは「公開して終わり」ではなく、更新し続けることが安全性そのものになります。
ここでは初心者でも運用に落とし込めるように、実務で効く“型”として整理します。

アップデート方針（本体/プラグイン/依存ライブラリ）

まず決めるべき「更新のルール」

更新は気合いで回すと破綻しがちなので、最初にルールを固定します。

通常更新（機能改善・安定化）：月1回（検証→本番）
緊急更新（脆弱性対応）：告知を見たら最優先で対応（検証は短くても必須）
大きめ更新（4.1→4.2など）：作業手順書を作ってから実施（ロールバック手段も用意）

EC-CUBEの更新は「3点セット」で考える

EC-CUBEは本体だけ更新しても安全になりません。次の3つをセットで扱います。

本体（EC-CUBEコア）
プラグイン
依存ライブラリ（Composer）

特に4系では、バージョン帯によってComposer周りの前提が変わることがあります。古い系統を運用している場合は、プラグイン管理の仕組みも含めて注意が必要です。

“失敗しない”更新手順のテンプレ

次の流れを毎回同じにすると、事故が減ります。

バックアップ（ファイル一式＋DB）
メンテナンスモード（購入導線を止める）
プラグイン更新（先に互換性を揃える）
本体差し替え（変更範囲を意識して置換）
Composer更新（composer.json / lock を含め整合性を取る）
マイグレーション（スキーマ更新）
キャッシュ再生成
テンプレート差分の反映
メンテ解除 → 重要画面の動作確認（購入・メール・管理画面）

コツ：検証環境（ステージング）で「購入テスト（ダミー決済）」まで通してから本番へ。

脆弱性情報のチェックは“公式一本化”が安全

EC-CUBEは脆弱性情報の公開方針が明確で、公式告知として追えるのが強みです。
日々の運用では、次の2つを習慣化すると十分に回ります。

脆弱性リストを定期確認（最低でも月1回）
緊急のお知らせが出たら即対応（本体・公式プラグインを含むケースあり）

管理画面の防御（IP制限、強固な認証、権限分離）

ECの攻撃は「管理画面」か「決済まわり」に寄ってきます。
初心者でも効く防御は、まず“到達させない”ことです。

IP制限は最優先（できる範囲で）

EC-CUBE 4系では、管理画面へのIP制限（拒否リスト）が用意されています。
「怪しいIPが分かっている」「総当たりが来ている」などの場合に効果的です。

まずは拒否リストで攻撃元を塞ぐ
可能ならサーバー側でも追加で制限（.htaccess / WAF / 管理画面だけBasic認証など）

さらに4.2.1以降では、フロント画面側にもIP制限（許可・拒否）が用意されており、不正アクセス（例：カード情報の不正試行が疑われるアクセス）対策としても使えます。

強固な認証の“最低ライン”

管理者パスワードは 長く・使い回さない（パスワードマネージャ推奨）
管理者IDを共有しない（個人ごとにアカウント発行）
退職・外注終了時は 即時に無効化
ログイン失敗が増えたら、早めに制限（IP制限／ロック系の仕組み）

EC-CUBE公式のセキュリティ系プラグイン（例：管理画面ログインのロック強化など）が提供されていることもあるので、「自前で実装する」前に選択肢として確認すると安全です。

権限分離（“できる人”を増やさない）

運用が回り始めるほど、アカウントは増えがちです。
増やすほどリスクも増えるので、次の分け方が現実的です。

フル権限：あなた（または責任者）のみ
受注処理担当：受注・発送に必要な範囲だけ
商品登録担当：商品・画像・カテゴリ周りだけ
開発/外注：検証環境中心、本番は最小権限（作業時間も限定）

バックアップ戦略（頻度・世代・復元テスト）

バックアップは「取っている」だけでは弱く、戻せることが保証です。
ECでは復旧の遅れがそのまま機会損失になりやすいので、最初に“型”を作ります。

最低限の設計（初心者向けの現実ライン）

DB：毎日（できれば自動）
ファイル（画像・カスタマイズ含む）：毎日
世代：14日以上（できれば30日）
保管場所：サーバー内だけで完結しない（可能なら外部保管も）

目安として、DBは「受注・会員・在庫」が入る心臓部です。DBだけ戻っても、画像や設定が戻らないと復旧が崩れるため、DB＋ファイルはセットで扱います。

復元テストは「四半期に1回」で十分効果が出る

復元テストは毎回やる必要はありませんが、ゼロだと本番障害で詰みます。

復元テストのミニ手順（検証環境でOK）

バックアップから DBを復元
ファイル（画像・カスタマイズ）を復元
次の3点だけ確認
- フロント表示
- 管理画面ログイン
- テスト注文（メール送信まで）

この“3点セット”が通れば、最悪時の復旧手順として成立しやすいです。

決済まわりの考え方（外部決済・トークン化等の基本）

結論から言うと、初心者が安全に運用するなら 「カード情報を自サーバーで扱わない」のが基本です。
責任範囲を最小化でき、運用難易度が一気に下がります。

決済連携の方式と、負担の違い

スクロールできます

方式	ざっくり概要	自サーバーに残るもの	運用の難しさ
リダイレクト/ホスト型決済ページ	決済会社のページで支払い	注文情報のみ（カード番号は扱わない）	低〜中
トークン化（JSでトークン発行）	カード情報を直接決済会社へ送り、トークンだけ受け取る	トークン（カード番号は扱わない）	中
自サーバーでカード情報を処理	自サイト上でカード情報を受け取る	カードデータに触れる可能性	高（非推奨）

トークン化は「カード番号の代わりに使える“代替文字列（トークン）”だけを自サーバーで扱う」考え方です。
これによりカード番号を保持せずに決済連携でき、リスクと運用負担を下げられます。

なぜ“外部決済寄せ”が安全なのか

カード情報を自社サーバーに通さない設計にすると、攻撃対象が減る
実務上、自己管理の範囲が小さくなり、チェック項目も絞れる
決済会社側がセキュリティ運用を担う領域が増える

EC-CUBE運用で気を付けたい「決済攻撃」

ECサイトは、カードの不正試行（自動化されたアクセス）を受けることがあります。
やっておくと効く対策は次の通りです。

WAFを有効化し、怪しい挙動をブロック
不審IPを見つけたら IP制限（拒否）
管理画面・フロントともにログを確認し、急増に気付ける状態にする
決済プラグインは 常に最新（脆弱性告知が出たら最優先で更新）

アクセス増・機能追加に備える：移転とスケールアップ

EC-CUBEは「最初は軽い→育つほど重くなる」タイプのEC基盤です。
だからこそ、最初から完璧なインフラを作るよりも、段階的に“上げていける設計”にしておくと失敗しにくくなります。

ここでは、初心者でも判断しやすいように

まずやるべき「同一サービス内の上位プラン」
VPS/クラウドに移るタイミング
移転時に事故りやすいポイントのチェックリスト

を順番に整理します。

同一サービス内で上位プランへ（まずはここから）

結論として、性能が足りなくなったときは 「同じレンタルサーバー内で上位プラン」が最優先です。
理由はシンプルで、移行コストとリスクが最小だからです。

上位プランに上げるべき“分かりやすいサイン”

次のような症状が出たら、まずは上位プランを検討します。

セールやSNS流入で 表示が遅い／タイムアウトが増える
管理画面でCSVや画像登録が重く、作業が止まる
注文が増えたタイミングで 受注一覧・商品検索が遅い
画像が増え、ストレージや転送量の余裕がなくなる

上位プラン移行で「増えることが多いもの」

サービスやプランによりますが、主に次の余力が増えやすいです。

CPU/同居影響の軽減（混雑時の落ち込みが緩和）
メモリ余力（管理画面操作の安定）
ディスクI/O（DB・画像の読み書きが安定）
バックアップ世代や復元手段（運用がラクに）

同一サービス内でも“切り替え前に確認したい”注意点

プランアップが「完全な無停止」になるかは、事業者や方式次第です。
最低限、次を先に確認しておくと安全です。

PHP/DBのバージョン条件が変わらないか（EC-CUBE側要件に影響）
IPアドレスが変わる可能性（変わるならDNS・SSL・メール影響が出る）
移行支援機能があるか（動作確認URL／簡単移行／マイグレーション等）
バックアップの復元方法（ボタンで戻せるのか、申請が必要か）

コツ：上位プランへ上げる前に、検証環境（ステージング）で「同条件に寄せる」ほど移行がラクになります。

VPS/クラウドへ移る判断基準（負荷・要件・運用体制）

上位プランでしばらく伸ばせますが、どこかで「共有サーバーの枠」を超える瞬間が来ます。
そのタイミングは、“負荷”だけでなく“要件と運用体制”で決めるのが現実的です。

VPS/クラウドへ移るべき判断ポイント

次のうち、複数当てはまるなら移行を具体化してOKです。

速度対策をしても、ピーク時に CPU/DBが頭打ちになる
Redis / Elasticsearch / Queueなど、サーバー側の追加コンポーネントが必要
同居影響を避けたい（安定性の優先度が上がった）
セキュリティ監査や社内規定で、構成管理・ログ管理・権限分離を厳密にしたい
障害対応を内製できる（または保守運用を委託できる）

逆に、まだレンタルサーバーで粘れるケース

月間の売上が安定しきっていない（先に商品・導線改善の余地が大きい）
インフラ担当がいない／運用負荷を増やしたくない
「まずは安定稼働」が優先で、構成の自由度はそこまで要らない

迷ったら：“いま困っているのは性能不足か、運用不足か”で切り分けると判断しやすいです。
性能不足ならスケール、運用不足ならクラウド/EC特化寄せが効きやすいです。

移転チェックリスト（DB/SSL/DNS/メール/SEO影響）

サーバー移転は、作業そのものよりも「切り替えの瞬間」に事故が起きます。
ここでは、初心者でも抜け漏れしにくいように “切り替え前→切り替え→切り替え後”でチェック項目を並べます。

移転前（準備フェーズ）

現状把握
- EC-CUBEのバージョン、本番PHP/DB、Cronの有無、メール送信方式（SMTP等）
バックアップ
- DB（必須）＋ファイル一式（画像・カスタマイズ含む）
- 復元手順をメモ（どの画面/どのコマンドで戻すか）
移転先の受け皿を先に作る
- ドメイン設定、SSLの発行準備、DB作成、メールアカウント作成
動作確認の仕組み
- 可能なら「動作確認URL」やhosts切り替え等で、本番URLを切り替える前にチェックできるようにする

切り替え直前（“差分”を小さくする）

ECは移転中も注文が入るので、差分（データのズレ）をどう抑えるかが重要です。

切替時間を決める（深夜・早朝など）
メンテナンスモードで購入導線を止める（差分を止める）
最終同期
- DBの最終エクスポート → 移転先へインポート
- 画像やアップロードファイルの最終コピー
キャッシュ類は持ち越さない（移転先で再生成するほうが安全）

DNS/SSL（切替の“要”）

DNS切り替えは「徐々に反映」されるため、旧サーバーと新サーバーが混在する時間が発生します。
この期間に事故を起こさない設計が大切です。

DNS切り替え前に、移転先が httpsで正常表示できることを確認
旧サーバーでも一定期間はサイトを残しておく（混在期間の保険）
可能ならDNSのTTLを事前に短く（反映を早めやすい）
SSLは「新サーバー側で新規発行」になるケースが多いので、発行手順と完了確認を先に

メール（意外と落とし穴）

ECは「注文メールが届かない」が致命傷です。

移転先に 同じメールアカウントを作る（必要ならパスワードも再設定）
SPF/DKIM/DMARC等のDNS設定を使っているなら、レコードの引き継ぎを確認
切替後に テスト注文 → 受注メールが届くかを必ずチェック

SEO影響（結論：URLが変わらなければ影響は最小化しやすい）

同一ドメイン・同一URLでサーバーだけ変えるなら、基本的に大きなSEO変動は起こりにくいです
ただし次のミスは順位に響きやすいので要注意です
- http/httpsの混在（正規URLが揺れる）
- canonical設定の崩れ
- 画像やCSS/JSが404になり表示が崩れる
- リダイレクト設定のミス（意図しない301/302）

URL構造やドメインが変わる場合は、リダイレクト設計（301等）を前提に計画します。

切替後（“本番チェック”で終わらせない）

切替直後に最低限見る場所はこれだけでOKです。

フロント：トップ、カテゴリ、商品詳細、カート、購入完了
管理：ログイン、受注一覧、在庫、メールテンプレ
運用：Cronが回っているか、バックアップが動くか
ログ：エラーが急増していないか

よくある質問（検索で拾われやすい悩みを集約）

レンタルサーバーとVPS、どちらが向いている？

迷ったら最初に、「運用の手間を許容できるか」で決めるのがいちばん失敗が少ないです。

ざっくり結論

レンタルサーバー向き：まずは早く・安全に立ち上げたい／運用担当がいない（または兼務）
VPS向き：同居影響を避けたい／構成を自由に組みたい／チューニングや監視を自分で回せる

判断の目安（初心者向け）

次のうち 1つでも強く当てはまるなら、まずレンタルサーバーが堅実です。

OSやミドルウェア更新（セキュリティ対応）を自分でやるのが不安
障害時にログを追って原因究明する体制がない
バックアップ復元や切り戻し作業を自分でできる自信がない

逆に、次が増えてきたらVPS/クラウドを検討する段階です。

セール時などピークで レスポンスが急に悪化する（同居影響を疑う）
検索・絞り込み・受注一覧が重く、改善が頭打ち
Redis / Queue / 検索エンジンなど追加コンポーネントが必要になってきた
社内規定や監査で、構成管理・ログ管理・権限分離を厳密に求められる

“VPSにするなら”初心者が踏むべきステップ

いきなりフル自前VPSに行くより、次の順が安全です。

レンタルサーバーの上位プラン（一番低リスク）
マネージドVPS/クラウド（運用負荷を抑えつつ性能を上げる）
フル自前VPS（運用の自走が前提）

EC-CUBEはどのバージョンを選ぶべき？

基本はシンプルで、新規なら“最新のメンテされている系統”を選ぶのが安全です。
理由は、セキュリティ修正や周辺ライブラリ（PHP/Symfony等）の更新が継続されるからです。

新規構築のおすすめ

原則：4.3系（最新）
サーバー側のPHP/DB条件が満たせるなら、まずここを基準に考えるのが堅いです。

4.2系を選ぶ余地があるケース

使いたいプラグインが「4.3対応が遅れている」
サーバー都合で、PHPやDBの要件を4.3に上げられない（当面は4.2の範囲で運用したい）

4.0/4.1系を“あえて”選ぶのはどんな時？

すでに稼働中のサイトが4.0/4.1で、当面は保守を優先して段階移行したい
ただし、古いミドルウェア前提になりやすく、長期的にはアップグレード計画が必須です

バージョン選びで必ず確認する3点

サーバーのPHP/DBが要件を満たすか（あとから変えにくい）
導入予定プラグインが対応しているか
カスタマイズ量（多いほど“バージョンアップの難易度”が上がる）

迷ったら：まず検証環境で、
「同じサーバー条件」＋「必須プラグイン全部」＋「テスト注文（メール送信まで）」
が通るバージョンを採用すると、実運用で詰まりにくいです。

PHPやDBのバージョンが合わないと言われたときの対処は？

このエラーは「何が悪いか」を分解すると解決が早いです。
見るべきは EC-CUBEのバージョンと、サーバーで選べるPHP/DBの2つです。

対処の基本フロー

自分が入れようとしているEC-CUBEのバージョンを確認
そのバージョンの 要件（PHP/DB範囲）を確認
サーバー側で
- PHPのバージョン変更ができるか
- DBの種類（MySQL/PostgreSQL）とバージョンが合うか
  を確認
合わない場合は、次のいずれかを選ぶ
- サーバー設定で解決（PHP切替、DB作り直し）
- プラン変更で解決（上位プランで新しいDBが使える等）
- サーバー移転で解決（要件を満たす環境へ）