Studioの初動対応は全体としてどの順番で進めればいいですか？
何から手をつければいいのか見当がつかず、作業の順番で足が止まるかもしれません。全体の作業手順が公式に厳密指定されているわけではないものの、不正な侵入や意図しない改変を防ぐ入口の防御から固めるのが自然でしょう。おおまかな流れは次のとおりです。
- Studioアカウントのパスワードを変更し、同じパスワードを使い回している他のサービスでも変える
- 外部サービスのAPIキーとWebhookを新しいものに差し替える
- スプレッドシート連携を解除し、使い続けるなら再接続する
- 発行済みのライブプレビューURLを削除する
- パスワード保護ページのパスワードを変更し、閲覧者に伝える
なお、パスワードを忘れてしまった場合は、ログイン画面から登録メールアドレスに再設定メールを送り、届いたメールから新しいパスワードを決めます。手順はパスワード再設定の手順にまとまっています。自分で再設定を始めたときに届くメールと、事故を知らせる案内メールは別物なので、取り違えないようにしてください。
また、スプレッドシート連携は、Studio側で解除したうえで、Google側からもStudioのアクセス権を外します。解除しているあいだはフォームの回答がシートに転記されませんし、同じGoogleアカウントでつないでいる他のプロジェクトにも影響が出ます。複数のサイトを抱えている人は、作業の前に影響の出るプロジェクトを洗い出しておくと慌てずに済みますね。
StudioのAPIキーやWebhookは、どの順番で再発行・失効すればいいですか？
連携中のキーやURLを更新するとき、先に古いものを消すべきか、それとも新しいものを登録してから消すべきでしょうか。新しいキーを先に作り、古いキーは最後に消します。逆にすると、差し替えが終わるまでのあいだ、フォームや外部データの読み込みが止まってしまいます。
この並びはStudioに限った話ではありません。Google CloudのAPIキー運用でも、旧キーと同じ制限をかけた新キーを作り、使っているアプリをすべて更新してから旧キーを削除する手順になっています。たとえばStudioでよく使われるGoogleスプレッドシートとの連携であれば、フォーム設定から一度接続を外したうえで、スプレッドシート連携の手順に沿って外部連携アイコンからアクセスを許可し直しましょう。再接続すると新しいシートが作られ、以後の回答はそちらに入るので、社内で共有しているシートのリンクも貼り替えが必要になります。
Slackなどの通知に使うWebhookも同様の考え方です。外部サービス側で新しい送信先URLを発行し、Studioや連携プログラム側の宛先を書き換えます。ちなみに、フォームの回答をスプレッドシートに送り、Google Apps Scriptの中からSlackのWebhook URLを呼び出す作り方では、URLはスクリプトに書かれています。Studioの設定画面を探しても見つからないので、どこにURLを書いたかを先に思い出しておきましょう。SlackのIncoming Webhookには認証情報そのものが含まれているため、取り扱いには注意が欠かせませんね。更新作業の直後にライブプレビューや公開サイトからテスト送信を試し、正しく通知が届くことを確認した段階で、発行元の管理画面から古いURLを無効化します。
移管する予定でも、StudioのAPIキーやパスワードの差し替えは必要ですか？
必要です。他社CMSや自社サーバーへサイトを移管する予定がある場合でも、Studioに登録していた認証情報の差し替えや失効作業は省けません。サイトを別の仕組みへ引っ越したとしても、過去に登録されていたAPIキーやパスワードが無効化されるわけではないからです。microCMSなどのAPIキーは発行元で生きているので、Studioを使わなくなってもキーは有効なまま残ります。実際にStudioの案内でも、現在は利用していない外部サービスのキーであっても、発行元の管理画面で失効させる対応が呼びかけられています。もうひとつ、すでに第三者に取得された可能性のある情報は、保存場所を移しても守れません。漏れたかもしれない鍵は、置き場所を変えるのではなく、失効させて新しいものに替える必要があります。
使わなくなったWebhook通知であれば、Studio側の登録URLを空にして保存しつつ、通知元サービス側でも古いURLを無効化する手続きが求められます。
あわせて、キーを作り直す権限にも気をつけてください。microCMSのAPIキーの権限では、作成・編集・削除ができるのは管理者権限を持つユーザーだけです。制作会社がStudioを触れても、クライアントのmicroCMSで管理者でなければキーは作れないので、誰が作業するかを先に決めておきましょう。
さらに、アカウントのパスワードは、右上のアイコンから設定、アカウント、パスワードを変更と進み、今のパスワードと新しいパスワードを入れて保存します。
カスタムプロキシや期限のある作業はありますか？
「普通のプランとは別の契約をしているけれど、自分にも何か作業があるのか」と迷うのが、カスタムプロキシを使っている人です。期限のある作業がはっきり決まっているのは、このカスタムプロキシです。期限は、Studioの不正アクセスに関するお知らせで、2026年10月16日に送られたメールの受信から30日以内とされています。起点は事故の発生日ではなくメールを受け取った日です。
このカスタムプロキシは、カスタムプロキシの仕様に記載があるように、既存のサーバー環境とStudioサイトをつなぐ上位プラン向けのアドオン機能です。ホスティング側で、届いたリクエストにStudioが指定したプロキシキーを付けて転送する仕組みになっています。対象はBusiness Plus以上で、旧プランならBusiness以上。
やることは、サーバー側の設定を新しいキーに替え、サイトが表示されるのを確かめてから、Studioに旧キーの無効化を頼むことです。依頼は問い合わせ窓口で「プロキシキーの無効化依頼」を選び、対象プロジェクトのStudioサブドメインを伝えます。キーそのものを書く必要はありません。Studioが旧キーを無効にすると完了の連絡が来ますが、それまでは旧キーも使える状態です。キーの交換を済ませただけで連絡を忘れると、旧キーが残り続けます。
一方、スパム対策のGoogle reCAPTCHA v3に関しては、全員に対する一律の差し替えは求められていません。予防のために交換してもかまいませんし、フォームが送れない、管理画面で身に覚えのない利用が増えているといった異常があれば、新しいキーに切り替えます。交換したときは、ライブプレビューと公開サイトの両方でフォームを送ってから古いキーを削除してください。
ところで、今回の件でStudioから届くメールに、認証情報を入力させるリンクは入っていません。ログインするときは、画面のURLが app.studio.design になっているのを確かめましょう。
APIキー差し替えの作業費はクライアントに請求できますか？
制作会社やフリーランスが受託案件でキーの差し替えを代行した場合、その作業工数をクライアントへ請求してよいのでしょうか。一律には決まっておらず、クライアントと結んでいる契約の内容しだいです。
前提として、外部サービスのAPIキーやトークンは発行元が管理しているので、Studio側では無効にできません。新しいキーへの切り替えと古いキーの失効は、利用者が自分でやる必要があります。原因は、2026年9月30日から10月1日にかけて、第三者がStudioの一部機能の脆弱性を突いて不正にアクセスしたことでした。クライアントからすれば自分に落ち度のない作業なので、費用の話はこじれやすいでしょうね。とはいえ、プラットフォーム側の脆弱性に起因する作業であっても、外部サービスのキー管理自体は利用者の責任範囲となるため、無条件で無償対応すべき作業とは言い切れません。
Web制作や運用の現場では、外部ツールの仕様変更や予期せぬトラブルへの対応が保守の月額費用に含まれるのか、それともスポットの別見積もりになるのかが契約ごとに異なります。WordPressの保守サービスでは、更新で不具合が出たら元の状態に戻すところまでを月額に含め、根本的な修正は別に見積もる会社があります。設定変更やシステム修正が契約範囲に入らない場合があり、範囲を超える作業は内容と費用を先に案内する、と明記している会社もありますね。他社製品が原因の調査や復旧も、必ず別料金になるわけではなく、個別の見積書や契約書の記載が優先される決まりになっていることが多いです。
ですから、まずは保守契約書や仕様書を開き、外部サービスの設定変更が月額の範囲に入るかを見てください。範囲外なら、着手する前に作業内容と金額を伝えて了承をもらいます。保守契約を結んでいない単発のクライアントなら、通常の追加作業として見積もりを出すことになります。今回の作業は発行元の管理画面に入る権限が要るので、見積もりの段階で、誰が管理者アカウントを持っているかも確かめておきましょう。