GitHubはフラグ、シム、そして残りを担うAIエージェントでCSS-in-JSランタイムを廃止した

2023年までに一部のGitHubページ上のコンポーネント数は急増し、既存のCSS-in-JSソリューションがその代償を払っていた。クライアント側でスタイルが初期化されるため初回ページ読み込みが遅くなり、スタイル収集がサーバー側に移ったことでサーバーサイドレンダリングが劣化し、スタイル更新は制御不能に膨れ上がった。Primerチームは、移行中にGitHubを一切壊さないという厳格な制約のもと、問題を根本から修正することを決めた。

答えはCSS Modulesだった。各コンポーネントと同居するネイティブなCSSファイルで、クライアント側にもサーバー側にもランタイムを必要としない。形式が根本的に異なるため、チームはコンポーネントごとに移行を進めた。変換済みスタイルシートを追加し、新旧のスタイルを切り替えるフラグの背後にコンポーネントを置き、ピクセルが同一であることを視覚回帰スナップショットで検証し、その後フラグをチームへ、スタッフへ、そして最終的に全員へ展開した。2024年12月までにすべてのPrimerコンポーネントが移行され、ページのサーバーサイドレンダリングは55%高速化し、コンポーネントの初期化は25%高速化した。

より困難な半分はGitHub自身のコードベースだった。そこではsxプロップが長年にわたりスタイリングの標準であり、数千ものインスタンスがランタイム不要の@primer/reactへの切り替えを妨げていた。チームは@primer/styled-reactを構築した。これは推移的ラッパーパッケージで、sxを使うコードがそれを介して同じコンポーネントをインポートできるようにしつつ、それ以外のコードは高速な経路をインポートできる。

その後、変換はパッケージごとに進められた。2025年4月のピーク時には約7,760個のsxプロップが移行対象となり、VS Codeプラグインと社内codemodが作業の大半を担い、8名のエンジニアが6か月で6,419個のプロップを移行し、ページあたり1%から22%のSSR改善を得た。2026年4月には、Copilotコーディングエージェントを伴う2名のエンジニアが残りの895個を3週間でゼロにした。2026年6月までにGitHubは100% CSS Modulesで稼働し、sx、styled-components、styled-systemはすべてなくなった。

視覚回帰スナップショットを伴うフィーチャーフラグの背後で移行する。推移的ラッパーパッケージにより、レガシーなsx利用者は動作を続けながら、新しいインポートは速度を得られる。

CSS-in-JSのランタイムコストはページの複雑さに比例して増大したため、修正はランタイムを調整するのではなく、ランタイム自体を取り除く必要があった。

フィーチャーフラグと視覚回帰スナップショットにより、移行の各ステップは可逆かつピクセル同一となった。これによりデザインシステムチームは、他チームが依存するコンポーネントを変更できた。

@primer/styled-reactラッパーは2つの移行を切り離した。コンポーネントの内部は近代化しつつ、数千のsx呼び出し箇所は順番が来るまで手を付けずに済んだ。

codemod、専用のVS Codeプラグイン、そして最終的にはCopilotコーディングエージェントにより、7,760個のプロップに及ぶ難作業はほぼ自動化された作業となり、2名で完了した。

デザインシステムはプラットフォーム全体の変更を実現する最も安価な手段である。コンポーネントを修正すれば製品もそれに従う。フラグとスナップショットテストがあれば、複数年にわたる移行でも本番環境を壊すことはない。

GitHubは2026年6月以降、完全にCSS Modulesで稼働している。移行のために構築された安全策、すなわちフラグ、スナップショット、段階的ロールアウトは、4年にわたるアーキテクチャ変更を本番環境の破損なしに支えた。そして同じ手法が現在、将来のPrimerプラットフォーム作業を支えている。