暗号化されていたのに、なぜ漏れたことになるのですか？
暗号化して保存していたなら、外部から侵入されても中身は読み取れないはずではないか。そう思いたくなりますが、暗号化は鍵が守られているあいだだけ働く守りです。鍵を手にした人は、暗号化されたデータを元の文字に戻せます。
Studioの件では、フォームの送信内容などを暗号化して保存していたものの、元に戻すための鍵まで同じ不正アクセスで読み出されていました。データと鍵の両方が外に出たかもしれないため、暗号化されていても内容を知られた可能性が残ります。Studioの不正アクセスに関するお知らせでも、これらのデータについて「漏えいした可能性がある」と案内されています。
なお、第三者が実際にデータを取得した事実は確認されていませんが、10月14日にStudioが対処するまでは環境内のデータを外部から取得できる状態が続いていたため、Studioは取得されたものとみなして対応しています。
Studioのどのデータが暗号化され、どのデータがハッシュ化されていたのですか？
暗号化とハッシュ化は、どちらも「そのままでは読めない形にして保存する」方法なので、同じものだと受け取られがちです。ただ、今回の件では保存のしかたによって、利用者がやることも変わります。
Studioは、暗号化して保存していたものとして、フォームの送信内容や、Data Connect API・API連携（Beta）の設定に登録された外部サービスのAPIキー・トークン、スプレッドシート連携の認証情報、プロキシキー、reCAPTCHAの設定、WebhookのURLを挙げています。暗号化して保存していたものについても、復号に必要な鍵が同じ不正アクセスで読み出されたため、内容を知られた可能性があります。
これに対して、利用者のログインパスワードや、サイトの閲覧を制限するパスワード保護機能で設定したパスワードは、ハッシュ化されて保存されていました。ハッシュ化は一方通行の計算処理で、暗号化と違って鍵で元に戻す仕組みではありません。Studioは、ハッシュから元のパスワードを割り出すのは困難だが完全には否定できないとして、変更を求めています。
| データ | 保存のしかた | 利用者がすること |
|---|---|---|
| フォームの送信内容 | 暗号化 | Studioからの個別案内を確認する |
| 外部サービスのAPIキー・トークン | 暗号化 | 発行元で新しいキーを発行し、Studioの設定を更新してから古いキーを失効させる |
| Studioアカウントのパスワード | ハッシュ化 | パスワードを変更する |
| パスワード保護ページのパスワード | ハッシュ化 | 新しいパスワードを保存し、サイトを更新する |
パスワード保護ページを設けている場合は、管理画面で新しい文字列を入力して保存し、サイトの更新公開を済ませたうえで閲覧者へ新しい合言葉を伝えます。
ハッシュ化パスワードなら、変更しなくても大丈夫ですか？
暗号化なら鍵で戻せるけれど、ハッシュ化は元に戻せない。だから変えなくてもいいのでは、と考える人もいるでしょう。ここは変えておくのが正解です。
ハッシュ化されたパスワードからは元の文字列を直接は計算できませんが、別の方向から当てにいく攻撃があります。よく使われるパスワードの一覧を同じ方法でハッシュ化し、盗んだ値と照らし合わせて一致するものを探すやり方です（パスワード保存の仕組み）。単語ひとつだけのパスワードや、誰でも思いつくフレーズ、キーボードを順に押しただけの並びは、こうした方法ですぐに見つかってしまいます。
Studioと同じパスワードをほかのサービスでも使っているなら、そちらも変えておきましょう。万が一照合によって文字列が突き止められた場合、メールや通販サイトなど無関係なアカウントへ不正にログインされる二次被害へつながります。
もっとも、GoogleやFacebookのアカウント連携だけでログインしていて、Studio専用のパスワードを一度も設定したことがない人は変更の対象外です。ただし、以前にメールアドレスとパスワードで登録やログインをしたことがあると、パスワードが残っている場合があります。心当たりがあれば、アカウント設定からパスワードの変更を試してください。パスワードが設定されていれば変更でき、未設定ならエラーが出ますが、その場合は追加の対応は不要です。
暗号化していたなら、個人情報保護委員会への報告は不要になりませんか？
「暗号化を施していたのであれば、個人情報保護法に基づく監督官庁への報告義務は免除されるのではないか」という疑問を持つ人もいるでしょう。確かに法令の運用上、高度な暗号化によって高度な秘匿性が保たれていれば、報告を要しない例外規定が設けられています。ただ、暗号化していたという事実だけで、この例外に当てはまるわけではありません。
例外として扱うには、2つの条件がそろっている必要があります。ひとつは、第三者が読める状態に戻すのが難しい技術的な措置をとっていること。もうひとつは、そうした措置をとった情報を読める状態に戻すための手段が適切に管理されていることで、暗号化した事実だけでは足りないとされています（暗号化と報告の例外に関するQ&A）。
Studioの件では、復号に必要な鍵も同じ不正アクセスで読み出されていました。2つ目の条件を満たしていたとは言いにくい状況でしょう。Studioの事案について、例外にあたるかどうかの最終的な判断が公表されたわけではありませんが、暗号化を理由に「報告はいらない」とする話にはなりにくいはずです。
また、個人情報保護委員会の報告基準において、外部からの不正アクセスのような悪意ある行為に伴う事案は、人数の多寡に関わらず重大な事態と位置づけられています。1,000人を超える漏えいだけでなく、不正の目的による行為で個人データが漏えいした、またはそのおそれがある場合は、人数にかかわらず報告の対象になります。
報告の期限も決まっています。最初の報告にあたる速報は、事態を知ってから概ね3〜5日以内に出します。そのあとの確報は原則30日以内ですが、不正な目的のおそれがある場合は60日以内です。60日あるからといって、最初の報告まで待ってよいわけではありません。
Studioは暗号化の問題にどう対応しましたか？
鍵が読まれたなら、Studioは鍵を替えたのか。気になる人は多いと思います。答えは、替えています。
Studioは2026年10月17日、フォームの送信内容や外部サービスのAPIキーなどを暗号化する鍵を、新しいものに切り替えました。その一方で、外部サービスのAPIキーやトークンは発行元のアカウントで管理されているため、Studio側の作業だけでは利用を停止できない仕組みになっています。そのため利用者自身が外部サービス側で新しいキーを発行し、Studio側の設定欄を更新したあとで、古いキーを失効させる手順を踏む必要があります。順序を取り違えて古いキーを先に消してしまうと、外部サービスとの通信が途切れてしまう点には配慮が必要です。
問い合わせの着信を知らせる設定についても、Studioの不正アクセスに関するお知らせでは、新しい受信用URLを取得し、テスト送信を確かめてから古いURLを無効にする順で切り替えるよう案内されています。SlackのIncoming Webhookのように、発行されたURLにデータを送るだけで外部サービスへ投稿できる仕組みは、URLそのものが合言葉の役割を持つからです。逆の順にすると、通知が届かなくなります。
国の側では、デジタル庁が2026年10月16日、第三者の不正アクセスによってクラウド環境内のデータを外部から取得できる状態になっていたとの報告をStudioから受けたと公表しています（デジタル庁の公表）。