サイト内検索の遷移先を先読みできるChromeの新しい指定

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

ページの表示を速くする手段のひとつに、リンク先を先に読み込んでおく先読み(prerender)がある。ChromeではSpeculation Rules(投機ルール)という仕組みが用意されていて、JSONを数行書くだけで、どのページを先読みするかをブラウザに伝えられる。先読みといっても中身は実際にページを読み込んで表示の準備まで済ませておく処理で、遷移した瞬間に画面が出るのが特徴になる。ただしこれまでは、フォームの送信による画面遷移には効かなかった。7月に安定版へ上がったChrome 151で、その穴が埋まっている。

新しく使えるようになったのは、prerenderのルールに書けるform_submissionというフィールド。サイト内検索のように、送信すると /search?q=… といったGETリクエストの遷移になるフォームを対象に、遷移先をあらかじめ用意しておける。これまでもURLを指定した先読み自体は書けたのだが、実際の遷移がフォーム送信だと用意した先読みを使えず、結局その場で読み込み直しになっていた。ブラウザ側から見れば、使われないページの準備に通信量とCPUを費やしていたことになる。今回の指定は、フォーム送信という遷移の種類そのものを先読み側に伝えるもので、ボタンを押した瞬間に用意済みのページへ切り替えられる。Chromeは146でオリジントライアルとして試したうえで、151からデスクトップとAndroidで正式に有効化した。WebViewは対象外のままとなっている。

サイト内検索を抱えるサイトでの使いどころ

商品検索や記事検索を備えたサイトは、規模を問わず多い。検索結果ページは一覧の組み立てやデータベースへの問い合わせが挟まるぶん、トップページより重くなりやすい。そこを先読みで前倒しできれば、押してから表示までの体感は変わってくる。もっとも、先読みしたのに遷移しなかった分はそのまま無駄になるので、あれもこれもと広げる性質のものではない。先読みは通信環境や省データ設定によってブラウザ側の判断で見送られることもあり、必ず効くものとして設計するより、効いたら速いという上乗せとして扱うほうが無難だと思う。対象を選ぶときは、アクセス解析でよく使われている検索欄はどれかを先に見ておくと判断しやすい。

気をつけたいのはサーバー側の負荷とアクセス解析の扱い。WordPressのサイト内検索は結果がURLごとに散らばるためキャッシュが効きにくく、先読みの指定を広げるとリクエストだけが増えることもある。計測についても、先読みされた時点と実際に表示された時点をどう数えるかはツールによって差がある。また、今回想定されているのは検索フォームのようなGETでの遷移で、POSTで送る問い合わせフォームの類は同じようにはいかない。ChromeのDevToolsには投機ルールの動作を確認する画面があるので、まずはそこで先読みが成立しているかを見ながら、よく使われる検索フォームひとつに絞って試すあたりが現実的なところだろう。

枠線にグラデーションを回り道なしで指定できるCSSの新機能

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

ボタンやカードの枠線にグラデーションをかけたい、という要望は制作の現場でよく出てきます。ところがこれまでのCSSでは、枠線そのものに直接グラデーションを指定する手立てがありませんでした。地方の小さなサイトから大規模サイトまで、デザイナーが同じ回り道を強いられてきた領域です。ここに動きがあったので共有します。

これまで枠線グラデーションは回り道が必要だった

border-colorには単色しか指定できません。そのためグラデーションの枠線を作るには、いくつかの遠回りな方法が使われてきました。代表的なのがborder-imageを使う書き方ですが、角丸との相性が悪く、border-radiusを当てると角が欠けてしまうという弱点があります。

もうひとつは、擬似要素や入れ子の要素を重ねて、背景のグラデーションを枠線に見せかける方法です。こちらは角丸にも対応できますが、余分なマークアップが増え、レイアウトの計算も複雑になります。SVGで枠を描いて重ねるやり方もありますが、いずれにしても本来の目的に対して手数が多すぎました。

結果として、枠線グラデーションは「できなくはないが、毎回コピーしてきた定型のコードを貼り付けて使う」ような、少し身構える表現になっていました。どれも「枠線にグラデーション」というシンプルな見た目のわりに、裏側の手間が大きいのが実情です。新しく担当する制作者がコードを読み解くときにも、なぜこんな構造になっているのか分かりにくいという副作用がありました。

background-clipにborder-areaという値が加わった

Chrome 150で、background-clipプロパティにborder-areaという新しい値が入りました。これは要素の背景を、枠線が描かれる範囲に沿って切り抜くという指定です。border-widthとborder-styleを踏まえて背景を枠線の形に合わせ、border-colorの透明度は無視します。

やっていることは単純で、背景にグラデーションを敷き、それを枠線の領域だけに見えるよう切り抜く、という発想です。border-imageのような専用の仕組みではなく、使い慣れた背景まわりのプロパティの延長で枠線を装飾できるのが利点です。角丸ともきれいに馴染みます。なおこの機能は先にWebKit系のブラウザが搭載しており、今回のChrome側の対応で足並みがそろった形になります。

実際の書き方と気をつける点

基本の流れは、background-imageにグラデーションを指定し、background-clipにborder-areaを指定し、あわせてbackground-originをborder-boxにする、という三点セットです。background-originを省くと初期値のpadding-boxで描かれてしまい、グラデーションの位置が枠線とわずかにずれます。ここは忘れやすい落とし穴なので、border-boxを明示しておくと安全です。

枠線を実際に見せるには、border-styleをsolidにしてborder-widthで太さを与える必要があります。透明な枠線では切り抜く範囲そのものが生まれないためです。破線や点線を指定すれば、その途切れた形のままグラデーションが乗るので、単なるグラデーション枠にとどまらない装飾も作れます。詳しい挙動はChrome 150の公式ブログにまとまっているので、導入前に一度目を通しておくとよいでしょう。

既存の背景色や背景画像と組み合わせたいときは、backgroundを複数レイヤーで重ねる書き方になります。枠線用のグラデーションと本体の背景を別々のレイヤーとして指定し、border-areaを枠線側のレイヤーにだけ効かせる、という整理をしておくと崩れにくくなります。

中小企業サイトでどう活かせるか

現時点では対応ブラウザがまだ限られるため、すべての来訪者に同じ見た目を届ける用途には早すぎます。実務では、枠線グラデーションを装飾の飾りと位置づけ、対応していないブラウザでは単色の枠線にフォールバックさせる考え方が無理のない使い方です。見た目が少し華やかになるかどうかの差であれば、対応環境だけで恩恵を受けられれば十分という判断もできます。

キャンペーンのバナーや、目立たせたいボタン、料金プランのカードなど、装飾の効果が効く場所は中小企業サイトにもよくあります。これまで擬似要素を積んで実現していた表現が、背景まわりの数行で書けるようになるのは、保守のしやすさという点でも歓迎できる変化です。ブラウザ全体に広がるのを待ちつつ、手元の環境で挙動を試しておくと、対応がそろったときにすぐ使い始められます。

証明書の有効期間が短くなる流れと、更新まわりで見直すところ

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

ウェブサイトのHTTPS化に使う証明書は、一度設定してしまえばあとは自動更新に任せきり、という運用が多いと思います。ところがここ数年、その有効期間を短くしていく動きが業界全体で進んでいて、更新が止まったときに表面化しやすい環境へ変わりつつあります。

7月に入ってからも、無料の証明書として広く使われているLet’s Encryptで一つ区切りがありました。証明書まわりで決まっている予定を、順に並べて見ていきます。

有効期間の上限が段階的に下がる

証明書を発行する認証局とブラウザベンダーが集まるCA/Browser Forumは、2025年4月に有効期間を段階的に短縮する日程を可決しています。これまで最長398日だった上限は、2026年3月15日から200日、2027年3月15日から100日、2029年3月15日からは47日になります。

あわせて、ドメイン所有の確認結果を使い回せる期間も短くなります。ドメイン検証の再利用は2026年に200日、2027年に100日、2029年には10日まで縮む予定です。証明書の寿命だけでなく、確認作業そのものの頻度も上がるということです。

短くする理由は、鍵が漏れたときに悪用され続ける期間を限定することと、失効の仕組みに頼りきらずに済むようにすることだとされています。

Let’s Encryptはさらに先を行く日程を出している

Let’s Encryptの公表によると、現在の90日はさらに短くなる予定です。2027年2月10日に既定のプロファイルが64日へ、2028年2月16日には45日になるとされています。先に試したい向きには、2026年5月13日から45日の証明書を受け取れるプロファイルも用意されました。

同時に、更新の推奨時期を認証局側から知らせる仕組み(ACME Renewal Information)を使うことがすすめられています。クライアントが決め打ちした間隔で回すのではなく、認証局が示すタイミングに合わせて更新する形です。

クライアント認証向けの証明書は入手先が変わった

7月8日、Let’s Encryptはクライアント認証(TLS Client Authentication)の用途に使える証明書の発行を終了しました。暫定的に残されていた専用のプロファイルも、この日で廃止されています。

背景には、サーバー用途とクライアント用途で証明書の階層を分けるという、ブラウザ側のルート証明書プログラムの要件があります。ウェブサイトを公開するために使う証明書はサーバー用途なので、通常のサイト運用に影響はありません。

影響が出るのは、機器やAPIの相互認証、VPNの接続認証などにLet’s Encryptを流用していた場合です。手元の証明書が切れた時点で更新できなくなるため、別の発行元へ移す必要があります。

手作業での更新は現実的でなくなる

45日や47日という期間になると、更新は年に8回前後発生します。カレンダーに予定を入れて手で差し替える運用は、まず続きません。自動更新を前提に組み直しておくのが無難です。

自動化するときの目安として、Let’s Encryptは有効期間の3分の2ほど過ぎた時点での更新を挙げています。加えて、更新が失敗したときに気づける監視を用意しておくことも案内されています。自動更新は動いている間は何も言ってこないので、止まったことに気づけない構成が一番こわいところです。

中小規模のサイトで確認しておきたいところ

共有レンタルサーバーの管理画面から証明書を発行している場合、更新はサーバー側の仕組みに任されています。まずは自動更新が有効になっているか、管理画面で状態を見ておくと安心です。契約プランによっては手動更新のままになっていることもあります。

自前のサーバーやVPSでcertbotなどを動かしているなら、実行間隔の見直しどころです。90日を前提に月1回程度で組んでいると、45日の証明書では余裕がなくなります。日次で実行して更新時期が来たものだけ更新する形にしておけば、期間が変わっても影響を受けません。

それから、証明書の有効期限を外側から監視しておくこと。更新の自動化と期限の監視は別の話で、後者があると、どこか一箇所で自動化が壊れたときに訪問者より先に気づけます。日程表を眺めると先の話に見えますが、更新の仕組みを触るのは余裕のある今のうちが手戻りも少なくて済みそうです。

所有者が変わったプラグインと、更新経路そのものを狙う攻撃

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

更新の通知が来たらできるだけ早く当てる。WordPressサイトを預かる立場では長く正しい習慣として語られてきましたし、その前提はいまも変わりません。ただ2026年に入ってから表面化したいくつかの事例は、その習慣が暗黙に置いている「配信されてくる更新そのものは信頼できる」という部分に、これまでとは違う角度から光を当てました。

狙われたのはプラグインのコードに残っていた穴ではなく、プラグインが利用者の手元に届くまでの経路のほうです。脆弱性を探して突くのではなく、正規の更新に紛れ込んで入ってくる。防ぐ側から見ると、注意を向ける場所が一段ずれる話になります。

所有者が変わったあとに仕込まれた休眠コード

4月初旬に問題になったのは、Essential Pluginという作者名で公式ディレクトリに並んでいた30本あまりのプラグインでした。カウントダウンタイマー、クリックで開くポップアップ、お客様の声の表示といった、小規模サイトで気軽に足される種類のものが並んでおり、合計の稼働数は数十万件規模とされています。

経緯として報じられているのは、この一群がまとめて売買され、開発者が交代していたという点です。WordPress.orgのプラグインは、作者が変わっても配布の枠組みはそのまま引き継がれます。利用者側の管理画面には、以前と同じ名前のプラグインに更新が来たようにしか見えません。

不正なコードが加えられたのは2025年8月、互換性対応をうたった版でした。そこから約8か月のあいだ、そのコードは何もしないまま眠っていたと分析されています。動き出したのは2026年4月上旬で、外部から指示を受け取って処理を実行する経路が有効になり、検索エンジンのクローラーに対してだけ表示されるスパムや転送が仕込まれました。WordPress.orgのプラグインチームは4月7日に該当する全プラグインの配布を停止し、翌日には強制的な更新で通信部分を無効化しています。

公式ディレクトリの外でも同じ形が起きた

6月には別の形の事例が公表されました。ShapedPluginという開発元の有償版プラグイン、具体的にはWooCommerce向けの商品スライダー、お客様の声、投稿一覧表示の三製品で、開発元自身のビルドと配信の仕組みが侵害されていたというものです。

こちらで問題になったのは、公式ディレクトリに置かれている無償版ではなく、開発元のサーバーから直接配信される有償版のほうでした。つまり影響を受けたのは、対価を払って正規に自動更新を受けていた利用者だけということになります。混入は5月下旬、利用者からの報告が上がり始めたのが6月上旬、開発元が事実を認めたのが6月中旬という流れでした。

盗み出されたとされる情報は、管理者のログイン情報、二段階認証の秘密鍵、データベースの接続情報、メール送信サービスの認証情報、そして受注データにまで及びます。セキュリティメディアの報道では、一連の侵害はCVE-2026-10735として整理されています。有償版だから安全、公式ディレクトリだから安全、という単純な線引きが成り立たないことを、二つの事例は逆方向から示した形です。

気づくまでに時間がかかる理由

Essential Pluginの件で目を引くのは、仕込まれてから発覚するまでのおよそ8か月という長さです。仕込む側からすれば、加えた直後に動かす必要はありません。しばらく普通に動く版を配り、更新が行き渡り、疑いが薄れたころに起こせばよい。監視する側の目線に合わせて時間をずらされると、更新直後の挙動を見るだけでは捕まえられなくなります。

もうひとつは、公式ディレクトリに所有者交代を扱う仕組みが用意されていないという構造の問題です。プラグインが売買されて委譲されても、利用者に通知が飛ぶわけではなく、新しい担当者による最初の更新に追加の審査が入るわけでもありません。稼働数の多いプラグインは、それ自体が売り物として価値を持ちます。数万件のサイトに更新を届けられる立場が、市場で取引できてしまうという事実のほうが、個々の脆弱性より扱いが難しい部分かもしれません。

被害の出方が静かであること

今回のような侵害でやっかいなのは、サイトを見ている限り異変がわからないところです。Essential Pluginの件で配られたスパムは検索エンジンのクローラーにだけ見せる作りで、運営者が自分のサイトを開いても、いつも通りのページが表示されます。気づく糸口は検索結果の見え方や、Search Consoleの警告、ホスティング側からの連絡といった、サイトの外から届く信号のほうになります。

認証情報の窃取はさらに静かです。抜かれた時点では何も起きず、しばらく経ってから別の入口として使われます。管理画面のログイン履歴に見覚えのないものが混ざる、送信していないメールが自社ドメインから出ている、といった形で後から現れることが多く、そのころには最初の原因までたどるのが難しくなっています。

運用側でできる現実的な備え

まず効くのは、入れているプラグインの数を減らすことです。装飾のために一つ、フォームのために一つ、と足していった結果として、10本20本と並んでいるサイトは珍しくありません。一本ごとに、その開発元の更新経路を信頼するという判断が積み上がっていると考えると、使っていない機能のために枠を空けておく理由はあまりありません。

次に、自動更新をどこまで任せるかの線引きです。本体のマイナー更新は自動に任せるとして、プラグインについては稼働数の多いもの、更新頻度の高いものほど、当てる前に一拍置く運用にも意味があります。ただし更新を止めれば安全という話ではなく、既知の脆弱性を放置するほうが確率としてははるかに危ないので、遅らせるとしても数日という幅に留めるのが現実的でしょう。

加えて、更新の中身を軽く確かめる習慣も持っておきたいところです。プラグインの更新画面には変更内容へのリンクが並んでいますし、公式ディレクトリなら開発の記録も公開されています。毎回すべてを読む必要はありませんが、しばらく静かだったプラグインに突然大きな更新が来た、作者名の表示が変わっている、といった違和感は、目を通していれば引っかかります。今年の二件も、外形的な変化としては読み取れる材料が残っていました。

三つ目は、変化に気づける状態を作っておくことです。ファイルの改変を検知する仕組み、wp-config.phpや読み込み処理の周辺に見慣れない記述が増えていないかの確認、そして管理者アカウントの棚卸し。侵入を完全に防ぐ前提ではなく、入られたあと早く気づく前提で組んでおくほうが、この種の攻撃には噛み合います。

依存の数を意識するという話

WordPressの強みは、必要な機能をプラグインで足していける柔軟さにあります。制作会社としてもその恩恵は受けてきましたし、ゼロから作るより速く安く仕上げられる場面はいくらでもあります。ただ、その柔軟さは同時に、他人が書いたコードを自動で受け取り続ける関係を何本も抱えることでもあります。

プラグイン単体の良し悪しだけでなく、誰が作っていて、どういう経路で更新が届いていて、その開発元がいまも同じ人たちなのか。ここまで気にして選ぶのは手間ですが、今年の二件はその手間が無駄ではないことを示しています。次に一本足そうとしたとき、それが本当に必要かどうかを一度考えてみる。当たり前のようでいて、いちばん効く判断はそのあたりに残っている気がします。

WordPress本体で連鎖する脆弱性が見つかり緊急の修正版が出た

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

WordPress本体に、ログインしていない相手がサーバー上で任意のコードを実行できてしまう脆弱性の組み合わせが見つかり、開発チームが緊急の修正版を公開しました。プラグインやテーマ側ではなく本体そのものの問題で、特別な設定や特定の拡張を入れていないサイトも対象になります。

公開は2026年7月17日。研究者が付けた「wp2shell」という呼び名で各所のセキュリティメディアが報じており、公開から数日のうちに実際に狙われている事例も確認されています。WordPressを扱っている制作者としては、いったん手を止めて手元の案件を見直しておきたい内容です。

本体だけで成立してしまう経路

今回問題になったのは二つの弱点です。ひとつは、WordPress 6.9で導入されたREST APIのバッチ処理用エンドポイントで、複数のリクエストをまとめて処理する際に権限の確認が正しく働かない場合があるというもの。もうひとつは、WP_Queryのauthor__not_inというパラメータに残っていたSQLインジェクションの穴で、こちらは6.8の系統から存在していたとされています。

単独で見ればどちらも即座に致命傷というわけではないのですが、順につないでいくと、認証を一切通らないまま任意のコードの実行まで到達します。プラグインを一つも入れていない素のWordPressでも成立する点が、今回いちばん重く受け止められている理由です。REST APIは投稿画面やブロックエディタが日常的に使っている入口なので、単純に閉じてしまえば済むという性質のものでもありません。

対象になる版と修正が入った版

修正版として出ているのは 7.0.2、6.9.5、6.8.6 の三つです。7.0.0から7.0.1、6.9.0から6.9.4、そして6.8系の古い版が対象に含まれます。自分の案件がどの系統で止まっているかによって、上げるべき先が変わる形です。

数年前に納品してそのまま動いている中小企業のサイトほど、メジャー更新を意図的に止めているケースが多いはずです。テーマや古いプラグインとの相性を心配して更新を保留する判断自体は珍しくありませんが、今回のように本体側で認証を通らない経路が見つかった場合は、その保留がそのまま危険の持ち越しになります。

なお、SQLインジェクション側の穴は6.8の系統から存在していたとされる一方で、実際に危険な連鎖として成立するのはREST APIの入口が加わった6.9以降です。古い版だから安全という話ではなく、修正版が出ている以上はどの系統でも上げておくのが素直な対応になります。

強制的な自動更新という対応

WordPress.orgは、対象となるサポート中のインストールに向けて自動更新を強制的に配信する措置を取りました。マイナー更新が自動で当たる仕組みは以前から用意されていましたが、深刻度に応じてここまで踏み込んだ形で運用されるのは、それだけ状況が急いでいるという合図と読めます。

ただし、この仕組みに全面的に寄りかかるのも避けたいところです。自動更新を明示的に無効化している環境、ファイルの書き換えを禁止している構成、独自の配置で運用しているサイトなどでは、そもそも配信が届きません。届いているつもりで届いていない、という状態がいちばん危ないパターンです。

受託で複数のサイトを預かっている立場だと、更新方針が案件ごとにばらばらというのもよくある話です。どのサイトが自動更新に任せてあって、どのサイトが手動運用なのか。今回のような場面で真っ先に効いてくるのは、その一覧がすぐ出てくるかどうかという、地味な管理の部分だったりします。

制作者側で確認しておきたいこと

まずは管理している各サイトのバージョンを実際に開いて確認するのが先です。更新が当たっているサイトはそれで終わりですが、当たっていないサイトが一つでも出てきたら、その環境で自動更新が働いていない理由を確かめておく価値があります。サーバー側で遮断する運用を取っている場合は、バッチ処理用のエンドポイントへの外部からのアクセスを一時的に止める手も選択肢に入ります。

抜けやすいのは、日常の運用から外れているサイトです。検証用に残したままの複製、しばらく更新していない古い案件、担当が変わって誰も見ていないサブドメイン。攻撃する側は運用の熱心さで対象を選り好みしないので、忘れられているサイトほど先に踏まれます。案件一覧を開いて、更新の当たり具合を一通り眺めておくだけでも、この週末の作業としては十分に意味があります。

Firefoxが隔週リリースへ、ブラウザ更新の間隔が縮む

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

Mozillaが、Firefoxのリリース間隔を4週間ごとから2週間ごとへ短縮すると発表した。エンジニアリング担当のSylvestre Ledru氏が開発者向けメーリングリストで明らかにしたもので、8月18日公開予定のFirefox 154が4週間サイクル最後のバージョンになる。以降は9月1日のFirefox 155を皮切りに、9月15日、9月29日と隔週で番号が進んでいく予定だという。対象はデスクトップ版とAndroid版で、リリース履歴の並び方もこれまでとは違って見えるようになる。

狙いは、できあがった機能を待たせずに届けることと、リリース計画を読みやすくすることだとされている。締め切り直前に作業が集中する状況を和らげたい、という説明も添えられている。ただしMozillaは、開発の速度を倍にするという意味ではないと補足しており、熟していない機能は無理に載せず時間をかける方針は変えないという。今回の変更もあくまで試験的な位置づけで、品質や開発者の負荷への影響を見たうえで、恒久化するかどうかを判断するとしている。

Firefoxのリリース間隔は、かつての6週間から4週間へ一度短縮された経緯がある。今回はそこからさらに半分になる計算で、バージョン番号が大きな節目を意味しなくなる流れは、ChromeやEdgeが先に通ってきた道でもある。受け止めは一様ではなく、更新の回数が増えれば不具合に当たる機会も増えるのではないか、二倍の頻度で安定版を出しきる体制があるのか、といった声も出ている。Mozilla自身が試験的と断っているのは、そのあたりを含めて見極めたいという姿勢の表れだろう。リリースの回数が増えるということは、後戻りの判断も細かく打てるということでもあり、どちらに転ぶかは実際に走らせてみないと見えてこない部分が大きい。

制作の現場から見た影響

実務で効いてくるのは、対応ブラウザをバージョン番号で語りにくくなることだと思う。要件定義書や見積書に特定の番号を書き込む運用は以前から実態と合わなくなっていたが、隔週更新が加わると、番号を追いかける意味はさらに薄れる。使いたい機能が主要なブラウザに出そろっているかどうかで判断するほうが現実的で、この見方はすでに定着しつつある。中小企業のサイトのように長く運用する案件ほど、番号ではなく機能の足並みで線を引いておくと、あとから説明もしやすい。

企業内で使われるESR(延長サポート版)は今回の変更の対象外で、これまで通りのゆっくりした間隔が保たれる。社内システムの動作確認を抱えている現場では、ここが動かない点は押さえておきたいところだ。一方、一般の利用者に向けては、修正が手元へ届くまでの待ち時間が縮むことになる。不具合の報告を受けてから直りが行き渡るまでの見通しが立てやすくなるなら、サイトを預かる側にとっても悪い話ではない。表示崩れの相談を受けたときに、環境側の更新でいずれ解消するのか、こちらで手を入れるべきなのかを切り分ける時間も、少しずつ短くなっていくはずだ。

ブロックごとにタブレットとモバイルの見た目を変えられるエディタの新機能

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

WordPressのブロックエディタに、ブロック単位でタブレット表示とモバイル表示のスタイルを指定できる仕組みが入ろうとしています。開発版プラグインのGutenberg 23.5に含まれた変更で、8月19日に予定されているWordPress 7.1に向けた作業の一部です。7月3日にはコアチームからテスト協力の呼びかけも出ており、いまが仕様に意見を出せる時期でもあります。

これまでブロックエディタの画面幅切り替えは、デスクトップ、タブレット、モバイルという固定の三択でした。しかも切り替えられるのは見え方の確認だけで、余白や文字サイズといった値そのものを画面幅ごとに変えることはできません。細かく詰めたい場合は、テーマ側でCSSを書くか、追加CSSクラスを当てて自前のメディアクエリを用意するのが定番の逃げ道でした。今回の変更は、その前提を編集画面の側から作り直そうとしています。

プレビューの幅を自由にドラッグできるようになった

まず目に見えて変わるのが、エディタキャンバスの幅です。従来のプリセット三択はドロップダウンに残ったまま、キャンバス自体が任意の幅にドラッグできるリサイズ可能なものに変わりました。ドロップダウンとリサイズハンドルは連動していて、プリセットの幅に一気に飛ぶこともできれば、ハンドルを掴んで数十ピクセル単位で詰めることもできます。

実務では、崩れるのは決まってプリセットの三点ではなく、その間のどこかです。タブレット表示は問題ないのにやや狭い幅でボタンの文字が折り返す、といった話は日常的に出てきます。幅を連続的に動かせるだけで、そうした境目を編集画面の中で見つけやすくなります。ブロックにビューポート別の設定が入っている場合は、幅を動かすとその境目で表示と非表示が実際に切り替わるため、確認の粒度も上がります。

ブロックごとにタブレットとモバイルの値を持たせる

本題はスタイル側です。プレビューのドロップダウンにレスポンシブ編集の切り替えが追加され、これを有効にすると、そのとき選んでいる画面幅に対してスタイル変更が適用されるようになります。つまりタブレット幅で余白を変えれば、それはタブレットだけの指定として保存され、デスクトップの値は元のまま残ります。同じブロックにタブレットとモバイルで別々の値を持たせ、それぞれが独立して記憶される作りです。

対象は文字サイズだけではありません。テスト呼びかけの中でも、グループやボタン、画像といった異なるブロックで、余白や色を含む複数のプロパティを試してほしいと案内されています。加えて、ブロックの表示と非表示をタブレットだけ切り替えるといった指定も扱えます。これまで追加CSSクラスと自作のメディアクエリで運用していた類の調整が、エディタの標準機能の側に寄ってくることになります。

ブロックの作り手にとっての線引き

制作会社の視点で押さえておきたいのは、恩恵が自動で行き渡る範囲がはっきり分かれている点です。標準のブロックサポートを使って実装されたブロックは、特別な対応をしなくてもレスポンシブなスタイル指定に対応します。一方で、独自のコントロールを自前で組んでいるブロックは対象外で、追いつくには手を入れる必要があります。自社製のカスタムブロックや、独自UIを持つプラグインを抱えているサイトほど、この線引きは効いてきます。

もう一点、useResizeCanvas() というフックが非推奨となり動作しなくなりました。getDeviceType() と setDeviceType() は引き続き使えます。エディタの幅制御に手を入れているテーマやプラグインを持っているなら、7.1が出る前に一度検索をかけておくと安全です。この手の変更は、リリース後に管理画面が白くなってから気づくのがいちばん厄介なので、ベータ期間のうちに確認できるのはありがたいところです。

運用の現場でどう効いてくるか

中小企業のサイトでは、公開後の細かな見た目の調整をお客様自身が行う場面が少なくありません。そのとき、スマートフォンだけ余白を詰めたいという要望に対して、これまでは制作側がCSSを書き足すしかありませんでした。ブロックの設定として持てるようになれば、依頼の往復が一段減ります。地方の小さな制作体制ほど、この手の細かい差し戻しが積み上がって時間を食っている実感があります。

ただし現時点ではまだテスト段階で、仕様も細部が動く可能性があります。本番サイトの開発版プラグインで試すのではなく、ステージング環境や検証用サイトで触るのが前提です。逆に言えば、いま試して違和感を報告すれば、8月のリリースに反映される余地があります。ブロックテーマを使っているサイトを一つ用意して、手持ちのブロックがどこまで追従するかを見ておくと、7.1が出たときの案内が具体的になります。

セール価格の期間と商品カテゴリを伝える構造化データの指針

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

Googleの検索セントラルが、商品ページ向けの構造化データのドキュメントを更新した。セール価格がいつからいつまで有効なのかを書き表す方法と、商品のカテゴリを指定する方法について、これまでよりはっきりした説明が加わっている。ネットショップを運営していると、セールのたびに価格表示の扱いで迷う場面があるが、ちょうどその部分に踏み込んだ内容になっている。

まずセール期間の書き方から。価格が有効な期間を示すプロパティとして、開始日時を表すvalidFromと、終了日時を表すvalidThroughがある。加えて、その時刻を過ぎると価格が有効でなくなることを示すpriceValidUntilも使える。日時はいずれもISO 8601形式で書く。Googleのドキュメントでは、開始と終了の両方を書いて期間をはっきりさせること、そして開始日時が終了日時以前になっているかを確かめることが促されている。書く場所は、Offerノードの価格がそのままセール価格になっているならOfferに、セール価格を別に持たせる構成ならPriceSpecificationノードに置く、という整理になっている。

もうひとつがcategoryプロパティの扱いだ。ここにはテキストをそのまま書くこともできるし、CategoryCodeというオブジェクトを使ってGoogleの商品タクソノミーを参照することもできる。CategoryCodeを使う場合に書くのは、@typeと、タクソノミーのURLを指すinCodeSet、それにカテゴリの数値IDかカテゴリパスを入れるcodeValueの三つ。カテゴリパスは記号で階層をつないで書く形式になっている。値は複数指定できるので、自社サイト独自の分類とGoogle側の分類を併記しておく、という使い方が想定されている。

小さなネットショップならどこから手をつけるか

WooCommerceなどのプラグインを使っているサイトでは、構造化データの出力はプラグイン任せになっていることが多い。その場合でも、セール中の商品ページをリッチリザルトテストにかけて、期間の情報が実際に入っているかを一度見ておく価値はある。期間が抜けたままだと、セールが終わった後も割引価格の情報が検索結果側に残って見えることがある。逆に言えば、ここを整えておくだけで、店頭の表示と検索結果の見え方がずれる場面を減らせる。カテゴリのほうも、商品数がそれなりにあるサイトなら、独自の分類名だけで済ませているケースが少なくない。タクソノミー側の値を足しておけば、検索側に商品の位置づけが伝わりやすくなる。

構造化データの話は全体像が大きく、どこから手をつけるか決めにくい領域だが、価格と期間はどのショップにも共通して効く部分だ。規模の小さいサイトほどセールの入れ替えを手作業でこなしていることが多く、そこに期間の指定が加わると運用も楽になる。新しい機能が増えたというより、これまで各社が手探りでやっていた書き方に公式の型が示された、という受け止め方が近い。

スクロールで画面に入ると動き出すアニメーションのCSS新機能

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

ウェブサイトで「下にスクロールしていくと、画面に入った要素がふわっと動き出す」という演出はよく見かけます。これまでこの手の動きは、JavaScriptでスクロール位置を監視するか、専用のライブラリを読み込むのが定番でした。ところが最近のChromeに、こうした動きをCSSだけで指定できる新しい仕組みが加わりました。制作の手間が一段減りそうなので、いまのうちに内容を整理しておきます。

これまではJavaScript頼りだった

要素が画面に入ったタイミングでアニメーションを始めたい場合、多くの現場ではIntersectionObserverというJavaScriptの仕組みを使ってきました。要素が見えたことを検知し、クラスを付け外ししてCSSアニメーションを起動する、という流れです。

動かす方法としては十分ですが、監視するコードを書き、要素ごとに設定し、画面から外れたときの処理も考える、という作業が毎回ついて回ります。アニメーションを多用するページほど、JavaScript側の記述が積み重なっていきます。GSAPのScrollTriggerのような外部ライブラリを入れる手もありますが、読み込むファイルが増える分、表示速度への影響も気になるところです。

animation-trigger でCSSに寄せられる

新しく加わったのはanimation-triggerとtimeline-trigger、それにtrigger-scopeという3つのプロパティです。ざっくり言うと、「どの位置に来たら」「どのアニメーションを」再生するかを、CSSの中だけで書けるようになります。

まずtimeline-triggerで、監視したい範囲に名前を付けます。たとえば要素が画面に現れる範囲をview()で指定し、そこに--tのような名前を割り当てます。次に動かしたい要素側でanimation-triggerにその名前を書き、入ってきたら順に再生、出ていったら逆に再生、といった動作を指定します。Chrome for Developersの解説によると、カードが順に現れる演出や、文字が飛び込んでくる表現などが、この仕組みで組めるとされています。なお、トリガーの名前はページ全体から見えるため、同じ名前を複数の箇所で宣言すると最後のものが勝ちます。trigger-scopeで名前の見える範囲を絞っておけば、部品ごとに同じ名前を使い回せます。

細かい調整も効きます。要素がどこまで入ってきたら再生を始めるか、どの範囲にいる間は動いた状態を保つか、といった境目を指定できます。画面の下端に少し入った瞬間から動かす、まだ半分見えていないうちは静止させておく、といった塩梅を、値を書き換えるだけで整えられます。

JavaScriptで書いていた「見えたら動かす」という一連の流れが、スタイルシートの数行に置き換わるイメージです。要素が増えても、監視用のコードを書き足す必要はありません。

スクロール駆動アニメーションとの違い

少し紛らわしいのが、以前から話題になっている「スクロール駆動アニメーション」との違いです。スクロール駆動のほうは、スクロール量そのものにアニメーションの進み具合を結びつけます。スクロールを止めれば動きも止まり、戻せば巻き戻る、という連動です。

今回のスクロールで動き出すほうは性格が異なります。ある位置を通過した瞬間に、決まった長さのアニメーションを頭から再生する動きです。スクロールの速さに関係なく、いったん始まれば最後まで再生されます。JavaScriptのIntersectionObserverでやっていたことに近く、用途もそちらに寄っています。両者は名前が似ていますが、狙う演出が違うので、目的に応じて使い分けることになります。

現場で使うときの見極め

便利な仕組みですが、2026年の時点ではChromeとEdgeで先行して使える段階で、ほかのブラウザはこれからです。すべての来訪者に同じ動きを届けたい場面では、まだ本命として据えるのは早いかもしれません。

とはいえ、この種の演出は「あれば嬉しいが、無くても中身は読める」性質のものです。対応ブラウザでは動き、そうでなければ静止したまま表示される、という前提で組めば、いまから取り入れても実害はありません。中小企業サイトのトップページで、見出しや写真をさりげなく動かす程度の使い方なら、JavaScriptを減らす一歩として試す価値があります。WordPressで運用しているサイトでも、テーマのスタイルシートに数行足すだけで組み込めます。演出のためにプラグインを増やさずに済むのは、管理する部品が少なくなるという意味でも扱いやすい点です。仕様が固まってほかのブラウザにも広がれば、スクロールに連動した演出はCSSで書くのが当たり前になっていくはずです。

次期WordPressのベータに加わったタブや目次の新しいブロック

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

ウェブサイトの土台としてWordPressを使っている制作者や事業者にとって、次のバージョンで何が増えるかは気になるところです。2026年7月15日に、次期版となるWordPress 7.1のベータ1が公開されました。正式リリースは8月19日が予定されています。今回のバージョンはブロックの追加とデザイン調整の作り込みが目立ちます。今回は編集画面に加わる新しいブロックを中心に、実際の制作でどう役立ちそうかという視点で並べて紹介します。ベータは開発中の段階なので、ここで挙げた仕様は正式版までに変わる可能性がある点は念頭に置いてください。

タブ切り替えを標準ブロックで作れる

これまでタブ形式の表示は、プラグインや独自のJavaScriptに頼るのが一般的でした。7.1ではTabsブロックが標準で加わり、料金プランの比較や、よくある質問の分類などを、コードを書かずにタブでまとめられるようになります。標準機能として編集画面に組み込まれているため、表示のためだけに入れていたプラグインを一つ減らせる場面も出てきます。プラグインが増えるほど更新や不具合対応の手間もかさむので、保守を軽くしたい中小企業のサイトとは相性がよさそうです。

目次ブロックは7.1では見送られた

長い記事に目次を付けたいときも、これまでは専用プラグインが定番でした。7.1のロードマップにはTable of Contents(目次)ブロックも挙がっていましたが、正式版に入った新しいブロックはTabsとPlaylistで、目次ブロックは見送られました。標準ブロックで目次を組めるようになるのは、先の版を待つことになります。

音声をまとめて並べるプレイリスト

Playlist(プレイリスト)ブロックは、複数の音声ファイルを一覧として並べ、続けて再生できるようにするものです。ポッドキャストの配信ページや、社内向けの音声資料をまとめるページなどで使い道があります。あわせて、複数の画像を柔軟に扱えるギャラリーの新しい型も実験的に用意されており、メディアを見せる場面での表現の幅が広がりつつあります。動画や音声を扱うページはこれまで外部の埋め込みサービスに頼りがちでしたが、標準ブロックで完結できれば表示の速さや管理のしやすさの面でも扱いやすくなります。

画面幅ごとに見た目を細かく調整できる

ブロックそのものだけでなく、デザインを整える仕組みにも手が入っています。レスポンシブスタイリングによって、同じブロックでもパソコンとスマートフォンで余白や配置を分けて指定できるようになります。加えて、サイト全体のデザイン設定(グローバルスタイル)に文字の影が加わり、グリッドやフレックスで組んだ並びが意図せず縮んだり崩れたりしにくくする調整も入りました。これまでCSSを直接書いて対応していた細かな見た目の調整が、編集画面の操作だけで届く範囲に少しずつ近づいています。ブロックとブロックの内容を結びつけるブロックバインディングも箇条書きの項目まで扱えるようになり、繰り返しの多いページを組みやすくなっています。

ベータ版はそのまま本番サイトに入れるものではありませんが、正式リリースの前に検証環境で触っておくと、公開後の切り替えがスムーズになります。プラグインで補ってきた機能が標準側に取り込まれていく流れは、サイトの構成をできるだけシンプルに保つうえでも見逃せない動きです。詳しい仕様はWordPress開発者向けの公式ニュースで確認できます。