Web Platform Baselineとは？対応ブラウザと確認方法・ビルドへの組み込み手順

Web Platform Baseline（ウェブプラットフォーム・ベースライン、以下Baseline）とは、主要ブラウザで安全に使えるWeb機能を「相互運用が取れている基準」として示す仕組みです。ある機能がChrome・Edge・Firefox・Safariのすべてで使えるようになったか、そしてそれが十分に枯れているかを、開発者が一目で判断できるように状態化しています。定義と判定データはW3CのWebDX Community Groupが管理するweb-featuresで公開されています。判定結果が表示されるのは、MDN・Can I Use・web.devといった、開発者が実装を決める場所です。この記事では、状態ごとの正確な判定条件と対象ブラウザを一次情報で整理し、機能ごとの確認方法、主要CSS機能の実際の状態、そしてbrowserslist・ESLint・Stylelintへ組み込む設定までを、コピーして使える形で解説します。

まとめ｜Web Platform Baselineの判定条件と開発での使い方の要点

• Baselineは機能の「相互運用の到達度」を示す指標。状態はLimited availability → Newly available → Widely availableの3つで、このうちBaselineと呼ぶのはNewly／Widelyの2状態。俗に言われる「Baseline Included」という段階は存在しない。
• Newly availableは、7つのコアブラウザ環境の現行安定版がすべて対応した状態。最後に対応したブラウザのリリース日が起点になる。
• Widely availableは、その起点から30か月が過ぎ、Firefox ESRの条件も満たした状態。多くのサイトで特別な対策なしに使える目安。
• 機能の状態はMDN・Can I Use・webstatus.devで確認でき、機械可読データのweb-features（2026年10月時点で3.42系）をNode.jsから直接読める。
• 開発に組み込むなら、browserslist 4.29系の標準クエリbaseline widely available、@eslint/cssのuse-baseline、stylelint-plugin-use-baselineで判定を自動化できる。Vite 8系は既定のビルド対象がすでにBaseline基準になっている。

判断の初期値はWidely availableに置きます。Newly availableへ引き上げるのは、訪問者のブラウザ分布を実データで確認できたときだけ、というのがこの記事の結論です。

Web Platform Baselineの意味と運営主体｜WebDX CGが定める基準線

Web技術には毎年新しいCSSプロパティやJavaScript APIが追加されますが、それらが全ブラウザで同時に使えるようになるわけではありません。従来はCan I UseやMDNの対応表を機能ごとに引き、「この機能はどこまで使えるか」を都度調べる必要がありました。Baselineは、この判断を「安全に使える基準に達したか」という1つの状態に集約したものです。基準を満たした機能だけを選べば、ブラウザ差異の調査コストを大きく減らせます。

「baseline」の意味とWebDX Community Groupによる管理体制

ここでのbaselineは「基準線」の意味で、主要ブラウザが共通してサポートし、相互運用が取れた機能の集合を指します。判定ルールはweb-featuresリポジトリのdocs/baseline.mdに明文化されており、コアブラウザセットの選定やリリース、個別機能の判定上書きはWebDX CGのowners groupが決めます。Googleが起点の取り組みですが、仕様文書はベンダー横断のコミュニティグループで管理され、特定ブラウザの独自基準ではありません。「google baseline」で検索されることが多いものの、実体はブラウザ各社とドキュメント整備側の合意ベースです。

なお同文書には、状態定義そのものを2026年9月9日に見直すという期日が記されています（2026年10月時点の記載）。定義は固定ではなく、ブラウザの勢力図に合わせて変わり得るものとして読むのが正確です。

Interopプロジェクトとの関係｜相互運用を進める側と結果を示す側

Baselineが測るのは「相互運用が達成された結果」です。これに対し、複数ブラウザで挙動を揃える取り組みが毎年のInteropプロジェクトで、Interopの対象になった機能は各社が優先実装するため、Newly availableへ到達する速度が上がります。Interopが「原因」、Baselineが「結果の可視化」と整理すると分かりやすいでしょう。

Baselineの3状態｜Newly・Widely availableの判定条件と違い

Baselineの中核は、機能ごとの状態の定義にあります。「Newly Available／Widely Available／Baseline Included」の3ステージという説明を見かけますが、これは誤りです。正しくはLimited availabilityを含む次の3状態で、Baselineと呼ぶのはNewly／Widelyの2つです。

Limited availability｜コアブラウザのどれかが未対応の段階

いずれかのコアブラウザで未対応、または部分実装（MDNのデータでpartial_implementation扱い）の状態です。使うには機能検出（CSS.supports(...)や@supports、'feature' in windowなど）とフォールバックが前提になります。仕様に非推奨の記載がある機能も、ここから外れません。

Newly available｜全コアブラウザの現行安定版で対応した日が起点

コアブラウザすべての現行安定版で使えるようになった状態です。旧版の記事やまとめサイトでは「直近2メジャーバージョンで判定」と書かれることがありますが、定義文書の条件は「各コアブラウザの現行安定版が対応していること」です。最後に対応したブラウザのリリース日がkeystone dateとして記録され、これがWidely availableへの起算日になります。古い端末では動かない可能性が残るため、採用はユーザー層を見て決めます。

Widely available｜起点から30か月とESR条件を満たした段階

keystone dateから30か月が経過し、さらにFirefox ESR（延長サポート版）の最新x.0リリース日より前に対応が揃っている状態です。ESR条件があるため、30か月ちょうどで切り替わらない機能もあります。起点は「Newly availableになった日」であり、現在日や年号ラベルからの起算ではない点に注意してください。

web-features 3.42.0（2026年10月9日公開）のデータでは、1,214機能のうちWidely availableが650、Newly availableが123、Limited availabilityが441でした。Newly availableの機能は全体の1割ほどしかなく、新機能を使うかどうかの判断は実質この123件で起きます。

コアブラウザセットの7環境と年号ラベル（Baseline 2024／2025）の読み方

判定の母集団になるブラウザと、MDNなどで見かける年号付きラベルの意味を押さえます。どちらも誤解が多い箇所です。

Chrome・Edge・Firefox・Safariの4ブラウザ7環境と対象外のブラウザ

Baselineの判定基準となるブラウザ群をコアブラウザセットと呼びます。4つのブラウザ（レンダリングエンジンはBlink／Gecko／WebKitの3種。ChromeとEdgeはともにBlink）を、デスクトップとモバイルの組み合わせで扱い、合計7環境で評価します。

Samsung Internet・Opera・アプリ内WebViewは対象外です。Edge for Android／iOSも含まれません。Firefoxが1環境だけ未対応のままLimitedにとどまる機能も多いため、Firefoxのリリース動向は到達時期の予測に直結します。たとえばWebGPUはweb-features 3.42.0でもLimited availabilityのままで、判定を左右しているのはFirefoxの対応範囲です。直近の変更点はFirefox 147の新機能と変更点｜WebGPU・XDG対応と147.0.4までの修正・脆弱性で確認できます。

Baseline 2025など年号ラベルは到達年で固定される機能セット

MDNやweb.devでは「Baseline 2024」「Baseline 2025」といった年号付きラベルを見かけます。これはその年にNewly availableへ到達した機能群を指し、確定すると中身が変わらない「固定ターゲット」です。一方でWidely availableは30か月で対象が入れ替わる「移動ターゲット」になります。web-features 3.42.0では、Newly availableへの到達年が2024年の機能が53件、2025年が36件、2026年（10月時点）が46件でした。「対応環境を2024年基準で揃える」といった意思決定には、この固定ターゲットが向いています。

機能のBaselineステータスを確認する手順｜MDNとwebstatus.dev

個々の機能がどの状態かは、開発者が普段見る場所に表示されます。「baseline status」「mdn baseline」「baseline css」といった検索で求められるのは、この確認手段です。用途ごとに4つを使い分けます。

MDN・Can I Useのバッジで1機能の状態と到達日を確認する方法

MDN Web Docsの各機能ページ上部と、Can I Useの機能ページにはBaselineバッジが表示されます。「Widely available」「Newly available」「Limited availability」のいずれか、到達日、コアブラウザの最小対応バージョンが一目で分かります。特定の1機能を調べるならこれが最短です。

webstatus.devで状態・年号を条件に複数機能を横断検索する方法

webstatus.dev（Web Platform Status）は、web-featuresの全機能をBaseline状態や到達年で絞り込めるダッシュボードです。検索欄にbaseline_status:newlyと入れればNewly availableの機能だけが並び、URLのクエリにも同じ条件が残るので、チームへの共有にも使えます。「2025年にNewly availableになった機能を一覧したい」といった、複数機能をまとめて調べる用途に向きます。

web-featuresのデータをNode.jsで読み状態を一覧化するコード

自社で使っている機能の状態を定期的に棚卸しするなら、データを直接読むのが確実です。web-featuresの公式READMEにあるfeaturesオブジェクトを使い、状態と到達日を表示します。

// baseline-report.mjs（npm i web-features 後に node baseline-report.mjs）
import { features } from "web-features";

const ids = ["container-queries", "has", "nesting", "popover", "view-transitions", "anchor-positioning"];
const label = { high: "Widely", low: "Newly", false: "Limited" };

for (const id of ids) {
  const f = features[id];
  if (!f || f.kind !== "feature") {
    console.log(id, "未定義、または別IDへ移動・分割済み");
    continue;
  }
  const { baseline, baseline_low_date, baseline_high_date } = f.status;
  console.log(id.padEnd(20), label[baseline].padEnd(8), baseline_low_date ?? "-", baseline_high_date ?? "-");
}

kindの確認は省かないでください。web-featuresでは機能IDの改名や分割があり、そのとき値は"moved"または"split"のリダイレクトになります。3.42.0では1,226件のうち12件がこの形でした。

<baseline-status>で社内ドキュメントに状態を埋め込む手順

社内ドキュメントや技術記事に最新のBaseline状態を自動表示したい場合は、公式の<baseline-status> Webコンポーネント（2026年10月時点で1.2系）が使えます。featureIdに機能IDを指定するだけで、状態バッジが動的に描画されます。

<script src="https://cdn.jsdelivr.net/npm/baseline-status@1/baseline-status.min.js" type="module"></script>
<baseline-status featureId="container-queries"></baseline-status>

機能IDは前節のコードと同じweb-featuresのキーです。npmでnpm install baseline-statusとして組み込むこともできます。

主要CSS機能のBaseline状態一覧｜web-features 3.42の実データ

「この機能はもう使ってよいか」という問いに、2026年10月時点のデータで答えます。Widely availableへの切り替え見込み日は、keystone dateに30か月を足した最短日です（ESR条件で後ろにずれる場合があります）。

:has()とCSSネストは2026年6月にWidely availableへ移りました。Widely基準のプロジェクトでも、2026年後半からはフォールバックなしで書ける機能です。構文とコンポーネント単位での使い方はコンテナクエリ（@container）の使い方｜container-typeとcqi単位、メディアクエリとの違いにまとめています。

一方、View TransitionsはFirefox 144の対応でNewly availableに入ったばかりです。Invoker Commandsも同じ段階で、ボタンからポップオーバーやダイアログを宣言的に開く使い方はInvoker Commands APIの使い方と対応ブラウザで扱っています。Widely基準のプロジェクトでこれらを使うなら、@supportsや機能検出で囲む前提になります。

ビルドとLintにBaselineを組み込む手順｜browserslistとCSS検査

Baselineは「読んで確認する」だけでなく、ビルドやLintに組み込んで自動でチェックできます。手作業でCan I Useを引く運用との決定的な差は、Baseline外の機能をうっかり使ったときに機械が警告してくれる点です。

browserslist 4.29系の標準クエリでBaselineを対象に指定する方法

Babel・Autoprefixer・PostCSSなど多くのツールはBrowserslistの対象ブラウザ指定を読み込みます。Browserslist本体は、追加パッケージなしでBaseline系のクエリを解釈します（2026年10月時点の最新は4.29.3）。

# .browserslistrc
baseline widely available

# 指定例（いずれか1行を使う）
# baseline newly available
# baseline 2024
# baseline widely available on 2026-01-01
# baseline widely available with downstream

npx browserslist "baseline widely available"を実行すると、クエリが展開された具体的なブラウザ版の一覧を確認できます。with downstreamを付けると、Samsung InternetやOperaなどChromium・Gecko系の派生ブラウザも、エンジン版から逆算して対象に加わります。

Viteを使っているなら、設定を書く前に既定値を確認してください。Vite公式のbuild.targetの既定は'baseline-widely-available'で、Vite 8系では2026-01-01時点のWidely availableに相当するchrome111・firefox114・safari16.4などに固定されています。Vite自体の構成はViteとは？Reactの環境構築手順とVite 8の変更点で解説しています。

browserslist-config-baselineで年号の基準を固定する方法

共有設定としてbrowserslist-config-baseline（0.5系）を使う方法もあります。extendsの末尾に年を付けると、その年末時点の機能セットに固定できます。

{
  "browserslist": [
    "extends browserslist-config-baseline/2024"
  ]
}

Chromium派生ブラウザも含めるならextends browserslist-config-baseline/with-downstream/2024と書きます。新規プロジェクトでは前節の標準クエリで足ります。こちらはwidelyAvailableOnDateなどの細かな設定をpackage.jsonに残したい場合の選択肢です。

@eslint/cssのuse-baselineでBaseline外CSSを検出する設定

ESLint公式のCSSプラグイン@eslint/css（2026年10月時点で2.0系）にはcss/use-baselineルールがあります。availableの既定は"widely"で、"newly"または2023のような年号も指定できます。

// eslint.config.js
import css from "@eslint/css";

export default [
  {
    files: ["**/*.css"],
    plugins: { css },
    language: "css/css",
    rules: {
      "css/use-baseline": ["error", { available: "widely" }]
    }
  }
];

特定の機能だけ例外にするにはallowAtRules・allowFunctionsなどの配列オプションを使います。flat configの基本はESLintとは？VSCodeでの設定からflat config・Prettier連携まで解説を参照してください。

stylelint-plugin-use-baselineをStylelintへ追加

Stylelintを使っているなら、stylelint-plugin-use-baseline（1.4系）が同等の検出を行います。データ元はweb-featuresで、@supportsで囲んだ記述は警告の対象外です。逆に、すでにWidely availableの機能を@supportsで囲んでいると「不要な分岐」として指摘してくれます。

// stylelint.config.js
export default {
  plugins: ["stylelint-plugin-use-baseline"],
  rules: {
    "plugin/use-baseline": [true, { available: "newly", severity: "warning" }]
  }
};

READMEでも推奨されているとおり、導入初期はwarningで入れ、既存CSSの指摘件数を把握してからerrorへ上げる順番が安全です。

Baselineターゲットの決め方｜Widely availableを初期値にする判断基準

ツールに何を設定するかは、最後は自社サイトの事情で決まります。ここでは判断を言い切ります。初期値はWidely available、引き上げは実データがある場合だけです。

自社訪問者のブラウザ分布でNewly availableへ引き上げる条件

Widely available一択にすると新機能の採用が遅れ、Newly availableに寄せると一部ユーザーで動かないリスクが出ます。web.devのHow to choose your Baseline target（2025年5月公開）は、Google Analytics Baseline CheckerやRUMvisionで自サイト訪問者の何%がその基準を満たすかを測り、Can I Useのアナリティクス取り込みで個別機能まで掘り下げる手順を示しています。

引き上げてよいのは、訪問者の大半が自動更新されるブラウザで、Newly availableの機能が動かない層が少数だと数字で確認できた場合です。GA4のデータからブラウザ版の分布を取り出し、ターゲットを決める作業はWebコンサルティング・アクセス解析の範囲で支援しています。

Baselineを採用基準にしない場面｜社内端末固定・WebView・部分実装

次の場面では、状態だけを見て採用を決めると事故になります。優先度の高い順に並べます。

• 業務端末のブラウザが固定されている社内システム：Baselineは現行安定版が前提です。更新が止まった端末が残るなら、Widely availableでも実機検証が要ります。この場合はBaselineではなく、実在する端末の版を直接Browserslistに書きます。
• アプリ内WebViewや派生ブラウザの比率が高いサイト：コアブラウザセットの外です。with downstreamで近似できますが、WebViewの版は端末側の更新に依存します。
• 機能の一部オプションに依存する実装：Baselineは機能単位の判定です。同じ機能でも細かな値や組み合わせにはブラウザ差が残ることがあるため、挙動の要になる箇所は実機テストで裏を取ります。
• 支援技術での動作：定義文書の対象外です。スクリーンリーダーでの読み上げはBaselineでは保証されません。

デザイン面から新しいCSS表現を取り入れる判断は、Webデザイントレンド2026｜注目の10様式とCSS対応状況・取り入れる判断基準でBaselineの状態と合わせて整理しています。

Web Platform Baselineの対応ブラウザと確認方法についてよくある質問

検索の多い5つの質問に、短く答えます。

Web Platform Baselineの「意味」を一言で言うと？

主要ブラウザで安全に使えるWeb機能の基準です。ある機能がChrome・Edge・Firefox・Safariの7環境すべてで相互運用可能になったか、さらに十分に枯れているかを、Limited／Newly／Widelyの3状態で示します。判定データはweb-featuresとして公開され、MDNやCan I Useのバッジもこのデータを表示しています。

Newly availableとWidely availableの違いは？

Newly availableは全コアブラウザの現行安定版で使えるようになった状態です。Widely availableはそこから30か月が経過し、Firefox ESRの条件も満たした状態を指します。古い環境も含めて広く動くのはWidely availableなので、本番で無難に使うならこちらが目安です。

Baselineはどのブラウザを対象にしていますか？

Chrome（デスクトップ／Android）、Edge（デスクトップ）、Firefox（デスクトップ／Android）、Safari（macOS／iOS）の4ブラウザ・7環境です。各ブラウザの現行安定版の対応状況で判定します。Samsung InternetやOpera、アプリ内WebViewは対象外のため、利用者が多い場合は別途確認してください。

browserslistでBaselineを指定するには？

Browserslist本体がbaseline widely availableやbaseline 2024といったクエリを標準で解釈するので、.browserslistrcに1行書くだけで済みます。派生ブラウザも含めるなら末尾にwith downstreamを付けます。Vite 8系は既定のビルド対象がすでにWidely available基準です。

「Baseline 2024」「Baseline 2025」とは何ですか？

その年にNewly availableへ到達した機能群を指す固定ラベルです。中身は後から変わりません。2026年10月時点では、Baseline 2025が直近の完了セットで、Baseline 2026が進行中です。対応環境を年単位で揃えたいときの指定に使えます。

関連記事

• コンテナクエリ（@container）の使い方｜container-typeとcqi単位、メディアクエリとの違い：Widely availableに到達したレイアウト機能の実装
• Invokerとは？Invoker Commands APIの使い方と対応ブラウザ、HTTP Invokerとの違い：Newly availableに入ったばかりのAPIの使い方
• ESLintとは？VSCodeでの設定からflat config・Prettier連携まで解説【ESLint v10対応】：use-baselineルールを載せるESLint設定の基本
• ARIA Notify（ariaNotify()）の使い方：aria-liveとの違い・priorityの指定と対応ブラウザ：対応ブラウザが揃う前の新APIの扱い方
• Firefox 147の新機能と変更点｜WebGPU・XDG対応と147.0.4までの修正・脆弱性：Baseline到達を左右するFirefoxの更新内容