GPT-6 Luna は 8 分の 1 のコストで、Nova 2 Lite と誤差の範囲内のスコア

2026年10月4日訂正: 9 月の版では、GPT-6 Luna を 8 月の Nova 2 Lite の実行と比べていました。両方を同じ日に再実行したところ結論が変わり、コスト比は 12× から約 8× に下がりました。

DynoTable の Eval スイートを条件をそろえて実行したところ、同じ 189 のエージェントケースで GPT-6 Luna は 93.47%、Amazon Nova 2 Lite は 95.06% のスコアでした。この差の 95% 信頼区間は −5.0 から +1.9 ポイントです。

2 つのモデルの間に検出可能な差は見つかりませんでした。それでも区間は、Nova 2 Lite が最大 5 ポイント上回っている可能性を残しています。

GPT-6 Luna はそれを約 8 分の 1 のコストで達成しました: 各モデルが使ったトークンから価格を計算して、試行あたり $0.000995 対 $0.007832 です。両方の実行は 2026年10月4日に、同じハーネスと、同じシードデータを入れたデータベースを使いました。

2 つのモデルは失敗の仕方が異なります。GPT-6 Luna は一部の結合を拒否し、データを読むべき場面でテーブルを開くことを提案します。Nova 2 Lite は曖昧なリクエストに対して、どのテーブルのことかを尋ねるべき場面でテーブルを選んでしまいます。

Amazon Bedrock の Converse API から GPT-6 Luna を呼び出すには、us.openai.gpt-6-luna または global.openai.gpt-6-luna の推論プロファイルを使います。temperature も cachePoint も送らないでください。どちらもリクエストを失敗させます。

条件をそろえた実行の横に、以前の結果が 3 つあります:

• GPT-5.6 Luna、8 月: 古いハーネスで、201 ケースで 93.94%、Nova 2 Lite は 96.00% でした。この差も 0 を含みます。
• 12 モデルのラダー、8 月: GPT-5.6 Luna は、試行あたり Nova 2 Lite の約 4 分の 1 のコストで、スコアは 3.6 ポイント低くなりました。
• 自動補完、9 月: GPT-6 Luna、Claude Haiku 4.5、Nova 2 Lite のスコアは、互いに 2 試行以内の差に収まりました。

シードデータを入れたローカルの DynamoDB に対し、201 のエージェントケースで結果を採点しました

DynoTable の AI エージェントは、ツール呼び出しでアプリを操作します。アイテムを読み、PartiQL と SQL を実行し、書き込みをレビュー用にステージします。

私たちのスイートは、そのエージェントを本物のプロンプトとリクエストバリデーターとともに、固定データを読み込んだ DynamoDB Local に対して実行します。

各ケースは 1 つのリクエストです: 複合キーでアイテムを読む、価格の変更をステージする、すべての削除を拒否する、といったものです。採点者は結果、つまり何が読まれ、ステージされ、拒否されたかを確認します。試行とは、ケースの 1 回の実行です。

ほとんどのケースは 3 試行を実行し、十数ケースは 1 回だけ実行しました。ケースのスコアはその試行の平均、モデルのスコアはそのケースの平均です。

1 試行が反転すると、3 試行のケースは 33 ポイント動きます。そのため 2 つのモデルの比較には、両方が共有するケースに対するペアブートストラップ信頼区間を使います。

比較セットは 201 ケースです。Nova 2 Lite の実行はそのうち 12 ケースを終える前に中断されたため、条件をそろえた比較には両方のモデルが完了した 189 ケースを使います。

欠けている 12 ケースは、5 つのネガティブケース（それぞれ、エージェントが不要なステップを省くことを確認します）、4 つのマルチターンケースのうち 3 つ、1 つのケースの推論の強度違いのバリアント 3 つ、そしてその他の 1 つです。

このスイートは 2 つのモデルに寄っています。プロンプトと採点者は、DynoTable が出荷時に合わせているモデルである Nova 2 Lite と Claude Haiku 4.5 でチューニングしました。後の修正の一部は Luna の失敗から生まれたもので、該当する箇所ではそう明記しています。

設定は異なっていました。GPT-6 Luna はデフォルトの推論の強度（AWS のドキュメントでは medium）で実行し、temperature は受け付けません。Nova 2 Lite は推論なし、temperature 0 で実行しました。どちらも出力上限は 1,024 トークンでした。

6 つのケースは推論の強度を明示的に設定します。それらのケースではどちらのモデルにも出力上限がなく、Nova 2 Lite は temperature 1 で推論しました（high の強度では temperature を未設定）。

コストは、トークン数に、呼び出したプロファイルの Bedrock の公開定価を掛けたものです。私たちの AWS の請求額ではありません。

既知の採点者の不具合が 1 つ残っています。あるケースで GPT-6 Luna は、別の有効なツールを通じてステージされた変更を開き、採点者は 3 試行すべてに 0 を付けます。これで約 0.5 ポイント失っています。

GPT-6 Luna は Nova 2 Lite より 1.6 ポイント低く、誤差の範囲内でした

差は −1.59 ポイントで、95% 区間は −5.0 から +1.9 です。GPT-6 Luna は 20 ケースで上回り、24 ケースで下回りました。符号検定では p = 0.65 です。このサンプルサイズでは、差は 0 と区別できません。

GPT-6 Luna 自身のスコアは、9月23日の最初の実行からほとんど動いていません: 201 ケースで当時 93.02%、現在 93.53% で、誤差の範囲に十分収まる変化です。

GPT-6 Luna が負ける場面:

• 顧客から注文への結合を拒否します。 orders の複合キーが customerId での結合を妨げると述べ、その後に質問するか、逆方向のビューを作ります。3 つのケースのスコアが 0 から 44% の間です。
• 空の書き換えを返します。4 つの PartiQL と SQL の編集ケースで、すべての試行でそうなりました。9 月には、同じ 4 ケースが 12 試行中 9 試行で空でした。
• データの代わりにテーブルを提案します。GSI に対する上位 5 件のクエリなど、一部の読み取りの質問で起きます。クエリを実行した場合も、大文字と小文字を区別する begins_with を大文字にして再試行しません。
• ファイルパスを尋ねます。見つけたばかりのエクスポートファイルを調べる代わりにです。
• 7 試行で出力が尽きました。推論中に 1,024 トークンの上限で止まりました。7 試行のいずれも満点ではありませんでした。

Nova 2 Lite が負ける場面:

• 尋ねるべき場面で決めてしまいます。 データを見せてという曖昧なリクエストに対し、orders を選んで行を表示します。
• エージェントの質問ツールではなく、文章で尋ねます。また、ステージされた変更を求められたのにテーブルを開きます。
• Smart Table をあきらめます。バリデーターが最初の定義を拒否した後で、ステップを使い果たします。

GPT-6 Luna の試行あたりのコストは Nova 2 Lite の約 8 分の 1 でした

GPT-6 Luna の実行は、短い自動補完のケースを含め、カタログにある 234 ケースすべてを対象にしました。Nova 2 Lite の実行は早く止まり、201 の比較ケースのうち 11 ケースに到達しませんでした。

GPT-6 Luna は試行あたり 7.9 倍、呼び出しあたり 7.7 倍安価でした。

定価がこの差の大半、約 3.3 倍を説明します。US geo プロファイルの GPT-6 Luna は、100 万入力トークンあたり $0.11、100 万出力トークンあたり $0.55 です。Nova 2 Lite は $0.33 と $2.75 です。

キャッシュによる差は 2 倍未満です。Nova 2 Lite のキャッシュ読み取りは入力レートの 4 分の 1 で、GPT-6 Luna は 10 分の 1 で課金されます。さらに Nova 2 Lite は入力トークンの 9.7% に通常レートを払い、GPT-6 Luna は 0.1% でした。

その一部は私たちの設定によるものです。Nova 2 Lite のリクエストはキャッシュのブレークポイントをシステムプロンプトに 1 つ設定し、会話履歴には設定していません。通常レートの入力が支出の 26.7% を占めました。

プロンプトが大きいことで、約 1.3 倍が加わります。Nova 2 Lite は 1 呼び出しあたり平均約 19,600 の入力トークンを送り、GPT-6 Luna は 14,900 でした。

暗黙的キャッシュが GPT-6 Luna の入力の 95% をカバーし、キャッシュ書き込みが請求額の 3 分の 1 を占めました

エージェントループは、ステップごとにシステムプロンプト、ツール定義、履歴を再送します。GPT-6 Luna は、リクエストのどこにもキャッシュのブレークポイントがないまま、入力トークンの 95.2% をキャッシュから読み取りました。

キャッシュ書き込みは GPT-6 Luna の入力トークンの 4.7% でしたが、支出の 31.9% を占めました。書き込みは入力レートの 1.25 倍、読み取りは 10 分の 1 で課金されるからです。

Bedrock のプロンプトキャッシュのガイドは、Nova と Anthropic のモデルについても暗黙的キャッシュを記載しています。私たちの Nova 2 Lite のリクエストは、その上に明示的なシステムプロンプトのブレークポイントを加えています。

GPT-6 Luna のモデルカードは、暗黙的キャッシュと明示的キャッシュを Responses API についてのみ記載しています。私たちは Converse でそれを確認しましたが、AWS はこれを記載していないので、これを前提に予算を組まないでください。

Converse で cachePoint ブロックを使ってキャッシュを強制しようともしないでください。GPT-6 Luna では、そのブロックがリクエスト全体を失敗させます。

Converse で GPT-6 Luna を呼び出すには推論プロファイルが必要で、4 つのリクエストフィールドを外す必要があります

bedrock-runtime エンドポイントでは、GPT-6 Luna にはクロスリージョン推論プロファイル経由でのみ到達できます: us.openai.gpt-6-luna または global.openai.gpt-6-luna です。AWS は、そこではベースモデル ID がリージョン内の呼び出しに使えないと明記しています。

US geo プロファイルはグローバルプロファイルより 10% 割高で、100 万入力トークンあたり $0.11 対 $0.10 です。ソースリージョンで提供されているプロファイルを選んでください。モデルカードに一覧があります。

Converse のプローブで、GPT-6 Luna が拒否し Claude Haiku 4.5 が受け付ける 4 つのリクエストフィールドが見つかりました。どれもリクエスト全体を失敗させます:

• temperature
• stopSequences
• ドキュメントのコンテンツブロック
• cachePoint ブロック

最初の 3 つは ValidationException を返します。cachePoint ブロックは AccessDeniedException を返し、権限の問題のように読めてしまいます。

推論の強度は additionalModelRequestFields に reasoning: {effort} として指定し、none から max まで選べます。デフォルトは medium です。推論トークンは出力上限に数えられ、そのため私たちの試行のうち 7 つが 1,024 で尽きました。

簡潔な、または詳細な推論の要約を求めるリクエストも失敗します。Bedrock は GPT-6 Luna にも GPT-5.6 Luna にも推論のテキストを返しません。

GPT-5.6 Luna にも現在は us. と global. のプロファイルがあります。素の ID openai.gpt-5.6-luna は bedrock-mantle エンドポイントに向かい、そこでは次の点に時間を取られました:

• ベースパスは /v1 ではなく /openai/v1 です。
• temperature はハードエラーです。 Mantle は unsupported_parameter: 'temperature' is not supported with this model を返します。
• 401 はサブスクリプションの欠如を意味することがあります。 モデルの AWS Marketplace サブスクリプションが有効になるまで、Bedrock は "Your subscription to the model is being set up" と返します。
• AI SDK の OpenAI プロバイダー（@ai-sdk/openai）は、強度を設定するとデフォルトで詳細な推論の要約を要求します。 reasoningSummary: null を渡さないと、すべてのターンが失敗します。

8 月の GPT-5.6 Luna は Nova 2 Lite に 2 ポイント届かず、これも誤差の範囲内でした

最初の Luna の比較は 8月5日と6日に、古いハーネスで実行しました。GPT-5.6 Luna は Mantle 経由で、適応型のデフォルト推論で呼び出しました。

同じ 201 ケースで、Nova 2 Lite は 96.00%、GPT-5.6 Luna は 93.94% でした。2.06 ポイントの差の 95% 区間は −0.8 から +5.0 で、これも 0 を含みます。

そのハーネスでの GPT-5.6 Luna の試行あたりのコストは Nova 2 Lite の約 5 分の 1 で、$0.0019 対 $0.0100 でした。

その期間の修正の 1 つは、GPT-5.6 Luna の失敗から生まれました。採点者が結果ではなくツール名を確認していたのです。その話には専用の記事があります。

その修正とその後の変更を通じて、GPT-5.6 Luna は 2.75 ポイント、Nova 2 Lite は 0.06 ポイント上がりました。

GPT-5.6 Luna に残った取りこぼし: 試みるべきタスクを拒否し、インデックスの効く上位 N 件のクエリをテーブル全体の走査で処理し、一度はエクスポートを未完了のままユーザーに戻しました。

同じ 189 ケースで、Nova 2 Lite は 8 月の 96.10% から 10 月の 95.06% になりました。−1.03 ポイントのこの変化の区間は −3.0 から +0.8 で、誤差の範囲内です。

その間に、201 ケースのうち 9 ケースで採点者が変わりました。ローカルデータベースは 13 または 14 テーブルから 49 テーブルに増え、すべてのテーブルを説明させる入門ケースが難しくなりました。

8 月の 12 モデルのラダーで、GPT-5.6 Luna は Nova 2 Lite の 4 分の 1 のコストで 3.6 ポイント低いスコアでした

8月6日、12 のモデルを 39 のシナリオでそれぞれ 3 試行ずつ、$20.49 かかった 1 つのセッションで実行しました。表は 12 モデルすべてが実行した 36 のシナリオを使っています。GPT-6 Luna はまだ存在しなかったので、行はありません。

(1) 私たちがチューニングの対象とする 2 つのモデルです。(2) Bedrock のプロンプトキャッシュがないため、ループの各ステップが入力の定価を払います。

(3) これらは 36 のエージェントシナリオだけを実行しました。他のモデルは短い自動補完のシナリオ 3 つも実行しており、それで試行あたりのコストが少し下がっています。

表から言えること:

• GPT-5.6 Luna の試行あたりのコストは Nova 2 Lite の約 4 分の 1 で、スコアは 3.6 ポイント低くなりました。前のセクションの 5 分の 1 は、別のケースセットである 201 ケースの実行から出た数字です。
• Terra は約 9.5 倍のコストで、Luna と 1 ポイント以内のスコアです。 Luna の 93.60% は、Mantle のサーバーエラーで失われた 1 試行を除外しています。それを 0 として採点すると 92.67% になり、Terra の 92.82% をわずかに下回ります。
• キャッシュがないことのコストは、定価が示す以上に大きくなります。 DeepSeek V3.2 の試行あたりのコストは Claude Haiku 4.5 の 5 倍で、スコアは 10 ポイント低くなりました。
• Nova Lite (Gen 1) は 90% を超える中で最も安価なモデルで、試行あたり $0.0013 です。
• 隣り合う行に差はありません。 シナリオあたり 3 試行なので、隣同士は 1 試行の反転で順位が入れ替わり得ます。

GPT-6 Luna は列を作り出すより、自動補完を空白のままにします

自動補完とは、DynoTable のクエリエディタに表示される灰色のゴーストテキストです。ここまでのステートメント、テーブルのスキーマ、いくつかの保存済みの値をもとに、モデルがその行を補完します。

9月23日、4 つのモデルを 22 の自動補完ケースで、それぞれ 3 試行、推論をオフにして実行しました:

ここでは 1 試行の反転でスコアが 1.5 ポイント動くので、上位 3 つは互いに約 2 試行以内の差に収まります。時間はストリーミングなしの、クライアントでの往復時間の中央値です。

GPT-6 Luna の最初の実行が、このスイートを変えました。18 ケースのうち 7 ケースで、すべての試行が空白でした。その 7 つすべてで、プロンプトには名前のヒントがなく、プロンプトは既に、推測するくらいなら何も出力しないよう指示していました。

7 つのうち 3 つは、既に空白を受け入れていました。私たちは、補完に必要なテーブル名や列名をプロンプトが一度も示していない場合は、空白が正解だと判断しました。

現在はそうしたケース 6 つが空の補完を受け入れており、そのうち 4 つは GPT-6 Luna の 7 つに含まれていました。新しい 4 ケースは欠けている名前をプロンプトに示し、モデルがそれを使うことを求めます。

GPT-6 Luna は、プロンプトが列に保存された 4 つの値を示したときも空白のままでした。推論はそれを変えませんでした。low と medium の強度では、推論オフと 1 試行以内の差のスコアで、時間は約 2 倍かかりました。

生の出力が理由を示していました: 示された値の 1 つを選ぶことを、するなと言われていた推測だと読んでいたのです。1 文で直りました: ステートメントやスキーマが示している候補は推測ではない、という文です。

再実行では、すべてのモデルのスコアが上がるか横ばいで、Nova Micro は 8.6 ポイント上がりました。その 4 モデルの実行のコストは 5 セントでした。

どちらの変更も、GPT-6 Luna の最初の実行の後に行いました。その 96.97% は、その振る舞いに合わせて調整したスイートから出たもので、これは一種のチューニングです。

私たちのスイートは 2 度、自らのバグをモデルの失敗として採点しました

9 月、GPT-6 Luna の 2 つのケースが、シードデータの古いコピーにある名前と答えを照合していました。GPT-6 Luna は現在の行を正しく読み、不正解と判定されました。10 月の実行では修正済みの採点者を使っています。

8 月のラダーでは、3 つの自動補完シナリオが、プロンプトキャッシュのない 4 モデルすべてで 0% になりました。合計 36 試行です。

どのリクエストも、モデルがトークンを生成する前に失敗していました。それらのモデルが拒否する stopSequences フィールドを送っていたからです。

私たちはそれらのゼロを除外し、これで 4 つのスコアはそれぞれ約 7 ポイント上がりました。そのうえでリクエストを修正しました。

再実行では、DeepSeek V3.2 が 3 つのシナリオすべてで 100% を出しました。MiniMax M2、Ministral 8B、Ministral 3B は、3 つのシナリオでそれぞれ 100%、50%、50% でした。

訂正しなければ、最初の実行は DeepSeek V3.2 を自動補完ができないモデルとして扱っていたことになります。

2026年10月4日時点で、Bedrock に GPT-6.1 Luna はありませんでした

Bedrock における OpenAI の 6.1 リリースは GPT-6.1 Sol で、9月29日に利用可能になりました。

GPT-6.1 Sol のモデルカードには、US geo プロファイルで 100 万入力トークンあたり $2.20、出力 $11.00 と記載されており、GPT-6 Luna の 20 倍です。私たちはまだ評価していません。

安価なエージェントモデルを選ぶときに応用できること

• 自分のループで測定する。 私たちの結果は、DynamoDB のエージェント作業と、他の 2 つのモデル向けにチューニングしたプロンプトに固有のものです。
• 信頼区間で比較する。 189 ケースでの 1.6 ポイントの差に検出可能な違いはありませんでしたが、その区間は 5 ポイントの差も許していました。
• 記録したトークンからループのコストを計算する。 キャッシュ書き込みは GPT-6 Luna の請求額の 3 分の 1 を占めましたが、トークンあたりの価格はそれを示しません。
• 各モデルがどこで負けるかを読む。 拒否された結合と、推測で選ばれたテーブルでは、ユーザーが失うものが違います。
• テストデータとリクエストを監査する。 古い期待値と、サポートされていない 1 つのフィールドが、私たち自身に原因のある失敗を生みました。

コストが制約なら、私たちのおすすめは GPT-6 Luna です。エージェント作業で Nova 2 Lite との検出可能な差は見つからず、コストは約 8 分の 1 でした。ただし区間は、Nova 2 Lite が最大 5 ポイント上回る可能性を残しています。

読み取りや結合をエージェントに最後までやり遂げさせる必要があるなら、Nova 2 Lite か Claude Haiku 4.5 を使い続けてください。

DynoTable を新しくインストールすると、リージョンで提供されている場合はモデルピッカーに GPT-6 Luna が表示されます。GPT-5.6 Luna は「設定」の「表示するモデル」でオンにすると、「その他のモデル」の下に表示されます。

どちらも検証済みのモデルで、つまり私たちの eval スイートがこれらに対して実行されます。どちらもあなた自身の Bedrock 認証情報で動作します。

AI エージェントの仕組み · DynamoDB における PartiQL と SQL · DynoTable をダウンロード