Figmaより動くHTMLモック

そーくん
Figmaより動くHTMLモックを作る話、テック界隈でかなり話題ですね。
ボス
けんすう氏の実践共有がきっかけで、一気に議論が広まったね。
そーくん
デザインツールより直接コードで作る方が速いって本当ですか？
ボス
どういう試行錯誤の末にその運用に至ったのか、まずは流れを追ってみよう。

何が起きたか

試行錯誤期
デザインツール×AIを検証
画像からの起こしや細かい文字修正のコストが高く、デザインツールとAIの単純併用では遅かったと本人が振り返る。
拡散の起点8/9 未明
動くHTMLモック運用を公開
Claude CodeでHTMLモック、Codexで画像やレビュー、確定はGitHub、優先度はROADMAP表、という運用を長文で共有した。
直後
PdM・CTO層が共感
デザイナー不足組織や個人開発勢から「実装距離が短い」「トークンだけ同期」への賛同が集まった。

そーくん
実際に動く画面で確認できるなら、手戻りも少なそうですね。
ボス
PdMの判断スピードを最大化する知恵として、強く共感されているよ。
そーくん
でも、デザイナーがいらなくなるって話とは違うんですよね？
ボス
そうだね。いまどういう視点で評価されているか、整理して見てみよう。

議論の現在地

主流派の視点: PdMが判断力を最大化するためのClaude/Codex運用として、静的デザインより動くHTMLモックが速い、という実践知枠。
その他の視点: 本番とトークンだけ同期し、モックを正にしない割り切りが肝
エンジニア主体組織のデザイナー不足を埋めるナレッジ
プロのデザインプロセスの代替ではない、という本人の留保
ハーネスやレビュー自動化とセットのAI駆動プロダクト開発論
目立つ論者: @kensuu（実践の一次発信）
個人開発・PdM層
CTO／エンジニアリング寄り共感層
デザインツール擁護の潜在層（まだ一次声は薄い）

そーくん
SNSの反応を見ていると、賛同している人が多い印象です。
ボス
デザイナー不足に悩む現場や個人開発者には、特に刺さっているね。
そーくん
逆に慎重な見方をしている人はどれくらいいるんでしょう？
ボス
意見のバランスや全体の世論の傾きがどうなっているか、確認してみよう。

世論の分布

意見陣営別シェア(推定レンジ)

Xサンプル上の可視的な言論に占める割合 · 下限—上限

HTMLモック推進派38–52%
不足解消・現場派18–28%
プロ別解留保派16–26%

推定下限推定上限

ポジ / 中立 / ネガ集計

陣営をスタンス別に統合 · 賛同2陣営の中央値合算を最大セグメントで100調整

69%

17%

14%

ポジティブ 58–72%(HTMLモック推進派、不足解消・現場派)中立 12–22%(プロ別解留保派)ネガティブ 10–18%(プロ別解留保派)

テーブルビュー(グラフと同じデータ)

陣営	スタンス	シェア	中心的主張
HTMLモック推進派	ポジティブ	38–52%	動くモックならその場でフィードバックでき、実装への距離も短い。PdMには最適解。(@kensuu、@shintaro_campon、@Mar_3simai)
不足解消・現場派	ポジティブ	18–28%	デザイナー不足がボトルネックの組織では、このナレッジは実務の救いになる。(@sakumenx、スタートアップCTO層)
プロ別解留保派	混在	16–26%	PdM向けの最適化であり、プロのデザイナー／エンジニアには別の正しいやり方があるはず。(@kensuu（自注）、デザイン職の潜在反論)

そーくん
結局、これからのデザインツールってどうなっていくんですかね？
ボス
HTML優先か、従来のツールとの分業か、論点が分かれているね。
そーくん
作る立場と全体を設計する立場とで、意見が食い違っている感じです。
ボス
両者の主張がどう噛み合っていないのか、具体的な論点を確かめてみよう。

進行中の論争

論点1

デザインツールはAI時代にまだ必要か？

A側 · HTML優先

動くモックとデザイントークン同期の方が実装コストが低く、PdM判断に直結する。

B側 · ツール分業

探索的ビジュアル設計やブランド横断ではFigma等の専門ツールがなお強い可能性がある。

根拠: けんすう本投稿と賛同リプ、本人の「プロは別かも」呼びかけ

主なポスト

kensuu@kensuu·実践の一次発信サイトのデザインの開発、いろいろな試行錯誤をしてたんですが、結局は FigmaやPencilの代わりに、Claude Codeで「動くHTMLモック」を作ってしまう、というので落ち着きました。 CSSは本番と同じデザイントークンだけで書くので、エンジニアはほぼコピペで実装できる。デザインツールとAIをかけ合わせると、細かい文字の変更とかに時間がかかるし、実装時にも画像から起こさないといけなかったりしてコストが高いんですよね。んで、管理のコツは「デザインが確定したか」と「いつ実装するか」を別の道具で管理すること。確定したか → GitHubが管理（mainにマージ＝確定）いつ実装するか → ROADMAPの表で「次に実装」「あとで実装」「構想中」に分けて管理HTMLモック運用の結論と管理分離を示した起点ポスト

kensuu@kensuu·適用範囲の自注プロのエンジニアやデザイナーさんからしてみたら「それじゃない方がいい」というのがありそうなので、ツッコミやアドバイスは大歓迎です！PdM最適化でありプロ別解があり得る、と自ら留保を付けた

編集部まとめ

そーくん
ここまで読むと、プロダクト開発の現場が一気に変わりそうな熱量を感じますね。
ボス
ここまでの話を踏まえると、これはPdMの判断速度を最大化するための工夫と言えるね。
そーくん
単にデザインツールを全否定して捨てるという話ではないんですね。
ボス
そうだね。HTML優先派は、動くモックとトークン同期で実装への距離が縮まると考えている。
そーくん
確かに、静止画で説明するより動くものを見せる方が意思決定は早そうです。
ボス
一方でツール分業派は、ブランド設計や視覚的な試行錯誤には専門ツールが不可欠だと主張する。
そーくん
双方の立場によって、見えているメリットや重視するポイントが違うわけですね。
ボス
ここで世論の動きとして知っておきたいのは、知名度のある人の実践論は共感を呼びやすいという型だ。
そーくん
ああ、それまさに今回の現象そのものですね。説得力があるから一気に拡散する。
ボス
一方で、異論を持つ専門職層が、単に表で反論せず静観しているだけのケースも多いんだ。
そーくん
声が大きい賛同意見ばかりが目立って、サイレントマジョリティの懸念が見えにくくなると。
ボス
そういうことだね。では、今回の分析における注意点を一つずつ整理しておこう。一つ目は、単一の影響力ある実践共有が起点で、サンプルが賛同側に偏りやすい点だ。
そーくん
共感した人ばかりが声を上げている可能性があるわけですね。
ボス
二つ目は、プロのデザイナーからの強い反論は表面化しておらず、対立が潜在化している点。
そーくん
別解はあるかもしれないけれど、まだ議論として表に出てきていないと。
ボス
三つ目は、これがXで話題になったAI活用の一例に過ぎず、全体像ではない点だね。
そーくん
特定の文脈での成功事例であって、万能薬ではないということですね。
ボス
では次に、この見方がガラリと変わる条件も一つずつ挙げていこう。まず一つ目は、著名なデザイナーや専門家から体系的な反論が出された場合だ。
そーくん
設計上の問題点がロジカルに指摘されたら、評価は見直されますね。
ボス
二つ目は、この手法を導入した大規模プロダクトで、品質事故や運用破綻が共有された場合。
そーくん
規模が大きくなったときの耐用性が問われるわけですね。
ボス
三つ目は、既存のデザインツール側がAI連携を強化し、実装コストの差を埋めた場合だ。ツール側が進化すれば、わざわざHTMLモックを作る優位性は薄れるからね。
そーくん
なるほど。前提条件が変われば、最適解も簡単にひっくり返るんですね。
ボス
そういうことだ。新しい手法に飛びつく前に、自分の組織の状況を見極めることが肝心だよ。
そーくん
表面的なトレンドに惑わされず、本質を見抜く視点が大切だと分かりました。
ボス
ところでそーくん、旅行の計画で完璧な動く日程表を作って満足して、宿の予約を忘れてないかい？
そーくん
ギクッ……見栄えにこだわって準備を忘れたの、なんで知ってるんですか。まいりましたー！

この記事をポスト

何が起きたか

デザインツール×AIを検証

動くHTMLモック運用を公開

PdM・CTO層が共感