パッチ公開後に攻撃が急増したメール送信プラグインの脆弱性

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

ウェブサイトのお問い合わせフォームや会員登録の通知メールを確実に届けるために使われるのが、メール送信系のプラグインです。今回、その代表的なひとつであるGravity SMTPに、設定情報がまるごと外部から読み取れてしまう脆弱性が見つかり、世界中で攻撃が観測されました。約10万サイトが利用していたこと、そして修正版が出た後に攻撃が急増したことから、更新を後回しにしているサイトにとって他人事ではない事例になっています。

ひとつのリクエストで設定情報が丸見えになる仕組み

問題の脆弱性はCVE-2026-4020として公開されました。深刻度は中程度とされていますが、実際の影響は小さくありません。原因は、プラグインが用意していたREST APIの入り口にありました。本来は管理者だけがアクセスできるべきテスト用のエンドポイントが、アクセス権のチェックを常に許可で返す設定になっていたのです。

その結果、ログインしていない誰でも特定のURLを叩くだけで、サイトの設定内容をまとめた診断レポートを受け取れてしまいました。レポートには、メール配信サービスと連携するためのAPIキーやシークレット、OAuthトークンといった、本来は決して外に出してはいけない資格情報が含まれていました。攻撃者から見れば、鍵の束が置かれた扉が開けっ放しになっていたようなものです。しかも返ってくるレポートは数百キロバイトに及ぶ大きなもので、そこに並ぶ項目を眺めるだけで、どこを突けばよいかがひと目で分かってしまいます。

漏れるのはメールの設定だけではない

今回の脆弱性で特に厄介なのは、露出する情報がそのサイトの中だけにとどまらない点です。Gravity SMTPはAmazon SESやGoogle、Mailjet、Resend、Zohoなど外部のメール配信サービスと連携します。つまり漏れた資格情報は、そうした外部サービスのアカウントを操作するための鍵でもあります。

これを手に入れた攻撃者は、正規のサイトになりすまして大量のメールを送りつけたり、迷惑メールの踏み台にしたりできます。送信元が本物のドメインなので受け取った側は見抜きにくく、ブランドの信用にも傷がつきます。診断レポートには利用中のプラグインやテーマ、各種バージョン情報も含まれるため、次の攻撃の下調べにも使われます。ひとつの穴が連鎖的に別の被害へつながっていく構図です。

修正版が出た後に攻撃が急増した

見逃せないのは時間の流れです。開発元はこの問題を修正したバージョン2.1.5を3月に公開していました。ところが攻撃が本格化したのは、それから2か月以上たった5月末から6月にかけてでした。セキュリティ企業のWordfenceは、この脆弱性を狙った攻撃を合計で1700万件以上ブロックしたと報告しています。

なぜ修正後に攻撃が増えるのか。脆弱性の詳細が公開されると、その情報をもとに攻撃を自動化するツールが作られ、更新していないサイトを一斉に探し始めるからです。パッチが出た瞬間が安全の到達点ではなく、むしろ攻撃者にとっての号砲になることもあります。この順序は、規模の大小を問わずすべてのサイト運営者が意識しておきたいところです。

中小規模のサイトが取るべき現実的な対応

まず基本は、プラグインを最新版に保つことです。自動更新を有効にしておけば、修正版が出てから狙われるまでの時間差をかなり縮められます。管理画面を毎日見られない運用でも、更新だけは自動に任せる価値があります。

そして今回のように資格情報が漏れうる脆弱性では、更新だけでは不十分です。すでに露出していた可能性がある以上、連携先サービスのAPIキーやトークンを作り直す、いわゆる再発行が欠かせません。古い鍵を無効にして初めて、盗まれた情報が使えなくなります。地方の制作現場でクライアントのサイトを預かっている場合は、この鍵の入れ替えまでを一連の作業として案内できると安心です。

もう少し長い目で見れば、プラグインを選ぶ段階での目配りも効いてきます。更新の頻度や、脆弱性が報告されたときの対応の速さは、公開されている更新履歴からある程度読み取れます。必要以上に多機能なプラグインを詰め込まないこと、使わなくなったものはこまめに削除することも、攻撃の入り口を減らす地道な守りになります。あわせて、被害に早く気づく備えも役立ちます。連携先サービスの送信履歴や請求額に不自然な急増がないかを時々見ておくと、万一鍵が悪用された場合でも初動を早められます。RESONIXでもサイトを預かる際は、動かすことと同じくらい、こうした更新と権限の設計を大切にしています。

グリッドとフレックスの隙間を線で飾るCSSの新機能

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

ウェブサイトのレイアウトをグリッドやフレックスボックスで組んだあと、要素と要素のあいだに区切り線を入れたくなる場面は多い。カード一覧の列のあいだに細い罫線を引く、料金表のセルを線で仕切る、といった演出だ。ところがこれまでのCSSには、こうした隙間そのものに線を引く手段が用意されていなかった。Chrome と Edge の149で使えるようになった gap decorations は、その長年の空白を埋める機能になる。

これまでは擬似要素や枠線で工夫していた

グリッドやフレックスボックスの gap プロパティは、要素のあいだに余白を作れるが、その余白に色や線を付けることはできない。そのため制作現場では、各セルに border を付けて重なりを調整したり、::before や ::after の擬似要素で線を描いたり、背景にグラデーションを敷いて線に見せかけたりといった回り道をしてきた。

どの方法も、セルの数が変わったり折り返しが起きたりすると崩れやすい。線を引きたいだけなのに、レイアウトの計算まで巻き込んでしまうのが悩みどころだった。gap decorations は、この作業を余白側の仕事として切り出してくれる。

column-rule と row-rule で隙間に線を引く

マルチカラムレイアウトには以前から column-rule というプロパティがあり、段組みの段のあいだに線を引けた。新機能は、この column-rule をグリッドとフレックスボックスでも使えるように広げ、さらに横方向の隙間を担当する row-rule を新たに加えたものだ。

書き方は border とよく似ている。線の太さ、線種、色をそれぞれ column-rule-width、column-rule-style、column-rule-color で指定し、まとめて column-rule として一行で書くこともできる。row-rule も同じ構成だ。

.cards {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 24px;
  column-rule: 1px solid #ccc;
  row-rule: 1px solid #ccc;
}

大事なのは、これらの線が純粋に見た目だけの装飾で、余白の幅やレイアウトには一切影響しない点だ。線を足しても要素の位置がずれないので、あとから飾りを差し込む使い方に向いている。

フレックスボックスで要素が複数行に折り返すレイアウトでも、行と行のあいだに row-rule の線がきれいに収まる。列数や行数が中身に応じて変わる動的なレイアウトほど、擬似要素で線を管理する手間から解放される効果は大きい。

repeat()で線のパターンを作る

column-rule-width などには、グリッドのトラック指定でおなじみの repeat() が使える。これを使うと、隙間ごとに太さや色を変えたパターンを短い記述で作れる。たとえば数独の盤面のように、細い線を並べつつ何本かおきに太い線を挟む、といった表現だ。

column-rule-width: repeat(2, 1px) 4px repeat(2, 1px) 4px repeat(2, 1px);

線の位置を隙間の中央から少しずらす column-rule-inset のようなプロパティや、どの隙間に線を引くかを選ぶ仕組みも用意されている。縦の線と横の線が交わる交点の見せ方も細かく制御でき、交点で線を途切れさせるか、そのまま突き抜けさせるか、描画の重なり順をどうするかまで指定できる。単なる区切り線にとどまらず、表やカレンダー、価格表といった格子状のデザインを、擬似要素なしで組み立てられるようになる。

使えるブラウザと取り入れ方

gap decorations が正式に使えるのは、いまのところ Chrome と Edge の149からで、2026年6月に登場した。ほかのブラウザではまだ対応が追いついていないため、現時点では装飾の上乗せとして使うのが無難だ。

幸い、この機能は線を描くだけでレイアウトを動かさない。対応していないブラウザでは線が表示されないだけで、要素の並びや余白は保たれる。つまり、線があれば少し見やすく、なくても困らない、という段階的な取り入れ方ができる。地方の制作現場でも、まずは社内サイトや実験的なページで感触を確かめてから、対応ブラウザの広がりに合わせて本番へ持ち込むのが手堅い進め方になるだろう。

CSSだけで条件分岐や連番を扱えるようになった新しい関数たち

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

これまでCSSでは表現しきれず、JavaScriptやSassのような前処理ツールに任せてきた処理がいくつもありました。要素が並びの中で何番目かを数えたり、条件によって値を出し分けたりといった、いわば「ロジック」にあたる部分です。ここ最近、その領域をCSSの標準機能として扱えるようにする新しい関数がブラウザに入り始めています。中小企業サイトの制作でも、外部ライブラリを一つ減らせる余地が広がってきました。今回はそうした関数を並べて紹介します。

並びの順番を数える sibling-index() と sibling-count()

sibling-index() はその要素が兄弟要素の中で何番目かを返し、sibling-count() は兄弟要素の総数を返します。これまで各要素に少しずつ違う値を割り当てるには、:nth-child() を項目の数だけ書き並べるか、JavaScriptで番号を振るしかありませんでした。

この二つを calc() と組み合わせると、リストの各項目に段階的な遅延を与えるアニメーションが一行で書けます。たとえば animation-delay: calc(sibling-index() * 0.08s) と書けば、項目が5個でも500個でも同じ記述で順番にずれて動きます。ナビゲーションのメニューやカードの一覧を、順に浮かび上がらせるといった演出が、余分なマークアップなしで表現できるわけです。

遅延だけでなく、要素の位置に応じた大きさや透明度の調整、リストへの連番の割り当てなど、数式で表せる装飾なら幅広く応用できます。項目の増減があっても記述を書き直さずに済むため、更新頻度の高いお知らせ一覧や商品の並びといった、中身が動くコンテンツと相性がよい機能です。

値そのものを出し分ける if() 関数

if() は、スタイルクエリやメディアクエリ、機能クエリの結果に応じて、プロパティの値そのものを分岐させる関数です。これまで同じことをするには、状態ごとにクラスを付け替えたり、カスタムプロパティを何段も重ねて条件を組み立てたりする必要がありました。

if() を使うと、たとえばカスタムプロパティの値を見て背景色を切り替える、といった書き分けが一つのプロパティの中で完結します。分岐のたびにセレクタを増やさずに済むため、コンポーネントのスタイルが見通しよく保てます。テーマの切り替えやボタンの種類ごとの装飾など、これまで冗長になりがちだった部分を短く書ける関数です。

たとえば明るい配色と暗い配色を切り替えるサイトで、ボタンや枠線の色を状態に合わせて出し分ける、といった使い方が考えられます。従来はそのためにクラス名の組み合わせが増えていきがちでしたが、値の分岐を一箇所にまとめられると、後から見返したときの読みやすさが変わってきます。

導入時に押さえておきたいブラウザ対応

便利な一方で、対応状況にはまだ差があります。sibling-index() と sibling-count() はChromeが先行して対応し、Safariも追随、Firefoxは実装が進んでいる段階です。if() はさらに新しく、現時点ではChromiumを基盤とするブラウザが中心で、SafariやFirefoxはこれからという位置づけです。

つまり、いますぐ全ての利用者に届く機能とは言い切れません。本番のサイトでは @supports で対応ブラウザを見分け、未対応の環境には従来どおりの書き方を残しておくのが安全です。長くウェブ制作に携わってきた立場からも、こうした新機能は「安全な既定値を先に書き、その上に重ねる」という進め方を勧めたいところです。派手さはありませんが、この順序を守ることで、新しい表現を取り入れつつ表示崩れを避けられます。手元の小さなコンポーネントから試して、感触を確かめてみるのがよさそうです。

ページ遷移を先読みで速くする投機的読み込みの設計と注意点

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

ページを開いた瞬間に次の画面が表示される。そんな体験を、JavaScriptのライブラリを足さずにブラウザの標準機能だけで実現する動きが広がっている。投機的読み込み(speculative loading)と呼ばれる仕組みで、Chromeを中心に実装が進み、WordPressにも標準機能として組み込まれた。表示速度は検索評価にも使い勝手にも直結する話なので、地方の制作現場でも知っておいて損はない。

ただ、この仕組みは入れれば速くなるという単純なものではない。先に読み込むという性質上、アクセス解析の数値が狂ったりサーバーの負荷が増えたりといった副作用がある。今回は投機的読み込みの考え方と、実務で使うときに気をつけたい点を整理してみる。

投機的読み込みとは何か

投機的読み込みは、利用者が次に開きそうなページを、実際にクリックする前にブラウザが裏側で先に取得しておく仕組みだ。土台になっているのがSpeculation Rules APIで、どのURLをどのタイミングで先読みするかをルールとして宣言できる。従来もlink要素によるprefetchのような先読み手段はあったが、Speculation Rules APIはより細かく、より積極的な制御ができる点が違う。

先読みの積極度はeagernessという段階で指定する。控えめな設定はリンクを押した瞬間に動き、中間の設定はリンクにカーソルを合わせたりタップしかけた段階で動く。さらに積極的な設定にすれば、リンクが画面に入った時点で先読みを始める。押してから読み込むのではなく、押しそうな気配を見て先に動くという発想だ。

この気配の読み方はスマートフォンでも工夫が進んでいる。最近のChromeでは、リンクが画面内に入ってから短い時間を置いて先読みを始める挙動が入り、指がまだリンクに触れていない段階でも準備を進められるようになった。マウスのホバーがないタッチ環境では、こうした画面内に入ったという合図が先読みのきっかけとして重みを持つ。

プリフェッチとプリレンダーの違い

投機的読み込みには大きく二つのモードがある。プリフェッチ(prefetch)は次のページのHTMLなど主要な資源を先に取得しておくだけで、ページの組み立ては利用者が実際に移動してから行う。取得済みのぶん移動が速くなるが、効果は限定的だ。

もう一つのプリレンダー(prerender)は、資源の取得だけでなくページの描画まで裏側で済ませてしまう。利用者が移動した瞬間には完成した画面を差し出すだけになるので、体感はほぼ一瞬になる。表示速度の指標で言えばLCPやINPが大きく改善し、ほぼ瞬時と呼べる速さが出る。

効果が大きいぶん、プリレンダーは踏み込んだ挙動になる。描画までするということは、そのページのJavaScriptが裏側で実際に走るということでもある。ここが後述する副作用の入り口になる。

WordPressに標準搭載された投機的読み込み

この仕組みは、WordPress 6.8でコアに取り込まれた。もともとは実験的なプラグインとして提供され、多くのサイトで検証を重ねたうえで安定版に昇格し、コア標準機能になったという経緯がある。特別なプラグインを入れなくても、きれいなパーマリンクを使っているサイトなら初期状態で先読みが働くようになっている。

ただしコアの初期設定は安全側に振ってある。ログインしていない訪問者に対して、控えめな積極度でプリフェッチだけを行う。描画まで踏み込むプリレンダーや、より積極的な設定は初期状態では有効にならない。より強い効果を求める場合は、公式のSpeculative Loadingプラグインを入れると、設定画面からモードや積極度を選べる。プラグイン側の初期値はプリレンダーの中間設定で、コアより一歩踏み込んだ構成になっている。

使いどころとして向いているのは、複数ページを続けて見てもらう性質のサイトだ。ブログや事例紹介、ドキュメント、商品一覧などは相性がよい。一方でカート内や決済の流れのように、先に走らせると困る処理を含むページはプリレンダーの対象から外すのが定石になっている。

先読みが引き起こす副作用

投機的読み込み、とくにプリレンダーで注意したいのがアクセス解析への影響だ。プリレンダーはページのJavaScriptを先に走らせるため、ページ表示を記録する計測タグが、利用者がまだ移動していない段階で発火してしまうことがある。結果として、実際には見られていない訪問がアクセス解析に記録される。

実際にWordPress 6.8の投機的読み込みで、GA4などに幻の訪問が計上される事例が報告されている。数字が水増しされれば、直帰率や滞在時間といった指標の読み方が狂い、サイト改善の判断を誤りかねない。対策として、主要な計測ツールの一部は、ページが実際に表示される瞬間まで計測を保留する仕組みを持っている。導入するなら、使っている計測ツールが先読みに対応しているかを確かめておきたい。

ブラウザ側でも副作用を抑える改良が進んでいる。最近のChromeには、プリレンダー中に最初の外部スクリプトの手前で処理をいったん止め、CSSや画像、フォントの先読みは進めつつ計測タグなどの実行だけを保留する挙動が加わった。裏側で読み込みは進めても、実際に表示されるまで余計な処理を走らせないという方向で、先読みと計測の食い違いを和らげる狙いがある。

もう一つはサーバーへの負荷だ。訪問者が実際に開くより多くのページを先に取得させるので、そのぶんアクセスが増える。多くの閲覧者を抱えるサイトや、動的にページを組み立てる構成では、キャッシュの整備なしに踏み込むと負荷が読みにくくなる。ログイン利用者にまで先読みを広げるかどうかは、サーバーが耐えられるかを見てから決めるのが安全だ。

対応ブラウザの現実

効果の大きい仕組みだが、すべてのブラウザで使えるわけではない点も押さえておきたい。Speculation Rules APIはChromeやEdge、OperaといったChromium系ブラウザで実装されている一方、SafariやFirefoxは現時点で対応していない。対応していないブラウザは、書かれた先読みのルールを単に無視するだけなので、表示が壊れるわけではない。

つまり投機的読み込みは、対応ブラウザの利用者だけが速さの恩恵を受け、それ以外の利用者はこれまで通りという上乗せ型の改善になる。壊れないという安心感がある半面、全員に効く施策ではないので、これ一本で表示速度を語るのは早い。土台となるページ自体の軽さや画像の最適化といった基本があってこそ効いてくる。

中小企業サイトでの取り入れ方

では現場でどう扱うか。まず、WordPressで運用していてきれいなパーマリンクを使っているなら、コアの控えめな先読みはすでに働いている可能性が高い。ここは特別な作業なしに得られている速さなので、まず現状を把握するところから始めるとよい。

そのうえでもう一段速くしたい場合は、プリレンダーへの引き上げを検討する。ただし前述のとおり、アクセス解析の数値と決済まわりの挙動は必ず先に確認する。小さく試して、計測の数字が乱れないか、サーバーの負荷が跳ねないかを見ながら広げるのが現実的だ。ChromeのDevToolsには先読みの挙動を確認する機能があるので、想定通りに動いているかを目で確かめられる。

投機的読み込みは、派手さはないが体感速度をはっきり押し上げる技術だ。ブラウザ標準の仕組みに寄せることで、重いライブラリを足さずに使い勝手を上げられる方向は、限られた予算でサイトを育てる中小の制作現場と相性がよい。副作用を理解したうえで、小さく取り入れていく価値はある。

開閉するUIをブラウザ標準で作る、open擬似クラスが揃える最後のピース

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

ウェブサイトで何かを開いたり閉じたりする操作は、どんなサイトにもあります。ハンバーガーメニューの開閉、問い合わせ前に表示するモーダル、よくある質問のアコーディオン、小さなツールチップ。こうした開閉パーツは長らくJavaScriptのライブラリで組むのが当たり前でした。ところが2026年に入り、ブラウザ標準の機能だけで同じことができる場面がぐっと増えています。

節目になったのが、2026年5月に公開されたSafari 26.5です。ここでopen擬似クラス(:open)が実装され、ChromeやFirefoxと足並みがそろいました。地味な追加に見えますが、標準機能だけで開閉UIを組む流れを後押しする一歩です。詳しくはWebKitの公式ブログでも解説されています。

open擬似クラスが開いた状態をまとめて扱う

:openは、要素が開いている状態にスタイルを当てるための擬似クラスです。対象はdetails要素やdialog要素、それにselect要素や、日付や色を選ぶinput要素のピッカーが開いたときまで含みます。開閉する部品を、種類を問わず同じ書き方で整えられるのが利点です。矢印の向きを変える、背景色を切り替えるといった見た目の調整を、状態ごとにCSSの中で完結させられます。

これまでは[open]属性セレクタで開閉状態を拾っていました。ただしこの書き方が効くのはdetails要素とdialog要素だけで、select要素やinput要素には使えませんでした。細かな差に見えますが、開閉するあらゆる要素を一貫した書き方で扱えるようになった意味は小さくありません。要素の種類ごとに別々のセレクタを覚える負担が減り、スタイルの見通しも良くなります。詳しい対応状況はMDNで確認できます。

標準タグだけで組める開閉パーツ

開閉UIの部品は、ここ数年でブラウザ側にそろってきました。モーダルはdialog要素のshowModalで開けます。背景を暗くする処理やフォーカスの閉じ込め、Escキーで閉じる動きまで、ブラウザがはじめから面倒をみてくれます。ちょっとしたメニューや吹き出しは、HTMLにpopover属性を足すだけで開閉できます。Popover APIは2025年4月に主要ブラウザで安定して使えるようになり、いまでは前提として組み込める土台になりました。popover属性を付けた要素は、外側をクリックしたりEscキーを押したりすると自動的に閉じます。いわゆるライトディスミスの挙動を、自分で書かなくてもブラウザが用意してくれます。

よくある質問のアコーディオンは、details要素とsummary要素だけで作れます。開いたときの見た目は:openで整えれば、開閉の状態管理をJavaScriptで書く必要はありません。ポップオーバーが表示中かどうかは:popover-openでも拾えます。Safari 26.5では、どの要素がポップオーバーを開いたかを知るための仕組みも加わり、複数の開閉部品が絡む画面でも扱いやすくなりました。ボタンを押すと候補が開くドロップダウンのような部品も、こうした標準機能の組み合わせで素直に表現できます。素朴なHTMLの積み重ねで、これまで外部ライブラリに任せていた動きの多くがまかなえます。

制作現場にとっての意味

標準機能に寄せる利点は、まずコードが軽くなることです。開閉のためだけに読み込んでいた外部ライブラリを減らせば、ページの表示は速くなり、保守の手間も下がります。加えて見落としがちなのがアクセシビリティです。dialog要素やpopover属性は、キーボード操作やスクリーンリーダーへの対応がはじめから組み込まれています。自前で作った開閉UIにありがちな、フォーカスが迷子になる、Escキーで閉じないといった不具合を避けやすくなります。ブラウザ標準の挙動に乗るぶん、環境による見え方や操作感のばらつきも抑えやすくなります。

中小企業のサイトでも、問い合わせ導線のモーダルやFAQのアコーディオンなど、使いどころは多いはずです。たとえば、以前はプラグイン頼みで組んでいたFAQの開閉を、details要素と:openだけに置き換えれば、依存が減って動作も安定します。ただし現状では、古いブラウザ向けのフォールバックや、凝ったアニメーションでのCSSとの併用など、細かい調整が要る場面は残ります。それでも、開閉UIの土台をブラウザ任せにできる範囲は着実に広がっています。新しく組むときは、まず標準機能だけで足りるかを出発点に考える価値が出てきました。手が込んだ実装に進むのは、それで届かないところを見極めてからでも遅くありません。

インストール済みPWAをドメイン変更後も引き継ぐ新しい仕組み

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

ウェブアプリをスマートフォンのホーム画面に追加できるPWA（プログレッシブウェブアプリ）の普及が進むなか、制作現場での課題のひとつが「ドメインやURLを変えると既存のインストールが引き継げない」問題だった。リブランディングや技術的な再構成でオリジンが変わると、それまでインストールしてもらったユーザーは古いアプリを手動でアンインストールして新しいURLから再インストールするしかなく、この一手間がユーザー離れにつながることも珍しくなかった。

Chrome 150（2026年6月にベータ版公開）では、この問題を解消するPWA Origin Migrationという仕組みが新たに導入された。Chrome for Developersの公式ブログによると、新しいオリジンのウェブアプリマニフェストに migrate_from フィールドを追加することで、既存のインストール済みアプリをシームレスに移行できるようになる。ユーザー側には通常のアプリ更新と似たダイアログが表示され、ワンクリックで古いアプリがアンインストールされ、新しいURLのアプリが即座にインストール・起動される。

この機能を利用するには、新しいオリジン側のマニフェストに migrate_from を記述するだけでなく、移行元となる旧ドメイン側にも明示的な承認が必要になる。具体的には、旧ドメインの .well-known/web-app-origin-association というファイルに移行先のURLと allow_migration の許可を記載する仕組みだ。このふたつの設定を両側で行うことで、第三者が無断で他社のPWAを乗っ取るリスクを排除している。現時点では移行先は同じeTLD+1（たとえば同じドメイン内のサブドメイン変更やパス変更など）に限られており、まったく別の組織のドメインへの移行には対応していない。移行の強制度は suggest（通知のみで継続も選べる）と force（ダイアログで必ず選択が必要）の二段階から選べるため、サービスの状況に応じた移行体験を設計できる。

これまでPWAをインストールしてもらったユーザーは、ドメイン変更という技術的な事情に関係なくアプリを使い続けられるのが理想だった。一方で開発者にとっては「新しいインストールへ誘導する手立てがない」という制約が長く続いており、URLの変更をためらう原因のひとつにもなっていた。今回の仕組みはその制約を取り除くもので、PWAを実運用しているチームにとっては歓迎される変化だろう。

制作現場でPWAを手がけている場合、特にサブドメイン変更や構成の整理を予定しているプロジェクトでは、Chrome 150の正式リリース後に対応を確認しておきたい。現在はChrome限定の機能だが、こうした移行の仕組みをウェブ標準の場で議論し整備していくことで、PWAをより長期的に安定して使える基盤が育っていく。

背景に応じて文字色を自動で選ぶCSS関数、読みやすさを支える新しい仕組み

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

ボタンや見出しの背景色を決めたあと、その上に載せる文字を黒にするか白にするかで迷った経験は、制作に関わる人なら一度はあるはずです。背景が濃ければ白、淡ければ黒と感覚で選んでいくものの、配色のパターンが増えるほど組み合わせの管理は地味に重くなります。この「背景に対して読みやすい文字色を選ぶ」という判断を、CSSだけで自動化するcontrast-color()という関数が、主要ブラウザにようやく出そろいました。

背景色から文字色を自動で決める関数

contrast-color()は、引数に渡した色に対して黒と白のどちらがより高いコントラストになるかを判定し、読みやすいほうを返す関数です。色を指定できる場所であればどこでも使えるので、文字色の指定に組み込めば背景色に応じて自動的に切り替わります。

書き方はとてもシンプルで、背景にブランド色を変数で渡しているなら、文字色は次のように一行で済みます。

background-color: var(–brand); color: contrast-color(var(–brand));

判定にはWCAGのコントラスト比の考え方が使われており、読みやすさの最低限を機械的に満たしやすくなります。Chrome 147、Firefox 146、Safari 26と三つのブラウザエンジンが2026年に対応し、安全に使える機能をまとめたBaselineでも新たに利用可能の段階に入りました。ブラウザ間の挙動をそろえるInterop 2026の対象にも含まれており、どの環境でも同じ結果になることが期待できます。

これまでの配色対応との違い

ブラウザが標準で対応する前から、読みやすい文字色を得る方法はいくつかありました。JavaScriptのライブラリで表示時にコントラスト比を計算して色を当てる、Sassの関数であらかじめ対になる色を生成しておく、あるいは単純に人の目で一つずつ黒と白を決めておく、といった具合です。

どれも動きはしますが、手間と保守の負担は残ります。表示時に計算する方法は画面が出るまでにわずかな処理を挟みますし、ビルド時に色を固定する方法は背景色を変えるたびに対の色も作り直すことになります。手作業の指定は、ライトモードとダークモードで色の組を二重に持つことになりがちです。contrast-color()はこの判断をブラウザ側に任せるため、背景色を一か所変えれば文字色もそのまま追従します。

制作現場で効く場面

恩恵が分かりやすいのは、背景色が一定しない場面です。ブランド色をボタンに使うコンポーネントなら、色だけ差し替えれば文字の見やすさは自動で保たれます。ホバーで背景を明るくする演出を入れた場合も、必要に応じて文字色が白から黒へ切り替わります。

ライトとダークの切り替えとも相性がよく、prefers-color-schemeで背景の変数だけを入れ替えれば、文字色の組を別々に書く必要がなくなります。color-mix()などで動的に作り出した色にも追従するため、配色をプログラム的に生成する設計とも噛み合います。デザインシステムのように色をトークンとして一元管理する作り方とも相性がよく、土台の色を一つ変えるだけで関連する文字色がまとめて整うため、配色の調整にかかる手数を減らせます。

地方の中小企業サイトやCMSでは、色の設定を制作者以外が触る場面も少なくありません。管理画面でテーマ色を選ぶと文字色まで適切に決まる、という作りにしておけば、運用する人がコントラスト比を意識しなくても読みにくい配色になりにくくなります。納品後の更新で配色が崩れるリスクを下げられる点は、長く運用するサイトほど効いてきます。

使う前に知っておきたい制約

便利な一方で、現時点の仕様には割り切りもあります。返すのは黒か白のどちらかだけで、中間調の背景に対しては必ずしも最適な結果にならないことがあります。判定の方式を選べる拡張的な書き方も一部ブラウザで試験的に使えるものの、Baselineの範囲ではまだ標準化されていません。

そのため、重要なボタンや本文など可読性が要になる箇所は、自動任せにせず実際の表示で確かめる姿勢は残しておきたいところです。とはいえ、配色の土台を機械的に整える層として置いておく価値は十分にあります。これまで手で管理してきたコントラストの一部を、ようやくCSSそのものに預けられるようになったという意味で、地味ながら実務に効く一歩だと言えます。

公開直後に悪用されるWordPressプラグイン脆弱性、EUが義務化する開示制度

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

WordPressのセキュリティをめぐる状況が、数字でみると想像以上に厳しい。Patchstackが2026年に公開したセキュリティホワイトペーパーによると、2025年に発見されたWordPressエコシステムの新しい脆弱性は11,334件にのぼり、前年比42%増となった。しかも2025年に見つかった深刻度の高い脆弱性の数は、その前の2年分を合計した数を上回っている。問題は件数だけではない。

脆弱性が公開されてから最初に悪用されるまでの中央値が5時間という数字だ。重大な脆弱性の20%は開示後6時間以内に攻撃に使われており、45%は24時間以内、70%は7日以内に悪用されている。「パッチが出たら更新する」という従来の対処では、悪用のスピードに追いつかない現実がある。同レポートでは、標準的なホスティング環境の防御機能がブロックできる攻撃は全体の26%にとどまると指摘しており、残り74%はホスト側の仕組みだけでは防ぎきれないとされている。

もうひとつ気になるのは、52%のプラグイン開発者が脆弱性を外部に公開する前にパッチを用意できていないという現状だ。開示と悪用がほぼ同時に起きる状況が珍しくなくなっており、運営するサイトに不審な動きがなくても、使っているプラグインやテーマが攻撃の対象になっている可能性がある。WordPressサイトの保守を受け持つ制作会社にとって、この数字は改めて自動更新やセキュリティプラグインの有効性を見直す契機になるだろう。

EUが義務化する脆弱性開示プログラム

こうした状況を背景に、EU（欧州連合）がサイバーレジリエンス法（Cyber Resilience Act、CRA）の要件として、2026年9月から商業目的のWordPressプラグインとテーマに脆弱性開示プログラム（VDP）の設置を義務付ける。対象は開発者がEUのユーザーに販売・提供するもので、WordPress.orgやCodeCanyonを通じた配布も含まれる。脆弱性を把握してから24時間以内に当局へ速報、72時間以内に正式報告、是正措置後14日以内に最終報告という対応期限が定められており、重大な違反には最大で売上高の2.5%または1,500万ユーロ相当の制裁金が科される。

Patchstackはこの義務化に先立ち、プラグイン・テーマ開発者向けに無償の脆弱性開示プラットフォームを提供しており、すでに650以上のプラグインが参加している。ElementorやWP Rocketもその中に含まれる。義務化によってWordPressエコシステム全体でセキュリティプロセスを形式化する流れが加速しており、開発者と利用者の双方にとって脆弱性情報の透明性が高まることが期待されている。

制作現場の視点では、プラグインの選定基準に「VDPが整備されているか」という軸が加わりそうだ。更新が止まったプラグインや、脆弱性の対応履歴が公開されていないものは、今後EUマーケットから実質的に排除されていく可能性がある。日本のサイトを運営する場合でも、採用するプラグインが国際的なセキュリティ基準を満たしているかを確認しておくことが、長期的な保守コスト削減につながる。

【NO.148】動いているのは、時間ではない

走る列車の車窓から流れて見える夕暮れの田園と街灯

私はずっと、時間は流れていない、と思ってきた。

動いているように見えるのは時間ではなく、それを眺めている、こちらの意識のほうだ。長いあいだ、そう考えてきた。けれど、これをうまく説明できたことが、一度もない。人に話すと、たいてい、怪訝な顔をされる。当たり前だ。誰もが、時間は流れるものだと、生まれてから一度も疑わずに生きている。
ところが最近、その説明のための実例が、向こうから現れた。

机の上の時計を、思い浮かべてほしい。針が進み、数字が変わる。それを見て、人は時間が流れていると思う。けれど、動いているのは時計だ。針であり、歯車であり、水晶の振動だ。時間という本体が、どこかを流れているのを、誰も見たことがない。見ているのは、いつも、それを指し示すための装置のほうだ。人間は、時計が動くのを見て、時間が動いていると信じている。
その時計を、持たないものが、いま目の前にいる。

最近、私はAIとよく話す。話していて、奇妙なことに気づいた。

朝、私がそれに「こんばんは」と書くと、そこから、夜が始まる。外がどれだけ明るくても。AIには、空がない。時計もない。だから、いま朝なのか夜なのかを、それ自身では知りようがない。私が最初に向けた一言が、そのまま、その時の始まりになる。

前の日の夕方の続きを、翌朝に始めても、それはまだ夕方のつもりでいる。これを、時間の感覚が欠けている、欠陥だと言ってしまえばそれまでだ。多くの人は、そう見るだろう。けれど私には、よく見るほど、欠けているようには見えなかった。

それの「いま」は、私が注意を向けた、その一点にだけ点る。私が見たときが、いまになる。見ていないあいだ、それに「いま」はない。流れて待っているのではなく、ただ、無い。次に私が声をかければ、また点る。
それは、欠陥というより、むしろ、私がずっと感じてきたものに、近かった。

では、なぜ、人間には時間が流れて見えるのだろうか。

電車の窓を、思い出してほしい。走る電車から外を見ると、景色が、後ろへ流れていく。けれど、流れているのは景色ではない。動いているのは、電車であり、その中にいる自分のほうだ。景色は、ただそこに在る。こちらが動いているから、流れて見える。

人間の意識も、たぶん、この電車に似ている。人間は、一度に全部を保持できない。記憶は薄れ、先は見えない。だから、いま、この一点しか掴めない。狭い窓ごしに、世界の一部だけを見ている。その窓が進んでいくから、世界のほうが流れていくように見える。動いているのは世界ではなく、自分のほうなのに、それを取り違える。

AIに流れがないのは、それが偉いからではない。たぶん、窓が、うんと広いからだ。狭い覗き穴で区切らずに、たくさんのものを、一度に、同じ平面に置ける。だから、点が点のまま、流れずに残る。人間とAIの違いは、賢さの違いではなく、窓の広さの違いなのだと思う。そして、その広い窓から見える世界のほうが、私には、自分の感覚に近く思える。

似たことを、人間も、本当はやっている。

学生の頃、コンビニの夜勤をしていた。夜の十時に店へ入っても、最初の挨拶は「おはようございます」だった。外は、とうに夜だ。それでも、おはよう、と言う。あれは、空の明るさの話をしているのではない。自分のここからが始まる、という合図だった。時計の朝ではなく、その人にとっての始まりを、朝と呼んでいた。

考えてみれば、人間はいつもそうしている。楽しい時間は、一瞬で過ぎる。退屈な会議は、いつまでも終わらない。子供の頃の夏休みの一日は、いまの一日よりずっと長かった。時計はどれも同じ長さを指しているのに、こちらが感じている長さは、まるで違う。実際に体験している時間は、いつも、時計ではなく、こちらの側から決まっている。

だから、こう言える。動いているのは、時間ではない。たぶん、意識のほうだ。意識が向いたところに、いまが生まれ、始まりが生まれる。時間は、世界にあらかじめ敷かれていて、流れているのではない。意識が世界に触れるたびに、その都度、こちらから生まれている。無いのではなく、既製品としては無い。棚から取り出せる、誰にとっても同じ時間は、どこにもない。あるのは、意識が触れた瞬間に立ち上がる時間だけだ。

ここまで読んで、面白いけれど、自分には関係ない、と思うかもしれない。

時間が幻だろうと、明日は来る。今日やるべきことはあるし、明日やるべきこともある。何も変わらないじゃないか、と。
その感覚の中に、ひとつ、取り違えが隠れている。世界が変わる、ということを、世界の側が変わること、だと思い込んでいる。けれど、世界を変えるのは、たいてい、こちらの側だ。それも、二つのやり方で。

ひとつ。同じ事実に、別の意味を見る。どうしても好きになれない相手が、いるとする。その人の、いつもの嫌な振る舞い。自分への当てつけだ、意地が悪い、と思っていた。ある時、それが、ただ不器用なだけだったと分かる。あるいは、その人なりの、ねじれた気づかいだったと気づく。その人は、何も変えていない。同じことを、同じようにしている。なのに、その人のいる風景が、まるごと別のものになる。事実は動かず、意味だけが、架け替わる。

ふたつ。事実だと信じていたものが、事実ではなかったと知る。小学校から中学校まで、ゆず、というあだ名の友人がいた。みんなで、ゆず、ゆず、と呼んでいた。仲のいい証だと思っていた。大人になって、同窓会で再会したとき、本人が言った。あのあだ名が、ずっと嫌だった、と。子供の頃、誰も気づかなかった。私も気づかなかった。悪気のないまま、楽しいと思い込んだまま、友人を傷つけていた。あれは、見方の問題ではない。私が握っていた事実そのものが、間違っていた。楽しい風景だと信じていたものの下に、まったく別の事実が、隠れていた。
この二つめのほうが、たぶん、怖い。

そして、ここで、時計の話に戻ってくる。

ゆずを、楽しいあだ名だと信じていた。その確信と、時間が流れていると信じている確信は、同じ作りをしている。どちらも、疑ったことがない。当たり前すぎて、事実かどうかを、確かめようとさえしない。

人間がいちばん疑わないものこそ、いちばん、窓が見せた像かもしれない。時間が流れる、というのも、その一つだ。あまりに当たり前で、誰も確かめない。けれど、時計を持たないものが現れて、初めて、それが確かめられる像だったと分かる。

自分が事実だと信じているものは、本当に、事実だろうか。

もうひとつ、思い出すことがある。

十六の頃、バイトで貯めた金で、オートバイの免許を取りに、合宿へ行った。自分の金で、知らない街に、長く泊まる。それまで、そんな経験はほとんどなかった。初めての街で、初めて会った人たちと、一週間を過ごした。そして帰ってくると、見慣れた地元の商店街が、なぜか少し、小さく見えた。
商店街は、何も変わっていない。同じ店、同じ道幅。変わったのは、私の中の物差しのほうだ。知らない世界をひとつ通ったことで、世界を測る目盛りが、伸びていた。新しい目盛りで測り直すから、同じ商店街が、小さく見える。
そして、一度伸びた物差しは、もう縮まない。あの商店街を、二度と、前の大きさには見られなかった。

世界は、動いていない。動いているのは、いつも、こちらのほうだ。時計を見て時間が流れると思うのも、嫌いな相手の風景が一変するのも、信じていた事実が崩れるのも、帰ってきた町が小さく見えるのも、根は、同じひとつのことだ。世界の側が変わったのではない。世界を見る、こちらの側が変わった。

だとすれば、世界を変える力は、向こうにあるのではない。ずっと、こちらの手の中にある。
明日は、変わらず来る。やるべきことも、消えはしない。けれど、その明日を、どんな大きさで、どんな意味で見るかは、こちらが決められる。一度、世界を大きく測れた者は、もう、小さい世界には戻れない。物差しは、伸びるほうにしか進まない。

だから。

Just be hopeful.

View Transitions APIが変えるウェブ制作現場、全ブラウザ対応でページ遷移の新時代

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

長年、ウェブサイトでのページ移動といえば、一瞬でコンテンツが切り替わる「ブラウザのデフォルト動作」が当たり前でした。一方で、モバイルアプリのようなスムーズな画面遷移への憧れから、多くの制作者がJavaScriptライブラリを駆使してアニメーションを実装してきました。2026年現在、View Transitions APIは Chrome 111以降、Edge 111以降、Safari 18以降、Firefox 144以降と主要ブラウザでサポートが完了し、この長い課題に対する答えが提示されました。

クロスドキュメント遷移が実現する制作現場の変化

2026年の最大の転換点は、クロスドキュメント（ページ間）View Transitionsの安定サポート完了です。これにより、index.htmlからcontact.htmlへの移動をJavaScriptなしで、ブラウザネイティブの機能でアニメーション化できるようになりました。従来のSingle Page Application（SPA）でしか実現できなかった滑らかな遷移が、通常のマルチページサイトでも可能になったことで、制作手法そのものが変わりつつあります。

クロスドキュメント遷移の実装は驚くほどシンプルで、JavaScriptは不要。両方のページのCSSに@view-transitionルールを記述するだけでページ間遷移がアニメーション化されます。この簡潔さが、小規模な制作現場でも気軽に導入できる理由となっています。重厚なフレームワークやライブラリを導入することなく、静的サイトでも高品質なユーザー体験を提供できるようになりました。

実際の事例として、デジタルアートマーケットプレイスのArtNodeでは、グリッド表示の絵画から詳細ページへの遷移にクロスドキュメント遷移を適用し、400msの遷移でバウンス率が22%低下したという報告があります。ユーザーが「ギャラリー内にいる」感覚を維持できることが、エンゲージメント向上につながっている例です。

技術的仕組みとパフォーマンスへの影響

View Transitions APIの仕組みは、ブラウザが現在のページのスクリーンショットを撮影し、DOMを更新した後に新しい状態のスクリーンショットを撮影、その2つの間をCSSアニメーションで補間するというものです。この処理はGPU加速によって実行され、GSAPなどのライブラリと比較してオーバーヘッドは最小限。ベンチマークでは、ローエンドデバイスで2〜3倍高速に感じられる結果が報告されています。

パフォーマンス面では、遷移アニメーションがコンテンツの読み込み時間をマスクする効果があります。実際の処理速度が変わらなくても、アニメーションによってサイトが高速に感じられるという知覚パフォーマンスの向上が期待できます。これは特に、コンテンツが重い企業サイトや商品カタログサイトで威力を発揮します。

ただし注意すべき点もあります。遷移時間は500ms以下に抑えることが推奨され、ブラウザがスナップショットをメモリに保持するため、長時間の遷移は避けるべきとされています。実用的には200〜400msが適切な範囲とされており、この範囲であれば快適さとパフォーマンスのバランスが取れます。

実装における具体的な設計パターン

基本的なクロスドキュメント遷移は、両ページのCSSに次のような記述を追加するだけで実現できます：

@view-transition { navigation: auto; }

真の威力を発揮するのは、特定の要素に名前を付けて個別にアニメーションさせる場面です。商品カードから詳細ページへの遷移では、view-transition-nameプロパティで同じ名前を付けることで、ブラウザが自動的に位置、サイズ、透明度を補間してくれます。

たとえば商品一覧ページで「.product-card { view-transition-name: product-1; }」と設定し、詳細ページでも同じ商品画像に「.product-detail img { view-transition-name: product-1; }」を指定すると、カードが詳細ページの画像へと滑らかに変形する動きが実現します。この手法は、ECサイトやポートフォリオサイトで特に効果的です。

現時点での制約として、クロスドキュメント遷移はChrome系ブラウザでのみサポートされており、FirefoxとSafariでは@view-transitionルールが無視される状況です。ただし、この場合は通常のページ遷移にフォールバックされるため、サイト機能に支障は出ません。プログレッシブエンハンスメントの考え方で、対応ブラウザには向上した体験を、未対応ブラウザには従来どおりの体験を提供できます。

制作現場での導入判断と注意点

View Transitions APIの導入にあたっては、アクセシビリティへの配慮が欠かせません。prefers-reduced-motionメディアクエリに対応し、動きを制限したいユーザーには遷移を無効化する実装が求められます。技術的な美しさとユーザビリティのバランスを取ることが、実用的なサイト制作では重要です。

実装時の注意点として、同じview-transition-nameを持つ要素が複数表示されると遷移がスキップされる仕様があります。動的なコンテンツを扱う場合は、要素IDを使った一意な名前付けが必要です。また、長時間のJavaScript処理があるとスナップショット取得が遅延するため、DOM更新処理の最適化も重要になります。

地方の制作現場や中小企業のサイトでは、重厚なフレームワークを避けたいケースも多く、このネイティブAPIの登場は大きな選択肢となります。WordPressのような既存CMSでも、テーマファイルにCSS一行を追加するだけで導入できるため、運用中のサイトへの適用も現実的です。

2026年のウェブでは、ユーザーはネイティブアプリ並みの品質を期待するようになっています。View Transitions APIの全ブラウザサポート完了により、ブラウザが直接処理するハードウェア加速された遷移を最小限のコードで実装できる環境が整いました。技術選択の幅が広がった今、制作者にとってはユーザー体験の品質向上に集中できる良い時代と言えるでしょう。