GPT-6・Claudeの比較を続けて、成功1件あたりのコストを計算してみた

前回の記事では、GPT-6、Claude、Gemini、Grokの性能とAPI料金を用途別に整理しました。料金表を並べてみると、次に気になったのは、やり直しまで含めて何件の仕事が終わるかです。今回は、普段の業務に持ち込むための比較方法を考えます。

2026年9月27日時点の公式情報を確認しています。ここで行ったのは評価条件の設計と費用の試算です。各モデルを同じ課題で実行したベンチマークではなく、後半の成功率も説明用の仮定です。

ここでいう評価は、入力と合格条件を用意し、結果が条件を満たすか確かめる作業です。私はまず、最初の回答で合格した割合と、再試行後に合格した割合を分けて残すことにしました。

前回のLunaからSolへ切り替える試算では、失敗を検出できることを前提にしました。ここが少し気になっています。JSONとして読めても、抽出した金額が間違っていれば仕事は終わっていません。

Anthropicの評価設計の記事でも、エージェントの発言と、実際に達成した結果を区別しています。修正したと言うだけでは不十分で、対象の不具合が直り、既存の動作も維持されているかを確認する考え方です。Anthropicの評価設計

そこで、私なら最初の比較用に次の3種類を用意します。まず各10件の計30件から始める設計です。30件で一般的な優劣を断定するつもりはありません。自分の仕事でどこを間違えるかを探すための入口にします。

正常な入力だけでは判断しにくいので、日付が書かれていない文書や、似た金額が二つ出てくる文書も混ぜます。実際に問題になった入力を使う場合は、社内で利用できる範囲に整えてから固定します。

たとえば項目抽出なら、次のような小さな課題にします。これは架空の文書です。課税の判断をさせる問題ではなく、書いてある値をそのまま取り出せるかを見ます。

次の文書からJSONオブジェクトを1つ返してください。
キーはinvoice_no、invoice_date、subtotal_jpy、tax_jpy、total_jpy、due_dateです。
金額は整数、日付はYYYY-MM-DD形式です。
記載のない項目はnullにしてください。期日は推測しないでください。
説明文やMarkdownのコードフェンスは付けないでください。
対象文書:
請求番号: NX-0927
発行日: 2026年9月27日
税抜金額: 120,000円
消費税: 12,000円
請求合計: 132,000円
お支払期日: 別途ご相談

正解データは次の形です。モデルの出力をJSONとして読み込んだうえで比較します。キーの順番や空白の違いは採点対象にしません。

{"invoice_no":"NX-0927","invoice_date":"2026-09-27","subtotal_jpy":120000,"tax_jpy":12000,"total_jpy":132000,"due_date":null}

この課題なら、形式チェックに加えて値の一致も確認できます。期日に月末の日付を補ってしまったら不合格です。数字を文字列で返した場合も、整数という仕様を満たしていません。

ただし、正解データがあるのは評価用だからです。本番の未知の請求書では、合計の整合性や原文との対応も見ます。それでも通り抜ける誤りはあるので、合格扱いの結果も抜き取りで確認します。形式チェックだけで上位モデルへの切り替えを決めると、この差を見落とします。

コード修正なら同じコミットから始め、前の試行の変更を残さないようにします。資料要約なら入力ファイルを固定します。比較中に資料を差し替えると、モデルの差なのか入力の差なのか分からなくなります。

思考設定も記録します。同じhighという名前でも、会社をまたいで同じ計算量を意味するとは限りません。私なら、まず通常運用したい設定で比べ、制限時間と費用の上限を揃えます。設定を変えた試行は別の行に残します。

ここでいう独立の3回と、失敗時の再試行は別です。良かった1回だけを採用すると、普段どのくらい安定して通るかが見えません。集計では成功数と試行数を併記し、同じ課題の繰り返しを別の90種類の課題として扱わないようにします。

実行日も残したい理由があります。OpenAIは9月25日、GPT-6 Sol / Lunaの画像理解を低下させていた画像エンコードの不具合を修正したと案内しました。画像入力を使う場合には再評価を勧めています。9月24日の結果があったとしても、画像の読み取りについてはそのまま現在の評価にしない方がよさそうです。OpenAIの更新履歴

API単価から仕事の費用へ移るために、次の式で集計します。分子には失敗分も含めます。分母は再処理を重複して数えず、合格した元の依頼の件数です。成功が0件なら、費用を0円にせず算出不可とします。

成功1件あたりのAPI費用
  = 全依頼の初回・再試行・ツールの課金合計 ÷ 最終的に合格した依頼数

前回と同じく、1回あたり入力2,000、課金対象の出力500トークンで計算します。出力には課金される推論分も含む仮定です。通常処理の短い入力を想定し、キャッシュ、検索、税は除外します。トークン数と合格率を仮に置いた計算で、実際の処理量を予測したものではありません。

GPT-6 Lunaの入力・出力単価は100万トークンあたり$0.10・$0.50、Solは$2・$10です。この条件では1回あたりLunaが$0.00045、Solが$0.009になります。OpenAIの公式料金案内

1,000件を処理する設計について、次の仮定を置きます。Lunaの初回は800件合格し、残り200件をすべて検出できるとします。その200件をSolで再処理すると160件が合格する設定です。Solだけを使う場合は、1,000件中950件が合格する別の仮定を置きます。

表の成功単価は小数第7位を四捨五入しています。二段階の費用は1,000 × $0.00045 ＋ 200 × $0.009 = $2.25です。合格数は800 ＋ 160 = 960件になります。Lunaだけの行は成功単価が最も低いものの、200件が未完了です。必要な合格率を満たすかも一緒に見ないと、安さだけで選んでしまいます。

この表から二段階の方が高精度だとは言えません。Solによる救済率80%は、Lunaが落とした200件に対する条件付きの仮定です。全体でのSolの成功率95%を、そのまま失敗した課題に当てはめるのも違います。似た誤りをするモデル同士なら、切り替えても残る失敗があるはずです。

また、この例は失敗をすべて検出できる理想条件です。実運用では、検証を通った誤答と、正しいのに再処理へ回した件数を別に数えます。二段階処理を比較するなら、この検出部分まで含めて一つの仕組みとして評価します。

同じ入力・出力量で計算する限り、Luna全件＋Sol再処理の費用は$0.45 ＋ $9 × 再処理率です。Sol全件の$9より安い境目は、再処理率95%未満になります。これはAPI料金だけの境目です。再処理時に履歴を追加したり出力が長くなったりすれば、式も変わります。

数字だけを見ると余裕がありそうですが、私はここに待ち時間と人の確認を足したいです。たとえば1,000件で人の確認が合計60分増え、社内の時間単価を仮に3,000円と置くと、それだけで3,000円です。API費用は米ドルなので、円へ換算してから加算します。時間単価も為替も、実際の条件に置き換えます。

自動で完了した件数と、人が修正して完了した件数も分けます。人の作業を分子に足したうえで、修正済みの件数を分母へ入れるのが業務全体の費用です。自動処理だけの数字と混ぜないようにします。

これは前回の比較を踏まえた試す順番です。新たな実測順位ではありません。AstraやFableを使う理由も、難問で最終的な合格件数が増えるか、修正時間が減るかで確かめたいと思います。

検索が絡む比較では、全モデルに同じ保存済み資料を渡す評価と、検索から任せる評価を分けます。前者は読み取りを、後者は道具を含めた調査全体を見ます。GrokのX Searchには、トークン料金とは別に取得した投稿・プロフィールの件数に応じた料金があります。検索を呼んだ回数だけでは集計できません。GrokのAPI料金

最初は、次のようなCSVで十分だと思います。task_idは元の依頼、trial_idは独立した繰り返し、attemptはその中の初回・再処理を区別する番号です。合格条件を変えた場合には、eval_versionも変えます。

eval_version,task_id,trial_id,attempt,model_id,run_at,settings,passed,failure_reason,api_cost_usd,tool_cost_usd,elapsed_seconds,human_minutes

元のAPIレスポンスの使用量も別に保存します。集計時には、出力に推論分が含まれているかを各社の仕様で確認し、二重に足さないようにします。キャッシュを使う評価に進めるときは、読取だけでなく作成・保存にかかった分も対象です。

今回計算してみて、単価表の次に作るべきものは、自分の仕事の合格条件だと感じました。次はこの条件を固定して少数の課題を回し、失敗した結果と検証を通り抜けた誤りを読みたいです。その記録が揃ってから、常用モデルと切り替え先を決めるつもりです。

ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。

• 選考ではありません
• 履歴書不要
• 技術の話が中心
• 所要時間30分程度
• オンラインOK

エンジニアと話してみる