レンタルサーバでECサイトを立ち上げようとすると、だいたい最初にぶつかるのが「ミドルウェアのバージョン問題」です。
PHPは（サーバによって）7.4にしたり8.1にしたり、ある程度“選べる”ことが多いんですが、DB（MySQL/MariaDB）のバージョンは「それ固定です」になりがち。で、EC-CUBEみたいに要件がはっきりしているソフトだと、ここが地味に効いてきます。
今回は、Googleの開発エージェント（IDE）Antigravityに手伝ってもらって、EC-CUBE4.1.2-p2をPHP7.3.33＋MariaDB10.5という（正直ちょいクセのある）組み合わせで「とりあえず起動できるところまで」持っていった話を書きます。
レンタルサーバあるある：PHPは選べてもDBは選べない
レンタルサーバだと、コントロールパネルでPHPのバージョンは変更できるのに、DBは「MySQL（またはMariaDB）で、このバージョンです」から動かせないケースが多いです。
で、EC-CUBE側はというと、バージョンごとにシステム要件が決まっています。
EC-CUBE4.1系（4.0/4.1）のシステム要件
EC-CUBE 4 系の要件としては、ざっくり以下のイメージになります（4.1系の想定）。
- PHP：7.3 ～ 7.4
- MySQL：5.7系（InnoDB前提）
ここで重要なのが、要件として明示されるDBが「MySQL 5.7系」になりやすい点です。つまり、MariaDBは“公式の要件としては書かれていない（または濁されがち）”で、環境によっては自己責任ゾーンになりやすい。
MariaDBで考えるなら「MySQL互換の目安」を見る
MySQLとMariaDBは互換性が高いと言われますが、バージョン帯によって「だいたいこのへんが互換の目安」という考え方があります。
たとえば、MySQL 5.7相当を狙うならMariaDB 10.2～10.4あたり、MySQL 8.0寄りの機能帯になるとMariaDB 10.4～10.6以降…というイメージで語られることが多いです。
今回のMariaDB 10.5は、体感としてはMySQL 8.0寄りのレンジに入りやすいので、EC-CUBE4.1（想定：MySQL5.7系）から見ると「要件外になりやすい組み合わせ」という前提を持っておくのが安全です。
Dockerなら「本番と同じっぽい環境」を先に作って検証できる
ここでDockerの出番です。
Dockerだと、PHPもDBもバージョンを固定して組めるので、
- 本番が「PHP7.3系」「DBはMariaDB10.5固定」みたいな制約でも
- ローカルで“ほぼ同じ”構成を再現して
- EC-CUBEが動くのか（要件外でも耐えるのか）を先に確認できる
というのが強いです。レンタルサーバ本番でいきなり賭けに出なくて済む。
今回のテーマはまさにこれで、「要件にピッタリじゃない構成だけど、現実的にその構成でしか運用できない」みたいな状況で、先に検証しておく価値がデカいです。
まずはAntigravityで「EC-CUBEが起動する」ところまで持っていく
今回やったことはシンプルで、ゴールはまずこれ。
- Dockerで PHP7.3.33 を用意
- Dockerで MariaDB10.5 を用意
- EC-CUBE 4.1.2-p2 を載せる
- EC-CUBEのフロント画面と管理画面が表示できるところまで持っていく
で、ここをAntigravityに手伝ってもらいました。
体感としては、Antigravityは「環境構築の作業員」になってくれるのが便利で、
- docker-composeの叩き台づくり
- コンテナ起動 → ログ確認 → 修正のループ
- EC-CUBE側の権限・キャッシュ・依存関係まわりの“いつもの沼”の切り分け
このへんをテンポよく回せました。「次に何を試すべきか」を提案してくれるので、手探り時間が削れる感じです。
注意：要件外の組み合わせは「動いても保証されない」
ここ大事なので明記しておきます。
要件上は「PHP7.3～7.4」「MySQL5.7系」みたいな想定がある中で、MariaDB 10.5はそこから外れやすい組み合わせです。
なので、今回みたいな構成は“動いたらラッキー”じゃなくて、“動くか検証してから決める”が正解です。まさにDocker検証の価値が出るところ。
Antigravityが便利だったポイント（個人的まとめ）
- ログ→原因候補→次に試すことの流れが速い（沼りにくい）
- 「まず起動まで」みたいな段階ゴールに強い（最短ルートを作りやすい）
- 環境差分の吸収（PHP拡張、権限、キャッシュ、DB接続など）で、手戻りが減る
もちろん、最終的な責任は人間側にあるんですが、環境構築みたいな「作業量が多い・ミスりやすい」領域ほど、エージェントの恩恵は大きい印象でした。
ショップのフロント画面などもAntigravityを利用すれば、カスタマイズが用意になる
起動できたら次はカスタマイズなんですが、ここでもAntigravityが地味に効きます。
- テンプレート（Twig）やCSS/SCSSの変更点整理
- 「この画面のこの部分、どこが生成してる？」の当たり付け
- 差分パッチっぽく提案してくれるので戻しやすい
EC-CUBEは触る場所が分かれば早い反面、最初の探索で時間が溶けがちです。なので「調べる担当」がいるのは普通に助かります。
まとめ：要件外は“祈る”より“再現して検証”が強い
レンタルサーバだと、どうしても「DBのバージョンが選べない」問題が起きます。EC-CUBE4.1系の想定要件に対して、現実の本番環境がMariaDB寄りになるケースも普通にあります。
そういうときは、
- Dockerで本番相当を再現して
- 動くかどうかを先に確認して
- いけるなら進む／厳しければ構成を見直す
これがいちばん堅いです。
そして、その検証ループを回す相棒としてAntigravityが思った以上に便利でした。環境構築〜初期起動までを人間が全部やると疲れるので、こういうところはAIに作業させて、判断と設計に集中したほうが勝ち、という結論です。
次は、今回の構成で「どこまで実運用に耐えるか（プラグイン含む）」の検証観点を整理して、チェックリスト化してみようと思います。
