GPT-6 Luna と GPT-5.6 Luna を比較：計測できるアップグレード計画

Luna のワークロードで役に立つ単位は、たいてい「合格レコード」です。フィールドが正しい請求書、ラベルが正しいチケット、下流の検証を通過する変換結果などがそれに当たります。JSON としてパースできる応答でも、中身が間違っていることはあります。トークンの請求額が小さくても、その裏でリトライのキューが膨らんでいるかもしれません。

文書化されたベースラインと未検証の候補モデル

これらの事実が裏付けるのは、モデル ID と出発点となる契約です。将来の Luna が同じスキーマの挙動を保つこと、安くなること、あなたのキューを速く処理することは裏付けません。

実際のキューを反映したレコードセットを作る

出発点は、自社のワークロードの分布です。バランスの取れたテストセットとは、必ずしも各カテゴリを同数にすることではありません。ある顧客のフォーマットが処理量の大半を占めるなら、それを十分に反映させる必要があります。同時に、発生頻度は低くても、ロールアウトを止めるほどコストの高い失敗ケースも含めてください。

安定したレコード ID、入力のバージョン、期待される出力、許容される null 値、検証ルール、エスカレーションの判断を保存します。評価環境で処理する権限のない機微な内容は取り除いてください。プロンプト、スキーマ、前処理、後処理のリビジョンは、データセットと一緒に保管します。

セットは、小さな開発用の部分と、取り分けておく検証用の部分に分けます。前者は、ハーネスの明らかな不備の修正と、候補モデルのチューニングに使います。後者は、チューニングした構成が汎化するかを確かめるために使います。全レコードでチューニングしておいて、同じレコードを新規のテストとして報告すると、確信度を過大に見せることになります。

結果は、ワークロードのスライスごとにまとめてください。全体の精度が健全に見えても、特定の言語、文書テンプレート、件数の少ないラベルが不安定になっていることがあります。全体スコアは、実際に流す予定のトラフィック構成で重み付けし、重要なスライスは別途示します。

6 つの繰り返しタスクとその合格ルール

スキーマの妥当性と、意味的な正しさは分けて扱います。たとえば請求書の応答が、キーも型も正しいのに、仕入先の税番号を顧客に割り当てていることがあります。「JSON として有効だった割合」という 1 つの数字では、この失敗は見えません。

レビュアーが必要なタスクもあります。レビュアーには評価基準を渡し、可能であればモデルのラベルを伏せてください。判定の食い違いは記録し、一貫した方法で解決します。自動で判定できたレコード数と、人が必要だったレコード数も報告してください。手動レビューを増やす移行は、運用コストを変えます。

同時実行数を上げる前に互換性を確認する

大規模な再実行の前に、候補モデルの正確なモデル ID と対応エンドポイントを確認します。モデルの選択は設定で切り替えられるようにしておき、ジョブを投入する側のコードをすべて書き換えなくても変更できるようにします。検索用の slug を、文書化されたリクエスト ID の代わりに使わないでください。

推論 effort、出力上限、スキーマ形式、ストリーミング、ツールのレスポンスなど、実際に使っているコントロールを確認します。GPT-5.6 Luna が受け付けるパラメータでも、後継モデルでは拒否されたり、異なる解釈をされたりするかもしれません。HTTP の成功レスポンスは、リクエストした設定が反映された証明にはなりません。

このチェックの一環として、失敗時の経路も実際に動かしてください：

• 切り詰められた出力や不正な形式の出力は、検証で不合格にし、回数に上限のあるリトライポリシーに従わせる。
• 拒否応答は、空だが有効な抽出結果と区別できる状態を保つ。
• レート制限は、歯止めのないリトライの集中ではなく、制御されたバックオフを引き起こす。
• 途中までのストリームやネットワークのタイムアウトを、合格レコードに数えない。
• 再実行するジョブは同じジョブ ID を保ち、外部への書き込みを重複させない。

必要な挙動が確認できなかった場合は、統合を修正するか、そのワークロードを旧ルートに残したうえで、より大きな処理量のテストに進んでください。検証が壊れた状態で得たスループットの数値は、比較の役に立ちません。

応答の速さではなく、合格スループットを計測する

両方の構成で同じレコード構成とリトライポリシーを使い、同時実行数を段階的に上げていく管理されたテストを実施します。最初の小さな試験で基本的な失敗が見つかり、規模を上げるとキューイングとレート制限の挙動が見えてきます。プロバイダーが文書化している上限の範囲内で行ってください。

出力の長さと推論の設定は、常に見える状態にしておきます。はるかに長い応答を返す候補モデルは、レイテンシと支出の両方を変える可能性があります。プロンプトキャッシュやウォームアップも短時間の実行結果をゆがめることがあるため、キャッシュが温まっていたかどうかを報告し、説明なしに条件の異なる結果を混ぜないでください。

可能であればテストを繰り返し、サンプル数と実行時間を示します。短時間のバーストでは持続的なキュー処理能力を裏付けられず、ごく小さなサンプルから得た低い P95 は、本番で当てにできる保証にはなりません。

使えるレコードのコストを計算する

分子には、失敗した試行とリトライを含めます。エスカレーション先のモデルがレコードを修正した場合は、その API コストも含めてください。人手による修正時間は別に記録し、金額に換算する場合は時給の前提を明示します。合格レコードが 1 件もないキューについては、ゼロで割るのではなく、不合格として報告します。

移行するならどのレコードかを決める

試験の前に、重要なスライスごとのしきい値を書き出しておきます。全体の成功スコアが良くても、重要なラベルやフィールドでの許容できないリグレッションを帳消しにしてはいけません。値は、万能の「移行パーセンテージ」からではなく、自社のサービス目標とエラーのコストから決めてください。

シャドー再実行は、外部への副作用を生まない場合に有用です。本番のジョブでは、ジョブ ID を保持し、タイムアウト後にリトライする前に状態を確認してください。最初のレスポンスが失われただけで、フォールバックルートが更新を重複させるようなことがあってはいけません。

繰り返しタスクには GPT-6 Luna か、GPT-6 Sol か？

FAQ

GPT-6 Luna は GPT-5.6 Luna より速い、または安いですか？

このガイドに検証済みの比較はありません。新モデルの料金、スループット、挙動は、2026年9月20日に確認したソースでは未検証のままです。

JSON として有効なら、レコードを合格にしてよいですか？

いいえ。スキーマに加えて、必須フィールド、値、タスクとしての意味も検証してください。形式が整った応答でも、レコードを誤って分類したり、存在しない値を作り出したりすることがあります。

1 秒あたりのトークン数を比較すべきですか？

実行の診断には役立ちますが、キューの完了をよりよく表すのは、1 分あたりの合格レコード数とエンドツーエンドのレイテンシです。リトライとエスカレーションも含めてください。

コストの例は実際の Luna の料金ですか？

いいえ。合格レコード単価を説明するための、仮定のパイプライン合計額です。実際の評価では、現在のプロバイダーの請求額を使ってください。

すべてのレコードを新世代に移す必要がありますか？

いいえ。ルーティングルールが信頼でき、パイプライン全体が目標を満たすなら、一部だけの移行が適切な場合もあります。不合格のスライスや未テストのスライスは、実測済みのルートに残してください。

どうなったらロールバックすべきですか？

ロールアウト前に決めた停止条件を使います。重要フィールドのリグレッション、バックログの増加、許容できないエラー率やリトライ率、修正作業の増加、コスト予算の超過です。