StudioからFramerへ移行するには？判断軸・手順・チェックリスト

Studio・Framerとは？まずサイトの土台を整理

Studioは、Webサイトを制作・公開するサービスです。今回の脆弱性に関しては、対象となったStudioの環境でPHPを使用しており、修正版へ更新したと公式に案内しています。

Framerも、Webサイトを制作・公開するサービスです。Framerはアプリ・サービス・インフラでPHPを使用しておらず、FramerとFramerで公開したサイトは今回のPHP脆弱性の影響を受けないと公式に説明しています。

Studioへの不正アクセスやPHPの脆弱性に関する公表を受け、StudioやPHPを利用する環境からFramerへ移行することも、サイト運用を見直す選択肢の一つです。ただし、PHPの修正対応は移行とは別に進め、現状維持や部分移行も含めて、自社の機能要件や更新体制に合う方法を選びましょう。

StudioからFramerへの移行は、単純なデータコピーではない

StudioからFramerへの移行は、画面をコピーして終わる作業ではありません。ページ・CMS・フォーム・URL・計測・運用体制を棚卸しし、必要な範囲だけ移行先で作り直すプロジェクトとして考えると、工程も見積もりも現実的になります。

Studio公式ヘルプによると、他のプラットフォームへ移行するためのサイトデザイン・ページ・ソースコード・Studio CMSデータの書き出しには対応していません。一方、フォームの回答データは個別にCSVで出力できます。つまり、移行計画の出発点は、「持ち出せるもの」と移行先で「作り直すもの」を先に分け、必要なサイト資産を棚卸しすることです。

Studioから何を持ち出せる？

Studio公式ヘルプ「他のプラットフォームへ移行するため、Studioのサイトデータをエクスポートしたい」では、サイトデザイン・ページ・ソースコード・Studio CMSのデータについて、他サービスへ移行するためのエクスポートには対応していないと案内されています。

つまり、移行プロジェクトで最初に必要なのは「エクスポート手順」ではなく、公開中の資産の棚卸しです。URL一覧、各ページの役割、CMSの項目設計、フォームの入力項目をドキュメントにしておくと、移行先の構築もレビューも短くなります。

Framerへ移すとき、何を引き継ぎ、何を作り直す？

次の6つは、すべてを一から作り直す項目ではなく、移行前に引き継ぎ方を決めるための確認領域です。それぞれについて「そのまま使う」「Framer向けに再設定する」「作り直す」「使わない」のどれにするかを決めます。ページ・CMSはサイトの内容、フォーム・外部連携は問い合わせなどの業務、計測は成果確認、運用設計は公開後の責任分担に関わります。性質の違う作業を分けておくことで、見積もりや担当者、公開前テストの抜け漏れを防げます。

1. ページ構成とナビゲーション（残す／統合する／終了するの判断を含む）

2. CMSモデル（コレクション、項目、公開ステータス、一覧と詳細の表示ルール）

3. フォーム（入力項目、必須条件、送信先、通知、自動返信、スパム対策）

4. 埋め込み・外部連携（チャット、予約、地図、動画、API、Webhook）

5. 計測（GA4、Google Tag Manager、広告タグ、Cookie同意）

6. 運用設計（編集権限、更新担当、公開フロー、ドメイン・プランの契約主体）

特に、ページ構成やナビゲーションに関わるデザインを、今のまま「再現」するのか、情報設計から「再設計」するのかは、最初に決めておきたいポイントです。再現する範囲が明確なら工数を見積もりやすく、再設計する場合は、何を改善するかの合意や確認工程も必要になります。方針を先に共有しておくと、移行範囲と見積もりのずれを抑えやすくなります。

Studio・PHPの公表内容を受けて、最初に確認すること

2026年10月に公表された内容は、別々の出来事です。まとめて「セキュリティ事故」として受け止めると、自社が確認すべきことがぼやけます。時系列・対象・公表されている現状の3点で分けて確認してください。

Studioの不正アクセス

Studioは、9月30日〜10月1日に不正アクセスがあり、外部からデータを取得できる状態は10月14日に解消したと説明しています。実際に取得された事実は確認できていない一方、取得されたものとみなして対応中です。11月4日時点の案内では、アカウント情報、サイト・CMSの内容、Studioに保存されたフォーム回答、外部サービスのAPIキーやWebhook URLなどが流出した可能性があります。Studioが情報管理に使っていた認証情報は切替済みですが、利用者自身のStudioパスワードは案内に沿って変更してください。外部サービスのAPIキーやトークンは各サービスで新規発行し、古いものを失効させる必要があります。

まず10月16日の個別メールと管理画面の通知を確認し、対象プロジェクトに応じてパスワード、APIキー、Webhook URL、フォーム連携などを案内に沿って見直してください。Studioは11月4日、フォーム機能で個人データを扱う事業者向けに連名報告の申込みを開始し、期限を11月18日23:59（日本時間）と案内しています。連名報告はフォーム送信者本人への通知を含まず、Studioも送信者へ直接通知しないと説明しています。対象データや必要な対応は個別案内と最新の公式情報で確認し、迷う場合は社内の個人情報担当者や専門家に相談してください。

PHPのセキュリティ更新：確認先は「サイト」ではなく「環境」

PHP公式は10月21日、CVE-2026-109618／109619の修正版（8.5.12、8.4.27、8.3.36、8.2.35）を公開しました。対象はWordPressに限らず、Webリクエストを処理するPHP環境全般です。CISAは10月26日に両CVEを「Known Exploited Vulnerabilities（KEV）」、つまり悪用が確認された脆弱性をまとめるカタログへ追加し、対象環境の棚卸しと速やかな修正適用を促しています。10月23日にPHP公式が案内した特定設定向けの暫定対応は、修正版適用の代わりにはなりません。

まず管理者やホスティング事業者に、稼働中のPHPバージョンと修正済みパッケージの適用状況を確認してください。PHP 8.1以前などサポート終了版や、直ちに更新できない環境について、CISAは修正・更新までPHPシステムをオフラインにするよう勧告しています。PHP 8.2は2026年12月31日にサポート終了予定のため、次の更新計画も確認しましょう。WordPress利用だけで個別サイトの侵害を意味するわけではありませんが、サイト移行は脆弱性修正の代わりにはなりません。

フォーム・API・外部連携を担当者と棚卸しする

公表内容の確認とあわせて、自社がどこに何を預けているかを一覧にしておくと、この先の判断がすべて速くなります。フォームの入力項目と送信先、回答データの保存場所、CRMやスプレッドシートへの連携、通知先、APIキーやWebhookの設定、保存期間と削除ルール、そして各項目の責任者を整理しましょう。Studioの対象プロジェクトについては、個別メールで指定されたキーやURLの更新、パスワード変更などを移行計画とは別に優先して実施します。個別の影響確認や必要な対応を終えてから、継続・部分移行・全面移行を検討してください。

継続・部分改修・移行、どれを選ぶ？

選択肢は「今のまま続ける」「一部だけ移す」「全面的に移す」の3つです。セキュリティのニュースだけで全面移行を決める必要はありません。判断は、運用要件・更新負荷・責任分担から組み立ててください。

迷ったときは、いちばん更新頻度が高いページを1つだけ移すのが現実的な一歩です。移行の勘所（CMS、フォーム、計測、公開フロー）を小さく検証できるので、全面移行の判断材料にもなります。

移行先としてFramerを検討する段階なら、Framerとは？特徴・料金・使い方とFramerの料金・価格もあわせてご確認ください。なお、FramerはISO 27001およびSOC 2 Type 2への対応を公式のセキュリティページで公表しています。これは選定時の確認材料のひとつで、移行すれば安全になるという意味ではありません。

StudioからFramerへ移行する前のチェックリスト

移行で事故が起きるのは、デザインではなくほぼフォーム・URL・計測です。着手前に次の5領域を埋めておくと、抜け漏れが大きく減ります。

ページ・CMS・画像

• 公開中の全URLを一覧化した（サイトマップと解析データの両方から拾う）

• 各ページの役割を決めた（継続／統合／終了）

• CMSの項目設計を書き出した（コレクション名、項目、必須条件、公開日）

• 記事・事例の件数を数えた（入力工数の見積もりに直結する）

• 画像・動画の原本と利用許諾の所在を確認した

フォーム・顧客データ

• 入力項目と必須条件を一覧化した

• 送信先・通知先・自動返信の設定を確認した

• 既存の回答データの保存場所と保存期間を決めた

• CRM・スプレッドシート・MAツールへの連携を洗い出した

• 個人情報の移転方法とアクセス権限を決めた（担当者を明記する）

• 移行当日のフォーム停止時間と代替の受付方法を決めた

URL・SEO

• 検索流入と被リンクが多い重要ページを特定した

• 旧URLと新URLの対応表をつくった

• 301リダイレクトの設定方法と確認方法を決めた

• タイトル・ディスクリプション・構造化データの引き継ぎを決めた

• 内部リンクとサイトマップの更新範囲を決めた

• Search Consoleの登録とインデックス状況の確認担当を決めた

なお、リダイレクトを正しく設定しても、検索順位や流入の維持を保証できるものではありません。公開後に変動を見ながら調整する前提で計画してください。

計測・外部連携

• GA4・Google Tag Managerの設定を移す範囲を決めた

• 広告タグ・コンバージョン計測の設定を一覧化した

• Cookie同意の表示要件を確認した

• チャット・予約・決済などの埋め込みを一覧化した

• APIキー・Webhookの管理者と再発行手順を確認した

体制・費用

• ドメイン・サイト・各種アカウントの所有者を確認した

• 編集権限を持つメンバーと公開フローを決めた

• 制作側と自社側の責任範囲を文書化した

• 移行先のプラン料金と追加機能の費用を把握した

• 旧サービスの解約時期と重複期間を決めた

移行作業の流れは？公開後までの6ステップ

移行は、制作だけでなく、現状把握・要件合意・公開後の確認までを含むプロジェクトです。各ステップで「誰が何を確認したら次へ進むか」を決め、成果物を残しましょう。Studioの個別案内への対応やPHPの更新は、移行の有無にかかわらず別途進めます。

Step 1｜目的・対象・責任者を決める

まず、何を解決するための移行なのかを一文で定めます。たとえば「更新を社内で完結したい」「保守負荷を減らしたい」などです。セキュリティに関する公表がきっかけでも、緊急の修正対応とサイト移行は別の判断として扱います。

対象サイトの意思決定者、Web担当、フォームや個人情報の管理担当、ドメイン管理者、制作・保守パートナーを洗い出し、最終承認者と各工程の担当者を決めます。移行対象がサイト全体か一部か、公開希望時期、移行中に止められない機能も確認します。

この段階の成果物： 移行目的、対象範囲、成功条件、担当者一覧。たとえば「主要ページを移し、問い合わせフォームと計測が稼働し、旧URLから適切に遷移できること」を完了条件として合意します。

Step 2｜現行サイトと運用を棚卸しする

公開中のURLを、サイトマップだけでなくアクセス解析や社内資料も使って一覧化します。各ページには、継続・統合・終了の方針、担当者、検索流入や問い合わせへの重要度を記録します。CMSはコレクション、項目、記事件数、公開状態を整理し、Studioから移行用データを出力できない項目は、画面や内容を確認しながら移行先へ再登録する前提で工数を見積もります。

続けて、フォームの入力項目・送信先・通知・自動返信、CRMや外部ツールとの連携、計測タグ、独自ドメイン、アカウント権限、画像の原本と利用許諾を記録します。フォーム回答など個人情報を扱うデータは、移行するか、どこに保管するか、誰がアクセスできるかを管理担当と確認してください。

この段階の成果物： URL一覧、CMS項目・コンテンツ一覧、フォーム・外部連携一覧、素材・権限・契約の確認表。抜けている情報と確認担当も明記します。

Step 3｜移行範囲と要件、URL方針を合意する

棚卸しをもとに、各ページや機能を「引き継ぐ」「Framer向けに再設定する」「作り直す」「終了する」に分類します。デザインを再現するか、情報設計から見直すかも決めます。CMSの構造、フォームの代替手段、外部連携、計測、編集・公開の権限、保守の分担を要件として書き出しましょう。

旧URLを維持するページと変更するページを決め、変更分は旧URL・新URLの対応表を作ります。Framerで必要な機能が実現できるか、プランや外部サービスの条件も確認します。可能なら代表的なページとフォームを小さく試作し、見た目だけでなく更新方法と運用負荷も確認してから、全面構築へ進みます。

この段階の成果物： 要件一覧、ページ・CMS・機能の移行方針、URL対応表、概算見積もり、スケジュール、承認記録。費用と納期、公開後の支援範囲を関係者間で合意します。

Step 4｜Framerで構築し、コンテンツを移す

合意した要件に沿ってページのテンプレートとCMSを作り、ページ本文・画像・メタ情報を再構築します。StudioのサイトやCMSデータを移行用に書き出せない場合は、元ページと棚卸し表を照らし合わせながら転記し、移行済み・未確認・対象外を管理表で追跡します。CMSの件数が多い場合は、一部を先に移して表示や項目の対応を確認してから、残りを進めます。

フォームは入力項目、送信先、通知、自動返信、スパム対策を設定し直します。APIキーやWebhookなどの認証情報は、必要なものだけを適切な権限で設定し、公開資料や共有範囲の広い文書に記載しません。計測タグ、Cookie同意、外部埋め込み、編集権限も設定し、ステージング環境で確認できる状態にします。

構築中も現行サイトを維持し、既存サイト側で更新が発生した場合の反映担当と締切を決めます。公開直前に内容の差分を照合し、更新の取りこぼしを防ぎます。

この段階の成果物： ステージング環境、移行状況を記録した管理表、フォーム・連携・計測の設定一覧、公開前の未完了項目一覧。

Step 5｜公開前テストと承認を行う

担当者を分けて、主要ページをPC・スマートフォンで確認します。リンク切れ、表示崩れ、画像、CMSの一覧・詳細、タイトル・ディスクリプション、canonical、robots設定、サイトマップを確認します。旧URLから新URLへのリダイレクトは、重要ページを優先して対応表と照合し、意図したページに到達するかテストします。

フォームはテスト用の情報で送信し、完了画面、通知先への到着、自動返信、CRMなどへの連携まで確認します。計測はページビューやコンバージョンなど、移行前に合意したイベントが記録されるかを確認します。実データや個人情報をテスト送信に使わないようにします。

不具合は担当者・修正期限・再確認者を記録し、重要なものが残っている場合は公開を延期します。Web担当、情報管理担当、事業側の承認者が公開可否を確認し、切替手順と問題発生時の戻し方も事前に共有します。

この段階の成果物： テスト結果、未解決事項と対応記録、公開承認、切替・切り戻し手順。フォーム通知を受け取る担当者にもテスト結果を確認してもらいます。

Step 6｜公開を切り替え、稼働を確認する

公開日時と作業担当を決め、ドメイン管理者が現行のDNS設定と変更手順を確認したうえで、ドメインの接続先を切り替えます。DNSの具体的な設定値や反映時間は利用サービスによって異なるため、ドメイン・ホスティング事業者の最新手順に従います。切り替え直後に、主要ページの表示、SSL、旧URLからの遷移、フォーム送信・通知、計測を実環境で確認します。

問題があった場合に備え、切り替え前の設定値、旧サイトの状態、連絡先、切り戻し判断者を手元に置いておきます。重大な表示不具合やフォーム停止など、事前に定めた基準に当てはまれば切り戻しを検討し、対応と再公開の判断を記録します。

公開後は旧サイトや旧契約をすぐに停止せず、数日から数週間を目安に、フォームの受信、主要URLのエラー、検索流入、計測データを担当者が定点観測します。問題がないことと必要なデータの保管を確認してから、旧サービスの終了時期を決めます。

この段階の成果物： 公開・切替記録、公開後の確認結果、未解決事項と担当者、旧環境の終了判断。検索順位や流入の維持は保証できないため、変動を見ながら必要な調整を続けます。

各ステップの完了条件を満たしてから次へ進めば、制作の手戻りと公開時の抜け漏れを抑えられます。とくに公開前テストと切り替え後の監視は省略せず、フォーム・URL・計測の担当者を明確にしておきましょう。

移行費用とスケジュールは何で変わる？

移行費用は「サイト1本いくら」では決まりません。おもな変動要因は次の7つです。

1. 移行するページ数と、統合・終了するページの判断量

2. CMSの件数と項目の複雑さ（手入力か、一括入力の仕組みをつくるか）

3. デザインを再現するか、情報設計から再設計するか

4. フォームの数と外部連携の本数

5. URL変更の有無とリダイレクトの件数

6. 多言語対応や会員機能などの追加要件

7. 公開後の運用支援・教育をどこまで含めるか

あわせて、Framerのプラン料金・構築費用・既存サービスの解約時期は分けて見積もることをおすすめします。重複期間が長引くと、想定外のコストになりやすい箇所です。

期間についても、ページ数とCMS件数、社内の確認体制で大きく変わります。確定した要件のない段階で「○週間で移行できます」と言える案件はほとんどありません。まずは棚卸しの結果をもとに範囲を決め、そこから逆算してください。