Amazon Bedrock上のOpenAIモデルに、異なるコストテストが登場
Amazon Bedrock上のOpenAIモデルに対し、9月11日、新たな本番向けベンチマークが提示された。その結果は、「最も安いトークンを選ぶ」というルールに疑問を投げかける。AWSとOpenAIは、学術問題、リサーチエージェント、業務文書、レイテンシー計測にまたがる5つの構成をテストした。中心的な結論は一貫している。トークン単価が安いモデルでも、低品質な回答、繰り返される検索、人手による手直しを計算に入れれば、結果的に高コストになり得る。
比較対象には、GPT-5.6 Luna、Terra、Solに加え、GPT-5.4 MiniとNanoが含まれる。単一の万能な勝者を宣言するのではなく、このベンチマーク調査は、成功した各成果物が何を消費するかを問う。そこには、失敗した試行、蓄積されたコンテキスト、ツール呼び出し、レイテンシー、受け入れルーブリックを満たさない成果物も含まれる。
これは、エージェントや文書ワークフローを導入するチームにとって、購買判断の枠組みを変える。主な争点はもはや、安いトークン対高いトークンではない。表示上のトークン価格対、受け入れられる結果を得るまでの総コストである。この新しいオープンソースのハーネスにより、開発者は自社のタスクでその比較を検証できる。
ベンチマークはトークン順位を成果順位へ置き換える
このベンチマークは、比較単位を生成トークンから、定義済みの品質基準を満たす作業へと移している。
これは小さな会計上の調整に聞こえるかもしれない。しかし、どのモデルが経済的に見えるかを変える。
AWSとOpenAIは、単一の精度テストでは本番システムを表現できないため、複数のワークロード形態を評価した。学術スイートにはAIME、GPQA Diamond、MMLU-Proが含まれた。サンプル数はAIMEの60問からGPQA Diamondの198問までで、その間にMMLU-Proの140問がある。
各モデルについて、成功した試行と失敗した試行の双方にわたる使用量が計上された。評価者は、観測された総利用コストを正解数で割った。これにより、1回のリクエストあたりのコストではなく、正解1件あたりのコストが算出された。
精度差が大きい場合、この違いは重要になる。GPT-5.6 Solは、サンプリングされたAIME問題の75パーセントに正解した。GPT-5.4 Miniは37パーセントだった。SolはGPQA DiamondでもMiniを上回り、68パーセント対43パーセント、MMLU-Proでも82パーセント対59パーセントとなった。
精度37パーセントのモデルでは、平均すると成功1件あたり約2.7回の独立した試行が必要になる。ただし、本番環境の再試行が独立していることは稀だ。同じ曖昧なプロンプトや不足した証拠が、すべての試行を似た失敗へと向かわせる可能性がある。
Lunaは、テストされたサンプル全体で、正解1件あたりの観測コストが最も低かった。記録された前提条件ではNanoの名目トークン単価がわずかに低かったにもかかわらず、Nanoとの比較もこれに含まれる。Lunaはテスト構成で請求対象トークンをより少なく使い、より多くの試行を受け入れ可能な回答に変換した。
この結果は、Lunaが常に最も安価なモデルであることを証明するものではない。請求額は料金表だけから推測できない理由を示している。プロンプト長、出力長、推論設定、再試行ポリシー、要求精度はいずれも最終的な順位に影響する。
このハーネスは、それらの依存関係を可視化する。回答、トークン消費量、品質スコア、算出された成果コストを記録するため、チームは総合リーダーボードのスコアをそのまま受け入れるのではなく、基礎となる結果を確認できる。
この透明性は重要だ。モデル評価はしばしば複数のトレードオフを1つの数値に圧縮するからである。本番環境の責任者は、モデルが事実誤認、構造不足、過剰なターン、出力の切り詰めのどれによって失敗したのかを知る必要がある。失敗の種類ごとに、取るべき対応は異なる。
事実誤認であれば、より強力なモデルを正当化できるかもしれない。構造上の不足なら、より明確なルーブリックで修正できる可能性がある。繰り返される検索は、ツール選択の弱さや非効率なエージェントループを示すことがある。切り詰めは、推論品質ではなく出力制限を示唆する。
したがって、Amazon Bedrock上のOpenAIモデルにとって、このベンチマークはより有用な最初の問いを提示する。この特定のワークフローにおいて、成功とは何を指すのか。その閾値を定義して初めて、チームは到達に必要なリソースを比較できる。
正解1件あたりのコストが再試行ペナルティを明らかにする
アプリケーションが静かに再試行している場合でも、すべての不正解はモデル選定の予算に含めるべきだ。
トークン単価による比較では通常、2つのモデルが同等の作業を完了すると仮定する。学術評価の結果は、その前提がなぜ成り立たないかを示している。精度が高いほど想定される呼び出し回数は変わり、トークン効率は各呼び出しの規模を変える。
顧客への公開前に技術的な質問へ回答するアプリケーションを考えてみよう。誤答は、自動再試行、フォールバックモデル、あるいは人によるレビューを引き起こす可能性がある。これらの影響はいずれも、初期のトークン見積もりには現れない。
正解1件あたりのコスト計算は、失敗した試行における直接的なモデル利用を捉える。より完全な本番計算には、検証、レビュー時間、下流での修正、顧客向けリスクを加えることができる。適切な範囲は、誰がそのワークフローを管理するかによって決まる。
AWSの調査は、普遍的な順位を約束するのではなく、意図的に観測サンプルを用いている。この選択は結論の適用範囲を限定する一方、実務上の価値を高めている。記録されたタスク、プロンプト、設定、採点ルールは、確認と変更が可能だからだ。
チームは、ハーネスを適用する際にもこの規律を保つべきである。既知の回答セットは、実際のトラフィックに近い必要がある。簡単な質問では、すべてのモデルが代替可能に見える可能性があり、異常に難しい質問ではプレミアムモデルの必要性を過大に見せる可能性がある。
失敗コストもユースケースによって異なる。不完全な社内要約なら数秒で修正できるかもしれない。不正確なコンプライアンス声明は、より長いレビュー工程を開始させる可能性がある。どのモデルの実行を始める前にも、精度の閾値はこの違いを反映すべきだ。
ここでは、単一の全社標準よりもルーティングのほうが有用になる。定型的な分類は、控えめな閾値を効率的にクリアするモデルへ送れる。難しい分析は、バリデーターが不確実性や失敗を検出した後にエスカレーションできる。
ルーティングにも測定が必要だ。安価な最初の試行の後に頻繁なエスカレーションが発生すれば、最初からより強力なモデルへ送るより高コストになり得る。また、レイテンシーを増やし、呼び出し間でコンテキストを重複させることもある。
ベンチマークの結果は、多くの高ボリュームタスクにおいてLunaが最初の評価対象に値することを示唆している。調査の学術サンプル全体で、Lunaは最も低い観測成果コストを示した。それでも、難問に対する精度が厳格な条件となる場合には、Solがより強い選択肢であり続けた。
これはブランドの序列ではなく、ワークロードの判断である。Luna、Terra、Sol、Mini、Nanoは、品質、速度、消費量にわたる異なる位置を占める。その名称から、特定の受け入れ基準を満たす位置を判断することはできない。
推論設定は、さらに状況を複雑にする。Amazon Bedrockでの比較では、テスト対象モデルの推論を無効化し、意図的なコスト下限を作った。推論を有効にすると、結果が改善する場合も、利用量が増える場合も、両方が起こる場合もある。
公平な評価では、各モデルと各推論レベルをそれぞれ独立した構成として扱う必要がある。推論なしのあるモデルを、より高い推論設定の別モデルと比較すれば、結果を生んだ仕組みが見えにくくなる。
成果フレームワークは、価格変更による混乱も抑える。チームは評価記録内の現行料金を更新し、順位を再計算できる。商取引条件が変わるたびに品質調査を作り直す必要はない。
安定した品質エビデンスと変動する商業的入力を分離することには価値がある。それにより、モデル選定は一度きりの調達判断ではなく、運用プロセスへと変わる。
エージェント軌跡のコストは、余分なステップを累積コンテキストへ変える
リサーチエージェントでは、高コストの振る舞いは1つの長い回答ではなく、不必要な一連のツール呼び出しであることが多い。
この調査は、層化された50問のDeepSearchQAサンプルでその問題をテストした。これらは、ライブのウェブ検索ツールとページ取得ツールを通じて処理される、複数ステップのリサーチ質問だった。
エージェントは、ストレージを無効にしたクライアント管理の会話履歴を使用した。新しいターンごとに、システムプロンプト、以前のツール結果、蓄積されたコンテキストが再送信された。軌跡が伸びるにつれ、各リクエストは前のリクエストより大きくなった。
これにより、累積効果が生まれる。履歴が蓄積し続ける場合、ターンごとの入力はおおむね線形に増加する。ターン数が増えるにつれて、請求対象となる累積入力は二次的な増加に近づく可能性がある。
したがって、8ターンのエージェントは、5ターンのエージェントと比べて単に3回多く呼び出すだけではない。後半の呼び出しには、より多くの過去の情報も含まれる。各往復はレイテンシーを追加し、重複したコンテキストは消費量を増やす。
MiniはDeepSearchQAの質問1件あたり平均7.6ターンで、テストされたモデルの中で最も多かった。その多くは追加の検索ループだった。平均入力量は質問1件あたり114,000トークンに達し、Terraの50,000トークンと比べて大きい。
これは、回答品質を考慮する前の時点でTerraの入力量の2.3倍である。Miniの平均F1スコアは0.39で、Terraは0.50に達した。F1は、適合率と再現率のバランスを取りながら、期待された回答内容と生成された回答内容の重なりを測定する。
F1スコアが少なくとも0.7に達した回答は合格とされた。評価では、決定的な事前チェックの後に、固定されたGPT-5.5の自動評価器を用いた。評価器を固定することで、モデル実行間における変動要因の1つを抑えた。
Terraは、Miniより少ないターン数と高い平均品質でリサーチ軌跡を完了した。Miniは繰り返し、より多くの蓄積済みエビデンスを再送していたため、Terraのより高い名目トークン単価が最終結果を決めることはなかった。
LunaはMiniより少ないターン数を記録し、合格回答1件あたりの観測エージェント軌跡コストも大幅に低かった。このサンプルでは、その合格レベルのコストはMiniのおよそ8分の1だった。Nanoは名目トークン価格が安かったが、合格した質問は18パーセントにとどまった。
3つのGPT-5.6構成はいずれも、2つのベースラインより高い平均F1スコアを示した。これは記事のより広い主張を支持するが、サンプルには限界がある。50問だけでは、すべてのリサーチ領域における僅差を決着させることはできない。
別のワークロードでモデルの順位が逆転したとしても、その仕組みには注目すべき価値がある。履歴を再送するクライアント管理型エージェントは、軌跡の設計に対してコストを支払う。より優れたモデルの振る舞いと、より良いオーケストレーションは、どちらもその履歴を短縮できる。
モデルは、より関連性の高い検索クエリを選ぶ、十分なエビデンスを認識する、あるいは追加の検索なしに回答を構成することでターン数を削減できる。オーケストレーターは、ツール出力の整理、履歴の要約、検索予算の強制によってターン数を削減できる。
こうした改善は個別に評価すべきである。そうしなければ、チームはオーケストレーションの変更をモデルの功績と見なしたり、アプリケーションが不要なコンテキストを挿入したことをモデルの責任にしたりする可能性がある。
Responses APIは、Amazon Bedrockを通じてOpenAI互換のリクエスト構造を提供する。互換性によりモデルの置き換えは容易になるが、等価なリクエストが等価な軌跡を保証するわけではない。
ツールスキーマ、停止ルール、プロンプト設計、リージョンごとの挙動は、依然として観測された実行に影響する。有用なテストでは、これらの要素を固定しつつ、一度に1つのモデル構成だけを切り替える。
チームは総トークン数以上の情報も記録すべきだ。ターン数、ツール選択、取得バイト数、重複クエリ、完了状態、バリデーターの結果は、ある軌跡がなぜより高コストになるのかを明らかにする。
エージェントにとって実用的な指標は、完全な実行1回あたりの承認済み回答数です。エージェントの軌跡コストは、1回あたりの料金表では似通って見えるモデル間の差を説明します。
プロフェッショナル向け成果物では、品質も請求額の一部になる
もっともらしい下書きであっても、専門職が満たすべき要件を満たせない場合があるため、文書は生成後にもコストを生みます。
多くのエンタープライズ向け成果物は、完全一致の文字列比較では評価できません。コンプライアンス概要書には必須の注意書きが必要です。財務計画には一貫した前提条件が必要です。ケアプロトコルには、具体的な安全対策と実用的な構成を含めなければなりません。
この研究では、GDPvalから抽出した48のタスクを扱いました。GDPvalは、専門職の業務を中心に作成された基準を用いて、現実的なナレッジワークの成果物を評価します。より広範な GDPval framework は、9分野・44職種を対象としています。
AWSの評価では、人間が作成したルーブリックを用い、要件ごとに重み付けを行いました。利用可能なルーブリック得点の70%以上を獲得すると、文書は合格と判定されました。これにより、主観的な品質が明示的な受け入れ基準へと変換されました。
GPT-5.6の3構成はいずれも、推論を無効化したMiniおよびNanoより高い観測ルーブリックスコアを獲得しました。報告された差が最も大きかったのは、法律、看護、金融アドバイスのタスクでした。
ただし、各サブグループは小規模だったため、これらのカテゴリ別の結果は探索的なものです。それでも、形式と完全性をベンチマークに含めるべき理由を示しています。正しい事実を含む回答でも、専門的な文書として使えるようにする注意書きが欠けている場合があります。
Lunaは48件の成果物のうち31件でMiniを上回りました。9件では下回り、8件は同点でした。Lunaは27タスクに合格し、Miniは20タスクに合格しました。
Nanoはタスクの35%に合格しました。Miniは42%、Lunaは56%に達しました。Solは48件中31件の成果物に合格しており、品質が厳格な要件となる場合に適した位置付けを裏付けています。
これらの結果は、経済性に関する問いを変えます。従業員が欠落したセクションを繰り返し補完しなければならないなら、モデル料金が低いことの価値は限られます。レビューと手戻りのコストは、最初の下書きを生成するコストを上回る可能性があります。
したがって、品質ゲートを設けた文書作成には、相互に関連する2つの測定が必要です。1つ目は、合格する成果物1件あたりのモデル利用量です。2つ目は、不合格または限界的な出力を承認済みの出力へ変えるために必要な人手です。
ベンチマークは前者を直接測定します。組織は後者を自社のワークフローから補う必要があります。レビュー時間は、承認システム、編集ログ、または構造化された評価者フィードバックを通じて収集できます。
この追加の証拠により、適切なモデルが変わる可能性があります。TerraまたはSolは、下書きに必要な専門的レビューが大幅に少ないなら、より大きなモデル消費を正当化できるかもしれません。総利用量を抑えながらLunaの合格率がビジネス上の閾値を超えるなら、Lunaが引き続き望ましい選択肢となる可能性があります。
出力上限は別の不確実性をもたらします。この評価では成果物を8,192トークンに制限しました。その結果、Lunaの出力6件、Terraの出力9件、Solの出力7件、Nanoの出力1件が切り詰められ、Miniの出力は切り詰められませんでした。
これらの切り詰めは、テストした構成における実際の結果として数えられます。同時に、モデル品質と課された長さの上限を分離することを難しくします。上限を引き上げれば、消費量を増やしつつルーブリックの充足度を改善できる可能性があります。
慎重な再現検証では、上限とモデルの両方をテストすべきです。また、より長い文書が有用な内容を増やすのか、それとも単に繰り返しが増えるだけなのかも確認すべきです。出力が多ければ自動的により良い成果物になるわけではありません。
ルーブリックにも同様の精査が必要です。汎用的な採点フォームでは、分野固有の失敗モードを見逃します。法務、臨床、金融、エンジニアリングの業務には、それぞれ異なる証拠、資格要件、エスカレーション規則が必要です。
ベンチマークの著者が推奨するように、チームは代表的な50〜100件のタスクから始められます。各タスクには、既知の良好な結果、またはレビュアーが一貫して適用できる受け入れルーブリックを含めるべきです。
有用なセットには、一般的な業務、難しいエッジケース、失敗に敏感な例を含めます。また、従業員が実際に使用する入力ファイルとコンテキストも保持すべきです。サニタイズされた簡易プロンプトは、検索や書式設定の問題を過小評価しがちです。
知識集約型の文書チームにとって、こうした評価セットの維持は運用上の記憶の一部になります。検索可能な engineering knowledge base は、ルーブリック、参照ファイル、過去の失敗分析の保持に役立ちます。
目的は、専門的な判断をなくすことではありません。その判断を、生成されたすべての下書きに含まれる回避可能な欠陥のレビューではなく、代表的な評価と重要な例外に振り向けることです。
Amazon Bedrock上のOpenAIモデルにもローカル検証は必要
公表されたランキングは、最初に何をテストすべきかを示す証拠であり、テストを省略してよいという許可ではありません。
このハーネスはより強力なモデル選定手法を提供しますが、その制約により万能の推奨はできません。サンプル構成、リージョン、推論設定、出力上限、採点者の選択はいずれも結果に影響します。
著者らは2026年7月にレイテンシ比較を実施しました。LunaとTerraはAWSの米国西部リージョンで単一リージョン構成を使用しました。Solは挙動と利用可能性が異なったため、米国東部リージョンを使用しました。
一致した12構成全体で、最初のトークンまでの時間の中央値は、Amazon Bedrock上のLunaで平均21%低くなりました。Terraは平均5%低くなりました。最初のトークンまでの時間は、ストリーミング出力が始まるまでの遅延を測定します。
少なくとも500トークンを含む出力では、LunaのスループットはAmazon Bedrock上で平均43%高くなりました。Terraの優位性は平均4%でした。これらの測定は、同じモデルを2つのアプリケーション経路で比較したものです。
中央値に対する観測上の最悪ケース遅延は、Amazon Bedrockでは2.1〜2.5倍でした。OpenAI APIにおける対応する範囲は4.6〜6.6倍でした。
これらの最大値は、99パーセンタイルのレイテンシ推定値ではありません。この研究では、特定時点での観測値として明示的に説明されています。共有インフラは、リージョン、負荷、クォータ、ルーティング、リクエスト形状によって変化します。
本番チームは、自身のデプロイリージョンからレイテンシ試験を繰り返すべきです。現実的な同時実行数、プロンプトサイズ、ストリーミング動作、サービスレベル目標をテストすべきです。中央値だけでは、ユーザーに見えるテール遅延を隠してしまうことがあります。
品質テストにも意図的な構成上の選択がありました。推論は無効化され、低利用量のベースラインが作られました。難しい計画立案や統合に依存するアプリケーションでは、実際にデプロイする想定の推論レベルで実行を繰り返すべきです。
採点には別の懸念もあります。DeepSearchQAは決定論的なステップとGPT-5.5の自動評価器を組み合わせました。このプロセスは再現可能ですが、モデル評価器には選好が入り込んだり、分野固有のエラーを見逃したりする可能性があります。
較正のためには、人間によるレビューが引き続き有用です。レビュアーは合格閾値付近の不一致を調べたうえで、ルーブリックまたは決定論的チェックを調整できます。ただし、どのモデルが勝ったかを見てからルールを変更すべきではありません。
GDPvalには別の制約があります。48タスクのスライスはパターンを明らかにするには十分広範ですが、個別の職種について確信を持った結論を導くには小さすぎます。報告されたカテゴリ別の差異には、より大規模で対象を絞ったサンプルが必要です。
チームはベンチマーク漏洩にも抵抗しなければなりません。プロンプトが公開評価にあまりに似ている場合、結果は実際の性能を過大評価する可能性があります。実際のワークフローから収集した非公開タスクの方が、ローカルな価値をより適切に検証できます。
オープンソースの benchmark harness は、この適応を支援します。学術評価、DeepSearchQAの軌跡、GDPvalの成果物、性能比較のためのスクリプトが含まれています。
再現性があっても、運用上の変数はなくなりません。モデル改訂、サービス更新、プロンプト変更はいずれも結果を動かし得ます。したがって、評価記録にはモデル識別子、日付、リージョン、設定、ルーブリックのバージョンを保存すべきです。
セキュリティおよびガバナンス要件は、小さな効率差を上回ることもあります。OpenAIモデルは2026年6月にAWS経由で一般提供となり、AWSネイティブの制御機能と調達ワークフローを利用できるようになりました。AWS availability は、すでにその環境に標準化している組織にとって重要です。
ただし、プラットフォーム適合性はモデル品質とは分けて考えるべきです。Bedrockはガバナンスを簡素化できますが、すべてのモデルをすべてのタスクに適したものにするわけではありません。ハーネスは、インフラ要件によって利用可能な選択肢が絞られた後の品質テストを支援します。
したがって、健全な意思決定は4つのゲートを組み合わせます。モデルはガバナンス規則を満たし、品質閾値を超え、レイテンシの期待を満たし、承認済みの業務で消費される総リソースを最小化しなければなりません。
公開ベンチマークが、個々の組織のためにこれらのゲートを定めることはできません。隠れたトレードオフを明らかにする測定項目を示せるだけです。
成果ベースの価格設定が標準化するかを示す3つのシグナル
次の試金石は、チームがこのベンチマークを別の静的なリーダーボードとして扱うのではなく、成果測定を運用に組み込むかどうかです。
第1のシグナルは、非公開でワークロード固有の評価セットの採用です。今後数か月で、最も有益な組織は、普遍的なモデルランキングではなく方法論の詳細を公表するでしょう。
優れた評価セットには、日常的なタスク、高コストな失敗、承認済みの参照出力が含まれます。また、再試行ポリシー、人間のレビュー手順、本番構成も記録します。
より多くのチームが承認済み結果あたりのコストを報告するようになれば、このベンチマークの中核的な判断はより強固になります。比較の大半がトークン単価と公開試験にとどまるなら、成果ベースの選定は専門家向けの慣行にとどまるでしょう。
第2のシグナルは、軌跡テレメトリによって駆動されるモデルルーティングです。リサーチエージェントは、ターン数、重複検索、コンテキストの増加、バリデーターの失敗、エスカレーション頻度を公開すべきです。
ルーティングシステムはこの証拠を用いて、単純なタスクをLunaに割り当て、難しい業務をTerraまたはSolへエスカレーションできます。ただし、ルーティングポリシーは、失敗した初回試行をすべて含めた後でも、単一モデルのベースラインを上回らなければなりません。
ルーティングが品質やレイテンシを弱めずに承認済み結果のコストを下げるなら、ワークロード形状は実用的な価格設定の入力要素になったと言えます。エスカレーションが節約分を消費してしまうなら、より単純なモデル割り当ての方が引き続き信頼できます。
第3のシグナルは、モデル、サービス、または商用条件の変更後に繰り返されるベンチマークです。OpenAIとAWSは2026年に、Bedrock上のOpenAIモデルおよびエージェントインフラを含む、より広範な提携を開始しました。Amazon partnership により、両社には共同提供を継続的に調整する理由があります。
各変更は、推奨される構成を変える可能性があります。改訂されたモデルは、より少ないトークンで済むかもしれず、ツールにより確実に従うかもしれず、長文の完了率を向上させるかもしれません。リージョンのサービス更新は、品質に影響せずレイテンシだけを変える可能性があります。
元のベンチマークは、再実行が重要である理由をすでに示しています。更新された商用条件は、過去の回答を変えずに成果ランキングを変えました。将来のモデル改訂は、方程式の両側を動かし得ます。
チームは、モデルバージョンが変わったとき、重要な料金更新が届いたとき、本番プロンプトが変化したときに再評価を予定すべきです。また、観測された失敗パターンが元の評価セットに似なくなった場合にも、テストを再実行すべきです。
実行可能な出発点は控えめです。既知の50〜100件のタスクを選び、合格ルールを定義し、意図した本番設定で各候補を実行します。失敗、再試行、ターン、トークン、レイテンシ、レビュー工数を数えます。
そのうえで、承認済みの成果に消費されたリソースを計算します。勝者を選ぶ前に、失敗カテゴリを確認してください。平均では経済的に見えるモデルでも、ビジネスリスクが最も大きいケースで失敗する可能性があります。
Amazon Bedrock 上の OpenAI モデルには現在、その判断を行うための公開フレームワークが用意されています。長期的に有効な示唆は、特定の GPT-5.6 バリアントがすべてのワークロードで勝つということではありません。最も安価なトークンも、システムがそれを許容可能な成果物へ変換するまでは、事業価値を持たないということです。
標準モデルの選択を更新する前に、測定可能な問いを一つ投げかけてください。組織が実際に利用できる回答、軌跡、または成果物を一つ得るごとに、完全なワークフローはどれだけ消費しているのか。
