Q.Studioのようなノーコードツールで不正アクセスが起きたとき、使い続けるかはどう判断し、2026年の代わりのツールには何がありますか？

Studioはデザインから公開までを1つの画面で済ませるツールです。国内で開発されたツールに目を向けると、デザイン一体型の手軽なサービスと、コンテンツ管理に特化した開発者向けのサービスという、対照的な選択肢が存在します。

手軽さを前面に出した代表格がペライチです。あらかじめ用意されたテンプレートを選び、文章や画像を当てはめて編集するだけで、Webサイトを素早く公開できる仕組みを備えています。Studioのように細かくレイアウトを組むより、決まった型に沿って手早く作りたい人に合っています。会社案内や1枚もののサービス紹介ページなら、これで足りる場合も多いでしょう。

反対に、作り方がまったく違うのがmicroCMSです。こちらはAPIを土台とした日本製のヘッドレスCMSであり、サイト全体の見た目を作るノーコードツールとは根本的な役割が異なります。Webサイトとして公開するには、表示部分を作り、それを配信するWebサーバーを別に用意する必要があります（microCMSで必要なインフラ）。静的サイト生成を採用する場合は、別途ビルド用サーバーが必要になるケースもあります。ノーコードだけで完結するサービスではないので、実装を担当するエンジニアや制作会社と相談しながら決めることになります。

記事を自社で更新したいけれど、デザインや公開の仕組みは制作会社に任せたい。そんな体制ならmicroCMS、ページを自分で手早く用意したいならペライチが候補になります。

「自分が普段利用している企業や自治体のサイトは大丈夫なのだろうか」と、影響を受けた組織の一覧を探している方もいるでしょう。民間でまとめられたものとして、セキュリティブログのpiyologが影響を公表した組織の一覧を出しており、国と自治体、上場企業、その他の企業と団体、個人事業主と小規模事業者に分けて載せています。制作会社が顧客向けに出した告知や、報道だけの組織は数えていません。影響を調べていると公表した段階の組織も含むため、被害が確定した数ではありません。

個別企業の公表内容を見ると、影響の範囲は一律ではありません。たとえばLuupは2026年10月16日の公表で、自社サイトのフォームから送られた個人情報が流出した可能性があるとし、LUUPアプリで登録された情報はStudioとは別のシステムで管理しているため対象ではないと説明しています。Studioのサイトに埋め込んだGoogleフォームの回答も、Studioを通らないため今回の流出対象に入りません。

Studioを使っている事業者は、自社が対象かを一覧ではなく、Studioからのメールとログイン時の画面表示で確認します。もうひとつ気をつけたいのが、公表された組織を名乗る不審な連絡です。デジタル庁も、庁をかたる不審な電話やメールに注意するよう呼びかけています。不用意に個人情報を伝えないよう自衛したいですね。

不正アクセスの入口は塞がれましたが、すでに外に出た可能性のある情報は元に戻りません。安全かを考えるときは、この2つを分けて見ます。

Studioは2026年10月13日から14日にかけて脆弱性を修正し、不正アクセスに使われた経路を遮断して、外部からデータを取得できる状態を解消したと公表しました。ただし、これはStudio自身の発表で、外部の専門機関による原因調査はまだ依頼先を調整している段階です。さらに、Studio側で鍵や認証情報を新しく切り替えても、不正アクセスの時点で外部へ取得された恐れのあるデータを元通りに保護し直すことは不可能です。したがって、利用者自身による速やかなセキュリティ対応が欠かせません。

まずパスワードの変更です。Studioのパスワード変更は、画面右上のアイコンから「設定」「アカウント」「パスワードを変更」を選び、現在と新しいパスワードを入力して保存します。GoogleログインかFacebookログインだけを使い、Studioのパスワードを設定していない場合は、変更しようとするとエラーが出ますが、追加の対応は要りません。設定したか分からなければ、ログイン画面の「パスワードをお忘れですか？」から再設定できます。

API連携に外部サービスのキーを登録しているなら、発行元で新しいキーを作り、Studioの設定を更新してから古いキーを失効させます。古いキーを先に失効させると連携が止まる場合があるため、手順の順序を守る配慮が大切です。連携先がmicroCMSなら、読み取りと書き込みでキーの権限を分けられるかを管理画面で確かめ、書き込み権限を持つキーの扱いを見直しておきたいところです。サービス側の修正完了を過信せず、自社で設定した認証情報を適切に見直したいですね。

Studioから別のCMSやサーバーへサイトを引っ越せば、過去に漏えいした可能性のある情報はきれいに消え去るのでしょうか。消えません。ツールを乗り換えても、Studioのアカウントやサイトを削除しても、すでに第三者の手に渡った可能性のあるデータには手が届かないからです。たとえばソフトウェア開発で使われるGitHubでも、元のリポジトリから機密情報を削除したとしても、他の利用者が手元に作成したクローン内の情報までは自分で削除できない仕様になっています。

移行より先にやるべきは、漏れた可能性のある認証情報の入れ替えです。古いキーが有効なまま残っていれば、新しいサーバーへ移転した後であっても外部連携先のアカウントを悪用されかねません。発行元で新しいキーを発行し、古い認証情報を失効させる作業は、移行の前に済ませておきたいところです。連携しているサービスごとに手順が違うため、どの順で入れ替えるかを決めてから作業してください。

報告の義務も移行では消えません。民間の事業者は、不正な目的による行為で個人データが漏えいした場合や、そのおそれがある場合に、漏えい等の報告の対象になります。報告が必要になるのは漏えいやそのおそれが起きた時点なので、あとから別のツールに移っても、その事実は変わりません。

移行は今後の安全対策を固める選択肢であっても、過去の事態を帳消しにする手段ではないと認識しておきたいですね。パスワードと外部サービスの鍵の入れ替え、フォームで情報を預かった人への連絡は、移行を決める前に、今のサイトのまま進める方法もあります。