GPT-Image-2.6のmarkupで画像の一部だけ直す方法

「写真の看板の文字だけを直したいのに、頼むと背景まで変わってしまう」「どこを直してほしいのか、文章だけでは伝わらない」——画像生成のAPIで写真を直そうとした人の多くが、この壁に当たります。

結論から言うと、2026年11月4日に OpenAI が出した GPT-Image-2.6 の API では、markup（書き込みを描いた透明のPNG）を渡して「ここを直して」と絵で指示できるようになりました。直す場所は丸や矢印で示し、どう直すかは prompt に書く、という分担です。あわせて、画像を描く前にどれだけ考えるかを決める complexity という設定も加わっています。

株式会社Fyveは、記事のサムネイルや資料の画像を毎日自動で作る仕組みを自社で運用しています。この記事では、OpenAI の開発者向けドキュメントと changelog に書かれている範囲で、markup の使い方と決まり、complexity の選び方を手順にしてお伝えします。手元ではまだ 2.6 で画像を作っていないので、「試したらこう出た」という話はしません。

GPT-Image-2.6 の markup とは：直す場所を絵で指す編集

markup は、POST /v1/images/edits（画像の編集のAPI）に渡す追加の画像です。元の写真と同じ縦横の透明なPNGに、直したい所を丸で囲んだり矢印を描いたりして送ります。モデルはその書き込みを「どこを直すか」の指示として読み、prompt に書いた「どう直すか」に従って1枚目の画像を直します。

開発者ガイドの手順は、要約すると次の4つです（2026年11月6日時点）。

1. 元の写真を、入力画像の1枚目にする
2. 透明なPNGの書き込みのレイヤーを作る。向きをそろえた後で、1枚目の画像と同じ幅と高さにする。透明な画素を含めること、元の写真に重ねて1枚に焼き込まないこと
3. それを markup として送る
4. prompt に「何をどう直すか」と「そのまま残したいもの」を書き、出てきた結果を確かめてから使う

ガイドの例は、台所の写真で花瓶を赤い丸で囲み、「赤い丸の中の縞模様の花瓶を、無地のコバルトブルーの陶器に塗り替える。形と枯れた茎、台所のほかの部分は変えない。仕上がった写真から赤い丸は消す」という趣旨の prompt を送るものです。直す内容・残すもの・書き込みを消すことの3つを prompt に書いている点が、そのまま真似できる型になっています。

なお changelog には「Added markup-guided editing for supported GPT Image 2.5 and 2.6 models.」とあり、markup は 2.6 だけでなく対応する GPT Image 2.5 のモデルでも使えると書かれています。2.6 に乗り換えなくても試せる、ということです。

2026年11月4日に出たもの：Sunburst と Flare の2モデル

OpenAI の開発者向け changelog の 11月4日の項には、「Released GPT-Image-2.6 Sunburst and GPT-Image-2.6 Flare for image generation and editing with adjustable complexity, SVG generation, and animated GIF generation.」とあります。モデルは2つで、どちらも画像の生成（v1/images/generations）と編集（v1/images/edits）で使えます。

料金は2026年11月6日時点で各モデルのページに出ていた値（米ドル）です。キャッシュされた入力はテキスト $1.25、画像 $2 でした。導入の判断に使うときは、必ず公式の料金ページでその時点の値を確かめてください。

この数字は、私たちが9月に調べた GPT-Image-2.5 の Flare / Sunburst と同じです。ガイドには「Markup-guided edits use the same token rates as other edits, with no extra fee.」ともあり、markup を使う編集に追加の料金はかかりません。ただし同じガイドが「Equal token rates don't mean equal cost per image」と念を押しているとおり、単価が同じでも1枚あたりの費用が同じとは限りません。消費するトークンの数がモデルと品質の設定で変わるからです。

単価と1枚あたりの費用の違いは、2.5 のときに詳しく書きました。

AI業務効率化GPT-Image-2.5の料金｜単価が同じでも費用は違う

もう1つ気をつけたいのは、2.6 のモデルページで Responses API が「対応なし」になっている点です。ガイドにある Responses API の画像の例は、2026年11月6日時点では 2.5 のモデル名で書かれています。チャットの流れの中で画像を直す作りにしている場合、2.6 と markup を使うには Image API を直接呼ぶ形に寄せる必要があります。

文章だけ・mask・markup の違い

画像の一部を直す方法は、これまで大きく2つでした。prompt の文章だけで頼む方法と、mask（直してよい範囲を透明にした画像）を渡す方法です。markup はその間に入る3つ目の方法です。

文章だけで頼むと、「左上の看板の文字を…」のように場所も言葉で説明することになります。写真に似たものが複数あると、どれのことかが伝わらず、関係ない所まで変わりやすくなります。

mask は、直してよい範囲を塗って示す方法です。ガイドでは、画像と mask は同じ形式と大きさで、50MB 未満、mask にはアルファチャンネル（透明度の情報）が必要とされています。一方で「masking is entirely prompt-based」、つまり mask も最後は prompt として扱われ、モデルが塗った形をそのとおりに守るとは限らない、とも書かれています。

markup は、範囲を塗りつぶすのではなく、丸・矢印・短い書き込みで「ここ」と指します。写真の上に赤ペンで印を付けて人に渡すのと同じ感覚です。

mask と markup は併用できません。ガイドに「Do not combine markup with mask or prompt_rewriter.」とあり、APIリファレンスの markup の説明にも「Cannot be combined with mask.」と書かれています。どちらで直すかは、1回の依頼ごとに決めることになります。

手順1：書き込みのPNGを作る

いちばん間違えやすいのが、書き込みのPNGの作り方です。決まりは3つあります。

• 元の写真と同じ幅と高さにする。ガイドは「After orientation」、つまり向きをそろえた後の大きさで比べるとしています。スマホの写真は、ファイルの中の向きの情報（EXIF）で縦横が入れ替わって表示されることがあるので、先に向きを反映させてから大きさをそろえます
• 透明な画素を含める。背景を白で塗りつぶしたPNGは書き込みのレイヤーになりません
• 元の写真に焼き込まない。赤丸を描いた写真を1枚だけ送るのではなく、写真と書き込みを別々のファイルで送ります

画像編集ソフトでレイヤーを分けて書き出してもよいですし、決まった位置に印を付けるならスクリプトで作るほうが確実です。次の Python のコード（Pillow という画像処理のライブラリを使います）は、写真の向きをそろえてから同じ大きさの透明なキャンバスを作り、右上寄りの範囲に赤い丸を描いて保存します。

from PIL import Image, ImageDraw, ImageOps

# 元の写真を開き、スマホ写真の向き（EXIF）を先に反映しておく
photo = ImageOps.exif_transpose(Image.open("photo.jpg"))
w, h = photo.size

# 同じ縦横の、完全に透明なキャンバスを作る
layer = Image.new("RGBA", (w, h), (0, 0, 0, 0))
draw = ImageDraw.Draw(layer)

# 直したい場所を赤い丸で囲む（座標は左上・右下）
box = (int(w * 0.55), int(h * 0.20), int(w * 0.85), int(h * 0.55))
draw.ellipse(box, outline=(255, 0, 0, 255), width=max(6, w // 150))

layer.save("markup.png")

私たちの手元で、1600×1200 の画像を相手にこのコードを動かし、同じ 1600×1200 で RGBA（透明度つき）のPNGができること、透明な画素と不透明な画素の両方が含まれることを確かめました。API に送る前に、この2点を機械で確かめておくと、大きさの食い違いで弾かれる手戻りが減ります。

向きの扱いで1つ注意があります。上のコードは書き込みの大きさを「向きを反映した後の写真」に合わせています。API に送る写真も、同じく向きを反映したものを書き出して送ると、両者の縦横が確実にそろいます。

手順2：/v1/images/edits に写真と markup を送る

送り方は2通りあります。ファイルをそのまま添付する multipart 形式と、JSON 形式です。

multipart 形式では、写真を image[]、書き込みを markup として添付します。ガイドの cURL の例は -F 'markup=@...;type=image/png' の形で書き込みを添付し、モデルに gpt-image-2.6-flare、品質に medium を指定していました。同じ形で書くと、次のようになります。

curl -s https://api.openai.com/v1/images/edits \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -F "model=gpt-image-2.6-flare" \
  -F "image[]=@photo.jpg" \
  -F "markup=@markup.png;type=image/png" \
  -F "quality=medium" \
  -F "prompt=赤い丸の中の看板の文字を「本日休業」から「営業中」に直してください。看板の形・色・書体と、写真のほかの部分は変えないでください。仕上がった画像から赤い丸は消してください。"

JSON 形式では、入力画像を images という配列で渡し、markup には image_url か file_id のどちらか1つだけを持つオブジェクトを渡します。APIリファレンスでは、markup は「file ID, HTTPS URL, or base64 data URL」で指定できる、とされています。すでにファイルを OpenAI にアップロードしてあるなら file_id、手元のファイルなら base64 の data URL を image_url に入れる形です。

返ってくる画像は、これまでの編集と同じく base64 で返ります。ガイドの例も、応答を base64 から戻してファイルに書き出しています。

2枚目以降の画像の扱いも覚えておきたい点です。ガイドには「Markup applies to the first input image. Additional images serve as references.」とあります。書き込みが効くのは1枚目だけで、2枚目以降は「この色に合わせて」「この商品の形で」のような参考の画像として扱われます。直したい写真は必ず1枚目に置きます。

手順3：決まりを先に確かめる

送る前に確かめておきたい決まりを、ガイドとAPIリファレンスから1つの表にまとめます（2026年11月6日時点）。

16,777,216 は 4096×4096 と同じ数です。スマホで撮った高画素の写真は、そのままだとこれを超えることがあるので、送る前に縮めておきます。縮めたら書き込みのPNGも同じ大きさで作り直すのを忘れないでください。順番を「写真を縮める → その大きさで書き込みを作る」に固定しておくと、食い違いが起きません。

prompt の書き方：直す内容・残すもの・印を消すこと

markup で場所を指せるようになっても、prompt の役目は残ります。ガイドは「Describe the requested change and the details you want to preserve.」、つまり直す内容と残したい細部を書くように求めています。

ガイドの例から読み取れる型は、次の3つの文に分けることです。

1. 直す内容：「赤い丸の中の◯◯を、△△に変える」。書き込みの色や形を名指しして、どの印の話かをはっきりさせる
2. 残すもの：「形・質感・周りの部分は変えない」。変えてほしくないものを具体的に並べる
3. 印を消すこと：「仕上がりから赤い丸は消す」。書き込みが完成品に残らないようにする

3つ目は見落としやすい一文です。書き込みは「指示」ですが、モデルにとっては画像の一部にも見えます。ガイドの例がわざわざ「赤い丸を消す」と書いているのは、そのためだと読めます。

書き込みを複数入れる場合は、色を分けて prompt でも呼び分けるのが分かりやすい方法です。たとえば「赤い丸の中は文字を直す」「青い矢印の先の影は消す」のように、印と指示を1対1にします。ただし、複数の書き込みをどこまで正確に読み分けるかはガイドに書かれておらず、私たちもまだ試していません。最初は1枚に1か所から始めるのが無難です。

ガイドの「Limitations」には「the model can still struggle with precise text placement and clarity」ともあります。文字の位置や読みやすさはまだ苦手、ということです。看板やチラシの文字を直す使い方は、markup で場所を絞れても、出てきた画像の文字を人の目で確かめる工程を外さないでください。ガイドの手順の最後にある「結果を確かめてから使う」は、ここで効いてきます。

complexity の選び方：描く前にどれだけ考えるか

2.6 で加わったもう1つの設定が complexity です。APIリファレンスは「Computation spent planning the image, independently of rendering quality.」と説明しています。画像を描く前の計画にどれだけ計算を使うかを決める設定で、描画の品質（quality）とは別のつまみです。

• 値は low・medium・high の3つ
• 省略すると、Sunburst も Flare も high
• 「Adjusting complexity has no separate fee.」——complexity を変えること自体に別の料金はかからない
• 高くすると時間がかかることがあり、意図しない変更が入ることもある。だから自分の用途で結果を比べるように、とガイドは書いています

ここで覚えておきたいのは、省略すると一番高い high になることです。何も考えずに 2.6 に切り替えると、常に high で描いていることになります。写真の一部を直すだけの依頼で、余計な所まで変わる・時間がかかると感じたら、まず complexity を下げて比べる、という順番で試すのが筋です。

逆に、何も無いところから構図ごと作る依頼（ポスターの全体や、要素の多い図）では、high のまま計画に時間を使わせるほうが向いている可能性があります。ガイドには、同じ題材を low・medium・high で描き分けた例が載っています。

quality との関係も整理しておきます。quality は描画の細かさで、2.5 のモデルでは xhigh と max も選べるとAPIリファレンスにあります（2.6 で選べるかは、私たちが読んだ範囲では書かれていませんでした）。ガイドには「Use quality: "low" for quick drafts.」ともあり、下書きは quality を下げて回し、決まった構図だけを上げて描く、という使い分けがしやすくなっています。

この表は、ガイドの説明から私たちが組んだ「最初に試す順番」です。どの組み合わせが一番よいかは画像の中身で変わるので、決め打ちにせず、同じ prompt で2〜3通り出して比べてください。

SVG と動くGIF：ガイドに書かれていること

changelog には SVG の生成と動くGIFの生成も挙がっています。ガイドで確認できたのは、次の範囲です（2026年11月6日時点）。

• SVG の出力は、ストリーミング・途中経過の画像・output_compression・prompt_rewriter に対応しない。返ってくるのは静的なベクターの内容で、スクリプトや外部の資源は含まない
• GIF の出力も、ストリーミング・途中経過の画像・output_compression の指定・prompt_rewriter に対応しない。コマ数・コマの大きさ・アニメーションの数は、モデルの大きさの上限に収まる必要がある
• APIリファレンスでは、output_format に gif を指定でき、frame_count・frame_duration_ms という項目も載っている

SVG をどう頼むか（どの項目に何を入れるか）は、私たちが読んだ範囲でははっきりしませんでした。ロゴやアイコンをSVGで作りたい場合は、ガイドの該当の節とAPIリファレンスを読んでから組み込んでください。ここは推測で手順を書かないでおきます。

自社の運用で：画像を作る係を1か所に寄せておく

新しい画像モデルが出た日に私たちが最初に考えるのは、「どこを直せば切り替えられるか」です。

私たちの仕組みでは、画像を作る処理を1本のスクリプト（画像を作る係）にまとめています。記事のサムネイル、資料の挿絵、LPの画像など、画像を使う作業の手順書は15本ありますが、どれも「プロンプト・出力先・品質・大きさ」を渡してこの係を呼ぶだけで、自分では画像のAPIを呼びません。

これが効いたのが2026年9月9日でした。係が使っていたモデルの名前が廃止になり、呼ぶと 404 のエラーが返るようになりました。放っておけば15本の作業の画像が全部止まるところでしたが、直したのは係の既定のモデル名の1行だけで済みました。

係の側では、返し方も決めています。成功したら OK: <出力パス> を1行で返す。画像生成が使えないときは終了コード2で止まり、AIが勝手に別の方法で代わりの絵を合成しないようにする。呼ぶ側はこの返事だけを見て成否を判断します。

GPT-Image-2.6 と markup を取り入れるときも、この形なら手を入れるのは係の中だけです。たとえば次の順番で進めるつもりです。

1. 係に「写真＋書き込み」を受け取る口を足す。書き込みの大きさが写真と一致するか、透明な画素があるかを、APIに送る前に係の中で確かめる
2. モデル名と complexity を係の引数にして、既定は今のまま変えない
3. 同じ依頼を、今のモデルと 2.6 の Flare・Sunburst で出し比べ、仕上がりと時間を見てから既定を切り替える

大事なのは3つ目です。省略時の complexity が high であること、料金の単価が同じでも1枚あたりの費用は変わりうることを考えると、「新しいから切り替える」ではなく、同じ依頼で比べてから決めるほうが安全です。戻すときも係の1行で戻せます。

外のサービスに頼る処理を、呼ぶ側に散らさず1か所に寄せ、成功と失敗の返し方をそこで決めておく。画像に限らず、AIのモデルは数か月ごとに名前が変わるので、この寄せ方が一番手戻りを減らしてくれました。

APIの従量課金とサブスクの利用枠のどちらで画像を作るかの考え方は、こちらにまとめています。

AI業務効率化画像生成のコスト｜API従量課金とサブスク枠の使い分け

まだ確かめられていないこと

2026年11月6日時点で、公式の文書で確かめられなかったことも書いておきます。

• 速さ：「前より速い」という話はSNSに出ていますが、私たちが読めた開発者向けの文書には数字がありませんでした。ガイドには、複雑な prompt は処理に最大2分かかることがある、とだけ書かれています
• ChatGPT や Codex で使えるか：開発者の changelog は API の話で、ChatGPT や Codex の画像生成が 2.6 になったかは、私たちが読めた文書には書かれていませんでした。OpenAI の発表ページは私たちの環境からは開けませんでした
• 1枚あたりの費用：単価はモデルページに出ていますが、1枚で何トークン使うかの表は 2.6 向けのものを見つけられませんでした

なお、markup という項目は 11月4日より前に公開のAPI仕様に現れていた、と海外の技術ブログが報じています。ただ、正式に使えると書かれたのは 11月4日の changelog です。

出てきた画像の大きさが指定どおりにならないときの直し方は、こちらで扱っています。

AI業務効率化AI画像のサイズが指定通りにならない原因と直し方

よくある質問

Q1. markup は GPT-Image-2.6 でしか使えませんか？

いいえ。changelog には「supported GPT Image 2.5 and 2.6 models」とあり、対応する 2.5 のモデルでも使えると書かれています。いま 2.5 で動いている仕組みなら、モデルを変えずに markup だけを試すこともできます。

Q2. 写真に赤丸を描いて1枚で送ってはいけませんか？

ガイドは、書き込みを元の写真に重ねて1枚にしないように、と明記しています。写真と書き込みは別のファイルで送り、写真は入力画像の1枚目に置きます。

Q3. mask と markup はどちらを使えばいいですか？

範囲がはっきりしていて「この形の中を入れ替えたい」なら mask、「この物だけ」「この文字だけ」を指したいなら markup が向いています。ただし同じ依頼で両方は使えません。

Q4. complexity を上げると料金は上がりますか？

ガイドには「Adjusting complexity has no separate fee.」とあり、complexity を変えること自体に別の料金はかかりません。ただし時間がかかることがあり、省略すると high になる点は覚えておいてください。

Q5. Responses API から 2.6 を使えますか？

2026年11月6日時点のモデルページでは、Sunburst・Flare とも Responses API と Chat Completions は「対応なし」です。使えるのは Image API の生成と編集です。

まとめ：場所は絵で、直し方は文章で

• GPT-Image-2.6（2026年11月4日）は Sunburst（細かい絵）と Flare（速く試す）の2モデル。Image API の生成と編集で使える
• markup は、元の写真と同じ大きさの透明なPNGに印を描いて送り、直す場所を指す編集。2.5 の対応モデルでも使える
• 書き込みは写真に焼き込まない。1枚目と書き込みはそれぞれ 16,777,216 ピクセルまで、書き込みは 50MB まで。mask・prompt_rewriter とは併用できない
• prompt には「直す内容・残すもの・印を消すこと」の3つを書く
• complexity は low・medium・high。省略すると high。追加の料金はないが、時間と余計な変更が増えることがある
• 切り替えは、同じ依頼で今のモデルと出し比べてから。画像を作る処理を1か所に寄せておくと、試すのも戻すのも1か所で済む

株式会社Fyveでは、こうした新しいモデルを自社の仕組みに入れるとき、まず「どこを直せば切り替えられるか」から考えています。画像の自動生成を業務に組み込む際の参考になれば幸いです。