AIが乱雑なブリーフを実行可能なプロトタイプに変えるとき
チームが本気でAIプロトタイピングツールを初めて使ったとき、際立っていたのは提供されたUIではなかった。デザインフェーズがスライドの寄せ集めのように見える段階を抜け出し、システムのように振る舞い始めるその速度だった。
いつものところから始めた：営業電話の散在したメモ、競合のフローのスクリーンショット、半端なアイデアで埋まったFigJamボード。数年前なら、その混沌はワイヤーフレームになり、次に高精細な画面になり、誰も本気で考えていなかったエッジケースについての終わりのないコメントスレッドになっていただろう。今回は違った。私たちはその混乱を「make UI」するためではなく、実際に壊してみたくなる何かを作るためのエージェント群への入力として扱った。
数時間のうちに実行可能なプロトタイプが手元にあった：権限設定、基本的な状態、頼りないが機能するハッピーパス。見た目は私たちの実際の考えよりも完成して見えた—そしてそれがAIの利点であると同時に罠でもあることが判明した。
静的成果物から実行可能なデザインループへ
AIはデザインフェーズを変えているが、ピッチデッキが約束していたような意味でではない。面白いのは、より多くの画面をより速く作れることではない。面白いのはデザインフェーズ自体が実行可能になりつつある点だ。
ただのツールではなくエージェントと共に働くSaaSやプラットフォームのチームでは、デザインはもはや静的成果物の連続ではない—ペルソナ、ジャーニーマップ、ワイヤーフレーム、モック、ハンドオフ。むしろループだ：リサーチ、仮定、実行可能なプロトタイプ、評価、システムの制約、そして反復。デザイナーのアウトプットはFigmaファイルの束であることをやめ、製品とその内部のエージェントがどのように振る舞ってよいかを示す運用マニュアルのようになっていく。
なぜワークフローの再設計がAI導入より重要なのか
ほとんどの企業はまだそこに到達していない。McKinseyの2025年のState of AI調査によれば、現在88％の組織が少なくとも1つの業務機能でAIを使用しているが、ほとんどにとってAIは旧来のワークフローに付け加えられた実験に過ぎない。最も成果を出している企業は、ワークフローをAI中心に再設計し、AIエージェントのスケーリングを進めている可能性がほぼ3倍高い。
その違いはデザインにとって重要だ。プロセスが変わらなければ、AIは単に同じ古いボトルネックにチャットボックスを追加するに過ぎない。プロセスが変われば、デザインフェーズ自体が書き換えられる。
この記事はその書き換えについて、特にSaaSやプラットフォーム製品に携わる人々に向けて書かれている。プロトタイプが振る舞い始め、インターフェースが人間とAIエージェントの両方に役立ち、デザインシステムが機械可読になり、デザインとエンジニアリングの引き渡しが共有可能な実行可能成果物へと崩壊するときに何が起きるのか。そしてAIが「混乱を片付ける」だけで終わらないとき、Aliyehのようなシニアデザイナーが実際に何をすることになるのかについてだ。
従来のデザイン成果物の限界
従来のSaaSプロジェクトでは、デザインフェーズは何かが進行しているという証拠の山を生み出していた。5人か10人のユーザーにインタビューしてその発言をペルソナにまとめ、付箋と矢印でジャーニーをマップし、フローやワイヤーフレーム、高精細なUIをスケッチした。ステークホルダーが「動いているのを見たい」と言えば、きっとプロトタイプをつなぎ合わせたりもした。
そうした成果物はある程度までは有用だった。チームがプロダクトについて話すのを助けた。しかし、それらは意図的に不完全でもあった。
ジャーニーマップは自動化が黙って失敗したときに何が起きるかを教えてくれない。静的なフローダイアグラムは、AIアシスタントが95％ではなく60％の確信度のときにどう反応すべきかを示さない。美しいプロトタイプでさえ、権限、監査ログ、可逆性、障害からの回復などの退屈だが危険な要素をエンコードすることはめったにない。
挙動を可視化するAIネイティブツール
AIネイティブツールがそれを自動的に解決するわけではないが、問題を表面近くに引き上げる。
デザイナーがFigma Makeやv0、Boltのようなシステムに向き合うとき、出力は平面的なモックアップではない。実際に触れられる成果物だ。ボタンは反応し、フォームは送信され、データは何らかの方向に流れる。
Figmaが共有した社内の例の一つでは、チームがMakeを使って複雑なグリッドのインタラクションを約1時間半でプロトタイプした—従来なら数日を要したコードによるプロトタイピングが必要だったはずだ。ここで重要なのは「1.5時間でグリッドができた」という話ではなく、誰もアーキテクチャを決めたりチケットを切る前に、デザイナーがプロダクトの一部の挙動がどのように感じられるかをテストできたという点だ。
実行可能なプロトタイプがデザインの会話をどう変えるか
挙動を体感できるようになると、いい加減な説明は通用しなくなる。ダッシュボードのレイアウトが「見た目がスッキリしているか」議論する代わりに、AI生成の要約が人間の確認なしに基になるレコードを更新してよいかどうかを問うようになる。ボタンの色を議論する代わりに、エージェントがチケットを三回連続で誤分類した場合に顧客データに何が起きるかを決めようとしている。
ここでAIが役に立つのは、スタイリストとしてではない。誰もが見られる場所に挙動のファーストドラフトを安価に出せるようにする点で助けになる。
磨かれた画面と脆い挙動の間のギャップ
落とし穴がある。prompt-to-appツールは、かつてFigmaページの名前を付けるのに要した時間で、完成品のように見える何かを与えてくれる。最近の人間中心のベンチマークでは、Replit、Bolt、Firebase Studioなどのツールで96のプロンプトから生成された288のアプリをテストし、視覚的な磨きと機能的信頼性の間に一貫したギャップがあることがわかった。参加者は実際に使ってみると見たものを信頼しなくなった。画面は光っていたが、挙動は脆かった。
デザインチームにとって、そのギャップこそが物事が面白くなる場所だ。AIは、挙動する前にプロダクトのように見える何かをこれまでになく簡単に作れるようにする。それはデザイナーが不要になるわけではない。むしろ責任が増す。
誰かが、体験が一貫しているか、状態が現実世界の混乱をカバーしているか、人間が実際にエージェントを信頼して代わりに行動させるかどうかを決めなければならない。
