OpenAIのプロダクトデザイン責任者が語る、「今こそデザイナーにとって史上最高の時代である理由」

不安は幻想ではない。「最高の時代」という言葉も慰めではない

デザイナーの不安は、まず、速度の異なる加速から生まれます。

エンジニアには、AIによる能力強化の分かりやすい道筋が既にあります。比較的明確なタスクをプログラミングエージェントに任せ、コードを得て、テストを実行し、さらに修正を続ける、というものです。Ian氏曰く、OpenAI内部でも従業員調査を行っているそうですが、デザインチームは、エンジニアの生産性が「十倍、時には百倍」に向上するのを目の当たりにしているものの、自分たちには同じような分かりやすい向上が見られないと感じているとのことです。

その理由は、デザイナーがツールを使おうとしないからではありません。デザインの仕事は、フィードバックがそれほど二元的ではないからです。アイデアは素晴らしく見えても、実際に作ってみると酷い結果になることがあります。ユーザーに届けて初めて、自分たちが問題を誤解していたことに気づくこともあります。たとえ解決策が正しかったとしても、大企業では、方向性、リスク、トレードオフについて、多くの関係者の合意を得る必要があります。AIは、チームがより速く、より多くのアイデアを生み出すのを支援してくれますが、試行錯誤やユーザーフィードバック、組織内の調整を自動的に排除してくれるわけではありません。

組織は、先にエンジニアリングの成果が増えるのを見れば、すぐに納品への期待値を引き上げます。しかし、デザイナーには、まだそのような明確な新しい仕事のサイクルがありません。そうなると、問題は「新しいツールを使えるかどうか」ではなく、「会社は今、デザイナーに一体何を求めているのか」になります。毎日コードを書くことでしょうか？ リサーチ、プロダクト、ビジュアル、フロントエンドのすべてを担当することでしょうか？ これまで受けてきた専門的な訓練は、突然、意味を失ってしまうのでしょうか？

このことが、「能力が増幅された」と「仕事がより忙しくなった」が同時に起こり得る理由を説明しています。「最高の時代」という言葉は、デザインができる一人の人間が、その能力によってどれだけ大きな結果を生み出せるかを表しています。一方、調査が示しているのは、現在のデザインという職務における責任、時間、報酬の分配のされ方です。この二つは、元々、同じ指標ではありません。

Ian氏は、デザイナーの不安に関する章で、しばしば見落とされる組織的な条件についても触れています。OpenAIは自らを研究ラボと位置付けており、新しいデザイナーにAIのバックグラウンドは求めませんが、好奇心は求め、チームには探求の余地を与えています。デザイナーは同僚の間で新しい仕事の方法を交換し、シニアメンバーもジュニアメンバーも、悪いアイデアを試してはすぐに捨て、次のラウンドに進むことができます。人の状態を良くするのは、個人の「前向きさ」だけでなく、組織が探求を許容し、同僚が知識を共有し、失敗がすぐに能力の評価に直結しない環境なのです。

つまり、「変わりたいと思うこと」は、個人の精神論ではありません。実験する時間がなく、同僚のサポートもなく、ただより高い成果だけが求められるチームが、デザイナーに楽観的でいることを求めたところで、同じ結果を得るのは難しいでしょう。

AIは実装を加速させたが、チームに代わって判断を下してくれるわけではない

Ian氏は育児休暇中に、いくつか個人プロジェクトを行いました。当時のプログラミングエージェントを試してみたところ、動作はするものの、さまざまな小さな問題で何度も行き詰まったそうです。そして一ヶ月後、Codexがリリースされ、同じようなことをもう一度試してみると、「これは本当に使える」という感覚に変わったとのことです。

このエピソードは、ツールのランキングよりも重要です。AIプロダクトの能力は、年に一つのバージョンというように安定して向上するわけではなく、数週間のうちに、ある実用化の敷居を超えることがあるからです。昨日までの失敗に基づいて形成された仕事の習慣が、今日にはもう時代遅れになっている可能性があります。だからこそデザイナーは、固定された操作方法を学ぶだけでなく、低コストで再試行できるフィードバックループを構築する必要があるのです。

従来のデジタルプロダクトチームは、しばしばFigmaファイルを境界線としてきました。デザイナーは左側に理想的な状態を描き、エンジニアは右側でそれを実際のパフォーマンス、実際のデータ、モデルの応答、異常系の状態に変換します。多くのエラーは、開発に投資が行われた後に初めて明らかになります。

生成AIが真に圧縮したのは、仮説が実際のユーザー行動に触れるまでの距離です。漠然としたコンセプトを、モデルやデータに接続された実行可能なバージョンへと、より速く変換できるようになりました。チームはより早い段階で、ユーザーがタスクを完了できるか、モデルがどのような入力で制御不能になるか、実際のコンテンツが情報の階層構造を壊してしまわないか、いわゆる「賢い機能」が本当にユーザー行動を変えるのか、といったことを発見できます。

しかし、フィードバックループが消えたわけではなく、より早く始まるようになっただけです。実行可能なバージョンは依然として人間に使われる必要があり、エラーは依然として観察される必要があり、複数の選択肢の中から選ぶ必要があり、チーム間での調整も依然として必要です。Ian氏のデザインプロセスについての描写は、非常に格好良くないものかもしれません。あるアイデアが一度試してひどく、もう一度試してもひどく、社内やユーザーからのフィードバックを得て初めて、その道全体が間違っていたことに気づく、ということもあるからです。AIが増やしてくれるのは各ラウンドで試せる量であって、どのラウンドを残す価値があるかをチームに代わって宣言してくれるわけではありません。

また、実行可能なプロトタイプは、リリース可能なシステムと同義ではありません。信頼性、セキュリティ、パフォーマンス、データガバナンス、メンテナンス、そして極端な状況への対応には、依然としてエンジニアリングの深い知識が必要です。AIを使って表現のハードルを越えることと、AIを使って本番環境での責任を越えることは、全く別の話です。

三つの役割は接近しているが、三つの役割を担う人物は依然として必要だ

司会者は、Marc Andreessen氏の「三人のスパイダーマン」の比喩を引用しました。プロダクトマネージャー、エンジニア、デザイナーが互いに相手を指差し、それぞれが「AIが最終的には他の二つの職種を消滅させ、自分たちが最後の勝者になる」と考えている、というものです。

これに対するIan氏の答えは、「最終的に全員がビルダーと呼ばれるようになる」というものではありません。彼は、役割を、ソフトウェアを構築する際に誰かが必ず担わなければならないいくつかの役割として捉えています。

人材と役割は、もはや一対一で対応しません。デザイナーがコードを書いたり実行可能なプロトタイプを作ったりすることもできれば、エンジニアが直接インタラクションを決定することもでき、プロダクトマネージャーが要件をテスト可能なバージョンにすることもできます。しかし、チームを横断して問題に焦点を当て、リソースを確保し、コラボレーションを推進する仕事は消えていません。ユーザーを理解し、体験を定義し、プロダクトに対する見解を形成する仕事も消えていません。そして、アウトプットの信頼性を確保し、それをより大きなシステムに統合できるようにするエンジニアリング上の責任も消えていません。

スタートアップ企業では、非常に有能なゼネラリストが同時に三つの役割を担うかもしれません。Ian氏は、起業を計画している友人が、一般的な「デザイナー一人に対してエンジニア十五人」という比率を逆転させて、「デザイナー二人に対して優秀なエンジニア一人」にするというアイデアを議論していたことにも言及しました。エンジニアがシステムの信頼性を守り、二人のクリエイティブなビルダーがプロダクトをエンドツーエンドで探求する、という構想です。ただし、これはあくまで友人の起業アイデアであり、OpenAIの人員構成や業界の採用予測を示すものではありません。

大企業になると、役割はむしろ消えにくくなります。一人の人間が、デザインをしながら、複数のチームを調整し、リソースを設定し、さらに自らシステムをエンジニアリングするとなると、問題は「理論的に可能かどうか」ではなく、注意力と能力の構造がそもそもそれに耐えられない、ということになります。Ian氏は、デザイン能力が非常に高い人でも、焦点を絞り組織運営を改善してくれる優秀なプロダクトマネージャーを必要とし、また、部分的なアウトプットがシステム全体に統合されることを保証してくれるエンジニアも必要とするのを見てきました。

これは、OpenAIが、すべてにおいて最強のスーパーデザイナーを探すのではなく、互いの能力を補完し合うチームを重視している理由も説明しています。ビジュアル、ブランド、プロトタイピング、戦略的プロダクト思考、そして最先端の探求は、異なる人々の組み合わせによって形作られます。実際、OpenAIの現在のプロダクトデザイン職の募集要項を見ても、ユーザーリサーチ、デザインシステム、高忠実度プロトタイプ、複雑なインタラクション、曖昧な問題の明確化が依然として求められています。これはあくまで公開されている一件の求人情報の要件に過ぎず、市場全体を代表するものではありませんが、「役割の融合」が専門性の深い価値を直ちに失わせるわけではないことを示すには十分です。

もちろん、境界線が曖昧になることは、企業に「一人で三人分の仕事をする」と解釈される可能性もあります。責任だけが拡大し、意思決定権、時間、報酬が変わらなければ、能力の融合は職務の縮小へと退化してしまいます。ある仕事が本当にアップグレードされたかどうかを判断するには、ツールの権限がどれだけ増えたかだけでなく、その人が問題を決定する権限、価値の低いタスクを拒否する権限、そして品質にリソースを配分する権限を持っているかどうかを見る必要があります。

AIは過去の答えを得意とし、人間は未来のパラダイムを発明する

司会者から「AIは優秀なプロダクトデザイナーになれるか」と問われたIan氏は、職業上の尊厳を守るために否定したりはしませんでした。彼は、AIはすでに非常に優れたプロダクトデザインツールであり、誰もがそれを使うことができると述べました。

しかし、「非常に優れている」ということは、「すべての側面で最高である」という意味ではありません。彼が具体的に挙げた弱点は、ビジュアルデザイン、情報階層、タイポグラフィ、ユーザーエクスペリエンス、インタラクションデザインなどです。さらに重要なのは、モデルは主に既存の作品から学習するのに対し、優れたプロダクトは、しばしば、登場したばかりでまだ確立された事例がない新しい能力を活用している、という点です。

iPhoneが登場した時、デザイナーは前例のないマルチタッチに直面しました。Instagramは、誰もが持ち歩くカメラ付きモバイルデバイスを、新しいビジュアルネットワークへと変えました。Snapchatは、当時としては奇抜に思えたインタラクションを用いて、デジタルコミュニケーションを永遠に残るものから、より一時的でカジュアルな表現へと塗り替えました。これらは、既存のウェブサイトをより美しくしたのではなく、新しい能力と満たされていないニーズを認識し、後になってからトレーニングデータとなるようなパラダイムを発明したのです。

AIエージェントも同様の段階にあります。それは、いつ自ら行動し、いつ静かにしているべきか、ユーザーに何をしているかをどう伝えるか、エラーが発生した後、どのように一時停止し、取り消し、責任を追及するか、といった問いに対して、まだ安定していて直接模倣できる答えはありません。モデルは昨日の多数のインターフェースを再構成することはできても、明日の最も適切な社会的慣習を自動的に発明することを保証してはくれません。

Ian氏は、人間には依然として三つの重要な仕事があると考えています。

第一に、具体的な人間を理解することです。ユーザーがクリックしない理由は、理解できない、信頼できない、間違いを恐れる、あるいはそもそもその機能を必要としていない、など様々です。行動を観察し、フィードバックに耳を傾け、その結果として方向性を変える意志があって初めて、「ユーザーを理解する」という言葉は、単なる「人間には共感力がある」という決まり文句ではなくなります。

第二に、トレーニングサンプルが存在しない新しいパラダイムを発明することです。新しい能力が登場したばかりの時、最初の信頼できるインタラクションは、誰かが実際のユーザーと失敗の結果を通じて、ゆっくりと見出していく必要があります。

第三に、複数の実行可能な選択肢の中から、自分の見解を形成することです。品味（センス）とは、特定の色が好きだということではなく、誰のためにデザインするのか、なぜそうするのか、何を強調すべきか、何を削除すべきかを説明でき、それを多くのプロジェクトで一貫して適用できることです。

AIがまず価値を下げるのは、判断力ではなく、他人の結論を描くだけで、自分自身では判断を形成していない仕事です。

「少なくやる」こと。まず、何をデザインする価値があるかを判断する

アウトプットが速くなるにつれて、OpenAIで不足しているのは、ページ数ではなく、システムです。

Ian氏は、Notion初期のコンポーザブルなブロック（組み合わせ可能な部品）を使って、システム思考を説明しました。新しいニーズが発生するたびに孤立した機能を作るのではなく、互いに構築し合える基礎的なプリミティブを形成する、という考え方です。AIプロダクトには、さらに別の要件が加わります。これらのプリミティブは、デザイナーやエンジニアが理解できるだけでなく、モデルがそれらの組み合わせ方を推論できる必要があり、最終的には、多くの機能がユーザーの目には一貫性のあるプロダクトとして映るようにしなければなりません。

これが、Ian氏がチームに「少なくやる」と話す背景でもあります。彼の言葉は、普遍的に品質を下げろという意味ではなく、まず三つのより基本的な質問をすることを促しています。それは、「既存のシステムやコンポーネントで解決できないか？」「既存の機能を拡張できないか？」「この新機能はそもそも存在する必要がないのではないか？」というものです。

作る価値があると判断した後は、どこまで作り込むかを、プロダクトの段階と技術の耐久性に応じて決めます。

ChatGPTの核となる体験の一部は、繰り返し磨き上げられます。チームは百の案を試して九十九を捨てるかもしれません。入力欄は毎日変化し、ユーザーリサーチ、A/Bテスト、社内でのドッグフーディングがすべて意思決定に入ってきます。一方、一部の新しい方向性については、ビルド・イン・パブリックを選択します。まず大きな動きを実際の世界に投入し、社内外のフィードバックから迅速に学ぶのです。Ian氏によると、アイデアが浮かんでからリリースまでに、わずか四時間しかかからないこともあるそうです。

この二つのスピードは矛盾しません。モデルの能力、レイテンシー、利用可能なインタラクションが急速に変化している間は、今日慎重に作り込んだ設定項目が、来月には不要になっているかもしれません。また、以前は実現できなかった動作が、突然デフォルトの能力になることもあります。これらの部分を過剰に大切にすることは、まさに消えゆく前提条件に作り込みを浪費していることになります。

逆に、チームがChatGPTをどのように長期的に個人の生活に統合するか、どのように安定した関係と信頼を築くかをデザインする場合、それは一晩でリリースされることはありません。ホワイトボード、Figma、実行可能なプロトタイプ、長期的なドッグフーディング、そして多くの放棄された案が必要です。真の境界線は、「この機能のリスクが高いか低いか」という単純なものではなく、それが長期的に存在するかどうか、技術的な前提が安定しているかどうか、エラーのコストがどれほどか、そしてチームが今、学ぶことを必要としているのか、それとも確約することを必要としているのか、という点にあります。

「少なくやる」ことには、最終的に二つの意味があります。必要のない新しいものを製造しないこと、そして、均一な品質をすべてのものに平均的に注ぎ込まないことです。

十億人のユーザーは、一人のユーザーではない

ChatGPTのデザインが難しいのは、その能力の多さだけでなく、それを使う人々の違いが非常に大きいからです。

Ian氏はInstagramで既に十億人規模のユーザーを経験してきましたが、そのプロダクトの中核となる行動は比較的集中していました。一方ChatGPTは、片方の端では、今夜の夕食やヘアスタイルの変更についてのアイデアを尋ねるだけのユーザーがいますが、もう一方の端では、日本の農業の自動化方法を変革するために使うユーザーもいます。その中間には、無料でたまに使う人、毎日仕事の主要なツールとして使う人、そして毎月数百ドルを支払うヘビーユーザーまで存在します。

これは、単純な「初心者モードと上級者モード」の問題ではありません。同じ空白の入力欄の背後で、ユーザーが意図の表現、アウトプットの形式、制御の度合い、そして信頼性に求めるものは大きく異なります。

OpenAIは、この問題の一つを「capability overhang（能力の未活用余地）」と表現しています。それは、大多数のユーザーが、モデルの実際の能力のほんの一部しか活用できていないという状況です。これは、彼らに価値がないという意味ではありません。レシピを教えてもらうだけで十分に役立つかもしれません。問題は、一般ユーザーを圧倒することなく、どのようにしてより深い能力を段階的に利用可能にするか、ということです。

Ian氏が語る戦略は、最先端のオプションをすべてメインのインターフェースに詰め込むというものではありません。チームはまず、本当に新機能を必要としている人々の間で実験できます。例えば、デスクトップ版やCodexのような、より専門的な入り口です。インタラクションと機能が成熟したら、それをメインの体験に蒸留します。最終的に、十億人のユーザーが正しい結果を得るために、モード切り替えやモデル一覧を理解しなければならない設計にすべきではありません。

ここでの設計課題は、すべてのユーザーを専門家に変えることではなく、製品のシンプルさを保ちながら、専門ユーザーの上限を塞がないようにすることです。

チャットボックスの後に、単にボタンを増やすのではない

空白の入力ボックスは、しばしば「美化されたターミナル」と批判されます。何でもできる反面、初めて使う人に何をすべきかをほとんど教えてくれないからです。

しかし、チャットがすぐに消えないのには、強い理由があります。Kevin Weil氏は別のインタビューで、人間は言語を通じて認知レベルの大きく異なる人々とコミュニケーションが取れると述べています。言語は、絶えず変化し、強化され続ける知能を自然に運ぶことができます。言い換えれば、空白のボックスは発見可能性の問題であると同時に、現在最も広い範囲をカバーする普遍的な入り口でもあるのです。

したがって、真の製品進化とは、チャットボックスの周りに単にボタンを追加することではなく、五つの問題を段階的に解決することです。

第一に、ユーザーが意図を表現するのを助けることです。ユーザーが最初にプロンプトエンジニアになるべきではありません。Ian氏によると、ChatGPTは現在、自由形式の質問の後に追加の質問を続け、その一部をクリック可能な回答に変えています。インターフェースはモデルに代わって答えを選ぶのではなく、モデルがユーザーの真の目的を理解するのを助けるのです。

第二に、出力を作業に適した成果物にすることです。メールは長いチャット履歴に埋もれることなく、独立した作文ブロックに入り、ユーザーが直接修正、部分編集、コピーできるようにします。画像生成にも、画像タスクに適した専用ツールが必要です。チャットは意図の開始を担当し、成果物インターフェースは作業の継続を担当します。

第三に、コンテキストに応じてアフォーダンスを変えることです。デザイナー、データサイエンティスト、私生活を管理する人々は、皆同じ入り口から始めるかもしれませんが、必要なツール、情報密度、操作可能な出力は異なります。汎用製品は、全員が常にまったく同じインターフェースを見ることを意味しません。

第四に、受動的な応答から能動的な協働へ移行することです。Ian氏は、カレンダーやSlackなどの外部コンテキストについて言及し、音声がより自然になれば、システムは完全な指示を待つのではなく、より適切なタイミングで提案できるようになると述べています。

第五に、持続可能なワークフローを形成することです。今日の多くのチャットは、毎回ゼロから始まるかのようです。将来の方向性は、ユーザーが繰り返し使える作業方法を確立し、システムが迅速に回答すべきか、対話を続けるべきか、現在のターンを離れて作業を完了すべきかを自律的に判断できるようにすることです。一般ユーザーは、最終的にモデル名や速度設定を理解する必要はありません。

これらはIan氏が説明した製品の方向性であり、すべての機能が完全かつ普遍的に展開されているわけではありません。これらが共通して示しているのは、AI製品設計の核心は、画面に何を表示するかだけでなく、意図がどのように理解されるか、成果物がどのように編集され続けるか、システムがどのようにコンテキストを利用するか、そして積極性が増した後もユーザーがどのように制御を維持するかということです。

実際に先を行く人はいない、AIの自信に満ちたパフォーマンスに騙されるな

「まだ誰もが早い段階にいる」という言葉は、単なる慰めとして片付けられがちです。しかし、Ian氏の経験は、この言葉にもう少し信憑性を与えています。

彼がOpenAIに入社したばかりの頃、GPT-4が登場したばかりでした。彼はすでにこれらのツールを使用していましたが、それらを本当に理解しているとは言えず、面接も入社も怖いと感じていました。その後、会社とチームは急速に拡大し、彼は長い間、この新しい管理職が自分には向いていないと感じ、毎日、学んだことのない仕事をしているかのようでした。

彼を本当に助けたのは、自己啓発の記事をもう一度読むことではなく、大規模なデザインチームを率いた経験がある友人や、同様の変革を経験している人々に相談することでした。彼は自分の問題が特別なものではないことに気づきました。メンター、同僚、そして困難を率直に話し合えるコミュニティが、「自分はダメなのかもしれない」という思いを、「これは多くの人が一緒に学んでいる新しい問題だ」という認識に変えてくれました。

その後、インタビューでは、非常に的確な表現が紹介されました。「AI confidence theater」です。ソーシャルメディアは、誰かがAIを使って作った素晴らしい作品、驚くべき自動化、新しいワークフローを絶えず表示しますが、その過程で何度失敗したか、結果がどれほど脆いものかを示すことはほとんどありません。それを見た人は、他人はすべてをマスターしていると思い込み、自分の実験がうまくいかないのは、すでに遅れを取っている証拠だと誤解してしまいます。

だからこそ、組織が単にツールを購入するだけでは不十分なのです。より良い状態にあるデザイナーは、通常、探求する時間、話し合う相手、未完成の作品を安全に披露できる場所を同時に持っています。個人は好奇心を持ち続け、実験を繰り返すことが重要です。チームも、最終的な美しいスクリーンショットだけを評価するのではなく、プロセスを見えるようにする必要があります。

Ian氏は、今日ゼロから始める人は、ほとんどの人よりも早く新しい仕事の方法を身につける可能性がまだあると言います。重要なのは、現在の最先端の操作を暗記することではありません。今日の最先端の方法は、一ヶ月後には古く見えるかもしれないからです。重要なのは、継続的に再試行し、結果を比較し、昨日の結論を今日の新しい証拠で覆すことを許すことができるかどうかです。

IGTVの失敗後、Reelsがそれでも成功できた理由

インタビュー全体を通して、「アイデアに過度に固執しないこと」を最もよく説明しているのは、OpenAIではなく、Ian氏のInstagramでの失敗経験です。

彼はIGTVを大きな失敗だったと率直に認めています。チームは製品にいくつかの誤った仮定を持ち込み、後に不適切であることが判明したいくつかの制約も取り入れました。製品のリリースは自動的に方向性の正しさを証明するものではなく、批判と実際の使用状況がこれらの問題を明らかにしました。

その後、チームは最初のリリースを守らなければならない結論とは見なさず、制約を変更して製品を作り直し、最終的にReelsをリリースしました。Reelsの成功は、もちろん「デザインチームがいくつかの仮定を変更した」という単純な理由に矮小化することはできません。Ian氏がこの経験を通じて示したかったのは、失敗したリリースはキャリアの宣告である必要はなく、次の判断の材料になり得るということです。

真のフィードバックループには、あまり格好良くないいくつかの動作が含まれます。当初の理解が間違っていたことを認めること、どの制約が自分たちで設定したものかを区別すること、外部からの批判を受け入れること、間違った方向への修正を続けるのをやめること、そして新しい判断を持って前に進むことです。Ian氏はこれを「fix forward」と呼んでいます。重要なのは、あるリリースが完璧に見えるかどうかではなく、チームが証拠を受け取った後にどう反応するかです。

これは逆に、AIが生成速度を向上させた後も、判断が自動的に安くなるわけではないことを説明しています。チームが生成したものを手放す能力がなければ、制作コストの削減は、間違った方向への積み重ねを速めるだけです。

すべての企業に適合する単一の設計プロセスはない

Ian氏のキャリアは、Groupon、Instagram、OpenAIにまたがっています。これら三社に共通する最も価値のある点は、まさに共通のベストプラクティスが存在しないことです。

初期のGrouponの製品は、強いブランド人格を持っていました。会社にはコメディアンで構成されたライティングチームがあり、メールは面白く、個性があり、人々は割引のためだけでなく、それを開いていました。デザインの価値はインターフェースの秩序だけでなく、企業の声が際立っているかどうかにも存在します。

InstagramのDNAは、どちらかと言うとデザインと創造性に偏っています。その発展段階のほとんどにおいて、ゆっくりと、安定して、製品をあまり変更しないことが効果的でした。チームはしばしば「まず最も簡単なことをする」という制約でソリューションを検討し、創業者のKevin Systrom氏もデザイナーとして深く製品に関与していました。

OpenAIは研究ラボに由来し、モデルの能力と製品の前提は絶えず変化しています。もしInstagramの「遅さ」と「安定性」をそのまま適用すれば、多くの機会は検証される前に失効してしまうでしょう。一方、OpenAIの迅速な実験を、成熟した強力な規制下にある製品にそのまま適用すれば、同様に災害を引き起こす可能性があります。

Ian氏の結論は、新しい会社に入ったらその文化を変えようとすることではありません。特に創業者主導の組織では、デザイン責任者が会社のDNAを根こそぎ変えることは困難です。より現実的なアプローチは、ここでどのような行動が評価されるかを理解し、自分が過去に役立った原則を持ち込み、それを使って既存の文化の盲点を補うことです。

「まず最も簡単なことをする」はInstagramからOpenAIに持ち込むことはできますが、それが常に正しいとは限りません。時には、実験段階では一時的に複雑なものが存在することを許容すべきです。ワークフローは職業上の信念ではなく、組織の段階、技術の変化、製品の責任が組み合わさって生まれる選択です。

最終的に最適化すべきはツールの使用率ではなく、製品の成果

ホストがIan氏に不安を抱えるデザイナーへのアドバイスを求めたとき、彼は最後に特定のソフトウェアを推奨しませんでした。彼は、焦点を成果に戻すべきだと言いました。デザイナーは最も複雑なツールのワークフローを構築するためでも、トークンの使用を最大化するためでもなく、人々が愛する製品を作るために存在します。

AIは非常に具体的で、些細な作業の瞬間にも入り込むことができます。Ian氏は夜にアイデアを思いついたとき、それをクラウドに渡して、チームと議論できるプロトタイプを生成させます。返信が必要なSlackメッセージをまとめさせ、重要な会議の前にコンテキストを補完させます。採用や日常業務の運営も支援します。コンピューターの前にいないときでも、先にタスクを指示し、後で生成された成果物を確認することができます。

これらのシナリオに共通するのは、「AIをたくさん使った」ということではなく、アイデア、コンテキスト、次のアクションの間の距離を縮めているということです。デザイナーは引き続き、問題の選択、結果の評価、継続するかどうかの決定を担当します。

次のプロジェクトで五つのことだけを行うなら、次のように始めることができます。

1. 実際の問題を一つ選び、ユーザー、状況、失敗のコスト、最終的に変えたい結果を明確に書きます。
2. 美しい画面を追求する前に、実際のデータ、モデルの応答、または重要な失敗を明らかにする実行可能なバージョンを作ります。
3. それを実際のユーザーや同僚に渡し、好みを集めるだけでなく、行動によってどの仮定が覆されたかを記録します。
4. 保持、削除、延期の理由を書き留めます。特に、既存のシステムで解決できる機能と、技術的な前提がまだ耐久性に欠けるものを説明します。
5. 失敗、再試行、ツールが機能しなかった場所を含むプロセスの一部を公開し、チームと業界が新しい仕事の方法を学べるようにします。

同時に、十分に深い専門性を一つ維持します。それは、ビジュアルクラフト、複雑なインタラクション、ユーザーリサーチ、コンテンツデザイン、プロトタイプエンジニアリング、製品戦略などです。役割の融合は深さの消失を意味しません。誰もが迅速に「まあまあ使える」バージョンを作れるようになったとき、信頼できる深さはむしろ認識されやすくなります。

また、三つの境界線を守る必要があります。

第一に、デザイン能力のレバレッジが高まることは、デザインのポジションが増えることを意味しません。Ian氏自身も、採用市場の証拠を示していません。短期的には、少数の人がより大きなエンドツーエンドの領域を得る一方で、成果物の納品を中心としたポジションが減少する可能性があります。

第二に、「エンジニアの生産性が十倍、百倍になる」というのは、Ian氏による最先端のチームの観察であり、業界平均の事実ではありません。METRは2025年初頭に、自身のオープンソースプロジェクトに精通した16人のシニア開発者を対象にランダム化比較試験を実施し、246のタスクで、当時のAIツールの使用を許可されたグループは、平均で19%多くの時間を費やしました。METRの2026年の更新では、新しいツールがより多くのスピードアップをもたらす可能性が高いとされていますが、参加者の離脱や並行エージェントの計時により、全体的な効果を確実に測定することはより困難になっています。方向性は急速に変化しており、統一された倍数はまだ存在しません。

第三に、OpenAIのモデル、人材、データ、実験環境は、一般的な企業に直接コピーすることはできません。本当に持ち帰る価値があるのは、明日の人員比率ではなく、一連の問いです。技術的な前提はどの程度安定しているか、ユーザーの範囲はどの程度広いか、どのような責務が依然として誰かが担わなければならないか、何が長期的な設計に値するのか。

今は確かにデザイナーになるための最高の時代かもしれませんが、古い形のデザインポジションを維持するための最高の時代とは限りません。前者は、人を理解し、実際の証拠を作り出し、新しいパラダイムを発明し、組織に適応し、失敗後に判断を修正できる人を評価します。後者は、安定した分業、固定されたプロセス、成果物の境界に依存しています。

AIは、より多くの人がアイデアを製品に変えることを可能にします。デザイナーの真の価値は、自分がまだ特定のツールを独占していることを証明することではなく、「何でもできる」ようになった後でも、何が存在する価値があるか、何を変えるべきか、そして何をそもそも行うべきでないかを判断できることにあります。