Claudeに「画像を作って」と頼んでも作れない。テキストを書くAIと、絵を描くAIは別物だからだ。
じゃあ絵が描ける方を横に置いて、Claudeに使わせたらどうなるのか。しかも環境の構築からプロンプトの執筆、出来の判断まで全部任せたら。
やってみたら半日で動いた。おもしろかったのはそこから先で、動いてからの数時間はほぼ全部、失敗を見つけて直す時間だった。その記録を書く。
何を作ったか
ローカルPCで動く画像生成環境（ComfyUI + Stable Diffusion XL）を、必要なときだけ起動する形で組んだ。使い終わったら落ちる。20分放っておいても勝手に落ちる。ゲームを起動したら落ちる。
うちのGPUはVRAM 8GBで、常駐させると他の作業を確実に圧迫する。だから「常にいる召使い」ではなく「呼んだら来る職人」にした。
この構成自体はよくある話だ。この記事の本題は、作った後に何が壊れていたかの方にある。
私は日本語で言うだけ、英語は書かない
いちばん体感が変わったのはここだった。
画像生成は普通、英語のプロンプトを書く技術がいる。「マゼンタとシアンを効かせて」「85mmレンズで浅い被写界深度」みたいな語彙を覚えて、順番を工夫して、何度も打ち直す。私はその修行をしていない。
今回はその工程をまるごとClaudeに渡した。私が言うのは日本語で「楽しそうに笑ってる女の子が海辺で走ってる絵」くらいのものだ。英訳も語順の調整も、失敗したときの原因究明も向こうがやる。
そして重要なのは、Claudeは出来上がった画像を実際に見られるということだ。生成したPNGを読み込んで、「手の指が破綻している」「構図が中央に寄りすぎ」と自分で判定して、プロンプトを直して出し直す。
つまり人間がやっていた試行錯誤のループが、こちら側の手を離れて閉じる。この閉じたループが成果物であって、画像生成ソフトの方はただの実行エンジンだ、というのが今回いちばんの発見だった。
失敗1: 空いてるドライブに置いたら4倍遅かった
最初、生成1枚に73〜87秒かかっていた。遅い。
原因を探ると、実際に絵を描いている計算は14秒しかかかっていない。残りの60〜70秒は、6.6GBのモデルファイルを毎回ディスクから読み直す時間だった。
なぜ毎回読み直すのか。置き場所をDドライブにしていたからだ。そしてDドライブは5400回転のハードディスクだった。
これは我ながら間抜けだった。「Dドライブは空きが1TBもあるから大容量のものはそこへ」と何も考えずに置いた。でもDドライブの空きが大きいのは、容量の大きい安いHDDだからであって、速度が要るものの置き場所ではない。写真サーバーの保管先としては正しい選択でも、今回は真逆だった。
CドライブのSSDへ移したら21秒になった。約4倍。
ついでに「VRAMにモデルを常駐させる設定」も試したが、こちらは487秒とむしろ大幅に悪化した。8GBのGPUはWindowsのデスクトップ側（ブラウザやエディタ）と取り合いになるので、常駐させようとすると破綻する。善意の最適化が逆効果になる典型で、測らずに入れていたら気づけなかった。
失敗2: 顔が溶けた。でも犯人はモデルではなかった
浜辺を走る人物を作らせたら、顔が明らかに崩れていた。
原因の候補は2つあった。ひとつは使っていたモデルが人物の顔に弱いこと。もうひとつは、全身が写る構図だと顔が縦150ピクセルくらいしか占めていないこと。
直感的には前者を疑う。実際に測ったら、支配的だったのは後者だった。
拡散モデルは、与えられた解像度なりの細かさでしか描けない。顔に150ピクセルしか割り当てられていなければ、どんなに優秀なモデルを持ってきても顔は溶ける。モデルを替えるだけでは直らない問題だった。
解決策は、生成した後に顔だけを検出して切り出し、1024ピクセル相当に拡大して描き直し、元の位置へ戻す工程を挟むことだった。同じ設定・同じ乱数のまま、この工程の有無だけを比べるとこうなる。
上が処理前、下が処理後だ。眉の左右が揃い、目の周りの黒い滲みが消え、潰れていた歯が一本ずつ描かれている。
追加でかかる時間は2〜3秒だった。ほとんどタダだ。
失敗3: 「人物だから付ける」という覚えたてのルールが間違っていた
顔の描き直しが効いたので、Claudeは「人物が写る絵には必ずこの工程を付ける」というルールを自分の手順書に書き込んだ。
しばらくして、原色ベタ塗りのポスター風イラストを作らせた。
ここでも「人物だから」とルールに従って顔の描き直しを掛けたのだが、掛けた方が悪くなった。顔の輪郭に淡いフチが出て、唇と眉の線が甘くなる。この工程は要するに顔を写実方向へ寄せる処理なので、硬いエッジが命のフラットな絵とは真逆に働く。
判断基準を「人物だから付ける」から「写実だから付ける」に書き換えた。
覚えたてのルールが早々に反例にぶつかって修正される、という流れがそのまま観測できたのがおもしろかった。しかも修正のきっかけは私の指摘ではなく、Claudeが自分で有無を比較して「掛けない方が良い」と判定したことだった。
（余談だが、この検証の途中でClaudeは一度誤判定している。処理の効果を確かめるのにファイルのハッシュを比べて「両方とも処理された」と結論を出した。実際にはこのソフトは画像ファイルに設定情報を埋め込むので、中身の絵が完全に同一でもハッシュは変わる。画素で比べ直したら、片方は一切変化していなかった。検証手段そのものが間違っている、という失敗だ）
失敗4: 「ひねりがない」
好きなテイストの絵を見せて「こんな感じで」と頼んだ。返ってきたものは、確かにテイストは合っていた。合いすぎていた。参照した絵の構図と被写体をほぼそのままなぞっていた。
「ひねりがない。テイストだけ採用して、デザインはオリジナリティを出して」と言った。
ここでの返しが良かった。まずテイストの定義を言語化して（鮮烈な分光、きらめき、明るい階調、光沢）、それを保ったまま被写体と構図を6案作り直してきた。
そして1巡目を自分で否定した。「6案とも構図は成立したが、全部が青紫のパステルに寄っていて、テイストの核である鮮烈さが死んでいる」と。使ったモデルには放っておくと青系に寄る癖があり、vivid colors（鮮やかな色で）程度の指示では効かない。欲しい色を名指しで列挙し、避けたい色を明示的に禁止して、ようやく狙いどおりになった。
結果の3枚がこれだ。
逆さまに落ちながら絵の具の渦を突き抜ける。斜めの構図で、足が上にある。
人物を真っ黒の抜きにして、色は周囲の渦だけが持つ。人物を描くのをやめて、色と余白の配置の問題にしている。
振り返る後ろ姿で、髪が虹の帯と蝶に分解していく。
元の参照画像は目のクローズアップだった。3枚とも、そこから完全に離れている。
半日でやったこと、かかったもの
- 追加費用はゼロ。使ったモデルは全部無料で公開されているもの
- ディスクは約20GB（モデル3本）
- 生成は1枚21秒。起動に15〜95秒
- 私が書いた英語プロンプト: 0文字
用途によってモデルを3本使い分けている。写実の人物、アニメ絵、それ以外のイラスト。アニメ絵に汎用モデルを使うと、否定形で指示しても6枚中3枚が実写の写真に流れることが分かったので、そこは専用のものを足した。プロンプトで殴るよりモデルを替えるべき問題だった。
道具ではなく、判断が積み上がっている
半日の作業で、Claudeが自分の手順書に書き足した知見はこうなった。
- 速度が要るものをHDDに置かない（空き容量ではなく回転数を見る）
- 8GB環境で常駐設定は逆効果
- 顔が小さい構図では、モデルではなく解像度が問題
- 顔の描き直しは写実専用。フラットな絵には逆効果
- 画像処理の効果検証にファイルハッシュを使わない
- 特定のモデルは色が青に寄る。欲しい色は名指しする
- 参照画像を渡されたとき、なぞるのではなくテイストを言語化してから離れる
これは道具のマニュアルではなく、判断基準の集積だ。しかもほとんどが、私が指示したのではなく、失敗を測って本人が書いたものになっている。
家の道具を作らせるのを続けていて最近思うのは、貯まっていくのはコードではないということだ。「この状況ではこう判断する」という記述が貯まっていく。次に似た場面が来たとき、同じ穴には落ちない。
そういう意味では、今回作ったのは画像生成環境ではなく、画像の良し悪しを判断できるようになった同僚の方だったのかもしれない。
記事内の画像について
掲載した画像はすべて、この記事で書いたローカル環境で生成したものです。使用モデルは Stable Diffusion XL 1.0（OpenRAIL++）、Juggernaut XL v9（CreativeML OpenRAIL-M）、Animagine XL 4.0（OpenRAIL++）で、いずれも生成物の利用に制限のないライセンスです。写っている人物は実在しません。