画面の高機能化に伴ってページ内のReactコンポーネントが増えると、スタイルの解決やレンダリングにかかる負荷が無視できなくなることがあります。GitHub Blogの改善報告によると、GitHubでは一部のページでコンポーネント数が急増した結果、クライアントでの初期スタイル初期化、サーバー側レンダリング（SSR）時のスタイル収集、スタイル更新時の処理負荷が課題になっていました。

そこで採用されたのがCSS Modulesへの移行です。従来のCSS-in-JSが持っていたスコープの閉じ込めやすさを活かしつつ、スタイル定義をHTMLとともに配信されるCSSファイルへと集約することで、クライアントおよびサーバーでのスタイル解決処理をなくす構成を選びました。

互換ラッパーと段階的な展開で安全性を確保する

既存のsx指定から互換ラッパー、CSS Modules、視覚的回帰チェック、フィーチャーフラグによる段階的展開へと至る移行手順を示す概念図

大規模な運用中のシステムでは、設計が優れていても一斉切り替えに伴う画面崩れのリスクを避けなければなりません。GitHubのデザインシステムであるPrimerチームは、コンポーネントごとにCSS Modules版のスタイルを用意したうえで、新旧を切り替えるfeature flagを導入しました。既存の視覚的回帰テストを用いて移行前後のスナップショットが一致することを確認し、開発チーム、GitHub社内、そして全利用者へと段階的に公開範囲を広げる手順を採っています。

さらに、製品コード側に残る既存のスタイル指定を壊さない工夫として、推移的な互換パッケージ「@primer/styled-react」を用意しました。これは移行後のコンポーネントに対しても従来のsx propによるインライン指定を受け取れるようにするラッパーです。これにより、製品コード全体を一気に書き換えることなく、準備が整った箇所から安全に切り替えを進められる土台を整えました。

残るコード変換へのAI支援と機械的置換の限界

移行作業が進む中でも、製品コード側には長年使われてきたsx propの記述が多数残っていました。GitHubの報告によると、2026年4月に作業を再開した段階では、2人のエンジニアとCopilot coding agentの活用によって、残存していた895個のsx propを3週間でゼロにしたとしています。これはAI単独の比較実験ではなく、2人のエンジニアとAIツールの併用による自己報告ですが、定型的なコード変換においてエージェントを活用した具体例といえます。

ただし、コードの移行はすべてを機械的に自動置換できるわけではありません。Primerの公式CSS変数移行資料が示しているように、ボタンやラベルなどのコントロール要素に設定する値は、サイズや密度、上下と左右の指定の違いに応じて個別の判断が必要です。また、レスポンシブ対応で使われる@mediaや@containerのクエリ式ではCSS変数が利用できないため、ピクセル値を直接記述しなければならないといった構文上の制約も存在します。変換規則を定めてAIに任せられる部分と、画面の文脈に応じて人間が判断・検証すべき境界を見極める必要があります。

記法の解消と依存ライブラリの完全分離

画面上の記法をCSS Modulesへ置き換えた後にも、重要な工程が残されていました。GitHubでは複数のテーマやハイコントラスト表示をサポートしており、これらがstyled-components由来のJavaScript処理やユーティリティに依存していたためです。

テーマ変数自体はもともとCSS側で定義されていたものの、ライブラリへの依存を完全に断ち切るには、テーマ制御のJavaScriptコードを切り離す改修が必要でした。この作業もfeature flagを用いて慎重に検証され、GitHubは2026年6月時点で100% CSS Modulesでの稼働へ到達したと報告しています。表面的なプロパティの書き換え完了と、基盤ライブラリの依存解消という2つの完了基準を区別して管理したことが分かります。

国内の業務画面に応用するアプローチ

国内の業務システムでも、Reactを用いた画面で共通コンポーネントが増え、性能改善や保守性の向上を目的にスタイル構成の見直しが検討される場面があります。

たとえば、Reactで構築された受注管理画面において、明細行の件数が増加した際にスクロールや描画が重くなるケースを考えてみます。いきなりシステム全体のCSS-in-JSを全面移行するのではなく、まずはブラウザの開発者ツール等で描画処理やスタイル解決にかかっている時間を計測し、本当にスタイル処理がボトルネックになっているかを確かめます。

課題が特定できたら、利用頻度が高く影響範囲を限定しやすい共通部品をいくつか選定します。そのうえで、新旧の表示崩れを防ぐためのテスト条件を整え、定型的なスタイル変換をAIツールで下書きさせつつ、画面サイズや密度に応じた微調整を手動で検証していきます。GitHubが実践したように、既存の指定を一時的に受け止めるラッパーや切り替えフラグの活用は、対象の部品やテーマ、切り替え構成に適用できるかを踏まえつつ、既存画面への影響範囲を抑えて段階的に検証を進めるためのアプローチといえます。

業務画面の改修と実装範囲の整理

既存の業務システムで画面性能を見直す際は、どの画面・操作で負荷が発生しているかの特定から、共通部品の切り分け、AIを活用した改修手順の組み立てまで、段階を踏んだ設計が不可欠です。デノフのWeb・システム開発サービスでは、TypeScriptやReactを中心とした業務システムの設計・開発・運用保守や、AIを取り入れた開発業務の支援を行っています。

画面の重さやライブラリの刷新でお悩みの際は、対象画面の課題整理や、限定した部品から試す改修範囲の切り分けについて、デノフのお問い合わせ窓口からご相談ください。現状の構成に合わせた現実的な進め方を一緒に検討します。