Baselineの「Newly available」は、主要ブラウザの最新の安定版がそろった段階にすぎない ── 2026年9月に加わった機能を使う前に確認する13項目（2026年10月時点）

目次

1. 01 何が起きたか — 2026年9月は、Baselineの「Newly available」になった機能が一度に増えた。ただし、それは「全員が使える」ではない
   1. 2026年10月2日の、web.devの月次まとめ
   2. 「Newly available」になった10の機能
   3. 表と本文が食い違う2か所
2. 02 なぜ・背景 — Baselineは「使ってよいか」の目安であって、判断の代わりではない
   1. Baselineの2つの段階
   2. 「Newly available」は、古い版や端末を含まない
   3. Baselineが測らないこと
3. 03 用語 — Baselineの言葉を先にそろえる
   1. Newly available、Widely available、Limited availability
   2. Baselineの目標（moving targetとfixed target）
   3. 機能クエリ（@supports）
4. 04 型別 — 使う前に、自社の閲覧環境と、機能が使えなかったときの形を確かめる
   1. 🅰 この記事が扱う範囲
   2. 🅱 発表とBaselineが測っていないこと
   3. 🅲 手順1: 使いたい機能の、Baselineの段階を見る
   4. 🅲 手順2: 自社の閲覧環境を、GA4で見る
   5. 🅲 手順3: Baseline Checkerで、利用者の何割が目標に入るかを見る
   6. 🅲 手順4: 動く目標か、固定の目標かを決める
   7. 🅲 手順5: 機能が使えなかったときの形を、3つに分ける
   8. 🅲 手順6: 出し分けと、代わりの見え方を決める
   9. 🅲 手順7: 実際の画面と、公式の記録で確かめる
5. 05 自分のサイトで確認するチェックリスト
6. 06 代替・他の選択肢 — 使う、待つ、出し分ける、補う、使わない
   1. 選択肢を並べる
   2. ポリフィルは、補うたびに費用がかかる
   3. 利用者のデータが無いときは
7. 07 当サイトで確かめたこと
   1. 9月の10機能を、トップのCSSとJavaScriptで検索した
   2. 検索が働いていることを、先に確かめた
   3. 当サイトの利用者のブラウザの内訳は、この記事では扱わない
8. 08 このテーマの、これまで
   1. 公式の、日付つきの記録
   2. 当サイトの、関連する過去の記事
9. 09 この記事のまとめ

01 何が起きたか — 2026年9月は、Baselineの「Newly available」になった機能が一度に増えた。ただし、それは「全員が使える」ではない

2026年10月2日の、web.devの月次まとめ

web.devに、2026年10月2日付で「New to the web platform in September」（訳: 9月にウェブの基盤へ加わったもの）が載った。2026年10月13日に本文を開いて確かめた範囲では、2026年9月にChrome 153と154、Firefox 155と156と157、Safari 27が安定版になり、その中で、複数のブラウザがそろって対応した機能が、Baselineの「Newly available」になったと書かれている。Firefox 155は、MDNのリリースの案内によると、2026年9月1日に出た。

"It's the first month of bi-weekly Chrome and Firefox releases."

（訳: ChromeとFirefoxが、2週間ごとにリリースされる最初の月である。）

この記事は、機能の紹介ではなく、「Newly available」になった機能を、自社のサイトで使う前に何を確かめるかに絞る。Safari 27そのものの変更は、当サイトの記事「Safari 27.0は機能が83に増え、customizable selectとスクロール位置の保持が入った ── 自社サイトの表示をiPhoneとMacのSafariで確認する14項目（2026年10月時点）」で扱ったので、ここでは繰り返さない。

「Newly available」になった10の機能

まとめの中で、見出しに「becomes Baseline」（訳: Baselineになる）と付く機能は10件ある。各機能の下には、ChromeとEdgeとFirefoxとSafariの、対応した最初の版が並ぶ。その数字を、表に写した。

機能	Chrome	Edge	Firefox	Safari
progress()	138	138	155	26
alpha()	151	151	155	27
revert-rule	148	148	150	27
light-dark()の画像値	150	150	150	27
overflow-anchor	56	79	66	27
font-width	未対応と表示	未対応と表示	155	18.4
sizes="auto"	126	126	150	未対応と表示
ReadableStreamの非同期反復	124	124	110	27
AnimationEvent.animation	151	151	152	27
cookieStore.set()のmaxAge	145	145	148	27

表の数字は、ページの各機能に付いた「Browser Support」（訳: ブラウザの対応）の表示から読んだものである。本文を読むと、10件のすべてで、Newlyになった理由として挙げられているのは、Safari 27かFirefox 155の対応である。古い版から対応していたブラウザもあれば、今月に入ったばかりのブラウザもある、という並びである。

表と本文が食い違う2か所

表のうち2か所は、本文の文章と食い違って見える。font-widthの表は、ChromeとEdgeを「未対応」と表示している。本文は「Chrome 154 also adds the font-width descriptor in @font-face rules and the width property on FontFace objects.」（訳: Chrome 154も、@font-faceの規則でのfont-widthの記述子と、FontFaceオブジェクトのwidthプロパティに対応する。）と書いている。また、sizes="auto"の表は、Safariを「未対応」と表示しているのに、本文は次のように書く。

"With support in Chrome, Firefox, and now Safari 27, sizes="auto" is Baseline Newly available."

（訳: Chrome、Firefox、そして今回のSafari 27が対応したことで、sizes="auto"はBaselineのNewly availableになる。）

この食い違いの理由は、ページの冒頭の注意書きにある。

"Browser compatibility data pulled from MDN is included in these posts and may not have been updated yet for very recent browser releases."

（訳: MDNから取ったブラウザの互換性のデータがこの記事に含まれているが、ごく最近のブラウザのリリースについては、まだ更新されていないことがある。）

ただし、2か所の食い違いの理由が、この注意書きのとおりであることは、この記事では確かめていない。表の数字は、本文より遅れていることがある、とだけ言える。

02 なぜ・背景 — Baselineは「使ってよいか」の目安であって、判断の代わりではない

Baselineの2つの段階

web.devのBaselineの案内は、段階を2つに分けて説明している。

"Newly available: The feature is supported by all of the core browsers, and is therefore interoperable."

（訳: Newly available: その機能が、すべてのコアブラウザで対応されており、したがって相互運用できる。）

コアブラウザは、Chrome（PCとAndroid）、Edge、Firefox（PCとAndroid）、Safari（macOSとiOS）である。もう1つの段階は、次のとおりである。

"Widely available: 30 months have passed since the newly interoperable date."

（訳: Widely available: 相互運用できるようになった日から、30か月が経っている。）

同じ案内は、Newlyになる前の機能を「Limited availability」（訳: 限られた対応）と呼ぶ。2026年9月に加わった10機能は、30か月後の2029年3月ごろまでは、Newly availableのままである。この日付は、この記事の計算であり、実際の日付は、Baselineを定めるWebDXコミュニティグループが決める。

「Newly available」は、古い版や端末を含まない

MDNは、Newly availableの意味を、次のように書いている。

"Features listed as newly available work in at least the latest stable version of each of the Baseline browsers, but may not work with older browsers and devices."

（訳: Newly availableと載っている機能は、Baselineのブラウザそれぞれの、少なくとも最新の安定版で動くが、古いブラウザや端末では動かないことがある。）

つまり、Newlyは最新の安定版がそろったという意味で、自社の利用者がその版を使っているかどうかは、別の話である。ブラウザは2週間ごとに新しい版が出るようになったが、利用者の端末の更新は、それに合わせて進むとは限らない。

Baselineが測らないこと

MDNは、Baselineの限界も書いている。

"Baseline is a summary of browser support. It is not a substitute for accessibility, usability, performance, security, or other testing."

（訳: Baselineは、ブラウザの対応の要約である。アクセシビリティ、使いやすさ、性能、安全性、その他の試験の代わりにはならない。）

同じページは、Baselineが、古い端末やブラウザの版、OSの組み込みの表示部品（ウェブビュー）、スクリーンリーダーなどの支援技術で動くかどうかを、教えてくれない場合があるとも書いている。

03 用語 — Baselineの言葉を先にそろえる

Newly available、Widely available、Limited availability

Baselineの目標（moving targetとfixed target）

2026年にNewly availableになった機能は、まとめて「Baseline 2026」と呼ばれる。web.devのBaselineの案内によると、2026は、いま増えている最中の最新の集まりである。固定の目標は、ずっと変わらない代わりに、古くなるので、定期的に見直すことが勧められている。

機能クエリ（@supports）

MDNは、@supportsを次のように説明している。

"The @supports CSS at-rule lets you specify CSS declarations that depend on a browser's support for CSS features."

（訳: @supportsというCSSの規則は、ブラウザがCSSの機能に対応しているかどうかによって変わる、CSSの宣言を指定できる。）

同じページは、この使い方を「機能クエリ」と呼ぶと書いている。新しい機能に対応しているブラウザにだけ新しい見え方を出し、対応していないブラウザには従来の見え方（フォールバック）を残す、という出し分けの方法である。

04 型別 — 使う前に、自社の閲覧環境と、機能が使えなかったときの形を確かめる

🅰 この記事が扱う範囲

この記事が扱うのは、CSSやJavaScriptを自社で書いている、またはテーマや制作会社から受け取って管理しているサイトである。「Newly availableの機能を使ってよいか」を、自社の閲覧環境と、機能が使えなかったときの影響で決める手順を扱う。個々の機能の書き方と、ブラウザごとの細かい挙動は、範囲の外である。

🅱 発表とBaselineが測っていないこと

• 自社の利用者が、どのブラウザの、どの版を使っているかは、Baselineにも月次のまとめにも出ない。自社のデータでしか分からない
• 表の数字が、本文より遅れていることがある（01章）。遅れが、いつ直るかは書かれていない
• 機能が使えないブラウザで、画面がどう変わるかは、機能ごとに違う。まとめの文章には書かれていない
• Baselineは、アクセシビリティや性能の試験の代わりにならない（02章）

🅲 手順1: 使いたい機能の、Baselineの段階を見る

MDNの各機能のページの上部には、Baselineの段階の表示がある。使いたい機能のページを開き、Limited、Newly、Widelyのどれかを確かめる。同じページの互換性の表で、ChromeとEdgeとFirefoxとSafariの、対応した最初の版も読む。月次のまとめと食い違うときは、手順7に進む。

🅲 手順2: 自社の閲覧環境を、GA4で見る

GA4には、ブラウザの名前と版を示す項目がある。Googleの公式の説明は、「Browser」を、"The browser from which user activity originated."（訳: 利用者の活動が始まったブラウザ）と説明し、「Browser version」を、利用者のブラウザの版と説明している。これらを並べた表を、直近28日で開く。Safariの利用者の割合と、その中の新しい版の割合を、先に見る。9月に加わった機能の多くは、Safari 27かFirefox 155の対応で、Newlyになったからである。

🅲 手順3: Baseline Checkerで、利用者の何割が目標に入るかを見る

web.devの案内は、利用者のデータがあるときは、目標を決める判断を、データから始めるよう勧めている。

"Knowing the right Baseline target to select should be, when possible, a data-driven decision."

（訳: どのBaselineの目標を選ぶかは、可能なときは、データに基づく判断であるべきである。）

GA4を使っているなら、web.devの「Baseline Checker」が、Googleのアカウントでログインして、GA4のブラウザの版のデータを取り出し、利用者のうち、各目標に入る割合を出してくれる。2026年6月8日付のweb.devの記事は、このツールについて、次のように書いている。

"As before, all of your data is processed locally on your device."

（訳: これまでと同じく、データはすべて、自分の端末の中で処理される。）

期間の既定は、直近28日である。出てきた割合は、Newly availableの目標に入る利用者の割合と、Widely availableの目標に入る利用者の割合の2つを書き留める。

🅲 手順4: 動く目標か、固定の目標かを決める

手順3の割合を見て、自社の目標を決める。web.devの案内は、「Widely available」が、既定として優れた目標だと書き、特別な事情がある場合に、より新しい目標を選ぶことを想定している。目標の決め方は、サイトの種類でも変わる。案内は、通販や企業向けのサイトは、より低い対応の水準を許せるかもしれず、公共のサイトは、高い水準を求めることがあると書いている。

🅲 手順5: 機能が使えなかったときの形を、3つに分ける

目標の外の機能を使いたいときの考え方を、web.devの案内は、こう書いている。

"One important rule of thumb here is that not all web features fail the same way."

（訳: ここでの大事な経験則は、ウェブの機能がすべて同じ形で失敗するわけではない、ということである。）

案内は、失敗の形を3つに分けている。

形	公式の説明（要旨）	公式が挙げる例
Enhancement	使えないブラウザでも、体験は壊れない	loading="lazy"
Additive	見た目や機能に、気づける程度の上乗せがある。使えなくても、比べない限り気づかないことがある	サブグリッド
Critical	使えないと、悪い体験になる。壊れることもある	中心の機能として使うFile System Access API

案内の原文は、Enhancementを、"If the feature is used in an unsupported browser, the experience is not broken."（訳: 対応していないブラウザでその機能を使っても、体験は壊れない）と説明している。自社が使おうとしている機能が、どの形に当たるかを、手順5で1つずつ決める。この分類は、公式が決めた表ではなく、判断のための整理である。

🅲 手順6: 出し分けと、代わりの見え方を決める

CSSの機能は、03章の機能クエリで包み、対応していないブラウザには、従来の書き方を残せる。JavaScriptの機能は、機能の有無を調べる書き方になる。ポリフィルで補う方法もあるが、web.devは、補うたびに費用がかかると書いている（06章）。代わりの見え方は、1行で書ける形にしておく。書けないなら、その機能は目標の外に置く。

🅲 手順7: 実際の画面と、公式の記録で確かめる

最後に、2種類の確認をする。1つは、実際の画面である。スマホとPCの画面幅、新しい版と1つ前の版で開き、見た目と動きを見比べる。もう1つは、公式の記録である。月次のまとめの表が、本文より遅れていることがある（01章）ので、各ブラウザのリリースノートと、MDNの表を並べて読む。食い違いがあれば、どちらが新しいかを、リリースノートの日付で決める。

05 自分のサイトで確認するチェックリスト

下の13項目は、1項目5分ほどでできる作業で、04章の手順1〜7に順に対応している。項目8はGoogleのアカウントでのログインを使う。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。

• 自社のCSSとJavaScriptで、01章の表の10機能の名前を検索し、見つかった数を機能ごとに10個書く
• 項目1で数えた範囲（CSSとJavaScriptのファイルの本数）を書き、見つからなかった機能には「0件」と書く
• 今後使いたい機能を1つ選び、MDNのそのページで、Baselineの段階を「Limited」「Newly」「Widely」のどれかで書く
• 項目3の機能について、ChromeとEdgeとFirefoxとSafariの、対応した最初の版を、MDNの表から4つ書く（未対応なら「未対応」と書く）
• 項目4の版が出た日を、各ブラウザのリリースノートで調べ、最後に対応した版と、その日付を書く
• GA4で、期間を直近28日にして、ディメンション「ブラウザ」の上位5つと、それぞれの割合を書く
• 項目6のSafariの利用者のうち、バージョンが27以上の割合を書く（版の列が読めなければ「読めない」と書く）
• Baseline Checkerを、自分のGoogleアカウントで開いて直近28日を指定し、Newly availableの目標に入る利用者の割合と、Widely availableの目標に入る割合を書く
• 項目3の機能が使えないブラウザで、画面が「崩れる」「少し変わる」「変わらない」のどれになるかを、1つ選んで書く
• 項目9が「崩れる」なら、代わりの見え方を1行で書く（「変わらない」なら「不要」と書く）
• 項目3の機能が、機能クエリで包めるCSSかを、MDNの@supportsのページで確かめ、「包める」「包めない」のどちらかで書き、包めないなら別の方法を1行で書く
• 項目5で調べた版について、リリースノートとMDNの表が食い違っていないかを見比べ、「一致」「食い違い」「片方に記載なし」のどれかで書く
• 項目3の機能が、Widely availableになる月（Newlyになった月に30か月を足した月）を書き、その月を、次に見直す日として予定に入れる

06 代替・他の選択肢 — 使う、待つ、出し分ける、補う、使わない

選択肢を並べる

選択肢	できること	前提と注意
Newlyの機能をそのまま使う	最新の主要ブラウザで、新しい書き方が使える	古い版や端末では動かないことがある（MDN）。使えなかったときの形を決めておく
Widelyになるまで待つ	Newlyから30か月たった、互換性の心配が少ない機能だけを使う	新しい機能は、その間は使えない。web.devは、Widelyを優れた既定の目標と書く
機能クエリで出し分ける	対応するブラウザにだけ新しい見え方を出す	CSSの機能に使う。書き方はMDNの@supportsのページ
ポリフィルで補う	JavaScriptで、足りない機能を補う	web.devは、性能、アクセシビリティ、再現の正しさに欠点があると書く
使わない	従来の書き方を、そのまま残す	新しい機能の利点は得られない。次の見直しの日を決めておく

ポリフィルは、補うたびに費用がかかる

web.devの「How to think about Baseline and polyfills」（訳: Baselineとポリフィルをどう考えるか）は、ポリフィルについて次のように書いている。

"A feature that's polyfilled always has a cost compared to the same feature that's supported in a browser, and these costs add up as you add more polyfills:"

（訳: ポリフィルで補った機能には、ブラウザが対応している同じ機能と比べて、いつも費用がかかり、ポリフィルを足すほど、その費用は積み重なる。）

案内が挙げる費用は、JavaScriptが増えることによる性能への影響、仕様に沿わない場合のアクセシビリティへの影響、機能の細かい部分を再現できないことの3つである。補う前に、Baselineで段階を確かめ、補わなくてよい機能を減らす、というのが、この記事の読みである。

利用者のデータが無いときは

新しいサイトで、まだ利用者のデータが無いこともある。web.devの案内は、その場合に、一般的な傾向を見る資料があること、新しい目標ほど、利用者の中での対応が少ないと見てよいことを書いている。ただし、これは自社の利用者のデータではない。公開後に、GA4の内訳が溜まった時点で、手順2と3をやり直すのが安全である。

07 当サイトで確かめたこと

9月の10機能を、トップのCSSとJavaScriptで検索した

手順1に沿って、2026年10月13日に、当サイトのトップページが読み込む、当サイトのサーバーから配っているCSS13本（約224KB）とJavaScript11本（ライブラリの圧縮版を含む。約209KB）、トップページのHTMLを取得し、01章の表の10機能の名前で検索した。外部のサービスから読み込んでいるもの（スライダー、アイコン、jQueryなど）は、数えていない。他のページ、会員向けの画面は、この検索の範囲の外である。

結果は、10機能のうち、使っているものは1つも見つからなかった。ただし、1件だけ、数字が出た。「alpha(」という書き方が、CSSに3件あった。中身を開くと、昔のブラウザ向けの透明度の指定（filter: alpha(opacity=30)の形）で、今月Newlyになった色の関数のalpha()とは別のものだった。文字の検索だけで「使っている」と読むと、間違える。

検索が働いていることを、先に確かめた

「0件」が本当に0件かを確かめるために、必ず見つかるはずの語でも、同じ範囲を検索した。「@media」はCSSで56件、「font-size」はCSSで304件が見つかった。同じ検索で、機能クエリの「@supports」は、CSSにもJavaScriptにも1件も無かった。つまり、当サイトのトップのCSSは、機能クエリによる出し分けを、いまは使っていない。

当サイトの利用者のブラウザの内訳は、この記事では扱わない

手順2と3のGA4の内訳とBaseline Checkerの結果は、持ち主の画面でしか見られないので、この記事には書かない。

08 このテーマの、これまで

公式の、日付つきの記録

• 2026年10月2日: web.devの「New to the web platform in September」。9月に安定版になったブラウザと、Baselineの「Newly available」になった機能が載った
• 2026年9月1日: Firefox 155のリリース（MDNのリリースの案内）
• 2026年6月8日: web.devの記事で、Baseline CheckerがGA4のデータを、ログインして取り出せるようになった
• 2025年5月20日: web.devの「How to choose your Baseline target」（訳: Baselineの目標の選び方）
• 2025年3月18日: web.devの「How to think about Baseline and polyfills」

当サイトの、関連する過去の記事

• Chromeは153から、安定版が2週間ごとに出る。年末年始だけ間隔がのびる予定 ── 表示確認・計測・納品後の確認の予定を組み直して確認する13項目（2026年10月時点） — ブラウザの新しい版が2週間ごとに出る前提で、確認の予定を組み直す話。
• Chrome 155のベータにJPEG XLの表示が入ったが、「入った」と「自社で足す」は別の判断 ── 配信している画像の形式を確認する13項目（2026年10月時点） — 「入った」と「自社で足す」を分けて考える話。
• 「0件」に、探した数を書いていなかった ── 9種類で確かめた5日後、73種類で確かめ直した — 「0件」には、探した範囲を書く話。
• 「吹き出しが出ていない」と写った ── 壊れていたのは、作ったものではなく写し方だった。自動のスクリーンショットが読者の画面と違う3つ（動き・幅・枚数） — 自動のスクリーンショットが読者の画面と違う3つの理由の話。
• 「測定中」と書いてあると、誰も測らなくなる ── llms.txtの52日分のログを、宣言から15日後に初めて開いた — 約束した確認を、期限つきで行う話。
• 記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかった — 確認項目を、公開した日に自分のサイトへ当てた話。
• 外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた — 外から取った画面が、目当ての画面とは限らない話。
• Search Console の通知 65 件のうち 33 件が未読だった ── 「修正を検証」を押さなかった理由と、毎週の点検にした日 — 通知を溜めず、毎週の点検にした話。