Figmaとコードの乖離を断つ：AI時代の「Component Spec」という真実

深夜の障害対応や、リリース直前のUI崩れに頭を抱えた経験は、エンジニアなら誰しも一度はあるはずだ。Figma上のデザインと、実際にブラウザでレンダリングされるコンポーネントの微妙なズレ。角丸の半径が数ピクセル違う、ホバー時の挙動が微妙に異なる、あるいは無効状態のスタイルが定義されていない。これらを我々はこれまで「デザイナーとエンジニアのコミュニケーション不足」や「実装の怠慢」として片付けてきた。しかし、Matz氏が指摘するように、これは個人の努力で解決できる問題ではない。Figmaとコードは、そもそも「表現のパラダイム」が根本から異なるからだ。

Figmaのコンポーネントは、バリアントという単一の仕組みで状態を平面的に管理する。一方で、Reactなどの実装コードでは、props、CSS擬似クラス、useStateといった複数のレイヤーに状態が分散する。この「パラダイムの非対称性」がある限り、どちらか一方を「正」として同期させようとすれば、必ずどこかで情報が欠落する。この欠落こそが、我々が長年苦しめられてきた「乖離」の正体である。AIがデザインを生成し、コードを書き出す現代において、この構造的な欠陥を放置することは、もはや技術的負債を通り越して、プロダクト開発のボトルネックそのものと言えるだろう。

これまで我々が頼ってきた「デザインシステム」は、あくまで人間のデザイナーとエンジニアの暗黙知を前提としていた。しかし、AIエージェントが開発フローに組み込まれた今、AIには「経験」も「勘」も存在しない。書かれていないルールは、AIにとっては存在しないルールと同義だ。この状況下で、Figmaのキャンバスを正とすることは、AIに対して「不完全な設計図」を渡しているに等しい。我々エンジニアは、この構造的な乖離を「頑張って埋めるもの」から「構造的に排除するもの」へと認識を転換しなければならない。

では、このパラダイムの壁をどう乗り越えるべきか。その答えが「Component Spec（コンポーネント仕様書）」である。これはFigmaでもコードでもない、ツール中立な「正」の置き場所だ。YAMLで構造化されたデータと、人間やAIが解釈可能なマークダウン形式のドキュメントを組み合わせることで、コンポーネントの振る舞いを定義する。例えば、ボタンコンポーネントであれば、状態（default, hover, pressed, focused, disabled, loading）という「事実」のみを記述し、それをどう実装するかという「表現」は、各パラダイム（FigmaのバリアントやReactのprops）に委ねる。これにより、FigmaとコードはSpecから生成される「派生物」という位置付けに変わる。

このアプローチの最大の利点は、乖離が「議論の対象」から「検出可能なエラー」に変わることだ。Specと実装がズレていれば、それはSpecに従っていないという客観的な事実として処理できる。議論の余地はない。さらに、AIエージェントに対してこのSpecを読み込ませることで、デザインとコードの整合性を保ったままの生成が可能になる。これは単なるドキュメント化ではない。AI時代の開発における「プロトコル」の策定である。

以下に、Component Specが定義する情報の構造を整理する。

Code Connectのようなツールは、確かにデザインとコードを紐づける「配管」としては優秀だ。しかし、それはあくまで「両端が正しいこと」を前提とした道具に過ぎない。角丸が8pxか4pxかという議論において、Code Connectは対応関係を示すだけで、どちらが正しいかの裁定は下せない。その裁定を下すための「根拠」こそがSpecであり、これこそがAIエージェントを正しく駆動させるための燃料となる。Specを維持するコストは決して小さくないが、中途半端な運用は「3者のズレ」という最悪の事態を招く。導入するならば、「Specを更新しない変更は存在しない」という規律をチーム全体で徹底する覚悟が必要だ。

最後に、我々エンジニアに突きつけられた問いは極めてシンプルだ。「君のプロダクトの『正』はどこにあるのか？」ということである。Figmaのキャンバスか、それともGit上のコードか。もしその答えがどちらか一方に偏っているなら、あなたのチームは構造的な乖離という名の時限爆弾を抱え続けていることになる。AIがコードを生成する時代において、人間が手作業でデザインとコードを同期させるという行為は、もはや非効率の極みである。我々が明日から取るべきアクションは、最も頻繁に使われるコンポーネントを一つ選び、その「仕様」を言語化することから始まる。

「これまで誰の頭の中にあったのか？」という問いを立ててみてほしい。デザイナーの経験則、エンジニアの勘、そしてSlackの過去ログに埋もれた意思決定。それらをすべて抽出し、ツール中立なSpecとして書き出す。この作業は、単なるドキュメント作成ではない。プロダクトの振る舞いを再定義し、AIという強力なパートナーに「正しい設計思想」を教え込むプロセスそのものだ。Specを整備することは、将来的にFigmaが別のツールに置き換わろうと、Reactが別のフレームワークに移行しようと、プロダクトの核となる「振る舞いの定義」だけは守り抜くという、エンジニアとしての防衛戦略でもある。

乖離を「頑張って直すもの」から「再生成で消すもの」へ。このパラダイムシフトを受け入れられるかどうかが、これからの開発現場における生存戦略を分かつだろう。あなたは、AIに何を語りかけ、何を「正」として定義するのか。その答えが、あなたの書くコードの価値を決定づけることになる。