移行すれば、今回流出した情報のリスクはなくなりますか？
「サイトをまるごと別のサービスへ移せば、今回の件とはもう関係なくなるのでは」と考えたくなる気持ちはわかります。けれども、移行しても今回のリスクは消えません。
Studioの事案お知らせによると、2026年9月30日から10月1日にかけて不正アクセスがあり、10月14日にStudioが対処するまで、データを外部から取得できる状態が続いていました。実際に取得されたことは確認されていません。それでもStudio自身は、取得されたものとみなして対応を進めています。外へ出た可能性のあるコピーは、サイトの置き場所を変えても手元には戻りません。公的な機関の動きとしても、デジタル庁の注意喚起において個人情報漏えいの可能性が公表され、二次被害は確認されていないとしつつ、関係機関を装う不審な連絡への警戒が呼びかけられました。
外部サービスのAPIキーやトークンも、移行では片づきません。Studio側では無効にできないため、発行元のサービスごとに新しいキーへ切り替え、古いキーを失効させる作業が残ります。個人情報保護委員会への報告や本人への通知も同じです。こちらは移行したかではなく、漏れた可能性のある個人データの内容と法令上の条件によって決まります。
とはいえ、移行先の設計によって、問い合わせの回答をメールやチャットへ転送し、サーバー上に長く残さない仕組みを整えることは可能です。将来のデータ蓄積を減らす備えにはなりますが、過去に扱った情報への影響は別に点検しなければなりません。
移行とは別に、漏えいした可能性のある情報について何をすべきですか？
移行の準備とは並行して、今回の件そのものへの手当てを進めます。やることは次の5つです。
- Studioのパスワードを変え、同じパスワードを使い回している他のサービスも変更する（GoogleやFacebookのログインだけで、Studioのパスワードを設定していない人は不要）
- 外部サービスのAPIキーとWebhook URLを、新規発行、Studio側の設定更新、発行元での旧情報の無効化の順に切り替える
- スプレッドシート連携をStudioで解除し、Googleアカウント側でもStudioへのアクセス権を削除する（使い続けるなら再連携）
- カスタムプロキシを使っている場合は、新しいキーへ差し替えたうえで、Studioに旧キーの無効化を依頼する
- フォームで受け取った個人データと影響の範囲を確かめ、報告と本人通知の要否を決める
キーの切り替えでは順番が大事です。古いキーを先に止めると、サイトの連携や通知が途中で止まってしまいます。カスタムプロキシの旧キーの無効化を頼む期日は、2026年10月16日にStudioから届いたメールの受信から30日以内です。依頼には対象のStudioサブドメインを添えれば足り、キーそのものを送る必要はありません。
報告については、漏えいが確定していなくても、不正アクセスによる「おそれ」の段階で漏えい等の報告制度の対象になり得ます。
移行後もStudioに残るデータはどうすればよいですか？
別のサーバーへサイトを移し終えたあと、これまでStudioに保管してきたデータやプロジェクトをどう片付ければよいか迷うところですね。ただ、フォーム回答やプロジェクトは移行しても自動では消えないので、片づけ方を決めておきます。
フォーム回答は、消す前に保存しておきます。回答一覧画面の右上にある3点メニューから、すべての回答をCSV形式でダウンロードできます。今回の件で事実関係や影響の範囲を調べるときにも、この記録があれば困りません。保管期間や、委託契約で決まっている条件も合わせて確かめておきましょう。
問い合わせフォームで受け取った回答データを完全に消去するには、二段階の操作を踏みます。回答一覧で対象のステータスをゴミ箱へ変更したあと、ゴミ箱タブを開いて対象を選び、完全に削除を実行する流れです。ゴミ箱へ入れただけでは保管状態が解かれない点に気を配ります。手順はフォーム回答の削除手順で確認できます。
一方、プロジェクトそのものは完全には削除できません。プロジェクトの削除可否のとおり、できるのはアーカイブで一覧から隠すことと、サイトを非公開にすることまでです。「不要なプロジェクトを消して終わり」とはいかないため、非公開にしたうえでフォーム回答を消す形になります。
また、外部連携に利用していたAPIキーやトークンも、設定画面の入力欄を空にするだけでは無効になりません。発行元の管理画面側で古い鍵を失効させなければ、通信権限が生きたまま残ってしまいます。
Studioから移行してもURLをそのまま使えますか？
他の制作サービスやレンタルサーバーへ乗り換える場合、これまで運用してきたWebサイトのURLをそのまま維持できるでしょうか。訪問者のブックマークや配布物の印刷もあるため、アドレスが変わるかどうかは大きな関心事ですね。
独自ドメインを接続して運用していたサイトであれば、移転先でも同じURLを継続して使えます。新しいホスティング環境で同じHTTPS通信、同じホスト名、同じページパスを整え、ドメインのDNS参照先を新しいサーバーへ向ければ、訪問者から見たアドレスは一切変わりません。逆に、example.studio.siteのようなStudio提供のサブドメインは他社へ持ち出せないため、このアドレスを使っていた場合は移転に伴ってURLが変更されます。違いはドメインの継続利用の表で見比べられます。
StudioのCMSで作成した動的ページは、設定したパスと各記事のスラッグを組み合わせてURLを構成する仕組みです。スラッグは作成時に自動生成されますが、任意の文字列へ書き換えることもできます。気をつけたいのは、スラッグだけ合わせても、ドメインやパスが違えばURLは別物になることです。ドメインからスラッグまで全体を同じにできれば、移行のためのリダイレクトは要りません。
どうしてもURLが変わる場合は、旧URLと新URLの対応表を作り、旧URLから新URLへ301や308のような永続的なリダイレクトをかけます。
URLを変えない移行では、DNSの切り替えを早く反映させる工夫もできます。移行の少なくとも1週間前に、TTL（DNSの情報を覚えておく時間）を数時間ほどへ下げておくやり方です。
Studioから移行しても被リンクの評価は引き継げますか？
引き継げます。URLを変えなければ、外部サイトから張られたリンクの行き先は、移行後も同じページのままです。URLが変わる場合についても、旧URLから新URLへ301などの永続的なリダイレクトをかければPageRankの損失は生じない、とGoogleは説明しています。
でも、リダイレクトの設定しだいで結果は変わります。GoogleのURL変更を伴う移転の手順をもとに、押さえる点は次のとおりです。
- 旧URLと新URLを1対1で対応させ、転送先は最終的なページに直接つなぐことが勧められている（リダイレクトの連鎖を作らない）。
- 多数の旧URLを関連の薄いトップページへまとめて飛ばすと、soft 404として扱われることがあるとURL変更を伴う移転の手順で説明されている。
- リダイレクトはできるだけ長く、目安として1年以上残すよう案内されている。
中規模のサイトでは、大半のページが移転として反映されるまでに数週間以上かかることがあり、大規模なサイトではさらに長くなります。
ちなみに、Studio内蔵のリダイレクト機能は接続中の独自ドメインのパスに対してのみ有効で、転送先には外部URLも設定可能です。もっとも、ドメインのDNSを移行先へ向け直したあとは、旧URLへのアクセスは移行先が受けます。移行後のリダイレクトは、旧URLを実際に配信しているサービス側で設定してください。