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

【NO.149】謝れない同僚がやってきた



「今何時？」と聞かれたら「そうねだいたいね」と答える、めんどくさい昭和世代です。
ネットフリックスのドラマ「ガス人間」で、
ピタゴラスイッチから「いとしのエリー」へ流れるところにはググッと来ました。


ガス人間は、悪いことをした人間に責任を取らせるドラマです。
まあ実際のところは復讐なのですが、それが責任を取らせる、という言葉で受け取られている。
この響きが、しばらく頭に残っていました。


というわけで今日は、責任の話をします。


社長が辞任する。深く頭を下げる。あの角度と、あの秒数には、たぶん誰も明文化していない基準がある。
浅すぎれば反省が足りないと言われ、長すぎれば今度は演出くさいと言われる。
世の中には、練習しないと務まらない仕事がずいぶんある。


それで、頭を上げたあと、壊れたシステムは直っているだろうか。直っていない。
失われたお金も戻っていない。当たり前だ。辞任は復旧作業ではない。


にもかかわらず、私たちはそこで一区切りついた気になる。

ニュースは次の話題へ移り、翌朝には別の見出しが並んでいる。


そもそも「責任を取る」という言い方が、落ち着いて考えるとおかしい。取ったあと、それをどこへ持っていったのかを誰も聞かない。持ち帰ったのか、置いてきたのか。お土産のように誰かに渡したのか。
取った本人ですら、たぶん説明できない。


この妙な習慣を、私たちは長いあいだ疑わずに使ってきた。
そして今、疑わないままでは済まなくなりつつある。
会社のなかに、頭を下げられないものが働きはじめたからだ。


責任という言葉が大きすぎる
責任には、本来もっと細かい名前がついている。


決めたことをやりきる行動責任がある。
何がどうなったのかを筋道立てて話す説明責任がある。
法に照らして問われる法的責任があり、法には触れていないが人としてどうなのかを問われる道義的責任がある。
部下の不始末に及ぶ監督責任があり、仕組みや部署を預かる管理責任があり、意図がどうであれ出たもので問われる結果責任があり、会社が世の中に対して負う社会的責任がある。

これだけ名前が分かれているということは、本来それぞれ別のものだということだ。
ところが実際の会議で使われるのは、たいてい上位概念の方の「責任」である。
「責任の所在をはっきりさせましょう」という一言で、この全部がまとめて一つの箱に放り込まれる。
ちなみにこの発言が出た会議は、経験上あまりはっきりしないまま終わる。

箱に放り込むと何が起きるか。中身の性質が、確認されないまま混ざる。
なかでも紛らわしいのが、直す方の責任と、痛む方の責任だ。
この二つは、同じ箱に入っているのが不思議なくらい別物である。

直す方は、実務だ。原因を調べ、手を動かし、再発しないようにする。誰がやってもよく、むしろ上手い人がやった方がいい。説明責任や管理責任は、だいたいこちら側に寄っている。

痛む方は、実務ではない。頭を下げても不具合は直らないし、辞めても売上は戻らない。役に立っていないのに、省略すると許してもらえない。あれは修理ではなく儀式である。壊れたのはシステムだけではなく、まわりの人の信頼の方でもあるので、そちらを焚きつけ直すために誰かが痛む必要がある。道義的責任や結果責任が引き受けているのは、たいていこちらだ。

そして日本の会社は長らく、この二つを一人の人間に束ねてきた。責任者という肩書は、直す指揮も執り、いざとなれば痛む係も兼任する、という意味である。名刺には書いていないが、そういう契約になっている。

謝れない同僚
さて、ここにAIが入ってくる。
AIはよく働く。深夜でも文句を言わないし、頼めば何度でもやり直す。直す方の責任なら、かなりの部分を担える。
この点については、もう議論の余地が薄くなってきた。

問題は、痛む方である。
AIは頭を下げられない。正確に言うと、下げる動作はできる。申し訳ありませんと出力することくらい、朝飯前だ。ただ、そこに縮こまるものが何もない。失う面目もなければ、翌朝の気まずさもない。儀式は、受け手が痛むという前提で組まれているので、痛まないものを入れた瞬間、装置ごと空回りする。

つまり会社は、生まれて初めて、こういう同僚を迎えることになった。仕事はできる。謝れない。
これがどれくらい厄介かというと、たとえば社内でAIに何かを任せようとするときの、あの妙な足踏みを思い出してほしい。技術的にはできる。効果も出そうだ。それなのに、稟議のどこかで必ず止まる。止まる場所はだいたい決まっていて、それで、何かあったときは誰が、というあたりである。

このとき現場が困っているのは、AIの精度ではない。
責任という一語のなかで、直す方と痛む方がくっついたまま議論されているせいで、話が前に進まないのだ。

AIに任せるという提案は、直す方の話をしている。
会議室で不安になっている人は、痛む方の話をしている。

同じ単語を使っているので、噛み合っていないことに誰も気づけない。
導入が進まない会社は、たいてい技術で負けているのではなく、この分解をしていないだけだったりする。

痛む係という職業
会社がまず思いつく解決策は、たぶんこれである。
実務はAIにやらせて、隣に頭を下げる人間を置く。

そんな乱暴なことをするだろうかと思うかもしれないが、もう部分的に始まっている。
情報漏洩の会見で深く頭を下げている役員が、自社のシステムの中身を一行も理解していない、という光景をときどき見る。あの人は、事件が起きてから自社の構成をいちばん熱心に勉強することになる。順番が逆なのだが、儀式の担当としては別に間違っていない。
この配置は、短期的にはよく機能する。仕事は速いし、頭を下げる人もちゃんといる。書類の上では何も欠けていない。
ただ、長くはもたないと思う。儀式というのは、痛む人が事情を分かっていることを、うっすら前提にしているからだ。何が起きたのかよく分からないまま謝っている人を見ても、こちらの信頼は焚きつけ直らない。むしろ少し寒くなる。役に立たない儀式は、やがて誰も本気にしなくなる。

辞任しない社長
その先に、AI社長がいる。
私はこれが望ましいとは思っていない。ただ、順番として来るだろうとは思っている。
直す方の責任を担える範囲が広がり続ければ、束ねていたピンはいずれ抜ける。
望むかどうかと、来るかどうかは、別の話だ。

そして、そこで儀式が完全に空転する。AI社長が辞任する場面を想像してみてほしい。深く頭を下げる。辞める。翌日には同じものが別の会社で働いている。退職金も要らないし、気まずくもない。世間の溜飲は、たぶん１ミリも下がらない。

このとき私たちが失うのは、社長ではない。秩序を戻す手続きの方である。
壊れたものを直すことはできるのに、壊れた信頼を戻す方法だけが手元からなくなる。
厄介なのは前者ではなく、後者だ。

会社は、すでに一度これをやっている
ここで少し気が楽になる話をしたい。
会社という仕組みそのものが、もともと同じことをやった発明だからだ。

法人は生き物ではない。食事もしないし、眠りもしない。それなのに契約を結び、お金を払い、税を納め、そして信用を失う。誰も見たことがないものに人格を認めて、痛む役を肩代わりさせる。落ち着いて考えると、かなり無茶な発想である。最初に言い出した人は、相当変な顔をされたのではないかと思う。

けれども今では、誰もこれを疑わない。会社が信用を失う、という言い方に違和感を持つ人はいない。私たちは既に一度、痛む主体を虚構に預けることに成功している。

だから今回は、初めての作り直しではない。二度目だ。二度目には、少なくとも前例がある。

箱を開けるところから
とはいえ、最初にやることは壮大な制度設計ではないと思う。もっと地味な作業だ。
責任という箱を開けて、中身に名前を戻す。今この会議で話しているのは、直す方なのか、痛む方なのか。説明責任なのか、監督責任なのか、それとも誰かに痛んでほしいという気持ちなのか。それを分けて置くだけでいい。

これは今日からできる。AI導入の稟議が止まったとき、何かあったときは誰が、という問いを二つに割ってみてほしい。何かあったとき誰が直すのか。何かあったとき誰が引き受けるのか。この二つは、答える人も、必要な備えも、まるでちがう。割った瞬間に前へ進む話は、かなり多い。

人類は言葉を大きく使いすぎてきた。
大きい言葉は運ぶのが楽なので、そのまま何百年も運んできた。
中身を並べ直す時期に来たというだけの話で、それは失うことではなく、名前を取り戻すことだと思う。

箱を開ける、と何度か書いてきた。
パンドラの箱を思い出した人がいるかもしれない。
開けてはいけないものを開けてしまう話として、たいてい記憶されている。

ただ、あの話には続きがある。
箱から災いが全部飛び出していったあと、ひとつだけ中に残ったものがある。
希望である。

Just be hopeful.

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

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

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開発者向けの公式ニュースで確認できます。

要素同士を結びつけて配置するCSSアンカーポジショニングが全ブラウザに揃う

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

ツールチップやドロップダウンメニュー、吹き出し。ボタンの近くに小さな要素をぴたりと寄り添わせる場面は、ウェブサイトのあちこちにあります。ところが、この「ある要素を別の要素のそばに置く」という一見単純な処理が、これまでのCSSでは驚くほど手間のかかる作業でした。その状況を根本から変えるアンカーポジショニング(anchor positioning)が、2026年に入って主要ブラウザすべてで使えるようになりました。単なる新プロパティの追加ではなく、位置決めという古くからの悩みに対する設計思想の転換なので、少し腰を据えて整理しておきたいと思います。

これまでの位置決めがなぜ面倒だったのか

従来のCSSで要素を任意の場所に置く手段は、position: absolute でした。ただしこれは「親要素を基準にした座標」でしか位置を決められません。ボタンの真下にメニューを出したいとき、ボタンそのものを基準にすることができず、共通の親を用意して相対位置を調整する、といった回りくどい組み立てが必要でした。

さらに厄介だったのが、画面のスクロールやウィンドウのリサイズです。ボタンが動けばメニューも追従させなければなりませんが、CSSだけではそれを追いかけられません。そこで多くの現場が JavaScript に頼りました。要素の座標を getBoundingClientRect で毎回計測し、スクロールやリサイズのたびに再計算して位置を書き換える。この処理を安定して動かすのは意外に難しく、Floating UI や Popper.js といった専用ライブラリが広く使われてきたのは、まさにこの面倒を肩代わりするためでした。

つまり「要素を別の要素のそばに置く」という日常的な要件のために、数十KBのライブラリを読み込み、イベント監視のコードを書く。この構図が長らく当たり前になっていたのです。位置ずれの不具合報告が絶えなかったり、スクロール中にメニューがわずかにガタつく、といった細かな粗さに悩まされた記憶のある制作者も多いのではないでしょうか。

アンカーポジショニングの基本的な考え方

アンカーポジショニングは、この関係を CSS だけで宣言的に記述できるようにします。仕組みは素直です。基準にしたい要素、つまり錨(いかり)となる要素に anchor-name というプロパティで名前を付けます。名前はカスタムプロパティと同じくハイフン二つで始まる文字列です。一方、寄り添わせたい側の要素には position-anchor でその名前を指定し、どの要素に結びつくかを宣言します。

あとは anchor() 関数を使って、錨のどの辺を基準に自分をどこへ置くかを書きます。たとえば錨の下端を自分の上端に合わせれば、ボタンの真下にメニューが並びます。座標を計算するのはブラウザの役目です。錨が動けば結びついた要素も自動で追従し、スクロールしてもリサイズしても関係は保たれます。JavaScript のイベント監視も、再計算のループも要りません。ひとつの錨に対して複数の要素を結びつけることもでき、たとえばボタンにツールチップと補助メニューの両方をぶら下げる、といった構成も素直に書けます。位置の面倒をブラウザに任せられると、制作者は見た目の設計そのものに集中できるようになります。

position-areaで方向をわかりやすく指定する

anchor() 関数は柔軟ですが、上下左右の細かな指定を辺ごとに書くのはやや冗長になりがちです。そこで用意されているのが position-area というプロパティです。これは錨の周囲を九つのマス目に見立て、そのどこに要素を置くかを言葉で指定できる仕組みです。「錨の上」「右下」といった感覚で配置を書けるため、コードの意図が読み取りやすくなります。

ちなみにこのプロパティは策定の途中で inset-area という名前から position-area へ改称された経緯があり、Chrome でも 129 で名称が揃いました。少し前の解説記事では古い名前で書かれている場合があるので、参照するときは注意しておくとよいでしょう。

はみ出しを自動で回避するフォールバック

位置決めで最も神経を使うのが、画面の端での挙動です。ボタンの下にメニューを出す設計でも、そのボタンが画面の下端近くにあれば、メニューが見切れてしまいます。従来はこの判定も JavaScript で書く必要がありました。空きスペースを測り、足りなければ上に開く、といった条件分岐です。

アンカーポジショニングには、この切り替えを CSS だけで完結させる仕組みが備わっています。position-try-fallbacks というプロパティに候補の配置を並べておくと、既定の位置ではみ出しが起きたときにブラウザが順番に候補を試し、収まる配置を自動で選びます。より込み入った代替案は @position-try という規則で定義できます。判定はレイアウトの過程で自動的に行われ、リサイズ監視のコードは一切必要ありません。下に空きがなければ上へ、横が詰まっていれば別の向きへ、といった気配りをブラウザが肩代わりしてくれるわけです。

Popover APIやdialogと組み合わせて真価を発揮する

アンカーポジショニングが特に力を発揮するのは、HTML の popover 属性や dialog 要素と組み合わせたときです。popover 属性は、追加のコードなしで開閉できる小さな重ね表示をブラウザ標準で実現する仕組みで、メニューやツールチップの土台に向いています。ただし popover 属性だけでは「どこに出すか」までは面倒を見てくれません。ここに位置決めを担うアンカーポジショニングを重ねることで、開閉と配置の両方を標準機能だけで組み立てられます。

しかもこの組み合わせにはアクセシビリティ上の利点もあります。popover 属性や dialog 要素と一緒にアンカーポジショニングを使うと、キーボード操作の順序、つまりフォーカスの移動をブラウザが適切に補正してくれます。錨となるボタンから開いた要素へ自然に焦点が移るため、支援技術を使う利用者にも扱いやすい構造になります。メニュー、サブメニュー、設定ダイアログといった部品を、ライブラリ抜きで組み立てられる土台が整ったことになります。

導入をどう見極めるか

気になる対応状況ですが、アンカーポジショニングは Chrome が 125 から、Safari が 18.2 から対応し、最後まで残っていた Firefox も 147 で既定有効となりました。これで主要なブラウザエンジンがすべて出そろい、2026年時点でおよそ9割の利用環境をカバーする水準に達しています。新しい制作案件であれば、実務で採用できる段階に入ったと言ってよいでしょう。

とはいえ、少し前のバージョンのブラウザを使う利用者が一定数残るサイトもあります。中小企業のサイトで慎重に進めるなら、アンカーポジショニングが効かない環境でも致命的に崩れない設計、たとえば従来の配置を素の状態として残し、対応ブラウザではより洗練された位置決めが効く、という重ね方が現実的です。位置が多少ずれても内容は読める、という状態を保っておけば安全に導入できます。

ツールチップ一つのために外部ライブラリを読み込む時代が、静かに区切りを迎えつつあります。読み込むコードが減れば表示は軽くなり、保守すべき依存も減ります。派手さはないものの、こうした基盤の更新こそ、日々サイトを預かる制作者にとって地味に効いてくる変化だと感じています。

gzipやBrotliに続く圧縮方式zstd、全ブラウザ対応が揃う

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

ウェブページやファイルをブラウザに届けるとき、多くのサーバーは中身を圧縮してから送っている。長年その主役はgzipで、近年はより縮むBrotliが加わってきた。ここに三つ目の選択肢として、zstd(Zstandard)という圧縮方式が本格的に使えるようになりつつある。ChromeやFirefoxはすでに対応済みで、遅れていたSafariも直近のアップデートで足並みをそろえた。主要ブラウザが一通り対応したことで、実務でも検討できる段になってきた。

そもそも転送時の圧縮とは何か

HTMLやCSS、JavaScriptといったテキストは、そのまま送るとサイズが大きい。そこでサーバーは送信前にデータを圧縮し、ブラウザが受け取って展開する。この仕組みが転送時の圧縮で、リクエストのAccept-Encodingヘッダーでブラウザが対応方式を伝え、サーバーがContent-Encodingヘッダーで実際に使った方式を返す。読者から見えないところで、日々のページ表示を支えている土台のような機能だ。

gzipは登場からかなり時間が経っているが、いまも事実上すべての環境で通じる共通語として残っている。Brotliはgzipよりよく縮む方式で、Googleがウェブのために設計した。同じファイルでもより小さくなるため、公開サイトの配信では定番になってきた。zstdはMetaが開発した比較的新しい方式で、IANAの圧縮方式一覧にも「zstd」という名前で正式に登録されている。

zstdはどのあたりに位置するのか

三つの方式は、縮む度合いと処理の速さのバランスが少しずつ違う。ざっくり言えば、圧縮率はBrotliがもっとも高く、gzipが控えめ、zstdはその中間あたりに収まる。一方で圧縮にかかる時間はzstdが速く、条件によってはBrotliの最高設定より数倍速く処理できるとされている。縮み具合と速さのどちらを取るかという、昔からある悩みに新しい落としどころを用意した方式だと言える。実測を比べた記事でも、zstdはgzipより一回り小さく縮めつつ、処理そのものは軽いという傾向が繰り返し報告されている。数字の細部は圧縮の強さの設定やファイルの中身で変わるため、自分のサイトで試してみて初めて分かる部分も多い。

この特性から、zstdはその場で圧縮して送る動的なコンテンツと相性がよい。ページを表示するたびに圧縮し直す場面では、少しでも速く処理できるほうが待ち時間の短縮につながるからだ。逆に、あらかじめ圧縮しておける静的なファイルなら、時間をかけてでも最小サイズを狙えるBrotliの最高設定が向く。一度圧縮すれば以後は使い回せるため、処理速度の差はほとんど問題にならない。用途によって使い分けるのが素直な考え方になる。

導入で押さえておきたい前提

実際に使うにはいくつか条件がある。まず、Chromeはzstdを安全な通信、つまりHTTPS接続のときだけ候補として提示する。暗号化されていない通常のHTTPではgzipやBrotliに戻る。常時HTTPS化が当たり前になった今ならほとんどのサイトが該当するが、頭の片隅には置いておきたい。ブラウザごとの対応状況はCan I useのような一覧で確認できる。

サーバーやCDN側の対応も欠かせない。CDN大手のCloudflareは以前からzstdを扱えるようにしており、配信基盤としての土台は整いつつある。自前のサーバーで有効にする場合は、使っているウェブサーバーソフトがzstdに対応しているかを確認することになる。ブラウザが受け取れても、送り出す側が方式を用意していなければ実際には使われない。両側がそろって初めて効いてくる点は、gzipやBrotliと同じ理屈だ。

中小規模のサイトでどう受け止めるか

では今すぐ全サイトがzstdに乗り換えるべきかというと、そこは冷静でよい。多くの中小企業サイトは、gzipやBrotliがすでに効いていれば体感できる速度は十分に出ている。zstdはあくまで選択肢が一つ増えたという話であり、乗り換えないと遅れるという性質のものではない。既存の圧縮が正しく効いているかをまず確かめるほうが、ずっと実益は大きい。

それでも、配信の速さを突き詰めたい場面や、動的に生成する部分が多いサイトでは、zstdが効いてくる余地がある。地方の制作現場でも、圧縮方式の違いと使い分けの勘どころを知っておけば、サーバーやCDNを選ぶときの判断材料が一つ増える。ブラウザ側の対応が一巡した今は、その知識を仕込んでおくのにちょうどよい頃合いだ。

WordPressの最新メンテナンス更新が直した不具合と自動更新の意味

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

WordPress本体に、公開済みのバージョンを細かく手入れする小さな更新が届いた。派手な新機能の発表ではないので見過ごされやすいが、日々サイトを預かる立場からすると案外大事な話なので、手短に共有したい。

WordPress.orgの告知によると、7.0.1が2026年7月9日に公開された。これは5月に登場したメジャー版7.0のあとに見つかった不具合を直すメンテナンスリリースで、ブロックエディター、管理画面、メディアまわりを中心に31件の修正が入っている。新しい機能を足すものではなく、すでにある動きを安定させるための更新という位置づけになる。

31件という数字だけ見ると多く感じるかもしれないが、メジャー版の直後に出る最初のメンテナンスリリースとしてはよくある規模だ。大勢が使い始めて初めて表面化する細かな不具合を、報告を受けて短い周期でまとめて直す。ブロックエディターや管理画面は制作者が毎日触れる場所なので、ここが少しずつ安定していくのは地味ながらありがたい。

マイナー更新は自動で当たることが多い

こうしたマイナー更新は、自動バックグラウンド更新が有効なサイトであれば、管理画面を開かなくても順に適用されていく。手動で運用している場合は、ダッシュボードの「更新」から今すぐ当てられる。特別な準備はいらず、作業としては数分で終わることがほとんどだ。

マイナー更新はメジャー版のように仕様が大きく変わるものではないため、更新でレイアウトやプラグインが急に動かなくなる心配は基本的に小さい。だからこそ自動更新に任せておける部分でもある。もちろん本番前にステージング環境がある案件なら、そこで一度確認してから本番へ、という手順を挟めばより安心できる。

WordPressは初期設定でマイナー更新だけを自動で当て、メジャー版は手動に委ねる作りになっている。つまり7.0.1のような更新は放っておいても順に届く一方、7.0から7.1へといった大きな移行は自分のタイミングで判断できる。運用を任されている側からすると、この線引きを理解しておくと、顧客に「どこまでが自動で、どこからが手動の判断か」を説明しやすくなる。トラブルを避けたいからと自動更新まで止めてしまうと、かえって細かな修正が当たらず古いままになりやすいので、少なくともマイナー更新は生かしておくのが無難だ。

現場では「問題なく動いているから触らない」という判断になりがちだが、メンテナンスリリースは表示の崩れやエディターの引っかかりといった、実際に手を止められる不具合を静かに潰している。安定性やセキュリティに関わる修正が含まれることも多いので、後回しにする理由はあまりない。中小企業のサイトや個人で回している案件ほど、更新通知に気づかず古いまま放置されやすいので、自動更新が効いているかを一度確認しておくとよい。

次のメジャー版7.1は、8月19日のWordCamp USに合わせて公開が予定されている。大きな変更点はそのとき改めて追うとして、まずは足元の7.0.1を当てて土台を整えておきたい。

フォームの入力欄が中身に合わせて伸縮する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指定を土台にしつつ、非対応のブラウザではこれまでどおりの固定サイズで問題なく使えるという前提で組んでおくと安心です。あってもなくても壊れない、あれば快適になるという足し方であれば、今日から少しずつ取り入れられます。ブラウザ標準の機能で書き心地を底上げできる場面は、着実に増えています。