スタイル名を知らないところから探し始めたい
画像生成AIの使い方を調べていると、「デザインのスタイル名を指定すると、プロンプトを具体的にできる」「欲しい雰囲気に近づけやすい」といったアドバイスを見かけます。
ただ、そもそも名前を知らなければ指定できません。Future Funk、Art Deco、Vaporwave、Y2K。そうした言葉と画像を見ながら、どんな方向があるのか、自分はどんな雰囲気に惹かれるのかを探れるものが欲しいと思いました。
デザイン名を一覧で紹介するサイトはあります。でもそうではなくて、候補を見比べたり、「もう少しレトロに」「もっと明るく」と動かして変化を見たりしたい。眺めているうちに、気になるものが変わったら、そちらも試してみる。そんな探索をするために作ったのが、Design Compassです。
参考画像やスライダーを入口に、スタイルの候補を3件ずつ表示するWebアプリです。「こういう方向かもしれない」という複数の可能性を見ながら、自分でも操作して、行ったり来たりできるようにしています。
3件の候補を見て次に試す方向を考える
Design Compassでは、探索の途中で好みや気になる雰囲気が変わることも含めて扱っています。最初に「これが欲しい」と説明できる必要はなく、最後に一つのスタイルへ決めることも必須ではありません。既存の画像を正しいスタイルに分類することとは目的が違い、候補を見た人が「こういう方向もあるかもしれない」と次を試せることを重視しています。
たとえば、参考画像から検索して3件の候補を見たとします。「この色づかいが気になる」と思っていたけれど、別の候補の形にも惹かれるかもしれません。そこからスライダーを動かして検索し直し、候補がどう変わるかを見ます。さらに別の組み合わせを試したり、値を戻したりします。いろいろな雰囲気をザッピングするうちに、最初には考えていなかった方向も見えてくると思います。
候補を3件返すのは、複数の可能性を見比べる余地を持たせたいからです。サービスが示す候補と、それを見た人が感じることの両方から、次に試す方向が生まれるようにしたい。Compassという名前も、探索中に方向の手掛かりを得る道具というイメージで付けました。
スタイル名も、その手掛かりの一つです。気になる名前からほかの作例を調べたり、画像生成のプロンプトに取り入れて試したりできます。そこで見つけたものをきっかけに、また別の雰囲気に興味が向いてもいい。
操作は、参考画像を選び、候補を見て、スライダーを調整してもう一度検索する、という流れです。画像を入力した場合は、その特徴からスライダーの初期値を求めます。画像がなくても、すべてのスライダーが50の中立な状態から検索できます。
最初のアイデアには、サービスからの質問に答えながら探す対話モードも含めていました。現在のコードで実装しているのは、画像とスライダーを使う探索です。対話モードのボタンは「Coming Soon」に相当する案内付きで無効になっており、LLMは検索に使っていません。対話を通じた探索は、今後取り組みたい方向として最後に紹介します。
レトロ感と未来感を両方試せるスライダー
いろいろな組み合わせを試すためには、スライダーの分け方も大切です。
最初のアイデアでは、「レトロ ↔ 未来的」という軸を例に挙げていました。一方、実装では時代感と未来感を独立した二つのスライダーにしています。
Retro-futurismのように、昔の人が想像した未来を感じさせるデザインなら、レトロ感と未来感、どちらも強くてよいからです。一つのスライダーの両端に置くと、片方を強めるほど、もう片方を弱めることになってしまいます。
たとえば、時代感を強めた状態から未来感も上げてみる。さらに明るさを変えると、候補はどう変わるのか。そうやって、気になった組み合わせを試せるようにしました。これは操作の例で、特定の候補が必ず出るという意味ではありません。
スライダーは全部で16本です。現在の軸には「繊細 ↔ 大胆」があります。ほかにも「パステル ↔ ビビッド」「有機的 ↔ 幾何学的」「落ち着いた ↔ エネルギッシュ」などを用意しています。
操作する前には思い付かなかった組み合わせも、スライダーがあれば試すきっかけになります。感覚を扱うUIとして、その選択肢をできるだけ残しておきたいと考えています。
デザインの地図と人が動かせる方向を分ける
ここからは、候補を出す仕組みを紹介します。内部では、画像を数値のベクトルに変換し、スライダーによって探索位置を動かして、その位置に近いスタイルを探しています。
現在の生成済みデータは、60スタイルと20種類の共通モチーフを組み合わせた1,200画像分です。
画像の特徴抽出には、OpenCLIPのViT-B-32、学習済み重みはlaion2b_s34b_b79kを使っています。画像から得た512次元のEmbeddingをL2正規化し、PCAで12次元に圧縮します。この12次元の空間を、デザインの地図として扱っています。
各スタイルには画像ごとのばらつきがあるので、一つの中心点だけではなく、広がりのある領域として表します。各スタイルの平均と、Ledoit–Wolf法で推定した共分散を使い、探索位置からのマハラノビス距離で候補を並べます。領域同士は重なっていてもかまいません。その位置から近い3件を、見比べる候補として返します。
結果カードの「近さ」は、その距離を0から1の範囲に変換した値です。スタイルごとの確率を足して1にするものではないため、「この画像がそのスタイルである確率」としては扱いません。参照画像には、各候補スタイルに属する20画像のうち、探索位置にユークリッド距離で最も近い画像を選びます。名前と参照画像を一緒に見ることで、候補ごとの雰囲気を比べられます。
この地図の中を人が移動するために用意したのが、16本のスライダーです。内部の12次元と、画面上の16本は別のもので、それぞれのスライダーが空間内の移動方向に対応しています。
軸は、CLIPのテキストEmbeddingからオフラインで生成します。たとえば時代感なら、ニュートラルなデザインを表すプロンプト群と、レトロなデザインを表すプロンプト群を用意します。それぞれのEmbeddingの平均を取り、その差をPCA空間に射影して正規化したものを軸方向にします。
画像投入直後のスライダー値は、画像の位置を各軸へ射影し、1,200画像の分布のどのあたりにあるかを0〜100で表したものです。スライダーの移動量も、その分布に合わせて調整しています。
こうして、画像から得た探索位置と、「レトロ感を強める」といった操作を同じ空間で扱っています。ただし、「時代感」という名前を付けた方向が、人の感覚といつでも一致するわけではありません。動かしたときの候補の変化も含めて、軸の定義や検索結果を確かめていく必要があります。
行ったり来たりできるよう同じ条件では同じ位置に戻す
いろいろ試して見比べるには、操作と結果の関係が安定していることも大切です。そのため、探索位置は検索のたびに基準点から計算し直します。
画像を入力した場合は、その画像の位置と、入力直後のスライダー値を基準として保持します。そこに、現在のスライダー値と基準値との差に応じた移動を加えます。画像がない場合の基準点は12次元空間の原点で、スライダーの基準値はすべて50です。
たとえば未来感を少し強めて検索し、そのままもう一度検索したとします。同じ操作状態なのに、検索ボタンを押すたびにさらに未来方向へ動いてしまうと、何を調整しているのか分からなくなります。実装では前回の検索位置に移動を積み重ねないため、同じ基準点とスライダー値なら同じ位置を計算します。
スライダーを動かした後に値を戻せば、元の条件でもう一度候補を見られます。リセットも実装していて、画像がある場合は画像投入直後のスライダー値へ、画像がない場合は中立な値へ戻して再検索します。画像を取り除いた場合は、画像の基準点と結果を消し、中立な状態に戻します。
これは実際に起きた不具合の修正談ではなく、仕様で決めて実装した振る舞いです。気になった方向を試してから戻ることも、探索の一部として扱っています。
画像の推論と検索をブラウザ内に移す
探索をWebアプリとして公開するにあたり、実行する場所も変えました。
Phase 1の仕様書では、フロントエンドを表示と操作に専念させ、画像の推論や探索計算をバックエンドで行う構成を想定していました。公開に向けて、Cloudflare Pagesとブラウザ内推論を使い、無料でサービス提供する方針に変えています。
現在のフロントエンドはReact、TypeScript、Viteで構成し、画像推論にはONNX Runtime Webを使っています。OpenCLIPの画像エンコーダーをFP32のONNXモデルへ変換し、WebGPUを優先して初期化します。WebGPUでセッションを作れない場合は、WASMを試します。
画像を入力したときにモデルを読み込んで推論し、その後のPCA変換や候補検索もブラウザ内で行います。画像なしのスライダー検索では、画像モデルを読み込む必要はありません。PCA、スタイル領域、軸、参照画像の位置は、あらかじめ生成した静的なJSONから読み込みます。
配信構成は、アプリをCloudflare Pages、モデルと結果の参照画像をCloudflare R2に置く形です。通常の画像解析と検索にFastAPIは不要です。ただし、モデルや参照画像のダウンロードは発生します。ブラウザ内で推論することと、通信が一切ないことは別です。
移行で重要なのは、同じモデルを使うだけでなく、画像の前処理もそろえることです。実装では、Python側のPillowに合わせたリサイズと中央切り抜きをブラウザ側に用意しています。リサイズを横方向と縦方向の2段階で行い、途中の8ビット整数への丸めも合わせています。
次は対話しながら候補を見比べたい
今後やりたいのは、質問への回答と候補を見た感想を行き来する、対話を通じた探索です。
たとえばサービスから、レトロな雰囲気が気になるかを聞く。その答えを受けて、「こういう方向かもしれません」といくつかの候補を出す。候補を見て「もう少し明るくしてみたい」「こちらの雰囲気も気になる」と感じたら、また質問や提案を重ねる。レトロと未来を一緒に試すような組み合わせも含めて、やり取りできるようにしたいと考えています。
回答や候補への反応を蓄積しながらも、途中で気が変わったり、以前気になった方向をもう一度試したりできる形を考えています。最初の回答だけでは思い付かなかった候補に出会い、そこから話が広がるような対話にしたいです。
画像生成AIにスタイル名を指定するとよいと言われても、名前を知らなければ指定できない。そこから始まって、名前と画像を眺めるだけでなく、自分で変化を起こしながら探れるものを作りました。
3件の候補を見比べて、スライダーを動かし、気になった方向を試す。その途中で新しい好みに気付いたり、試したい雰囲気が変わったりすることもあると思います。Design Compassを、そうした探索の手掛かりを得られる場所にしていきたいです。