🎨 PromptForge — マルチモデル対応AIイメージプロンプトジェネレーター

インスピレーション

課題の発見

AIイラスト生成の現場で、ある事実に気づいた。

同じ「かわいい女の子を描いて」という意図でも、モデルごとに必要なプロンプトの構造が根本的に異なる。

モデル	トークン上限	得意領域	プロンプト戦略
Seedream 5.0 Pro	~500トークン	大気感・ライティング	凝縮・キーワード重視
GPT Image 2.0	~4000トークン	テキスト描画・構造忠実性	長文・セクション構造
Gemini (Imagen)	~1000トークン	バランス型	中程度・自然言語

毎回手動で変換していた。これは自動化すべき問題だった。

数学的直感

プロンプト変換は、本質的に意味空間の射影と捉えられる。

ユーザーの意図ベクトル $\vec{I}$ を、各モデル固有のプロンプト空間 $P_m$ に射影する写像 $f_m$ を定義する：

$$f_m: \vec{I} \rightarrow P_m \quad \text{where } m \in {\text{Seedream}, \text{GPT}, \text{Gemini}, \ldots}$$

各 $f_m$ は以下の制約を満たす必要がある：

$$|f_m(\vec{I})| \leq T_m \quad \text{(トークン上限制約)}$$

$$\text{sim}(G(f_m(\vec{I})), \vec{I}) \geq \theta \quad \text{(意味保存制約)}$$

ここで $G$ は画像生成関数、$\text{sim}$ は意味的類似度、$\theta$ は品質閾値。

学んだこと

1. プロンプトはプログラミング言語である

各モデルのプロンプトには「文法」がある：

Seedream文法 := [スタイル] + [被写体] + [構図] + [色彩] + [雰囲気]
                 ← 全体500トークン以内 →

GPT Image文法 := [概要]
                  + [セクション1: キャラ詳細]
                  + [セクション2: 環境詳細]
                  + [セクション3: ライティング]
                  + [セクション4: スタイル指示]
                  ← 各セクションが独立して解釈される →

2. 情報密度 $\rho$ の最適化

トークン上限が厳しいモデルほど、情報密度を高める必要がある：

$$\rho_m = \frac{\text{意味量}(f_m(\vec{I}))}{|f_m(\vec{I})|}$$

Seedreamでは $\rho$ を最大化するために形容詞の圧縮、冗長な説明の排除、カンマ区切りのキーワード列挙が有効。一方GPT Imageでは $\rho$ を下げて冗長性を持たせた方が出力が安定する。

3. モデル固有の「地雷ワード」

各モデルには、意図しない出力を引き起こすトリガーワードが存在する：

モデル	地雷ワード例	結果
Seedream	"realistic" + "anime" 併用	不気味の谷
GPT Image	"simple"	品質低下
Gemini	特定の固有名詞	安全フィルタ

これらをネガティブパターンDBとして蓄積し、自動回避する仕組みが必要だと学んだ。

プロジェクトの構築

アーキテクチャ

graph TD
    A[ユーザー入力] -->|自然言語| B[意図解析エンジン]
    B -->|意図ベクトル| C{モデルセレクター}
    C -->|Seedream| D[Seedream変換器]
    C -->|GPT Image| E[GPT Image変換器]
    C -->|Gemini| F[Gemini変換器]
    D --> G[トークン最適化]
    E --> G
    F --> G
    G --> H[ネガティブパターンフィルタ]
    H --> I[最終プロンプト出力]

    J[(スタイルDB)] --> B
    K[(地雷ワードDB)] --> H
    L[(成功プロンプトDB)] --> G

技術スタック

レイヤー	技術	理由
フロントエンド	Next.js + TypeScript	SSR対応、型安全
UI	Radix UI + Tailwind	アクセシブルかつ高速開発
バックエンド	Next.js API Routes	フルスタック統合
LLM	Gemini API	プロンプト変換の推論エンジン
DB	Supabase (PostgreSQL)	スタイルDB・履歴管理

コア変換アルゴリズム

プロンプト変換のパイプライン：

入力: ユーザーの意図 (自然言語)
      ターゲットモデル m
      スタイルプリセット (optional)

Step 1: 意図をセマンティック要素に分解
        → {被写体, 構図, スタイル, 色彩, 雰囲気, テキスト要素}

Step 2: モデル固有の優先順位で要素を並び替え
        → Seedream: スタイル > 被写体 > 雰囲気 > 色彩
        → GPT:     被写体 > 構図 > スタイル > 色彩

Step 3: トークン予算配分
        → 各要素に予算 b_i を割り当て: Σb_i ≤ T_m

Step 4: 要素ごとにプロンプトテキスト生成
        → 予算 b_i 以内で最大情報密度の表現を選択

Step 5: ネガティブパターンフィルタ適用
        → 地雷ワードの検出と代替語への置換

出力: 最適化済みプロンプト文字列

直面した課題

課題1: 「同じ絵」の定義

「GPT Imageで生成した絵と同じものをSeedreamで作りたい」

この「同じ」が曖昧。ピクセル単位の一致は不可能なので、スタイル一致度と構造一致度を分離して定義した：

$$\text{一致度} = \alpha \cdot \text{sim}{\text{style}}(A, B) + \beta \cdot \text{sim}{\text{structure}}(A, B)$$

ここで $\alpha + \beta = 1$、ユーザーが重視する軸によって重み付けを変える。

課題2: トークン圧縮の品質劣化

Seedream向けに4000トークンのGPTプロンプトを500トークンに圧縮すると、何かが必ず失われる。情報理論的に：

$$H(\text{GPTプロンプト}) > \log_2(|\text{Seedream語彙}|^{500})$$

の場合、ロスレス圧縮は不可能。

解決策: ユーザーに「何を優先するか」を選ばせるUI — キャラ重視 / 背景重視 / 雰囲気重視のスライダーを設け、圧縮時の情報損失の方向をユーザーが制御できるようにした。

課題3: プロンプトの評価指標

「良いプロンプト」を定量評価する指標が存在しない。

暫定解: ユーザーフィードバックループ

生成 → ユーザー評価(1-5) → プロンプトDB蓄積 → 類似ケースの成功率計算

$$\text{Quality}p = \frac{\sum{i=1}^{n} r_i \cdot w_i}{\sum_{i=1}^{n} w_i}$$

$r_i$ は評価スコア、$w_i$ は時間減衰重み $w_i = e^{-\lambda(t_{\text{now}} - t_i)}$ で新しい評価を重視。

課題4: スタイル語彙の標準化

ユーザーが「エモい感じ」と入力した場合、これをモデル別にどう変換するか：

ユーザー入力	Seedream変換	GPT Image変換
「エモい」	`nostalgic, warm light, golden hour, film grain`	`A nostalgic atmosphere with warm golden-hour lighting, slight film grain texture, evoking a sense of gentle melancholy`
「バズる」	`vibrant, eye-catching, dynamic composition, high contrast`	`An immediately striking composition with vibrant saturated colors and dynamic angular framing designed to stop scrolling`