Studioが不正アクセスで全ユーザーの情報流出の可能性を公表 — フォーム回答・APIキー流出時に運営者がやるべきこと
ノーコードWeb制作プラットフォーム「Studio」を提供するStudio株式会社が、2026年10月16日に不正アクセスによる情報流出の可能性を公表しました。対象は登録しているすべての顧客で、アカウント情報だけでなく、サイトのフォームに送信された内容や外部サービスのAPIキー・トークンまで含まれます。暗号化して保存していたデータも、復号に必要な鍵が同じ不正アクセスで読み出されたため「内容を知られた可能性がある」と同社は説明しています。Studioでサイトを運用しているなら、パスワード変更だけでは対応は終わりません。認証情報の切り替え、ライブプレビューURLの削除、そしてフォーム回答に含まれる個人情報の取り扱い判断までを、今日から順に進める必要があります。
まず着手する順番
影響範囲が広いため、被害が連鎖しやすいものから着手します。優先順位は次の通りです。
- 外部サービスのAPIキー・トークンの切り替え。流出した認証情報がそのまま使えると、Studioの外にある連携先サービスまで被害が広がります。最優先です。
- カスタムプロキシのプロキシキー、Webhook通知先URLの切り替え。
- Studioアカウントのパスワード変更（メールアドレスとパスワードでログインしている場合）。他サービスで同じパスワードを使い回しているなら、そちらも変更します。GoogleまたはFacebookログインのみでパスワードを設定していない場合、この対応は不要とされています。
- パスワード保護ページのパスワード変更、ライブプレビューURLの削除。
- フォーム回答の影響範囲の確認と、必要な連絡・報告の判断。Googleスプレッドシート連携は解除が呼びかけられています。
1〜2が先なのは、鍵が有効なままだと時間の経過がそのままリスクになるためです。パスワード変更は重要ですが、Studioのパスワードはハッシュ化されており（同社は平文保存はしていないと説明）、即座に悪用される性質のものではありません。
公表された事実の整理
Studioの第一報によると、第三者が同社の一部機能の脆弱性を悪用してクラウド環境に不正アクセスし、環境内のデータを外部から取得できる状態にしていたことが確認されました。時系列は次の通りです。
- 2026年9月30日〜10月1日（日本時間）：不正アクセス（現時点で確認できている期間）
- 10月13日：社内調査で不正アクセスを確認
- 10月13日〜14日：脆弱性を修正し、経路を遮断。外部から取得できる状態を解消
- 10月16日：第一報を公開
注意したいのは、攻撃が確認された期間とデータを取得できる状態が続いた期間が別だという点です。同社は、この状態が10月14日の対処まで続いていたとしています。実際に第三者が取得した事実は確認されていないものの、取得されたものとみなして対応が進められています。データの改ざんや削除は、第一報の時点では確認されていません。対象件数、二次被害の有無、原因の調査結果と再発防止策は続報で公表されるとしています。
Studioはスタートアップや中小企業のコーポレートサイトを中心に使われており、ユーザー数は90万人以上（2026年7月の同社発表、ITmedia報道）とされます。影響範囲の広さは、この利用規模に比例します。
「暗号化していたから安全」が成り立たない理由
流出した可能性があるとされたのは、アカウント情報（ユーザー名、メールアドレス、ハッシュ化されたパスワードなど）、Studio上で管理しているデータ（デザインエディタ・CMSの内容、フォームに送信された内容、Google reCAPTCHA v3の設定情報、Webhook通知のURL）、公開前のページを確認するライブプレビューのURL、そして各種設定に含まれる認証情報です。
このうちフォーム送信内容、外部サービスのAPIキーやトークン、Googleスプレッドシート連携の認証情報、プロキシキー、reCAPTCHA v3の設定情報、WebhookのURLは、暗号化保存していたものも復号鍵が同じ不正アクセスで読み出されたため、内容を知られた可能性があると説明されています。
暗号化は、鍵が守られて初めて機能します。データと鍵が同じ侵害範囲にあれば、暗号化の有無は結果を変えません。インシデント対応では「暗号化していた」という説明を鵜呑みにせず、鍵の保管場所が侵害範囲に含まれるかを確認する必要があります。今回はそれが含まれていたため、暗号化を根拠に影響なしと判断することはできません。
フォーム回答が含まれる場合の法令上の検討
問い合わせ、採用応募、資料請求、イベント申込などをStudioのフォームで受けていた場合、影響は自社の従業員にとどまらず、フォームに入力した社外の人にも及びます。Studioは、フォーム利用プロジェクトのオーナーに個別メールで案内しており、送信した本人には送信先サイトの運営者から案内がある場合があると述べています。つまり、エンドユーザーへの説明責任は、サイトを運営する企業側にも生じます。
個人情報保護委員会は、個人データの漏えい等が発生し個人の権利利益を害するおそれがあるときは、同委員会への報告と本人への通知が必要だとしています。報告は「速やか（概ね3〜5日以内）」に行うよう案内されており、不正の目的による行為が疑われる漏えいは、人数にかかわらず対象になり得ます。
ここからは制度の一般論を踏まえた整理です。自社サイトのフォームで取得した個人データは自社が取り扱う個人データであり、Studioはその取り扱いを担う事業者という位置づけになり得ます。そのため、Studioが報告した事実とは別に、自社として報告・本人通知の要否を検討する必要が生じます。起算点は「事態を知った日」です。Studioからの個別メールや第一報を受け取った時点が起点になり得るため、調査完了を待たずに判断を進めるのが安全です。実際の該当性はフォーム項目や件数、契約関係で変わるため、法務または弁護士に確認したうえで対応を決めてください。
便乗フィッシングへの注意と、続報の追い方
Studioは、本件に便乗して同社を装うメールやメッセージが送られる可能性があると注意を呼びかけ、パスワードや認証情報をメールや電話で尋ねることはなく、本件のメールに認証情報の入力を求めるリンクを含めることもないと明記しています。社内でこの点を共有し、Studioからの案内に見える連絡を受け取った担当者が独断でリンクを開かない運用にしておくと安全です。対応操作は、受信メールのリンクではなく、ブックマークや公式サイト経由で管理画面にアクセスして行うのが確実です。
対象件数や二次被害の調査結果は、同社の第一報ページで続報として更新されます。クライアントサイトを受託運用している制作会社は、この更新を定点観測し、誰がいつ何を切り替えたかを記録しておくと、後の説明や確報の作成が楽になります。
再発に備えて見直したい運用
今回の構図は、Studio固有というより、外部サービスに認証情報とフォーム回答を預ける運用に共通するものです。鍵が集まる場所が一度破られると、連携先すべてに影響が波及します。復旧後に次の点を見直しておくと、次回の初動が短くなります。
- APIキーの権限最小化。読み取りだけで足りる連携に書き込み権限を与えない。権限を絞るほど、流出時の被害上限が下がります。
- 定期的なキーのローテーションと棚卸し。どのサービスのキーをどこに登録したかの一覧がないと、緊急時に切り替え漏れが出ます。
- フォーム回答の保管場所と保持期間。管理画面に過去の回答を無期限に貯めるほど、漏えい時の影響件数は増えます。必要な期間を決めて削除・移管する運用に変えます。
- プレビューURLや共有リンクの管理。URLを知っていれば見られる仕組みは、公開前情報の置き場としては脆弱です。用が済んだら削除する前提で扱います。
- 委託先でインシデントが起きた場合の連絡・判断フロー。誰が一次受けし、誰が法務判断を行い、誰がクライアントへ連絡するかを事前に決めておきます。
結論
今回の公表は第一報であり、件数や二次被害の有無は調査中です。確定を待つ間にできる対応ははっきりしています。APIキーなど認証情報の切り替えを最優先で終わらせ、ライブプレビューURLを削除し、パスワードを変更したうえで、フォーム回答に含まれる個人情報の範囲を洗い出すこと。そのうえで、自社に報告・通知義務が生じるかを法務と確認し、続報を追いながら対応記録を残してください。
