OpenAI が GPT-6 Sol / Luna の画像エンコーディング不具合を修正 — 公開から3日間、画像理解が劣化していた。公式は評価の再実行を推奨

要約

OpenAI API の changelog に 2026-09-25 付で1件が追加されました。エントリのタグは Fix · Model: gpt-6-sol · Model: gpt-6-luna です。

公式本文は2段落だけで、全文がこれです。

Fixed a bug in image encoding that degraded image understanding in GPT-6 Sol and GPT-6 Luna. This update improves results on visual tasks in the API and Codex, including computer use.

If your use cases involve image inputs, we recommend rerunning your evaluations and retrying workflows affected by the issue.

短い。ただ、時系列を重ねると意味が変わります。

GPT-6 Sol と GPT-6 Luna が公開されたのは 2026-09-22 です。 Responses API と Chat Completions 経由で、テキストと画像入力に対応する推論モデルとして発表されました。価格は Sol が入力 $2 / 出力 $10（100万トークンあたり）、Luna が入力 $0.10 / 出力 $0.50 で、Luna は高volumeの処理を安く回すための選択肢として位置づけられています。

その 09-22 から 09-25 まで、つまり公開から3日間、画像理解が本来より劣化した状態で提供されていたということになります。

影響範囲は API だけではありません。 公式は「in the API and Codex, including computer use」と書いています。Codex 側でも、画面や画像を扱う処理が影響を受けていたわけです。computer use は画面を見て操作する機能なので、画像理解の劣化は動作の質に直結します。

そして、公式が求めているのは利用者側での再実行です。

「画像入力を使うユースケースなら、評価を再実行し、この問題の影響を受けたワークフローを再試行することを推奨する」。修正の適用だけで完結しない、という書き方です。

ここが実務上の要点になります。 公開直後に Sol / Luna を画像タスクで評価し、期待を下回ったので採用を見送った——という判断をした組織は少なくないはずです。新モデルが出たら試すのは普通の動きで、09-22 から 09-25 はまさにその「試す」期間でした。その評価結果は、モデルの実力ではなく不具合を測っていた可能性があります。

一方で、公式は改善幅を数値で出していません。

「degraded image understanding」という定性的な記述だけです。どのベンチマークがどれだけ動いたか、劣化がどの程度だったか、影響が全リクエストに及んだのか一部だったのか——いずれも書かれていません。したがって 「どれだけ良くなったか」を公式値で語ることはできず、各自の再評価で確かめるしかない構造になっています。

不具合の技術的な内容も公開されていません。 「画像エンコーディングのバグ」という粒度です。自社側の前処理（解像度、フォーマット、圧縮率など）との相互作用があったのかどうかも判断できないため、「自社の使い方では影響が小さかった」と推測で結論するのは避けた方がよい領域です。

何が変わったか

• 2026-09-25、OpenAI API changelog に Fix · Model: gpt-6-sol · Model: gpt-6-luna のエントリが追加
• GPT-6 Sol / GPT-6 Luna の画像理解を劣化させていた画像エンコーディングの不具合を修正
• 改善は API と Codex の両方の visual task に及び、computer use を含む
• 公式は、画像入力を使うユースケースでの「評価の再実行」と「影響を受けたワークフローの再試行」を推奨
• Sol / Luna の公開は 2026-09-22 → 公開から3日間、画像理解が本来より劣った状態だった
• 改善幅・劣化の程度・影響範囲の内訳について、公式は数値を出していない（定性的な記述のみ）
• 不具合の技術的内容も非公開。自社の画像前処理との相互作用は判断できない
• 呼び出し方の変更は不要（モデル側の修正）

業務インパクト（一般企業向け）

このエントリの実務的な価値は、修正そのものではなく「評価の有効期限」という論点にあります。

まず、直接の宿題です。 GPT-6 Sol または Luna を画像入力込みで評価した組織は、その評価が 09-22 から 09-25 の間に行われたなら、結論を保留に戻す必要があります。「Sol は画像が弱いから Astra を使う」「Luna は安いが画像は任せられない」といった判断は、不具合下での測定に基づいている可能性があります。

ここで効いてくるのが、評価ログに日付とモデルバージョンが残っているかどうかです。残っていなければ、どの評価を再実行すべきか特定できません。結果として「全部やり直すか、放置するか」の二択になり、実際には放置されます。

そこで、この事案から取り出せる恒久的な手当ては次の1点です。モデル評価の記録に「実施日」を必須項目として入れる。

具体的には、評価レポートに (1) 実施日時、(2) モデル ID とバージョン表記、(3) 入力の種別（テキストのみ／画像込み／ツール利用あり）、(4) 判断（採用・見送り・条件付き） を揃えておく。これだけで、ベンダー側の修正告知が出たときに再評価の対象を機械的に絞れます。今回のように「画像入力を使っているものだけ」という条件が出る以上、入力種別を記録していないと絞り込みができません。

2点目は、モデル公開直後の評価を「暫定」として扱う運用です。

今回の構図——公開から3日で画像処理のバグが修正された——は、モデル公開直後の数日がまだ安定していない期間であることを示しています。これは珍しいことではなく、大型モデルの公開直後には配信側の設定やエンコーディング周りの調整が入ります。

したがって、公開直後の評価結果で採用可否を確定させないという運用が合理的です。「初回評価は方向性の確認まで。公開から2〜4週間後に本評価」という二段構えにしておくと、今回のようなケースで手戻りが小さくなります。急ぎで判断が必要な場合も、「暫定評価である」と明記しておくだけで、後から見直す根拠になります。

3点目は、Codex と computer use を使っている場合の見直しです。

公式は影響が Codex にも及び、computer use を含むと明記しました。画面を見て操作するタイプの自動化は、画像理解の質がそのまま成功率に出ます。09-22 以降に Sol / Luna で computer use 系の自動化を試し、「まだ実用に足りない」と結論した場合、その結論も再検証の対象です。

この種の判断は、いったん「使えない」と結論が出ると、次に見直されるまで長い時間が空きます。自動化の検討が止まっている理由が実は修正済みの不具合だった、という状態は避けたいところです。

4点目、ベンダー告知の読み方として1つ。

今回の告知は changelog に2段落だけです。ブログ記事もプレスリリースもありません。「重要だが目立たない告知」の典型です。しかも openai.com と help.openai.com は本稿執筆時点で外部からのアクセスが 403 で返る状態が続いており、API changelog を見ていなければ気づけません。

情報収集の観点では、モデルを本番で使っている場合、ベンダーの API changelog を監視対象に入れるのが実務的です。製品ブログは大きな発表を出しますが、「すでに使っているものが変わった」という情報は changelog 側に出ます。そして今回のように、利用者側のアクションを求める内容が changelog の2段落に入ることがあります。

副業・個人活用視点

個人で使っている立場からは、この件は「自分の印象を疑う機会」として使えます。

新しいモデルが出た直後に触って、「画像の読み取りが思ったほどではない」と感じたことがあるなら、それは 09-22〜09-25 の不具合だった可能性があります。Luna は入力 $0.10 / 100万トークンという価格帯で、スクリーンショットや資料画像を大量に流す用途にはまさに向くモデルです。そこで一度「使えない」と判断していたなら、もう一度試す価値があります。

具体的な再試行の対象としては、画面のスクリーンショットからの情報抽出、紙資料・PDF 画像の読み取り、図表からの数値の書き起こし、UI の状態判定を伴う自動化——このあたりです。単価が安いモデルで通るなら、そのまま運用コストが下がります。

受託・案件の文脈では、この件は「見積もりの前提が動く」話です。

画像を扱う自動化を提案するとき、どのモデルで通るかによって処理単価が桁で変わります。Sol（入力 $2）と Luna（入力 $0.10）では20倍です。Luna で通るなら、月間の処理量が多い案件ほど提案の競争力が変わります。不具合下の評価で Luna を候補から落としていたなら、見積もりを作り直す余地があります。

同時に、クライアントへの説明材料としても使えます。 「AI の性能評価は時点依存で、ベンダー側の修正で結果が変わる」という事実を、公式の告知という具体例で示せます。これは「だから継続的な再評価が必要」という保守・伴走契約の根拠になります。抽象的な「AI は進化が速いので」ではなく、**「実際に公開3日後に画像処理が修正され、公式が再評価を推奨した事例がある」**と言える方が説得力があります。

発信ネタとしては、地味ですが実用度が高いテーマです。

「ベンチマークやSNSの評価が、そもそも同じものを測っていない」という話に接続できます。モデル公開直後の「速い/遅い/賢い」という評判は、配信側の状態が揃う前の観測であることが多い。今回はそれが公式の修正告知という形で裏づけられました。一次情報に戻る習慣の具体的な根拠として書けます。

書くときの注意は1点だけです。公式は改善幅を数値で出していません。 「劇的に良くなった」「別物になった」といった表現は根拠がありません。「劣化していた状態が修正された。どれだけ良くなったかは自分で測る必要がある」——ここまでが言えることの範囲です。