GPT-6 Sol・Lunaの画像認識修正後、何を再テストすべきか
9月25日の画像エンコード修正を受け、スクリーンショット・OCR・グラフを同じ条件で再評価する手順と、比較できる範囲を整理します。
2026年9月25日、OpenAIはGPT-6 SolとGPT-6 Lunaの画像理解を低下させていた画像エンコードの不具合を修正しました。以前スクリーンショットや文書画像、画面操作で失敗した場合は、その結果だけでモデルの限界と判断せず、同じ課題を再実行する価値があります。公式API変更履歴によると、修正対象にはAPIとCodexの視覚タスク、およびcomputer useが含まれます。
これは画像を使う評価を見直す理由です。すべてのコーディング上の問題が解決した証拠ではありません。本記事は再現可能な再テスト手順を示すもので、Ofoxによるベンチマークや修正前後の改善率を報告するものではありません。
発表から分かること、分からないこと
| 確認項目 | 発表で確認できる範囲 |
|---|---|
| 対象モデル | GPT-6 Sol、GPT-6 Luna |
| 修正内容 | 画像理解を低下させていた画像エンコードの不具合 |
| 対象環境 | APIとCodexの視覚タスク。computer useを含む |
| 改善率 | 引用した発表には記載なし |
| 各社の中継ルートへの同時反映 | この発表だけでは確認できない |
評価記録にはモデル名だけでなく、プロバイダーのルート、実行時刻、画像の前処理、プロンプト、推論設定、ツールも残します。ゲートウェイが画像を変換している場合、残る失敗の原因はモデルではなく、その変換にあるかもしれません。
一般的なタスク選びにはSolのeffort設定ガイドを参照してください。今回の画像処理の不具合とは分けて判断します。
正解を確認できる小さなテストセットを作る
実際の業務に必要な画像を選び、送信権限を確認して個人情報を取り除きます。メッセージアプリで何度も再保存するのではなく、元のファイルを保持してください。
| テスト | 質問例 | 検証できる結果 |
|---|---|---|
| 画面の読み取り | 無効になっている操作はどれか | 正確なラベルと表示状態 |
| 文書OCR | 請求書番号は何か | 先頭のゼロを含む正確な文字列 |
| グラフの読み取り | 最後の点で最も高い系列はどれか | 系列名と位置。読めない場合は不確実性を示す |
| 画面上の位置特定 | 指定したボタンはどこか | 同じ画像上で照合できる位置 |
これはテスト素材の提案であり、実施済みの結果ではありません。必要なタスクごとに簡単な画像と難しい画像を含めます。ぼけや切り欠けがある場合は「判読不能」も許容します。推測した値を埋めることは抽出の成功ではありません。
実行前に正解と許容範囲を決めます。OCRでは空白や句読点を評価に含めるか、グラフでは厳密な数値と軸からの概算をどう区別するかを明記します。画面操作では認識だけを評価するのか、その後のツール操作まで含めるのかも決めておきます。
条件をそろえて再実行する
- 実行時刻、正確なモデルID、接続先を記録します。Codexではクライアント版、選択モデル、effort、関連ツール設定も記録します。
- 画像のバイト列、順序、質問、回答形式を固定し、各入力ファイルのSHA-256を保存します。
- 比較するモデル間で設定をそろえます。片方で未対応のパラメーターは、黙って省略せず差分を記録します。
- ばらつきが判断に影響する場合は複数回実行し、失敗や拒否を含むすべての回答を保存します。
- 事前に決めた基準で採点します。正確性と応答時間、報告された使用量は別項目にします。
修正前の実測結果が保存されていなければ、改善率を主張できません。新しい表には「修正後の評価」と記し、取得した結果だけを比較します。以前の誤答を記憶から再構成しても基準値にはなりません。
記録用CSVには、例えば次の列を使えます。
run_time_utc,provider,model,client_version,effort,image_sha256,case_id,expected,actual,correct,latency_ms,request_id
これは記録形式の提案であり、APIの応答スキーマではありません。APIキーや非公開画像URLは記載せず、元の応答は評価担当者だけがアクセスできる場所に別途保存します。
まだ画像を正しく読めない場合
プロバイダーを変える前に、実際にAPIへ送信したファイルを開き、解像度や小さなラベルの可読性を確認します。リクエストに画像パートがあり、ローカルファイル名をテキストで伝えただけになっていないかも確認してください。URL入力では、ブラウザーのログイン状態なしでプロバイダーが画像を取得できる必要があります。
次に認識と操作を分けます。クリックさせる前に、対象と表示状態を説明させてください。正しく説明した後のクリック失敗と、説明自体の誤りは別の問題です。抽出処理では、アプリが回答全体を解析しているか、必要なフィールドを捨てていないかも確認します。
最後に、対応する画像入力形式と実際の送信リクエストを照合します。テキストだけの呼び出し成功は、画像入力の成功を保証しません。直接OpenAIに接続する場合は公式の画像・視覚ガイド、中継する場合はそのプロバイダーの仕様を参照します。
このタスクで使い続けるかを決める
判断するのは、この構成が自分の画像や文書の受け入れ基準を満たすかどうかです。鮮明なグラフを一つ読めても、アプリ全体で安定した画面操作ができるとは限りません。
費用も比較するなら、画像ファイルサイズからトークン数を決めつけず、使用量と実際のルートを記録します。SolのAPI費用ガイドでは入力・出力・キャッシュを分ける理由を説明しています。この手順では新しい価格や割引を前提にしていません。
よくある質問
- 修正によってSolやLunaがAstraより画像に強いといえますか?
- いいえ。発表は不具合とその修正を示したもので、Astraとの比較試験ではありません。比較するなら画像、採点基準、設定をそろえて記録します。
- テキストだけのコーディング評価もやり直すべきですか?
- 今回の変更は画像理解に関するものです。視覚上の不具合が修正されたという理由だけで、テキストのみの評価が無効になるわけではありません。別の関連変更や評価上の問題がある場合に再実行します。
- 新しい結果を改善率として示せますか?
- 有効な過去の測定と定義済みの指標がある場合に限ります。修正前の基準値がなければ、修正後の結果として報告してください。


