Agentforceの従量課金と席課金を選ぶ：実行ユーザーと業務完了単価から見積もる

AIエージェントの予算を決めるとき、月額ライセンスとアクション単価だけを並べても、実運用の原価は決まらない。
Agentforceでは、同じ処理でも実行ユーザーや権限によって従量課金の対象が変わる。
さらに、課金された処理が何回成功したかと、顧客の依頼が何件完了したかは、それぞれ数える必要がある。

Salesforceは2026年9月3日、Agentforce SalesやServiceなどにCore、Advanced、Maxという新しいエディションを発表した。AI、分析、セキュリティなどをまとめたパッケージだ。[1]

購買単位がまとまっても、実装を見ないと決まらない費用は残る。本稿では2026年9月13日に確認した公式料金ページと課金仕様を使い、どの従量料金が消えるのかを先に特定し、その後で業務完了1件当たりの原価を比べる方法を考える。

以下の金額は米ドルの公開表示価格、計算例は筆者が作成した架空のデータである。Salesforce環境で測定した利用実績ではない。

請求までの変換を、業務ログと結び付ける

Agentforceの使用量は、最初から「ドル」や「解決件数」として記録されるわけではない。公式仕様では、機能に応じてアクションやプロンプトなどの使用量を計測し、使用種別ごとの倍率でFlex Creditsへ変換する。[3]

これを費用分析に利用するなら、次のような二つの記録を結ぶとよい。図は請求APIの内部実装ではなく、本稿で提案する分析の構成である。

実行ログには「何を呼んだか」がある。業務側には「注文変更が確定したか」「必要な項目が正しく更新されたか」がある。この二つをつなげると、処理回数の増加が、利用拡大によるものなのか、同じ依頼のやり直しによるものなのかを調べられる。

単価の異なる使用種別をまとめて平均してしまうと、その区別が難しくなる。最初はテキストのアクション、プロンプト、音声、その他サービスを分けたまま集計する。

「自動実行なら従量」とは限らない

公式のGlobal Unmeteringには、対象となるAI機能・エージェント種別、StandardまたはAdminのユーザー、Unmetered User-Based AI権限、その権限を持つcurrent userとしての実行、といった条件がある。[4]

特に見落としやすいのが、レコード更新を起点とするFlowだ。公式の例を必要な部分だけ比べると、次の違いがある。

公式仕様にある実行例	AI使用量の扱い	確認する実装上の差
レコード更新から起動し、適切な権限を持つcurrent userとして動くFlow	条件を満たせばunmetered	実際の実行主体と権限
レコード更新から起動し、Automated Process Userとして動くFlow	metered	自動処理用の実行主体
Agentforce Gridからの使用	常にmetered	機能自体の課金条件

製品別の例外もある。unmeteredにも毎分30 LLM呼び出し／ユーザーの条件があり、確認時点では技術的に強制されていない。[4]

設定面でも、対象ライセンスを購入したという情報だけでは足りない。公式手順は、必要に応じたPermission Set Licenseの割り当て、Permission Setの作成、ユーザーへの権限付与までを含む。[5]

実務では、設計書の「ユーザー操作で開始」という説明だけで判定せず、実際の経路を確認する。たとえば、最初の画面操作の後にバッチへ渡しているなら、画面を押した人と、その後のAI処理を実行する主体を別々に記録する。

この確認は安い実行主体へ付け替えるためではない。利用権、データアクセス、監査上の責任を保ったまま、どの費用が発生する構成なのかを把握するために行う。

席課金と比べるのは、消せる従量料金

2026年9月13日時点の公式料金ページは、Flex Creditsを100,000 credits当たり500ドル、通常のテキストアクションを20 creditsとしている。[2]

この組み合わせで、対象アクション1回の表示単価を計算すると、次のようになる。

$$
p=\frac{500}{100{,}000}\times20=0.10
$$

ただし、この0.10ドルをすべてのAI呼び出しへ掛けてはいけない。アクションとプロンプトは別の使用種別であり、テキストと音声でも条件が異なる。また、変数設定やトピック遷移などはエージェントアクションとしての課金対象ではない。[6]

料金ページには、5ドル／ユーザー／月のAgentforce User Licenseと、125ドル／ユーザー／月のAgentforce add-onも掲載されている。前者はFlex Creditsを必要とし、CRMオブジェクトへのアクセス範囲も限定される。後者は特定のCloud向けの追加機能を含む。[2]

したがって、価格差120ドルを0.10ドルで割った「1,200回」を、そのまま契約変更の分岐点にはできない。機能と利用権が同等であることも、対象の使用量がすべてunmeteredになることも、この二つの価格だけでは確認できないからだ。

先に必要機能と利用権を満たす二つの構成を決める。そのうえで、追加の固定費を $\Delta F$、実際に課金対象から外せるアクション数を $A_e$ とすると、単純化した比較は次のように書ける。

$$
\Delta C=\Delta F-pA_e
$$

ここで $\Delta C$ は、固定費を追加する構成の費用から、比較元の費用を引いた差である。他の費用と業務成果が等しければ、負のときに追加固定費を従量料金の削減で回収できる。

たとえば、ある契約変更による追加固定費が月300ドルだったと仮定する。全体で月10,000回呼び出していても、課金対象から外れるのが1,000回なら削減額は100ドルで、差額は月200ドル増える。外れるのが4,000回なら削減額は400ドルで、差額は月100ドル減る。

これはSalesforceの特定プランの見積もりではない。固定費を回収する変数は総呼び出し数ではなく、同じ契約期間で実際に削減できる課金対象量だという計算例である。

前払い済みの残高が余っている場合も、credit消費量の削減が直ちに現金支出の削減になるとは限らない。公式FAQでは未使用Flex Creditsは次の契約期間へ繰り越されないとされる。[2] 消費額、請求額、支払済み額は別々に見る必要がある。

平均呼び出し数を、完了単価へ変換する

次は従量課金部分の運用品質を考える。ここからの例では、全アクションが通常のテキストアクションとして課金対象になり、1回0.10ドル、値引きと付与creditはゼロと仮定する。

1,000件の業務依頼について、次の架空のログを作る。完了件数は、各依頼の業務条件を確認して数えたものとする。

依頼の群	依頼件数	1依頼当たりの課金アクション数	業務完了件数	アクション費用
定型処理	800	5	760	400.00ドル
複雑な処理	150	25	105	375.00ドル
再試行の多い処理	50	100	20	500.00ドル
合計	1,000	平均12.75	885	1,275.00ドル

全依頼に対する平均費用は1.275ドルだ。しかし完了した依頼1件当たりに、未完了分も含めた費用を配賦すると、次の値になる。

$$
\widehat C_{\mathrm{done}}
=\frac{1{,}275}{885}
\approx1.44
$$

ここで未完了の115件に費やした処理を分子から除かないことが大切だ。除くと、失敗の多い構成ほど安く見える場合がある。

一般に、同じ集計対象について、1依頼当たり平均アクション数を $\bar A$、業務完了率を $\hat s$ と書けば、アクション費用だけの完了単価は $p\bar A/\hat s$ になる。成功とアクション数が独立だという仮定は不要で、総費用と総完了件数の比を変形しただけである。完了件数がゼロのとき、この単価は定義できない。

もちろん実際の原価には、固定費、他サービスの費用、人による確認や修正の時間もある。1.44ドルはそれらを含まない。

少数の長い処理を、件数と費用の両方で見る

上の例では、再試行の多い50件は依頼全体の5%だが、アクション費用の約39.2%を占める。

中央値は5回、nearest-rank方式で求めたp95は25回、p99は100回になる。p95だけなら、最も費用の大きい群の100回が代表値に現れない。パーセンタイルの計算法も含めて記録し、上位群の費用比率と一緒に読むとよい。

次のコードは、その集計を再現する。外部ライブラリやSalesforceへの接続は使わない。

from decimal import Decimal
from math import ceil

# 架空データ: (依頼件数, 1依頼の課金アクション数, 完了件数)
groups = [(800, 5, 760), (150, 25, 105), (50, 100, 20)]
price = Decimal("0.10")

requests = sum(n for n, _, _ in groups)
completed = sum(done for _, _, done in groups)
actions = sum(n * count for n, count, _ in groups)
cost = price * actions
counts = sorted(
    count for n, count, _ in groups for _ in range(n)
)

def nearest_rank(values, percentile):
    return values[ceil(len(values) * percentile / 100) - 1]

tail_cost = price * 50 * 100
print(f"requests={requests}, completed={completed}")
print(f"billable_actions={actions}, cost_usd={cost:.2f}")
print(f"mean_actions={actions / requests:.2f}")
print(f"cost_per_completed_usd={cost / completed:.4f}")
print(f"p95={nearest_rank(counts, 95)}, "
      f"p99={nearest_rank(counts, 99)}")
print(f"top_5pct_cost_share={tail_cost / cost:.2%}")

実行結果は次のとおり。

requests=1000, completed=885
billable_actions=12750, cost_usd=1275.00
mean_actions=12.75
cost_per_completed_usd=1.4407
p95=25, p99=100
top_5pct_cost_share=39.22%

この例から実際の顧客の費用分布を推定することはできない。示しているのは、同じログでも集計する単位によって見える問題が変わることだ。

本番では、長い処理を一律に打ち切る前に、再試行の理由を分ける。入力不足、外部サービスの障害、ツール選択の誤り、確認を要する複雑な依頼では、必要な対策が違う。処理を短縮しても完了率が大きく下がれば、完了単価は悪化しうる。

変更前後を比較するなら、依頼の種類、担当チーム、期間をそろえる。同じ会話から発生した100回のアクションを、独立した100件の業務成功として扱わない。信頼区間を推定する場合も、会話や顧客内の依存が残るなら、そのまとまりを保って再標本化する設計が必要になる。

「解決課金」と、自社が確認した完了を照合する

すべてのAgentforce製品が、前述のアクション課金になるわけではない。公式仕様にはHelp Agent Resolutionsという別の使用種別がある。課金対象の解決には、最低2ターン、最終フィードバックが明示的な否定ではないこと、さらに人へのエスカレーションなしに正常終了するか最終フィードバックが明示的に肯定であること、という条件が記載されている。解決したセッションのアクションとData 360クエリは、別途課金されない。[6]

これに対して、本稿の「業務完了」は、注文やケースなどの状態を自社で確認した結果だ。請求上のresolutionと同一であることを前提にせず、別の列として保存する。

請求上のresolution	自社で確認した業務完了	調べること
あり	あり	通常の完了原価
あり	なし	判定条件の違い、確認の遅れ、処理内容の不一致
なし	あり	請求単位と業務単位のずれ、他経路での完了
なし	なし	中断や未解決の理由、追加対応の費用

この照合表は異常の断定ではない。たとえば業務側が翌日に状態を確定するなら、時点の違いだけで不一致が生じる。依頼を開始した時期で集計対象を定め、十分な観測期間を置いてから完了を判定する。

Conversation課金も別の選択肢だが、公式FAQでは同一orgでFlex Creditsとの併用はできない。[2] 依頼ごとに安い課金方式へ切り替えられるという計算を、そのまま運用設計へ持ち込まない。

本番で集める記録と、予算の扱い

最初に保存したいのは、依頼ID、業務の種類、エージェントのバージョン、実行主体、使用種別、課金対象量、完了判定、確認や再処理に要した時間だ。これらは本稿が提案する分析項目であり、そのまま存在するSalesforceのフィールド名ではない。

公式には、AI使用量のデータモデルでunmetered分やその理由も確認できる。[4] Digital Walletでは標準のconsumption tagsによりエージェントやアクション単位に使用量を分けられる。[7] 自社の業務結果と結合する際は、時間帯やorg、対象期間も合わせる。

導入テストの費用も予算へ入れる。公式仕様では、Builderでの作成と、チャットや音声によるプレビュー、Testing CenterやSandbox等での実行は区別され、後者は計測の対象とされている。[3] 本番のテキストアクション単価を、別の環境や機能の使用量へ一律に当てはめず、それぞれの倍率を確認する。

また、Digital Walletは利用量を監視する仕組みであり、残高やentitlementを使い切ったときにサービスを止める仕組みではない。[7] アラートを置くだけで月額上限が保証されるとは考えず、通知を受けたときに誰がどの処理を調整するかを運用として決める。

この見積もりで確認できていないこと

今回検証したのは、公開仕様と、架空データに対するPythonの計算結果である。実際の契約、Salesforce orgでの課金イベント、請求書との一致、完了判定の精度は検証していない。

公開価格は契約単価や地域別条件と異なる場合がある。既存のライセンス、付与credit、値引き、最低コミット、Data 360などの別費用、人の確認工数も、提示した計算例には含めていない。資料の確認日が同じでも、告知されたエディションと既存契約の条件は同一とは限らない。

選択の順序は、必要な機能と利用権を決め、実行経路ごとに課金対象量を測り、その量から総費用を計算し、最後に確認済みの業務完了件数で割る、という流れになる。

利用者が多い部署、長い処理が集中する部署、バックグラウンド実行が多い部署では、同じモデルを使っていても適した契約と改善策が変わる。次の契約を決める前に、この違いをログで説明できる状態を作っておきたい。

参考リンク

[1] New Salesforce Editions Bundle Everything Businesses Need for Agentic Transformation（2026年9月3日）

[2] Agentforce Pricing（2026年9月13日確認）

[3] Agentforce and Generative AI Usage and Billing（2026年9月13日確認）

[4] Metering for Agentforce and Generative AI Usage（2026年9月13日確認）

[5] Configure User Permissions for Unmetered Licenses（2026年9月13日確認）

[6] Flex Credits Billable Usage Types（2026年9月13日確認）

[7] FAQ: Digital Wallet Credits and Entitlements（2026年9月13日確認）