Studioの不正アクセスで何を点検する？フォーム回答と外部連携の対応を整理

Studioは2026年10月16日、利用するクラウド環境への不正アクセスにより、顧客情報などが流出した可能性を公表しました。10月18日までの更新では、フォーム回答の対象範囲や外部連携の対応も説明しています。サイトが現在表示されることと、過去に保存した情報や連携先の安全を確認できることは別の課題です。

本稿は10月20日に確認した一次資料に基づき、制作会社とサイト運営者の対応を整理します。確認された不正アクセスの期間、発見日、初回公表日を分け、実際のデータ取得が確認されていない事項を流出確定とは扱いません。以下の確認票や作業の組み立ては本サイトの提案です。AIを使った攻撃とする根拠は確認していません。

出典：Studio：不正アクセスによる情報流出に関するお詫びとお願い

経路の修正と利用者側の対応を分ける

公式発表によると、確認された不正アクセスは9月30日から10月1日で、10月13日に発見し、13日から14日に脆弱性と侵入経路へ対処しました。外部からデータを取得できる状態があり、実際の取得は確認できないものの、取得されたものとみなして対応しています。

運営者が区別したいのは、提供元が実施する侵入経路の修正と、自社が保有する連携情報や顧客対応です。前者が完了しても、既に知られた可能性のある秘密を第三者の手元から消すことはできません。サイトの稼働確認だけで作業を閉じず、保存データと接続先の確認を別の担当へ割り当てます。

出典：Studio：不正アクセスによる情報流出に関するお詫びとお願い

最初にプロジェクトとフォームを棚卸しする

影響確認の単位は会社名だけでは足りません。自社サイト、採用ページ、イベント用LP、公開を終えたキャンペーンなど、Studio上に残るプロジェクトを列挙します。制作会社が所有しているもの、顧客へ移管済みのもの、担当者が退職したものを区別し、管理者へ連絡できる状態にします。

公式発表ではStudioに保存されたフォーム回答が対象となり、完全削除していないゴミ箱内やテスト回答なども含まれます。一方、外部フォームの埋め込み回答など、対象に含めない条件も示されています。「今ダッシュボードに見える回答」だけを母数にせず、保存設定と利用期間を対応させることが重要です。

棚卸しの記録は、プロジェクト名、公開ドメイン、フォーム用途、保存設定、利用期間、情報の種類、責任者に絞ります。確認のために回答の全文を共有表へ複製すると、事故対応の資料に新たな個人情報が集まります。原本へのアクセスを限定し、対象範囲を判断できる情報を必要最小限だけ残してください。

出典：Studio：不正アクセスによる情報流出に関するお詫びとお願い

暗号化済みという説明だけで対象外にしない

Studioは、一部の保存情報では復号に必要な鍵も同じ不正アクセスで読み出され、暗号化していた内容も知られた可能性があると説明しています。これは、暗号化という語だけから今回のデータを安全と判断できないことを示します。ただし、対象の保存方式を自社で推測し、すべてが平文保存だったと言い換えてはいけません。

一般的な設計の見直しでは、データを読む権限と復号用の鍵を利用する権限が、同じ管理経路で一度に取得できないかを検討します。運営者がSaaS内部の方式を直接変更できない場合でも、保存する項目、保存期間、外部へ渡す秘密の権限は選べます。提供元への確認と自社側の削減策を分けて考えます。

出典：Studio：不正アクセスによる情報流出に関するお詫びとお願い

外部連携は接続先ごとの作業にする

公式案内は、API連携に登録したキーやトークンの切り替え、Webhook通知先URLの切り替えなどを求めています。Googleスプレッドシート連携、カスタムプロキシについても固有の手順があります。アカウントのパスワードを変更したことを、外部サービスの認証情報まで更新した証拠にはできません。

本サイトでは、接続先、資格情報の用途、発行者、許可操作、交換担当、旧情報の無効化方法を一覧にすることを勧めます。秘密そのものは一覧へ書きません。顧客が発行したキーを制作会社が交換できない場合は、依頼先と作業待ちの状態を明示し、連絡を送っただけで完了にしないでください。

切り替えは接続先の手順に従います。新しい情報を登録し、必要な読み書きが成功することを確認して、旧情報の失効を確かめます。ただし、悪用中と判断される場合は停止を先に行うなど、継続性より封じ込めを優先する判断が必要です。無効化の順序を全サービスで同一に決め付けないことが大切です。

出典：Studio：不正アクセスによる情報流出に関するお詫びとお願い

プレビューと保護ページも共有経路として確認する

StudioはライブプレビューURLの削除と、引き続き必要な場合の再発行を案内しています。パスワード保護ページの利用者には、パスワード変更も求めています。プレビューは未公開だから影響しない、検索結果に出ないから秘密のままと考えるのではなく、リンクを知る人が何を閲覧できるかで点検します。

たとえば公開前の製品ページを代理店と共有していた場合、URLを再発行する作業と、旧リンクを含むメールや資料の扱いを分けます。新しいリンクを広い宛先へ再送する前に、現在も閲覧が必要な関係者だけを選びます。これは説明用の仮想例であり、今回特定の未公開情報が閲覧された事実を示すものではありません。

出典：Studio：不正アクセスによる情報流出に関するお詫びとお願い

フォーム停止の判断は目的と代替経路を添える

問い合わせの受付を止めるかは、サイト全体の公開を止めるかとは別の判断です。提供元の現在の案内、残っている不確実性、フォームで集める情報の重要性を踏まえます。受付を継続する場合も、不要な生年月日や詳細な相談内容などを見直し、事故対応の最中に追加の情報を集めない設計を検討できます。

仮想例として、採用応募フォームを一時停止し、問い合わせ先だけを別の場所へ出す場合を考えます。そのメールボックスの閲覧権限、添付ファイルの扱い、受信容量も確認が必要です。フォームの代わりに個人の無料メールへ送ってもらうだけでは、情報の管理場所を把握しにくくなります。

代替経路を設けたら、元のフォームから送信できないこと、案内先が正しいこと、内部で受信担当へ届くことを実際に確認します。テストには架空の情報を使い、本番の個人情報を検証用に再送しないでください。停止したままのページには、更新予定や正規の案内先を残すと利用者が迷いにくくなります。

顧客への説明は確認済みの範囲から書く

制作会社が最初に渡す説明は、提供元の公表日、自社で使っていた機能、確認できた保存範囲、実施済み作業、未完了項目を分けると読みやすくなります。提供元が調査中としている件数や被害を、自社の推測で確定しません。影響がないという結論も、埋め込み先や保存設定などの根拠を添えます。

個人情報に関する報告や本人への連絡が必要かは、扱った情報と契約上の役割に基づき責任者が確認する事項です。Studioの第一報だけから、利用者全員に同じ報告義務がある、あるいは報告不要と結論付けないでください。最新の公式案内を確認し、必要に応じて自社の法務や相談窓口へつなぎます。

本稿では、別ページで更新される報告手続きの内容を確認できたものとして代わりに断定しません。提供元からの個別メールがある場合は、契約者が正規の管理画面などから照合します。第三者が転送したメールのリンクだけで、認証情報の入力や顧客データの提出を行わない運用にしてください。

複数サイトを扱う制作会社での進め方

同じ担当者が複数顧客のプロジェクトへ参加している場合、ひとつの変更を全件の対応と数えないようにします。たとえばアカウントのパスワード変更は担当者単位ですが、フォーム保存範囲はプロジェクト単位、外部APIキーは接続先の契約単位です。作業の単位を分ければ、対応漏れと不要な変更の両方を減らせます。

引き継ぎ時には、顧客が発行した資格情報を制作会社側で勝手に削除しないようにします。影響する定期処理と連絡先を確認し、正規の権限を持つ担当へ切り替えを依頼します。緊急停止が必要な場合も、停止理由と停止した機能を伝え、後でどの接続を戻すか判断できるよう記録します。

顧客ごとの票を一枚の一覧へまとめるなら、秘密や回答を入れず、進捗と責任者だけを集約します。担当者間の共有には個人のチャットではなく、閲覧者を管理できる場所を使います。対応資料の保存期限も決め、事故対応が終わった後に顧客情報の複製だけが残る状態を避けてください。

対応完了は失効と動作確認を組み合わせる

完了条件の例は、必要なキーの交換と旧情報の失効、旧プレビューURLの無効化、最小権限での再接続、フォームの受付確認、顧客への説明担当の決定です。一覧に作業日だけを記録するより、何を確かめたかまで残すと引き継ぎに使えます。例外には期限と責任者を付けます。

OWASPの秘密管理資料も、秘密の生成、交換、失効、有効期限を異なる段階として扱っています。本件への具体的な適用は接続先の仕様とStudioの個別案内を優先します。交換した新しいキーをメール本文やチケットへ貼り付けず、作業票には参照先と確認結果を記載する方法を提案します。

動作したことは、権限が適切である証明とは限りません。連携が必要な一つのデータだけを読めるか、不要な書き込みまで許していないかを確認します。以前の接続設定をそのまま復元するより、継続して必要な処理を決めてから権限を戻す方が、再開後の管理を続けやすくなります。

出典：OWASP：Secrets Management Cheat Sheet

次の更新まで残す確認事項

今回の公表では、対象範囲や件数、二次被害、原因の詳細に調査中の事項が残ります。提供元が経路を塞いだことと、全調査が終了したことを同義にしないでください。自社の対応票にも、確認済み、未確認、提供元の続報待ちを区別して残します。

継続確認の担当と次の確認日を一つ決め、続報が出たときに契約者、制作会社、情報管理担当が同じ資料を参照できるようにします。SaaSを使うことでサーバーの保守を任せられても、自社が預けた回答や外部接続の責任範囲は残ります。今回の対応を、保管する情報と接続を減らす運用へつなげることが重要です。