移行先の比較更新日
#Webflowはどんなセキュリティの認証を受けていますか？
Webflowは、米国の第三者監査基準であるSOC 2 Type IIへの準拠と、情報セキュリティ管理の国際規格であるISO 27001認証への適合を公表しています。SOC 2 Type IIの対象の範囲は、Webflow Trust Centerで取り寄せる報告書で確かめてください。ISO 27001については、公式のTrust Centerに認証取得が明記されており、ISO/IEC 27001:2022の資料も載っています。
ただし、この2つはWebflow社の運営体制に対する評価です。自分のサイトで設定するパスワードの強さや、フォームで集めた回答の扱い、外部サービスと連携するAPIキーの管理までは保証してくれません。認証があるからといって、サイトごとの設定を見直さなくてよいことにはなりません。
もうひとつ、証明書の適用範囲や有効期限は、資料そのものを取り寄せて確かめます。報告書や認証資料は申請すれば読める仕組みになっており、Enterpriseプランの契約がなくても申し込めます。稟議や取引先への説明に使うなら、名前だけで済ませず資料の日付まで見ておいたほうが話が早いですね。
#Webflowで過去に大きな情報漏えいはありましたか？
海外の制作基盤へ乗り換えるにあたり、過去に深刻な漏えい事故が起きていないかは誰もが気になるところですね。
Webflowについては、Trust Centerで関連する事案への見解を出しています。Trust Centerの見解は個々の事案についてのもので、これから先も起きないことを示すものではありません。
Studioでも不正アクセスの事案が公表されています。対象になった情報とパスワードの扱いは、このあとの『Webflowに移せばStudioで漏えいした可能性のある情報は守られますか？』の項でまとめます。
気にかけたいのは、フォームの回答のような情報を、Webflowでも同じように預けることになる点です。フォームの送信先にWebflowを選ぶと、回答はサイト設定のFormsにたまっていき、そこで閲覧や管理をします。管理者のログイン情報が脆弱であったり、権限管理が適切でなかったりすれば、管理画面経由で情報が閲覧されてしまうリスクは常に残ります。問い合わせの氏名やメールアドレスをどこに置くかは、移行先を決めるときに一緒に考えておきたい点でした。
#Webflowへ移ってもSaaSに依存するリスクは残りますか？
Webflowへ制作環境を移しても、公開サイトでCMSや標準フォームを使い続ける限り、SaaSへの依存は完全にはなくなりません。Webflowには有料のWorkspaceプランを契約することで、作成したデザインのHTMLやCSS、JavaScript、画像などのアセット一式を外部へ書き出せる機能が備わっています。自社で用意したサーバーや静的ホスティング環境へファイルをそのまま配置してサイトを公開できるため、制作プラットフォームへの依存を減らせる大きな利点に見えます。
しかし、Webflowのコード書き出し仕様を確認すると、ブログなどのCMS機能や動的なフォーム送信処理は書き出されるコードに含まれません。CMS内のデータ自体は別途CSVファイルとして取り出せるものの、管理画面を通じた記事の投稿や、サイト上での動的な一覧表示といった仕組みはWebflowのサーバーに頼り続けることになります。お知らせやブログをCMSで更新し、問い合わせをWebflowのフォームで受ける使い方なら、Webflowの障害や仕様変更の影響をそのまま受けます。この点はStudioのときと変わりません。コードを書き出して他社サーバーで完全な形で自立運用させるには、動的処理の部分を自前で開発し直さなければなりません。
その中で、フォームだけは依存を減らせます。新しく作ったフォームは初期設定で回答をWebflowに送って保存しますが、Custom actionで送信先を外部に向けると、回答はWebflowに送られず保存もされません。代わりに、Webflow側での保存やメール通知とは一緒に使えなくなります。外部の受け先としては、たとえばCloudflareのStatic Formsなら、受け取った回答への処理を自分で書けて、KVへの保存も必要なときだけ足せます（CloudflareのStatic Forms）。もっとも、これは回答の預け先がWebflowから別のサービスへ移るだけです。
なお、Studioは回答をサーバーに保存してCSVで落とせる仕組みで、1プロジェクトにつき1日5,000件まで保存でき、超えた分は保存されません（Studioのフォーム回答の保存）。
#Webflowでもページのパスワード保護はできますか？
公開前の制作物や社内関係者向けの資料ページなど、特定の関係者だけに閲覧を制限したい場面はありませんか？できます。ページ単位でもフォルダ単位でもかけられますが、パスワード保護の設定を使うにはSite planの追加が必要です。同じ案内の手順は、ページ設定のGeneralでPassword protectionをオンにし、パスワードを決めて保存し、サイトを公開する流れです。
公開し直したら、ログインしていない状態でページが開けないことを確認しておきましょう。
フォルダに対してパスワードを設定すると、そのフォルダ配下に置かれたすべてのページやサブフォルダへ同じ保護設定が自動的に引き継がれます。子ページに個別のパスワードを設定していても上書きされるため、会員向けと社内向けを同じフォルダに入れている場合は分けておきましょう。
注意したいのが、ページに貼ったPDFや画像です。保護されるのはページ本体だけで、アップロードしたファイルの直接リンクにはパスワードがかかりません。保護設定を行う前に検索エンジンの巡回などでファイルのURLが収集されていた場合、ファイルのURLを直接ブラウザに入力すれば誰でも閲覧できてしまいます。配布資料を限られた人にだけ見せたい場合、ページの保護だけでは足りません。
Studioで使っていたパスワードは使い回さず、新しく決め直してください。
#Webflowは初心者には難しいですか？
ドラッグ＆ドロップで手軽にサイトを作れる国産ツールに慣れていると、海外製で専門用語が多いWebflowの操作に戸惑う声は少なくありません。直感的な見た目の操作だけで完結するツールと比べると、一定の学習期間が必要になるのは確かです。
Webflowの操作画面は、ウェブ制作の標準規格であるCSSの設計思想に基づいて作られています。中でも理解の土台となるのが、CSSのボックスモデルと呼ばれる概念です。ボックスモデルとは、文字や画像などのコンテンツ本体の外側に内側の余白（padding）、その外側に枠線（border）、さらにその外側に外側の余白（margin）が順番に配置されることで要素の領域が定まる仕組みを指します。この考え方を知っていると、余白がなぜずれるのかで迷う場面が減るでしょう。逆に、ここを知らないまま始めると、思った位置に要素が並ばずに手が止まりがちです。
学ぶための入口は公式にそろっています。初心者向けの講座「Webflow 101」では、ランディングページを1枚、順を追って作りながら、スマホやタブレットでも崩れない作り方と、誰でも使いやすいページの作り方を学べます。
困るのは言葉の面でしょう。操作方法を質問できるAI Assistantは、質問も回答も英語にしか対応していません。日本語で疑問点を尋ねても意図通りの回答を得にくいため、翻訳ツールを併用しながら英語で質問文を組み立てる手間がかかります。
さらに、料金体系の変更にも注意が必要です。プラン名は改定で変わることがあり、以前のCMS SiteプランやBusiness Siteプランが今どのプランにまとめられているかは、公式の料金ページで確かめてください。古いプラン名で書かれた解説記事もあるため、今のプラン名は料金ページで確かめてください。
こんな聞き方も
- Webflowのセキュリティは安心できますか？
- webflow セキュリティ
- webflow 情報漏洩 過去
- Webflowで過去に情報漏えいはありましたか？
- webflow 移行 同じ saas リスク
- Webflowへ移ってもSaaSに依存するという同じリスクは残りますか？
- webflow 難しい 初心者
- Webflowは初心者には難しいですか？
- webflow パスワード保護 ページ
- Webflowでもページのパスワード保護はできますか？
あわせて知りたい（関連する疑問）
QWebflowは2段階認証に対応していますか？
対応しています。Webflowの2段階認証をアカウントで設定できます。ログイン時にアカウントのIDとパスワードを入力した後、認証アプリが生成する固有のコードを要求する仕組みにより、パスワードが漏れても、認証アプリのコードがなければログインできなくなります。
設定はログイン後に次の順で進めましょう。
- Account settingsのSecurityタブを開く
- スマホに認証アプリを入れる
- 画面のQRコードを認証アプリで読み取る
- バックアップコードを保存する
- 認証アプリに出たコードを入力して確認する
この設定手順の途中で、画面に8個のバックアップコードが一度だけ表示されます。端末の紛失や故障によって認証アプリが開けなくなった際に使う緊急用のコードで、1つのコードにつき1回だけ使用できる使い切りの仕様です。スマホをなくしたときにログインできなくなるので、パスワード管理ツールなど、スマホとは別の場所に控えておきましょう。アカウント復旧に備えて、Account Settingsから予備のメールアドレスを追加することもできます。
ちなみに、お客さんのアカウントでは2段階認証は自動的にオンになりません。制作会社や社内の複数人で編集するなら、全員がオンにしているかを移行のタイミングでそろえておくと抜けがなくなりますね。
QWebflowに移せばStudioで漏えいした可能性のある情報は守られますか？
制作環境をStudioからWebflowへ新しく移し替える作業と、過去の不正アクセスによって漏えいしたおそれのある情報を保護する対応は、まったく別の問題です。Webflowに移して守れるのは、移行したあとに預ける情報です。新しいプラットフォームへサイトを移行したからといって、過去に外部へ持ち出された可能性のあるデータが自動的に消去されたり、安全な状態へ戻ったりすることはありません。Studio側でサーバーの暗号化鍵や認証情報を切り替える措置が講じられたとしても、不正アクセスの時点で第三者の手に渡ってしまった可能性のある情報を防衛することはできないためです。
特に注意が必要なのが、外部連携で用いていたAPIキーの取り扱いです。例えばヘッドレスCMSのmicroCMSを利用していた場合、書き込み権限が付与されたAPIキーが外部に漏れると、第三者によってサイト上の掲載コンテンツを不正に書き換えられてしまう危険が生じます。こうした被害を未然に防ぐには、連携先のサービスで古いAPIキーを速やかに失効させ、新しいキーを再発行しなければなりません。この作業は手順の順序が肝心です。
新しいAPIキーを先に発行して稼働中のシステムやWebflow側の設定を更新し、連携の疎通を確認してから最後に古いキーを削除します。古いキーを先に止めると、サイトの連携が止まる場合があります。Google Cloudでもキーの入れ替えは同じ順番です。読み取りだけで足りる連携なら、新しいキーは読み取り専用にしておきます。
Studioの不正アクセスのお知らせによると、実際に第三者に取得された事実は確認できていないものの、Studioは取得されたものとみなして対応しており、対象にはサーバーに保存されたフォームの回答、外部連携用のAPIキー、パスワード保護ページのパスワードが含まれ、外部の埋め込みフォームで受けた回答や添付ファイルの中身は含まれません。パスワード保護ページのパスワードはStudioの事案の対象に含まれ、ハッシュ化して保存されていたものの、元の値を割り出す可能性を完全には否定できないとして変更が呼びかけられています。Studioのパスワードを設定していれば、画面右上のアイコンから［設定］→［アカウント］→［パスワードを変更］で変え、同じパスワードを使うほかのサービスでも変えます。GoogleやFacebookのログインだけでパスワードを設定していなければ変更は要りません。細かな手順はお知らせの案内に沿って進めてください。
フォームで氏名や連絡先を集めていた事業者の場合、不正な目的で個人データが漏えいした、またはそのおそれがあるケースは、要件に当てはまれば個人情報保護委員会への報告義務の対象になります。自社が当てはまるかは、集めていた項目と件数を手元で確かめてから判断しましょう。
QWebflowのセキュリティ資料はどこで見られますか？
Webflowのセキュリティ対策や第三者認証の取得状況を示す公式資料は、専用のポータルサイトであるTrust Centerや公式の案内ページから確認できます。資料は誰でもすぐ開けるわけではなく、資料の閲覧申請を出して承認を受けるまで読めません。
申請の流れは次のとおりです。
- Trust Centerで「Request access」を押す
- Webflow側の手動承認を待つ（案内では通常2〜3営業日）
- メールで届く1回限りのリンクを開く
- 求められた場合はNDA（秘密保持の同意）に同意する
Enterpriseプラン以外のセルフサービス契約でも申請できます。一度付与された閲覧権限は8週間有効で、その期間を過ぎるとアクセス権は自動的に失効します。後日、再点検が必要になった場合は再び申請を行わなければなりません。社内の審査に出す日から逆算して、承認待ちの日数を見込んでおくと慌てずに済みますね。
一方で、自社のセキュリティチェックシートにWebflowの回答を書き込んでもらう依頼は、契約中のEnterprise顧客に限られます。依頼先は担当のCustomer Success Managerです。契約面で確かめたい場合は、Data Processing Addendum（データの取り扱いに関する契約の補足書類）のSchedule 2を見てください。個人情報を守るための技術的な対策と、社内の運用面の対策が書かれています。
Q官公庁や自治体のサイトをWebflowへ移すのは向いていますか？
高いセキュリティ認証を掲げるWebflowであれば、自治体や官公庁のウェブサイトでもそのまま移行先として使えるのではないかと考える担当者もいるかもしれませんね。
まず大きな壁となるのが、個人情報保護に関する法的な規制です。行政機関がクラウドなどで個人情報を扱う場合、委託先をきちんと監督すること、データが国外で扱われるならその国の制度も把握すること、責任の所在をはっきりさせることが大切だとされています（個人情報保護の基本方針）。デジタル庁でも、情報システムの調達をデジタル・ガバメント推進標準ガイドラインなどの政府共通ルールに沿って進めています。各自治体にどこまで同じ決まりが当てはまるかは、庁内の情報政策の担当部署に確かめるのが近道です。
個人情報がからむのは、ほとんどの場合フォームです。WebflowのフォームにカスタムアクションのURLを設定すると、回答はWebflowの処理を通らず指定した送信先へ直接届き、Webflowからの通知メールも届かなくなります。受け先を庁内のシステムや審査済みのサービスにすれば、Webflowに個人情報を預けない作りにできます。
ところで、WebflowはEnterpriseの顧客を除き、電話やビデオ通話でのサポートをしていません（WebflowのCustomer Support Policy）。電話の窓口が無い点は、障害時の連絡手段として、業務継続の計画の中で確かめておきたい点です。
お知らせや観光情報のように公開前提の情報だけを載せるサイトなら、フォームを外に出す形で話を進めやすいでしょう。住民からの申請や相談を受け付けるサイトは、Webflowだけで完結させず、受け付けの部分を別の仕組みに分けるつもりで考えたほうが現実的です。
この内容をChatGPTで相談
