StudioとWordPressでは、セキュリティのリスクの形はどう違いますか？
サーバーやプログラムの保守を運営会社へ一任するStudioと、土台から自前で管理するWordPressとでは、警戒すべき危険の所在が大きく異なります。
Studioでは、サーバーや部品の更新をサービス側が引き受けます。利用しているプラットフォームやライブラリに脆弱性が見つかれば、Studio側で更新する体制です。利用者が自分で更新作業をする場面はありません。そのかわり、提供会社の環境で問題が起きると、自社がどれだけ気をつけていても影響を受けます。
一方のWordPressでは、本体やプラグイン、テーマの古い版が攻撃の入口になりやすく、更新を続けるのは運用する側の仕事です。共有サーバーで動かしている場合は、同じサーバーの別サイトが侵害されたときに、自サイトまで巻き込まれる可能性もあります。更新に加えて、定期的なバックアップと侵入の監視までそろえて、ようやく安全管理になります（WordPress公式の安全強化ガイド）。
ただし、SaaS（ネット上で借りて使うサービス）なら任せきりでよい、というわけでもありません。基盤を提供会社が管理していても、データと、誰がログインできるかを守る責任は利用者に残ります。自社の基準に合致するか確かめる手段として、Studioが公開しているチェックシートを照合材料に使う組織も見られますね。
2026年10月のStudioの事案では、SaaS型のどんな弱点が表に出ましたか？
クラウド事業者に管理を任せていれば事故は防げるのかという疑問に対して、今回の事案はSaaS特有の弱点を浮き彫りにしました。提供会社の環境に一度入られると、全利用者のデータがまとめて危険にさらされます。
Studioが確認した不正アクセスの期間は、2026年9月30日〜10月1日です。一部機能の脆弱性が悪用され、クラウド環境のデータを外部から取得できる状態は10月14日の対処まで続きました（Studioの事案のお知らせ）。流出の可能性があるのは全登録顧客で、アカウント情報、CMSやフォームの内容、外部サービスのAPIキーなどが含まれます。利用者のサイトに届いたお問い合わせなど、各組織が集めた個人情報にも影響が及びました。
暗号化して保存していたフォーム内容やAPIキーも安心できません。復号に使う鍵が同じ不正アクセスで読み出されたため、暗号化した中身も、流出した可能性のある情報に含まれています。第三者が実際にデータを取得したことは確認できていないものの、Studioは取得されたとみなして対応しています。
加えて、外部サービスのAPIキーはStudio側で一括無効化ができません。利用者が発行元で新しいキーを作り、設定を更新してから古いキーを消すという個別作業を余儀なくされました。順番を逆にすると、サイトの連携が止まることがありますね。
なお、Studioを通さずGoogleフォームで受け付けていたデータは、今回の対象外とされた事例もあります。とはいえ、自分だけでは防げない事故はWordPressの共有サーバーでも起こりえるので、SaaSだけの弱点とは言い切れません。
WordPressにはどんなセキュリティの弱点がありますか？
Studioの弱点が提供会社の側に集まるのに対して、WordPressの弱点は自分のサイトのまわりに散らばっています。よく狙われるのは、更新されていないプラグインやソフトウェアの脆弱性と、ログインパスワードの推測です。
プラグインは、便利な機能を簡単に追加できる反面、更新が途絶えたプラグインや脆弱な設計がそのまま不正アクセスの入口になってしまうのです。
もうひとつの盲点は、動作基盤となるPHPの管理です。2026年10月21日には、PHPの重大な脆弱性2件を直す更新が公表されました（WordPress日本語版の告知）。修正版は8.5.12、8.4.27、8.3.36、8.2.35。この問題はWordPress固有ではなく、PHPでウェブの要求を処理する環境全体に関わるため、WordPress本体を更新しても対処にはなりません。
使用中の環境は、管理画面の「ツール」から「サイトヘルス」、「情報」、「サーバー」の順に進むと確かめられます。PHPの版ごとのサポートの期限は、契約先のホスティング会社の案内でも確かめておきたいところです。
同じサーバーで複数のサイトを動かしているなら、データベースと管理するユーザーをサイトごとに分けておくと、1つのサイトが破られたときに他へ広がる被害を抑えられます。さらに復旧に備えて、本体ファイルとデータベースの両方を含むバックアップを定期的に取り、信頼できる場所に保存します。バックアップは侵入を防ぐものではなく、壊されたあとに戻すための備えです。
自社の場合、StudioとWordPressのどちらが安全か判断するには？
自社で更新や監視をどこまで担えるのか。ここを先に書き出すと、答えはかなり見えてきます。
IPAのウェブサイト管理案内でも示されている通り、利用先の事業者が担う作業範囲と自社の責任範囲を整理し、足りない対策を自力で補える体制を整えなければなりません。
WordPressを選ぶ場合、本体やプラグインの修正プログラムが出た際の迅速な更新はもちろん、PHPなどサーバー環境の更新時にサイトが正しく動くか検証する技術力が求められます。強いパスワードの設定や二段階認証の導入、復元テストまで済ませた定期バックアップ計画を実行できる担当者や保守委託先が不可欠です。
反対にStudioは、ミドルウェアやライブラリの更新をプラットフォーム側が引き受けるため、日常のシステム保守に人を割けない組織にとって運用の負担を抑えられます。ただ、脆弱性が見つかれば迅速に更新するという説明は、事故が起きないという約束ではありません。今回もフォームの送信内容は暗号化されていましたが、復号の鍵まで読み出され、中身を知られた可能性が出ました。お問い合わせで個人情報を多く受け取るサイトほど、提供会社で事故が起きたときの影響が大きくなりますね。
StudioとWordPress以外に、より安全な選択肢はありますか？
「どちらにも不安があるなら、別の作り方はないのか」と考える人もいるでしょう。選択肢として挙がるのが、静的サイト生成という作り方です。
アクセスがあるたびにサーバー上でデータベースと通信してページを組み立てる動的サイトと異なり、公開サーバーには完成されたファイルしか置きません。Astroなどのツールにこの作り方の機能があり、作ったファイルを読み取り専用で公開すれば、攻撃に使える入口を減らせます。
誰が見ても同じ内容が表示されるコーポレートサイトやお知らせ記事の配信には、この静的な仕組みがよく合いますね。もっとも、内容を変更した際にはページを再生成するビルド作業が必要になります。このビルド作業自体は自動化が可能ですが、ログインした会員ごとに異なる画面を出し分けるような用途には単独で対応しにくい制限があります。
ちなみにStudioを使い続ける場合でも、設定次第でリスクを抑える工夫は可能です。事前に設定しておけば、回答をStudioのデータベースに残さず、通知先のメールだけで受け取れます（Studioのフォーム回答の設定）。この設定では画像やPDFなどのファイルを受け取れないので、添付が必要なフォームには使えません。メール側に回答が残ることも頭に入れておいてください。