【2026年9月時点】Agentforce Gridとは？一括処理を任せる範囲の決め方と費用の見方

Agentforce Gridとは、Salesforceのレコードを表計算のように行へ並べ、AIの処理を列として一括で実行する面のことです。エージェントを1体組んで動かせるところまで進んだ担当者が次に持ち出すのは、たまっている記録をまとめて処理したいという要望です。Agentforceを1件ずつの会話で使っている限り、数千件の記録は手つかずのまま残り続けます。

そこで本記事では、記録がたまったまま動かせない状態がなぜ起きるかから、Gridが持つ4種類の列、まとめて処理してよい仕事を見分ける条件、エージェントとの線引き、そして費用の増え方までを解説します。軸に置いたのは、どの仕事を任せてよいかという判断で、画面の操作手順は扱いませんので、自社の検討の順番を決める材料として参考にしてください。なお、本機能は提供が始まったばかりで条件も変わりやすいため、本記事は2026年9月時点で確認できた情報にもとづいています。

この記事を書いた人

本田正憲

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

Agentforce Gridを調べる前の3つの場面

ビル設備の保守を手がける企業は、従業員380名で、そのうちカスタマーサポートが14名、情報システムの担当が3名という編成でSalesforceを運用してきました。この企業は説明のための架空の設定であり、実在の企業ではありません。問い合わせの記録は3年で12,000件たまっており、当初の目的は「たまった問い合わせの記録を分類して、多い順に手を打てる状態にすること」でしたが、人手では終わらないまま着手の判断が半年止まっています。そこでここでは、この会社の状況をもとに、Agentforce Gridを調べる前に起きている3つの場面を整理します。

場面①分類したい記録が数千件あり、人手では終わらない

記録の分析が進まない理由は、分析のやり方が分からないからではなく、件数に対して人の時間が足りないという一点にあります。何を見ればよいかは決まっていて、1件を読めば数分で分類できるにもかかわらず、全体に手が届かないのは、件数を掛け算した時間が確保できないためです。

このビル設備の会社でも、直近1年ぶんの4,200件を対象にすると決めていました。1件あたり2分で分類できるとして、合計で140時間かかります。カスタマーサポート14名がほかの業務を止めて取りかかる形にはできず、着手の判断だけが残りました。

同じ状態は、たまっている記録の種類が増えるほど起こりやすくなります。片づけたい記録が1種類なら順番を待てばよいのですが、複数の種類が同時にたまっていると、どれから手を付けるかを決める作業が先に必要になるためです。分析の設計より先に、件数と時間の掛け算が現実的かどうかを確かめておくと、止まる場所が早く見えてきます。

場面②1件ずつ試すと動くのに、件数が増えると誰も回さなくなる

エージェントに1件ずつ読ませて分類させる形は試した範囲では問題なく動きますが、本番の件数になると、誰かが1件ずつ投げ続ける作業が発生し、その担当を置けないまま止まります。動くことと運用に乗ることは別だというわけです。

先ほどの会社の担当者も、まず10件ほどをエージェントへ投げて分類の精度を確かめました。返ってきた分類はおおむね妥当でしたが、残る4,190件を同じやり方で処理する段になって、誰が投げるのかという問いに答えが出ていません。

試す規模と本番の規模のあいだにあるのは、投げる担当を決める工程です。この工程を飛ばしたまま件数を増やすと、精度に問題がなくても、誰も回さないという理由で止まることになります。1件で確かめた結果をそのまま全件へ広げられるとは限らず、広げる工程を誰が担うかまで決めて、はじめて試したことになります。

場面③やり方は決まっているのに、着手の判断が半年止まっている

3つ目は、方法も担当も見えているのに決裁が下りない状態です。効果が読めない作業に人の時間を割り当てる判断は、他の業務と比べられた時点で後回しになります。

この会社では、分類の結果を使って保守契約の見直しにつなげる計画まで立てていました。ところが分類そのものに140時間かかる見込みが示されたことで、投資に見合うかどうかの議論が始まり、半年のあいだ結論が出ないまま止まっています。

止まっている理由は、担当者のやる気や理解の不足にはありません。効果が見えるのは分類が終わった後なのに、判断が求められるのはその前という順番になっているためです。

これが、Agentforce Gridを調べる前に起きている3つの場面でした。いずれも原因は分析の設計にはなく、件数を処理する手段の側にあります。

会話で足りる？Agentforceで件数に耐えない理由3つ

前章では、記録がたまったまま動かせない3つの場面を整理しました。では、なぜ会話の形では件数に耐えられないのでしょうか。それは、会話が1件ごとに人の操作を前提にした形になっているからです。そこでここでは、1件ずつ会話で処理する形が件数に耐えない3つの理由を解説します。

理由①会話は1件ごとに人が始める前提になっているから

1つ目の理由は、会話の形が「人が話しかけたら答える」という順番でできているからです。1件ごとに誰かが投げる操作が必要になるため、件数がそのまま人の作業量になります。

このビル設備の会社の場合、4,200件を1件ずつ投げるとなると、投げる作業だけで担当者の時間が埋まります。読ませて分類させる部分をAIが担っても、始める操作が人に残っている限り、件数に対する時間は減りません。

1件あたりの処理を速くしても、縮むのは1件の待ち時間だけです。件数ぶん繰り返される起動の操作は、速さとは別の場所に残ります。実行を予定に組み込めるかどうかを先に見ておくと、速さの改善に時間を使うべきかどうかも決まります。

件数の多い仕事で効いてくるのは、判断を任せることよりも、始める操作を人から外せるかどうかのほうです。

理由②途中で止まったときに、どこまで進んだかが残らないから

2つ目は、会話の履歴が処理の記録としては読めないことです。どこまで終わったか、どの件が失敗したかを後から並べて確かめる形になっておらず、件数が増えるほど、この差が効いてきます。

たとえば、この会社が数百件を会話で処理したとします。途中で結果が返らない件があっても、どの件だったかを探すには履歴を1つずつ開くことになり、確かめる作業が処理そのものより重くなってしまいます。

途中で止まること自体は、どの形で処理しても起こります。分かれるのは、止まった位置が一覧で残るか、探しに行かないと分からないかのほうです。一覧で残る形なら、止まった行だけをもう一度実行する選び方もできます。処理を任せる前に、止まったときに何が残るかを見ておくと、規模を広げてよいかの判断がつきます。

理由③同じ指示を出しても、結果を並べて比べられないから

3つ目は、結果が1件ずつ別の場所に返るため、全体の傾向を確かめられないことです。分類の精度を上げるには外れた件を並べて共通点を探す作業が要りますが、会話の形では、その並べる作業が手作業になります。

先ほどの会社の担当者も、10件を試した段階では結果を目で追えました。ところが数百件になると、どの分類が多いのか、どの条件で外れているのかを集計する作業が別に発生します。集計のために結果を書き写す手間が、処理を広げる妨げになりました。

Agentforce Gridは、この3つをまとめて外す形になっており、行にレコードを並べ、列に処理を置くことで、始める操作は1回で済み、結果は表の形で並び、どの行が外れたかもその場で見えます。公開されている情報では、各行は独立して並列に処理されると案内されており、行数が増えても処理の仕組みそのものは変わりません。（2026年9月時点の情報にもとづく）※参考記事はこちら

Agentforce Gridが持つ4種類の列

前章では、会話の形が件数に耐えない理由を3つ挙げました。ここからは、画面の操作は扱わず、判断に必要な範囲で、Gridがその処理をどう組み立てるのかを見ていきます。そこでここでは、Agentforce Gridが持つ4種類の列を解説します。

列①Salesforceから取り込む列

最初の列は、処理の対象になるレコードを行として並べる列です。オブジェクトと項目を選ぶ形のほか、条件を書いて絞り込む形も用意されており、ここで並んだ行が、そのまま処理の母数になります。

このビル設備の会社では、問い合わせのレコードのうち直近1年ぶんを取り込む形にしました。3年ぶん12,000件をすべて並べることもできましたが、まず4,200件に絞っています。母数を決める作業がこの列に集約されているため、後から範囲を変えるのも同じ場所で済みます。

この列で決まるのは件数だけではありません。どの項目を持ち込むかによって次の列が読める情報の範囲も決まるため、後の列で情報が足りないと気づいたときは、この列まで戻ることになります。取り込む条件は処理の精度を左右するので、どの仕事をまとめて処理してよいかを見分ける条件のところで、改めて扱います。

列②プロンプトを1行ずつ実行する列

2つ目は、並んだ行それぞれに同じ指示を当てる列です。あらかじめ作ったプロンプトテンプレートを使う形と、その場で指示を書く形があり、1行ずつ処理されるため、行が増えても指示は1つで足ります。

先ほどの会社は、問い合わせの本文を読んで内容の種類を返す指示を1つ用意しました。用意した指示は1つで、4,200行に当たります。1件ずつ投げていた時期と比べると、担当者が行う操作は実行のボタンを押す1回だけになりました。

指示を1つに保てると、書き直しの手間も1回で済みます。返ってくる内容を変えたいときに直す場所が1か所しかないため、どの行で試した結果も、そのまま全体の変更につながっていくというわけです。同じ指示が全行に当たる性質は、そのまま制約にもなり、行ごとに違う判断が要る仕事はこの形に向きません。

列③前の列の結果を加工する列

3つ目は、前の列が返した内容を整える列です。表記をそろえる、余分な記号を落とす、決められた選択肢に寄せる、といった処理がここに入ります。公開されているTrailheadの教材でも、生成した文章の記法を変換する例が示されています。

この会社では、種類を返す指示の結果に「設備の不具合」「点検の依頼」といった表現の揺れが残りました。そこで加工の列を1つ足し、あらかじめ決めた6つの区分のどれかに寄せる形にしています。列を分けたことで、揺れが出たときにどちらの列を直せばよいかが分かるようになりました。

前の列が返した値を次の列が受け取る形は、教材の手順の中でも、前の列の名前を指定して参照するやり方として示されています。（2026年9月時点の情報にもとづく）※参考記事はこちら

列④結果をレコードへ書き戻す列

最後は、できあがった結果をSalesforceのレコードへ反映する列です。対象のオブジェクトと項目を選び、どの列の値を書き込むかを指定します。ここが実行されると、表の中だけの作業が業務のデータになります。

このビル設備の会社は、最初の2週間は書き戻しの列を置きませんでした。表の中で結果を確かめ、区分の付き方に納得できてから最後に足しています。書き戻しを後回しにしたことで、区分を作り直しても業務のデータには影響が出ませんでした。書き戻しを足す時期は、返ってくる区分の名前が変わらなくなった時点を目安にします。

以上が、Agentforce Gridが持つ4種類の列でした。取り込み・実行・加工・書き戻しのうち、判断が要るのは最初と最後の2つです。

まとめて処理してよい仕事を見分ける4つの条件

前章で列の役割を4つに分けて見てきましたが、すべての仕事がこの形に乗るわけではありません。ツール設定ではなく業務設計から入ってほしい場合に最初に取り組むのが、この見極めです。そこでここでは、まとめて処理してよい仕事を見分ける4つの条件を解説します。

条件①1件ごとの判断が同じ形で繰り返されるか

1つ目の条件は「1件ごとの判断が同じ形で繰り返されるか」です。全行に同じ指示が当たる以上、行ごとに違う観点で見る仕事は形に合わず、判断の手順を1文で書けるかどうかが、そのまま目安になります。

この会社の分類は「問い合わせの本文を読み、6つの区分のどれに当たるかを返す」と1文で書けました。一方で、同じ記録から保守契約の見直し案を作る作業は、契約の内容と過去の対応履歴を読み合わせる必要があり、1文には収まりません。前者はGridで回し、後者は担当者が続けています。

1文で書けるかどうかを試すときは、書いた文に「ただし」を足したくなるかを見ておくと分かりやすくなります。例外を足さないと成立しない手順は、行ごとに違う判断が混ざっている証拠だからです。判断が1文で書けない仕事は、まとめて処理する対象から外します。

条件②入力が1つのレコードの中で完結するか

2つ目は、答えを出すために見る情報が、その行のレコードの中にそろっているかどうかです。他のレコードを参照しないと判断できない仕事は、行ごとに取りに行く処理が必要になり、形が複雑になります。

先ほどの会社の分類は、問い合わせの本文と件名だけで判断できました。対して、同じ顧客の過去3年の対応履歴をすべて読んでから判断する形にしていたら、1行の中に必要な情報が収まらず、取り込みの設計から作り直しになっていたはずです。

参照する先が増えるほど、確かめる場所も増えます。返ってきた内容が違っていたときに、指示の書き方の問題なのか、参照した情報が足りなかったのかを切り分けられなくなるためです。入力が1行に収まるかどうかは、取り込む列の設計で先に確かめられます。

条件③外れた行を後から選び直せるか

3つ目は、処理の結果が外れた行を、後から特定して選び直せるかどうかです。全行が正しく処理される前提の仕事はまとめて回すには向かないため、外れる前提で、選び直せる形を残しておきます。

この会社では、200件を試した段階で人の判断と一致した行が176件、一致しなかった行が24件ありました。24件は表の上で選び出せたため、共通点を探す作業がその場で終わっています。もし結果が別々の場所に返っていたら、24件を探すところから始めることになりました。

選び直せる形かどうかは、外れた行に何らかの印が残るかで見分けられます。印が残らない設計では、次に実行したときに同じ行がまた外れても、前回と同じ行なのかどうかが分かりません。

まとめて処理してよい仕事かどうかは、うまくいく割合よりも、外れた行をその場で選び直せるかどうかで決まります。

条件④結果を人が読める形で残せるか

4つ目は、処理の結果が人の目で確かめられる形になるかどうかです。数値や区分のように短く書けるものは並べて確かめられますが、長い文章を全行ぶん読み返す形は現実的ではありません。

このビル設備の会社が返させたのは6つの区分のどれかという短い値でした。そのため200行を並べて目視で確かめる作業が1時間ほどで終わっています。仮に1件ごとに数百字の要約を返させていたら、確かめる作業に分類と同じだけの時間がかかっていました。

返させる形を短くするほど、確かめられる行数は増えます。逆に、長い文章を返させる設計にするなら、全行を確かめるのはあきらめて、抜き取りで見る前提に切り替えておく必要があります。

以上が、まとめて処理してよい仕事を見分ける4つの条件でした。4つを満たさない仕事は、人が続けるか、形を変えてから当て直します。

エージェントかGridか、どちらで回す？3つの線引き

前章では、まとめて処理してよい仕事の条件を4つ挙げました。ここで迷いやすいのが、同じ処理をエージェントに任せる形との違いです。どちらでもできる仕事があるため、線を先に引いておきます。そこでここでは、エージェントに任せる仕事と、Gridで回す仕事の3つの線引きを解説します。

線引き①相手からの依頼で始まるならエージェント

1つ目は「相手からの依頼で始まるならエージェント」です。顧客や社内の担当者が話しかけた時点で処理が始まる仕事は待ち受ける形が要り、いつ来るか分からない依頼を、こちらの都合でまとめることはできません。

このビル設備の会社では、代理店から届く設備の型番の照会をエージェントが受けています。届いたその場で返すことに意味がある仕事で、まとめて処理する対象にはなりません。一方で、届いた後の記録を分類する仕事は、いつ実行してもかまいません。

同じ業務でも、依頼を受ける部分と受けた後の部分では、置く場所が変わります。届いた瞬間に返す部分だけをエージェントに残し、後から見返す部分をまとめて回すという分け方も成り立つためです。始まりが相手の側にあるか、こちらの側にあるかで、置く場所が分かれます。

線引き②こちらの都合で始められるならGrid

2つ目は、実行の時期を自分で決められる仕事です。締め切りが月末でも来週でもよい仕事は、1行ずつ人が投げる必要が無いぶん、まとめて1回で回したほうが手間が少なくなります。

先ほどの会社の分類は、半年止まっていたことからも分かるとおり、いつ実行してもよい仕事でした。担当者が月末に1回まとめて回す形にしたところ、毎月350件前後を扱う運用に落ち着いています。実行の時期を選べる仕事だったからこそ、担当者の都合に合わせられました。

時期を選べるということは、混み合う時期を外せるということでもあります。月初の請求や月末の締めと重ならない週に寄せておけば、結果を確かめる時間まで含めて予定に入れられます。

エージェントとGridの線は、処理の難しさではなく、実行の時期を誰が決めるかで引きます。

線引き③1件の中で会話が往復するならエージェント

3つ目は、1件を処理する途中で相手に聞き返す必要があるかどうかです。足りない情報を尋ねて、返ってきた内容で処理を続ける形は、表の列では組めません。列は前から後ろへ1回流れる形になっているためです。

この会社でも、問い合わせの内容が短すぎて分類できない行がありました。人であれば「どの設備の話ですか」と聞き返せますが、Gridの中ではその往復ができません。そのため、聞き返しが要る行は分類の対象から外し、担当者が処理を続ける形にしています。

聞き返しが要るかどうかを決めるのは、記録の書かれ方です。どの行にも同じ項目がそろっているなら往復は起こりませんが、書き方が人によって違う記録では、一定の割合で足りない行が出てきます。

エージェント側の作り方は1体目を作る手順で解説していますので、あわせて参考にしてもらえると嬉しいです。

回す前に何を？Agentforce Gridの決めごと4つ

前章までで、Gridに置く仕事は選べるようになったので、次に決めるのは実行する前に固めておく条件です。ここを決めずに実行すると、結果を見てから慌てて止めることになります。そこでここでは、Gridで回す前に決めておく4つのことを解説します。

決めごと①対象にする行の条件

最初に決めるのは、どのレコードを行として取り込むかです。全件を対象にすると処理に向かない行まで混ざり、外れた行の分析が難しくなるため、条件を書いて絞り込んだ状態から始めます。

このビル設備の会社は、直近1年ぶんの4,200件を最初の対象にしました。その後、記録が1行しかない行を対象から外す条件を足し、600件を除いて3,600件に絞っています。絞ったことで、人の判断と一致する割合は88%から92%へ変わりました。

条件は、後から足していける形で書いておきます。最初から完成した条件を書こうとすると、どの行が外れるのかを想像で決めることになり、実際の結果を見て直す余地が残らないためです。対象を絞る作業は、精度を上げる作業でもあります。

決めごと②書き戻す項目と、書き戻さない項目

次に決めるのは、結果をどこへ書き込むかです。既存の項目を上書きする形にすると元の値が消えるため、新しい項目を用意するのか、上書きしてよいのかを先に決めておきます。

先ほどの会社は、分類の結果を既存の項目には書かず、新しく作った項目へ書き込む形にしました。既存の項目には担当者が手で入れた内容が残っており、上書きすると過去の入力が失われるためです。分けたことで、機械が付けた区分と人が入れた内容を並べて比べられるようにもなりました。

書き込まない項目を先に決めておくのも、同じくらい効いてきます。触ってはいけない項目が一覧になっていれば、後から列を足すときに確認する範囲が狭くなるからです。書き戻す先は、上書きしてよいかどうかで選びます。大量の記録を書き換える作業を誰が持つかは、設定を誰が持つかの線引きとして別に整理しています。

決めごと③外れた行をどう扱うか

3つ目は、処理が外れた行や、結果が返らなかった行をどう扱うかです。放置すると次に実行したときに同じ行がまた外れるため、人が処理するのか、条件を変えて再度回すのかを決めておきます。

この会社では、外れた行に印を付けて担当者の確認待ちへ回す形にしました。最初の月は24件、条件を足した後は月に10件前後で推移しています。担当者が確認する件数が読めるようになったことで、確認の時間を業務の予定に入れられるようになりました。

決めておく内容は、扱いだけではありません。どこまで増えたら条件を見直すのかという線も一緒に決めておくと、担当者が自分の判断で手を打てます。外れた行の扱いを決めておくと、実行の後に人がやることが決まります。

決めごと④誰がいつ実行するか

最後は実行の担当と時期で、1回で終わる仕事なら誰が押しても同じですが、繰り返す仕事は担当を決めないと止まります。実行の後に確認まで行うため、確認まで含めた担当にします。

このビル設備の会社は、情報システムの3名のうち1名を実行の担当に決め、毎月の月初に回す形にしました。実行そのものは数十分で終わり、外れた行の確認に1時間ほどかかっています。担当と時期を先に決めていたため、運用に入ってから止まった月はありません。

担当を1名に固定するなら、代わりに回せる人も同時に決めておきます。休みや異動で1回飛ぶと、翌月の対象が2か月ぶんに増え、確認の時間も2倍になるためです。

以上が、Gridで回す前に決めておく4つのことでした。いずれも実行の前に決めておけば、後から直す作業になりません。

1つの業務から試す4つのステップ

前章では、実行前に固める条件を4つ挙げました。ここからは、実際に着手するときの順番を見ていきますが、小さく始めたい場合は、最初から全件を対象にせず、数十行で試すところから入ります。そこでここでは、1つの業務から試す4つのステップを解説します。

ステップ①件数の多い記録を1種類選ぶ

最初に選ぶのは、いちばん件数のたまっている記録です。件数が多いほど外れ方の傾向が短期間で見えてきますが、めったに発生しない記録から始めると、手を打つ材料がそろうまでに時間がかかります。

このビル設備の会社は、3年で12,000件たまっていた問い合わせの記録を選びました。ほかにも点検の報告書や見積の記録がありましたが、件数の多さと、分類した結果を使う予定が決まっていたことから、問い合わせを最初の対象にしています。

1種類に絞るのは、外れた原因を切り分けるためでもあります。複数の記録を同時に扱うと、指示が合わないのか、記録の書かれ方が違うのかを分けて考えられません。1種類で手順が固まってから次の記録へ広げれば、確かめる範囲も狭いままで済みます。最初の1種類は、件数と使い道の2つで選びます。

ステップ②数十行で試して、外れ方を数える

次に、対象を数十行から数百行に絞って実行し、結果を人の判断と突き合わせます。ここで見るのは全体の割合ではなく、外れた行に何が共通しているかです。

先ほどの会社がまず200件で試したところ、人の判断と一致したのは176件で、一致しなかった24件を読み直すと、15件は記録が1行しか書かれていない行でした。割合だけを見ていれば88%という数字で終わりますが、外れた行を読んだことで、次に打つ手が決まっています。

読むときは、外れた行を原因ごとに分けて数えておきます。同じ原因が固まっているなら条件で外せますが、原因がばらけているなら、返させる形のほうを見直すことになるためです。試す段階で見るべきなのは、うまくいった行よりも外れた行のほうです。

ステップ③対象の条件を狭める

3つ目は、外れ方の共通点をもとに、取り込む条件を狭めることです。指示を書き足して精度を上げようとするより、対象から外すほうが早く効きます。

この会社は、記録が短すぎる行を対象から外す条件を足しました。4,200件のうち600件が対象から外れ、残る3,600件での一致は92%になっています。指示の文面は1文字も変えておらず、変えたのは、どの行を入れるかという条件だけでした。

条件を狭めるときは、一度に1つだけ足します。2つ同時に足すと、割合が動いた理由がどちらの条件にあるのかを確かめられなくなるからです。足した条件と、そのときの割合を並べて記録しておくと、条件を戻す判断も数字で説明できるようになります。精度が上がらないときは、指示より先に対象を疑います。

ステップ④書き戻しを最後に足す

最後に、結果をレコードへ反映する列を足しますが、ここまでの3つが表の中だけで完結しているのに対し、この列だけが業務のデータを変えます。順番を最後にしておけば、途中で作り直しても影響が出ません。

このビル設備の会社は、実行と確認を2週間繰り返してから書き戻しの列を足しました。組み始めてから運用に入るまでにかかったのは、この2週間だけです。当初の目的は「たまった問い合わせの記録を分類して、多い順に手を打てる状態にすること」でしたが、140時間と見積もっていた作業は、毎月350件前後を回す運用に置き換わりました。

書き戻しを最後に置けば、途中で何度作り直しても業務のデータは変わりません。以上が、1つの業務から試す4つのステップでした。

一括処理でつまずく3つの落とし穴

前章では1つの業務から試す順番を追いましたが、ここからは、その途中で実際に起きやすい失敗のほうを見ていきますが、いずれも操作を誤ったからではなく、進め方の順番から生まれるものです。そこでここでは、一括処理でつまずく3つの落とし穴を解説します。

落とし穴①全件を対象にしたまま実行する

1つ目は「全件を対象にしたまま実行する」ことです。取り込む列は条件を書かなければ対象を広く取るため、試すつもりで数千件を処理してしまい、結果の確認が終わらないうちに、消費だけが積み上がります。

このビル設備の会社でも、最初に3年ぶんの12,000件を並べようとした場面がありました。担当者が実行の前に直近1年ぶんへ絞り直したため実際には回していませんが、そのまま押していれば、確認できない量の結果が一度に返っていたはずです。

防ぎ方は単純で、実行のボタンを押す前に、いま何行が並んでいるかを声に出して確かめるだけで足ります。表に並んだ行数は実行前から見えているため、押した後に気づく理由がないからです。試す段階の対象は数百行までに抑え、確認しきれる量かどうかを実行前に見積もっておきます。

落とし穴②書き戻しを最初から入れてしまう

2つ目は、表の中で結果を確かめる前に、レコードへ反映する列を組み込んでしまうことです。結果が想定と違っていた場合、業務のデータを元へ戻す作業が発生します。

先ほどの会社は、書き戻しの列を2週間後まで足しませんでした。この2週間のあいだに区分の数を8つから6つへ変えており、書き戻しを先に入れていれば、そのたびにレコードを直す作業が発生していました。表の中だけで作り直せたことが、短い期間で運用に入れた理由になっています。

急ぎたくなるのは、書き戻すまでは成果が目に見えないからです。それでも、区分の数や名前が固まっていない段階の結果は、業務のデータとして残す価値がまだありません。書き戻しは、結果に納得できてから最後に足します。

落とし穴③外れた行を見ずに割合だけを見る

3つ目は、一致した割合だけを見て、外れた行を読まないことです。割合は上がったか下がったかしか教えてくれず、何を直せばよいかは、外れた行の中にしかありません。

この会社の場合、88%という割合だけを見ていれば「まずまず動いている」で終わっていました。実際には外れた24件のうち15件が同じ原因で、対象から外すだけで92%になっています。読んだのは24件で、時間にして30分ほどの作業でした。

読んだ内容は、原因ごとに一行ずつ書き残しておきます。外れた行を読む時間は、対象を絞っている限り増え続けません。母数が減れば外れる行も減るため、読む作業は最初の数回がいちばん重く、そこから軽くなっていきます。割合は結果の要約であって、直す手がかりではないと考えます。

一括処理が機能しているかをフェーズごとに測る

前章で挙げた3つの失敗を早い段階で見つけるには、時期に応じて見る数字を入れ替えておく必要があります。1つの指標を最後まで追い続けると、いま手を入れるべき場所が読み取れなくなるからです。そこでここでは、一括処理が機能しているかをフェーズごとに測る方法を解説します。

段階①試す時期｜人の判断と一致した行の割合

試す時期に見るのは、機械が付けた結果と人の判断が一致した行の割合で、件数が少ないうちは実数で追っても変化が読み取れません。分母は試した行数、分子は担当者が「これで正しい」と判断した行数になります。

このビル設備の会社では、200件を試した時点が88%、対象を3,600件へ絞った後が92%でした。判断は担当者が1行ずつ目で確かめており、200行の確認に1時間ほどかかっています。

判断する担当者は、期間中は同じ人にそろえておきます。人が入れ替わると、正しいと判断する基準まで一緒に動いてしまい、割合の変化が処理の変化なのか判断の変化なのかを切り分けられなくなるためです。試す時期に100%を目指すと、対象を狭めすぎて処理できる行が減ります。一致した割合の伸びが小さくなったら、割合を追いかけるのはそこまでにして、次の段階へ移ります。

段階②広げる時期｜対象から外れた行の件数

対象を広げていく時期に見るのは、条件によって処理から外れた行の件数です。この時期は割合よりも、外した行の中に処理すべきものが混ざっていないかを確かめることが目的になります。

先ほどの会社では、記録が短すぎる行として600件を対象から外しました。担当者がこの600件を抜き取りで読んだところ、大半は「至急連絡ください」のような一行の記録で、外した判断が妥当だったことを確かめられています。

抜き取りで読む件数は、毎回そろえておくと比べやすくなります。前の月と同じ件数を読んでいれば、混ざり方が増えたのか減ったのかを件数のまま比べられるからです。外した行を確かめない限り、処理できる行まで捨てていないかどうかは分かりません。

段階③続ける時期｜書き戻した後に人が直した件数

運用が続く時期に見るのは、レコードへ書き戻した後に、担当者が手で直した件数です。この件数は、機械が付けた結果が実務で通用しているかを直接あらわします。

この会社では、運用に入って以降、外れた行として確認へ回るのが月に10件前後で推移しています。書き戻した後に直された件数はそれより少なく、区分そのものは実務で使える水準に収まりました。当初の目的は「たまった問い合わせの記録を分類して、多い順に手を打てる状態にすること」でしたが、毎月350件前後を回す形になったことで、目的の状態に届いています。直した件数が増え始めたら、区分の決め方か対象の条件のどちらかが実務とずれた合図です。

一括処理が機能しているかは、処理した件数ではなく、書き戻した後に人が直した件数で確かめます。

いつ人が見る？一括処理の結果を確かめる3場面

前章では時期ごとに見る数字を分けましたが、数字がそろっていても、人が目で読んだほうがよい場面は残ります。機械が測れるのは結果の形までで、その結果を業務へ出してよいかどうかは、内容を知っている担当者にしか決められないからです。そこでここでは、人が結果を確かめるべき3つの場面を解説します。

場面①顧客へ出る文面を作ったとき

最初の場面は、処理の結果が顧客の目に触れる文面になる場合です。社内で使う区分と違い、文面は一度出ると取り消せないうえ、件数が多いほど確認を省きたくなる圧力もかかります。

このビル設備の会社は、分類の次の段階として、顧客へ送る案内文を行ごとに作る計画を持っていました。ただし現時点では作るところまでにとどめ、送信は担当者が1件ずつ確かめてから行う形にしています。件数が増えたときにどう確かめるかは、まだ決めていません。

文面を扱うなら、作る列と送る操作を分けておくと確認の場所が決まります。同じ列の中で送信まで済ませる設計にすると、確かめる時間を挟む場所が無くなってしまうためです。出る先が社外であるほど、確認の形を先に決めておきます。

場面②レコードを上書きする処理を含むとき

2つ目は、書き戻しの列が既存の項目を上書きする場合です。新しい項目へ書き込むなら元の値が残りますが、上書きは戻せないため、上書きする設計にした時点で実行前の確認が必須になります。

先ほどの会社は、新しい項目へ書き込む形にしたため、この確認を省けています。仮に既存の項目を上書きしていたら、3,600件ぶんの元の値を先に控えておく作業が必要でした。設計の段階で上書きを避けたことが確認の手間を減らしており、取り消せるかどうかで確認の重さが変わります。

上書きを避けられない項目があるなら、その項目だけ対象の件数を落とします。戻す作業が発生したときに手で直しきれる件数まで下げておけば、確認の負担が読めるようになるからです。一任と承認の線引きについては、人が承認する場面の考え方のほうで別に扱っています。

場面③取り込む条件を変えた直後

3つ目は、対象を絞る条件を変えた直後です。条件を変えると母数が変わるため、それまでの割合と直接は比べられず、変えた直後の1回は結果を並べて確かめます。

この会社では、記録が短すぎる行を外す条件を足した週に、担当者が結果を抜き取りで確認しました。母数が4,200件から3,600件へ変わっており、割合が88%から92%へ上がったのが条件のおかげなのか、母数が変わったためなのかを切り分ける必要があったためです。

条件を変えた日付は、割合の記録と並べて残しておきます。数か月たってから割合の動きを見返したときに、どの週で前提が変わったのかを思い出せる形にしておくためです。条件を変えた回だけは、割合の比較を1回休みます。

Gridを先に試すべき企業の3つの条件

ここまで進め方と確かめ方を見てきたものの、どの会社にも同じ優先度で必要なわけではありません。件数と使い道がそろっている会社ほど、早く効果が出ます。そこでここでは、Gridを先に試すべき企業の3つの条件を解説します。

条件①同じ形の記録が数千件たまっている

1つ目の条件は「同じ形の記録が数千件たまっている」です。件数が少なければ人が処理したほうが早く、形がそろっていなければ同じ指示が当たらないため、この2つがそろって、はじめてまとめて回す意味が出ます。

このビル設備の会社の問い合わせの記録は、3年で12,000件たまり、項目の構成も3年間変わっていませんでした。同じ形で並んでいたからこそ、1つの指示を全行に当てられています。途中で入力の様式を変えていたら、時期ごとに別の指示が必要になっていました。

形がそろっているかは、古い記録と新しい記録を並べて読めば分かります。同じ項目に入っている内容の粒度が変わっていれば、様式が途中で変わった合図だからです。件数と形のそろい方は、着手する前に確かめられます。

条件②その記録を使う予定が決まっている

2つ目は、処理した結果を何に使うかが決まっているかどうかです。分類しただけで終わる作業は費用と時間をかけた分の説明がつきませんが、使い道が先に決まっていると、返させる形も決まります。

先ほどの会社は、分類の結果を保守契約の見直しに使う計画を持っていました。使い道が決まっていたため、返させるのは6つの区分でよいという判断ができています。使い道が決まっていなければ、要約を返させるか区分を返させるかで迷い、設計が長引いていたはずです。

使い道は、誰がその結果を見るかまで決めておくと具体になります。見る人が決まれば、必要な粒度も自然に決まり、返させる形を選ぶ場面で迷わなくなるためです。使い道が決まっていない記録は、まだ処理する時期ではありません。

条件③実行を任せられる担当を置ける

3つ目は、実行と確認を続けられる担当を置けるかどうかです。1回で終わる仕事なら誰でも回せますが、繰り返す仕事は担当が決まっていないと止まります。

この会社は情報システムが3名おり、そのうち1名を実行の担当に決められました。仮に1名の体制であれば、実行そのものは数十分で終わるとしても、外れた行の確認まで含めた時間を確保できたかどうかは分かりません。

置ける担当がいないうちは、対象の件数を落として始める形も選べます。確認に使える時間から逆算して対象を決めれば、担当が1名でも続けられる規模に収まるからです。担当を置けるかどうかは、着手の可否より先に確かめておきます。

先に試すべきかどうかは、記録の件数ではなく、実行と確認を続けられる担当を置けるかで決まります。

Gridを急がなくてよい企業の3つの条件

前章では先に試したほうがよい条件を3つ挙げましたが、いま着手しないほうが合理的な会社もあり、試す作業にも設計と確認の手間がかかるので、急ぐ理由がなければ、他の工程に時間を回したほうが早く進みます。そこでここでは、Gridを急がなくてよい企業の3つの条件を解説します。

条件①対象になる記録が数十件しかない

1つ目の条件は、処理したい記録が数十件にとどまる場合です。人が処理しても半日で終わる件数であれば、設計と確認の時間のほうが大きくなります。

たとえば、月に30件ほどの問い合わせしか受けていない会社であれば、1件2分で処理しても1時間で終わります。この規模では、対象の条件を決めて結果を確かめる時間のほうが、処理そのものにかかる時間を上回ります。4,200件で140時間かかるビル設備の会社と、同じ判断にはなりません。

先に数えるのは、たまっている総数よりも、月ごとに増える件数のほうです。総数は一度片づければ減りますが、毎月増える件数が少ないなら、仕組みを作っても回す機会がほとんど来ないためです。件数を先に数えておけば、まとめて回す対象かどうかの判断は迷いません。

条件②1件ずつの判断が毎回違う

2つ目は、記録ごとに見る観点が変わる仕事です。同じ指示が全行に当たる形に乗らないため、行ごとに例外を足していくことになり、かえって手間が増えます。

先ほどの会社でも、保守契約の見直し案を作る作業はこちらに当たりました。契約の内容・過去の対応履歴・設備の年数を読み合わせる必要があり、判断を1文で書けません。この作業は担当者が続けており、Gridには乗せていません。

観点が変わる仕事でも、前段だけを切り出せる場合はあります。読み合わせる前に必要な情報を1か所へ集める作業だけなら、行ごとに同じ手順で済むからです。判断が1文で書けるかどうかは、まとめて処理してよい仕事を見分ける条件①でそのまま確かめられます。

条件③書き戻す先の項目が決まっていない

3つ目は、結果をどこへ書き込むかが決まっていない場合です。書き戻す先が決まらないうちに処理を回すと、表の中に結果が残るだけで業務は変わりません。

この会社は、分類の結果を書き込む項目を新しく作ってから運用に入りました。項目を作る判断が先にあったからこそ、書き戻しの列を最後に足すだけで運用へ移れています。項目の設計が決まらない段階では、処理を回しても置き場所がありません。

項目を作る判断には、名前と選択肢を決める作業が含まれます。分類の区分がまだ動くうちに項目を作ると、選択肢の作り直しが業務のデータにも及びます。

急がない判断は、後回しにしたのではなく順番を選んだ結果です。件数が増えるか使い道が決まった時点で始めれば間に合います。

一括処理にかかる費用の3つの内訳

前章までで着手するかどうかの判断はそろい、残るのは費用の見立てです。1件ずつ処理する形と違い、まとめて回す形は件数がそのまま消費に効いてきます。そこでここでは、一括処理にかかる費用の3つの内訳を解説します。

内訳①実行のたびに発生する分は件数に比例する

1つ目は処理を実行するたびに消費される分で、Agentforceの課金には、アクション1回ごとに消費されるFlex Creditsがあります。目安として、Flex Creditsは10万クレジットあたり500ドルで、標準的なアクションは1回あたり20クレジット、金額にして0.10ドルを消費します。（2026年9月時点の目安）※参考記事はこちら

まとめて回す形ではこの消費が行数ぶん発生するため、このビル設備の会社が毎月350件前後を処理する運用であれば、消費の規模は事前に計算できます。行数が読めている限り、費用も読めるというわけです。

料金の考え方そのものは料金の考え方で解説していますので、あわせて参考にしてください。

内訳②試す段階でも同じだけ消費する

2つ目は試す段階の消費で、本番の処理と検証の処理で単価が変わるわけではないため、試した行数もそのまま消費に乗ります。試す回数を重ねるほど、着手前の費用が積み上がります。

先ほどの会社は200件を3回試しており、行数にすると600行ぶんの処理を、運用に入る前に消費しています。もし最初から4,200件で試していれば、同じ3回で12,600行ぶんの消費になっていました。試す規模を絞ったことが、そのまま費用を抑える形になっています。

試す規模を決めるときは、外れ方の傾向が見える最小の行数を探します。行数を増やしても同じ原因しか出てこないなら、それ以上は同じ内容を確かめるために消費していることになるからです。試す段階の消費は、設計の費用として最初から見込んでおきます。

内訳③対象を狭める作業は費用を下げる作業でもある

3つ目は対象を絞る作業が費用に直接効くことで、処理しない行を決めることは、消費しない行を決めることでもあります。精度を上げる作業と費用を下げる作業が、同じ1つの作業になっているのがこの形の特徴です。

この会社が記録の短い行を外したとき、対象は4,200件から3,600件へ減りました。処理する行が600件減ったぶん、実行のたびの消費もその割合で下がっています。同時に、人の判断と一致する割合は88%から92%へ上がりました。絞る判断を1回入れるだけで、精度と費用の両方が同じ向きへ動きました。

逆に、対象を広げて精度を上げようとすると、消費だけが先に増えることになります。

対象を絞る作業は、精度を上げる作業と費用を下げる作業を同時に進めることになります。

【2026年9月時点】Gridを検討する4つの注意

前章で費用の内訳を3つに分けたところで、もう一点、提供が始まったばかりのAgentforce Gridには、条件も名称も動きやすい固有の事情があり、自社で構築するので設計レビュー・アドバイザリーだけ頼みたい場合も、この見立てが最初の相談事項になります。そこでここでは、提供が始まったばかりの機能を検討するときの4つの注意を解説します。

注意①提供状況と条件を、確かめた時点つきで残す

1つ目は、いつの時点で何を確かめたかを記録に残すことです。提供状況が動く機能では半年前の調査結果がそのまま使えるとは限らず、時点を書いておけば、いつ確かめ直すべきかも決まります。

Agentforce Gridは、公開されているブログで、まずは担当のAEへ連絡する形で案内されています。（2026年9月時点の情報にもとづく）※参考記事はこちら

このビル設備の会社の担当者も、確かめた日付と情報源を1枚にまとめてから稟議へ出しました。時点を添えたことで、決裁の場で「その情報はいつのものか」という問いに答えられています。

残すのは、確かめた事実と確かめられなかった事実の両方です。分からなかった項目が空欄のまま残っていれば、次に調べ直す担当がどこから手を付ければよいかを迷わずに済みます。

注意②画面の名前より、やっていることで記録する

2つ目は、社内の資料に画面の名称をそのまま書かず、何をする面なのかで書くことです。提供の初期は名称が変わることがあり、名前で書いた資料は数か月で読めなくなります。何をする面なのかで書いておけば、名称が変わっても資料は生き残ります。

先ほどの会社の資料には「レコードを行に並べて、AIの処理を列として一括で回す面」と書かれています。画面の名前は括弧の中に添えるだけにしたため、名称が変わった場合でも本文を書き直す必要がありません。

同じ書き方は、稟議や社内の説明にも効いてきます。名称を知らない相手にも何をする仕組みかが伝わるので、機能の説明から始めなくて済むためです。やっていることで書く形は、社内の引き継ぎにも役立ちます。

注意③本番の組織でいきなり試さない

3つ目は、検証の環境で試してから本番へ移すことです。書き戻しの列を含む処理は業務のデータを変えるため、試す段階から本番で回すと、想定と違った結果を1件ずつ元へ戻す作業が発生します。戻す作業は件数に比例するので、行数が多いほど負担も大きくなります。

この会社は、検証の環境で2週間試してから本番へ移しました。区分の数を8つから6つへ変えたのもこの期間で、本番のレコードには一度も書き込んでいません。

検証の環境を用意する手間は、書き戻しの列を足す前に済ませておくと軽くなります。列が少ないうちであれば、同じ組み立てを本番でもう一度作るのに時間はかかりません。まとめて検証する方法そのものは、まとめて検証する仕組みのほうで別に扱っています。

注意④止まったときに人手へ戻せる形にしておく

4つ目は、機能が使えなくなった場合に業務が止まらない形にしておくことです。提供の条件が変わる、名称が変わる、有効化の方法が変わるといった動きは、初期ほど起こりやすくなります。

このビル設備の会社は、処理を止めた場合に担当者が手で分類する手順を1枚残しています。月に350件前後であれば、14名のカスタマーサポートで分担すれば処理できる件数です。戻せる形を残しておいたことで、提供の条件が変わっても業務が止まらない見通しが立ちました。

戻す手順は、書いて終わりにせず、実際に1回動かして時間を測っておきます。手順が書いてあるだけでは、止まった月に本当に回せるかどうかが分からないためです。

以上が、提供が始まったばかりの機能を検討するときの4つの注意でした。新しい機能ほど、使い方より戻し方を先に決めておきます。

一括処理の設計に外部支援を使う4つの判断軸

ここまでで、自社だけで進める場合の判断材料はひととおりそろいました。ただし対象の絞り込みから外れた行の扱いまでを社内の担当者だけで詰めるには時間がかかるので、外部へ頼む場合に何を見ればよいかを最後に足しておきます。そこでここでは、一括処理の設計に外部支援を使う4つの判断軸を解説します。

判断軸①対象の絞り込みから一緒にやるか

1つ目は、どの行を対象にするかを決める工程から一緒に入るかどうかで、この工程は地味な作業ですが、精度も費用もここでほぼ決まります。画面の設定から入る支援では、社内の担当者が決めた対象を動かさないまま作業が進みます。

このビル設備の会社では、対象を4,200件から3,600件へ絞る判断に、外れた24件を読む作業が必要でした。記録の中身を1件ずつ読む作業なので、業務の内容を知っている人が同席しないと前に進みません。

提案書を読むときは、対象を決める工程に何日置かれているかを見ます。設定と検証の日数しか書かれていない提案は、対象が決まっている前提で組まれているからです。対象を誰が決めるのかがあいまいなまま始まると、精度が上がらなかったときの責任の所在も分からなくなります。

判断軸②任せてよい仕事の基準を先に示すか

2つ目は、どの仕事をまとめて回してよいかの基準が、作業に入る前に示されるかどうかです。基準の説明がないまま設定だけが出てくると、次の業務へ広げるときに自社で判断できません。

先ほどの会社では、判断が1文で書けるか・入力が1行に収まるか・外れた行を選び直せるか・結果を人が読める形かという4つを先に共有したうえで対象を決めました。基準が言葉になっているため、点検の報告書へ広げるかどうかを担当者だけで判断できています。

基準が示されたかどうかは、断った仕事の理由を説明してもらえるかで分かります。乗せない仕事の理由まで言葉になっていれば、その基準は自社でも同じように使えるからです。示された基準をそのまま次の業務へ当てられるかどうかが、その支援の残り方を決めます。

判断軸③外れた行の扱いまで決めるか

3つ目は、運用に入ってから外れた行をどう扱うかまでを、支援の中に入れるかどうかです。組み上げた直後は整っていても記録の書かれ方は変わり続けるので、扱いが決まっていないと、外れた行が積み上がったまま放置されます。定着まで伴走してほしい場合は、そこまでが見積もりに入っているかを確かめておきます。

この会社では、外れた行に印を付けて確認へ回す、月末に件数を数える、増えていたら条件を見直す、という3つを運用の手順として決めています。運用に入って以降、外れた行は月に10件前後で推移しています。

見積もりを読むときは、設計が終わる時点で作業が切れているのか、最初の数か月の見直しまで入っているのかを確かめておきます。手順が決まっていれば、担当が代わっても同じ扱いを続けられるためです。受け取る範囲を先に線引きしておけば、運用に入ってからの追加の相談も減らせます。

判断軸④自社の担当が引き取れる形で残すか

4つ目は、支援を受け終えた後に、自社だけで回せる状態が残るかどうかです。対象の条件と外れた行の扱いが自分たちの言葉で書き残されていれば、担当が代わっても同じ運用を続けられます。

引き取れる形かどうかは、支援の終わりに何が手元へ残るかで確かめられます。設定の画面だけが残る場合と、対象の条件と外れた行の扱いが文章で残る場合とでは、次の業務へ広げるときの手間が変わります。

支援先の比べ方をもっと広く知りたい場合は、導入支援会社の選び方のほうで、7つの見極め方をまとめています。なお当社では、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援を提供しており、まとめて処理する仕事の見極めについても無料相談を受け付けています。

【一問一答】Agentforce Gridに関するよくある質問

ここまで、まとめて処理する仕事の選び方と進め方を見てきました。ここからは、検討の場で実際に出やすい疑問を拾っておきます。そこでここでは、Agentforce Gridに関するよくある質問を5つ取り上げます。

Agentforce Gridで一括で回してよいのは、1件ずつの判断が同じ形で繰り返される仕事だけ

Agentforce Gridで何をまとめて処理できるかを決めるのは、機能の幅ではありません。決め手になるのは、その仕事の判断が1件ずつ同じ形で繰り返されるかどうかという点です。当初の目的は「たまった問い合わせの記録を分類して、多い順に手を打てる状態にすること」でしたが、このビル設備の会社が目的に届いたのは、処理の量を増やしたときではなく、処理する行を絞ったときでした。人の判断と一致した割合は88%から92%へ変わり、140時間と見積もっていた作業は毎月350件前後を回す運用に置き換わっています。

本記事で整理した4つの条件、3つの線引き、4つの決めごと、4つのステップは、いずれも画面を開かずに紙の上で終わります。判断が1文で書けるかを確かめ、入力が1行に収まるかを見て、外れた行を選び直せる形にし、書き戻しを最後に足します。提供が始まったばかりの機能だからこそ、使い方より戻し方を先に決めておくことが、後から効いてくるでしょう。本記事の内容が、自社で判断を組み立てるときの材料として少しでもお役に立てれば幸いです。