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で表示確認」と書いてあるだけで、いつ確認するかは決めていないというケース。間隔が半分になると、確認の回数を増やすのか、こちらで区切りを決めてまとめて棚卸しするのかを先に決めておかないと、追いつけていない感覚だけが残ってしまう。

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

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

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

メニューの現在地と画面遷移を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で一本化される

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

サイトにアイコンを一つ足すだけの作業が、案外ややこしい。テーマのフォルダにSVGを直接置く方法、プラグインが独自に読み込む方法、外部のアイコンフォントを呼ぶ方法が、同じサイトの中に混在していることは珍しくない。担当者が代わったあとで「この矢印はどこから来ているのか」を追いかけた経験のある人は多いはずだ。

8月19日に公開が予定されている次期WordPressで、この部分に手が入る。アイコンを本体側に登録しておき、編集画面からもテンプレートのPHPからも、さらにREST API経由でも同じ名前で取り出せる仕組みが、正式な関数として公開される。

これまでは各自で抱え込むしかなかった

アイコンを置くためのブロックは、ひとつ前のバージョンで本体に入っている。ただし、そこへ自社のロゴマークや業種特有の記号を足したい場合に、公開された入り口が用意されていなかった。開発者向けの告知によると、内部向けのクラスを無理に呼び出すか、プラグイン側で独自の一覧を持ち回るか、どちらかを選ぶしかない状態だったとされている。

結果として、ひとつのサイトの中に似たような管理方法がいくつも並ぶ。テーマの中にはあるのに編集画面の一覧には出てこない、といったずれも起きる。小さな話に見えて、更新や引き継ぎのたびに時間を取られるのはこういうところだ。

アイコンを足したい場面自体は、規模の小さいサイトほどよくある。問い合わせ先に添える電話やメールの記号、事業内容を並べたときの業種ごとのピクトグラム、外部の会員サイトへ誘導するボタンの矢印。どれも凝ったものではないが、既定の一覧に入っていなければ自前で持ち込むしかなかった。

登録は一か所、呼び出しは三通り

新しく加わるのは、アイコンのまとまりを作る関数と、そこへ個々のアイコンを加える関数だ。wp_register_icon_collection() でグループを作り、wp_register_icon() でSVGの中身かファイルの場所を渡す。名前は「グループ名/アイコン名」の形で付ける決まりで、使えるのは小文字と数字、ハイフン、アンダースコアに限られる。不要になったものを外す関数も対で用意されている。

登録したアイコンは三つの場所から使える。編集画面のアイコン選択欄ではグループごとのタブに分かれて並び、名前やラベルでの絞り込みも効く。テンプレート側では wp_get_icon() で書き出せて、大きさやクラス名、読み上げ用のラベルを添えられる。加えて /wp/v2/icon-collections や /wp/v2/icons といった読み取り専用のエンドポイントが用意され、記事を編集できる権限を持つユーザーであれば一覧を取得できる。

地味だが大きいのは、登録する場所がひとつに決まったことだと思う。テーマが持っていてもプラグインが持っていても、同じ棚に並ぶ。そのサイトで今どのアイコンが使えるのかを一覧で確認できる状態は、これまで意外と手に入らなかった。

読み込めるSVGはかなり絞られている

登録したSVGはそのまま出力されるわけではなく、本体のタグ整形処理を通る。許されるのは svg、path、polygon の三種類の要素と限られた属性だけで、それ以外の要素やインラインの装飾指定、スクリプト、イベント属性は落とされる。現時点では線の太さを指定する属性や、外側の要素に付けた塗りの指定も対象外とされている。

SVGは以前から、アップロードを許すと侵入の入り口になりやすい形式として扱われてきた。管理画面から自由に置けるようにしないほうがよい、という判断はここでも変わっていない。線で描いたアイコンを使いたい場合は、あらかじめ塗りの形に変換してから登録するといった準備が必要になる。窮屈ではあるが、安全側に倒した設計だと考えるとつじつまは合う。

効いてくるのは引き継ぎの場面

この変更は派手ではない。既存のサイトが速くなるわけでも、見た目が変わるわけでもない。効いてくるのは、作った人と日々更新する人が違うときだ。アイコンの出どころが一か所にまとまっていれば、あとから触る人はまずそこを見ればよい。制作会社が納品したあと社内で運用していく中小企業のサイトほど、この差は効いてくる。

もっとも、現時点での使いどころはアイコンを置くブロックとナビゲーション周りが中心で、既存のサイトを慌てて作り替えるような話ではない。新しくテーマやプラグインを組む段になって、アイコンをどこに持たせるか決めるときに、この方法があることを思い出せれば十分だろう。仕様の詳細は開発チームの告知にまとまっている。

毎年恒例のCSS調査から見える現場の使い分け

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

CSSの使われ方を毎年たずねている調査「State of CSS」の最新の結果が公開された。回答を集めたのは今年の5月中旬から6月末にかけてで、世界の制作者4,902人が答えている。新機能の発表そのものではないが、現場で何が実際に使われていて、何がまだ様子見なのかが数字で並ぶので、自分たちの手札を確かめる材料になる。

使用率の上位は、条件に合う子要素を持つ親側を指定できる :has() が83.7%、縦横比を保つ aspect-ratio が81.3%、入れ子で書ける CSS Nesting が70.6%と続いた。少し前まで「便利そうだが対応状況が心配」と言われていた顔ぶれが、上から順に普通の道具として定着したことになる。逆に、この春から夏にかけて主要ブラウザに入ったばかりの指定は使用率が数%にとどまっており、ブラウザで使えるようになったことと、実案件で使われることの間には、やはり数年単位の距離があるとわかる。参考にしている情報源としては、MDN と Can I Use を挙げた人が多かった。新しい指定を試す前に対応状況を確かめる、という手順が広く共有されているということだろう。

気に入られている機能と、使われている機能

面白いのは、注目度と使用率が一致していない点だ。回答者が最も気に入った新機能として挙げたのは、要素を別の要素に紐づけて配置するアンカーポジショニング(anchor positioning)だった。ところが「対応状況が理由で使えていない機能」の筆頭にも、同じ名前が並ぶ。画面遷移をなめらかに見せる View Transition API や、条件分岐を書ける if() も似た位置にいる。触ってみたい気持ちと、納品するサイトに入れられるかどうかの線引きが、はっきり分かれている様子がうかがえる。

つまずきどころとして多く挙がったのは配置まわりで、次いで :has()、コンテナの幅で見た目を出し分ける @container が並んだ。どれも、うまくはまれば記述量がぐっと減る反面、思ったように効かないときの原因追いに時間を取られやすい種類の機能だ。それでも全体の満足度は5段階でおよそ4と、ここ数年ほぼ横ばいのままだった。書きやすくなった実感と、細かいところでの引っかかりが同居している、という受け止め方が続いていることになる。

中小企業のサイトを預かる立場からすると、この手の調査は流行を追うためというより、線引きの目安として使いやすい。使用率が高く枯れた機能は迷わず採用し、話題の新しい指定は、効かなかったときの見え方まで用意できる範囲で試す。企業サイトは公開してから何年も動き続けるものが多く、閲覧環境の幅も広い。上位に並ぶような定着した機能であれば、古い端末が混ざる相手でも心配は少ない。数字を眺めながらそのあたりの分け方を決め直すだけでも、調査に目を通す価値はある。詳しい内訳は調査結果のページで公開されている。

地域ごとの週の始まりや暦をブラウザ標準で引ける仕組み

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

日付まわりの表示は、サイトを作っていればどこかで必ず触ることになります。予約フォームのカレンダー、記事の投稿日、営業日の一覧。一見どれも単純ですが、対象の地域が変わると前提そのものが変わります。週の始まりは日曜なのか月曜なのか、週末はどの曜日にあたるのか、どの暦を併記するのか。こうした知識は、これまでブラウザの外から持ってくるしかありませんでした。

2026年7月、JavaScriptの国際化機能であるIntl.Localeに加わった一連のメソッドが、主要ブラウザすべてで使える状態になりました。web.devの月次まとめによると、Firefox 153が対応したことで、Baselineの「新しく利用可能」に入ったとされています。地味な機能ですが、カレンダー部品を自作したことがある人ほど、ありがたみが分かる種類の追加です。

これまでは辞書を自前で抱えていた

「この地域では週が月曜から始まる」といった知識は、CLDRという国際的なデータベースにまとめられています。ただ、ブラウザからその中身を直接引く手段が長らくなく、カレンダーの見た目を自分で組む場合は、データの一部を写し取ったライブラリを読み込むのが普通でした。週の初日を表す値ひとつのために、数十キロバイトの追加読み込みが発生することも珍しくありません。

Intl自体はかなり前からあり、Intl.DateTimeFormatを使えば日付を地域の書式に整えることはできました。ただしそれは整形済みの文字列が返ってくるだけで、UIを自分で組み立てるために必要な素の情報、たとえば曜日を並べる順番の起点までは取り出せません。今回埋まったのは、ちょうどこの隙間にあたる部分です。

Intl.Localeから引けるようになった情報

書き方は素直で、ロケールを表すオブジェクトを作ってメソッドを呼ぶだけです。new Intl.Locale("ja-JP").getWeekInfo() のように書くと、週の始まりの曜日、週末にあたる曜日、その年の最初の週とみなすための最小日数がまとめて返ってきます。曜日は1が月曜、7が日曜という決まりになっています。

同じ要領で、その地域で使われる暦の一覧を返す getCalendars()、時刻を12時間制と24時間制のどちらで扱うかを返す getHourCycles()、文字を左から右に並べるか右から左に並べるかを返す getTextInfo()、地域に結び付いたタイムゾーンの一覧を返す getTimeZones() が用意されています。ほかに数字の表記体系や並べ替えの規則を返すものもあり、いずれも MDNのIntl.Localeのページに一覧があります。

返ってくるのは配列や小さなオブジェクトなので、そのまま画面に出すというより、自分のUIの初期値として使う性格のものです。

日本語のサイトで効いてくる場面

日本のロケールで getCalendars() を呼ぶと、グレゴリオ暦と和暦の識別子が返ってきます。行政関連の書類を扱うサイトや、年号の併記が求められる申込フォームでは、この結果を起点にIntl.DateTimeFormatへ和暦を指定する、という流れが自然に組めます。和暦を出すかどうかを地域の慣習として扱えるので、判定を自前のif文で書き分けずに済みます。

週の始まりも実務的です。日本語圏では日曜始まり、英国では月曜始まりというように、カレンダーの見た目は地域で割れます。多言語対応のサイトで同じカレンダー部品を使い回すとき、対応表を自分で抱えなくてよくなるのは負担が減るところです。予約カレンダーや営業日の表示は、中小企業のサイトでも決して珍しい要素ではありません。

使う前に確認しておきたいところ

Baselineの「新しく利用可能」は、主要ブラウザの最新版で動くという意味であって、少し前の端末まで含めて安全という意味ではありません。企業サイトの訪問者には更新の止まった端末も混ざりますから、メソッドがあるかどうかを確かめて、無ければ従来どおりの既定値を使う、という組み方が現実的です。値が取れなくても表示が壊れないようにしておけば十分です。

もう一点、以前の実装ではメソッドではなくプロパティとして提供されていた時期があります。古い解説記事のコードをそのまま持ってくると動かないことがあるので、参照する情報の新しさには注意しておきたいところです。

外部ライブラリに頼っていた小さな機能が標準側に移ると、依存パッケージがひとつ減り、更新の手間もその分軽くなります。派手さはありませんが、次にカレンダーまわりを触る機会があれば、置き換えられる部分がないか見ておく価値はありそうです。

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

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

ウェブサイトの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日の証明書では余裕がなくなります。日次で実行して更新時期が来たものだけ更新する形にしておけば、期間が変わっても影響を受けません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

記事の目次を自動で組み立てる

長い記事に目次を付けたいときも、これまでは専用プラグインが定番でした。新しいTable of Contents(目次)ブロックは、本文の見出しを読み取って目次を自動で生成します。見出しを増やしたり並べ替えたりしても目次がそれに追従するため、更新のたびに手作業でリンクを張り直す必要がなくなります。読み手が長文の全体像をつかみやすくなり、目的の項目にすぐ飛べるようになる点も、問い合わせページやサービス紹介ページでの実用的な利点です。

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

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

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

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

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

フォームの入力欄が中身に合わせて伸縮するCSSの新プロパティ

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

問い合わせフォームやアンケートを作っていると、テキスト入力欄の高さで毎回悩みます。狭くすると長文が書きづらく、広くすると空白ばかりで間が抜けて見えます。落としどころを最初に決めても、実際に届く文章の長さは人によってばらばらで、どこかで無理が出ます。これまでは入力量に合わせて欄を伸ばすのに、文字数や高さを測って調整するJavaScriptを書くのが定番でした。入力のたびに走らせる地味な処理ですが、行数計算や初期化の順番でつまずくと、意外と手のかかる部分でもありました。

この処理をブラウザ側に任せられるCSSのプロパティが、主要ブラウザで使えるようになりました。field-sizingです。MDNによると、field-sizingは2026年に主要4エンジン(Chrome、Edge、Firefox、Safari)が出そろい、安心して使える段階を示すBaselineの「新規利用可能」に入りました。数行のCSSで、フォーム部品を中身に応じて伸び縮みさせられます。

fixedからcontentへ切り替えるだけ

field-sizingが取る値は2つだけです。初期値のfixedは、これまでどおり決まった大きさを保つ従来の挙動です。もう一方のcontentを指定すると、部品が中身の分だけの大きさに縮み、文字が増えるほど広がっていきます。使い方も、対象の要素にfield-sizingをcontentと書くだけで、特別な初期化やイベント登録はいりません。

textareaに指定した場合、まず横幅の許す範囲で広がり、幅の上限に達すると今度は行を増やして縦に伸びます。高さの上限まで来ると、そこで初めてスクロールバーが出ます。つまり、入力が短いうちは小さく、長くなるにつれて必要な分だけ育つという自然な動きになります。content指定時はrowsやcols属性は効かなくなり、大きさの決定はCSS側に移ります。

textareaだけでなく入力欄や選択肢にも効く

このプロパティが便利なのは、複数行のtextareaに限らない点です。一行のtextやsearchといった入力欄でも、中身の幅に合わせて欄が伸びます。placeholderを設定しておけば、その文言が収まる程度の幅で表示され、入力するにつれて広がっていきます。ファイル選択の入力欄では、選んだファイル名の長さに合わせて幅が変わります。

selectのドロップダウンにも効きます。通常は一番長い選択肢に合わせた幅で固定されますが、content指定なら今選ばれている項目の幅にぴったり合わせて幅が変わります。並びが間延びしがちな選択式の項目を、すっきり見せられます。フォームを構成する部品のほとんどが、同じ一つのプロパティで足並みをそろえられるわけです。

暴走させないための上限指定

中身に合わせて自由に伸びるということは、極端に長い入力で欄がレイアウトを押し広げてしまう心配もあります。そこでmax-widthやmax-heightで上限を、min-widthで下限を添えて、伸縮する範囲を枠にはめておくのが実務的です。上限まで来ればスクロールに切り替わるので、際限なく広がることはありません。逆に、widthやheightで固定寸法を決めてしまうと伸縮の余地がなくなるため、併用は避けます。文字数を制限したい欄では、maxlength属性が上限に達した時点で成長も止まります。

制作現場での使いどころ

中小企業サイトの多くは、問い合わせや資料請求といったフォームが成果につながる入口です。入力欄が窮屈だと、長めの相談内容を書く途中で書きづらさを感じて離脱されることもあります。入力に応じて欄が自然に広がるだけで、書き心地の印象は変わりますし、送信前に全文を見渡せる安心感にもつながります。

これまで数十行のスクリプトで実装していた自動リサイズが、一行のCSSで済むのも見逃せません。JavaScriptが減れば、その分だけ表示の負荷も保守の手間も軽くなります。Firefoxは対応が最後発だった経緯があるため、古い環境も想定する案件では、content指定を土台にしつつ、非対応のブラウザではこれまでどおりの固定サイズで問題なく使えるという前提で組んでおくと安心です。あってもなくても壊れない、あれば快適になるという足し方であれば、今日から少しずつ取り入れられます。ブラウザ標準の機能で書き心地を底上げできる場面は、着実に増えています。