CMSのセキュリティと静的サイトへの切り替え

Studioの不正アクセスでは、フォームに送られた内容まで流出した可能性がある

2026年10月16日、ノーコードでWebサイトを作れるサービス「Studio」を運営するStudio株式会社が、クラウド環境への不正アクセスを公表しました。登録しているすべての顧客の情報が流出した可能性がある、という内容です（出典 Studio「不正アクセスによる情報流出に関するお詫びとお願い（第一報）」）。

Studioを使って自社サイトを公開している会社は多く、制作会社に頼んでStudioで作ってもらったというケースもよくあります。今回の件は、Studioのアカウントを持っている人だけでなく、そのサイトの問い合わせフォームから連絡した人にも関わる話です。

公式発表で確認できている事実

第一報で公表されている内容を整理すると、次のとおりです。

項目	公表内容
不正アクセスの期間	2026年9月30日〜10月1日（現時点で確認できている期間）
外部から取得できる状態	10月14日に対処するまで続いていた
発覚と対処	10月13日に社内調査で確認、14日までに脆弱性を修正し経路を遮断
対象の範囲	Studioに登録しているすべての顧客が対象の可能性
流出した可能性のある情報	アカウント情報、CMSの内容、フォームの送信内容、外部サービスのAPIキー、Googleスプレッドシート連携の認証情報、パスワード保護ページのパスワードなど
取得の有無	第三者に取得された事実は確認できていないが、取得されたものとみなして対応
改ざん・削除	現時点で確認されていない

フォームの送信内容やAPIキー（外部サービスとつなぐための合い鍵のような文字列）は暗号化して保存されていたものの、復号に必要な鍵も同じ不正アクセスで読み出されたため、内容を知られた可能性があるとされています。原因は「一部機能の脆弱性」とされていて、詳しい内容や対象件数、二次被害の有無は調査中です。いずれも続報で公表される予定です（この記事は10月16日時点の第一報をもとに書いています。続報で内容が変わる可能性があります）。

Studioだけの問題として片づけられない

今回の件を受けて「Studioは危ない」と考える方もいるかもしれませんが、サイトの内容や問い合わせのデータを事業者のサーバーに預けるサービスであれば、同じ種類の事故は起こりえます。Studioは公表と同時に、利用者がやるべき対応まで具体的に案内しています。

気をつけたいのは、データを預ける仕組みのほうです。フォームに送られた個人情報がサービス側のデータベースに保存されている以上、そこが破られれば、サイトを運営している会社は自分では何もしていなくても当事者になります。

フォームの中身が漏れると、サイトを運営する会社にも連絡と報告の仕事が生じる

フォームの送信内容が流出した可能性がある場合、サイトを運営している会社は、問い合わせをしてくれた人に連絡する必要が出てきます。Studioの第一報でも、フォームを使っているプロジェクトのオーナーには、送信内容についての連絡を個別に案内するとしています。

問い合わせを送ってくれた人へ、一人ずつ連絡することになる

問い合わせフォームには、名前、電話番号、メールアドレス、相談内容が入っています。相談内容には、病院であれば症状、士業であれば家族の事情や借金の話、採用フォームであれば経歴が書かれていることもあります。

これらを送ってくれた人に「あなたの情報が漏れた可能性があります」と連絡するのは、会社にとって重い作業です。誰に連絡するのか、どこまで説明するのかは、サービス側の続報を待ちながら自社で判断することになります。

件数や内容によっては、個人情報保護委員会への報告が必要になる

個人情報保護法では、個人データの漏えい（そのおそれを含む）が一定の条件に当てはまる場合、個人情報保護委員会への報告が義務になっています。条件には、本人の数が1,000人を超える場合や、不正な目的で行われたおそれがある場合が含まれます（出典 個人情報保護委員会「漏えい等の対応とお役立ち資料」）。

報告には期限もあります。発覚から3〜5日以内に速報、30日以内に確報を出す形で、不正な目的で行われたおそれがある場合は確報の期限が60日以内になります。病歴など、法律で「要配慮個人情報」とされる情報が含まれていれば、1件でも報告の対象になります（自社のケースが当てはまるかどうかは、委員会の資料や専門家に確認してください）。

制作会社もクライアントへの説明に追われる

制作会社の立場から言うと、こうした事故が起きたときに一番つらいのは、クライアントへの連絡です。自社で作ったサイトのフォームの中身が漏れた可能性がある、と一社ずつ伝えて回ることになります。

原因が使っているサービス側にあっても、クライアントから見れば「あの制作会社に作ってもらったサイトで起きた」という事実が残ります。次のリニューアルや新しい提案の話もしにくくなります（正直、制作会社にとってはこれが一番こたえます）。

WordPressは便利な反面、昔から狙われやすい

クラウド型のサービスだけでなく、WordPressにも以前からセキュリティの心配がつきまといます。サイシアも制作案件の多くはWordPressで納品していますが、その前提として、更新や保守の手間がかかる仕組みであることはお伝えしています。

世界のWebサイトの約4割がWordPressで動いている

調査会社W3Techsによると、2026年10月時点でWordPressは全Webサイトの39.7%で使われていて、CMS（ホームページの更新システム）を使っているサイトの中では58.4%を占めています（出典 W3Techs「Usage statistics and market share of WordPress」）。

利用者が多いということは、攻撃する側から見ても効率がよい標的だということです。1つの弱点を見つければ、同じ仕組みで動いている大量のサイトに同じ手口が使えます。

弱点の9割はプラグインで見つかっている

WordPressのセキュリティを専門に扱うPatchstackの年次報告では、2025年にWordPress関連で見つかった新しい脆弱性（プログラムの欠陥による弱点）は11,334件で、前年から42%増えています。そのうち91%がプラグイン、9%がテーマで見つかったもので、WordPress本体で見つかったのは6件だけでした（出典 Patchstack「State of WordPress Security in 2026」）。

同じ報告では、脆弱性の46%が公表された時点で開発者からの修正版が出ていなかったとされています。また、大規模に悪用された脆弱性では、悪用が広がるまでの時間の中央値が5時間という数字も出ています。

更新が止まったサイトから狙われる

フォーム、予約、SNS連携、スライダーなど、WordPressのサイトには何らかのプラグインが入っているのが普通です。公開から数年たつと、作った担当者が退職していたり、保守契約が切れていたりして、誰も更新していない状態のサイトが出てきます。

弊社でリニューアルのご相談を受けるサイトでも、プラグインが何年も前のバージョンのまま、というケースは珍しくありません。更新を止めた状態が長く続くほど、狙われやすくなると考えてよいと思います。

ノーコードでもWordPressでも、リスクの入口は「サーバー側で動く仕組み」

Studioのようなクラウド型のサービスとWordPressは、仕組みは違っても、共通点があります。どちらも、ページを更新するための管理画面や、データを保存する仕組みを、サービス側やサーバー側に持っています。

管理画面やデータベースがあると、攻撃される対象になる

ページを更新するための管理画面と、記事やフォームの送信内容を保存するデータベースがあるから、専門知識がなくてもブラウザからページを直せます。一方で、管理画面やデータベースが外からつながる場所にある以上、攻撃する側にとっては入口になります。

便利さとリスクはセットになっているので、どちらか一方だけを取ることはできません。

クラウド型は、自社で手を打てる範囲がほとんどない

WordPressであれば、プラグインを減らしたり、管理画面へのアクセスを制限したりと、自社や制作会社で打てる手があります。

クラウド型のサービスでは、セキュリティの管理はサービスを提供する会社に任せる形になります。利用者側でできるのは、パスワードを強くする、二段階認証を使うといった範囲に限られます（サービス側で手厚く管理してくれるのは利点でもあるので、悪いことばかりではありません）。

静的サイトは攻撃される入口が少ない

静的サイトは、ページを完成した状態のファイル（HTML）にしてサーバーに置いておくだけの仕組みです。見に来た人には、置いてあるファイルをそのまま返します。ページを表示するたびにサーバーでプログラムを動かす必要がないので、CMSに比べて攻撃される入口が減ります。

管理画面とデータベースを持たない

静的サイトには、ブラウザからログインする管理画面がありません。記事やページの内容を保存するデータベースもありません。WordPressのログイン画面を総当たりで破られる、プラグインの弱点からデータベースを抜き取られる、といった典型的な被害は、構造上起こりにくくなります。

CMSのように、本体やプラグインの更新を追いかけ続ける必要もほとんどありません（フォームの送信に使う小さなプログラムは、サーバー側での更新が必要です）。保守の手が回らない中小企業にとっては、この点が大きいと考えています。

フォームは内容を保存せず、メールで受け取るだけの形にできる

静的サイトでも問い合わせフォームは使えます。送信だけを受け持つ小さなプログラムをサーバーに置き、送信された内容を保存せずに担当者のメールアドレスに送るだけの作りにすれば、サイトの側に個人情報がたまっていきません。

仮にサーバーに不正にアクセスされたとしても、過去の問い合わせ内容がまとめて抜き取られる、という事態は起きにくくなります。

なお、サイシアのこのサイトも静的サイトで運用しています。問い合わせフォームも、送信内容を保存せずにメールで受け取る形にしています。

静的サイトでもリスクはゼロにならない

静的サイトにすればリスクがなくなる、というわけではありません。減らせるのはCMS特有のリスクで、それ以外のリスクは残ります。

契約しているサーバー会社側で漏洩が起きる可能性は残る

静的サイトも、どこかのレンタルサーバーやクラウドに置いて公開します。そのサーバー会社が攻撃を受けたり、設定のミスがあったりすれば、影響を受けることもあります。メールを受け取るためのメールサーバーも同じです。

サーバー会社を選ぶときは、価格だけでなく、運営実績やセキュリティへの取り組みも見ておくのがベターです。

フォームに外部サービスを使う場合は、その会社の管理に依存する

静的サイトのフォームでは、送信の処理を外部のフォームサービスに任せる方法もよく使われます。この場合、送信内容がそのサービスに保存されるかどうかは、サービスの仕様次第です。

保存される仕組みであれば、今回のStudioと同じ種類のリスクがそのサービスに移るだけになります。フォームの作り方は、制作会社に確認しておくと安心です。

サーバーのパスワード管理とフォームの保守はこれまでどおり必要

サーバーにファイルを置くためのFTPのパスワードや、サーバー会社の管理画面のパスワードが漏れれば、サイトを書き換えられるおそれがあります。パスワードの使い回しを避け、退職した担当者のアカウントを残さないといった基本の管理は、静的サイトでも変わりません。

フォームの送信に使うプログラムも、サーバー側の言語のバージョンアップに合わせて手を入れたり、迷惑メール対策を見直したりする必要があります。CMSに比べれば手間はずっと少ないものの、まったく放っておいてよいわけではありません。

静的サイトの弱点は、自社でページを直せなくなること

静的サイトに切り替えるときのデメリットもお伝えしておきます。一番大きいのは、お客様の側で自由にページを直したり追加したりできなくなる点です。

修正やページの追加は制作会社に頼む形になる

WordPressやStudioでは、お知らせの投稿や文章の修正を、ブラウザから自社で行えます。静的サイトには管理画面がないので、文章を1行直すにも、制作会社に依頼してファイルを作り直してもらう形になります。

「ちょっとした修正のたびに見積もりを取るのは面倒」と感じる方には、この点は大きな負担に見えると思います。

AIの活用で、制作会社側の修正コストが下がってきた

この弱点は、この1〜2年で事情が変わってきました。AIを使ってページのコードを書いたり直したりできるようになり、制作会社側で修正にかかる時間が大幅に短くなっています。

文章の差し替えや、既存のページと同じ形式でのページ追加であれば、依頼を受けてから短時間で反映できるケースが増えています。以前は「静的サイトは更新のたびにお金がかかる」というのが定説でしたが、今は以前よりも修正の費用を抑えやすくなっています（修正の内容や頻度によって変わるので、保守の範囲は事前に決めておくのがおすすめです）。

保守費用の考え方はホームページ保守費用の内訳にもまとめています。

毎日ブログを更新する会社には向かない場合もある

社内の担当者が毎日のようにブログやお知らせを投稿している会社では、その都度制作会社に依頼するのは現実的ではありません。こうした会社では、WordPressのまま、プラグインを絞って保守をしっかり回すほうが合っている場合もあります。

更新の頻度が月に数回程度であれば、静的サイトに切り替えても困る場面は少ないと考えています。

静的サイトへの切り替えはAIの活用で費用を抑えやすくなった

これまで、既存のサイトを静的サイトに作り直すには、ページを1つずつ作り直す手間がかかっていました。今はAIを使うことで、この作業にかかる時間と費用を抑えられるようになっています（ページ数や必要な機能によって費用は変わります）。

今のサイトの内容とURLを引き継いで作り直す

切り替えは、今のサイトのページと文章を洗い出して静的サイトとして組み直し、URLを引き継いで公開する、という順番で進めます。

URLを変える場合は、古いURLから新しいURLへの転送（リダイレクト）を設定しないと、検索順位が落ちる原因になります。リニューアル全般の確認項目はホームページリニューアルのチェックリストを参考にしてください。

デザインを大きく変えず、今のサイトの見た目をほぼそのまま静的サイトに移すこともできます。見た目を変えずに中身の仕組みだけを入れ替える形なので、社内での説明もしやすいと思います。

会社案内が中心で更新が月数回のサイトは切り替えに向いている

静的サイトへの切り替えが向いているのは、会社案内やサービス紹介が中心で、更新の頻度が月に数回程度のサイトです。問い合わせフォームで個人情報を受け取っているサイトや、保守の担当者がいなくてWordPressの更新が止まっているサイトも、切り替えによってリスクを減らせる余地が大きいと見ています。

反対に、会員ログインや予約、ネットショップのように、サイト上でデータをやり取りする機能が中心のサイトは、静的サイトだけでは対応できません。こうした機能は専用のサービスと組み合わせる形になります。

最後に

Studioの件は、サイトの仕組みを提供する会社に事故が起きると、サイトを運営している会社も問い合わせ者への連絡や報告に追われる、という現実を見せたものだと受け止めています。WordPressも、利用者が多い分だけ狙われやすく、更新を止めればリスクは上がっていきます。

静的サイトに切り替えても、リスクがゼロになるわけではありません。ただ、管理画面やデータベースといった攻撃の入口を減らし、フォームの内容をサイトにためない作りにすることで、事故が起きる可能性と起きたときの影響を小さくできます。自社で更新しにくいという弱点も、AIの活用で制作会社側の対応コストが下がり、以前ほどの負担ではなくなってきました。

サイシアでは、WordPressやノーコードCMSで作ったサイトを、AIを活用して費用を抑えながら静的サイトに切り替えるご相談を承っています。今のサイトが切り替えに向いているかどうかの確認からでも対応しますので、気になる方はお気軽にご相談ください。

ホームページ制作のご相談はこちら