お客様からのご質問:ChatGPTでは制限されないのに、なぜAPIは32Kで上限が設定されているのですか?
匿名化されたやり取りの内容:お客様:そちらのpromptの長さはChatGPTと異なっています。32Kで上限が設定されているようです。 当社:制限は存在します。そもそも、32Kものpromptを使用する画像ジョブがあるのでしょうか? お客様:たくさんあります。広告クリエイティブやパッケージの寸法など……自分でCodex CLIを呼び出すことにします。 当社:確認のためにお伺いしますが、32,000 tokenのpromptのことでしょうか? お客様:はい。英語での32,000は決して長くありません。ここでは3つの異なる概念が混同されています。まずはこれらを整理しましょう:
「英語での32,000は長くない」という発言は文字数に関するものであり、その指摘はもっともです。しかし、お客様が比較対象とされているChatGPTのWebアプリは、まったく異なる経路を通っています。
32K制限の由来
prompt フィールドに対する公式の OpenAI Images API の制限(/v1/images/generations および /v1/images/edits も同様):
出典: OpenAI API リファレンス、
developers.openai.com/api/reference/resources/images/methods/generate。
文字数と tokens は異なります。 課金およびモデルの理解はどちらも tokens 単位で行われ、usage.input_tokens_details.text_tokens は呼び出しごとに実際に消費されたテキスト tokens を報告します。同じ 32,000 文字でも、英語では約 8K tokens ですが、1 文字あたりより多くの tokens にマッピングされ、より多くの情報量を持つ中国語では大幅に多くなります。そのため、「英語の 32K は短く」、「中国語の 32K は長い」という両方の事象が起こり得ます。そして中国語は、32,000 文字に達するよりも前に 8,192 tokens の上限に達してしまいます。
ChatGPTのウェブアプリが無制限に見える理由
満足のいく画像を取得する方法や安全性による拒否と同じポイントです。ウェブアプリはエージェントであり、APIは単一のアトミックな呼び出しです。- 長いドキュメントをChatGPTに貼り付けると、それを読むのは画像モデルではなくチャットモデルです。チャットモデルは内容を読んだうえで、独自の短い画像用promptを作成し、それを使って画像ツールを呼び出します。画像モデルが元の素材を見ることはありません。10,000文字を超える貼り付けは自動的に添付ファイルにも変換されます(OpenAIヘルプセンター、
help.openai.com)。このことからも、テキストがチャットモデル向けであることは明らかです。 - APIでは画像モデルに直接話しかけます。途中で誰かが素材を読んで、代わりに判断を下すことはありません。制限は画像モデル層に属しており、ウェブアプリは画像モデルをその制限にさらしていません。
- お客様の別れ際の言葉である「自分でcodex CLIを呼び出します」は、正しい直感です。テキストモデルに素材を読ませ、画像用promptを生成させます。これはまさにウェブアプリが裏側で行っていることであり、以下の2段階パイプラインによって実行可能になります。
長いpromptにかかる2つのコスト
まずコスト、次に結果です。 コスト: gpt-imageファミリーのテキスト入力はtoken単位で課金されます(gpt-image-2.5では100万tokenあたり$5.00。概要の料金表を参照してください)。32,000文字の英語promptは約8K tokenで、1回の呼び出しあたりおよそ$0.04です。中国語ではさらに高くなります。単体では小さな金額ですが、画像の枚数分だけ積み重なり、リトライするたびに再度支払うことになります。promptの90%がシーンの説明ではなく素材そのものである場合、その支出の大部分は何も生みません。
結果: 詳細を増やせば、指示への忠実度が高くなるとは限りません。何百もの要件を一度に画像モデルに提示すると、それらが競合します。本当に重要な厳格な制約(ロゴを歪めない、パッケージのテキストを正確にする、人物の人数など)ほど、埋もれてしまいます。画像promptに関するOpenAI独自のガイダンスでは、まず1〜3個の明確な文から始め、その後に必要な構図、ライティング、厳格な制約を追加するよう推奨しています(openai.com/academy/image-generation)。画像モデルに必要なのは、文字数ではなく、優先順位が明確な情報密度です。
したがって、「プロフェッショナルな広告には多くの要件がある」というのは正しいですが、詳細であることは、長いことと同じではありません。高度な画像生成の6つの要素と、画像promptドクタースキルにある「形容詞でpromptを水増ししない」というルールは、同じことを述べています。
2つのステージ:素材をテキストモデルへ、prompt を画像モデルへ
画像生成タスクの背景に実際に32Kもの素材がある場合、それは通常、ブランドブック、パッケージ仕様書、広告ブリーフ、またはキャラクター設定資料です。その素材はまずテキストモデルに渡す必要があり、画像モデル向けの高密度な1つの prompt へと蒸留されます:
蒸留の出力テンプレートでは、6つの要素に加えて広告特有の3つのセクションを追加します:
1
素材をそのままテキストモデルに渡す
ブランドブック、仕様書、ブリーフ:テキストモデルのコンテキストは十分に大きいため、前処理は不要です。システム prompt で、出力テンプレート、文字数バジェット(2,500文字以下が適切な目標)、および「ハードな制約を最優先」することを明記します。
2
prompt を長さゲートに通す
長さをチェックします。中国語で10,000文字または英語で30,000文字(あるいは推定8,000 tokens)を超える場合は、テキストモデルにもう一度圧縮させます。制限を超えてもエラーは発生せず、単に誤った画像が生成されるだけであるため、このゲートをご自身で適用する必要があります。蒸留された prompt は通常1,000〜2,000文字程度であるため、このステップは安全対策(セーフガード)となります。
3
prompt を保存してから画像モデルを呼び出す
蒸留された prompt を永続化し、生成時にはそれのみを再利用します。リトライ、サイズ変更、モデル切り替えの際に、素材を再読み込みしたり、その分の tokens を再度支払ったりすることはありません。
4
素材が変更された場合はステージ1のみを再実行する
パッケージのデザイン変更やブリーフの更新時は、再度蒸留を行います。生成コードやパラメータは一切変更しません。
長い prompt が真に必要な場合
prompt が長くなるケースもいくつか存在しますが、どれも32Kには到底達しません。- 複数画像の編集: 参照画像を「image 1 / image 2 / image 3」のように参照し、それぞれから何を取り入れるかを指示します。数百文字程度です。
- 画像内のテキスト: 看板、ポスター、パッケージの文言などはモデル任せにせず、そのまま正確に指定する必要があります。数十〜数百文字程度です。
- シリーズ共通のプレフィックス: 一連の生成で共通するスタイル、照明、構図のブロックです。1,000文字未満です。
クイックリファレンス
- 実効制限は8,192 tokens(実測値)です: これを超えるとプロバイダーはエラーを返さず、prompt全体を暗黙的に無視します。ドキュメントに記載されている32,000文字は英語の場合ほぼ同等ですが、中国語では約11,000文字で制限に達します。APIYIの公式リレーがこれを狭めることはありません。
- 文字数、tokens、コンテキストウィンドウはそれぞれ異なります: 英語の32K文字は約8K tokensに相当しますが、中国語ではそれ以上になります。テキストモデルのコンテキストウィンドウは、画像モデルのprompt制限とは無関係です。
- Webアプリ上の「無制限」は錯覚です: チャットモデルが素材を読み込み、画像ツール向けに独自の短いpromptを作成しているため、画像モデルが直接32K文字を受け取ることはありません。
- 詳細であることと長いことは異なります: テキスト入力はtoken単位で課金され、再試行するたびに再度コストが発生します。また、競合する無数の要件によって重要な制約条件が埋もれてしまいます。
- 2段階のアプローチ: テキストモデルを使用して素材を1K〜3K文字の構造化されたpromptに要約し、重要な制約条件を先頭に置いて保存した上で、生成時にはそのpromptのみを渡すようにします。