全顧客が対象だった。外部サービスの鍵は、自分で替えるしかない
公式のFAQが詳しくなっていました。替えてもらえる鍵と、自分で替えるしかない鍵があります。順番を間違えるとサイトが止まります。

この記事の結論
- 対象は登録しているすべての顧客。公式がそう書いている
- 外部サービスのAPIキーは、Studioでは無効化できない
- 古いキーを先に失効させると、サイトの連携が止まる
- 対象は登録しているすべての顧客。公式がそう書いている
- 外部サービスのAPIキーは、Studioでは無効化できない
- 古いキーを先に失効させると、サイトの連携が止まる
Studioの不正アクセスについて、公式のFAQがかなり詳しくなっていた。
これまでこのサイトでは鍵の置き場所と報告の義務を書いた。今回は手を動かす作業の話になる。
順番を間違えるとサイトが止まるので、そこを中心に整理する。
まず、対象の広さ
公式の書き方はこうだ。
Studioにご登録いただいているすべてのお客様について、以下の情報が外部に流出した可能性があります。
一部ではない。登録していれば対象になる。
挙げられている内容は4つに分かれる。
- アカウントの情報 — ユーザー名、メールアドレス、ハッシュ化されたパスワード
- Studio上で管理しているデータ — デザインエディタとCMSの内容、フォームに送信された内容、reCAPTCHA の設定、Webhook の通知先URL
- ライブプレビューのURL — 公開前のページを確認するためのもの
- 各種設定に含まれる認証情報 — 外部サービスのAPIキーやトークン、パスワード保護ページのパスワード、Googleスプレッドシート連携の認証情報、カスタムプロキシのキー
4番目が今回の本題になる。
暗号化していたのに、なぜ知られうるのか
公式が理由を明記している。
暗号化して保存していたものについても、復号に必要な鍵が同じ不正アクセスで読み出されたため、内容を知られた可能性があります。
5日前に鍵がデータと同じ場所にあった件として書いた話が、FAQでも同じ説明になっている。
金庫と鍵が同じ部屋にあれば、金庫は意味を持たない。
書き換えもできる権限が含まれていた
これは報道で見かけなかった。
第三者が取得した認証情報には、データを書き換えることができる権限も含まれていました。
ただし続きがある。操作の記録を調べた結果、デザインエディタやCMSの内容を書き換えたり削除したりした記録は無いことを確認した、とされている。
読む側としては「できた」と「された」を分けて受け取る。できる状態だったのは事実で、された記録は無い。調査は続いている。
替えてもらえる鍵と、自分で替える鍵
ここがいちばん大事だと思った。Studio側で片づく分と、片づかない分がある。
| 対象 | 誰が替えるか |
|---|---|
| Studioが使う認証情報(決済・ログインを含む) | Studio側で切替済み |
| 暗号化に使う鍵 | 10月17日に切替済み |
| カスタムプロキシのキー | Studioが新規発行済み |
| 外部サービスのAPIキー・トークン | 自分で替える |
| パスワード保護ページのパスワード | 自分で変える |
| Studioのパスワード | 自分で変える |
理由も書かれている。
外部サービスのAPIキーやトークンは発行元のサービスで管理されているため、弊社では無効化できません。
当然ではあるが、見落としやすい。Studioが「切り替えました」と言っても、自分の分は残っている。
古い鍵がまだ残っている点
正直に書かれているので拾っておく。
古い鍵は、切り替える前に保存されたデータを読み出すためだけに残しており、新しく保存されるデータには使用しておりません。現在、これらのデータを新しい鍵で暗号化し直す(古い鍵を廃止する)作業を進めております。
そして、もっと重要な一文がある。
弊社で鍵や認証情報を切り替えても、不正アクセスの時点で取得された可能性のある情報を守ることはできません。
すでに出たものは戻らない。切り替えは、これから先の悪用を止めるための作業になる。
作業の順番を間違えない
公式が順番を指定している。ここは本当に効く。
- 各サービス(microCMS・Notionなど)で新しいキーを発行する
- Studioの設定を新しいキーに更新する
- 各サービスで古いキーを失効させる
そして、こう念を押されている。
古いキーを先に失効させると、サイトでの連携が止まる場合がありますのでご注意ください。
慌てていると、つい「まず古いのを止めよう」と考える。それをやるとお客様のサイトが先に壊れる。
急いでいる場面で順番を間違えるのは、よくある。先に手順を読むという、それだけの話になる。
使っていないキーも対象
見落としやすい点が添えられている。
現在は使っていない外部サービスのキーが登録されている場合も、各サービスで失効させることをおすすめいたします。
昨日書いた福岡市の件でも、消防局が契約終了後も削除されていなかったデータで対象になっていた。使い終わったものが、いちばん忘れられる。
やっておきたい確認
切り替えと別に、見る作業がある。
各サービスの利用履歴などで、2026年9月30日以降に心当たりのない利用がないかご確認ください。
9月30日は不正アクセスが始まったとされる日だ。
APIキーが使われていれば、外部サービス側に記録が残る。Studio側では見えない部分なので、ここは自分で見るしかない。
ライブプレビューのURLも消す
公開前のページを確認するためのURLが対象に入っている。
公式は「直接特定されたことは確認していないが、可能性を完全には否定できない」として、削除を依頼している。引き続き共有が必要なら、削除してから発行し直す形になる。
未公開の制作物が外から見られる状態は、受託だと説明が難しい。ここは早めがいい。
本物の連絡を見分ける材料
公式が条件を出している。これは助かる。
- 送信元は @studio.design または @studio.site
- 本件の連絡にパスワードや認証情報の入力を求めるリンクは含まれない
- ログイン画面のURLは app.studio.design
昨日書いた阪急阪神百貨店の件でも、正規の送信元アドレスが明示されていた。本物の条件を先に出すのは、いま増えてきた良い形だと思う。
アカウントが無い人にも連絡が行っている
これは知らないと驚く。
2022年12月から2023年8月にかけて募集していた「Studio AI」(当時の名称は「Auto」)の先行利用に申し込んだ人にも連絡が行っている。
対象はメールアドレス、ユーザー名、申し込み時の接続元から判定された居住国。パスワードや支払いの情報は預かっていないため、対応は不要とされている。
3年以上前の申し込みフォームのデータが残っていたということになる。ここは作る側としても考えさせられる。
やることの順番(まとめ)
- Studioのパスワードを変える(Google・Facebookログインのみなら不要)
- 同じパスワードを使っている他サービスも変える
- 外部サービスのAPIキーを、新規発行 → Studio更新 → 旧キー失効の順で替える
- パスワード保護ページのパスワードを変える
- ライブプレビューのURLを削除する
- Webhook の通知先URLを切り替える
- 各サービスの履歴で、9月30日以降の不審な利用を見る
- フォームを使っているなら、報告と通知を検討する(連名報告の話)
対象のプロジェクト名は10月16日に機能ごとに送られた個別メールに書かれている。件名は「【重要】不正アクセスに伴う、」で始まる。見当たらない場合は迷惑メールも確認する。
まとめ
- 対象は登録しているすべての顧客
- 暗号化していた分も鍵が一緒に読まれたため、内容を知られた可能性がある
- 書き換えができる権限も含まれていた。ただし書き換えの記録は無い
- Studio側の鍵は切替済み。10月14日には全員を一括ログアウトしている
- 外部サービスのAPIキーはStudioでは無効化できない
- 順番は新規発行 → Studio更新 → 旧キー失効。逆にすると連携が止まる
- 使っていないキーも失効させる
- 9月30日以降の利用履歴を各サービスで確認する
- 本物の送信元は@studio.design / @studio.site。ログインは app.studio.design
出典
- Studio「Studioにおける不正アクセスに関するご案内」(よくあるご質問。対象の範囲、流出した可能性がある情報、暗号化の鍵、書き換え権限、鍵の切り替え状況、キー切り替えの手順、ライブプレビュー、本物のメールの見分け方、Studio AI 先行利用者への連絡。2026年10月21日に確認)
- Studio「フォーム機能をご利用のお客様へ:個人情報保護委員会へのご報告についてのご案内」(2026年10月20日の続報)
本記事は2026年10月21日時点の公表内容に基づく。原因の詳細な調査と再発防止策は、外部の専門機関に依頼して進める段階とされており、続報で内容が変わる可能性がある。実際の対応は、自分のプロジェクト宛に届いた個別の案内と公式のFAQで確認すること。本記事は法的な助言ではない。
新しい記事が出たら、ブラウザの通知でお知らせします。
メールアドレスの登録は要りません。いつでも止められます。
関連記事
RELATED
Laravelの認証回避、直した版は8月に出ていた。「いつも通り更新していた」サイトは守られていた
PHPのフレームワーク「Laravel」の標準のAPI認証「TokenGuard」で、トークンを知らなくても他人として認…
危ないのは「圧縮する側」ではなく「展開する側」。Brotliの穴で、Node.jsなどが更新
Webでよく使われる圧縮形式「Brotli」の展開処理に、メモリを壊して遠隔からプログラムを動かされるおそれのある穴が見…
第5報で順番が変わった。「まず自分のパソコンを確かめて」の意味と、やり方
「お名前.com デスクトップクラウド」の第5報で、手元のパソコンのフルスキャンとバックアップが「予防的措置」から「至急…