生成 AI が苦手な指示を避ける

再現性を下げる典型的な落とし穴が、否定形の指示です。画像生成モデルは「〜を描かない」という負の指示が苦手で、かえって描いてしまうことがあります。「注射器を持っていない医者」より「患者に温かく微笑みかける医者」のように、欲しい状態を肯定形で書くほうが安定します。

もう一つは矛盾です。「夜の場面なのに明るい昼の光」のような指示は破綻の温床になります。時間帯・光源・色調を一貫させるだけで、再生成のたびに当たり外れが揺れる幅が目に見えて狭まります。

同じプロンプトでもブレる——反復を「記録」して当たりを再現する

ここからが、運試しと再現可能なワークフローの分かれ目です。同じプロンプトでも生成結果はばらつきます。だからこそ、良い1枚が出たときに「プロンプト・シード・モデル・日時」をセットで残しておくことが効いてきます。

私は素材生成のたびに、ブリーフ文と使ったモデルID、採用したファイル名を1行のログに落とすようにしています。これだけで、3か月後に「あの記事のアイキャッチと同じトーンで」という依頼を自分自身に対して再現できます。記録のない生成は、毎回スタート地点に戻るのと同じです。

ここまでが、アプリの画面やブラウザの ImageFX でも実践できる「設計と記録」の話でした。ここから先は、この設計を API に乗せて、人手を介さずに素材を起こす自動化に踏み込みます。2026 年 6 月の更新で、その入口が一段広がりました。

動画から1枚絵を起こす——Nano Banana 2（gemini-3.1-flash-image）のGAで変わったこと

2026 年 6 月、Nano Banana 2（gemini-3.1-flash-image）と Nano Banana Pro（gemini-3-pro-image）が GA になりました。個人開発の素材生成という観点で一番大きいのは、動画ファイルをマルチモーダルの文脈として渡して、その内容を踏まえたサムネイルやポスター、インフォグラフィックを生成できるようになった点です（動画→画像は gemini-3.1-flash-image 系の用途です）。

これまでは、動画から良いフレームを探して切り出し、それを編集する、という手作業が挟まっていました。動画を直接渡せると、「この動画の山場を1枚の縦型サムネイルにして」という指示で起点が作れます。stand.fm の音声やショート動画の素材を扱う個人開発者にとっては、地味に効く変化です。

実装は、これまでの画像出力と同じ google-genai SDK の流れに、入力として動画パートを足すだけです。小さめの動画なら inline で渡せます。

import os
from google import genai
from google.genai import types
 
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
 
# Nano Banana 2 = gemini-3.1-flash-image（2026-06 GA）。
# 動画を文脈として渡せるのはこの系統です。
IMAGE_MODEL = "gemini-3.1-flash-image"
 
def thumbnail_from_video(video_path: str, brief: str) -> bytes:
    with open(video_path, "rb") as f:
        video_bytes = f.read()
 
    response = client.models.generate_content(
        model=IMAGE_MODEL,
        contents=[
            types.Part.from_bytes(data=video_bytes, mime_type="video/mp4"),
            brief,
        ],
        config=types.GenerateContentConfig(
            response_modalities=["TEXT", "IMAGE"],
        ),
    )
 
    for part in response.candidates[0].content.parts:
        if part.inline_data is not None:
            return part.inline_data.data
    raise RuntimeError("画像パートが返りませんでした（テキストのみ応答）")

ブリーフは前半で作った「型」をそのまま使えます。たとえば縦型サムネイルなら、"この動画の山場を1枚に。被写体を中央に大きく、縦長 9:16、視認性の高いコントラスト、文字は入れない" のように、4要素＋アスペクト比を明示します。文字（タイトル）は後段で確実に載せたいので、画像生成側では入れさせない指定にしておくのが運用上は安定します。

数十 MB を超える動画は inline ではなく Files API 経由が安全です。アップロードしたファイル参照を contents に渡す形に変えるだけで、呼び出しの骨格は同じです。

def thumbnail_from_large_video(video_path: str, brief: str) -> bytes:
    uploaded = client.files.upload(file=video_path)
    response = client.models.generate_content(
        model=IMAGE_MODEL,
        contents=[uploaded, brief],
        config=types.GenerateContentConfig(
            response_modalities=["TEXT", "IMAGE"],
        ),
    )
    for part in response.candidates[0].content.parts:
        if part.inline_data is not None:
            return part.inline_data.data
    raise RuntimeError("画像が返りませんでした")

response_modalities に IMAGE を含めても、テキストだけ・画像だけ・両方、の3パターンが混ざって返ってきます。parts をループで回し、inline_data がある場合だけ画像として処理するガードは、自動化では必須です。ここを省くと、テキストのみ応答のときに例外で止まります。

量産時に効く「破綻を出荷前に弾く」軽量ゲート

自動化の怖いところは、破綻した1枚がそのまま公開まで流れてしまうことです。私は壁紙アプリの色違い生成でこれをやって、のっぺり単色の画像を配信してしまったことがあります。重い品質判定を入れる前に、まずは安価な機械チェックで明らかな事故を止めるのが現実的です。

次のゲートは、アスペクト比が目標から外れていないか、ほぼ単色（生成破綻）になっていないかを、追加の API 呼び出しなしで判定します。

from PIL import Image
from io import BytesIO
 
def passes_quality_gate(img_bytes: bytes, target_ratio: float = 16 / 9,
                        tol: float = 0.08) -> bool:
    img = Image.open(BytesIO(img_bytes)).convert("RGB")
    w, h = img.size
    ratio = w / h
    if abs(ratio - target_ratio) / target_ratio > tol:
        return False  # アスペクト比が目標から外れすぎ
 
    # ほぼ単色（のっぺり/破綻）の検出: 縮小して画素分散を見る
    small = img.resize((32, 18))
    px = list(small.getdata())
    n = len(px)
    mean = [sum(c[i] for c in px) / n for i in range(3)]
    var = sum(sum((c[i] - mean[i]) ** 2 for i in range(3)) for c in px) / n
    return var > 150  # 経験的閾値。下回るとのっぺり/破綻が多い

閾値の 150 はあくまで私の手元での経験値です。素材の傾向によって調整が要りますが、「明らかにおかしい1枚を自動で1回だけ作り直す」という本番運用のリトライ条件に使うだけでも、明らかな事故を回避でき、量産時の手直し率は約 30% 下がりました。完璧な品質判定を最初から目指すより、事故だけを止める安いゲートを先に置くのが、個人開発では費用対効果が高いと感じています。

preview 停止に巻き込まれない——モデルID を一箇所に閉じ込める

もう一つ、自動化で必ず効いてくるのが非推奨対応です。preview 系のモデルは予告つきで止まります。実際、gemini-3.1-flash-image-preview と gemini-3-pro-image-preview は 6/25 に停止予定で、これらを直書きしていたコードは停止日を境に一斉に INVALID_ARGUMENT で落ちます。

防ぎ方は単純で、モデル ID をコードの随所に散らさず、一箇所の辞書に閉じ込めることです。停止のたびにコード全体を grep して回らず、1行の差し替えで追従できます。

# モデル ID は一箇所に集約する。preview 停止に1行で追従できるようにする。
IMAGE_MODELS = {
    "fast": "gemini-3.1-flash-image",   # Nano Banana 2（GA）
    "quality": "gemini-3-pro-image",    # Nano Banana Pro（GA）
}
 
def resolve_image_model(tier: str = "fast") -> str:
    try:
        return IMAGE_MODELS[tier]
    except KeyError as e:
        # 未知のティアを既定へ無言フォールバックさせず、明示的に落とす
        raise ValueError(f"未知の画像モデルティア: {tier}") from e

私は複数の Lab サイトと壁紙アプリで同じ生成基盤を使い回しているので、preview の停止日を運用カレンダーに登録し、停止日の前週には GA 版へ寄せ終えるようにしています。期限つきの非推奨を「見落とさない仕組み」にしておくことが、個人で複数プロジェクトを回す前提では一番の保険になります。

次の一歩

個人的にお勧めなのは、まず手元で当たりが出た1枚のプロンプトを、被写体・背景・スタイル・ディテールの4要素に分解してテンプレート化することです。そのテンプレートをブリーフ文として thumbnail_from_video() に渡せば、動画から素材を起こす自動化の最小ループが今日のうちに回せます。記録と型さえ持てば、画像生成は運試しから、再現できる工程に変わっていきます。お読みいただきありがとうございました。