Lunaを先に使えば安くなりますか？

必ずしも下がりません。追加のモデル呼び出し、再試行、人の確認を含め、同じ品質条件の全件Sol処理と比較します。

モデルの自信だけで切り替えてよいですか？

それだけでは不十分です。独立したラベルで校正し、確認可能な失敗やリスク条件も使います。

いいえ。任意の費用単位による教材です。料金表でもモデル実測でもありません。

Lunaで一次処理しSolへ切り替える構成は、受理した結果の誤りが許容範囲内で、総費用も低い場合に初めて採用理由ができます。 最初の安い呼び出しだけを数えると、追加処理や人の対応を見落とします。

2026年9月24日にLunaとSolの文書を確認しました。一次処理と追加確認への割り当ては仮説であり、測定済みの品質順位ではありません。教材は事前に作成した記録のみで、APIを呼びません。

構造化抽出の課題を使い、分類、注文番号、引用を返します。完了、解析可能、スキーマ適合、原文との一致を確認しても、分類の意味までは保証されません。

受理、Solへの切り替え、人の確認の3経路を分けます。情報不足なら質問が必要なこともあり、すべての失敗を別モデルに送るわけではありません。返金などの行為には別途権限確認が必要です。

ルールをバージョン管理します。途中で閾値を変えたら旧版を残し、評価用データを再実行して、異なる条件の結果を混ぜないでください。

追加確認へ回った例だけを調べると、検証を通り抜けた誤りが見えません。受理済みの記録を、自信の値に依存せず抽出して確認します。

誤受理件数を受理件数で割った値と、全件数で割った値を区別し、標本数と抽出方法を記録します。少数の選別例から本番の誤り率は推定できません。まれでも損失の大きい分類や言語を別に見ます。

モデルの自信は校正済み確率とは限りません。スコアを使うならラベル付きデータで閾値を設計し、別の評価用データで確認します。回答したモデルだけを唯一の審査役にはしません。

元の問い合わせごとに、初回、Sol、失敗した再試行、外部ツール、人の対応をひも付けます。その日・供給元・モードに合う実使用量と料金を使い、過去の請求を現在価格で書き換えません。

経路費用 = 一次処理 + 追加処理 + 再試行・ツール + 人の対応

トークン単価ではなく、完了して合格した仕事当たりで比較します。未解決を隠すと、難しい仕事を捨てた構成が安く見えます。人の対応は時間と換算条件を明記するか、所要時間を分単位で別に表示し、ゼロと仮定しないでください。

展開したディレクトリで次を実行します。

python3 lab.py routing

4件の記録は任意の費用単位を使った教材です。米ドル価格でも、モデルの生成結果でも、実測の節約額でもありません。

問い合わせ	経路	仮の総単位	事前に設定した判定結果
T1	受理	1	正しい
T2	追加処理	5	正しい
T3	受理	1	誤り
T4	人へ	10	正しい

合計は17単位です。全件Solの仮定値16はトークン費用だけで、品質も人の対応費も測っていません。したがって勝者を選べる比較ではなく、最初の4呼び出しだけでは節約を示せない例です。受理2件中1件の誤りも、Lunaの実測誤り率50%を意味しません。

同じ評価入力、分類規則、スキーマ、判定方法を使います。供給元、モデルID、effort、予算、ツール権限を固定し、統一できない条件は記載します。サービス状況が遅延に影響するなら実行順序をランダム化し、実時間を測ります。

基準側も再試行と人の確認を計上します。分類別品質、合格したタスク当たりの費用、未解決数、遅延分位数と標本数を比較します。繰り返しは不安定さの発見に役立ちますが、小標本の代表性を保証しません。

先に業務上の許容範囲を決め、それを満たす閾値を選びます。試行段階で人の承認を残すのも妥当です。Sol料金とLuna料金は使用量の解釈に使い、同一課題の評価の代わりにはしないでください。