元Appleデザイン・開発チーム責任者が語る:チーム運営で培った手法をAIに移植し、世界レベルのデザインを生み出す方法

Anshu Chimala氏が、Appleでデザイン・開発チームを率いた際に培った探索・評価・削減のプロセスを、AIエージェントが実行できるデザインガイドへと作り変えました。

著者:Lenny's Newsletter09-02 · 約18分
深掘り · 小互解読
1分で要点
  • AIの次語予測と人間の好みへの学習は、デザインを高確率で低リスクな無難なテンプレートへ導きます。プロンプトが曖昧なほど、モデルが代わりに決める既定の選択が増えます。
  • Discover段階では、真に外部のランダム性と十分に大胆な方向性、そして好みを引き出す3段階の手順を用いて、候補を広げてから人間の好みをビルド用ブリーフに落とし込みます。
  • Define段階では、独立したレビュアーがスクリーンショットのみを見て、固定基準で最大のギャップを指摘します。同時に、生成画像や動画を記事末の飾りではなく、インターフェースの素材として扱います。
  • Deliver段階では、グロー・グラデーション・コンテナ・不要なコピーを削除し、AIらしさを除去した上で、重要なコピーは人間が書き直します。最終的には各段階の成果物と合格条件で受け入れます。

Apple で12年間ソフトウェアエンジニアリングとデザイン組織を率いてきた Anshu Chimala 氏が、Lenny's Newsletter にゲスト記事を寄稿しました。その内容は、人間のデザインチームをマネジメントする際に培った手法を、どのようにAIエージェントへ応用したかというものです。彼はチームを率いて未来のAIプロダクトの研究やプロトタイプ制作に携わり、Apple退社後も継続してAIを用いたプロダクトやデザインの実験に取り組んでいます。

最初に、記事内で紹介されている三つの実際の事例をご覧ください。これにより、この手法でどこまでの完成度に到達できるかが分かります。各事例のタスクタイプ、使用モデル、プロンプトの実行回数は、素材の横に直接記載してあります。事前に長い説明を読む必要はありません。

原文の3つの動的ケース|結果、モデル、プロンプトのラウンド数を並べて見る
対話式カロリー記録アプリプロンプト3ラウンド・Claude Fable 5
宇宙探査ゲームプロンプト2ラウンド・Claude Opus 5
動的ブランドランディングページプロンプト3ラウンド・Claude Opus 5 + GPT-5.6 Sol
著者によるAI設計空間の概略図。一般的なAIインターフェースが中心に集中し、大胆なスタイルは外周に位置する

デフォルト出力は高確率の中心に過ぎず、モデル能力の限界を意味するものではありません。

上記はすべて原文の動的例と概念図です。概念図は著者の説明モデルを示すもので、測定された確率分布ではありません。

Anshu氏がこの種の作品を公開するたびに、彼は繰り返し同じ質問を受けます。それは、なぜ同じClaudeやCodexといったツールを使っているのに、ある人は完全で個性的なプロダクトを作れる一方で、自分自身の結果はいつも紫と青のグラデーション、左にテキスト右に画像、ガラスカード、派手なボタンといった、いわゆるAIスロップにしかならないのか、という疑問です。

彼はこの理由を次のように説明します。大規模言語モデルは、トークンごとに次に来そうなコンテンツを予測し、さらに人間の好みに関するフィードバックを通じて学習することで、安定していて信頼性が高く、大多数の人に受け入れられやすい選択を行うようになります。デザインとは、モデルに対して色、フォント、レイアウト、素材、空間関係を連続的に決定することを要求します。プロンプトが明確な取捨選択を示さない場合、各段階で作品は馴染み深く、安全で、平均的な組み合わせへと引き戻されてしまいます。著者はこれを「委員会デザイン」と呼んでいます。誰もが受け入れられるが、ほとんど誰の心も動かせないものです。

この解決策は、もともとAIのために発明されたわけではありません。Appleでチームを率いていたとき、Anshu氏はデザイナーやエンジニアも既存のインターフェース経験に制限され、議論が深まると過去にやったことのある解決策に後退してしまうことに気づきました。そこで彼らは、より厳格な探索と磨き上げのプロセスを確立しました。まずチームをアイデアの限界まで追い込み、次に選択した方向性を納品可能な状態まで繰り返し磨き上げるというものです。現在、AIエージェントはかつてチームが数週間かけて行っていた探索と制作をわずか数時間に短縮しましたが、それでも責任者は、どこを探索するか、何が良いか、最終的に何を削除するかを決定する必要があります。

記事によると、このプロセスは ダブルダイヤモンド(Double Diamond) を「大まかに参考にした」ものです。これは、英国デザイン協議会がデザインとイノベーションのプロセスを説明するために使用するフレームワークです。最初のひし形は、問題を発散的に理解してから、収束させて問題を定義します。二番目のひし形は、再び発散的に複数の解決策を開発し、最終的にテスト、却下、改善を通じて収束させ、納品に至ります。Anshu氏は、Discover、Define、Develop、Deliver の四つのフェーズをそのままコピーしたのではなく、AIエージェントの働き方に合わせて次の三つのフェーズに圧縮しました。

フェーズ 解決すべき問い 人間の役割
Discover 候補空間を広げ、デフォルトのテンプレートから脱却する 外部からの変化をもたらし、感覚に訴える方向性を選択する
Define 方向性を、独立したデザイン言語へと深める 品質の基準を確立し、エージェントからのフィードバックやマルチメディア素材を整理する
Deliver 粗い部分を磨き上げ、納品可能な状態にする 不要な要素を削除し、AI特有の痕跡を見抜き、重要なコピーを書き直す

この方法は、AI自身に「美的感覚を身につけさせる」ことを要求するものではありません。AIは高速な探索、実装、そして様々なメディアの活用を担当し、人間は引き続きクリエイティブディレクターの役割を担います。つまり、変化をもたらし、好みを表現し、品質基準を設定し、最終的な取捨選択を行うのです。

AIが常に安全なテンプレートへ戻ってしまう理由

記事では、同じ「プロダクティビティアプリのランディングページ」というタスクを三回実行し、その結果を比較しています。一回目は普通のプロンプト、二回目は単に言語でランダム性を要求、三回目はさらにシェルが生成した外部のランダム文字列を追加します。まず、三つの結果をまとめて見てみましょう。

01 · 通常のプロンプト:安全なテンプレートに戻る

4つの類似した生産性アプリのランディングページ。一般的に薄い背景、左テキスト右画像、紫のボタンを使用

02 · ランダムと言うだけ:構造は変わらず外見だけ

4つすべてが陶芸と窯のメタファーを中心としたランディングページで、スタイルの変化は限定的

03 · ランダムシード:候補が明確に分散

4つのより多様なランディングページ。異なるフォント、明暗の配色、マトリクスと構図を使用
原文の例は候補の分散を支持しますが、美的品質、有用性、再現性を測定したものではありません。SSoTの研究はランダム文字列が特定の生成タスクの多様性を高めることを支持しますが、デザイン品質を保証するものではありません。
  1. 通常のプロンプト: 四つのClaude Codeインスタンスのほとんどが、紫のグラデーション、左側のタイトル、右側のグラフィック、上部のナビゲーション、派手なボタンといったデザインに回帰しました。ブランド名は変わっても、デザインの文法は変わりません。
  2. 「ランダムにして」とだけ指示: ページは似たような暖色とレイアウトに変わり、陶器のメタファーが繰り返し登場することさえありました。モデルは「ランダムに聞こえる」案を生成しましたが、外部からの変化の源は得られていません。
  3. ランダム文字列を追加: フォント、色彩、明暗、構図が明らかに分散し、候補が同じスタイルファミリー内に密集しなくなりました。

三つ目のステップが示すのは、候補空間が広がったということだけです。美学、実用性、再現性が向上したことを自動的に証明するものではありません。記事内のウェブ実験は一例を示すための比較です。Sakana AI の SSoT 研究は、確率的サンプリングと出力の多様性を検証しましたが、ウェブデザインの品質を検証したわけではありません。

Discover:まず候補空間を広げる

Discoverフェーズの目的は、最初から特定の解決策に飛びつかないことです。まず十分に異なる方向性を複数生成し、その後、人間の反応を使って空間を徐々に絞り込んでいきます。

方法一:モデルに真に外部の変化の源を与える

Anshu氏は String Seed of Thought のアイデアを借用しつつ、Coding Agent 向けに改良を加えました。エージェントに、まずシェルスクリプトで長いランダムな英数字の文字列を生成させ、その文字の形状、繰り返しパターン、特別な数字、構造的な関係性から視覚的なインスピレーションを引き出させるという方法です。

プロンプトは、以下の四つのステップで構成できます。

  1. スクリプトを使用して、十分に長いランダムな英数字の文字列を生成します。
  2. 文字列からデザインルールに変換できる構造を見つけ、配色、フォント、レイアウト、視覚的なリズムをそれぞれ決定します。
  3. この方向性に従ってページを完成させます。途中で一般的なSaaSテンプレートに後戻りしないでください。
  4. 文字列は思考のみに使用し、最終的なインターフェースには表示しないでください。

確認可能な成果物: 同じ製品について、少なくとも4つの候補を生成し、それらを並べてスクリーンショットを撮影します。

受け入れ基準: 候補間で、フォントカテゴリ、明暗の関係性、構図の骨格、情報のリズムに構造的な違いが見られること。ブランド名、メインカラー、イラストを交換しただけでは、異なる方向性とは見なされません。

ここで研究との境界線を明確にしておきます。元々のSSoTメソッドは、モデルが内部でランダムな文字列を生成し、それを操作するというものでしたが、Anshu氏の実装は、シェルが提供する外部のランダム文字列を使用するように変更されています。どちらもデフォルトの好みを打ち破ることを目的としていますが、その具体的なメカニズムは完全に同じではありません。

著者はまた、非常に実用的な長期的な習慣を提案しています。今日は失敗した大胆なプロンプトを保存しておき、新しいモデルがリリースされたら再テストすることです。 以前は壊れたページしか生成できなかった方向性が、アップグレード後に突然安定して実装できるようになった場合、それは新しい能力があなたの利用可能なデザイン空間に加わったことを意味します。古いプロンプトだけで新モデルをテストしていると、このような変化を見逃しがちです。

方法二:野心を、決定を制約できる「世界」として記述する

「もっと大胆に」「もっとハイレベルに」「もっと創造的に」といった指示は、視覚的な制約を何も提供しません。効果的なプロンプトは、ページ全体を統率できる一貫した世界を提供します。例えば、以下のようなものです。

  • プロダクティビティツールを、連続したピクセルアート風のゲームシーンとして表現し、各セクションをゲームのひとコマのように扱う。
  • 機能を等角投影の3Dシティとして組織化し、街区や建物に情報アーキテクチャの役割を持たせる。
  • 機能を読み取れる状態を保ちつつ、過激な非対称性、衝突する色、心地よくないネガティブスペースを使用する。

これらの方向性は失敗する可能性があります。しかし、その失敗自体に価値があります。もしアイデアが聞いた感じ安全すぎるなら、それはおそらく訓練データの平均的な答えしか返ってこないでしょう。逆に、「これをウェブページにできるのか?」と疑問に思わせるようなアイデアこそ、モデルに新しいデザインの文法を試させることになります。

三つのステップでAIのインスピレーションを個人の好みに変える

オリジナルの方向性は、"AIにアイデアを出させて、そのAIのアイデアをそのままAIにフィードバックする"だけでは生まれません。Anshu氏は、人の選択をプロセスに組み込むために、次の三つのステップを使用しています。

  1. 方向性のリストアップのみ行い、詳細には踏み込まない。 AIに、野蛮主義のツール、産業用コンソール、ジェルインターフェース、段ボールのプロトタイプ、コミック風UIなど、一文か二文のコンセプトを大量に生成させます。この段階では、想像力を刺激することだけが目的です。
  2. 気に入った方向性を目に見える形にし、その反応を記録する。 例えば、産業用コンソールには、物理的なボタンの触感と音が必要です。漫画的またはレトロなスキューモーフィズムは避けます。灰色のグラデーションは退屈なので、パウダーコーティング、陽極酸化、または細かい粒子のマテリアルが必要です。
  3. 方向性が定まったら、AIに構築プロンプトを逆算して書かせる。 最終的なプロンプトには、視覚的原則、マテリアル、コンポーネントの一貫性、禁止事項、優先順位が含まれ、Coding Agent が最初のPOCバージョンを作成するために使用します。
まず方向を十分遠くまで押し出し、3ラウンドのフィードバックで収束させる
ピクセルゲームスタイルのインターフェースアニメーション
ピクセルゲームスライス
3D浮遊都市
大胆な非対称
  1. 01最小限のコンセプトだけを列挙し、発想を広げるAIが列挙した多様なデザインコンセプトのリスト
  2. 02好きな点と嫌いな点を指摘し、原則を抽出する触感、エンジニアリング感、レトロ度に関するユーザーの好みのフィードバック
  3. 03コーディングエージェントの初期プロンプトに書き換える精密工業用制御パネルの方向性を詳述した構築プロンプト
3枚のプロセススクリーンショットは原文からのものです。同じラウンドで完全なページを急がないでください。コンセプト、好み、構築制約は3つの異なる成果物です。

確認可能な成果物: 一ページ以内のデザインブリーフ。少なくとも、インスピレーションの源泉、必ず維持すべき雰囲気、明確に避けるべき手法、3〜5のデザインルール、参考画像のセットを含みます。

受け入れ基準: 議論に参加していない別の実装担当エージェントがブリーフを読んだ後、「何をすべきか、何をしてはいけないか、何を最初に実装すべきか」を説明でき、「高級感とは具体的に何か」と問い直さないこと。

Define:方向性を個性的なデザインへと磨き上げる

ランダムシードは多様性を広げることができますが、最初のバッチのページには、トップナビゲーション、左にテキスト右に画像、CTAボタンといった残骸がまだ残っている可能性があります。Defineフェーズの目的は、「少し違う」を「独自のアイデンティティを持つ」へと推し進めることです。

独立したレビュー担当エージェントに結果だけを見せる

コーディングエージェントは、自分の仕事を客観的に評価するのが苦手です。コードの構造、実装コスト、以前の決定、そしてその決定のために書いた理由をすべて背負っているため、既存の解決策にパッチを当て続ける傾向があります。

Anshu氏は、二番目のエージェントをデザイン批評家(Design Critic)として導入しました。各ラウンドで、以下のサイクルが実行されます。

  1. 実装担当エージェントが現在のバージョンを完成させ、スクリーンショットを撮影します。
  2. 新しいコンテキストでレビュー担当エージェントを起動し、スクリーンショットのみを渡します。コード、実装の詳細、過去の意見、前回の弁解は一切渡しません。
  3. レビュー担当は、作品が追求している美学を特定し、トップクラスのデザインスタジオが同じ方向性をどのように完成させるかを想像し、最もギャップが大きい部分を指摘します。
  4. レビュー担当は10点満点でのスコアと、少数の具体的な修正項目を提示します。実装担当エージェントは優先順位に従って修正し、新しいスクリーンショットを提出します。

記事では、実装担当エージェントの完了条件として 9/10 が設定されていますが、レビュー担当がプロセスを終了させるために甘く評価しないよう、このしきい値をレビュープロンプトに書き込まないことが明示的に推奨されています。レビュープロンプトは毎回同じにすることで、スコアの相対的な比較可能性が保たれます。

変化はあるが、骨格は依然として馴染みのある左テキスト右画像

ランダム性を加えたが、類似したページ骨格を持つ4つのデザイン
  1. 01実装担当のスクリーンショット取得
  2. 02新しいコンテキストで結果のみを見る
  3. 03ベースラインと比較し、最大のギャップを指摘する
  4. 04修正後に再スクリーンショット

複数ラウンドのレビュー後:視覚的アイデンティティが本当に分離し始める

原文での複数ラウンドの独立スクリーンショットレビューの前後の長尺画像比較
著者は9/10をプロセス側の停止閾値に設定し、終点をレビュー担当者に書きません。費用と効率の数値は彼のケースからのもので、一般的なベンチマークではありません。

レビュー基準は、三つのレベルに分けることができます。

  • 悪い例: 「きれいかどうか、AIっぽくないかどうかを見る。」この基準は主観的で、毎回の判断がぶれやすいです。
  • 使える例: 「現在の美的方向性を判断する。一流のスタジオがどのように実行するかを想像する。その品質基準とのギャップを見つける。」
  • より信頼性の高い例: 4つの専門的なケーススタディと1枚の現在のスクリーンショットを提供し、レビュー担当に完成度と好みの観点で順位付けさせ、その順位の根拠を説明させる。

参照画像は品質のベースラインとムードボードの役割を果たしますが、模倣の対象ではありません。停止条件も慎重に設定する必要があります。まず一、二ラウンド実行して、主要な問題とスコアが収束するかどうかを確認します。二回連続で意見が行き来したり、スコアが上がらなかったりする場合は、エージェントに無限にトークンを消費させるのではなく、人間が方向性を調整する必要があります。

モデルは役割に応じて割り当てることができます。高速で安価なモデルは反復的な実装を担当し、より高性能なモデルは頻度の低い美的判断を担当します。記事で紹介されたいくつかの事例では、Fable のレビューモデルが生成した出力トークンは、各事例の総量の10%未満でした。著者によると、Fable にページを直接作り直させると、約二倍のコストがかかり、時間もかかったとのことです。この数字は彼の事例のみを説明するものであり、一般的な予算比率として扱うべきではありません。

エージェントに画像生成を明示的に要求する

Coding Agent はデフォルトで、コードに直接書ける素材を好みます。グラデーション、幾何学的形状、グリッド、ガラスカードなどです。これらが使えないわけではありませんが、すべてのビジュアルが数行のCSSから生成されている場合、作品は同じような生成の痕跡を露呈しがちです。

記事のプロンプトは非常に直接的です。「現在のページは平面的すぎる。画像生成を使用して個性を加えなさい。必要に応じて、生成画像をシェーダーや3Dエフェクトと組み合わせなさい。結果をブラウザでフレームごとに確認しなさい。」

原文の4つの動的例。画像、3D、シェーダーが共に視覚的ナラティブを担い、CSSのグラデーションと色ブロックだけがすべてのアートを担うのを避けます。

ツールによって、連携方法は異なります。

  • Codex、Antigravity、または Grok Build に組み込みの画像生成機能がある場合は、エージェントにその使用を明示的に指示するだけです。
  • Claude Code などの環境では、Codex CLI を呼び出して画像を生成できますが、サブスクリプション機能を使用しているのか、追加料金が発生するAPIを使用しているのかを確認する必要があります。
  • OpenAI または Gemini API を直接使用する場合は、独立した、明確な制限付きで、いつでも取り消せるAPIキーを作成する必要があります。
  • エージェントがキーを繰り返し使用する必要がある場合は、リポジトリにコミットされないローカルの環境ファイルに配置し、プロジェクトルールに、キーは開発専用であり、製品には使用できないことを明記します。

確認可能な成果物: ページ内の各ビジュアル素材が、その目的を説明できること。例えば、空間の確立、マテリアルの表現、キャラクターの生成、状態の説明などです。

受け入れ基準: 生成画像を一枚削除したとき、情報と体験に損失がなければ、それはおそらく単なる装飾です。もしすべての生成画像を普通のグラデーションに置き換えられるなら、視覚的な方向性はまだ深まっていません。

ビデオモデルをタイムラインツールとして活用する

この記事では、インターフェースデザインに適した二つのビデオ活用法が紹介されています。

一つ目は、透明感のあるループするモーショングラフィックスです。まず、無地の背景でループする映像を生成し、その後、カラーキーイングやビデオマット処理用のモデルを使用して背景を除去します。こうして、ガラスの破砕、回転、屈折、影、コースティクスなどの複雑な物理的動きをUIに重ね合わせます。ガラスの屈折をよりリアルにするには、ページの背景色と同じ色でビデオをレンダリングし、その背景に屈折の効果を焼き付けてから、背景を除去する方法が効果的です。

二つ目は、状態間のキーフレームトランジションです。二つの製品の静止画から中間のビデオを生成し、ビデオの進行をスクロールやジェスチャーにマッピングします。記事のスーツケースの例では、浮遊している状態、開いて着地する状態、物が上から落ちてくる状態が順に表示されます。前のビデオの最後のフレームが、次のビデオの開始フレームとして使用され、トランジションの不連続性を減らしています。

キーイングループアニメーション単色背景で生成 → キーイング/マスク → インターフェースループに埋め込む
キーフレームスクロールトランジション開始と終了の製品画像 → ビデオ補間 → タイムラインをスクロールにマッピング
ビデオモデルは連続的な動きを生成し、ウェブページはロード、再生、スクロール制御を担当します。複雑なエフェクトでは、フォールバックとしてファーストフレームやポスターを準備する必要があります。

著者は fal.ai のようなアグリゲーションプラットフォームを使用して、エージェントがさまざまなビデオモデルから選択できるようにしています。サンプルのプロンプトで言及されている Seedance 2.5 は、当時のモデルの能力に基づいた提案であり、長期的な固定の答えではありません。

確認可能な成果物: モーションファイル、静止した代替フレーム、トリガー条件、インタラクションマッピング。

受け入れ基準: ループに明確なつなぎ目がないこと。開始時と終了時の状態が連続していること。スクロールの方向がオブジェクトの動きと一致していること。自動再生をオフにするか、reduced motion を有効にした場合でも、ユーザーがページを理解できること。メディアのサイズとデコードコストが、初回表示の体験を損なわないこと。

納品:削除、AI臭の除去、コピーライティングの書き直し

AIは要素を追加し続けるのが得意で、コードを自ら削除することはほとんどありません。作成者は納品段階で、情報や操作能力、状態に関するフィードバックを追加しない要素を削除する作業に最も多くの時間を費やします。

カロリーアプリの初稿はすでに完全な機能を備えていました。しかし同時に、ピンク色の光彩、グラデーションのプログレスバー、ランダムなテキストのアクセントカラー、重複したラベル、大きな空白領域、そしてiOS標準コンポーネントよりも粗雑な自作のボタンや入力欄も含まれていました。

彼の修正要求は、次の三つのグループだけでした。

  1. ページを食べ物の画像を中心としたグリッドに変更する。
  2. グラデーション、光彩、不要なコンテナを削除する。
  3. 可能な限り標準のiOSコンポーネントを使用し、フォントサイズ、間隔、情報密度を引き締める。

削除前

ピンクのグロー、赤いプログレスバー、多くの説明テキスト、小さな食べ物の画像を持つカロリーアプリのインターフェース

削除後

控えめなベージュの背景、少ないテキスト、大きな食べ物の画像、簡素化されたコントロールを持つカロリーアプリのインターフェース
原文の前後のバージョン。比較は著者のデザインの選択を示すもので、ユーザー調査やコンバージョン率の証明とは同等ではありません。

改訂後、食べ物の画像とその日の摂取量が視覚的な焦点となり、インターフェースの色は少なく、テキストは短く、コントロールはシステムの習慣により近いものになりました。この前後の画像の組が示しているのは、作成者のデザイン上の判断であり、ユーザー調査やコンバージョン率の実験の結果ではありません。

すべての要素に対して、削除テストを一回実施できます。

  • 削除した後、ユーザーは重要な情報を失うか?
  • 操作の入り口を失うか?
  • 現在の状態や次のステップを理解できなくなるか?
  • このデザインの方向性において、最も特徴的な部分が損なわれるか?

四つの質問すべてが「いいえ」の場合、削除は、美化を続けるよりも効果的であることが多いです。

公開されているページでは、テクニック7「AI臭を取り除く」の見出しの時点でペイウォールが発生します。テクニック8「コピーライティングを手で書き直す」については、公開側の要約によって確認されています。公開されている情報には、これらの二つのセクションの完全なリストは含まれていないため、ここで作成者の代わりに詳細を補足することはしません。確認できる納品の原則は次の通りです。人間は、「テック製品らしく見せるため」だけに積み上げられた視覚的な副産物をチェックし、タイトル、ボタン、空の状態、エラーメッセージなど、製品のトーンに最も影響を与えるコピーライティングを自分自身で処理する必要があるということです。

検証可能なワークフローとして実行する

以下の実行順序は、公開されている方法論を、デザイン責任者とCoding Agentに渡すことができるプロセスとして整理したものです。

  1. 製品の制約を明確に書き出す。 ターゲットユーザー、中核となるタスク、維持すべき機能、デバイスの境界を記録します。成果物は、問題定義をまとめた一ページです。
  2. 8〜12個の短い方向性を生成する。 まず幅を広く、その後で深く掘り下げます。同じレイアウトで外観だけを変えることは許可されません。成果物は方向性のリストです。
  3. 外部からのランダムな変動を取り入れる。 差異が乏しい方向性にはランダムな文字列を使用し、少なくとも4枚のサイドバイサイドのスクリーンショットを生成します。
  4. 人の好みを注入する。 2〜3の方向性を選択し、好きな点、嫌いな点、過剰な点、欠けている点を項目ごとに書き出します。成果物は、禁止事項を含むデザインブリーフです。
  5. 最初のバージョンのPOCを作成する。 Coding Agentにブリーフに従った実装を依頼しますが、この段階では本番運用レベルの完全性は追求しません。
  6. 独立したスクリーンショットレビューを開始する。 レビューでは、結果と固定された品質ベースラインのみを確認します。まず一、二回のイテレーションを行い、意見が収束していることを確認します。
  7. 理解のニーズに応じて画像と動画を追加する。 各メディアには、情報、素材、空間、状態に関する役割を持たせ、静止画やアニメーションなしの代替手段を用意します。
  8. 削除レビューを実施する。 情報、操作、状態、または特徴を追加しない要素を削除し、成熟したシステムコンポーネントを優先的に使用します。
  9. コピーライティングと最終検収を人間が行う。 重要なテキストを書き直し、レスポンシブ対応、パフォーマンス、アクセシビリティ、実際のタスクフローをチェックします。
01

Discover

外部ランダム性、大胆な方向性、3段階の好み抽出

成果物:比較可能な候補の複数セットと構築ブリーフ合格条件:フォント、配色、構図、メタファーがもはや表面的な変更に留まらない
02

Define

スクリーンショットレビュー、固定ベースライン、画像とビデオの生成

成果物:レビュー済みのビジュアルシステムと、フォールバック付きのリッチメディア合格条件:最大の視覚的ギャップが埋まり、モバイルと静的状態が成立する
03

Deliver

装飾の削除、AI痕跡の除去、人間によるテキストの書き直し

成果物:簡素化されたインターフェース、人間が書いたコピー、納品チェックリスト合格条件:すべての要素に機能があり、主要タスクが明確で、AIの痕跡が除去されている
「センスを良くする」という曖昧な要求を、納品・検証・終了条件が明確な3段階のワークフローに変換します。

このシステムの本質は、より長い「魔法のプロンプト」を書くことではありません。責任者が、複数の候補を生成し、結果を注意深く確認し、具体的な好みを表現し、安定した品質ベースラインを確立し、最後には完成したコードを削除することが求められます。AIは探索のスピードと実装能力を提供し、人間は方向性、基準、取捨選択を担当します。

↑ 本文ここまで
✓ この記事は全文無料です

メンバーは全文 Markdown のコピー・保存に加え、自分の AI に購読・質問させることができます。

原文を読む ↗
📮 新着解説をメールでいち早く

役に立ちましたか?メールを登録すると、新着解説を公開と同時にお届けします。解除はいつでも。