Linear StyleX移行でナビゲーション約30%高速化
Linear StyleX移行は、同社のReactアプリケーションをstyled-componentsから切り離す作業で、1,000本を超えるプルリクエストを経て2026年8月上旬に完了しました。エンジニアのケネス・スコーフス氏が2026年8月26日に公表しています。決定的なcodemod、コーディングエージェント、人によるレビューを組み合わせた取り組みです。Linearによると、表示の重いページではメインスレッドの処理が20%〜35%減り、中位クラスのマシンでナビゲーションが約30%速くなりました。作り直さずに、顧客にとって速い製品を実現した事例です。
Linearがstyled-componentsをやめた理由
Linearは旧来のスタイリングライブラリに、速度と制御という2つの問題を抱えていました。ランタイムCSS-in-JSは、アプリの描画中にブラウザがスタイルを生成してCSSルールを挿入する仕組みです。LinearはReact 18の並行レンダリングへアップグレードした後、そのコストを強く感じました。ちょうどstyled-componentsがメンテナンスモードに入った時期です。SanityのCody Olsen氏は最適化したフォークを公開し、Linearの描画時間を40%短縮しましたが、本人は最後の手段だと語っています。
2つ目の問題はカプセル化でした。styled(Button)のような書き方では、コンポーネントを外側から簡単に上書きできます。デザイン刷新の後、Linearは多数のUI退行を追いかける羽目になりました。エンジニアのスコーフス氏は、コーディングエージェントがコードベースに貢献する割合が増えるほど、明確な境界が重要になると書いています。
Linearが代わりに選んだものとその理由
チームは次のライブラリの条件を定めました。ビルド時のスタイル生成、離れた場所からのスタイル変更を意図的に難しくすること、ファイルをまたいでも予測できるマージ、Reactへの十分な対応、活発なメンテナンスです。主なReact向けスタイリング手段はほとんど検討しました。最有力の代替だったvanilla-extractは、APIが断片的で、スタイルを別ファイルに分ける点が理由で見送られました。
選ばれたのは、Metaのオープンソースのアトミック型CSS-in-JSライブラリStyleXです。スタイル生成をビルド時に移し、衝突しない小さなアトミッククラスを出力します。Facebook、Instagram、WhatsAppのウェブ版を支えているライブラリです。スタイルをコンポーネントのそばに置け、APIは小さく、型安全なスタイリング契約を備えます。代償は柔軟性の低さで、親に依存するセレクタ、グローバルセレクタ、ラッパー越しの上書きは難しくなります。Linearはグローバルセレクタの逃げ道としてCSS Modulesを残しました。
codemod、エージェント、エンジニアの役割分担
作業はエージェントではなく、決定的なcodemodから始まりました。スコーフス氏は大規模なテストスイートを土台にstyled-components-to-stylex-codemodを作り、エージェントがその拡充を手伝いました。オンラインのプレイグラウンドがあり、InfoQによると現在は500本を超えるプルリクエスト、およそ10万行に達しています。
チームはまずStyleXの変数と共有プリミティブを整え、codemodランナー、例、検証スクリプト、チェックリストを添えてエージェントに狭い範囲を任せ、共有コンポーネントより先に末端のコンポーネントを移行しました。エージェントはホバー状態やテーマ設定といった見た目の差分の確認でしばしば行き詰まり、手作業のテストが大量に必要でした。プロジェクトの途中でFableとSolという2つの新しいモデルが登場するまで、その状況が続きました。
「いま移行を始めるなら、FableとSolにもっと頼り、直接実行させるでしょう。」 ケネス・スコーフス氏、Linearのエンジニア
Linearが数か月間移行を止めなかった方法
Linearは2つのシステムが共存する間もプロダクト開発を続け、ツールで移行を促しました。開発者ツールバーのカウンターは各ページにあるstyled-componentsの数を示し、ハイライトは移行済みのコンポーネントを見分けさせ、ボットはプルリクエストに新しいstyled-componentsが入ると指摘しました。現在はOxlintのルールが新しい規約を強制しています。
進捗グラフがその曲線を示しています。Reactのスタイリングファイルのうちstyled-componentsファイルが占める割合は、2026年3月8日の週に100%、6月7日に49%、8月6日に0%でした。新規のstyled-componentsファイルは、4月19日の週のピーク22件から、5月31日以降はほとんどの週でゼロになりました。
Linear StyleX移行の成果
計測結果はLinear自身のものです。移行には1,000本を超えるプルリクエストと約5か月がかかり、2026年8月上旬に完了しました。Linearによると、表示の重いページではメインスレッドの処理が20%〜35%減り、中位クラスのマシンでナビゲーションが約30%速くなり、ページ遷移中に挿入されるCSSルールはゼロでした。
大規模ウェブアプリを持つ企業への示唆
ソフトウェア企業にとっての課題は、活発に更新される大規模なコードベースで、プロダクト開発を止めずに中核のフロントエンドライブラリを入れ替えることです。Linearの答えは3つの組み合わせでした。繰り返しの多い大部分は決定的なcodemod、残りは範囲を絞ったエージェント、判断と見た目の確認はエンジニアです。同社自身は、いまならエージェントがもっと多くを担えるとみています。
市場全体も同じ方向に動いています。InfoQによると、CursorはTailwindからStyleXに切り替えました。Syntaxポッドキャストは、追加の硬直性は人間にはあまり楽しくないが、エージェントはそれを得意とする、と結論づけました。
よくある質問
LinearのStyleX移行にはどのくらいかかりましたか。
約5か月、1,000本を超えるプルリクエストを要しました。Linearは2026年8月上旬に完了し、スコーフス氏は2026年8月26日にプロジェクトを紹介しました。
なぜLinearはvanilla-extractではなくStyleXを選んだのですか。
vanilla-extractは静的な抽出と型安全性を備えていましたが、LinearはAPIが断片的で、スタイルを別ファイルにする点も好みませんでした。StyleXはスタイルをコンポーネントのそばに置け、APIも小さい点が評価されました。
移行はAIエージェントが行ったのですか。
一部はそうです。繰り返しの多い作業の大半は決定的なcodemodが担い、エージェントは範囲を絞った作業を受け持ち、エンジニアは見た目の確認を行いました。プロジェクトの途中でFableとSolのモデルが登場するまでは、その分担でした。
MOZGIIの視点
私たちならこう作ります
この事例は、大規模なコード移行のよい手本です。Linearは最初からエージェントに任せたのではなく、まず大きなテストスイートを備えたルールベースの変換ツールを作りました。変換ツールで扱えない部分にエージェントを使い、画面の見た目が正しいかの判断のように、機械がまだ苦手な作業は人に残しました。私たちも同じ順序をたどるでしょう。
このような移行を私たちが進めるなら、共有の土台から始めます。変換するすべてのファイルが使うデザイントークンと基本コンポーネントです。変換ツールは一般的なパターンを処理し、認識できないものは変換を拒否します。そうすれば、変わった例は誤変換されず、エージェントか人に回ります。エージェントには、例と結果を確認するスクリプトを添えて、小さく明確に定義した作業を一度に1つずつ任せます。目に見えるカウンターと、すべてのプルリクエストでの確認があれば、旧式のコードが新たに紛れ込むのを防げます。
つまずくのは見た目の確認でしょう。コードはコンパイルとテストを通っても、ホバー状態やダークテーマの見え方が間違っていることがあります。Linearもエージェントがまさにそこで苦労したと述べています。そこで、変換したコンポーネントごとにスクリーンショットを比較し、差分があれば人に回します。注視する指標は1つ、旧ライブラリのままのスタイリングファイルの割合を週ごとに追い、旧式で追加された新規ファイルも併せて見ることです。
次に、リントルールを新規コードの標準にして、次のデザイン刷新を最初からきれいな状態で始められるようにします。
出典
この記事の事実の出典です。