AnthropicのClaude Designは、単なるFigma対抗ツールではなく、Claude CodeやClaude for Workと連動する新しい制作ワークフローの一部である。本動画は、ピッチデック、説明動画、3Dデモ、デザインシステム、管理画面、モバイルアプリ試作など、従来は専門ツールや専門職を必要とした作業がコードとして生成されるようになった変化を解説する。中心にある主張は、モックアップという中間成果物が消え、試作品そのものが本番に近い形で動く時代に入ったということである。さらに、PM、デザイナー、エンジニア、創業者それぞれの役割や、チーム構造そのものがどう変わるのかを論じている。
Claude Designが示す本当の変化
AnthropicがClaude Designを発表しました。では世界はどう反応したのでしょうか。株価で反応しましたよね。Figmaの株価が急落しました。
しかし、報道の中心がFigmaであるにもかかわらず、この発表でFigmaの話は最も面白くない部分です。本当の話は、Claude Designが、モックアップから本番への引き継ぎ全体を静かに終わらせようとしている、Anthropicの連携スタックにおける三つ目のピースだということです。
これから数分で、Claude Designで実際に作れる八つのものを紹介し、それがClaude CodeやClaude for Workとどう組み合わさるのかを示し、さらにGoogleがすでにStitchの変更によって反撃を始めている理由を説明します。
つまり、これはFigmaの葬式ではありません。もっと大きな話です。
プロダクトチームが20年以上にわたり、これから作ろうとしているものを伝えるために作ってきたモックアップというものが、まもなく絶滅しようとしています。そして、あなたのチーム構造の大部分は、LLMによって実質的に削除されたコストを前提に作られています。
では、私が何を言っているのかを見ていきましょう。五つの具体的な要素に分けて進めます。
一つ目は、Claude Designで作れる八つのものについてです。以前なら別々のツールが必要だったものです。もちろん八つだけではありません。Claudeが提供する範囲の広さを感じてもらいたいのです。
二つ目は、Claude CodeとClaude for Work、そしてDesignが、注意すべき連携パターンの中でどのように組み合わさるのかです。
三つ目は、なぜClaude Designが欠けていたピースなのか。そしてGoogle Stitchがそこにどう関わってくるのかです。
四つ目は、PM、デザイナー、エンジニア、創業者といった役割ごとに何が変わるのかです。
そして五つ目は、それがチーム構造に何を意味するのかです。
まずは、その八つのものから始めましょう。
Claude Designで作れる八つのもの
最初に作れるものは、ライブで埋め込まれたAIを備えたピッチデックです。
あなたの1枚企画書をClaude Designに貼り付けて、Series A向けの12枚構成のピッチデックを作るように依頼します。そして7枚目、つまりプロダクトのデモを見せるスライドに、実際に動くチャットボットを埋め込むようにします。
Claudeはそのデック全体を生成し、あなたの実際のデザインシステムを適用できます。そして7枚目のチャットボットは、VCがミーティング中に実際に使える動作するチャットボットです。スクリーンショットではありません。録画でもありません。デックの中に入ったライブデモです。
これは、長年多くのスタートアップチームが使ってきた、ピッチデックとデモ動画という一連の動きを置き換えるものです。
ここで言いたいのは、画面にチャットボットを置くだけで巨大なシードラウンドを獲得できる、ということではありません。そういう話ではありません。重要なのは、Claude Designがプレゼンテーションにかかるコストを圧縮し、創業者であるあなたが、プレゼンそのものの使い勝手よりも、自分のアイデアを磨き、それを鋭くすることに多くの時間を使えるようにするという点です。そこが重要なのです。
二つ目のユースケースは、コードでレンダリングされるアニメーション付きのプロダクト説明動画です。
これが重要なのは、生成後に最初からやり直すことなく、カラーパレットを調整したり、字幕のオンオフを切り替えたり、動画全体のタイミングを調整したりできるからです。
モーショングラフィックスの外注先に頼めば、数週間かけて作ってもらうような45秒のアニメーション説明動画がありますよね。それが5分でできます。そしてコードなので、いつでも別のスタイルで再生成できます。
これは実質的にAfter Effectsを置き換えます。外注作業を置き換えます。
さらに、3Dコンポーネントを使うこともできます。プロダクト設定ツール、データグローブ、ライブのカスタマイズスライダーを備えた軌道制御ビューアなどです。そうしたコードでレンダリングされる三次元効果によって、非常に派手なデモを作れるようになります。
この種のものは、以前ならWebGLエンジニアリングに3週間かかっていました。それが、すべての配線が済んだ状態で、そのまま動くものとして出てくるのです。
ピッチデックやランディングページに、物理プロダクトのインタラクティブな3Dモックアップを入れたいと思ったことがあるなら、これは自分でWebGLコードを書かずにそれを実現できる初めてのツールです。
四つ目は、既存のコードベースから抽出されるデザインシステムです。
Claude Designに自分のリポジトリを指定するか、CSS、Tailwindの設定、あるいはFigmaのエクスポートをアップロードします。すると数分後には、デザインシステムファイルができます。タイプスケールやコンポーネントパターンがすべて、Claudeがこれまで見たことのないコードから抽出され、そのワークスペースで今後生成するすべてのプロジェクトに自動で適用されるようになります。
これは以前なら、数週間がかりのデザインオペレーションのコンサル案件でした。
正直に言うと、これが完璧ではないという話は私もしてきました。別の動画で、これを試したときにClaude Designが、頼んでもいないのに私のロゴを勝手に変更してしまう問題があったと話しました。
しかし、そうした面倒はさておき、大きなアイデアを見てほしいのです。以前なら、デザイナーが既存のぐちゃぐちゃなコードファイル群からデザインシステムを作るために数週間かけていた作業が、今では一瞬でできるようになりました。
もちろん、いくつか問題は出ます。見直す必要があります。少し修正する必要があります。現時点では、この利用に関してトークンの制約もあります。Anthropicが計算資源の問題を解決していけば、きっと楽になっていくでしょう。しかし大きな流れは明らかです。多くのチームにとって、デザインシステムを設計する容易さという点で、これは大きなブレークスルーです。
五つ目は、Webキャプチャとリスキンです。
Claude DesignのWebキャプチャツールを使って、競合のランディングページを取得します。Claudeはそのページの構造、コンテンツ、流れを読み取り、それをあなた自身のデザインパターンで再レンダリングします。
数分で、あなたの分野における最良の競合事例をもとにした、ブランド化された参考プロトタイプが手に入ります。
これは、デザイナーがインスピレーションボードを作り、さらにページをゼロから作り直す作業を置き換え得るものです。
ここで、あなたがデザイナーを置き換えると言っているのか、と言いたくなるかもしれません。そうではありません。私が言っているのは、このツールがデザイン機能の大きな部分を加速させることで、デザイナーがデザインの核心に集中できるようにするということです。デザインの核心とは、ユーザーにとって意味のある形で、特定の文脈の中にプロダクトを位置づけることです。
六つ目は、インタラクティブなダッシュボードとデータビューです。
共有可能なURLとして、ライブで操作できる分析ビューを作れます。Tableauからスクリーンショットを取り出し、それをGoogleドキュメントに貼り付け、スプレッドシートで共有したり、何であれそうした作業をしたりする代わりに、一度作ればチャートが自動で更新されます。
これは取締役会向けメモ、投資家アップデート、社内レビューに使えるユースケースです。多くのチームが使っている、BIツールのスクリーンショットを貼るやり方を置き換えます。
七つ目は、社内管理ツールです。
これらは非常に素早く出荷できます。たとえばモデレーションキュー、オペレーションダッシュボード、管理パネルなどです。私が知るどの会社にも、こうした社内ツールのバックログが、半分完成した状態で積み上がっています。顧客向けの仕事が常に優先されるからです。
Claude Designは、まさにこの種の作業を素早く片づけるために作られています。そのバックログは出荷されるか、Claude Designが非常に素早く組み立て、コネクタにつないで実際にライブ状態を保つ、使えるものに置き換えられるかのどちらかになります。
八つ目は、静的な画面ではなく、実際の状態遷移を備えたモバイルアプリのプロトタイプです。画面間の本物の遷移です。空の状態、エラー状態、データが少ない状態、多い状態など、あらゆる状態がデフォルトで描かれます。
プロトタイプの準備ができたら、あとはそれをバンドルとしてClaude Codeに渡し、コード化してもらうだけです。
以上が、何が可能なのかを示すために私が選んだ八つの例です。ライブ要素を備えたピッチデック、説明動画、3Dコンポーネント、コードベースからのデザインシステム、Webキャプチャ、ダッシュボード、管理ツールなど、リストはまだ続きます。
これらはすべて、以前なら専用ツールか専門家のどちらかを必要としていました。そしてそこで作られるものは、常に最終的に出荷するものの粗い近似にすぎませんでした。
Claude Designは、それぞれを、それが存在することになる媒体上で動くコードとして生成します。これこそがモックアップの死です。
ただし、この八つのユースケースはツールの幅を示してはいますが、本当の話はそこではないと私は思います。本当の話は、Claude Designが、Anthropicの連携スタックにおける三つ目のリリースだということです。
そのパターンを見るには、まずCodeとClaude for Workを見る必要があります。
Claude Code、Claude for Work、Claude Designが作る連携スタック
この三つのプロダクトは、どのように組み合わさるのでしょうか。
三つすべてが同じ仕組みで動きます。あなたは欲しいものを自然言語で説明します。Claudeは動作する成果物を生成します。あなたは会話を通じてそれを改善します。そして準備ができたら、スタック内の次のプロダクトへ引き渡します。
三つの間で変わるのは、得られる成果物の種類です。それを得る方法自体は、実は変わりません。
最初に来たのは、2025年半ばのClaude Codeでした。あなたは作りたいものを説明します。Claudeがコードを書きます。テストに合わせて反復します。プルリクエストを出荷します。
生成されるコードは、そのまま出荷されるコードです。中間の1か月はありません。
Claude Codeを本気で使ってきたエンジニアたちは、このツールを単なる高速なオートコンプリートとして扱いませんでした。実際には、とりわけ昨年12月以降にエージェント機能を獲得してからは、ワークフロー全体をそれ中心に再構築しました。
次に来たのが1月のClaude for Workです。同じ動きがナレッジワークに適用されました。あなたは成果を説明します。Claudeがファイルを読み、複数ステップのタスクを実行し、実際の成果物を生成します。
6か月分の会議メモから作られた取締役会向けデック。50本の異なる記事から作られた競合分析。ファイルシステム内の大量の混沌から再編成された研究ディレクトリ。
Codeと同じパターンです。ただし、ソフトウェアではなく文書や分析に適用されているだけです。
Claude Designは、同じパターンを視覚的な成果物、プロトタイプ、デック、アニメーション、3Dなど、先ほど見てきたすべてのものへ拡張します。仕組みはCodeやClaude for Workと同一です。
新しいのは、プロダクトチームがプロジェクト初期に最も多くの時間を費やす視覚的な作業が、誰でも数分で作れるものになったということです。
そして重要なのはここです。
過去20年間、プロトタイピングは仕様と実装の間にある独立したフェーズでした。通常はデザイナーという専門家が担い、あとで捨てられる成果物を作っていました。プロトタイプは、何を作るべきかを見極めるために存在していました。その後、まったく別の媒体で別のものを作り、あらゆる段階で翻訳ロスが発生していました。
このモデル全体は、プロトタイピングが高価で、コードはさらに高価だったから存在していました。現実的なインタラクティブモックアップを作るには、デザイナーが何日もかける必要がありました。だからデザイナーは、何をプロトタイプ化するかを配分しなければなりませんでした。
一つには、プロトタイピングに長い時間がかかりました。もう一つには、プロトタイプは出荷するものとは別物でした。
この二つの事実が、いま変わりました。
Claude Codeは、エンジニアリングの出力をプロトタイプにしました。Claude for Workは、ナレッジワークの出力をプロトタイプにしました。Claude Designは、視覚的な出力をプロトタイプにします。
プロトタイプは、もはや対象物の近似ではありません。それは実際にそのもの、あるいはそこから一つ引き継ぐだけのものです。プロトタイプと本番コードの間に残る唯一の分離は、あなたがそれをローンチすると決めるかどうかだけです。
これがパターンです。三つのプロダクト、一つの新しい動きです。
では、なぜDesignが、この戦略を読み取れる形にする特別なピースなのかを説明しましょう。そこから、私たちがどこへ向かっているのかが見えてきます。
Claude Designが欠けていたピースだった理由
Design以前、Anthropicのスタックには明確な隙間がありました。
チャットは思考を扱いました。Claude for Workはナレッジワークの実行を扱いました。Codeはソフトウェア実行を扱いました。それがプロトタイプであれ本番コードであれ、です。
しかし、プロダクト作業の多くは視覚的な成果物から始まります。スケッチ、モックアップ、デック、粗いプロトタイプ画面です。視覚的な成果物は、私たちが互いにアイデアを伝える方法です。PMはそれを使って機能を伝えます。デザイナーはそれを使って方向性を示します。創業者はそれを使って、まだ存在しないプロダクトを売り込みます。
Design以前、Anthropicはそのワークフローの中にいませんでした。
しかし、Designがこのような形で機能することには、さらに深い理由があります。それは、Sam Henry Goldがローンチ直後の投稿で指摘したことに関係しています。
Figmaは10年かけて、高度なデザインプリミティブを作ってきました。コンポーネント、変数、モード、プロップス、ピクセルレベルのデザイン作業のための美しい抽象化です。しかし、それらのプリミティブはFigma独自のものでした。
それらは、現在デザイン生成の大部分を担っているモデルの訓練データには入っていませんでした。LLMはFigmaファイルではなく、コードで訓練されました。
だからフロンティアモデルがデザインに非常に強くなったとき、それらが強くなったのは、実際に学習している媒体においてでした。つまりコード、HTML、CSS、SVGなどです。
AI支援デザインにおいて、コードが事実上の信頼できる情報源になりました。なぜなら、AIが知っているのはコードだからです。
Claude Designは、この点を完全に受け入れています。出力は、エンジニアが再構築しなければならないUIのピクセル近似ではありません。それは、実行される媒体で、すでに書かれているUIです。
だからClaude Codeへの引き継ぎが非常にきれいに機能します。翻訳レイヤーがありません。デザイン成果物は、すでに本番形式になっています。
Claude Designは、主にFigmaの競合ではありません。Figmaはしばらくの間、本番グレードのデザイン作業における地位を保つでしょう。大規模なデザインシステム、コンポーネントライブラリの保守、プロダクトライフサイクルの中盤にあるクラフト作業です。Figmaは、その中盤を非常に粘着性の高い形で築いてきました。
Claude Designが競合するのは、始まりの部分です。素早い探索、初期プロトタイピングです。そしてClaude Codeを通じて終盤に直接接続します。Figmaが最も強い中盤を飛ばすのです。
そこが手がかりです。
Anthropicの最高プロダクト責任者であるMike Kriegerは、Designの出荷数日前にFigmaの取締役を退任しました。
ですから私の見立てでは、Figmaは現実には今のところかなり粘着性があるように見え、市場はFigmaのいわゆる終焉に過剰反応している可能性が高いものの、Anthropic側には、デザインの中盤の大部分を削除するビジョンがあります。なぜなら、それは根本的に非効率だからです。
本質的には、コードの上に抽象化を築いているわけですが、本来はコードの中でデザインすべきなのです。それがClaude Designのビジョンです。
現時点で完全にそこまで到達しているわけではないかもしれません。私はむしろ、初期のスケッチ用プロトタイピングツールとして見ています。より単純なプロダクトでは機能すると思います。より複雑なものになれば、特に現在のトークン予算の制限もあって、いくつか課題が出るでしょう。
しかし、彼らが向かっている先はそこです。
そして彼らは非常に速く出荷します。6か月与えれば、Figmaが伝統的に所有してきたデザインプロセスの中盤が、より強くなったClaude Designツールによって、どんどん空洞化されていくのを見ることになるでしょう。
Google Stitchの反撃と、AIデザインの標準化競争
Google Stitchを作っているGoogleも、このローンチを見過ごしてはいません。
Google Stitchは、このローンチが起きてほぼすぐに、design markdownと呼ばれるものを導入しました。それは、デザイントークン、タイプスケール、コンポーネントルールを記述するプレーンテキストのMarkdownファイルで、AIは毎回の生成の前にそれを読むことができます。
Claude Designのローンチからわずか数日後、Googleはその仕様をオープンソース化しました。これにより、どのツールでもそれを読み書きできるようになりました。つまり、色の意図、アクセシビリティ検証など、すべてをその形式に組み込み、オープンに共有できるということです。
これはAnthropicとは異なる賭けです。Googleはオープンソースと標準化に賭けています。ただし、競争戦略としては似ています。Google Stitchは、共有可能性と引き継ぎで競争する必要があることを理解しています。なぜならClaude Designが、プロダクトの構成においてそこを非常に強調していたからです。Claude Codeへまっすぐ進めるわけです。
ですから、これがここでのGoogleの答えです。そして非常にGoogleらしい答えですよね。仕様を公開し、それを広く普及させ、その中でモデルとしてのGeminiの品質で競争するのです。
Anthropicは自分たちのハーネスに賭けています。統合に賭けています。これまでのところ、それは彼らにとって成果を出してきました。
コードベースからデザインシステムを自動で抽出できます。Anthropicスタック内のあらゆる成果物タイプにそれを適用できます。そしてClaude Codeに引き渡せます。
Google Stitchは、それよりはるかに狭いものです。WebとモバイルUIは扱います。デックは扱いません。アニメーションも扱いません。3Dも扱いません。しかし、デザインにおけるGeminiの力を示す、Googleらしい無料ツールです。
実際、Geminiがハーネスの中に入っている数少ない例の一つです。これはここ数か月、OpenAIとAnthropicがモデルにハーネスを付ける方向へ進む一方で、Geminiにとって大きな問題の一つでした。Googleはそうしてきませんでした。そして報道によれば、Googleはいまそれを変えるための大きな取り組みの最中にあります。
しかし現時点では、Stitchのようなツールは非常に少ないです。そしてGeminiとのやり取りの大半は、ほとんどの場合チャットのようなインターフェースを通じて行われます。StitchやNotebookLMなど、いくつかの例外はあります。
これは非常に興味深い違いです。そして私は、Googleが今後数か月でその差を埋め始めるのではないかと見ています。
とはいえ現時点では、StitchがClaude Designに最も近い競合でしょう。そして彼らの進化の仕方は、注意しなければClaude Designに昼食を奪われると考えていることを示唆しています。
つまり、根底にある変化については、両社が同意しているわけです。
少し引いて見ると、AIが扱う媒体はFigmaファイルではなく、コードとMarkdownです。両社が意見を異にしているのは、その堀がどこにあるのかです。
Googleは、堀は利便性だと考えています。Anthropicは、堀はスタックだと考えています。Googleはそれを無料で使いやすいものにしたい。Anthropicは、堀はプロシューマー向けの真剣な作業であり、スタックに統合されていることだと考えています。
ここで、実際に仕事をする人たちにとって、それが何を意味するのかという話に移ります。
PM、デザイナー、エンジニア、創業者の役割はどう変わるのか
役割ごとに何が変わるのでしょうか。
ここでは四つの役割を扱います。PM、デザイナー、エンジニア、創業者です。変化の現れ方はそれぞれ異なりますが、根底にある変化は似ています。
アイデアを持ってから、見せられるものを持つまでの距離が、今や数分に縮まりました。そして見せるものは、出荷される成果物です。あるいは、そこから一歩手前のものです。これは違いますよね。新しいことです。
まずPMです。
PRDはデフォルトの成果物ではなくなります。機能をプロトタイプ化する方が、ドキュメントよりも、自分が何を求めているのかをはるかに明確に伝えられます。そしてプロトタイピングのコストは、今やほぼゼロです。
Designから最大限の価値を引き出すPMは、まずプロトタイプを作り、それを使って議論を進めます。エンジニアはそれをもとにスコープを見積もります。デザイナーはそれを批評します。最終的に、それが何を作るかの判断を形作ります。
いまや、ユーザーストーリーや受け入れ条件をDesignに貼り付けることができます。それを満たすフローを作るようにプロンプトを出し、できあがったプロトタイプをJiraに入れれば、それで完了です。
PRDはデフォルトの成果物ではなくなります。機能をプロトタイプ化することは、ドキュメントを書くよりも、自分が望んでいることをよりよく伝えます。そしてプロトタイピングにかかるのは数分だけです。
Designから最大限の価値を得るPMは、まず動作するプロトタイプを作り、それを全員が議論する対象として使います。エンジニアはそれをもとにスコープを見積もります。デザイナーはそれを批評します。リーダーシップは、それを作るかどうかを判断します。
具体的なワークフローは次のようなものです。
ユーザーストーリーと受け入れ条件をDesignに貼り付けます。それらを満たすフローを作るようにプロンプトを出します。空の状態、エラー状態、読み込み状態など、すべての状態をデフォルトで生成します。単なる生の仕様ドキュメントだけではなく、プロトタイプをJiraチケットに入れます。もっとも、私は仕様ドキュメントも含めるでしょう。そしてそれで完了です。
もしその機能にAIの挙動が関わるなら、実際のモデル呼び出しをプロトタイプに直接埋め込み、それがどのように動くのかを示します。
最終的には、実際に使える、コードでできた完全に動作するプロトタイプになります。そして、それを使って本物のエージェント作業を進めることができます。
ちなみに、それはエージェントが読めるのかと思っているなら、答えはイエスです。そのコードは仕様を補完し、エージェント駆動開発のパターンをより正確にします。
次にデザイナーを取り上げましょう。
何よりもまず、デザイナーの注意を配分する時代は終わります。デザイナーは以前、複数の方向性をプロトタイプ化するのか、探索するのか、決め打ちするのかを選ばなければなりませんでした。そうしたトレードオフはもう重要ではありません。1時間で10通りの方向性を出すことは、ごく普通になるからです。
そのため、クラフトは上流へ移動します。モックアップを作る時間は減り、どの方向性が良いのか、なぜ良いのかを判断する時間が増えます。
Jenny WenはAnthropicでデザインを率いています。彼女はFigma出身で、FigJamとSlidesを率いていました。彼女はこの変化について、自分のチーム内で公にこう位置づけています。モック作成とプロトタイピングは、以前は彼女の1日の3分の2を占めていました。今では、チーム全体でおおよそ3分の1に近づいています。残りの時間は、エンジニアと直接ペアを組み、コードの中で作業することに移りました。
私が話したプロのデザイナーたちは、これを、自分たちが置き換えられることではなく、1日のうち何時間も取り戻すことだと表現しています。
これは本当に重要な区別だと思います。なぜなら、このローンチに関して、特にデザイナーについて息をのむような見出しを多く見てきたからです。
そして私は、このローンチをデザイナーの置き換えとして描写するのは、公平でも正確でもないと思います。そこは非常にはっきりさせておきたいです。
むしろこれは、デザイナーに対して、彼らが最も得意なことをするよう迫るものだと思います。それは、顧客にとって深く役立つ形で、プロダクトを文脈の中に位置づけることです。それこそ、あなたがやるべきことです。
そしてこのツールは、それを加速し、そこにもっと多くの時間を使えるようにするだけです。
次にエンジニアを取り上げましょう。
ここでは引き継ぎが変わります。単なる仕様書から始めるのではなく、Claude Codeへの引き継ぎバンドルとしてパッケージされた、HTMLやCSSなどで書かれた動作するプロトタイプから始めることになります。
あなたがそれを見る時点で、概念的なデザイン作業はプロトタイピングに移っています。そしてあなたの仕事も変わります。
あなたはもはや、エージェントのためにドキュメントを翻訳しているのではありません。むしろ、自分たちの本番パイプライン内のエージェントが、このプロトタイプコードを仕様と一緒に取り込み、実際に使えるフルスケールの本番コードを生成できる状態になっているかを確認することになります。これはまったく新しい役割です。
エンジニアについて特に指摘したいことが一つあります。スケールと、プロトタイプには現れないエッジケースに対応できなければなりません。
今年の初め、Jane Streetのデザイナーが、まさにこのループを最初から最後まで回したことを公に書いていました。彼はプロトタイプ機能をコードベースの中に直接作ります。それを数日間使って生活します。動作する成果物を提案として使います。そして提案を説明するFigmaファイルではなく、コードへまっすぐ進みます。レビュアーが見るのは、体験そのものです。それを描いた絵ではありません。
このフローをスケールさせたい場合、プロダクト、デザイン、エンジニアリングを合わせた形では、実際に10万人や100万人に展開したときにどのようなエッジケースが出てくるのかを、より深く考えることでスケールに対応することになります。
以前は、そのための時間がそれほどありませんでした。今はあります。
今年の初め、Jane Streetのデザイナーが、プロトタイプ機能をコードベースに直接作り、数日間使いながら生活し、エッジケースを露出させる機会を得るというループについて公に書きました。彼はそれをデザイナーの視点から書いていました。
しかし、最近チームと仕事をしていて私が観察しているのは、これは全員の仕事だということです。基本的に、コードへ移行して単純化すると、人々の認知的な余力が解放され、以前は難しかった形で品質やエッジケースに集中できるようになります。
これは、市場で本当に差別化されるソフトウェアを作るうえで非常に重要です。なぜなら、バイブコーディングされた雑なものが大量にあることを、私たちはみんな知っているからです。
では、創業者を取り上げましょう。
創業者にとって最大の変化は、プロトタイピングのループを単純化できるようになったことです。平面的なスクリーンショットを見せるだけではなく、自分が説明しているプロダクトを直接デモできます。そこへ到達するための複雑さが下がります。
そしてAIネイティブな創業者にとって特に、Designはプロトタイプに実際のモデル呼び出しを埋め込めるようにします。これは大きなことです。ワークフロー全体を実際に動くものにできるからです。VCに平面的な体験を見せる必要がなくなります。
資金調達の会話は、約束されているものではなく、実際にそこにあるものを売り込むときに変わります。伝えやすくなるのです。もちろん、資金調達が保証されるわけではありません。そんなことはみんな分かっています。しかし少なくとも、自分のビジョンをより明確に伝える助けにはなります。
少し引いて見ると、これは単にデザインプロセスの話ではありません。ここまで複数の役割を扱ってきたので、それは見えてきたと思います。
本質的には、組織図の話です。
チーム構造はどう変わるのか
これはあなたのチームにとって何を意味するのでしょうか。
ツーピザチームはAmazonの標準になり、しばしば業界全体にも広がりました。なぜなら、調整のオーバーヘッドは現実に存在し、それを減らすことが重要だったからです。
デザイン、プロダクト、エンジニアリング、QAにはそれぞれ十分に専門化された仕事がありました。だから、それらを役割に分ける方が、ジェネラリストを訓練するより効率的でした。一定数の役割が必要であり、そうしてツーピザチームが生まれました。そして、その調整コストは、作ることのコストより低かったのです。その計算は20年間成り立っていました。
しかし、いまその計算が変わりつつあります。
すべての役割がプロトタイプを作れるようになると、役割間の壁が動き始めます。PMはデザインを作れます。デザイナーはコードを出荷できます。エンジニアは仕様を書けますし、デザインもできます。
関与する引き継ぎが減るため、調整コストは下がっています。
AtlassianのCTOであるRajeev Rajanは、2月のPragmatic Summitで、自社の一部チームはコードを一行も書いていないと語りました。彼の表現では、すべてがエージェント、あるいはエージェントのオーケストレーションなのです。
それらのチームは、以前の開発モデルに比べて2倍から5倍のアウトプットを生み出しています。
同じイベントで、200年の歴史を持つ農業関連企業のエンジニアリング責任者は、自社のツーピザチームがワンピザチームになりつつあると語りました。そして私が話したエンジニアリングリーダーたちも、この傾向を確認しています。
Claude Designは、Claude CodeとClaude for Workがすでに可能にした同じパターンに、三つ目の専門機能であるデザインを加えることで、小さな専門家チームという考え方を効果的に加速します。
その結果、あなたのスーパースター、精鋭チーム、特殊部隊、何と呼んでも構いませんが、そうした人たちが、より少人数のチームでより多くのことをできるようになります。
そしてそれは、チームの未来と仕事の未来について多くを教えてくれます。
AIを中心にワークフローを再構築する意思がある限り、チームはより小さく、より速くなります。なぜなら、各人がプロセスのより多くの部分を自分で回せるようになるからです。もっとも、多くの場合、そこがより大きな障害になります。
さて、ワークフロー全体を再設計しに走り出す前に、事前に知っておくべきことがいくつかあります。
Claude Designを使う前に知っておくべき制約
まず、これはMaxティアのツールです。Proプランでは週次制限をすぐに使い切ります。これを本気で使うつもりなら、100ドルまたは200ドルのプランを予算に入れてください。無料ティアで遊ぶ目新しいおもちゃではありません。
二つ目に、Claude DesignはSVGファーストです。ネイティブの画像生成機能はありません。これはレイアウトと構造のツールです。マーケティング資料に本物の写真が必要なら、最終的な合成はまだCanvaか、それに類するものに引き渡すことになります。
三つ目に、Figmaは死んでいません。大規模な本番グレードのデザインシステム、コンポーネントライブラリの保守、プロダクトライフサイクル中盤の深いクラフト作業については、Figmaがまだ所有しています。
Claude Designは、非デザイナーの最低ラインを劇的に引き上げます。そしてプロには、より多く探索する余地を与えます。しかし本番の中盤は、今のところまだそのままです。
そして、ツールがどれほど優れても変わらないことがあります。
ブランド戦略、ポジショニング、あなたのプロダクトを際立たせる審美判断です。それらはすべて、あなたの側に残ります。
Claude Designは1時間で10通りの方向性を出してくれます。どの方向性が自社にとって正しいのかを決めること。それは依然としてあなたの仕事です。
実行作業は圧縮されます。判断の仕事は拡大します。
これを判断の代替として扱えば、悪い仕事をより速く出荷するだけです。すでにあなたが持っている判断力のレバレッジとして扱えば、より良いものを出荷できます。
欠点は本物です。しかし、それは重要ではありません。
問うべきは、Claude DesignがFigmaキラーかどうかではありません。問うべきは、あなたのチームのどれだけの部分が、いま消えたばかりのコストを前提に作られていたのかです。
結局のところ、プロトタイプを作れるPMは、中央集権的なデザイナーの順番待ちをする必要がありませんよね。コードを出荷できるデザイナーは、小さなアプリであれば、エンジニアの順番待ちをする必要がありません。
AIを中心にワークフローを再構築する意思がある限り、チームはより小さく、より速くなります。なぜなら、各人がプロセスのより多くの部分を自分で回せるようになるからです。もっとも、多くの場合、そこがより大きな障害なのですが。
コメント