Images 2.6 では、API に 2 つの独立したコントロール (quality と complexity) が導入されています (体系的に文書化されています)。製品の発表によると、画質は視覚的な詳細と忠実度を制御し、複雑さは「シーンにどれだけの計画を入れるか」を決定します。 OpenAI は、ワークフローに必要な品質レベルと組み合わせて編集を高速化するために、ほとんどの編集タスクに低複雑性を使用することを明示的に推奨しています。変更ログ (2026-11-04) には、2.6 リリースのハイライトの中で調整可能な複雑さもリストされています。

👉 PoYoでGPT Image 2.6 APIを試す：1枚あたりの料金とプレイグラウンド。

この 2 つを混同すると、「より細かく描く」と「より考える」を 1 つのノブとして扱います。公式の定義は逆です。前者は忠実度を規定します。後者は、レンダリング前の計画の深さを制御します。 「パラメーターの省略は最大値を意味する」という古い習慣を維持していると、複雑さが静かにデフォルトの high に影響し、編集が遅くなり、不要な変更が導入される可能性があります。

値、デフォルト、コスト

イメージ生成ガイドとイメージ プロンプト ガイドによると、次のようになります。

複雑さの調整には個別の請求明細はありません。複雑さが増すと、遅延や不要な追加の変更が追加される可能性があるため、ドキュメントでは、常に最大値にするのではなく、特定のタスクの結果を比較することを推奨しています。製品ページにはさらに、多くの要素や制約があるシーンでは、中程度または高度の複雑さを試すことができると記載されています。高速編集は低い設定に適しています。複雑さが低いため、背景や道路標識の交換などの集中的な変更に適しています。より複雑になると、高密度のテキスト、複雑なレイアウト、オブジェクト間の関係が役立ちます。

Flare が quality=low で実行されると、OpenAI は生成が約 6 秒で完了すると言います。 medium/high の Sunburst の品質は、より詳細で編集の一貫性が強化されるように配置されています。これらはモデル層と品質層の複合的な影響であり、複雑さだけが原因であるとは考えられません。比較せずに「一方の層が常に高速である」と主張すべきではありません。

A/B の方法

プロンプト ガイドでは、一度に 1 つの設定を変更するという明確な調整規則が示されています。複雑さを比較するときに quality をフリーズします。レイアウトはすでに正しいが、小さなテキストが読みにくい場合は、同じ複雑さで異なる quality 値を比較します。ドキュメントでは、size="1024x1536" と quality="medium" を修正した同じサッカー ペーパー カット プロンプトを使用して、トロフィー、「チャンピオン」サインの配置、ジャージの詳細における低/中/高の複雑さにおける Sunburst の違いを示します。低複雑さでは、トロフィーに王冠が表示され、チームの前に大きなバナーが表示されます。ミディアムは月桂樹と紋章を追加します。ハイはサインをスタンドに移動し、前景を選手とジャージの折り目に残します。この例は、プロンプトでレイアウト、テキスト、スタイルが十分に指定されていない場合、複雑さを高めると構成の決定が大きく変化することを示しています。レイアウト、コピー、スタイルがプロンプト内ですでにロックされている場合、より複雑になってもほとんど違いが見られない可能性があります。

対象を絞った編集の場合、公式アドバイスは、low から開始して、周囲の詳細が損なわれていないことを確認することです。製品の発表と生成ガイドの文言は一致しています。背景の交換や道路標識の編集など、焦点を絞った変更は、複雑さを軽減するのに適しています。高密度のテキスト、複雑なレイアウト、オブジェクトの関係では、中/高を試してみる価値があります。マークアップ編集では、複雑性が低く、通常は「円で囲まれたオブジェクトのみを変更する」プロンプト制約と一致し、円から外れるドリフトを抑制するのに役立ちます。

実際の組み合わせ (まだ文書化された推論の範囲内)

「高速ドラフト」を次のように扱います: Flare + quality=low (または medium) + 編集用に complexity から low を明示的に設定します (省略するとデフォルトで高になり、実際には遅くなる可能性があるため)。 「最終アセット」を次のように扱います。Flare または Sunburst を選択した後、quality を上げ、複雑さを個別に上げるかどうかを A/B に設定します。max の品質が high の複雑さと組み合わされる必要があると想定しないでください。既存の 2.5 ワークフローを移行する場合、プロンプト ガイドでは、最初の比較ではプロンプト、参照、サイズ、品質、出力形式を変更せずに維持し、複雑さはモデルのデフォルトのままにし、受け入れ後に調整することを推奨しています。スケーリングする前に、応答時間、失敗/再試行、許容されるイメージごとのコストを追跡します。

また、一般的な制限にも注意してください。複雑なプロンプトには最大で約 2 分かかる場合があります。テキストのレンダリングと構成の制御には依然として境界があります。パラメーターは、モデル機能エンベロープ内の忠実度、計画、レイテンシのみを交換します。パラメーターは、コンテンツのモデレーションや物理レベルのシミュレーション制限を削除しません。 xhigh と max は、満たされていない品質が明らかに向上し、レイテンシの予算が許す場合にのみ使用してください。ドキュメントは、すべてのプロンプトに対して上位層の方が優れていることを保証するものではありません。

結論: quality は「どのくらい細かく描くか」、complexity は「どのくらい深く計画するか」に答えます。 Images 2.6 はそれらを分割し、公式ガイダンスでほとんどの編集シナリオを複雑さの低い方向に誘導します。つまり、「省略 = 最大」の習慣を維持するインテグレーターは、代わりにデフォルトで高い計画の深さを取得します。ドキュメントの説明に従って、パラメーターを明示的に設定し、単一変数の比較を実行します。