静止画か短い動画か — Nano Banana 2 Lite と Omni Flash のコスト桁差で機能の置き所を決める

動く意思決定関数に落とし込む

「たぶんこれくらい」で本番を回すのが、いちばん危ういところです。上の3項目を式にして、アセットの条件を渡すと推奨メディアと月額見込みを返す関数にしました。私が実際に手元で使っている最小版を、そのまま載せます。

type MediumInput = {
  monthlyAssets: number;   // 月に配信する新規アセット数
  videoSeconds: number;    // 動画にする場合の1本の秒数
  yieldRatio: number;      // 歩留まり(採用/生成)。0.33 = 3枚に1枚採用
  editPasses: number;      // 動画の会話編集の平均やり直し回数
  avgDownloads: number;    // 1アセットあたりの想定DL数
  cdnPerGB: number;        // CDN転送単価(USD/GB)
};
 
const IMAGE_PER_UNIT = 0.034 / 1000; // $/枚
const VIDEO_PER_SEC = 0.10;          // $/秒
const IMAGE_MB = 0.05;               // 静止画の想定サイズ
const VIDEO_MB_PER_SEC = 0.6;        // 動画の想定サイズ/秒
 
function estimate(input: MediumInput) {
  const { monthlyAssets, videoSeconds, yieldRatio, editPasses,
          avgDownloads, cdnPerGB } = input;
 
  // 生成費(歩留まりで割り戻す)。動画は編集やり直し回数も秒課金
  const genImage = (IMAGE_PER_UNIT / yieldRatio) * monthlyAssets;
  const videoUnit = VIDEO_PER_SEC * videoSeconds * (1 + editPasses);
  const genVideo = (videoUnit / yieldRatio) * monthlyAssets;
 
  // 配信費(サイズ × DL数 × 転送単価)
  const gbImage = (IMAGE_MB * avgDownloads * monthlyAssets) / 1024;
  const gbVideo = (VIDEO_MB_PER_SEC * videoSeconds * avgDownloads * monthlyAssets) / 1024;
  const cdnImage = gbImage * cdnPerGB;
  const cdnVideo = gbVideo * cdnPerGB;
 
  const image = genImage + cdnImage;
  const video = genVideo + cdnVideo;
 
  return {
    imageMonthlyUSD: Number(image.toFixed(2)),
    videoMonthlyUSD: Number(video.toFixed(2)),
    ratio: Number((video / image).toFixed(1)),
    recommend: video > image * 20 ? "image" : "video-ok",
  };
}

この関数の肝は、生成費と配信費を足してから比べる点です。生成だけを見ると静止画が圧勝ですが、配信を足すと差は縮みます。逆に言えば、DL数が伸びていないうちは動画の配信費もまだ小さく、目玉アセットに動画を1本だけ置く程度なら現実的だと分かります。recommend の閾値（ここでは20倍）は、その機能に許せるコスト差の許容度で決める設計値です。数字を式で持つと、この閾値を「感覚」ではなく「方針」として議論できるようになりました。

私がこの基準で実際に線を引いた場所

壁紙アプリで数百枚単位の背景を作る一次生成は、迷いなく Nano Banana 2 Lite に寄せています。捨てる前提で大量に回す工程に、動画の単価は絶対に乗せられません。ここは静止画の独壇場です。

一方で、アプリのトップに1枚だけ置く「今日の一枚」のような枠には、5秒だけ静かに動くループを検討する価値があると考えました。ここは月に30本程度、しかも編集を重ねて品質を追い込む枠です。関数に月30本・8秒・編集2回・DL控えめの値を入れると、動画の月額は静止画の数百倍にはならず、目玉としての体験向上に見合う範囲に収まりました。全面に配ると破綻するが、一点豪華主義なら成立する。この線引きが、私が数字から得た結論でした。

課金導線とも素直につながります。動画アセットのように1本あたりの原価がはっきり高いものは、AdMob の報酬型広告を見てもらった後や、プレミアム会員向けに絞るのが理にかなっています。個人開発でアプリの収益化を続けてきた実感として、この場合は原価と提供条件を一致させておくことを強く推奨します。原価が桁で違うものを無料で全員に配ると、ダウンロードが伸びるほど赤字が深くなるためです。原価の構造をそのまま提供条件に反映させる、という発想に切り替わりました。

会話編集の作り直しコストを見積もりに織り込む

Omni Flash の特徴は、登場人物の差し替えやシーンのリライティング、アングルの変更を自然文で指示できる会話編集です。元の音声と映像のトラックがネイティブに保持されるのも、動画を作り直すうえでは大きな利点です（ここはドキュメント上の仕様として押さえておき、実際の効き方はご自身のアセットで確かめるのが確実です）。

ただ、意思決定の観点では、この編集のしやすさが同時にコストのリスクにもなります。会話編集の1回ごとに、また秒数ぶんの課金が発生するからです。5秒動画を「もう少し暗く」「アングルを少し上に」と3回直せば、その1本の実効コストは $0.50 が $2.00 に膨らみます。上の関数で editPasses を独立した変数にしたのは、この「直すほど高くなる」性質を見積もりから隠さないためでした。静止画なら作り直しは同じ単価の再生成ですが、動画は作り込むほど単価が積み上がる。この非対称性を知らずに「動画のほうが調整しやすいから」と選ぶと、月末に足をすくわれます。

私自身、最初は編集のしやすさを純粋な利点として捉えていました。式に editPasses を入れて初めて、それが利点と同時に費用の増幅器でもあると腹落ちしました。触ってみて、数字にして、ようやく設計判断として扱えるようになった、という順番でした。

まず自分の機能でこの式を1本埋めてみる

もし今、静止画にするか動画にするかで迷っている機能があるなら、上の関数に自分の運用値を入れて、月額の2つの数字を並べてみてください。月に何アセット配るのか、歩留まりは何割か、DL数はどれくらいか。この3つを埋めるだけで、迷いの多くは「好み」ではなく「桁」の問題だったと見えてきます。

コスト設計は地味な作業ですが、桁で間違えると個人開発は続きません。私自身まだ運用しながら数字を更新している途中ですが、同じように機能の置き所で迷っている方の判断材料になれば嬉しいです。お読みいただきありがとうございました。