01
シードは比較に役立ちますが、同一画像を保証しません
シード対応モデルでは、プロンプト、モデル版、サイズ、参照画像と一緒に保存します。同じシードでも結果が変わる endpoint があります。
画像 API ソリューション
モデルが実際に公開している操作で画像を作る。
画像エンドポイントはそれぞれ独自のフィールドを宣言します。ネガティブプロンプトを取るもの、seed を取るもの、一度に四枚返すもの。汎用フォームは、結果を再現可能にする操作をちょうど隠してしまいます。
解決する課題
汎用フォームは肝心な操作を失わせる
「プロンプトを入れれば画像が出る」は十秒しかもちません。次に必要なのは同じキャラクターの二枚目、正方形ではなく 3:2、一度に四枚の候補、そして書き留められる seed です。
02
サイズは既定値ではなくフィールドです
resolution や aspect_ratio を取るエンドポイントもあれば、ピクセル指定の width と height を取るものもあります。間違えれば 400 ですし、メガピクセル課金のエンドポイントでは選んだサイズがそのまま価格です。
03
一回の呼び出しで複数枚返ることがあります
num_outputs があるエンドポイントでは、課金はリクエスト数ではなく枚数に従います。既定 4 は既定 1 の四倍で、その差が送信前に見えるのは見積もりだけです。
実装方針
スキーマを読み、フィールドを残し、seed を記録する
入力は endpoint のスキーマに従って作成します。リクエスト、参照画像の順序、モデル版を結果と一緒に保存し、後の変更を比較できるようにします。元画像を保管してください。再生成は保証されません。
画像タスクは動画と同じ「作成して追跡」の契約です。違いはすべて input の中にあります。
POST /api/v1/jobs/createTask
POST /api/v1/jobs/createTask
Authorization: Bearer $SPICY_API_KEY
Idempotency-Key: 7b1f0c2e-9a4d-4f31-8c67-2b5e0d9a1c44
Content-Type: application/json
{
"model": "<publisher>/<model>/text-to-image",
"input": {
"prompt": "A ceramic teapot on linen, soft window light, muted palette",
"aspect_ratio": "3:2",
"num_outputs": 2,
"seed": 1337
}
}GET /api/v1/jobs/recordInfo?taskId=…
{
"code": 200,
"msg": "success",
"request_id": "req_example_record",
"data": {
"taskId": "job_01k3m8x9q2z4v7n5p6r8s0t1w3",
"state": "succeeded",
"output": {
"assets": [
{
"mime": "image/png",
"url": "https://…/result.png?X-Amz-Signature=…",
"expiresAt": "2026-09-12T12:20:08Z"
}
]
},
"cost": "0.040000",
"settled": true
}
}契約
先に押さえておく項目
| フィールド / ヘッダー | 値・上限 |
|---|---|
| input | additionalProperties: false |
| seed · num_outputs · aspect_ratio | declared per endpoint |
| cost + settled: false | hold · final charge never exceeds it |
| errorCode | 9 stable values, content_rejected included |
横にスワイプして全項目を確認できます。
導入
最初の呼び出しから本番まで
- 01エンドポイントのモデルページを開き、seed、negative_prompt、num_outputs、サイズ系のどれが宣言されているか確認します。
- 02本文は input_schema から組みます。additionalProperties は閉じているため、未宣言のキーは無視ではなく 400 です。
- 03見積もり、Idempotency-Key 付きで送信、taskId と seed と解決済みの model 値を結果の隣に保存します。
- 04コールバックまたは recordInfo から output.assets を取得し、自社バケットへ複製します。
向き不向き
この方法が向いている場面
こんなときに選ぶ
- テキストから生成していて、複数の提供元をひとつのリクエスト形状、ひとつの残高、ひとつの請求で扱いたい。
- 保存したリクエストとモデル版を使い、条件をそろえて変更を比較したい場合。
こんなときは別の方法へ
- ユーザーが手持ちの写真から始める場合。編集は独自の参照契約を持つ別タスクです。
- 全モデルで単一のハウススタイルを揃えたい場合。スタイルはこの層ではなくモデルの中にあります。
裏付け
自分で確認できること
試用のリクエストが本番のリクエストです
モデルページで組み立てた本文が、サーバーから送る本文そのものです。同じフィールド、同じ検証、同じ見積もり。あとで食い違う簡易プレビューはありません。
未宣言のフィールドは明確に失敗します
入力は additionalProperties を閉じたエンドポイントのスキーマで検証されます。宣言のないパラメータは黙殺されず、安定した errorCode 付きの 400 になります。
出力はプラットフォームのストレージから配信されます
結果は key、MIME タイプ、署名付き url、expiresAt を持つ output.assets として返ります。実行された場所へ直接リンクすることはありません。
公開前に
確認しておくプラットフォームの挙動
- seed をどこに保存するかを公開前に決めます。残していない seed に価値はありません。
- 新しいキーに必須の日次上限を設定し、必要に応じて月次と累計の上限も加えます。
- content_rejected を含む閉じた errorCode 集合を、通常のプロダクト状態として扱います。
- 14 日の保持期間内に成果物を自社ストレージへミラーします。
よくある質問
このページでよく聞かれること
元の入力、モデル版、対応していればシードを再利用します。ただしピクセル単位の一致は保証されません。同じ画像が必要なら元の出力をダウンロードして保管してください。
num_outputs を宣言したエンドポイントなら可能で、課金は枚数に比例します。送るつもりの枚数での金額は、本文を見積もれば分かります。
エンドポイントが宣言したものだけです。resolution、aspect_ratio、あるいは width と height。選択肢はモデルページに列挙され、範囲外の値はタスク作成前に拒否されます。
プラットフォームは追加しません。振る舞いは選んだモデルによります。モデルが拒否した場合は errorCode content_rejected を持つ通常の終端タスクとして返ります。
モデル
この用途で呼び出せるモデル
各リンクはそのモデルシリーズのページに移動します。入力、上限、コンテンツ方針、単位あたりの現在価格をそこで確認できます。
次に
画像エンドポイントを並べて比べる
入力、サイズと seed の操作、出力枚数、一枚あたりの価格で画像エンドポイントを比較し、試した通りのリクエストをそのまま使います。