EC-CUBE4系のアーキテクチャを解説｜Symfonyベースで拡張・保守しやすい構造とは【2026年版】

この記事でわかること
EC-CUBE4系は、世界的に使われているPHPフレームワーク「Symfony」を基盤に構築されています。この記事では、EC-CUBE4系がSymfonyの仕組み（MVC構造、Doctrine ORM、DIコンテナ、イベント拡張など）をどう利用しているか、そして3系から4系で拡張・カスタマイズの方式や保守の考え方がどう変わったのかを、開発者・技術担当者向けに解説します。あわせて、2026年時点の技術スタックも整理します。

EC-CUBE4系の基盤：PHPフレームワーク「Symfony」

EC-CUBE4系の大きな特徴は、PHPフレームワークのSymfonyを基盤にしていることです。EC-CUBE4系ではSymfonyを基盤としながら、3系からプラグインやサービス定義などの拡張方式も見直されています。

採用しているSymfonyのバージョンは、EC-CUBEのバージョンアップに伴って更新されてきました。初期の4系から現在まで、ベースとするSymfonyの世代は更新されており、2026年時点の現行開発ライン（4.4系）では、Symfony 7.4が採用されています。技術記事などでEC-CUBE4のSymfonyバージョンに触れる際は、対象のEC-CUBEバージョンを確認することをおすすめします。

MVC構造による役割の分離

EC-CUBE4系では、Symfonyの仕組みに沿って、Controller・Entity・Twigテンプレートなどの役割が整理されています。MVC（Model・View・Controller）の考え方に沿って役割が分かれているため、どこに何を書くかが整理しやすくなっています。

Model（モデル）

データやビジネスロジックを扱う層です。EC-CUBE4系では、エンティティ（データの構造を表すクラス）を通じてデータを管理し、後述のDoctrine ORMがデータベースとのやり取りを担います。

View（ビュー）

画面表示を担う層です。テンプレートエンジンにTwigを採用しており、表示のロジックとデザインを分離しやすい構造です。デザインの変更やUIの調整が、プログラムのロジックと切り離して行いやすくなっています。

Controller（コントローラ）

リクエストを受け取り、モデルとビューをつなぐ層です。ルーティング（URLと処理の対応付け）やHTTP処理を扱います。役割が明確なため、処理の流れを追いやすくなっています。

Doctrine ORMによるデータアクセス

EC-CUBE4系は、データベースとのやり取りにDoctrine ORMを採用しています。ORM（Object-Relational Mapping）は、データベースのテーブルをオブジェクトとして扱えるようにする仕組みです。

これにより、SQLを直接書く場面を減らし、オブジェクト指向的にデータを扱いやすくなります。エンティティとしてデータ構造を定義するため、BtoB-ECのように複雑なデータ構造や取引ルールを扱う場合でも、構造を整理しながら設計しやすくなります。

プラグイン・拡張の仕組み

EC-CUBE4系では、コアのコードを直接書き換えずに機能を拡張する仕組みが整理されています。イベント（処理の特定のタイミングで独自の処理を差し込む仕組み）や、後述のDIコンテナを活用することで、コア改修を抑えた拡張がしやすくなっています。

コアを書き換えずに拡張できると、EC-CUBE本体のバージョンアップ時に、独自の改修とぶつかる可能性を減らしやすくなります。長期的に運用・保守していくうえで、重要な考え方です。

サービスコンテナと依存性注入（DI）

Symfonyベースであるため、EC-CUBE4系ではDIコンテナ（依存性注入の仕組み）を利用できます。DIは、あるクラスが必要とする別の機能を、外から渡す設計手法です。

DIを活用すると、クラス同士の結びつきを緩やかにできます（疎結合）。これにより、個別の機能をテストしやすくなったり、コードを再利用しやすくなったりします。長期運用を前提とする場合に、保守しやすさにつながる構造です。

外部システム連携の実装

基幹システム、在庫管理システム、外部のCRMなどとの連携は、BtoB-ECの構築では特に重要になる部分です。EC-CUBE4系では、SymfonyのサービスやDIなどを利用しながら、こうした外部システムとの連携処理を実装できます。

連携の設計や費用感については、EC-CUBE構築費用の内訳もあわせてご覧ください。

セキュリティの仕組み

EC-CUBE4系は、Symfonyのセキュリティ関連のコンポーネントを活用しています。CSRF対策、認証、権限制御といった仕組みが、フレームワークの機能として利用できます。標準的なフレームワークの仕組みに沿っているため、セキュリティ対策を一から自前で作り込むのに比べて、整理された形で実装しやすくなっています。

EC-CUBE3系との違い

EC-CUBE3系と4系は、いずれもSymfonyの仕組みを利用していますが、4系では拡張の方式やサービス定義などが見直されています。主な違いは次のとおりです。

• プラグインの拡張の仕組みが見直された（3系のServiceProviderから、SymfonyのDI機構を利用する方向へ）
• 従来のフックポイントなど、一部の拡張方式が非推奨化された
• サービス定義やDIコンテナの活用など、拡張・カスタマイズの作法が整理された

これは、同じSymfony系でありながら、拡張やカスタマイズの方式が変わったものと言えます。そのため、3系のプラグインやカスタマイズを、そのまま4系で使えるとは限りません。

「拡張・保守しやすい」と言われる背景

EC-CUBE4系が拡張・保守の面で評価される背景には、次のような要素があります。

• 標準的なフレームワーク（Symfony）を基盤にしている
• DIによる疎結合な設計ができる
• コアを書き換えずに拡張する仕組みがある
• 外部システムとの連携を実装しやすい

ただし、Symfonyベースであれば、自動的に拡張・保守がしやすくなるわけではありません。あくまで「そうした設計をしやすい土台がある」ということです。この土台を活かせるかどうかは、実際の設計の仕方によります。

注意：構造の良さは、設計次第で活かされる

EC-CUBE4系は拡張しやすい構造を持っていますが、自由度が高いぶん、設計次第では、その良さが活かされないこともあります。たとえば、安易にコアを書き換えたり、設計方針がないままプラグインを増やしたりすると、保守の負担が大きくなることがあります。

アーキテクチャの良さを活かすには、その構造を理解したうえで設計することが大切です。EC-CUBEでの構築を検討する際は、この点を踏まえて、制作・開発の進め方を考えるとよいでしょう。

まとめ

EC-CUBE4系では、Symfonyを基盤に、Doctrine ORM、DIコンテナ、Twig、イベントなどの仕組みを利用しながら、プラグインやカスタマイズを実装できます。3系からは、ServiceProviderの廃止やSymfonyのDI機構の利用など、拡張方式も見直されています。コアを書き換えずに拡張しやすい構造を活かすことが、長期的な運用・保守につながります。

ただし、この構造の良さは、それを活かした設計をして初めて発揮されます。EC-CUBE4系での構築・カスタマイズを検討する際は、アーキテクチャを理解したうえで設計できるかどうかが重要です。私たちサンクユーは、EC-CUBE4系のカスタマイズや基幹連携に対応しています。技術的な相談を含めて、お気軽にお問い合わせください。