GPT Image 2で「Unknown parameter: 'style'」が出る原因と直し方

GPT Image 2で Unknown parameter: 'style' が返る場合、まず 送信するJSONから style キーそのものを削除してください。"natural" を別の値に変える修正ではありません。画風の希望は prompt に文章で書きます。

OpenAIのImages APIでは、style はDALL·E 3専用のパラメータです。以前の画像生成コードや自動化設定でモデル名だけを gpt-image-2 に変えると、残ったフィールドが原因になり得ます。以下は2026年9月8日に確認した公式の画像生成APIリファレンスに基づく対処です。

最初に直すのは、画風ではなく送信する項目

たとえば、次のリクエストにはGPT Image 2に渡すべきでない style が含まれています。

json
{
  "model": "gpt-image-2",
  "prompt": "雨上がりの東京の路地を描いてください。",
  "style": "natural"
}

修正後は、描写の希望を prompt にまとめます。

json
{
  "model": "gpt-image-2",
  "prompt": "雨上がりの東京の路地。自然な色調と柔らかい光を使い、写真のような質感で描いてください。"
}

この修正は、natural の動作を同じ名前の別パラメータへ移すものではありません。欲しい見た目を具体的な言葉で伝え直しています。「水彩画風」「線の少ないフラットなイラスト」「落ち着いた色調」のような指定も prompt に含めます。画像の内容や見た目をプロンプトで指定する使い方は、公式の画像生成ガイドで説明されています。

空文字やnullに変えても、キーの削除にはならない

"style": "" と "style": null は、どちらもJSON上では style が存在します。必要なのは、送信データからそのキーをなくすことです。各値を送った際の個別のサーバー応答を前提にせず、未対応の項目を送らない形に直します。

辞書やオブジェクトから組み立てているなら、送信直前のデータを確認してください。Pythonでは payload.pop("style", None)、JavaScriptでは delete payload.style でトップレベルのキーを削除できます。ただし、その後に共通設定を合成していれば、そこで再追加される可能性があります。削除する場所は、画面の入力値だけを見て決めず、最終的なリクエストがどう作られるかを確認して決めます。

画面にstyleがなくてもエラーが残るとき

自動化ツールの入力欄が空でも、保存済みの設定、モジュールの既定値、SDKを包む共通関数などが項目を追加することがあります。エラーだけから、どの処理が追加したかまでは特定できません。

Makeのコミュニティには、画面で style を割り当てていないのに同じエラーが返ったという利用者の報告があります。スレッドでは旧モジュールの置き換えや、URLではなくファイル・Base64を扱う後段処理が話題になっています。ただし、そこでの成功報告はGPT Image 1に関するもので、GPT Image 2の再現試験でも、現在の全モジュールに共通する不具合の証明でもありません。

切り分けるときは、接続先・エンドポイント・モデルをそろえて、送信項目だけを減らすと原因を追いやすくなります。

1. 失敗した呼び出しの接続先、パス、モデルIDを控える。
2. ツールの実行履歴や送信処理で、最終的な本文に style があるか確認する。
3. 同じ接続先で、対応する最小リクエストと比較する。OpenAIへ直接送るImages APIなら model と prompt から始める。
4. 最小リクエストが通ったら、必要なオプションを一つずつ戻す。

比較の途中で別のAPIサービスへ変更すると、送信項目を減らした効果なのか、サービス側の処理の違いなのか判断しにくくなります。互換APIを利用している場合は、そのサービスが受け付ける項目と返却形式も確認してください。OpenAIの仕様と同じとは限りません。

外部にログを共有するときは、APIキー、認証ヘッダー、非公開のプロンプト、入力画像を取り除きます。最初の相談には、項目名の一覧、エラー全文、接続先のホストとパス、使用モジュールやSDKのバージョンがあれば役立ちます。

SDKを更新すれば直るのか

更新によって不要な項目を送る実装が変わる場合はありますが、SDKの更新そのものがGPT Image 2の style 対応を追加するわけではありません。共通の型定義や入力候補に項目が表示されても、選択したモデルがすべての項目を受け付けるとは限りません。

更新後もエラーが同じなら、バージョン番号だけを追うより、最終的なリクエストから style が消えたかを確認します。同じ未対応パラメータを付けたままの再試行では、この原因は取り除けません。

styleを消した後に残りやすい設定

DALL·E向けの設定を流用している場合、style 以外にも見直す項目があります。OpenAIのImages APIに直接送るGPT Imageのリクエストでは、次のように整理できます。

response_format と output_format は役割が異なります。response_format: "url" を output_format: "url" に書き換える方法では直りません。前者を削除し、後者は保存したい画像形式を指定するために使います。各項目の対応範囲は公式リファレンスのパラメータ定義で確認できます。

最初から設定を全部置き換えると変更点が増えるため、まず model と prompt だけで試し、必要な画質や形式を後から追加するのが分かりやすい手順です。

最小リクエストからPNGの保存まで

以下はOpenAIへ直接送るImages API用のPython例です。環境変数 OPENAI_API_KEY を用意し、ファイルに保存して実行します。標準ライブラリだけを使い、送信する項目を model と prompt に限定しています。公式ドキュメントに基づく実装例であり、この記事で実APIへの課金を伴う生成試験を行ったものではありません。

python
import base64
import json
import os
from pathlib import Path
from urllib.error import HTTPError
from urllib.request import Request, urlopen

payload = {
    "model": "gpt-image-2",
    "prompt": (
        "雨上がりの東京の路地。自然な色調と柔らかい光を使い、"
        "写真のような質感で描いてください。"
    ),
}

request = Request(
    "https://api.openai.com/v1/images/generations",
    data=json.dumps(payload).encode("utf-8"),
    headers={
        "Authorization": f"Bearer {os.environ['OPENAI_API_KEY']}",
        "Content-Type": "application/json",
    },
    method="POST",
)

try:
    with urlopen(request, timeout=300) as response:
        result = json.load(response)
except HTTPError as error:
    detail = error.read().decode("utf-8", errors="replace")
    raise SystemExit(f"HTTP {error.code}: {detail}") from error

items = result.get("data") or []
encoded = items[0].get("b64_json") if items else None
if not encoded:
    raise RuntimeError("応答に画像データ data[0].b64_json がありません。")

image_bytes = base64.b64decode(encoded, validate=True)
if not image_bytes.startswith(b"\x89PNG\r\n\x1a\n"):
    raise RuntimeError("PNG以外のデータです。返却形式を確認してください。")

output = Path("generated.png")
output.write_bytes(image_bytes)
print(f"保存先: {output.resolve()} ({len(image_bytes)} bytes)")

この例では既定のPNGを前提にしています。output_format を追加してJPEGやWebPに変える場合は、保存時の拡張子と形式確認も合わせて変更します。タイムアウトはクライアント側の待機時間の設定で、生成完了までの時間を保証する値ではありません。

実行後は generated.png を画像ビューアで開いてください。JSONを受信したこと、Base64を復号できたこと、画像として開けたことは、それぞれ確認する内容が異なります。この例のPNG判定は先頭の識別情報を確認するだけなので、ファイル全体が正常に表示できるかは実際に開いて確かめます。

互換API経由の構成を調べている場合、比較のためにこの例の接続先へ切り替えると条件が変わります。利用中のサービスの接続先と仕様を保って最小化してください。呼び出し方法そのものを整理したい場合は、GPT Image 2 APIの使い方も参考になります。

自動化では「URL待ち」の後段も確認する

生成リクエストの修正後、画像アップロードや添付のステップだけが失敗するなら、後段が何を受け取る設計か確認します。DALL·EのURL出力を前提にしたフローでは、GPT Imageの返却データをそのまま同じ欄へ渡せない場合があります。

OpenAIのImages APIから直接受け取る場合は、data[0].b64_json をBase64からバイナリへ復号し、ファイル名と画像に合ったMIMEタイプを付けて後段へ渡します。PNGなら、たとえば generated.png と image/png です。利用中のモジュールがすでにファイルとして返しているなら、そのファイル出力を使い、重ねてBase64復号しないでください。

URLしか受け付けない後段であれば、生成した画像を利用中のストレージへアップロードし、その処理が返すURLを渡す構成が必要です。response_format: "url" を戻すのではなく、画像の保存とURLの取得を後段で行います。

復旧の確認点は、最終リクエストから未対応のキーが消えていること、応答から画像データを取り出せること、保存した画像を開けることです。style のエラーが別のエラーへ変わった場合は、その新しい応答に沿って次を調べます。最初のエラーが消えたことだけで、画像保存まで成功したとは判断しないようにします。