何が発表されたか:公式ブラウザ拡張機能がChromeとSafariで公開
発表によると、公式のWordPressブラウザ拡張機能は、Google ChromeおよびChromiumベースのブラウザ向けにChrome Web Storeで、macOSのSafari向けにMac App Storeで、それぞれ提供が開始されています。記事ではオープンソースの拡張機能であると明記されています。
拡張機能ができることとして、記事は3つを挙げています。1つめは、ログイン中のサイトユーザーが管理バーを簡単に隠せるようにしつつ、その中でも最も役立つショートカットをブラウザのツールバーに残すこと。2つめは、自分が持つすべてのWordPressサイトへの素早いアクセスを提供すること。3つめは、開発者とコンテンツ制作者に向けた便利なツールを追加することです。
配布先について、発表で名前が挙がっているのはChrome Web StoreとMac App Storeの2つだけです。Chrome Web Store版については「Google ChromeおよびChromiumベースのブラウザ向け」、Mac App Store版については「macOSのSafari向け」と限定して書かれています。それ以外のブラウザやプラットフォームについては発表に記載がないため、この記事でも触れません。導入を検討する際は、自社の制作環境で使っているブラウザがこの2系統に当てはまるかどうかを最初に確認してください。
著者はJake Goldman氏、掲載カテゴリはDevelopmentとGeneralです。公式ニュースとしての発表であり、後述するように、もともとは独立したプロジェクトとして始まったものが公式プロジェクトになった、という経緯が説明されています。
出発点は管理バー:「自分が見ている画面」が訪問者の画面と一致しない
この拡張機能が生まれたきっかけとして記事が説明しているのは、WordPressの管理バーが抱えるトレードオフです。
既定では、WordPressにサインインしている間、閲覧するすべてのページの上部に管理バーが表示されます。これによってダッシュボード、エディター、プロフィールが手の届く場所に置かれるという利点があります。しかし記事は、その利便性にはコストが伴うと指摘します。バーがビューポートを占有するため、画面に映っているページは、訪問者が見るページと完全には同じにならないのです。
さらに具体的な問題として、記事はビューポートまわりで凝ったことをしているサイトを挙げています。スティッキーヘッダーやスクロール連動の演出を使っているサイトでは、管理バーの存在がアーティファクト(表示上の不整合)を引き起こすことがあり、実際には存在しないバグを探し回るはめになる、という指摘です。
加えて、プラグインがそれぞれの機能やショートカットを管理バーに追加していくことで、管理バーが手に負えないほど大きくなることがある、とも書かれています。
では、プロフィール設定で管理バーをオフにすればよいのかというと、記事はそれを「一方の問題をもう一方の問題と取り替えるだけ」と表現しています。管理バーを消すと、ショートカットも一緒に消えてしまうからです。ここが、この拡張機能が解こうとした課題の核心です。
拡張機能はこの問題をどう解いたか:隠す、しかしショートカットは残す
記事によれば、拡張機能は選んだサイトで管理バーを隠すか、あるいは既定ではすべての場所で隠します。そのうえで、最もよく使われるショートカットは1クリックで届く場所に保持されます。
そして、フルの管理バーを呼び戻したくなったときは2クリックで済み、ダッシュボードに行く必要はありません。管理バーをオフにするかオンにするかを、プロフィール設定の往復なしに切り替えられる、という設計です。
この一点だけを取っても、制作の現場では意味があります。一般論として、実装したページの見え方を確認するとき、ログイン状態のまま見た画面とログアウト状態で見た画面が違うために、シークレットウィンドウを開き直したり、別ブラウザを立ち上げたりする手間が発生しがちです。管理バーの分だけビューポートの高さがずれるという性質は、ファーストビューの見せ方やスクロール量を詰めていく作業と相性がよくありません。拡張機能が提供するのは、この確認作業を「ログアウトせずに、同じブラウザのまま」行える状態です。
記事は、この1つのトレードオフを解消する修正として始まったものが、もっと広いものへ育っていったと述べています。すなわち、ウェブ上のどこにいてもWordPressを見分けられるようにすること、どこからでも自分のサイトに飛び込めるようにすること、そしてテストとレビューのための小さなツール一式を持ち歩けるようにすることです。
サイト横断の入口:WordPressを見分け、自分のサイトへ飛ぶ
2つめの柱が、サイトを横断する入口としての機能です。
記事によると、ブラウジング中、ツールバーのアイコンが現在のサイトがWordPressで動いているかどうか、そして自分がサインインしているかどうかを、押しつけがましくない形で示します。訪問先がWordPressサイトかどうかを、都度ソースを覗いたり判定サービスに投げたりせずに把握できる、ということです。
自分が管理しているサイトでは、拡張機能を開くとダッシュボードへのショートカットや、いま表示している当該の投稿・固定ページ・タクソノミー・テンプレートのエディターへのショートカットが現れます。ブロックテーマにおいては、テンプレートに紐づくページはサイトエディターで開く、とも明記されています。
ここは実務上のポイントです。一般論として、公開ページを見ていて修正箇所に気づいたとき、管理画面に入り直して該当の投稿を一覧から探す、という往復が発生します。表示中のURLからそのままエディターへ飛べるなら、その往復が消えます。タクソノミー(カテゴリーやタグのアーカイブ)やテンプレートまで対象に含まれている点は、ブロックテーマでサイトを組んでいる制作者にとって意味が大きい部分です。
さらに、ローカルに保存されるランチャーが、サインインしたサイトを記憶します。記事は「まったく別の場所にいるときでも、それらのサイトが利用可能なままになる」と説明しています。つまり、いまWordPressサイトを見ていなくても、拡張機能から自分のサイト群へ入っていけるということです。
一般論として、制作会社や事業会社のWeb担当者は、複数のWordPressサイトのURLと管理画面のパスをブックマークやパスワードマネージャーに分散して抱えていることが少なくありません。ブラウザのツールバーに常駐するランチャーがその役割を引き受けるなら、日々のアクセス経路は単純になります。
ブラウザ側にあるほうが都合のよい開発者向けツール
3つめの柱が、開発者・コンテンツ制作者向けのツールです。記事は「いくつかのツールは、WordPressプラグインよりもブラウザのほうが適していることが分かった」と書いています。
挙げられているのは次の4つです。
・レンダリングされたページの上にブロックの境界を描画する
・スマートフォンサイズのプレビューウィンドウを開く
・キャッシュバスティング付きで再読み込みする
・いま開いているサイトのCookieとローカルストレージを削除する
記事は、これらの一部はサイトの内側から実現するのが難しいこと、そしてこれらのどれもプラグインや他のソフトウェアのインストールを必要としないため、訪問するあらゆるWordPressサイトで同じツールが使えることを利点として挙げています。
この「サイト側に何も入れなくてよい」という性質は、実務では効きます。一般論として、確認用のプラグインをクライアントの本番環境に入れるという判断は、それ自体が調整と説明を必要とする作業です。デバッグ用途のプラグインを入れっぱなしにして事故につながる、という懸念もあります。ツールがブラウザ側にあるなら、サイトの構成には一切影響しません。
4つのツールそれぞれの使いどころを、発表内容の範囲で整理しておきます。ブロック境界の描画は、公開後のページで「どこからどこまでが1つのブロックなのか」を見た目のうえで把握するためのものです。スマホサイズのプレビューウィンドウは、開発者ツールのデバイスエミュレーションを開くほどでもない確認を、素早く済ませたい場面に対応します。キャッシュバスティング付きの再読み込みは、変更を反映したはずなのに古い表示が返ってくる、という状況に直接効きます。Cookieとローカルストレージの削除は、ログイン状態や表示制御の挙動を初回訪問の状態から確かめ直したい場面に効きます。いずれも、いま開いているサイトに対してその場で実行できるという点が価値です。
プライバシー設計:すべて端末内で完結し、トラッキングは一切ない
ブラウザ拡張機能を業務端末に入れるとき、最も気にされるのが挙動の透明性です。この点について、記事は明確に書いています。
記事によると、これらはすべて自分のデバイス上で起こります。拡張機能は目の前のページを読んで、それが何を見ているのかを判断します。ページから分かること以上の情報が必要になったときには、そのサイトに問い合わせます。
そして、ユーザーの設定と、サインインしたサイトの一覧は、ブラウザの中に留まります。記事は「他のどこにも送信されず、いかなる種類のトラッキングもアナリティクスもない」と述べています。
拡張機能を導入する際の社内説明では、この一文が判断材料になります。一般論として、ブラウザ拡張機能は閲覧中のページの内容にアクセスできる立場にあるため、情報システム部門の審査対象になりやすいカテゴリです。公式の発表文で、処理が端末内で完結すること、設定とサイト一覧が外に出ないこと、トラッキングとアナリティクスが存在しないことが明言されているのは、その審査に持ち込める根拠になります。加えて、オープンソースであること、そして後述するGitHubリポジトリで開発が追えることも、確認可能性という意味では材料です。
成り立ちと配布先:独立プロジェクトから公式プロジェクトへ
この拡張機能は、最初から公式のものだったわけではありません。記事は、独立したプロジェクトとして始まり、Matt Mullenweg氏の積極的な支援を受けて公式プロジェクトになったと説明しています。
主要な貢献者として名前が挙がっているのは次の方々です。Fabian Kägy氏は、コアコントリビューターでありFueled(旧10up)の同僚で、初期の設計とアーキテクチャの多くを形づくることに貢献したと記されています。Khokan Sardar氏は、複数のパッチを提供したと記されています。加えて、Fueledの他の複数の同僚が包括的なテストを行い、最終的な形に影響を与えたとされています。
開発の進捗はGitHubリポジトリで追うことができ、バグ報告とプルリクエストを歓迎すると記事は述べています。なお、リポジトリの具体的なURLは今回参照した発表記事の本文中でリンクとして示されており、この記事では出典元をたどっていただく形とします。
成り立ちを押さえておく意味は、単なる背景説明にとどまりません。独立プロジェクトが公式化されたという経緯は、この拡張機能が「WordPressコアの機能として設計されたもの」ではなく、実際の制作現場で困っていた人が作ったものであることを示しています。管理バーがビューポートを占有するという問題設定の具体性は、そこから来ていると読めます。
日本の制作現場での使いどころ
ここからは編集部による解釈です。発表内容そのものではなく、日本のWeb担当者・制作者がどの場面で効果を感じられるか、という観点で整理します。
まず、デザイン確認・検収の場面です。管理バーがビューポートを占有することで表示が訪問者の画面と一致しない、という問題は、ファーストビューの高さを詰める作業やスクロール連動の演出を実装する作業で顕在化します。発表が挙げているスティッキーヘッダーやスクロール駆動の効果は、日本の制作案件でも頻出する実装です。ログイン状態を維持したまま管理バーだけを隠せて、必要なときは2クリックで戻せるという設計は、この確認作業の往復を減らします。
次に、複数サイトを担当している場合です。ローカル保存のランチャーがサインインしたサイトを記憶し、別の場所を見ているときでもアクセスできる、という機能は、担当サイト数が増えるほど価値が出ます。一般論として、受託制作では保守契約中のサイトが並行して複数あることが普通で、管理画面への入口が分散すること自体が細かい時間の損失になります。
3つめは、本番環境に手を入れずに確認したい場面です。キャッシュバスティング付きの再読み込みや、Cookieとローカルストレージの削除は、確認作業でよく必要になる操作です。これらがブラウザ側にあり、プラグインや他のソフトウェアのインストールを必要としないなら、クライアントの本番環境の構成を変えずに済みます。他社が構築したサイトを引き継いだ直後など、環境に不用意な変更を加えたくない局面ほど、この性質は効きます。
4つめは、ブロックテーマで組んだサイトの運用です。表示中のページから、投稿・固定ページ・タクソノミー・テンプレートのエディターへ直接飛べること、そしてテンプレートに紐づくページはサイトエディターで開くことが明記されています。ブロックテーマでは「この見た目はどのテンプレートが担当しているのか」を突き止める作業が発生しがちなので、公開ページ側からの入口があるのは実務的です。ブロック境界を描画する機能も、同じ文脈で使えます。
逆に、慎重に判断すべき点も挙げておきます。1つは対応環境です。発表で明記されているのはChromeおよびChromiumベースのブラウザとmacOSのSafariであり、それ以外については記載がありません。チーム全員で同じワークフローを前提にするなら、使用ブラウザの統一状況を先に確認する必要があります。もう1つは、業務端末への拡張機能導入そのものが社内ルールの対象になっているケースです。この場合は、前述したプライバシー面の記述とオープンソースである点を添えて、正規の手続きで通すのが順当です。
所感
Scale Basics編集部として注目したのは、この拡張機能が解こうとしている問題の選び方です。管理バーがビューポートを占有するせいで、自分が見ている画面が訪問者の画面と一致しない――これは、WordPressで制作をしていれば誰もが日常的に踏んでいるにもかかわらず、「そういうもの」として受け入れられてきた種類の摩擦です。プロフィール設定でオフにするとショートカットまで消える、というトレードオフの構造まで含めて言語化されている点に、実際に困っていた人が作ったプロジェクトであることが表れています。
もう1点評価したいのは、ツールの置き場所についての判断です。発表は「いくつかのツールは、WordPressプラグインよりもブラウザのほうが適している」と述べ、その理由として、サイトの内側から実現するのが難しいことと、プラグインや他のソフトウェアのインストールを必要としないことを挙げています。受託制作の実務では、確認のためだけにクライアントの本番環境へプラグインを追加するという判断が、技術的な是非とは別のところで負担になります。機能をブラウザ側に置くという選択は、その負担を最初から発生させません。訪問するあらゆるWordPressサイトで同じツールが使える、という帰結も、複数サイトを横断する働き方には素直に噛み合います。
導入判断については、まずは自分の作業端末に入れて、管理バーの制御とエディターへのショートカットだけを試してみる、というのが現実的な入口だと考えます。これらは既存のワークフローを変えずに効果が分かる部分です。そのうえで、チーム標準として展開するかどうかは、対応ブラウザの状況と社内の拡張機能ポリシーを踏まえて決めることになります。プライバシーについては、処理が端末内で完結し、設定とサインイン済みサイトの一覧がブラウザに留まり、トラッキングもアナリティクスも存在しないと公式に明記されているため、説明のための材料は揃っています。オープンソースであり、GitHubリポジトリで開発を追え、バグ報告とプルリクエストを歓迎するという体制も、長期的に使うツールを選ぶうえでは加点材料です。
まとめ
・WordPress公式のブラウザ拡張機能が、Google ChromeおよびChromiumベースのブラウザ向けにChrome Web Storeで、macOSのSafari向けにMac App Storeで公開された。オープンソースの拡張機能である
・開発のきっかけは、管理バーがビューポートを占有して「画面に映るページ」が訪問者の見るページと一致しない問題。拡張機能は管理バーを隠しつつ、よく使うショートカットを1クリックで届く場所に残し、フルの管理バーは2クリックで戻せる
・ツールバーのアイコンが、そのサイトがWordPressかどうかとサインイン状態を示し、管理サイトでは表示中の投稿・固定ページ・タクソノミー・テンプレートのエディターへ直接飛べる。ローカル保存のランチャーがサインイン済みサイトを記憶する
・開発者向けツールとして、ブロック境界の描画、スマートフォンサイズのプレビューウィンドウ、キャッシュバスティング付き再読み込み、Cookieとローカルストレージの削除を搭載。プラグインや他のソフトウェアのインストールは不要
・処理はすべて端末内で完結し、設定とサインイン済みサイトの一覧はブラウザに留まる。外部への送信はなく、トラッキングもアナリティクスも一切ない。独立プロジェクトとして始まり、Matt Mullenweg氏の支援を受けて公式プロジェクトになった
よくある質問
Q1: この拡張機能を入れると、WordPressの管理バーは使えなくなりますか?
使えなくなるわけではありません。発表によると、拡張機能は選んだサイトで、あるいは既定ではすべての場所で管理バーを隠しますが、最もよく使われるショートカットは1クリックで届く場所に残されます。フルの管理バーを呼び戻したいときは2クリックで済み、ダッシュボードに行く必要はないと説明されています。プロフィール設定で管理バーをオフにした場合はショートカットも一緒に消えてしまうため、そのトレードオフを解消することがこの拡張機能の出発点だと記事は述べています。
Q2: この拡張機能を使うために、サイト側にプラグインを入れる必要はありますか?
必要ありません。発表は、ブロック境界の描画、スマートフォンサイズのプレビューウィンドウ、キャッシュバスティング付きの再読み込み、Cookieとローカルストレージの削除といったツールについて、そのどれもプラグインや他のソフトウェアのインストールを必要としないと明記しています。そのため、訪問するあらゆるWordPressサイトで同じツールが使えるとされています。クライアントの本番環境の構成を変えずに確認作業ができる、という点が実務上の利点です。
Q3: 閲覧しているサイトの情報やログイン先の一覧が、外部に送信されることはありますか?
発表によれば、送信されません。処理はすべて自分のデバイス上で行われ、拡張機能は目の前のページを読んで何を見ているのかを判断し、ページから分かること以上が必要なときはそのサイトに問い合わせます。ユーザーの設定と、サインインしたサイトの一覧はブラウザの中に留まり、他のどこにも送信されず、いかなる種類のトラッキングもアナリティクスもないと記されています。
出典:Introducing the WordPress Browser Extension(WordPress.org News、Jake Goldman氏、2026年8月13日)https://wordpress.org/news/2026/08/browser-extension/
無料ダウンロード資料
はじめてのSEO 完全ガイド
Web担当になった人が、90日で自走するための実務書
検索エンジンの仕組みから、キーワード選定・記事づくり・技術対応・効果測定、 そしてAI検索時代の打ち手まで。専門用語の知識ゼロの状態から読み始められるよう、用語はすべて本文中で説明しています。
| 体裁 | PDF／A4縦・全109ページ |
|---|---|
| 収録 | 図解21点、チェックリスト120項目、90日実行プラン、用語集56語 |
※フォーム送信後、ご入力のメールアドレス宛にダウンロードリンクをお送りいたします。
こちらのフォームにご記入ください
入力は1分ほどで終わります。
