WordPress 7.0の延期が明かす、セキュリティ最優先の開発哲学

つくば市のホームページ制作会社

WordPress 7.0の開発が進む中、リリース日が4月9日から5月20日に延期された。この変更は単なるスケジュール調整ではない。WordPressコア開発チームが「最も安定し、最もパフォーマンスに優れたソフトウェアを提供する」ために取った、慎重な判断だった。

昨年来のWordPress界隈の複雑な状況を踏まえ、開発陣はスケジュールよりも品質を重視する姿勢を明確にした。アーキテクチャの安定性とパフォーマンスに追加作業が必要と判断し、結果として約1ヶ月半の延期となった。制作現場で安定稼動が何より重要なWordPressにとって、これは理にかなった決断といえる。

セキュリティ強化が加速する2026年のWordPress

WordPress 7.0の延期と並行して、WordPress 6.9.2がセキュリティリリースとして公開された。修正内容を見ると、Blind SSRFの問題、HTML APIとBlock Registryの弱点、数値文字参照での正規表現DoS脆弱性など、技術的に高度な攻撃に対応している。

2026年のWordPressセキュリティ状況は、2024年に約8,000件の新しい脆弱性が発見され、2月には244件の新しい開示があり、うち80件が未修正という深刻なレベルにある。この状況を受けて、2026年のWordPressセキュリティ環境は大幅に変化し、HTML APIの強化、自動プラグインスクリーニング、認証制御の改善により、より安全な基盤を構築している。

特に注目すべきはWordPressがセキュリティアップデートを重要度別に分類し、重要なパッチは2〜4時間以内に自動デプロイされる仕組みが整備されたことだ。制作会社にとって、クライアントサイトの安全性を保つために自動アップデートの設定確認が必須の作業となっている。

プラグインエコシステムの脆弱性対策

WordPressの最大の強みであるプラグインシステムが、同時に最大のセキュリティリスクになっている現実がある。新しい脆弱性の91%がプラグインで発見され、9%がテーマ、WordPressコアでの報告はわずか6件で低優先度の問題だった。

プレミアムやフリーミアムコンポーネントで1,983件の有効な脆弱性レポートがあり、総レポートの29%を占める状況は、制作現場での慎重なプラグイン選択を求めている。12ヶ月以上アップデートされていないプラグインは代替品を探すことが推奨されており、定期的な棚卸しが重要になっている。

WooCommerceでもStore API脆弱性が52のバージョンで修正され、特定のブラウザ環境でログイン済み管理者が悪意のあるリンクを訪問した場合に管理者アカウントの作成などが実行される可能性があった。E-コマースサイトを運営する場合、こうしたアップデートへの迅速な対応が欠かせない。

WordPress 7.0が目指すコラボレーション機能

WordPress 7.0はGutenbergプロジェクトのPhase 3の決定版的ローンチであり、コラボレーションとワークフローに完全に焦点を当て、「単独エディター」モデルから共有リアルタイム創作環境への移行を目指している。

具体的には複数ユーザーが同じ投稿やページを同時編集でき、デフォルトのHTTPポーリング同期プロバイダーを搭載し、ホストやプラグインがWebSocketサポートを追加できるフック、オフライン編集の同期、Notesリアルタイム同期などが実装される予定だ。

チーム制作が主流になりつつある現在、これらの機能は特に代理店や制作会社にとって業務効率向上の要となりそうだ。ただし、リアルタイムコラボレーション機能、Web Client AI API、レスポンシブブロック表示制御は、サードパーティプラグインが拡張する領域に関わるため、事前のテストが強く推奨されている。

実務での対応方針

WordPress 7.0への移行準備として、最小PHPバージョンが7.4に引き上げられ、PHP 7.2と7.3のサポートが正式に廃止、最適なパフォーマンスとセキュリティのためPHP 8.3以上が推奨される。つくば周辺の制作者も含め、レンタルサーバーのPHP環境確認は早めに済ませておきたい。

延期によりRC 3(新Beta 1)が5月8日、5月20日の正式版まで最終テスト期間が設けられた。この期間を活用して、使用中のテーマやプラグインの互換性を入念にチェックし、本格導入は正式リリース後2〜4週間の安全期間を置くのが現実的だろう。

セキュリティ脅威が多様化し高度化する中で、WordPressは単なる機能追加よりも安定性と安全性を重視する方向性を明確にした。延期という判断にも表れているように、制作現場の実務を支える基盤としての責任を果たそうとするその姿勢は、長期的にはユーザーにとってプラスになるはずだ。

WordPress 6.8で実現するページの先読み技術、Speculation Rules APIの実用性

つくば市のホームページ制作会社

WordPressの最新版6.8「Cecil」では、Speculation Rules APIによる先読み機能がコアに統合されました。この機能により、ユーザーのクリック前にページを先読みすることで、Largest Contentful Paint(LCP)のパフォーマンスが大幅に改善し、設定によってはページの即座読み込みも実現可能となっています。

Speculation Rules APIは、ユーザーの行動を予測してページやリソースを事前に読み込む最適化技術で、JSON形式でルールを定義してブラウザに先読みの指示を出す仕組みです。現在はChrome、Edge、OperaなどのChromium系ブラウザでサポートされており、Safari や Firefox では機能は無視されるものの、悪影響はなく、単に先読みの恩恵を受けられないだけです。

WordPress 6.8では、デフォルトで保守的な設定が採用されており、クエリパラメーターやハッシュフラグメントのないアンカーリンクに対してのみ先読みが適用されます。現時点では先読み(prefetch)モードと保守的(conservative)な積極性が採用されており、ユーザーがリンクと相互作用したときにURLが先読みされる仕組みです。

実際のパフォーマンス向上効果

この機能の効果は実際のサイト運営で確認されています。複数のクライアントサイトでのテストでは、体感的なページ読み込み時間が最大40%短縮された事例も報告されています。ユーザーからの評価では、なぜかは言葉で表現できないものの、先読み機能を有効にしたサイトの体験を好む傾向があり、「サイトがより高級に感じる」という反応も得られているとのことです。

ただし、先読み機能は同一サイト内での別ページへの遷移時にのみ効果を発揮するため、個別のURLに対するベンチマークテストでは効果を測定できず、実際のユーザー体験では測定結果以上の改善効果が期待できます。

WordPress 6.8のコア機能では保守的な先読みのみですが、専用のSpeculative Loadingプラグインを使うことで、より積極的な事前レンダリング機能を利用でき、設定画面から先読みの方式と積極性をカスタマイズすることも可能です。制作現場では、サイトの性質に応じてこれらの設定を調整することで、さらなるパフォーマンス向上が見込めるでしょう。

制作者が知っておくべきウェブ技術の新動向を整理してみた

つくば市のホームページ制作会社

春の新しい技術や動向が出揃ってきたので、今知っておきたいウェブ制作・WordPress・セキュリティの動きを整理してみました。それぞれがどう制作現場に影響するか、中小企業サイトでどう活用できるかという視点で見ていきます。

WordPress 7.0の準備が本格化

WordPress 7.0は2026年5月20日にリリース予定で、現在RC(リリース候補版)の最終テストが行われています。リアルタイム共同編集機能がGutenberg Phase 3の一環として導入される見込みで、複数人でのコンテンツ制作が大きく変わりそうです。

ただし、この機能にはWebSocket接続をサポートするホスティングが必要になる可能性があるため、現在のサーバー環境が対応しているかの確認が必要です。システム要件もPHP 7.4以上、MySQL 8.0またはMariaDB 10.6以上に引き上げられるため、古い環境からのアップグレード計画も立てておきたいところです。

WordPress 6.9.1のメンテナンスリリースも2月に配布済みで、49件のバグ修正が含まれています。メジャーバージョンの前に安定性を確保する流れが見えています。

CSS コンテナクエリがようやく実用段階に

コンテナサイズクエリは、Chrome 105+、Firefox 110+、Safari 16+、Edge 105+で95%以上のグローバル対応を達成し、制作現場で本格的に使えるレベルになりました。2015年から求められていた機能が、ついに全主要ブラウザで実際に動作する状況です。

コンテナクエリの何が変わるかというと、コンポーネントがビューポートサイズではなく、親コンテナのサイズに基づいてスタイルを調整できることです。同じカードコンポーネントをサイドバーに配置しても、メディアクエリだとページ幅を見てしまうが、コンテナクエリならサイドバーの幅に応じて適切にレイアウトが変わるというわけです。

ただし、スタイルクエリ(@container style())はChrome 111+とEdge 111+のみ対応で、FirefoxとSafariはまだ開発中なので、段階的な導入が賢明でしょう。

Core Web VitalsのINPが本格始動

Interaction to Next Paint(INP)は2024年3月にFirst Input Delay(FID)に代わってCore Web Vitalになりましたが、2026年に入ってその影響が本格化しています。

2026年初頭のCrUXデータによると、43%のウェブサイトがINPの200ミリ秒の閾値をクリアできず、最も失敗率の高いCore Web Vitalとなっています。FIDからINPへの移行により、モバイルのCore Web Vitals合格率が約5ポイント低下しており、多くのサイトで対応が急務です。

INPがFIDより厳しいのは、最初のインタラクションだけでなく全てのインタラクションを測定し、入力遅延だけでなく処理時間と描画遅延も含むためです。重いアニメーションや複雑なJavaScriptが動くサイトでは、パフォーマンスの見直しが必要になるでしょう。

WordPressセキュリティの新たな脅威

4月のセキュリティ動向で注目すべきは、Essential Pluginポートフォリオの31個のプラグインで、所有者変更後にバックドアが仕込まれ、8か月間潜伏した後に数千のサイトが感染した事件です。

WordPressはプラグインの所有者変更をユーザーに通知しない仕様のため、信頼していたプラグインが密かに悪意のあるコードを含むようになっても気づけません。最近の1週間だけで185件の新しい脆弱性が発見されており、そのうち16件は未修正という状況も踏まえると、定期的なセキュリティ監査の重要性が高まっています。

2026年には商用WordPressプラグインは法的にEU圏ユーザーに提供するため脆弱性開示プログラム(VDP)の設置が義務化される予定で、セキュリティ体制の透明性がより求められるようになります。

実務への影響を考える

これらの動向を踏まえ、制作現場で今できることを整理すると、WordPress 7.0に向けては現行サーバー環境の要件確認、コンテナクエリは既存メディアクエリとの併用での段階導入、INP対策は重いJavaScriptの見直しとパフォーマンス測定の習慣化、セキュリティは月次でのプラグイン監査の仕組み作りが挙げられます。

3つのCore Web Vitalsすべてをクリアしたサイトは、失敗サイトと比べて離脱率が24%低く、オーガニック検索トラフィックの改善も確認されているという調査結果も出ているため、パフォーマンス改善の投資対効果は明確です。

新技術の導入は一度にすべて対応する必要はありません。現在運用中のサイトの安定性を保ちながら、段階的に新しい手法を取り入れて、ユーザー体験の向上につなげていくのが現実的なアプローチでしょう。

3-1 コンテンツ管理システム(CMS):人気のCMSの比較(WordPress、Joomla、Drupal等)

3-1 コンテンツ管理システム(CMS):人気のCMSの比較(WordPress、Joomla、Drupal等)

3-1 人気のCMSの比較(WordPress、Joomla、Drupal等)

はじめに
コンテンツ管理システム(CMS)は、ウェブサイトの作成、管理、公開を容易にするためのソフトウェアアプリケーションです。CMSを使用することで、技術的な専門知識がなくても、テキストや画像などのデジタルコンテンツを編集し、ウェブサイトに公開することができます。現在、市場にはさまざまなCMSが存在しますが、その中でもWordPress、Joomla、Drupalは最も広く使用されているシステムです。この章では、これらの人気CMSを機能、使いやすさ、カスタマイズ性、セキュリティの観点から比較し、どのCMSがあなたのプロジェクトに最適かを探ります。

1. WordPress

WordPressは、世界中で最も広く使われているCMSです。利便性、拡張性、大規模なコミュニティサポートが主な特徴です。非技術者でも簡単にウェブサイトを構築でき、数千のテーマとプラグインを利用してカスタマイズ可能です。小規模なブログから大企業のウェブサイトまで、幅広い用途に対応しています。

長所

  • 利用者が多く、サポートと情報が豊富
  • インストールと設定が簡単
  • 広範囲のテーマとプラグインで高度にカスタマイズ可能

短所

  • カスタマイズが進むと、パフォーマンスが低下する場合がある
  • セキュリティの問題が発生しやすい

2. Joomla

Joomlaは、中規模から大規模のウェブサイトに適したCMSです。社会的なネットワーキングサイトやeコマースサイトなど、複雑な機能を必要とするサイトの構築に最適です。カスタマイズの自由度は高いですが、WordPressに比べると少し技術的な知識が求められます。

長所

  • 強力なコンテンツ管理機能
  • 柔軟なアクセス管理と拡張機能
  • eコマースサイトや社会的ネットワーキングサイトの構築に適している

短所

  • 初心者にはやや扱いにくい
  • 拡張機能の質が不均一

3. Drupal

Drupalは、高度にカスタマイズ可能で強力なCMSです。大規模な企業や高度なデータベース統合が必要なプロジェクトに適しています。Drupalは柔軟性が高く、複雑なサイト構築のニーズに応えることができますが、その分、学習曲線は急です。

長所

  • 強力なカスタマイズと開発機能
  • セキュリティが高く、大規模サイトに適している
  • 複雑なコンテンツ構造とデータ管理が可能

短所

  • 初心者には非常に難しい
  • セットアップと管理に時間がかかる

4. まとめ

WordPress、Joomla、Drupalはそれぞれ異なるニーズに対応しています。WordPressは使いやすさと拡張性を求めるユーザーに、Joomlaは少し複雑なサイトを構築したい中級者に、Drupalは高度なカスタマイズとセキュリティを必要とする専門家や大企業に最適です。上記以外にもMovable Typ、MT7、Concrete5、EC-CUBEなどもあります。最終的には、プロジェクトの要件、技術的なスキル、将来の拡張計画に基づいてCMSを選択することが重要です。

「一部のJavascriptファイルは縮小されていないようです」の解決方法

Wordpress

All in One SEOのSEO分析で「一部のJavascriptファイルは縮小されていないようです」と表示された場合の解決方法です。

これを解決するのはWordpressのプラグインの「Autoptimize」が便利です。
WordPressにAutoptimizeを追加して以下のように設定します。

AutoptimizeのJavaScript オプション
AutoptimizeのCSS オプション
AutoptimizeのHTML オプション

上記の設定が完了すると

すべてのJavaScriptファイルが縮小されているようです。

警告が解除されます。

「お使いのサーバーは画像に “expires” ヘッダーを使用していません。」の解決方法

Wordpress

All in One SEOのSEO分析で「お使いのサーバーは画像に “expires” ヘッダーを使用していません。」と表示された場合の解決方法です。

今回は、Apache で mod_expires モジュールが使えるのを前提に書いています。
htaccessに以下のように追加します。

## EXPIRES HEADER CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
</IfModule>
## EXPIRES HEADER CACHING ##

期間はお好みで設定してください。
上記の例では1 year(1年)になっております。

htaccessに追加が完了すると

お使いのサーバーは画像に "expires" ヘッダーを使用しています。

警告が解除されます。

「オープン・グラフのメタタグはありません」の解決方法

Wordpress

All in One SEOのSEO分析で「オープン・グラフのメタタグはありません」と表示された場合の解決方法です。
これはOGP(Open Graph Protocol)、つまりSNSでシェアされた時に表示される設定が完了していないことを意味します。

OGPの設定には、他のプラグインは必要なく、このプラグインのAll in One SEO Pack自体で設定できます。
設定を始める前に、OGPに設定する画像を用意しておくとスムーズです。

Facebook用の画像サイズは、最小サイズ:200px x 200px、理想的な比率1.91:1、最大8MB(例:1640px x 856px、Retinaスクリーン用3280px x 1712px)です。JPG、PNG、WEBP、GIF形式のみ。

Twitter用の画像サイズは、最小サイズ: 300px x 157px、理想的な縦横比2:1、最大5MB。 JPG、PNG、WEBP、GIF 形式のみ。

手順
1)All in One SEOの「ソーシャルネットワーク」にアクセス。

1)All in One SEOの「ソーシャルネットワーク」にアクセス。


2)Facebookの一般設定を表示して「デフォルト投稿Facebook画像」を設定する。

2)Facebookの一般設定を表示して「デフォルト投稿Facebook画像」を設定する。

3)Twitterカード設定を表示して「デフォルト投稿Twitter画像」を設定する。

3)Twitterカード設定を表示して「デフォルト投稿Twitter画像」を設定する。

以上で完了です。

必要なオープングラフメタタグがすべて見つかりました。

このように警告が解除されます。