Studioの不正アクセス、フォーム利用企業が確認する情報と最新案内

Studioの不正アクセスについて、利用企業が最初に行いたいのは、自社の対象プロジェクトと利用機能を把握し、Studioからの個別案内を確認することです。公式案内では、情報が第三者に取得された事実は確認できていないものの、取得されたものとみなして対応すると説明されています。

「漏えいがすべて確定した」「被害が確認されていないから何もしなくてよい」のどちらにも寄せず、公表された事実と必要な確認を分けてください。以下は2026年10月21日に確認した案内に基づく整理です。

公式に公表された経緯を確認する

発生と発見と対処の日付を分ける

Studioの案内では、確認できている不正アクセスの期間は2026年9月30日から10月1日とされています。社内の調査によって不正アクセスを確認したのは10月13日で、13日から14日に脆弱性の修正と経路を塞ぐ対応を行ったと説明されています。これらの日付は同じ意味ではありません。

社内で情報を共有するときは、アクセスを確認した期間、提供元が発見した日、対処した日、案内を確認した日を分けて記載します。例えば「10月16日に知った」ことを、その日に不正アクセスが発生したという説明にしないようにします。時系列が変わった場合に訂正できるよう、参照した公式案内も一緒に残してください。

取得の可能性と確認済みの事実を分ける

公式案内では、環境内のデータを外部から取得できる状態だったことと、実際に第三者に取得された事実は確認できていないことが説明されています。そのうえで、取得されたものとみなして対応するとされています。この区別を落とすと、社内や顧客への説明が公表内容より強くなったり、逆に対応を不要と誤解したりする可能性があります。

自社の資料でも、「公式に確認されたこと」「可能性として案内されていること」「調査中のこと」を分けます。攻撃者、詳しい原因、流出件数など、公表で確認できない情報を推測して補う必要はありません。自社側で別の不審な事象が見つかった場合も、今回の事案が原因だと先に断定せず、記録を保全して提供元や専門家へ確認します。

案内に含まれる情報の種類を把握する

流出した可能性のある情報として、アカウント情報、Studio上で管理するデータ、ライブプレビューのURL、外部サービスのAPIキーなどの認証情報が挙げられています。フォームの送信内容も含まれるため、Studioの契約者だけでなく、サイトで問い合わせや応募を受け付けていた会社にも確認すべき点があります。

ただし、すべての会社が同じ機能を利用し、同じ種類の情報を保存しているとは限りません。自社の対象を判断するため、利用機能と保存していた情報を対応させます。今回の整理では、件数を創作したり、公開された項目だけから自社の全社員・全顧客が対象だと決めたりしないことが重要です。

自社で案内を確認する窓口を決める

オーナーへのメールと画面の案内を見る

Studioの公式ポータルでは、対象プロジェクトのオーナー権限を持つメールアドレスへの連絡や、ログイン時の画面上の案内を確認するよう説明されています。日常のサイト担当者がそのメールを受け取る立場とは限らないため、オーナーを誰が管理しているかを最初に確かめてください。

制作会社や以前の担当者が管理している場合は、必要な個別案内を受け取っているか確認します。メールが見つからないことだけで対象外と判断しないようにします。公式の窓口へ問い合わせる場合は、対象プロジェクトと自社が把握している利用状況を整理し、パスワードやAPIキーの値そのものを本文へ貼り付けないでください。

会社のサイトと利用機能を一覧にする

代表サイトのほかに、採用ページ、キャンペーン、別事業のサイトをStudioで運用していないかを確認します。一覧にはプロジェクト名、サイトの用途、管理担当、フォームや外部連携の利用有無を記載します。事業や担当部署が違うと、同じ会社の中でも情報が分かれている場合があります。

すべての機能を最初から詳しく調べ切ることよりも、どの項目を誰へ確認すればよいかを見えるようにするのが目的です。使っていない機能、使っている機能、まだ分からない機能を分けてください。画面から確認できない情報がある場合は、導入時の資料や提供元への照会で補い、不明なまま対象外へ分類しないようにします。

社内の連絡を一つの記録にまとめる

制作会社、サイト担当、経営者が別々に情報を集めると、古い案内や途中の作業結果が混ざりやすくなります。確認した日時、案内の版、依頼した作業、担当者からの回答、次に確認する相手を同じ記録にまとめると、どこまで進んだかを共有しやすくなります。

ただし、関係者全員に回答データや認証情報を広く共有することが目的ではありません。対象を識別する情報と確認状況を中心にし、個人情報や秘密情報は必要な担当だけが適切に扱います。小さな会社で専任部署がなくても、窓口と最終判断をする責任者を決めておけば、連絡の重複や対応漏れを減らせます。

利用機能ごとの対応を照合する

パスワードとプレビューの案内を読む

公式案内では、メールアドレスとパスワードでStudioへログインする利用者にパスワード変更を求めています。GoogleまたはFacebookログインのみを利用し、Studioのパスワードを設定していない場合は、この対応は不要と説明されています。使い方による違いを確認せず、社内全員へ同じ操作を求めないことが大切です。

ライブプレビューのURLを発行している場合は、削除と、引き続き共有が必要なら再発行の案内があります。プレビューが侵入原因だったと公表されたわけではないため、そのような因果関係は付け足しません。現在共有している相手や確認中のページへの影響を担当者と整理し、正規の手順に沿って対応します。

APIや通知の連携を種類別に分ける

API連携、Googleスプレッドシート連携、カスタムプロキシ、Webhook通知には、それぞれ異なる案内があります。制作会社に「連携を直してください」とだけ依頼するのではなく、どの機能について、誰が設定を変更し、誰が動作を確認するかを分けてください。

特に、外部サービスが発行する認証情報と、Studioが発行するカスタムプロキシのキーは、発行元や停止の担当が異なります。新しい設定で動いたことと、古い認証情報が使えなくなったことも別の確認です。具体的な機能操作や期限は、更新される公式案内と個別メールを照合し、不明点を提供元へ問い合わせます。

フォーム回答は保存状況から判断する

フォームについては、Studioに保存されていた回答が対象として説明されています。ゴミ箱、テスト、表示上限の扱いや、完全削除した時期、外部フォームへの直接送信などによって確認する範囲が異なります。画面に見える件数だけで判断せず、公式案内の条件と自社の保存状況を照合してください。

外部へ通知していることと、回答がStudioを経由せず外部フォームへ直接送信されることは同じとは限りません。どこへ保存される仕組みかを制作会社に確認します。対象範囲を調べるために、顧客の回答を不用意に別のツールへコピーすることは避け、必要な情報を絞って調査を進めます。

初動を整理して続報へつなぐ

便乗した不審な連絡に注意する

今回の案内に便乗した不審なメールやメッセージにも注意が必要です。Studioは、パスワードや認証情報をメールや電話で尋ねることはなく、本件の連絡メールにも、それらの入力を求めるリンクを含めないと説明しています。受け取った連絡は、正規の案内や窓口から確認してください。

社内には、心当たりのないリンクや添付を開かず、不審な連絡を受けたときの報告先を伝えます。今回の公式案内の特徴として共有し、あらゆるサービスで同じ連絡方法が使われると一般化しないことも大切です。既に何か入力した場合は、入力した内容と時点を責任者へ伝え、必要な対応を判断します。

技術対応と報告や通知を分ける

認証情報の変更が終わったことと、過去のデータへの影響を調査したことは別です。また、個人情報保護委員会への報告と、サイト利用者本人への通知も同じ手続きではありません。最新の公式案内を読み、どの手続きに関する説明かを区別して確認してください。

自社の責任者へは、取得した情報、保存状況、対象として考えられる範囲、まだ不明な点を整理して渡します。必要な報告や通知は個別の事情に応じて専門家へ確認し、人数が少ないことや、サイトが現在表示されることだけで不要と決めないようにします。ここでは、個別企業の法的判断を代わりに行うものではありません。

完了した作業と調査中の事項を残す

確認表では、実施済みの作業、提供元への問い合わせ中の項目、調査の続報を待つ事項を分けます。すべてを一括して「対応完了」にすると、後から追加された案内が見落とされやすくなります。更新情報を確認する担当と、自社の一覧へ反映する方法も決めてください。

今回の対応を機に、フォームで集める情報、保存する目的、外部連携の管理者を整理することも考えられます。ただし、今後の改善と今回の調査を混ぜ、必要な記録を先に削除してしまわないようにします。まずは公表された条件と自社の利用状況を揃え、分からない部分を残したままにしないことが、次の判断の土台になります。