WordPressで記事や商品、店舗情報などが増えてくると、「カテゴリーやタグだけでは目的の情報を探しにくい」という問題が出てきます。

そんなときに便利なのが「VK Filter Search」です。

VK Filter Searchを使うと、カテゴリーやタグ、キーワードなど、複数の条件を指定して投稿を検索できるフォームをWordPress上に作成できます。

さらに有料版の「VK Filter Search Pro」では、チェックボックスやラジオボタン、段階プルダウンなどを使った、より本格的な絞り込み検索も利用できます。

この記事では、VK Filter Searchの無料版とPro版について、WordPress初心者にも分かりやすいように紹介します。

VK Filter Searchとは？

VK Filter Searchは、WordPressに「絞り込み検索」を追加できるプラグインです。

通常のWordPress検索では、検索ボックスにキーワードを入力して記事を探す方法が中心です。

VK Filter Searchを利用すると、それに加えて、「カテゴリー」「タグ」「カスタムタクソノミー」「投稿タイプ」などを条件にして検索できます。

WordPressの技術ブログであれば、「カテゴリー：WordPress」「タグ：セキュリティ」「キーワード：アップデート」といった複数の条件を組み合わせて記事を探せます。

情報量が増えてきたサイトほど、目的の記事を見つけやすくするために役立つプラグインです。

絞り込み検索とは？

「絞り込み検索」と聞くと難しく感じるかもしれません。

しかし、ネットショップや不動産サイトなどではよく使われています。

不動産サイトなら、「東京都」「マンション」「家賃10万円以下」「駅から徒歩10分以内」といった条件を選んで物件を探します。このように、いくつかの条件を指定して候補を減らしていく仕組みが「絞り込み検索」です。

VK Filter Searchを使えば、WordPressでもこれに近い検索フォームを作成できます。

VK Filter Searchには無料版とPro版がある

VK Filter Searchには、大きく分けて2種類があります。

無料版の「VK Filter Search」と、有料版の「VK Filter Search Pro」です。「VK Filter Search」はプラグイン画面から検索して直接インストールすることができる一方、「VK Filter Search Pro」は購入する必要がございます。

無料版でも基本的な絞り込み検索は十分可能です。一方、Pro版では検索項目の表示方法や検索条件を細かく設定できるため、店舗検索、求人検索、不動産検索など、より複雑な検索フォームを作りたい場合に向いています。

無料版のVK Filter Searchでできること

まずは無料版の機能から見ていきましょう。

カテゴリーやタグから検索できる

無料版では、カテゴリーやタグを検索条件として利用できます。

例えば、「カテゴリー：WordPress」「タグ：初心者向け」と指定して検索できます。

WordPressでは、カテゴリーやタグのような投稿を分類する仕組みを「タクソノミー」と呼びます。

自分で追加したカスタムタクソノミーも検索条件として利用できます。

キーワード検索ができる

通常のWordPress検索と同じように、キーワード入力欄も設置できます。

例えば、「カテゴリー：WordPress」「キーワード：セキュリティ」のように条件を組み合わせて検索できます。

カテゴリーだけでは探しにくい記事も、キーワードを追加することで見つけやすくなります。

投稿タイプを指定できる

WordPressには通常の「投稿」以外にも、「固定ページ」「カスタム投稿タイプ」などがあります。

VK Filter Searchでは、どの投稿タイプを検索対象にするか指定できます。

例えば、カスタム投稿タイプで「店舗情報」を作成している場合、「店舗情報だけを検索する」といったフォームも作成できます。

検索結果ページにもフォームを表示できる

検索を実行したあとに、「カテゴリーを変えて検索し直したい」というケースもあります。

VK Filter Searchでは、検索結果ページにも検索フォームを表示できます。

ユーザーが検索条件を変更しながら何度も探せるため、情報量の多いサイトでは特に便利です。

投稿アーカイブにも検索フォームを配置できる

カスタム投稿タイプの一覧ページなどにも検索フォームを表示できます。

例えば、「店舗一覧」「製品一覧」「求人情報一覧」といったページの上部に検索フォームを置き、条件を指定して一覧を絞り込めます。

無料版でも十分使える

ここまでを見ると分かるように、VK Filter Searchは無料版でもかなり多くのことができます。

• カテゴリーから探す
• タグから探す
• キーワードから探す
• 投稿タイプを限定する

といった用途であれば、まずは無料版で十分でしょう。

一般的なブログや情報サイトであれば、無料版だけで必要な検索機能を実現できるケースも多いです。

無料版の主な制限

無料版で注意したいのが、検索項目の表示方法です。

例えば、カテゴリーを検索条件にする場合、無料版では基本的にプルダウン形式になります。「カテゴリー：WordPress ▼」のような形です。

一方で、「□ WordPress」「□ セキュリティ」「□ プラグイン」といったチェックボックス形式で選ばせたい場合には、Pro版が必要です。

ここが無料版とPro版を選ぶ際の大きなポイントになります。

VK Filter Search Proとは？

VK Filter Search Proは、無料版の機能をさらに拡張した有料版です。

基本的な検索の仕組みは同じですが、以下のようにより細かな設定ができるようになります。

• 検索条件の選択方法
• 検索結果の並び順
• カテゴリーの階層表示
• 日付検索
• カスタムフィールド検索

特に、「条件が多い検索フォームを作りたい」「ユーザーに分かりやすい検索画面を作りたい」という場合に便利です。

本プラグインは31,900円（税込）の買い切りとなっています。サブスクリプションではありませんので、更新後に料金を請求されることはありません。

VK Filter Search Pro

不動産サイトの物件検索で見かけるような高度な絞り込み検索フォームを、WordPress のブロックエディタを使用してノーコードで簡単に設置できます。

商品を確認する

販売元公式サイト

ポチップ

VK Filter Search Proで追加される主な機能

チェックボックスで検索できる

Pro版では、タクソノミーなどをチェックボックスとして表示できます。

「□ WordPress」「□ PHP」「□ CSS」のような形で、複数の条件を同時に選ばせたい場合に便利です。

プルダウンよりも選択肢が見やすいため、ユーザーにとっても使いやすい検索フォームを作れます。

ラジオボタンを使える

Pro版ではラジオボタンも利用できます。

「○ 初心者向け」「○ 中級者向け」「○ 上級者向け」のように、「いずれか1つを選択してほしい」項目に向いています。

AND検索・OR検索を設定できる

Pro版では、複数条件を選んだ場合の検索方法も細かく指定できます。

AND検索は、「WordPressであり、なおかつセキュリティの記事」を探す方法です。一方、OR検索では、「WordPressまたはセキュリティに該当する記事」を検索します。除外検索（いわゆる「NOT検索」）も設定可能です。

検索フォームの目的によって使い分けることで、より柔軟な検索が可能になります。

投稿日で検索できる

Pro版では、投稿日を条件にした検索もできます。

例えば、2026年1月1日から2026年9月30日までといった期間を指定して記事を検索できます。

ニュースサイト、イベント情報、求人情報など、日付が重要になるサイトで便利です。

検索結果の並び替えができる

Pro版では検索結果の並び順も変更できます。

例えば、「投稿日が新しい順」「投稿日が古い順」「更新日が新しい順」「更新日が古い順」などです。

検索結果が多いサイトでは、ユーザーが目的の情報を見つけやすくなります。

カスタムフィールドを条件にできる

Pro版では、カスタムフィールドを使った検索にも対応しています。

カスタムフィールドとは、投稿に独自の情報を追加する仕組みです。不動産サイトであれば、「家賃」「築年数」「面積」「駅からの距離」といった情報を保存できます。これらの値を検索条件に利用できれば、より本格的な絞り込み検索が可能になります。

ただし、カスタムフィールド検索はデータ量や設定内容によってサーバーへの負荷が大きくなる可能性があります。そのため、この機能を使う場合には注意文が表示されます。

大量の投稿を扱う場合には、サイトの速度にも注意した方がよいでしょう。

段階プルダウンを利用できる

Pro版では、階層構造になっているタクソノミーを段階的に選択できます。

「東京都」を選択 →「新宿区」「渋谷区」「港区」などが表示、といった検索フォームの作成が実現できます。

地域検索との相性が非常によく、「不動産サイト」「店舗検索」「求人検索」「施設検索」などで活用できます。

アコーディオン表示ができる

検索条件が多い場合、すべてを表示すると検索フォームが非常に長くなります。

Pro版では、検索条件を折りたたむアコーディオン表示が利用できます。必要な部分だけを開いて検索できます。

スマートフォンでも検索フォームを見やすくしやすい機能です。

投稿数を表示できる

Pro版では、検索項目ごとに投稿数を表示することもできます。

例えば、「WordPress（120）」「CSS（35）」「PHP（42）」といった形です。

ユーザーは検索する前に「どのカテゴリーにどのくらい記事があるのか」を確認できます。

0件の検索項目も表示できる

通常、投稿が存在しない項目は検索候補に表示しないことがあります。

Pro版では、投稿数が0件の項目も表示できます。例えば、「WordPress（120）」「CSS（35）」「JavaScript（0）」といった表示です。

今後記事が追加される予定のカテゴリーなどをあらかじめ表示しておきたい場合にも利用できます。

ラベルを変更できる

Pro版では、検索フォームに表示する文字をより柔軟に変更できます。

例えば、内部的には「カテゴリー」という分類であっても「記事のジャンル」と表示することができます。

専門用語を避け、サイトの利用者に分かりやすい表現へ変更できるのがメリットです。

検索ボタンの表示を変更できる

検索ボタンについても、「検索」ではなく、「記事を探す」「条件から検索する」「この条件で探す」など、サイトに合わせた表示に変更できます。また、色や余白等についても変更可能です。

検索フォーム全体を自然な表現・体裁に整えたい場合に便利です。

無料版とPro版の違いを比較

主な違いを簡単にまとめると、次のようになります。大きな違いは、「検索できるかどうか」というよりも「どのような検索画面を作れるか」という点にあります。

無料版がおすすめのサイト

無料版は、次のようなサイトに向いています。

• 一般的なブログ
• 技術ブログ
• ニュースサイト
• カテゴリーやタグで記事を探せれば十分なサイト
• まず絞り込み検索を試してみたいサイト

特に「カテゴリー＋タグ＋キーワード」程度の検索フォームであれば、無料版から試してみるのがおすすめです。

Pro版がおすすめのサイト

Pro版は、より検索条件が多いサイトに向いています。

例えば、「不動産サイト」「求人サイト」「店舗検索サイト」「施設検索サイト」「製品データベース」「イベント情報サイト」「大量の記事を扱うメディア」などです。

チェックボックス、ラジオボタン、段階プルダウンなどを使えば、検索サイトらしい画面を作りやすくなります。

まず無料版から試すのがおすすめ

VK Filter Searchを初めて使う場合は、まず無料版から試すのがよいでしょう。

無料版でも検索の基本的な仕組みは確認できます。

実際に使ってみて、「チェックボックスにしたい」「カテゴリーを段階的に選びたい」「日付やカスタムフィールドでも検索したい」と感じるようになった段階でPro版を検討すると分かりやすいでしょう。

最初からPro版を導入する必要があるとは限りません。プラグイン自体も31,900円（税込）と高額のため、事前に入念にご検討いただくことを強くオススメいたします。

まとめ

VK Filter Searchは、WordPressに絞り込み検索を追加できる便利なプラグインです。

無料版でも「カテゴリー」「タグ」「キーワード」「投稿タイプ」などを利用した基本的な検索フォームを作成できます。一般的なブログや情報サイトであれば、無料版でも十分活用できるでしょう。

一方、Pro版では「チェックボックス」「ラジオボタン」「AND・OR検索」「投稿日検索」などが利用でき、より高度な検索フォームを作れます。

簡単に整理すると、無料版は「記事を条件から探しやすくする検索プラグイン」、Pro版は「不動産サイトや店舗検索のような本格的な絞り込み検索を作れるプラグイン」と考えると分かりやすいでしょう。

まずは無料版を使って検索フォームを作り、必要な機能が増えてきた段階でPro版を検討するのが、導入しやすい流れです。

関連ライセンス

Vektor Passport（ライセンス期間1年）

ベクトルパスポートは、コピペで使える豊富なプロ品質のプレミアムパターンや、WordPressテーマ・プラグイン等が使えるお得なオールインワンライセンスです。

商品を確認する

販売元公式サイト

ポチップ

WordPress 7.1.3が、2026年10月6日付（UTC）の公式告知で公開されました。今回は、7件のセキュリティ修正と4件の通常の不具合修正を含むアップデートです。

コメント管理画面の問題や、非公開・未公開の記事に付いたコメントが漏れる問題などが修正されています。WordPress公式は速やかな更新を勧めており、7.1.2へ更新済みのサイトも対応が必要です。

この記事では、修正された問題と、サイト運営者が確認しておきたいことを、初心者向けに説明します。

参考資料

• WordPress 7.1.3メンテナンスとセキュリティのリリース – WordPress.org 日本語

英語

• WordPress 7.1.3 Maintenance and Security Release – WordPress News
• WordPress 7.1.3 Security Release – Patchstack

WordPress 7.1.3はどのような更新？

今回の更新は、WordPress本体の安全性と安定性を改善するためのものです。プラグインやテーマの更新とは別に、WordPress本体を更新する必要があります。

「脆弱性」とは、攻撃に利用されるおそれのある、ソフトウェアの弱点です。ただし、脆弱性があるからといって、すべてのサイトですでに被害が発生しているという意味ではありません。

今回も、ログイン不要で情報が見られる問題や、一定のユーザー権限・操作が必要な問題など、成立する条件は異なります。

自分のサイトにどの条件が当てはまるかだけで更新を見送るのではなく、バックアップを確認して、早めに更新しましょう。

修正された7件のセキュリティ問題

① 承認待ちコメントから、管理画面で不正なプログラムが動く問題

コメント管理画面で「格納型XSS」が起きる問題が修正されました。

XSSとは、サイトに紛れ込ませた不正なプログラムを、閲覧者のブラウザーで動かす攻撃です。「格納型」は、その不正な内容がコメントなどとして保存され、後から表示された際に問題を起こす形を指します。

Patchstackの分析によると、攻撃者が細工したコメントを送り、編集者や管理者が、その中のリンクをクリックすることで成立します。

気を付けたいのは、コメントが「承認待ち」でも攻撃の入口になり得ることです。公開前のコメントだから安全とは限りません。

管理画面で不正なプログラムが動けば、ログインしているユーザーの権限を悪用されるおそれがあります。今回の修正では、管理画面のリンク処理が見直されています。

② URLの処理が終わらなくなる問題

URLを処理する内部機能「WP_Http::make_absolute_url()」で、特定の形式のURLを扱うと、繰り返し処理が終わらなくなる問題が修正されました。

これは「DoS（サービス拒否）」に関係する問題です。DoSは、処理を詰まらせたり、負荷をかけたりして、サービスを正常に利用できなくする攻撃を指します。

今回の修正では、URLの変換処理が進まなくなった場合に、繰り返しを終了するようになりました。

サイト運営者がこの機能を直接使っていなくても、WordPressの機能を通じて内部で呼び出されることがあります。画面上で使っていないように見える機能も、更新の対象として考える必要があります。

③ エクスポート時に、保存済みデータが不正な命令として扱われる問題

投稿などを書き出す「WXRエクスポート」に、第二段階SQLインジェクションの問題がありました。

WXRは、WordPressのコンテンツを別のサイトへ移すときなどに使うXML形式です。SQLインジェクションとは、データベースへの命令に不正な内容を混ぜ、意図しない処理を行わせる攻撃です。

「第二段階」という言葉は、先に保存されたデータが、後の処理で使われる際に問題を起こすことを表します。

今回の修正では、アイキャッチ画像のIDなどを、データベースへの命令に組み込む前に整数へ変換しています。画像の番号として扱うべき値に、不正な文字列が混ざらないようにする対策です。

通常のエクスポート操作が、そのまま攻撃になるわけではありません。保存された値を安全に扱うための修正と理解すると分かりやすいでしょう。

④ 「投稿者」が投稿を先頭に固定できる問題

「投稿者（Author）」のユーザーが、本来許可されていない投稿の先頭固定を行える問題が修正されました。

先頭固定は、記事を投稿一覧の上部に表示させる機能です。複数人で運営するサイトでは、記事を書く担当者と、掲載順を管理する担当者を分けたい場合があります。

今回の修正では、REST APIを通じた操作で、必要な権限を正しく確認するようになっています。REST APIとは、WordPressと編集画面や外部のプログラムが情報をやり取りする窓口です。

担当者に与えた権限の範囲を超えて、記事の表示順を変更されることを防ぐための修正です。

⑤ 非公開・未公開の記事に付いたコメントが見られる問題

非公開の記事や、まだ公開していない記事に付いたコメントが、ログインしていない第三者へ漏れる問題が修正されました。

報告者のPatchstackによると、記事ごとのコメントフィードで、記事を閲覧できるか確認する前にコメントを取得していたことが原因です。記事を表示対象から外しても、取得済みのコメントが残り、フィードに出力されていました。

フィードとは、記事やコメントなどの更新情報を、対応するアプリ等で受け取れるようにする仕組みです。公開画面で記事が見えないことだけでなく、フィードなどの別の経路にも、閲覧制限が適用される必要があります。

なお、今回公表されている漏えい対象はコメントです。「非公開記事の本文もすべて漏れる」とは説明されていません。

⑥ Imgurの埋め込みによるXSS

画像共有サービス「Imgur」の埋め込みに、XSSの問題がありました。対策として、WordPress標準のoEmbed対応先からImgurが削除されています。

oEmbedとは、対応するサービスのURLを貼ると、画像や動画などを自動的に埋め込む仕組みです。Imgurを記事で使っている場合は、更新後に表示を確認しましょう。

さらに、Patchstackは、更新だけでは既存の埋め込みキャッシュが削除されないと説明しています。

キャッシュとは、一度取得・生成した内容を、再利用するために保存したデータです。今回関係するものには、WordPressがデータベースに保存する埋め込みデータも含まれます。

Imgurを使っているサイトでは、過去の埋め込み内容も確認してください。通常のページキャッシュを削除すれば、すべての埋め込みデータも消えるとは限りません。不審な内容がある場合は、該当する埋め込みと保存済みデータへの対応も必要です。

⑦ WordPress内部の処理名が衝突する問題

WordPressには、投稿の公開や保存などに合わせて、プラグイン等の処理を呼び出す「フック」という仕組みがあります。

一部のフック名は、投稿の状態と投稿タイプを組み合わせて作られます。今回、その値を細工すると、別の処理と同じ名前になってしまう問題が修正されました。

分かりやすくいうと、処理を呼び出すための名前が重なり、想定していない処理まで呼び出されるおそれがある問題です。修正後は、正式に登録された投稿状態と投稿タイプの場合にだけ、該当するフックを呼び出します。

通常のサイト運営者が設定を変更する項目ではありませんが、独自プラグインなどを開発している場合には関係する修正です。

通常の不具合も4件修正

セキュリティ対策に加えて、次の4件も修正されています。

• サイトアイコン： 管理バーのアイコンが大きく表示される問題
• someecards.com： oEmbed対応先から削除
• ReverbNation： oEmbedの接続先を更新
• 画像アップロード： DOMライブラリーがないサーバー環境で、致命的エラーが発生する問題

DOMライブラリーは、HTMLやXMLなどをプログラムで扱うための機能です。最後の修正は、サーバー環境によって画像アップロードが失敗する問題に対応するものです。

サイトアイコンについては、テーマやプラグインの画像用CSSの影響で、管理バーのアイコンが大きく表示されるケースに対処しています。

7.1.2や古いバージョンを使っている場合も確認を

今回の問題は、WordPress 7.1.2にも存在します。直前のセキュリティアップデートを適用していても、7.1.3への更新が必要です。

また、旧バージョンの系列も影響を受けます。公式のセキュリティ勧告には、主な修正版として次のバージョンが記載されています。

このほか、4.7系まで修正対象とされています。ただし、リリース記事では、旧系列向けの修正版は準備が整い次第公開すると案内されています。更新画面と公式情報を確認してください。

なお、古い系列に修正が提供されることは、継続的なサポートを保証するものではありません。公式は、積極的にサポートするのは最新バージョンのみとしています。旧系列を使い続けている場合は、今回の修正を適用するとともに、最新系列への移行も検討しましょう。

サイト運営者が行う更新対応

① 現在のバージョンを確認する

まず、WordPress管理画面の「ダッシュボード → 更新」を開き、現在のバージョンを確認します。

自動更新に対応しているサイトでは、すでに更新されている場合があります。「自動更新を設定しているから大丈夫」と考えず、修正版になっていることを実際に確認することが大切です。

複数のサイトを管理している場合は、それぞれ確認してください。

② バックアップを確保する

手動で更新する前に、サイトを復元できるバックアップを確認します。WordPress公式も、更新前のバックアップを案内しています。

確認したいのは、主に次の2つです。

• データベース：投稿本文や各種設定など
• サイトのファイル：画像、テーマ、プラグインなど

レンタルサーバーの自動バックアップを利用している場合も、保存日時と復元方法を把握しておきましょう。

③ 管理画面から更新する

「ダッシュボード → 更新」で、WordPress本体の更新ボタンを押します。更新が完了したら、バージョンが修正版になっていることを確認してください。

管理を制作会社や保守担当者に依頼している場合は、「WordPress 7.1.3で修正された脆弱性への対応状況」を確認すると、用件が伝わりやすくなります。

④ 更新後の表示と動作を確認する

更新後は、日常的に使うページや機能を確認しましょう。

• トップページ、投稿、固定ページが表示されるか
• 管理画面にログインできるか
• 投稿や固定ページを編集できるか
• コメントや会員機能が正常に動くか
• 問い合わせフォームなどが動作するか

サイトが普段どおり表示されていても、セキュリティ上の問題がないとは限りません。

WordPress 7.1や7.1.1、7.1.2を利用している場合は、バックアップを確保し、動作確認の準備を整えたうえで、7.1.3への更新を進めてください。

まとめ

WordPress 7.1.3は、7件のセキュリティ問題と4件の通常の不具合を修正する更新です。コメント管理画面、未公開記事のコメント、エクスポート、権限確認、外部コンテンツの埋め込みなど、複数の機能に修正が入っています。

サイト運営者がまず行いたいのは、バックアップを確認してWordPress本体を更新し、その後に普段使う機能の動作を確かめることです。

特にImgurを利用している場合は、過去の埋め込みと保存済みデータにも目を向けましょう。

「最近更新したから大丈夫」と考えず、管理画面で現在のバージョンを確認し、今回の更新にも対応しておくことが大切です。

スマートフォンでWebサイトを見ると、画面の上部に「≡」のようなメニューボタンが表示されることがあります。

このボタンを押したときに開くメニュー画面を、もっと自由にデザインできるようにしたのが、WordPress 7.0の「カスタマイズ可能なナビゲーションオーバーレイ」です。

メニューのリンクだけでなく、ロゴや検索欄、お問い合わせボタンなどを組み合わせて、サイトに合った案内画面を作れるようになりました。この記事では、従来との違いから基本的な使い方まで、初心者向けに説明します。

ナビゲーションオーバーレイとは？

「ナビゲーション」は、読者を目的のページへ案内するためのメニューを指します。「オーバーレイ」は、元の画面の上に別の画面を重ねて表示することです。

つまり、ナビゲーションオーバーレイとは、メニューボタンを押すと、閲覧中のページの上に重なって表示されるメニュー画面のことです。

読者はメニューから行き先を選んだり、「閉じる」ボタン（「×」アイコンなど）で元のページに戻ったりできます。

なお、この表示方法自体は、WordPress 7.0より前から存在していました。7.0で新しくなったのは、開いたメニュー画面の中身を、ブロックで組み立てられるようになったことです。

従来のメニューと何が違う？

従来の標準オーバーレイは、メニュー項目を表示するための決まった構成が基本でした。サイトの雰囲気に合わせて、画面全体の配置や内容を変更するには制約がありました。

7.0では、サイトエディターでブロックやパターンを使ってデザインできます。パターンとは、複数のブロックを組み合わせた、ひな型のようなものです。専用の閉じるボタンも配置できます。

例えば、通常のヘッダーには短いメニューだけを表示し、メニューボタンを押した画面には、検索欄や詳しい案内をまとめる構成が考えられます。

どのような使い方ができる？

ブログのカテゴリーや検索欄をまとめる

記事数が多いブログでは、カテゴリーへのリンクと検索欄を並べると、読者が目的の記事を探す手がかりになります。

構成例としては、次のような形です。

• サイトロゴ
• ホーム・カテゴリー・プロフィールへのリンク
• 記事を探す検索欄
• SNSへのリンク

お問い合わせや予約への案内を加える

店舗や事業のサイトなら、通常のメニューに加えて「お問い合わせ」「予約する」などのボタンを配置する使い方も考えられます。公式の案内でも、画像やロゴ、行動を促すボタンなどを組み込む用途が紹介されています。

ただし、情報を増やしすぎると、目的のリンクを見つけにくくなることもあります。まずは主要なメニューを分かりやすく配置し、必要な要素を少しずつ追加するとよいでしょう。

基本的な設定方法

ここでは、サイトエディターを利用できるブロックテーマでの基本的な流れを紹介します。

ブロックテーマとは、ヘッダーやフッターなども、ブロックを使って編集できるテーマのことです。

「FSEテーマ」（ブロックテーマ）導入ポイントを解説

WP Pilot

1．ナビゲーションブロックを選択する

管理画面の「外観」→「エディター」から、ヘッダーなどの編集画面を開きます。

続いて、メニュー全体を管理する「ナビゲーション」ブロックを選択します。個別のリンクを選んでしまう場合は、リストビューから探すと選びやすくなります。

2．オーバーレイを作成する

設定サイドバーのオーバーレイ関連の項目から、新しいオーバーレイを作成します。

すでに作成済みのものや、テーマが用意しているものがあれば、それを選ぶこともできます。

3．ブロックを配置して保存する

開いた編集画面で、メニューやロゴなどを配置します。用意されたデザインを出発点にして調整する方法もあります。

編集が終わったら保存し、公開側のページでメニューボタンを押して、表示を確認しましょう。

スマートフォンだけで使う機能なの？

オーバーレイの表示条件（オーバーレイの可視性）には、次の選択肢があります。

「常時」を選べば、パソコンでもボタンを押してメニューを開く構成にできます。スマートフォン専用というわけではありません。

使う前に知っておきたい注意点

更新しただけで既存のメニューが変わるわけではない

カスタムオーバーレイは、利用者が作成・選択するか、テーマ側であらかじめ指定することで使われます。

WordPress 7.0へ更新しただけで、既存のメニュー画面が自動的に新しいデザインへ置き換わるわけではありません。

7.0の初期実装は全画面表示

7.0で導入されたカスタムオーバーレイは、画面全体に表示される形式です。

画面の端から細いパネルだけが出てくるような形式は、初期実装の標準機能では対応していません。

作成したデザインはテーマにひも付く

オーバーレイは「テンプレートパーツ」として管理されます。これは、ヘッダーやフッターのように、サイト内で繰り返し使う部品のことです。

7.0の実装では有効なテーマにひも付くため、テーマ変更先にも自動的に引き継がれるとは限りません。

テーマ独自のメニューとは区別する

今回の機能は、WordPress標準の「ナビゲーション」ブロックに対する拡張です。

テーマが独自に提供するスマートフォン用メニューについては、WordPress本体の更新だけで同じ編集機能が使えるとは限りません。まずは、自分のサイトが標準のナビゲーションブロックを使っているかを確認しましょう。

まとめ

WordPress 7.0のナビゲーションオーバーレイでは、メニューボタンを押したときの画面を、ブロックでデザインできるようになりました。

リンクの一覧にロゴや検索欄などを組み合わせることで、サイトに合った案内画面を作れます。

初めて使う場合は、主要なメニューと閉じるボタンを中心にした、シンプルな構成から試してみましょう。実際のスマートフォンでも、文字の読みやすさやボタンの押しやすさを確認すると、読者に使ってもらいやすいメニューに近づけられます。

2026年9月22日（UTC）、WordPress 7.1.2が公開されました。

今回は、深刻度が「Critical（緊急）」と評価された脆弱性を修正するセキュリティアップデートです。WordPress公式は、サイトを速やかに更新するよう呼びかけています。

WordPress 7.1.1に更新済みのサイトも、今回の対応が必要です。 この記事では、脆弱性の概要と、サイト運営者が行うべき対応を分かりやすく解説します。

追記：セキュリティアップデートが出ています

2026年10月6日付けでセキュリティアップデート WordPress 7.1.3 が出ております。もし7.1にアップデートされておりましたら、7.1.3への追加アップデートのご対応もお願いいたします。

WordPress 7.1.3公開。7件のセキュリティ修正を中心に解説します

WP Pilot

公式情報

• WordPress 7.1.2 リリース – WordPress.org 日本語
• WordPress 7.1.2 Release – WordPress News（英語）
• Unauthenticated path traversal in page-template resolution leading to conditional RCE · Advisory · WordPress/wordpress-develop · GitHub（英語）

WordPress 7.1.2で修正された問題

今回修正されたのは、ページの表示に使用する「テンプレート」を選ぶ処理の脆弱性です。テンプレートとは、ページの構成や表示方法を決めるためのファイルを指します。

公式発表によると、一定の条件下で、ログインしていない攻撃者が、使用中のテーマのフォルダー外にあるPHPファイルを読み込ませられる問題がありました。サーバー環境とテーマの条件がそろうと、外部からコードを実行される可能性があります。

CVSSは、脆弱性の深刻さを共通の基準で評価する仕組みです。今回の9.2という数値は、優先して対応すべき重大な問題であることを示しています。

「リモートコード実行」とは？

リモートコード実行は、英語の「Remote Code Execution」を略して「RCE」とも呼ばれます。外部の攻撃者が、サーバー上でコードを実行できてしまう問題です。

今回の脆弱性では、サーバー上に存在し、読み取り可能なPHPファイルを不正に読み込ませられる点が問題になっています。PHPファイルはプログラムとして動くため、条件によっては深刻な影響につながります。

一般に、RCEが成立した場合には、実行されるコードやサーバー上の権限によって、情報の取得、ファイルの改ざん、サービスの妨害などにつながる恐れがあります。

ただし、これらは想定される影響の説明であり、今回そのような被害が確認されたという意味ではありません。また、「すべてのWordPressサイトで、無条件に攻撃が成功する」という発表でもありません。 公式は、サーバー環境と使用中のテーマについて前提条件があると説明しています。

とはいえ、公開されている説明だけで、自分のサイトがその条件に該当するかを判断するのは困難です。独自の判断で更新を見送ることは避けましょう。

ログイン対策だけでは防げない点に注意

強いパスワードや二段階認証は、アカウントを守るために大切な対策です。

ただし、今回の脆弱性は、攻撃者がログインしていなくても悪用できる可能性がある問題です。そのため、ログイン対策を実施していることは、本体の更新を見送る理由にはなりません。

まずは、脆弱性が修正されたバージョンを適用することを優先してください。

7.1.1や古いバージョンを使っている場合も確認を

今回の問題は、WordPress 7.1.1にも存在します。直前のセキュリティアップデートを適用していても、7.1.2への更新が必要です。

また、旧バージョンの系列も影響を受けます。公式のセキュリティ勧告には、主な修正版として次のバージョンが記載されています。

このほか、4.7系まで修正対象とされています。ただし、リリース記事では、旧系列向けの修正版は準備が整い次第公開すると案内されています。更新画面と公式情報を確認してください。

なお、古い系列に修正が提供されることは、継続的なサポートを保証するものではありません。公式は、積極的にサポートするのは最新バージョンのみとしています。旧系列を使い続けている場合は、今回の修正を適用するとともに、最新系列への移行も検討しましょう。

サイト運営者が行う更新対応

① 現在のバージョンを確認する

まず、WordPress管理画面の「ダッシュボード → 更新」を開き、現在のバージョンを確認します。

自動更新に対応しているサイトでは、すでに更新されている場合があります。「自動更新を設定しているから大丈夫」と考えず、修正版になっていることを実際に確認することが大切です。

複数のサイトを管理している場合は、それぞれ確認してください。

② バックアップを確保する

手動で更新する前に、サイトを復元できるバックアップを確認します。WordPress公式も、更新前のバックアップを案内しています。

確認したいのは、主に次の2つです。

• データベース：投稿本文や各種設定など
• サイトのファイル：画像、テーマ、プラグインなど

レンタルサーバーの自動バックアップを利用している場合も、保存日時と復元方法を把握しておきましょう。

③ 管理画面から更新する

「ダッシュボード → 更新」で、WordPress本体の更新ボタンを押します。更新が完了したら、バージョンが修正版になっていることを確認してください。

管理を制作会社や保守担当者に依頼している場合は、「WordPress 7.1.2で修正された脆弱性への対応状況」を確認すると、用件が伝わりやすくなります。

④ 更新後の表示と動作を確認する

更新後は、日常的に使うページや機能を確認しましょう。

• トップページ、投稿、固定ページが表示されるか
• 管理画面にログインできるか
• 投稿や固定ページを編集できるか
• コメントや会員機能が正常に動くか
• 問い合わせフォームなどが動作するか

サイトが普段どおり表示されていても、セキュリティ上の問題がないとは限りません。

WordPress 7.1や7.1.1を利用している場合は、バックアップを確保し、動作確認の準備を整えたうえで、7.1.2への更新を進めてください。

まとめ

WordPress 7.1.2は、条件によって外部からコードを実行される可能性のある、深刻な脆弱性を修正するアップデートです。公式は速やかな更新を推奨しています。

サイト運営者は、現在のバージョンを確認し、バックアップを確保したうえで修正版を適用しましょう。自動更新を利用しているサイトも、更新が完了しているか確認が必要です。

「更新したつもり」で終わらせず、修正版の適用と更新後の動作確認まで行うことが、今回の対応のポイントです。

2026年9月17日（UTC）、WordPress 7.1.1が公開されました。

今回の更新には、通常の不具合修正に加えて、11件のセキュリティ上の問題を修正する内容が含まれています。WordPress公式は、速やかな更新を推奨しています。

「脆弱性が修正された」と聞いても、自分のサイトにどう関係するのか、分かりにくいかもしれません。

この記事では、修正された問題を一つずつ紹介しながら、サイトへの影響と更新時の注意点を初心者向けに説明します。

公式情報

• WordPress 7.1.1メンテナンスとセキュリティのリリース – WordPress.org 日本語
• Version 7.1.1 – Documentation – WordPress.org（英語）

追記：セキュリティアップデートが出ています

2026年9月22日付けでセキュリティアップデート WordPress 7.1.2 が出ております。もし7.1にアップデートされておりましたら、7.1.2への追加アップデートのご対応もお願いいたします。

WordPress 7.1.2が公開。深刻な脆弱性を修正、サイト運営者は速やかな更新を

WP Pilot

WordPress 7.1.1は、どのような更新？

WordPress 7.1.1は、セキュリティ上の弱点や、既存機能の不具合を修正するための更新です。

今回のセキュリティ修正は、大きく分けると次の3種類に整理できます。

• 不正なスクリプトやHTMLの混入
  ページに意図しない処理や内容が入り込む
• 権限を超えた操作
  本来そのユーザーには許可されていない変更ができる
• 非公開情報の漏えい
  閲覧できないはずの情報の一部を取得できる

ただし、11件すべてが、誰でも同じように悪用できる問題ではありません。 ログインが必要なもの、特定の権限が必要なもの、マルチサイトに関係するものなど、条件は異なります。

以下では、公式に公表された内容と、理解を助けるための説明を区別して紹介します。被害の例は想定される影響であり、今回の脆弱性による実際の被害事例を示すものではありません。

修正された11件の脆弱性

① コメントの段落整形を悪用する「保存型XSS」

WordPressには、文章の改行を段落や改行用のHTMLに変換するwpautop()という関数があります。文章を読みやすく表示するための処理です。

今回は、この処理に関係して、未ログインの訪問者が不正なスクリプトを混入させられる問題が修正されました。公式発表では「コメント承認を条件とする」と説明されています。

「XSS（クロスサイトスクリプティング）」とは、ページに入り込んだ不正なスクリプトが、閲覧者のブラウザーで動いてしまう問題です。そのうち、不正な内容がサイトに保存され、後から閲覧した人に影響するものを「保存型XSS」と呼びます。

コメントを承認制にしていても、悪意ある内容を承認してしまう可能性はあります。コメントを受け付けるサイトでは、承認の運用とあわせて修正版の適用が必要です。

② HTMLコメントの範囲を抜け出せる問題

HTMLコメントは、HTMLのソース内に書く、通常は画面に表示されない注記です。読者が記事に投稿するコメントとは異なります。

WordPressのHTML APIには、周囲のHTML構造を保ちながら文字列を変更するset_modifiable_text()という機能があります。

今回は、特定の文字列によって、HTMLコメントを想定より早く終了させられる問題が修正されました。注記の中に収まるはずの文字列が外へ出ると、その後の内容がHTMLとして解釈される可能性があります。

実際の影響は、この機能がどのような処理で使われているかによって異なります。具体的な攻撃経路や必要な権限は、公表文だけでは確認できません。

③ 一部テーマのカスタムヘッダーにおける保存型XSS

カスタムヘッダーは、対応テーマでサイト上部の画像などを変更する機能です。

今回は、カスタムヘッダーに対応する一部のテーマで、保存型XSSが成立する問題が修正されました。

上記①と同じ種類の問題ですが、不正な内容が入り込む箇所が、ヘッダー画像に関係する処理である点が異なります。

なお、サイトの上部に画像があるだけで、必ず該当するという意味ではありません。対象テーマの一覧は公式発表に記載されておらず、個別のテーマへの影響は、この説明だけでは判断できません。

④ 細工されたURLによってテーマをインストール・プレビューさせられる問題

特殊なURLによって、WordPress.orgにあるテーマのインストールとプレビューが自動的に行われる問題が修正されました。

テーマの追加は、サイトにファイルを設置する管理操作です。通常は、テーマをインストールする権限を持つユーザーが行います。

今回の問題では、URLを通じて、意図しないテーマ操作を起こせる点が重要です。

ただし、公表されているのは「インストールとプレビュー」です。本番サイトのテーマが恒久的に切り替わることや、任意の外部ファイルを設置できることまで示されているわけではありません。

⑤ 個別サイトの管理者がプラグインをネットワーク全体で有効化できる問題

この問題は、1つのWordPressで複数サイトを管理する「マルチサイト」に関係します。

マルチサイトでは、個別サイトの管理者と、ネットワーク全体を管理する特権管理者の役割を分けています。

今回は、個別サイトの管理者が、インストール済みのネットワーク専用プラグインを、ネットワーク全体で有効化できる問題が修正されました。

自分の担当範囲を超えて、ほかのサイトにも影響する操作ができてしまうイメージです。影響の内容は、有効化されるプラグインによって異なります。

通常の単一サイト構成では、このマルチサイト固有の条件には該当しません。

⑥ テンプレート処理における「パストラバーサル」

REST APIは、エディターや外部プログラムなどがWordPressのデータを取得・更新するための仕組みです。

今回は、そのテンプレート処理で、ログイン済みユーザーによるパストラバーサルが修正されました。

パストラバーサル（またはディレクトリトラバーサル）とは、ファイルの場所を指定する情報を悪用し、本来許可されたフォルダーの範囲を越えようとする攻撃です。一般に、想定外のファイルの読み取りなどにつながる可能性があります。

ただし、「ログインが必要」という情報だけで、購読者を含むすべてのユーザーが悪用できるとは判断できません。アクセスできるファイルの範囲など、詳細な条件も公表文には示されていません。

⑦ XML-RPC経由でCSS編集権限の確認を回避できる問題

XML-RPCは、外部アプリなどからWordPressを操作するための通信機能です。

今回は、XML-RPC経由でカスタマイザーの変更データを公開する際に、CSSを編集する権限の確認を回避できる問題が修正されました。

CSSは、文字色、余白、配置など、ページの見た目を決める仕組みです。WordPressでは、カスタムCSSに専用の編集権限が設けられています。

一般に、CSSを不正に変更されると、重要な案内を見えなくするなど、表示を悪用されるおそれがあります。管理画面上の操作を制限するだけでなく、外部から操作する経路でも、同じように権限を確認する必要があることを示す問題です。

⑧ 寄稿者以上のユーザーが任意の投稿を上書きできる問題

寄稿者以上のユーザーが、任意の投稿を上書きできる問題が修正されました。寄稿者は、本来、自分の投稿を作成・編集できますが、自分で公開したり、他人の投稿を自由に編集したりする権限はありません。

投稿が不正に上書きされると、記事の説明が変わったり、リンク先が書き換わったりするなどの被害が考えられます。

外部ライターなどに寄稿者アカウントを渡しているサイトでは、特に注意したい修正です。ただし、上書き可能な項目や投稿種別の細かい範囲は、公表文だけでは確認できません。

⑨ 添付ファイルの情報から非公開投稿のタイトルが漏れる問題

WordPressでは、画像などの添付ファイルに、投稿との紐付けが保存される場合があります。添付ファイルの編集画面には、その紐付け先の投稿名を表示する処理があります。

今回は、親となる投稿の閲覧権限の確認不足によって、非公開投稿のタイトルが漏れる問題が修正されました。

画像を扱える人であっても、その画像に紐付く非公開記事まで閲覧できるとは限りません。

タイトルだけでも、未発表の商品名や社内案件名などが伝わる場合があります。今回公表されている対象はタイトルですが、それだけでも保護すべき情報になり得ます。

⑩ 下書き・承認待ち投稿のスラッグが漏れる問題

寄稿者以上のユーザーに、本来取得できない下書き・承認待ち投稿のスラッグが漏れる問題が修正されました。

スラッグは、投稿URLなどに使う識別文字列です。例えば、URLの末尾にある「new-product」のような部分を指します。

スラッグには記事の題材や商品名を含めることが多いため、未公開の記事の存在や内容を推測する手掛かりになります。

ただし、スラッグを取得できることと、未公開の本文を読めることは同じではありません。今回は、URLに使う文字列の漏えいとして捉える必要があります。

⑪ コメントやノートの親子関係を変更できる問題

ログイン済みユーザーが、ノートを含むコメントの親子関係を変更できる問題が修正されました。

親子関係とは、「どのコメントへの返信なのか」という紐付けです。コメントAへの返信を、コメントBへの返信として付け替えるような操作に当たります。

文章そのものが変わらなくても、返信先が変われば、発言の意味や会話の流れが変わってしまうことがあります。編集上のノートでも、何に対する指摘なのか分かりにくくなるおそれがあります。

公表されている操作は親子関係の変更であり、本文の書き換えや削除まで可能と説明されているわけではありません。

今回の修正から、サイト運営者が理解しておきたいこと

ログインできても、すべての操作が許可されるわけではない

WordPressには、管理者、編集者、投稿者、寄稿者、購読者などの役割があります。それぞれに、実行できる操作の範囲が定められています。例えば、会員としてログインできる人に、ほかの人の記事を編集する権限まで与える必要はありません。

今回の修正には、こうした「その人に許可された操作の範囲」を守るためのものが複数含まれています。

複数人で運営しているサイトでは、更新とあわせて、各ユーザーに必要以上の権限を付けていないか確認するとよいでしょう。

非公開情報は、記事の本文だけではない

記事を非公開にしていても、タイトルやスラッグから内容が伝わる場合があります。例えば、未発表の商品名を記事タイトルやスラッグに含めていれば、その文字列自体が秘密の情報になります。

企業サイトや会員サイトでは、本文だけでなく、周辺の情報も含めて公開範囲を考えることが大切です。

旧バージョンを利用している場合は？

今回のセキュリティ修正は、WordPress 4.7から7.0までの旧系列にも提供されており、該当箇所があれば修正されるようになっています（バージョンによっては、一部機能がその段階では実装されていないなどの理由で、脆弱性の対象範囲外となっている箇所があります）。

主な修正版は次のとおりです。

旧系列への修正提供は、最新系列と同じ継続的なサポートを保証するものではありません。とはいえ、互換性などの事情ですぐに最新系列へ移行できない場合も、利用中の系列に提供された修正版を確認しましょう。

更新前後に確認すること

① 現在のバージョンを確認する

まず、WordPress管理画面の「ダッシュボード → 更新」を開き、現在のバージョンを確認します。

自動更新に対応しているサイトでは、すでに更新されている場合があります。「自動更新を設定しているから大丈夫」と考えず、修正版になっていることを実際に確認することが大切です。

複数のサイトを管理している場合は、それぞれ確認してください。

② バックアップを確保する

手動で更新する前に、サイトを復元できるバックアップを確認します。WordPress公式も、更新前のバックアップを案内しています。

確認したいのは、主に次の2つです。

• データベース：投稿本文や各種設定など
• サイトのファイル：画像、テーマ、プラグインなど

レンタルサーバーの自動バックアップを利用している場合も、保存日時と復元方法を把握しておきましょう。

③ 管理画面から更新する

「ダッシュボード → 更新」で、WordPress本体の更新ボタンを押します。更新が完了したら、バージョンが修正版になっていることを確認してください。

管理を制作会社や保守担当者に依頼している場合は、「WordPress 7.1.2で修正された脆弱性への対応状況」を確認すると、用件が伝わりやすくなります。

④ 更新後の表示と動作を確認する

更新後は、日常的に使うページや機能を確認しましょう。

• トップページ、投稿、固定ページが表示されるか
• 管理画面にログインできるか
• 投稿や固定ページを編集できるか
• コメントや会員機能が正常に動くか
• 問い合わせフォームなどが動作するか

サイトが普段どおり表示されていても、セキュリティ上の問題がないとは限りません。

WordPress 7.1を利用している場合は、バックアップを確保し、動作確認の準備を整えたうえで、7.1.1への更新を進めてください。

まとめ

WordPress 7.1.1では、不正なスクリプトの混入、権限を超えた操作、非公開情報の漏えいなど、11件の脆弱性が修正されました。

それぞれの問題には、ログインの有無やユーザー権限、利用している機能などの条件があります。ただし、見た目に異常がないことや、一部の機能を使っていないことだけで、更新が不要とは判断できません。

サイト運営者は、次の点を確認しましょう。

• 更新前に、ファイルとデータベースのバックアップを確保する
• 利用中のWordPressの系列に対応する修正版を適用する
• 更新後に、記事の編集・画像アップロード・公開ページの表示などを確認する
• 複数人で運営している場合は、ユーザーに必要以上の権限を与えていないか見直す

セキュリティ更新は、記事や利用者の情報を守るための大切な保守作業です。WordPress 7.1を利用している場合は、バックアップと動作確認の準備を整え、7.1.1への更新を進めましょう。

WordPressでは、ブロックエディターの機能強化が続いています。その中でもWordPress 6.9以降、大きく進化しているのが「ブロックの表示・非表示」に関する機能です。

WordPress 6.9では、ブロックを削除せずに一時的に公開ページから隠せるようになりました。

WordPress 7.0ではさらに、画面幅に応じた表示・非表示が可能になっています。

そしてWordPress 7.1では、その画面幅の基準となるブレークポイントを theme.json から変更できるようになり、レスポンシブスタイルの仕組みとも連携するようになりました。

一見すると「非表示機能が少しずつ便利になった」だけにも見えますが、内部の仕組みまで確認すると、

• WordPress 6.9：ブロックそのものを非表示にする
• WordPress 7.0：画面幅ごとに表示・非表示を切り替える
• WordPress 7.1：画面幅の基準をテーマ側で設定し、レスポンシブデザイン全体へ広げる

という段階的な進化が見えてきます。

今回はWordPress 6.9・7.0・7.1で、ブロックの表示・非表示機能がどのように変わってきたのかを、初心者向けに整理します。

公式情報（英語）

• Ability to Hide Blocks in WordPress 6.9 – Make WordPress Core
• Block Visibility in WordPress 7.0 – Make WordPress Core
• Roadmap to 7.1 – Make WordPress Core
• Responsive block styles and configurable viewports in WordPress 7.1 – Make WordPress Core
• WordPress 7.1: Block visibility configurable breakpoints and theme.json integration · Issue #75707 · WordPress/gutenberg

WordPress 6.9：ブロックを削除せず「非表示」にできるようになった

最初の大きな変更は、WordPress 6.9です。

WordPress 6.9では、ブロックを削除せずに公開ページから隠せるブロックの非表示機能がWordPress本体に追加されました。

使用例

例えば、次のような文章があるとします。

キャンペーンが一時的に終了したとき、以前であれば文章を削除したり、下書きとして別の場所に保存したりする必要がありました。

WordPress 6.9以降は、ブロックのメニューから「非表示」にすることで、編集画面には残したまま、公開ページには表示しないという使い方ができます。再び使いたくなった場合は、リストビューなどから「表示」に戻せます。

なお、リストビュー内には、当該ブロックが非表示であることが分かるよう、専用のマークが付きます。

どのような場面で便利？

例えば、以下のような使い方が考えられます。

• 一時的にキャンペーンのお知らせを隠す
• 公開準備中の文章を残しておく
• 後日再利用するセクションを保管しておく
• A案・B案のレイアウトを編集画面内に残しておく

つまりWordPress 6.9の非表示機能は、削除せずに一時保管する機能として考えると分かりやすいでしょう。

WordPress 6.9の「非表示」はHTML自体が出力されない

ここで重要なのが、WordPress 6.9の非表示が単なるCSSの display:none ではないことです。

WordPress 6.9の機能でブロック全体を非表示にすると、公開ページではそのブロックのHTML自体が出力されません。

公式の開発者向け資料でも、非表示にされたブロックは公開時のマークアップから除外されると説明されています。

つまり、通常は「HTMLを出力する→ブラウザに表示される」のに対し、「ブロックを非表示→HTMLを出力しない→公開ページには存在しない」という処理になります。関連するスクリプトやスタイルも、原則として非表示ブロックだけのためには読み込まれません。

ブロックはエディター内で非表示になり、フロントエンドで公開されるマークアップからも除外されます。リストビュー (Shift+Alt+O) で選択して、再度設定を変更できます。

この点は、後述するWordPress 7.0の「モバイルでは非表示」などと大きく異なる部分です。

内部ではBlock Supportsの「visibility」が使われている

少し技術的な話になりますが、この機能はWordPressのBlock Supports（ブロックサポート）という仕組みの一つとして実装されています。

Block Supportsとは簡単に言えば、「このブロックは余白を設定できる」「このブロックは文字色を設定できる」「このブロックは表示・非表示を設定できる」といった、ブロックが利用できる機能を定義する仕組みです。

表示・非表示についてはsupports.visibility という設定が使われます。例えばテーマ・プラグイン開発者は、特定のブロックについてVisibility機能を無効にすることもできます。

なお、ここは少し紛らわしいところです。

supports.visibility は、そのブロックがVisibility機能に対応しているかを表します。

一方、個々のブロックが実際に表示されるかどうかは、ブロックのメタデータに保存されます。この違いはWordPress 7.0以降を理解するうえでも重要です。

WordPress 7.0：スマートフォン・タブレット・パソコンごとに設定可能に

WordPress 7.0では、6.9のVisibility機能がさらに進化しました。

新しく追加されたのが、Viewport（ビューポート）ごとの表示・非表示です。Viewportとは、ここでは簡単に「ブラウザ上でWebページを表示している領域の幅」と考えてください。

WordPress 7.0では、「モバイル（Mobile）」「タブレット（Tablet）」「デスクトップ（Desktop）」という3種類の画面幅について、ブロックを表示するか非表示にするか指定できるようになりました。

これにより、例えば、

• デスクトップで非表示　→ チェックしない
• タブレットで非表示　→ チェックしない
• モバイルで非表示　→ チェックする

とすれば、スマートフォン程度の画面幅でだけブロックを隠せます。

これによって、「パソコンでは詳しい説明を表示するが、スマートフォンでは省略する」といったレスポンシブなページ設計を、WordPress標準機能で行いやすくなりました。

WordPress 7.0ではVisibilityの保存形式も拡張された

内部的には、例えば次のような情報として保存されます。

{
  "metadata": {
    "blockVisibility": {
      "viewport": {
        "mobile": false,
        "tablet": true,
        "desktop": true
      }
    }
  }
}

この場合、mobile: false tablet: true desktop: trueなので、Mobileでは非表示、それ以外では表示という意味です。

ブロックマークアップでは、例えば次のようになります。

<!-- wp:paragraph {"metadata":{"blockVisibility":{"viewport":{"mobile":false}}}} -->
<p>スマートフォンでは非表示になる文章です。</p>
<!-- /wp:paragraph -->

初心者がこのコードを直接編集する必要はありませんが、WordPress内部ではこのようにVisibilityの情報が保存されています。

6.9と7.0では「非表示」の仕組みが違う

ここは特に重要なポイントです。

同じ「非表示」という言葉でも、WordPress 6.9からある全体非表示と、WordPress 7.0で追加されたViewportごとの非表示では、内部処理が異なります。

全体を非表示にした場合

例えば、「このブロックを公開しない」「公開するコンテンツから除外」という設定の場合、

• ブロック：HTMLは生成されない
• DOMに存在しない

という処理になります。こちらは上述のとおりです。

DOMとは、簡単に言えばブラウザがWebページのHTMLを扱うための構造です。

Mobileだけ非表示にした場合

一方、「モバイルでは非表示」とした場合は、以下のような処理となります。

• ブロック：HTMLは生成される
• DOMにも存在する
• CSSでMobile時だけ隠す

という処理になります。

設定時の注意書きにもその旨が記載されています。

ブロックは選択したビューポートに応じて非表示になります。これはフロントエンドで公開されるマークアップに含まれます。リストビュー (Shift+Alt+O) で選択して、再度設定を変更できます。

なぜHTMLを残す必要がある？

これは考えてみると当然です。

例えば、「Mobile → 非表示」「Desktop → 表示」という設定の場合、同じページをパソコンで表示したときにはブロックが必要です。そのためHTMLそのものを削除することはできません。

HTMLを出力しておき、「画面が狭い→CSSで非表示」「画面が広い→CSSで表示」と切り替える必要があるわけです。

WordPress 7.0のブレークポイントは固定だった

WordPress 7.0では、Mobile・Tablet・Desktopの基準となる画面幅は固定されていました。

標準では、おおむね次の区分です。

WordPress 7.0の段階では、このViewportのブレークポイントをテーマ側から自由に変更する仕組みは用意されていませんでした。公式Dev Noteでも、7.0では固定値であり、7.1での設定可能化が予定されていると説明されています。

例えばテーマ側で、「Mobile = 600px以下」「Tablet = 960px以下」のような独自設計を採用していた場合でも、WordPressのVisibility側は480px・782pxを基準としていました。

そのため、テーマのレスポンシブ設計とWordPress標準のVisibilityの基準がずれる可能性があるという問題がありました。

WordPress 7.1：ブレークポイントをtheme.jsonから変更可能に

WordPress 7.1では、この部分が改善されました。

新しく theme.json のsettings.viewportから、MobileとTabletのブレークポイントを指定できるようになっています。

例えば、以下のように設定したといたします。

{
  "version": 3,
  "settings": {
    "viewport": {
      "mobile": "600px",
      "tablet": "900px"
    }
  }
}

その場合、以下のような考え方になります。

• モバイル（Mobile）：600px以下
• タブレット（Tablet）：600px超～900px以下
• デスクトップ（Desktop）： 900px超

なお、指定できる単位は、px em remです。パーセントや単位なしの数値などには対応していません。

settings.viewportはVisibilityにも使われる

重要なのは、settings.viewport が単にエディターのプレビューサイズを変える設定ではないことです。

ここで指定したViewport幅は、

• ブロックのレスポンシブスタイル
• ブロックの表示・非表示
• エディター上のViewportプレビュー

で共通して利用されます。

例えば、以下のように、「モバイルでは非表示」と設定したブロックも、標準の480pxではなく600pxを境界として判定されるようになります。

"settings": {
  "viewport": {
    "mobile": "600px",
    "tablet": "900px"
  }
}

WordPress 7.1ではこのように、Visibilityの画面幅をテーマ設計に合わせやすくなりました。

WordPress 7.1ではスタイルもレスポンシブ化

WordPress 7.1では、Viewportの仕組みがVisibilityだけではなく、ブロックのスタイルそのものへ広げられています。

新しく「Responsive Style States（レスポンシブスタイルステート）」が導入され、MobileやTabletのときだけスタイルを変更できるようになりました。

詳しくは以下の記事で解説しています。

WordPress 7.1でレスポンシブデザインが大きく進化！スマホ・タブレット向けのデザイン調整が簡単に

WP Pilot

「表示／非表示」運用上の注意点

本記事で紹介している機能の注意点についても、下記のとおりまとめておきます。

「カラムをモバイルで縦並び」にする機能とは別

ここで一つ注意しておきたい点があります。

WordPressには以前から「カラム」ブロックなどにレスポンシブ機能があります。

例えば「カラム」ブロックには、「モバイルでは縦に並べる」という設定があります。しかし、これは今回紹介しているViewport VisibilityやResponsive Style Statesと完全に同じ仕組みではありません。

大まかに分類すると、現在のWordPressには、

1. ブロック独自のレスポンシブ処理
2. ViewportによるVisibility
3. Responsive Style States

という複数のレスポンシブ処理が存在しています。

「非表示＝読み込まれていない」とは限らない

もう一つ、実際の運用で重要なポイントがあります。

特にWordPress 7.0以降の、モバイル（タブレット）では非表示については、「スマートフォンでは見えないから、HTMLも読み込まれていない」とは限りません。ViewportによるVisibilityでは、HTMLはDOMに存在し、CSSによって見えなくなっているだけです。

そのため、大きな画像や重いコンテンツをモバイルで非表示にすればスマートフォンの通信量も完全になくなると考えるのは適切ではありません。

Visibilityは基本的に、レイアウトや情報量を画面幅ごとに調整する機能として考えた方がよいでしょう。

パフォーマンス改善を目的とする場合は、画像の最適化や遅延読み込みなど、別の対策も必要です。

一部のブロックではVisibilityを利用できない場合もある

VisibilityはBlock Supportsとして提供されているため、すべてのブロックで必ず使えるとは限りません。ブロック側でVisibilityのサポートが無効化されている場合には、表示・非表示機能が利用できないことがあります。

例えばWordPress 7.0では、カスタムHTMLブロックについてVisibilityのBlock Supportが意図的に無効化されたことが公式記事でも案内されていますし、実際に「表示／非表示」が使用不可となっています。

そのため、「別のブロックでは【表示／非表示】が使えるのに、このブロックには項目がない」という場合、必ずしも不具合とは限りません。

テーマやプラグインによるカスタムブロックについても、そのブロックがVisibilityに対応しているか確認するとよいでしょう。

WordPress 7.1でレスポンシブデザインは大きく変わり始めた

WordPress 6.9から7.1までの流れを見ると、単に「非表示」という小さな機能が追加されたわけではないことが分かります。

WordPress 6.9では、「ブロックを削除せず、一時的に公開ページから隠す」という仕組みが導入されました。

WordPress 7.0では、「画面幅によって表示・非表示を切り替える」ところまで発展しました。

さらにWordPress 7.1では、「Viewportの基準をテーマ側で設定し、表示・非表示だけでなくスタイル変更にも利用する」という形へ進化しています。

つまり、以下のように整理すると、流れを理解しやすいでしょう。

• WordPress 6.9はVisibility機能の出発点
• WordPress 7.0はVisibilityのレスポンシブ化
• WordPress 7.1はViewportをWordPress標準のレスポンシブデザイン基盤として発展させたバージョン

まとめ

最後に、WordPress 6.9・7.0・7.1の違いを簡単にまとめます。

WordPress 6.9

ブロックを削除せず、公開ページから非表示にできるようになりました。

非表示にしたブロックはHTML自体が公開ページへ出力されません。

WordPress 7.0

「モバイル」「タブレット」「PC」ごとに表示・非表示を設定できるようになりました。

こちらはHTML自体を削除するのではなく、CSSを使って画面幅ごとに隠す仕組みです。

ブレークポイントは以下が基本で、7.0では固定でした。

• モバイル：480px以下
• タブレット：480px超～782px以下
• デスクトップ：782px超

WordPress 7.1

theme.json の settings.viewport によって、モバイル（Mobile）・タブレット（Tablet）のブレークポイントをテーマ側から変更できるようになりました。

さらに同じViewportの仕組みを利用して、「文字サイズ」「色」「背景」「枠線」「サイズ」「余白」「レイアウト」などをモバイル・タブレットごとに変更できるレスポンシブスタイルも追加されています。

WordPressのレスポンシブデザインは、従来は各ブロックやテーマ側で個別に対応する部分が多くありました。WordPress 7.1では、それをViewportという共通の考え方で扱うための土台がかなり整ってきたと言えます。

ただし、「カラム」のモバイル縦並びなど従来から存在するブロック独自のレスポンシブ処理まで、すべてが新しいViewportの仕組みに統一されたわけではありません。

そのため現時点では、「WordPress 7.1ですべてのレスポンシブ処理が統一された」というよりも、WordPress標準のレスポンシブデザインを統一していくための重要な基盤が整ったと捉えるのが適切でしょう。

今後WordPressのブロックエディターを使ってサイトを制作するうえでは、「Visibility」と「Responsive Styles」、そして settings.viewport の関係は、ぜひ押さえておきたいポイントになりそうです。

WordPress 7.1では、ブロックエディターのレスポンシブデザイン機能が大きく強化されました。

これまでWordPressで「パソコンでは文字を大きく、スマートフォンでは小さくする」「スマホだけ余白を狭くする」といった調整を行う場合、テーマ側のCSSや追加CSSを使うことが少なくありませんでした。

WordPress 7.1では、新しく「Responsive Style States（レスポンシブ・スタイル・ステート）」という仕組みが導入され、ブロックごとに「タブレット」「モバイル」向けのデザインを設定できるようになりました。

この記事では、WordPress 7.1で何が変わったのかを、できるだけ専門用語を避けながら紹介します。

公式情報

• WordPress 7.1 “メアリー・ルー” – WordPress.org 日本語
• Responsive block styles and configurable viewports in WordPress 7.1 – Make WordPress Core（英語）

追記：セキュリティアップデートが出ています

2026年9月22日付けでセキュリティアップデート WordPress 7.1.2 が出ております。もし7.1にアップデートされておりましたら、7.1.2への追加アップデートのご対応もお願いいたします。

WordPress 7.1.2が公開。深刻な脆弱性を修正、サイト運営者は速やかな更新を

WP Pilot

WordPress 7.1では何が変わった？

まず大きなポイントは、WordPress自身が、「通常のデザイン」「タブレット向けのデザイン」「スマートフォン向けのデザイン」を区別して管理できるようになったことです。

例えば、見出しの文字サイズを次のように設定できます。

• 通常：40px
• タブレット：32px
• モバイル：24px

これまでもCSSを書けば同じことはできました。しかしWordPress 7.1では、これをブロックエディターのデザイン設定として扱えるようになっています。

つまり、「レスポンシブデザイン＝テーマやCSSだけで行うもの」という従来の考え方から、「WordPressのブロック設定としてレスポンシブデザインを管理する」方向へ一歩進んだことになります。

その他の変更点についてはこちらから

WordPress 7.1とは：リリース時点での情報や主な変更点を解説します

WP Pilot

そもそも「レスポンシブデザイン」とは？

レスポンシブデザインとは、パソコン、タブレット、スマートフォンなど、画面の大きさに応じてレイアウトやデザインを変化させる仕組みです。

例えば、パソコンでは、以下のようなレイアウトでも問題ありません。

• 大きな文字を表示する
• 左右に広い余白を取る
• 複数の要素を横に並べる

しかしスマートフォンで同じデザインを使うと、下記のような問題が発生します。

• 文字が大きすぎる
• 余白が広すぎる
• 横並びの要素が窮屈になる

そこで画面幅に応じてデザインを調整するのがレスポンシブデザインです。

WordPress 7.1では「Mobile」と「Tablet」が追加された

WordPress 7.1では、レスポンシブスタイルとして主に次の2つの状態を利用できます。

• Mobile（モバイル）
• Tablet（タブレット）

通常のスタイルを含めると、実質的には3段階です。

WordPress 7.1の標準設定では、Mobileは480px以下、Tabletは480px超～782px以下として定義されています。ただし、テーマ側で設定を変更することが可能のため、必ずしも上記のとおりになるわけではありません。

設定例

ブラウザの幅を縮めたり広げたりすると、以下の文章の文字色や背景色が変わるはずです。

「Desktop」という設定はない

少し注意したいのが、WordPress 7.1には「Desktop」「Tablet」「Mobile」という3つの専用スタイルが用意されているわけではないことです。

正確には、以下のような仕組みとなっています。

• 通常のスタイル
• Tabletで必要な部分だけ上書き
• Mobileで必要な部分だけ上書き

そのため、WordPress内部では@desktopというようなスタイルはありません。メニュー上でも「すべてのビューポートをスタイリング」と説明がございます。

公式の説明でも、通常のスタイルがBase Style（基本スタイル）となり、TabletやMobileでは必要な部分だけを上書きする仕組みになっている、ということになっています。

設定していない項目は通常のデザインを引き継ぐ

ここは初心者の方にも重要なポイントです。

通常の見出しを「文字サイズ：40px、文字色：黒」とします。その後、タブレットで「文字サイズ：32px」だけを変更したとします。

するとタブレットでは「文字サイズ：32px、文字色：黒」になります。文字色についてはTablet側で変更していないため、通常設定の「黒」がそのまま使用されます。

モバイルでも同様です。

つまり、すべての項目をPC・Tablet・Mobileそれぞれで設定し直す必要はありません。変えたいところだけ設定すればよいという仕組みです。

文字サイズだけでなく余白や色も変更できる

WordPress 7.1のレスポンシブ設定は、文字サイズだけに限定されません。

「Core Block Supports」と呼ばれるWordPress標準のスタイル機能に対応した項目で利用できます。公式では、主に次の設定が対象として挙げられています。

• Typography（文字設定）
• Color（文字色など）
• Background（背景）
• Border（枠線）
• Dimensions（サイズ）
• Spacing（余白）
• Layout（レイアウト）

そのため、例えば「グループ」ブロックで「通常 余白：48px」「タブレット 余白：32px」「モバイル 余白：16px」といった調整が可能になります。

これまでCSSを書いて調整していたような部分の一部を、WordPressのデザイン設定として管理できるようになったわけです。

個別のブロックにも設定できる

WordPress 7.1では、サイト全体の設定だけでなく、ページ内に配置した個々のブロックにもレスポンシブスタイルを設定できます。例えば「この見出しだけスマートフォンで小さくしたい」といった調整も可能です。

なお、設定いただくにあたっては、投稿・固定ページ等の「プレビュー」リンクに新たに設置された「レスポンシブスタイル」をチェックいただく必要がございます。

内部的には、ブロックのstyle属性に、@mobileや@tabletという情報が保存されます。

例として、モバイルだけ文字サイズを変更した段落ブロックは、内部的には次のような情報を持つことがあります。

<!-- wp:paragraph {"style":{"@mobile":{"typography":{"fontSize":"1rem"}}}} -->
<p>文章が入ります。</p>
<!-- /wp:paragraph -->

つまり、単にスマートフォン表示をプレビューしているだけではありません。モバイル用のデザインそのものがブロック情報として保存されるのが大きな違いです。

グローバルスタイルからも設定できる

ブロック一つ一つではなく、「サイト内のすべての見出しをスマートフォンでは小さくしたい」という場合には、サイトエディター上のグローバルスタイルを利用することもできます。

例えば、以下のように設定すれば、見出しブロック全体の基本デザインとして利用できます。

見出しブロック
 ├ 通常：40px
 ├ Tablet：32px
 └ Mobile：26px

その上で特定の見出しだけ個別に変更するといった使い分けもできます。

WordPress 7.1の標準ブレークポイント

レスポンシブデザインでは「何pxからデザインを切り替えるのか」という境界が重要です。この境界をブレークポイント（ブレイクポイント）と呼びます。

WordPress 7.1では、標準で次の値が設定されています。

モバイル（Mobile）

@media (width <= 480px)

つまり、480px以下です。

Tablet

@media (480px < width <= 782px)

つまり、480pxより大きく、782px以下です。

全体のイメージ

イメージすると、以下のとおりとなります。

～480px        481～782px        783px～
───────────────────────────────
 Mobile         Tablet           Base

これまでの「プレビュー」と何が違う？

WordPressには以前から、エディターの表示幅を切り替えてスマートフォン表示を確認する機能がありました。しかし、これは主に、「スマートフォンくらいの幅でどう見えるか」を確認するためのプレビューでした。

WordPress 7.1のレスポンシブスタイルでは、「スマートフォンのときは、この文字サイズにする」という実際のスタイル情報を保存できます。ここが大きな違いです。

WordPress側が必要なメディアクエリを生成し、実際のサイト表示にも反映します。

CSSが完全に不要になったわけではない

WordPress 7.1のレスポンシブ機能は便利ですが、CSSがまったく不要になったわけではありません。

現在利用できるのは、基本的にWordPressのブロック設定に対応したデザイン設定です。そのため、「特殊なレイアウト変更」「複雑なアニメーション」「独自のCSSプロパティ」「細かな要素単位の調整」などでは、引き続きCSSが必要になることがあります。

また、自由に何個でもブレークポイントを追加できるわけではありません。基本的には、「Base」「Tablet」「Mobile」という構造です。

したがってWordPress 7.1は、「CSSが不要になるアップデート」というより、これまでCSSで対応していたレスポンシブ調整の一部をWordPress標準機能として扱えるようにしたアップデートと考えるのがよいでしょう。

theme.jsonではブレークポイントを変更できる

ここからは少し開発者向けの内容です。

WordPress 7.1では、テーマのtheme.jsonからMobileとTabletのブレークポイントを変更できます。新しく追加されたのがsettings.viewportです。

例えば、以下のように設定できます（分かりやすくするため、かなり極端な値を入れています）。

{
	"settings": {
		"viewport": {
			"mobile": "30rem",
			"tablet": "45rem"
		}
	}
}

この場合、以下のように解釈されます。

• 30rem以下→ モバイル
• 30rem超～45rem以下 → タブレット
• 45rem超→ 通常

pxだけでなくemやremも利用できる

settings.viewportでは、次の単位を利用できます。

• px
• em
• rem

そのため、"mobile": "600px"でも"mobile": "40rem"でも構いません。

一方、以下の値は使用できません。無効な値を指定すると、その設定は利用されません。

• %
• vw
• 単位なしの数値
• calc()
• その他のCSS関数

実例：テーマ Lightning の例

実際、有名な無償テーマ「Lightning」では、theme.json内に以下のとおり設定されています（該当箇所のみ抜粋）。

		"viewport": {
			"mobile": "576px",
			"tablet": "992px"
		},

ブレークポイントの数値はサイトエディターから変更できない

初心者の方が混乱しやすいポイントとして、settings.viewportそのものは、サイトエディターから自由に変更するための設定ではありません。

サイトエディターでは、「モバイルでは文字を小さくする」「タブレットでは余白を狭くする」といったスタイル変更を行えます。

一方、「Mobileを480pxから600pxに変更する」「Tabletを782pxから900pxに変更する」といったブレークポイントの数値変更はtheme.json側で行います。

整理すると以下のようになります。

【補足】このブレークポイントは「表示／非表示」にも適用されます

詳しくは以下の記事をご覧くださいませ。

WordPressのブロック表示・非表示機能はどう進化した？　6.9・7.0・7.1の違いを初心者向けに解説

WP Pilot

theme.jsonからレスポンシブスタイル自体も設定できる

ブレークポイントだけでなく、テーマ側からMobile向け、Tablet向けのスタイルをあらかじめ設定することもできます。

たとえば、グループブロックの通常の余白を3rem、Mobileでは1remにする場合は、次のように設定できます。

{
	"styles": {
		"blocks": {
			"core/group": {
				"spacing": {
					"padding": {
						"top": "3rem",
						"right": "3rem",
						"bottom": "3rem",
						"left": "3rem"
					}
				},
				"@mobile": {
					"spacing": {
						"padding": {
							"top": "1rem",
							"right": "1rem",
							"bottom": "1rem",
							"left": "1rem"
						}
					}
				}
			}
		}
	}
}

これまでテーマのCSSファイルに書いていたレスポンシブデザインの一部を、theme.jsonのデザイン設定としてまとめられるようになったわけです。

注意：「カラム」ブロックの「モバイル」とは意味が違う

WordPress 7.1では特に注意しておきたい点があります。

「カラム」ブロックには以前から、「モバイルでは縦に並べる」という設定があります。

しかし、この「モバイル」はWordPress 7.1の新しい@mobileと同じ意味ではありません。

WordPress 7.1の新しいレスポンシブスタイルでは「モバイル → 480px以下」です。一方、カラムブロックは従来から、基本的に782px未満で1列化するCSSを持っています。

現在のGutenbergのソースでも、カラムブロックでは$break-mediumとして782pxが使用され、781px以下ではカラム幅を100%にする処理が残っています。

つまり、以下の状態になることがあります。

～480px       　 481～781px       782px～
───────────────────────────────────────────
 Mobile     　    Tablet
   │      　         │
   └─ カラムは縦一列 ─┘        　　横並び

「モバイル」という言葉が2種類あると考えると分かりやすい

少しややこしいのですが、WordPress 7.1では、新しいレスポンシブ機能のモバイル（480px以下）と、従来のカラムブロックでいう「モバイル」（782px未満）が混在しています。

これはカラムブロックのレスポンシブ機能がWordPress 7.1よりずっと前から存在するためです。そして、カラムブロックの固定ブレークポイントを改善するための修正事項も以前から提案されているようですが、実装には至っていません。

したがって、WordPress 7.1ですべてのレスポンシブ処理が480px・782pxという新しい仕組みに完全統一されたわけではない点には注意しましょう。

settings.viewportを変更してもカラムの縦並び境界は変わらない

ここも重要です。

例えばtheme.jsonで以下のように変更したとします。

{
	"settings": {
		"viewport": {
			"mobile": "600px",
			"tablet": "900px"
		}
	}
}

この場合、新しいレスポンシブスタイルでは「Mobile → 600px以下」「Tablet→ 600px超～900px以下」になります。

しかし、だからといってカラムブロックの「モバイルでは縦に並べる」が900pxを基準に変化するわけではありません。カラムブロックには、現在も従来のbreak-medium、つまり782pxを使った独自のCSSがあります。

そのため、settings.viewportはWordPress内のすべてのブレークポイントを一括変更する設定ではありません。正確にはWordPress 7.1で導入されたレスポンシブスタイルやブロック表示制御で使用する共通のViewport設定と考えるのがよいでしょう。

公式記事でも、設定したviewport幅はレスポンシブ・ブロックスタイルやブロック表示制御、エディターのデバイスプレビューで使用されると説明されています。

少なくとも、完全に統一する必要性を感じたら、現時点ではCSSで追加で補正する必要があるわけです。

テーマ制作者にとっても大きな変更

WordPress 7.1以前では、テーマ制作者がレスポンシブデザインを設定するとき、

@media (max-width: 768px) {
	.example {
		font-size: 16px;
	}
}

といったCSSを書くことが一般的でした。

もちろん今後もCSSは必要ですが、WordPress 7.1では、theme.jsonによる仕組みを利用できる場面が増えました。すなわち、WordPressのデザイン設定をよりtheme.jsonに集約しやすくなっています。

特にブロックテーマでは重要な変化でしょう。

レスポンシブ編集自体を無効化することもできる

テーマやサイトによっては、「投稿者にはモバイルやタブレットの設定を変更させたくない」というケースもあります。

WordPress 7.1では、responsiveEditingEnabledというエディター設定が追加されており、レスポンシブ編集のUIを無効化できます。デフォルトはtrueです。

例えば、functions.phpに以下のとおりに記載すれば表示はされなくなります。

function example_disable_responsive_editing( $settings ) {
	$settings['responsiveEditingEnabled'] = false;
	return $settings;
}

add_filter(
	'block_editor_settings_all',
	'example_disable_responsive_editing'
);

ただし、これはレスポンシブ機能そのものを無効化する設定ではありません。すでに保存されているレスポンシブスタイルやtheme.jsonの設定はそのまま利用されます。

あくまで、「ユーザーにレスポンシブスタイルを編集させるUIを表示するかどうか」を決める設定です。

WordPress 7.1以前と比較すると？

今回の変更を簡単に整理すると、次のようになります。

WordPress 7.1は「レスポンシブデザイン完全統一」ではない

WordPress 7.1のレスポンシブ機能は大きな進歩ですが、現時点では「WordPress内のすべてのレスポンシブ処理が一つになった」と考えない方がよいでしょう。

カラムブロックのように、以前から独自のレスポンシブCSSを持つブロックも存在します。

Gutenbergのブレークポイント定義自体にも、現在、分かる範囲だけで以下のような値が残っているようです（今後消去される可能性があります）。

• 1920px
• 1440px
• 1280px
• 1080px
• 960px
• 782px
• 600px
• 480px

したがってWordPress 7.1は、「WordPress全体のレスポンシブデザインが完成した」というよりも、「レスポンシブデザインをWordPress標準のデザインシステムで扱うための共通基盤が本格的に導入された」アップデートと考えると分かりやすいでしょう。

初心者はまず何を覚えればよい？

細かな仕様まで覚える必要はありません。まずは次の3点だけ押さえておけば十分です。

1. WordPress 7.1では「モバイル」「タブレット」ごとにデザインを変更できるようになった
2. 標準では「モバイル」が480px以下、「タブレット」が480px超～782px以下
3. 従来からあるカラムなどのレスポンシブ機能とは、一部仕組みが異なる

特に通常のサイト運営であれば、theme.jsonまで編集する必要はありません。サイトエディターやブロックエディターから必要な部分だけ調整する使い方で十分でしょう。

まとめ

WordPress 7.1では、ブロックのレスポンシブデザイン機能が大きく進化しました。

これまではCSSで対応することが多かった、

• スマートフォンでは文字を小さくする
• タブレットでは余白を減らす
• 画面幅によって背景やサイズを変更する

といった処理を、WordPressのブロックスタイルとして管理できるようになりました。

標準のブレークポイントは、「モバイル：480px以下」「タブレット：480px超～782px以下」「通常：782px超」です。さらにテーマ制作者はtheme.jsonのsettings.viewportを利用して、この境界を変更できます。

一方で、カラムブロックの「モバイルでは縦に並べる」など、従来から存在するレスポンシブ処理までsettings.viewportに統一されたわけではありません。

そのためWordPress 7.1は、レスポンシブ機能の「完成形」というより、WordPress自身がレスポンシブデザインを本格的に管理するための大きな一歩と見るのが適切でしょう。

これまで「スマートフォンだけデザインを変えたいけれどCSSは難しい」と感じていたユーザーにとっても、テーマ開発者にとっても、WordPress 7.1を代表する重要なアップデートの一つといえそうです。

WordPress 7.1「Mary Lou」が、2026年8月19日（UTC）に正式リリースされました。

今回のWordPress 7.1では、スマートフォンやタブレット向けのデザイン調整がしやすくなったほか、画像編集機能、共同作業に便利な「ノート」強化、新しい「タブ」「プレイリスト」ブロックなど、多くの機能が追加・改善されています。WordPress公式によると、7.1には1,500件を超える改善・修正が実施あれています。

変更点が多いため、一見すると難しそうに感じるかもしれません。

しかし、一般的なサイト運営者から見ると、以下のように記事の作成に関わる改善・仕様変更が中心です。

• スマートフォン向けのデザインを調整しやすくなった
• 画像を扱いやすくなった
• WordPressだけで作れるデザインやUIが増えた
• 複数人で記事を確認しやすくなった
• 編集画面がより安定して表示されるようになった

この記事では、WordPressにあまり詳しくない方にも分かるように、WordPress 7.1の主な新機能や変更点を紹介します。

公式情報

日本語

• WordPress 7.1 “メアリー・ルー” – WordPress.org 日本語

英語

• WordPress 7.1 “Mary Lou” – WordPress News（英語）
• WordPress 7.1 Field Guide – Make WordPress Core（英語）
• Client-Side Media Processing in WordPress 7.1 – Make WordPress Core（英語）
• Introducing name and informational tool tips in WordPress 7.1 – Make WordPress Core（英語）
• Responsive block styles and configurable viewports in WordPress 7.1 – Make WordPress Core（英語）

WordPress 7.1の主な変更点

代表的な変更を簡単にまとめると、次のようになります。

一般ユーザーに特に関係が深いものから見ていきましょう。

PC・タブレット・スマートフォン別にデザインを調整できる

WordPress 7.1の中でも特に注目したいのが、レスポンシブスタイルです。特にブロックテーマでは大きく関わりのある機能となります。

「レスポンシブ」とは、パソコン・タブレット・スマートフォンなど、画面の大きさに応じてWebサイトの表示を変える仕組みです。

例えば、以下のような設定が該当します。

• パソコンでは見出しを大きくする
• スマートフォンでは余白を小さくする
• タブレットだけ少し文字サイズを調整する

これまでもWordPressでレスポンシブデザインは可能でしたが、細かな調整を行うにはCSSを書いたり、テーマやブロックプラグインの独自機能を使ったりする場面が少なくありませんでした。

WordPress 7.1では、サイトエディター内の個々のブロック設定から、画面サイズごとにスタイルを変更できるようになりました。

この他、各投稿・固定ページなどでも、個別にスタイルの指定を行うことができるようになっています（こちらはクラシックテーマでも使えます）。

そのため、以下のような調整が、以前よりWordPress標準機能だけで行いやすくなります。

• パソコン：上の余白48px
• タブレット：上の余白32px
• スマートフォン：上の余白16px

編集しながら画面サイズを切り替えてプレビューすることもできます。

theme.jsonにより基準となる画面幅も変更可能

テーマ開発者がtheme.jsonを使って、スマートフォン・タブレットとして扱う画面幅の基準を変更することもできます。

初心者の方は細かな仕組みまで覚える必要はありません。

重要なのは、「WordPress標準機能だけでも、スマートフォン向けのデザインを以前より細かく調整できるようになった」という点です。

WordPress初心者が知っておきたい「theme.json」とは？ 基本から使い方まで分かりやすく解説

WP Pilot

この機能は詳細はこちらから

上述のとおり、こちらはWordPress 7.1の中でも目玉となるアップデート内容となっています。以下の記事で詳しく解説しています。

WordPress 7.1でレスポンシブデザインが大きく進化！スマホ・タブレット向けのデザイン調整が簡単に

WP Pilot

ボタンの「マウスを乗せたとき」のデザインも設定可能に

WordPress 7.1では、「ボタン」ブロックについて、以下のデザインも編集画面から設定できるようになりました。

• hover（ホバー）：マウスポインターをボタンの上に乗せた状態です。
• focus（フォーカス）：キーボード操作などでボタンが選択されている状態です。
• focus-visible ：キーボードのTabキーで操作した時にフォーカスが当たっている状態です。
• active（有効：アクティブ）：ボタンをクリックしている最中などの状態です。

例えば、「通常は青いボタンだが、マウスを乗せると濃い青になる」といった演出があります。

従来はCSSを追加するなり独自ブロックを作成するなりして設定することも多かった部分ですが、WordPress 7.1ではこうしたデザインも標準の編集画面から扱いやすくなっています。

新しい「タブ」ブロックが追加

WordPress 7.1では、「タブ」ブロックが標準ブロックとして追加されました。

「タブ」とは、クリックした項目に応じて表示内容を切り替える仕組みです。

例えば、「基本情報｜料金｜アクセス」という3つのタブを用意し、利用者がクリックした情報だけを表示するといった使い方ができます。

これまでもタブ表示はWordPressサイトでよく使われていましたが、多くの場合、「テーマ独自機能」「ブロック系プラグイン」などを利用する必要がありました。

WordPress本体に「タブ」ブロックが追加されたことで、追加プラグインを使わずにタブ形式のコンテンツを作れるようになった点は大きな変化です。

FAQ、商品比較、施設案内、料金説明など、さまざまな場面で利用できそうです。

音声をまとめられる「プレイリスト」ブロックも登場

もう一つの新ブロックが「プレイリスト」ブロックです。

複数の音声ファイルをまとめて、一つのプレイリストとして表示できます。さらに、再生中の音声を視覚的に表す波形表示にも対応しています。

例えば、「Podcast」「インタビュー音声」「音楽作品」「語学学習用音声」「ラジオ形式のコンテンツ」などを掲載するサイトで利用できます。

一般的なブログでは使用頻度が高くないかもしれませんが、音声コンテンツを扱うサイトにとっては便利な新機能です。

画像編集画面が大きく使いやすくなった

WordPress 7.1では、画像編集機能も大幅に改善されています。従来の簡易的な切り抜き画面に代わり、専用のメディア編集画面（Media Editor Modal）が導入されました。

新しい画面では、「自由な範囲での切り抜き」「左右・上下反転」「細かな角度・一定角度ごとの回転」「一定角度ごとの回転」「画像情報の編集」などを一か所から操作できます。

画像の「Crop（切り抜き）」ボタン自体は残っているため、従来とまったく違う操作方法になったわけではありません。

これまでよりも、WordPress上で画像を整えてから記事に使いやすくなったと考えるとよいでしょう。

画像処理をブラウザ側でも行うようになった

WordPress 7.1では、見た目には分かりにくいものの重要な変更として、Client-Side Media Processing（クライアント側メディア処理）が導入されています。

簡単にいうと、画像をWordPressへ送ってからすべてサーバーで処理するのではなく、利用しているWebブラウザ側でも画像処理を行うという仕組みです。

対応しているブラウザでは、「画像圧縮」「リサイズ」「画像形式の変換」「回転」「サムネイル生成」などをブラウザ上で処理します。

なお、WordPressではWebAssembly版のlibvipsという画像処理技術が利用されています。

なぜブラウザ側で処理するの？

従来、大きな画像をアップロードすると、サーバー側で大量のメモリを消費することがありました。その結果、「メモリ不足」「タイムアウト」「画像処理の失敗」などにつながる場合があります。

ブラウザ側にも処理を分担することで、サーバーへの負担を減らし、大きな画像でも扱いやすくすることが狙いです。

初心者の方は、「画像アップロードの裏側が効率化された」くらいに理解しておけば十分でしょう。

AVIF・HEICなど新しい画像形式への対応も強化

メディア関連では、「AVIF」「HEIC」「HDR gain map」などへのネイティブ対応も強化されています。従来アップロードすることのできなかった形式がアップロード対応するようになりました（ただし、サーバー環境や画像処理系プラグイン側が対応していない場合がございますので、事前にご確認のほどよろしくお願いします）。

特にHEICは、iPhoneなどで撮影した写真で利用されることがある画像形式です。最近のスマートフォンやカメラで作られる画像を、WordPressでより扱いやすくする方向へ進んでいることが分かります。

また、GIFアニメーションを動画へ変換する機能も用意されています。こちらは自動で強制的に変換されるものではなく、必要に応じて利用するオプトイン方式です。

「ノート」がさらに便利に

複数人でWordPressの記事を確認する場合には、「ノート」の強化も注目ポイントです。「ノート」とは、記事の内容についてWordPressの編集画面上でコメントを残せる機能です。

WordPress 7.1では、以下のような操作に対応しました。

• 文章の一部分を選択してNoteを付ける
• 同じブロックに複数のNoteを付ける
• 太字を使う
• 斜体を使う
• コードを表示する
• リンクを貼る
• @を使って他のユーザーを指定する
• 長いNoteを折りたたむ

例えば、「この文章をもう少し分かりやすくしてください」という指摘を、段落全体ではなく該当する文章そのものに付けられます。@ユーザー名のように指定すれば、確認してほしい相手へ通知することもできます。

会社やメディアなどで、「執筆者 → 編集者 → 確認担当者」という流れで記事を作っている場合には、特に便利でしょう。

リアルタイム共同編集はまだ搭載されていない

ここは少し注意が必要です。

WordPressでは以前から、Googleドキュメントのように複数人が同じ記事を同時に編集するリアルタイム共同編集の開発が進められています。しかし、WordPress 7.1ではリアルタイム共同編集そのものは正式搭載されていません。

今回強化されたのは、主にNotesを使った、「一人が編集し、別の人が後から確認・コメントする」タイプの共同作業です。

そのため、「WordPress 7.1からGoogleドキュメントのような同時編集ができるようになった」と考えないよう注意しましょう。

管理バーがエディターでも表示されるように

WordPress 7.1では、画面上部に表示される管理バー（ツールバー）も変更されています。

これまでは、「通常の管理画面」「投稿エディター」「サイトエディター」で画面構成が大きく変わるため、操作していて少し戸惑うことがありました。

WordPress 7.1では管理バーが各エディターでも継続して表示されるようになり、管理画面と編集画面を移動しても同じナビゲーションを利用しやすくなっています。

一見すると小さな変更ですが、WordPress全体の操作感を統一する取り組みの一つです。

投稿エディターがすべてのテーマでiframe化

テーマやプラグインとの互換性という点では、投稿エディターのiframe化も重要です。

WordPress 7.1では、すべてのテーマで投稿エディターがiframeを使う仕組みへ移行しました。

iframeとは、簡単に説明すると、WordPressの管理画面の中に、投稿本文を編集するための独立した領域を作る仕組みです。これによって、「管理画面用CSS」「記事本文用CSS」をより明確に分離できます。

管理画面のCSSが記事編集部分へ意図せず影響する問題を減らし、メディアクエリなどのレスポンシブCSSも編集領域を基準に動作しやすくなります。

通常のユーザーが意識する場面は多くありませんが、編集画面の表示を安定させるための重要な変更です。

古いテーマ・プラグインでは確認が必要

一方で、「独自のエディターCSSを読み込んでいる」「JavaScriptから編集画面を直接操作している」「独自メタボックスを利用している」」といったテーマ・プラグインでは、7.1への対応が必要になる可能性があります。

WordPress 7.1へアップデート後、「公開ページは問題ないのに編集画面だけ表示がおかしい」という場合は、テーマやプラグインとiframe化との相性も確認してみましょう。

SVG Icon APIが公開

WordPress 7.0では「アイコン」ブロックが追加されました。

WordPress 7.0の「アイコン」ブロックとは？使い方や特徴、注意点を分かりやすく解説

WP Pilot

WordPress 7.1ではさらに、SVG Icon APIが一般の開発者向けに公開されています。テーマやプラグインの開発者は、自分で用意したアイコンセットをWordPressへ登録できるようになります。

例えば、「テーマ独自のアイコン」「プラグイン専用アイコン」「SNSアイコン」「ブランド用アイコン」などを、WordPress標準のアイコンシステムへ組み込みやすくなります。

一般ユーザーがAPIを直接触る必要はありません。今後、対応するテーマ・プラグインが増えれば、WordPressの「アイコン」ブロックから選べるアイコンが増える可能性があるという点に注目するとよいでしょう。

メディアライブラリは無限スクロールが標準に

WordPress 7.1では、メディアライブラリのグリッド表示にも変更があります。

画像を下へスクロールしていくと、次の画像が自動的に読み込まれる無限スクロールが標準になりました。SNSなどでよく使われている方式です。そのため、大量の画像を登録しているサイトでは、使用感が少し変わる可能性があります。

「従来のクリック式の方が使いやすい」という方のために、ユーザーごとの設定で従来のページ送り方式へ戻すこともできます。

アクセシビリティも改善

WordPress 7.1では、アクセシビリティにも多くの改善が行われています。

アクセシビリティとは、年齢や障害、操作方法などにかかわらず、できるだけ多くの人がWebサイトやサービスを利用できるようにする考え方です。

今回のアップデートでは、「スクリーンリーダーでの操作」「投稿一覧のラベル」「管理画面の移動」「エディター内の操作」などが改善されています。

開発者向けには、アクセシブルなツールチップを作るためのwp_get_tooltip()やwp_get_toggletip()も追加されています。

開発者向けの仕組みも多数強化

一般ユーザーには見えにくい部分ですが、WordPress 7.1では今後のWordPressを支える仕組みも多く改善されています。

代表的なものが、「Abilities API」「WordPress Design System」などです。

Abilities API

Abilities APIは、WordPressやプラグインが「何ができるのか」を、外部の仕組みから扱いやすくするためのAPIです。

WordPress 7.1では、実行処理や検証、機能の検索などがさらに強化されています。WordPress公式でも、将来的な自動化やAIを利用したツールとの連携に利用できる仕組みとして紹介されています。

ただし、「WordPress 7.1にAI機能が標準搭載された」という意味ではありません。AIなどがWordPressと連携する際の土台が整備されている、と理解した方が正確です。

WordPress Design System

WordPress Design Systemは、管理画面のデザインを統一するための仕組みです。

色や角丸、カーソル表示などを共通化し、WordPress本体やプラグインの管理画面をより一貫した見た目にしていくための基盤となります。

こちらも今すぐ一般ユーザーが操作する機能ではありませんが、今後のWordPress管理画面の変化につながる重要な取り組みです。

パフォーマンス面でも改善

WordPress 7.1では、表示やメディア処理に関するパフォーマンス改善も行われています。特に大きいのは、上記で紹介したブラウザ側での画像処理です。

画像の圧縮・リサイズ・サムネイル生成などをブラウザへ分担することで、サーバーの処理負荷を軽減し、PHPのメモリ不足やタイムアウトを避けやすくしています。

その他、「GIFから動画への変換」「アップロード進捗の表示」「通信が切れた場合の自動再試行」なども追加されています。

WordPress 7.1へすぐアップデートして大丈夫？

WordPress 7.1は正式版ですので、RCやBetaのようなテスト版ではありません。とはいえ、WordPress 7.0から7.1への更新はメジャーアップデートです。

特に仕事用サイトやアクセス数の多いサイトでは、公開直後に何も確認せず更新するよりも、以下の手順で進めていただくことをお勧めいたします。

1. バックアップを取得する
2. テーマ・プラグインを最新版にする
3. 可能ならテスト環境で7.1を確認する
4. WordPress 7.1へアップデートする
5. サイトの表示と管理画面を確認する

今回の7.1では、特に次の部分を確認しておくと安心です。

• 投稿・固定ページの編集画面
• ブロックエディター内のデザイン
• スマートフォン表示
• 画像のアップロード
• 画像編集
• メディアライブラリ
• 独自ブロック
• 独自メタボックス
• テーマ独自の編集機能

とりわけ、投稿エディターの全面iframe化とメディア処理の変更は、テーマ・プラグインとの互換性に関係する可能性があります。更新後は公開ページだけでなく、編集画面も一度確認しておきましょう。

WP Q&A集 (2)：WordPressのアップデートはすぐにしてしまって大丈夫でしょうか？

WP Pilot

WordPress 7.1は「標準機能だけでできること」をさらに増やしたアップデート

WordPress 7.1を全体として見ると、WordPress標準機能だけでWebサイトを作れる範囲を、さらに広げたアップデートと評価できそうです。

特に、以下の設定を見ると、これまでテーマやブロックプラグインに頼ることの多かった機能が、少しずつWordPress本体へ取り込まれていることが分かります。

• レスポンシブスタイル
• 「ボタン」ブロックのhover・focus・active設定
• 「タブ」ブロック
• 「プレイリスト」ブロック
• Icon API

一方で、WordPressの特徴であるテーマ・プラグインが不要になるわけではありません。

むしろ、WordPress本体が基本的な機能を提供し、テーマやプラグインはさらに高度な機能や独自性を提供するという役割分担が進んでいると考えた方がよいでしょう。

さらに、画像処理、Notes、iframe化、Abilities API、Design Systemなどを見ると、今回のアップデートは現在の使いやすさだけではなく、今後のWordPressを見据えた基盤整備も多く含まれています。

まとめ

WordPress 7.1では、非常に多くの改善が行われました。

初心者の方がまず覚えておきたいポイントを絞るなら、

• スマートフォン向けのデザイン調整がしやすくなった
• TabsブロックとPlaylistブロックが追加された
• 画像編集が使いやすくなった
• 画像アップロード・処理の仕組みが改善された
• Notesで記事の確認・共同作業がしやすくなった
• 管理画面と編集画面の操作感が統一されてきた

という6点でしょう。

WordPress 7.1は、何か一つの派手な新機能だけを目玉にしたバージョンではありません。

その代わり、普段のサイト制作や記事作成で感じていた小さな不便を幅広く改善し、WordPressだけでできることを着実に増やしたアップデートとなっています。

特にレスポンシブスタイルや「タブ」ブロックの追加は、今後WordPressでサイトを作るうえで利用する機会が増えていきそうです。

メジャーアップデートであることには変わりませんので、バックアップとテーマ・プラグインの互換性を確認しながら、WordPress 7.1の新しい機能を試してみるとよいでしょう。

記事の概要

質問の詳細

WordPressのサイト制作を外部の業者・フリーランス等に委託するとき、悪質な業者にぶつかってしまい、いざというときに連絡が取れなくなるケースがあります。

質の悪い業者にあたってしまわないようにするにはどうすれば良いでしょうか？ また、運悪くそのような業者に当たった場合、どのようにトラブルを解決すべきでしょうか？

回答の詳細

WordPress制作では「業者への依存」を減らすことが重要

WordPressサイト制作のトラブルというと「悪質な制作会社に騙された」というケースを想像するかもしれません。

しかし、必ずしも悪意があるとは限りません。

例えば、以下のような理由で、突然サポートを受けられなくなることもあります。

• 制作者が病気になった
• フリーランスが廃業した
• 制作会社が倒産した
• 担当者が退職した
• 会社の事業内容が変わった

そのため、業者選びでは、「この会社なら絶対安心だろう」と考えるだけでは不十分です。

むしろ、「明日からこの会社と連絡が取れなくなったとしても、自分のサイトを維持できるだろうか？」という視点を持っておくことが重要です。

WordPressは比較的引き継ぎやすいCMS（Webサイトを管理する仕組み）です。適切に管理されていれば、別の制作会社や制作者へ移管することもできます。

ところが、必要な権限をすべて制作会社側が握ってしまうと、このWordPress本来のメリットを十分に活かせません。

ドメインはできるだけ自分名義で契約する

まず確認したいのが、ドメインの所有者です。ドメインとは、example.comのようなWebサイトの住所にあたるものです。

制作会社によっては、「面倒な手続きはこちらですべて行います」として、制作会社名義でドメインを取得する場合があります。手間がかからないため一見便利ですが、長期的には注意が必要です。

例えば、契約終了後に「ドメインを移管してもらえない」という問題が発生すると、非常に面倒です。サイトのデザインや記事データは作り直せても、長期間使用してきたドメインを失ってしまう影響は小さくありません。

特別な事情がなければ、ドメインはサイト運営者自身の名義・アカウントで契約することをおすすめします。

レンタルサーバーも自分で契約する

ドメインと同じくらい重要なのがレンタルサーバーです。WordPress本体や画像、テーマなどのデータは基本的にサーバー上に保存されています。

そのため、「ドメイン」「サーバー」の両方を業者側が管理していると、トラブルになった際にサイトへアクセスできなくなる可能性があります。

理想的なのは、サイト運営者がレンタルサーバーを契約し、制作会社に必要な作業権限だけを渡す方法です。

こうしておけば、制作会社との契約が終わったとしても、サーバーそのものは手元に残ります。

WordPressの管理者アカウントを必ず持っておく

WordPressには複数のユーザー権限があります。

代表的なものには、「管理者」「編集者」「投稿者」「寄稿者」「購読者」があります（デフォルトではこの5つが設定されています）。このうち、「管理者」はテーマやプラグイン、ユーザー管理などを含め、WordPressサイトのほぼすべてを操作できます。

制作会社へサイト制作を依頼する場合でも、サイト運営者自身の管理者アカウントを1つは確保しておきましょう。

• サイト運営者：管理者
• 制作会社：管理者
• ライター：投稿者

という形にしておけば、一般的には問題ありません。

制作会社との契約終了後は、その会社用の管理者アカウントを削除したり、権限を変更したりできます。

逆に、「セキュリティ上の理由でお客様には管理者権限を渡しません」などと言われた場合は、その理由を詳しく確認した方がよいでしょう。

運営者本人が自分のサイトを管理できない状態には注意が必要です。

契約書や見積書の内容を確認する

制作を依頼するときは、料金だけを見るのではなく、「どこまでやってくれるのか」を確認することが重要です。

最低でも次のような内容は確認しておきたいところです。

• 制作ページ数
• 制作料金
• 納期
• 修正可能回数
• 使用するテーマ
• 使用するプラグイン
• サーバー管理の担当者
• ドメイン管理の担当者
• 保守料金
• 保守内容
• バックアップ方法
• 納品物
• 著作権の扱い
• 契約終了方法
• 契約終了後のデータ引き渡し方法

例えば、「ホームページ制作一式 300,000円」だけでは、具体的に何をしてもらえるのか分かりません。

後になって、「お問い合わせフォームは別料金です」「スマートフォン対応は含まれていません」「修正は1回までです」といった話が出てくる可能性もあります。

契約内容は、できるだけ具体的にしておきましょう。

【雑談】料金表は公開すべきか否か？ メリット・デメリットを解説します

WP Pilot

保守契約を終了するとどうなるか確認する

WordPress制作では、完成後に月額の保守契約を結ぶ場合があります。

保守契約自体に問題はありません。

WordPressは、「WordPress本体」「テーマ」「プラグイン」などを定期的に更新する必要があるため、専門家へ管理を任せるメリットもあります。

注意したいのは、保守契約を終了したらサイトがどうなるのか分からないケースです。契約前に、「保守契約を解除した場合、Webサイトはどうなりますか？」と確認してみましょう。

特に確認したいのは次の点です。

• サイトはそのまま表示できるか
• テーマはそのまま使用できるか
• 有料プラグインは使用できるか
• アップデートできなくなる機能はあるか
• 自分でライセンスを購入すれば継続できるか
• 別の制作会社へ移管できるか

制作会社が複数サイト向けのライセンスを利用している場合、保守契約終了後にそのライセンスが外れること自体は珍しくありません。

重要なのは、そのことが事前に説明されているかどうかです。

制作実績の「デザイン」だけを見ない

制作会社を選ぶとき、多くの人がポートフォリオを確認するでしょう。

もちろん制作実績を見ることは重要です。ただし、「おしゃれなサイトをたくさん作っている」という理由だけで決めるのはおすすめできません。

WordPressサイトでは、見た目以外にも、

• 更新しやすいか
• スマートフォンで見やすいか
• 表示速度に問題がないか
• バックアップが取られているか
• セキュリティ対策が行われているか
• テーマやプラグインが適切に管理されているか
• 別の制作者へ引き継げるか

なども重要です。

完成したサイトの見た目だけでは、こうした部分は分かりにくいものです。

そのため、制作実績を見るときには、「制作後の運用まできちんと考えている会社か」という視点も持っておきましょう。

契約前に少し細かい質問をしてみる

業者選びでは、契約前のやり取りも重要な判断材料になります。

例えば、次のような質問をしてみましょう。

• 契約終了後、別の制作会社へ引き継ぐことはできますか？
• ドメインやサーバーはこちらで契約しても問題ありませんか？
• WordPressの管理者アカウントは受け取れますか？
• 使用予定のテーマやプラグインを教えてもらえますか？
• バックアップはどのように取りますか？
• 保守契約を終了すると使えなくなる機能はありますか？

難しい専門知識を問う必要はありません。重要なのは、質問に対してきちんと説明してくれるかです。

一方、「その辺はこちらに任せてもらえれば大丈夫です」「専門的なことなので説明できません」「契約してから説明します」といった回答ばかりの場合は、少し慎重になった方がよいでしょう。

こんな業者には少し注意しよう

もちろん、一つ当てはまっただけで悪質業者と決めつけるべきではありません。ただし、次のような特徴が複数見られる場合は注意した方がよいでしょう。

• 契約書を作りたがらない
• 見積書の内訳が極端に曖昧
• ドメインを業者名義にしたがる
• サーバーの情報を教えてくれない
• WordPress管理者権限を渡さない
• 使用テーマやプラグインを説明しない
• 解約条件が分からない
• 他社への移管について説明しない
• 契約を急かす
• 即決を条件に大幅値引きをする
• 質問すると態度が急に悪くなる
• 契約終了後にサイトがどうなるのか説明しない

特に、「ドメイン・サーバー・WordPress管理者権限のすべてを制作会社が握っている」という状態は避けたいところです。

優良な業者は「囲い込み」をしない

逆に、信頼しやすい制作会社にはどのような特徴があるのでしょうか。

一つの目安になるのが、「別の会社への引き継ぎを想定しているか」です。

例えば、以下のように進めていただける会社は、比較的安心して付き合いやすいでしょう。

• ドメインは顧客名義
• サーバーも顧客名義
• 管理者アカウントを顧客へ渡す
• テーマやプラグインを説明する
• 操作マニュアルを渡す
• バックアップ方法を説明する
• ライセンス条件を説明する
• 契約終了時の移管にも対応する

良い制作会社とは、「ずっと自社へ依存させる会社」ではなく、「必要であれば他社にも引き継げる状態にしてくれる会社」ともいえます。

すでに怪しい業者と契約してしまったら？

ここからは、すでにトラブルが起きてしまったケースについて考えてみましょう。

まず重要なのは、相手と激しく言い争うことではありません。サイトと証拠を確保することを優先します。

可能であれば、次のものを保存しておきましょう。

• WordPressのバックアップ
• データベース
• 画像
• テーマ
• 子テーマ
• 独自プラグイン
• 契約書
• 見積書
• 請求書
• 支払い記録
• メール
• チャット履歴
• 制作会社から受けた説明資料

制作会社のWebサイトに掲載されている契約条件なども、必要に応じてスクリーンショットを保存しておくとよいでしょう。

管理アカウントやパスワードを確認する

制作会社との契約が終了した場合は、アクセス権限も整理します。

代表的なものとして、以下のようなものがあります（場合によっては使用していないこともあるかと思います）。

• WordPress
• レンタルサーバー
• FTP・SFTP
• ドメイン管理サービス
• Google Analytics
• Google Search Console
• Googleアカウント
• CDNサービス

制作会社用のアカウントが残っている場合は、不要になったタイミングで削除することも検討しましょう。ただし、契約上の争いが続いている途中で一方的にアクセスを遮断すると、新たな問題になる可能性もあります。

特に金額の大きなトラブルである場合や争いが長期化しそうになっている場合は、専門家に相談しながら進めた方が安心です。

連絡はできるだけ記録に残す

業者とトラブルになったとき、電話だけでやり取りするのはおすすめできません。

できるだけ、「メール」「チャット」「書面」など、履歴が残る方法を使用しましょう。

例えば、「○月○日にお願いした○○について、現在まで回答をいただいておりません。○月○日までに状況をご回答ください。」というように、何を・いつ依頼し・いつまでに回答を求めているのかを明確にします。

重要な契約トラブルになっている場合には、内容証明郵便などを検討する場合もあります。

別のWordPress制作者にサイトを見てもらう

技術的な状況が分からない場合は、別のWordPress制作者へ相談する方法もあります。

その際は、「現在の制作会社と連絡が取れなくなっても、このサイトを維持できる状態か確認してください。」とお願いすると分かりやすいでしょう。

以下のような状態であれば、比較的スムーズに別の業者へ引き継げる可能性があります。

• サーバーへアクセスできる
• WordPress管理者権限がある
• ドメインを管理できる
• バックアップを取得できる

一方、以下のような場合には、ライセンスも含めた複雑な移行作業が必要になり、工数がかさむことがあります。

• 独自テーマへ大きく依存している
• 独自プラグインを使用している
• 制作会社独自のシステムと連携している
• 有料プラグインが制作会社のライセンスになっている

お金や契約の問題になったら専門機関へ相談する

料金を支払ったのにサイトが完成しない、契約内容と明らかに違う、ドメインやデータの引き渡しを拒否されている、といったケースになると、WordPressの技術問題だけでは解決できません。

契約や金銭をめぐる問題になった場合は、「弁護士」「自治体などの法律相談」「取引トラブルに関する相談窓口」などへ相談することも検討しましょう。

特に高額な制作費が絡んでいる場合は、自己判断だけで無理に解決しようとしない方が安全です。

WordPress制作を依頼するときの5つの自衛策

さまざまな注意点を紹介しましたが、最低限押さえておきたいのは次の5つです。

1. ドメインを自分名義で契約する
2. レンタルサーバーを自分名義で契約する
3. WordPress管理者アカウントを持つ
4. 契約終了時の引き継ぎ方法を確認する
5. 自分でもバックアップを確保する

この5つを守るだけでも、「制作会社と連絡が取れなくなり、サイトまで動かせなくなった」という最悪の事態を防ぎやすくなります。

「安い業者＝悪い業者」とは限らない

最後に注意したいのが、料金だけで良し悪しを判断しないことです。

個人で活動しているフリーランスでも、非常に丁寧な仕事をする制作者はいます。反対に、有名な制作会社だから絶対に問題が起きないとも限りません。

特に大切なのは、以下のような点です。

• 契約内容をきちんと説明してくれるか
• 質問へ丁寧に答えてくれるか
• 管理権限を明確にしているか
• 過度な囲い込みをしていないか
• 契約終了後まで考えられているか

料金や会社規模よりも、「サイトを誰のものとして扱っているか」を見ると、業者選びの判断材料になりやすいでしょう。

まとめ：良い制作会社は「いつでも引き継げるサイト」を作ってくれる

WordPressサイト制作では、デザインや料金だけに注目しがちです。

しかし、長くサイトを運営するのであれば、管理権限・契約・バックアップ・引き継ぎについても確認しておく必要があります。

特に重要なのは、「この業者がいなくなっても、自分のサイトを維持できるか」という視点です。どれだけ信頼している制作会社でも、将来何が起こるかは分かりません。

ドメインやサーバーを自分で管理し、WordPress管理者権限とバックアップを確保しておけば、万が一のときにも別の制作者へ相談しやすくなります。

良いWordPress制作会社とは、顧客を囲い込む会社ではありません。

必要になったとき、別の制作会社へ問題なく引き継げるWebサイトを作ってくれる会社。この点を一つの判断基準として、安心して長く付き合える制作パートナーを探してみてください。

記事の概要

質問の詳細

WordPressを使い始めたばかりなのですが、管理画面に「WordPressアップデート」のお知らせが出てきました。調べてみると「メジャーアップデート」と「マイナーアップデート」があるようですが、違いがよく分かりません。

新しいバージョンが出たら、すぐにアップデートしてしまって大丈夫なのでしょうか？

回答の詳細

WordPressには「メジャー」と「マイナー」のアップデートがある

WordPressのバージョンは、たとえば次のように表記されます。

• WordPress 7.0
• WordPress 7.0.1
• WordPress 7.0.2
• WordPress 7.1

このうち、大きく分けると次のように考えられます。

WordPressでは、メジャーアップデートでも既存サイトとの互換性をできるだけ維持するように開発されています。そのため、「メジャーアップデートをすると必ずサイトが壊れる」というわけではありません。

一方で、新機能や内部仕様の変更が比較的多く含まれるため、マイナーアップデートより慎重に確認した方がよい場面があります。

マイナーアップデートで気をつけたいこと

まずは「7.0 → 7.0.1」のようなマイナーアップデートから見ていきましょう。

基本的には早めのアップデートがおすすめ

マイナーアップデートには、不具合の修正だけでなく、セキュリティ上の問題を修正する内容が含まれることがあります。

そのため、「不具合が怖いから、しばらくアップデートしないでおこう」と長期間放置するのは、必ずしも安全とはいえません。特にセキュリティリリースとして公開されている場合は、更新しないことで既知の脆弱性が残ってしまう可能性があります。

基本的には、内容を確認したうえで早めにアップデートすることをおすすめします。

マイナーアップデートは自動更新されることもある

WordPressでは、マイナーアップデートやセキュリティアップデートが自動的に適用されることがあります。特に、functions.phpや外部プラグイン等で制限を入れていなければ、マイナーアップデートの自動更新を止めることはできません。そのため、「自分で更新ボタンを押していないから大丈夫」とは限りません。

また、利用しているレンタルサーバーによっては、WordPress本体を自動的にアップデートする独自機能が用意されていることもあります。

「WordPress本体の自動更新設定」「レンタルサーバー側の自動更新設定」「WordPress管理サービスなどの設定」を確認しておくとよいでしょう。

マイナーアップデートでも動作確認はしておこう

マイナーアップデートは比較的小規模な変更が中心ですが、だからといって絶対に問題が起こらないとは限りません。テーマやプラグイン、独自カスタマイズとの組み合わせによって、不具合が表面化することがあります。

更新後には最低限、「トップページ」「投稿・固定ページ」「管理画面」「ブロックエディター」「お問い合わせフォーム」「ログイン画面」などを確認しておくと安心です。

ECサイトの場合は購入処理、会員サイトの場合はログインや会員登録など、そのサイトにとって特に重要な機能も確認しておきましょう。

メジャーアップデートで気をつけたいこと

続いて、「7.0 → 7.1」のようなメジャーアップデートです。

メジャーアップデートでは、新しい機能や仕様変更などが比較的多く含まれます。そのため、マイナーアップデートより少し慎重に進めるのがおすすめです。

まずバックアップを取る

最も重要なのがバックアップです。万が一アップデート後に問題が発生しても、バックアップがあれば以前の状態へ戻せる可能性があります。

ここで注意したいのは、データベースだけをバックアップすれば十分とは限らないことです。

WordPressサイトには、

• 投稿や固定ページなどが保存されたデータベース
• テーマ
• プラグイン
• アップロードした画像
• 各種設定ファイル

など、数多くのファイルによって構成されており、アップデートの前後にデータベース以外のファイルにも不都合が出る場合があります。

できれば、データベースとWordPressのファイルの両方をバックアップしておきましょう。

さらに理想的なのは「バックアップを取ったことがある」というだけではなく、「必要になったら実際に復元できる」状態にしておくことです。

レンタルサーバーの自動バックアップを利用している場合も、復元方法まで一度確認しておくと安心です。

テーマとプラグインの対応状況を確認する

WordPress本体だけが動いても、サイト全体が正常に動くとは限りません。

WordPressでは、「WordPress本体」「テーマ」「プラグイン」が組み合わさってサイトが動いています。特にメジャーアップデートの前には、利用しているテーマや主要プラグインが新しいWordPressに対応しているか確認しておくとよいでしょう。

特に注意したいのは、以下のようなWordPressサイトです。

• 長期間アップデートされていないプラグイン
• 開発が終了しているテーマ
• 独自開発したテーマやプラグイン
• functions.phpに多くの独自コードを書いているサイト
• WooCommerceを利用したECサイト
• 会員サイト
• 予約サイト

一般的なブログよりも、多くの機能を組み合わせたサイトほど影響を受ける可能性があります。

WordPress本体だけでなく、テーマ・プラグインも確実にアップデートを行う

意外に見落としやすいポイントです。

WordPressの新しいバージョンが公開される前後には、テーマやプラグイン側でも互換性を確保するためのアップデートが行われることがあります。そのため、「WordPress本体だけ最新」「テーマやプラグインは数年前のまま」といった状態は避けた方がよいでしょう。

WordPress本体だけでなく、サイト全体を定期的にメンテナンスすることが大切です。

メジャーアップデートは公開直後に入れなくてもよい？

これはサイトの性質によります。

個人ブログなど比較的シンプルなサイトであれば、バックアップを取ったうえで比較的早めにアップデートしても問題ないケースが多いでしょう。一方、企業サイトやECサイト、会員サイトなどの場合は、公開直後に本番環境へ適用せず、少し状況を確認してから更新する方法もあります。

新しいメジャーバージョンが公開された直後には、「WordPress本体の不具合」「テーマとの互換性問題」「プラグインとの互換性問題」などが見つかる場合があります。その後、修正版となるマイナーアップデートが比較的早い段階で公開されることもあります。

そのため、「メジャーアップデートは絶対に公開当日に入れなければならない」というものではありません。

ただし、セキュリティに関する重要な修正が含まれている場合などは事情が変わります。単純にバージョン番号だけを見るのではなく、アップデート内容を確認して判断することが重要です。

重要なサイトなら「ステージング環境」で確認しよう

企業サイトやECサイトなど、停止すると大きな影響が出るサイトでは「ステージング環境」を利用する方法もあります。ステージング環境とは、簡単にいえば本番サイトとは別に用意したテスト用のコピーサイトです。

例えば、以下のような手順で確認できます。

1. WordPress 7.0の本番サイト
2. ステージング環境を作成
3. ステージング環境だけWordPress 7.1へアップデート
4. テーマ・プラグイン・各機能を確認
5. 問題なければ本番サイトもアップデート

上記の進め方であれば、不具合が発生しても本番サイトには直接影響しません。重要度の高いサイトほど有効な手法となり得ます。

レンタルサーバーによっては、ステージング環境を簡単に作成できる機能が用意されていることもあります。

【サーバー選び】エックスサーバー系4サービスを比較。WordPress運用の仕組み・料金・強みの違いについて

WP Pilot

アップデート前に確認しておきたいポイント

WordPressをアップデートするときは、少なくとも次のポイントを意識しておくとよいでしょう。

• WordPressの更新内容を確認する
• バックアップを取る
• テーマを最新版にしておく
• プラグインを最新版にしておく
• テーマ・プラグインの対応状況を確認する
• 独自カスタマイズがある場合は注意する
• アップデート後に主要ページを確認する
• フォームやログインなど重要機能を確認する

サイトの規模が大きい場合は、さらにステージング環境で事前確認を行うと安心です。

「マイナーだから安全」「メジャーだから危険」とは限らない

WordPressのアップデートを考えるうえで、特に覚えておきたいのがこの点です。

例えば、「7.1 → 7.1.1だから、たいした更新ではないだろう」とは限りません。マイナーアップデートであっても、重要なセキュリティ修正が含まれることがあります。

反対に、「7.0 → 7.1だから、大きな問題が起こるかもしれない」などと過度に怖がる必要もありません。WordPressは既存サイトとの互換性を重視しながら開発されています。

大切なのは数字だけではなく、「今回のアップデートでは何が変更されたのか」を確認することです。

アップデートしないこと自体が安全とは限らない

WordPressでありがちな誤解として、「動いているサイトには触らない方が安全」という考え方があります。

確かに、更新した直後に不具合が発生する可能性はゼロではありません。しかし、WordPress本体やテーマ、プラグインを長期間アップデートしなければ、今度はセキュリティ上の問題が残ったままになる可能性があります。

古いプラグインが新しいPHPに対応しなくなったり、一気に何年分もの更新をしなければならなくなったりすることもあります。

そのため、「更新しないことでリスクを避ける」のではなく、「安全に更新できる環境を整える」という考え方が重要です。

マイナーアップデートとメジャーアップデートの違いをまとめると

最後に簡単に整理してみましょう。

マイナーアップデート

7.0から7.0.1のように3番目の数値が上がる更新です。不具合修正やセキュリティ修正が中心となるため、基本的には早めの適用を考えます。

ただし、自動更新される場合もあるため、更新後にはサイトの主要部分が正常に動作しているか確認しておきましょう。

「WordPress 7.0.4」セキュリティアップデート――Imagick・Ghostscriptを悪用したRCE脆弱性を修正

WP Pilot

【メモ】WordPress 7.0.2／6.9.5／6.8.6で修正された脆弱性について

WP Pilot

メジャーアップデート

7.0から7.1のように2番目の数値が上がる更新です。

新機能や仕様変更が比較的多いため、「バックアップ」「テーマやプラグインの対応確認」「更新後の動作確認」をより意識して行うことが重要です。

重要なサイトでは、ステージング環境を使って事前確認するとさらに安心です。

WordPress 7.0とは？ 主な変更点を解説します

WP Pilot

WordPress 6.9の主な変更点について

WP Pilot

まとめ

WordPressは定期的にアップデートされ、新機能の追加だけでなく、不具合やセキュリティ上の問題も修正されています。そのため、基本的には最新版へ更新しながら使っていくことが望ましいでしょう。

ただし、マイナーアップデートは比較的早めに対応し、メジャーアップデートはバックアップや互換性を確認しながら慎重に進めるという違いを意識しておくと、より安全に運用できます。

また、重要なのはアップデートそのものを怖がり、更新を止めることではありません。

普段から、「バックアップを取る」「WordPress本体を放置しない」「テーマやプラグインも更新する」「更新後に動作を確認する」といった習慣を身につけておくことが大切です。

WordPressは「アップデートしない方が安全なCMS」ではなく、「安全にアップデートできるように管理しながら使うCMS」と考えると分かりやすいでしょう。