画像生成APIを自前にすべき場面｜Replicate / fal / OpenAIの使い分け

プロトタイプ段階ではゲートウェイ任せでOKですが、ユーザーが日常的に画像生成するアプリでは自前APIへの切り替えが定石です。

用途別おすすめ#

• 汎用・最速: fal.ai (FLUX等が低レイテンシ)
• モデル選択肢の多さ: Replicate
• テキストとの統合: OpenAI gpt-image

実装パターン#

「リクエスト → ジョブID → ポーリング/Webhookで完成 → ストレージに保存 → URLを返す」の非同期フローが基本。UIはスケルトン+プログレスで体感速度を担保します。

実例ケーススタディ：月画像生成費を1/3に#

ECで商品画像のバリエーション生成（季節背景の差し替え）を月1万枚行うサービスの最適化例。

• 下書き：fal.ai のFLUX schnell（最安・高速）で大量生成
• 本採用候補：Replicate FLUX dev で品質確認
• 最終仕上げ：自前OpenAI gpt-image-1（高単価だが破綻が少ない）
• 切替：Lovable AI Gatewayの画像モデルとも比較し、用途別ルーティング
• 結果：月18万円→月6万円（用途別ルーティング＋小モデルキャッシュ）

つまずきポイント集#

• 症状：プロンプトが各サービスで効きが違う → 対処：プロバイダー別にプロンプトテンプレを持つ。共通インターフェースに変換層を1枚
• 症状：APIキーがクライアントに漏れる → 対処：必ずserver function経由。VITE_は禁止
• 症状：生成に時間がかかってUIが固まる → 対処：非同期＋polling、または画像URLをWebSocket/SSEで通知
• 症状：日本語プロンプトの精度が低い → 対処：英語に翻訳してから投げ、UIには日本語を残す

よくある質問（検索意図別）#

[実装手順] Q. 生成画像をStorageに保存するまでの流れは？

①Edge FunctionでAPIに生成リクエスト→②返ったバイナリ/URLを取得→③supabase.storage.from('images').upload() で保存→④getPublicUrl()の結果をDBに記録。10秒超になりそうならInngest等で非同期化を。

[トラブル解決] Q. 生成が途中で失敗・タイムアウトする

Edge Functionの実行上限超過が9割の原因。①非同期キュー（Inngest/QStash）に逃がす ②小さいモデルで再試行 ③プロンプトを短縮、の順で潰せばほぼ解決します。