AIアプリビルダーの料金は、何を作業として数えるかで決まる

週100回のプロンプト反復で最も安いプランは、たいてい各プロンプトの周辺作業を最も少なく数えるものです。月額の表示価格だけでは、再試行、計画、テスト、デプロイ、バックグラウンドで動くエージェントが同じメーターに触れるかどうかが分かるまで、ほとんど判断できません。

チームがサブスクリプション価格を100プロンプトで割ってプランを比べる場面を見てきました。その計算はきれいですが、誤りです。ボタンの文言を変えるプロンプトとデータベース構造を変えるプロンプトは、入力する人にとってはどちらも1メッセージです。しかし請求額は大きく異なることがあります。正直な比較は、まず作業負荷の台帳を作り、同じ台帳に各ベンダーの課金ルールを当てはめるところから始まります。

この記事では、特定のベンダーの実際の価格ではなく、仮想の料金表を使います。購入前に実際のプラン条件へ置き換えられる計算方法を示すことが目的です。

同じプロンプト数でも請求額は3通りになり得る

ユーザーメッセージ数は会話を測るものであり、計算量や完了した作業を測るものではありません。クレジット制はモデルの活動を計測しやすく、タスク制はベンダーが定義した作業単位を計測し、定額制は一定の境界内での利用権を売ります。アプリも週100件の依頼も同じでも、この境界の違いで合計は変わります。

たとえば、創業者が毎週、小さな画面変更を70件、複数ファイルにまたがる変更を20件、ビルドまたはデプロイに関する変更を10件依頼するとします。画面上の数は100です。その裏でビルダーはリポジトリを調べ、計画を作り、モデルを何度も呼び出し、テストを走らせ、失敗した編集を直し、アプリを再ビルドし、チャットの返答が出た後もエージェントを動かすかもしれません。あるプランはモデル呼び出しごとに課金します。別のプランは一連の流れ全体を1タスクと呼ぶかもしれません。サブスクリプションには含まれる場合も、上限がある場合も、一部が超過料金になる場合もあります。

購入者がよく混同するのはここです。反復とはユーザーが判断する一連のサイクルで、課金イベントとは売り手が計測対象に選んだものです。両者を同義に扱うと、最も曖昧な料金ページのプランが有利になります。チームがアプリをそのプラットフォームに預けた後、安く見えたプランが高くつく原因にもなります。

比較では、毎月を4週間とみなすのではなく、月平均の4.33週を使います。週100回の反復は月433回になります。この小さな補正だけで33回増え、再試行やバックグラウンドジョブはまだ計算に入っていません。

見積もりを頼むときは、単に合計を予測してもらうのではなく、作業を分類するようベンダーに求めると役立ちます。何がメーターを動かすのか。いつ止まるのか。失敗した実行も数えるのか。自動再試行も数えるのか。画面で完了と表示された後にも続く作業は何か。未使用の容量は繰り越せるのか。答えが請求額を決めます。

計算機を開く前に、1つの作業負荷を決める

実際に想定する作業から代表的な1週間を作り、プランを比べる前に固定します。料金モデルごとに作業負荷を変えると、価格ではなく営業文句を試すことになります。

ここでの比較では、次の週間作業負荷を使います。

• 小さな編集70件、各1クレジット単位
• 複数ファイルの変更20件、各3クレジット単位
• ビルドまたはデプロイの変更10件、各5クレジット単位
• 再試行25回、平均2クレジット単位
• 合計45クレジット単位を消費するバックグラウンド実行35回

依頼された100回の反復は、初回試行で仮想クレジット180単位を消費します。再試行で50増えます。計画、インデックス作成、テスト、デプロイの作業で45増えます。週間合計は275単位、平均的な月では1,190.75単位です。

同じ活動は、タスク課金では別の形になります。毎週、ユーザーが開始するタスクは100件、再試行の開始は25件、バックグラウンドタスクの開始は35件です。週160イベント、月692.8イベントになります。この692.8件すべてが課金対象かは、契約でのタスク定義次第です。

成功した作業と失敗した作業は分けて記録してください。画面に見えるエラーメッセージだけから失敗率を出すと、目立たない修復、自動モデル切り替え、テストの再実行を見落とします。利用データを出力できるなら、チャット履歴よりよい証拠になります。チャットは複数のエージェント実行を1つの返答にまとめることがあるからです。

普段起きる厄介さを含む1週間を使いましょう。曖昧なプロンプト1件、依存関係の競合1件、関係ない理由で失敗するテスト1件、デプロイの修復1件です。きれいなデモの週から作った予算は、実際の開発が始まるまでしか持ちません。

備えのために作業負荷を膨らませないでください。観測した基準値を計算してから、別に変動分の余裕を加えます。基準値と余裕を分ければ、通常作業が高いのか、忙しい月への保険を買ったために高いのかが分かります。

クレジットパックはビルダー内部の動きに課金する

クレジットパックは、プラットフォームの単価が低く、未使用クレジットが使えるだけ長く残り、ビルダーの修復回数が少ないと安くなります。単純な依頼が、ユーザーに見えない複数のモデル呼び出しに広がると高くなります。

クレジットは標準単位ではありません。トークン、モデル呼び出し、エージェントのステップ、秒数、または加重した組み合わせを表す場合があります。ベンダーは高速モデルと高性能モデルに異なるクレジット数を設定することもあります。2つのパックのクレジット数を比べても、両方のプラットフォームが同じ方法で消費量を定義していなければ意味がありません。実際には、そうであることはまれです。

仮想作業負荷を、500単位で$30のパックで計算します。月間需要は1,190.75単位です。パックは分割できないため、購入者には3パック必要で、支払額は$90です。クレジットが失効しなければ、月末には309.25単位が残ります。パックには1単位6セントと書かれていても、未使用容量を買う必要があったため、消費した作業の実効コストは約7.56セントです。

繰り越しがあれば結果は変わります。残りの309.25単位が有効なら、翌月は3パックではなく2パックで済むかもしれません。数か月にわたり利用が安定すれば、平均コストは表示単価に近づきます。クレジットが月ごとに失効するなら、使えずに残った分も価格の一部です。モデルから外してはいけません。

プロンプト数を変えずに、モデルの選択で消費量が変わることがあります。複雑な編集を4単位倍率のモデルへルーティングするプラットフォームでは、最も難しい10件が請求額の大部分を占めるかもしれません。ルーティングは自動か、後から確認できるか、上限を設定できるかを聞いてください。2回失敗して再試行する安いモデルは、1回で成功する高性能モデルより高くつく場合があります。

クレジットパックは、不規則なプロジェクトに向いています。クレジットに十分な有効期間があれば、作業が発生したときに支払えるためです。一方で、自由に試行錯誤するチームでは予算化が難しくなります。メーターは行動を変えることがあります。無関係な依頼を大きすぎるプロンプトにまとめたり、テストを避けたり、クレジットを節約するために弱い出力を受け入れたりします。その選択は請求額を下げますが、アプリを傷つけます。

厄介なのは、バックグラウンド作業がクレジットを消費すべきかという点です。リソースを使うため、課金には筋があります。問題は、購入者が予測も停止もできないときです。公平に評価するには、画面で各バックグラウンド料金を確認できるか、残高がゼロになる前に支出上限が新しい作業を止めるかを確認します。

タスク課金は、タスクの始まりと終わりに左右される

タスク制は、計画、モデル呼び出し、テスト、修復を含めて1回の試行を1価格で扱うなら、最も安いモデルになり得ます。内部の動作すべてが新しいタスクになると、最も高くなります。

台帳にある開始イベントごとに、仮想単価$0.14を当てはめます。月692.8イベントなら、セント単位に丸めて$96.99です。料金ページで14セントが小さく見えても、これは$90のクレジットパックより高い金額です。

ここで契約の1文だけを変えます。433回のユーザー依頼の反復だけに課金し、再試行とバックグラウンド作業は各タスク内に含めるとします。月額は$60.62まで下がります。アプリは何も変わっていません。タスクの境界が変わり、その境界によって$36.37が動きました。

完了タスク課金には、もう1つ定義が必要です。実行でファイルが変わってもデプロイに失敗した場合、プラットフォームではタスクが完了したのでしょうか。ユーザーが結果を却下して修正を求めた場合、それは新しいタスクか継続か。ベンダーには1料金で無制限の作業を防ぐルールが必要です。しかし購入者にも、活動ログから再現できるルールが必要です。

成功したプロンプト1件あたりのコストを比べるというよくある勧めは、成功が自己申告なら誤りです。ユーザーは部分的な結果を受け入れ、大きな依頼を分け、出力を手作業で修正します。記録上の成功あたりの低コストは、何時間もの後片付けを隠すことがあります。チームがマージ、デプロイ、その他の方法で結果を残すと決める地点を使い、承認された変更1件あたりのコストを比べてください。

タスク価格には、単位が人に分かるものに対応する場合、予算上の利点があります。チームは何百万トークンより、承認された変更400件の方を自信を持って見積もれます。製品がインデックス作成、計画、テスト、デプロイを別タスクと呼ぶなら、その利点は消えます。単位が安定していると判断する前に、実際の請求書や利用データのイベント名を読んでください。

同時実行の仕組みも確認しましょう。2つのエージェントを同時に動かせば経過時間は短くなりますが、タスク開始は2倍になるかもしれません。テストエージェントを起動するバックグラウンド修復は、1回、2回、または課金なしで数えられる可能性があります。請求額は時計ではなくメーターに従います。

定額サブスクリプションが有利なのは、含まれる境界の内側だけ

定額サブスクリプションがこの作業負荷で最も安くなるのは、月433回のユーザー反復、108.25回の再試行開始、151.55回のバックグラウンド開始すべてを月額に含む場合です。どれかのカテゴリがサブスクリプション外なら、定額プランが安いと結論づける前に足してください。

対話型と再試行を合わせて600回まで、バックグラウンド実行を200回まで含む、仮想の月額$79プランを使います。この例では月に対話型と再試行が541.25回、バックグラウンドが151.55回発生します。どちらも上限内なので、料金は$79のままです。この前提では、定額制は$90のクレジットパックと$96.99の開始タスク制を上回ります。

「無制限」という言葉に、スプレッドシート上の価値を与えてはいけません。実際の公正利用しきい値、同時実行の上限、モデル制限、速度低下のルールに置き換えてください。ベンダーが境界を示さないなら、低い場合と高い場合をモデル化します。無限に使えるという解釈でしか安く見えないプランには、信頼できる価格がありません。

定額プランには段差コストもあります。含まれる実行が599回なら、もう1回は無料かもしれません。600回に達すると、次の実行で超過料金が発生したり、上位プランが必要になったりします。少なくとも3つの作業負荷を描いてください。静かな月、予想する月、リリース月です。予想ケースだけでは、サブスクリプションが跳ね上がる地点を隠してしまいます。

課金が作業ではなく利用者に従う場合、シート数も重要です。1人用の$79プランは、チームが同じ433回の反復を共有していても、必要な4シートなら$316です。アカウント共有が許されると決めつけないでください。プロンプトを確認し、デプロイを承認し、利用状況を見る必要がある人を価格に入れます。

定額料金なら、失敗した案ごとに目に見える少額課金が生じないため、健全な試行錯誤を促せます。一方、プラットフォームがアカウントを制限するまで無駄を隠すこともあります。利用状況の可視性は依然として大切です。エージェントがループしていないか、リリース月に含まれる境界を越えるかを知る必要があります。

年額割引は最後に計算へ入れてください。まず月額条件で最も安いモデルを見つけます。その後で割引と拘束のコストを当てはめます。3か月で使わなくなるツールに10か月分を払っても節約ではありません。

再試行は注記ではなく基準値に入れる

再試行は通常の開発作業です。初回の出力がすべて完璧だと仮定する料金比較は、購入判断には使えません。役立つ数字は、総試行回数を依頼した反復回数で割った再試行増幅率です。

この例では、依頼100回に対して対話的な試行は125回で、再試行増幅率は1.25です。これはプロンプトの25%が単純に失敗するという意味ではありません。明確化が必要な依頼もあれば、編集はコードチェックを通るものの意図を外す場合もあります。ツールや依存関係に原因がある失敗もあります。プランが追加の試行を計測するなら、課金への影響は同じです。

2人が一貫して適用できるルールで再試行を測りましょう。以前の出力を却下または修復した後、ユーザーが同じ意図した結果を繰り返し求めた場合に再試行として数えます。本当に新しい要件は再試行に数えません。ユーザーが目にしない自動再試行は別にタグ付けしてください。

小さなパイロットには、難しくなると予想するタスクを含めるべきです。ランディングページの文言や色の変更だけを試しても、データベース移行、認証、状態管理、モバイルビルドでの再試行率はほとんど分かりません。候補ごとに少なくとも1つのリスクの高い変更を通し、活動記録を確認してください。

再試行の影響はモデルごとに異なります。

• クレジット課金では通常、すべての試行で消費したリソースに課金します。
• 開始タスク課金では、再試行がイベントを作るなら通常は各試行に課金します。
• 完了課金では、完了ルールによって失敗した試行を吸収する場合があります。
• 定額課金では、含まれる上限または公正利用の制御に達するまで再試行を吸収します。

無料の再試行という回答だけで済ませないでください。同じモデルを使うのか、自動フォールバックが別枠を消費するのか、無料の再試行期間がどれほど続くのかを聞きましょう。翌朝に送った修正は、作業が明らかに同じでも新しいタスクになるかもしれません。

人の再試行コストもあります。ユーザーが修復を毎回見守る必要があるなら、ドルでは安くても注意力の面で高くつくプランです。パイロット中、承認された変更1件あたりのレビュー時間を記録してください。その時間をプラットフォーム請求額に無理に入れる必要はありませんが、低価格が悪い作業フローを隠せないよう、請求額の横に表示しましょう。

バックグラウンドエージェントは見えない倍率になる

バックグラウンドのエージェント作業は、ユーザーが返答を見た後も続く可能性があるため、独立した行として記録しなければなりません。リポジトリのインデックス作成、計画、依存関係チェック、テスト、ビルド監視、デプロイ、修復エージェントは、別のチャットメッセージを増やさずに予算を消費することがあります。

この例では、週35回のバックグラウンド実行と45クレジット単位を割り当てています。この数字は意図的に見える仮定です。パイロットの利用記録に置き換えてください。ベンダーが合計しか示さないなら、任意の自動化を無効にして同じプロンプトを1回実行し、有効にしてもう1回実行します。差分は証明ではなく推定ですが、作業を無料扱いするよりましです。

計画モードには特に注意が必要です。計画によって早い段階で競合を見つけ、失敗する高価な実装を減らせる場合があります。一方で、些細な編集の前にも有料のステップを追加することがあります。小さな変更と大きな変更を分けて試してください。スキーマ変更と複数ファイルの作業には計画を使い、文言編集では省く、といった方針が適切かもしれません。

インデックス作成のコスト構造は異なります。リポジトリ全体の初回読み取りは高価でも、後の差分更新はほとんどかからない場合があります。初期インデックス作成を含む1週間のパイロットは定常状態のコストを大きく見せることがあり、本番リポジトリがずっと大きければ逆に過小評価します。セットアップ時の消費と継続的な消費を分けてください。

テストとデプロイは、任意の無駄ではありません。クレジット枠に合わせるためにオフにすると、失敗の発見をユーザーへ移すだけです。守るためのチェックも含め、実行するつもりの安全なワークフローに価格を付けてください。テストを無効にした比較は、間違った事業上の問いに答えています。

Koder.aiは計画モード、デプロイとホスティング、スナップショットとロールバック、ソースコードのエクスポートをサポートしています。パイロットではチャットメッセージだけでなく、こうしたワークフローの部分も観測できます。ここでのサイト情報は階層の存在を示すもので、現在の利用枠は示していないため、プラン名と価格は現在の製品画面で確認する必要があります。

製品で許されるならバックグラウンド予算を設定してください。ただし、上限と予測可能性を混同してはいけません。上限は作業を止めることで超過支出を防ぎます。エージェントが追加容量を待つ間、アプリはリリースに間に合わないかもしれません。金銭上の制限と運用上の結果の両方を記録します。

すべての候補を同じ台帳に通す

台帳があれば比較を再現でき、請求書の争いになる前に契約の曖昧さを見つけられます。1行には1つの計測イベントを記し、クレジット、タスク、サブスクリプションの利用枠に対応づけるための十分な文脈を入れます。

パイロット中は、このCSVヘッダーをコピーして使ってください。

week,event_id,requested_iteration,event_type,outcome,retry_of,background_kind,credit_units,task_events,flat_bucket,notes
2026-W01,001,1,user_edit,accepted,,,1,1,interactive,copy change
2026-W01,002,2,user_edit,rejected,,,3,1,interactive,multi file edit
2026-W01,003,2,retry,accepted,002,,2,1,interactive,repair after failed test
2026-W01,004,2,background,completed,,test,1,1,background,automatic test run

イベント種別と結果は分けてください。バックグラウンドのテストは成功して完了しても、依頼された変更は承認に至らないことがあります。これらを1つの状態にまとめると、ベンダーの完了タスクルールを検証できません。

週の終わりに、4つの値を計算します。

monthly_iterations = weekly_requested_iterations * 4.33
monthly_credits = weekly_credit_units * 4.33
monthly_task_events = weekly_task_events * 4.33
retry_amplification = (user_attempts + retry_attempts) / requested_iterations

次に、行を変えずにプラン条件を当てはめます。仮想料金表では次の計算です。

credit_cost = ceil(1190.75 / 500) * $30 = $90.00
started_task_cost = 692.8 * $0.14 = $96.99
flat_cost = $79.00, because 541.25 interactive runs < 600
             and 151.55 background runs < 200

スプレッドシートでは、使えずに残るクレジット、残っている利用枠、次の価格境界も示すべきです。例で勝つプランには、対話型で58.75回、バックグラウンドで48.45回の余裕があります。デプロイ作業が2倍になるリリース週には十分な余裕ではないため、契約前にそのケースも計算すべきです。

匿名化した台帳の1ページをベンダーに確認してもらいましょう。どのプランが一番安いかは聞かず、各行をどう分類するかを聞きます。書面の分類は営業上の見積もりより役立ちます。最初の請求書と比べられるからです。

表示価格より変動の方が重要

例の結果は、定額サブスクリプションが$79、クレジットパックが$90、開始タスク課金が$96.99です。この順位は、ここで示した料金表と作業負荷にだけ当てはまります。再試行の扱いや含まれるバックグラウンド作業が少し変わるだけで、順位は逆転します。

各ペアの損益分岐点を計算してください。未使用クレジットに将来価値がないと仮定すると、月間需要が3パック以上必要なとき、$79の定額プランは$30のクレジットパックを上回ります。繰り越しにより全単位を使えるなら、6セントずつで$79は約1,316.7クレジット単位に相当します。それより少ない利用量では、使い切るクレジットの方が安くなります。

$0.14の開始タスクと比べると、$79は約564.3イベントに相当します。予想の692.8イベントはこの地点を超えます。ただしタスクプランが433回の依頼された反復だけに課金するなら、料金は$60.62で勝ちます。ここでも、見出しの単価より1つの定義が重要です。

見積もりが正確だと装わず、感度分析をしてください。この作業負荷では、再試行増幅率を1.10から1.50へ、バックグラウンド作業を週20イベントから60イベントへ変え、複雑な編集の消費量にはベンダーが示した妥当な倍率を当てはめます。何十通りものシナリオは要りません。判断を変え得る少数の変数が必要です。

単位コストとは別に、資金繰りと拘束も考えます。パックは柔軟性を残せます。月額サブスクリプションは境界内にいる間、予測可能な上限を作ります。年額サブスクリプションは柔軟性と割引を交換します。ソースコードのエクスポートとスナップショットはビルダーを離れるコストを下げられますが、移行を無料にはしません。エクスポートしたアプリにも、動くビルド、インフラ、保守できる人が必要です。

利用量が不確かな創業者は、下振れリスクが見えるモデルを選ぶべきです。予想月額が少し高くても、繰り越し期間の長いパックが適することがあります。安定して測定できる作業のチームは、含まれる利用枠の中ほどに収まる定額プランを選べます。タスクプランは、承認された成果にきれいに対応し、修復作業をタスク内に含む場合に向いています。

例で勝ったプランを選ばないでください。すべての仮想単価と利用枠を確認できる条件へ置き換え、すべての作業負荷の仮定をパイロットの観測値に置き換えてから選びます。

課金モデルを受け入れテストにかける

別の人が台帳とプラン条件から月額合計を再現できるなら、その料金モデルは判断の準備ができています。計算に、営業担当者が後から内部タスクを解釈することが必要なら、そのモデルはテストに失敗しています。

次の簡潔な受け入れチェックリストを使ってください。

1. 代表的な依頼反復を100件記録します。すべての主要な作業種別を含む、より小さなサンプルでも構いません。
2. 再試行、自動再試行、計画、テスト、ビルド、デプロイ、その他のバックグラウンド実行にタグを付けます。
3. 各イベントを、ベンダーのクレジット、タスク、または含まれる利用枠のルールに対応づけます。
4. 同じ4.33の係数で、予想月、静かな月、リリース月の合計を計算します。
5. プラン条件を保存し、最初の実際の請求書を予測と比べます。

パイロット前に許容差を決めます。たとえば、予測を10%超上回る合計は調査する、と決められます。この割合は業界標準ではなく、管理上の選択です。イベント履歴が残っている間に見直しを促すことが目的です。

実際の利用量が予測を超えたら、原因となった行のカテゴリを見つけます。承認された作業が増えたことと、再試行が増えたことは別です。計画されたデプロイ実行が増えたことと、エージェントのループも別です。対処は、より大きなプラン、より狭いエージェント方針、より明確なプロンプト、または課金修正かもしれません。合計だけでは見分けられません。

最初の3回の請求サイクルでは、台帳を請求書の横に置いてください。静かなパイロットでは、バッチジョブ、リリース作業、自動修復を見逃すことがあります。したがって、週100回の反復で最も安いモデルには条件がありますが、判断を曖昧にする必要はありません。明示した例では、$79の定額サブスクリプションが勝ちます。成功範囲のタスク課金では、同じ作業は$60.62となり、タスク課金が勝ちます。繰り越しによって無駄を防げるなら、低い利用量や一時的な利用増ではクレジットパックが勝ちます。何を数えるかを書き出し、隠れた作業を測り、請求書で約束を確かめてください。