Smashing Magazine が Advanced Tree Counting: Mathematical Layouts With sibling-index() And sibling-count()（2026-05-21）で、CSS の新しい関数 sibling-index()（自分が兄弟要素の中で何番目か）と sibling-count()（兄弟要素の総数）の実用的な使い方を解説しました。これらを calc() と組み合わせると、要素数や順番に応じた遅延（スタガー）アニメーション、段階的に変化する色・サイズ・回転、動的なグリッドや円形レイアウトの計算を、これまで JS や手書きの :nth-child(n) の羅列で実装していた処理を、CSS だけで宣言的に書けるようになりました。しかも要素が増減しても自動で追従します。
受託 Web 制作の現場では、**「リストやカードの段階的な演出・レイアウト計算を JS や大量の nth-child で実装し、要素が 1 つ増減するたびに崩れ、誰も触れない塩漬けコードになる」**という事故が繰り返されてきました。受託で Web 制作を支える立場では、これは 「派手に動かせるか」ではなく、「要素数に自動追従し、JS に頼らず、未対応ブラウザでも成立する、壊れにくい動的レイアウトを実装して引き渡せるか」を設計に組み込む課題だと捉えています。これまで モダンCSSのネイティブ機能を受託で使う（GH Media） で扱った ネイティブ機能の活用方針、2026年春のCSS新機能（GH Media） で扱った 最新仕様の動向と接続して、本記事では sibling-index() / sibling-count() を土台にした 「動的レイアウト・脱JS演出 実装支援」を 受託パッケージとして整理します。
なぜ「いま」動的レイアウトを作り直すのか
| 観点 | JS / nth-child 羅列（従来） | sibling-index 系（2026） |
|---|---|---|
| 記述 | 要素ごとに数値を手書き | 1 行の calc() で宣言 |
| 要素増減 | 都度ずれて作り直し | 自動で追従 |
| 依存 | JS バンドルが必要 | CSS 単体で完結 |
| 保守 | 誰も触れず塩漬け | 数式 1 箇所を直すだけ |
| 性能 | JS 実行・再計算が走る | ブラウザがネイティブ計算 |
| フォールバック | 未対応で崩壊しがち | 演出なしでも成立可能 |
つまり 「動く」ことと「要素が増減しても壊れず、保守でき、JS なしで成立する」ことは別物であり、受託でも 「数式で宣言し、フォールバックを用意し、保守手順を添えて引き渡す」ことが品質の前提になりました。これにより 「要素数に自動追従する壊れにくいレイアウト」を成果物として保証できます。
sibling-index() / sibling-count() でできること
sibling-index() は要素が兄弟の中で何番目か、sibling-count() は兄弟の総数を返します。これを calc() に通すだけで、要素の位置や全体数に応じた値をスタイルへ流し込めます。
/* 要素の順番に応じてアニメーション開始を 80ms ずつ遅らせる（スタガー） */
.card {
animation: fade-in 0.4s both;
animation-delay: calc(sibling-index() * 80ms);
}
/* 全体数に対する位置の割合（0〜1）で色相を段階変化させる */
.tag {
--ratio: calc(sibling-index() / sibling-count());
background: hsl(calc(var(--ratio) * 360) 70% 55%);
}① スタガー演出
animation-delay: calc(sibling-index() * 80ms) のように、順番に応じて遅延を増やすだけで、カードやリストが上から順にふわっと現れる演出になります。JS で forEach して style を当てる処理が丸ごと不要です。
② 段階的スタイル
色相・サイズ・回転・透明度などを 位置や総数の割合で連続的に変化させられます。:nth-child(1)〜:nth-child(10) を手書きしていたグラデーション的な指定が、calc() 1 行に置き換わります。
③ グリッド / 円形レイアウト計算
sibling-count() で総数を取り、各要素の角度を calc(360deg / sibling-count() * sibling-index()) で求めれば、要素を円周上に等間隔で配置できます。メニューや図解の動的配置を、要素数が変わっても自動で再計算してくれます。
受託で提供する「動的レイアウト・脱JS演出 実装支援」5 フェーズ
フェーズ 1: 棚卸し・診断（1 週間）
- 既存の JS 演出・
nth-child羅列の洗い出し - 要素増減で壊れる箇所のリストアップ
- 対応ブラウザ範囲とフォールバック要件の確認
- 成果物: 現状レポート + 置き換え候補一覧
フェーズ 2: 設計（1 週間）
- 数式（スタガー / 段階スタイル / レイアウト計算）の設計
- フォールバック方針の定義（
@supports分岐） prefers-reduced-motionなどアクセシビリティ要件の整理- 成果物: 実装仕様書 + フォールバック設計
フェーズ 3: 実装（1〜3 週間）
sibling-index()/sibling-count()ベースの置き換え実装- JS 演出コードの削減・撤去
@supportsによる未対応ブラウザ向けフォールバック- 成果物: 実装済みコンポーネント
フェーズ 4: 検証・引き渡し（1 週間）
- 要素増減テスト（0 件・1 件・大量件）
- 対応 / 未対応ブラウザでの表示確認
- 性能計測と保守手順書の整備
- 成果物: 検証レポート + 保守ドキュメント
フェーズ 5: 継続保守（継続）
- ブラウザ対応状況の定点観測
- フォールバック撤去の判断・実施
- 新規コンポーネントへの標準適用
受託向け実装標準セット
| 用途 | 推奨 | 避ける |
|---|---|---|
| スタガー演出 | calc(sibling-index() * 時間) | JS で要素ごとに style 注入 |
| 段階スタイル | 総数比 sibling-index() / sibling-count() | :nth-child(n) の長大な羅列 |
| 円形 / グリッド配置 | calc(360deg / sibling-count()) | 座標を手計算でハードコード |
| フォールバック | @supports で分岐 | 未対応を無視して崩壊 |
| 動きの抑制 | prefers-reduced-motion で停止 | 全ユーザーに強制アニメ |
| 保守 | 数式 1 箇所に集約 | 要素ごとに値を散在 |
どの案件に必要か / 不要か
| 必要な案件 | 優先度が低い案件 |
|---|---|
| 要素数が動的に増減するリスト / グリッド | 件数固定の静的な数項目 |
| CMS 連動で件数が読めないカード一覧 | 演出を一切付けない画面 |
| JS 削減・脱重量化を求める案件 | レガシーブラウザが必須要件 |
| メニュー / 図解の動的配置 | ワンオフの使い捨てページ |
| 演出コードの保守に困っている | 既に十分シンプルな実装 |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象範囲 | 置き換える演出 / 画面 | JS 撤去の範囲 |
| フォールバック | 未対応時の見え方 | 許容する劣化度 |
| 対応ブラウザ | 保証する範囲 | サポート要件 |
| アクセシビリティ | 動き抑制の対応 | prefers-reduced-motion |
| 引き渡し | 数式仕様 / 保守手順 | 保守体制 |
| 継続保守 | 対応状況の監視 | フォールバック撤去判断 |
価格モデル — 動的レイアウト実装パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 | 18 万円〜 | 1 サイト | 置き換え候補洗い出し + 設計方針 |
| 標準実装 | 70 万円〜 | 中規模 | 主要演出の置き換え + フォールバック |
| 本格対応 | 150 万円〜 | 大規模 | + 円形 / グリッド計算 + JS 全面撤去 |
| Lite 保守 | 3 万円〜 / 月 | 小規模 | 対応状況監視 + 軽微調整 |
| Standard 保守 | 9 万円〜 / 月 | 中規模 | + フォールバック撤去 + 新規適用 |
顧客側 ROI 試算（CMS 連動カード一覧を想定）
| 項目 | JS / nth-child で構築 | sibling-index 系で構築 | 差分 |
|---|---|---|---|
| JS バンドル | 演出ごとに増える | ほぼ不要 | 軽量化・表示高速化 |
| 保守工数 | 都度コード修正 | 数式 1 箇所で完結 | 保守コストの削減 |
| 要素増減への強さ | ずれて作り直し | 自動追従で無修正 | 改修費の発生抑制 |
| 演出の崩れ | 件数変化で崩壊 | 件数に自動適応 | 品質トラブルの回避 |
| 年間効果 | — | — | JS 削減 + 保守工数の圧縮 |
診断（18 万円〜）だけでも、「いまの演出コードのどこが要素増減で壊れ、どこを CSS だけに寄せられるか」を可視化できること自体に価値があります。塩漬けコードの代償は、たいてい次の改修のときにまとめて請求されます。
ハマりやすい 5 つの落とし穴
落とし穴 1: 過剰演出で全要素を派手に動かす
大量要素にスタガーをかけると重く・うるさくなります。動かす範囲と量を絞る設計にします。
落とし穴 2: 性能を測らずに本番投入する
ネイティブ計算でも要素数次第で負荷は出ます。実件数で計測してから出します。
落とし穴 3: フォールバックを用意しない
未対応ブラウザで演出が崩壊します。@supports で演出なしでも成立する形を先に作ります。
落とし穴 4: アクセシビリティを無視する
動きが苦手なユーザーに負担を強います。prefers-reduced-motion で抑制します。
落とし穴 5: 数式を要素ごとに散らかす
保守不能に逆戻りします。数式は 1 箇所に集約して引き渡します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1 | JS 演出 / nth-child 羅列の棚卸し |
| Week 2 | 数式設計 + フォールバック方針定義 |
| Week 3〜5 | 主要演出の置き換え実装 + JS 削減 |
| Week 6 | 要素増減・ブラウザ検証 + 保守手順整備 |
| Week 7〜13 | 対応状況ウォッチ + 新規コンポーネントへ展開 |
まとめ — 「JS で無理やり動かす」から「要素数に自動追従する形で引き渡す」へ
sibling-index() / sibling-count() の登場で、これまで JS や大量の nth-child で支えていたスタガー演出・段階スタイル・レイアウト計算を、CSS だけで宣言的に書けるようになりました。受託で Web 制作を支える立場では、数式で宣言し、フォールバックを用意し、保守手順を添えて引き渡す 「動的レイアウト・脱JS演出 実装支援」が、要素数に自動追従する壊れにくいレイアウトを成果物として届ける主力サービスです。配色の自動化まで含めるなら contrast-color() でアクセシブルな配色を自動化（GH Media） を併読してください。
弊社では診断 / 標準実装 / 本格対応 / Lite / Standard の各段階で本パッケージを提供しています。「いまの演出コードは要素が増えても壊れないか」「JS をどこまで減らせるか」「未対応ブラウザでも成立するか」というご相談は お問い合わせフォーム からお気軽にどうぞ。
