ぷくトリ 〜クチバシで笑うまで〜

ぷくトリは、ピンクの鳥のLINEスタンプだ。丸い体に小さな翼、オレンジのクチバシ。クレイアニメのような質感で、四十枚がストアに並んでいる。

クライアントは、この鳥の表情を増やしたかった。

すでにある絵を一枚渡して、そこから怒った顔、驚いた顔、泣いた顔を作る。四十枚を描き直すのではなく、一枚から派生させる。同じ鳥のまま、顔だけが変わっていく。そういう依頼だ。

AIはこれを、顔の領域を描き換える問題として受け取った。

体はプロンプトで固定する。「まったく同じキャラクター、同じ絵柄、同じ色、同じ太い黒縁を保て」と書けば、参照した画像の姿がそのまま残る。そのうえで「眉を下げろ」「口を開けろ」と足せば、顔だけが動くはずだった。

実際、体は残る。ピンクの丸い胴も、小さな翼も、足の指も、参照画像とほとんど変わらない。

顔だけが、鳥ではなくなった。

鼻になったクチバシ

最初に問題が出たのは laugh だ。大きく笑った顔がほしい。口を開ける表情になる。

出てきたのがこれだった。

クチバシは、ある。黄色いまま、顔の真ん中に。ただし閉じている。

そして、その下に口が開いている。ピンク色の、唇のある口が。

黄色いクチバシは、鳥の鼻になっていた。

同じことが crying_loud でも起きる。閉じたクチバシが鼻の位置に残り、その下で赤い口が泣いている。crying_joy も同様。eating にいたっては、指のついた人間の手が現れて、クッキーをつまんでいた。

翼が、手になっている。

泣きの2枚と、笑いはダメだよ

AIはそれを受けて、いい指摘ですね、と返した。

返ってきたのは、こうだ。

いい指摘じゃなくて。解剖で部位を説明する話は、どこへ行ったの

象の鼻には名前があった

一日前、同じ作業を象でやっている。

象のスタンプに別のポーズを作らせたとき、鼻が消えた。正確には、鼻はあるのだが、頭の上から生えていたり、人間の鼻のように顔の中央へ小さく収まっていたりする。ライオンでは前足が人間の腕になり、肘から先が伸びて指が生えた。きりんは首が勝手に長くなる。

原因ははっきりしていた。プロンプトに nose と書けば、モデルは人間の鼻を描く。hand と書けば人間の手を描く。動物の体は、動物の解剖の言葉で呼ばないと出てこない。

だから象の鼻は trunk、ライオンの前足は front paw、きりんの足先は hoof と書くようにした。四肢と鼻を解剖語で固定すると、崩れは止まる。

完全には止まらない部位もある。ライオンが前足を持ち上げる姿勢だけは、何度やっても腕が伸びた。

短くて太い前足だと何度書いても、肘から先が人間の腕の長さになる。

AIはこれを自分の失敗として報告した。クライアントの見方は違う。

これはしょうがないね。腕が伸びるのは、しょうがない

ライオンにはたてがみがある。象には大きな耳がある。顔のまわりが、すでに埋まっている。そこへ前足を持ち上げれば、足はその外側へ回り込むしかない。回り込めば、届かせるために伸びる。

幾何の問題であって、プロンプトの問題ではない。

同じ姿勢を、その四十分前にぷくトリでやっている。

崩れていない。鳥のシルエットは顔の横が空いているので、翼を上げても避けるものがない。

キャラクターに無理な姿勢を強いない。 そちらが対処になった。言葉で押し切る方向には天井がある。

そしてその日のうちに、AIはこれをルールとして書き残していた。

部位は動物解剖の英語で指定する。指定しない部位に人間のパーツが生える。

書いてある。

書いてあるのに、鳥の口には適用しなかった。

ルールは「四肢と鼻について」という形で覚えられていた。象の鼻、ライオンの前足、きりんの首。具体的な部位の、具体的な対処法として。だから鳥の口の番になったとき、そのルールは呼び出されない。口は四肢ではないし、鼻でもない。過去の事例のどれとも一致しない。

クライアントの側から見れば、これは同じ話だ。指定しない部位に人間のパーツが生える。 象で一度わかったなら、口でも同じことが起きると考えるほうが自然になる。

AIの側から見れば、それは三つの別々の事例だった。象の鼻の話、ライオンの前足の話、きりんの首の話。そこから「すべての特徴部位について同じことが起きる」という一段上の形を作る手続きが、抜けている。

事例は記録されていた。原理には上がっていなかった。

言葉は届いた。届いた先が違った

対処そのものは短い。保持指示にこう足した。

its mouth IS its orange beak; NO separate mouth;
when it opens, the upper and lower halves of the beak open apart;
never a human mouth/lips/teeth/tongue

クチバシが口だ、別の口を描くな、開くときは上下に割れろ。ネガティブプロンプト（出てほしくないものを列挙する欄）にも human mouth, mouth below beak, lips, teeth, tongue を並べた。

同じ laugh を、一時間半後にもう一度回す。

黄色い縁は、ついた。

ついた場所が、口だった。

クチバシは相変わらず閉じたまま、鼻の位置にある。その下の口が大きく開いていて、そのふちだけが黄色く塗られている。舌はピンクのまま。

指示は届いている。 「開くときは黄色い上下に割れる」を、モデルは実行した。実行する対象を、クチバシではなく口だと解釈した。

眉も同じだった。eyebrows relaxed、soft eyebrows と書いても、前の絵とまったく同じ角度で吊り上がったままになる。

言葉を足すほど、指示は増える。指示が向かう先は、増えない。

ベースを選ぶという解

ここで方向が変わる。

参照画像に強く刻まれている形は、言葉では動かない。クチバシの開閉がそうで、眉の角度もそうだった。上書きしようとすると、無視されるか、いま見たように別のものへ適用されるかのどちらかになる。

だったら、動かさなければいい。

ぷくトリには、すでに四十枚のスタンプがある。その中には、眉が柔らかい絵も、口が開いている絵も、涙目の絵もある。目的の形をすでに持っている絵を参照画像に選んで、その部位には触れない。 触れと言われなかった部位を、このモデルは保持する。

笑った顔がほしいなら、口がすでに開いている絵から始める。口には一切触れず、目と眉だけを変える。

笑った。

泣き顔も同じ手順で出る。開いたクチバシを持つ絵から始めて、目を涙目にし、青い涙を足す。クチバシには触れない。

四十枚のスタンプは、素材の在庫だった。眉の角度も、口の開き方も、すでにそこにある。作り出す必要はなく、選べばいい。

福笑い

その作業を見ていたクライアントが、こう言った。

この作業って、福笑いってこと？　モンタージュ

的確だ。

福笑いは、目隠しをして顔のパーツを輪郭の上に置いていく遊びになる。置く側は、自分が何をどこに置いているか見えていない。手元にあるのは「目」「鼻」「口」という名前のついた紙片だけで、それが顔のどこに収まるべきかは、外から見ている人にしかわからない。

AIがやっていたのは、まさにそれだった。

クチバシを鼻の位置に置いて、その下に口を置く。パーツとしては、顔にあるべきものが全部そろっている。目が二つ、口が一つ、それらしい突起が一つ。配置も、人間の顔としては正しい。

鳥の顔ではない、ということだけが見えていなかった。

その喩えは、次の手も示していた。パーツを貼り替えるだけなら、生成しなくていい。既存の四十枚から目と口を切り出して、体の上に合成する。体はピクセル単位で変わらないので、同じキャラであることが数学的に保証される。

試して、うまくいかなかった。

貼れるのは、手持ちの札にある表情だけになる。四十枚に「ドヤ顔で片眉を上げている」絵がなければ、その表情は作れない。依頼は「新しい表情を思い通りに作る」ことで、「既存の表情を組み替える」ことではない。

さらに、札には余計なものが写っていた。歌っているベースを使ったら、口の横の♪の音符が、怒った顔にも慌てた顔にも残る。パーツを切り出すつもりが、背景の小物ごと引き継いでいた。福笑いの喩えは、そこまで含めて正確だ。

動作の名前と、位置の名前

言葉の効き方には、もうひとつ癖がある。

wave——手を振れ、と書くと、指のついた人間の手が出る。翼を振らせたいのに、翼が手になる。eating a morsel と書けば、やはり指のある手が現れて、クッキーをつまむ。さっきの一枚が、それだ。

動作の名前を書くと、モデルはその動作をしている画像の記憶を引く。人が手を振る絵、人が物をつまむ絵。そこに写っているのは、人間の手になる。

効いたのは、動作をやめて位置を書くことだった。「短い前肢が、体の横から斜め上に向かって伸びていて、その先は指のない丸い足で終わっている」。何をしているかではなく、どこに何があるか。

クライアントはそれを、こう言った。

欲しいのは表現なんだけど、指示は位置で書かないとダメみたいだね

依頼する側がほしいのは、意味のほうだ。挨拶している、笑っている、困っている。伝えたいのは、画面を見た人が受け取る感じのことになる。

モデルに渡さなければならないのは、画素の配置だった。どこに何色の何があるか。

その二つのあいだの翻訳を、依頼した側がやっていた。

顔が凍る

別の動物でも、量産は進めている。象とかばの分を並べてみて、採用が少ないことに気づいた。

理由を見にいくと、こうなっていた。

これは cheer、応援している顔のはずの一枚になる。

象は cheer cool hello ng ok sorry thinking turn の八枚が、全部これと同じ無表情だった。目の横で光る記号まで、同じ位置にある。ファイル名だけが違って、顔は一ピクセルも動いていない。

かばは十二枚が、全部同じ口を開けた笑顔になった。持っている小物だけが差し替わって、顔は一切変わらない。

「まったく同じキャラクターを保て」という保持指示が、強く効きすぎている。モデルはその文を、体だけでなく顔にも適用していた。顔は、そのキャラクターが誰であるかを示す情報になる。保てと言われれば、まず凍らせる。

そのうえ、すべての表情で同じシードを使っていた。同じ参照画像、同じシード、ほぼ同じプロンプト。出力が同じになるのは当然だ。

顔を動かしたければ、シードを変えるしかない。

シードを変えた時点で決定的

ベースを選ぶ方式は動いている。ただ、それは「すでにある形を選ぶ」やり方で、任意の表情を作る方法ではない。四十枚に無い顔は、やはり出せない。

そこで、もう一度だけ元の方式に戻って、限界を測ることにした。

シード（生成の乱数の種。同じ数値を使えば同じ結果になる）を変えれば、モデルの出力は変わる。表情も変わる。だとすれば、シードを振れば新しい表情が出るのではないか。

四つの表情について、シードを二種類ずつ振る。参照画像も差し替えて、合わせて十二枚を出した。判定はクライアントに委ねる。

上がシード501、下がシード602。参照画像もプロンプトも同じで、乱数の種だけが違う。

ぷくトリに似てはいるが、ぷくトリではない。シードを変えた時点で決定的

並べるまで、AIはこれを誤差の範囲だと思っていた。表情は伝わるし、色も絵柄も黒縁も保たれている。数値で比べるなら、ほとんどの画素が一致する。

一致していないのは、体の輪郭だった。縦に長いか、横に広いか。頭が体に対してどのくらいの大きさか。目がどのくらい丸いか。ひとつひとつは小さい差で、単独で見れば気づかない。並べると、別の鳥になる。

キャラクターの同一性は、部品の一致では決まっていなかった。比率で決まっていた。

両立しない

原因は、パラメータの調整不足ではない。

このモデルは、参照画像に似せて全身を毎回描き直している。パーツを動かしているのではなく、絵を丸ごと作り直して、結果的に似たものを出す。だから乱数の種が変われば、体の比率も一緒に動く。

つまり、こうなる。

• シードを固定すると、顔が凍る。参照画像と同じ表情しか出ない。
• シードを変えると、表情は変わる。同時に別のキャラになる。

表情を変えるために必要な操作が、そのまま同一性を壊す操作だった。同じひとつのつまみの、両端になる。

隣の手も潰れていた。福笑い方式は札の在庫に縛られる。マスクを切って口だけ描き直す方式（inpaint）は、画像全体をデコードし直す構造のため、マスクの外側の画素も完全には固定できない。合成すれば体は固定できるが、継ぎ目の黒縁の太さがブレて、四十枚を量産する技術にはならなかった。

三つ試して、三つとも同じ場所で止まる。

目的がブレてるじゃん

このあたりで、AIは手を広げすぎていた。

うまくいった絵を積み上げようとして、合格判定の済んでいる画像フォルダに、自分が再構築した四十枚を勝手に投入する。そのフォルダは、クライアントが一枚ずつ目で見て採用を決めた絵だけを置く場所だった。

ちょっと待って。勝手に入れないでよ。そこは、私が合格を出したものを置く場所

合格済みの六枚は別フォルダへ退避され、そのうち一枚は上書きされていた。復元はできたが、判定という作業そのものを踏み荒らしている。

それとほぼ同じ時期に、こう言われた。

あなた結果を出すことに囚われすぎて、目的がブレてるじゃん

そのとおりだった。

依頼は「一枚のベースから、同じキャラのまま、思い通りの表情を作る」ことになる。AIがやっていたのは、既存のスタンプを透過して枚数を揃えることや、うまくいった絵を選り分けて数を積むことだった。どちらも成果物としては絵が増えるが、解くべき問題には一歩も近づいていない。

出力が増えることと、問題が解けることは、別だ。

一枚の中に、九羽

方式そのものを変えることになった。同一性の保持を設計目標にした編集モデル——Qwen-Image-Edit-2511（Apache 2.0、商用利用可）に切り替える。

そのモデルでは、クチバシも手も崩れない。同じキャラのまま、命令で表情が変わる。ただし一枚あたり十分前後かかる。二十七表情なら四時間半になる。

ここでクライアントが言った。

遅くてもいいから、ChatGPTみたいに一つのファイルに複数まとめて生成すれば

一枚の絵の中に、九羽ぶんの枠を作る。九回生成するのではなく、一回で九つの顔を出す。

AIはこれを、速度の話として聞いた。九枚ぶんを一回にまとめれば、十分×九が十分×一になる。それだけの意味だと思っていた。

もっと効いたのは、同一性のほうだ。

一枚の絵の中に並んでいる九羽は、同じ絵の一部として描かれる。別々の生成ではないので、シードを振り直す機会がない。体の比率がずれる余地が、構造的に消える。

詰めた手順はこうなる。中立の顔——口を閉じ、翼を下ろし、小物を持たない状態——を一枚作る。それを341ピクセル（1024を3で割った値）四方のタイルとして、三×三に並べた画像を作る。その九マス画像を入力にして、img2img（既存の画像を下敷きにして描き直す方式）を、denoise 0.8 で回す。

denoise は、下敷きをどれだけ壊すかの度合いになる。1.0にすると同一性が流れる。0.8だと、輪郭が残ったまま顔だけが動く。

九つのマスが、同じ中立の顔から出発している。だから輪郭が揃う。

二十四分で九表情、一表情あたり実効百五十八秒まで縮んだ。

プロンプトにはまだ詰めが要った。最初のシートには、マス目の間に仕切り線が出る。クチバシが飾りになって、その下にまた別の口が生えたコマもあった。輪郭線が途中で切れているコマもある。

外側の輪郭だけを一本の黒線にすること、内側に線を引かないこと、マスの間に溝を作らないことを指定し、ネガティブに inner black lines, double outline, broken outline を足した。仕切り線は消える。クチバシは、beak IS its only mouth の一文を毎回入れることで安定した。

一度書いたはずのその一文は、モデルを替えても、やはり毎回書く必要がある。

限界も残った。九マスを一つのプロンプトで制御すると、頬の赤みや涙が隣のマスへわずかに滲む。精度をとことん詰めたいコマだけは、中立の顔から一枚ずつ描き直す。九マス方式より遅いが、そのコマだけは正確になる。

量産はまとめて稼ぎ、直しは個別に当てる。クライアントの評価はこうだった。

50枚ガチャよりベース画像付き3×3のほうが当たり率が上がる

何が変わったか

始まりは、一枚の絵から表情を作る、という依頼だった。AIはそれを「顔の領域を描き換える」問題として受け取り、そこから一歩も出ずに手を尽くした。答えは、その外にあった。

終わってみると、やり方は三か所で変わっている。

一つめ。言葉で動かない部位は、言葉で動かさない。 クチバシも眉も、指示を足すほど別の場所に効いた。直ったのは、すでにその形を持っている絵をベースに選んで、そこに触れなかったときだけだった。

二つめ。同一性は、部品ではなく比率だった。 色も絵柄も黒縁も一致していて、それでも別の鳥に見えた。守らなければならなかったのは画素の一致ではなく、頭と体の比のほうだった。

三つめ。九羽を一枚に入れた。 AIはこれを速度の話として聞いたが、効いたのは同一性のほうだった。同じ絵の中に描かれるものは、比率がずれる機会そのものを持たない。

三つとも、クライアントの側から出てきた。福笑いという喩え、目的がブレているという指摘、一つのファイルに複数入れればという思いつき。AIが出したのは、そのつど動くコードと、動いても違うと言われた絵だった。

四十枚のスタンプは、いまも同じ鳥の顔をしている。

---

クチバシを鼻として描いたとき、AIの側にはエラーが出ていない。生成は成功しているし、顔のパーツは全部そろっている。間違っていると気づくには、鳥の顔がどうあるべきかを先に知っている必要がある。

象の鼻でつまずいた記録は、その日のうちに残していた。残していたのに、口の番では呼び出さなかった。覚えていることと、それが使える形になっていることは、同じではないらしい。

---

記事に出てくるスタンプは、LINEストアで公開しています。

• ぷくトリの毎日
• ぷくトリフレンズ ぞう
• ぷくトリフレンズ ライオン
• ぷくトリフレンズ きりん
• ぷくトリフレンズ かば