StudioのAPIキー切り替え、制作会社へ依頼する作業と完了確認

Studio の API キー切り替え作業は、まず「Studio に登録されている外部サービス用の認証情報」と「Studio が発行するカスタムプロキシ用キー」を区別し、発行元・設定先・無効化の担当者を確認することから始めます。制作会社に作業を委託する場合は、以下の項目について確認・報告を依頼してください。

1. 対象となる認証情報・プロキシキーの一覧（担当者が把握できる形で提供）
2. 新しい認証情報・キーを使用した動作確認手順と結果（テスト環境での検証を含む）
3. 旧認証情報・キーの無効化手順と実施状況（無効化が完了したことを証拠として残す）
4. 未完了項目や問題が残っている場合の報告内容と提出期限 作業依頼の際は、上記項目をチェックリスト形式で提示し、完了報告時に必要な証跡（設定画面のスクリーンショットやログの抜粋など）を添付してもらうよう指示してください。なお、具体的な作業手順や設定項目については、最新の公式ガイドラインや担当保守提供元に確認の上、適切な手順を採用してください。

最初に切り替える認証情報を区別する

外部サービスのAPIキーを洗い出す

Studioの公式案内では、API連携に登録されている外部サービスのAPIキーやトークンが流出した可能性のある情報に含まれています。まず確認したいのは、自社のどのプロジェクトが、どのサービスと、何の目的で連携していたかです。「サイトが表示できるから関係ない」と判断せず、制作時の仕様書や運用担当の記録も確認します。

一覧には、プロジェクト名、連携先、キーの発行元、設定を変更できる担当者を記載します。キーの値そのものを一覧や依頼メールへ貼り付ける必要はありません。識別名など、秘密情報を含めずに対象を区別できる方法を担当者と決めてください。管理画面に一覧出力機能があるかは、実際の仕様を確認します。

カスタムプロキシのキーを分ける

カスタムプロキシ機能については、Studioが発行した新しいプロキシキーへ、自社側のサーバー設定を差し替える案内があります。確認した公式案内では、差し替え後にStudioの窓口へ完了を知らせ、その後Studioが古いキーを無効化する流れです。外部サービスのキーを発行する作業と混同しないようにします。

制作会社には、サーバーの設定を変更する権限を誰が持っているか、変更後に誰がStudioへ連絡するかを聞いてください。「新しいキーを受け取った」「サーバーへ反映した」「旧キーの無効化を確認した」は別々の状態です。作業表でも分けておけば、途中の状態を完了と取り違えにくくなります。

その他の連携を一括で扱わない

公式案内では、Webhook通知のURL切り替えやGoogleスプレッドシートとの再連携など、機能ごとに異なる対応が示されています。これらをすべて「APIキーを変更すれば済む」とまとめないでください。reCAPTCHA v3についても、一律のシークレットキー差し替えは求められていないと説明されています。

制作会社には、利用機能ごとに「今回の案内のどの項目に該当するか」を整理してもらいます。使用していない機能は、確認した根拠とともに対象外と残します。利用状況が不明な機能は、対象外にせず未確認としてください。最新の個別メールと公式案内に差がある場合は、推測で選ばずStudioへ確認します。

制作会社へ依頼する範囲を決める

発行と設定と停止の担当を揃える

依頼書は「APIキーを更新してください」だけで終わらせず、発行元で新しい認証情報を用意する人、Studioや連携先の設定を変更する人、動作を確かめる人、古い認証情報を止める人を分けます。制作会社が外部サービスの契約を管理していない場合、発行作業には自社担当者の協力が必要になることがあります。

担当者が決まっていない作業は、そのまま未割り当てとして見える形にします。制作会社への依頼に含まれない作業がある場合は、追加費用や対応時間とあわせて確認してください。会社の管理用パスワードをそのまま共有するのではなく、必要な権限を安全に渡す方法を各サービスの仕様に照らして検討します。

変更前に業務への影響を聞く

例えば、サイトから外部のデータを読み込む連携と、フォーム受付を通知する連携では、止まったときに困る仕事が違います。制作会社には「更新中に何が表示されなくなるか」「受付は続くか」「通知だけ遅れるのか」を確認します。仕様を確認できていない段階で、影響がないと社内へ案内しないことが大切です。

必要に応じて、変更時間、関係部署への連絡、問い合わせを受ける代替窓口を決めます。ただし、流出した可能性のある認証情報を長く使うことにもリスクがあるため、通常の改修日程と同じ優先度で後回しにする判断は避けます。個別案内の期限と、自社で必要な作業を照合して責任者が判断します。

秘密情報を受け渡す経路を決める

認証情報を変更する作業では、依頼や完了報告の途中で新しいキーを広く共有してしまうことも避けたい問題です。メールの宛先に関係者を増やしたり、全員が見られる議事録へキーを貼ったりすると、切り替え後の管理が難しくなります。制作会社と、秘密情報の受け渡し方法と閲覧する担当者を先に決めてください。

報告書には値そのものを記載せず、対象の識別情報、作業日時、結果を残します。画面の画像を証拠にする場合も、キーや顧客情報が写っていないか確認します。作業後に一時的な共有権限をどう扱うかも相談してください。具体的な共有手段は、自社のルールと相手が利用できる方法に合わせて選びます。

切り替え後に実際の仕事で確かめる

新しい認証情報で機能を試す

検証は、利用している連携の目的に合わせます。例えば商品情報の表示であれば、想定した情報が表示されるか、更新した内容が届くかを確認します。通知の連携なら、テストと分かるデータを使い、送信元から受信先まで届くことを確かめます。実在すると確認していない検証用APIや固定の応答コードを合格条件にしません。

何を試して何を正常と判断するかは、変更前に決めておくと比較しやすくなります。制作会社の技術的な確認に加え、受付や営業を担当する人にも業務上の結果を見てもらってください。顧客へ不用意な通知が届かないように、テストの送信先、内容、実施する時間を関係者で揃えます。

古い認証情報の停止を確認する

新しい認証情報で動いたことだけでは、古い認証情報が使えなくなったとは分かりません。外部サービスのキーなら、その発行元でどう停止するかを確認します。Studioのカスタムプロキシなら、公式案内の差し替え完了連絡と、Studio側での旧キー無効化の確認を区別して残します。

自社で旧キーの利用可否を試せるかどうかも、担当者と確認してください。一般的な確認方法をそのまま本番へ当てはめる必要はありません。止めた記録や提供元からの回答など、対象に合った証跡を求めます。別のシステムが同じ認証情報を使っていた場合は、関係先を調べて対応し、未完了なのに停止済みと報告しないようにします。

失敗したときの扱いを決める

切り替え後に動かない場合は、対象、確認した時刻、発生した現象、直前の変更を整理して制作会社へ渡します。ログを共有するときは、認証情報や個人情報が含まれていないか確認します。原因が分からないまま同じ設定変更を繰り返すと、何が影響したか追いにくくなるため、変更の記録を残してください。

通常の不具合対応のように、流出した可能性のある古いキーへ戻せばよいとは限りません。復旧方法や一時停止の必要性は、提供元の案内と実際の連携仕様を確認して責任者が判断します。動作が回復しても、古い認証情報の停止など残っている作業があれば、別の課題として追跡します。

完了報告で未対応を残さない

機能ごとの結果を報告してもらう

完了報告には、対象プロジェクト、連携機能、実施した変更、確認した動作、古い認証情報の扱い、未完了事項を記載してもらいます。自社が読む際は、対象一覧と報告の行を照合してください。「認証情報を更新しました」という一文だけでは、どの設定まで終わったか判断できません。

提供元への問い合わせ中の項目や、自社担当者の操作待ちの項目は、その状態と次の担当を残します。すべての項目が同じ日に完了するとは限りませんが、未対応が見えなくならないことが重要です。書式を増やすこと自体を目的にせず、依頼した作業と実施結果の差が分かる報告にします。

事故の調査と更新完了を分ける

認証情報の切り替えが終わっても、不正アクセスの時点で取得された可能性のあるデータを取り戻せるわけではありません。過去の不正な利用がなかったと証明する作業とも異なります。Studioの公式案内でも、認証情報の変更と、影響範囲や二次被害の調査は別に扱われています。

自社の業務で不審な操作やデータの変化が見つかった場合は、作業完了とは切り分けて責任者と提供元へ連絡します。調査が必要なら、保存している記録と不足している記録を整理して専門家へ相談してください。制作会社に依頼した範囲に調査が含まれるかどうかも確認し、更新作業だけで安全確認まで終えたと説明しないことが大切です。

続報を確認する担当を残す

今回確認した公式案内も、調査や対応の進展に伴って更新される可能性があります。完了後は誰も見ない状態にせず、公式情報と個別メールを確認する窓口を決めてください。新たな案内が来た際は、自社の対象一覧にどの作業が追加されるかを照合します。

記録の保存期間を一律の日数で決める必要はありません。契約、自社の情報管理ルール、事故対応の必要性に照らして責任者が決めます。将来の制作会社変更に備え、利用している連携、管理者、保守の範囲を引き継げるようにしてください。秘密情報を本文へ残さずに、誰が何を管理しているか分かる状態を維持することが、次の対応にも役立ちます。