Agentforceの導入は決まったものの、いざ最初の1体を作る段になって、どこから手をつけるべきか迷っている担当者は少なくありません。Agentforceの使い方は、Salesforce上でエージェントを作成し、トピックとアクションを設定し、テストしてから公開する流れが基本です。手順自体は公式ドキュメントに沿えば進められますが、実際にはいくつかの決まった箇所でつまずいて先へ進めなくなりやすいのが実情です。なお、画面や仕様は変わりやすいため、本記事は2026年8月時点の情報にもとづいています。
そこで本記事では、Agentforceで最初の1体を作るまでの設定手順と、公式ドキュメントには書かれていないつまずきポイントの回避法を、順を追って解説します。
当社はSalesforce公式コンサルティングパートナーとして、 ソリューション営業に特化したAgentforce導入・定着支援を 行っています。
- どのユースケースから始めればいいか分からない
- 設定は完了したが現場に定着しない
- ナレッジ設計から一緒に考えてほしい
というお悩みがあればお気軽にご相談ください。 1ユースケース×3ヶ月のスモールスタートプランから対応しています。
この記事を書いた人
合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援を提供している。
Agentforceの使い方の全体像4ステップ
まずは、Agentforceで最初の1体を作るまでの流れを、大きく4つのステップで押さえておきましょう。今回取り上げるのは、中堅の産業機器メーカーでSalesforceを一人で管理している情報システム担当者です。この担当者のもとには、製品の仕様や納期についての問い合わせが毎日およそ30件届き、その一次対応に追われて本来のシステム運用の仕事が後回しになっていました。そこでここでは、その担当者が最初の1体を公開するまでの全体像を、4つのステップで解説します。
ステップ①利用環境と権限を準備する
最初に取りかかるのは、エージェントを作る前に利用環境と権限を整えることです。Agentforceは、いきなり作成画面から始められません。先に検証用の環境を用意し、機能を有効化し、利用者に権限を割り当てておく必要があります。先ほどの担当者も、日々30件ほど届く問い合わせ対応を任せる1体を作ろうとしましたが、本番組織でいきなり試すのは避け、まずDeveloper Editionの検証環境を用意しました。この順番を飛ばすと、作成の途中で権限が足りずに画面が進まず、原因を探して時間を使うことになります。実際にこの担当者も、はじめは準備の全体像が分からず、どこから手をつけるべきか迷いました。環境・有効化・権限のうちどれか一つでも欠けていると作成画面は最後まで進まないため、3つはまとめて済ませておきましょう。準備の中身は、次の章で3つに分けて解説します。
ステップ②Agent Builderでエージェントを作成する
利用環境と権限が整ったら、次はAgent Builderでエージェントを作成します。Agent Builderは、会話型の画面でエージェントの役割や指示文を設定できる仕組みで、専任の開発者がいなくても操作できます。なお、2026年7月中旬以降、新しいエージェントの作成はAgentforce Studio内の新しいAgentforce Builderで行う形に変わっているため、画面の名称は組織によって異なります。産業機器メーカーの担当者は、問い合わせ対応に使えるService Agentのテンプレートを選び、そこを出発点にしました。ゼロから設計せず、業務に近いテンプレートから始めることで、最初の1体は短い時間で形になります。この担当者の場合も、身近な製品仕様の問い合わせから入ったため、画面の操作に迷う場面はほとんどありませんでした。実際、この段階でつまずく人は少なく、多くの人が案内に沿って進められます。具体的な作成手順は、後半の章で3つのステップに分けて解説します。※参考記事はこちら
ステップ③トピックとアクションを設定する
エージェントを作成したあとは、そのエージェントに担わせる業務を、トピックとアクションで設定していきます。トピックはエージェントが扱う業務のまとまり、アクションはその中でエージェントが実行する具体的な処理を指します。今回の担当者は、製品仕様の問い合わせに答えるトピックを設定し、必要に応じて製品レコードを参照するアクションを組み込もうとしました。実は、多くの人が設定を進められなくなるのがこのアクションです。画面に表示されるアクション名のラベルと、実際に動く処理の名前が一致しないなど、公式ドキュメントには書かれていないつまずきが、ここに集中しています。この担当者も、ラベルのとおりに指定したのにアクションが動かず、設定のどこが悪いのか分からないまま時間を費やしました。その回避法は、後半の2つの章で具体的に取り上げます。
ステップ④テストして公開する
そして最後に、作ったエージェントをテストしてから公開します。Agent Builderには、実際に会話を試せるテスト画面が用意されており、想定した質問にどう答えるかをその場で確認できます。この担当者も、公開の前に、日々届いていた製品仕様の問い合わせを思い出しながら、よくある質問をいくつも入力して応答を確かめました。この段階で大切なのは、答えられたかどうかだけでなく、どのデータやアクションを使って答えたのかまで見ることです。正しそうに見える回答でも、根拠にしているデータが違えば、別の質問で誤った回答になりかねないためです。ここまでが、最初の1体を公開するまでの4つのステップの全体像です。テストの観点と公開までの流れは、後半の章で3つのステップに分けて解説します。
Agentforceの使い方は準備・作成・設定・テストの4ステップで進み、つまずきが集中するのは3つ目のトピックとアクションの設定です。
エージェントを設定する前に必要な3つの準備
前章では、最初の1体を作るまでの全体像を確認しました。ここからは、その出発点となる準備を詳しく見ていきます。準備を飛ばして作成画面に進むと、途中で権限や環境の不足に気づいて手戻りになりやすいためです。そこでここでは、Agentforceの設定を始める前に必要な準備を、3つに分けて解説します。
準備①Developer Editionで検証用の環境を用意する
1つ目の準備は、検証用の環境を用意することです。Agentforceの設定を、いきなり本番のSalesforce組織で試すと、ほかの業務データに影響が出るおそれがあります。そこで、まずは無料で使えるDeveloper Editionの組織を用意し、そこで動作を確かめるのが安全な進め方です。先ほどの担当者も、本番組織とは別にDeveloper Editionを取得し、そこで最初の1体を組み立てていきました。検証環境であれば、設定を間違えても業務への影響がなく、納得できるまで試行錯誤できます。なお、Developer Editionは45日間ログインしないと組織が削除されるため、検証を続けるあいだは定期的にログインしておきましょう。※参考記事はこちら
準備②AgentforceとAgent Builderを有効化する
2つ目の準備は、AgentforceとAgent Builderを有効化することです。これらの機能は、組織の設定画面から有効化して初めて使えるようになり、有効化しないままでは作成画面にたどり着けません。例に挙げた担当者は、設定メニューからAgentforceをオンにし、あわせてエージェントを組み立てるAgent Builderを使える状態にしました。ここでつまずきやすいのは、機能を有効化したつもりでも、必要な設定が一部抜けていて画面が表示されないケースです。有効化の手順は画面の案内に沿って進められますが、途中の確認項目を飛ばさず一つずつ完了させることが大切です。有効化が済んでいれば、次の権限の割り当てにそのまま進めます。
準備③利用者に必要な権限セットを割り当てる
3つ目の準備は、エージェントを使う利用者に、必要な権限セットを割り当てることです。Agentforceは、機能を有効化しただけでは利用者が使えず、適切な権限セットを個々のユーザーに割り当てて初めて操作できるようになります。今回の担当者も、まず自分自身に権限を割り当て、作成画面が正しく開くことを確かめてから作業を始めました。ここを見落とすと、機能は有効なのに特定の利用者だけ画面が開かない、原因の分かりにくいつまずきが起こります。誰がどの範囲でエージェントを使うのかを先に決め、その利用者に権限を割り当てておくことで、後からの手戻りを防げます。準備がここまで整えば、いよいよ最初の1体の作成に進めます。
エージェントを設定する前に、検証環境・機能の有効化・権限の割り当てという3つの準備を済ませておくと、作成の途中での手戻りを防げます。
Agent Builderで最初の1体を作る3ステップ
準備が整ったところで、いよいよAgent Builderで最初のエージェントを作成します。ここは多くの人が迷わず進められる段階ですが、最初の1体をどこまで作り込むかで、その後の負担が変わってきます。そこでここでは、Service Agentのテンプレートを使って最初の1体を作る流れを、3つのステップで解説します。
ステップ①テンプレートを選んでエージェントを作成する
作成画面を開いたら、まずテンプレートを選んでエージェントを作成します。Agent Builderには、あらかじめ用途別のテンプレートが用意されており、ゼロから設計しなくても、業務に近いものを選んで出発点にできます。この担当者は、問い合わせ対応に向いたService Agentのテンプレートを選び、名前を付けてエージェントを作成しました。ここでお伝えしたい独自の判断は、最初の1体で完璧を目指さないほうがよい点です。あれもこれもと機能を盛り込むより、一つの業務に絞ってまず動く状態を作るほうが、公開までたどり着きやすくなります。テンプレートは後から調整できるため、最初は業務に最も近いものを選び、そのまま次のステップへ進むのが現実的です。
ステップ②エージェントの役割と指示文を設定する
エージェントができたら、次はそのエージェントの役割と指示文を設定します。役割は、そのエージェントが何を担うのかを一文で定義するもので、指示文は、どのように振る舞ってほしいかを言葉で伝えるものです。先ほどの担当者は、役割を「製品仕様に関する一次対応を行う」と定め、判断に迷う内容は人へ引き継ぐよう指示文に書き加えました。具体的には、在庫状況や特別な値引きなど、その場で答えると誤りにつながる質問は、自分に転送するように指示しています。ここで大切なのは、担わせる範囲を欲張らず、対応する内容とそうでない内容をはっきり決めることです。何でも答えさせようとすると、かえって的外れな回答が増え、テストの段階で手直しが多くなります。最初は対応範囲を狭く定義し、動作を確かめながら少しずつ広げていくほうが、結果的に早く公開までたどり着きます。
ステップ③業務に対応するトピックを追加する
役割と指示文が決まったら、最後に業務に対応するトピックを追加します。トピックは、エージェントが扱う業務のまとまりを指し、たとえば「製品仕様の問い合わせ」や「納期の確認」といった単位で切り分けていきます。産業機器メーカーの担当者は、まず製品仕様の問い合わせに答えるトピックを一つだけ追加し、そこに想定される質問と対応方針を設定しました。ここでも、最初はトピックを一つに絞るのがおすすめです。複数のトピックを一度に設定すると、どのトピックが原因で回答がずれたのかが分かりにくくなり、調整が難しくなります。一つのトピックで公開まで到達させ、動作が安定してから次のトピックを足すほうが、つまずきを一つずつ解消できます。トピックにアクションを組み込む段階でつまずく人は多いのですが、その回避法は次の章で解説します。
最初の1体は、役割と対応範囲を狭く定義し、トピックを一つに絞って作ると、公開まで早くたどり着けます。
プロンプトビルダーで指示を作り込む3つの方法
エージェントの基本の設定ができたら、応答の中身をより意図どおりにするために、プロンプトビルダーを使って指示を作り込みます。プロンプトビルダーは、エージェントが参照する指示のひな型を作る仕組みで、どのデータをもとに、どう答えるかを細かく指定できます。そこでここでは、プロンプトビルダーで指示を作り込む方法を、3つに分けて解説します。
方法①プロンプトテンプレートを作成する
1つ目の方法は、プロンプトテンプレートを作成することです。プロンプトテンプレートは、エージェントに与える指示のひな型で、聞かれた内容に対してどう答えるかの枠組みを定義します。先ほどの担当者は、製品仕様の問い合わせに答えるためのテンプレートを一つ作成し、回答の形式や口調をそこで指定しました。たとえば、型番を聞かれたら該当する製品の仕様を要点だけ短くまとめて返す、といった答え方の枠組みを言葉で書き添えたのです。テンプレートを用意しておくと、担当者ごとに回答がばらつくことがなくなり、同じ種類の質問には同じ品質で答えられます。この担当者の場合も、最初から複数のテンプレートを作ろうとせず、まず一つに絞ったことで、設定の見通しが立てやすくなりました。テンプレートを分けるかどうかは、回答の形式や口調を業務ごとに変える必要があるかどうかで判断しましょう。
方法②グラウンディングで参照データを指定する
2つ目の方法は、グラウンディングで参照データを指定することです。グラウンディングとは、エージェントが回答を組み立てるときに、どのデータを根拠にするかを指定する仕組みです。今回の担当者は、製品仕様が登録されたレコードをグラウンディングの対象に指定し、その情報にもとづいて答えるように設定しました。グラウンディングの対象には、Salesforceのレコードのほか、ナレッジ記事や、Data 360に取り込んだ社外のデータも指定できます。グラウンディングを設定しないと、エージェントは手元の一般的な知識だけで答えてしまい、自社の製品情報に沿わない回答が返ることがあります。参照させたいデータが社内に散らばっている場合は、その整備から着手する必要も出てきます。
方法③テンプレートを有効化してエージェントから呼び出す
3つ目の方法は、作成したテンプレートを有効化して、エージェントから呼び出せるようにすることです。プロンプトテンプレートは、作成しただけでは使われず、有効化して初めてエージェントの応答に反映されます。例に挙げた担当者は、テンプレートを有効化したうえで、テスト画面で実際に呼び出されるかを確かめました。ここでのつまずきは、テンプレートを作ったのに有効化を忘れていて、設定が応答に反映されないことです。この担当者も、最初は有効化の操作を見落としており、指示を書き換えても応答が変わらず、原因が分からないまましばらく悩みました。作成と有効化はひとまとまりの作業として続けて済ませておくと、こうした行き違いを防げます。
プロンプトビルダーでは、テンプレートを作成し、グラウンディングで参照データを指定し、有効化して呼び出すことで、自社の業務に沿った応答を設定できます。
標準アクションの設定でつまずく2つの落とし穴
ここまでの手順は、公式の案内に沿えば大きく迷わず進められます。ところが、トピックにアクションを組み込む段階になると、公式ドキュメントには書かれていない、分かりにくいつまずきが待っています。先ほどの担当者も、まさにこの段階でしばらく設定が進みませんでした。そこでここでは、標準アクションの設定でつまずきやすい2つの落とし穴を解説します。
落とし穴①アクション名のラベルから実体の識別子を推測できない
1つ目の落とし穴は、標準アクションの画面に表示されるラベルと、実際に動く処理の識別子が一致しないことです。プロンプトから特定のアクションを呼び出すには、その実体の識別子を正しく指定する必要があります。ところが、画面上のラベルから識別子をそのまま推測すると、多くの場合で外れます。実際に、標準アクションとして用意されている「Search The Web」の実体は「webSearchStream」で、表示名からは想像しにくい綴りです。この担当者も、ラベルをそのまま指定して呼び出しがうまくいかず、原因が分からないまま時間を使いました。この食い違いを知らないと、設定は正しいはずなのにアクションが動かない状態になります。なお、こうした識別子は変わることがあるため、実際の値は次章の手順で確認するのが確実です。（2026年8月時点の情報にもとづく）※参考記事はこちら
落とし穴②構文検証は存在しないアクションでもエラーを出さない
2つ目の落とし穴は、構文の検証機能が、アクションが実在するかどうかまでは確認しないことです。プロンプトや設定を保存するとき、構文の検証が走り、問題がなければエラーなしと表示されます。ところが、この検証は文法の形式を見ているだけで、指定したアクションが実際に存在するかは見ていません。そのため、実在しないアクション名を書いても、検証はエラーなしと表示して通ってしまいます。産業機器メーカーの担当者も、検証が通ったのだから設定は正しいはずだと考え、動かない原因をしばらく別の場所に探していました。検証が通ることは、指定したアクションが正しく動くことを保証しません。アクション名を指定したら、検証の結果だけを信じず、次章の手順で実体を一つずつ確かめておきましょう。（2026年8月時点の情報にもとづく）
標準アクションは、画面のラベルから実体の識別子を推測できず、構文検証も実在を確認しないため、指定した名前が正しいかは別の方法で確かめる必要があります。
標準アクションの実体を確認する3ステップ
前章の2つの落とし穴は、いずれも指定したアクションの実体が正しいかを確かめられていないことが原因です。逆にいえば、実体の識別子を確認する手順さえ知っていれば、この2つのつまずきはまとめて避けられます。そこでここでは、Agentforceの標準アクションの実体を確認する手順を、3つのステップで解説します。
ステップ①アクションの詳細画面を開く
実体を確かめる作業は、対象のアクションの詳細画面を開くところから始めます。Agentforceの新しい画面では、各アクションに詳細を確認できる画面が用意されており、そこからアクションの中身をたどれます。先ほどの担当者は、それまで画面に並ぶラベルだけを見て設定を進めていましたが、トピックに組み込もうとしているアクションを選び、その詳細画面を開きました。ラベルの表示だけで判断せず、まず詳細画面を開いて中身を確認する習慣をつけることが、識別子の食い違いを防ぐ出発点になります。この担当者も、この一手間を入れるようにしてから、原因の切り分けが早くなりました。画面の名称や位置は変わることがあるため、見当たらない場合は、アクションを管理する設定画面から探すとたどり着けます。
ステップ②参照アクション欄で実体の識別子を確認する
詳細画面が開いたら、「参照アクション」欄で実体の識別子を確認します。この欄に表示されるのは画面上のラベルとは異なり、実際に呼び出される処理の識別子です。今回の担当者も、ここを見て初めて、「Search The Web」と表示されていたアクションの実体が「webSearchStream」であると把握できたのです。ラベルから推測して指定していたときはうまくいかなかった呼び出しも、この欄で確認した正しい識別子に置き換えたところ、意図どおり動くようになりました。トピックに複数のアクションを組み込むときは、追加するたびにこの欄を開いて識別子を控えておくと、後から突き合わせる手間がなくなります。（2026年8月時点の画面にもとづく）
ステップ③プロンプトに正しい識別子を指定する
識別子が分かったら、その値をプロンプトに指定します。参照アクション欄で実体を確かめたら、その識別子をプロンプトの呼び出し部分へ正確に書き写しましょう。例に挙げた担当者は、これまで指定していたラベルを消し、確認した識別子に置き換えたうえで、テスト画面でアクションが実際に呼び出されることを確認しました。ここで、指定したら必ずテスト画面で動作を確かめることが大切です。前章のとおり構文検証は実在を保証しないため、実際に呼び出して初めて、正しく設定できたと判断できます。この担当者の場合も、書き写した識別子に一文字の打ち間違いがあり、テストで気づいて直せたという経験をしています。逆に、書き写した直後にテストをしなければ、こうした打ち間違いは公開後まで見つかりません。
標準アクションは、詳細画面の参照アクション欄で実体の識別子を確認し、その識別子をプロンプトに指定してテストで動作を確かめれば、確実に設定できます。
作成上限がテンプレート単位になる3つのポイント
最初の1体を無事に作れると、次はもう1体、別の業務でも作りたくなります。そのときに知っておきたいのが、エージェントの作成上限の数え方です。ここには、あらかじめ確認しておかないと後で戸惑う制約があります。そこでここでは、Agentforceでエージェントを増やすときの上限の数え方を、3つのポイントで解説します。
ポイント①作成上限はテンプレート単位で数える
1つ目のポイントは、作成上限が何を単位に数えられているのかを、最初に確かめておくことです。上限はテンプレートの数ではなく、有効にしたエージェントの数で管理され、1つのSalesforce組織で有効にできるエージェントは20体までとされています。あわせて、1体のエージェントが扱えるトピックは15、1つのトピックに組み込めるアクションは15までという上限もあります。先ほどの担当者は、上限がどう数えられるのかを確かめないまま2体目に取りかかり、上限の表示を見て初めて数え方を知りました。この数え方を知らないと、まだ作れるはずだと考えていたのに追加できなかったり、逆にもっと作れることに気づかなかったりします。何体まで作れるのかを最初に把握しておくと、増やすときの計画を立てやすくなります。（2026年8月時点の情報にもとづく）※参考記事はこちら
ポイント②同じテンプレートから複数のエージェントを作成できる
2つ目のポイントは、同じテンプレートから複数のエージェントを作成できることです。テンプレートはあくまで作成の出発点なので、一つのテンプレートをもとに、設定を少しずつ変えた複数のエージェントを用意できます。産業機器メーカーの担当者は、製品仕様の問い合わせに使ったテンプレートをもとに、納期確認向けに一部を変えたエージェントを追加することを検討しました。具体的には、参照するレコードと指示文だけを差し替え、基本の設定は引き継ぐ進め方です。よく似た業務であれば、テンプレートを共有して複数のエージェントを展開するほうが、設定を見直すときの手間も少なくて済みます。この担当者の場合も、業務ごとにテンプレートをゼロから作らずに済み、二つ目以降の準備にかかる時間が短くなりました。どのテンプレートを共有するかを先に決めておけば、2体目以降は設定の差分だけを考えれば済みます。
ポイント③上限に達すると新しいテンプレートを作成できなくなる
3つ目のポイントは、上限に達すると、新しく作成できなくなることです。20体すべてを有効にした状態では、既存のエージェントを編集することはできても、新しいエージェントを追加することはできなくなります。今回の担当者も、業務ごとにエージェントを増やしていくといずれ20体に近づくことを見越して、どの業務をどのエージェントでまかなうかを整理しました。実際に、問い合わせ対応と納期確認は一つのエージェントにまとめ、性質の異なる社内申請だけを別に分ける、といった整理を先に決めています。使わなくなったエージェントを有効なまま残しておくと、その分だけ上限が埋まってしまうため、不要になったものは無効にしておくことが大切です。増やす前に、いま何体を有効にしているかを設定画面で確認しておきましょう。
エージェントの作成上限は1つのSalesforce組織あたり20体で、同じテンプレートから複数作れる一方、20体すべてを有効にすると新しいエージェントは追加できなくなります。
作ったエージェントをテストして公開する3ステップ
設定がひととおり終わったら、公開の前にテストで動作を確かめます。ここでのテストは、答えられたかどうかを見るだけでなく、どのように答えたのかまで確認することが大切です。そこでここでは、Agentforceで作ったエージェントをテストして公開するまでの流れを、3つのステップで解説します。
ステップ①テスト画面で想定質問を試す
テストはまず、想定される質問をテスト画面で試すところから始めます。Agent Builderのテスト画面では、実際の利用者になったつもりで質問を入力し、エージェントの応答をその場で確認できます。先ほどの担当者は、日々届いていた製品仕様の問い合わせを思い出しながら、よくある質問を一つずつ入力して応答を確かめました。ここで大切なのは、うまく答えられそうな質問だけでなく、判断に迷う質問や答えにくい質問も試すことです。たとえばこの担当者は、型番だけを伝えて仕様を尋ねる曖昧な聞き方や、複数の製品をまとめて比べる質問など、答えに詰まりそうな聞き方をわざと入力してみました。想定内の質問だけで確認を終えると、公開後に想定外の質問でつまずきます。どこまで試せば十分かは、実際に届いている問い合わせの型をひととおり入力できたかどうかが目安になります。
ステップ②回答の根拠と参照データを確認する
応答を確認できたら、次はその回答の根拠と、参照したデータまで確認します。エージェントが正しそうな回答を返したとしても、それがどのデータやアクションをもとにした回答なのかまで見ておく必要があります。例に挙げた担当者は、応答の内容だけでなく、そのとき参照されたレコードや呼び出されたアクションを一つずつ確認しました。たまたま正しく見える回答が返っていても、根拠にしているデータが違っていれば、別の質問では誤った回答になりかねません。なかでも複数のトピックにまたがる質問では、意図しないトピックが選ばれていないかまで見ておくと安心です。答えの内容と、その答えを導いた根拠の両方を確かめることが、公開後のトラブルを防ぎます。
ステップ③問題がなければ有効化して公開する
テストで問題が見つからなければ、いよいよエージェントを有効化して公開します。テストで想定した質問に正しく答えられ、根拠も確認できたら、利用者が使える状態にしましょう。この担当者は、最初の1体であるService Agentを有効化し、まずは限られた範囲の問い合わせ対応から使い始めました。具体的には、いきなり全社に開放せず、自分と近い数名だけが使える状態から始めています。公開は一度で完成させるものではありません。実際に使われるなかで見つかった課題を、少しずつ直していく前提で始めるのが現実的です。当初の目的は「製品仕様に関する一次対応を行う」ことでしたが、公開から1か月ほどで、毎日およそ30件届いていた問い合わせのうち18件ほどをエージェントが一次対応するようになりました。
エージェントは、テスト画面で想定質問を幅広く試し、回答の根拠まで確認してから有効化して公開すると、安定して使い始められます。
Agentforceを使い始めるのにかかる費用3つのポイント
最初の1体を作れたところで、実際に使い続けるとどれくらいの費用がかかるのかを押さえておきましょう。Agentforceの費用は、試す段階と本番で使う段階で考え方が変わり、金額の条件も変わりやすいため、最新の情報は公式サイトで確認するのが確実です。そこでここでは、Agentforceを使い始めるのにかかる費用を、3つのポイントで解説します。
ポイント①Developer Editionは無料で検証できる
1つ目のポイントは、検証の段階は無料で始められることです。Agentforceの動作を試すために使うDeveloper Editionは、無料で取得できる開発者向けの環境です。先ほどの担当者も、最初の1体はこのDeveloper Editionで組み立て、費用をかけずに動作を確かめました。この担当者のように、一人で情報システムを担っていて、いきなり予算を確保しづらい立場でも、まずは自分の手で試してから判断できます。まず無料の環境で使い方を身につけ、本番で使うかどうかを見極めてから費用の話に進められるため、いきなり大きな支出を決める必要はありません。実際に動かして効果を確かめたうえで社内に費用を説明できる点も、この段階の大きな利点です。
ポイント②本番利用はEnterprise Edition以上とFlex Creditsが前提になる
2つ目のポイントは、本番で使う段階では、一定以上のSalesforceエディションとFlex Creditsが前提になることです。Agentforceの主要な機能は、Enterprise Edition以上のエディションを利用していることが条件になります。Salesforce Foundationsを通じて、Enterprise Edition以上であれば追加費用なしで主要な機能を使え、20万クレジット分のFlex Creditsもあわせて付与されます。ただし付与量は変わることがあるため、契約の内容は個別に確認しておきましょう。産業機器メーカーの担当者は、自社が契約しているエディションを確認し、本番で使う前提が整っているかを先に確かめました。契約しているエディションが条件を満たしていないと、機能を使う前にエディションの見直しが必要になります。料金体系の詳細は、ほか記事「Agentforce料金・ライセンス完全ガイド」で解説していますので、あわせて参考にしてもらえると嬉しいです。（2026年8月時点の情報にもとづく）
ポイント③エージェントを動かすとアクション単位でFlex Creditsを消費する
3つ目のポイントは、エージェントを動かすと、アクション単位でFlex Creditsを消費することです。Agentforceの課金には、エージェントが処理を実行するたびに消費されるFlex Creditsがあります。目安として、Flex Creditsは10万クレジットあたり500ドルで、標準的なアクションは1回あたり20クレジット、金額にして0.10ドルほどを消費します。今回の担当者は、最初は一つの業務に絞って動かすことで、消費するクレジットを限られた範囲にとどめました。使い方の段階で対象を狭くしておけば、消費量も把握しやすく、想定外の費用が出ることを避けられます。毎日およそ30件の問い合わせに標準的なアクションを1回ずつ使うとすると、月20営業日で12,000クレジット、金額にして60ドルほどが目安になります。（2026年8月時点の目安）※参考記事はこちら
Agentforceは、検証はDeveloper Editionで無料で始められ、本番はEnterprise Edition以上とFlex Creditsが前提で、動かした分だけアクション単位でクレジットを消費します。
【一問一答】Agentforceの使い方に関するよくある質問
ここまで、Agentforceの使い方を、準備から公開までの手順とつまずき回避の観点で整理してきました。最後に、使い方を進めるうえでよく寄せられる質問に答えていきます。
質問①Agentforceの使い方にプログラミングの知識は必要か
必須ではありません。Agent Builderは会話型の画面でエージェントを設定でき、プロンプトビルダーも画面上の操作でひな型を作れるため、コードを書かなくても最初の1体は作れます。ただし、標準アクションの識別子を正しく指定するなど、設定の細部でつまずくことはあるため、本文で紹介した確認の手順を押さえておくと安心です。
質問②Agentforceの設定を試すDeveloper Editionは無料で使えるか
無料で使えます。Developer Editionは開発者向けの無料環境で、本番組織に影響を与えずにAgentforceの設定を試せます。ただし、使える機能の範囲には制限があるため、本番と同じ条件で確認したい場合は、その点を踏まえて使い分けるのが確実です。
質問③Agentforceの設定やプロンプトは日本語でもできるか
設定画面の操作やプロンプトの記述は日本語でも進められます。ただし、参照するデータや扱う内容によっては、意図どおりの精度が出ないことがあります。精度が思うように出ないときの原因は複数あるため、設定の言語だけでなく、参照データやトピックの切り方も含めて見直すことが大切です。
質問④作ったエージェントの動作確認はどの画面でできるか
Agent Builderのテスト画面で確認できます。実際の利用者になったつもりで質問を入力し、その場で応答を確かめられます。確認するときは、答えられたかどうかだけでなく、どのデータやアクションをもとに答えたのかまで見ておくと、公開後のトラブルを防げます。
質問⑤標準アクションが期待どおり動かないときはどこを確認するか
まず、指定したアクションの識別子が正しいかを確認します。画面上のラベルと実体の識別子は一致しないことが多いため、アクションの詳細画面にある参照アクション欄で、実際に呼び出される識別子を確かめます。構文検証が通っていても実在は保証されないため、テスト画面で実際に呼び出されるかまで見ることが確実です。
Agentforceの使い方は設定のつまずきどころを押さえれば身につく
Agentforceの使い方は、準備から作成、設定、テスト、公開までの手順自体は、公式の案内に沿えば大きく迷わずに進められます。ただ、実際につまずくのは、標準アクションの識別子がラベルから推測できない、構文検証が実在を確認しない、エージェントの作成上限が1組織あたり20体で決まっている、といった公式ドキュメントが説明を省いている箇所です。本記事では、中堅の産業機器メーカーの担当者が最初の1体を公開するまでを例に、これらのつまずきどころと回避法を、2026年8月時点の情報にもとづいて整理してきました。この担当者の場合、毎日およそ30件届いていた問い合わせのうち18件ほどを、最初の1体が受け持つようになっています。
つまずく箇所は決まっているからこそ、そこだけ先に押さえておけば、最初の1体は必ず公開まで到達できます。まずは無料のDeveloper Editionで、一つの業務に絞った小さな1体を、完璧を目指さずに作ってみてはいかがでしょうか。実際に操作して確かめることが、使い方を身につける最も早い方法です。
当社では、ソリューション営業に特化したAgentforceの導入・定着支援を行っています。自力での設定は進んだものの、設計が正しいか不安、あるいは現場に定着させるところまで一緒に考えてほしいという場合は、Agentforce導入・定着支援もあわせてご覧ください。