WordPress 7.1でサイトエディターが真っ白になる原因と直し方
WordPress 7.1に更新した後、サイトエディター（wp-admin/site-editor.php）だけが真っ白になる場合は、ブラウザの互換性とJavaScriptエラーを最初に確認し、それでも解決しなければサーバーエラーログとREST APIの応答を調べる。サイトエディターは投稿編集画面と比べてJavaScriptとREST APIへの依存度が高く、原因はこの2系統に集中している。
なぜサイトエディターだけが真っ白になるのか
サイトエディターは、テンプレートやテンプレートパーツ、グローバルスタイルと呼ばれるデザイン設定を、REST API経由でサーバーから取得してJavaScriptで描画する。投稿編集画面が正常でも、サイトエディターだけが真っ白になるのは、この特殊な描画経路のどこかでエラーが起きているためだ。
主な原因は次の4つに分けられる。
- 古いブラウザが最新JavaScript機能に対応していない
- JavaScriptファイルの読み込み失敗や例外が起きている
- REST APIが内部エラーを返してテンプレート情報を取得できない
- PHPのメモリ不足で致命的エラーが発生している
真っ白な画面の原因切り分けは、この4ステップの順で行うと効率的だ。
古いブラウザが原因かどうかを確認する手順
最初に確認するのはブラウザの互換性だ。サイトエディターはブロックエディターと同じく、最新のJavaScript機能をフルに使って動作する。Firefox ESRや数世代前のSafari、旧バージョンのChromeでは、これらの機能に対応できずに画面全体が真っ白になることがある。特に長期的にブラウザをアップデートしていない業務用端末や古いノートPCで起こりやすい。
確認方法はシンプルで、同じサイトを別の端末や別のブラウザで開いてみる。もし最新版のChrome、Edge、Firefoxのいずれかで正常に表示されるなら、使用中のブラウザが古いことが原因だ。その場合はブラウザのアップデートを行うか、対応ブラウザに切り替える。どうしても古いブラウザで作業しなければならない場合は、サイトエディターの使用を避け、投稿編集画面から個別のテンプレートを編集するという回避策もある。
デベロッパーツールでJavaScriptエラーを確認する
最新ブラウザでも真っ白になる場合は、デベロッパーツール（開発者ツール）を開いてJavaScriptエラーを調べる。画面が真っ白になる症状の多くは、レンダリングを途中で止めるJavaScriptの例外や、重要なファイルの読み込み失敗が直接の原因になっている。
ChromeやEdgeではF12キー、MacではCommand+Option+Iキーでデベロッパーツールが開く。Firefoxでは右クリックから「要素を調査」を選ぶとよい。開いたら「コンソール」タブに切り替え、ページを再読み込みする。コンソールに赤い文字で表示されるエラーを上から順に確認する。
TypeErrorやReferenceError、SyntaxErrorの表示があれば、それが画面描画を止めている例外だ。また「Failed to load resource」のようなエラーは、必要なJavaScriptファイルが読み込めていないことを示す。この場合は更新時にファイルが欠損した可能性が高いため、後述するWordPress本体の再インストールで解決することが多い。
サーバーエラーログとREST APIを確認する
ブラウザ側に明確なJavaScriptエラーが見つからない場合、次にサーバー側の状態を確認する。サイトエディターはREST API経由でテンプレート情報を取得するため、サーバーでエラーが発生していても画面上には何も表示されず、真っ白なままになる。
サーバーのエラーログを確認するときは、サイトエディターを開いた直後の時刻に注目する。エラーログには過去のボットスキャンや他のリクエストも大量に記録されている。AH01276のようなDirectoryIndex関連のエラーは、多くの場合ボットがディレクトリを直接スキャンした痕跡であり、エディターの真っ白とは無関係だ。ログを上から眺めるのではなく、症状が起きた時刻に新しいエントリが追加されたかどうかを確認する。
サーバーログと並行して、REST APIが正しく応答するかを直接チェックする。ブラウザのアドレスバーに自分のサイトURLに続けて wp-json/wp/v2/templates と入力して開いてみる。正常ならテンプレート一覧の入ったJSONデータが表示される。ここでエラーページやHTTP 500系のエラーが返るなら、REST API側に問題がある。
PHPメモリ上限と再インストールで直す
確認した内容に応じて対処する。PHPのメモリ不足を示すエラー（Allowed memory size of から始まるFatal error）がログに記録されている場合は、メモリ上限を引き上げる。デフォルトの128Mでは、テンプレートの多いサイトや高機能テーマでサイトエディターの読み込み中に不足することがある。wp-config.phpに次の1行を追加するか、レンタルサーバーの管理画面からメモリ上限を変更する。
define('WP_MEMORY_LIMIT', '256M');エラーログにメモリ不足が出ていない場合や、ブラウザのコンソールにファイル読み込みエラーが出ている場合は、WordPress本体の再インストールが有効だ。ダッシュボードの「更新」メニューを開き、「WordPressを再インストールする」ボタンを押す。wp-admin、wp-includes、ルートのコアファイルが最新版で上書きされ、更新時に欠損したファイルが復元される。テーマやプラグイン、投稿データには影響しない。
再インストール後も症状が続く場合は、一度標準テーマ（Twenty Twenty-Fiveなど）に切り替えてサイトエディターが開くか確認する。標準テーマで開くなら使用中のテーマ側に原因があり、標準テーマでも開かないならサーバー設定やREST APIの応答に原因が残っている可能性が高い。
よくある質問
プラグインをすべて無効化しても直らないのはなぜか
サイトエディターの真っ白はプラグインの競合だけでなく、ブラウザ、JavaScript、REST API、PHPメモリなど複数の要因が絡む。特にREST API経由のデータ取得に失敗している場合はプラグイン無効化だけでは切り分けが不十分だ。ブラウザのコンソールとサーバーログの両方を確認する必要がある。
同じブラウザなのにサイトによって動作が違うのはなぜか
サイトごとに使用中のテンプレートやブロック、グローバルスタイルの構成が異なる。古いブラウザが対応していないJavaScript機能を使うブロックや設定が含まれているサイトだけが真っ白になる。また、サイトごとのメモリ上限やサーバー設定の違いも影響する。
WordPress 7.0に戻した方がよいか
セキュリティ修正を含む更新を戻すのは推奨しない。WordPress 7.1のまま原因を特定して解決する方が安全だ。原因を切り分ける手順を踏めば、ロールバックせずに直せるケースがほとんど。
デベロッパーツールが使えない端末ではどうすればいいか
別の端末やブラウザで同じサイトを開いて症状を再現し、そこからデベロッパーツールやサーバーログを確認する。どうしても別端末が用意できない場合は、サーバーエラーログを症状発生直後の時刻で確認し、PHPの致命的エラーやREST APIの応答を調べるとよい。
この記事のポイント
- サイトエディターの真っ白はブラウザ互換性を最初に疑う
- デベロッパーツールでJavaScriptエラーを特定する
- サーバーエラーログは症状が起きた直後の時刻で確認する
- REST APIの応答を直接チェックして切り分ける
- PHPメモリ不足なら上限を引き上げる
- ファイル欠損が疑わしい場合はWordPress本体を再インストールする
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
MDN MCPサーバーでAIに正確なCSSブラウザ互換性情報を提供、開発効率が向上
MDN Web DocsがMCP（Model Context Protocol）サーバーを公開した。このサーバーを使うと、AIコーディングアシスタントにMDNの最新ドキュメントとブラウザ互換性データを直接読み込ませられる。CSSの新機能やブラウザサポートを正確に把握できるため、誤ったコード提案を防ぐことが可能だ。
特に、CSSの最新機能（light-dark()画像対応、:buffering疑似クラスなど）はLLMの学習データに含まれていないことが多い。MDN MCPを導入すれば、AIが正しい情報を参照して回答を生成するため、開発者はわざわざブラウザで互換性を調べる手間が省ける。
MDN MCPサーバーとは
MCPはAIツールが外部データソースに接続するためのオープンスタンダードだ。MDN MCPサーバーはこのプロトコルを使って、MDNの豊富なWebプラットフォーム情報（HTML・CSS・JavaScript・Web APIのリファレンス、ブラウザ互換性データ）をAIエージェントやIDEに提供する。これにより、AIが常に最新のWeb標準に基づいてコードを提案できるようになる。
MCPの基本とMDNの役割
MCP（Model Context Protocol）はAnthropicが中心となって策定したオープンプロトコルで、LLMが外部ツールやデータベースと通信するための共通インタフェースを提供する。MDN MCPサーバーはHTTPトランスポートで動作し、クライアント（VS CodeやClaude Codeなど）がリクエストを送ると、MDNのコンテンツAPIから必要な情報を抽出して返す仕組みだ。
たとえば、AIが「CSSのlight-dark()は画像でも使えるか」と問われた場合、通常のLLMは学習時の知識だけを頼りにする。しかしMDN MCPサーバーが接続されていれば、AIはリアルタイムで正式な仕様とブラウザ実装状況を取得し、誤った回答を防げる。
対応しているツール一覧
MDN MCPサーバーは主要な開発ツールと連携する。エディタではVS Code、Zed、Cursorがサポートされており、AIコーディング支援機能から直接MDNを参照できる。ターミナルベースのエージェントとしてはClaude Code、OpenAI Codex CLI、Google Antigravity CLI（旧Gemini CLI）が対応。チャットアプリではClaude Desktopで利用可能だ。
これらのツールにMCPサーバーを登録する手順は各公式ドキュメントに記載されている。基本はHTTPエンドポイントを指定するだけで、追加のAPIキーなどは不要だ。
なぜ今、MCPが必要なのか
Webプラットフォームの進化は速い。CSSだけを見ても、light-dark()の画像対応、@view-transition、:buffering疑似クラスなど、直近1年以内に実装が始まった機能は多い。AIの学習データは数カ月から1年以上前の情報で固定されているため、こうした新機能に関する質問には正確に答えられない可能性がある。
MDN Blogの記事では、Claude Code Opus 4.7を用いてテストを行った結果、MCPなしではWeb Serial APIについて「Firefoxでは未実装で、Mozillaの標準ポジションでは有害とされている」と誤った回答をしたと報告されている。実際にはFirefox 151でサポートが開始されており、MCPを有効にすることでこの誤りは解消された。
AIの回答が誤っていると、開発者はブラウザの実装状況を手動で調べ直す必要が生じる。MDN MCPはその手間を省き、AIが確かなソースに基づいて回答する仕組みを提供する。
実際のCSS機能で検証、MCP有無の比較
light-dark()画像対応のブラウザサポート
light-dark()はカラースキームに応じて値を切り替えるCSS関数だが、画像も受け付ける。たとえば次のように書ける。
.profile-avatar {
background-image: light-dark(url(avatar-light.png), url(avatar-dark.png));
}light-dark()はOSのカラースキームに応じて自動で画像を切り替える。画像以外にもグラデーションやURLが使用可能だ。
このlight-dark()の画像対応について、Claude CodeにMCPなしで質問した場合、色の値に関する説明しか得られず、画像がサポートされていることは明確に示されなかった。一方、MCPを有効にすると、Firefox 150以降、Chrome（フラグ付き）でサポートされていることが即座に回答された。
:buffering疑似クラスとWeb Serial APIの誤情報
:buffering疑似クラスは、メディア要素がバッファリング中であることを検出するため、MCPなしでも正しいブラウザサポート情報が返された数少ない事例だ。しかしshadowrootslotassignment属性やWeb Serial APIについては、MCPなしでは誤った情報が目立った。
MCPを導入すると、最新のブラウザ互換性データが参照されるため、誤情報を防げる。
特にWeb Serial APIのケースでは、MCPなしのAIは「有害」という強い表現を使ってまで非対応と主張しており、誤った知識で開発を妨げるリスクがあった。MDN MCPはこのような誤解を回避し、確かな情報に基づいたコーディング支援を実現する。
導入方法と活用のポイント
Claude Codeでの設定手順
MDN MCPサーバーはHTTPエンドポイントが公開されており、対応クライアントでMCPサーバーとして追加するだけで利用できる。たとえばClaude Codeの場合、次のコマンドをターミナルで実行する。
claude mcp add --transport http mdn https://mcp.mdn.mozilla.net/この設定後、AIアシスタントがMDNの情報を必要とする質問を受け取ると、自動的にMCPサーバーへリクエストが送られ、最新のドキュメントが参照される。他のエディタやCLIツールでも同様に、MCPサーバーのURLを登録するだけで連携が完了する。
プライバシーと注意点
現在のMDN MCPサーバーは実験的な提供段階であり、使用時にはMDNのプライバシー通知を確認することが推奨されている。サーバーは利用者が送信したクエリを一時的に処理するが、データの取り扱いについては今後アップデートされる可能性がある。
また、MCPが参照するデータはMDNの公式コンテンツとブラウザ互換性テーブルであるため、正確だが、あくまでAIの出力はLLMの生成結果である点に注意が必要だ。複数の情報源と組み合わせながら活用するのが賢い使い方といえる。
この記事のポイント
- MDN MCPサーバーは、AIツールにMDNの最新ドキュメントとブラウザ互換性データを提供する。
- CSSの新機能（light-dark()画像対応、:bufferingなど）の正確な情報を得られる。
- MCPなしではWeb Serial APIのように「未実装」と誤った回答をするケースがあった。
- VS CodeやClaude Codeなど主要な開発ツールで利用可能。導入はURL登録のみ。
- AIの回答が古い知識に依存するリスクを減らし、開発効率を高める。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
2026年3月のBaselineアップデート！最新Web技術の互換性と実務への活用法
Webプラットフォームの進化が加速している。2026年3月、主要なブラウザエンジンすべてで相互運用が可能になった機能を示す指標「Baseline」において、多くの強力な機能が新たに「利用可能（Newly available）」な状態となった。
同時に、登場から30ヶ月が経過し、もはやポリフィルなしで安心して本番環境に投入できる「広く普及（Widely available）」の段階に達した技術も大量に増えている。レイアウト制御の高度化から、低遅延なネットワーク通信、洗練されたストリーミング機能まで、Webの可能性はさらに広がった。
この記事では、2026年3月のアップデート内容を整理し、それぞれの技術が実務にどのようなメリットをもたらすのかを詳しく掘り下げていく。Web制作の現場で「今、どの技術を使うべきか」を判断する材料として役立ててほしい。
最新機能とタイポグラフィの進化
今回のアップデートでは、CSSのタイポグラフィ制御に関する機能がいくつかBaselineの「Newly available」となった。これにより、これまで実現が難しかった高度なテキストレイアウトが、標準的なCSSのみで完結するようになる。
数式表示とテキストインデントの自由度
まず注目したいのが、font-family プロパティに新しく追加された math という値だ。これは数式コンテンツ（MathMLなど）をレンダリングするために特別に設計されたフォントセットを指定するものだ。技術文書や教育サイトにおいて、複雑な数式を美しく、かつ正確な間隔で表示するために不可欠な機能となる。
また、text-indent プロパティも大幅に強化された。新しく追加された each-line キーワードを使えば、ブロックの最初の行だけでなく、<br /> による強制改行の後のすべての行にインデントを適用できる。さらに hanging キーワードを使えば、1行目はそのままに、2行目以降をインデントさせる「ぶら下げインデント」が簡単に実現可能だ。
/* ぶら下げインデントの指定例 */
.bibliography {
text-indent: 2em hanging;
}これは通常のテキスト配置だ。1行目の先頭だけが空くのが一般的だが、参考文献リストなどでは2行目以降を下げたい場合がある。
参考文献:Web技術の進化に関する考察。この行は1行目だが、2行目以降は左側に余白が作られ、項目名が際立つようになる。
text-indent: hanging の動作は対応ブラウザで確認してほしい。このコードを適用すると、参考文献リストや箇条書きのような、特定のデザインルールが求められるレイアウトを非常にシンプルに記述できるようになる。従来のようにネガティブマージンとパディングを組み合わせるハックは不要だ。
JavaScriptの反復処理を簡略化する新メソッド
スクリプト面では、Iterator.concat() が全ての主要ブラウザでサポートされた。これは、複数の反復可能なオブジェクト（配列やセットなど）を一つのイテレータに結合する静的メソッドだ。途中で中間的な配列を作成することなく、複数のデータソースを連続して処理できるため、メモリ効率の向上とコードの簡略化に寄与する。
データ通信とパフォーマンスの最適化
Webアプリケーションの「体感速度」を左右する通信技術やストリーミング機能も、Baselineの新たなステージへと進んだ。特にリアルタイム性が求められるサービスにおいて、これらの技術は大きな武器になる。
WebTransportによる低遅延通信
WebTransport は、HTTP/3をベースにした現代的な通信APIだ。クライアントとサーバー間での双方向通信を可能にし、従来のWebSocketよりも効率的で低遅延なデータのやり取りを実現する。信頼性の高いデータ転送と、信頼性は低いが高速な「データグラム」の両方をサポートしている点が特徴だ。
例えば、オンラインゲームやライブストリーミングなど、一分一秒の遅延が許されないアプリケーションにおいて、WebTransport は理想的な選択肢となる。HTTP/3のメリットである「ヘッドオブラインブロッキング（一つのパケット損失が全体の通信を止める現象）」の解消を享受できるため、不安定なネットワーク環境下でもパフォーマンスが安定しやすい。
バイナリデータの効率的なストリーミング
Streams APIにおける「読み取り可能なバイトストリーム（Readable byte streams）」のフルサポートも重要な進展だ。これはバイナリデータの処理に最適化されており、開発者が用意したバッファに直接データを読み込むことができる。これにより、巨大なファイルのアップロードやダウンロード、動画の動的処理などにおけるメモリ管理が劇的に効率化される。
さらに、ブラウザレベルでのエラーやポリシー違反を通知する「Reporting API」も共通の基盤となった。コンテンツセキュリティポリシー（CSP）の違反や、非推奨機能の使用、ブラウザのクラッシュレポートなどを特定の終端（エンドポイント）へ送信し、集中的に監視することが可能になる。これは大規模なWebサービスの運用保守において、問題の早期発見に大きく貢献するはずだ。
「広く普及」した技術：CSS subgridと安定したレイアウト
2026年3月には、多くの技術が「Widely available（広く普及）」へと移行した。これは登場から30ヶ月が経過し、もはや「最新技術」というリスクを負うことなく、あらゆるプロジェクトで標準的に採用できることを意味している。
CSS subgridによるグリッドレイアウトの完成
中でも最大の影響力を持つのが CSS subgrid だ。これは、子要素が親要素のグリッド定義（列や行のサイズ）をそのまま継承できる機能だ。これまでは、異なる階層にある要素同士を正確に整列させるために複雑な計算やHTML構造の妥協が必要だったが、subgridを使えばDOM構造を美しく保ったまま、完璧な整列が実現できる。
このデモが示すように、カード型レイアウト内のタイトルや本文の高さが、隣のカードと完全に一致するように制御できるのが subgrid の強みだ。もはや、JavaScriptで高さを揃える処理（いわゆるmatchHeightのようなもの）を書く必要はない。
表示の最適化とデバイス対応
また、image-set() 関数も普及段階に入った。これは <img> タグの srcset 属性に近い機能をCSSの background-image などで実現するものだ。ユーザーのデバイス解像度（DPI）に応じて、ブラウザが最適な画像ファイルを自動的に選択してダウンロードする。無駄な帯域を消費せず、Retinaディスプレイなどでは鮮明な画像を表示できる。
さらに、update メディアクエリも広く利用可能になった。これはデバイスの画面がどの程度の頻度で更新されるかを判定するものだ。スマートフォンのような高速リフレッシュレートを持つ画面と、電子書籍リーダー（e-ink）のような低速な画面を区別し、それぞれに最適なアニメーションや装飾を出し分けることができる。
実務での技術選定：Baselineをどう活用するか
Web技術がこれほど速く進化する中で、エンジニアやディレクターは「いつ、どの技術を実務に導入するか」という難しい判断を迫られる。GoogleのRachel Andrew氏は、自身の講演の中で、この課題に対する現実的なアプローチを提示している。
「安全」と「最新」のバランスを取る戦略
Andrew氏によると、Baselineのステータスを単なる「安全な機能のリスト」として見るのではなく、プロジェクトのリリース日に合わせてターゲットを設定することが重要だという。例えば、開発開始時点では「Newly available（最新）」であっても、プロジェクトの公開日が数ヶ月先であれば、その頃にはユーザーのブラウザ更新が進み、安全に使えるようになっている可能性がある。
一方で、特定のブラウザバージョンをサポートしなければならない制約がある場合、Baselineの「Widely available（広く普及）」に達している機能を選ぶのが最も堅実だ。この区分に入っている技術は、主要なブラウザすべてで安定して動作することが30ヶ月にわたって証明されている。ポリフィルによるパフォーマンス低下や、予期せぬバグのリスクを最小限に抑えつつ、モダンな開発体験を享受できる基準と言える。
コミュニティでの実装例と可視化
開発者コミュニティでも、このBaselineの考え方を積極的に取り入れる動きが出ている。Stu Robson氏は、自身のサイトに「Baseline status」を表示するWebコンポーネントを導入した事例を紹介している。特定の技術について解説する記事の冒頭に、その技術が現在のブラウザでどの程度サポートされているかをリアルタイムで表示する仕組みだ。
このような取り組みは、読者（またはクライアント）に対して、その技術が「今すぐ使えるものなのか」を即座に伝えるための優れた方法だ。Webコンポーネント自体はオープンソースで公開されており、Eleventyなどの静的サイトジェネレーターに限らず、WordPressなどあらゆるフレームワークで利用可能となっている。
この記事のポイント
- 2026年3月のアップデートで、
WebTransportやtext-indent: hangingなどが主要ブラウザで利用可能になった。 CSS subgridやimage-set()などの強力な機能が「広く普及」の段階に達し、本番環境で安心して使えるようになった。mathフォントファミリーやIterator.concat()により、数式表示やデータ処理のコードがよりシンプルになる。- Baselineのステータスを基準にすることで、プロジェクトのリリース時期に合わせた最適な技術選定が可能になる。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験