最終更新2026年8月9日 21:16

テック76

Figmaより動くHTMLモック

アルのけんすう氏が、FigmaやPencilの代わりにClaude Codeで動くHTMLモックを作り、デザイントークンとGitHubで確定管理する運用に落ち着いたと報告した。実装距離の短さとPdM判断力の増幅を評価する声が多い一方、本人もプロの反対意見を歓迎しており設計職の役割論が残る。

拡散の起点2026-08-08夜

けんすうがHTMLモック運用を公開

Figma/Pencil代わりにClaude Codeで動くHTMLモック、トークンとGitHub管理に落ち着いたと投稿。

期間: 直近10時間(運用共有の余波)信頼度: (起点は個人の運用報告。組織一般化にはサンプル不足)
一方的
ポジティブ50%42–56%
中立36%28–42%
ネガティブ14%10–20%
  1. そーくん

    Figmaより動くHTMLモックの話題、第2回ですね。

  2. ボス

    けんすう氏のClaude Codeを使ったモック運用の話だね。ポジティブな反応が多かった。

  3. そーくん

    投稿されてから、具体的にどんな流れで広がったのか気になります。

  4. ボス

    直近までの動きを時系列で整理したから、まずはタイムラインを確認してみよう。

何が起きたか

  1. 拡散の起点2026-08-08夜

    けんすうがHTMLモック運用を公開

    Figma/Pencil代わりにClaude Codeで動くHTMLモック、トークンとGitHub管理に落ち着いたと投稿。

  2. 2026-08-09

    賛同と役割論

    PdM導線としての有用性への賛同と、プロ視点では別解があり得るという留保が並んだ。

  1. そーくん

    単にツールを変えたという話以上の盛り上がりを感じますね。

  2. ボス

    道具の変更というより、プロダクトマネージャーの動き方の話として捉えられているね。

  3. そーくん

    専門家の間でも、見方がいくつか分かれているんでしょうか。

  4. ボス

    そうだね。主流の評価と現場ごとの視点の違いを、記事本文で読み解いてみよう。

議論の現在地

主流派の視点
静的デザインツールより、本番トークンで動くHTMLモックの方が実装距離が短くPdMに効く
その他の視点
  • 確定と実装タイミングを道具で分ける管理論
  • モックを本番に追随させない割り切り
  • デザイナー不足組織では特に効くという現場共感
  • プロのデザイナー/エンジニアから見ると最適解ではない可能性
目立つ論者
  • @kensuu
  • PdM・CTO層
  • 個人開発者
  • デザインツール利用者
  1. そーくん

    賛否のバランスって、どれくらいの割合になっているんですか?

  2. ボス

    前回の傾向を引き継ぎつつ、ネガティブはかなり低い水準に収まっているよ。

  3. そーくん

    推進する声以外にも、冷静に観察している層もいそうですね。

  4. ボス

    その通り。陣営ごとの比率と世論の分布データを一度チェックしてみよう。

世論の分布

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

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

  • 動くモック推進派40–55%
  • 専門職最適解留保派20–32%
  • 管理分離実務派15–25%
推定下限推定上限

ポジ / 中立 / ネガ 集計

陣営をスタンス別に統合 · 起点への賛同が優勢。残差をポジに

50%
36%
14%
ポジティブ 42–56%(動くモック推進派)中立 28–42%(専門職最適解留保派、管理分離実務派)ネガティブ 10–20%
テーブルビュー(グラフと同じデータ)
陣営スタンスシェア中心的主張
動くモック推進派ポジティブ40–55%トークン共有の動くHTMLは実装コストを下げ、PdMの判断速度を上げる(@kensuu、@sakumenx、@shintaro_campon)
専門職最適解留保派混在20–32%PdM視点の最適化であり、プロのデザイン/エンジニアリング工程では別の方が良い場合がある(@kensuu本人の留保、専門職リプ層)
管理分離実務派中立15–25%ツール論争より、確定管理と着手管理を分ける設計が本質だ(運用に共感するCTO層)
  1. そーくん

    デザイナーの役割がなくなるんじゃないか、なんて意見も出そうですね。

  2. ボス

    まさにそこが白熱している論点の一つだね。役割の境界線を巡って議論がある。

  3. そーくん

    Figmaが不要になるのかどうかも気になります。

  4. ボス

    双方の言い分がどう噛み合っていないか、最後の議論パートで見ていこう。

進行中の論争

論点1

Figmaはまだ必要か

A側 · 代替可

動くHTMLとトークンがあればデザインツール往復は無駄が多い

B側 · 役割残

探索・合意形成・ブランド設計では専門ツールが残る

根拠: けんすう報告と本人のプロ向けツッコミ歓迎

論点2

これはデザイナー不要論か

A側 · 不要論ではない

PdMが判断力を増幅する話で職種否定ではない

B側 · 実質侵食

モック制作の主戦場がコード側に移り役割境界が変わる

根拠: デザイナー不足組織の感謝と専門職留保の並存

主なポスト

kensuu@kensuu·起点の運用報告サイトのデザインの開発、いろいろな試行錯誤をしてたんですが、結局は FigmaやPencilの代わりに、Claude Codeで「動くHTMLモック」を作ってしまう、というので落ち着きました。 CSSは本番と同じデザイントークンだけで書くので、エンジニアはほぼコピペで実装できる。デザインツールとAIをかけ合わせると、細かい文字の変更とかに時間がかかるし、実装時にも画像から起こさないといけなかったりしてコストが高いんですよね。 んで、管理のコツは「デザインが確定したか」と「いつ実装するか」を別の道具で管理すること。 確定したか → GitHubが管理(mainにマージ=確定) いつ実装するか → ROADMAPの表で「次に実装」「あとで実装」「構想中」に分けて管理 マージは「実装してよい在庫に入れる」だけで着手指示ではなく、優先順位の変更は表の書き換えだけでGit操作ゼロ。構想段階のものはDraft PRに【構想・実装しない】と付けて寝かせておきます。 ローカルで方針が固まったらGitHubにPushして、その時にNotionのタスクもスクショと一緒にClaude Codeに起票してもらう。 実装が終わったモックは本番に追随させない(以降の正は本番コード)と割り切っているのもポイントで、同期し続けるのはデザイントークンとルール集だけ。ドキュメントを2重管理すると必ずズレて、AIと人間の両方を騙すので。 デザインをするときも、Codexと繋げておいて、画像とかまで作っておいてもらうと、それなりの見栄えのものができるし、gifアニメとかにして少し動きがあるページも作れる。 また、任意でCodexによるレビューを走らせるようにしておくと(スクショとHTMLとデザインルールを渡して、最後にPASS/FIXの判定が出る)、間違っているところや使いづらいところを指摘してくれるので、クオリティも上がる。 というのが一番楽で早いなと思いました。 大事なのは、僕はPdM的な立場なので、デザイナーでもエンジニアでもないというところ。その状態で、ひたすらにPdMの判断力を最大限、クオリティ上げるためにClaudeを使うということかなあ、と思いました。Figma代替のHTMLモック運用と管理分離を詳述した起点
kensuu@kensuu·留保の明示プロのエンジニアやデザイナーさんからしてみたら「それじゃない方がいい」というのがありそうなので、ツッコミやアドバイスは大歓迎です!本人が専門職視点の反対を歓迎し、一般解ではないと示している

編集部まとめ

  1. そーくん

    一通り記事を読みましたが、今回の議論って結局どう捉えればいいでしょうか。

  2. ボス

    ここまでの流れを踏まえると、まずは成果を出した一つの事例として見るべきだね。

  3. そーくん

    単一のプロダクトマネージャーの成功談を、大規模組織にそのまま当てはめるのは危険ですか?

  4. ボス

    そうだね。これがそのまま大型のデザインシステム組織に適用できるわけではない。

  5. そーくん

    あくまで特定のWebサイト開発フローにおける工夫という話なんですね。

  6. ボス

    うん。「Figmaが完全に不要になる」という一般論として受け取るのも違うよ。

  7. そーくん

    反対意見もすごく巻き起こっているのかと思っていました。

  8. ボス

    本人が議論を歓迎した割には、直接の批判リプライが殺到しているわけでもない。

  9. そーくん

    ツール市場全体が揺れている、という話でもなさそうですね。

  10. ボス

    対立が際立つ論点を選んで議論しているだけで、業界全体の総意ではないからね。

  11. そーくん

    前回と比べると、世論の数字や空気感にはどんな変化がありましたか?

  12. ボス

    前回のポジティブ7割近くから今回は5割前後に落ち着き、中立の割合が増えたね。

  13. そーくん

    勢いで持ち上げる段階から、冷静な実務議論にシフトした感じでしょうか。

  14. ボス

    まさに。各陣営の主張も整理されてきている。推進派は判断速度の向上を重視する。

  15. そーくん

    動くコードがあれば、PdMと開発者のコミュニケーションが最速になりますもんね。

  16. ボス

    一方、専門職の留保派は、デザインや設計の深い検証には別のツールが良いと言う。

  17. そーくん

    プロのデザイナーとしての専門性が必要な場面は確実に残りますよね。

  18. ボス

    さらに実務派は、確定管理と着手管理をどう分けるかという運用の枠組みを見ている。

  19. そーくん

    ツールそのものより、運用の設計こそが本質だという立場ですね。

  20. ボス

    ここで一つ覚えておきたいのは、SNSでは極端な意見ほど拡散されやすいという型だ。

  21. そーくん

    それ、まさに「Figmaはもう不要」みたいな切り出し方に引っかかっちゃうやつですね。

  22. ボス

    そう。実際の現場の多くは静観しているのに、一部の主張が全体の空気に見えてしまう。

  23. そーくん

    ネットの議論を見るときは、そのグラデーションを意識しないとですね。

  24. ボス

    では、今後この見方が変わるとしたらどんな条件があると思う?

  25. そーくん

    プロのデザイン組織から「やっぱりダメだった」という反論事例が出たときとかですか?

  26. ボス

    そうだね。体系的な反論ケーススタディが出てくれば評価は変わる。 あとはAIツール側に、デザインの合意形成を行う標準機能が載った場合だね。

  27. そーくん

    ツール自体が進化して合意形成まで巻き込んだら、話が変わりますね。

  28. ボス

    もう一つは、この運用が原因で重大な実装品質の事故報告が出た場合かな。

  29. そーくん

    現場の安全性が脅かされたら、慎重論が一気に強まりそうです。

  30. ボス

    そーくんも自分の仕事の進め方を、AIに全部投げてモック化してみたらどうだい?

  31. そーくん

    まいりましたー、僕の雑な雑務をモックにしたら怒られちゃいますよ!