Published: November 7, 2025
日本国内で38,000社を超えるエンタープライズ顧客のブラウザ互換性を管理することは、決して容易ではありません。1日あたり150万以上のアプリケーションでクリティカルなビジネス運用を支えているkintoneにとって、ブラウザサポートの判断は極めて重要な意味を持ちます。
日本を代表するグループウェア企業であるサイボウズは、その課題に直面していました。製品全体で一貫したウェブ標準の基準を維持しながら、独自のブラウザサポート基準のメンテナンス負担を回避するには、どうすればよいのか。
至った解決策は、開発時の機能基準にBaselineを採用することでした。この決断は、私たちのウェブプラットフォーム機能へのアプローチを大きく変えるものでもありました。
課題：明確な指針のないブラウザサポート
Baseline導入以前、私たちはアクセスログと手動でのバージョン管理に基づいて、独自のブラウザサポート基準を維持していました。具体的には、アクセスログの上位98%をカバーするブラウザをサポートするという基準です。この閾値を下回るブラウザを使用しているユーザーには、ブラウザ更新を促すメッセージを表示する仕組みでした。
基準の更新は四半期ごとに行われ、エンジニアリングチームが約1時間を費やすものでした。それに反して、開発チームへの基準の浸透は十分とは言えず、「いつからこの新しいCSS機能を使えるのか」「いつこのJavaScript APIのpolyfillを削除できるのか」「結局のところ、今使える機能はどれなのか」といった質問が絶えませんでした。
この独自基準は、メンテナビリティと参照容易性に欠けていただけでなく、さらなる潜在的な問題がありました。アクセスログベースのユーザーエージェント検出と、手動でのバージョン管理では、現代のウェブの進化スピードに適切に追従できないということです。
User-Agent文字列は本当に信頼できるのか
従来のアプローチでは、User-Agent文字列からブラウザ名とバージョンを導出し、それらを「ユーザー」データとして集計していました。しかし、これは本当に私たちのユーザーの実態を反映しているのでしょうか。
User-AgentはHTTPリクエストヘッダーです。つまり、クライアント側で自由に設定できる情報なのです。プロダクトのアクセスログには、ボット、クローラー、攻撃者など、様々なソースからの膨大な量のリクエストが含まれています。中には脆弱性スキャンなど様々な目的で、意図的に古いUser-Agent文字列を送信するクライアントも存在します。`
つまり、アクセスログでは本来サポートすべきユーザーを正確に表すことができていないのです。
User-Agentでは利用可能な機能が分からない
ブラウザのバージョンと機能は、必ずしも対応しません。同じバージョンであっても、チャンネル（Stable/Beta/Dev/Canary）、機能フラグ、Finchのヒット状況、エンタープライズポリシーなどによって、利用可能な機能が異なる可能性があります。
また、ブラウザによって機能の実装タイミングも異なります。例えば、CSS Nestingは、Safari 16.5（2023年5月）に先立ってChrome 112（2023年4月）でリリースされました。User-Agent文字列からは、こうした機能の利用可能性を判断することはできません。](https://developer.chrome.com/blog/new-in-chrome-112)
ブラウザバージョンをサポートすることの責任
ブラウザのアップデートは、新機能の追加だけを意味するものではありません。定期的なブラウザリリースには、新機能とともに重要なセキュリティパッチやバグフィックスが含まれています。古いバージョンをサポートするということは、単に新機能を使わないという選択ではなく、ユーザーの安全性に直接影響を及ぼす判断なのです。
エンタープライズ環境では、一部のユーザーが正当な理由から、ブラウザのバージョン更新に制約を受けることも考えられます。例えば：
- 組織の厳格なブラウザポリシーにより更新が妨げられている
- レガシーハードウェアが最新ブラウザの更新に対応していない
- 規制の厳しい業界のため変更承認プロセスに時間がかかる
しかし、そうしたユーザーをサポートすることは、同時に彼らが脆弱な状態に留まることを許容することでもあります。
もし古いブラウザバージョンの既知の脆弱性が悪用されてセキュリティインシデントが発生した場合、「ユーザーのリクエストに基づいてサポートしていた」という説明では通用しません。ブラウザを適切に更新している他のユーザーにまで攻撃が広がった場合、安全でないブラウザのサポートを継続した責任は私たちにあります。
何が言いたいのかというと、アクセスログベースのアプローチでは、ブラウザを最新に保っている大多数のユーザーにリスクをもたらすものだったということです。アクセスログだけに基づいたブラウザのサポート判断は、適切なセキュリティの考慮を欠いています。適切な判断を欠いた基準を用いることは、単に新機能の利用可否に留まる問題ではなく、ユーザーを保護する責任を果たしていないことにもなるのです。
こうして、私たちの問いは「このバージョンにどれだけのユーザーがいるのか」から「そもそもブラウザバージョンに基づいてサポートを判断すべきなのか」へと変化しました。
なぜBaselineが私たちにとっての答えだったのか
独自基準をメンテナンスする運用上の課題感だけでなく、方法論そのものの根本的な欠陥にも対処できる、新しいアプローチが必要でした。そんな中、Baselineは、まさに私たちが求めていた解決策を提供してくれるものでした。
外部でメンテナンスされ、進化し続ける基準
BaselineはW3C WebDX Community Groupによってメンテナンスされる動的な基準です。四半期ごとにブラウザバージョンを手動で再評価するのではありません。Baselineは、個々の企業が恣意的に決定する基準値ではなく、ブラウザベンダーや標準化団体からの知見を取り入れながら、基準が自動的に進化していく仕組みです。
kintoneの開発では、もはや自分たちでバージョンの閾値を管理する必要がなくなりました。Baselineはチームが何もしなくても進化し続けます。機能に対応するBaselineステータスは利用可否の問いに正確に答えるものであり、その答えはプラットフォームの進化とともに自動的に更新されます。
機能レベルでの正確な判断
個々のブラウザの状況を追跡しようとする代わりに、Baselineは根本的に異なるアプローチを採用しています。
Baseline Widely availableは、主要ブラウザで30か月以上利用可能な実績のあるウェブの機能を表します。この期間は、「開発者からのシグナル、時間経過に伴うブラウザリリースの普及状況、高い総市場シェアのサポートの推定、そしてWebDX Community Groupの最善の判断」を総合的に考慮して決定されたものです。この閾値により、Baselineは観測不可能な個々のブラウザの状況を追跡する作業を不要にしてくれます。)
Baselineを使えば、特定の機能がブラウザ間でどの程度利用可能かを直接的に知ることができます。「CSS container queriesは今使えるのか？」という問いに対して、的確な答えが得られるのです。私たちは、各ブラウザの対応状況を個別に確認することなく、MDNなどのドキュメントでBaselineステータスを即座に確認できるようにもなります。
セキュリティを考慮した設計
Baseline Widely availableを標準として採用することで、私たちのサポートポリシーはブラウザベンダーのサポートライフサイクルと自然に連動します。現在も積極的にメンテナンスされているブラウザは、すべてのWidely availableな機能をサポートしながら、重要なセキュリティアップデートも受け取っています。
アクセスログベースの基準は、サポート対象を古いブラウザに固定してしまい、ユーザーの更新意欲を削ぐ可能性がありました。Baselineを採用することで、自信を持ってモダンな機能を活用できるだけでなく、古いブラウザを使用しているユーザーも、ウェブの進化とともに自然に更新の必要性が出てくるようになります。
Baselineは脆弱なブラウザを明示的に排除するのではなく、ユーザーが自然とブラウザのメンテナンスバージョンを使い続けるための仕組みを提供するものです。
Baselineを採用するにあたっての考慮事項
もちろん、Baselineの採用には、従来のバージョン管理からの移行が伴いました。そこで重要になるのが、Baselineが本当に問題なく機能するという確信です。特に、導入前にどの程度のユーザーに影響を与えるのかを把握しておくことは、エンタープライズレベルでの採用判断において極めて重要なことでした。
Google Analytics Baseline Checkerは、Google Analyticsからエクスポートされたデータを分析し、各Baseline年の機能をサポートするユーザーの割合を示すツールです。このツールにより、Baselineターゲットを選択した場合の実際の影響を確認できました。プロダクトに対してBaseline Checkerを実行したところ、驚くべき結果が得られました。
Baseline Checkerの分析により、98.8%のユーザーがBaseline Widely availableをサポートするブラウザを使用していることが明らかになりました。これは「少なくとも98%のユーザーをカバーする」という以前の社内基準よりも広いカバレッジです。データからは3つの主要なポイントが読み取れました：
- 以前サポートしていたブラウザ：影響を受けない
- 以前サポートしていなかったブラウザ：Baseline Widely available基準を満たしているものの、これまでブラウザ更新プロンプトが表示されていた約0.8%のユーザーが、今後プロンプト表示されずに済む
- 残りのブラウザ：以前と同様にブラウザ更新プロンプトが表示され続ける
特に注目すべきは、偽陽性を排除できることでした。約0.8%のユーザーは、十分に対応可能なブラウザを使用しているにもかかわらず、不必要に警告を表示されていたのです。同時に、以前サポートしていたユーザーに新たに警告を出すという偽陰性も発生しません。
このデータにより、Baseline Widely availableを新しい標準として自信を持って採用することができました。
Baselineの実践と効果
Baselineを基準として採用することと、それを実際に運用可能にすることは別の話です。開発者がBaselineステータスを手動で確認することなく、サポートされていない機能を誤って使用しないようにする仕組みが必要でした。
ESLint設定による静的解析
@cybozu/eslint-configは、サイボウズ製品全体で使用されるOSSの設定です。ビルド時にCSS機能をBaselineに対してチェックするcss-baselineプリセットのサポートを開始しました：
// eslint.config.mjs
import cybozuEslintConfigBaseline from '@cybozu/eslint-config/flat/presets/css-baseline.js';
export default [
...cybozuEslintConfigBaseline.map((config) => ({
...config,
files: ['**/*.css']
})),
];
Baseline Widely availableになっていない機能を使用すると、ESLintから即座にフィードバックを受け取ることができます。
これにより、互換性の問題が本番環境に到達するのを未然に防ぐことができるだけではありません。開発プロセスの早い段階でBaselineに基づいた判断を下せるようになります。機能がWidely availableになるまで待つか、影響を受けるユーザーを正確に把握した上でプログレッシブエンハンスメントな実装をするか、実装の選択がしやすくなるということです。（ESLintのCSSとBaselineサポートについて詳しく学ぶ）
トランスパイラのターゲットをBaseline Widely availableに設定
昨今のビルドツールは、Baselineの指定をビルドターゲットとしてサポートし始めています。例えばViteは、本番環境においてデフォルトで自動的にBaseline Widely Availableをターゲットにします。Browserslistも、Baselineのサポートを開始しました。
コンパイラの設定を活用することで、JavaScriptとCSSは必要な場合にのみトランスパイルされ、すでに広くサポートされている機能に対する不要な変換やpolyfillを回避できます。
独自基準とブラウザ検出システムにおける手動メンテナンスの廃止
最大の成果は、手動での独自基準のメンテナンスを廃止できたことでした。今では、独自基準の決定に四半期おきに時間をかけるのではなく、オープンにメンテナンスされている@web-platform-dx/baseline-browser-mappingパッケージに依拠しています。
また、古いブラウザを使用しているユーザーにアップグレードを促す自動ブラウザ検出機能も構築しています。
この検出機能は、@web-platform-dx/baseline-browser-mappingパッケージから互換性のあるブラウザバージョンを直接取得します。ビルドプロセスで実行され、チームで共有可能な警告バナーを生成する仕組みになっています。Baseline Widely availableの対象が新しいブラウザを含むように更新されると、手動介入なしで自動的に変更が反映されます。
コミュニケーションの効率化
最も重要でありながら予想外だった効果の一つは、Baselineがチーム間のコミュニケーションを大幅に簡素化したことでした。
以前まで、ウェブ技術の利用可否の議論には、会社固有のドメイン知識が必要でした。どのブラウザのどのバージョンをサポートし、どの機能が現在利用可能か、といった独自基準のための知識です。例えば、新しいメンバーは社内の独自基準を理解するのに時間を要していました。しかしこれからは、Baselineの採用により、ウェブコミュニティ全体で広く認識されている共通の基準を参照できるようになります。
これにより、エンジニアリングチーム内だけでなく、より広いウェブコミュニティとの間でも共通言語が生まれました。機能の利用可否について議論する際、誰もが同じソースから同じデータを参照するため、社内の独自基準を説明したり、基準に対する考え方をすり合わせたりする必要がなくなりました。
開発ツールも進化しています。VSCodeやChrome DevToolsのStyleパネルは、Baseline互換性情報を直接表示するようになりました。機能が安全に使用できるかどうかを確認するために、MDNやCan I useを逐一チェックする必要はありません。ツールが即座に教えてくれるのです。
すべてのユーザーに、自信を持ってプロダクトを提供するために
Baselineにより、ブラウザの互換性というものを「管理すべき負担」から「信頼できる基盤」へと転換することができました。Baselineの利活用にあたっては、開発時のすべての段階で自動化を徹底しました：
- 開発時のフィードバック：静的解析とBaselineステータスカードの利用**
- ビルド時の検証：トランスパイラが自動的にBaseline** Widely availableをターゲットに設定
- ランタイム検出：
baseline-browser-mappingを使用した、サポート外ブラウザに対するユーザー向け警告** - 継続的な更新：Baselineデータとの自動同期により、手動メンテナンスが不要に**
導入後の変化は明確でした：
- ブラウザバージョンのメンテナンスにかける時間：ゼロ
- 機能単位での確実な判断により、98.8%以上のユーザーをカバー
- 「このブラウザバージョンでこの機能は使えるのか」という FAQ への即座な回答
- エンジニアリングチーム全体で通じる共通言語の確立
- 機能レベルの利用可否が明確になり、新機能の導入やpolyfill削除のタイミングをチームで自然に議論できるように
さらに、Baselineの採用を検討している組織にとって、ユーザーに与える影響を知ることは極めて重要です。Google Analytics Baseline Checkerのようなツールは、この影響測定を容易かつ分かりやすくしてくれる助けになります。データに基づき、自信を持ってBaselineを採用すると決めたら、成長が目覚ましいBaselineエコシステムを活用して、開発ワークフローを整備できるでしょう。
ウェブプラットフォームは、かつてないほどパワフルかつ、高い一貫性と信頼性を持って、急速に進化しています。Baselineにより、その力を自信を持ってプロダクションで使える。そんな時代が来ているのだと実感しています。
リソース
- 元記事：プロダクト開発の基準に Baseline を取り入れるまで - Cybozu Inside Out
@cybozu/eslint-config設定：@ybozu/eslint-configon GitHub- Baseline Checker：Google Analytics Baseline Checker
- Baselineブラウザマッピング：
@web-platform-dx/baseline-browser-mapping - Baselineについて学ぶ：Baseline at MDN