【第30回】Grok Imagine API を漫画コマ生成に使ってみた——OpenAI 互換のフリして全然違う、料金・3枚制限・棲み分け

Grok Imagine API とは

Grok Imagine は xAI が提供する画像生成 API だ。Grok チャット側の「画像を作って」相当を、REST API として叩ける。OpenAI の gpt-image-2 や Google の Gemini（Nano Banana）と同じ立ち位置になる。

エンドポイントは 2 種類:

• POST https://api.x.ai/v1/images/generations（テキスト→画像）
• POST https://api.x.ai/v1/images/edits（画像編集、参照画像対応）

URL の形からして OpenAI 互換に見える。実際 docs にも "OpenAI compatible" と書いてある。

が、信じてはいけない。 互換なのは URL の形だけだ。リクエスト body はけっこう違う。

まず料金から

フラットレート。OpenAI のように size × quality の組み合わせ表があるわけではなく、モデルを選んだら 1 枚いくら、で終わる。これは見積もりが楽。

第21回で書いた gpt-image-2 の料金と並べるとこうなる:

standard ($0.02) は gpt-image-2 low の 3〜4 倍だが、Gemini Flash よりは安い。quality ($0.05) は OpenAI medium とほぼ同じ。

ただし第29回で書いた通り、gpt-image-2 は per-image の表示価格の 4 倍以上を入力トークンに払うことがある。Grok は今のところ入力トークン課金が docs に明記されていない（実際の請求でどうなるかは要観察）。

API の罠：OpenAI 互換は嘘

実装してから 3 回ハマった。

罠 1: size パラメータは存在しない

OpenAI と同じ感覚で叩くとこうなる。

curl -X POST https://api.x.ai/v1/images/generations \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -d '{"model":"grok-imagine-image","prompt":"...","size":"1024x1024"}'

返ってくるのは HTTP 400 Argument not supported: size。

正解は aspect_ratio と resolution の組み合わせ:

{
  "model": "grok-imagine-image",
  "prompt": "...",
  "aspect_ratio": "1:1",
  "resolution": "1k",
  "n": 1,
  "response_format": "b64_json"
}

• aspect_ratio: "1:1" "16:9" "9:16" "3:4" "2:3" ...
• resolution: "1k" または "2k"（小文字）
• n: 1〜10
• response_format: "url" または "b64_json"

OpenAI で慣れた手癖でリクエスト書くと、最初の関門でいきなり止まる。

罠 2: /v1/images/edits は JSON、multipart ではない

OpenAI の /v1/images/edits は multipart/form-data で画像ファイルをアップロードする。Grok は JSON で base64 data URI を渡す。

{
  "model": "grok-imagine-image-quality",
  "prompt": "Render this as a pencil sketch",
  "images": [
    {
      "type": "image_url",
      "url": "data:image/png;base64,iVBORw0KG..."
    }
  ]
}

• image ではなく images（複数形）
• 中身は {"type": "image_url", "url": "..."} の配列
• URL も data URI も両対応

OpenAI 用に書いた multipart のクライアントコードを使い回そうとすると、ここで全部書き直しになる。

罠 3: 参照画像は 最大 3 枚

Multi-image editing で渡せるのは 3 枚まで。OpenAI の 16 枚、Gemini Pro の 6 枚と比べると一番厳しい。

manginus はキャラのリファレンスを CharDB（プロジェクト共通のキャラ辞書）に複数枚登録する設計なので、Grok を組み込むとこれが直撃する。1 キャラに表情バリエ含めて 10 枚登録していたら、即アウト。

うちは 「3 枚超なら ValueError で fail-fast」 にした。第28回でも書いた通り、silent truncation（黙って何枚か捨てる）にすると ref が反映されない原因が分からなくなる。落ちた方がいい。

OpenAI / Gemini と何が違うか、棲み分け

3 つを並べる:

安く済ませたい：gpt-image-2 low

1 枚 $0.005 は依然として最安。参照画像のトークン代を載せても、Grok standard より安いことが多い。ただし参照画像を 3〜5 枚以上渡すケースでは入力トークンが効いてきて逆転する場合があるので、ダッシュボードで請求を実測する必要がある（第29回参照）。

参照画像をいっぱい渡したい：Gemini か OpenAI

キャラの正面・横顔・後ろ姿・表情バリエを全部渡したい場面は、Grok の 3 枚枠では足りない。Gemini か OpenAI に投げる。

モデレーションが厳しめの題材：Grok

OpenAI で safety_violations=[sexual] が出るような構図——たとえばホットパンツとか部屋着の薄着とか——を Grok は通すことが多い。これは 次の節の話になる。

コマの局所修正：gpt-image-2 か Grok

edits の API があるのは OpenAI と Grok。Gemini にも編集系の API はあるが、manginus 側では json-edit（scene_json を渡して構造を保ちながら編集する仕組み）として Gemini 経路を使っている。

修正の性質によって使い分ける、というのは第21回でも書いた通り、引き続き有効だ。

manginus への組み込み

manginus は元々 Gemini と OpenAI のどちらを使うかを IMAGE_BACKEND 設定で切り替えられる作りだった。今回 "grok" を 3 番目の選択肢として追加した。

IMAGE_BACKEND_GENERATE = "gemini" | "openai" | "grok"
IMAGE_BACKEND_EDIT     = "gemini" | "openai" | "grok"
IMAGE_BACKEND_INPAINT  = "gemini" | "openai"   # grok は未対応

per-fn で切り替えられるので、たとえば「生成は安い gpt-image-2 low、編集はモデレーションに引っかかるかもしれないから Grok」みたいな組み合わせができる。

使用量ダッシュボードも /api/grok/usage として生やした。Settings → Grok Usage で per-image の累積を月別・プロジェクト別に確認できる（モデル別 = grok-imagine-image-quality か grok-imagine-image か、で内訳が見える）。

実際の出力（ノリクロ P2、standard モデル）

切り替え後にノリクロ第1章 P2 を grok-imagine-image（standard, $0.02）で再生成した。art_style（shonen color, cel-shaded, bold outlines）と CharDB のキャラ参照（のり子・クロコ各 1 枚）を正規パイプラインで通したもの。

ref を 2 枚（のり子全身 1 + クロコ全身 1）に絞った状態。テンプレ + base_prompt + art_style が全部効いているのが分かる。canvas は 832×1248、ファイルサイズは PNG で 240 KB、WebP で 74 KB。OpenAI 版（1024×1536、PNG 2.1 MB）と比較すると解像度は一段下、ファイルもかなり軽い。

これから Grok で何を書きたいか：お色気ラブコメギャグ

正直に書く。Grok を入れた一番の動機は、お色気ラブコメギャグを書きたいからだ。

ラブコメというジャンルは、ちょっとお色気が入って読者が「うわっ」とか「やめろ！」とか心の中でツッコミ入れる、あの一連の流れまで含めて成立する。マンガとして当然の表現範囲なのに、OpenAI のモデレーションは反応の出し方が硬くて、よくある「下着がチラ見えしたコマでヒロインが照れる」みたいなお約束パネルが safety_violations で落ちる。Gemini も中間で、通るか通らないか確率的にギャンブルになる。

これだと、毎回モデレーションを避けるために構図を作り直すか、修整を別経路でやるか、二度手間が起きる。

Grok は今回試した範囲では、このあたりの お約束ライン を素通りした。ラブコメをコメディとして成立させるための演出の自由度が、他社より明確に広い。

manginus の次の企画として、ノリクロ（ノリとクロコのデータ探検）の流れを引き継ぎつつ、もう少し「ラブコメ寄り」のシリーズを試してみたい。Grok を本番経路に入れる前提で書ける、というのは創作の選択肢を 1 つ広げるという意味で大きい。

まとめ

• Grok Imagine API は OpenAI 互換を謳うが、size 不可・/edits は JSON・images 配列という独自仕様
• 料金は standard $0.02 / quality $0.05 のフラットレート
• 参照画像は最大 3 枚という強い制約。CharDB 設計と相性が悪いので fail-fast にした
• 入力トークン課金が（今のところ）見えないのは魅力。実請求で要確認
• OpenAI のモデレーションで詰まる構図——お色気ラブコメギャグのお約束パネル——を通したい題材に向いている
• manginus には IMAGE_BACKEND_*=grok で per-fn 切替を実装、使用量ダッシュボードも追加した