同じ依頼を6回投げたら、6本とも「累計値」に騙された

何を投げたか

6回とも同じプロンプト・同じファイルです。差はモデル設定と、実行ごとの確率変動だけです。

結果

黄色は700字の制約超過。円換算は $1=¥150（https://api.teai.io/v1/models/pricing の usd_jpy、2026-11-04取得）。文字数は空白除去後。

• 平均: auto 235.7秒 / $0.02683（¥4.02）、cheap 301.9秒 / $0.02279（¥3.42）
• 標準偏差（標本, n−1）: auto 2.6秒 / $0.00411、cheap 307.9秒 / $0.01135

（auto #1 と #2 がともに 237.2 秒なのは、ログの記録粒度が0.1秒のためです。同一値が偶然か丸めかを切り分けるには、より細かい粒度での再測定が必要です＝未確認。）

平均だけ見ると cheap がわずかに安く、中央値では auto のほうが安い。3回ずつの比較でこの差に意味はありません。

この記事で「差がある」と言える範囲

平均の差（auto ¥4.02 / cheap ¥3.42）は n=3 では意味がありません。同じ理由で、分散の差（auto 幅4.5秒 / cheap 幅603.5秒）も、この3回だけでは偶然を排除できません。以下で扱うのは「差の証明」ではなく、6本の実行ログに現に記録された手数の内訳です。設定の優劣ではなく、次に自分で測るときの観測項目として読んでください。

単価は同じ。違うのはトークン量だけ

teai/auto と teai/cheap は、料金表上は同じ単価です（入力 $0.15 / 出力 $0.60 per 1M tokens）。実際の請求額が単価×トークンで説明できるか確認しました。

料金APIは sell_per_1m_tokens_in / sell_per_1m_tokens_out という別項目も返しますが、これも両IDで同値でした（0.117211 / 0.174075）。請求額と一致したのは input_per_1m_tokens / output_per_1m_tokens のほうなので、本記事はそちらで計算しています。

• auto 合計: 入力 362,753 / 出力 43,461 tokens → 0.362753×0.15 + 0.043461×0.60 = $0.0805（実測 $0.08049）
• cheap 合計: 入力 238,844 / 出力 54,228 tokens → 0.238844×0.15 + 0.054228×0.60 = $0.0684（実測 $0.06836）

費用 = 入力tokens/1e6 × 0.15 + 出力tokens/1e6 × 0.60

つまり差額は単価ではなく、読んだ量と書いた量です。auto は cheap より39%多くトークンを使い、18%高い請求になりました。cheap という名前から「同じ仕事が安くなる」と期待すると、この範囲では外れます。

（内部でどの基盤モデルが選ばれたか、各リクエストがどの経路を通ったかは未確認です。実行ログに出るのは teai/auto / teai/cheap というIDだけでした。）

もう1つ、計算していて気づいた点があります。実行ログには cache.read が記録されており、6回合計で約776万トークン（auto 2,566,400 / cheap 5,190,400）でした。しかし請求額は上の式（input＋output のみ）と6回すべてで小数第5位まで一致し、cache read は課金に含まれていません。単価表にも項目がありません。意図的な仕様か計測上の扱いかは未確認なので、この点は費用の見積もりに使わないでください。

（なお reasoning フィールドは全ステップで0でした。推論トークンの有無は、このログからは判断できません。）

639秒かかった回に何が起きていたか（1例の分解）

639秒かかった cheap #3 を1本だけ分解します。これは「cheapの性質」ではなく「1回の実行で起きたこと」です。

1ステップあたり = 待ち時間 ÷ ステップ数

1ステップあたりは 4.0〜19.8秒と、ここも5倍振れています。「推論が速い/遅い」と「手数が多い/少ない」は両方効いており、片方だけでは説明できません。cheap #3 は手数が突出していたため、合計が最も伸びた回です。

cheap #3 は 639.1秒・71ステップのうち、22回のファイル書き込みと13回の編集、24回の文字数チェックを繰り返しました。「700字に収める」という制約に対して、書いては測り、測っては書き直す往復が発生しています。

最終的な文字数（空白除去）は 645字で制約内。つまり制約は満たしたが、そのために長時間を使った回です。

逆に cheap #2 は 35.6秒・9ステップで終わり、832字で制約を超過しました。速い回は、確認が足りない回でもあります。

（639秒の内訳がキュー待ち・推論・ツール往復のどれに寄っているかは未確認です。分離できていないため「手数が主因」は、ステップ数と文字数チェック回数からの推論です。）

中身の比較：5本は同じ結論、1本は誤読

元ログと突き合わせた結果です。

外した1本（cheap #2）は「ログインへ」列が全期間0であることを「できた100件が全損」と読み、最大損失をそこに置きました。0件の列は通過率0%ではなく計測されていない可能性が高く、実際この列は216スナップショットすべてで0です。

既停止群の扱いでは4本が外しました。配分は {"std": 1, "annual": 1} で、founder・trial7・first480 はすでに0です。それでも「founderの配分を下げる」「trial7を停止」と書いた回答が4本ありました（auto #1、cheap #1、cheap #2、cheap #3）。auto #2 は「配分0で停止済み」と明記し、auto #3 も「既に0で凍結済み」と書いています。この2本だけが通過です。なお cheap #1 は trial7 についてだけ「配分0のまま再開しない」と書いていますが、founder を停止対象に残しているため外れとして数えました。

6本すべてが見落としたこと

ログの 2026-11-02 13:55 の項目に、こうあります。

完了画面にProリンクが0個だった（料金は注意書きの一文のみ）。価格以前に課金の入口が無かった。
koe-edge PR#159 マージ・本番反映: 完了画面にProカードを追加

つまりこの広告の累計値は、課金導線が無かった期間と、あった期間の合計です。6本のうち5本は累計の「できた100 → 決済画面3 = 3.0%」を現在の実力として扱い、「課金導線が最大の穴」と結論しました（auto #1・#2・#3、cheap #1・#3）。残る cheap #2 は最大損失を「できた→ログインへ」の全損100件としましたが、これは全期間0件の列を「100%離脱」と読み替えただけで、累計値を現在の実力として扱った点は同じです。6本すべてが、累計の区切りを確認していません。

変更の前後で分けると、数字は変わります。

7.1% = 2 ÷ 28      1.4% = 1 ÷ 72

（境界は13:17と14:17のスナップショットの間。13:55の変更はログの記述のみで、その時刻のスナップショットは無い）

決済画面3件の発生時刻も偏っています。11/2 13:17（変更前）に1件、11/4 14:03 と 14:17（変更後）に2件。3件のうち2件は直近24時間です（216スナップショットを走査し、決済画面の累計が増えた時刻を抽出）。

なお、13:55のメモに書かれた「累計¥40,048」は、その前後のスナップショット（13:17: ¥42,335 / 14:17: ¥42,770）と一致しません。メモとスナップショットで集計基準が違う可能性があるため、前後分割はスナップショット側の値で行いました。ログ自体にこの不整合がある点は、後述の限界に含めます。

1件あたりの費用も変わります。

• 累計: ¥53,354 ÷ 3 = ¥17,785/決済画面
• 変更後のみ: ¥11,019 ÷ 2 = ¥5,510/決済画面

サンプルは n=28・2件で、確度は低い。それでも「3%だから導線が壊れている」と「7.1%で、直近に動き始めた」では、次にやることが変わります。前者なら導線の再設計、後者ならサンプルを増やして7.1%が再現するかを見るです。

ログに書いてある変更履歴を読まなかった、というより、累計値の定義（いつからいつまでか）を確認しなかったのが原因です。これは auto と cheap の両方で起きました。モデル設定を変えても直らない種類の誤りです。

自分に置き換えると：手元のログをモデルに渡すとき、「この指標はいつからいつまでの累計か」「その期間中に何を変えたか」を必ずセットで渡す。今回の6本は、そこが唯一の共通の弱点でした。設定を変えても直らないので、プロンプト側で塞ぐしかありません。

月3〜8万円のAPI利用に当てはめると

1回 ¥3.96（auto の中央値）を基準にすると、月7,500回で約¥30,000。この規模で auto と cheap の差は、中央値なら ¥0.04/回＝月 約¥300、平均なら ¥0.60/回＝月 約¥4,500です。しかも中央値では auto が安く、平均では cheap が安いと符号が入れ替わります。n=3 でこの差の向きが決まらない以上、費用は判断材料になりません。判断すべきは費用ではなく、時間と正しさです。

仮に10回に1回 639秒かかると、月7,500回では750回×10.7分＝約133時間の待ちが発生します（これは仮定の試算であり、本記事の実測ではありません）。

実務での判断

1. 費用の見積もりは中央値で置き、上限は最大値で置く。cheap の中央値は ¥4.00 でも、最大は ¥4.75、時間は639.1秒でした。平均だけ見ると足元をすくわれます。
2. 「安い設定」を選ぶ基準は単価ではなくトークン量。今回は同じ単価表で、消費トークンが39%違いました。
3. 累計値を渡すときは、いつ何を変えたかを一緒に渡す。6本とも、そこだけが共通の弱点でした。プロンプトに「ログ内の変更履歴を確認し、変更前後を分けて計算せよ」の1行を足すだけで、この6本の結論は変わっていたはずです。
4. 自分の環境で確かめる：直近50回の実行ログから p50 / p95 / 最大 を出し、費用は「中央値×回数」で予算化する。本記事の6本はその前段の観測例です。

この比較で言えないこと

なお「同じ設定でも実行ごとに出力が振れる」こと自体は既知です。コード生成では同一プロンプトで一致する出力が1つも出ないタスクが47.56〜75.76%に達し、temperature=0 でも決定性は保証されないことが報告されています（Ouyang et al., "An Empirical Study of the Non-determinism of ChatGPT in Code Generation", arXiv:2308.02828, 2024-10改訂）。本記事が足せるのは、その振れが費用・待ち時間にどう現れるかの1例と、累計指標が制度変更を隠すという別種の落とし穴です。

• n=3。1タスク・1データ・1日。設定間の優劣を統計的に主張するには足りません。
• 裾は測れていません。n=3では p95・p99 は算出できません。実運用の判断には、自分のワークロードで50回以上ログを取り、p50/p95を出す必要があります。
• 内部のモデル経路は未確認。teai/auto が何を選んだかは実行ログから分かりません。
• 「品質」の採点は筆者1人。上の検査項目は機械的に判定できますが、文章の読みやすさや優先順位の妥当性は主観です。
• cheap が常に安いわけではない。単価が同じなので、トークン量と手数が支配します。
• ログ側の欠測。広告グループ別の費用・CPA・売上・LTVは元ログにありません。申込 ログインへ 見込み¥/人 は全期間0で、未配線か実ゼロかは不明です。
• 閲覧646 > クリック476 の定義差も未説明のままです。
• 元ログに内部不整合があります。13:55のメモの累計額が前後スナップショットと合わず、累計費用が2回（10/28 00:17、11/2 19:17）減少しています。ログの集計基準そのものが揺れている可能性があり、前後分割もその影響を受けます。
• 直接API直叩きとの比較は範囲外。読者の実際の選択肢は「auto vs cheap」ではなく「teai経由 vs 直接」かもしれませんが、今回は測っていません。

生データ

6回分の実行時間・費用・トークン数・ステップ数・ツール呼出・文字数を公開します。単価は https://api.teai.io/v1/models/pricing（2026-11-04取得）です。