この記事は、CYBOZU SUMMER BLOG FES '25の記事です。
こんにちは！サイボウズでデザインテクノロジストをしている saku (@sakupi01) です。
はじめに
数ヶ月前に、個人ブログにて以下のエントリを投稿しました。
このエントリの執筆背景には、プロダクトに導入する Web 標準の機能について、社内で導入基準を策定していたことがありました。
そこから数ヶ月が経った現在、kintone というプロダクトのフロントエンドでは、この基準に「Baseline Widely Available」を採用し、運用を開始しています。
本エントリでは、Baseline を採用するまでの背景、運用に至るまでに考慮したこと、kintone での活用方法について紹介します。
前置き
新しい Web 標準の機能をプロダクトに入れても、ユーザがサポートされてないブラウザを利用していれば、その機能は動作しません。
そのため、プロダクトを使っているユーザの User-Agent 情報や RUM などのログを解析し、その機能が動かないユーザができるだけ少なくなるよう、対策を講じる必要があります。
背景と従来の課題
元々、kintone では、User-Agent 情報をもとにアクセスログを収集し、あまりにも古いブラウザからアクセスされた場合には「警告バナー」を表示していました。
その後、IE の完全サポート終了 (2022年6月) の影響を受け、IE でページを表示した際にも、警告バナーが表示されるようにしています。
しかし、プロダクトに対する Web 標準機能の導入基準については、課題がありました。
Web 標準機能の導入基準を見直す必要
プロダクトに導入してよい Web 標準機能については、2022年6月までは「IE11 が最低保証ライン」という対外指標に基づいた基準が存在していました。
しかし、IE をサポートしなくなったことで、Chrome / Edge / Safari / Firefox それぞれのサポート機能の差異に対して、「どのブラウザの、どのバージョンまでをサポートすればよいのか」という議論がおこりました。
そこで、「全体の 98% 以上のユーザはサポートできるようにする」という社内合意のもと、プロダクトで導入可能な Web 標準の機能は以下のように定義されました。（※この指標は製品の動作保証をするものではありません）
- Chrome & Edge: アクセスログの利用率をもとにバージョンを判断し 2% 未満であれば切る
- Safari: 最新 2 バージョンと、最新バージョンリリースから半年間は 3 バージョンをサポート
- Firefox: ESR バージョンまでサポート
つまり、導入する機能の基準は、アクセスログベースのブラウザのバージョンを元に決定するというものです。
サポートバージョンの管理問題
プロダクトにおける導入基準ができたことで、それに則った警告バナーを出せるようになりました。しかし、当初そのサポートバージョンの管理は、チームごとに独立して行われていました。
サポートバージョンの更新を忘れると「ページによってサポートするブラウザのバージョンが違う」状態になってしまいます。
そこで、「サポートするブラウザのバージョンを一元化するパッケージ」を作成し、持ち回りでバージョンを更新していました。
結果、パッケージのオーナーシップが曖昧になってしまい、最終的にサポートバージョンの更新が滞ってしまいました。
導入基準に対する認識のズレ・薄れ
「サポートするブラウザのバージョンを一元化するパッケージ」を依存に取り込んでいないチームが存在し、導入基準に対する共通認識が実質取れていないという状況もありました。
そもそも、このパッケージの中身は以下のような「バージョン」以外の何者でもなく、実際に開発する際に意識するべき導入可能な Web 標準の機能の基準として活用しにくかったのが実際でした。
export const SUPPORTED_BROWSER_VERSIONS = {
FIREFOX: 115,
SAFARI: 17,
CHROMIUM_EDGE: 122,
CHROME: 122,
} as const;
導入可能な Web 標準機能を各チームで均一にし、サポートするブラウザのブレを無くすために、開発現場での対応を見直していたところに、 Baseline という指標が広まってきました。
Baseline は、標準化された機能ごとにサポートしているブラウザの対応が取れるため、これを導入可能な機能の基準として採用できるのでは？というのが今回の改善のきっかけとなりました。
Baseline を活用できるメリット
Baseline を基準にすることで、kintone フロントエンドでは以下のようなメリットがあると考えられました。
- 利用可否を人力で判断する手間がなくなる
- 静的解析ツールやダウンパイルのオプションで Baseline を指定できるものも増えてきた
- VSCode や Chrome の Devtools でも Baseline 情報がホバーされるようになった
- 都度 MDN や caniuse で「この機能って使って良いんだっけ？」を調べる必要がなくなる
- 独自基準をメンテナンスしなくて良くなる
- 指標が WebDX のリポジトリでオープンに管理されている
- Widely Available に対応する主要ブラウザのバージョンを取得し、自動更新される仕組みも用意されている
- 共通認識が揃えやすくなる
- 社内固有のドメイン知識をオープンなものに置き換えることができる
- 業界でも広く認知されているため、リファレンスで参照が容易になる
- 独自指標の存在を知らなかった人や Newcomer でも、業界共通認識として共有可能
特に、Baseline が WebDX CG によって管理されており、定期更新される仕組みを持っていることは、「独自基準をパッケージとして管理し、オーナーシップを失って衰退した」という過去がある我々には、魅力的なメリットでした。
従来の方法に対する懸念
今までは、「98% 以上のユーザはサポートできるようにしよう」という独自の基準を、「プロダクトのアクセスログ」に基づいた「ブラウザのバージョン単位」で運用していました。しかし、この考え方はそもそも適切なのか？という議論も、 Baseline の採用を進めるきっかけになりました。
その User-Agent は本当に信用できるのか
従来の基準は User-Agent からブラウザとバージョンを割り出し、その結果を「ユーザ」の情報として集計していました。
しかし、そもそもこれはきちんと「ユーザの実情」を反映したデータになっているのでしょうか？
User-Agent は HTTP ヘッダ中の文字列であり、クライアントが簡単に偽装可能な情報です。
プロダクトのアクセスログには、Bot、クローラー、攻撃者、etc からのリクエストが大量に含まれています。脆弱性のスキャンなど様々な目的で、古い User-Agent を意図的に送信してくるクライアントもあります。ログを残したアクセスが、私たちの想定する「サポートすべきユーザからのアクセス」であるとは限りません。
UA は利用可能な”機能の基準”を反映できているのか
User-Agent の情報をもとにブラウザとそのバージョンを特定し、それを基準として利用していますが、この 「UA の情報」がそのまま「ユーザが利用可能な機能」を反映しているとも限りません。
ユーザはさまざまな設定や制限のもと、ブラウザを利用しています。ITP の有効/無効、Feature Flags の ON/OFF、Finch のヒット状況、Stable/Beta/Nightly/TP など様々なビルドの利用、組織ポリシーによる制限など、User-Agent だけでは判断が難しい要素は多数存在します。
特定機能のサポート状況を正確に把握したければ、User-Agent からの推測ではなく、Feature Detection によって、実際に使えるか判定する方が精度の高い結果が期待できます。
ブラウザのバージョンを独自でサポートする責任
ブラウザの定期的なリリースは、新機能を追加するためだけに行われているわけではありません。
発覚した脆弱性への対応など、ユーザの安全性を確保するための変更も多数含まれています。
古いバージョンをサポートすることは、単に「新しい機能を使うのを諦めるかどうか」という技術的な制約の問題として捉えられがちです。しかし実際には、古いバージョンをサポートするかどうかは 「ユーザの安全を担保できるか」というサービスの責任問題につながる判断でもあります。
もちろん、ユーザの中にはサポートが切れた端末を使い続けていたり、所属する組織のポリシーで自分ではブラウザを更新できないなど、様々な要因で最新のものが使えない状況も考えられます。
しかし、仮に古いバージョンの脆弱性を突いたインシデントが発生した場合、それを防ぐことができなかった理由として「ユーザのサポートを尊重したから」では済まされなくなるかもしれません。
攻撃範囲がそのユーザだけにとどまらず、きちんと更新していた他のユーザにも影響が及んだ場合、プロダクトには「安全ではないブラウザのサポートをきちんと切らなかった責任」が発生する可能性もあります。
ただただアクセスログの User-Agent の集計数だけを見て「古いブラウザを使っているユーザがいる」と判断し、それが本当に「想定したユーザなのか」、「サポートできる安全なバージョンなのか」もきちんと確認せず無条件にサポートすることは、他の大多数のユーザーのリスクを高めることになりかねません。
Baseline を利用する上での懸念の解消 - サポートできるユーザを概算する
Baseline の採用を検討するにあたって、まず、今までの社内合意を経た独自の基準と、どのくらいの乖離が生じるのかを調査しました。
これまでの基準では、社内合意のもと「98% 以上のユーザはサポートできるようにしよう」という方針だったため、Baseline の採用でどの程度のユーザをサポートできそうか/できなさそうかを事前に把握する必要があるためです。
Baseline Checker の活用
Google Analytics Baseline Checker は、Google Analytics (GA) から取得したデータを元に、サイトのアクティブユーザデータに基づいた Baseline Target を確認することができます。
ところが kintone は社内の規定で GA の利用ができないため、代わりに社内のログ解析基盤からアクセスログをパースし、GA Baseline Checker で解析しました。
その結果、Baseline Widely Available の基準を適用した場合、99.0% のユーザをサポートできることがわかりました。
参考：Baseline Checker で得られるデータの例
考えられる影響
この結果は、「98% 以上のユーザはサポートできるようにしよう」というこれまでの社内基準に対して、Widely Available の方が広範なサポートが可能な基準であることを示すものです。
これにより、Widely Available を利用することで、具体的には以下のような影響が出ることがわかりました。
- これまでサポートされていたブラウザについて
- 影響なし
- これまでサポート外とされていたブラウザについて
- Baseline Widely Available 以上の約 1% のユーザは、サポート対象とみなされるため、警告バナーを表示する必要がなくなる
- それ以外は従来通り警告バナーを表示する
これは、従来「サポート可能だが警告バナーを表示していた」可能性のある 1 % のユーザ（偽陽性）から、警告バナーの表示を消すことができることを意味します。逆に、従来サポートされていたユーザに警告が表示されるようになる、といったことはないため、ネガティブな顧客影響は出にくいと結論づけています。
よって、弊社の場合は、基準を Baseline Widely Available にしても、社内規定の基準を満たすことができることが確認できました。
以上の背景を経て、開発時に内部的に保証する利用可能機能の基準として「Baseline Widely Available」を採用するという結論に至りました。
kintone フロントエンドにおいて、「Baseline Widely Available」の参照は、 特別な理由がない限り必ず遵守すべき項目としています。
Baseline の活用方法
Baseline の活用は、現状以下のような方法で開発チームに働きかけています。
警告バナーの表示
警告バナーは、Widely Available の対象範囲から外れるブラウザに出現させる必要があるため、スクリプトはターゲットをかなり下げてビルドしています。
Baseline に対する UA のヒット判定には、web-platform-dx/baseline-browser-mapping を利用しています。
baseline-browser-mapping は、指定の Baseline Target と互換性のあるブラウザとそのバージョンを配列で返してくれます。
この情報を、警告バナー表示の際の UA ヒット判定に利用しています。
警告バナーはフロントエンド領域の Monorepo として実装しており、ビルド成果物を各チームが取り込んで利用するという形で運用しています。
静的解析ツールの設定に Widely Available を指定する
CSS においては、ESlint や Stylelint などの静的解析ツールで Baseline をもとにしたルールやプラグインが充実してきました。
これらを活用することで、Baseline に則ったコードかどうか、実装時点で気付けるようになります。
@cybozu/esliet-config | css-baseline プリセット の提供
eslint に関しては、@cybozu/esliet-config から css-baseline プリセットを提供するようにしました。 弊社では、ほとんどのチームが @cybozu/esliet-config を利用しており、css-baseline プリセットを追加で利用することで Baseline Widely Available に則った CSS の実装ができるようになります。
そのほかの静的解析ツールを利用している場合は、それぞれの設定を参照するようにします。
トランスパイラの設定に Widely Available を指定する
ビルドツールが、Browserslist や esbuild ビルド target によるダウンパイルの設定をサポートしているのであれば、 Baseline Target をクエリに指定することで、選択した Baseline Target に応じてコードがトランスパイルされるようになります。
弊社のほとんどのチームで利用されている Vite は、 2025/08 時点では Browserlist を build.target としてサポートしていません。
しかし、 build.target を指定しない場合、Vite はデフォルトで Baseline Widely Available をターゲットとしてトランスパイルするので設定不要です。
そのほかのトランスパイラを利用している場合は、それぞれの公式ページを参照して設定します。
- Browserslist 形式
- e.g. webpack, Rsbuild, Babel, autoprefixer, eslint …
- browserslist to esbuild : marcofugaro/browserslist-to-esbuild
- esbuild 形式
- e.g. Vite
- Use Baseline with Browserslist | Articles | web.dev
あとがき
Baseline という指標の導入で、適切に現実を計測できているかも怪しい User-Agent ベースの「サービス独自の基準」を廃止し、「Web 全体」で統計がとられた機能単位の基準に寄せることができました。
「Web 全体」の指標をサービスに持ち込むことに、定量的な根拠が必要なのであれば、Baseline Checker を利用して、組織合意を得る際に活用できるでしょう。
ユーザの利用するブラウザをどのバージョンまでサポートするかは、そのプロダクトがどこまでの HTML/CSS/ARIA/JS/プライバシー/セキュリティ etc... に責任を持つのかを明確にすることにも繋がります。
そして、これらの責任は、独自基準では正確な担保が難しい側面があります。
独自基準に対して、Web プラットフォーム全体で十分に信頼可能な基準として認められた「Baseline」は、その有力な代替手段となり得ます。
プロダクトの責任をより信頼できる基準に寄せていくために、Baseline を開発に取り入れる地盤を作り、それをチームに啓蒙し、活用していくことできればと思います。
