Agentforceのアクションとは、エージェントが業務のなかで実行する処理の単位のことです。エージェントを組み始めた段階で最初につまずくのが、このアクションをどう選べばよいのかという判断ではないでしょうか。設定の画面には標準で用意されたものが並んでいますが、その一覧を眺めても自社の業務に当てはまるかどうかは分からず、結局は自分で作り始めることになりがちです。作ってから業務に合わないと分かると、3週間かけた作業がそのまま作り直しになります。Agentforceを組む段階で効いてくるのは、作る技術より、作る前に何を確かめるかという順番のほうです。
そこで本記事では、アクションを決めないまま組み始めたときに何が起きるかから、業務から起こす4つの手順、標準で足りるかを見分ける条件、独自に作る前の確認、そして1業務から組む手順までを解説します。設定の画面の操作ではなく、選び方の基準として整理していますので、自社の状況に合わせて参考にしてください。なお、Agentforceで標準として用意されているアクションの範囲は変わることがあるため、本記事は2026年9月時点で確認できた情報にもとづいています。
- Agentforceのアクションを決めずに組んで止まる3場面
- 一覧で選べる?アクション選びが外れる理由3つ
- Agentforceのアクションを業務から起こす4手順
- 標準か独自か、どちらで作る?見分ける3つの条件
- 独自に作る前に確かめる3つのこと
- 何を任せる?Agentforceの呼び分けの線引き3つ
- アクションを1業務から組む4つのステップ
- アクションの設計でつまずく3つの落とし穴
- アクションが機能しているかをフェーズごとに測る
- 人がアクションを確かめるべき3つの場面
- 独自のアクションを作るべき企業の3つの条件
- 独自のアクションを作らなくてよい企業の3つの条件
- アクションの設計にかかる費用の3つの内訳
- アクションの設計に外部支援を使う4つの判断軸
- 【一問一答】Agentforceのアクションに関するよくある質問
- Agentforceのアクションは作る前に、標準で足りる範囲と足りない範囲を切り分けたところで決まる
当社はSalesforce公式コンサルティングパートナーとして、 ソリューション営業に特化したAgentforce導入・定着支援を 行っています。
- どのユースケースから始めればいいか分からない
- 設定は完了したが現場に定着しない
- ナレッジ設計から一緒に考えてほしい
というお悩みがあればお気軽にご相談ください。 1ユースケース×3ヶ月のスモールスタートプランから対応しています。
この記事を書いた人
合同会社クロスコムの代表|専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援と、Agentic CRM設計支援を提供している。Salesforce認定アドミニストレーター・Sales Cloudコンサルタント・Marketing Cloud Account Engagement スペシャリスト。
Agentforceのアクションを決めずに組んで止まる3場面
建設資材の卸売を手がける企業では、従業員150名のうち営業が16名、情報システムの担当が1名という体制でSalesforceを使ってきました。この企業は説明のための架空の設定であり、実在の企業ではありません。営業から情報システムへ届く在庫の照会をエージェントへ任せる計画を立て、当初の目的は「営業からの在庫照会を、情報システムの手を借りずに返せる状態にすること」でした。ところが最初から独自のアクションを作り始めた結果、3週間かけて組んだものが業務では使えず、作り直しになっています。そこでここでは、この会社を例に、アクションを決めないまま組み始めて止まる3つの場面を整理します。
場面①動くものはできたが、業務で使うと途中で止まる
検証の環境で動かしている限りは、アクションが呼ばれて結果が返るところまでは問題なく進みます。ところが実際の業務では、入力が足りない照会や、複数の商品をまとめて聞かれる照会が届き、想定した1つの型に収まりません。動くかどうかと業務で使えるかどうかは別の問いであり、前者を確かめても後者の保証にはならないというわけです。
この建設資材の会社でも、単一の商品コードを渡せば在庫が返るアクションを作っていました。ところが営業から実際に届く照会は、複数の商品を1通で聞くものが月に68件あり、そのうち半数近くは商品コードではなく通称で書かれています。届く照会の型を先に数えていれば、単一の商品コードを前提にした形では足りないことは、作り始める前に分かっていました。
場面②標準で足りるかを確かめず、最初から作り始める
標準で用意されているアクションを調べる作業は、画面を開いて一覧を追うだけで済みます。ところが一覧の項目名は機能の名前で並んでいるため、自社の業務の言い方とは一致せず、探しても見つからないという判断になりがちです。見つからないという結論が、実際には探し方の問題であることは珍しくありません。
この会社では、在庫を返すという処理が標準に無いと判断して独自に作り始めました。後から調べ直したところ、レコードを検索して項目を返すという標準のアクションを2つ組み合わせれば、求めていた動きの大半は再現できることが分かっています。3週間の作業のうち、実際に必要だったのは商品の通称を正式なコードへ変換する部分だけでした。
場面③似たアクションが増えて、どれを呼ぶか決まらなくなる
業務ごとにアクションを作っていくと、名前も動きも似たものが並ぶ状態になります。エージェントはどれを呼ぶかを名前と説明文から判断するため、似たものが増えるほど選択が揺れ、同じ照会でも呼ばれるアクションが日によって変わるという事態が起こります。呼ばれ方が安定しない原因は推論の側にあると受け取られがちですが、実際には選択肢の作り方にあることが多いといえます。
この会社では、在庫に関するアクションを3つ作った時点で呼び分けが揺れ始めました。名前が「在庫照会」「在庫確認」「在庫の残数」と並んでおり、説明文もほぼ同じだったためです。作る数を増やす前に、1つのアクションが受け持つ範囲を決めておく必要がありました。
3つの場面に共通しているのは、作る前に確かめる工程を持たないまま設定の画面へ入ってしまったという点です。動くものを作る作業そのものは難しくありませんが、業務で使えるかどうかは届く照会の形に左右されるため、照会を集めて型を見るという工程を挟まない限り、作ったものが合っているかどうかは分かりません。2026年9月時点のAgentforceでは、標準で用意されているアクションの一覧が公式のヘルプで公開されており、調べずに作り始める判断はそれだけ損になりやすくなっています。
※参考記事はこちら
一覧で選べる?アクション選びが外れる理由3つ
3つの場面はどれも、アクションを機能の一覧から選ぼうとしたことから起きています。一覧は用意されているものを網羅していますが、自社の業務がどれに当たるかまでは示さないため、選ぶ側の判断が要ります。そこでここでは、アクションを機能の一覧から選ぶと外れる3つの理由を整理します。
理由①一覧に並ぶのは名前であって、業務の単位ではないから
一覧に並んでいるのは、レコードを検索する、項目を更新する、外部へ問い合わせるといった処理の単位です。これに対して業務の側は、在庫を答える、納期を伝える、見積を出すという単位で動いています。処理の単位と業務の単位は粒度が違うため、名前を突き合わせても対応が見つからないのは当然だということになります。
対応を見つけるには、業務の単位を処理の単位まで分解する作業が要ります。在庫を答えるという業務であれば、商品を特定する、在庫の数を取る、返す形に整えるという3つの処理に分かれます。分解してから一覧を見れば、それぞれに当たる標準のアクションが見つかることが多いといえるでしょう。
理由②同じ名前でも、渡す項目が業務と合っているとは限らないから
名前が業務と一致しているアクションが見つかったとしても、そのアクションが受け取る項目と自社が渡せる項目が一致しているとは限りません。商品コードを受け取る設計になっているところへ、営業が使う通称しか渡せないのであれば、そのアクションは業務では機能しません。名前の一致は出発点であって、判断の材料としては足りないというわけです。
確かめるのは、そのアクションが要求する入力を自社の側で用意できるかという一点です。用意できないのであれば、変換する処理を先に置くか、別の入力で動く形へ組み替えるかのどちらかになります。変換する処理を1つ置けば済むのか、入力の形から見直す必要があるのかで、作る量は大きく変わります。
理由③呼ばれる条件を決めていないと、揺れが後から出るから
エージェントはどのアクションを呼ぶかを、名前と説明文をもとに判断します。似たアクションが並んでいれば判断は揺れますし、説明文が業務の言葉で書かれていなければ、届いた照会との対応も取りにくくなります。呼ばれる条件は設定として明示するものではないため、書き方でしか制御できない部分です。
だからこそ、アクションを作る段階で「どういう照会が来たときに呼ばれるべきか」を1文で書いておく必要があります。この1文がそのまま説明文になり、呼ばれ方の安定につながります。揺れが出てから調整するより、作る時点で書いておくほうが手間は小さく済みます。
3つの理由はどれも、一覧を出発点にしたことから生まれています。一覧は用意されているものを漏れなく並べるための道具であり、自社の業務がどれに当たるかは、業務を処理の単位まで分解した側からしか見えてきません。だからこそ、次の章では業務の側から分解する手順を先に置いています。
Agentforceのアクションを業務から起こす4手順
では、一覧を見るところから始めないとすると、何から手を付ければよいのでしょうか。業務の側から分解していくと、必要なアクションは自然に決まり、標準で足りるかどうかも同時に見えてきます。そこでここでは、アクションを業務から起こす4つの手順を整理します。
手順①任せたい作業を1文で書く
最初にやるのは、任せたい作業を1文で書くことです。「営業から届いた商品の在庫数を返す」というように、主語と対象と動作がそろった形にします。この1文が曖昧なままだと、後の分解も曖昧になり、作るべきものが決まりません。
ツール設定ではなく業務設計から入ってほしい場合は、この1文を一緒に書くところから始められるかどうかが、支援会社を見る目安になります。設定の画面から入る提案は、この1文を飛ばしていることが多いためです。1文が書けていれば、その後の作業は自社でも進められます。
手順②その作業に必要な入力と出力を並べる
次に、その作業を成り立たせる入力と出力を並べます。在庫を返す作業であれば、入力は商品を特定する情報、出力は在庫の数と拠点になります。ここで並べる項目が、そのままアクションが受け取る項目と返す項目になっていきます。
この会社では、入力として商品コードと拠点、出力として在庫数と入荷予定日を並べました。並べてみて初めて、営業が渡してくるのは通称であり、想定した商品コードとは一致しないという食い違いが表に出ています。並べた項目と実際に渡ってくる項目が違っていれば、その時点で変換の処理が要ると分かるため、作った後の作り直しは起きません。
手順③入力がどこから来るかをたどる
3つ目は、並べた入力がどこから来るのかをたどる作業です。営業が文章で書いてくるのか、画面から選ぶのか、別の仕組みが持っているのかで、必要になる処理が変わります。文章で書かれてくるのであれば、そこから項目を取り出す処理が先に要ることになります。
この作業を飛ばすと、アクションは作ったのに渡す項目がそろわないという状態になります。この建設資材の会社が最初に作ったものが業務で使えなかったのも、入力の出どころを確かめていなかったためでした。たどる先が社外の仕組みであれば、そこへ接続する前提の確認も必要になります。
手順④出力を誰が受け取るかを決める
最後は、出力を誰がどの形で受け取るかを決めます。営業が画面で読むのか、そのまま顧客へ転送するのかで、返す形も、人の確認を挟むかどうかも変わります。受け取る相手が決まっていないと、返す形が決まらず、アクションの設計も終わりません。
この会社では、在庫の数を営業が画面で読む形にしました。顧客へそのまま転送する形にしなかったのは、入荷予定日が確定していない商品が月に12件ほどあり、そのまま伝えると訂正が発生するためです。受け取る相手を決めることが、人の確認をどこに置くかの判断にもつながっています。
4つの手順は、いずれも設定の画面を開かずに紙の上で終わります。任せたい作業を1文で書き、入力と出力を並べ、入力の出どころをたどり、出力の受け取り手を決めるという4つで、必要なアクションの輪郭はほぼ決まります。この4つを飛ばして画面から入ると、作ったものが業務と合わないという結果になりやすいと考えます。
標準か独自か、どちらで作る?見分ける3つの条件
業務から起こした入力と出力がそろえば、次は標準で足りるかどうかの判断です。ここを先に済ませておくと、独自にアクションを作る範囲は驚くほど小さくなります。そこでここでは、標準で足りるかを見分ける3つの条件を整理します。
| 条件 | 確かめること | 外れたときの対処 |
|---|---|---|
| ①扱う対象 | 標準の項目に収まるか | 処理の形が標準か見る |
| ②入力の項目 | 毎回同じでよいか | 前段に組み立てを足す |
| ③出力の形 | 返す形が決まっているか | 整える処理を足す |
条件①扱う対象がSalesforceの標準の項目に収まるか
1つ目の条件は、扱う対象が標準で用意されている項目に収まるかどうかです。取引先や商談のように標準で持っている対象であれば、検索も更新も標準のアクションで足ります。独自に追加した項目だけで完結する場合も、多くは標準の検索で扱える範囲に入ります。
標準で何が用意されているかを調べる手順は、定義をコードで管理する側の記事で扱っており、画面から一覧をたどるより速く確かめられます。調べる前に作り始めてしまうのが最も損なので、この確認だけは省かないほうがよいでしょう。
条件②入力の項目が固定でよいか
2つ目は、入力として渡す項目が毎回同じでよいかどうかです。商品コードと拠点という2項目で毎回足りるのであれば、標準のアクションをそのまま使えます。照会のたびに渡す項目が変わるのであれば、その前段で項目を組み立てる処理が要ることになります。
判断の材料は、届いた照会を20通ほど並べて、渡せる項目が同じかどうかを見るだけで足ります。この会社では、20通のうち14通は商品の通称しか書かれておらず、項目としては固定にできませんでした。この時点で、変換する処理が要ることが確定しています。
条件③出力の形が決まっているか
3つ目は、返す形が決まっているかどうかです。在庫数という1つの値を返すだけであれば標準で足りますが、複数の商品をまとめて表にして返すのであれば、整える処理が要ります。返す形は受け取る相手が決めるため、手順④で決めた内容がそのまま条件になります。
3つの条件のうち1つでも外れるなら、外れた部分だけを独自に作れば足り、全部を作り直す必要はほとんどありません。この切り分けができているかどうかが、作業量を大きく左右します。
3つの条件を当てる作業そのものは、届いた照会を20通ほど並べれば半日で終わります。2026年9月時点のAgentforceには、レコードの照会やレコードの更新といった処理が標準のアクションとして用意されており、扱う対象が標準に収まっているならこの範囲で足りることが多くあります。調べる工程を半日かけるか、作る工程を3週間かけるかという選択だと考えると、先に条件を当てる価値は分かりやすいはずです。
※参考記事はこちら
独自に作る前に確かめる3つのこと
条件に照らして足りない部分が見つかったとしても、すぐにアクションを作り始めるのは早いといえます。作った後に残る負担まで含めて考えると、判断が変わることがあるためです。そこでここでは、独自に作る前に確かめる3つのことを整理します。
確認①似た標準のアクションを組み合わせて代替できないか
最初に確かめるのは、標準のアクションを2つ3つ組み合わせて同じ動きを作れないかという点です。1つで足りないからといって独自に作る必要はなく、順番に呼ぶ形で足りることは多くあります。組み合わせで済むなら、作る作業も、後から直す作業も発生しません。
この建設資材の会社でも、後から調べ直したところ、レコードを検索する標準のアクションと項目を返す標準のアクションを組み合わせれば、求めていた動きの大半は再現できました。組み合わせで代替できるかを先に確かめたことが、独自に作る対象を通称の変換1つに絞る結果につながっています。
確認②作った後に誰が直し続けるか
2つ目は、作った後に誰が直すのかという点です。独自に作ったものは、参照する項目が変わったときや業務の型が変わったときに、直す必要が出てきます。作った本人しか中身を知らない状態だと、その人が動けないあいだは止まることになります。
自社で構築するので設計レビュー・アドバイザリーだけ頼みたい場合は、この直し続ける体制をどう作るかだけを相談するという形も成り立ちます。作る作業そのものより、作った後の引き継ぎのほうが判断の難しい部分だといえるでしょう。
確認③その作業が月に何回起きるか
3つ目は、その作業が月に何回起きるかという回数です。回数が少ない作業のために独自のアクションを作ると、構築と維持の工数が業務の削減量を上回ります。回数は、いま人が処理している件数を数えれば分かるため、判断に時間はかかりません。
この会社では、在庫の照会が月に210件ありました。この件数であれば作る価値があるという判断になりましたが、月に十数件の別の照会については、独自に作らず人が処理する形を残しています。作らないという判断も、設計の一部だと考えます。
3つの確認は、作る前に立ち止まるための工程です。代替できないか、直し続けられるか、回数が見合うかという3つを順に当てると、作る範囲は当初の見込みより小さくなることがほとんどでした。作らずに済ませた部分は、後から直す工数も発生しないため、二重に効いてくることになります。
何を任せる?Agentforceの呼び分けの線引き3つ
作る範囲が決まると、次は呼び分けをどこまで任せるかという話になります。すべてを任せると外部へ出る処理まで自動で走り、すべてを固定すると柔軟さが失われます。そこでここでは、アクションの呼び分けをAIに任せる3つの線引きを整理します。
線引き①どのアクションを呼ぶかは任せる
届いた照会に対してどのアクションを呼ぶかという判断は、機械に任せられます。照会の書き方は毎回違うため、条件を人が書き切ることはできず、名前と説明文から選ばせるほうが現実的です。任せる前提として、説明文が業務の言葉で書かれていることが要ります。
説明文の書き方は、前の章で挙げた「どういう照会が来たときに呼ばれるべきか」の1文をそのまま使えば足ります。この会社では、3つ並んでいた在庫関連のアクションを1つに統合し、説明文を「営業から商品の在庫数を尋ねられたとき」と書き直しました。統合と書き直しの後、呼び分けの揺れは出ていません。1体のエージェントで抱えきれないほどアクションが増えた場合は、サブエージェントへの分割という選択肢もあります。
線引き②渡す項目の埋め方は任せるが、必須の項目は人が決める
照会の文面から項目を取り出して埋める作業も、機械に任せられます。ただしどの項目が必須なのかという判断は、人が決めておく必要があります。必須の項目が埋まらないまま実行されると、返ってくる結果が業務として意味を持たなくなるためです。
この会社では、商品を特定する情報を必須に置き、拠点は空欄でも動く形にしました。拠点が指定されない照会が全体の3割ほどあり、その場合は全拠点の在庫を返す設計にしています。必須をどこまで絞るかは、業務でどこまで許容できるかで決まります。
線引き③外部へ出る処理の実行は人の承認を挟む
社外の仕組みへ書き込む処理や、顧客へ直接届く処理については、実行の前に人の承認を挟みます。誤って実行されたときに取り消せない性質のものは、機械の判断だけで走らせない形にしておくほうが安全です。一任と承認の境界の置き方は人が承認する場面の設計として整理できます。
この線引きは、機械の精度の問題ではなく取り消せるかどうかの問題として置いています。取り消せる処理であれば任せてよく、取り消せない処理は承認を挟む、という基準にしておくと判断が揺れません。
3つの線引きに共通しているのは、任せているのが選択と抽出という繰り返しの作業だけだという点です。何を必須とするか、どこから先を人が承認するかという判断は、業務でどこまで許容できるかを決める作業であり、そこを任せてしまうと運用が始まってから説明が続かなくなります。
アクションを1業務から組む4つのステップ
線引きが決まれば、あとは着手の順番だけです。複数の業務を同時に組もうとすると、アクションが増えて呼び分けが揺れます。そこでここでは、アクションを1業務から組む4つのステップを整理します。
ステップ①件数の多い業務を1つ選ぶ
最初に、対象とする業務を1つに絞ります。選ぶ基準は件数の多さで、いま人が処理している件数が最も多いものから入るのが確実です。件数が多い業務ほど、組んだときの効果も、届く照会の型を集める作業も進めやすくなります。
小さく始めたい場合は、この1つに絞るという決め方がそのまま最初の設計になります。この建設資材の会社では、月210件の在庫照会を最初の対象にしました。2番目に多い納期の照会が月80件だったため、件数の差で迷わず決められています。
ステップ②標準で足りるかを条件に当てる
次に、その業務について標準で足りるかを3つの条件へ当てます。扱う対象が標準の項目に収まるか、入力の項目が固定でよいか、出力の形が決まっているかを順に見ていきます。1つでも外れたら、外れた部分だけを次のステップで作ることになります。
この確認は、設定の画面を触らずに紙の上で終わります。届いた照会を20通並べて条件に当てるだけの作業であり、この会社では半日で終わりました。設定の手順そのものは設定の手順の側で扱っており、条件の確認とは別の作業になります。
ステップ③足りない部分だけを独自に作る
条件から外れた部分だけを独自に作ります。全体を作り直すのではなく、変換や整形といった小さな処理を1つ足す形が大半です。作る範囲が小さいほど、後から直す負担も小さくなります。
この会社が作ったのは、商品の通称を正式なコードへ変換する処理だけでした。作業は2日で終わり、当初の見込みだった3週間とは大きな差が出ています。標準で足りる範囲を先に切り分けたことが、この差を生んでいます。
ステップ④呼ばれ方を記録して、条件を直す
組み終わったら、どのアクションが呼ばれたかを記録します。意図したものが呼ばれているか、呼ばれずに終わった照会がどれだけあるかを見て、説明文や必須の項目を直していきます。1回で完成させる必要はなく、記録を見ながら寄せていく形が現実的です。
この会社では、最初の2週間で意図したアクションが呼ばれた割合が78%でした。呼ばれなかった照会を読み返すと、複数の商品をまとめて聞く形が多かったため、説明文にその場合の扱いを書き足しています。記録がなければ、この直し方にはたどり着けませんでした。
4つのステップを1つの業務に絞って回すと、着手から運用までは数週間で届きます。2つ目以降の業務は、すでに作った対応表へ行を足す形で進められるため、同じ期間はかかりません。最初の1つに時間をかけることが、結果として全体を早く終わらせる形になるというわけです。
アクションの設計でつまずく3つの落とし穴
4つのステップは、順番どおりに進めれば数週間で運用に入ります。ところが途中で作業が膨らむ会社もあり、膨らみ方には共通した型があるものです。そこでここでは、アクションの設計でつまずく3つの落とし穴を整理します。
落とし穴①1つのアクションに複数の作業を詰め込む
1つ目は、1つのアクションに複数の作業を詰め込んでしまう形です。在庫を返すついでに履歴も残す、といった作り方をすると、片方だけを使いたい場面で流用できなくなります。作業の単位で分けておけば、後から別の業務で組み替えて使えます。
分ける目安は、手順②で並べた入力と出力の組が1つに収まるかどうかです。入力の組が2種類あるなら、それは2つのアクションだということになります。詰め込んだものは、直すときにも影響の範囲が読めなくなってしまいます。
落とし穴②標準を調べずに同じものを作る
2つ目は、標準にあるものを調べずに同じ処理を作ってしまう形です。この会社が3週間を使ったのも、まさにこの落とし穴に当たります。調べる作業は半日で終わるため、作り始める前に必ず挟むべき工程だといえます。
調べる範囲は、扱う対象と処理の種類の2つで絞れます。検索なのか更新なのか外部への問い合わせなのかを決めれば、見るべき項目は数個に収まります。一覧を最初から最後まで読む必要はありません。
落とし穴③呼ばれなかった記録を見ない
3つ目は、呼ばれた記録だけを見て、呼ばれなかった照会を見落とす形です。意図したアクションが呼ばれた割合だけを追っていると、そもそもどのアクションも呼ばれずに終わった照会が視界から外れます。改善の手がかりは、むしろ呼ばれなかったほうに多く含まれています。
この会社では、呼ばれずに終わった照会が最初の2週間で22%ありました。読み返すと、複数商品をまとめて聞く形と、在庫ではなく納期を聞いている形の2種類に分かれています。前者は説明文の追記で解決し、後者は別の業務として切り分けました。
3つの落とし穴は、どれも作業を早く進めようとした結果として生まれています。詰め込むのは呼び出しを減らすためですし、調べないのは着手を早めるためです。それでも結果として時間がかかるのは、確かめる工程を省いた分が後から作り直しとして戻ってくるからだと考えます。
アクションが機能しているかをフェーズごとに測る
落とし穴を避けて運用が始まったあと、次に必要になるのは効果の説明です。ただし組んだ直後と運用が続いた後では、見るべき数字が入れ替わります。そこでここでは、アクションが機能しているかをフェーズごとに測る形を整理します。
段階①組んだ直後|意図したアクションが呼ばれた割合
組んだ直後に見るのは、意図したアクションが呼ばれた割合です。この段階では高い数字を目指す必要はなく、呼ばれなかった照会の型が分かれば足ります。割合そのものより、外れた照会をどう分類できるかが重要になります。
当初の目的は「営業からの在庫照会を、情報システムの手を借りずに返せる状態にすること」でしたが、最初の2週間では呼ばれた割合が78%でした。この時点で目的には届いておらず、外れた22%を読み返すところから次の手が決まっています。
段階②広げる時期|1件あたりの手戻りの回数
対象を広げる時期に見るのは、1件あたりの手戻りの回数です。アクションが呼ばれて結果が返っても、営業が情報システムへ聞き直しているなら、業務としての時間は減っていません。手戻りの回数は、呼ばれた割合よりも、営業の作業時間が実際に減ったかどうかをよく表す数字になります。
この会社では、在庫照会に関する情報システムへの問い合わせが月210件から月34件へ変わりました。残る34件は、在庫ではなく代替品の可否を尋ねるもので、もともとアクションの対象に含めていなかった型です。減った数より、残った型が説明できることのほうが運用では効いてきます。
段階③続ける時期|使われていないアクションの数
運用が続く時期に見るのは、作ったのに使われていないアクションの数です。使われていないものが増えていくと、呼び分けの選択肢だけが増え、揺れの原因になります。四半期に一度、呼ばれた回数がゼロのものを外す運用にしておくと、選択肢は整理された状態を保てます。
外す判断は、業務が無くなったのか、呼ばれない書き方になっているのかを見て決めます。後者であれば説明文を直せば足り、外す必要はありません。数だけを見て機械的に外すと、必要なものまで消えてしまいます。
3つの段階は、そのまま上長や経営へ説明する順番にもなります。組んだ直後には何が噛み合っていないかを示し、広げる時期には手戻りが減ったことを示し、続ける時期には選択肢が整理されていることを示すという組み立てです。呼ばれた割合だけを最後まで追い続けると、手戻りが減ったことも、選択肢が整理されたことも数字で示せなくなります。
人がアクションを確かめるべき3つの場面
指標が動き始めても、機械に任せてよい範囲は無条件には広がりません。取り消せない処理が絡む場面では、人が確かめる形を残すことになります。そこでここでは、人がアクションを確かめるべき3つの場面を整理します。
場面①外部の仕組みへ書き込む処理
社外の仕組みへ書き込む処理は、人が確認します。書き込んだ後に取り消せない場合があり、誤った内容が相手側の記録として残ると、訂正の手間は自社の中で完結しません。読み取るだけの処理と書き込む処理を分けて扱うのが基本になります。
この会社では、在庫の照会は読み取りだけで完結するため、確認を挟んでいません。一方で受注の登録に関わる処理は、書き込みが発生するため対象から外しました。読み取りと書き込みで扱いを分けたことが、確認の量を増やさずに済んだ理由です。
場面②顧客へ直接届く処理
顧客へ直接届く処理も、人が確かめます。内容が正しくても、伝え方や時期によって受け取られ方が変わるためです。社内向けに返す処理であれば読み手が補えますが、社外へ出る処理には補う人がいません。
この会社が在庫の回答を営業の画面で止めたのも、この考え方によるものです。入荷予定日が確定していない商品が月に12件あり、そのまま顧客へ届くと訂正が必要になります。誰が受け取るかを手順④で決めておいたことが、ここで効いてきます。
場面③標準の仕様が変わった直後
標準で提供されているアクションの仕様が変わった直後は、人が動きを確かめます。受け取る項目や返す形が変わると、組み合わせて使っていた処理が想定どおりに動かなくなることがあるためです。変更の情報は公式の発表で確認でき、四半期に一度見ておけば追いつきます。
確認の対象は、その標準アクションを使っている業務に限ります。全部を見直す必要はなく、どのアクションをどの業務で使っているかの対応表があれば数時間で終わります。この対応表は、作った時点で残しておくと後で効いてきます。
人が確かめる範囲を決めておくことは、任せる範囲を広げるための前提でもあります。どこまでを人が見るのかが曖昧なままだと、担当者は不安から全件を確認するようになり、機械へ任せた意味が薄れてしまいます。逆に、読み取りだけで完結する処理まで確認の対象に含めると、担当者の作業が増えるだけで、確かめる意味は生まれません。
独自のアクションを作るべき企業の3つの条件
ここまでの手順は、どの会社でも同じ順番で進められます。ただし独自に作るかどうかの判断は会社によって分かれ、作らないほうが早い場合もあります。そこでここでは、独自のアクションを作るべき企業の3つの条件を整理します。
条件①扱う対象が独自の項目に載っている
1つ目は、業務で扱う対象が独自に追加した項目に載っている場合です。標準の対象から外れているほど、標準のアクションだけでは届かない範囲が増えます。この場合は、独自に作る前提で見積もりを立てるほうが計画は現実的になります。
ただし独自の項目であっても、検索や更新という処理の形が標準に収まっていれば、標準のアクションで扱えることは多くあります。載っている場所が独自だから作るという判断ではなく、処理の形が標準に収まるかで見るほうが正確です。
条件②同じ作業が月に一定の回数を超える
2つ目は、同じ作業が月に一定の回数を超える場合です。回数が多いほど、作る工数を回収できる見込みが立ちます。この会社では月210件という件数が判断の根拠になりましたが、業務の1件あたりにかかる時間によって、必要な回数は変わります。
判断の材料は、いま人が処理している件数と、1件あたりにかかっている時間の2つで足ります。この2つを掛けた時間が、作る工数を上回るかどうかを見れば結論は出ます。回数が読めない業務は、まず人が処理する形で数えるところから始めます。
条件③直し続ける担当を置ける
3つ目は、作った後に直し続ける担当を置ける場合です。独自に作ったものは、業務や項目が変わるたびに直す必要が出てきます。担当を置けないまま作ると、動かなくなった時点で誰も触れない状態が残ります。
担当は専任である必要はなく、四半期に一度確かめる時間を確保できれば足ります。2026年9月時点で公式のヘルプに載っているAgentforceの標準アクションの一覧を、四半期に一度見直す程度の頻度であれば、変化を追いながら自社で回せる範囲に収まります。この建設資材の会社では情報システムの担当が1名でしたが、対応表を残したことで、確かめる作業は数時間で終わる形になっています。
独自のアクションを作らなくてよい企業の3つの条件
一方で、独自に作らずに進められる会社もあります。作らないという判断ができれば、着手から運用までの期間は大きく縮みます。そこでここでは、独自のアクションを作らなくてよい企業の3つの条件を整理します。
条件①標準の項目だけで作業が完結する
扱う対象も参照する項目も標準に収まっているなら、標準のアクションの組み合わせで足ります。組み合わせで足りるかどうかは、業務を処理の単位まで分解してから一覧を見れば確かめられます。この確認だけで済むなら、着手から運用までは数日の話になります。
判断を早めるには、分解の粒度をそろえておくことです。検索する、更新する、外部へ問い合わせるという3つの動詞に寄せると、一覧との対応が取りやすくなります。細かく分けすぎると、かえって対応が見えにくくなってしまいます。
条件②件数が少なく、人が処理しても負担が変わらない
件数が少ない業務であれば、作る工数のほうが大きくなります。月に十数件の照会であれば、人が処理しても業務の負担はほとんど変わりません。この場合は対象から外し、件数が増えた時点で改めて判断すれば足ります。
外すという判断は、後ろ向きなものではありません。対象を絞るほど、残した業務の設計に時間をかけられます。この会社が在庫の照会に集中できたのも、ほかの照会を対象から外したためです。
条件③直す担当を置けない
作った後に直す担当を置けないのであれば、独自に作らないほうが安全です。動かなくなったときに触れる人がいない状態は、業務にとっては使えない状態と変わりません。標準のアクションであれば、仕様が変わっても提供側が保ってくれる範囲が広くなります。2026年9月時点で提供されている標準のアクションを組み合わせて使う形にしておけば、直す担当を置けない期間も業務を止めずに進められます。
担当を置けるようになってから作るという順番でも、遅くはありません。それまでは標準の範囲で組み、足りない部分は人が処理する形を残しておけば、業務は止まらずに進みます。
アクションの設計にかかる費用の3つの内訳
条件が当てはまるとなると、次に出てくるのは費用の話です。アクションの費用は、作る工数だけでは見積もれません。そこでここでは、アクションの設計にかかる費用の3つの内訳を整理します。
内訳①実行のたびに発生する分
1つ目は、アクションが実行されるたびに発生する分です。エージェントが動いて何かを返す以上、実行の回数に応じた消費が積み上がります。見込みを立てるには、1か月あたりの実行回数を業務の実績から置く必要があります。
料金の考え方そのものは料金の考え方の側で整理しています。この会社では月210件という実績をそのまま上限として置き、平均ではなく上限で見込む形にしました。上限で置いておけば、繁忙期に超えて説明を求められることもありません。
内訳②独自に作る場合の構築の工数
2つ目は、独自に作る場合の構築にかかる工数です。作る範囲が小さいほど工数も小さくなるため、標準で足りる範囲を先に切り分けておくことが、そのまま費用の削減になります。この会社では当初3週間を見込んでいた作業が、切り分けの後には2日で終わっています。
工数は見積書の金額には現れませんが、社内の時間として確実に発生します。稟議へ出すときは、誰の時間が何時間使われるかまで書き出しておくと、後から「聞いていない」という話にはなりません。
内訳③仕様が変わったときの直しの工数
3つ目は、標準の仕様や業務の型が変わったときに直す工数です。独自に作ったものほど、変化のたびに手を入れる必要が出てきます。四半期に一度の確認を前提に、年間でどれだけの時間を見込むかを先に置いておくほうが実態に合います。
この会社では、5つのアクションと3つの業務の対応を1枚の表にまとめたことで、四半期の確認にかかる時間は2時間ほどに収まる見込みになりました。対応表が無ければ、どのアクションがどの業務で使われているかを毎回たどり直すことになります。作る時点で残す資料が、後の工数を決めるというわけです。
アクションの設計に外部支援を使う4つの判断軸
ここまでの内容は、情報システムの担当が1名いれば自社でも進められる範囲です。とはいえ業務の分解や標準の調べ方で迷う場面はあり、外部の支援を検討する会社もあります。そこでここでは、アクションの設計に外部支援を使う4つの判断軸を整理します。
判断軸①業務から起こす手順を持っているか
1つ目は、業務から起こす手順を持っている相手かどうかです。設定の画面の説明から始まる提案は、任せたい作業を1文で書くという工程を飛ばしていることが多くあります。最初の打ち合わせで、実際の照会を見せてほしいと言われるかどうかで、この差は見えてきます。
判断軸②標準で足りる範囲を先に示すか
2つ目は、標準で足りる範囲を先に示すかどうかです。作る前提で話が進む提案は、工数が大きくなるほど相手の売上にもなるため、切り分けが後回しになりがちです。標準の組み合わせで足りる部分を先に示してくれる相手のほうが、結果として自社に残る形になります。
判断軸③作った後の直し方まで決めるか
3つ目は、作った後にどう直すかまで含めて決めるかどうかです。独自に作ったものは変化のたびに手が要るため、直し方が決まっていないと運用が止まります。定着まで伴走してほしい場合は、この直し方の取り決めが契約の範囲に入っているかを確かめておくとよいでしょう。
判断軸④自社の担当が引き取れる形で残すか
4つ目は、支援が終わった後に自社で回せる形が残るかどうかです。どのアクションをどの業務で使っているかの対応表が自社の言葉で残っていれば、担当が代わっても続けられます。支援先を比べる観点をより広く持ちたい場合は、導入支援会社の選び方で7つの見極め方を整理しています。なお当社では、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援を提供しており、アクションの切り分けについても無料相談を受け付けています。
【一問一答】Agentforceのアクションに関するよくある質問
ここまで、アクションを業務から起こす手順から、標準で足りるかの条件、独自に作る前の確認、呼び分けの線引き、費用の内訳までを整理してきました。実際に組む段階では、標準の範囲や担当の置き方といった細かい点で迷う場面が出てきます。そこでここでは、アクションの設計を進める場でよく出る質問に順に答えていきます。
扱う対象と処理の形が標準に収まっていれば、多くの場合は足ります。この建設資材の会社でも、後から調べ直したところ、標準のアクションを2つ組み合わせれば求めていた動きの大半を再現できました。独自に作ったのは通称をコードへ変換する部分だけで、作業は2日で終わっています。
作る範囲によって変わります。項目を組み立てる程度であれば画面上の設定で足りることが多く、外部の仕組みへ接続する場合は開発の知識が要ります。この会社では情報システムの担当1名が2日で作れる範囲に収まりました。
数の上限より、増えたときに呼び分けが揺れることのほうが先に問題になります。この会社では在庫に関するアクションを3つ作った時点で呼ばれ方が揺れ始め、1つに統合しています。増やす前に、1つのアクションが受け持つ範囲を決めておくほうが確実です。
まず似た名前のアクションが並んでいないかを見ます。この会社では「在庫照会」「在庫確認」「在庫の残数」という3つが並んでおり、説明文もほぼ同じでした。統合して説明文を業務の言葉で書き直した後、揺れは出ていません。
業務を分解する部分は業務を知っている人が担い、標準の調べ方と設定は情報システムの担当が担うという分担が現実的です。この会社では情報システムが1名でしたが、照会の型を集める作業は営業16名を束ねる責任者と一緒に進めています。
Agentforceのアクションは作る前に、標準で足りる範囲と足りない範囲を切り分けたところで決まる
Agentforceのアクションをどう組むかは、作る技術で決まるわけではありません。決まるのは、任せたい作業を業務から分解し、標準で足りる範囲と足りない範囲を切り分けられるかどうかのほうです。当初の目的は「営業からの在庫照会を、情報システムの手を借りずに返せる状態にすること」でしたが、この建設資材の会社が目的に届いたのは、作り方を変えたときではなく、作る前に切り分けたときでした。
本記事で整理した4つの手順、3つの条件、3つの確認、4つのステップは、いずれも設定の画面を触らずに紙の上で終わります。任せたい作業を1文で書き、入力と出力を並べ、標準で足りるかを条件に当て、足りない部分だけを作ります。この順番を守れるかどうかが、3週間かかるか2日で終わるかを分けます。本記事の内容が、自社の検討の材料として少しでもお役に立てれば幸いです。

