この記事は生成AI Advent Calendar 2025の7日目の記事です。
はじめに
Image2Imageを禁止する画像生成AI
よく目の敵にされがちなImage2Image機能ですが、「クリーンな画像生成モデル」を謳うMitsua Likesなどはこの機能を技術的に使いづらくするという工夫を施しています。
具体的には、Latent Diffusion Modelに対して入力画像からlatentに変換するモジュールであるVAE Encoderを公開しないことで、初期ノイズからのText2Image生成のみを強制するという手法です。
（元論文：https://arxiv.org/abs/2112.10752 ちなみにMitsua LikesのアーキテクチャはSDXLベースです）
こうすることで、Mitsua Likesの生成した画像は常に
- プロンプトのみを基に全くランダムなlatentからデノイズしたもの
- ＝ Mitsua Likesの学習データセットのみを再現する確率分布からのサンプル
- ＝ クリーン
という建付けになります。
latentを保持するというアイディア
ではMitsuaではt2iのガチャを回す以外やることが無いのかというと、実はそんなことはありません。なぜならMitsuaで生成したlatentは再利用できるためです。
すると以下の図のように、「Mitsuaが表現可能な画像空間」の中であればi2iやその他latent空間における操作が自由に行えます。この記事では、こういった「リミックス」を行うための仕組みや、単純なi2i以外にどんなことができそうかについて考えてみます。
latentを生成画像に埋め込む
まず生成結果のlatentをどのように共有するかですが、生成画像と別で公開するよりは画像のメタデータに埋め込んだ方が取り回しが良いでしょう。対象がPNGであれば以下のようにlatentやプロンプト・乱数シードをテキストベースで埋め込むことができます。
ただ、最近C2PAがアツいことを考えると、オレオレフォーマットで埋め込むよりもなにかしらの作法に沿って埋め込んだ方が良いかもしれません。
from base64 import b64encode, b64decode
from PIL import Image
from PIL.PngImagePlugin import PngInfo
import torch
import safetensors.torch
import json
def save_image_with_metadata(image: Image.Image, path: str, latent: torch.Tensor, generation_config: dict):
tensordata = safetensors.torch.save({"latent": latent})
metadata = PngInfo()
metadata.add_text(
"latent_tensor",
b"data:application/octet-stream;base64," + b64encode(tensordata),
zip=True
)
metadata.add_text(
"generation_config",
json.dumps(generation_config)
)
image.save(path, pnginfo=metadata)
例えばこちらの画像は解像度640x640のPNGでファイルサイズは931KiBですが、そのうちの約100KiBをメタデータが占めています。つまりだいたい12%くらいのサイズ増加でlatentや生成時のプロンプトなどを埋め込めます。
ただし、これをSNSで共有する際はメタデータが消えてしまわないか注意が必要です。現在(2025年)は例えばXでは投稿時にメタデータが削除されます。プラットフォームがどのメタデータを残すか判断しやすくするという意味でもC2PAのフォーマットに相乗りした方がいいかもしれません。
i2i, inpaint, image edit
このようにして公開されたlatent付き画像を取り込んで、i2iやinpaintなどを行うことができます。
実装については画像からlatentへの変換をスキップする以外は基本的なi2i,inpaintと同等です。diffusersのi2i pipelineではlatentを直接入力するケースにも対応しています。
また、DDIM Inversionを用いてノイズからlatentへのデノイズ過程を復元し、その過程をいじることで、元画像の構造を維持したままほかの情報を注入することができます。
活用例としてPlug-and-Play Diffusionは追加学習を行わずにプロンプトで指示した画像編集が可能です。
また、StyleIDという手法を使えば、二つのlatent付き画像間のstyle transferもできそうです。
著作者であることの証明（多分可能？）
これはまだ具体的なアルゴリズムを思いついていませんが、もしかしたらうまくメタデータを埋め込むことでその画像の作成者が自分であることを証明できるのではないかと思っています。
ここで電子署名を思い浮かべた人もいるかもしれませんが、電子署名は中身を取り出して自分の署名で上書きできてしまいます。つまり電子署名はあくまで「私はこの中身を確認しました」と言うためのものであり、言うだけなら誰でもできてしまうためコピー品の対策にはなりません。
その他の方法として、作成者を主張する者が複数現れたら先に主張していた者を真とみなすというものがあります。これを実現するためには主張とその時の時刻を改ざん不可能な形で保存する必要があるので、信頼できる管理者によるプラットフォーム（実際これはXでも魚拓でもなんでも良いですが）やブロックチェーンを使うことになります。
しかしながらインターネットに放流するタイプの画像生成モデルに「作成したらこの台帳に記録しておいてね」という仕組みを組み込むのは骨が折れそうです。
そこで、「latentが無ければその画像を再現できない」という特徴を活かしてうまいことできないか考えてみます。考慮すべき性質は
- 作成者のみが知っている何らかの情報Pがある
- 生成画像は公開される
- latentも公開されるほうが望ましい
- Pがなければ画像またはlatentを再現できない
- 公開情報をもとに作成者情報を検証できる
になりそうです。特に4が電子署名にはできないことです。
こう考えると、Pはlatentを生成するためのgeneration config、つまりプロンプトや乱数シードになりそうです。プロンプトも公開されると嬉しいだろうと考えるとシードの一択でしょうか。（float計算の再現性が怪しいのは一旦おいておきます。まあシードとプロンプトが同じなら大体同じ画像が出てくるでしょう...多分）
そこでシードまわりの話に限定することで満たすべき性質を単純化してみます。
a. 秘密情報Pは作成者のみが知っている
b. 関数FによってPから乱数シードF(P)を算出し、Fは入力Pを逆算できない
c. F(P)はlatentの初期ノイズの作成など、普通の乱数シードとして使用する
d. F(P)は公開情報である（これとプロンプトから元の画像を生成できる）
e. 公開情報をもとに作成者がPを持っていることを検証できる
このような関数Fは存在するでしょうか？なんだかゼロ知識証明っぽい話になってきました。ですが私はゼロ知識証明に詳しくないのでここでギブアップします。
（また、この手法は作者のなりすましは防げますが作者情報を消すことは可能です。まあ後から作者が名乗り上げることもできます）
ちなみにここまでの話は乱数シードが必要不可欠な処理すべてに適用可能です。さらにMitsua Likesのような閉じた環境の場合、最終成果物ができるまでの完全なワークフローをすべて保存すればあらゆる元データの来歴を保持することが可能です。
まとめ
Image2Imageを禁止した画像生成モデルを公開する方法としてVAE Encoderを秘匿するというものがあり、またそのような条件下で何か面白いことができそうかについて考察しました。
その結果、既に生成できている画像のi2iやimage edit, style transferが可能で、著作者証明も多分可能かもということが分かりました。