「Figma は 100% 不要」宣言の真意 — Claude Code が溶かすデザインとコードの境界

@kawai_design 氏が X で公開した記事が議論を呼んでいます。

Claude Code を使えば使うほど、Figma を開く理由が消えていく。これは私だけの感覚ではありません。今、世界中のデザイナーが同じ疑問を抱えています。私の結論は明確です。Figma は 100% 不要。

同時期に UX Collective に掲載された Michael Buckley 氏の記事「Figma はデザインツールではない。コードを避けるためのピタゴラスイッチだ」も世界のデザイナーを震撼させました。本記事では、この「Figma 不要論」の構造と、Figma 自身の対応、そして AI 時代のデザインワークフローの変化を技術的に整理します。

「ピタゴラスイッチ」批判 — 何が問題なのか

UX Collective の記事が突いた急所

Michael Buckley 氏の記事は、Figma でのデザイン作業を**ルーブ・ゴールドバーグ・マシン（ピタゴラスイッチ）**に例えました。

Figma でボタンを作る作業:

  1. Auto Layout を設定する
  2. パディングを調整する
  3. ホバーステートを作る
  4. インタラクションを設定する
  5. プロトタイプモードで動作確認する
  6. 開発者に引き渡す
  7. 開発者がコードで再実装する

開発者が同じボタンを作る作業:

  <button className="btn-primary">送信</button>
  → 5 分で完了。ホバー、アクセシビリティも含めて

「パンケーキを返すためにピタゴラスイッチを作るようなもの」— この比喩が刺さったのは、多くのデザイナーが無意識にこの非効率を受け入れていたからです。

本質的な問題: デザインとコードの「翻訳」

Figma の存在意義はデザインとコードの間の翻訳レイヤーにあります。

従来のワークフロー:

  デザイナーの意図
    → Figma でビジュアル化（翻訳 1）
    → デザインスペック作成（翻訳 2）
    → 開発者がコードに変換（翻訳 3）
    → 実装結果をデザイナーがレビュー（逆翻訳）

翻訳のたびに情報が劣化する:
  - ピクセルのズレ
  - インタラクションの解釈違い
  - レスポンシブ挙動の不一致
  - アクセシビリティの抜け漏れ

AI がデザインの意図を理解し、直接コードを生成するようになれば、この翻訳プロセス自体が不要になります。@kawai_design 氏の「翻訳の元データである Figma ファイルも要りません」という指摘は、ここに根ざしています。

Figma 不要派の 4 つの論拠

@kawai_design 氏は、Figma 必要派の主張を 4 つに整理し、それぞれに反論しています。

1. 「全画面を俯瞰できる」への反論

Figma なら全ページを一望できる。しかしユーザーが複数ページを同時に見ることはありません。1 画面ずつ体験するのがプロダクトの現実です。「俯瞰が必要」というのは開発者・デザイナー側の都合であり、AI でコードを生成するなら、その都合すら消えます。

2. 「初期ブレストに便利」への反論

デザインの初期探索なら、画像生成 AI の方が圧倒的に速い。ラフなデザイン案を 10 パターン出すのに Figma を開く必要はありません。Nano Banana 2 のような画像生成モデルなら、テキスト指示だけで日本語を含むデザイン案を即座に生成できます。

3. 「チームコラボに必須」への反論

「成熟したプロダクトはクロスファンクショナルチームで作る。AI ツールは 1 人作業向き」という反論に対して、@kawai_design 氏は大規模チームの前提自体を問い直します。

少人数 AI ネイティブ企業の実績:

  Midjourney:  11 人 → 年間収益 200 億円以上
    従業員あたり収益: 約 200 万ドル

  Cursor（Anysphere）: 約 20 人 → ARR 5 億ドル（780 億円）
    従業員あたり収益: 約 330 万ドル
    評価額: 約 4.6 兆円

  Sam Altman の予測: 「1 人で 10 億ドル企業が生まれる」

AI がデザイナー、エンジニア、PM の役割を吸収していく。職種の境界が溶ける。大人数チームという「前提」が消えれば、その前提に最適化された Figma の武器も失われます。

4. 「デザインシステムの統制」への反論

Figma のコンポーネントライブラリがなければ一貫性が保てない？CLAUDE.md やプロンプトテンプレートにデザインルールを書けばいいと @kawai_design 氏は言います。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# CLAUDE.md のデザインシステム定義例

## カラー
- Primary: #2563EB（Blue 600）
- Secondary: #7C3AED（Violet 600）
- Background: #F8FAFC（Slate 50）
- Text: #0F172A（Slate 900）

## タイポグラフィ
- 見出し: Inter, font-weight: 700
- 本文: Inter, font-weight: 400, line-height: 1.6

## スペーシング
- コンポーネント間: 24px
- セクション間: 64px
- ボタンパディング: 12px 24px

## コンポーネントルール
- ボタンは必ず hover / focus / disabled の 3 状態を実装
- フォームは aria-label を必ず付与
- カード要素は影 (shadow-md) + 角丸 (rounded-lg)

テキストで定義すれば、AI が一貫性を保ってくれる。Figma のデザインシステムと同じ機能を、テキストファイルが果たせる時代になったという主張です。

Figma の対応 — Code to Canvas

Figma は「不要論」にどう答えたか

興味深いことに、Figma 自身もこの流れに対応しています。2026 年 2 月 17 日、Figma は Anthropic と提携し 「Code to Canvas」 機能をリリースしました。

Code to Canvas の仕組み:

  Claude Code でコードを生成
    → ブラウザで動作確認
    → Code to Canvas で Figma にキャプチャ
    → 編集可能な Figma フレームとして取り込み
    → Figma 上でデザインを調整
    → Figma MCP でコードベースに反映

  従来: Figma → コード（一方通行）
  現在: コード ↔ Figma（双方向）

Figma CEO の Dylan Field は 「The Future of Design Is Code and Canvas」 というブログ記事で、デザインの未来はコードとキャンバスの双方向にあると宣言しました。

Figma の戦略転換の意味

Figma の動きは「不要論」への反論ではなく、デザインとコードの境界が溶けることを認めた上での適応です。

時代Figma の位置づけ
2016〜2023デザインの起点。Figma → コード
2024〜2025コード生成ツールとの並存
2026〜コードからの逆輸入も受け入れ。双方向ツール

Figma は「デザインツール」から「デザインとコードのインターフェース」に変わろうとしています。

3 つに割れた議論

世界のデザイナーの議論は、以下の 3 つに分かれています。

不要派: Figma は完全に不要

主張:
  v0 や Claude Code がモックアップの必要性を消した。
  「動くもの」を直接作れるのに、
  なぜ「動かない絵」を先に作るのか。

代表的な声:
  @kawai_design: 「Figma は 100% 不要」
  Michael Buckley: 「ピタゴラスイッチを作るな」

必要派: 大規模チームのコラボにはまだ必要

主張:
  50 人チーム × 100 画面 × 非デザイナーが意思決定に参加する組織には、
  まだ Figma が要る。
  AI ツールは 1 人作業には優れるが、
  非技術者を含むチームのコミュニケーション基盤としては機能しない。

代表的な声:
  Aaron Gustafson: 「Figma 批判はデザイナーの苦労を無視している」

中間派: 初期検証は AI、磨き込みは Figma

主張:
  初期のプロトタイピングは AI で高速に回す。
  ブランドの質感やマイクロインタラクションの磨き込みは Figma で。
  Code to Canvas で双方向に行き来する。

実践例:
  Claude Code で UI を生成 → Code to Canvas で Figma に取り込み
  → Figma で細部を調整 → Figma MCP でコードに反映

数字で見る産業構造の変化

@kawai_design 氏が指摘するように、これは「個人の好み」の話ではなく産業構造の変化です。

指標数値出典
AI コーディング市場規模（2025 年）約 55 億ドルMarket.us
AI コーディング市場規模（2034 年予測）約 473 億ドルMarket.us
年平均成長率（CAGR）24%Market.us
AI コードアシスタント利用率（2028 年予測）75〜90%Gartner
AI コードアシスタント利用率（2024 年時点）約 14%Gartner

Gartner は当初「2028 年までに企業エンジニアの 75% が AI コードアシスタントを使う」と予測しましたが、その後「90%」に上方修正しています。AI がコードを書く時代に、「コードを書くためのモックアップツール」の位置づけは根本的に変わります。

開発者・デザイナーへの実践的な示唆

Claude Code でのデザインワークフロー

@kawai_design 氏が実践するワークフローは以下の通りです。

AI ファースト・デザインワークフロー:

  1. 要件定義（テキスト）
     → 「ユーザー登録フォーム。メール・パスワード・名前。
        モダンなデザイン、アクセシビリティ対応」

  2. Claude Code で直接実装
     → HTML / CSS / JavaScript を即座に生成
     → ホバー、フォーカス、バリデーションも含む

  3. ブラウザで確認
     → 「動くもの」を直接触って検証

  4. フィードバック → 修正
     → 「ボタンをもう少し大きく」「余白を広げて」
     → Claude Code が即座に反映

  所要時間: 数分〜数十分

CLAUDE.md をデザインシステムにする

プロジェクトの CLAUDE.md にデザインルールを定義しておけば、Claude Code が全てのコード生成でそのルールを遵守します。Figma のコンポーネントライブラリと同じ役割を、テキストファイルが果たします。

CLAUDE.md によるデザイン統制:

  利点:
    - バージョン管理（Git）が使える
    - コードとデザインルールが同じリポジトリに存在
    - AI が自動で遵守する
    - 非デザイナーでも更新できる

  制約:
    - ビジュアルでのプレビューがない
    - 色やタイポグラフィの微調整は試行錯誤が必要
    - 非技術者との共有には不向き

Code to Canvas で双方向ワークフローを構築する

Figma を完全に捨てるのではなく、コードファーストで始めて Figma で磨くハイブリッドアプローチも有効です。

双方向ワークフロー:

  Day 1: Claude Code で MVP の UI を生成
  Day 2: Code to Canvas で Figma に取り込み
  Day 3: Figma 上でデザインチームがレビュー・修正
  Day 4: Figma MCP でコードベースに変更を反映
  Day 5: Claude Code で機能を追加

  → デザインとコードが常に同期

「不要論」が当てはまらない領域 — バナー・ベクター・グラフィックデザイン

UI コードと画像アセットは別の話

ここまでの「Figma 不要論」は、主に UI/UX プロトタイピング → コード変換のワークフローに限定された議論です。HTML/CSS/JavaScript で表現される UI コンポーネントは Claude Code で直接生成できますが、バナー画像やベクターイラストはコードではありません。

「不要論」が当てはまる領域:
  ボタン、フォーム、カード、ナビゲーション、レイアウト
  → HTML/CSS/JS で表現される → Claude Code で直接生成可能

「不要論」が当てはまりにくい領域:
  バナー画像、アイキャッチ、ベクターイラスト、アイコンセット
  → ラスタ/ベクター画像として出力が必要 → コード生成では代替しにくい

Figma がまだ強い領域

バナー制作やベクターグラフィックの領域では、Figma（や Illustrator）にはまだ明確な優位性があります。

用途Figma の強み
ベクター編集 → SVG/PNG エクスポートノードの微調整、パスの精密操作、ベジェ曲線の直感的な編集
複数サイズのアセット一括書き出し@1x, @2x, @3x の同時エクスポート
ブランド準拠のバナー制作ロゴ配置、余白、色の正確な指定（#2563EB ぴったり等）
デザインレビュー非技術者がブラウザ上で直接コメント

画像生成 AI（Nano Banana 2 等）が向く領域

一方、画像生成 AI は以下の用途で Figma より高速です。

用途画像生成 AI の強み
SNS サムネイル・アイキャッチの量産テキスト指示だけで 10 パターン即座に生成
写真素材やイラストを含むビジュアル素材探し不要、一発で生成
ラフ案の高速探索方向性の検討に Figma を開く必要がない
日本語テキスト入り画像Nano Banana 2 は日本語描画精度が高い

画像生成 AI の制約

ただし、画像生成 AI には現時点で以下の制約があります。

画像生成 AI ではまだ難しいこと:

  - ピクセル単位の精密な配置指定
    → 「ロゴをあと 2px 右に」ができない

  - ベクター出力（SVG）
    → ラスタ画像（PNG/JPEG）のみ。SVG は生成できない

  - ブランドカラーの厳密な指定
    → #2563EB ぴったりの色が出るとは限らない

  - ロゴの正確な再現
    → 既存ロゴを「そのまま」配置することが困難

  - 複雑なベクターイラスト
    → Claude Code が生成できる SVG はアイコン程度の複雑さまで

現実的なハイブリッド運用

バナーやグラフィック制作においては、画像生成 AI で初期案を出し、精密な調整や SVG 化は Figma で仕上げるハイブリッドが現実的です。

グラフィック制作のハイブリッドワークフロー:

  Phase 1: 画像生成 AI でラフ案を 10 パターン生成
    → 方向性を決定（5 分）

  Phase 2: 選んだ方向性を Figma で精密に再現
    → ブランドカラー、ロゴ配置、テキスト配置を正確に調整
    → SVG/PNG を書き出し（30 分〜1 時間）

  従来: Figma で 0 から作る（2〜3 時間）
  ハイブリッド: AI + Figma で仕上げる（35 分〜1 時間 5 分）

つまり「Figma は 100% 不要」は UI コンポーネントのプロトタイピングに限定した主張であり、バナー制作やベクターグラフィックの領域では Figma（やベクター編集ツール）にはまだ代替困難な価値があります。

「道具より覇気」という結論

@kawai_design 氏の記事は、ツール論に留まらない問いかけで締めくくられています。

道具への執着は、成長の敵です。大切なのは「何を使うか」ではなく「何を作るか」。そしてもっと大切なのは、「なぜ作るか」という意志の強さ。道具は変わります。来年にはまた新しいツールが生まれるかもしれない。でもあなたの「覇気」— 何を成し遂げたいかという意志だけは、どんなツールにも代替されません。

Figma が不要かどうかは、技術の進化が答えを出します。問うべきは「何のツールを使うか」ではなく、そのツールで何を実現したいかです。

まとめ

  • 「ピタゴラスイッチ」批判: Figma で複雑な Auto Layout を組んでボタンを再現する横で、開発者は 5 分でコードを書く。デザインとコードの「翻訳レイヤー」としての Figma の存在意義が問われている
  • AI が翻訳を消す: Claude Code がデザインの意図を理解し直接コードを生成するようになれば、翻訳の元データである Figma ファイル自体が不要になる
  • 大規模チームの前提が崩れる: Midjourney（11 人）、Cursor（約 20 人）など少人数で巨大な成果を出す AI ネイティブ企業が台頭。大規模チーム向けコラボツールとしての Figma の武器が刺さる対象が縮小
  • Figma 自身が適応: Code to Canvas（2026 年 2 月）で Claude Code との双方向連携を実現。「デザインツール」から「コードとキャンバスのインターフェース」への戦略転換
  • CLAUDE.md がデザインシステムになる: テキストでデザインルールを定義し、AI が一貫性を保ってコードを生成する。Git 管理可能で、非デザイナーでも更新できる
  • バナー・ベクター領域では Figma にまだ優位性: 「不要論」は UI コードのプロトタイピングに限定した主張。ベクター編集・精密配置・SVG 出力・ブランド準拠のバナー制作では Figma が代替困難。画像生成 AI でラフ案を出し Figma で仕上げるハイブリッドが現実的
  • Gartner 予測: 2028 年に 90% が AI コードアシスタントを利用: AI コーディング市場は年 24% で成長。産業構造の変化がツール選択を根本から変える

参考