プロダクトデザインは変わりつつある

• AIツールがデザインシステムを直接活用してUIを生成するようになり、デザイナーの役割は単なる視覚設計から戦略と調整中心へ移行
• いま重要なのは**「誰が誰の仕事を奪うのか」**ではなく、プロセスがどう変わるのかという問い
• コード・PRD・要約のような見えない仕事は自動化しやすい一方、ユーザーが直接見て触れるUI・フローのような見える仕事は品質差が大きく、デザイン自動化の速度は依然としてエンジニアリングに追いついていない
• Figmaモックアップをコードに翻訳する工程が最大のボトルネックだったが、デザイナーがコード環境で直接デザインすれば、このハンドオフの無駄を完全に取り除ける
• AI時代のデザイナーの中核的価値はピクセル作業ではなくオーケストレーション能力：何を作るかを判断し、AIの出力を批判的に評価し、作業を指揮する力
• 小規模なエンパワードチームと機械可読なデザインシステムに投資する企業が、大規模なフィーチャーファクトリー型組織を圧倒するようになるだろう

---

プロダクトデザイン変化の背景

• 1999年にDreamweaverで最初のWebサイトを作って以来、筆者はPhotoshop・Sketch・Figmaなどでデザインし、開発者に渡すやり方で働いてきた
• 最近はClaude Codeを自社のデザインシステムにつなぎ、わずか3回のプロンプトで実際に動くUIを生成し、従来の視覚設計段階を飛ばした
• この経験を通じて、デザイナーの価値が実行能力から「センスと戦略的判断」へ移りつつあることを確認
• AIがデザインシステムを土台に**「プロンプト → 生成 → デプロイ」**の流れを実現し、プロダクトデザインの根本的な変化が進行中

誤った論点：人数ではなくプロセスの変化

• AIとプロダクト職種をめぐる現在の議論は、「デザイナーは仕事を失うのか」「エンジニアは代替されるのか」といった人数中心の縄張り争いにとどまっている
• 本当の問いはプロセスに関するもので、AIがこれらの機能をなくすのではなく、誰が、どれだけ速く実行し、ボトルネックがどこへ移るのかが核心
• コーディング、PRD作成、データ分析のような見えない仕事（invisible work）は、品質差がUIの裏に隠れるため自動化しやすい
  • コードが多少汚くてもアプリが動けば誰も気にせず、PRDがAIで生成されても問題定義が正しければ問題ない
• 一方、ユーザーインターフェース、フロー、体験のような見える仕事（visible work）は品質差が即座に表れ、ユーザーがすぐに認識する
• ビルドが速く安くなるほど、「どう作るか」ではなく**「何が作る価値があるのか」**が最も難しい問題になる
• AI支援デザインの速度向上はエンジニアリングに比べて遅れざるを得ず、この非対称性がプロダクト開発プロセス全体とチーム編成のあり方を再編していく

見える仕事：デザインは壁の向こう側ではなく壁そのもの

• エンジニアリングは配管にたとえられる — 壁の裏に隠れていて、蛇口から水が出れば内部構造は重要ではない
  • Boris Chernyは4〜5体のコーディングエージェントを同時に運用して400%以上の速度向上を達成し、シリコンバレーのエンジニアたちはコードを直接書くより、エージェントチームをオーケストレーションする方向へ移行している
• ソフトウェアデザインは壁そのものであり、蛇口であり、取っ手でもあるため、AIが作ったとしてもユーザーは見た目と使い心地に敏感に反応する
• AIは学習データにある標準やパターンには従えても、数十件のユーザーインタビュー、アンケート結果、利用分析、競合監査など膨大なユーザーリサーチに基づく意思決定はコンテキストが大きすぎて扱いにくい
• 取り込み問題（ingestion problem）というボトルネックがある — AIが大量のコードや会議要約を生成しても、人間がそれを読んで内面化し、批判的に評価しなければ知的な対話や判断はできない
  • コードレビューが実質的なボトルネックになっており、これは人間の速度という制約のため、どのモデルでも回避できない
• AIはコンテンツ生成と要約には優れるが、新しいものを創造したりセンス（taste）を持ったりする能力はまだ実証されていない

Figmaではなくコードでデザインする

• プロダクト開発の最大のボトルネックは、Figmaモックアップを本番コードへ翻訳するデザイナーと開発者のハンドオフ工程
  • ソフトウェアの絵を描き、ピクセルを磨き、エンジニアに渡すと、QAがモックアップとコードを照合し、タイポグラフィや間隔の不一致でPRを差し戻すという膨大な非効率がある
• AIはこのボトルネックを解消できるが、それはデザイナーがコード環境で直接デザインする場合に限られる
• 一部のデザイナーは実際にFigmaの契約を解約してAIツールへ移行しており、モックアップは製品そのものではなく、翻訳・レビュー・調整が必要な並行成果物にすぎないというのが核心的な論拠
  • Figmaで押し出すすべてのピクセルは、エンジニアがまったく別の媒体で守らなければならない約束であり、デザインツールが本番コードから遠いほど、ハンドオフで生じる無駄が増える
• Claude Codeにデザインシステムのリポジトリを指し示し、3回のプロンプトで動作するUIを生成した実験がこれを裏づけた
  • スケールした信頼性のためには堅牢なドキュメント、明示的なルール、エージェントのオーケストレーションが必要だが、土台はすでに整っている
• Monday.comエンジニアリングチームの事例：FigmaリンクをCursorに貼り付けた最初の試みでは、生成されたコードがデザインシステムのコンポーネントを使わず、色がハードコードされ、タイポグラフィがシステムのデフォルトを上書きしてしまった
  • 解決策としてデザインシステムMCP（Model Context Protocol）を構築 — コンポーネント、トークン、アクセシビリティ規則、利用パターンを機械可読にし、11ノードのエージェント型ワークフローでモデルに構造化されたコンテキストを与えた
  • エージェントが直接コードを書くのではなく、コードがどうあるべきかの理解を構築したうえで開発者のコーディングエージェントに渡すという**「魔法ではなくオーケストレーション」**のアプローチ
• AnthropicのデザイナーはClaude Codeとコンソール製品に自らフルリクエストを提出し、本番にデプロイしている — 2026年2月時点で、すでに現実になっている

人間に残るもの：オーケストレーションと判断

• AIがコード生成、PRD作成、リサーチ要約、インターフェースのプロトタイピングをすべて行えるなら、人間に残るのはオーケストレーションだ
  • モデルは十分に有能であり、ボトルネックはキーボードの前の人間 — 何を頼むか、作業をどう分割するか、モデルの結果をいつ却下するかを知る能力が重要
• Kyle Zantosは勤務時間の70%をターミナルで過ごすデザイナーで、4カ月前の推奨すらすでに古くなるため、具体的なツール設定より哲学とアプローチを学ぶことが重要だと強調する
• SAPのChief Design Officer、Arin Bhowmickは、見た目に洗練されたインターフェースが信頼できない出力、不透明な意思決定、エッジケースでの脆い挙動といった深層の問題を隠してしまう可能性を指摘
  • デザインリーダーは表面的な品質ではなく、信頼、明確さ、信頼性を第一級のデザイン成果物として扱うべきだ
• Vlad Derdeiceaによれば、デザインリードの時間の約**80%**はコミュニケーション、アラインメント、正当化に費やされ、実際のハンズオンのデザイン作業に使えるのは20%だけ
  • すべてのデザイン判断には「正当化税（justification tax）」がある — 他分野なら短い会話で済む選択について、説明し、文書化し、守るためにかかる時間のこと
  • AIが狙うべきなのはモックアップ作業ではなくこの80%であり、議事録の統合、ステークホルダー向けコミュニケーションの下書き、リサーチ要約、意見ではなくデータで議論を解決するための高速プロトタイプが対象になる
• Jan Tegzeのフレーミング：現在の仕事をよりうまくこなそうとするのではなく、人間の限界ゆえに存在するドメインの制約を見つけ、エージェントで取り除くべきだ — いまの作業を加速するのではなく、以前は不可能だったことを可能にする方向
  • 「エージェントと競争するのではなく、自分とエージェントの両方を必要とする新しい能力を生み出すこと」
• 経験5年以下のジュニアデザイナーはより大きなリスクにさらされている — AI出力を評価する判断力や、モデルの誤りを見抜く経験が不足しているためで、スキルの最低ラインが上がっている

小規模チーム、大きなレバレッジ

• ほとんどのソフトウェア企業の構造は現在の状況に合っておらず、専任のデザイン支援の有無にかかわらず各スクワッドにPMを置くPM過剰のフィーチャーファクトリーになっている
  • PMがZIRP時代に急増したのは、収益に近く、組織の複雑性に応じて人員が膨らみやすいから
  • Marty Caganはこれを**「プロダクトマネジメント劇場」**と呼ぶ — ロードマップを作り、スタンドアップを回すだけの、高給取りのプロジェクトマネージャーにすぎない非効率なPMの過剰
• Andrew Ngはダボスで、AIがエンジニアリング生産性を爆発的に高めれば、PM対エンジニアの比率は1:8から1:1方向へ反転すると予測した
  • AIエージェントが本番コードの大半を書くようになれば、広いエンジニアリング基盤は縮小し、仕様化と判断が希少資源になる
• Airbnbはプロダクトマネジメントとプロダクトマーケティングをひとつの**「フルスタック」役割**に統合
  • Brian Chesky: 「製品についてどう語るかがわからなければ、製品を作ることはできない」 — ストーリーテリングと対外コミュニケーションをPM職の第一級の要素へ引き上げた
  • デザイナーを、エンジニアとともに製品を導く**「アーキテクト」**へ格上げし、チケットを受けて処理する下位サービスではない役割にした
  • これまでPM人数を膨らませていた調整業務は、専任のプログラムマネージャーへ移管
• Appleの機能別組織モデルに似ている：専門家が専門家を率い、CEOが統合ポイントとなり、事業部を運営する「ミニCEO」型PMは存在しない
• AI時代の理想的なチームは、エンジニア2〜3人、PM1人、デザイナー1人の小規模なエンパワードチーム
  • デザインシステムが中核インフラとなり、コード内のデザインシステムとドキュメントがなければ、AIはUIと実装について誤った判断を下す
  • 機械可読なデザインシステムと小規模なエンパワードチームに投資する企業が、15人スクワッドと3段階承認を維持する企業を圧倒するだろう

複利効果：オーケストレーターとピクセルプッシャーの格差

• Claude Codeでデザインシステム上で動く画面を生成した実験以降、よりよいドキュメント化、厳格なコンポーネント規則、明確な組み合わせガイドラインによって継続的に改善している
  • ラウンドを重ねるごとに速くなり、本番投入可能な状態に近づいており、モデル改善・スキル洗練・指揮能力向上のすべてが複利で蓄積していく
• **「AIをオーケストレーションするデザイナー」**と「Figmaでピクセルを動かすデザイナー」との格差は、12カ月以内に巨大になる見込み
  • ピクセルプッシャーの能力が低いからではなく、オーケストレーターが根本的に異なる速度とスコープで動くからだ — 他の人がハンドオフ会議用のモックアップを出している間に、動くUIをデプロイしている
• 筆者はチームにこのやり方を教えている。仕事が消えるからではなく、センス、判断力、作業を指揮する能力が、絵を描く能力より重要な職業へ変わりつつあるからだ