「動いているから大丈夫」ではない。未アップデートのECサイトが抱える脆弱性と保守の考え方
EC- 未アップデートによる影響範囲とは
- 未アップデートのECサイトとは、本体・プラグイン・テーマ・サーバー環境などが古いまま運用されているECサイト
- 脆弱性が修正されないまま残り、不正アクセスや情報漏えいのリスクが高まる
- 独自カスタマイズやコアファイルの直接編集により、アップデート自体が難しくなっているケースがある
- 安全に運用するには、現状調査・バックアップ・検証環境・段階的な更新・継続保守が必要になる
数年前に構築したECサイトが今も問題なく動いているように見えても、古いシステムには脆弱性が残っている可能性があります。特にオープンソースのECやCMSでは、本体・プラグイン・テーマ・サーバー環境を継続的に更新しなければ、不正アクセスや情報漏えいのリスクが高まります。安全に運用するには、現在の構成を把握し、アップデートできる状態へ整えることが重要です。
古いECサイトは「動いている」だけでは安全とは言えない
数年前に構築したECサイトが、今も問題なく注文を受け付けている。
- 管理画面にもログインできる
- 商品登録もできる
- だから、特に問題はない
そう考えてしまうことは少なくありません。しかし、Webシステムにおいて「動いていること」と「安全であること」は別です。
特にECサイトは、会員情報、注文情報、配送先、問い合わせ情報などを扱います。クレジットカード情報そのものを保持していない場合でも、個人情報や購入履歴を扱う以上、不正アクセスの影響は大きくなります。
オープンソースのECシステムやWordPressでは、本体やプラグインの脆弱性が継続的に報告されています。例えばEC-CUBE公式の脆弱性リストでは、複数のバージョンを対象とした脆弱性情報が公開されており、2026年にもMFAバイパスに関する脆弱性が案内されています。
つまり、古いまま動いているECサイトは、見た目には問題がなくても、攻撃者から見ると「更新されていない狙いやすい入口」になっている可能性があります。
システムの老朽化は、脆弱性につながる
ECサイトの老朽化は、デザインが古くなることだけではありません。本当に問題になるのは、システム面の老朽化です。
オープンソースのECやCMSでは、脆弱性が見つかるたびに修正版が提供されます。これは、裏を返せば、古いバージョンには既知の弱点が残っている可能性があるということです。
攻撃者は、すべてのサイトを一つずつ人力で確認しているわけではありません。古いバージョンのシステム、脆弱性のあるプラグイン、更新されていない管理画面などを機械的に探し、条件に合うサイトを狙うことがあります。
WordPressでも、プラグインの脆弱性が悪用されるケースは実際に確認されています。JPCERT/CCは、WordPress用プラグイン「File Manager」の脆弱性について、悪用を試みる国内宛の通信やインシデント報告を確認し、修正バージョンへのアップデートなどの対応を推奨しています。
ECサイトも同じです。
- 本体は古い
- プラグインも古い
- サーバーのPHPも古い
- 保守業者はもういない
- 誰がどこを改修したのか分からない
このような状態は、単なる「古いサイト」ではなく、セキュリティ上のリスクを抱えた状態と考えるべきです。
アップデートできないECサイトが生まれる理由
本来であれば、システムは定期的にアップデートすべきです。しかし、現場では「アップデートしたくてもできない」ECサイトが少なくありません。
理由のひとつが、過去のカスタマイズです。オープンソースECは柔軟にカスタマイズできる反面、実装方法を誤ると、将来のアップデートを難しくします。
特に問題になりやすいのが、コアファイルの直接書き換えです。本体側のファイルを直接修正していると、バージョンアップ時にその修正が上書きされたり、逆に新しい本体との差分が衝突したりします。
その結果、アップデートした瞬間に画面が真っ白になる、管理画面にログインできなくなる、購入フローが動かなくなる、といったトラブルが起こります。
もうひとつの原因が、プラグインの依存です。便利なプラグインを複数導入している場合、それぞれが本体バージョンや他のプラグインに依存していることがあります。
- 本体をアップデートすると、プラグインが動かない
- プラグインを更新すると、別のプラグインと競合する
- 古いプラグインが新しい環境に対応していない
こうなると、更新作業は単純なボタン操作では済みません。結果として、「怖いから触らない」という状態になります。しかし、触らないまま時間が経つほど、アップデートの難易度はさらに上がります。
コアファイル編集は「禁止」ではなく「管理」が重要
オープンソースECでは、標準機能やプラグインだけでは要件を満たせないことがあります。
業務フローが特殊な場合、既存の拡張ポイントだけでは対応しきれない場合、あるいは過去の仕様との整合性を保つ必要がある場合など、コアファイルに近い領域まで手を入れなければならないケースもあります。
そのため、コアファイルの編集そのものを一律に否定する必要はありません。問題になるのは、変更内容が管理されていない状態です。
- どのファイルを変更したのか
- なぜ変更したのか
- 標準との差分はどこにあるのか
- アップデート時に影響する範囲はどこか
- 元に戻す手段はあるのか
こうした情報が残っていないまま運用されていると、将来の保守が難しくなります。
特に、仕様書や改修履歴がない状態でコアファイルが直接編集されていると、次の開発者が見たときに標準仕様なのか独自修正なのか判断できません。
その結果、アップデート時に必要な修正が消えてしまったり、新しいバージョンとの差分が衝突したりする可能性があります。
大切なのは、コアファイルを絶対に触らないことではなく、触った場合に保守できる状態を作っておくことです。
- 変更箇所を記録する
- 差分を管理する
- 検証環境で動作確認する
- アップデート時の影響範囲を把握する
- 必要に応じて、将来的に拡張しやすい実装へ整理する
こうした管理ができていれば、コアファイルに手を入れたECサイトでも継続運用は可能です。
逆に、コアファイルを編集していなくても、プラグインや独自処理が複雑に絡み合い、誰も全体を把握していなければ、保守しやすいとは言えません。
保守性を左右するのは、「コアファイルを触ったかどうか」だけではありません。変更内容を把握し、将来のアップデートに備えられる状態になっているかどうかです。
プラグインの競合は、見えないところでリスクになる
プラグインは便利です。ECサイトに機能を追加するうえで、プラグインは大きな助けになります。しかし、プラグインを増やしすぎると、サイト全体の構造が複雑になります。
- 決済プラグイン
- 配送プラグイン
- ポイントプラグイン
- 会員制御プラグイン
- 商品項目追加プラグイン
- 販促系プラグイン
- 外部連携プラグイン
それぞれが個別に動いているように見えても、実際には同じデータや同じ処理に関わっていることがあります。
- 本体のアップデートによって、あるプラグインが対応しなくなる
- プラグイン同士の処理順序が変わる
- 片方のプラグインが想定しているデータ構造を、別のプラグインが変更してしまう
こうした競合は、管理画面上では分かりにくいものです。
特にECでは、購入完了、決済、在庫、メール送信、会員情報など、複数の処理がつながっています。一箇所の不具合が、注文全体に影響することもあります。
そのため、アップデート前には、単に本体バージョンを見るだけでなく、導入プラグイン、カスタマイズ内容、決済・配送・外部連携まで含めて確認する必要があります。
未アップデートのまま放置した場合に起こり得ること
未アップデートのECサイトを放置すると、どのような問題が起こるのでしょうか。
まず考えられるのが、不正アクセスです。管理画面に侵入されると、顧客情報や注文情報を閲覧される可能性があります。商品情報や価格を改ざんされる可能性もあります。不正なファイルを設置され、別の攻撃に利用されることもあります。
次に、サイト改ざんです。トップページや商品ページが書き換えられる、不審なリンクが埋め込まれる、検索結果に怪しい文言が表示される、こうした被害は、ブランドの信用にも影響します。
さらに、決済や個人情報を扱うECでは、カード会社や決済代行会社との関係にも影響する可能性があります。情報漏えいの懸念があると、調査対応や決済停止など、事業運営に大きな負担が発生することがあります。
EC-CUBEの脆弱性に関しても、JVNでは任意コード実行可能な脆弱性について、最新版へのアップデートまたは修正パッチの適用が対策として案内されています。
「今まで問題がなかったから大丈夫」ではありません。問題が起きてからでは、調査、復旧、報告、再発防止まで大きなコストがかかります。
まず確認すべきこと
古いECサイトを運用している場合、いきなりアップデートするのは危険です。まずは現状を確認する必要があります。
確認すべき項目は、次のようなものです。
- 使用しているECシステムの種類とバージョン
- PHPやデータベースのバージョン
- 導入しているプラグインの一覧
- 現在も使っているプラグインと、不要なプラグイン
- 過去のカスタマイズ内容
- コアファイルを直接書き換えていないか
- 決済・配送・在庫・基幹システムとの連携
- バックアップの有無
- テスト環境の有無
- 保守契約や障害時の連絡先
この段階では、すぐに更新することよりも、どの程度リスクがあるかを把握することが重要です。現状が分からないままアップデートすると、どこが壊れたのか分からなくなります。
まずは、構成を見える化すること。これが最初の作業です。
安全にアップデートするための考え方
安全にアップデートするには、本番環境でいきなり作業しないことが重要です。
まずはバックアップを取得します。ファイルだけでなく、データベースも含めて復旧できる状態にしておく必要があります。
次に、検証環境を用意します。本番環境に近い状態でアップデートを試し、画面表示、管理画面、購入フロー、決済、メール送信、外部連携などを確認します。
特にECサイトでは、トップページが表示されるだけでは不十分です。
- 商品をカートに入れられるか
- 会員登録できるか
- 注文できるか
- 決済できるか
- 注文メールが届くか
- 管理画面で注文を確認できるか
- 在庫が正しく変わるか
- 外部システムにデータが連携されるか
ここまで確認して初めて、アップデートの影響を判断できます。
また、一度にすべてを更新するのではなく、段階的に進めることも重要です。本体、プラグイン、PHP、サーバー環境をまとめて変えると、問題が起きた時に原因を切り分けにくくなります。更新は、計画的に行うべき作業です。
アップデートできない場合は、リニューアルも選択肢になる
サイトによっては、アップデートよりもリニューアルした方が良い場合があります。
特に、次のような状態では注意が必要です。
- 開発会社がすでに対応できない
- 仕様書が残っていない
- コアファイルが大きく書き換えられている
- 古いプラグインに依存している
- サーバー環境も古い
- テスト環境がない
- 決済や配送連携がブラックボックス化している
- アップデートすると不具合が出ることが分かっている
この場合、無理に既存システムを延命するより、将来の保守を考えて作り直す方が安全なこともあります。
リニューアルといっても、単にデザインを変えることではありません。
- 保守しやすい構造にする
- カスタマイズの影響範囲を整理する
- プラグイン依存を減らす
- アップデートしやすい設計にする
- サーバー環境を見直す。
- 不要な機能を削る
- 運用フローに合わせて管理画面を整える
こうした改善を含めて、次の数年を安全に運用できるECサイトへ整えることが重要です。
綺麗なコードとは、将来の保守に耐えられる構造のこと
「綺麗なコード」という言葉は、見た目の問題ではありません。
ECサイトにおける綺麗なコードとは、将来の保守に耐えられる構造のことです。
- どこを変更したか分かる
- 本体とカスタマイズの境界が明確
- 不要な処理が少ない
- プラグイン依存が整理されている
- アップデート時の影響範囲を把握しやすい
- 別の開発者でも理解できる
- 障害時に原因を追いやすい
こうした状態であれば、将来の改修やアップデートに対応しやすくなります。逆に、動いているけれど誰も中身を理解できない状態は、保守性が低い状態です。
ECサイトは、公開して終わりではありません。商品、会員、決済、配送、法改正、セキュリティ、外部サービス連携など、運用中に変化し続けます。その変化に対応できる構造にしておくことが、長く安全に運用するための条件です。
継続保守は、トラブル対応ではなく予防である
保守というと、何か問題が起きた時に直すことだと思われがちです。しかし、本来の保守は予防です。
- 脆弱性情報を確認する
- 本体やプラグインの更新状況を見る
- サーバー環境の期限を確認する
- バックアップが取得できているか確認する
- 不要なアカウントやプラグインを整理する
- エラーログや不審なアクセスを確認する
- アップデートの影響を検証する
こうした作業を継続することで、大きな事故を防ぎやすくなります。特にECサイトでは、止まること自体が売上機会の損失になります。さらに、不正アクセスや情報漏えいが起きれば、信用面のダメージも避けられません。
だからこそ、保守は「壊れたら直す」ではなく、「壊れにくくする」「侵入されにくくする」「復旧できる状態にしておく」という考え方が必要です。
ECサイトは、売上を支える重要なシステムです。そのシステムが、誰も更新できない状態、誰も中身を把握していない状態になっているなら、早めに見直す必要があります。
- まずは現状を確認すること
- 次に、アップデートできる状態へ整えること
- 必要であれば、保守しやすい構造にリニューアルすること
「動いているから大丈夫」ではなく、「安全に動かし続けられるか」を基準に考えることが大切です。

- 執筆者:西部俊宏
- 株式会社Webの間代表取締役。上場企業でのSEOやWebサイト構築実績多数。ECサイトのカスタマイズ経験も多数あり。
- 会社概要はこちら
私たちは、ECを業務に合わせて設計・構築します。
カスタマイズ前提だからこそ、これまで実現できなかった要件にも対応できます。