ホームページは何で作れば安全？情報漏洩事例から考えるWebサイトのセキュリティ
執筆：監修 水谷敏暉
ヒアリングから設計、デザイン、実装まで一気通貫で行うWix専門のWeb製作者。年間20社以上の企業のサイト制作を業務委託で作成しつつ、個人事業としてもWeb制作を行なっている。
「会社のホームページを作りたいけれど、WordPress、Wix、Studio、AIサイト制作など、結局どれを選べばいいのかわからない。」
「すでにホームページを持っているけれど、最近の情報漏洩や不正アクセスのニュースを見て、このまま使い続けて大丈夫なのか不安になってきた。」
Webサイトを作る選択肢が増えた今、このように感じている経営者や事業者は少なくないでしょう。
特に最近は、生成AIの発達によって「数分でWebサイトを作れる」「制作会社に頼まなくてもホームページを作れる」というサービスも急速に増えています。
確かに、Webサイトを作ることそのものは以前より簡単になりました。
しかし、ここで一つ考えてほしいことがあります。
そのWebサイトを、公開したあと誰が守るのでしょうか。
Webサイトには、デザインや文章とは別に、サーバー、CMS、データベース、SSL、認証、脆弱性対策、バックアップ、不正アクセスの監視など、多くの仕組みが動いています。
そしてセキュリティの世界には、残念ながら「絶対安全」というものはありません。
実際、2026年には、十分なセキュリティ対策を実施していたサービスでも不正アクセスが発生しています。
だからこそホームページを選ぶときには、
「簡単に作れるか」ではなく、「誰が、どこまでセキュリティを管理してくれるのか」
まで考える必要があります。
この記事では、2026年に公表されたEストアー「ショップサーブ」やStudioの事例をもとに、Wix、Studio、WordPress、Shopify、BASE、AI生成サイトなどの違いを、Webセキュリティの視点から整理します。
先に結論｜「一番安全なCMS」を探すだけでは不十分
先に結論をお伝えすると、
「このCMSなら絶対安全」というサービスは存在しません。
WordPressにも脆弱性は見つかります。
Wixにも過去に脆弱性は報告されています。
Studioでは10/16日に情報漏洩、やECサービスでも、脆弱性が発生しています。
重要なのは脆弱性が一度も発生しないことだけではありません。
見るべきなのは、
脆弱性が発生したとき、誰が発見し、誰が修正し、誰が攻撃を監視し、誰が復旧まで担当するのか。
つまり、Webサイトを守るための「責任分界」です。
特に社内にWebエンジニアやセキュリティ担当者がいない中小企業では、この違いが非常に重要になります。
Webサイトは「作る」より「守り続ける」ほうが難しい
ホームページ制作というと、多くの人は次のような部分をイメージします。
デザイン、文章、写真、SEO、問い合わせフォーム、スマートフォン対応などです。
もちろん、これらは重要です。
しかしWebサイトを公開すると、その裏側では別の仕事が始まります。
たとえば、
サーバーを正常に稼働させる
OSやミドルウェアを更新する
CMSをアップデートする
プラグインやライブラリを更新する
SSL/TLSを管理する
不正アクセスを監視する
脆弱性を調査する
DDoS攻撃などに対応する
データをバックアップする
インシデント発生時に原因を調査する
攻撃経路を遮断する
必要に応じて利用者へ通知する
といった作業が必要になります。
ここが、
「ホームページを作る技術」と「ホームページを安全に運用する技術」は別物
と言われる理由です。
AIがHTMLやWebサイトを生成してくれるようになっても、この部分まで自動的に消えるわけではありません。
2026年に起きた情報漏洩から、Webサイトのセキュリティを考える
まず、実際に2026年に公表された事例を見てみましょう。
重要なのは「どの会社が危険だったか」を探すことではありません。
十分な対策をしている企業であってもインシデントは起こり得る
という現実を理解することです。
Eストアー「ショップサーブ」で約2,335万人が漏えい対象に
2026年10月16日、EストアーはECサイト構築・運営支援サービス「ショップサーブ」への不正アクセスについて最終報を公表しました。
調査の結果、2026年5月21日から8月1日までの間、第三者がサーバー上で稼働するWebアプリケーションの脆弱性を悪用して不正なプログラムを実行し、データベース内の情報を外部へ送信していたことが確認されています。
Eストアーが事案を認知したのは8月1日で、その日に攻撃元からの通信を遮断しています。
最終的に公表された漏えい対象者数は、
約23,356,000人
でした。
さらに対象店舗は7,858店。
このうち約2,096,900人については、カード名義、カード番号の一部、有効期限など、クレジットカード情報の一部が含まれていました。
非常に大きなインシデントです。
一方で、ここには重要なポイントがあります。
完全なクレジットカード番号やCVVは保持されていなかった
Eストアーによると、完全なカード番号およびセキュリティコード（CVV/CVC）は保持しておらず、今回の漏えい対象にも含まれていません。
そのため、同社は「今回漏えいした情報のみではクレジットカード決済を行うことはできない」と説明しています。
ショップサーブはPCI DSS準拠を公表しているサービスです。現在公開されているサービス資料でもPCI DSS準拠が示されています。
※PCI DSSについて
PCI DSS：クレジットカード情報を安全に扱うための国際基準
ここで、
「PCI DSSに準拠していたのに漏えいした。だからPCI DSSには意味がない」
と考えるのは適切ではありません。
PCI DSSは、そもそもクレジットカード会員データを安全に取り扱うための国際的なセキュリティ基準です。
今回の事例から分かるのは、
PCI DSSへの準拠と、Webアプリケーション全体に脆弱性が存在しないことは別の問題
だということです。
カード情報の管理方法によって完全なカード番号やCVV/CVCが漏えい対象にならなかった一方で、Webアプリケーションの脆弱性そのものは悪用されました。
つまりセキュリティは、一つの認証だけでは判断できません。
Studioでも2026年10月に不正アクセスが発覚
そしてこの記事を執筆している直前の2026年10月16日、ノーコードWeb制作プラットフォーム「Studio」も不正アクセスについて第一報を公表しました。
Studioの発表によると、第三者がStudioの一部機能の脆弱性を悪用し、同社が利用しているクラウド環境へ不正アクセスしたことが確認されています。
現時点で確認されている経緯は、
2026年9月30日〜10月1日に第三者による不正アクセスが発生。
10月13日にStudio側の社内調査で不正アクセスを確認。
10月13日〜14日に脆弱性修正と不正アクセス経路の遮断を実施。
10月16日に第一報を公表。
となっています。
ここは情報を正確に理解する必要があります。
2026年10月17日時点では、
「第三者が実際にデータを取得した事実」は確認されていません。
ただし、外部からデータを取得できる状態になっていたため、Studioは「取得されたものとみなして」対応を進めています。
流出した可能性がある情報として、Studioアカウントのユーザー名、メールアドレス、ハッシュ化されたパスワード、CMS・フォームデータ、一部のAPIキーやトークンなどが挙げられています。
特に一部の暗号化情報については、同じ不正アクセスによって復号用の鍵にもアクセスされた可能性があるため、内容を読み取られた可能性があると説明されています。
ただし、対象件数や二次被害、詳細な原因、再発防止策については現在も調査中です。
したがって現段階で、
「Studioで大規模な情報漏洩が確定した」
などと断定するのは適切ではありません。
Studioはセキュリティ対策をしていなかったのか？
そうではありません。
Studioは以前から複数のセキュリティ対策を公表しています。
たとえばISO/IEC 27001とISO/IEC 27017の認証を取得しています。
※ISO/IEC 27001とISO/IEC 27017とは
ISO/IEC 27001：会社全体の情報セキュリティ管理に関する国際認証 ISO/IEC 27017：クラウドサービスの安全管理に関する国際基準
さらに、
Google Cloud Armorを利用したWAF
DoS/DDoS対策
SSL/TLS
データ暗号化
OWASP ZAPを利用した脆弱性診断
ポートスキャン
ペネトレーションテスト
権限管理
監査ログ
Bug Bounty Program
なども公表しています。
つまり今回の事例から得るべき教訓は、
「Studioはセキュリティ対策をしていなかった」ではありません。
むしろ逆です。
セキュリティ対策を複数実施し、第三者認証を取得している企業であっても、脆弱性を完全にゼロにすることはできない
ということです。
そして、インシデント発覚後には脆弱性修正、不正アクセス経路の遮断、認証情報の交換、外部専門家との調査、個人情報保護委員会への報告などが進められています。
こうした発生後の対応力も、セキュリティを評価するときの重要なポイントです。
セキュリティ認証があれば「安全」とは限らない
「ISO27001を取得している会社だから安全」
「PCI DSSに準拠しているから安全」
という説明を目にすることがあります。
しかし、ここには少し注意が必要です。
たとえばISO/IEC 27001は、情報セキュリティマネジメントシステムに関する国際規格です。
組織として情報セキュリティのリスクを評価し、管理し、継続的に改善するための仕組みが整えられているかを評価します。
これは非常に重要です。
しかし、
「その会社が開発するソフトウェアに脆弱性が一切存在しない」ことを証明する認証ではありません。
同じようにPCI DSSも重要な基準ですが、主な目的はクレジットカード会員データの保護です。
Webサービス全体に脆弱性が存在しないことを保証するものではありません。
つまり認証を見ることは大切ですが、
認証だけを見るのでは不十分
なのです。 実際、Eストア、STUDIOはお問い合わせフォームのようなアプリケーションの脆弱性から侵入されています。
セキュリティを見るなら「予防・検知・対応・復旧」の4つを見る
Webサービスの安全性を判断するときは、大きく4段階で考えると分かりやすくなります。
観点 | 意味 | 確認したいこと |
予防 | 侵入されにくくする | WAF、脆弱性診断、セキュア開発、暗号化など |
検知 | 攻撃に早く気付く | ログ監視、異常検知、SOC、SIEMなど |
対応 | 発見後に被害を止める | 攻撃経路遮断、認証情報失効、Incident Responseなど |
復旧 | 正常な状態へ戻す | バックアップ、災害復旧、BCP、再発防止など |
特に見落とされやすいのが検知です。
どれだけ防御していても、突破される可能性をゼロにはできません。
だからこそ、
「侵入を100％防ぐ」
だけではなく、
「侵入された場合、どれだけ早く気付けるか」
まで考える必要があります。
Webサイトの安全性を考えるなら「責任分界」を見る
ここからが、ホームページを選ぶときに特に重要な部分です。
Web業界では「責任分界」という言葉があります。
難しく聞こえますが、簡単に言えば、
「Webサイトを安全に運営するための仕事を、誰が担当するのか」
という意味です。
これを理解すると、WordPressとWixなどのSaaSの大きな違いが見えてきます。
Wix・Studio・Shopify・BASE・WordPressのセキュリティ管理責任を比較
大まかに整理すると、次のようになります。
※ここでいうWordPressは、自社や制作会社がレンタルサーバー等へインストールする一般的な「セルフホスト型WordPress」を想定しています。
管理項目 | Wix | Studio | Shopify | BASE | WordPress自前運用 | AI生成＋自前ホスティング |
ホスティング | Wix側 | Studio側 | Shopify側 | BASE側 | 利用者側 | 構成による |
サーバー基盤管理 | Wix側 | Studio側 | Shopify側 | BASE側 | 利用者・ホスティング側 | 構成による |
OS・インフラ更新 | Wix側 | Studio側 | Shopify側 | BASE側 | 利用者・ホスティング側 | 構成による |
CMS本体更新 | Wix側 | Studio側 | Shopify側 | BASE側 | 利用者側 | 構成による |
SSL/TLS | 基本自動 | 基本自動 | 自動 | サービス側 | ホスト・設定による | 構成による |
プラットフォーム脆弱性対応 | Wix側 | Studio側 | Shopify側 | BASE側 | WordPress側＋利用者側 | 開発者・サービスによる |
プラグイン等の更新 | 原則不要※ | 原則不要※ | アプリ等は別途注意 | Apps等は別途注意 | 利用者側 | ライブラリごとに必要 |
サーバー監視 | Wix側 | Studio側 | Shopify側 | BASE側 | 契約環境による | 構成による |
利用者のサーバー保守 | 原則不要 | 原則不要 | 原則不要 | 原則不要 | 必要になる場合あり | 必要になる場合あり |
アカウント管理 | 利用者にも責任 | 利用者にも責任 | 利用者にも責任 | 利用者にも責任 | 利用者 | 利用者 |
外部連携・APIキー管理 | 利用者にも責任 | 利用者にも責任 | 利用者にも責任 | 利用者にも責任 | 利用者 | 利用者 |
※外部アプリ、カスタムコード、API連携等を利用する場合は別途管理が必要です。
この表を見ると分かるように、
SaaSだから利用者にセキュリティ責任が一切ないわけではありません。
パスワード管理、二要素認証、権限設定、外部サービスとの連携、個人情報の取り扱いなどは利用者側にも責任があります。
しかし、
インフラやCMS基盤、サーバー、プラットフォーム自体のセキュリティを誰が管理するか
には大きな違いがあります。
WordPressは危険なのか？
ここも誤解されやすいところです。
WordPressだから危険、というわけではありません。
WordPressには専門のSecurity Teamがあり、WordPress本体の脆弱性調査や修正、セキュリティアップデートなどが継続的に行われています。
また、2026年6月からWordPress.orgではプラグインリリースに対する自動セキュリティレビューも強化されています。
正しく管理されたWordPressは十分に安全性を高めることができます。
問題は、
誰がその管理を続けるのか
です。
WordPress公式ドキュメントでも、WordPress本体、プラグイン、テーマを最新状態に保つことがセキュリティ上重要だとされています。
さらにセルフホスト型では、利用する構成によってPHP、Webサーバー、データベース、WAF、バックアップ、アクセス制御なども考える必要があります。
制作会社が保守してくれるのであれば問題ありません。
社内にエンジニアがいる企業でも問題ありません。
マネージドWordPressホスティングを利用して管理範囲を減らす方法もあります。
つまり、
WordPressが悪いのではなく、「WordPressを安全に維持する責任を誰が持つのか」が重要
なのです。 個人でやるにしても企業でやるにしても、CMSやプラグイン、サーバーのアップデートを毎日管理するのは大変です。
AIでWebサイトを作れる時代だからこそ確認したいこと
現在は、AIへ指示するだけでWebサイトを生成できるサービスも増えています。
これは非常に便利です。
私自身も、AIによってWeb制作のハードルが大きく下がったことはポジティブな変化だと考えています。
ただし、
Webサイトを生成できることと、そのWebサイトを安全に運用できることは別です。
AIがHTMLやReactなどのコードを生成してくれたとしても、
そのサイトをどこでホスティングするのか。
利用しているライブラリに脆弱性が見つかったら誰が更新するのか。
サーバーは誰が管理するのか。
WAFはあるのか。
ログは監視されているのか。
バックアップは取られているのか。
不正アクセスが発生したら誰が気付くのか。
といった部分は別途確認しなければなりません。
AIサイト制作サービスの中には、ホスティングやセキュリティまでマネージドで提供しているものもあります。
その場合は管理負担をかなり減らせます。
一方、AIでコードだけを作り、VPSやクラウド環境へ自分でデプロイする場合は、かなり多くの管理責任が利用者側へ戻ってきます。
「AIで作ったから危険」なのではありません。
重要なのは、
AIがサイトを作った“その後”を誰が管理する設計になっているか
です。
Wixがセキュリティ面で評価できる理由
では、ここからWixについて見てみましょう。
最初に明確にしておきたいのは、
Wixにも脆弱性が存在する可能性はあります。
大規模なソフトウェアやクラウドサービスで、脆弱性が一度も発見されないと考えること自体が現実的ではありません。
Wixを評価するときに見るべきなのは、
「脆弱性が存在しないこと」
ではなく、
脆弱性や攻撃を前提として、どのような予防・検知・対応の仕組みを用意しているか
です。
Wixが取得・公表している主な認証
2026年10月17日時点で、Wixは公式情報上、
ISO/IEC 27001
ISO/IEC 27017
ISO/IEC 27018
ISO/IEC 27701
SOC 2 Type II
SOC 3
PCI DSS Level 1
などを公表しています。
それぞれ対象は異なります。
ISO27001は情報セキュリティ管理。
ISO27017はクラウドセキュリティ。
ISO27018はクラウド環境における個人情報保護。
ISO27701はプライバシー情報管理。
SOC 2 Type IIは、一定期間にわたってセキュリティ等の内部統制が適切に運用されているかを第三者が評価するものです。
PCI DSS Level 1は決済・カード情報に関する高度なセキュリティ基準です。
もちろん、これらを取得しているから「絶対安全」という意味ではありません。
しかし、
複数の異なる観点から外部評価を受けている
ことは、プラットフォームを評価する材料の一つになります。
WixではSOCとSIEMによる24時間365日の監視を公表
個人的にWixのセキュリティで重要だと考えているのが、
「認証の数」よりも、監視と対応の仕組みです。
WixはSecurity Operations Center、いわゆるSOCによる24時間365日の監視体制を公表しています。
さらにSIEMと呼ばれる仕組みを利用して、システム上で発生するイベントや情報を集約し、不審な動きや攻撃の兆候を検知する体制を説明しています。
専門用語なので簡単に言えば、
「Webサイトやシステムの中で変な動きが起きていないかを、継続的に監視する仕組み」
と考えると分かりやすいでしょう。
中小企業が自社で同じ仕組みを構築しようとすると、かなりの専門知識とコストが必要になります。
脆弱性を「見つける」仕組みも複数存在する
Wixはクラウド環境や公開インターフェースについて、脆弱性や設定ミスを定期的に自動スキャンしているとしています。
さらに、
Wix内部のセキュリティチームによる侵入テスト。
外部第三者によるペネトレーションテスト。
セキュリティレビュー。
Bug Bounty Program。
などを実施しています。
Bug Bountyとは、世界中のセキュリティ研究者にサービスを調査してもらい、未知の脆弱性を発見した場合に報奨金を支払う仕組みです。
つまり、
「自社のセキュリティチームだけで脆弱性を探す」のではなく、外部の研究者にも発見してもらう
という考え方です。
もちろんBug Bountyがあるから脆弱性がなくなるわけではありません。
しかし、未知の問題を早期発見するための手段としては有効です。
Wixは開発段階からセキュリティを組み込んでいる
WixはSSDLC（Secure Software Development Life Cycle）という考え方も公表しています。
これは、
完成したシステムを最後にセキュリティチェックするのではなく、設計・開発段階からセキュリティを組み込む
という考え方です。
設計・コードレビュー、脅威モデリング、侵入テストなどを開発工程へ組み込んでいると説明しています。
セキュリティは「後から付け足すもの」ではなく、開発工程そのものへ組み込む必要があります。
その体制が明示されていることは、一つの評価材料になります。
DDoS対策やインシデント対応体制もプラットフォーム側
WixはDDoS攻撃への検知・対応に加え、専任のIncident Responseチームを設置していることも公表しています。
インシデントが発生した場合に調査・対応する専門チームです。
さらにBCP（事業継続計画）や復旧計画についても公表しています。
つまり、
予防だけではなく、検知・対応・復旧まで含めた設計
になっています。
ここがWebサイトのセキュリティを見るうえで重要なポイントです。
Wixの本当のメリットは「絶対安全」ではない
ここまで読むと、
「ではWixなら情報漏洩しないのか？」
と思うかもしれません。
答えは、
いいえ。そこまで断定することはできません。
セキュリティに100％はありません。
Wixを利用していても、フィッシングでパスワードを盗まれたり、管理者権限を誤って付与したり、外部APIの認証情報を漏らしたりすれば問題は起こり得ます。
Wix自身も二要素認証や権限管理などを提供しています。
では、Wixの本当のメリットは何でしょうか。
DRBでは、
「企業が自分で抱えなくてもよいセキュリティ管理領域が非常に広いこと」
だと考えています。
Wixならサーバー管理そのものを利用者がする必要がない
Wix公式のTrust Centerでは、Wixユーザーにはサーバーメンテナンスが不要であり、別途クラウドホスティングを購入する必要もないと説明されています。
これは中小企業にとってかなり重要です。
Webサイトを運営するためだけに、
OSを更新する。
Webサーバーを更新する。
PHPを更新する。
データベースを管理する。
CMSのセキュリティパッチを管理する。
DDoS対策を用意する。
24時間ログを監視する。
という作業を自社で抱える必要がありません。
その部分をプラットフォーム側へ委ね、
自社は、
コンテンツ、デザイン、SEO、採用、集客、ブランディング、顧客対応
といった、本来Webサイトを使って実現したかった活動へ時間を使うことができます。
これは「技術的に楽」というだけではありません。
経営資源をどこへ使うか
という問題です。
ShopifyやBASEもセキュリティ面で有力な選択肢
公平に比較するなら、ECサイトではWixだけが選択肢ではありません。
特にShopifyは非常に強力です。
Shopifyは公式に、
PCI DSS Level 1、SOC 2 Type II、SOC 3
を公表しています。
さらに大規模なBug Bounty Programも継続しています。
TLS証明書もShopifyへ接続したドメインに自動提供されます。
そのため、本格的なEC事業を中心に考えるのであれば、Shopifyは非常に有力な選択肢です。
BASEも2026年にISO27001認証を取得
BASE株式会社は2026年8月28日付で、PAY株式会社、want.jp株式会社とともにISO/IEC 27001認証を取得しています。
ネットショップ作成サービス「BASE」も認証の適用範囲に含まれています。
BASEの情報セキュリティ基本方針では、BASE株式会社についてPCI DSSのSAQ-Aを取得していることも公表されています。
また、二段階認証やパスキー認証も提供しています。
なお、情報漏洩のあったEストアーは現在BASEグループですが、2026年のショップサーブへの不正アクセスについてBASE株式会社は、BASEをはじめとする関係会社サービスとはサーバー・システム環境が異なり、BASE等で本件による情報漏洩は発生していないと発表しています。
「同じグループだから同じセキュリティ問題がある」と考えるのは適切ではありません。
Wix・Shopify・BASEのどれがいいのか？
ここは「どれが一番安全か」だけで決めるべきではありません。
用途が違うからです。
たとえば、
ECが事業の中心で、商品数や注文数が大きく、EC運営を本格化したい
のであれば、Shopifyは非常に有力です。
小規模にネットショップを始めたい
のであれば、BASEの手軽さは大きなメリットになります。
一方で、
コーポレートサイト、サービス紹介、CMS、ブログ、問い合わせ、予約、イベント、会員機能、マーケティングなどを一つのプラットフォームで運用したい
という事業主、企業ではWixが有力な選択肢になります。
重要なのは、
Webサイトの目的と、自社が管理できる範囲を合わせて考えること
です。
どんな企業にWixが向いているのか
特にWixのようなフルマネージド型SaaSと相性がいいのは、次のような企業です。
社内にWebエンジニアがいない
専任のセキュリティ担当者がいない
サーバーを管理したくない
WordPressのアップデート管理に不安がある
制作後は自社でもページを更新したい
ブログやCMSを運用したい
問い合わせや予約などもまとめたい
Webサイトのためだけにインフラ担当者を置けない
保守管理より集客やコンテンツ制作に時間を使いたい
制作会社へ毎回更新依頼を出すのではなく自社運用したい
特に中小企業では、
「高度なWebインフラを自社で管理すること」
そのものが事業目的ではありません。
本来の目的は、
問い合わせを増やす。
採用につなげる。
商品を販売する。
ブランドを伝える。
顧客との接点を作る。
という部分です。
そのため、
セキュリティやインフラ管理を専門事業者へ委ね、自社は事業活動へ集中する
という考え方は合理的です。
反対にWix以外を検討したほうがいいケース
もちろんWixがすべての企業に適しているわけではありません。
高度なサーバー構成を自由に設計する必要がある。
特定のバックエンド技術を使わなければならない。
インフラを完全に自社管理したい。
非常に特殊なシステム連携が必要。
大規模ECを中心に事業を組み立てる。
といった場合は、別の選択肢が適している可能性があります。
WordPressを適切な保守体制で運用する方法もあります。
Shopifyを選ぶ方法もあります。
独自開発する方法もあります。
Webサイト選びは、
「何が一番優れているか」ではなく「自社の目的に対して何が適しているか」
で考えるべきです。
ホームページを選ぶときのセキュリティチェックリスト
新しくホームページを作る場合や、現在のサイトを乗り換える場合は、制作方法だけでなく次の項目を確認してみてください。
確認項目 | 確認する理由 |
サーバーは誰が管理するのか | 障害・更新・攻撃対応の責任を確認する |
OSやミドルウェアは誰が更新するのか | 古いソフトウェアの放置を防ぐ |
CMSは自動更新されるのか | 脆弱性修正を誰が担当するか確認する |
SSL/TLSは自動管理されるか | 通信暗号化を維持する |
WAFがあるか | Webアプリへの代表的な攻撃を防御する |
DDoS対策があるか | 大量アクセス攻撃への耐性を見る |
脆弱性診断をしているか | 問題を早期発見する |
ペネトレーションテストをしているか | 実際の攻撃を想定して検証する |
24時間監視があるか | 攻撃を早く発見できるかを見る |
インシデント対応体制があるか | 発生後に誰が対応するのかを見る |
バックアップ・復旧体制があるか | 攻撃・障害後に復旧できるかを見る |
二要素認証・MFAがあるか | アカウント乗っ取りを防ぎやすくする |
権限管理ができるか | 必要以上のアクセス権を与えない |
第三者認証があるか | 組織的なセキュリティ体制を確認する |
外部連携の認証情報をどう管理するか | APIキー等の漏洩リスクを確認する |
この質問を制作会社やサービス提供会社へ聞くだけでも、ホームページ選びの判断材料はかなり増えます。
よくある質問
Wixは絶対安全ですか？
いいえ。
セキュリティに100％はありません。
Wixにも脆弱性が発見される可能性はあります。
ただしWixは、ISO27001、27017、27018、27701、SOC 2 Type II、SOC 3、PCI DSS Level 1などを公表し、SOCによる24時間365日の監視、SIEM、脆弱性スキャン、ペネトレーションテスト、Bug Bounty、Incident Responseなど複数層の対策を実施しています。
さらに、利用者自身がサーバー保守を担当する必要がない点も大きな特徴です。 同時にWixはレジストラでもあるため、最高レベルのセキュリティでドメイン管理も行なっており、サーバー、ドメインまでオールインワンです。
WordPressは危険なのでしょうか？
WordPressだから危険というわけではありません。
WordPress本体には専門のSecurity Teamがあり、継続的にセキュリティアップデートが行われています。
ただしセルフホスト型WordPressでは、WordPress本体だけでなく、テーマ、プラグイン、サーバー、PHP、バックアップなど利用者側に残る管理項目が比較的多くなります。
適切な運用体制を用意できるかが重要です。
Studioで不正アクセスが起きたので、Wixへ乗り換えたほうがいいですか？
今回の事案だけを理由に、すべてのStudioサイトがWixへ乗り換えるべきだとは考えていません。
StudioはISO27001・27017を取得し、WAF、DDoS対策、脆弱性診断、ペネトレーションテスト、Bug Bountyなど複数のセキュリティ対策を実施しています。
まずStudioが今後公表する原因調査や再発防止策を確認する必要があります。 特に、問題に気がつき対応まではとても早く信頼に値します。
そのうえで、自社サイトの用途、保有している情報、必要な機能、社内の運用体制などを考えて判断するべきです。
ISO27001などの認証があれば安全ですか？
認証は重要な判断材料ですが、それだけで絶対安全とは言えません。
ISO27001は情報セキュリティ管理の仕組みを評価する規格であり、「システムに脆弱性が一切存在しない」と保証するものではありません。
そのため、認証だけでなく、脆弱性管理、監視、検知、インシデント対応、復旧まで確認することが重要です。
小さな会社のホームページでも攻撃されますか？
可能性はあります。
攻撃者が必ずしも特定企業を狙って攻撃するとは限らず、自動化されたスキャンによってインターネット上の脆弱なシステムを広く探索する攻撃もあります。
「小さい会社だから誰も狙わない」と考えるより、
攻撃される可能性を前提として、管理負担をどう減らすか
を考えるほうが現実的です。
AIで作ったホームページは危険ですか？
AIだから危険とは言えません。
重要なのはAIが生成した後の運用環境です。
フルマネージド型サービス上で生成される場合と、AIが生成したコードを自分でサーバーへ公開する場合では、利用者側のセキュリティ責任が大きく異なります。
ホスティング、アップデート、脆弱性対応、ログ監視、バックアップの担当者まで確認しましょう。
WixとShopifyならどちらが安全ですか？
単純に「どちらが安全」と断定するのは難しいです。
ShopifyはPCI DSS Level 1、SOC 2 Type II、SOC 3などを公表しており、特にECを中心とする事業では非常に有力なプラットフォームです。
Wixも複数のISO認証、SOC 2 Type II、SOC 3、PCI DSS Level 1などを公表しています。
セキュリティだけでなく、EC規模、コンテンツ運用、CMS、予約、マーケティングなど、事業全体の用途を考えて選ぶことをおすすめします。
まとめ｜ホームページ選びを「作りやすさ」から「安全に運用し続けられるか」へ
AIによって、Webサイトを作ること自体は急速に簡単になっています。
しかし、
「作れるようになったこと」と「安全に運営できるようになったこと」は同じではありません。
2026年のEストアーやStudioの事例からも分かるように、セキュリティ対策を行い、第三者認証を取得している企業でもインシデントは起こり得ます。
だからこそ、
「どのサービスなら絶対安全か」
を探すのではなく、
「問題が起きる可能性を前提として、誰が予防し、誰が検知し、誰が対応し、誰が復旧するのか」
を見ることが重要です。
WordPressにはWordPressの強みがあります。
StudioにはStudioの強みがあります。
ShopifyやBASEにも、それぞれ適した事業があります。
そしてWixの大きなメリットは、
「脆弱性が存在しないこと」ではなく、サーバー、ホスティング、CMS基盤、監視、脆弱性管理、インシデント対応など、多くのセキュリティ業務をプラットフォーム側へ委ねられること
にあります。
社内に専任のWebエンジニアやセキュリティ担当者がいないのであれば、
自社で高度なインフラ管理を抱えるよりも、
専門事業者へ管理を任せ、空いた時間と予算をコンテンツ、集客、採用、ブランディング、顧客体験の改善へ投資する。
これもWebサイトのセキュリティ戦略の一つです。
Webサイトを選ぶ基準を、
「何で作れるか」から「安全に運用し続けられるか」へ。
これからホームページを作る企業にも、現在のホームページに不安を感じている企業にも、一度考えていただきたい視点です。
今のホームページを、このまま使い続けても大丈夫？
Design Radiant Bridgeでは、Wix Studioを中心にWebサイト制作・リニューアル・公開後の運用支援を行っています。
ただし、
「とにかくWixへ乗り換えましょう」
という前提でご提案することはありません。
現在利用しているCMSやサーバー、ホームページの構成、更新方法、社内の運用体制などを確認したうえで、
「現在の環境のままで問題ないのか」
「セキュリティ設定や運用方法の改善で対応できるのか」
「CMSそのものを変更したほうがいいのか」
「Wixへ移行するメリットがあるのか」
を整理します。
Webサイトは、作って終わりではありません。
公開したあと、安全に運用しながら事業の成果につなげていくことが本当のスタートです。
「今のホームページをこのまま使い続けていいのかわからない」
「WordPress、Wix、Studioなど、結局どれが自社に合っているのかわからない」
「ホームページのセキュリティや管理方法を一度整理したい」
という場合は、お気軽にDesign Radiant Bridgeへご相談ください。
