Web制作やフロントエンド開発を外注する際、RFP（提案依頼書）や要件定義書にCSS3まわりをどう書けばよいのか——多くの発注担当者がここでつまずきます。デザインのイメージは伝えられても、「対応ブラウザはどこまで」「表示速度はどの水準で」「アクセシビリティはどう担保するか」といった非機能要件を言語化できず、結果として見積もりがブレたり、納品後に「思っていたものと違う」というトラブルが起きたりします。本記事は、CSS3に関わる技術選定・採用要件をRFPや要件定義書にどう落とし込むかを、発注側視点で具体的に解説する記事です。
対応端末・ブラウザの定め方、Lighthouseスコアの基準点、WCAGのどこまでを満たすか、CSS設計手法（Tailwindかネイティブか）の指定の是非、検収基準の作り方まで、テンプレート的に使える観点を網羅します。これは競合記事が最も手薄にしている領域であり、ここを押さえるだけで発注の質が大きく変わります。なお、CSS3の全体像をまだ把握していない方は、まずCSS3開発の完全ガイドから読むことをおすすめします。
対応ブラウザ・端末をどう定義するか
CSS3の要件定義で最初に決めるべきは「どのブラウザ・端末まで保証するか」です。これが曖昧だと、ベンダーは「最も古い環境まで対応する」前提で過剰に見積もるか、逆に「最新だけ」で作って後からクレームになるか、どちらかのリスクを抱えます。対応範囲は、CSS3で使える機能の選択肢を大きく左右する根幹の要件です。
Baselineを基準に対応範囲を明記する
近年は「Baseline」という業界共通の指標が整備され、対応範囲の議論が格段に楽になりました。Baselineは、ある機能が主要ブラウザ（Chrome・Edge・Firefox・Safari）で安定して使えるかを示す指標で、「Newly available（新たに利用可能）」と「Widely available（広く利用可能）」の2段階があります。要件定義書には「Baseline Widely availableの機能を標準採用とし、それ未満の機能を使う場合は代替表示を用意する」と書くだけで、技術選定の前提が明確になります。
たとえばコンテナクエリやカスケードレイヤー、`:has()`、サブグリッドはいずれも2022〜2026年にBaselineへ到達しており、現在の標準的な案件であれば安心して採用できます。逆に、業務システムで古いブラウザの利用が残る企業では、「Internet Explorerの後継環境を含むか」などを明記する必要があります。対応範囲を1段階広げるごとに工数と検証コストが増えるため、ビジネス上の必要性とのバランスで決めるのが正解です。
端末・画面サイズのサポートマトリクスを作る
ブラウザと並んで重要なのが、対応する端末と画面サイズです。「スマホ・タブレット・PCに対応」とだけ書くと範囲が曖昧なため、代表的な画面幅（例：375px／768px／1280px）と縦横比を明示したサポートマトリクスを作るのが実務的です。これにより、レスポンシブ対応の検証範囲が明確になり、検収時の「この端末で崩れている」という水掛け論を防げます。
近年はコンテナクエリの登場により、画面サイズだけでなくコンポーネントの配置場所による表示最適化も可能になりました。要件としては「主要な代表画面幅で崩れないこと」を最低ラインとし、可能であれば「コンポーネント単位のレスポンシブ対応」を推奨要件として加えると、長期保守に強い設計を引き出せます。
表示速度・パフォーマンス要件の定量化
表示速度は、ユーザー体験とSEOの両方に直結する最重要の非機能要件です。しかし「速いサイトにしてほしい」という主観的な表現では検収できません。CSS3はレイアウトやアニメーションを通じて描画パフォーマンスに大きく関わるため、定量的な基準を要件に組み込むことが欠かせません。
Lighthouse・Core Web Vitalsで基準点を定める
表示速度の要件は、GoogleのLighthouseスコアやCore Web Vitalsという業界標準の指標で定めるのが実務的です。たとえば「Lighthouseのパフォーマンススコアをモバイルで80点以上」「LCP（最大コンテンツ描画時間）を2.5秒以内」「CLS（レイアウトのずれ）を0.1未満」といった具体的な数値を検収基準に書きます。これにより、誰が測っても同じ結果が出る客観的な合否判定が可能になります。
CSS3はこれらの指標に直接影響します。特にCLS（レイアウトのずれ）は、Webフォントの読み込みや画像のサイズ未指定によって悪化しやすく、CSS3レベルのチューニング（`font-display`の指定、`aspect-ratio`による領域確保など）で改善できます。要件にこれらの数値を明記しておけば、ベンダーは設計段階からパフォーマンスを意識せざるを得ず、納品後の「重い」というトラブルを未然に防げます。
CSSの軽量化方針を要件に含める
パフォーマンス要件には、CSSそのものの軽量化方針も含めると効果的です。具体的には「未使用CSSの削除（パージ）」「クリティカルCSSの優先読み込み」「JavaScriptで実現していた動きの可能な範囲でのCSS化」といった方針を求めます。Tailwind CSSのようなユーティリティ系を使う場合、本番ビルドで未使用クラスが削除される仕組みがあるため、最終的なCSSサイズを小さく保てます。
ここで注意したいのは、これらの実装手段を細かく指定しすぎないことです。要件には「LCP2.5秒以内」のような結果目標を書き、達成手段はベンダーの裁量に委ねるのが理想です。手段を縛りすぎると、より良い方法があっても採用できず、かえって品質を下げることがあります。発注側は「何を達成するか」を、ベンダーは「どう達成するか」を担うという役割分担を意識しましょう。
アクセシビリティとCSS設計手法の要件
アクセシビリティ（誰もが使える設計）は、近年ますます重視される非機能要件です。また、CSSの設計手法をどこまで指定するかも、要件定義で判断が分かれるポイントです。この2つは、発注側が「結果」を求めつつ「手段」は委ねるという原則が特に重要になる領域です。
WCAGの達成レベルを明記する
アクセシビリティの要件は、WCAG（Web Content Accessibility Guidelines）という国際標準の達成レベルで定めます。WCAGにはA・AA・AAAの3段階があり、一般的なWebサイトではAA準拠を目標にするのが現実的です。要件定義書に「WCAG 2.1 AA準拠」と書けば、達成すべき水準が明確になります。公的機関や大企業のサイトでは、AA準拠が事実上の必須になりつつあります。
CSS3はアクセシビリティに深く関わります。文字色と背景色のコントラスト比（AAでは4.5:1以上が基準）、フォーカス時の見やすい枠線表示、動きを減らす設定（`prefers-reduced-motion`）への対応などは、すべてCSSで実装します。これらを要件に含めておくことで、見た目だけでなく「誰もが使えるか」という品質を担保できます。アクセシビリティを後付けで対応すると工数が膨らむため、要件段階で明示するのが鉄則です。
Tailwindかネイティブか、CSS設計手法の指定の是非
「TailwindとネイティブCSSのどちらを使うべきか」を要件で指定すべきか、という相談はよく受けます。結論から言えば、原則は指定せずベンダーに委ねるのが賢明です。Tailwindは2025年のState of CSS調査で採用率37〜51%、週約3,100万ダウンロードと広く普及しており、複数人開発でのスピードと統一性に優れます。一方、ネイティブCSSはネスト・カスケードレイヤーの登場で大きく進化し、追加ツールなしでも保守性の高い設計が可能になりました。どちらにも合理的な選択理由があります。
発注側が指定すべきなのは手法そのものではなく、その先にある「結果」です。すなわち「属人化しない標準化された設計であること」「将来の開発者が引き継ぎやすいこと」「未使用CSSが本番で削除され軽量であること」を採用要件として求めます。特定の手法を強制すると、ベンダーの得意な技術を封じてしまい、かえって品質が下がる恐れがあります。ただし、社内に既存のデザインシステムやTailwind資産がある場合は、それとの整合性を要件に含めるのが合理的です。技術選定の基準そのものについては、後述の必勝法5軸でさらに詳しく整理します。
まとめ
CSS3まわりのRFP・要件定義で大切なのは、見た目の指定ではなく「対応ブラウザ・表示速度・アクセシビリティ」という非機能要件を測れる形で定量化することです。対応範囲はBaselineと代表画面幅で、表示速度はLighthouseとCore Web Vitalsで、アクセシビリティはWCAGのレベルで定める。これだけで見積もりのブレと検収トラブルが大きく減ります。
CSS設計手法（Tailwindかネイティブか）は原則ベンダーに委ね、「属人化回避・標準化・将来の保守容易性」を採用要件として求めるのが賢明です。「フワッとした使いやすさ」を要件にせず、結果は数値で、デザインはビジュアルで合意する。この切り分けこそが発注の質を決めます。riplaは発注前の要件整理から伴走します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。