AIにデザインを頼む方法

私はプロダクトデザイナーです。このサイトはデザインからコードまで自分でつくりましたが、コードを直接打つことはしません。代わりに依頼を書いています。

そうやって働いていると、少し不思議な瞬間があるんです。同じAIに似たような画面を任せたのに、ある日は一度で終わり、ある日は五回も差し戻すことになる。最初はただの運だと思っていました。今はそう思いません。結果の良し悪しは、AIの性能よりも依頼がどれだけ正確だったかに、はるかに大きくかかっていました。

以下は、ここ数日このサイトを直しながら実際に下した判断と、私が間違えた場所です。原則を先に立てて守ったわけではなく、たいてい間違えてから分かったことなので、その順番のまま書きました。

1. 目で見たものは、確認ではありませんでした

ケースページのギャラリー入口カードを、3Dの奥行きスタックに替える作業でした。画像五枚が内側へ退いて、奥へ行くほどぼやける形です。

つくってから画面を見たら、奥の層がほどよくかすんでいたんですね。ブラーがちゃんとかかったなと思って、そのまま進むところでした。それでも習慣で計算値を出してみたら、こうなっていました。

d0: filter: none
d1: filter: none
d2: filter: none
d3: filter: none
d4: filter: none

ブラーは一層もかかっていませんでした。私がかすんで見えたのは、奥の層に入れた明るさの低下だったんです。考えてみれば当たり前で、目は「なぜぼやけているのか」までは区別できず、それらしいほうへ勝手に結論を寄せます。

原因はCSSの一行でした。max(0px, var(--d) - 1) の 0px は長さなのに、var(--d) - 1 はただの数値です。こうして単位が混ざるとブラウザは式ごと捨ててしまい、そのせいで filter プロパティ全体が死にます。エラーも警告も出ません。ただ静かに、何も起きないだけです。

もっと痛いのはその次でした。同じバグが試作ファイルにもあったんです。私はその試作を見ながら「やっぱりブラーがあるほうがいいな」と判断したのに、そのとき見ていた画面にはブラーが無かったわけです。無いものを見て、良いと言っていたことになります。

それで頼み方を変えました。「ブラーを入れてください」で終わらせず、「層ごとのfilter計算値も一緒に出力してください」を付けます。目で見るのではなく、値で受け取るということです。

2. 形容詞はそのまま渡してはいけません

同じカードのモバイル動作を決めるときでした。指で使う画面にはホバーがないので、カードが自分で動く必要があります。そこで私はこう頼みました。

モバイルではループにできませんか。速すぎない程度で。

今見ると、この一文では何も決まっていません。「速すぎない」は4.2秒かもしれないし9秒かもしれなくて、その二つはまるで違う感じなんですね。

なので値を決めてもらう代わりに、選択肢をつくってもらいました。4.2秒で一枚ずつ送るもの、6.5秒のもの、それから画像はそのままで層の間隔だけがゆっくり開いて閉じるもの。三つを実際に動く形にして、並べて見ました。

見たら答えはすぐ出ました。このカードが画面に留まる時間は短いので、6.5秒だとスクロールで通り過ぎるあいだに一枚も入れ替わりません。層だけ呼吸するものは静かでいいのですが、新しい画像を最後まで見せてくれない。4.2秒に決めました。

形容詞を数字に変えるのは結局こちらの仕事です。好みの領域ですから。ただ、形容詞を比べられる選択肢に変えておく作業は任せられます。

3. 制約は答えではなく、探索の範囲でした

このカードの元の姿は、正方形の画像三枚を5度ずつ回して重ねたものでした。少し変えたくて、こう頼みました。

重なるのではなく別の方式で、似ないように。

三つ出てきました。縦に割った断片がそれぞれ違う速度で流れるもの、フィルムストリップのように両端が切れるもの、インクの下に敷いた画像がカーソルに従って現れるもの。三つとも重なりは使っていません。

ところが三つとも何かが足りませんでした。特に三つめは、止まっているときはただの空のカードに見えたんです。カーソルを載せるまでは何もない灰色の面で、マウスのない機器では永遠に空のカードのままです。

ここで、私がかけた制約のほうが問題だったと気づきました。「重ねないこと」はもともと既存と違って見せるための手段だったのに、いつのまにかそれ自体が目的になっていたんですね。なので外しました。

重なってもいいので、もっと多様に。

六つ追加で出てきました。カーソルの通った跡に写真が落ちて積もるもの、内側へ列をなして退く奥行きスタック、角がめくれて下の一枚が覗くもの、手札のように扇で開くもの、全量を小さく敷いたコンタクトシート、一枚ずつ送るディーリング。結局選んだのは、重なりを使う案でした。

制約は探索の範囲を狭める道具です。狭めても答えが出ないなら、答えが無いのではなく範囲の取り方を間違えたということになります。

4. 技術的な懸念は言いますが、決定までは渡しません

奥行きスタックをつくるとき、私はブラーを外しました。それなりに理由があって、五層すべてにブラーをかけるとモバイルでの合成コストがけっこう大きいですし、明るさの差だけでも奥行きは十分読めますから。

ところが試作を見て気持ちが変わりました。ブラーがあるほうが明らかに良かったんです。

こういうとき、たいてい二つのうちどちらかを選ぶことになります。性能を理由に押し切るか、きれいだからと懸念を見なかったことにするか。私は三つめを取りました。手前の二層は鮮明なままにして、三層目からだけブラーをかけます。こうすると層の奥行きはそのまま生きて、ぼかしの演算は半分以下に減ります。

デザインエンジニアの居場所はここだと思っています。性能も絶対条件ではないし美感も同じなのですが、両方を知っている人だけが、こういう折衷案をつくれるので。

5. 規則は言葉ではなくコードに残します

フッターに単語が流れる帯があります。もとはこうでした。

Designer · Typography · Editorial · Grid systems · Identity · Brand

典型的なグラフィックデザイナーの語彙ですね。今の自分の仕事と合わないので変えました。

Design engineer · Prototyping · Interaction · Design systems · Motion · Interface

ところが数日後に見直したら、これも違っていました。Motion、Interface、Interactionのような言葉は、結局「自分が扱える表面」の一覧です。職種の名前を入れ替えただけで、性格は前とまったく同じでした。三度目に直しました。

Design engineer · Problem framing · First principles · Prototyping · Judgment · End to end

三度直すあいだ、毎回テストが壊れました。古い一覧を期待するテストが、それを掴んでいたからです。面倒ではあるのですが、実はこれが得なんです。何が約束だったのかをコードが覚えている、ということですから。

なので最後に直すときは禁止リストを一つ足しました。ReactやTypeScriptのようなスタック名と一緒に、Motion、Interface、Typography、Grid systemsも入れてあります。スキルの羅列へ戻ること自体を防ぐためです。次に私がうっかり破れば、テストが先に声を上げます。

文章も似たやり方で守っています。AIが書いた韓国語には少し癖が出ます。文の61%に読点が入り（人が書くと26%ほどだそうです）、特定の接続表現が繰り返され、文末が一種類に寄る。これを毎回目で捕まえるのは難しいので、検査器を一つつくっておきました。この記事も読点の比率と常套句を測ってから上げています。

6. 依頼が続けて失敗するなら、階層が違います

さっきの語の帯に戻ると、私は二度頼んで二度とも失敗しました。一度目は語彙を変え、二度目は職種名を変えたのに、結果は相変わらず「できることの一覧」でした。

三度目に言ったのはこれです。

Motionのようなものより、根本的な問題解決を強調してください。デザインスキルより原論的なものを。

このとき初めて依頼の階層が変わりました。前の二度は一覧の中で語を入れ替えろという依頼で、三度目は一覧の性格そのものを変えろという依頼でしたから。

同じ失敗が繰り返されるときは、より正確な語を探すより、一段上で問い直すほうが早いです。何を直すかではなく、自分が今この瞬間、何を直せと言っているのかを。

まとめると

六つは結局、同じ話です。AIは判断を代わってくれません。代わりに、判断を早く試させてくれます。

インタラクションの試作を九つ一日でつくってみること、ループ速度を三つ並べて回してみること、ブラーの値を層ごとに出して確かめること。以前ならエンジニアの時間を借りる必要があって、だから大半は想像で決めていました。今はつくってみてから決めます。

何をつくるかを選ぶこと、それが正しいか測ること、間違いを認めること。それは今も自分の取り分です。しかもその取り分は減っていません。むしろ試せる回数が増えたぶん、判断すべきことも一緒に増えました。

依頼は仕様です。仕様がぼやければ、結果もぼやけます。