MakeのCreditsとは？

MakeではCreditsとOperationsを同じ言葉として扱わない

MakeではCreditsが購入・消費するbilling unit、OperationsがScenario内でmoduleがデータを処理・確認した活動です。多くの非AI appでは1 operation = 1 creditが基本ですが、すべての機能が常に1:1ではありません。

MakeのAI Providerや一部のadvanced機能では、token、file size、page count、run timeなど実際の使用量でcreditsが変わる場合があります。つまり『moduleが5個あるから毎回5 credits』は、標準的なScenarioの入口としては使えても万能式ではありません。

料金表を読む前に、この2語を分けておくだけで見積りミスはかなり減ります。Operationsは何をしたか、Creditsはそれにいくら消費したか、です。

• Credits：契約で購入し、機能利用で消費する単位
• Operations：moduleがデータを処理・確認した活動
• 多くの非AI app：原則1 operation = 1 credit
• AI/advanced機能：token等によるdynamic usageがあり得る

見積りは『月間イベント数 × 実際に走るoperations』から始める

AI等の例外を除く基本Scenarioなら、1件の業務イベントがどのmoduleを何回通るかを数えると概算できます。ただしRouter、繰り返し、複数bundle処理があると、operation数は見た目のmodule数と一致しません。

たとえば1つのmoduleが5件のbundleを処理すれば、1つの箱に見えても複数operationsになることがあります。図の箱を数えるのではなく、データが何回処理されるかを数えます。

この式はFineInTheoryの編集用モデルで、Makeが保証する料金計算式ではありません。契約量を決める前にScenario historyやCredit Usageで実測し、概算との差を確認します。

• 編集用基本式：月間イベント数 × 1イベントあたり想定operations
• Router/bundleで実行回数が増える点を考慮
• AI/Code等は個別credit ruleを確認
• 契約量を決める前に実際のScenarioでusageを確認

例：月1,000件なら、まず1件を分解する

仮に月1,000件のフォーム送信を処理し、各件でCRM登録・Slack通知・Spreadsheet記録の3処理が1回ずつ走るなら、標準的な1 operation = 1 creditのmoduleだけで構成した場合、編集上は約3,000 operations相当から考え始められます。

ただしこれは価格見積りの考え方を示す仮例です。Triggerの動作、bundle数、AI、Code、error/retryなど実際のScenario条件で変わるため、契約量をこの数字だけで確定しません。

• 仮定はEDITORIALとして明示
• 公式billing ruleはFACTとして分離
• 実測値で補正
• 価格改定時も業務量の仮定は再利用可能

Credits枠だけでなく、超過時と必要機能を見る

MakeのPricingはFreeから複数の有料PlanとCredit枠を提示しています。Plan選定では想定Creditsだけでなく、必要機能と追加Creditsの条件まで確認します。

Creditを毎月超過する前提のPlanは、たぶんPlan選びをやり直した方が早いです。価格と枠は変わり得るため、契約時に最新の公式Pricingを再確認してください。

• 想定credits/月
• 必要Plan機能
• 追加credits/超過条件
• 支払周期
• 契約時に公式Pricingを再確認