ComfyUI断念→Imagen 4無料枠で画像生成コスト0円

テクノロジー

ComfyUI断念→Imagen 4無料枠で画像生成コスト0円

ブログ記事のアイキャッチ画像を自動生成する仕組みを、できるだけ安価に運用したい。1記事あたり12枚（アイキャッチとセクション画像、それぞれ候補3枚）を生成するため、API課金となると費用がかさみます。

そんな思いに突き動かされ、M1 Pro 32GBのMacBook ProでFLUX.1 schnellからSD 3.5 medium、SDXLまで、ComfyUI経由で一通り試しました。

結論から先に述べます（本題に入る前に、私自身の誤認識に対する訂正が必要なので）：

  • ローカル生成はM1 Pro 32GBでは力不足でした。画質を優先すると1記事あたり35分を要し、速度を優先すると画質が破綻します。
  • 一度は諦めて「Gemini Nano Bananaの無料枠が救いになるだろう」と考えクラウドに回帰しましたが、これは私の大きな勘違いでした。Nano Banana（gemini-2.5-flash-image）の無料枠は実際には0枚/日であり、有料プランでしか動作しません。
  • 真の無料枠は、Imagen 4 Fast / Generate / Ultraの3モデルをローテーションすることで、合計75枚/日（各モデル25 RPD）です。
  • 現在はGeminiImageProviderにモデルチェーンを実装し、1つのモデルがRESOURCE_EXHAUSTEDで制限に達したら自動で次のモデルに切り替える形で運用しています。

以下、試した順に具体的な数値を示しつつ、途中で誤認識に気づいた経緯まで含めて詳しく解説していきます。

出発点：Gemini Imagen 4 Fast、予想以上に課金されていた

もともと記事生成フローにはGoogleのImagen 4 Fastを使用していました。設定ではimagen-4.0-fast-generate-001を利用。

1枚あたり $0.02（約 3 円）
1 記事 12 枚生成 = 約 36 円
月 100 記事書けば 3,600 円

月額3,600円程度なら許容範囲だと考え、しばらく運用を続けていました。しかし、ある日の課金額を見て驚きます。記事単位で見ると月額が見えにくいのですが、月次CAP（AI Studioで設定できる支出上限）に2度ほど達し、画像生成が停止していました。

この出来事をきっかけに、「ローカル環境で完結できるなら、そうしたい」と考えるようになります。Mac mini M1 8GBは常時稼働していますがSDXLの実行には厳しいため、手元のMacBook Pro M1 Pro 32GBを使用することを前提に検証を開始しました。

ComfyUI インストール直後の罠：チェックポイントがNSFW特化だった

機械学習ワークフローとモデル選択プロセス

AIモデルのチェックポイント選択と最適なパラメータ構成

ComfyUI.app（デスクトップ版）を起動し、最初に入っていた23個のチェックポイントの中からデフォルトらしきhassakuXLIllustrious_v21fix.safetensorsをそのまま使用しました。

しかし、生成してみると…出てくる画像はすべてNSFW（Not Safe For Work）寄りのものでした。ブログのアイキャッチに使えるレベルではありません。

IllustriousやPony系のアニメモデルはNSFWデータで強くファインチューニングされているため、弱いネガティブプロンプト（blurry, low quality, watermark, text, logo）だけではその影響を打ち消すことができません。

教訓 1：チェックポイント選びは用途を決めてから

ブログのテック記事用途であれば、Illustrious/Pony系は完全に避けるべきです。以下のいずれかを選ぶのが賢明でしょう。

  • バニラ: sd_xl_base_1.0.safetensors（中立的でリスクが最小）
  • セミリアル: perfectdeliberate_v30.safetensors（汎用的でSFW向き）
  • 写真系: xxmix9realisticsdxl_v10.safetensors（人物描写に強いが、用途は限定的）

そしてネガティブプロンプトにはSFWを強制するワードを追加します：

blurry, low quality, watermark, text, logo,
nsfw, nude, naked, sexual, explicit, suggestive,
revealing, underwear, lingerie, cleavage

FLUX.1 schnell に期待を込めて 17GB ダウンロード

SDXLでもベースモデルは素の状態で画質が低い傾向にあります。Black Forest LabsのFLUX.1がSDXL世代よりも一段上だと聞き、試してみることにしました。

schnellはApache 2.0ライセンスなので商用利用が可能です。ComfyUI公式が配布しているオールインワンのfp8版をダウンロードします：

cd ~/Documents/ComfyUI/models/checkpoints
curl -L -O https://huggingface.co/Comfy-Org/flux1-schnell/resolve/main/flux1-schnell-fp8.safetensors

ファイルサイズは17GB。回線速度にもよりますが、ダウンロードには10〜20分を要しました。

立ちはだかる壁：MPS fp16 アップキャストと swap 地獄

生成を開始した瞬間、Activity Monitorがオレンジ色に染まりました。

  • python3.12（ComfyUI）: 17.57 GB
  • 使用済みメモリ: 27.11 GB / 32 GB
  • swap: 7.09 GB
  • 圧縮メモリ: 7.59 GB
  • メモリプレッシャー: オレンジ（警告）

fp8は名前に反して、MPSバックエンドではfp16にアップキャストされて計算されます。結果として、実メモリを20GB近く消費することに。M1 Pro 32GBでは他のアプリケーションの分を差し引くと、常にswap領域との間でデータの出し入れが発生する状態でした。

1枚の画像生成に203秒。swapによるI/O待ちの時間が多くを占めていました。

GGUF 量子化で逃げる：UNET Q5_K_S + T5 GGUF

fp8がMacで重い問題は、GGUF量子化モデルとComfyUI-GGUFカスタムノードで回避できます。llama.cppが対応している量子化形式で、ComfyUIでもcity96氏が移植してくれています。

git clone --depth 1 https://github.com/city96/ComfyUI-GGUF.git \
  ~/Documents/ComfyUI/custom_nodes/ComfyUI-GGUF

~/Documents/ComfyUI/.venv/bin/python -m pip install --upgrade \
  gguf sentencepiece protobuf

# モデル（合計 ~12GB）
# UNET: 8GB
curl -L https://huggingface.co/city96/FLUX.1-schnell-gguf/resolve/main/flux1-schnell-Q5_K_S.gguf \
  -o ~/Documents/ComfyUI/models/unet/flux1-schnell-Q5_K_S.gguf

# CLIP L: 246MB
curl -L https://huggingface.co/comfyanonymous/flux_text_encoders/resolve/main/clip_l.safetensors \
  -o ~/Documents/ComfyUI/models/text_encoders/clip_l.safetensors

# T5 Q5_K_M: 3GB
curl -L https://huggingface.co/city96/t5-v1_1-xxl-encoder-gguf/resolve/main/t5-v1_1-xxl-encoder-Q5_K_M.gguf \
  -o ~/Documents/ComfyUI/models/text_encoders/t5-v1_1-xxl-encoder-Q5_K_M.gguf

# VAE: 335MB
curl -L https://huggingface.co/camenduru/FLUX.1-dev/resolve/main/ae.safetensors \
  -o ~/Documents/ComfyUI/models/vae/ae.safetensors

black-forest-labs/FLUX.1-schnellリポジトリはgated（Hugging Faceログインが必要）なので、VAE（ae.safetensors）だけはcamenduru氏の非公式ミラーから取得しました。FLUX schnell/devのVAEは同一です。

T5もGGUF量子化版（Q5_K_M、3GB）を使用することで、さらに2〜3GBのメモリを節約できます。

ComfyUI のワークフロー（FLUX GGUF）

UnetLoaderGGUF (UNET Q5)
       ↓
DualCLIPLoaderGGUF (T5 Q5 + CLIP L) → CLIPTextEncode (positive/negative)
                                                        ↓
EmptyLatentImage → KSampler (euler, simple, cfg=1, steps=4) → VAEDecode → SaveImage
                       ↑                                          ↑
                       └── model ───┘                        VAELoader (ae.safetensors)

schnellは蒸留モデルであるため、CFGは不要（cfg=1固定）・4ステップで十分です。

結果：メモリ改善、速度はほぼ変わらず

UNET Q5 + T5 fp8からT5 GGUF Q5_K_Mに切り替えた後：

  • python3.12: 13.07 GB（fp8比で-4.5GB）
  • 圧縮: 2.73 GB（-4.9GB）
  • swap: 7.23 GB（履歴であり、実質未使用）
  • メモリプレッシャー: 緑（健全）
  • 生成時間: 173 秒/枚（fp8時代の203秒から約15%改善）

メモリは大幅に改善されましたが、生成時間は大きく変わりませんでした。M1 ProのGPUでFLUXを動かす場合、重みが圧縮されていても計算はfp16で行われるため、ボトルネックは量子化ではなく純粋なGPU演算能力にあると判断できます。

1枚173秒 × 12枚 = 約35分/記事。これは自動パイプラインの実用域にはほど遠い時間です。

ここでの罠：候補画像が 1 枚しか保存されない

複数の非同期タスクをキューで管理・監視するシステムの図解

3候補生成しているはずなのに、データベースには1枚しか残らないという問題が発生しました。ログを追うと：

  • 20:40:36 candidate 1 キュー投入 → サーバー側で180秒タイムアウト
  • 20:43:40 candidate 2 キュー投入 → 同様にタイムアウト
  • 20:46:43 candidate 3 キュー投入 → 178秒で間に合い保存成功

ComfyUI側ではすべて197秒〜173秒で生成自体は完了しているにもかかわらず、サーバーのポーリング上限が180秒だったため、最初の2枚は「孤児」となってしまっていたのです。

修正：ポーリングタイムアウトを延長

// packages/server/src/services/image/comfyui-provider.ts

/**
 * ポーリング設定。
 *
 * Why: 1プロンプトあたり複数候補をsequentialに投入するケースで、
 * ComfyUIのキュー待ち + 生成時間の合計が3分を超えることがある
 * （特にFLUX系）。保険として10分まで待つ。
 */
const POLL_INTERVAL_MS = 2000;
const MAX_POLL_ATTEMPTS = 300; // 最大10分待機

SD 3.5 medium は思ったほど軽くない

AI モデルのパフォーマンスベンチマーク比較

FLUXの35分/記事はあまりにも重すぎるため、サイズの小さいSD 3.5 medium（11.6GB）に期待を寄せました。Comfy-Orgのsd3.5_medium_incl_clips_t5xxlfp8scaled.safetensorsをダウンロードして試します。

結果：1枚328秒。FLUXよりも1.5倍も遅いという結果になりました。

理由はシンプルで、SD 3.5は推奨ステップ数が30です。FLUX schnellの4ステップに対して7.5倍ものステップ数を要するため、モデル自体が小さくてもステップ数で処理時間が伸びてしまうのです。

画質もFLUXより一段劣ります。このモデルを選ぶ理由は見当たりませんでした。

SDXL base 1.0 は速度はマシだが画質が素

次にSDXL baseを試しました。1枚あたりの生成時間は98〜107秒。

  • FLUXの約半分の時間
  • 12枚生成で約20分/記事
  • しかし画質は「base」そのもので、ファインチューニングなしでは実用には厳しいレベル

SDXLのファインチューニングモデルであるperfectdeliberate_v30も試しましたが、速度はほぼ同じ（100秒前後）で、画質はbaseよりは改善されるものの、FLUXの領域には遠く及びませんでした。

ここで一度立ち止まる：ローカル生成の限界

これまでの検証結果をまとめます。

構成 1枚あたりの生成時間 12枚（3候補×4スロット）あたりの生成時間 画質
FLUX fp8 all-in-one 203秒 40分 ◎
FLUX Q5_K_S GGUF 173秒 35分 ◎
SD 3.5 medium 328秒 65分 〇
SDXL base 1.0 100秒 20分 ×
perfectdeliberate_v30 100秒 20分 〇

※上記はM1 Pro 32GB、macOS 14.x、ComfyUI 0.x.x での計測結果です。環境依存が大きいため、他のGPU/CPUでの実行時間は大きく異なります。

どの構成を選んでもトレードオフから逃れられないのが、M1 Pro 32GBでの現実でした。

1記事に20〜40分もの時間を使うのは、自動パイプラインの規模では致命的です。MacBook Proを画像生成に占有される時間で別の仕事ができた方が効率的。この時点でローカル生成からの撤退を決断しました。

クラウドに戻る ── ここで大きな勘違いをする

古いAPI仕様に基づいた判断ミス

古い情報に基づいた判断の誤り

当初、Nano Bananaが無料で500枚/日使えると思い込み、実装に切り替えました。しかし、DBのAPIキーの不整合とエラーログの隠蔽という2つのバグ、そしてNano Bananaが実際には有料モデルだったという誤解により、期待通りに機能していませんでした。以下に、この経緯と修正の詳細を記します。

ローカル生成からの撤退が決まり、クラウドAPIを見直すフェーズに入りました。このとき私の頭にあったのは「Gemini 2.5 Flash Image（Nano Banana）は無料枠で500枚/日使えると聞いた気がするな」という曖昧な記憶でした。

当時参照していた複数のテックブログやSNSの言論は、後に判明したことですが、Nano Bananaのpreview時代（例えば2025年X月頃）の情報であり、一般提供開始後のレート制限とは異なっていました。私はそれらの情報を見て、「うん、Nano Bananaは無料枠が手厚い」と自分を納得させました。そしてimage.gemini_image_modelをgemini-2.5-flash-imageに切り替え、「これで$0運用だ」と思い込んで数時間、別の作業に戻りました。

これが半日を費やす判断ミスの始まりでした。

切替ハマりポイント：「エラー無しで画像が変わらない」

設定をNano Bananaに変更して記事の画像を再生成。エラーが出ないのに画像が切り替わらないという現象が発生しました。ローディングは完了するものの、候補画像は古いままです。

原因は2つのバグが重なっていたことでした（Nano Bananaの無料枠問題に気づくよりも前に）：

バグ 1：DB の API キーが古いまま

const apiKey = imageConfig.geminiApiKey || config.geminiApiKey;

DBに暗号化保存されたimage.gemini_api_keyが古い状態のまま残っており、.envの現行キーにフォールバックしていませんでした。

バグ 2：エラーが debug レベルに握り潰されていた

} catch (error) {
  this.logger.debug(
    { error: ..., index: i },
    "画像候補の取得に失敗（スキップ）",
  );
}

本番ログはwarn以上しか出力していないため、API key not validという重要なエラーが完全にサイレントになっていました。UIには成功扱い（0件取得）で返されていたのです。

対処

  1. 古いキーを削除（.envフォールバックに戻す）: 
    DELETE FROM settings WHERE key = 'image.gemini_api_key';
  2. エラーログをdebug → warnに昇格（次回から可視化）

ここまで修正した時点で「ようやく画像が切り替わるようになった」と一瞬喜びましたが、その喜びは10分で打ち砕かれます。

騙されていた ── Nano Banana の無料枠は「0/0/0」だった

設定の切り替えと上記のバグ修正の両方を終え、新しいAPIキー（AI Studioの無料枠プロジェクトで発行したもの）で画像生成を走らせました。結果：

WARN  画像候補の取得に失敗（スキップ）
  error: Quota exceeded for metric:
         generate_content_free_tier_requests,
         limit: 0,
         model: gemini-2.5-flash-preview-image

limit: 0。

これは「使い切った」のではなく、そもそも無料枠が与えられていないことを意味します。

慌ててGoogle AI Studioの「レート制限」ページ（https://ai.google.dev/pricing など）を開いて確認した結果がこれ（無料枠タブ）です。本情報は2026年4月7日時点でのGoogle AI Studioの表示を確認したものであり、可能であれば最新のスクリーンショット（日時入り）を添付することをお勧めします。

モデル RPM TPM RPD
Nano Banana (gemini-2.5-flash-preview-image) 0 0 0
Nano Banana Pro (gemini-3-pro-image) 0 0 0
Nano Banana 2 (gemini-3.1-flash-image) 0 0 0
Imagen 4 Fast Generate – – 25
Imagen 4 Generate – – 25
Imagen 4 Ultra Generate – – 25
Gemini 2.5 Flash（テキスト） 5 250K 20
Gemini 3 Flash（テキスト） 5 250K 20

Nano Banana系はすべて0/0/0。つまり、Googleの設計では有料プランに課金設定を紐付けた状態でしか使えない、ということが判明しました。ネット上の「無料枠」に関する言及は、おそらくpreview時代の古い情報で、一般提供化のタイミングで無料枠が撤廃されたものと推測されます。

一方でImagen 4系は3モデルそれぞれ25 RPDの無料枠が残っていました。これが「本物の無料枠」だったのです。

発見 ── Imagen 4 を 3 モデル rotation すると 75 枚/日の無料枠

複数のAIモデルを活用した効率的なコンテンツ生成システム

複数のAIモデルを活用した画像生成の最適化戦略

RPD（1日あたりのリクエスト上限）はプロジェクトごとではなくモデルごとに与えられています。つまり：

モデル 無料枠 RPD
Imagen 4 Fast Generate 25
Imagen 4 Generate 25
Imagen 4 Ultra Generate 25
合計 75 枚/日

Googleの公式ドキュメント（例: Vertex AI Generative AI ドキュメント）に基づくと、モデルごとのRPD制限は独立しており、それぞれに無料枠が設定されています。

1記事12枚生成するとして、1日6記事まで$0で運用できます。個人ブログの更新頻度としては十分な枚数です。しかも画質はFLUXのローカル生成と同等かそれ以上。これこそが私が探し求めていた答えでした。

実装：GeminiImageProvider にモデルチェーンを入れる

あとはこの3モデルを自動でローテーションする仕組みを導入するだけです。既存のGeminiImageProviderは「プライマリモデル1個 + Nano Banana固定フォールバック」という設計でしたが、これを任意長のチェーンに作り直しました。

// packages/server/src/services/image/gemini-image-provider.ts

const DEFAULT_MODEL_CHAIN = [
  "imagen-4.0-fast-generate-001",    // 画質: 普通、無料枠 25/日
  "imagen-4.0-generate-001",          // 画質: 良い、無料枠 25/日
  "imagen-4.0-ultra-generate-001",    // 画質: 最高、無料枠 25/日
] as const;

async getImage(params: ImageSearchParams): Promise<ImageResult> {
  const aspectRatio = this.calcAspectRatio(params.width, params.height);
  let lastError: unknown = null;

  for (let i = 0; i < this.modelChain.length; i++) {
    const model = this.modelChain[i];
    const isLast = i === this.modelChain.length - 1;
    try {
      return await withRetry(
        () => this.generateWithModel(model, params.query, params.altText, aspectRatio),
        {
          maxRetries: 2,
          // quota 超過は同モデルでリトライしても意味がないので、チェーン移行で処理
          retryableErrors: (e) => isRetryableError(e) && !isPermanentQuotaError(e),
        },
      );
    } catch (error) {
      lastError = error;
      if (isPermanentQuotaError(error) && !isLast) {
        this.logger.warn(
          { model, nextModel: this.modelChain[i + 1] },
          "quota に達したため次のモデルへフォールバックします",
        );
        continue;
      }
      throw error;
    }
  }
  throw lastError instanceof Error
    ? lastError
    : new Error("全モデルで画像生成に失敗しました");
}

ポイント：

  • **isPermanentQuotaError**はRESOURCE_EXHAUSTED / quota / spending capを含むメッセージを検知します。
  • その場合は同じモデルでのリトライはせず、チェーンの次のモデルへ進みます。
  • クォータ以外のエラー（400, 500, ネットワークエラーなど）は同じモデルで2回リトライし、それでもダメならエラーをスローします。

1日の運用イメージ：

00:00〜  Fastの25枠を使用
～Fastを使い切る → 429エラー → Generateに自動切替
～Generateを使い切る → 429エラー → Ultraに自動切替
～Ultraを使い切る → 429エラー → エラーをスロー（UIにエラー表示）
翌00:00に枠がリセット

ただし、本記事執筆時点では1日のテスト運用のため、長期安定性や予期せぬ挙動についてはまだ検証中です。

実装から1日回した感触では、Fastだけで1日分の生成をまかなえています。モデル切り替えが発動するのは、月末のバースト時などの保険として機能すると考えています。

最終構成

  • 通常運用: Gemini imagen-4.0-fast-generate-001 + Generate / Ultraへの自動フォールバック。合計75枚/日の無料枠。
  • CAP超過時またはGoogle障害時: FLUX.1 schnell Q5 GGUF（ローカル環境、35分/記事、無料）。
  • さらなる保険: Cloudflare Workers AI（FLUX schnell、10,000 neurons/日の無料枠で約10-20枚生成可能）。

ローカル環境の後片付け

ストレージ容量を最適化するためのディスク整理とファイル削除

ローカル検証で集めた不要なモデルは合計32GBにもなりました。

  • flux1-schnell-fp8.safetensors (16.1GB)
  • sd3.5_medium_incl_clips_t5xxlfp8scaled.safetensors (10.8GB)
  • t5xxl_fp8_e4m3fn.safetensors (4.9GB)

macOSのtrashコマンドでゴミ箱に送り、Finderから空にしてディスク容量を解放しました。

残すもの：

  • flux1-schnell-Q5_K_S.gguf (8GB) — FLUX環境復帰用
  • t5-v1_1-xxl-encoder-Q5_K_M.gguf (3GB)
  • clip_l.safetensors (246MB)
  • ae.safetensors (335MB)

合計11GBでFLUX環境を温存できています。

振り返り ── 学び 4 つ

複数の技術アプローチを比較検討する図解

7時間を費やして、結局のところ「クラウドAPIのほうが速くて安くて画質も良い」という、検証を始める前から薄々感づいていた答えにたどり着きました。

しかし、その過程で踏んだ多くの罠から得られた学びも少なくありません。

  1. ComfyUIのワークフロー構造（FLUX / SD3 / SDXLの違い）が実践を通じて深く理解できました。UnetLoaderGGUFとDualCLIPLoaderGGUFの組み合わせでMacでもFLUXを動かせる、という確証が得られたのは大きな収穫です。
  2. MPSのfp16アップキャスト挙動、GGUF量子化が解決する範囲と解決しない範囲が明確になりました。メモリ消費は抑えられますが、GPUの計算時間はあまり短縮されないという実態を把握できました。
  3. エラーをdebugレベルで握り潰す設計の危険性を痛感しました。API key not validという重要なエラーが完全にサイレントで流れてしまい、UIからは「成功したのに画像が変わらない」という不可解な挙動に見えました。debugレベルで良いのは「頻繁に発生する正常系の軽微な情報」のみであるべきです。
  4. 「無料枠があるはず」という思い込みは必ず自分で検証することの重要性。Google AI Studioのレート制限ページを一度確認すれば済む話を、ネットの古い情報やSNSの曖昧な記憶で「あるはず」と決めつけて半日を無駄にしました。Nano Bananaは現時点で有料モデルであり、Imagen 4系は3モデルそれぞれ25 RPD、合計75枚/日の無料枠。これが2026年4月7日現在の正確な情報です。

特に4つ目の学びには、この記事の前バージョン（先日書いた下書き）にも「Nano Bananaの無料枠で500枚/日」と堂々と記していた、という恥ずかしいオチがついています。自信を持って書いた情報ほど、常に疑って自分で検証することの重要性を、身をもって学び直した経験となりました。

ローカルLLMや画像生成に手を出した人なら一度は経験する道だと思いますので、この記事が誰かの時間節約になれば幸いです。そして「Nano Banana 無料枠」をキーワードで検索してこの記事に辿り着いた方がいらっしゃいましたら、その情報は古いです。Imagen 4のモデルチェーンに切り替えることを強くお勧めします。

今すぐ試す：Imagen 4 無料枠活用ガイド

Imagen 4の無料枠を活用して画像生成を始めるためのステップバイステップガイドです。

  1. Google Cloud ConsoleでプロジェクトまたはAI Studioで無料アカウントを作成:
    まだアカウントをお持ちでない場合は、Google Cloud ConsoleまたはGoogle AI Studioで新しいプロジェクトを作成し、無料アカウントを設定してください。
  2. レート制限を確認:
    Google AI Studioの「レート制限」ページ（https://ai.google.dev/pricing など）にアクセスし、Imagen 4 Fast / Generate / Ultraの各モデルに25 RPD（1日あたりのリクエスト数）の無料枠が設定されていることを確認してください（2026年4月7日時点の情報）。
  3. モデルチェーンコードを実装:
    本記事の「実装：GeminiImageProvider にモデルチェーンを入れる」セクションで紹介したモデルチェーンのコードを、ご自身の画像生成システムに組み込んでください。これにより、いずれかのモデルのクォータが上限に達した場合でも、自動的に次のモデルに切り替わって生成を続行できます。
  4. テスト実行:
    実装が完了したら、少量の画像生成リクエストを送信し、モデルが正しく機能し、クォータ超過時に自動でフォールバックが行われるかを確認してください。

まとめ

M1 Proでのローカル画像生成検証と、Gemini Nano Bananaの無料枠に関する誤情報を踏んだ経緯を記録しました。結論として、個人ブログの画像生成コストをゼロに近づけるなら、Imagen 4系（3モデル × 25 RPD = 合計75枚/日の無料枠）が、2026年4月7日現在、最も現実的な選択肢です。

次のアクションとして、APIをシステムに組み込む際は、必ずGoogle AI Studioのレート制限ページを自分で確認することをお勧めします。インターネット上の情報は半年で陳腐化する可能性があります。

スポンサーリンク

コメント