Figmaの「唯一の情報源」が移動した: FigmaはいまやドキュメントだI
コードベースを唯一の情報源として扱い、Figmaをそれを説明するドキュメントとして位置づけるチームが増えている。何が変わったのか、Figmaがまだ担う役割、そしてチームを失わずにコードファーストのデザインシステムを運用する方法を解説する。

コードベースがいまや唯一の情報源であり、Figmaはそれを説明するドキュメントだ。これは2026年にかけて増加するプロダクトチームが行った転換であり、Figmaへの反発ではない。三つのことが同時に成熟した、その論理的な結末だ。
これは再配置であり、葬式ではない。Figmaは「真実が宿る場所」から「チームが探索してドキュメントを作る場所」へと移行している。これは降格であり、誰かを中心に再編する前に理解する価値がある。
「唯一の情報源」が実際に意味すること
唯一の情報源とは「デザインが最もきれいな場所」ではない。二つのバージョンが食い違うときに勝つアーティファクトのことだ。Figmaファイルが一つの角丸半径を示し、出荷済みコンポーネントが別の値を示しているなら、もう一方をそれに合わせて修正する側が唯一の情報源だ。
長年それはFigmaだった。デザイナーが値を定義し、エンジニアがそれを翻訳し、プロダクションがずれたとき、Figmaファイルが修正の基準となった。
問題は常に翻訳のステップにあった。デザインファイルは出荷できない。コードが出荷される。つまり「Figmaが唯一の情報源だ」とは実際には「エンジニアが再解釈するまでFigmaが唯一の情報源だ」という意味であり、これはハンドオフのたびに真実が持ち主を変え、誰もそのギャップを担っていなかったという丁寧な言い方にすぎない。
変化: コードファーストとドキュメントとしてのFigma
コードファーストはデフォルトを逆転させる。値、コンポーネント、そして出荷されるUIがリポジトリで定義される。Figmaはそのシステムを定義する代わりに説明する。
ここでデザイナーの日常を悪化させることは何もない。それでもFigmaでデザインする。そこで探索し、ブランチを作り、批評し、プロトタイプを作る。変わるのは権限の方向だ: リポジトリはもはやファイルを追わず、ファイルがリポジトリを参照する。

このフリップを誠実に行った後、各レイヤーが担うことは以下の通りだ。
| レイヤー | いま担うもの | もはや担わないもの |
|---|---|---|
| コードベース / リポジトリ | トークン値、コンポーネントの動作、実際に出荷されるUI | 何も手放していない: 値を得た |
| Figma | 探索、フロー、プロトタイプ、仕様、ドキュメント、デザインレビュー | 正規の値と「正しい」コンポーネント |
| デザイナー | 意図、階層、インタラクションデザイン、システムの方向性 | プロダクションと矛盾するピクセルへの最終決定権 |
| エンジニア | コードで定義されたトークンとコンポーネントの実装 | その都度手作業で静的ファイルを再解釈すること |
リポジトリが唯一の情報源になった理由
三つのことが同時に成熟した。いずれも「AIがデザイナーを置き換えた」ではない。どれも、ようやく着地した退屈なインフラだ。
トークンがコードに移行した。 デザイントークンは生の値だ: カラー、スペーシング、角丸半径、タイプスケール。Style Dictionaryのようなツールで構築されたトークンパイプラインにより、それらの値はコードで一度定義され、すべてのプラットフォームに同期される。正規のカラーがリポジトリに存在し、Figmaがそこから読み取った瞬間、リポジトリがカラーのソースになる。他の値も同様だ。
デザインとコードが結びついた。 FigmaのDev ModeとCode Connectにより、Figmaコンポーネントをリポジトリの実際のコードコンポーネントに紐付けられるようになった。これは人々が見落としがちな部分だ。Figmaはこの変化に抵抗していない。コードを結合対象とする機能を自ら出荷した。
一方、Storybookはコードされたコンポーネントに目で確認してテストできる生きた場所を与え、shadcn/uiはコンポーネントを再描画するレイヤーとしてではなく、リポジトリにコピーする実際のコードとして配布する。「どちらが正しいか」という問いがついに決定論的な答えを持つとき、その答えはコードだ。

AIはキャンバスではなくリポジトリでビルドする。 現世代のUI生成はコードを読み書きする。Figmaのレイヤーを読まないし、書き戻しもしない。だからビルドループはいまやリポジトリで始まり、リポジトリで終わる。これが静かにリポジトリを、作業が実際に蓄積される場所にしている。

Figmaがいま実際に担うこと
たくさんある。そしてその大部分はデザイナーが最も好きな部分だ。
Figmaはいまもプロセスの前半を担っている: 探索、発散、高速な反復、デザインがまだ存在しない状態で見つけていく、ぐちゃぐちゃな中間部分。コードは声に出して考える場所として最悪だ。Figmaはそのために作られている。
ドキュメントも担っている。フロー、状態、エッジケース、注釈、「なぜ」、ユーザーの前に置くプロトタイプ。リポジトリは唯一の情報源だが、クライアントにデザインの決断を説明する場所としては最悪だ。ファイルがその役割を担う。
| 仕事 | 最適な場所 |
|---|---|
| まだ存在しないアイデアの探索 | Figma |
| 正規のトークン値の定義 | コード |
| フロー、状態、エッジケースのマッピング | Figma |
| 「どのコンポーネントが正しいか」の解決 | コード(Code Connect / Storybookを通じて) |
| デザインレビューとクライアントレビュー | Figma |
| ユーザーに実際に出荷されるもの | コード |
正直な反論
Figmaは死んでいない。そのヘッドラインを売りつけてくる人間は、ヘッドラインを売っているだけだ。
三つの現実的な制限がFigmaを不可欠にしている:
- コードは初期探索に対して敵対的であり、発散フェーズはいまもキャンバスに属する。
- 非エンジニアはシステムを読む場所を必要としており、リポジトリはその場所ではない。
- バインドはデザインとコードされたコンポーネントを同期させる人間がいる場合にのみ機能する。これは規律であり、デフォルトではない。
これは再配置だ。真実が宿る場所は移動した。チームが考える場所は移動していない。「Figmaはドキュメントだ」をツールへの評決ではなく役割の明確化として捉えれば、デザイナーたちは抵抗する代わりに頷くだろう。
チームを失わずにコードファーストのデザインシステムを運用する方法
失敗のモードは技術的なものではない。デザイナーが降格されたと感じ、エンジニアが二つ目の仕事を押しつけられたと感じる、ハンドオフ戦争だ。これは命令としてではなく、順序として実行せよ。
-
まずトークンを移行し、他は何もするな。 カラー、スペーシング、タイプ、角丸半径をコードで定義し、同期させる。Figmaにそれらを宣言させるのではなく消費させる。これはリポジトリを権威あるものにする最小の変更であり、まだコンポーネントには触れない。
-
トップ10のコンポーネントを結びつけよ。 Code Connectを使って最もよく使うFigmaコンポーネントをコードされた対応物に紐付け、Storybookで生きた場所を与える。全部一気にやろうとするな。すべてに存在する10個のコンポーネントがずれのほとんどを担っている。

-
情報源を声に出して名指しせよ。 システムドキュメントに一文を書け: 「ファイルとコードが食い違うとき、コードが正しい。」戦争を始めるのはルールそのものではなく、曖昧さだ。
-
デザイナーを上流に置き、下流に置くな。 デザイナーは意図、階層、システムの方向性を担い、コードより先んじて作業すべきだ。プロダクションのレッドラインに縮小されてはならない。コードファーストがデザイナーをQAにするなら、やり方を間違えている。
-
同期を誰かが担う仕事にせよ。 デザインとコードの間のバインドは自動的に維持されない。誰かに割り当てよ。ずれたCode Connectマッピングは確信を持って嘘をつくため、マッピングなしよりも悪い。
誰が切り替えるべきで、誰が切り替えるべきでないか
すべてのチームがデフォルトを反転させるべきではない。決定要因は、デザインからずれる実際のコードベースを出荷しているかどうかだ。
切り替えるべき場合:
- コードにコンポーネントライブラリを持つプロダクションアプリがある
- デザインとビルドのずれが繰り返し発生している
- エンジニアがすでにStorybookや類似のセットアップで生活している
リポジトリはあなたの真実がすでに蓄積している場所だ。それを公式にせよ。

待つべき場合:
- アウトプットの大部分が静的な成果物、マーケティングページ、またはピッチ資料だ
- 耐久性のあるコンポーネントライブラリとして実装されるものがない
真実が宿るコードベースがない場合、「コードファースト」はスローガンであり、システムではない。Figmaを唯一の情報源にしておくことが正しい判断だ。
| シグナル | コードファーストに傾く | Figmaファーストを維持 |
|---|---|---|
| 耐久性のあるコードコンポーネントライブラリ | はい | いいえ |
| デザインとビルドの繰り返すずれ | はい | まれ |
| エンジニアがすでにStorybookにいる | はい | いいえ |
| アウトプットが主に静的またはピッチ資料 | いいえ | はい |
よくある質問
2026年もFigmaは唯一の情報源か?
増加するプロダクトチームにとっては、ノーだ。リポジトリがトークンとコンポーネントを定義し、Figmaがそのシステムをドキュメント化する。耐久性のあるコードベースを持たないチームにとっては、Figmaが唯一の情報源であることはいまだ正しい設定だ。
コードファーストはデザイナーがFigmaの使用をやめることを意味するか?
いいえ。デザイナーはいまもFigmaで探索し、プロトタイプを作り、ドキュメントを書く。変わるのは、正規の値と「正しい」コンポーネントがコードに存在し、Figmaがそれらを定義するのではなく参照するということだ。
Figma Code Connectの役割は何か?
Code ConnectはFigmaコンポーネントをリポジトリの実際のコードコンポーネントに紐付けることを可能にする。「どちらが正しいか」という問いに決定論的な答えを与えるメカニズムであり、Figma自身がコードを結合対象として扱うシグナルだ。
デザイントークンはどこに位置するか?
トークンが楔だ。Style Dictionaryのようなパイプラインを通じてカラー、スペーシング、タイプがコードで定義され、外部に同期されると、リポジトリがそれらの値のソースになる。トークンを最初に移行することが、最もリスクの低い始め方だ。
StorybookとShadcn/uiはどうか?
どちらもコードをコンポーネントの生きた場所にする。Storybookはコードされたコンポーネントに目で確認してテスト可能な場所を与え、shadcn/uiはコンポーネントを再描画するレイヤーとしてではなく、リポジトリにコピーする実際のコードとして配布する。チームが「コードが情報源だ」と言うとき指し示す先がこれらだ。
まとめ
真実は一箇所に存在する。唯一本当の問いは、その場所を意図して選んだか、デフォルトに任せたかだ。
2026年においてより多くのチームにとって、リポジトリがその場所だ: コード内のトークン、Code ConnectとStorybookを通じて結びつけられたコンポーネント、コードベースで始まりコードベースで終わるビルドループ。Figmaは仕事を失っていない。より明確な仕事を得た。プロセスの前半とシステムのドキュメント化だ。
唯一の情報源を意図して選び、順序通りに権限を移行し、ファイルとコードが食い違うときに誰が勝つかを書き留めよ。それをすればコードファーストはアップグレードだ。省略すれば、余分なステップを伴うハンドオフ戦争を手に入れる。
Want a design system where truth lives in one place? Brainy builds it.
Get Started




