React/Tailwind開発で共有ライブラリを廃止しAI生成へ移行すべき理由

• 事実と背景：AIエージェントの進化により、UIコンポーネントを「再利用」するより「都度生成」する方が低コストな時代が到来した。
• 技術的変革：中央集権的なコードパッケージを廃止し、デザインシステムやトークン、テスト仕様のみを共通ルールとして管理する。
• 現場への影響：開発者はバージョン管理の泥沼から解放され、AIプロンプトと自動テストを用いた自律的なUI構築へシフトすべきである。

深夜2時、本番環境で発生した謎のレイアウト崩れ。原因を調査していくと、別チームが共通UIライブラリのマイナーアップデートで行った「ボタンのパディング微調整」が、自チームのモーダルコンポーネントと干渉し、デッドロックを引き起こしていた――。フロントエンド開発に携わるエンジニアなら、誰もが一度はこのような「共通ライブラリの呪い」に直面したことがあるはずだ。

長年、我々エンジニアにとって「全社共通のUIコンポーネントライブラリを構築すること」は、開発効率とデザインの一貫性を担保するための絶対的な正義とされてきた。ボタン、モーダル、データグリッド、フォームコントロールを1つのnpmパッケージにまとめ、バージョン管理する。これによって、車輪の再発明を防ぎ、アクセシビリティやブランドの統一性を一挙に解決できると信じて疑わなかった。

しかし、Griffiths Waite社での長年のReact開発や大規模エンタープライズ支援の実績が示す通り、このアプローチの真のコストは「最初のリリース」ではなく、「その後の10年間」に支払うことになる。共通ライブラリが普及するにつれ、所有権の境界線は曖昧になり、メンテナーは日々のデリバリー業務に追われ、ライブラリのバックログは放置される。あるチームは特定のサードパーティ製ライブラリに依存したラッパーを求め、別のチームは独自のバリアントを勝手に追加する。結果として、ライブラリは肥大化し、依存関係のスパゲッティコードと化していく。

我々が直面しているのは、共通ライブラリを維持するための「組織的オーバーヘッド」という名の重税だ。バージョンアップの追従を諦めたチームが古いバージョンを使い続け、社内に複数の「単一の真実の源（Single Source of Truth）」が乱立する。この泥沼から抜け出すためのパラダイムシフトが、今まさに起きようとしている。

物理的な世界において、「再利用（Reusable）」は極めて価値の高い挑戦だ。例えば、SpaceXが開発する再利用可能ロケットは、宇宙開発のコストを劇的に引き下げ、中国などの競合国もこの技術を猛追している。しかし、物理的な制約を持たないソフトウェアの世界において、我々は本当に「コードの再利用」に執念を燃やし続けるべきなのだろうか。

2026年現在、生成AIとコーディングエージェントの進化は、この前提を根底から覆した。DockerがAIエージェント向けの公式スキル「Docker Skills」を公開したように、開発環境の構築からコード生成、テストの実行までをAIが自律的に行うエコシステムが急速に整いつつある。Tailwind CSSの普及がその好例だ。開発者はもはやコンポーネントライブラリのドキュメントを読まない。AIにプロンプトを投げ、その場でTailwindのクラスが適用された、美しくアクセシブルなコンポーネントを「再生成（Regeneratable）」させているのだ。

Denis Uraevが提唱するように、時代は「Reusable（再利用可能）」から「Regeneratable（再生成可能）」へと移行している。AIモデルに強固なデザインシステムと制約条件をインプットすれば、標準的なUIコンポーネントはオンデマンドで、かつ極めて高品質に生成できる。ここで、従来の「再利用」とこれからの「再生成」のアプローチを比較してみよう。

この比較からも明らかなように、高価なエンジニアリングリソースを割いて「共通パッケージ」を延命させる合理性は、もはや失われつつある。AIがコードを瞬時に生成できるのであれば、我々が中央で管理すべきなのは「完成されたコード」ではなく、それを生成するための「ルール」なのだ。

では、我々シニアエンジニアは明日からどのようなアクションを取るべきか。答えはシンプルだ。コードの共有をやめ、ルールの共有に徹することである。

具体的には、デザインシステム、デザイントークン（色、タイポグラフィ、スペーシングの定義値）、アクセシビリティのガイドライン、そしてそれらを検証するための「テスト仕様」のみを中央で厳密に管理する。コンポーネントの具体的な実装コードは、各プロジェクトのAIエージェントに生成させる。

このアプローチを成功させるための実践的な処方箋は以下の3点だ。

• 第一に、デザイントークンを唯一の真実の源として定義し、JSONなどの機械可読なフォーマットで配信すること。AIエージェントはこのトークンを読み込み、デザインに準拠したコードを正確に出力する。
• 第二に、視覚的退行テストやアクセシビリティ検証の自動テストパイプラインを徹底的に構築すること。AIが生成したコードが、中央のルールに準拠しているかを自動で検証する仕組みがなければ、このアプローチはただのスパゲッティコードの再生産に終わる。
• 第三に、真に複雑でドメイン固有のロジックを持つコンポーネントのみを、厳選して共通ライブラリとして残すこと。すべてのUIをAIに任せるのではなく、差別化につながらない「退屈なUI」の生成をAIに委ねるのだ。

最後に、我々エンジニア自身に問いかけたい。あなたのチームは、いつまで「ボタンのパディング調整」や「ライブラリのバージョン競合」という、本質的ではない作業に貴重な開発リソースを浪費し続けるのか？ AIがコードを無限に、かつ安価に生成できる時代において、我々の価値は「コードを書くこと」ではなく、「システムにどのような制約を与え、品質を保証するか」にある。今こそ、重厚な共通ライブラリを解体し、真にアジャイルなフロントエンド開発へと舵を切る時だ。