初動対応更新日
#Studioのカスタムプロキシキーの30日の期限はいつまでですか？
期日は、Studioが2026年10月16日に送信した案内メールを受信した日から数えて30日以内です。この期間内に、自社側のサーバー設定を新しいプロキシキーへ差し替え、そのうえで差し替えが終わったことをStudioへ連絡しましょう。差し替えだけでは終わらず、連絡までが期限内の作業に入ります。
2026年10月の不正アクセスに関するお知らせによると、古いプロキシキーは、利用者からの完了連絡を受け取った後にStudio側で無効化される手順になっています。無効化の処理が完了するまでの間は従来のキーでも接続が維持されますが、第三者による不正利用を防ぐためにも、後回しにせず早めの差し替えと完了連絡を済ませたいですね。
起算点はメールの受信日です。公式の案内にはカレンダー上の締切日や、受信した当日を数えるかどうかは書かれていません。メールを受け取った日を手元で確認し、そこから30日目より前に連絡まで済ませておけば、日数の数え方で迷わずに済みますね。
ちなみに、カスタムプロキシは、自社で用意したホスティング環境からStudio側へWebリクエストを送る際に「x-studio-proxy-key」ヘッダーを付与して通信を行う仕組みを採用しています。
#カスタムプロキシキーを新しいキーへ差し替える手順は？
新しいキーへの差し替えは、具体的にどのような手順で進めればよいでしょうか。新しいキーはどこにあるのか、という所でまず手が止まりがちです。メールに書かれているわけではなく、Studioが発行して対象プロジェクトにすでに反映しています。流れは次のとおりです。
- 新しいプロキシキーを確認する（新しいキーはStudioが発行し、対象のプロジェクトに反映済みで、プロジェクトのダッシュボードで「設定」＞「カスタム」＞「カスタムプロキシ」を開くと確認できる）
- 自社側のサーバー（リバースプロキシやCDNなど）の設定にあるプロキシキーを、新しいキーへ差し替える
- 差し替えたあと、サイトが正しく表示されることを確かめる
- Studioのお問い合わせ窓口で「プロキシキーの無効化依頼」を選び、対象プロジェクトのStudioサブドメインを添えて連絡する
冒頭で挙げた2026年10月の不正アクセスに関するお知らせでは、古いキーはStudio側で無効化されるまで使える状態が続くとされているので、表示を確かめたら早めに完了の連絡を出しましょう。窓口への連絡には、キーそのものを書く必要はありません。
最初の案内では、新しいキーでのアクセスが確認できた所から順に古いキーを無効化する、という流れでした。その後、利用者が完了を知らせる方式に切り替わっています。すでにキーの差し替えを終えている場合でも、この完了連絡を忘れずに送る必要がありますね。
#カスタムプロキシを使っているのはどんなサイトですか？
たとえば、自社ドメインの「/lp」だけをStudioで作ったページにし、「/blog」などほかの部分は自社で組んだサイトから配信する、という使い方です。外部のホスティング環境にリバースプロキシを置き、URLのディレクトリごとに行き先のサーバーを振り分けます。
このカスタムプロキシは、Business Plusプラン以上のプロジェクトで、プランとは別に追加契約して使う機能です。料金は月額39,800円（税込）の月額契約です（カスタムプロキシのヘルプ）。アドオンを契約しているかは、プロジェクトの契約内容で確かめてください。
また、Studioの公開サイトの手前にCDNやリバースプロキシを置く場合は、この契約が必須とされています。契約なしで前段に置いているプロジェクトはサポートの対象外で、公開などの動作も保証されません。Cloudflareなどを挟んでいても、カスタムプロキシの契約があるかは別の話です。
差し替えが必要なプロジェクトには、2026年10月16日に、Studioから機能ごとの個別メールが送られています。届いていないからといって対象外とは限らないため、迷惑メールも見たうえで、わからなければStudioに問い合わせてください。
#差し替え手順のメールが届いていない時はどうしますか？
対象の機能を使っている可能性があるのに、差し替え手順の個別メールが見当たらないときはどう確認すればよいでしょうか。まずは、普段使っているメールソフトの迷惑メールフォルダやゴミ箱、プロモーションなどの自動振り分けトレイにメールが入っていないかを確かめましょう。Studioからの通知は、代表的な送信ドメインである@studio.designや@studio.siteのほか、決済を処理するStripeやコミュニティを運営するCircleを含めたStudioの配信メール一覧に記載されている正規のアドレスから届きます。つまり、この2つのドメインだけで振り分けていると見落とすことがありますね。
次に、受け取る人が自分なのかを確かめます。プロジェクト別の重要な案内は、原則として対象プロジェクトのオーナー権限を持つアカウント宛てに送信されました。一部のオーナー不在のプロジェクトでは、ほかの参加メンバーへ送られることもあります。プロジェクトダッシュボードの「ホーム」＞「メンバー」から参加者の顔ぶれを確認し、同僚や制作パートナーのアカウントにメールが届いていないか照会してみましょう。
フォルダの確認や関係者への確認を行ってもメールが見つからない場合は、自社で対象外だと決めつけず、Studioのお問い合わせ窓口へ直接問い合わせます。アカウントへログインできる場合は、ダッシュボード画面にあるヘルプアイコンからサポートセンターを開き、「メッセージ」＞「会話を始める」＞「不正アクセスに関するお問い合わせ」を選んで連絡してください。ログインできない人や、契約の管理だけを担当していてアカウントを持たない人は、不正アクセスについての告知ページにある専用フォームを使ってください。
ログインする時は、画面のURLがapp.studio.designになっているかも見ておきましょう。
こんな聞き方も
- Studioのカスタムプロキシキーの対応期限の30日以内はいつまでですか？
- Studioのカスタムプロキシキー差し替えの30日の期限はいつまでですか？
- Studioのカスタムプロキシキーの差し替えには期限がありますか？
- カスタムプロキシキーの差し替えはいつまでに必要ですか？
- カスタムプロキシのキーはどう差し替えればよいですか？
- カスタムプロキシキーを新しいキーへ差し替えるには？
- Studioの古いカスタムプロキシキーの無効化はどう依頼しますか？
- 旧キーの無効化依頼は30日以内に出す必要があるのですか？
- カスタムプロキシのキーも漏えいの対象ですか？
- Cloudflare側のプロキシ設定も新しいキーに更新する必要がありますか？
- カスタムプロキシの差し替え手順のメールが届いていない時は？
- 旧API連携（Beta）で設定したキーも差し替えが必要ですか？
- API連携を使っていなければキーの対応は不要ですか？
- Data Connect APIを使っているBusinessプラン以上のサイトが対象ですか？
あわせて知りたい（関連する疑問）
QCloudflare側のプロキシ設定も新しいキーに更新する必要がありますか？
CloudflareをStudioの前段に置き、Transform Rulesでヘッダーを付けて転送しているなら、更新が必要です。キーを持ってStudioへリクエストを送っているのはCloudflare側なので、そこに書かれた値が古いままだと差し替えたことになりません。
CloudflareのRequest Header Transform Rulesでは、転送するリクエストヘッダーの値を固定の文字列で指定し、もとの値を上書きできます。Studio向けのルールを開き、ヘッダー名「x-studio-proxy-key」はそのままにして、値だけを新しいキーに置き換えましょう。ルールの作り方はRequest Header Transform Rulesの説明に載っています。Workersなど別の方法でヘッダーを付けている場合は、その設定の中でキーを書いている箇所を直してください。
差し替えに必要な新しいプロキシキーはStudio側ですでに発行と反映が完了しており、プロジェクトの設定メニューから「カスタム」＞「カスタムプロキシ」を開けばいつでも確認可能です。Studio側の管理画面で新しいキーが表示されている状態は、Studio側で新しいキーを受け付ける準備が整ったことを示しており、Cloudflare側の設定まで自動で書き換わったわけではない点に注意してください。
サイトが正常に表示されていることを確認した後は、Studioのお問い合わせ窓口から「プロキシキーの無効化依頼」を選び、対象プロジェクトのStudioサブドメインを添えて連絡します。古いキーはStudio側で無効化処理が行われるまで通信可能な状態が続くため、Cloudflare側の設定変更を先に完了させてから無効化を依頼する順序を守ると安全ですね。
Q旧API連携（Beta）で設定したキーも差し替えが必要ですか？
旧API連携（Beta）で登録した認証情報も、今回の差し替え対象に含まれるのでしょうか。なお、すでに連携済みのデータは引き続き全プランで使えますが、今後も使い続けられるとは保証されていません（Data Connect APIのヘルプ）。はい、旧API連携（Beta）に登録した外部サービスのAPIキーやトークンも切り替えの対象です。暗号化して保存していたものも含まれます。復号に使う鍵まで読み出されたため、中身を知られた可能性があるためです。
API連携（Beta）は、外部サービスのAPIからデータを取り込み、Studioの動的リストに一覧で出す機能です。どれがこの機能で取り込んだデータかは、データリスト上の「Beta」タグで見分けられます。
切り替えは、順番を守って進めましょう。
- 連携先のサービス（microCMS・Notionなど）で新しいキーを発行する
- StudioのAPI編集画面で、ヘッダーに設定したキーを新しいものに書き換える
- 連携先で古いキーを失効させる
古いキーを先に止めてしまうと、サイトでの連携が切れて一覧が表示されなくなることがあります。連携先がmicroCMSなら、APIキーを作ったり消したりできるのは管理者権限を持つユーザーだけです。新しいキーは、APIキー管理の一覧にある「追加」から作ります。過去の制作時にテスト目的で設定したまま、現在はWebサイトの運用に使っていない外部サービスのAPIキーがStudio内に残っている場合でも、放置せずに発行元のサービス側でキーを失効させておく対応が推奨されています。
QAPI連携を使っていなければキーの対応は不要ですか？
API連携は使っていないから、自分には関係ないと考えたくなりますね。ただ、今回の対応はAPI連携だけの話ではありません。使っていないつもりでも残っているものがあるので、次の点を見てください。
- 以前に外部サービスのAPIキーやトークンをStudioへ登録したことはありますか（登録していた場合は、そのサービス側で新しい値に切り替える。Studio側では無効化できない）
- 埋め込みコードにAPIキーやトークンを書いていますか（書いている場合は、外部サービス側での切り替えが要るかをお知らせで確かめる）
- カスタムプロキシのアドオンを契約していますか（契約している場合は、API連携とは別にプロキシキーの差し替えが要るかを確かめる）
- Studioのパスワードを設定したことはありますか（設定している場合は、変更が要るかを確かめる）
- フォームの回答をStudioに保存していましたか（保存していた場合は、その回答が今回の対象に入るかを確かめる）
どれが対象になるかは、冒頭で挙げたStudioのお知らせで確かめてください。1つ目は、今使っているかだけでなく、過去に登録した履歴があるかも思い出しておきたいところです。
パスワードについては、GoogleログインかFacebookログインだけを使い、Studioのパスワードを一度も設定していない人は変更しなくてかまいません。以前にメールアドレスとパスワードで登録やログインをしたことがある人は、パスワードが設定されている可能性があるので、右上のアイコンから［設定］、［アカウント］、［パスワードを変更］の順に開いて変更します（パスワードの変更方法）。パスワードが設定されていなければ、変更しようとするとエラーが出ますが、追加の対応は要りません。今のパスワードが分からないときは、ログイン画面の「パスワードをお忘れですか？」から再設定します。
フォームは、Studioに保存されていた回答が対象で、ダッシュボードに表示されていない保存済みの回答も含まれます。
Qお客様から補償について聞かれたらどう答えればよいですか？
クライアントや自社サイトの利用者から補償や賠償の方針を聞かれても、制作会社や担当者の判断で約束はせず、Studioが公表済みの事実と、自社で済ませた対応を伝えるにとどめましょう。補償の扱いがStudioの続報に入るかは、上で挙げたStudioのお知らせの更新で確かめてください。わからないことはわからないと伝え、Studioから新しい発表があれば知らせると答えておくのが無難でしょう。
そのうえで伝えたいのは、自社がすでに何をしたかです。たとえばAmazing Dayの告知では、Studioの管理アカウントのパスワード変更と、外部連携に使う認証情報の無効化・再発行を済ませたことを書き、新しい事実がわかればそのページで知らせるとしています。キーの差し替えや連絡が終わっていない作業は、終わったように言わないでください。
もうひとつ、インシデントの発生直後は、関係者の動揺につけ込んで「お詫び」や「補償のご案内」を装う不審な迷惑メールが第三者から届く危険性があります。心当たりのない連絡にあるリンクや添付ファイルは開かないよう、お客様にも一言伝えておきましょう。届いたメールの送信元は、上で挙げたStudioの配信メール一覧にある正規のアドレスと照らし合わせてください。
補償の有無や条件そのものをStudioに確認したい時は、不正アクセスに関する問い合わせ窓口から質問できます。
Q不正アクセスの場合、確報の期限は60日ですか？
不正アクセスに伴う情報漏えいが発生した際、監督官庁への正式な報告期限は一律で60日以内なのでしょうか。60日以内とされるのは、不正の目的で行われたおそれがある個人データの漏えいなどで、個人情報保護委員会への報告が必要な事態に当たる場合です。日数は、その事態を知った日から数えます。
ただし、60日間の猶予があるからといって、初回の報告まで期間を空けてよいわけではありません。事故の発生を認識した後は速やかに最初の状況報告（速報）を行う義務があり、個人情報保護委員会の漏えい等報告手続ではその目安として概ね3〜5日以内と案内されています。速報で全部がそろっていなくてもよく、調べてわかった内容を確報でまとめて出す、という順番になります。
ここで注意したいのが、Studioから案内されているカスタムプロキシキーの差し替え期限との違いです。プロキシキーの差し替えと完了連絡の期限は「2026年10月16日に送信された案内メールを受信してから30日以内」であり、個人情報保護法が定める確報の60日という期限とは関係のない、システム固有の対応期日になります。
漏えいの対象となり得る個人データを取り扱っている事業者は、法的な速報や確報の提出スケジュールを把握しながら、第三者による不正利用を防ぐためのキー差し替え作業を定められた期日までに間違いなく完了させましょう。
この内容をChatGPTで相談
