サブスクリプションとトークン単価制には明確な損益分岐点がある

サブスクリプションがトークン単価制より安くなるのは、使える1回の試行あたりの月額コストが、同じ受け入れ済み作業を生み出す従量課金コストを下回ったときです。これは当然に聞こえますが、ほとんどの比較ではプロンプト数を単位にしています。プロンプト数はほぼ役に立ちません。チームが支払うのは受け入れ済みの機能であり、プロンプトから受け入れ済み機能になるまでの間には、再試行、増えていくコンテキスト、放棄した分岐、最低シート数があります。

正しい計算は、1通のメッセージではなく1つの機能から始めます。その機能に何回の試行が必要か、失敗のたびにトークン使用量がどう変わるか、残さないコードを生むだけで有料の容量を消費する試行の割合はどれくらいかを見積もります。次にその機能モデルを1か月へ広げ、サブスクリプションの実際の制限を適用します。損益分岐点は万能の再試行率ではなく幅で考えるべきです。機能の規模とコンテキスト運用は、表示価格以上に判断を動かすことがあるためです。

重要な単位は受け入れ済み機能

受け入れ済み機能とは、チームが完了と数える最小の作業単位です。たとえばAPIにつながったログイン画面、テスト付きの請求Webhook、正しく保存されるモバイルフォームです。チームがすでに計画で使っている区切りを使ってください。エンジニアがデータモデルを修正したりテストを書き直したりしなければならないなら、見栄えのよい初稿を受け入れ済みとして数えません。

各機能について、受け入れまでの試行回数を記録します。試行は、モデルが実質的な実装案を出せるだけのコンテキストを受け取った時点で始まり、チームが受け入れる、却下する、方針を変える時点で終わります。ファイルの場所を尋ねるような小さな追加質問は、周囲の試行に含めてかまいません。完璧な分類より、一貫性のほうが重要です。

基本の従量課金コストは次のとおりです。

metered_feature_cost = sum(attempt_input_tokens * input_rate
                         + attempt_output_tokens * output_rate
                         + tool_charges)

請求書に実際に載る料金を使います。キャッシュ済み入力、推論トークン、画像入力、ツール呼び出しの料金が異なるなら、別々の項として扱ってください。混合トークン単価を使うのは、自社の利用構成から計算した後の簡易見積もりに限るのが妥当です。

サブスクリプション側にも同じ境界が必要です。

subscription_feature_cost = allocated_monthly_subscription_cost
                            / accepted_features_within_plan

これでよくある誤りがすぐ見えてきます。プラン料金をすべてのチャット数で割ると、失敗したチャットや些細なチャットが分母を膨らませるため、サブスクリプションが安く見えます。トークン請求額を成功したプロンプトだけで割ると、失敗分が消えるため、従量課金が安く見えます。両方とも受け入れ済み機能を基準にしなければなりません。

人による修正時間は別に追跡します。これはより広い開発コストの判断には入りますが、エンジニアの給与を片方だけに混ぜると価格比較が歪みます。まず同等の成果物に対するプラットフォーム支出を比べます。その後、一方がレビューや修正時間を一貫して変えるなら人件費を加えます。

再試行率は試行回数を非線形に変える

再試行率とは、ある試行が失敗し、次の試行が必要になる確率を指します。再試行があった機能の割合ではありません。この2つの定義では予測が変わります。各試行の失敗確率が独立に r であるなら、成功までに必要な期待試行回数は次のとおりです。

expected_attempts = 1 / (1 - r)

再試行率20%なら期待試行回数は1.25回です。50%なら2回、80%なら5回です。再試行自体も失敗し得るため、曲線は急になります。1 + r で計算すると、再試行を最大1回しか数えず、複雑な作業を大幅に過小評価します。

独立性は近似にすぎません。失敗した試行は、曖昧な要件、不慣れなフレームワーク、コンテキストに残り続ける悪いアーキテクチャ判断の周辺でまとまりがちです。実用的な予測では、サンプルから直接試行回数を計算してください。

observed_attempts_per_feature = total_material_attempts / accepted_features
observed_retry_rate = (total_material_attempts - accepted_features)
                      / total_material_attempts

受け入れ済み機能40件に重要な試行が68回必要だったなら、1機能あたりの試行回数は1.7回、観測された再試行率は約41%です。この観測比率には繰り返しの失敗もすでに含まれており、記憶から行動を復元するより安全です。

すべての改訂を失敗と見なさないでください。たとえば、最初にスキーマ、次にAPI、最後にインターフェースを作るという計画的な流れには、複数の成功段階があります。新しい試行が、本来なら受け入れチェックを通るべきだった作業を置き換えたり修正したりするときに再試行として数えます。この区別は重要です。反復は生産方法であり、再試行は手戻りです。同じものとして価格を付けると、意図的な分解を不当に高く見積もることになります。

予算では少なくとも2つの再試行帯を使ってください。通常の機能はチームの中央値付近に収まり、移行、不慣れな統合、曖昧な創業者からの依頼は再試行の多い帯に入ります。単一の平均値では、プラン上限を消費しがちな裾野のコストを隠してしまいます。

コンテキストの増加は再試行そのものより高くつくことが多い

繰り返しの試行でトークン数が同じになることはほとんどありません。最初の試行には、簡潔な仕様と数個のファイルだけが含まれるかもしれません。4回目には、元の依頼、生成コード、エラー出力、テスト失敗、修正内容、さらに多くのリポジトリコンテキストが含まれることがあります。従量課金では、提供元がより低いキャッシュ済み入力料金を適用しない限り、繰り返した入力もその都度請求される可能性があります。

入力の増加は、観測したトークン数または倍率でモデル化します。

input_tokens_on_attempt_n = initial_input_tokens * growth_factor^(n - 1)
output_tokens_on_attempt_n = initial_output_tokens * output_factor^(n - 1)

最初の試行で入力30,000トークン、出力4,000トークンを使うとします。試行ごとに入力が35%増え、出力が変わらない場合、4回目の試行では入力が約73,800トークンになります。見た目が同じようなチャット吹き出しが5つあっても、請求額が5回とも同じになるわけではありません。

指数的な増加はストレステストに便利ですが、多くのツールはコンテキストを切り詰め、要約し、キャッシュし、選択的に再読み込みします。実際に使っている動作を測定してください。利用可能ならトークン使用量をエクスポートし、代表的な1週間についてリクエスト単位の数を記録します。インターフェースがトークンを隠すなら、ファイルサイズとメッセージ履歴からコンテキストを見積もり、正確だと思い込むのではなく、低い倍率と高い倍率を試してください。

分岐の影響もあります。2回失敗した後、チームは汚染されたコンテキストを取り除くため、新しい会話を開くことがあります。これは繰り返し入力を減らしますが、準備用トークンを追加し、チャット内にしかなかった決定を失うかもしれません。リセットは、新しい最初の試行に固定の再構成コストを足したものとしてモデル化します。

reset_cost = repository_context + specification + accepted_decisions

これにより、コンテキスト衛生にも価格が付きます。すべての失敗を1つのスレッドに残すと、トークンがより多くかかるかもしれません。失敗するたびにリセットすると、リポジトリマップと仕様を繰り返すことになります。経済的なリセット時点は、スレッドがどれだけ速く増えるか、会話をまたいでキャッシュが維持されるかによります。

サブスクリプションプランでも、トークン単価が表示されないからといってコンテキストが無関係になるわけではありません。大きなコンテキストは使用量枠を速く消費し、スロットリングを引き起こし、月額プラン内で完了できる機能数を減らすことがあります。含まれる利用は、無限に無料のトークンではなく容量として扱ってください。

1つの式で損益分岐点を求める

明確な比較では、月間の受け入れ済み機能数を共通の成果物として使います。変数を次のように定義します。

• S: 必須シートを含む月額サブスクリプション総額。
• F: 月間の受け入れ済み機能数。
• A: 受け入れ済み機能1件あたりの期待試行回数。
• C(A): コンテキスト増加を含む、その試行回数の従量トークンおよびツールコスト。
• L: 制限または超過料金が発生する前にサブスクリプションが支えられる受け入れ済み機能の最大数。

含まれる容量の範囲内で、サブスクリプションが有利になる条件は次のとおりです。

S / F < C(A), provided F <= L

同じことを月間機能数の損益分岐点で表すと、次のようになります。

F_crossover = S / C(A)

チームが F_crossover を超える同等の機能を完了し、プラン容量内に収まるなら、サブスクリプションのほうが安くなります。下回るなら従量課金のほうが安くなります。機能の規模にばらつきがあるときは、1つの平均値を掛けるのではなく、実際の構成全体の従量コストを計算してください。

再試行率について具体的に解くには、A = 1 / (1 - r) と、増えていくコンテキストのコスト関数を代入します。1回の試行コストが等しい c の単純な場合は次のとおりです。

S / F = c / (1 - r)
r_crossover = 1 - (c * F / S)

この近道が使えるのは、試行ごとのコストがほぼ同じ場合だけです。後の試行でより多くのコンテキストを持つなら、候補となる再試行率ごとに C(A) を計算し、月間従量コストが S を超える最初の割合を探してください。段階的なキャッシュとプラン制限に無理に閉形式の式を当てはめるより、小さなスプレッドシートのほうが分かりやすいです。

行に再試行率、列に月間機能数を置いた表を使ってください。各セルには metered_monthly_cost - subscription_monthly_cost を表示します。負なら従量課金が安く、正ならサブスクリプションが安いことを意味します。容量超過の印も別に加えます。金額面で有利でもプランの利用枠を超えるセルは、使える損益分岐点ではありません。

試算例で隠れた変数が見える

月額1シート120ドルのサブスクリプションを評価している4人のプロダクトチームを考えます。したがってプランの月額は480ドルです。これは例示用の価格であり、特定サービスの価格を示すものではありません。チームは1か月に中規模の受け入れ済み機能を24件完了すると見込んでいます。

入力、キャッシュ済み入力、出力の実際の利用構成を反映すると、従量料金は入力1トークンあたり0.000006ドル、出力1トークンあたり0.000018ドルになります。このワークフローでは課金対象ツールを使わないため、ツール料金は除外します。最初の試行は平均して入力40,000トークン、出力5,000トークンです。再試行ごとに入力は30%増え、出力は5,000トークンのままです。

再試行がない場合、1機能のコストは次のとおりです。

40,000 * $0.000006 + 5,000 * $0.000018 = $0.33

24機能で7.92ドルにすぎないため、従量課金が明らかに有利です。独立した再試行率が50%なら、期待試行回数は2回です。1機能あたり2回の試行と近似すると、次のようになります。

attempt 1: 40,000 input + 5,000 output = $0.33
attempt 2: 52,000 input + 5,000 output = $0.402
feature total: $0.732
monthly total: $17.568

それでもサブスクリプションは大きく不利です。この例では、コンテキストが増えながら5回試行しても、1機能あたり約2.42ドル、月額約58ドルです。最初の機能が小さくトークン単価が低い場合、再試行率が高いだけで480ドルのプランが経済的になるわけではありません。

次に、再試行率ではなく機能規模を変えます。リポジトリ全体に及ぶリファクタリングでは、入力900,000トークン、出力35,000トークンから始まり、入力は25%ずつ増えます。同じ料金なら最初の試行は6.03ドルです。5回試行すると約41.88ドルかかります。このような機能が24件なら、従量課金は約1,005ドルに達します。サブスクリプションが有利になる可能性はありますが、そのワークロードをプラン容量が支えられる場合に限ります。

コンテキスト増加前の概算しきい値には、試行コストが等しいという近道を使えます。$S = 480、$F = 24、最初の試行コスト $c = 6.03 とすると、次のとおりです。

r_crossover = 1 - (6.03 * 24 / 480)
            = 0.6985

概算の損益分岐点は再試行率69.85%です。後の試行は6.03ドルを超えるため、コンテキストの増加を含めるとこのしきい値は下がります。シナリオ表では、誤った小数点以下の精度を主張せず、現実的な損益分岐点を試した割合の間に置けます。

この例は、他人の再試行率のしきい値をそのまま使えない理由も示しています。最初のコンテキストを40,000トークンから900,000トークンへ変える影響は、失敗率を少し変える影響よりはるかに大きいものです。割合ではなく、方法を使ってください。

シート数が有利なトークン比較を覆すことがある

サブスクリプションの料金は通常アクセスに付き、従量課金は消費に付きます。ときどきプロンプトを使う10人のチームでは、使用量の大半を2人が作っていても、10シートが必要になるかもしれません。この違いは、現実的な再試行率では届かないところまで損益分岐点を動かすことがあります。

S は日常的なアクティブユーザーではなく、請求対象のシート数から計算します。

S = required_seats * seat_price + fixed_plan_fees

次に、実際にサブスクリプションを必要とする作業へ結果を配分します。デザイン、プロダクト、エンジニアリングの全員がレビューやプロンプトのために直接アクセスを必要とするなら含めます。関係者がエクスポート結果を読むだけで、規約がその運用を認めているなら、不要なシートを想定しないでください。人数は契約と実際のコラボレーション形態で決まります。

シート利用率にも独自の比率があります。

seat_utilization = active_prompting_days / available_workdays

利用率が低いからといって、そのシートが自動的に無駄とは限りません。リリースマネージャーはデプロイ週だけツールを使うかもしれませんが、高価な引き継ぎを防いでいる可能性があります。それでも、あまり使われないシートを多数必要とするプランは、適切なアクセス制御を備えた従量課金アカウントと比べるべきであり、最も使う2人のトークン請求額と比べるべきではありません。

チームの成長は段差のある関数を作ります。5人目の採用で、月の機能成果物は一部しか増えないのに、シート料金が丸ごと1つ加わることがあります。従量コストはその人の実際の利用に応じて増えます。現在の人数と、契約期間中に見込む人数の両方でモデルを実行してください。

年額割引も同じように扱います。契約総額を月額相当に換算し、利用が少ない月を織り込みます。割引された年額の月額換算値を、使用量がピークの月のトークン請求額と比べないでください。休日、採用の空白期間、静かな保守期間を含む年間ワークロードと年間コストを比べます。

使用量制限が2つ目の損益分岐点を作る

サブスクリプションは紙の上では安くても、含まれる容量に上限がある、スロットリングされる、フェアユース規則があるなどの理由で、ワークロードを処理できないことがあります。最初の損益分岐点は金額面のものです。2つ目は運用面、つまり必要な時間枠の中でモデル化した試行をプランが完了できるかどうかです。

プランの上限は、提供元が適用する単位で表します。メッセージ数、重み付けされたリクエスト、コンピューティングクレジット、トークン、ローリング時間枠かもしれません。同じ試行分布を使って、その上限を受け入れ済み機能数へ換算します。

feature_capacity = usable_monthly_units
                   / expected_units_per_accepted_feature

広告上の最大値ではなく、使える単位を使ってください。調査、計画、まれに起きる深刻な再試行連鎖のために容量を残します。計画したすべての機能が、すべての試行が中央値どおりに動く場合にしか収まらないなら、そのプランはすでにきつすぎます。

チームが上限を超えると、通常は4つのことのいずれかが起こります。リセットまで作業が待つ、リクエストが遅くなる、超過料金が始まる、上位プランを買う、です。実際の結果をモデルに入れてください。従量超過が加わるプランの月額コストは次のとおりです。

hybrid_cost = subscription_cost + max(0, usage - included_usage) * overage_rate

厳格な上限では別の判断が必要です。上限が納品を妨げるなら、名目コストが低くてもそのプランは実行不可能です。架空の金額を割り当てて解決したことにせず、価格と並べて容量不足を報告してください。

使用量の時間枠は月間合計と同じくらい重要です。リリース日の午後に再試行の多い試行が40回集中すると、月の残りが静かでも短いローリング上限に達することがあります。月平均だけでなく、最も忙しい日と週をテストしてください。

Koder.aiにはfree、pro、business、enterpriseの各プランがあるため、関連する比較対象は、表示される最安プランではなく、チームのシート数と容量に合うプランです。計画モード、スナップショット、ロールバックは観測される再試行回数も変え得るため、別のワークフローの再試行率を持ち込むのではなく、チームがパイロットで測定すべきです。

自分をごまかさずにパイロットを測る

有用なパイロットでは、価格判断を再現できるだけの詳細を取ります。安定したチームなら2週間でもよいですが、サンプルには通常の作業と少なくともいくつかの難しい機能を含める必要があります。洗練されたデモ作業だけの期間では、コンテキストも再試行も過小評価されます。

重要な試行ごとに、次の項目を1行ずつ記録します。

• 機能IDと機能規模の帯
• 試行番号と、受け入れまたは却下の結果
• 入力、キャッシュ済み入力、出力トークンまたはプラン単位
• コンテキストのリセット、ツール料金、経過した作業時間枠
• 試行を開始したシートまたは担当者

選択肢間で受け入れテストを安定させます。サブスクリプションのパイロットでは見た目を一目確認しただけで機能を受け入れ、従量課金のワークフローではテストの合格を求めるなら、成果物は同等ではありません。パイロット前に受け入れルールを書き、両方に適用してください。

再試行の原因を分けます。要件変更、モデルの失敗、コンテキスト汚染、ツールの失敗、ユーザーエラーを記録してください。異なる料金プランやインターフェースで改善する原因は一部だけです。要件が3回変われば、どこでも容量を消費します。スナップショットとロールバックのワークフローは悪い分岐のコストを減らせるかもしれませんが、不明確な要件を無料にすることはできません。

最後に、中央値の機能、再試行の多い機能、実際の月間構成という3つの見方を計算します。中央値は通常の経済性を示します。高い帯は容量をテストします。構成が請求額を決めます。単一の平均値では、実際には起こらない月を表してしまうため、3つすべてを報告してください。

不確かな入力には感度チェックを行います。機能数、再試行率、コンテキスト増加、シート数を1つずつ増やします。10%の変化で選択が逆転するなら、短い契約を交渉するか、チームがより多くのデータを得るまで従量課金を維持してください。あり得るすべてのケースが同じ選択肢を支持するなら、判断は安定しています。

考え方ではなくワークロードの形でプランを選ぶ

トークン単価制は、利用がまばらな場合、小さなコンテキスト、実験的なチーム、止めても問題のないワークロードに向いていることが多いです。未使用のアカウントでは推論コストがほとんど、またはまったく発生しないため、限界価格も明確です。その代わり、長いコンテキストと繰り返しの失敗にさらされます。特に複数のエージェントやツールが見えないリクエストを追加する場合は注意が必要です。

サブスクリプションは、安定した処理量、高価な機能、含まれる容量を超えずに大半のシートを使えるチームに合います。予測可能性には価値がありますが、その価値をトークンの節約と呼び替えてはいけません。サブスクリプションが200ドル高くても、経理が受け入れない請求額の変動をなくせるなら、予測可能性の価格として200ドルを記録してください。

再試行が多く感じたらプランを切り替えるというよくある勧めは誤りです。人は痛みを伴う5回試行の機能を覚え、安価に成功した十数件を忘れます。請求書はトークンを重く見ますが、記憶は不満を重く見ます。1か月分の試行レベルのデータがこのずれを解消します。

新しいモデルにアクセスできると宣伝されているからというだけで、サブスクリプションを選ばないでください。モデル選択がコストへ影響するのは、受け入れられる作業、消費するトークン、発動する容量ルールを通じてです。より高性能なモデルは試行回数を減らすかもしれませんが、1トークンあたりの料金が高いことがあります。安いモデルは小さなインターフェース変更には成功しても、横断的なデータ移行では時間を消費するかもしれません。パイロットを機能帯で分け、各選択肢で有能な担当者が実際に選ぶモデルを使わせてください。

同じルールはエージェント数にも当てはまります。画面上の1つのユーザープロンプトが、インターフェースの裏で計画、実装、レビュー、修正のエージェントを起動することがあります。従量課金ではすべてのリクエストが数えられる一方、サブスクリプションでは作業が重み付け使用量単位に換算されるかもしれません。各側で見えるメッセージを1つずつ比べないでください。受け入れ済み機能全体を比較し、各請求書またはプランが示す消費単位を記録してください。

不確実性には、自信に満ちた推測ではなく予算項目が必要です。各入力に低い値、想定値、高い値を持たせます。想定値はパイロットから得るべきです。低い値と高い値は任意の割合ではなく、観測したばらつきを反映させます。3つの組み合わせすべてを計算し、どの入力が判断を変えるかを特定します。コンテキスト増加で答えが変わり、シート数では変わらないなら、人数についてもう1週間議論するより、優れたコンテキスト計測のほうが価値があります。

契約期間は許容できる余裕を変えます。月額プランならチームはすぐ離れられるため、推定損益分岐点の近くで試せます。年契約ではワークロード変化の余地が必要です。静かな四半期や空席のシート2つを吸収できる額など、契約前に必要な節約幅を決めてください。この余裕はビジネス上の選択であり、数学的な損益分岐点の一部ではないため、別に示します。

税金、為替換算、コミットメント支出クレジットは請求書の層に属します。生のサービス消費量を計算した後、一貫して適用してください。期限切れになるクレジットは、期限までにチームが使う見込みがある場合にだけコストを下げます。大量の未使用クレジット残高は節約ではありません。チームが受け入れ済み作業へ変えられなかった前払い容量です。

最後に、測定の担当者を決めます。実際の使用量を予測と照合する人がいなければ、正確な損益分岐点モデルも、機能規模、モデル、料金、人員の変化とともに劣化します。価格が変わったとき、チームがシートを追加したとき、1機能あたりの観測試行回数が大きく動いたときに見直してください。これは小さな運用作業です。入力を更新し、古いシナリオを残し、なぜ選択が依然として有効なのか、変更が必要なのかを記録します。

承認前に、前提を運用上の約束として読み直してください。受け入れ済み機能30件という予測は、プロダクトに十分に仕様化された作業があり、レビュー担当者が評価でき、プランがチームの勤務時間中に提供できることを意味します。レビュー容量が成果物を18件に制限するなら、30件を使うと、受け入れ済み作業を増やさずにサブスクリプションを安く見せることになります。コスト比較がプラットフォームだけを対象にしていても、分母には納品システム全体を反映させなければなりません。

提供元が許すなら、混合課金も試してください。利用の多い2人にはサブスクリプション、たまに使う人には従量アクセスという組み合わせが、全員シート制と全員従量制の両方を上回ることがあります。各グループを別々に計算してからコストを足します。シート料金を適用する前に利用の多い人と少ない人を平均化しないでください。その平均は誰も表さず、避けられるシートを隠すことがあります。

調達部門から損益分岐点となる再試行率を1つだけ求められることがあります。その場合は、名前を付けた前提に結び付けた幅を伝えます。たとえば、月間受け入れ済み機能数が観測した2つの値の間にあり、コンテキストが測定した帯の範囲で増えるなら55%から65%とします。容量が破綻する割合も含めてください。1つの割合より整ってはいませんが、リリース月と保守月が異なるときにははるかに役立ちます。

更新判断から埋没費用を除いてください。チームが次の期間に何を買うか決めるなら、サブスクリプションにすでに約束した費用が、次の従量リクエストを無料に見せるべきではありません。ただし現在の支払い済み期間では、未使用の含有容量に限界現金コストがないことがあります。モデルが今すぐの振り分け判断を支えるのか、将来の契約判断を支えるのかを明記してください。これらの問いではコストの境界が異なります。

セキュリティ、データの保管場所、ソースのエクスポート、デプロイ、ロールバックは、価格を計算する前に選択肢の適格性を決めることがあります。これらの要件は、作り出した金額調整ではなくフィルターとして扱います。必須要件を満たせない選択肢は除外してください。残った選択肢だけでコストを比べます。これにより、チームが譲れない制約を低いトークン見積もりが覆すことを防げます。

却下された機能と放棄された機能も記録してください。従量料金は機能が中止されても残り、サブスクリプションでは回収できない容量を消費します。成功した機能全体に静かに広げるのではなく、そのコストを放棄の区分に割り当てます。次に、それを引き起こしたプロダクト領域へ放棄を配分する別の見方を実行します。これにより、価格の問題が実は仕様の問題なのかが分かります。

金額を丸めるのは表示時だけにしてください。特にキャッシュ済み入力と未キャッシュ入力の価格が異なる場合、計算内部ではトークン数と料金の精度を保ちます。ただし、損益分岐点の再試行率は幅または整数の割合で報告してください。62.437%のような結果は、入力値が裏付けない知識を示しているように見えます。

判断では、受け入れ済み機能あたりのコストと、最も忙しい利用時間枠における受け入れ済み機能の容量という2つの数字を並べて書きます。前者は、サブスクリプションとトークン単価制が金額面で交差する場所を示します。後者は、その交差点が実際に利用可能かを示します。どちらかが欠けているなら、そのスプレッドシートが説明しているのは価格であり、実際の本番ワークロードではありません。