Agentforceで追加費用がかかるのはどこか｜ライセンスに含まれる範囲の見分け方

Agentforceの追加費用とは、いま契約している範囲では足りず、機能を使うために別途かかる費用のことです。稟議に出す総額を固めようとした段階で、機能ごとにこの費用が要るのかどうかが分からず止まってしまうという声は少なくありません。料金の考え方そのものは公開されていても、自社が使う予定の機能について「これは契約に含まれるのか、別に費用が要るのか」を1枚にまとめた資料はどこにもないためです。Agentforceの導入で最初につまずくのが、金額の大きさよりも金額が固まらないことだというのは、検討の場でよく起こることではないでしょうか。

そこで本記事では、追加費用の要否が分からないまま稟議に出したときに何が起きるかから、費用の要否を分ける4つの層、層を見分ける手がかり、稟議の前にそろえる資料、そして1機能から確認を始める手順までを解説します。金額そのものは扱わず、要否を切り分ける考え方として整理していますので、自社の状況に合わせて参考にしてください。なお、機能の提供状況やライセンスの扱いは変わりやすいため、本記事は2026年8月時点で確認できた情報にもとづいています。

この記事を書いた人

本田正憲

合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援と、Agentic CRM設計支援を提供している。Salesforce認定アドミニストレーター・Sales Cloudコンサルタント・Marketing Cloud Account Engagement スペシャリスト。

Agentforceの追加費用が分からず稟議で止まる3場面

金属加工の受託を手がける企業では、従業員180名のうち営業が12名、情報システムの担当が1名という体制でSalesforceを使ってきました。この企業は説明のための架空の設定であり、実在の企業ではありません。問い合わせ対応と提案書の下書きという2つの用途でAIエージェントを使う計画を立てましたが、稟議では総額の上限を先に決める必要があり、当初の目的は「使う予定の機能について、稟議に出せる総額を1枚にまとめること」でした。ところが機能ごとに費用の要否が固まらず、稟議の提出は2か月ほど先送りになっています。そこでここでは、この会社を例に、追加費用の要否が分からないまま稟議に出して止まる3つの場面を整理します。

場面①「含まれています」と聞いたのに、後から別の請求が立つ

検討の初期には、担当者が販売元や支援会社へ問い合わせて「その機能は含まれています」という回答を得ることが珍しくありません。ところがこの回答は、聞いた側が想定していた範囲と答えた側が想定していた範囲が一致しているとは限らず、契約の種類や利用の形が変われば結論も変わってしまいます。含まれるという言葉が指しているのが機能の利用権なのか、それとも実行にかかる分まで含めた話なのかを確かめないまま進めると、運用が始まってから別の請求が立つという形で差が表に出てきます。

この金属加工の会社でも、提案書の下書きに使う機能について「含まれています」という回答を口頭で受け取っていました。ところが実際には、機能を使う権利は契約の範囲にあっても、実行するたびに発生する分は別に見込む必要があり、稟議へ出す総額はその時点で作り直しになっています。担当者が確認を怠ったというより、聞き方の粒度が足りていなかったというほうが実態に近いといえるでしょう。

場面②機能ごとに担当者へ確認していて、稟議の直前まで金額が固まらない

使う予定の機能が3つ4つと増えてくると、確認の作業は機能の数だけ発生します。1つずつ問い合わせて回答を待つ形にすると、最後の回答が届くまで総額が確定せず、稟議の資料は直前まで空欄が残ったままになってしまいます。確認そのものが難しいのではなく、確認を機能単位の作業として積み上げていることが、期間を長くしている原因です。

この会社では、使う予定の機能を5つ挙げていましたが、それぞれ別の日に問い合わせていたため、最後の回答が届くまでに3週間かかりました。稟議の日程は先に決まっていたため、総額を仮置きして提出することになり、差し戻しの理由もそこにあります。先に層へ割り当ててから確認していれば、問い合わせは2回で済んだはずでした。

場面③試用のあいだは無料だったものが、本番で費用の対象になる

試用の期間中は費用がかからない形で提供される機能があり、その期間に検証を進めること自体は正しい進め方です。ところが試用の条件をそのまま本番の前提として資料に書いてしまうと、正式に使い始めた時点で費用が発生し、見込みとの差が生まれます。この差は金額の大小より、稟議で示した前提が崩れたという事実のほうが重く受け止められることが多いといえます。

この金属加工の会社では、試用のあいだに月120件ほどの問い合わせを流して検証していました。本番では同じ件数を扱う前提で総額を出しましたが、試用のときには発生しなかった分が加わることに気づいたのは、稟議の資料を作り終えた後です。試用と本番で条件が変わる機能を、資料の上で分けて書いていなかったことが原因でした。

名前で分かる？機能名で要否を判断できない理由3つ

3つの場面はどれも、機能の名前を手がかりに費用の要否を判断しようとしたことから起きています。名前は機能が何をするかを示しますが、その機能がどう提供されているかまでは示さないため、判断の材料としては足りません。Agentforceのように機能の追加と提供形態の見直しが続いている製品では、名前と費用の関係が固定されていないことも、判断を難しくしている要因です。そこでここでは、機能の名前だけでは要否を判断できない3つの理由を解説します。

理由①同じ名前でも、含まれる範囲が契約の種類で変わるから

同じ名前の機能でも、契約しているエディションやアドオンの構成によって、使える範囲と費用の扱いが変わることがあります。名前が一致しているという理由だけで他社の資料や記事の記述を自社に当てはめると、前提の違いをそのまま持ち込むことになってしまいます。確かめるべきなのは機能の名前ではなく、自社の契約でその機能がどう扱われるかという一点です。

この違いは、料金の考え方を押さえておくと理解しやすくなります。課金の形がどう分かれているかについては料金の考え方の側で整理しており、本記事はそのうえで「自社が使う機能はどこに当たるか」を切り分ける側を扱います。金額の立て方と要否の切り分けは別の作業であり、順番としては要否が先に決まる関係です。

理由②新しく出た機能ほど、提供の形が途中で変わるから

提供が始まったばかりの機能は、試験段階から正式提供へ切り替わる過程で、費用の扱いが変わることがあります。検討を始めた時点の情報をそのまま資料に書き写すと、稟議に出す頃には前提が古くなっているという事態が起こりかねません。新しい機能を計画に含めるほど、情報を取り直す作業を工程として見込んでおく必要があります。

判断の材料になるのは、その機能が正式に提供されているのか、それとも試験段階なのかという状況です。2026年8月時点でも、Agentforceには正式提供へ切り替わったばかりの機能と、まだ試験段階にある機能が混在しており、両者を同じ前提で資料に書くと後から差が出ます。切り替わりの時期は公式の発表で確認できるため、稟議の直前に一度取り直すという運用にしておくと安全です。

理由③「使える」と「費用がかからない」は別の話だから

使えるかどうかと、費用がかからないかどうかは、まったく別の問いです。契約の範囲で使える機能であっても、実行のたびに消費が発生する形であれば、使う量に応じた費用は積み上がります。この2つを1つの質問にまとめて聞いてしまうと、返ってくる答えもどちらか一方についてのものになり、聞いた側は自分が知りたかったほうの答えを得られません。

だからこそ、確認するときは「使う権利があるか」と「実行にかかる分があるか」を分けて聞く必要があります。この会社が口頭の回答で取り違えたのも、まさにこの2つが一体の質問として投げられていたためでした。質問を分けておけば、回答が1つ返ってきた時点で足りていないことに気づけるようになります。

3つの理由はどれも、機能の名前という手がかりが持っている情報の量を、実際より多く見積もっていたことから生まれています。名前が示すのはその機能が何をするかまでであり、どう提供され、どう課金され、何を前提にしているかまでは含まれていません。だからこそ、名前から離れて提供のされ方で切るという次の章の考え方が要ることになります。

Agentforceの費用の要否を分ける4つの層

ここまで整理してきたとおり、機能の名前は費用の要否を判断する手がかりになりません。では、何を手がかりに切り分ければよいのでしょうか。それは、その機能がどう提供され、どう課金されているかという提供のされ方です。Agentforceの機能を提供のされ方で切ると、費用の要否は4つの層に収まり、使う予定の機能はどれかひとつに割り当てられます。層は機能そのものの分類というより費用の扱いの分類であるため、機能が増えても層の数は4つのままだといえるでしょう。そこでここでは、費用の要否を分ける4つの層を整理します。

層①ライセンスに含まれる機能

1つ目は、契約しているライセンスの範囲で使え、実行の回数によって費用が変わらない機能です。安全性を担保する仕組みのように、使う量とは関係なく常にはたらく性質のものがここに入ります。この層に属する機能は、稟議の資料では機能名を並べるだけで足り、回数の見込みを書く必要はありません。

判定の手がかりは、その機能が単独で動くのではなく、ほかの機能の前提としてはたらいているかどうかです。前提としてはたらく仕組みは、使う量で費用が変わる設計になっていないことが多く、契約の範囲に含まれる形で提供されます。設定の画面に利用量の上限や消費の表示が出てこない機能も、この層に当たる可能性が高いといえるでしょう。ただし契約の種類によって扱いが変わる可能性は残るため、自社の契約内容と照らして確かめる作業は省けません。

層②使った分だけ費用が発生する機能

2つ目は、実行のたびに消費が発生する機能です。エージェントが動いて何かを返すという性質の機能は、ほぼこの層に入ると考えてよいでしょう。稟議の資料では、機能名だけでなく1か月あたりの実行回数の見込みを併記しないと、総額が固まりません。

消費がどの単位で発生するかは、アクションという単位で整理されており、その考え方はアクション単位の消費の側で扱っています。この層の機能が計画に入っている場合、見込みを立てる作業が総額の精度を決めることになるため、回数の根拠をどう置くかまで含めて資料に書くことになります。回数の見込みを空欄にしたまま稟議へ出すと総額の幅が広がり、審議の場で上限を問われて止まるのが通例です。逆にいえば、層②に当たる機能が計画に1つも入っていなければ、総額は契約の範囲だけで確定します。

層③別の製品の契約が前提になる機能

3つ目は、その機能を使うために別の製品の契約が必要になるものです。社内の文書を根拠に回答を組み立てる仕組みのように、データを扱う基盤の側の契約が前提になっている機能がここに入ります。この層を見落とすと、機能の費用は見込んでいたのに前提となる契約の費用が抜けているという形で総額が狂います。

見分けるときは、その機能が自社のどこにあるデータを参照するのかを確かめます。参照先がSalesforceの標準の項目にとどまるなら層①か層②で済みますが、外部の文書やほかの仕組みのデータを扱う場合は、前提となる契約の有無を確認する必要があります。この確認は情報システムの担当だけでは判断が難しいことがあり、契約を管理している部門と一緒に見るほうが確実です。

層④無料で使えるが、本番で条件が変わる機能

4つ目は、試用の期間や検証の環境では費用がかからないものの、本番の利用へ切り替えた時点で条件が変わる機能です。検証のために用意された環境と、実際の業務で使う環境では、そもそも提供の条件が違うということになります。この層の機能を試用の条件のまま資料に書くと、稟議で示した前提が本番で崩れます。

この会社が試用の条件をそのまま書いてしまったのも、この層に当たる機能でした。資料では層④の機能だけを別の欄に分け、試用の条件と本番の条件を並べて書く形にしたことで、差し戻しの原因は解消しています。分けて書くという一手間が、前提の崩れを防ぐ最も簡単な方法だと考えます。

4つの層のうち、稟議の総額に効いてくるのは層②と層③の2つです。層①は機能名を並べれば済み、層④は条件が変わりうるものとして別枠にしておけば足りますが、層②は回数の見込みが総額を左右し、層③は前提となる契約の費用がそのまま加算されます。使う予定の機能を並べたときに、この2つの層へいくつ入るかを数えるだけでも、確認にかかる期間の見当は付くようになるでしょう。

層を見分ける3つの手がかり

前章で整理した4つの層が決まっても、自社が使う機能をどの層に割り当てるかが分からなければ資料は作れません。割り当ての判断は、機能の説明を読むよりも、動き方から逆算するほうが早く決まります。Agentforceの機能は名称も説明文も似ているものが多く、公式の説明を読み比べるほど判断に時間がかかるという事情もあります。手がかりを先に決めておけば、機能が増えたときも同じ物差しで割り当てられるようになるでしょう。そこでここでは、層を見分ける3つの手がかりを見ていきます。

手がかり①その機能が動くときに何を消費するか

最初の手がかりは、その機能が動くときに何を消費するかです。実行のたびに消費が発生するのであれば層②であり、常時はたらいていて回数の概念がないのであれば層①に近いということになります。この判断は機能の説明文よりも、実際に動かしてみたときの記録を見るほうが確実です。

この金属加工の会社では、検証の環境で5つの機能を1週間動かし、消費の記録を突き合わせました。実行のたびに記録が増えた機能は3つで、残る2つは動かしても記録が変わりません。説明文を読み比べる作業に3週間かけていたことを考えると、動かして確かめるほうが早いという結果になっています。検証の環境は本番と条件が違うことがあるため、記録が増えるかどうかだけを見て、金額の水準はこの段階では見ないという使い分けが要ります。

手がかり②その機能が参照するデータがどこにあるか

2つ目の手がかりは、参照するデータの置き場所です。Salesforceの中にある項目だけを見て動く機能と、社内の文書や別の仕組みのデータを読みにいく機能では、前提として必要になる契約が変わります。参照先が外にあるほど、層③に当たる可能性が高くなるということです。

確かめ方は、その機能に何を答えさせたいかを1文で書き、その答えの根拠がどこにあるかをたどるだけで足ります。根拠が社内の文書にあるなら、その文書を扱う基盤の契約が前提になり、費用の確認と同時に、何を根拠に答えさせるのかという設計の確認にもなります。データの置き場所は運用のなかで変わることがあるため、参照先を広げるときには層の割り当ても見直すという前提で書いておくとよいでしょう。

手がかり③提供の状況が正式か、試験段階か

3つ目は、提供の状況です。正式に提供されている機能であれば費用の扱いは安定していますが、試験段階の機能は切り替わりの時点で条件が変わる可能性があり、層④として扱っておくほうが安全になります。稟議へ出す資料では、この状況を機能ごとに1列として持っておくと、後から取り直すときに差分だけを見れば済みます。

提供の状況は、公式の発表で確認できます。2026年8月時点で正式提供へ切り替わった機能もあり、切り替わった機能については前提を書き直す必要が出てきます。切り替わりの例としては正式提供に切り替わった機能を扱った記事があり、どの時点で条件が変わるのかの参考になるはずです。 ※参考記事はこちら

3つの手がかりは、上から順に当てていくと迷いが減ります。まず動かして消費の記録が増えるかを見て、増えなければ参照先を確かめ、それでも決まらなければ提供の状況を見るという順番です。この順で当てると、説明文を読み比べる作業をほとんど挟まずに割り当てが終わるため、確認にかける時間そのものが短くなります。

稟議の前にそろえる3種類の資料

ここまでの手がかりで層への割り当てが済めば、あとは資料の形にするだけです。資料は新しく作るというより、すでにある情報を1枚に集める作業になります。集める先は契約の書類、使う予定の機能の一覧、そしていま人が処理している件数の3つで、いずれもAgentforceの検討を始める前から社内にあるものです。稟議で問われるのは資料の体裁よりも、どの数字がどこから来たのかを示せるかどうかになります。そこでここでは、稟議の前にそろえる3種類の資料を整理していきます。

資料①現在の契約に含まれる機能の一覧

1つ目は、いま契約している範囲に何が含まれるかの一覧です。契約書や注文書に書かれている内容をそのまま書き出せば足り、解釈を加える必要はありません。この一覧があると、層①に当たる機能をその場で確定できるようになります。

一覧を作る作業は、情報システムの担当だけでは完結しないことがあります。この会社でも、契約の書類を管理していたのは総務で、担当者が探すところから始まりました。ツール設定ではなく業務設計から入ってほしい場合は、この書類の在り処を確かめるところから一緒に見てもらえるかどうかが、支援会社を見る目安になります。書き出した一覧は次の更新のときにも使えるため、機能名と契約書の該当箇所をひもづけて残しておくのが確実です。

資料②使う予定の機能と、その層の割り当て

2つ目は、使う予定の機能を並べ、それぞれを4つの層のどれかに割り当てた表です。機能名と層の2列があれば足り、金額はこの段階では書きません。層が決まっていれば、金額をどう出すかは層ごとに決まっているためです。

この会社では、使う予定の5つの機能を層へ割り当てたところ、層①が2つ、層②が2つ、層③が1つという内訳になりました。層③に当たる機能が1つあることが分かった時点で、前提となる契約の確認が新しい作業として立っています。表を先に作らなければ、この作業は稟議の後まで見つからなかったはずです。判断が付かない機能があっても表は止めず、空欄のまま残して確認中と書いておけば、どこが未確定かを一目で示せます。

資料③想定する実行回数と、消費の見込み

3つ目は、層②に当たる機能について、1か月あたりの実行回数を書いた表です。回数の根拠は、いま人が処理している件数から置くのが最も確からしく、想定で膨らませる必要はありません。回数を書いておくと、稟議で「その数字はどこから来たのか」と問われたときに、業務の実績で答えられるようになります。

この金属加工の会社では、問い合わせ対応が月240件、提案書の下書きが月35件という実績から回数を置きました。試用のときに流した月120件は検証のための数字であり、本番の見込みとしては使っていません。検証の数字と業務の実績を分けて扱ったことが、前提の崩れを防いだ形になっています。

3種類の資料は、いずれも新しく作るものではありません。契約の書類はすでに社内にあり、使う予定の機能は業務から決まり、実行回数はいま人が処理している件数から取れます。資料づくりが重く感じられるのは、情報が無いからというより、それぞれ別の部門が持っている情報を1枚に集める作業だからだと考えます。

AIに任せる？Agentforce見積もりの線引き3つ

先にそろえた3種類の資料の形が決まると、作る作業そのものをどこまで機械に任せられるかという話になります。一覧の照合のような作業は任せられますが、契約の意味を読む部分まで任せると、判断の責任が曖昧になってしまいます。任せられる範囲を先に決めておかないと、機械が出した結果をそのまま資料に載せてしまい、稟議で前提を問われたときに自分の言葉で答えられません。そこでここでは、費用の見積もりをAIに任せる3つの線引きを解説します。

線引き①一覧の照合は任せる

契約に含まれる機能の一覧と、使う予定の機能の一覧を突き合わせる作業は、機械に任せられます。名前が一致するかどうかという判定で足りるため、人が読んでも結論が分かれません。件数が増えるほど人の作業では抜けが出やすくなる部分でもあり、任せる価値があります。

この会社では、契約に含まれる機能が28項目あり、使う予定の5機能との突き合わせを機械で行いました。人が目視で確認していた段階では、名前の表記が微妙に違う項目を1つ見落としていたことも分かっています。照合の精度そのものが上がったというより、見落としに気づける形になったという効果のほうが大きいといえるでしょう。任せるときは、突き合わせた結果を機能名の一覧として出させておくと、後から人が見直せる形が残ります。

線引き②消費の見込みの計算は任せるが、前提は人が置く

実行回数から消費の見込みを計算する作業も、機械に任せられます。ただし1か月あたり何件処理するかという前提を置くのは、業務を知っている人の仕事です。前提の置き方で結果は大きく変わるため、計算を任せることと前提を任せることは分けて考えます。

前提を機械に推定させると、根拠が業務の実績から離れ、過去の平均値になってしまいます。稟議で問われるのは計算の正しさではなく前提の妥当性であるため、ここを人が持っておかないと説明が続きません。計算の部分だけを任せる形にすれば、前提を変えたときの再計算も短時間で済みます。繁忙期と閑散期で件数が大きく変わる業務であれば、前提を月ごとに置き直せる形にしておくと、実績とのずれも説明しやすくなるでしょう。

線引き③契約の解釈は人が持つ

契約の文言がどこまでを含むのかという解釈は、人が持ちます。同じ文言でも締結の時期や付随する取り決めによって意味が変わることがあり、文字面だけで判断すると誤りが外へ出る経路になってしまいます。判断が分かれる部分は、契約を管理している部門と一緒に確認するのが確実です。

この線引きは、機械の性能の問題というより、責任の所在の問題として置いています。解釈を誤ったまま稟議へ出すと、差し戻しでは済まず契約そのものの見直しになりかねません。人が持つ範囲を狭くしすぎないことが、結果として作業を早く終わらせることにつながります。

3つの線引きに共通しているのは、機械に任せているのが照合と計算という繰り返しの作業だけだという点です。前提を置くことと契約を解釈することは、どちらも業務や取り決めの文脈を読む作業であり、そこを任せてしまうと稟議の場で説明が続かなくなります。任せる範囲を作業の性質で切っておけば、責任の所在も自然に決まるというわけです。

追加費用の確認を1機能から始める4つのステップ

3つの線引きを決め終えたら、あとは着手の順番だけです。使う予定の機能をすべて同時に確認しようとすると、問い合わせの往復が重なって期間が延びます。Agentforceの確認は機能ごとに相手も書類も変わるため、同時に進めるほど回答待ちが積み重なり、どこで止まっているのかも見えなくなります。最初の1機能を決めてから動くほうが、結果として全体の期間は短くなるでしょう。そこでここでは、追加費用の確認を1機能から始める4つのステップを整理します。

ステップ①使う予定の機能を書き出す

最初にやるのは、使う予定の機能を書き出す作業です。この段階では抜けがあっても構わず、業務から逆算して「この作業を任せたい」という単位で並べれば足ります。機能の正式名称が分からないものは、やらせたいことを日本語で書いておくだけでも先へ進めます。

小さく始めたい場合は、この一覧のうち最初に着手する1つを決めてしまうのが確実です。この金属加工の会社では、5つの機能のうち件数が最も多い問い合わせ対応の1つだけを最初の対象にしました。1つに絞ったことで、次のステップの割り当てが2日で終わっています。選ぶ基準は、いま人がいちばん時間をかけている業務に当たるかどうかで、そこから始めれば社内の合意も取りやすくなるでしょう。

ステップ②各機能を4つの層へ割り当てる

次に、書き出した機能を4つの層へ割り当てます。判断に迷うものは、前の章の3つの手がかりを順に当てていけば、たいていはどれかに収まるはずです。どうしても決まらない機能は層④として扱い、条件が変わりうるものとして資料に残しておきます。

割り当てが済むと、確認すべき相手が層ごとに決まります。層①は契約の書類を見れば足り、層②は消費の記録を見れば足り、層③は契約を管理している部門との確認が要る、という形です。問い合わせの回数が機能の数ではなく層の数に収まるのは、この割り当てを先に済ませているからです。割り当てた根拠も機能ごとに一言ずつ書き添えておくと、後から別の担当が見直すときに、同じ判断をたどり直せるようになります。

ステップ③層②の機能について実行回数を見積もる

層②に当たる機能については、1か月あたりの実行回数を見積もります。いま人が処理している件数をそのまま使うのが最も確からしく、増える見込みがあるなら幅で書いておけば十分です。この見積もりは精度を追うものというより、桁を外さないためのものだと考えるほうが実態に合います。

この会社では、問い合わせ対応の月240件をそのまま置きました。エージェントが答えられない分は人へ戻る設計であるため、実行回数としては240件を上限に見ておけば足りるという判断です。上限で置いておけば、実績が下回ったときに説明が必要になることもありません。見積もりの根拠にした件数がどの期間のものかも、あわせて書いておくと確認の手間が減ります。

ステップ④層③・層④の機能を稟議の前に確定させる

最後に、層③と層④の機能について条件を確定させます。層③は前提となる契約の有無、層④は本番へ切り替えたときの条件が対象で、どちらも確認に時間がかかる性質のものです。ここを最後に回すと稟議の直前で止まるため、着手の早い段階で確認を始めておく必要があります。

この会社では、層③に当たる機能が1つあり、前提となる契約の確認に2週間かかりました。層①と層②の確認が2日で済んだことと比べると、確認にかかる時間の差は大きいといえます。層への割り当てを先にしていなければ、この2週間は稟議の後に発生していたはずです。

4つのステップを1つの機能に絞って進めると、着手から総額の確定までは数週間で届きます。2つ目以降の機能は、すでに作った層の割り当て表へ行を足すだけで済むため、同じ期間はかかりません。最初の1つに時間をかけることが、結果として全体を早く終わらせる形になります。

追加費用の見積もりでつまずく3つの落とし穴

ここまでの4つのステップは、順番どおりに進めれば数週間で総額が固まります。ところが途中で前提が崩れる会社もあり、崩れ方には会社をまたいで共通した型があるものです。崩れる原因の多くは確認の漏れというより、確認した内容を資料へどう書いたかのほうにあります。書き方を変えるだけで防げる崩れも多いため、稟議へ出す前にこの3つを知っておくと、差し戻しの回数を減らせるでしょう。そこでここでは、追加費用の見積もりでつまずく3つの落とし穴を見ていきます。

落とし穴①試用の条件をそのまま本番の前提にする

1つ目は、試用のあいだの条件を本番の前提として資料に書いてしまう形です。試用は検証のために条件を緩めて提供されていることが多く、そのまま本番へ持ち込むと前提が崩れます。崩れたときに問われるのは金額の差そのものよりも、前提の確かめ方のほうです。

避け方は、層④を資料の上で別の欄に分けることに尽きます。同じ表に混ぜて書くと、読む側は全部が同じ条件だと受け取ります。分けて書き、試用の条件と本番の条件を並べておけば、読む側も差を前提として受け取れるようになるでしょう。試用の期間そのものにも期限があるため、いつまでの条件なのかを日付で添えておくと読み違いが減ります。条件が変わりうること自体を先に書いておけば、変わったときも資料の修正だけで済むはずです。

落とし穴②「含まれる」を口頭の確認だけで済ませる

2つ目は、含まれるかどうかを口頭の回答だけで確定させてしまう形です。回答した側が想定していた範囲と、聞いた側が想定していた範囲が一致している保証はどこにもありません。稟議に出す資料の根拠が口頭の回答だけだと、差し戻されたときに示すものが残らないという問題も出てきます。

確認は、契約の書類か公式の記載のどちらかに戻すのが確実です。口頭で得た回答は、その内容がどの書類のどこに書かれているかまで確かめて初めて資料の根拠になります。この一手間を省くと、稟議の場で「その根拠は」と問われた時点で説明が止まります。聞いた相手と日付を記録に残しておけば、後から書類に戻って確かめる作業もたどりやすくなるでしょう。

落とし穴③消費の見込みを最大値でなく平均で置く

3つ目は、実行回数の見込みを平均で置いてしまう形です。平均で置くと、繁忙期に上限を超えた月が出たときに、見込みを外したという指摘を受けることになります。上限で置いておけば、実績が下回っても説明は要りません。

見込みは、精度を追うほど当たらなくなるという性質があります。この会社が月240件という上限で置いたのも、平均の170件で置くと繁忙期の月に説明が必要になると判断したためです。稟議で求められているのは正確な予測というより、超えない保証のほうだといえます。上限を置くときは、その数字が業務のどのピークから来たのかもあわせて書いておくと、根拠を問われても答えられます。実績が上限に近づいた時点で見直すという約束を先にしておけば、上限の置き方そのものも説明しやすくなるでしょう。

費用の見込みがフェーズごとに示すもの

先に挙げた落とし穴を避けて稟議が通ったあと、次に必要になるのは見込みと実績の突き合わせです。ただし見る数字は時期によって変わり、同じ指標を追い続けても判断の材料になりません。Agentforceの利用は使い始めてから数か月かけて業務に入っていくため、稟議の時期と運用の時期では、同じ数字を見ても意味が変わってきます。フェーズごとに何を見るかを先に決めておけば、費用の話を業務の話として続けられるようになるでしょう。そこでここでは、費用の見込みがフェーズごとに示すものを整理していきます。

段階①稟議の時期｜層ごとの機能の数

稟議の時期に見るのは、層ごとに機能が何個あるかという数です。層②と層③が多いほど、確認と見積もりにかかる作業は増えます。この数を先に示しておくと、稟議の場でも「どこに時間がかかるのか」を説明できるようになります。逆に、層①ばかりであれば確認は短く済み、稟議の前に時間をかける必要もありません。

当初の目的は「使う予定の機能について、稟議に出せる総額を1枚にまとめること」でしたが、層への割り当てを済ませた時点で内訳は層①が2つ、層②が2つ、層③が1つと確定しました。総額そのものより、この内訳が先に決まったことが提出の遅れを止めた要因になっています。層ごとの数は、あとから機能を足すときの目安にもなり、同じ層に入る機能であれば確認の手順をそのまま流用できます。

段階②実証の時期｜1か月あたりの実際の消費

実証の時期に見るのは、実際に発生した消費です。見込みで置いた回数と実績を突き合わせると、前提の置き方が妥当だったかが分かります。ここで大きくずれている場合は、業務の実態と機能の使われ方が想定と違っているということになります。

この会社では、最初の1か月で実行が月186件にとどまりました。上限の240件で見込んでいたため超過はありませんが、想定より少ない理由を確かめると、営業が従来どおり自分で調べていた分があったことが分かっています。消費の実績は費用の話であると同時に、使われ方を知る材料にもなるというわけです。実証の期間が業務の繁忙とずれていないかも見ておかないと、少なかった理由を取り違えることになります。

段階③運用の時期｜見込みと実績の差

運用が続く時期に見るのは、見込みと実績の差がどう推移するかです。差が小さくなっていくなら前提の置き方が業務に合ってきているということであり、差が開いていくなら使われ方が変わったということになります。金額そのものより、差の動き方のほうが判断の材料になります。

差を追いかける仕組みは複雑にする必要がなく、月ごとの実行回数を1行ずつ記録するだけで足ります。総コストの考え方まで含めて整理したい場合は総コストの内訳の側で扱っており、工数を含めた見方はそちらが詳しくなっています。差が開いた月には、その月に何があったのかを1行添えておくと、翌期の見込みを置き直すときの材料になるでしょう。記録を残す担当を決めておけば、月末の作業として続けられます。

いつ人が見る？費用を確かめる3場面

フェーズごとに示した指標が動き始めても、費用の確認を機械に任せきりにできる範囲は限られます。条件が変わる節目では、人が契約と公式の記載へ戻る必要があるでしょう。Agentforceは提供される機能も課金の扱いも動くため、一度作った層の割り当て表は、置いておくだけでは実態と合わなくなっていきます。見直す時期をあらかじめ決めておけば、気づいたときには前提が変わっていたという事態も避けられるはずです。そこでここでは、人が費用を確かめるべき3つの場面を解説します。

場面①契約の更新が近いとき

契約の更新が近づいたときは、含まれる範囲が変わっていないかを確かめます。更新の前後で提供の形が変わることがあり、層①だった機能が層②に変わるという事態も起こりえるでしょう。更新の直前になって気づくと、条件を確かめる時間も社内で相談する余地も残りません。更新の3か月ほど前に一度見直しておくと、変わっていた場合の対応に余裕が生まれます。

確かめる対象は、資料②で作った層の割り当て表だけで足ります。表があれば、変わったかどうかを機能ごとに確認するだけの作業になり、ゼロから作り直す必要はありません。この点でも、割り当ての表を残しておく価値があるといえます。更新の案内に書かれている変更点と、表の該当行をひもづけて残しておけば、次の更新のときも同じ手順を使えるでしょう。

場面②正式提供に切り替わった機能を使い始めるとき

試験段階だった機能が正式提供へ切り替わったときは、費用の扱いを確認し直します。切り替わりの時点で条件が変わることがあり、層④として扱っていた機能が層②へ移ることもあるでしょう。切り替わりは公式の発表で分かるため、四半期に一度ほど確認する運用にしておけば追いつきます。

この会社では、層④として扱っていた機能が1つあり、正式提供への切り替わりを待って稟議の資料を更新する形にしました。待つという判断ができたのは、その機能を最初の対象から外していたためです。着手の対象を1つに絞っておくと、こうした待ちが計画全体を止めることもありません。切り替わったあとに使い始める機能は、初月の実行回数を別に記録しておくと、見込みの置き方も早く固まります。

場面③対象の部署を広げるとき

使う部署を広げるときは、実行回数の見込みを置き直します。部署が変われば扱う件数も業務の型も変わるため、既存の見込みをそのまま倍にしても実態とは合いません。広げる前に、その部署でいま人が処理している件数を数え直す作業が要ります。

この作業は、最初に対象を決めたときと同じ手順をもう一度なぞるだけです。層への割り当ては既存の表を流用でき、増えるのは回数の見積もりの部分だけになります。手順が残っていれば、2回目以降は数日で終わるようになるでしょう。広げる部署で新しい機能を使う予定があるなら、その機能だけは層の割り当てからやり直す必要があります。層③に当たる機能が増えていないかを先に見ておけば、前提となる契約の確認も早い段階で始められます。

追加費用の確認を先に済ませるべき企業の3つの条件

ここまでの手順は、どの会社でも同じ順番で進められます。ただし確認を先に済ませるべきかどうかは会社によって変わり、後回しでよい場合もあるでしょう。Agentforceの検討では、稟議の様式と使う予定の機能の数によって、確認の重さがはっきり分かれます。自社がどちらに当たるかを先に見ておけば、確認にかける時間の配分も決めやすくなるはずです。そこでここでは、追加費用の確認を先に済ませるべき企業の3つの条件を整理します。

条件①稟議で総額の上限を先に決める必要がある

1つ目は、稟議の様式として総額の上限を先に決める必要がある場合です。上限を示さなければ審議に進めないという運用であれば、要否の切り分けを終えない限り資料が出せません。この場合、層への割り当ては着手の前提そのものになります。上限を後から見直す手続きが重い会社ほど、この条件は強くはたらきます。

この金属加工の会社がまさにこの条件に当てはまりました。上限を示す様式だったため、機能ごとの要否が固まらないことがそのまま提出の遅れになっています。上限を示さなくてよい様式であれば、実証の結果を見てから総額を出すという進め方も選べたはずです。自社の様式がどちらかは過去の稟議書を1枚見れば分かるため、着手の前に確かめておくとよいでしょう。

条件②使う予定の機能が3つ以上ある

2つ目は、使う予定の機能が3つ以上ある場合です。機能が1つか2つであれば、個別に確認しても期間はさほど延びません。機能の数は、確認にかかる期間よりも、確認の相手の数として効いてきます。3つを超えたあたりから、確認の往復が重なって期間が読めなくなるため、層への割り当てを先に済ませる効果が出てきます。

この会社では5つの機能を挙げていたため、個別の確認では3週間かかりました。層へ割り当ててから確認する形に変えたことで、問い合わせは層の数である3回に収まっています。機能の数ではなく層の数で確認が済むという点が、この手順の効き方だといえます。機能を増やす予定があるなら、いまは2つでも、この条件に当たるものとして進めておくほうが確実です。

条件③正式提供前の機能を使う計画がある

3つ目は、まだ正式に提供されていない機能を計画へ含めている場合です。試験段階の機能は条件が変わりうるため、層④として分けておかないと稟議で示した前提が崩れます。計画に1つでも含まれているなら、確認は先に済ませておくほうが安全です。

確認といっても、その機能の提供状況を公式の発表で見るだけで足ります。2026年8月時点の情報をそのまま使わず、稟議の直前にもう一度見るという運用にしておけば、切り替わりを見落とすこともありません。試験段階の機能を計画から外せるかどうかも、あわせて考えておくとよいでしょう。外せるのであれば、正式提供へ切り替わるのを待ってから計画に足すという進め方のほうが、稟議で示した前提は崩れにくくなります。

追加費用の確認を急がなくてよい企業の3つの条件

一方で、確認を先に済ませなくても進められる会社もあります。急いで確認しても、対象が決まっていなければ調べ直しになるだけです。前の章で挙げた3つの条件のどれにも当たらないのであれば、Agentforceを動かして実績を取るほうが先だという判断も成り立ちます。確認を後回しにする場合でも、根拠の残し方だけは先に決めておくと、あとで作り直さずに済むでしょう。そこでここでは、追加費用の確認を急がなくてよい企業の3つの条件を確認していきます。

条件①当面はライセンスに含まれる機能だけで足りる

契約の範囲に含まれる機能だけで当面の用途が足りるなら、追加費用そのものが発生しません。この状態であれば、確認は契約の一覧を見るだけで済み、層②以降の作業は不要です。使い始めてから範囲を広げる段階で、改めて確認すれば間に合います。この条件に当たる会社は、確認そのものより、使い始める時期を決めるほうが先になります。

ただし「含まれる」と判断した根拠は、この段階でも書類に戻して確かめておく必要があります。口頭の回答を根拠にしていると、広げる段階になって前提が崩れることがあるためです。作業としては軽くても、根拠の残し方だけは同じ基準で扱います。実際に使う機能が1つだけであれば、契約書の該当箇所を1行書き写しておくだけでも根拠として足りるでしょう。

条件②実行の回数が月に数十件にとどまる

実行の回数が月に数十件であれば、層②に当たる機能があっても総額への影響は小さくなります。見込みの精度を上げる作業に時間をかけるより、まず動かして実績を取るほうが早いという判断も成り立つでしょう。数十件の段階では、見込みを外しても総額の説明が崩れるところまではいきません。回数が増えてきた時点で見込みを置き直せば足ります。

判断の目安は、稟議で示す総額に対して層②の分が占める割合です。割合が小さいうちは上限で置いておけば済み、細かく見積もる必要はありません。割合が大きくなってきたら、そのときに資料③を作るという順番でも遅くありません。回数が少ないうちに実績を1か月ぶん取っておくと、増えたときの見込みも実績から置けるようになります。

条件③試用の期間が残っていて、本番の判断が先にある

試用の期間が残っており、本番で使うかどうかの判断がまだ先にある場合も、確認を急ぐ必要はありません。この段階で確認しても、本番の条件が確定していないため、資料は作り直しになります。まず使うかどうかを決め、決まってから条件を確かめるという順番が自然です。

ただし試用の条件をそのまま前提として社内で共有してしまうと、後から差が出ます。試用のあいだに得た数字は検証のためのものだと明示しておけば、判断の段階で取り違えることもなくなるでしょう。試用の終わりが近づいた時点で、本番へ移すかどうかを決める日を先に置いておくと、確認の着手も遅れません。判断の日が決まっていれば、そこから逆算して層の割り当てに取りかかれます。

追加費用の内訳を稟議へどう書くかの3つの型

ここまでに挙げた条件が当てはまるなら、次は書き方の話になります。同じ内訳でも、書き方によって差し戻される確率は変わるものです。読む側は費用の専門家ではないため、どこが確定していてどこが変わりうるのかが1枚で分かる形になっているかどうかを見ています。Agentforceの費用を初めて審議する会社ほど、この分かりやすさが判断の速さに効いてくるでしょう。そこでここでは、追加費用の内訳を稟議へどう書くかの3つの型を解説します。

型①層ごとに分けて書く

1つ目の型は、機能を層ごとにまとめて書く形です。層①は機能名だけ、層②は回数と見込み、層③は前提となる契約、層④は試用と本番の条件という具合に、書く項目が層ごとに決まります。読む側も、どの行に何が書かれているかを迷わずに追えるようになるでしょう。層の順に並べると、契約で決まっている部分から先に読ませる形にもなります。

この会社では、5つの機能を層ごとに並べ替えただけで、稟議の場での質問が減りました。並べ替える前は機能の順に書いていたため、含まれるものと含まれないものが交互に並んでいたためです。並び順を変えるだけで伝わり方が変わるというのは、資料としては効きの大きい部分だといえます。層ごとに小計を置いておけば、どの層が総額を押し上げているのかも同じ表のなかで示せます。

型②実行回数の前提を明記して書く

2つ目は、実行回数の根拠を数字の隣に書く形です。月240件という数字だけを書くと、その数字がどこから来たのかを問われます。いま人が処理している件数から置いたと1行添えておけば、問いそのものが立ちません。

前提を書いておくと、実績がずれたときの説明も簡単になります。前提が変わったから見込みも変わったという説明が成り立つためです。数字だけを書いた資料は、ずれたときに見込みを外したという評価だけが残ってしまいます。根拠として書くのは、集計した期間と対象の部署だけで足り、細かい算式まで載せる必要はありません。前提を1行で書けない数字は、まだ根拠がそろっていないという合図として扱い、稟議へ出す前に置き直すとよいでしょう。

型③変わりうる項目を分けて書く

3つ目は、条件が変わりうる項目を別の欄に分ける形です。層④に当たる機能と、正式提供への切り替わりを待っている機能がここに入ります。分けて書いておけば、変わったときに更新するのはその欄だけで済みます。

この分け方は、稟議を通した後の運用でも効いてきます。四半期ごとに見直すのは変わりうる欄だけになり、確定している部分は触らずに済むためです。資料の作り方が、そのまま運用の作り方になっているという構造です。変わりうる欄には、いつ確認したかの日付も添えておくと、次に見る人がどこまで確かめられているかを判断できます。この欄が空になった時点で、その機能は確定した扱いへ移せるようになり、見直しの対象からも外せるようになります。

費用の確認に外部支援を使う4つの判断軸

ここまでの内容は、情報システムの担当が1名いれば自社でも進められる範囲です。とはいえ契約の解釈や層の割り当てで迷う場面はあり、外部の支援を検討する会社もあるでしょう。Agentforceの導入支援を掲げる会社は増えていますが、費用の要否まで一緒に見てくれるかどうかは、提案の内容を読まないと分かりません。判断軸を先に持っておけば、最初の打ち合わせだけでも見極めがつくようになります。そこでここでは、費用の確認に外部支援を使う4つの判断軸を整理します。

判断軸①契約の内容を読んだうえで話すか

1つ目は、自社の契約を読んだうえで話をする相手かどうかです。一般的な料金の説明だけで終わる提案は、自社の契約でどう扱われるかという肝心の部分に触れていません。最初の打ち合わせで契約書や注文書を見せてほしいと言われるかどうかで、この差はだいたい分かります。契約の内容を見ずに出てくる金額は、他社の事例をそのまま当てはめたものになりがちです。

自社で構築するので設計レビュー・アドバイザリーだけ頼みたい場合は、この読み合わせだけを切り出して依頼する形も成り立ちます。層への割り当てまで自社で済ませておけば、確認したい点を絞って相談できるようになるでしょう。読み合わせの結果をどの形で残してもらえるかも、あわせて確かめておくと後の更新で困りません。

判断軸②消費の見込みを一緒に置くか

2つ目は、実行回数の前提を一緒に置いてくれるかどうかです。見込みの計算そのものは難しくありませんが、業務のどの数字を根拠にするかという判断には現場の理解が要ります。前提を置く作業に踏み込まない支援は、計算の代行にとどまります。

前提の置き方が変わると総額も変わるため、ここは最も相談する価値のある部分だといえます。小さく始めたい場合は、最初の1機能について前提の置き方を一緒に決め、2つ目以降は自社でなぞるという進め方も選べます。業務の件数をどこから取るかを一緒に決めてくれる相手であれば、稟議で前提を問われたときの答え方も同時に用意できるでしょう。現場の担当者への聞き取りまで入るかどうかが、この判断軸の見分けどころになります。

判断軸③正式提供の状況を追い続けるか

3つ目は、提供状況の変化を追い続けてくれるかどうかです。層④に当たる機能は条件が変わるため、稟議を通した後も確認が必要になります。導入の時点だけを見る支援では、この変化に気づく手段が自社に残りません。

定着まで伴走してほしい場合は、この追い続ける部分が契約の範囲に入っているかを確かめておくとよいでしょう。四半期に一度の確認であっても、外部が見ている状態と自社だけで見ている状態では、気づくまでの時間が変わってきます。確認の結果をどう伝えてもらうかまで決めておけば、変化があった月だけ資料を直すという運用にできます。Agentforceの提供状況は公式の発表で追えるため、外部に任せる範囲は変わったことを知らせてもらうところまでで足りることも多いはずです。

判断軸④自社で更新できる形で残すか

4つ目は、支援が終わった後に自社で更新できる形が残るかどうかです。層の割り当て表と回数の根拠が自社の言葉で残っていれば、担当が代わっても続けられます。支援会社の独自の様式でしか読めない資料だと、契約が終わった時点で更新も止まります。支援会社の選び方の全体像は導入支援会社の選び方で整理していますので、あわせて確認してください。

残す形として確実なのは、機能名・層・根拠・確認した日付の4列を1枚に収めた表です。この形であれば、次の担当者が引き継いだときも、どこまで確かめられているかがその場で分かります。支援を受けている期間のうちに、自社の担当が同じ表を一度は自分で更新してみるところまでを、契約の範囲に入れておくとよいでしょう。

費用の要否を自社だけで切り分けきれないときは、外部の目を一度入れておくと判断が早くなります。クロスコムのAgentforce導入・定着支援では、契約の読み合わせから層の割り当てまでを一緒に進めており、1ユースケース×3ヶ月のスモールスタートプランと無料相談も受け付けています。

【一問一答】Agentforceの追加費用に関するよくある質問

ここまで、追加費用の要否を分ける層から、見分ける手がかり、資料、手順、稟議への書き方までを整理してきました。実際に検討を進める段階では、契約の範囲や実行回数の置き方といった細かい点で迷う場面が出てきます。とくに「既存のSalesforceの契約だけで使えるのか」という問いは検討の初期に必ず出てくるもので、答え方によって社内での受け止め方も変わってくるでしょう。そこでここでは、検討の場でよく出る質問に順に答えていきます。

Agentforceの追加費用は、機能の新しさより、どの層に属するかで決まる

Agentforceで追加費用がかかるかどうかは、機能が新しいかどうかでは決まりません。ここまで整理してきたとおり、決まるのは、その機能がライセンスに含まれるのか、使った分だけ発生するのか、別の契約が前提になるのか、それとも試用と本番で条件が変わるのかという層のほうです。当初の目的は「使う予定の機能について、稟議に出せる総額を1枚にまとめること」でしたが、この金属加工の会社が目的に届いたのは、金額を調べ直したときではありません。5つの機能を4つの層へ割り当てた時点で、稟議に出せる総額が1枚にまとまりました。

本記事で整理した4つの層、3つの手がかり、3種類の資料、4つのステップは、いずれも特別な調査を必要としません。契約の書類を書き出し、使う予定の機能を並べ、層へ割り当て、層②のものだけ回数を置きます。この順番を守れるかどうかが、稟議に出せる総額を作れるかどうかを分けます。本記事の内容が、自社の検討の材料として少しでもお役に立てれば幸いです。