yuheijotaki.com

Claude Code Action で PR を自動レビューしてみる

Tue, 19 May 2026 00:00:00 GMT

概要

このリポジトリに anthropics/claude-code-action を導入して、PR の自動レビューと @claude メンションへの応答が動くようにしてみる。

2 つのワークフローの役割

.github/workflows/ に 2 つのワークフローを置く。

claude.yml
- Issue / PR / レビューコメントの本文に @claude を含む投稿があったとき
claude-code-review.yml
- PR が opened / synchronize されたとき

paths フィルタで対象を絞る

pull_request の paths で、コードとビルド系の変更だけに絞る。

paths:
  - 'src/**'
  - 'api/**'
  - 'astro.config.mjs'
  - 'package.json'
  - 'package-lock.json'
  - 'tsconfig.json'
  - 'eslint.config.mjs'
  - 'playwright.config.ts'
  - '.github/workflows/**'

動作確認

それぞれテスト用に Issue / PR を作って動かしてみた。

@claude メンション:
- 本文に @claude を含む Issue #7 を立てると claude.yml がトリガーされ、コメントが返ってきた
PR 自動レビュー:
- コメント 1 行を追加した PR #8 を作って、claude-code-review.yml が走り PR コメントで指摘が返ってきた

実行コスト

claude-code-action はジョブの末尾に実行結果を JSON 形式で出力する。動作確認用 PR（src/pages/index.astro にコメント 1 行追加だけ）でのレビュー 1 回の実測値を、デフォルトの Opus 4.7 と、claude_args に --model claude-sonnet-4-6 を渡して指定した Sonnet 4.6 で比較した。

項目	Opus 4.7	Sonnet 4.6
Duration	約 76 秒	約 59 秒
Turns	13	11
Total cost	$0.37	$0.17

Anthropic API は入力トークン / 出力トークン / プロンプトキャッシュの読み書きそれぞれに単価が設定されていて、消費したトークン量 × モデルの単価で課金される（料金 - Claude API Docs）。

claude-code-action は 1 回の起動の中で複数回 API リクエストを走らせる（Opus 4.7 は 13 turns、Sonnet 4.6 は 11 turns）ので、total_cost_usd はそれらの合計値。同じく 1 行追加だけの PR でも、Sonnet 4.6 に切り替えるとレビュー 1 回あたり半分以下のコストに収まった。

所感

CLAUDE.md にコーディング規約・コミット規約を書いておけば、レビューでもその文脈を踏まえた指摘が返ってくるのは便利だがコストとの兼ね合いかな。

Astro Fonts API を試してみる

Fri, 15 May 2026 00:00:00 GMT

Astro Fonts API とは

astro.config.mjs の fonts 配列でフォントを宣言し、<Font /> コンポーネントを <head> に置くと @font-face と preload link が出力される。

取得したフォントはローカル化されて、fallback フォントもメトリクス込みで自動生成される。組み込みプロバイダーは adobe / bunny / fontshare / fontsource / google / googleicons / local / npm の 8 種。

今回は Google プロバイダーで Noto Sans JP を読み込んで、生成される <head> と日本語フォントのサブセットがどう扱われるかを見ていく。動作確認は astro@6.3.3。

設定

import { defineConfig, fontProviders } from 'astro/config';

export default defineConfig({
  fonts: [
    {
      provider: fontProviders.google(),
      name: 'Noto Sans JP',
      cssVariable: '--font-noto-sans-jp',
      weights: [400, 700],
      subsets: ['japanese'],
    },
  ],
});

<head> 側：

---
import { Font } from 'astro:assets';
---

<Font cssVariable="--font-noto-sans-jp" preload />

生成された出力

npm run build 後の dist/client/_astro/fonts/ を見ると、woff2 が 120 ファイル / 合計 5.2 MB。weights 2 種 × unicode-range で 60 分割されている計算で各ファイルは 12〜88KB。

<head> には unicode-range 付きの @font-face が並ぶ。

<style>
  @font-face {
    font-family: 'Noto Sans JP-86c17494f12e7c6c';
    src: url('/_astro/fonts/5bcf9a2144f25cf1.woff2') format('woff2');
    font-display: swap;
    unicode-range: U+25ee8, U+25f23, U+25f5c, U+25fd4, /* ... 多数 ... */;
    font-weight: 400;
    font-style: normal;
  }
  /* ...同じ要領で 120 個続く... */
</style>

font-family 名にハッシュのサフィックスが付いて、同じファミリー名が複数の <Font /> 設定で衝突しないようになっている。

fallback も自動で出力される。

@font-face {
  font-family: 'Noto Sans JP-86c17494f12e7c6c fallback: Arial';
  src: local('Arial');
  font-display: swap;
  size-adjust: 197.1733%;
  ascent-override: 58.8315%;
  descent-override: 14.6064%;
  line-gap-override: 0%;
}

src: local('Arial') でローカルにある Arial を使い、size-adjust と ascent-override 等でメトリクスを Noto Sans JP に合わせて、ロード前後の見た目のズレを抑えてくれる。

preload link は <Font preload /> のままだと 120 個ぜんぶ に <link rel="preload"> が並ぶ。日本語のように分割数が多いフォントではここを絞らないと過剰。

内部の挙動

preload プロパティは boolean だけでなく filter を渡せる。filter-preloads.ts を読むと、weight / style / subset で絞り込めるのが分かる。

<details> <summary>コードを開閉する</summary>

export function filterPreloads(
  data: Array<PreloadData>,
  preload: PreloadFilter,
): Array<PreloadData> | null {
  if (!preload) {
    return null;
  }
  if (preload === true) {
    return data;
  }
  return data.filter(({ weight, style, subset }) =>
    preload.some((p) => {
      if (
        p.weight !== undefined &&
        weight !== undefined &&
        !checkWeight(p.weight.toString(), weight)
      ) {
        return false;
      }
      if (p.style !== undefined && p.style !== style) {
        return false;
      }
      if (p.subset !== undefined && p.subset !== subset) {
        return false;
      }
      return true;
    }),
  );
}

</details>

<Font preload={[{ weight: 400, subset: 'japanese' }]} /> のように書くと、特定の組み合わせだけに preload を絞れる。日本語フォントでは全 chunk を preload するのは過剰なので、こうした filter で絞る前提になりそう。

日本語フォントとサブセット

Noto Sans JP のフルセットは数 MB あって、何の工夫もなしに読ませると重い。Google プロバイダーで subsets: ['japanese'] を指定した場合、Google Fonts の CSS2 API がそもそも unicode-range で 60 分割した CSS を返してくる。Astro はそれをそのまま読んで、各 chunk の woff2 をローカルへコピーしている。つまり、Astro 自身が分割しているわけではなく、Google 側の分割をそのまま使っているということ。ブラウザは表示する文字に応じて必要な chunk だけ取りに行く動きになる。

所感

同一オリジンから配信してくれる、且つサブセット分割なども処理されるので、要件でリソースはセルフホストが必要な場合などに使えそう。

WCAG 1.4.13 からホバーUIを考える

Mon, 11 May 2026 00:00:00 GMT

概要

WCAG 2.2 の達成基準 1.4.13 ホバー又はフォーカスで表示されるコンテンツについて、ホバーUIを実装するときに何を気にすべきか考えてみる。

アクセシビリティの文脈で「なるべくホバーは使わないほうがよい」と聞くことがあるが、ホバー自体が禁止されているというより、ホバーしないと情報が得られない、またはホバーで出た情報をうまく扱えない状態が問題になる認識。

WCAG 1.4.13 とは

ポインタホバー、またはキーボードフォーカスによって追加コンテンツが表示される場合の達成基準。

対象になるものは次のようなUI。

サブメニュー、メガメニュー
ツールチップ
ホバー時にだけ表示されるカード内の詳細情報

逆に、ボタンの背景色が変わるなど追加コンテンツが表示されない単なる視覚的フィードバックは、この達成基準の主な対象ではない。

3つの要件

WCAG 1.4.13 では大きく3つの要件が示されている。

非表示にできる（Dismissible）

追加コンテンツが他のコンテンツを覆う場合、ポインタやフォーカスを動かさずに非表示にできる必要がある。

実装としては Esc キーで閉じられるようにするのが分かりやすい。特に拡大表示している場合、画面内に見えている範囲が狭くなるため、ホバーで出たコンテンツが邪魔になってもマウスを動かすと再度表示される、という状態が起こる。

ホバーできる（Hoverable）

ホバーで出た追加コンテンツに対して、その追加コンテンツ上へポインタを移動できる必要がある。

例えばツールチップが大きい場合や、マウスカーソルを大きくしている場合、ポインタ自体がコンテンツを隠してしまうことがある。そのときにトリガー要素から追加コンテンツへポインタを移動できないと、内容を確認できない。

CSSだけで実装する場合、トリガーと追加コンテンツの間に隙間があると、移動中に :hover が外れて消えてしまうので注意が必要。

表示が継続される（Persistent）

追加コンテンツは、ホバーやフォーカスが外れる、ユーザーが閉じる、または内容が無効になるまで表示され続ける必要がある。

一定時間で勝手に消えるツールチップなどは避ける。読む速度や拡大表示、ポインタ操作の正確さはユーザーによって異なるため、表示時間を実装側で短く決めてしまうのは危うい。

他社ガイドラインの例

Ameba Accessibility Guidelines でも、画面を拡大して閲覧している場合に追加コンテンツを知覚できなかったり、閲覧中のコンテンツが覆い隠されたりする例が挙げられている。ホバーUIは、見えている範囲やポインタ操作のしやすさによって使いやすさが大きく変わる。

SmartHR Design System の Tooltip では、Tooltip はユーザーが能動的に表示しなければならないことや、拡大表示時に領域外に表示される課題があるため、安易な使用は勧められていない。操作に必要な情報は Tooltip ではなく常に表示すること、モバイルでは Tooltip を使わないことも示されている。

ホバーUIの扱い方

自分の中では「ホバーを使わない」というより「ホバーでしか成立しない情報設計を避ける」と考えるのがしっくりきた。実装可否よりも、情報の重要度や表示される文脈で判断するのがよい。

避けたほうがよいもの。

フォームの入力要件やエラーメッセージをホバー時にだけ表示する
ホバーで表示された中に操作ボタンやリンクがある
拡大表示時に画面の大部分を覆う
ポインタを少し動かしただけで消える

使ってもよいもの。

すでに本文やラベルで分かる情報の補足
アイコンだけのボタンに対する補助的なラベル
省略されたテキストの全文表示
フォーカス、クリック、タップでも同じ内容にアクセスでき、Esc など閉じる操作が用意されている

ホバーはPCでは自然な操作だが、キーボードやタッチでは別の操作になる。なので、ホバーを入口にする場合でも、フォーカスやクリックでも同じ状態にできるようにしておくのが基本になる。

所感

:hover だけで表示するのではなく、:focus や :focus-within、クリック/タップでも同じ内容にアクセスできるようにする
追加コンテンツを読ませたい場合は、pointer-events: none; にせず、トリガーから追加コンテンツ上へポインタを移動できる構造にする
重要な情報は最初から表示するか、明示的に開けるUIにする

参考

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 の項目を対応しないという判断もある