WordPressの新版で増えた見た目まわりの指定

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

WordPressの新しいバージョンが8月19日に公開された。コードネームは「Mary Lou」で、ジャズピアニストのメアリー・ルー・ウィリアムスにちなんでいる。公式の発表によると、800人を超える貢献者が関わり、1500以上の改善と修正が入ったという。ここでは制作の現場で実際に触ることになりそうな変更を、いくつか並べて見ていく。

画面幅ごとのスタイルが標準の操作に

サイトエディターから、タブレットとモバイルの画面幅に対してブロックの見た目を指定できるようになった。グローバルスタイルでブロック種別ごとに設定することも、個々のブロックに設定することもできる。編集しながら表示幅を切り替えて確認する仕組みも付いている。

theme.json では @mobile と @tablet というキーの下に入れ子で書く。@desktop にあたるキーは意図的に用意されていない。ブロックの既定のスタイルがそのままデスクトップのスタイルであり、上書きしなかった項目はどの画面幅でも効き続ける、という考え方になっている。

区切りの位置も theme.json の settings.viewport で変えられる。既定はモバイルが480px、タブレットが782pxで、px、em、rem の非負の長さだけが有効になる。CSSの関数や割合、単位なしの値は無視される。標準のブロックサポート(タイポグラフィ、色、背景、境界線、寸法、余白、レイアウト)を使っているブロックは自動で対応し、独自のスタイル操作を持つブロックは対象外になる。自作ブロックを確認するときの境界線はここになる。

ホバーや押した状態も扱えるようになった

あわせて、擬似的な状態のスタイル指定が入った。theme.json とエディターの両方から :hover、:focus、:focus-visible、:active を指定できる。ただし今のところ対象は Button ブロックと Navigation Link ブロックに限られている。

メニューの現在地を表すための独自状態の仕組みも入っているが、こちらは theme.json のみで画面上の操作はまだ用意されていない。今は存在を知っておく程度でよさそうだ。

背景まわりで長年の回避策が不要に

ブロックサポートに background.gradient が加わった。従来の color.gradient は background の一括指定として出力されるため background-image まで打ち消してしまい、ひとつのブロックで背景画像とグラデーションを同時に使えなかった。新しい方は background-image の個別指定として出力され、画像とグラデーションをカンマ区切りでまとめて書き出せる。Group、Accordion、Pullquote、Post Content、Quote が最初の対応組になっている。

ほかに dimensions.minWidth が min-height と同じ流儀で追加され、グローバルスタイルでは text-shadow も扱えるようになった。

新しいブロックと編集画面の土台

Playlist と Tabs が試験的な扱いから正式なブロックになった。Playlist は複数の音声をひとまとめに並べ、再生中の様子を波形で添えることもできる。Tabs はタブで内容を切り替える表示で、これまでプラグインに頼っていた場面をいくらか置き換えられそうだ。

編集画面側では、管理バーがすべてのエディターで表示され続けるようになった。投稿エディターは、テーマの種類や登録済みブロックのバージョンにかかわらず常に iframe の中で動く。内容によって切り替わっていた従来の挙動はなくなる。エディター用のスクリプトが動く文書とキャンバスの文書は別物なので、素の document や window を見に行っているコードは対象を取り違える。要素から ownerDocument や defaultView をたどる書き方への置き換えが要る。

管理画面まわりの細かい追加

wp_get_tooltip() と wp_get_toggletip() が追加され、これまでエディターの中にしかなかった説明の吹き出しを管理画面全体で使えるようになった。前者はアイコンだけの操作に読み上げ可能な名前を与えるもの、後者は補足説明を開くボタンを添えるもので、コア自身も投稿画面のメタボックスやログイン画面のチェックボックスで使っている。

Navigation ブロックが子のリンクにフォントサイズを渡さなくなった点も、テーマを作っている人には効いてくる。相対単位が入れ子で掛け算になり、編集画面と表示側で文字の大きさが食い違う原因になっていた。has-{slug}-font-size を直接狙っているテーマは、開発者向けノートにある従来の挙動を戻すフィルターを見ておくとよい。

更新の前に、独自ブロックや管理画面を拡張しているプラグインを一度試しておきたいところだ。画面幅ごとの指定がコアに入ったことで、追加CSSで抱え込んでいた部分をテーマ側に戻せる場面は増えそうに思う。

【NO.150】AIが書いた文章に見えない印がつくようになりました。



先日、AnthropicのClaudeに仕様変更があると話題になりました。
AIが書いたかわかるように見えない印をつけるとのこと。

この騒動で「Claudeを解約」とか「印を消すサービス」とか
色々な方向に発展してるので、今日はこの「見えない印」のお話をしていきます。

今回、Claudeでこの話は話題になりましたが
実はGoogleは2年前からやっています。

ではなぜ、Googleの時には話題にならなかったのに、今回のAnthropicの場合は話題になったのか。

AI ActというEUが作ったAIについての法律があります。
この法律で新たに定められたのが

2026年8月2日から、透明性義務が適用開始。
2026年12月2日から、8月2日より前にEEA市場に出ていた生成システム（音声・画像・動画・テキスト）も対象。

という決まりです。

今回のAnthropicの動きは、この決まりに対応するためです。
Googleはこの決まりが出来る前からやっています。
つまりOpen AIも、なんらかの同様の印をつける必要があります。

このAI Actの決まりが出来てからなので、今回のAnthropicは話題になっただけと
わたしは考えています。

それと、Googleがやったときは、印の検出は一般人には出来なかったのが大きかったと思います。
今回のは、誰でも検出できるツールも配布される予定というのがポイントかも知れません。

今回の決まりに、大きな声で反発をする人たちはいますが
わたしは、今のうちになんらかの手を打っておく必要はあると思っている側です。

今回の決まりが、スキのない、素晴らしい決まりだとは思っていません。

ディープフェイクなど、さまざまな危険が放置されている状態ではあるので、何か決まりは必要だと考えます。
調整は今後行なっていけば良いかなと。

わたしが不思議だったのは、AIが作ったものだとバレることを嫌がる人が結構多いな。というところです。
個人的には、AIができること、わざわざ人間がやってどうするの？という考えなので、不思議な部分ではあります。

どういう感覚なのか、いまいちピンと来ません。
今の時代に、手書きの履歴書とか持ってこられて
「うんうん、パソコンに頼らず偉いな。」みたいな評価なんですかね？

わたしは、その人材が入社しても、効率の良い仕事をしてくれるとは考えられませんし
いかに自分をよく見てもらうかだけに一生懸命な印象を受けます。
これは個人の感想です（笑）

わたしは、今回の印を見分ける機能の痛手を受けるのは
学生が結構多いのはと思っています。

課題も論文も、AIチェックで即アウト。
ん〜、これも答えは分かりませんが何か違和感を感じます。

学びだから、自分で考える力を育てる。
はい、そこは同意です。

わたしは昭和の学校しか知りませんが、学生時代はルールで周りと同じようになることを良しとして
社会に出たら、個性を追求される矛盾を強く感じていました。

社会に出たらAIをうまく活用して課題をクリアすることを望むのに
学生時代の課題にAIを使うのはアウトってことですよね。
なんかこの辺の雑な感じ、どうにかならなないもんかと思っています。

先日、OpenAIが学生向けに作ったサービスで、すぐに答えを教えずに
答えに一緒に導いていくサービスがでまして、正解かどうかは分かりませんが
試みとしては、良い方向だと思いました。

AIを使うと、考える能力が低下する。

よく言われていますよね。
どうなんでしょうかね、一律で言うのは個人的に雑かなと。

メールというサービスが始まった時に
あんなもの使ってると、文章能力が落ちるって言われてました。
落ちたのは、字は読めるけど書けないということと、単純に字が下手になった感じじゃなかったでしょうか？
失うものが違うんですよね。こういうミスリード、多い気がしてます。

子供達は、人類の未来だと本気で思っています。
ミスリードがなるべく少ない世界を望みます。

印の話に戻りますが、今は嫌がっている人がいます
しかし、本当にASIの時代になったら、つまりAIが人間を調節する時代が来たら。

「Made in AI」じゃないと信じられない世界が来るかも知れません。
人間のドクターとか怖いです。
最新のロボットでお願いします。
なんて世界もありえるかも知れません。

「あの時代、印を嫌がっていた人いたよね（笑）」
なんて会話が未来でされちるかも知れませんね。

Just be hopeful.

ライブラリの棚卸しにBaselineを使うという発想

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

一度入れた外部ライブラリを、あとから見直すことはあまりない。動いているし、テストも通っているし、あえて触る理由がない。ただ、その間にもブラウザ側は動いていて、いま package.json に並んでいるもののうち何割かは、すでにブラウザが自前で持っている機能と重なっている。Smashing Magazine に出た依存関係の棚卸しの記事が、その重なりを具体的な数字で示していて面白かった。

入れたきりの依存が積み上がっていく

記事によると、中規模のJavaScriptアプリでは、圧縮後でおよそ60KBから90KB分の依存が、いまやブラウザ側で代替できる範囲に入っているという。日付や数値の書式、HTTP通信、モーダル、ツールチップ、オブジェクトの複製、配列のグループ化。数年前までは確かに穴だった領域が、順に埋まってきた結果だ。

それでもライブラリが残り続けるのは、怠慢だからではないと筆者は書いている。セキュリティの観点で npm audit は回していても、「このライブラリは今もブラウザにできないことをやっているのか」という問いを立てる機会が、そもそも運用の中に組み込まれていない。だから入れたまま何年も過ぎる。複数サイトの保守を抱えている制作の現場だと、この感覚は身に覚えがあるのではないかと思う。

Baselineという安全度の目盛り

棚卸しの物差しとして使われているのが Baseline だ。WebDX Community Group による指標で、ある機能が主要ブラウザ(Chrome、Edge、Firefox、Safari)でどこまで安全に使えるかを三段階で示す。全エンジンには載っていない「限定的な利用可能性」、出そろった直後の「新しく利用可能」、出そろってから30か月が経った「広く利用可能」という並びになっている。

この30か月の差が、棚卸しでは効いてくる。広く利用可能なものは、基本的に今日そのまま置き換えを検討できる。新しく利用可能な段階のものは、自分のサイトの訪問者層を確かめてから決める話になる。状態は webstatus.dev や、MDN の各機能ページに付いているバッジで引ける。

消す前に通しておきたい三つの問い

「ブラウザができるようになった」と読んで、すぐ削り始めないほうがいい、というのが記事の立場だ。紙の上では無料に見える置き換えが、一部の利用者の環境を静かに壊すことがあるし、気づかずに頼っていた機能を落とすこともある。そこで、削る前に三つ確認する。

ひとつめは、代替となる機能が自分の利用者にとって安全かどうか。一般論としてのBaselineではなく、アクセス解析や browserslist の設定と突き合わせて判断する。社内向けの管理画面と、古い端末からの流入が長く続く一般向けサイトでは、答えが変わる。

ふたつめは、置き換えの費用。ブラウザ側の対応が足りずポリフィルを足すことになり、それが外したライブラリより重ければ、容量は増えている。

みっつめは、ブラウザの機能が実際の使い方をカバーしているか。ライブラリは見た目の似た標準機能より多くの仕事をしていることが多い。記事が挙げているのが axios で、fetch に置き換えると、404や500で拒否されない、共通処理を差し込むインターセプタがない、自動再試行がない、アップロードの進捗が取れない、といった差が出る。実際にどこまで使っているかを見てから決める、という順番になる。

置き換えが効きやすいのは書式と画面部品まわり

記事はライブラリを一個ずつではなく、かたまりで見ていく。いちばん取りやすいのが国際化まわりで、相対時間、数値や通貨の書式、複数形、配列を文章に連結する処理は、ブラウザの Intl 系で大半が置き換えられる。この一群でおよそ14KBという計算だ。ただし継続時間の書式は主要エンジンに出そろったのが2025年3月で、広く利用可能になるのは2027年の見込みとされている。

もうひとつ大きいのが画面部品で、こちらはツールチップやポップオーバーのライブラリまで含めて合計およそ24KB。このうちモーダル用のライブラリ、フォーカスを閉じ込める処理、背景のスクロールを止める処理が、dialog要素とCSSの一行にまとまる。showModal で開けば、フォーカスが中に移り、背後が操作できなくなり、Escapeで閉じ、閉じたあとは元の要素にフォーカスが戻る。重なり順もブラウザが面倒を見るので、z-index と格闘しなくてよくなる。手書きの実装より結果的に読み上げ環境への配慮が行き届く、という指摘もうなずける。

通信まわりも同じ見方ができる。よく使われるHTTPクライアントは圧縮後で17KBから19KBほどあり、単純な取得や送信であれば fetch と中断用の仕組みで足りる。タイムアウトも標準の指定で書ける。ここは前述のみっつめの問いが効く場所で、共通処理や再試行に頼っているなら、外した分を自分で書き直すことになる。

配列やオブジェクトの操作も、グループ化や深い複製、集合の和や積は標準側に入った。一方で debounce と throttle には今も標準の代わりがないので、そこは残す。全部捨てるという話ではなく、ブラウザがすでに持っている部分を二重に配らない、という整理だ。

今は手放さないという判断も同じ枠組みから出る

この記事の良いところは、置き換えない例をきちんと入れているところだ。JavaScriptの日付処理を置き換える Temporal は、2026年3月に仕様策定の最終段階に達し、Firefox と Chrome には載ったが、Safari の安定版にはまだ来ていない。全ブラウザで使うにはポリフィルが要る。

そこで数字を並べると、軽量な日付ライブラリが圧縮後3KB程度なのに対し、公式のポリフィルは44KB前後ある。今すぐ乗り換えると容量は減るどころか増える。三つの問いに通すと、機能の良さでは勝っていても、利用者の範囲と費用で落ちる。だから今は現状維持で、Safari が対応してBaselineに入った時点でもう一度見る。判断を「保留」として記録しておける枠組みは、実務では地味に効く。

ブラウザ側の受け皿は今も増えている

置き換え先が増え続けているのも事実で、Chrome 150では、矢印キーでの移動やフォーカス位置の記憶を属性の指定だけで賄える focusgroup が入った。従来は tabindex を書き換える手書きのスクリプトで実現していた部分だ。文字を枠幅に合わせて拡縮する text-fit や、border-image の回り道なしでグラデーションの枠線を描ける background-clip の新しい値も同じ流れにある。

続く Chrome 151 のベータでは、コンポーネントの内側にある要素を aria-labelledby などから参照できる仕組みや、複合的な部品の中の補助的な操作を支援技術に伝える aria-actions が挙がっている。手書きのJavaScriptで補っていた振る舞いが、少しずつ宣言的な記述に移っていく。

中小企業向けのサイトだと、そもそも巨大な依存を抱えていないことも多い。それでも、テーマやプラグインが読み込んでいるものを一度数えてみる価値はある。四半期に一度、本番に出ている依存だけを並べ、それぞれが実際のビルドでどれだけ容量を占めているかを解析ツールで測り、代わりになる機能のBaselineの状態を確かめる。そのうえで先ほどの三つの問いに通し、いま標準になっているものを返していく。それだけで表示は軽くなり、更新を追いかける対象も減る。まずは一つの分野だけ選んで手元の設定ファイルを開いてみる、という始め方が現実的だと思う。

動画の再生状態に合わせた見た目をCSSで切り替える

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

動画や音声を埋め込んだページで、再生が始まったら中央の大きな再生ボタンを消す、読み込み待ちの間だけ画面を少し暗くする、といった切り替えを組んだことはないでしょうか。こうした見た目の出し分けは、これまでJavaScriptで再生や停止のイベントを拾い、要素にクラスを付け外しして実現するのが定番でした。その状態の判定を、CSSの側から直接書ける指定がブラウザに入ってきています。

再生中か止まっているかを見分ける指定

Chromeの開発者向けブログが公開したChrome 152ベータ版の案内には、:playing、:paused、:seeking、:buffering、:stalled、:muted、:volume-lockedという疑似クラスが並んでいます。いずれもaudio要素とvideo要素を、そのときの状態にもとづいて選ぶためのものです。

MDNの説明によると、:playingはメディアが再生されている状態を表します。興味深いのは、いま実際に映像や音が進んでいる場合だけでなく、利用者の意思以外の理由で一時的に止まっている場合も再生中として扱う点です。つまり、回線が細くて読み込み待ちになっている最中も:playingに当てはまります。利用者が自分でボタンを押して止めたときが:paused、というすみ分けになっています。

読み込み待ちや消音といった細かい状態も拾える

:bufferingは、再生を続けたいのにデータが足りず、読み込みを待っている状態を指します。MDNには、:bufferingに当てはまる要素は:playingにも同時に当てはまる、とはっきり書かれています。待機中の表示を出しているあいだも再生中用のスタイルは効いたままになるので、両方が重なる前提で指定を組む必要があります。

:mutedは、音を出せる要素が消音されている状態です。似たものに:volume-lockedがありますが、こちらは端末やブラウザ側の設定によって、JavaScriptからは消音の切り替えも音量の変更もできない状態を指します。作り手が制御できる消音と、作り手には手が出せない音量の固定を、別々に見分けられるようになっているわけです。

書き方は素直で、MDNにはvideo:mutedに枠線を付ける例が載っています。video:not(:muted)と組み合わせれば、音が出ている状態との出し分けもできます。利用者が再生コントロールで消音を切り替えれば、その場でスタイルのほうも切り替わります。

状態の同期をスクリプトに任せなくてよくなる

この手の状態管理は、地味に事故が起きやすいところです。イベントの取りこぼし、同じ画面に複数の動画を置いたときの指定の衝突、画面を切り替えたあとに前の状態が残ってしまう、といった不具合は制作の現場ではおなじみでしょう。判定をブラウザ自身が持ってくれるなら、そもそも表示と実態がずれる余地が小さくなります。

地方の中小企業のサイトでも、会社紹介の動画や商品の紹介映像を置くことは珍しくありません。凝った独自プレーヤーを作らない場合でも、再生が始まったら重ねていた説明の見せ方を控えめにする、読み込みが長引いているときだけ待機中の表示を出す、といった調整はCSSの側だけで書けるようになります。スクリプトを増やさずに済む分、表示の軽さにも保守のしやすさにも効いてきます。

いまの対応状況と現実的な取り入れ方

ただし、すぐにどこでも使えるわけではありません。MDNの各ページには限定的な対応と表示されていて、広く使われているブラウザの一部では動かないためBaselineには達していない、と明記されています。手元のブラウザで動いたからといって、すべての来訪者に同じ見え方を届けられる段階ではない点は押さえておきたいところです。

一方でChromeの案内では、これらの疑似クラスがInterop 2026の重点分野の一つに挙げられています。Interopはブラウザごとの実装のばらつきを揃えていくための取り組みなので、そこに入っているということは、対応が広がる方向で足並みが揃いつつあると読んでよさそうです。

現実的な取り入れ方は、これまでどおりの作りを土台に置いたうえで、対応しているブラウザでは見え方がもう少し気の利いたものになる、という上乗せの形でしょう。動かないブラウザでも困らない範囲から試してみると、次にプレーヤーまわりを触るときの引き出しが一つ増えます。

ゲスト購入した注文をあとから会員に紐づけられるように

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

ウェブショップを動かすWooCommerceの新しい版、11.0が公開されました。八月四日付の公開で、551件の変更が取り込まれ、89人が関わった大きめの更新です。中身は目新しい機能を足すより、土台の整理と積み残しの解消に寄っています。その中で買い物客の側から見て分かりやすいのが、ゲスト購入まわりの扱いの変化です。

WooCommerceには以前から、購入手続きを終えたあとにアカウントを作れる仕組みが用意されていました。11.0ではそこから一歩進んで、購入者が過去のゲスト注文を自分で探し出し、メールアドレスの確認を経てアカウントに結び付けられるようになっています。会員登録を後回しにしたまま何度か買い物をした人でも、あとから注文履歴を一つにまとめられる、という流れです。店舗側で名寄せの問い合わせに対応していた手間が、そのぶん減る可能性があります。

規模の大きい店舗向けの速度改善も入りました。内部の問い合わせの最適化、Store APIの改善、注文処理を通した在庫状態の扱いの見直しが挙げられており、商品数や注文数が増えるほど効いてくる部分です。ほかに、計測の取りこぼしを減らす調整、返金を売上の集計に反映する変更、取り込みに失敗した過去データをやり直せる仕組みも含まれています。

直後に出た修正版もあわせて

その六日後には11.0.1が出ています。こちらはセキュリティ更新の扱いで、ゲストのセッションcookieがソルト付きのより強いハッシュに変わりました。古いcookieは期限が切れるまで有効なままなので、更新をまたいでもゲストのカートは残ります。ほかにも、商品の短い説明にもパスワード保護が及ぶようになった点、Store APIでクーポンの利用回数の上限が正しく適用されるようになった点、カートや購入手続きのブロックに表示される通知の中身が安全に処理されるようになった点が並びます。ログの書き込みのたびにフォルダ全体を走査しなくなり、記録がたまった店舗で購入手続きが重くなりにくくなった改善も入りました。あわせて、次のWordPress 7.1に向けた互換性の調整も進んでいます。注文一覧が新しい一覧表の記述に合わせられた、といった地味な内容ですが、本体の更新を控えている店舗にとっては先に当てておきたい版といえます。

会員登録を必須にすると買い物の途中で離れられやすい、という悩みは店舗の規模を問わず共通です。ゲストのまま買えるようにしておき、必要になったときに履歴をアカウントへ寄せられる作りは、無理のない落としどころだと感じます。会員向けの案内やクーポンを届けたい店舗にとっても、購入のハードルを上げずに接点を作れる余地が広がります。一方で、注文とアカウントを結び付ける処理はメールアドレスの確認を挟むとはいえ個人情報に触れる部分なので、公開前に自分の店舗の設定で挙動を一度確かめておきたいところです。11.0はデータベースの更新を伴うため、控えを取ったうえで検証環境から順に試すのが安全です。

ChromeとFirefoxの更新間隔が秋から短くなる

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

ブラウザの新しい版が届く間隔が、この秋から短くなる。GoogleはChromeの安定版を4週間ごとに出してきたが、9月から2週間ごとに切り替える。ほぼ同じ時期に、MozillaもFirefoxで同じ方向の変更を試す。新機能が増えるという話とは少し性格が違って、これはサイトを作って納品したあとの面倒の見方、つまり段取りのほうに関わる変更だと思う。

Chromeは九月から二週間ごとに

Chrome for Developersの告知によると、新しい間隔での最初の安定版はChrome 153で、公開は2026年9月8日。ベータ版は各安定版の3週間前に出る。対象はデスクトップに限らずAndroidとiOSも含まれ、すべてのプラットフォームで同じ間隔になる。

変わらない部分もある。企業の管理者や、Chromiumを自社製品に組み込んで使う側に向けたExtended Stableは、これまでどおり8週間ごとのまま。DevとCanaryにも変更はない。更新の回数が増える代わりに、1回あたりに入る変更の幅は小さくなる。Googleはその点を、利用者への影響を抑えられて、公開後に問題を追いかけるときも切り分けがしやすくなる理由として挙げている。

切り替えの前後では、開発の締め切りにあたるブランチの日程も前倒しになる。告知には移行期の日程表が添えられていて、どの版がいつ枝分かれしていつ公開されるかが並べてある。個別の機能がどの版に入る予定かを追いたい場合は、Chromiumのダッシュボードや Chrome Status のロードマップで日付を確認できる。

Firefoxも同じ時期に間隔を詰める

Mozillaの開発者向けメーリングリストでは、Sylvestre Ledru氏が、Firefoxのデスクトップ版とAndroid版を9月から4週間間隔ではなく2週間間隔にすると告知している。最初の対象はFirefox 155で、公開予定は9月1日。これまでの日程なら出せなかったタイミングだ。

ただしMozillaはこれを実験と位置づけている。恒久的な変更と決め打ちせず、実際に走らせてみた結果を見ながら必要に応じて調整するという書き方をしている。開発者に倍の速さで働くことを求めるものではなく、準備できていない仕事を急がせるつもりもない、機能は必要なだけ時間をかけてよい、という説明も添えられている。頻度を上げる狙いは、出せる状態になったものが利用者に届くまでの待ち時間を減らすところにある。

四週間ごとで出る最後のChrome 152

現行の間隔で出る最後の版がChrome 152になる。ベータの告知を見ると、CSS側では音声や動画の状態に応じて見た目を変えられる擬似クラスが増えている。再生中や一時停止中、読み込み待ち、消音といった状態を :playing や :paused のような形で書き分けられる。自前の再生ボタンを作るときに、状態の受け渡しをJavaScriptで持たずに済む場面がありそうだ。

ほかにも、既存の色を参照して透明度だけを変えられる相対的な指定や、入力欄の自動修正の効き方を制御する autocorrect 属性が入る。どれも派手な機能ではないが、実務でよく書いていた小さな回り道を減らす種類の変更が並んでいる。こうした細かい追加が、これからは半分の間隔で積み上がっていくことになる。

保守の段取りをどこで区切るか

頻度が上がって困るのは、たいてい機能そのものではなく、こちら側の段取りのほうだ。よくあるのが、保守の説明や見積書に「最新版のChromeとFirefoxで表示確認」と書いてあるだけで、いつ確認するかは決めていないというケース。間隔が半分になると、確認の回数を増やすのか、こちらで区切りを決めてまとめて棚卸しするのかを先に決めておかないと、追いつけていない感覚だけが残ってしまう。

現実的なのは、毎回は追いかけないと割り切ることだと思う。ベータ版で先に触れる期間は変わらず用意されているので、自分たちが関わるサイトで実際に使っている仕組みに関係する変更だけを拾い、それ以外は通常の保守の周期でまとめて見る。手の数が限られている小規模な制作現場ほど、この線引きを最初にしておく効果は大きい。

頻度が上がることには直接の利点もある。修正が手元に届くまでの待ち時間が短くなることだ。深刻な脆弱性の修正を定期便とは別に配る仕組みは以前からあるが、通常の不具合や表示の食い違いも、これまでより早く解消されるようになる。閲覧する側の環境が新しくなる速度が上がるという意味では、作る側にとって悪い話ではない。

もうひとつ、版番号を条件にした分岐や、対応範囲を版番号で書いた文書は、これから急速に古びていく。番号ではなく、その機能が使えるかどうかで判断する書き方に寄せておいたほうが、あとで書き換える手間は少なくて済む。ブラウザ側が速く動くようになるほど、こちら側は番号から距離を置いたほうが楽になる。

外向きの通信先をサイト側で絞れる仕組みがChromeに

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

ページの中から外へ出ていく通信の宛先を、サイト側があらかじめ決めておく。そんな仕組みがChromeのベータ版に入った。Connection Allowlistsと呼ばれる機能で、少し前の版からオリジントライアルとして試験提供されていたものが、次の安定版で正式に出荷される段階へ進んだ。出荷予告によれば、デスクトップとAndroid、WebViewを対象に、利用者側で特別な設定をしなくても有効になるとされている。

使い方はHTTPのレスポンスヘッダー1本だ。Connection-Allowlist というヘッダーに、通信を許可するURLのパターンを並べて返す。ブラウザは接続を張る前に宛先を照らし合わせ、リストに載っていない相手には接続しない。自分自身のオリジンを含めたいときは response-origin という書き方が用意されている。対象になるのはfetchによるサブリソース取得だけでなく、画面遷移やリダイレクト、prefetchやpreconnectといった先読み系の指定、さらにWebSocketやWebTransport、WebRTCまで広い。文書だけでなく、Worker類にも適用できるとされている。

考え方としてはコンテンツセキュリティポリシー(CSP)の connect-src に近いが、CSPが読み込み元を用途ごとに細かく書き分けるのに対して、こちらは許可する宛先の一覧を一箇所にまとめ、接続を確立する手前でまとめて判定する。狙いとしてわかりやすいのは、外部から読み込んでいるスクリプトが何らかの理由で書き換えられ、フォームに入力された内容を見知らぬ宛先へ送り出してしまうような事故だろう。そうした通信を、ブラウザ自身が門番となって止める位置づけになる。

いきなり遮断せずに様子を見られる

現場的にありがたいのは、記録だけを取るモードが最初から用意されている点だ。Connection-Allowlist-Report-Only というヘッダーを使うと、実際の通信は止めないまま、リストから外れた宛先をReporting API経由で受け取れる。開発者ツール側の対応も入っているとされ、稼働中のサイトにいきなり適用して決済や地図が動かなくなる、という事態を避けながら、自分のサイトがどこへ通信しているのかを棚卸しできる。

一方で、現時点で実装を表明しているのはChromiumの系列だけだ。Firefoxはヘッダーの書式をめぐって意見の相違があり議論中、Safariは公式な立場をまだ示していないとされている。守りをこれ一本に預けるのではなく、これまで通りCSPを整えたうえで、対応するブラウザでは壁がもう一枚立つ、と考えるのが現実的だろう。中小企業のサイトでも、アクセス解析のタグ、チャットの窓口、フォーム、外部サービスの埋め込みと、気づけば通信先は増えていく。まずはレポート専用のモードで一度眺めてみると、思っていたより多くの宛先が並ぶかもしれない。

メニューの現在地と画面遷移をCSSで指定する提案

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

サイトのグローバルメニューで「今いるページ」だけ色を変える。制作の現場では当たり前にやっている処理ですが、実装の中身はいまだに泥臭いままです。WordPressならテンプレート側で付与されるクラスを頼りにし、静的サイトなら手書きでクラスを足すか、JavaScriptでURLを見て付け替える。ページ遷移のアニメーションまで含めると、さらに手数が増えます。

その領域をCSSの言葉で書けるようにしよう、という提案が7月末に公開され、8月に入って各所で取り上げられています。Chromeの開発者リレーション側から出ているもので、CSS Working Groupのベルリンでの対面会議で発表されたとされています。仕様案の名前はCSS Route and Navigation Matchingです。

URLのかたちに名前をつける

提案の土台になっているのが@routeという新しい記法です。URLのパターンに対して名前をつけておく、という発想で、たとえばトップページを表すパターンと、詳細ページを表すパターンをそれぞれ別の名前として登録します。パターンの書き方は、サーバー側のルーティングで広く使われている記法をそのまま持ち込む形になっています。

ここが効いてくるのは、URLの判定ロジックがスタイルシートの中に集約される点です。今までは「このページかどうか」の判定がテンプレート、JavaScript、CSSのクラス名の三箇所に散っていました。名前をつけて参照する形になれば、少なくとも見た目に関わる部分は一箇所に寄せられます。

サイトのURL設計そのものをスタイルシート側に書き写すことになるので、運用の途中でURLを変えたときの追従先が明確になる、という副次的な効果もありそうです。逆に言えば、パターンの登録場所が増えれば管理箇所も増えるわけで、そのあたりの落としどころは実装が出てからの評価待ちでしょう。

どこから来てどこへ行くかで演出を変える

@navigationは、遷移の出発点と到着点を条件にして、その組み合わせのときだけスタイルを効かせる仕組みです。一覧から詳細へ進むときは左へ流れ、詳細から一覧へ戻るときは右へ戻る、といった向きのある演出を、遷移の向きそのものを条件として書けます。

従来これを実現するには、遷移を横取りして遷移前と遷移後のURLを比べ、View Transitionの種類をスクリプトから動的に指定する必要がありました。ページ数が少ないうちはよくても、階層が増えるほど条件分岐が膨らみます。宣言的に書けるようになるなら、この手のコードはかなり減らせそうです。

実務の目線で言えば、遷移演出は「入れたいが手間に見合わない」と判断されがちな部類です。デザイン段階では案に上がっても、実装コストと不具合の起きやすさを考えて見送る。書き方が数行で済むなら、その判断のラインは確実に動きます。

リンクの行き先を見て装飾する

もうひとつ、:link-to()という擬似クラスが提案されています。リンクの行き先が、登録しておいたルートやURLパターンに合致するかどうかで、そのリンク自体の見た目を決められるというものです。冒頭に挙げたグローバルメニューの現在地表示は、まさにこれで書ける範囲に入ります。

あわせて、遷移のきっかけになった要素そのものを指す:nav-sourceも用意されています。押されたリンクやボタンだけを起点にした演出が組めるので、カード一覧から詳細へ移る際に押したカードだけを動かす、といった表現が素直に書けるようになります。

現時点でできること

状態としてはまだ仕様の草案段階で、Chrome Canaryで実験的機能のフラグを立てれば試せる、という位置づけです。仕様の細部は議論の最中で、GitHub上で意見を募っている段階でもあります。今日の案件に持ち込むものではありません。

ただ、方向としては注目に値します。この一年ほど、JavaScriptで組み立てていた挙動がHTMLやCSSの側へ移っていく流れが続いており、この提案もその延長線上にあります。中小企業のサイトのように、メニューが数項目で、遷移の演出も凝ったものは求められない案件ほど、この手の機能は恩恵が大きいはずです。現在地の表示のためだけにスクリプトを1本読み込む、という判断をしなくて済むからです。

今のうちにできるのは、自社サイトや保守案件で現在地表示や遷移演出をどう組んでいるかを把握しておくことくらいでしょう。実装が散らばっているほど、こうした仕様が実装されたときの整理の効果は大きくなります。

更新前に確かめておきたいWordPressの挙動変更

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

WordPressの次の版が8月19日に公開される予定で、いまは公開直前の候補版が配布され、検証が進んでいる段階です。新機能の紹介はあちこちで出そろってきましたが、制作の現場で先に気になるのは、いま動いているサイトのどこが変わるかのほうではないでしょうか。

公式の開発者向けまとめを読むと、機能追加とは別に、既存のテーマやプラグインが前提にしていた作りが静かに変わる箇所がいくつかあります。派手な話ではありませんが、当たっていると管理画面の見た目や動きに出ます。更新前に目を通しておきたいものを並べてみます。

投稿の編集画面が常に枠の中で動く

これまでは、テーマの種類やブロックの版によって、投稿編集画面がiframeの中に入るかどうかが切り替わっていました。次の版では条件によらず常に枠の中で動きます。どちらになるか読めない状態が解消されるのは扱いやすくなる方向の変更です。

ただし、編集画面に独自の見た目を足している場合は挙動が変わる可能性があります。enqueue_block_editor_assetsのような正規の入口から読み込んでいれば影響は小さいはずですが、管理画面全体のCSSに紛れ込ませていたり、親の画面を直接触るスクリプトを書いている場合は、実際に開いて確かめておくのが早いです。

一覧画面の表の作りが変わる

投稿一覧などの表で、行の見出しとして扱われるセルが、チェックボックスの列からタイトルの列へ移ります。読み上げたときの筋道としては素直になる変更ですが、列の位置を決め打ちしたセレクタに頼っている拡張は影響を受けることがあります。

一覧に独自の列を足すプラグインは、中小企業のサイトでもよく入っています。受注状況や公開予定日を一覧に出すような作り込みをしている場合は、更新前に検証用の環境で開いてみる価値があります。

管理画面の入力部品の大きさがそろう

管理画面の部品群では、大きさを指定していたプロパティが役目を終え、フォーム部品は一律で40ピクセルの高さで描かれるようになります。小さめの指定は渡しても効かなくなり、非推奨の扱いになります。

独自の設定画面を持つプラグインを作っている場合、詰めて並べていた入力欄の高さが変わり、レイアウトが縦に少し伸びることがあります。壊れる類の変更ではありませんが、二列に並べていた部分の折り返しなど、見た目の調整が必要になるかもしれません。

ナビゲーションの文字サイズの効き方が変わる

ナビゲーションのブロックが、子の項目に自分の文字サイズを押し付けなくなります。入れ子のドロップダウンで文字サイズが掛け算のように効いてしまい、階層が深いほど不自然に大きくなる、あるいは小さくなるという問題への対処です。

回り道の指定でごまかしていた部分が本体側で正されるのはありがたい変更ですが、裏を返せば、更新後にメニューまわりの見た目が変わるサイトはあるということです。納品済みのサイトが複数ある制作者は、階層メニューを持つものだけでも一度目視しておきたいところです。

実験段階だった機能が正式に使えるようになる

タブとプレイリストのブロックが実験扱いから外れ、標準の部品として使えるようになります。加えて、背景にグラデーションと画像を重ねられる指定や、ブロックの最小幅を指定できる仕組みも増えました。管理画面に説明の吹き出しを出すための関数も用意され、読み上げに配慮した形で組み込めるようになっています。

これまで小さなプラグインや自作のブロックで賄っていた部分が、本体側だけで足りるようになるかもしれません。プラグインの数を減らせれば更新の手間も脆弱性の窓口も減るので、棚卸しのきっかけにはなりそうです。

公開までは一週間ほどです。候補版は検証用に配布されているので、複雑なテーマや作り込んだ管理画面を抱えているサイトは、本番の更新を待つ前に複製した環境で一度開いておくと、当日は落ち着いて臨めます。

よくある質問の飾りが消えたあとの構造化データ

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

検索結果の見た目にかかわる仕組みは、この数年でずいぶん整理されてきた。中でも設置していたサイトが多かったのが、質問と回答を検索結果の中に折りたたんで見せるFAQのリッチリザルトだ。表示そのものは今年の五月に止まり、その後もSearch Console側の対応が段階的に外されてきた。最後まで残っていたAPIのサポートが、今月で終わる。

ひとつの表示形式が消えるという話にとどまらず、構造化データを何のために書くのかという前提が静かに動いている。過去に廃止された型の顔ぶれと、逆に細かくなっている領域を並べて見ると、その動きが見えてくる。

段階的に外されてきた対応が今月で終わる

時系列を整理しておく。FAQのリッチリザルトが検索結果に出なくなったのは五月七日で、翌日の五月八日にGoogleのドキュメントへ廃止の告知が入った。六月にはSearch Consoleの検索での見え方のレポートと、リッチリザルトテストからFAQの扱いが外れた。ドキュメント側でもFAQのリッチリザルトに関する記述そのものが削除されている。そして八月、Search Console APIからのサポートが外れる。

実務上の影響は、どこまで自動化しているかで変わる。管理画面を目視で確認しているだけなら、六月の時点でレポートが消えているので今月は何も起きない。一方、APIを叩いてレポートを自社ツールやスプレッドシートへ流し込んでいる場合、FAQの項目を参照している処理は今月のどこかで結果が返らなくなる。制作会社が保守で運用レポートを自動生成しているケースでは、ここが静かに壊れる。数字が出なくなるのではなく、項目そのものが無くなるという壊れ方なので、エラーで気づけるとは限らない点に注意したい。

付け加えると、Googleは表示をやめただけで、ページに書かれたFAQの構造化データを読むこと自体はやめていないと説明している。マークアップを急いで剥がす必要はない、という整理になる。

消えていった型に共通していたもの

廃止されたのはFAQだけではない。手順を検索結果に並べて見せるHowToは、モバイルでの表示が絞られたあと、二〇二三年九月にデスクトップでも出なくなった。教育系のサイトで使われていたPractice Problemは、今年一月にSearch Consoleとそのレポート機能からサポートが外れている。

共通しているのは、表示される機会がそもそも少なく、表示されても利用者があまり触っていなかった型だという点だ。Googleの説明でも、使われる頻度が低く利用者への価値が大きくない機能を整理した、という言い方をしている。逆に言えば、検索結果の面積は有限で、そこに何を出すかは常に取捨選択の対象だということでもある。

もうひとつ見落としやすいのが、FAQのリッチリザルトが後半では、政府機関や医療分野の、広く知られた権威あるサイトにしか出なくなっていたことだ。同じマークアップを書いても表示されるかどうかは相手次第で、それ以外のサイトでは書いても出ないという状態が先に来ていた。今回の廃止は、その状態を正式に確定させたに近い。

この経緯は、リッチリザルトを前提にページを設計することの危うさも示している。手順を並べる形式が有利だと聞いてHowTo用にページを組み直した制作現場は当時それなりにあったはずだが、その表示は数年で消えた。表示形式は検索側の都合で入れ替わるものだと考えておくほうが、長い目で見れば手戻りが少ない。

構造化データ全体が縮んでいるわけではない

廃止の告知が続いたことで、構造化データそのものを縮小していく方針なのではという受け取り方が一部で広がった。ただ、Googleはこれを明確に否定している。整理の対象はあくまで使われていない一部の型であり、基本的な情報の伝え方をやめるわけではない、という立場だ。担当者からは、表示形式は移り変わるものだが、タイトルタグやrobotsの指定のように手放してはいけないものもある、という趣旨の説明も出ている。

実際、記事、パンくず、事業所情報、商品、動画といった定番の型は今も現役で、廃止の予定は出ていない。中小企業のサイトで効いてくるのは元々このあたりで、FAQの有無で検索流入が大きく動いていたサイトはそう多くないはずだ。手を入れる優先順位を決めるときは、廃止された型の話より、こうした残っている型が正しく出力できているかを見るほうが実りがある。

商品や価格まわりはむしろ細かくなっている

縮小の反対側で、記述が細かくなっている領域もある。七月には、販売者向けの商品情報にcategoryプロパティが追加された。文字列でカテゴリ名を書く方法と、コード体系で指定する方法の両方が使えるようになっている。加えて、セール期間の扱いを説明する節が新設され、開始と終了の日時を表すvalidFrom、validThrough、そして表示価格の有効期限を示すpriceValidUntilの使い分けが整理された。

この方向は分かりやすい。人間が読む文章から機械的に取り出しにくい情報ほど、構造化データで明示する価値が残るということだ。質問と回答は本文を読めば分かるが、そのセール価格がいつまで有効なのかは本文の書きぶり次第で判別できない。だからこそ価格や在庫、期間といった要素は、むしろ書式が整えられていく。

通販をやっていないサイトでも、この考え方は流用できる。営業時間、所在地、対応エリア、料金の条件といった、本文中では表現がばらつきやすい情報を構造化データ側で揃えておくと、後から自分たちで検算しやすくなる。表示のためというより、データとしての整合性を保つための作業に近い。

付随して、期間を持つ情報には失効という考え方がついて回る点も押さえておきたい。終了日を書いた以上、その日を過ぎた記述が残っていれば、それは単に古い情報になる。構造化データを入れるということは、更新の責任を一つ増やすことでもある。誰がいつ見直すのかを決めないまま項目だけ増やすと、数年後に手をつけられない塊になりやすい。

口コミの扱いに条件が足された

七月下旬には、レビュースニペットのガイドラインにも追記があった。やらせのレビューや、報酬と引き換えに書かれたレビューについての基準が加わっている。星の数を検索結果に出す仕組みは以前から人気があるが、その分だけ、出所の怪しい評価を集めて表示させようとする動きも起きやすい。基準が明文化されたのは、そこに線を引く必要があったからだろう。

地方の事業者にとっては、他人事ではない話でもある。レビューを集める施策を外部の業者に任せている場合、その集め方がガイドラインに触れていないかは一度確認しておきたい。表示が止まるだけならまだしも、サイト全体の評価に影響が及ぶ形になると、回復に時間がかかる。

制作の現場で見直しておきたいところ

まず、FAQのブロック自体は消さなくていい。検索結果に出なくなっただけで、訪問者にとって質問と回答の形式が読みやすいことは変わらない。むしろ、リッチリザルト目当てで無理に質問形式へ変形させていたページがあるなら、この機会に読み物として自然な形へ戻すほうが素直だ。表示のために作られた文章は、たいてい読みにくい。

次に、構造化データの出所を把握しておきたい。WordPressで運用しているサイトの多くは、SEO系のプラグインやテーマが自動で出力している。プラグインを乗り換えたり、テーマを入れ替えたりしたときに、古い型と新しい型が二重に出ていたり、逆にどこからも出なくなっていたりすることがある。リッチリザルトテストやスキーマの検証ツールで、主要なページを何枚か抜き取って確認するだけでも状況はつかめる。

そして、レポートの自動化をしているなら今月のうちに参照箇所を確認しておく。APIの項目が消える変更は、画面を見ているだけでは気づきにくい。数年単位で運用するサイトほど、こういう小さな失効が積み重なって、いつの間にか誰も中身を保証できない状態になりやすい。

構造化データは、検索結果を飾るための道具から、ページの内容を機械に正しく渡すための道具へと、役割の重心が移りつつある。飾りが減ったぶん、書いた内容が正しいかどうかだけが残る。派手さはないが、こちらのほうが手入れのしがいはある。Google検索セントラルの更新履歴は日付順に並んでいるので、こうした変更を追うときの起点として使いやすい。