「WebflowのCMSが見えない」と言われたら——障害かどうかを切り分ける手順と、クライアントへの伝え方
「管理画面を開いたら、CMSのアイテムが表示されない」。運用中のサイトで、クライアントからこんな連絡が届くことがあります。
IGNITEでも、あるクライアントのサイトでCMSが見えなくなる事象がありました。このときは、Webflowのステータスページ（status.webflow.com）を開いて、Webflow側で障害が起きていることを確かめ、クライアントに状況を伝えて復旧を待ちました。原因がこちら側にあるのか、Webflow側にあるのかを早く見分けられたことで、不要な作業をせずに済みました。
本記事では、この経験をもとに、障害かどうかを切り分ける手順、ステータスページの見方、障害がなかったときの確認項目、クライアントへの伝え方をまとめます。
※本記事の内容は、2026年11月5日時点の公式情報に基づいています。
結論：まずstatus.webflow.comを開く
- Webflowには、サービスの稼働状況を公開するステータスページがあります
- 公式ヘルプでも、Webflowはステータスページで稼働状況を24時間監視していると説明されています
- 「CMSが見えない」「公開できない」と言われたら、まずステータスページで該当するコンポーネントの状態を見ます
- 障害が出ていれば、クライアントに状況を伝えて復旧を待ちます。出ていなければ、ログインや権限、ブラウザなど手元の原因を順に確かめます
切り分けの流れ
連絡を受けたら、次の順番で進めます。
- 状況を聞く：どの画面で、いつから、何ができないのか。スクリーンショットがあれば送ってもらいます
- 自分の環境で再現するか見る：制作側のアカウントで同じ画面を開きます
- ステータスページを見る：該当するコンポーネントと、進行中のインシデントを確かめます
- 障害あり：クライアントに共有し、復旧を待ちます。復旧の表示が出たら、もう一度画面を確かめます
- 障害なし：手元の原因を確かめます（後述）。それでも直らなければ、Webflowのサポートに問い合わせます
ここで大事なのは、ステータスページを「最初に」見ることです。障害中に設定をあれこれ変えてしまうと、復旧後に「どの変更が原因だったのか」がわからなくなります。
ステータスページの見方
status.webflow.comでは、Webflowのサービスがいくつかのコンポーネントに分かれて表示されています。2026年11月5日時点で確認できた主なものは次のとおりです。
| コンポーネント | 関係しそうな症状 |
|---|---|
| Site Pages | 公開しているサイトが表示されない、遅い |
| Webflow Canvas | Designerなどの編集画面が開かない、動かない |
| Dashboard | ダッシュボードにサイトが表示されない |
| Publishing | 公開ボタンを押しても反映されない |
| Forms | フォームの送信がうまくいかない |
| Localize | 多言語ページに関する不具合 |
| Ecommerce | ECの注文や決済まわり |
| Site search | サイト内検索 |
| SSL certificate provisioning | SSL証明書の発行 |
| Webflow.com、University、Support Portal、Marketplace | Webflowの公式サイトや関連サービス |
出典：Webflow Status
状態は、Operational（正常）、Degraded Performance（性能低下）、Partial Outage（一部停止）、Major Outage（大規模停止）、Maintenance（メンテナンス）で表示されます。インシデントが起きているときは、Investigating（調査中）、Monitoring（経過観察）、Resolved（解決）のように、対応の段階が更新されていきます。
「CMSが見えない」という症状は、CMS単体の項目ではなく、編集画面やダッシュボードの項目に表れることがあります。症状に近いコンポーネントを複数見るようにしましょう。
通知を受け取る
ステータスページには、インシデントの通知をwebhookで受け取る仕組みがあります。複数のサイトを運用している制作会社なら、社内のチャットなどに通知を流しておくと、クライアントから連絡が来る前に状況を把握できます。
Webflow Status（2026年11月6日撮影）。この時点の状態を示す画面例であり、常時の稼働を保証するものではありません。 出典：公式資料
障害が出ていないときの確認項目
ステータスページが正常でも、未掲載の障害や特定の環境だけで起きる不具合は否定できません。手元で確認できる次の項目を調べ、改善しなければ発生時刻と再現手順を添えてサポートへ連絡します。
- 別のブラウザや、シークレットウィンドウで開いても同じか
- ブラウザの拡張機能を止めると直るか
- 社内ネットワークのセキュリティ設定で、Webflowへの通信が止められていないか
- ログインしているアカウントが正しいか（個人と会社のアカウントを取り違えていないか）
- そのサイトやCollectionを見る権限があるか
- 制作側のアカウントでは見えるか
制作側では見えてクライアント側だけ見えない場合は、権限や席の設定が原因のことが多いです。この場合は、ワークスペースやサイトの設定で、その方の席とロールを確かめます。
クライアントへの伝え方
障害中のクライアントへの連絡は、短く、事実だけを伝えるのが基本です。例えば、次のような文面です。
現在、Webflow側でサービスの障害が発生しており、管理画面の一部が表示されにくくなっています。Webflowの公式ステータスページで、調査中と表示されています。復旧が確認できしだい、こちらで表示を確かめてご連絡します。それまでのあいだ、更新作業はお控えください。
ポイントは3つです。
- 原因がどこにあるか：Webflow側の障害であること
- 根拠：公式のステータスページに表示されていること
- 次に何をするか：復旧後にこちらで確かめて連絡すること、それまでは作業を控えてほしいこと
「いつ直りますか」と聞かれることもありますが、復旧の時間はWebflow側の発表を待つしかありません。わからないことは、わからないと伝えるほうが信頼につながります。
復旧後に確かめること
- ステータスページで該当するインシデントがResolvedになった
- 制作側のアカウントで、問題の画面が開けた
- クライアント側でも開けることを確かめてもらった
- 障害中に途中まで進めていた更新や公開がないか確かめた
- 公開サイトの表示とフォーム送信を確かめた
障害中に保存や公開の操作をしていた場合は、内容が反映されているかを必ず見ます。
日ごろからできる備え
障害は起きてから慌てるより、起きる前に段取りを決めておくほうがずっと楽です。IGNITEが運用中のサイトで意識しているのは次の点です。
| 備え | 内容 |
|---|---|
| 確認先を共有しておく | 社内とクライアントの双方に、status.webflow.comを確認先として伝えておく |
| 通知の流れを作る | ステータスページのwebhook通知を、社内のチャットなどに流す |
| 連絡の型を用意する | 上の連絡文をテンプレートとして保存しておく |
| 連絡窓口を決める | クライアントからの連絡を誰が受け、誰が判断するかを決めておく |
| 記録を残す | いつ・どの症状で・何を確かめたかを、障害ごとに残す |
| 大事な公開日を避ける段取り | 日時が決まった公開は、準備とテストを前日までに済ませ、公開操作・予約設定・復旧手順を確認する |
特に最後の点は見落としがちです。公開日の当日に作業を詰め込むと、たまたま障害が重なったときに打つ手がなくなります。事前に準備できる作業を済ませ、情報解禁の日時は守ったうえで公開できるようにしておきます。
記録は、次に同じような連絡が来たときの判断材料になります。「前回はPublishingの障害で、1時間ほどで解決した」といった記録があるだけで、クライアントへの説明もしやすくなります。
よくある失敗と対処
| よくある失敗 | 起きること | 対処 |
|---|---|---|
| ステータスページを見る前に設定を変える | 復旧後、どの変更が影響したのかわからなくなる | まずstatus.webflow.comを見る。変更は記録してから行う |
| 「CMS」という項目だけを探す | 該当する項目が見つからず、障害なしと判断してしまう | Webflow Canvas、Dashboard、Publishingなど、症状に近い項目を複数見る |
| 障害中に公開を何度も押す | 復旧後に、意図しない内容が公開されることがある | 障害中は公開を控え、復旧後に内容を確かめてから公開する |
| クライアントに原因を断定して伝える | あとで原因が違ったときに説明がしにくくなる | 「公式のステータスページにこう表示されている」と根拠を添えて伝える |
| 復旧の連絡だけで終える | 障害中に止まっていた更新が残る | 復旧後のチェックリストで、更新と公開の状態を確かめる |
例：管理画面の一覧が表示されないと連絡が来たとき
- クライアントに、開いている画面と時刻、スクリーンショットを送ってもらう
- 制作側のアカウントで同じサイトのCMSパネルを開く。ここでも表示されなければ、手元ではなくWebflow側の可能性が高い
- status.webflow.comで、Webflow Canvas、Dashboard、Publishingの状態と、進行中のインシデントを見る
- インシデントが出ていれば、上の連絡文の型でクライアントに共有する。制作側でも作業を止める
- インシデントがResolvedになったら、CMSパネルを開き直し、表示と公開の状態を確かめてクライアントに連絡する
- 対応の記録（時刻、症状、見た項目、連絡した内容）を残す
制作側のアカウントでは正常に表示される場合は、手順3に進む前に、クライアント側のブラウザやネットワーク、権限を疑います。どちらの環境でも同じ症状が出るかどうかが、最初の分かれ目です。
よくある質問（FAQ）
Q. ステータスページが正常なのに、表示がおかしいのはなぜですか？
手元のブラウザやネットワーク、権限が原因のことも、まだステータスページに掲載されていない不具合のこともあります。上の確認項目を順に試し、それでも直らなければWebflowのサポートに問い合わせます。
Q. 公開しているサイトも見られなくなりますか？
管理画面の不具合と、公開サイトの表示は別のコンポーネントとして表示されています。どちらに障害が出ているかで、影響の範囲が変わります。
Q. 障害の通知を自動で受け取れますか？
ステータスページには、webhookでインシデントの通知を受け取る仕組みがあります。
Q. サイトの表示速度が遅いときも、ステータスページを見るべきですか？
公式ヘルプのサイト速度に関する記事でも、ステータスページについて触れられています。まず障害がないかを見てから、画像の容量やコードなど、サイト側の改善に進むとよいでしょう。
まとめ
「CMSが見えない」と言われたら、まずstatus.webflow.comを開く。障害があれば共有して待つ。なければ手元の原因を順に確かめる。この順番を決めておくだけで、慌てずに対応できます。
AIエージェントやAPIを使った運用の仕組みは、Webflow CLI・MCP・APIの記事で紹介しています。運用中のサイトの保守や、障害時の連絡体制づくりは、Booostのお問い合わせからご相談ください。
※本記事はIGNITEが独自に調べてまとめたもので、Webflow, Inc.の公式見解ではありません。Webflowは、Webflow, Inc.の商標です（参考：Trademark Usage Policy）。記事中の製品画面や画像の著作権は、各出典元に帰属します。
参考資料
Booostはノーコードツール「Webflow」に特化したWeb制作サービスです。
デザイン・マーケティング・翻訳の3つの最適化で、Webサイトの集客力を最大化します。
