AIネイティブ・デザイナーは、フェーズ1にすぎなかった

先日、あるデザインディレクターとコーヒーを飲みながら、AIでデザインチームを本当の意味で変革するとはどういうことか、長い時間をかけて語り合いました。話していたのは、一人のデザイナーがClaudeやFigma Make、Cursor、Lovableを使いこなす方法ではありません。その段階は、この一年でほとんどの人が公然と試行錯誤を重ね、学びを共有しながら、すでに乗り越えてきたはずです。

本当に難しいのは、チーム全体が一斉に変わるときに何が起きるか、という問題です。7人のデザイナーが、それぞれ速くなり、それぞれ違うやり方で働きながら、同じプロダクトとエンジニアリングのパイプラインに合流する。この問題について書いている人は、ほとんど見当たりません。AIデザインをめぐる議論はいまだに「個人」というレベルに留まっていますが、それはもう分析の単位として適切ではないと思います。

第一段階は、AIネイティブなデザイナーをめぐるものでした。その段階は、事実上終わりました。次の段階は、AIネイティブなデザインチームをめぐるものであり、ほとんどの組織はその準備がまったくできていません。

個人のスピードは、AIがもたらす最も興味の薄い成果です

私たちは、間違った数字を祝い続けています。

AIが個人を速くするというのは事実であり、根拠もあります。ハーバード・ビジネス・スクールが758人のコンサルタントを対象に行った実験では、GPT-4を使った参加者は、モデルの得意領域に収まるタスクにおいて、完了数が12.2%増加し、作業時間は25.1%短縮されました。品質も向上しています。私の知るデザイナーは皆、これに似た感覚を味わっているはずです。リサーチの統合が数日ではなく数時間で終わる。批評の前により多くの方向性を検討できる。思考がまだ熱を帯びているうちに、粗いアイデアが動くプロトタイプになる。

これは、誰もがSNSに投稿したがる部分です。そして同時に、最も重要度の低い部分でもあります。なぜなら、それは簡単な部分だからです。個人のスピードは、ログインさえあれば誰でも手に入るものであり、優位性ではなく前提条件になっています。それを変革だと捉えることは、実際には変わっていないのに変わったと錯覚するための、確実な近道です。

同じハーバードの調査は、誰もスクリーンショットを撮らない部分も明らかにしています。モデルの得意領域の外でAIを使った場合、人はより高い確率で間違った答えにたどり着いていました。AIが押し上げたのは、スピードと自信であって、理解ではなかったのです。

これは、私自身も最近目にしました。あるチームが、相当な量のトークンを費やして、単体としては見事に作り込まれたツールを作りました。しかしプロダクトとしては、あまり意味をなしていませんでした。実在するユーザーの課題も、ビジネス上の課題も解決していない。ただ、印象的に作り込まれていただけです。ここには「作ることの誘惑」があり、警戒に値します。AIによって、洗練されたものをこれほど簡単に生み出せるようになった結果、「そもそもこれは存在すべきなのか」という問いを飛ばせてしまうのです。

洗練されていても、間違っていることはあります。機能するインターフェースでも、悪いプロダクトであることはあります。アウトプットが増えるということは、たいてい、レビューすべきものが増えるということです。そしてデザイナーが生み出す仕事量が増えることは、しばしばチームを速めるどころか、遅くします。

速いデザイナーの集まりは、遅いチームになります

これこそが、私たちが大きく見誤っている部分だと思います。

7人のデザイナーを思い浮かべてください。一人はCursorで作る。一人はFigma Makeを好む。一人は誰にも見えない独自のClaudeプロンプト集を持っている。一人はLovableを使い、エンジニアリングとのまったく新しい協働方法を、自分の頭の中だけで作り上げている。それぞれが速くなっています。そして同時に、それぞれが独立したプロセスであり、独立した正しさの基準であり、独立した「完了」の定義でもあります。

その結果、チームにはレビューすべきプロトタイプが増え、エンジニアリングが検証すべき生成コードが増え、プロダクトの意思決定を待つコンセプトが増え、誰とも共有されないまま顧客や会社の知見を静かに抱え込むツールが増えます。作業自体は速くなりました。その周りの調整は、まったく動いていません。

Atlassianは、これに名前をつけています。「AIフラグメンテーション税」です。同社の2026年版State of Teams調査によれば、ナレッジワーカーの85%がAIを使用している一方で、実際の業務フローに組み込めているのはわずか29%にとどまります。そして87%が、調整に割く時間や余力がないと答えています。誰もが実行作業に没頭しているからです。この一つの統計に、問題のすべてが表れています。AIによって誰もがより多くを生み出せるようになった一方で、その周りの会議、レビュー、承認は、まったく変わらないままなのです。

チームは、車線数はそのままに、速い車だけが増えたハイウェイのようなものになります。その先に何が起きるかは、想像がつくはずです。すべてが詰まり、速い車ほど早く渋滞にたどり着くだけです。

AIネイティブな個人の集まりは、AIネイティブなチームではありません。放っておけば、より速く、より断片化したチームになるだけであり、行き詰まるその瞬間まで、生産的であるかのように感じられてしまいます。

ツールの導入は、古いプロセスを飾り立てているだけです

こうなると、標準化したくなるのが人情です。全員にClaudeを配布する。Cursorのワークショップを開く。全員のデザイナーにAIプロトタイプを一つ出させる。どれも理にかなっているように見えます。しかし、そのどれもが変革ではありません。

それは、AIを取り付けただけの古いプロセスにすぎません。ディスカバリーは相変わらず同じやり方で進みます。デザインは相変わらず同じ成果物を生み出します。プロダクトは相変わらずそれをレビューし、エンジニアリングは相変わらずそれを解釈し直し、同じ承認が同じ順番で行われます。全員が、同じハンドオフに、より速くたどり着くだけです。組立ラインそのものを見直すことなく、組立ラインを速くしているにすぎません。

McKinseyの調査によれば、自社がAIにおいて「成熟している」——つまり、実際にワークフローに組み込まれ、現実の事業成果を生んでいる——と考えるリーダーは、わずか1%です。ほぼ全員が投資をしています。しかし、仕事のやり方そのものを変えた組織は、ほとんど存在しません。この1%という数字は、テクノロジーの問題ではありません。誰もが同じモデルを使っているのです。両者を分けているのは「胆力」——プロセスを飾り立てるのではなく、作り直す意志があるかどうかです。

本当に問われるべき問いを、ほとんど誰も口にしていません。もしAIが最初から存在していたとしたら、私たちはこのワークフロー全体をどう設計するか。この問いに答えられないなら、それはただのアップグレードを「変革」と呼んでいるにすぎません。

デザインディレクターの仕事は、チーム全体をここに導くことです

多くのリーダーは、AIにおける自分の仕事を「調達」だと考えています。スタックを選び、ライセンスを買い、全員にコードへの実装を義務づけ、変革を宣言する。しかし、私が異を唱えたいのはまさにこの発想です。それは簡単な道であり、間違った道でもあります。ツールを配って成果物を求めるだけなら、それは予算のついた放棄にすぎません。

デザインリーダーには、依然として人を育て、品質を守り、明確さを生み出し、信頼を築く役割があります。AIは、そのどれも肩代わりしてくれません。それどころか、より難しい仕事を上乗せしてきます——7人を放り出して各自の判断に任せ、生き残った者を「変革された」と呼ぶのではなく、チーム全体を意図的に、共に、そして安全に導いていくという仕事です。

「意図的に」とは、人とAIが共に働くシステムを、成り行き任せで組み上がるのではなく、自ら設計するということです。顧客のインサイトから出荷済みのプロダクトに至るまで、実際に何が起きているかを可視化し、どこが壊れているかを正直に見つめる。情報が失われている箇所、デザイナー同士が知らないうちに互いの作業をやり直している箇所、エンジニアリングがデザインの意図を逆算しなければならない箇所。どの意思決定はAIエージェントが支援できて、どの意思決定には自分の名前を結果に刻む人間がまだ必要なのか。

「共に」とは、誰も意図的に置き去りにしないということです。動きの速い人たちは、いつだって先を走ります。その差が広がるままにしておけば、手に入るのはAIネイティブなチームではなく、二、三人のパワーユーザーと、静かに用済みにされていく人々の集まりです。全員を連れていくことこそが、本物のチーム能力と、その人がいなくなれば消えてしまう少数の個人的なワークフローとを分けるものです。

「安全に」とは、洗練されているのに間違っているものが出荷されるのを防ぐチェックポイントを設け、どの顧客データをモデルに近づけてよいかを痛い目を見る前に決め、モデルがどれほど優秀になろうと自動化されるべきではない原則を守る、ということです。これらを伴わないスピードは、本番環境で間違える速度が上がるだけです。

そして、デザインだけを切り離して変革しても、何一つ機能しません。これは、ほとんど誰も口にしない部分です。デザインが速くなり、プロセスを作り直したとしても、プロダクトとエンジニアリングが従来のままであれば、仕事そのものは変革されていません。変わらない下流に流れ込む、速い上流を作っただけです。変革は、その仕事を受け取る人たちのワークフローに合っていなければなりません。そうでなければ、ボトルネックを一歩先にずらしただけです。

このほかにも、成果物をめぐる問いがあります。それらは、このシリーズの後の回で扱います。コードで書かれたプロトタイプは、いつ使い捨てで、いつ本物なのか。デザインシステムにどこまで密結合していれば、エンジニアリングの時間を割く価値があるのか。ある火曜日に一人のデザイナーが学んだことが、金曜日には残り六人の知識になるには、どうすればよいのか。どれも本物の問いであり、どれも自然に答えが出るものではありません。

これらはどれも、ツールの問題ではありません。組織設計の問題であり、7人がそれぞれ独自に、より良い個人的なワークフローを発明することでは解決しません。誰もリードしなければ、チームが最終的に手にするのは、7つのばらばらなワークフローです。

始めるべきは、号令ではなく一つの本物のプロジェクトです

もし自分がこれをリードするなら、変革を宣言することはしません。号令は、学びではなくコンプライアンスしか生みません。まずは、一つのプロジェクトから始めます。本物でありながら、範囲は限定されたもの——プロセスの実態を露わにするのに十分な規模でありながら、失敗しても危機にならない程度の規模です。デザイン、プロダクト、エンジニアリングが一体となり、意図的に違うやり方で働き、何が起きたかを正直に検証する。チームは速く学んだのか、それとも単に多く生成しただけなのか。エンジニアリングは時間を節約できたのか、それとも生成されたコードの後始末に時間を費やしただけなのか。人間の判断が、実はすべてを決めていた場面はどこだったのか。このパイロットと、そこから本物の再設計されたワークフローをどう組み立てるかは、次回の主題です。

スタンフォード大学デジタル・エコノミー・ラボが、51件の企業向けAI導入成功事例を調査した研究によれば、勝者とそれ以外を分けたのは、モデルそのものよりもはるかに、組織そのものでした。プロセス、リーダーシップ、備え、失敗から学ぼうとする意志。これは、率直に励みになります。ClaudeやCursorへのアクセスは、誰もが手に入れられるものです。差がつくのは、チームがそれらを共にうまく使いこなすことを、どれだけ速く学べるかであり、それはリーダーが実際に築けるものです。