yuheijotaki.com

Vertex AI Search でサイト内検索を実装してみる

Tue, 24 Feb 2026 00:00:00 GMT

概要

Google Cloud の Vertex AI Search（Discovery Engine API）を使ったサイト内検索を作ってみた。

構成

フロント
- Astro SSG のページで /api/search を叩く
バックエンド
- Vercel Functions（api/search.ts）が認証トークンを取得して Discovery Engine API に POST
認証
- Google Cloud サービスアカウントの JSON 鍵を Vercel 環境変数に保存し、google-auth-library でアクセストークンを取得

Google Cloud 側の準備

Discovery Engine API を有効化する
- Google Cloud コンソールの API ライブラリから有効化
データストアを作成する
- ウェブサイトクロール型を選択し、クロール対象を yuheijotaki.com/* に設定
検索アプリを作成する
- データストアと接続し、プロジェクト ID を控えておく
サービスアカウントを作成する
- roles/discoveryengine.viewer ロールを付与し、JSON 鍵をダウンロード
Vercel 環境変数に登録する
- GOOGLE_SERVICE_ACCOUNT_KEY（JSON 鍵の中身）と VERTEX_AI_SEARCH_ENGINE_ID（プロジェクト ID）を設定

所感など

ウィジェット埋め込みと API 2種類の統合形式がある
ウェブクロール後（インデックス作成後）に検索が可能となる。だいたい8時間ほどかかる
ページの取得件数は上限は100件まで（参考）
- filter 使えば特定階層のみに絞ったクエリも投げれそう
ページの取得順はデフォルトで関連度順になる。ランク付けをしたりすることも可能
サイト内検索の場合の料金（参考）
- データストアの容量は月 10 GiB まで無料
- Standard Edition ではなく Enterprise Edition（$4.00 / 1,000 クエリ）が必須。月 10,000 クエリまで無料
データソースは今回はウェブサイトを選択しているが、BigQuery や Cloud Storage も選択可能で、データソースの種類に合わせてAIを使った検索や会話機能を作れるAPIといったものらしい

pitcms を試してみる

Mon, 09 Feb 2026 00:00:00 GMT

pitcms とは

GitHub と連携してコンテンツを管理できる日本製ヘッドレスCMS
公式サイト：pitcms

導入から設定まで

入稿から反映まで

今回はデプロイ先、プレビュー環境を Cloudflare Pages にした。

pitcms の管理画面で「編集セッション」を作成
コレクション内の記事を編集
記事の保存後にプレビューURLが発行されるので確認（ https://pitcms-***.***.pages.dev/ など）
確認後、編集セッションの「変更を反映」
本番環境にデプロイされる

git の動きとしては、3. の段階でプレビューブランチが作成、5.の段階で main ブランチへマージされる

デモ

Astro の Content Collections（SSG）と組み合わせて使ってみた。

デモサイト：pitcms-sample.pages.dev
リポジトリ：yuheijotaki/pitcms-sample

分かったこと・所感

コレクションのスキーマはルートに置く pitcms.jsonc ファイルで定義する
プレビュー環境の対応は Cloudflare Pages の他に、Vercel、Netlify、Cloudflare Workers が選択できる。1クリックで設定できるので楽
GitHub のコンテンツをデータソースとするため、例えばローカルで記事編集してプッシュすると pitcms の管理画面に反映される仕組み
編集セッションの概念が最初はとっつきにくいが、使って理解すると理にかなっているように思えた
Astro の Content Collections との相性がよさそう
TinaCMS（TinaCloud）に近い感じがする
プランはコレクション（API）3つ、メンバー3人などの制限がある Free プラン、それらの数が無制限の Proプラン（¥980/月）がある

Astro Live Content Collections を試してみる

Thu, 15 Jan 2026 00:00:00 GMT

概要

Astro 5.10 で追加された Live Content Collections を試してみた。Live Content Collections はビルド時ではなくリクエスト時にデータを取得できる機能（v5 系だと要 experimental フラグ）。

Live Content Collections とは

従来の Content Collections

データはビルド時に取得される
データストアに保存される
静的なコンテンツに最適

Live Content Collections

データはリクエスト時に取得される
データストアには保存されない
常に最新のデータを取得できる
頻繁に更新されるコンテンツに最適

詳細： Live Content Collections: A Deep Dive | Astro

環境構築

SSR アダプターとして今回は Vercel を使用する。

設定

astro.config.mjs に実験的フラグを追加する。

export default defineConfig({
  adapter: vercel(),
  experimental: {
    liveContentCollections: true,
  },
});

src/live.config.ts にライブコレクションを定義する。（従来の src/content.config.ts とは別ファイル）

ポイントいくつか

defineLiveCollection() を使用
type: 'live' を指定
loader に loadCollection と loadEntry を実装

Content Collections と Live Content Collections の比較

今回は従来のビルド時 Content Collections と Live Content Collections の両方を実装して比較した。

デモページ、ソースコード

静的版（従来の Content Collections）
動的版（Live Content Collections）

静的版（Content Collections）

src/content.config.ts で定義する。ページコンポーネントでは getCollection() を使用。

動的版（Live Content Collections）

src/live.config.ts で定義する。ページコンポーネントでは getLiveCollection() を使用。

---
export const prerender = false;

import { getLiveCollection } from 'astro:content';
const { entries, error } = await getLiveCollection('liveBlog');
---

従来の fetch（SSR）との比較

従来の fetch

手動で型の定義が必要
バリデーションは自分で実装
エラーハンドリングも自分で実装

Live Content Collections

スキーマから自動的に型が推論される
Zod による自動バリデーション
エラーハンドリングが統一される
ローダーとして再利用や配布可能

Live Content Collections は SSR の上に構築された抽象化レイヤーという扱いらしい（よく分からない）

所感

割とシンプルなデータでも Live Content Collections のページは重いので使い所は気をつけないと
記事のプレビュー環境で使うのとかはいいかも

Astro で CSS ファイル名を固定する

Sun, 23 Nov 2025 00:00:05 GMT

概要

ビルド後に組み込み作業アリ用のAstro開発環境という記事で Astro の CSS ファイル名を固定する方法が紹介されていた。CSS ファイル名の固定はできないと思ってたので実際に試してみた。

Astro での CSS ファイル名の扱い

通常 Astro でビルドすると CSS ファイルにハッシュが付与される。

_astro/_slug_.a1Wq-uq3.css

ハッシュはファイルの内容が変わるたびに異なる値になる。キャッシュ戦略として有効だがバックエンドへの組み込み作業がある場合やクライアントのガイドラインでファイル名が制限される場合など固定のファイル名にしたいケースがある。

固定化すると以下のようなファイル名になる。

_astro/common.css
_astro/styles.css
_astro/styles2.css

CSS カスタムプロパティを使った固定化

仕組み

Vite の rollupOptions.output.assetFileNames で CSS のソースコードから特定のカスタムプロパティを抽出してそれをファイル名として使用する。

ビルド後に組み込み作業アリ用のAstro開発環境では以下の2つのカスタムプロパティが使われている。

--output-file-name-important - 優先度が高い（全ページ共通 CSS やページ固有 CSS で使用）
--output-file-name - 優先度が低い（複数ページ用 CSS で使用）

設定方法

astro.config.mjs に以下を追加する。

import { defineConfig } from 'astro/config';

export default defineConfig({
  build: {
    inlineStylesheets: 'never',
  },
  vite: {
    build: {
      rollupOptions: {
        output: {
          assetFileNames: (assetInfo) => {
            if (assetInfo.name && assetInfo.name.endsWith('.css')) {
              // --output-file-name-important: filename.css を優先
              const importantMatch = String(assetInfo.source).match(
                /--output-file-name-important:\s*([^;}\s]+)/,
              );
              if (importantMatch) {
                return `_astro/${importantMatch[1].trim()}`;
              }

              // --output-file-name: filename.css を次に確認
              const matches = [
                ...String(assetInfo.source).matchAll(/--output-file-name:\s*([^;}\s]+)/g),
              ];
              if (matches.length > 0) {
                const fileName =
                  matches.map((m) => m[1].trim().replace(/\.css$/, '')).join('-') + '.css';
                return `_astro/${fileName}`;
              }

              // カスタムプロパティがない場合はデフォルト名
              return '_astro/styles.css';
            }
            return '_astro/[name].[hash][extname]';
          },
        },
      },
    },
  },
});

build.inlineStylesheets: 'never' - CSS をインライン展開せず外部ファイルとして出力
assetFileNames 関数内で assetInfo.source から正規表現でカスタムプロパティを抽出
CSS ファイル以外のアセット（画像など）はハッシュ付きのままにする

CSS への記述

Astro コンポーネントの style タグに is:global を付けて、カスタムプロパティを記述する。

<style is:global>
  :root {
    --output-file-name-important: common.css;
  }
</style>

<style lang="scss">
  /* 通常のスタイル */
</style>

実際に試してみる

全ページで使われる Layout.astro などのコンポーネントに --output-file-name-important: common.css を追加する。

<style is:global>
  :root {
    --output-file-name-important: common.css;
  }
</style>

ビルド結果

_astro/common.css
_astro/styles.css
_astro/styles2.css
...

common.css が生成された。中身を確認すると Layout コンポーネントと全ページで使われている他のコンポーネントの CSS がまとめられていた。

Astro の CSS 分割の仕組み

Astro はコンポーネントの使用状況に応じて CSS を自動的に分割する。

全ページで使われるコンポーネント - 1つの CSS ファイルにまとめられる
一部のページでのみ使われるコンポーネント - 別の CSS ファイルとして分割される

複数のコンポーネントが1つの CSS ファイルにまとめられる場合そのファイル内には複数の --output-file-name カスタムプロパティが含まれる可能性がある。その場合は優先度の高い --output-file-name-important が使用される。

Vite と Rollup の役割

Astro はビルドツールとして Vite を使用しており CSS の出力は Rollup によって処理される。

Vite - モジュールのバンドルと最適化を担当
Rollup - output.assetFileNames で出力されるアセットファイルの命名規則を制御

参考：Vite Configuration Reference / Rollup - output.assetFileNames

assetInfo.source には CSS の内容が文字列として渡される。この文字列から正規表現でカスタムプロパティを抽出することでファイル名を制御できる。

その他の固定化方法

CSS カスタムプロパティを使う以外にも設定ファイルでマッピングを定義する方法がある。

設定ファイルでのマッピング

astro.config.mjs で明示的にファイル名のマッピングを定義する方法。

const cssMapping = {
  Layout: 'common.css',
  Header: 'common.css',
  Footer: 'common.css',
  index: 'top.css',
  about: 'about.css',
};

export default defineConfig({
  build: {
    inlineStylesheets: 'never',
  },
  vite: {
    build: {
      rollupOptions: {
        output: {
          assetFileNames: (assetInfo) => {
            if (assetInfo.name && assetInfo.name.endsWith('.css')) {
              // names から元のファイル名を推測
              const baseName = assetInfo.names[0];
              const mappedName = cssMapping[baseName] || 'styles.css';
              return `_astro/${mappedName}`;
            }
            return '_astro/[name].[hash][extname]';
          },
        },
      },
    },
  },
});

デメリット

Astro が複数のコンポーネントの CSS を1つのファイルに最適化する際 assetInfo.names に含まれる情報が限定的で元のファイルを正確に特定できないことがある
マッピングの管理が煩雑になる（コンポーネントが増えると設定も増える）
CSS とマッピング定義が離れているためメンテナンス性が低い

CSS カスタムプロパティを使う方法は CSS の中で完結してコンポーネント単位で管理できる点で優れている。

分かったこと・所感

バックエンドへの組み込みなどに有効だがフレームワークの設計を壊してる気もするので罪悪感が残る。

Astro SVG components を試してみる

Sun, 23 Nov 2025 00:00:04 GMT

概要

Astro 5.0 以降で追加された SVG components 機能を使って従来の astro-icon との違いを試してみた。

SVG components とは

SVG ファイルを直接インポートして Astro コンポーネントとして使える機能。

---
import StarIcon from './icons/star.svg';
---

<StarIcon width="48" height="48" />

このようにインポートすると、SVG の内容が HTML にインラインで埋め込まれる。

公式ドキュメント：SVG components - Astro Docs

SVG components の処理の仕組み

Astro は SVG ファイルをインポートするとビルド時に props を受け取れる Astro コンポーネントに変換する。

参考：astro/packages/astro/src/assets/utils/svg.ts#L1-L50

変換処理では SVG ファイルの内容を読み取って Astro.props で属性を受け取れる形に整形される。これにより SVG がそのままインラインで HTML に展開される。

生成される HTML

<!-- SVG components の生成HTML -->
<svg viewBox="0 0 24 24" width="48" height="48" fill="none" stroke="currentColor">
  <path
    d="M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z" />
</svg>

同じアイコンを複数回使うと、その都度 SVG がインラインで展開される。

astro-icon との比較

astro-icon の仕組み

astro-icon は SVG sprite を生成して最適化する仕組み。同じアイコンを複数回使う場合は <symbol> と <use> で参照する形になる。

---
import { Icon } from 'astro-icon/components';
---

<Icon name="star" width="48" height="48" class="custom-class" />

参考：astro-icon/packages/core/src/loaders/loadLocalCollection.ts

SVG ファイルを読み込む際 @iconify/tools を使って SVG の最適化や色の変換（currentColor への変換など）を行う。同じアイコンが複数回使われる場合は <symbol> 定義を一度だけ生成して <use> で参照することで HTML サイズを削減する。

生成される HTML

<!-- astro-icon の生成HTML -->
<svg data-icon="star" width="48" height="48" class="custom-class">
  <symbol id="ai:local:star" viewBox="0 0 24 24">
    <path
      d="M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z" />
  </symbol>
  <use href="#ai:local:star"></use>
</svg>

主な違い

機能	SVG components	astro-icon
インポート	`import Icon from './icon.svg'`	`<Icon name="icon" />`
HTML出力	インラインSVG	SVG sprite（symbol + use）
最適化	なし	同じアイコンの重複を自動削減
ファイル管理	SVGファイルを直接管理	アイコンディレクトリで一元管理

デモ

デモでは astro-icon と SVG components を並べて、生成される HTML の違いを確認できる。

分かったこと・所感

SVG components はシンプルな実装で追加のライブラリなしで SVG を扱える
どちらも props（width や height や class など）は渡せる
SVG components はインライン展開されるため同じアイコンを複数回使う場合は HTML サイズは増えそう

使っていいのか迷う機能 2025

Sun, 23 Nov 2025 00:00:03 GMT

概要

新しい CSS や HTML の機能が次々と追加されているが実際に実務で使っていいのか判断に迷う。ここ1〜2年で使えるようになったものとまだ使えないものを整理してみた。

判断基準

Baseline とは

Baseline は主要なブラウザで機能が利用可能になったことを示す指標。MDN や web.dev で表示される。

Newly available - すべての主要ブラウザで利用可能になってから30ヶ月未満
Widely available - すべての主要ブラウザで利用可能になってから30ヶ月以上経過

クライアントワークでの基準

Web 制作会社でのクライアントワークでは Chrome、Safari、Firefox、Edge、iOS Safari、Android Chrome の全てで利用可能でないと「使えない」という基準で判断する。

Baseline の「Newly available」であれば基本的には使えるが一部のブラウザでのみ実装されている機能はフォールバックを用意しない限り使用を控える。

使える機能

全ブラウザで利用可能になった機能。

CSS Nesting

Sass や SCSS で使われていたネスト構文がネイティブ CSS で利用可能になった。

Baseline: Widely available（2023年8月）

Popover API

JavaScript を使わずに HTML 属性だけでポップオーバーを実装できる。Anchor Positioning と組み合わせることで柔軟な配置が可能だが Anchor Positioning が未対応のブラウザでは位置調整が必要。

Baseline: Newly available（2024年4月）

@starting-style

display: none から display: block への切り替え時にトランジションを適用できる。これまで opacity や transform のトランジションは可能だったが display の変更時にはトランジションが効かなかった。

Baseline: Newly available（2024年5月）

light-dark() 関数

ライトモードとダークモードで異なる色を1行で指定できる。prefers-color-scheme のメディアクエリを書く必要がなくなった。

Baseline: Newly available（2024年3月）

まだ使えない機能

一部のブラウザでのみ実装されているか実装途中の機能。

CSS Anchor Positioning

ツールチップやポップオーバーをアンカー要素に対して正確に配置する機能。Chrome と Edge のみ対応で Safari と Firefox は未対応。Popover API と組み合わせて使うことが多いが Anchor Positioning が使えないブラウザでは JavaScript での位置調整が必要になる。

対応状況: Chrome 125+, Edge 125+（Safari と Firefox 未対応）

View Transitions API

ページ遷移時にスムーズなアニメーションを実現する API。Chrome と Edge のみ対応。SPA だけでなく MPA（マルチページアプリケーション）でも使える。

対応状況: Chrome 111+, Edge 111+（Safari と Firefox 未対応）

Scroll-driven Animations

スクロール位置に連動したアニメーションを CSS だけで実装できる。Safari が未対応。

対応状況: Chrome 115+, Edge 115+, Firefox 114+（Safari 未対応）

field-sizing

textarea や input 要素のサイズを内容に応じて自動調整する機能。Chrome のみ対応。

対応状況: Chrome 123+（他ブラウザ未対応）

interpolate-size

height: auto や width: auto でもアニメーションを可能にする機能。Chrome のみ対応。これまで height: 0 から height: auto へのトランジションができなかったがこの機能で可能になる。

対応状況: Chrome 129+（他ブラウザ未対応）

reading-flow

CSS Grid や Flexbox で配置した要素の読み上げ順序を制御する機能。まだ実装されているブラウザはない。視覚的な順序とスクリーンリーダーでの読み上げ順序を一致させることができる。

対応状況: すべてのブラウザで未対応（仕様策定中）

分かったこと・所感

CSS Nesting みたく使えるけど設計難しいとか light-dark() みたく使えるけどどこでとか field-sizing や reading-flow みたく使えてもいやだなとか、そういうのも多いがまあ知っておくのは大事ということで。

axe-core の Best Practice ルールを理解する

Sun, 23 Nov 2025 00:00:02 GMT

概要

axe DevTools で Web サイトのアクセシビリティチェックをしていると WCAG の達成基準とは別に「Best Practice」という項目が検出される。どのような基準で Best Practice なのか WCAG とどう違うのかを調べてみた。

axe-core の Best Practice ルールとは

axe-core の Best Practice ルールは WCAG の達成基準には直接該当しないがアクセシビリティ向上に寄与する推奨事項を含むルールセット。Deque Systems が独自に定義している。

WCAG の達成基準は A、AA、AAA の3つのレベルに分類されるが Best Practice はこれらのレベルとは別にユーザビリティの向上を目的とした項目が含まれる。

主な Best Practice ルール

axe-core の Best Practice タグで検出される主な項目：

ページ構造

page-has-heading-one - ページに h1 見出しが存在するか
region - コンテンツがランドマークに含まれているか
landmark-one-main - メインランドマークが1つだけ存在するか

見出し構造

heading-order - 見出しレベルが正しい順序で使われているか（h1 の次が h3 ではなく h2 など）

リンク

link-name - リンクにアクセシブルな名前が付いているか
link-in-text-block - テキストブロック内のリンクが識別可能か

画像

image-redundant-alt - 画像の alt テキストが冗長でないか（「画像」「写真」などの不要なテキストを含まない）

フォーム

label - フォーム要素に適切なラベルが付いているか（これは WCAG の達成基準にも含まれることがある）

WCAG との関係

Best Practice ルールは WCAG の達成基準とは独立している。WCAG の達成基準を満たしていても Best Practice で指摘されることがある。

例えば h1 見出しの存在は WCAG の達成基準には含まれていないがページの主要なトピックを明確にするために推奨される。

axe-core ではテスト時にタグを指定することで実行するルールを制御できる。

// WCAG 2.1 レベル A, AA のみをテスト
.withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa'])

// Best Practice も含めてテスト
.withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'best-practice'])

Best Practice の位置づけ

WCAG の達成基準はアクセシビリティの最低限または推奨される基準を定めている。Best Practice はそれらを補完する形でより良いユーザー体験を提供するための指針となる。

WCAG レベルでいうと：

レベル A - 達成が比較的容易で重篤な問題を引き起こしやすい基準
レベル AA - より高度なアクセシビリティを実現する基準（多くの組織が目指すレベル）
レベル AAA - 最も厳格な基準
Best Practice - WCAG の達成基準とは独立したユーザビリティ向上のための推奨事項

実務での扱い方

axe DevTools でチェックする際 Best Practice の項目は Issue として検出されるが WCAG 違反とは別に考える必要がある。

例えば WCAG レベル AA の準拠を目指すプロジェクトであれば Best Practice の項目は必須ではない。ただし Best Practice の項目を改善することでユーザー体験の向上につながることが多い。

また Best Practice で指摘された項目が実際にはプロジェクトの要件や文脈では適切でない場合もある。例えばランディングページではメインコンテンツをランドマークで囲まない設計も考えられる。

分かったこと・所感

Best Practice は WCAG の達成基準とは独立したユーザビリティ観点でのチェック項目
ページ構造（h1 やランドマーク）や見出し順序などコンテンツの構造に関する項目が多い
WCAG の達成基準を満たしていても Best Practice で指摘されることがある
必須ではないが改善することでユーザー体験の向上が期待できる
プロジェクトの要件や文脈によっては Best Practice の項目を対応しないという判断もある

参考記事

フォーカス制御のパターンを整理する

Sun, 23 Nov 2025 00:00:01 GMT

概要

モーダルやメガメニューなど UI によってフォーカスの制御方法が異なる。キーボード操作時にフォーカスが抜けられる／抜けられない UI の違いを整理してみた。

フォーカス管理とは

キーボード操作でウェブページを利用する際は Tab キーでフォーカスを移動していく。このとき特定の UI 内にフォーカスを留めるか自由に移動させるかを制御する。

主なフォーカス制御の方法

tabindex

HTML 要素のフォーカス順序を制御する属性。

tabindex="0": 通常のフォーカス順序に含める
tabindex="-1": Tab キーではフォーカスできないが、JavaScript の focus() では可能
tabindex="1" 以上: フォーカス順序を指定

inert 属性

要素とその子要素すべてを不活性化する HTML 属性。フォーカス移動とクリックイベントを無効化してアクセシビリティツリーからも除外する。

モーダル表示時に背後のコンテンツを完全に操作不可にする場合に使う。

フォーカストラップ

JavaScript でフォーカスを特定の範囲内に留める実装。モーダルやドロワーなど開いている間は背後のコンテンツを操作させたくない UI で使う。

UI パターンごとの実装

モーダルダイアログ

背後のコンテンツは操作できずフォーカスはモーダル内に留まる。ESC キーで閉じて元の要素にフォーカスを戻す。

実装は背後のコンテンツに inert 属性を付与してモーダル内でフォーカストラップを実装する。<dialog> 要素を使うと標準で実現できる。

メガメニュー

背後のコンテンツも操作可能でフォーカスがメニュー外に移動したら自動的に閉じる。マウスホバーでも開閉することが多い。

実装は inert 属性を使わず focusin イベントでフォーカス位置を監視してメニュー外にフォーカスが移動したら閉じる処理を実装する。

関連する WCAG 達成基準は 3.2.1 フォーカス時（レベル A）。

パターンの使い分け

UI	フォーカストラップ	背後を操作	閉じる条件
モーダルダイアログ	必要	不可	明示的な操作 or ESC
メガメニュー	不要	可	フォーカスが外れる or ESC
ツールチップ（Popover）	不要	可	フォーカスが外れる or ESC

APG パターンとの対応

ARIA Authoring Practices Guide (APG) では、各 UI パターンのキーボード操作が定義されている。

Modal Dialog: フォーカストラップを実装
Navigation Menubar: フォーカスは自由に移動可能

APG のコードを見ると、モーダル系の UI はフォーカストラップを実装していて、メニューバー系はフォーカスの移動制限をしていない。

分かったこと・所感

モーダル系（背後を操作させない UI）はフォーカストラップを実装する
メニュー系（背後も操作可能な UI）はフォーカスが外れたら閉じる実装が多い
inert 属性を使うと背後のコンテンツを完全に不活性化できる
<dialog> 要素はフォーカストラップを標準で実装してるのでモーダルが楽

参考記事

CSS scroll-state() を試してみる

Sun, 23 Nov 2025 00:00:00 GMT

概要

Chrome 131 で実装された CSS scroll-state() を使い、スクロール位置に応じたスタイリングを試してみた。

scroll-state() とは

CSS でスクロール状態をクエリできる機能。 @container と組み合わせて要素のスクロール状態に応じたスタイリングができる。

検出できる状態は主に3つ：

stuck - 要素が sticky 状態かどうか
snapped - スクロールスナップ位置に停止しているか
scrollable - スクロール可能な状態か（縦横や両方向を指定可能）

container-type: scroll-state は position: sticky を持つ要素自体に設定する。

.header-wrapper {
  position: sticky;
  top: 0;
  container-type: scroll-state;
}

@container scroll-state(stuck: top) {
  .header {
    background: tomato;
  }
}

ブラウザ対応状況

Chrome 131 以降でサポート。Safari と Firefox は現状未サポート。
参考：MDN - コンテナースクロール状態クエリーの使用
 Can I use...

デモ

デモでは次のパターンを試した：

stuck - ヘッダーがスティッキー状態でスタイル変更
snapped - スナップしたカードの強調表示
scrollable - スクロール可能/不可能の状態表示

分かったこと・所感

Intersection Observer や scroll イベントを JS で書いていた処理が CSS だけで実現できる
stuck はスティッキーヘッダーのシャドウ表示など定番パターンがシンプルに実装できる
snapped はカルーセルやスクロールスナップ UI で現在アクティブな要素を視覚的に示すのに使える
container-type: scroll-state は position: sticky を持つ要素自体に設定する（子要素ではない）
Chrome 131 以降で動作するが他ブラウザは未対応
Scroll-driven Animations と併用するとより高度なスクロール連動 UI が作れそう

参考記事

prefers-reduced-motion で制御する/しないアニメーション

Wed, 07 May 2025 00:00:00 GMT

概要

CSSの prefers-reduced-motion メディアクエリを使う際のアニメーション制御のポイントを考えてみた。

prefers-reduced-motionとは

prefers-reduced-motion はユーザーが「動きを減らす」とOS等で設定したかどうかを検出するメディアクエリ。
CSS（ @media (prefers-reduced-motion: reduce) ）やJavaScript（ window.matchMedia('(prefers-reduced-motion: reduce)') ）で検出可能。

前庭障害や偏頭痛で大きく動くアニメーションによるめまいや吐き気を感じる方がいるため、WCAG 2.1 2.3.3（AAA）でも機能や情報伝達に必須でないアニメーションをオフにできるよう求められている。

OSごとの設定項目

macOS
- 設定 > アクセシビリティ > ディスプレイ > 視差効果を減らす
iOS
- 設定 > アクセシビリティ > 動作 > 視差効果を減らす
Windows（MDN による）
- 設定 > 簡単操作 > ディスプレイ > アニメーションを表示する
Android（MDN による）
- 設定 > ユーザー補助 > アニメーションの削除

その他ブラウザ、各アプリケーション内での設定が可能でそれらが反映されることもある。

実装アプローチ

1. 基本的に全て消す（完全無効化）

:root {
  --transition-duration: 0.2s;

  @media (prefers-reduced-motion: reduce) {
    --transition-duration: 0s;
  }
}

2. 代替アニメーションに置き換え

大きい動きをフェードやディゾルブなどのシンプルなエフェクトに変更する

.box {
  animation: bounce 1s infinite;
}

@media (prefers-reduced-motion: reduce) {
  .box {
    animation: fade 0.5s both;
  }
}

3. カスタムトグルを用意

OS設定に加えサイト独自のトグルUIで切り替えを行う。
Smashing Magazine の記事では Animal Crossing 公式サイトの例が紹介されており、このサイトではトグルUIのON/OFFで代替アニメーションを切り替えている。

制御する/しないアニメーション

残すべき（機能的）
- ローディングのインジケーター
- 状態変化のトランジション
削るべき（装飾的）
- ループするオブジェクトアニメーション
- パララックススクロール

所感

ユーザーのプリファレンスに応じて過度なアニメーションを無効にする「prefers-reduced-motion」 | Accessible & Usable にある通り、「必要であれば保険的」程度のものと考える。
そのうえで、

主に自分が実装するときに 1. の完全無効化を選択しがちだが、本質的には代替のアニメーションを行うほうが良い気もしてくる
ブランディング的な観点での折り合いも考え所で、ニュアンスを残しつつ代替を提示するのが正解の場合もあるかもしれない
macOS/iOS と比べて Windows/Android の設定は、動きが全くなくなるという言葉のニュアンスなのでユーザーからするとその違いも捉え方が変わってくるのでは
Xを検索すると、iPhoneのバッテリー省エネ方法として「視差効果を減らす」のオンが紹介されているため、無意識的に設定している人も少なからずいそう