壁紙アプリの目玉に置くアセットを、静止画のままにするか、3〜5秒だけ静かに動くループにするか。ここで一度、手が止まりました。動くほうが目を引くのは分かっています。ですが、動かした瞬間に何が変わるのかを、私は感覚でしか掴めていませんでした。
決め手になったのは好みではなく、単価の桁でした。2026年7月に出そろった Nano Banana 2 Lite と Gemini Omni Flash の料金を並べてみて、初めて「これは同じ土俵で比べてはいけない数字だ」と分かりました。画像は1,000枚で $0.034、動画は出力1秒あたり $0.10。同じ「安い」という言葉でくくられていても、1アセットあたりに直すと桁が三つも四つも違うのです。その桁差を数字で掴み、機能ごとにどちらへ寄せるかを決める。ここではそのための型を残しておきます。
二つの単価を「配信1アセットあたり」に正規化する
料金ページの数字は、単位がそろっていません。片方は1,000枚あたり、もう片方は1秒あたりです。このまま眺めても直感は働かないので、まず「利用者に届く1アセットあたり、いくらか」に揃えます。
モデル 公称単価 1アセットに直すと 前提
Nano Banana 2 Lite $0.034 / 1,000枚 $0.000034 / 枚 静止画1枚 Gemini Omni Flash $0.10 / 秒 $0.50 / 本 5秒の動画1本
同じ「1アセット」に揃えると、静止画1枚に対して5秒の動画1本は約14,700倍の単価です。これは端数の話ではありません。静止画なら100万枚生成しても $34 で収まる一方、5秒動画を100万本作れば $500,000 に届きます。個人開発の財布では、動画は「全アセットに配る」ものではなく「ごく一部に置く」ものだと、この一行で決まりました。
正規化するときに大事なのは、動画の秒数を実際の運用値で置くことです。私は当初、頭の中で「動画=数秒」と曖昧に扱っていました。ですが5秒と8秒では、そのまま6割コストが変わります。秒数は仕様ではなく設計変数として持つべきでした。
単価だけで決めると、月末に足をすくわれる
公称単価は生成の一回分にすぎません。本番運用では、その手前と後ろにコストがぶら下がります。ここを見落とすのが、コスト設計で最初にはまる落とし穴でした。私が請求書で痛い目を見て式に組み込んだのは、次の3項目でした。
一つ目は再生成率 です。狙った構図や色が一発で決まることはほとんどありません。壁紙用の画像だと、100枚採用するために実際には300〜400枚を生成して、破綻したものをふるい落としていました。歩留まりが3分の1なら、実効単価は公称の3倍です。動画はこれがさらに重くのしかかります。後述しますが、会話編集の作り直しが1回ごとに秒数ぶんの課金になるためです。
二つ目は審査・モデレーション です。生成物をそのまま利用者に配るなら、不適切なものを弾く工程が要ります。人手なら時間、機械なら別のAPI料金が乗ります。静止画1枚の審査コストは生成単価より高くつくことすらあり、そうなると「生成が安い」利点は審査で相殺されます。
三つ目は配信帯域とストレージ です。ここが静止画と動画で決定的に違いました。数十KBの画像と、数MBになりうる5秒動画では、CDN の転送量が二桁変わります。ダウンロード数の多いアプリでは、生成費よりも毎月の配信費のほうが効いてくる場面があります。生成の桁差に配信の桁差が重なると、動画は「作る」段階ではなく「配る」段階でコストが膨らむのだと気づきました。
動く意思決定関数に落とし込む
「たぶんこれくらい」で本番を回すのが、いちばん危ういところです。上の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つを埋めるだけで、迷いの多くは「好み」ではなく「桁」の問題だったと見えてきます。
コスト設計は地味な作業ですが、桁で間違えると個人開発は続きません。私自身まだ運用しながら数字を更新している途中ですが、同じように機能の置き所で迷っている方の判断材料になれば嬉しいです。お読みいただきありがとうございました。