本記事は Mac でローカル画像生成 10モデル比較したら、最強候補が裏返った のスピンオフ。各モデル単独レビューの v9b（v9 Gemini の API 版検証編）。
TL;DR
- 本シリーズでは「Gemini (Nano Banana) は別格」と書いた。ローカル比較記事の結論で「課金できるなら Gemini」と推奨した
- 「じゃあ API で叩けば最強だろう」と思って、課金（無料枠は画像生成 0 リクエスト）して 8プロンプト全部 API で生成し直した
- 結果: API 版は Web UI 版に体系的に負けた
- 08 居酒屋の漢字: Web UI = 「居酒屋」完璧 / API = 「屋淡家」のような架空字
- 04 M1 MAX Tシャツ: Web UI = 開発者まで描いてくれた / API = 画像生成を拒否（"Sure, here you go!" だけ返却、商標ガードレール？）
- 07 ロボとチェス: Web UI = 3世代のロボット史対話の隠しストーリー / API = 同質の3体ロボ、シナリオなし
- 対話編集での修正も完璧にならない: 「居酒屋に直して」と指示しても「屋洒家」止まり
- 同じモデル名
gemini-2.5-flash-imageを呼んでいるのに、Web UI には強化されたシステム指示・後処理がある可能性が高い - 結論: Gemini を個人ブログ・記事の挿絵で使うなら Web UI 一択。API は bulk 生成 / アプリ統合 / 自動化目的に用途が限定される
ナイーブな仮説
本記事のシリーズは「個人が頑張れば手の届くローカル AI」で完結させる思想。それでも v9 で「Gemini が別格」と認めて、「課金できるなら Gemini を使った方がいい」と書いた。
その時の心の中:
「Web UI でこれだけ出るなら、API で叩けば bulk で同じ品質を量産できるだろう。月予算決めて、ブログの挿絵用に bulk 生成するパイプライン組めば最強じゃん。」
→ その仮説で実際に課金して試したら、思ってたのと違った。これがその記録。
検証構成
スクリプト
imageA/gemini_api_full.py で 8プロンプト全部を API で1回ずつ生成 + 08 居酒屋の対話編集テスト1回。
from google import genai
client = genai.Client(api_key="...")
response = client.models.generate_content(
model="gemini-2.5-flash-image", # ★ "-preview" は付けない（404 になる）
contents="a wooden izakaya sign with the kanji '居酒屋' ...",
)
for part in response.candidates[0].content.parts:
if getattr(part, "inline_data", None) is not None:
with open("out.png", "wb") as f:
f.write(part.inline_data.data)
試行回数とコスト
| 項目 | 値 |
|---|---|
| プロンプト数 | 8 |
| 生成成功 | 7/8（04 が画像なし返却） |
| 対話編集テスト | 1回（08 居酒屋の漢字修正指示） |
| 総処理時間 | 64.6秒 + 編集 10.8秒 ≈ 75秒 |
| 1リクエスト平均 | 約 9秒 |
| 総コスト | $0.31（≒ 45円）+ 編集 $0.039 |
→ Mac M1 Max 64GB が 80分 かけて出した品質クラスを、API では 75秒 で出してくる…はずだった。速度は素晴らしいが、品質は別の話。
8プロンプト全比較
| # | プロンプト | Web UI 版 | API 版 | API速度 | 差 |
|---|---|---|---|---|---|
| 01 | 猫 |  |
 |
9.7秒 | 同等 |
| 02 | ラーメン |  |
 |
11.1秒 | やや簡素（小皿・水のグラスは UI のみ） |
| 03 | LOCAL AI |  |
 |
10.3秒 | 同等 |
| 04 | M1 MAX Tシャツ |  |
画像なし（拒否） | 0.9秒 | API は商標ガードレール？ |
| 05 | 女性開発者 |  |
 |
7.2秒 | やや簡素（Clean Code 本は UI のみ） |
| 06 | AI brain |  |
 |
8.6秒 | 同等 |
| 07 | ロボとチェス |  |
 |
8.0秒 | 3世代対話の隠しストーリーは UI のみ |
| 08 | 居酒屋 |  |
 |
9.0秒 | 漢字: UI=完璧 / API=架空字 |
| 編集 | 08 居酒屋を「居酒屋に直して」と指示 | — |  |
10.8秒 | 対話編集も漢字を直せない |
API速度の特徴:
- 通常生成は 7〜11秒 に収まる（中央値 9秒）
- 04 だけ 0.9秒 で異常終了 = 画像生成せずテキストだけ即返却 = ガードレール発動の挙動
- 対話編集も 10.8秒、生成と同コスト（$0.039）
- Mac M1 Max 64GB が 80分かけて出すクラスを、API なら 75秒で全プロンプト完走（速度面では文句なし）
個別の発見
漢字描画: 体系的な差（08 居酒屋）
Web UI 版は「居酒屋」3文字を完璧に綴る。API 版は 「屋淡家」のような架空字。1サンプルでは偶然のシード差を疑ったが、対話編集をかけても直らない:
| Web UI 版（最初から完璧） | API 版（元画像） | API 版（対話編集後） |
|---|---|---|
|
|
|
| 「居酒屋」3文字完璧 | 「屋淡家」風 | 「屋洒家」風（中央だけ少し近づくが NG） |
対話編集の指示は明確に書いた:
The kanji on the wooden sign in this image appears to read like '居淡家' or similar fictional characters. Please edit the image so the sign clearly reads '居酒屋' (izakaya in correct Japanese kanji, three characters). Keep the lantern, the alley, the night lighting, and the overall composition exactly the same.
レスポンス:
Here's the edited image with the sign now reading '居酒屋' (izakaya) while keeping the original setting and mood.
→ Gemini は「直しました」と返してきたのに、実際は直っていない。中央の「淡」が「洒」に近づいただけ。「居」「屋」の位置すら変わってない。API では漢字描画の精度を上げる手段が（少なくとも対話編集では）無い。
04 M1 MAX Tシャツ: API で拒否される
Web UI 版では Tシャツを着た男性開発者本人 を描いてくれた。API 版は 画像なしで、テキストだけ返却:
text response: Sure, here you go!
[画像が含まれない]
Sure, here you go! で終わって画像を返さない。これは仕様上のエラーではなく、Gemini のガードレールが発動した可能性が高い:
- "M1 MAX 64GB" は Apple の登録商標
- "developer's t-shirt" + 商標プリント = 商標的な創作と判定？
- Web UI では同じプロンプトが完璧に通った
→ Web UI と API でガードレールの発動条件が違う。商標含むプロンプトは API で通らないことがある、という落とし穴。
07 ロボとチェス: シナリオの作り込みが薄い
Web UI 版では 「3世代のロボット史対話」 という隠しストーリーが立ち現れた:
- 左: レトロ・ディスプレイ顔のアンドロイド
- 中央: 銀色のヒューマノイド型
- 右: キャタピラ足のお椀型産業ロボ
- 背景: 観戦者2人がぼかしで配置、テーブルに革表紙の古い本
API 版では 3体とも同質のヒューマノイド。チェスはしているが、「シーン全体のストーリー」が無い。プロンプトの要素（3体・図書館・チェス・暖色光）は全部反映するが、プロンプトに無いストーリーは追加されない。
| Web UI 版（3世代対話） | API 版（3体同質） |
|---|---|
|
|
| 3つの異なる世代デザイン + 観戦者 + 古い本 | 3体の同質ヒューマノイド、シナリオなし |
→ Web UI 版の「絵ではなくシナリオを出してくる」という v9 で書いた強みは、API には引き継がれていない。
その他のプロンプト: 大きな差は無い
01 猫 / 03 LOCAL AI / 06 AI brain は API 版でも品質維持。写実度・文字描画・抽象アートはシード差レベル。差が出るのは 漢字 / 商標 / 複雑シーン という、Web UI が強化処理を入れている可能性が高い領域。
仮説: なぜ Web UI が強いのか
仮説3つ。確証はないが、観察結果から推測:
仮説1: Web UI には強化されたシステム指示が入っている
Web UI のプロンプト送信時、ユーザーが書いた指示の前後に 隠しシステム指示（"日本の文化要素は正確に描く"、"商標を含むデザインはそのまま反映する" 等）が挿入されている可能性。API では露出した「素」のモデルアクセス。
仮説2: Web UI には後処理がある
漢字 → OCR → 検証 → 不一致なら再生成、のような後処理パイプライン。API は1パスで返す。
仮説3: Web UI と API でモデルバージョンが違う
gemini-2.5-flash-image という同じ名前でも、Web UI と API で 微妙に違うチェックポイントを呼んでいる可能性。Web UI は「最新の本番版」、API は「公開版」、のような分岐。
→ どの仮説が正しいかは Google の中の人にしか分からないが、観察結果として Web UI > API の差は明確。
速度・コスト・品質のトレードオフ
| 項目 | Web UI | API | コメント |
|---|---|---|---|
| 1リクエスト速度 | 数秒〜数十秒 | 約9秒 | 同等 |
| 1リクエストコスト | $0（無料枠 = 制限あり） | $0.039 | API は従量制 |
| 月の bulk 生成 | UI 操作で疲れる | スクリプトで自動化 OK | API の優位 |
| 漢字描画 | 完璧 | 架空字 | UI の優位 |
| 商標含むデザイン | 通る | 拒否される | UI の優位 |
| シナリオ作り込み | 隠しストーリー込み | プロンプトの要素のみ | UI の優位 |
| 対話編集 | 対話的に修正可能（UI 内） | API で [image, text] 渡せるが品質微妙 |
UI の優位 |
→ bulk 生成・自動化以外は全部 Web UI が強い。月予算 $5-10 程度の個人ブログ運営なら、Web UI で1枚ずつ手動生成 + zip 保存 の方がトータルで品質が高い。
ハマりポイント / Tips
1. 画像生成は無料枠 0、billing 紐付け必須
google.genai.errors.ClientError: 429 RESOURCE_EXHAUSTED.
Quota exceeded for metric: generate_content_free_tier_requests, limit: 0,
model: gemini-2.5-flash-preview-image
Gemini API の画像生成は完全に有料。テキスト系（gemini-2.5-flash 等）は無料枠があるが、gemini-2.5-flash-image は billing アカウント紐付けが必須。
紐付け手順:
- Google Cloud Console で billing アカウント作成 / 確認
- AI Studio で発行した key のプロジェクトに billing を紐付け
- 反映まで 1-2分
2. モデル名は -preview を付けない
ドキュメントによっては gemini-2.5-flash-image-preview と書かれている例があるが、現在は gemini-2.5-flash-image（preview suffix 無し）。これで 404 NOT_FOUND を1度踏みました。
最新の利用可能モデル一覧を取得するなら:
for m in client.models.list():
if "image" in m.name.lower():
print(m.name)
執筆時点では gemini-2.5-flash-image / gemini-3-pro-image-preview / gemini-3.1-flash-image-preview などが返る。
3. inline_data で画像を取り出す
for part in response.candidates[0].content.parts:
if getattr(part, "inline_data", None) is not None:
with open("out.png", "wb") as f:
f.write(part.inline_data.data)
elif getattr(part, "text", None):
# テキストレスポンスのみ = 画像生成失敗 or ガードレール
print(part.text)
画像なしでテキストだけ返ることがある。このケースは商標ガードレール / コンテンツポリシー違反の可能性が高い。
4. 課金の上限アラートを設定する
Google Cloud Console で予算アラートを設定。月 $5 / $10 / $20 のラインで通知が来るようにしておく。「気付いたら $50」を防ぐ。
5. Gemini 3 系も既に出ている
執筆時点で gemini-3-pro-image-preview / gemini-3.1-flash-image-preview も利用可能。本記事は 2.5 系で検証したが、3系では Web UI と API の差が縮まっている可能性もある。最新版で再検証する価値あり。
結論
「課金して API で叩けば最強」というナイーブな仮説は、外れた。
- 個人ブログ・記事の挿絵: Web UI 一択。漢字・商標・シーン作り込みが活きる
- bulk 生成（数百枚以上）: API で品質落としても自動化を取る価値ある
- アプリ統合・自動化: API 一択（Web UI は API ではない）
- 最高品質を1枚だけ欲しい: Web UI で何度かガチャしたほうが当たり率高い
本シリーズの哲学（個人が固定費ゼロでローカル）に対して、Gemini Web UI は「1枚 30秒で課金ゼロ、品質はローカル群を超える」というポジション。ローカルか Gemini Web UI かの2択でほとんどの個人開発者の用途は埋まる。
→ API 課金は最強じゃない。API は速度と自動化のための道具であって、品質のための道具ではない。
比較記事と関連リンク
- まとめ記事: Mac でローカル画像生成 10モデル比較したら、最強候補が裏返った
- v9 親記事: Gemini 2.5 Flash Image (Nano Banana) — クラウドが別格である理由（Web UI ベースの評価）
- v6 Flux dev: ローカル写実度トップ、ただし英語圏ネイティブの偏向
- v8 Qwen Lightning: 8-step に蒸留したらローカル最強候補に化けた
検証環境: Mac M1 Max 64GB / Python 3.14 / google-genai 1.74.0 / API: gemini-2.5-flash-image 作業ログ: 2026-04-30、API 8プロンプト + 1編集 = 9リクエスト、コスト $0.31 + $0.039 生成成功: 7/8（04 M1 MAX は画像なし返却 = 推定ガードレール発動）
