필사 모드: ウェブプラットフォーム 2025 完全攻略:Container Queries・:has()・CSS Nesting・Subgrid・Popover API・Anchor Positioning・WebGPU・WASI・Speculation Rules・Baseline 2024-2025 — Season 6 Ep 5

プロローグ · プラットフォームが大きくなればフレームワークは軽くなる

2014-2020 年に React・Vue・Angular が必要だった理由は、ブラウザがあまりにも足りなかったからだ。コンポーネント・状態管理・アニメーション・ルーティング・レイアウト・インタラクションのすべてを JS で解決しなければならなかった。

2024-2025 年は違う。ブラウザがほとんどをやってくれる。

• Container Queries でコンポーネント自体がレスポンシブに
• :has() で JS なしの親要素ベースの選択
• CSS Nesting・Subgrid で SCSS の必要性が減少
• Popover API・Dialog でモーダルライブラリの必要性が最小化
• Anchor Positioning で Floating UI がネイティブ化
• View Transitions でページ遷移がネイティブ化
• WebGPU で高性能グラフィックス・ML
• Speculation Rules でプリレンダー・プリフェッチ

Next.js・React は今も使うが、2025 年の原則は 「プラットフォームに任せられるものはプラットフォームに」 だ。今回の記事はその地図。

第1章 · Baseline — 互換性の新しい言語

Baseline とは?

2023-2024 年に Web DX Community Group が作ったブラウザ機能の互換性ラベル体系。「この機能は今すぐ使っても安全か?」に答える。

3 段階

Baseline Newly available

• 直近の主要ブラウザ(Chrome・Edge・Firefox・Safari)に到達した
• 最新バージョンが対象

Baseline Widely available

• 上の状態から 30 か月 が経過
• 事実上すべてのアクティブなブラウザが対応
• 安心して使える

Limited availability

• 主要ブラウザの 1〜2 つだけが対応
• プロダクションでの使用は注意

実戦での使い方

• MDN・caniuse・web.dev に Baseline ラベルが表示される
• Next.js・Astro・Vite が target: baseline-2024 のようなオプションを導入
• 社内コーディングガイドで「Baseline widely available のみポリフィルなし」と宣言する

なぜ重要か

• 「IE 対応・モダンブラウザ」のような曖昧な基準を置き換える
• チーム内の意思決定が速く明確になる
• プロダクションの安定性・PWA の品質基準になる

第2章 · Container Queries — レスポンシブの革命

従来の問題

メディアクエリ @media は ビューポート全体 が基準。しかし同じカードコンポーネントが、あるときはサイドバー、あるときはメインに配置されるとサイズが変わる。ビューポートは同じでも。

解決: @container

.card-grid {
  container-type: inline-size;
  container-name: grid;
}

@container grid (min-width: 600px) {
  .card { display: flex; }
}

これでカードグリッド 自体の幅 を基準にカードのレイアウトが決まる。

単位

• cqw, cqh: container width/height
• cqi, cqb: inline/block
• cqmin, cqmax

2025 年の対応状況

• Chrome 105+・Safari 16+・Firefox 110+ すべて Baseline Widely available
• 事実上の 基本ツール

使用パターン

(1) 自己完結型のレスポンシブコンポーネント

• どこで再利用しても関係ない

(2) Style Queries (2024 Chrome/Edge)

• @container style(--theme: dark) — 親のスタイルプロパティに基づく条件

(3) ビューポート + コンテナの組み合わせ

• ページレイアウトはメディア、コンポーネントはコンテナ

第3章 · :has() — 親セレクタの到来

なぜ革命なのか

CSS はいつも 下方向にだけ 下りていくセレクタだった。子を基準にした親のスタイリングには JS が必須。:has() がこの制限を取り払った。

使用例

(1) 子の有無による親のスタイル

.card:has(img) { padding-top: 0; }
.form:has(input:invalid) { border: 1px solid red; }

(2) 子の状態による全体のスタイル

body:has(dialog[open]) { overflow: hidden; }

(3) 兄弟関係

label:has(+ input:focus) { color: blue; }

対応状況

• Chrome 105+, Safari 15.4+, Firefox 121+ — Baseline Widely
• かつての性能面の懸念は解消済み

実戦でのインパクト

• JS で parent のクラスを操作していたコードを 大量に削除できる
• インタラクション状態の UI がはるかに簡潔に
• React コンポーネントの「状態 prop」の多くが CSS へ

第4章 · CSS Nesting のネイティブ化

これまで

• SCSS・Less・Stylus で nesting
• ビルドツールへの依存、学習コスト

2023-2024 のネイティブ Nesting

.card {
  padding: 1rem;

  & .title {
    font-size: 1.5rem;
  }

  &:hover {
    background: #f0f0f0;

    & .title { color: #333; }
  }

  @media (min-width: 768px) {
    padding: 2rem;
  }
}

注意

• 最新の仕様では & セレクタを 省略できる (2024 年改訂)
• 古い文法(& )との混用に注意
• PostCSS Preset-Env でフォールバックのトランスパイル

対応状況

• Chrome 120+・Safari 17.2+・Firefox 117+ — Baseline 2023-2024

意味するもの

• SCSS の必要性が大きく減少
• CSS-in-JS への依存が減少
• Vanilla CSS の復活

第5章 · CSS Subgrid

従来の Grid の限界

• 親の grid に子の grid を入れても 行/列が揃わない
• カードのタイトル・本文・CTA を揃えるのが難しい

Subgrid が解決する

.parent {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
}

.child {
  display: grid;
  grid-template-columns: subgrid; /* 親グリッドを継承 */
}

これで子の grid が親の grid のトラックに揃う。

ユースケース

• カードリストのタイトル・本文・フッターの自動整列
• マルチカラムのフォーム
• Masonry(組積み)レイアウト

対応状況

• Firefox 71+ (2019 年以来対応), Safari 16+, Chrome 117+ — Baseline 2023

第6章 · Popover API・Dialog Element

従来のモーダルの問題

• フォーカス管理が手動
• スクロールロックを JS で
• ESC で閉じるのが手動
• アクセシビリティの ARIA を自前で

<dialog> (HTML5)

• モーダル・非モーダルの両方
• ネイティブのフォーカストラップ
• showModal() / close() メソッド
• ESC で自動的に閉じる
• ::backdrop のスタイル指定に対応

Popover API (2024-2025)

<button popovertarget="menu">メニュー</button>
<div id="menu" popover>
  <ul>
    <li>項目 1</li>
    <li>項目 2</li>
  </ul>
</div>

• popover 属性ひとつでポップオーバー
• 自動で Top Layer にレンダー (z-index の心配なし)
• Auto-hide (外側のクリック・ESC)
• popover="manual" で手動制御

対応状況

• Chrome 114+・Safari 17+・Firefox 125+ — Baseline 2024

実戦での影響

• Headless UI・Radix Dialog/Popover を使う必要性が減少
• ネイティブ + 少しの CSS/JS で十分

第7章 · CSS Anchor Positioning

問題: フローティング UI

ツールチップ・ドロップダウン・ポップオーバーを特定の要素を基準に 正確に配置 するのは複雑。

• Floating UI(Popper.js)のようなライブラリが必須
• リサイズ・スクロールに合わせて JS で再計算

解決: CSS Anchor Positioning (2024-)

<button id="btn">クリック</button>
<div popover style="position-anchor: --btn;">
  ツールチップ
</div>

#btn { anchor-name: --btn; }

[popover] {
  position: absolute;
  top: anchor(--btn bottom);
  left: anchor(--btn left);
}

• CSS だけで アンカーベースの位置決め
• 自動リポジショニング (fallback)
• 性能・アクセシビリティが内蔵

対応状況 (2025 年 4 月)

• Chrome 125+: 安定
• Safari: 開発中 (2025 年後半)
• Firefox: 開発中

インパクト

• Popper・Floating UI の使用が減少
• React のツリー構造が簡素化
• ただしまだポリフィルが必要 (Safari 対応前)

第8章 · Web Components の 2025 年の現在地

基本の 3 要素

• Custom Elements
• Shadow DOM
• HTML Templates

2024-2025 年の成熟

(1) Declarative Shadow DOM

• サーバーレンダー時に Shadow DOM を含められる
• SSR が可能に

(2) Form-associated Custom Elements

• 標準のフォームに自然に統合
• formAssociated = true、ElementInternals API

(3) CSS :state() 疑似クラス

• カスタム状態を CSS から選択

フレームワークとの統合

• React 19 で Custom Elements のサポートが改善 (attributes と props の区別)
• Lit・Stencil が成熟
• Vue・Svelte は自然に統合

現実的な評価

長所

• フレームワーク中立 (デザインシステム・埋め込みウィジェット)
• 長寿命 (ブラウザ標準)

限界

• React コンポーネント水準のエコシステムはない
• SSR・ハイドレーションが複雑
• 主に 共有ライブラリ・組み込みウィジェット に限定される

適した用途

• 複数チームで共有する「Button/Icon ライブラリ」
• 外部サイトに埋め込むウィジェット (コメント・チャット)
• Shopify・WordPress などのプラグイン

第9章 · WebGPU の現在地

WebGL の限界

• OpenGL ES ベースで、構造が古い
• 並列コンピューティングが限定的
• ゲーム・AI には不足

WebGPU (2023-)

• モダンな GPU API (Vulkan・Metal・DX12 水準)
• Compute Shader 対応 → 汎用 GPU コンピューティング
• 一つの API でマルチ OS 対応

2024-2025 の主な用途

(1) AI/ML のブラウザ実行

• Transformers.js: Whisper・Llama などをブラウザで推論
• ONNX Runtime Web: GPU アクセラレーション
• MLC-LLM: 7B モデルもブラウザで

(2) 高性能グラフィックス

• WebGPU ベースの 3D エンジン (Three.js, Babylon.js)
• ゲーム・バーチャル展示

(3) データ可視化

• 大規模なポイントクラウド・WebGL を超えた性能

対応状況

• Chrome 113+・Edge 113+ が安定
• Safari 18+・Firefox Nightly (2025 年に進行中)

限界

• モバイル対応はまだ部分的
• メモリ管理が複雑

第10章 · File System Access API・その他のローカル機能

File System Access API

• ブラウザから ローカルファイルを直接開く/保存する
• 従来の <input type="file"> を超えて 継続的なアクセス・変更 ができる
• Photopea・VS Code Web・Figma のようなアプリに必須

2024-2025 の主な新 API

(1) Clipboard API の高度化

• 画像・リッチテキストに対応

(2) Web Share API

• OS ネイティブの共有シート

(3) Wake Lock API

• 画面が消えるのを防ぐ (料理・会議アプリ)

(4) Screen Capture・WebCodecs

• ビデオ・オーディオの低レベル操作

(5) Compression Streams

• gzip・deflate をネイティブに

(6) Web Locks

• タブ間のミューテックス・リソース調整

限界

• 一部は PWA または設定が必要
• Safari・Firefox で対応にばらつきがある

第11章 · WebAssembly・WASI 2025

WASM の現在

• モバイル・デスクトップの多くのブラウザ でネイティブ級の性能
• JS との高速な interop (WASM SIMD、参照型、Exception Handling)
• 言語: Rust, Go, C/C++, AssemblyScript, Zig, Kotlin・Swift は実験的

WASI (WebAssembly System Interface)

ブラウザの外・サーバーで WASM を実行するための標準。

• WASI Preview 2(2024) — コンポーネントモデル
• wasmtime・wasmer・WasmEdge ランタイム

実戦での使用

(1) Serverless エッジ

• Cloudflare Workers, Fastly Compute@Edge, Vercel WASM
• Cold Start・隔離・多言語対応

(2) プラグインシステム

• Figma Plugins, Shopify Functions, Envoy Proxy
• ユーザーコードを安全に隔離

(3) ブラウザ内の重い演算

• 画像・ビデオ編集、ML 推論、エミュレータ

韓国での適用事例

• Naver Whale: WASM ベースの拡張
• KakaoTalk Web: 一部機能で WASM
• Toss: セキュリティ・中核ロジックへの WASM を検討

第12章 · Speculation Rules API

目的

• ユーザーが次に行くページを事前にロード
• prerender・prefetch の標準

例

<script type="speculationrules">
{
  "prerender": [
    { "source": "list",
      "urls": ["/next-page", "/likely-next"] }
  ],
  "prefetch": [
    { "source": "document",
      "where": { "href_matches": "/articles/*" } }
  ]
}
</script>

モード

• prefetch: リソースだけ取得し、実行はしない
• prerender: 全体をレンダー (最速だがコストは高い)

2024-2025 の現況

• Chrome 121+・Edge 121+ が安定
• Safari・Firefox は開発中
• Chrome Prefetch Hints がデータに基づいて自動で推薦

実戦での使用

• Next.js・Astro がバックエンドからの自動注入を検討
• 大企業のニュース・EC で活用が始まっている

注意

• コスト (CPU・ネットワーク)
• 分析ツールでの「偽の訪問」問題

第13章 · 実戦 · 「プラットフォーム優先」チェックリスト

新しいコンポーネント・機能を作るとき、フレームワーク・ライブラリの前に 確認する。

チェック項目

• レスポンシブ: Container Queries でいける?
• 状態スタイル: :has()・:focus-within で?
• モーダル・ポップオーバー: <dialog>・Popover API?
• ツールチップ・ドロップダウン: Anchor Positioning?
• フォームの妥当性: :user-invalid・:user-valid?
• サイドシート: <details> + スタイル?
• ファイル: File System Access?
• カウンター・数値の変化: CSS @property アニメーション?
• スクロール効果: Scroll-driven Animations?
• ページ遷移: View Transitions?

判断の順序

1. ウェブプラットフォームに標準機能はあるか?
2. Baseline Widely 対応か?
3. なければ、軽量ライブラリで代替できるか?
4. それでも必要なら、フレームワークのコンポーネント

第14章 · 次回予告 — Season 6 Ep 6:「パフォーマンス・Core Web Vitals 2025」

ウェブプラットフォームの機能をうまく使うことは、パフォーマンス をうまく使うことだ。Ep 6 は Core Web Vitals とパフォーマンス全般。

• LCP・CLS・INP (FID の後継)
• Real User Monitoring と Synthetic Test
• Critical Rendering Path、LCP の最適化
• JS バンドルのダイエット (Rollup・esbuild・swc)
• Image の最適化 (Next/Image・Astro Image・AVIF)
• Font の最適化 (font-display・可変フォント・サブセット)
• Caching 戦略 (Cache-Control・Service Worker)
• Edge・CDN・HTTP/3
• Vercel Speed Insights・CrUX・PageSpeed
• 2025 年のモバイル低消費電力での性能
• 韓国のユーザーのネットワーク特性 (地下鉄・5G)

「パフォーマンスは機能ではない。すべての機能の条件だ」

次の記事で会おう。

エピローグ · チェックリスト 12

1. Baseline Widely を基準に機能の使用を決めているか?
2. レスポンシブが必要なとき Container Queries を先に検討しているか?
3. 親要素ベースのスタイルに :has() を活用しているか?
4. CSS がビルドツールなしで Nesting で管理されているか?
5. 複雑なレイアウトに Subgrid を使っているか?
6. モーダル・ポップオーバーを ネイティブ API で実装しているか?
7. ツールチップ・ドロップダウンの位置を Anchor Positioning で?
8. Web Components を 共有ライブラリ に活用しているか?
9. WebGPU の機会(AI・可視化)を探索しているか?
10. ローカル機能(ファイル・システム)が必要なら Platform API が先か?
11. Speculation Rules でプリフェッチ/プリレンダーを検討したか?
12. 「プラットフォーム優先」チェックリストを 新しいコンポーネントごとに 適用しているか?

「良いエンジニアはプラットフォームの能力を知っている。 偉大なエンジニアはいつプラットフォームに任せ、いつ自分で作るかを知っている。」

— Season 6 Ep 5, Fin.