GPT-6 Sol / Lunaへの移行手順｜稼働中のNext.jsアプリをGPT-5.6から移す

Next.jsアプリにOpenAI APIを組み込むと、フレームワークのバージョン追従とは別に、モデルの更新という保守項目が増えます。 今回の更新は、これまでとは事情が少し違います。

2026年9月22日に発表されたGPT-6 Sol / Lunaは、GPT-5.6の同格モデルに対して単価がおおむね半分になりました。この50%という数字について、OpenAIの発表ページは「GPT-5.6のプロモーション価格と比べて」と書いています。一方でOpenAI広報はVentureBeatの取材に対し、今回の価格はプロモーションや導入価格ではなく恒久価格だと答えています（VentureBeat報道）。比較の基準が公式文面と報道で一致していないため、自社の削減幅は発表の見出しではなく、現在の請求明細に載っている単価から計算してください。

いずれにせよ、動いているコードを放置すると、同じ処理に高い単価を払い続けることになります。

本記事は「GPT-6とは何か」の解説ではなく、稼働中のNext.jsアプリをGPT-5.6からGPT-6へどう移すかという実装・運用の話です（2026年9月時点の公開情報にもとづきます）。移行コストの見積もりと決裁タイミングという経営判断の観点は、GPT-6 Sol / Lunaへの移行コストをどう計算するか（zetlinker.com）にまとめています。

先に結論です。

• 移行の実作業はモデルIDの差し替えが中心。破壊的変更にあたるものは、GPT-6 Sol側には見当たりません
• 一方でLunaには使えない機能がある。Chat Completionsでのツール呼び出しには制約があり、非対応エンドポイントも複数あります。「安いから全部Lunaへ」は成立しません
• 単価が下がる代わりに、272Kトークン超のリクエストは料金体系が変わる。ここを検知する実装を先に入れておきます

モデル更新を保守項目としてどう扱うか？

先に運用の土台を作っておくと、次のモデルが出たときの作業が「調査」ではなく「確認」で済みます。

OpenAI固有の話ではなく、Anthropic側の移行でも同じ型が使えます（Claude Opus 5.5への移行手順）。土台は3つです。

1. モデルIDをコードに直書きしない。切り替えも切り戻しも、デプロイなしで済む形にする
2. 提供元ドキュメントの「対応機能」表を先に読む。ティアごとに対応範囲が違う場合、見落とすと本番で落ちる
3. 切り替え後に品質とコストを計測する。単価が下がっても、請求額が下がるとは限らない

以下、この3点をGPT-6移行の実作業に落とします。

GPT-6 Sol / Lunaで何が変わったのか

エンドポイント・リクエスト形式は同じです。 Chat Completions / Responses / Batch で使え、モデルIDを差し替えれば動きます。

2026年9月時点の仕様は次のとおりです（出典：gpt-6-sol・gpt-6-luna・料金）。

単価をGPT-5.6の同格モデルと並べると差が見えます（100万トークンあたり・米ドル・Standard処理・short context。2026年9月時点）。

GPT-5.6 Terraは入力$2.00 / キャッシュ$0.20 / 出力$12.00でした。GPT-6 Solの単価は、前世代のTerraより出力が安いことになります。Terraで動かしていた処理をSolに寄せる判断が、単価の面では成立します。

effortの既定値は変わっていない

ここはAnthropic側の移行と事情が違うため、はっきり書いておきます。Claude Opus 5.5への移行では effort の既定値が high から medium に下がり、エラーを出さないまま品質が変わるという問題がありました。

GPT-6にはこの罠はありません。 GPT-5.6 Sol の既定値も medium で、GPT-6 Sol / Luna も medium です。effortを明示していないリクエストは、差し替え後も同じ既定値で動きます。同じ警戒をして検証工数をかける必要はありません。

ただし、明示的に書いておくこと自体は続ける価値があります。 次のモデルで既定値が変わったときに、コードを見れば意図が分かるためです。

モデルIDをどう環境変数に逃がすか？

gpt-5.6-sol から gpt-6-sol への切り替えが、デプロイ設定の変更だけで済む形にします。

App Router構成であれば、AI呼び出しはRoute HandlerかServer Actionに集約されているはずです。モデルIDをそこに直書きしていると、切り替えのたびにコード修正とデプロイが必要になり、切り戻しにもまたデプロイが要ります。

// src/lib/ai/models.ts
import OpenAI from "openai";

export const openai = new OpenAI();
// 環境変数で切り替える。未設定時のみ既定値を使う
export const MODEL_SOL = process.env.OPENAI_MODEL_SOL ?? "gpt-6-sol";
export const MODEL_LUNA = process.env.OPENAI_MODEL_LUNA ?? "gpt-6-luna";

// src/app/api/summarize/route.ts
export async function POST(req: Request) {
  const { document } = await req.json();
  const response = await openai.responses.create({
    model: MODEL_SOL,
    instructions: "社内文書を3点に要約してください。",
    input: document,
    reasoning: { effort: "medium" }, // 既定値でも明示しておく
  });
  return Response.json({ text: response.output_text });
}

Server Actionから呼ぶ場合も同じ定数を参照します。この形にしておくと、検証環境だけ gpt-6-sol、本番は gpt-5.6-sol という並行運用ができ、切り戻しも環境変数の値を戻すだけで済みます。

なおServer ActionはHTTPエンドポイントとして公開されるため、セッション確認をAI呼び出しの前に置く点は変わりません。認可を通さない経路があると、APIコストが外部から積まれます。

272Kトークン超をどう検知するか？

単価が下がっても、ここで料金体系が変わります。

OpenAIの料金には short context と long context の2段があり、入力が272Kトークンを超えると、そのリクエスト全体が long context 料金になります。入力が2倍・出力が1.5倍という関係で、GPT-6 Solなら入力$4.00 / キャッシュ$0.40 / 出力$15.00、GPT-6 Lunaなら入力$0.20 / キャッシュ$0.02 / 出力$0.75です（料金ページ、2026年9月時点）。

超過分だけが割高になるのではなく、リクエスト全体に適用される点が勘どころです。コンテキストウィンドウが1,050,000トークンあるため、「入るから入れる」という実装では気づかないうちに long context 側へ入ります。RAGで検索結果をまとめて詰める実装や、会話履歴を無制限に積む実装が該当しやすい箇所です。レスポンスの usage から入力トークン数を取って記録します。

// src/lib/ai/usage.ts
import type OpenAI from "openai";

const LONG_CONTEXT_THRESHOLD = 272_000;

export function recordUsage(
  response: OpenAI.Responses.Response,
  meta: { route: string; model: string },
) {
  const usage = response.usage;
  if (!usage) return;

  const record = {
    ...meta,
    inputTokens: usage.input_tokens,
    cachedTokens: usage.input_tokens_details?.cached_tokens ?? 0,
    outputTokens: usage.output_tokens,
    reasoningTokens: usage.output_tokens_details?.reasoning_tokens ?? 0,
    longContext: usage.input_tokens > LONG_CONTEXT_THRESHOLD,
  };

  if (record.longContext) console.warn("[ai] long context pricing", record);
  return record;
}

usage には input_tokens / output_tokens に加え、input_tokens_details.cached_tokens（キャッシュヒット分）と output_tokens_details.reasoning_tokens（推論トークン）が入ります（Reasoning models）。この4つをFirestoreなどに書き出しておくと、後述のコスト計測がそのまま回せます。

入力側を削るなら、RAGの検索件数に上限を置く、会話履歴を直近Nターンに切る、といった対処になります。どちらも1行で済む変更ではないため、閾値超えが実際に起きているかを先に計測してから手を入れます。

Lunaに落とせる処理と、落とせない処理をどう切り分けるか？

Lunaの単価はSolの20分の1です。ただし、対応範囲が同じではありません。

OpenAIは、Luna が GPT-5.6 Sol のおよそ100分の1のタスクコストで、高いeffort設定では事実性において同等だと説明しています（GPT-6 Sol / Luna の発表）。これはOpenAIの主張であり、自社のタスクで同じ結果になるかは別問題です。判断材料として、次の2点を先に確認します。

① Chat Completionsでのツール呼び出しに制約がある

公式ドキュメントには、Lunaは Chat Completions での function calling を reasoning_effort が none のときにのみサポートすると記載されています。あわせて「組み込みツールと function calling には Responses API を使うこと」とも書かれています（gpt-6-luna）。Responses API 側にはこの制約の記載がありません。

実装への影響は、いまどちらのAPIを使っているかで変わります。

• Chat Completions + ツール呼び出し：reasoning_effort: "none" に固定するか、Responses APIへ移すかの二択。推論を効かせたままツールを使う形は取れません
• Responses API + ツール呼び出し：この制約の対象外。モデルIDの差し替えで進められます
• ツール呼び出しなし（要約・分類・生成のみ）：制約は関係なく、Lunaの候補になります

移行前に tools: を含む呼び出し箇所を検索し、どちらのAPIを使っているかを洗い出します。Chat Completionsでツールを使っている箇所が多いなら、Luna移行の前にResponses APIへの移行が先に来ます。

② 非対応エンドポイントがある

Lunaは以下のエンドポイントに対応していません。

Live / Realtime（翻訳・文字起こしを含む）/ Assistants / Fine-tuning / Embeddings / Image generation / Videos / Image edit / Speech generation / Transcription / Translation / Moderation / 旧Completions

音声入出力やリアルタイム処理を含む実装は、Lunaでは置き換えられません。なお、これらの非対応はSolも同様です。 Sol / Luna ともに使えるのは Chat Completions / Responses / Batch の3つで、GPT-5.6世代でRealtimeやFine-tuningを使っている処理はGPT-6への移行対象から外れます。

対応ツール自体は Sol / Luna 共通で、web_search / file_search / image_generation / code_interpreter / hosted_shell / apply_patch / skills / computer_use / mcp / tool_search が Responses API 経由で使えます。

なお、EUデータレジデンシーは Standard processing でのみ利用できます。リージョナル処理エンドポイントは料金が10%上乗せになるため、試算はこの前提を含めて計算します。

SolとLunaの振り分けをコードでどう持つか？

処理の種類でモデルを選ぶ小さな関数を1つ置き、対応表は設定に逃がします。

呼び出し側で MODEL_SOL と MODEL_LUNA を直接使い分けると、振り分けの判断がコード中に散ります。「どの処理をLunaに落としたか」を後から追えなくなるため、タスク種別からモデルを引く形にします。

// src/lib/ai/routing.ts
import { MODEL_SOL, MODEL_LUNA } from "./models";

export type AiTask = "classify" | "summarize" | "extract" | "agent";
type Tier = "sol" | "luna";

// 環境変数で上書き可能にしておく（例: AI_TIER_summarize=sol）
const DEFAULT_TIERS: Record<AiTask, Tier> = {
  classify: "luna", summarize: "luna", extract: "sol", agent: "sol",
};

export function resolveModel(task: AiTask): string {
  const tier = (process.env[`AI_TIER_${task}`] as Tier) ?? DEFAULT_TIERS[task];
  return tier === "luna" ? MODEL_LUNA : MODEL_SOL;
}

呼び出し側は resolveModel("classify") のようにタスク名だけを渡します。これで1タスクだけSolへ戻す操作が環境変数1つでできます。Lunaに落として品質が足りなかった処理を、デプロイを待たずに戻せる状態です。移行直後は環境変数での上書きが効き、落ち着いたら DEFAULT_TIERS 側を書き換える、という順序になります。

請求額はどう動くか？

単価が半分になっても、請求額が半分になるとは限りません。 effortを上げれば、その分は出力側の請求に乗ります。

推論トークンはレスポンスのテキストには現れませんが、出力トークンとして課金されます。effortを medium から high に上げると、見える出力の長さは変わらないまま請求額が動きます。前掲の recordUsage で reasoning_tokens を記録しているのはこのためで、output_tokens（課金対象の合計）と output_tokens_details.reasoning_tokens（うち推論分）を並べると、effortを上げた分がどれだけ請求に乗ったかが読めます。

下げる方向では、キャッシュの効きも同時に見ます。input_tokens_details.cached_tokens が input_tokens に占める割合がキャッシュヒット率です。GPT-6 Solのキャッシュ入力$0.20は通常入力$2.00の10分の1なので、システムプロンプトや共通コンテキストを先頭に固定し、可変部分を後方に置く構造が効きます。即時性が要らない集計・分類であれば、Batch APIで50%減という選択肢もあります。

切り替え後に何を計測するか？

品質とコストの両方を、切り替え前後で比べられる状態にしておきます。

OpenAIは、GPT-6 Sol について AutomationBench 1.0.6 で33.2%（1タスクあたり$0.27）、DeepSWE 1.1 で68.8%、事実性評価でGPT-5.6 Solのおよそ半分の誤り、敵対的テストでの欺瞞率1.3%（GPT-5.6 Solは10.4%）といった数値を挙げています（GPT-6 Sol / Luna の発表）。

これらはいずれもOpenAIが公表したベンチマーク結果であり、自社のタスクでの結果ではありません。移行の可否は自社の評価セットで判断します。大がかりなものは要らず、実際に来ている入力を20〜50件固定し、GPT-5.6とGPT-6に同じ入力を流して出力を並べる形で足ります。前述の環境変数による並行運用が、そのまま比較環境になります。

コスト側は、切り替え前の1週間分を recordUsage で記録しておくと、切り替え後の同じ期間と比較できます。見る項目は、入力トークン数（キャッシュヒット分を含む・除くの両方）、出力トークン数とうち推論トークン数、272Kトークン超のリクエスト件数、そしてタスク種別ごとの内訳の4つです。請求ダッシュボードの合計額だけでは、どこが効いたかが分かりません。 タスク別に分けておくと、「分類をLunaに落とした効果」と「要約のeffortを上げたコスト」を別々に読めます。

作業の順序

ここまでの内容を手順に並べ直すと、次の順になります。

1. tools: を含む呼び出しを検索し、Chat Completions / Responses のどちらを使っているかを一覧にする
2. Realtime / Fine-tuning / Embeddings / 音声系エンドポイントの使用箇所を確認する。該当があればGPT-6の対象外として切り分ける
3. モデルIDを環境変数に逃がす（OPENAI_MODEL_SOL / OPENAI_MODEL_LUNA）
4. recordUsage を入れ、切り替え前の1週間を記録する
5. 検証環境だけ gpt-6-sol に切り替え、評価セットで出力を比較する
6. 問題がなければ本番を切り替え、同じ期間のusageを比較する
7. 落とせそうなタスクを1つずつLunaへ移し、タスク単位で品質とコストを確認する

Lunaへの移行は最後に置きます。モデル世代の移行とティアの変更を同時にやると、品質が変わったときにどちらが原因かの切り分けができなくなるためです。

まとめ

• GPT-6 Sol / Luna への移行は、モデルIDの差し替えが中心。GPT-5.6からの破壊的変更にあたるものは見当たらず、effort の既定値も medium のまま据え置きです
• Lunaは対応範囲が狭い。Chat Completionsでのツール呼び出しは reasoning_effort: "none" のときのみで、Realtime・Fine-tuning・音声系のエンドポイントには対応していません。「安いから全部Lunaへ」は成立しません
• 272Kトークン超のリクエストは料金体系が変わる。usage.input_tokens で検知して記録する実装を、切り替え前に入れておきます
• 単価が下がっても、effortを上げれば出力側の請求に乗ります。切り替え後は評価セットとusage集計の両方で確認します

モデルIDの環境変数化・対応機能の事前確認・切り替え後の計測という3点は、提供元が変わっても使える型です。同じ型でAnthropic側の移行を扱ったClaude Opus 5.5への移行手順、前世代のティア構成を整理したGPT-5.6のSol/Terra/Lunaとは、追従の体制づくりを扱ったNext.js保守運用の費用と契約もあわせてご覧ください。

私たちは、Next.js構成でのAI組み込みを、モデル選定からPoC実装・本番移行まで一貫してお手伝いしています。「既存のGPT-5.6実装をGPT-6へ安全に移したい」「どの処理をLunaに落とせるか切り分けたい」という段階からのご相談を歓迎します。Next.js × AIでのPoC開発について、15分のカジュアルな相談も受け付けています（事例・要件が固まっていなくても大丈夫です／営業はしません）。

※本記事に記載したモデルの仕様・料金・提供条件は、2026年9月23日時点の公開情報（gpt-6-sol・gpt-6-luna・料金ページ）に基づく整理です。ベンチマークの数値はOpenAIが公表したものであり、自社での検証結果ではありません。AI関連の状況は変化が速いため、実装・導入の判断にあたっては必ず公式情報で最新の内容をご確認ください。本記事はNext.js 16.x時点の情報です。