「モデルデザイナー」の台頭：AI製品におけるデザインの役割が変わりつつある

• AI製品設計に8年以上携わってきた Barron Webster は、Figmaで世界初の 「モデルデザイナー」 という役割を担っており、これはデザイナーがLLMと直接協働する 新しいハイブリッド職種 の登場を意味する
• モデルデザイナーの中核業務は、基盤モデルの限界を補完し、AI機能設計のための 新しいツールと思考法をデザイン組織に導入すること
• 従来のUIデザインと異なり、AI製品設計では まずモデルの挙動をプロトタイピング してからUIを設計する必要があり、そうしないと実際の動作と噛み合わないUIを作ってしまう危険がある
• 評価（Evals）システムの構築 がAI製品の品質管理の要であり、デザイナーが高速なフィードバックループで評価ケースを操作・実行できるツールが必要
• AI時代のデザイナーには、モデルの入出力構造を深く理解し、システム全体を把握する能力 が不可欠であり、単なるUI制作者ではなく意思決定の参加者になる必要がある

---

Barron Webster の紹介

• 8年以上にわたりAI製品に深く関わってきた デザイナーで、ハイプサイクルを見抜く洞察を持つ
• Google Creative Labで2017年に公開された Teachable Machine の設計に参加。これは消費者がAIモデルを学習させられる初のツールだった
• その後ReplitでAI機能に取り組み、スタートアップからユニコーンへの成長に貢献
• 最近、Figmaに世界初の モデルデザイナー として加わった

モデルデザイナーの役割

• FigmaのAIリサーチチームに所属し、2つの主要な任務を担う
  • 基盤モデルから最大限の性能を引き出しても十分ではない状況 を解決すること
  • Figmaのデータは独自フォーマットのため基盤モデルがうまく扱えず、そのギャップを埋めること
• デザイン組織に 新しいツールとAIファーストの思考様式 を導入
  • Figmaは大企業であり、多くのデザイナーにAI体験の設計経験がない
  • AI機能の設計は従来の製品設計とは異なる
• デザイナーがエンジニアにならなくても、プロセス初期にAI機能の中核をプロトタイピング できるツールを作ることが目標
  • 自分で体験していない機能のUIを設計すると、実際の動作と一致しない「理想ケース」向けのUIを作ってしまう危険がある

AIデザインツールの未来

• 最も期待しているのは、デザイナーが高速なフィードバックループで評価ケースを操作し実行 できるツール
  • FigmaファイルでAI機能がうまく動かなければ、すぐにテストケースへ追加できるべき
  • システムプロンプトの調整や別モデルの試行なども即座にできるべき
• 現在の問題はフィードバックループがあまりにも遅いこと
  • 優れたデザインツールの核心は、フィードバックループを取り除くか短縮すること
  • 評価セット構築作業のかなりの部分が、データ整理のための手作業になっている
• FigmaでAI機能をどう差別化するかも検討中
  • デザインプラットフォームである以上、Claude CodeやCursorより より良く設計された出力 が期待される
  • ターゲットを絞った評価戦略と、良いデザインの代理指標 を見つけることが鍵
  • これは美術学校レベルの哲学的問いでもある

Barron のAI入門体験

• 2014〜2015年 RISD Computer Utopias の授業：LLM以前の時代で、機械学習研究が分類器中心だった頃
  • 画像分類モデルが最も興味深く、Snapchatの顔フィルターやGoogle画像検索を支えていた
  • コンテンツモデレーションや推薦システムが主要テーマだった
  • Facebook、Twitter、Cambridge Analytica が全盛だった時期で、アルゴリズムフィードの発明 が新たな設計対象を生み出した
• 2016〜2018年 Google Creative Lab：Google Lens、Google Assistant、Teachable Machine に取り組む
  • ほぼすべてのプロジェクトがモデルの進歩を活用していた
  • テキスト生成ではなく、既存コンテンツの整列や注釈付け にモデルを活用していた
  • 日本のキュウリ農家がTensorFlowでキュウリを分類した事例のプロモーションも行った

Replitでの経験

• 3年以上勤務 し、AI機能がまったくない状態からスタートして、AI活用方法を評価する役割を担った
• モデルが継続的に改善される中で、新しい能力を活かしつつ信頼できるAI機能 をどう追加するかを模索した
• 基本的な手動トリガー機能（コード選択後にAIが説明、既存ファイルにコードを生成）から始めた
• 各機能のリリース後には、ユーザー期待値が上がるサイクルが繰り返された
  • コードスニペット生成を許可 → ファイル全体・プロジェクト全体の要求へ
  • 全体生成が可能 → 特定編集の要求へ
  • 特定編集が可能 → 最初から作り直してほしい要求へ
• 既存モデルで機能を試す → だめなら待つ → 新しい基盤モデルが出たら再挑戦する というパターン
• プログラミング環境ならではの製品制約
  • モデルがコードを書くのに優れていても、正しい場所に編集を入れる方法 が必要
  • Sonnet 3.5 以前は、モデルは行番号の扱いが苦手だった
  • 編集精度、内容重複の防止、関数置換のための 応急処置的な工夫 が必要だった
  • こうした作業の大半は、6か月〜1年後には新モデルで無意味になることが多かった

ユーザー検証への転換事例

• Replit Agent が自動でファイルを作りコードを書く際、エージェントが構築したアプリケーションをテストすること が大きな技術課題だった
  • 例：ログインページが動くかどうかの検証
• エンジニアリング側のアプローチ：サンドボックス起動、スクリーンショット機能構築、マルチモーダルモデルにスクリーンショットを与えてクリック位置や入力位置を決める
  • 本質的には モデルによる疑似的なコンピュータ利用 の実装だった
• Barron と別のエンジニアの提案：ユーザーにWebサイトを見せて、直接テストしてもらう
  • 検証とテストをユーザーにオフロードし、複雑な技術課題全体を回避した
• 技術課題ではなく ユーザー課題に集中する人 がいれば、多くのことを飛ばしたり単純化したりできる

プロダクトマーケットフィットの発見

• 従来のAI以前の製品戦略：計画を立て、既存ユーザー基盤をもとに市場・カテゴリ拡張戦略を設計する
• AIの急激な変化により、Replitの戦略ははるかに反応的 になった
• 教育市場では強いプロダクトマーケットフィットを持っていた（特にコロナ後の遠隔教育で）
• AI機能の改善によりジレンマが発生
  • インディー開発者やハッカーはAIを好む
  • 教師は、学生が基礎学習を飛ばせてしまうとして反対した
• Replit Agent リリース時には対象ユーザーが不明確だった
  • トップダウンの計画よりも、機能を出して反応を見る ほうが成功した
  • リリース後の対話を通じて、テック企業のオペレーション担当者というユーザー層を発見。営業データ収集やダッシュボード構築のニーズがあり、ZapierやRetoolのユーザーに近かった

評価（Evals）システム

• Replitの最初の2年間はあまり評価をしておらず、当時はその慣行が広く普及していなかった
• Agent では評価をより積極的に活用し、主に プロダクト開発指標 として用いた
  • 新モデルが出るたびに、プログラミング評価での性能を見てアプリテストの可否を判断した
• Sandbar では モデルの性格に関する評価 の作成に多くの時間を費やした
  • 業界の広範なベンチマーク評価に加え、製品固有の評価 を構築することが新しいデザイン作業になっている
• ワークフロー：プロンプト作成 → プロンプト調整 → 評価生成 → 性能確認 → 手動テストと主観的フィードバックを組み合わせる
• 評価がないと、AIの動作検証に必要な手作業が大幅に増える
• Sandbar の評価例
  • 答えが分からない場合、幻覚ではなく 単一で具体的な明確化質問 をすべき
  • 一度に2つ以上質問してはいけない
  • 回答は簡潔に保つ（例外あり）

評価の難しさ

• 迎合（Sycophancy） は評価作成で最も難しいテーマのひとつ
  • モデルは適切な場合にはユーザーに反論すべき、という考え方
  • 許容できる失敗率をどう決めるかは製品とデザインの意思決定であり、その製品のデザイン哲学の一部になる
• 評価結果が低い原因が、性能低下ではなく評価の書き方の誤り であることも多い
  • 例：「非常に簡潔であるべき」という評価では、ユーザーが「母が亡くなりました」と言ったときに「それは残念ですね」が高得点になるが、実際に望ましい応答とは限らない
• 評価は主に 回帰防止 のために使われ、特性を満たしているかを確認する
  • プログラミングにおけるテストカバレッジに近い
• 従来のプログラミングの テスト駆動開発（TDD） のようなものは、AIエンジニアリングではまだまれ
  • 先に評価を書き、その評価を通るコードを書くというやり方
• 評価デザイナー という未来の職業の可能性
  • チームがAI性能を理解できるダッシュボードを設計する、デザインシステム的な役割に近い

FigmaでのAI機能構想

• 「サービスとしてのデザイン批評」 というアイデアを検討中
  • AIにデザイン批評を依頼する
  • そのシステムの性格に関する興味深い問いが生じる
• 選択可能な態度（例：「Dieter Rams」 スタイル）を提供するか、デフォルトを設定するか
• アクセシビリティやコントラストの問題（より客観的なフィードバック）に集中するか、それともより広い範囲を目指すか
• 実際の製品体験にどこまで反映されるかは未定

評価ツールの発展方向

• 評価生成の反復速度を縮めるツール を望んでいる
• 現在、評価に関わる誰もが基本的にやっている作業
  • マッピング、フォーマット、パイプライン、出力を一か所で見られるインターフェースにつなぐこと
• テキスト向けツールはかなり良いが、他フォーマット向けは不足 している
• Design Arena のような類似の評価プラットフォームも存在する
  • 人々が望む最高の出力に投票する、ブラインドのサイドバイサイド比較テスト
• Figmaファイル上で直接 同様のことを行いたい
  • コメントを付けたり、問題点を指摘したりすることも含む
  • すばやくテストセットを作り、一括実行し、100件の応答を受けて30秒以内に反復できるべき
  • 現状、必要な部品はすべてあるが、時間がかかりすぎる

モデル生成におけるデザイナーの役割

• ゼロから学習する場合とファインチューニングする場合 の両方を経験してきた
• ゼロから学習する場合：ユーザーニーズが最も大きく、不便さが最も強い箇所を 組織に伝えること がデザイナーの最大の貢献
  • Replitでは、Pythonの一般的で単純なコードエラー向けにカスタムモデルを学習させた
  • 実際の学習そのものより、問題定義と、学習済みモデルをどう製品に適用するかの整理 に深く関わった
• ファインチューニングの場合：既存モデル、製品、評価があり、性能向上を目指すとき
  • プロンプトを書く人、評価を書く人、ユーザー対話をする人が、期待を満たしているかを最も明確に把握している
  • プロンプトエンジニアリングが限界に達したとき、次の段階がファインチューニングになる
• デザイナーの中核的な翻訳役割：ユーザーの前提を忘れないこと
  • モデルと密接に作業するエンジニアやデザイナーは、ユーザーが細部を知らないことを忘れがち
  • 「内なる愚かさ」を活かして、AIモデルの特性を知らない素朴なユーザーが何を試し、どこでつまずくかを伝える必要がある

AIプロダクトデザイナーへの助言

• 最も持続可能で影響力が大きいのは、モデルの入力と出力を本当に理解することに相当な時間を先行投資する こと
  • プロンプトとは何か、どんなユーザー情報が入力されるのか、どんなツールを呼び出せるのか、どんな評価があるのか
  • こうしたダイヤルを調整したときに何が起こるのかを直感的に把握する
• 深く理解していない出力のUI制作者 になってはいけない
  • 「モデルがこれを出すから、そのためのインターフェースを設計して」と言われればできるかもしれないが、ユーザーインサイトに基づく改善提案はできない
  • 後続のモデル変更に極めて受動的に振り回されることになる
• 新機能が本当に望まれるものかという 意思決定の一部 になるべきで、単なる受け手であってはならない
• コードに慣れていないデザイナーには難しいかもしれない
  • Langsmith のようなインターフェースを使うか、開発環境を自分で動かす方法を学ぶ必要がある

最も大きな影響を与えた事例

• Replit Agent：生成したアプリケーションが動くかどうかをユーザー自身に検証してもらうよう、チームを説得したこと
  • ユーザー検証という最も単純な経路に集中し、多くの労力を節約できた
• LaMDA の公開（Googleの初期LLM）：多様なモデルの試行と、何が最もうまく機能するかの検証に多くの時間を費やした
  • 当時は「プロンプティング」とは呼んでいなかったが、別の何かであるかのように振る舞わせ、それを安定して実行させようとした
  • 冥王星やその衛星と会話できるデモは、数え切れない試行の末に最もよく機能するもの を見つけた結果だった
  • 幅広い実験なしに戦略的な選択は不可能だった

デザイナーのプロンプティング

• 「デザイナーはプロンプトを書くべきか」という問いは、「デザイナーはコーディングすべきか」とは性質が異なる
• コーディングの場合、答えはかなり反証可能だ。ABC技術でXYZを構築できるか？ という問いは、エンジニアに聞くのと自分で知っているのとがかなり等価である
• AIモデルの振る舞いは本質的により主観的で繊細 だ
  • その素材を深いレベルで直接理解することに代わるものはない

それでもデザインなのか

• 振る舞いをデザインすること であり、完璧にならないかもしれないが、それでよい
• すべてのピクセルを完全に制御し、完璧さが報われるUIデザインとは異なるマインドセット
• それでもモックアップを作り、デザインツールを使う
• Figmaで評価ケースを作り、出力をレビューし、不自然な部分を直す
• ほとんどセラピーのようで、ハンドスピナー のようでもある
  • Webサイトのモックアップと30分あれば、タイポグラフィを直しながら幸せでいられる
• 機能が削除されない限り、決して終わらない種類の仕事 であり、常に改善できる