Agentforce Employee Agentとは？社内問い合わせを任せる範囲の決め方

AIエージェントを試すなら顧客対応から、と考えて検討が止まっている企業は少なくありません。顧客に見せる以上は誤答が許されず、回答を確認する体制を整えるだけで数か月かかるからです。一方で、社内の問い合わせを数えてみると、同じ質問が毎月繰り返し届き、情報システム部と人事部の時間がそこに使われ続けています。Agentforceには、この社内からの質問に答えるための Employee Agent という種類が用意されています。

本記事では、常温・冷蔵の食品物流を担う中堅企業（従業員520名・全国12拠点・情報システム部4名・人事部5名）を例に、社内問い合わせをどこまで任せてよいかの決め方を解説します。この企業は説明のための架空の設定であり、実在の企業ではありません。記載内容は2026年8月時点のものです。

この記事を書いた人

本田正憲

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

社内問い合わせで情シスと人事の時間が取られる3つの状況

社内問い合わせの負担は、月に何件届いたかという件数だけで語られがちです。実際に情報システム部と人事部の時間を使わせていたのは、同じ質問が何度も戻ってくることと、答えられる担当者が限られていることの2つでした。例に挙げた食品物流の企業に届く社内問い合わせは月におよそ480件で、そのうち何割が過去にも答えた内容なのかは、数えるまで誰も把握していません。件数だけを見て「多い」と判断している段階では、どこを減らせるのかも決められません。ここでは、担当者の時間が取られる3つの状況を整理していきます。

状況①同じ質問が毎月繰り返し届く

食品物流の企業で問い合わせの内容を1か月ぶん数えてみたところ、480件のうちおよそ6割が過去にも答えたことのある質問でした。件数の多い順に並べると、上位はどれも社内の規程やマニュアルに書かれている内容です。

繰り返し届いていた質問の上位3種類①経費精算・・・締め日と提出先を確認する質問です②勤怠・・・打刻の誤りを修正する手順を尋ねる質問です③共有フォルダ・・・アクセス権を誰に申請するかという質問です

書かれているのに質問が来るのは、探す場所が分からないからでした。規程は人事部のフォルダに、システムのマニュアルは情報システム部のフォルダに置かれており、どちらを見ればよいかを知っているのは、それぞれの部署の担当者だけだったのです。拠点の従業員には、2つのフォルダが分かれていること自体が知らされていませんでした。

1件あたりの対応は平均12分ほどでした。480件の6割にあたる288件が繰り返しの質問だとすると、月におよそ58時間が、すでに答えたことのある内容の説明に使われていた計算になります。情報システム部では、問い合わせへの対応が業務時間のおよそ25%を占めていました。

社内問い合わせの負担は、届いた件数よりも、同じ答えを何度も口頭で繰り返している割合で測ると実態が見えてきます。

状況②担当者本人にしか答えられない質問が滞る

繰り返しの質問と並んで担当者の時間を使っていたのが、特定の1人にしか答えられない質問です。この企業では、拠点ごとに導入時期の違う倉庫管理システムが動いており、拠点Aの設定は情報システム部のうち1名しか把握していませんでした。

その担当者が出張や休暇で不在になると、質問は返信待ちのまま滞ります。緊急でなければ翌週に回され、聞いた側は自分で試行錯誤するか、回答を待つあいだ作業を止めることになりました。担当者が戻ったときには、同じ内容の問い合わせが3件たまっているという状態も珍しくありません。

キヤノンマーケティングジャパンが2024年8月に実施した調査では、従業員300〜1,000名の企業の情報システム部門担当者108名のうち、社内ヘルプデスク業務に課題を感じている割合が64.8%にのぼり、その最多の理由は「ヘルプデスク対応に時間を取られ、他の進めたい業務が進められない」で62.9%でした。※参考記事はこちら

自社で同じことが起きているかどうかは、担当者が不在だった週に、回答までの日数が伸びていないかを見ると確かめられます。

状況③問い合わせの窓口が部署ごとに分かれている

3つ目は、聞く側から見て窓口が分かりにくい状況です。この企業では、システムの不具合は情報システム部のメールアドレスへ、勤怠と給与は人事部のチャットへ、経費は経理部の申請フォームへと、質問の種類ごとに3つの窓口が用意されていました。分ける側にとっては、担当が明確になる整理でした。

しかし拠点の従業員にとって、自分の質問がどれに当たるかは自明ではありません。パソコンが起動しないという相談は情報システム部でよいとして、リモート勤務の申請画面が表示されない場合はどちらに聞けばよいのでしょうか。判断のつかない質問はとりあえず情報システム部へ送られ、そこから人事部へ転送されることが日常的に発生していました。

転送の操作は数分で終わります。ただし転送を受けた側は経緯を把握するところから始めるため、実際には1件あたり20分近くかかることもありました。窓口を分けたままにしてよいかは、月にどれだけ転送が発生しているかを数えてから決めると判断しやすくなります。

社内問い合わせのAI化が続かない3つの原因

前章では、社内問い合わせで担当者の時間が取られる3つの状況を整理しました。では、こうした問い合わせをAIで減らす取り組みは、なぜ続かないのでしょうか。それは、立ち上げの作業だけが計画に入っていて、動かしたあとに誰が何を直すかが決まっていないからです。食品物流の企業でも、2年前に検索型のチャットボットを導入しながら、半年で誰も使わない状態になった経緯がありました。ここでは、その背景にある3つの原因を確認していきます。

原因①社内文書が更新されず回答がずれるから

まず起きたのは、答えの元になる社内文書が古いまま残り、回答だけが動き続けるという事態でした。この企業が導入したチャットボットは、人事部が作成した勤怠マニュアルを読み込んで回答していました。

しかし導入から4か月後に打刻システムが刷新され、画面の名称と操作の順番が変わりました。マニュアルの改訂は現場の運用が固まってからという判断で後回しにされ、その間もチャットボットは旧版のマニュアルにもとづいて答え続けていたのです。

利用者から「回答のとおりに操作しても画面が出てこない」という指摘が数件届き、人事部は暫定的にチャットボットの利用を止めました。止めた状態のまま改訂の担当が決まらず、そのまま使われなくなっています。回答の精度を保つ責任が誰にあるかを決めていなかったことが、実際の原因でした。

文書を更新する担当と期限を先に決めておけば、システムの刷新に合わせて回答も直せます。参照する社内文書をどう設計するかは、ほか記事「Agentforce RAGの仕組みは？精度が上がらない5つの原因と改善Tipsも」で詳しく解説しています。

原因②言い回しが違うと検索で見つからないから

次に問題になったのは、聞き方と文書の表記が一致しないことでした。検索型の仕組みは、入力された語と文書内の語を突き合わせて候補を返します。社内の規程では「時間外労働の事前申請」と書かれている手続きを、現場の担当者は「残業の申請」と呼んでいました。この差だけで、検索の結果には何も出てきません。

食品物流の企業では、拠点によって呼び方が違う用語がいくつもありました。倉庫では「棚卸」と呼ぶ作業を、本社の経理部は「実地棚卸」と表記しています。冷蔵の在庫を指す言葉も、拠点では「チルド」、本社の資料では「冷蔵品」と分かれていました。

呼び方の差を吸収するには、類義語を1語ずつ登録していく作業が要ります。その手間を負う担当者を置けなかったことが、利用が減った一因になりました。言い換えを理解して答えられるかどうかが、検索型の仕組みと生成AIを使う仕組みを分ける点になります。登録の作業が止まった時点で、答えられる質問もそれ以上は増えなくなりました。

原因③対応の記録が残らず改善点が分からないから

用語を登録すれば直せる問題も、直すべき箇所が分からなければ手をつけられません。この企業の問い合わせは、メールとチャットと口頭に分散しており、チャットボットが答えられなかった質問は、そのまま担当者への個別チャットへ回って、そこで解決して終わっていました。答えられなかった質問が何件あり、どんな内容だったかは、どこにも集計されていません。

答えられなかった質問の記録がないため、人事部の担当者は改善の材料を持てませんでした。実際に「使われていないのは分かるが、何を足せばよいのかが分からない」と話しています。利用が減った理由を後から調べられない仕組みは、改善の判断ができないまま止まります。

対応の記録は、エージェントを入れる前から残しておく価値があります。どの質問に答えられなかったかが分かれば、社内文書のどこを直すかを1件ずつ決められるためです。

社内問い合わせのAI化が続くかどうかは、答えられなかった質問を記録して次の改善につなげられるかで決まります。

Employee Agentが社内向けに動く3つの特徴

社内問い合わせのAI化が続かない3つの原因を確認してきましたが、これらは検索の仕組みと運用の設計に由来するものでした。Agentforceの Employee Agent は、この2つに手を入れやすい構成になっています。利用者ごとの権限を引き継ぎ、社内文書から答える構成をあらかじめ備えており、顧客向けのエージェントとは動く前提が違うためです。ここでは、Employee Agentが社内向けに動く3つの特徴を解説していきます。

特徴①利用者本人の権限のまま回答する

Employee Agentの中心にあるのは、質問した本人の権限で動く点です。Salesforce公式のTrailheadでは、Employee Agentについて「they’re logged in as the person they’re helping and follow the same permissions and org security settings」と説明されています（2026年8月時点）。※参考記事はこちら

つまり、エージェントが独自の広い権限を持って全社のデータを見るのではありません。質問した人が本来アクセスできる範囲の中で答えます。

食品物流の企業でいえば、拠点の担当者が自分の勤怠の申請状況を尋ねたときは答えられますが、他人の勤怠の内容までは返しません。権限の設計を新しく作り直す必要がなく、すでに運用しているSalesforceの権限をそのまま使える点が、社内向けに置きやすい理由になります。

Employee Agentは質問した本人の権限の範囲で答えるため、見せてよい情報の線引きを既存の権限設計に委ねられます。

特徴②社内文書から答えるトピックが用意されている

2つ目は、社内文書を読んで答える構成があらかじめ用意されている点です。同じくTrailheadでは「Employee agents come preconfigured with subagents and actions for many use cases」と記載されており、ナレッジから回答するトピックとアクションが最初から含まれています。

ゼロから設計する必要がないため、立ち上げの作業は「どの社内文書を読ませるか」を決めるところが中心になります。食品物流の企業が最初に選んだのは、経費精算の規程と勤怠マニュアルと共有フォルダの申請手順の3種類でした。どれも既存の文書をそのまま指定しており、新しく資料を作り起こす作業は発生していません。

用意されている構成をそのまま使うか、業務に合わせて追加するかは後から決められます。まず標準の状態で動かして、答えられない質問を見てから足していく進め方が現実的でしょう。追加するトピックは、あとから1つずつ増やせます。

特徴③Slackとモバイルからも呼び出せる

呼び出す場所を選べることも、社内向けでは重要になります。Employee AgentはSalesforceの画面のほか、Slackやモバイル端末からも利用でき、Trailheadでも展開先としてこの3つが挙げられています。

この違いは社内問い合わせで大きく出ます。拠点の従業員が普段開いているのは、Salesforceの画面よりも業務連絡に使っているチャットだからです。質問するために別のシステムへログインし直す必要があるなら、これまでどおり担当者へ直接聞くほうが早いと判断されます。聞く先を切り替える手間が、そのまま使わない理由になってしまいます。

食品物流の企業では、拠点間の連絡にSlackを使っていました。普段の連絡先の隣にエージェントを置けるかどうかが、使ってもらえるかどうかを分けます。Slackからの利用については、ほか記事「Agentforce in Slackとは？できることや導入手順、Box for Agentforceの関係」をご確認ください。

従業員エージェントと顧客向けエージェントの3つの違い

Employee Agentが社内向けに動く3つの特徴を確認してきましたが、顧客向けのエージェントと何が違うのかを整理しておく必要があります。同じAgentforceの中の種類でありながら、導入するときに求められる確認の量と、誤答が出たときに影響が広がる範囲が大きく異なるためです。従業員エージェントを先に選ぶかどうかの判断も、この違いを踏まえてから決めることになります。ここでは、社内向けと顧客向けを分ける3つの違いを解説していきます。

違い①誤答が届く相手が社内にとどまる

最も大きい違いは、間違えた回答が誰に届くかです。顧客向けのエージェントが誤った納期や金額を回答すれば、その内容はそのまま取引先に届きます。営業担当者が訂正の連絡を入れ、場合によっては経緯の説明を求められ、再発防止の手順を提出することもあります。

社内向けであれば、誤った回答を受け取るのは自社の従業員です。おかしいと気づいた時点で担当者に確認でき、影響はそこで止まります。食品物流の企業でも、試験運用の期間中に経費の上限額を古い規程のまま答えた例が1件ありましたが、質問した本人が経理部へ確認したうえで、その日のうちに規程の記載を直しています。

社外への謝罪や再発防止の報告書が必要になる場面と、社内で確認して終わる場面とでは、導入を承認する側が求める精度も変わってきます。顧客向けを先に置く場合は、この確認の重さを最初から引き受けることになります。社内向けから始めるのであれば、いつ引き受けるかを自社の準備に合わせて選べます。

違い②参照できるデータが利用者の権限で決まる

2つ目は、見せてよい範囲の決め方です。顧客向けのエージェントでは、どの顧客にどこまで見せるかを新しく設計する必要があります。本人確認をどう扱うか、他社の情報が混ざらないようにどう区切るかを、一から決めることになります。

社内向けでは、この設計がすでに終わっています。誰がどのデータを見てよいかは、Salesforceの権限として運用されているからです。エージェントはその権限を引き継いで動きます。新しく設計する場合と比べると、確認する相手も情報システム部の担当者だけで済みました。

食品物流の企業では、拠点の担当者と本社の管理職で見られる範囲が違いました。拠点の担当者は自分の拠点の勤怠と経費だけを、本社の管理職は担当する複数の拠点をまとめて確認できる状態です。この区別をエージェント側で作り直す作業は発生していません。既存の権限設計を流用できることが、社内向けの立ち上げが速い理由の1つです。 権限を見直す必要が出るのは、対象の質問が部署をまたいだときに限られます。

違い③公開前の確認にかかる手間が小さい

公開するまでに必要な確認の量も、社内向けと顧客向けで差が出ます。顧客向けの場合、想定される質問を洗い出し、回答の文面を法務や広報が確認する工程が入ります。表現の細部まで見る必要があるため、確認だけで数週間かかることもあるでしょう。顧客に向けて1件でも回答を出す前提であれば、この工程を省くことはできません。

社内向けでは、この工程を軽くできます。回答の相手が従業員であれば、表現の丁寧さより内容の正確さが優先されるためです。食品物流の企業では、情報システム部と人事部の担当者が2名で回答の内容を確認したうえで、4週間の試験運用に入りました。文面の言い回しは確認の対象にせず、規程の数字と手順の順番が合っているかだけを見ています。

確認を省いてよいという話ではありません。確認する範囲を、社外に出す文書と同じ水準にしなくてよいという意味です。どこまで見るかを先に決めておくと、確認にかかる日数も見積もれます。

社内向けエージェントをPoCの最初の対象に選ぶ3つの理由

社内向けと顧客向けを分ける3つの違いを見てきましたが、これらは社内向けを先に試すことの根拠にもなります。AIエージェントを導入する企業の多くは顧客対応から検討を始めるものの、最初の1体としては社内向けのほうが進めやすいと考えます。誤答が出たときの後始末が軽く、答えの元になるデータも自社で用意できるためです。社内問い合わせという題材は、動かしたあとに何が起きるかを確かめる場としても使えます。ここでは、社内向けエージェントをPoCの最初の対象に選ぶ3つの理由を解説していきます。

理由①誤答の影響範囲が社内に収まるから

まず前提として、エージェントが常に正しく答えると考えることはできません。参照する社内文書が古ければ古い内容を答えますし、質問の意図を取り違えることもあります。判断を分けるのは、精度の高さよりも、その誤りがどこまで広がるかです。

社内向けであれば、誤った回答は従業員に届き、そこで確認されて止まります。取引先へ訂正の連絡を入れる必要も、経緯を説明する必要もありません。食品物流の企業が試験運用を4週間で始められたのは、間違いが起きても社内で収まると判断できたからでした。試験運用の対象を本社の管理部門に限ったことも、この判断を支えています。

顧客向けであれば、同じ判断はできません。誤った金額を1件返しただけでも、取引先との条件を確認し直し、社内で経緯を共有するところから始まるためです。この差が、最初の1体をどちらに置くかという判断につながります。

社内向けエージェントは誤答の影響範囲が社内に収まるため、精度が固まりきる前に実際の質問で試せます。

理由②社内データのほうが整備しやすいから

答えの元になるデータを誰が直せるかも、社内向けと顧客向けで違います。顧客向けのエージェントが参照する情報には、製品の仕様や納期のように他部署や取引先の都合で変わるものが含まれます。整備しようにも、自部署だけでは決めきれません。取引先に確認しないと直せない情報であれば、更新の速さを自社の都合で決められないためです。

社内の規程やマニュアルであれば、作成した部署が自分の判断で改訂できます。食品物流の企業が最初に選んだ3種類の文書は、いずれも人事部と情報システム部が管理していたものでした。更新の必要が出たときに、他部署の承認を待たずに直せます。実際に、共有フォルダの申請手順は担当者1名の作業で当日中に更新できました。

文書の所在と改訂の権限が社内で完結していることが、整備の速さにつながります。整備の対象を広げすぎないことも大切で、この企業は最初に扱う質問の種類を8つに絞りました。対象を絞ったぶん、1つの文書にかけられる確認の時間は増えます。

理由③顧客接点へ広げる前に運用を確かめられるから

顧客に使う前に、運用の実際を確かめられることも挙げられます。エージェントを動かし始めると、設定の作業とは別に、答えられなかった質問を集めて社内文書を直すという継続的な作業が発生します。この作業を誰がどの頻度で担うかは、実際に運用してみないと見積もりにくいものです。

社内向けで先に動かしておけば、この負担の大きさを顧客向けへ広げる前に把握できると考えられます。食品物流の企業では、4週間の試験運用のあいだに情報システム部の担当者が週に1時間ほどを回答の見直しに使っていました。月あたり4時間強という数字を持って次の判断に進めた点が、いきなり顧客向けから始めた場合との違いになるのではないでしょうか。

一方で、社内で運用できたから顧客向けでも同じように運用できると言い切ることはできません。相手が変われば求められる精度も変わりますし、確認に加わる部署も増えるためです。ここで得られるのは、運用にどれだけ時間がかかるかという見積もりの材料にとどまると考えられます。

社内問い合わせをエージェントに任せる3つの場面

社内向けエージェントを最初の対象に選ぶ3つの理由を整理してきました。では、社内問い合わせのうち、具体的にどの場面を任せるとよいのでしょうか。それは、答えが社内文書に書かれていて、しかも人が毎回読み替えて説明している場面です。食品物流の企業が最初に対象とした8つの質問の種類も、この条件に当てはまるものばかりで、大きく3つの場面に分かれていました。ここでは、社内問い合わせをエージェントに任せる3つの場面を解説していきます。

場面①入社と異動の手続きに関する質問に答える

1つ目は、入社と異動にともなう手続きの質問です。この企業では拠点間の異動が年に数十件あり、そのたびに同じ質問が人事部へ届いていました。異動が決まってから初日までの期間が短く、聞かれる側も急いで答えることになります。

異動先で必要になる手続きは、複数の部署にまたがっていました。

異動のたびに発生していた手続き①社会保険・・・住所変更の届け出を人事部へ提出します②通勤経路・・・新しい拠点までの経路を再申請します③拠点システム・・・倉庫管理システムのアカウントを移管します

従業員から見ると、どこから手をつければよいかが分かりません。人事部の担当者は、その都度チェックリストを口頭で伝えていました。

エージェントに任せると、「来月に大阪の拠点へ異動します。何をすればよいですか」という質問に対して、必要な手続きを順に返せます。人事部に残るのは、個別の事情がある場合の判断だけになりました。異動の連絡が届いた時点で、本人が自分で手続きを確認できます。

場面②社内システムの使い方を画面ごとに案内する

手続きの案内に続いて多かったのが、システムの操作方法を尋ねる質問です。食品物流の企業では、倉庫管理システムと勤怠システムと経費精算システムの3つが日常的に使われており、操作の問い合わせが情報システム部へ集中していました。

この種の質問は、答えがマニュアルに書かれている点で共通しています。書かれているのに聞かれるのは、状況①で触れたとおり、どのマニュアルのどこを見ればよいかが分からないからでした。3つのシステムはそれぞれ提供元が違い、マニュアルの並び方もそろっていません。

エージェントであれば、「経費の申請を差し戻された場合はどうすればよいですか」という聞き方に対して、該当する手順を抜き出して返せます。マニュアルの構成を利用者が理解している必要がなくなる点が、検索との違いになります。差し戻された理由まで確認したい場合は、続けて聞き直すこともできます。操作の順番が変わったときも、マニュアルを差し替えれば回答の内容も切り替わります。

場面③経費精算の規程を条件つきで確認する

3つ目は、条件によって答えが変わる規程の確認です。この企業の出張にかかる経費は、移動距離と宿泊の有無と役職の3つによって上限が変わる仕組みでした。組み合わせの数だけ答えが分かれます。

規程には表の形で条件が書かれています。ただし自分がどの条件に当たるかを読み取るには、表の見方を理解している必要がありました。経理部への問い合わせのうち少なくない割合が、この読み取りに関するものだったのです。役職が変わった直後の従業員ほど、当てはめる行を間違えやすい状態にありました。

エージェントに任せると、「大阪に1泊で出張する場合の宿泊費の上限はいくらですか」という質問に、条件を当てはめた答えを返せます。条件が分岐する規程ほど、人が読み替える手間は大きくなります。 逆に、条件が1つしかない規程であれば、文書を検索できるようにするだけで足ります。

社内問い合わせのうち任せる効果が出やすいのは、答えが社内文書にあり、かつ条件の読み替えを人が代行している質問です。

社内問い合わせAIに任せる範囲を決める3つの判断軸

社内問い合わせをエージェントに任せる3つの場面を挙げましたが、社内問い合わせのすべてを対象にしてよいわけではありません。何を任せて何を残すかは、機能の説明を読んだだけでは決まりません。どの質問が業務のどこに影響するかを見たうえで、業務設計から決める必要があります。食品物流の企業も、対象を8つに絞り込む前に、外す質問のほうを先に決めていました。ここでは、社内問い合わせAIに任せる範囲を決める3つの判断軸を解説していきます。

判断軸①答えが社内文書に書かれているか

最初に確認するのは、その質問の答えが文書として存在しているかどうかです。エージェントは、読める形で保持されている情報にもとづいて答えます。担当者の頭の中にしかない判断は、そのままでは扱えません。

食品物流の企業では、拠点ごとの倉庫システムの設定に関する質問がこれに当たりました。設定の経緯を知っているのは担当者1名だけで、手順も判断の理由も文書化されていなかったのです。

このとき選べるのは、文書化してから対象に含めるか、対象から外して人が答え続けるかの2つです。この企業は、まず文書化されている質問だけを対象にすると決めました。文書化には時間がかかるため、最初の対象を増やすことより早く動かすことを優先しています。

文書がない質問を無理に含めると、答えられない質問が最初から積み上がります。どの業務から始めるかという判断の一般的な考え方は、ほか記事「Agentforceのユースケースの選び方は？どの業務から始めるかを決める5つの判断軸」で詳しく解説しています。

判断軸②間違えても取り消せるか

文書があるかを確かめたら、次は誤った回答が出たときに取り消せるかを見ます。回答を読んだ従業員がすぐに行動に移す種類の質問では、誤りがそのまま作業のやり直しにつながります。

たとえば「この伝票は取り消してよいか」という問い合わせに誤って肯定を返せば、取り消された伝票を元に戻す作業が発生します。倉庫の出荷指示のように、後続の作業が自動で動く場合はさらに影響が広がります。

一方で、規程の内容を確認する質問であれば、誤りに気づいた時点で正しい情報を確認し直せます。食品物流の企業が最初に選んだ8つの質問の種類は、すべて後者に当たるものでした。規程の確認であれば、誤りに気づくまでのあいだに作業が進んでしまうこともありません。読んだ従業員が申請ボタンを押す前に、担当者へ確かめる余地が残るためです。

取り消せるかどうかは、回答の正確さとは別の基準で見ます。精度が上がるまで待つ必要はなく、間違えても戻せる質問から始めるという考え方をとります。

判断軸③人事評価や給与に関わらないか

3つ目は、その回答が人事評価や給与に影響しないかという点です。給与の計算根拠や評価の基準に関する質問は、答えの正確さが個人の処遇に直結します。誤った回答が出た場合、取り消せるかどうか以前に、従業員との信頼に関わる問題になるでしょう。

この企業では、勤怠の打刻方法は対象に含める一方で、残業代の計算方法に関する質問は人事部が答えると決めました。同じ勤怠という領域でも、手続きの案内と処遇の説明では扱いを分けています。判断に迷う質問は、いったん人が答える側に置いてから、あとで移すという順番にしました。

線引きの基準を決めておくと、対象を広げるときの判断も速くなります。以上が、社内問い合わせAIに任せる範囲を決める3つの判断軸でした。セキュリティと権限の設計を含めた検討が必要な場合は、ほか記事「AIエージェントのセキュリティリスクとAgentforceの対策設計」でセキュリティ設計の詳細を扱っています。

任せる範囲は機能の一覧から選ぶものではなく、文書の有無と取り消しやすさと処遇への影響という業務側の基準で決めます。

Employee Agent導入でつまずく3つの落とし穴

社内問い合わせAIに任せる範囲を決める3つの判断軸を整理してきましたが、範囲を決めたあとの立ち上げにも、繰り返し起きるつまずきがあります。いずれも設定の技術的な難しさから生じるものではありません。答えられない質問が出たときにどう対応するかを決めていないことから生じます。Employee Agentは標準の構成で動き始められるぶん、この判断が後回しになりやすいところがあります。ここでは、食品物流の企業で実際に起きかけた3つの落とし穴を解説していきます。

落とし穴①権限を広げて答えさせようとする

1つ目は、答えられない質問が出たときに、権限を広げて解決しようとすることです。

試験運用に入って2週目、拠点の担当者から「他拠点の在庫の状況を聞いても答えてくれない」という声が上がりました。エージェントは質問した本人の権限で動くため、その担当者に閲覧権限のない他拠点のデータは返しません。仕様どおりの挙動です。在庫の閲覧を拠点ごとに分ける設定は、エージェントを入れるずっと前に決めたものでした。

このとき情報システム部で「エージェント用に広い権限を用意すればよいのではないか」という案が出ました。実行していれば、本来見えないはずの情報がエージェント経由で読める状態になっていたはずです。担当者が権限設計の意味を確認し、この案は採用されませんでした。

答えられない質問が出たときに疑うべきは、権限の狭さより、その質問を対象に含めた判断のほうです。対象から外すのか、閲覧権限の設計を業務として見直すのかは、情報システム部だけで決められる話ではありません。

落とし穴②古い社内文書をそのまま読ませる

権限と同じくらい見落とされるのが、更新されていない社内文書を対象に含めてしまうことです。原因①で触れたチャットボットが使われなくなった経緯と、構造は同じになります。

食品物流の企業では、対象にする3種類の文書について、最終更新日を確認する作業を先に行いました。経費精算の規程は前年に改訂されていた一方、共有フォルダの申請手順は3年前のままで、申請先の部署名がすでに変わっていたのです。勤怠マニュアルは打刻システムの刷新に合わせて改訂されており、そのまま使えました。

この手順書は先に改訂してから対象に含めました。もし気づかずに読ませていれば、存在しない部署へ申請するよう案内し続けることになっていたでしょう。改訂は申請先の部署名を差し替えるだけで済み、確認を先に回したことで作業のやり直しは起きていません。

対象の文書を選ぶときは、内容の適切さより先にいつ更新されたかを見て、古いものは読み直してから含めるかどうかを決めると危険を避けられます。

落とし穴③使われない理由を聞き取らないまま止める

3つ目は、利用が伸びないときに理由を確かめずに止めてしまうことです。

この企業の試験運用では、開始から2週間の時点で利用が想定を下回りました。ここで止めていれば、2年前のチャットボットと同じように使われないまま終わっていたはずです。情報システム部の担当者が拠点の従業員5名に理由を尋ねたところ、「Slackのどこから呼び出すのか分からない」という回答が複数ありました。

情報システム部の担当者がSlackでの呼び出し方を案内し直したところ、翌週から利用は戻っています。原因は回答の精度になく、呼び出す方法が知られていなかっただけでした。

利用が伸びない理由は、精度の問題と気づかれ方の問題に分けて確かめる必要があります。 前者なら社内文書を直し、後者なら案内の方法を直すことになり、打つ手がまったく変わります。どちらの問題かを確かめないまま止めると、次に始めるときも同じ理由で止まることになります。

利用が伸びないときは、回答の精度を疑う前に、そもそも呼び出し方が知られているかを確かめます。

社内向けエージェントを立ち上げる4ステップ

Employee Agent導入でつまずく3つの落とし穴を踏まえて、社内向けエージェントを実際に立ち上げる流れを整理します。食品物流の企業が4週間の試験運用に入るまでに踏んだのは、次の4つのステップでした。順番を見ると、設定の画面を開く前に決めておくことのほうが多くなっています。何を任せるかが決まらないまま設定から入ると、あとから対象を組み替えることになるためです。ここでは、社内向けエージェントを立ち上げる4ステップを順に解説していきます。

ステップ①問い合わせの多い質問を数える

最初にしたのは、実際に届いている質問を数える作業です。この企業では1か月ぶんのメールとチャットを情報システム部と人事部で分担して分類し、480件の内訳を出しました。口頭で受けた質問は記録が残っていないため、受けた担当者がその場でメモを取る運用を1か月だけ追加しています。

分類の粒度は細かくしすぎないほうが進みます。この企業は「勤怠」「経費」「システム操作」「入退社と異動」「その他」の5つに分けたうえで、件数の多い順に質問の種類を並べました。上位8つで全体のおよそ半分を占めていることが分かり、この8つを最初の対象にしています。「その他」に入った質問は対象から外し、件数だけを記録しました。

数える作業には2名で3日ほどかかりました。この3日を惜しんで現状の件数を残さないと、導入後に効果を比べる相手がなくなります。 件数だけでなく、どの種類の質問が何件だったかまで残しておくと、対象を広げるときにも使えます。

ステップ②答えの元になる社内文書を選ぶ

次に、8つの質問に答えるために必要な社内文書を選びました。落とし穴②で触れたとおり、選ぶ前に最終更新日を確認しています。

対象に選んだ3種類の社内文書①経費精算の規程・・・前年に改訂済みのためそのまま使いました②勤怠マニュアル・・・打刻システムの刷新に合わせて内容を確認しました③共有フォルダの申請手順・・・申請先を直してから対象にしました

この段階で、対象から外す判断もしています。倉庫管理システムの拠点別の設定に関する質問は、文書が存在しないため対象から外しました。文書化してから含めるという選択肢もありましたが、それを待つと立ち上げが数か月先になるためです。

対象にする文書を3種類に抑えたことで、更新の担当を部署ごとに1人ずつ決められました。担当が決まっていれば、改訂が遅れているかどうかにも気づけます。設定の画面操作については、ほか記事「【4ステップ】Agentforceで最初のエージェント1体を作るまでの設定手順」で解説しています。

ステップ③試験運用で回答を担当者が確認する

文書がそろったら、限られた範囲で動かして回答を確かめます。この企業は本社の管理部門40名だけを対象に、4週間の試験運用を行いました。拠点を入れなかったのは、拠点ごとに聞かれる内容が違い、確認する側の負担が読めなかったためです。

期間中は、エージェントが返した回答を情報システム部と人事部の担当者が週に一度まとめて確認しています。確認に使った時間は週におよそ1時間で、読むのは前の週に返した回答のうち、対象の8種類に当たるものだけに絞りました。誤った回答は経費の上限額に関する1件で、原因は規程の改訂内容が反映されていなかったことでした。

全社へ一度に広げていれば、この1件は12拠点の従業員に届いていた可能性があります。範囲を絞ったことで、影響を40名の中に収めたまま修正できました。確認の対象を8種類に絞ったからこそ、週1時間という枠に収まっています。40名という人数も、担当者2名が読み切れる量を基準に決めたものでした。

ステップ④使う範囲を部署単位で広げる

最後は、対象を広げていく段階です。この企業は本社の管理部門から始めて、次に本社の営業部門、そのあと拠点へと順に広げる計画を立てました。広げる判断は、前の部署で誤った回答が出ていないことを確認してから行っています。営業部門では、見積の作成手順に関する質問が新しく出てきました。

一度に全社へ展開しない理由は、部署ごとに聞かれる内容が違うからです。拠点では倉庫の作業に関する質問が中心になり、本社とは対象にすべき文書が変わります。広げるたびに、その部署でよく聞かれる質問を数え直す作業が入ります。

小さく始める（スモールスタート）進め方の利点は、この数え直しを1部署ぶんずつ確かめられる点にあります。全社で同時に始めていれば、どの部署で何が足りないのかを切り分けられないまま、全体の利用率だけを見ることになっていたでしょう。部署を1つ増やすごとに、その部署でよく聞かれる質問を対象へ足していく進め方も選べます。

以上が、社内向けエージェントを立ち上げる4ステップでした。

社内問い合わせAIの効果をフェーズ別に見る3つの指標

社内向けエージェントを立ち上げる4ステップを整理してきましたが、動かしたあとに何を見るかを決めておかないと、続けるかどうかの判断ができません。社内問い合わせAIの効果は、立ち上げ期・定着期・拡大期で見るべき指標が変わります。利用者がまだ少ない時期に割合を追っても数字が動きすぎますし、対象を広げた時期に件数だけを見ても待ち時間の悪化には気づけないためです。ここでは、フェーズごとに1つずつ、計3つの指標を解説していきます。

指標①立ち上げ期はエージェントだけで解決した件数

立ち上げ期に見るのは、担当者の手を借りずに解決した件数です。

この時期は利用者がまだ少なく、割合で見ると数字が安定しません。食品物流の企業では、試験運用の4週間で本社の管理部門40名から届いた質問のうち、エージェントだけで解決したのはおよそ4割でした。件数にすると多くはありませんが、担当者が対応せずに済んだ質問が実在したことは確認できています。残りの6割は担当者へ回っており、そのうち何件が対象外の質問だったかも記録しました。

この段階では、高い数字を目指すより、解決した質問がどの種類だったかを見ておくほうが役に立ちます。8つ選んだ対象のうち、どれが機能してどれが機能しなかったかが分かるためです。機能しなかった種類は、文書の書き方が質問の言い回しと合っていないことが多く、次の改訂の候補になります。ここで残した記録は、定着期に割合を見るときの比較の相手にもなりました。

立ち上げ期はエージェントだけで解決した件数を見て、対象に選んだ質問の種類ごとに機能したかどうかを確かめます。

指標②定着期は担当者へ引き継がれた質問の割合

定着期に入ったら、担当者へ引き継がれた質問の割合を見ます。件数が増えて分母が安定してくるためです。

引き継がれた質問には2つの種類が混ざっています。対象に含めていない質問と、対象に含めたのに答えられなかった質問です。この2つを分けて数えると、改善するべき場所が決まります。前者が多いなら対象を広げ、後者が多いなら社内文書の側に手を入れることになります。どちらの種類かは、質問の文面が対象の8種類に当てはまるかどうかで分けられます。

食品物流の企業では、この分類を情報システム部の担当者が月に一度行う運用にしました。原因③で触れた記録が残らない状態を避けるための仕組みでもあります。対象が8種類のうちであれば、月に一度まとめて確認するだけで足りていました。

引き継がれた割合が下がらない場合でも、内訳が対象外の質問に寄っているなら、対象を広げる時期に来ていると判断できます。割合の数字だけを追いかけると、この切り替えの時期を読み違えてしまいます。

指標③拡大期は回答までにかかった時間

拡大期に見るのは、質問してから回答が届くまでの時間です。この指標は、対象を広げたあとに意味を持ちます。範囲が広がると、エージェントが答えられずに担当者へ回る質問の絶対数も増えるためです。

担当者の処理が追いつかなくなると、引き継がれた質問の待ち時間が伸びていきます。待ち時間は、質問が届いた時刻と回答した時刻を残しておけば測れます。エージェントだけで解決した件数が増えていても、担当者へ回った質問の待ち時間が伸びていれば、従業員から見た使い勝手は導入前より悪くなります。

食品物流の企業では、状況②で触れたとおり、担当者不在で翌週に回る質問がもともと発生していました。拡大期にこの時間が導入前より伸びていれば、対象の広げ方が早すぎたと判断できます。その場合は、次の部署へ広げる前に対象の質問を足すほうを優先します。導入後に何を測り続けるかという考え方は、ほか記事「【失敗パターンから学ぶ】Agentforce定着ガイドと3ヶ月のロードマップ」が参考になります。

社内向けエージェントが向いている企業の3つの条件

社内問い合わせAIの効果をフェーズ別に見る3つの指標まで解説してきました。ただし、どの企業でも同じように効果が出るわけではありません。社内問い合わせの構造によっては、立ち上げにかけた労力に見合わない場合もあります。判断を分けるのは業種や規模よりも、繰り返しの質問がどれだけあり、その答えが文書として残っているかです。ここでは、社内向けエージェントが向いている企業に共通する3つの条件を整理していきます。

条件①同じ質問が繰り返し届いている

1つ目の条件は、同じ内容の質問が繰り返し届いている状態にあることです。エージェントで時間を減らせるのは、一度用意した答えを何度も返せるためです。逆にいえば、毎回内容の違う質問ばかりであれば、用意した答えが使われる回数は増えません。同じ答えが月に何度使われるかが、立ち上げにかけた工数に見合うかどうかを決めます。

食品物流の企業では、480件のうち6割が繰り返しの質問でした。この企業では上位8つの質問の種類だけで全体のおよそ半分を占めており、対象を絞っても答えられる範囲は広く取れています。反対に繰り返しの割合が低い企業では、8つに絞った時点で対象になる質問がほとんど残らないことになります。

自社の問い合わせのうち、過去にも答えたことのある質問がどれくらいを占めるかは、1か月ぶんを数えれば分かります。上位に並んだ数種類で全体の半分に届くようであれば、対象を絞っても効果を見込めます。届かない場合は、質問の種類を増やす前に、窓口の整理から検討する順番になります。

条件②答えの元になる社内文書がそろっている

繰り返しの多さと並んで見ておきたいのが、答えの根拠になる文書がすでに存在しているかどうかです。判断軸①で触れたとおり、文書化されていない知識は扱えません。規程やマニュアルが整っている企業ほど、立ち上げにかかる時間は短くなります。

逆に、これから文書を作るところから始める場合は、文書化の作業のほうが本体になります。エージェントを入れるかどうかに関係なく必要な作業ではありますが、立ち上げまでの期間は数か月単位で変わってきます。文書を作る作業には、内容を決める人と書く人の両方の時間が必要になるためです。

この企業は、経費と勤怠については規程とマニュアルが整っていた一方、拠点の倉庫システムについては文書がありませんでした。整っている領域から始めるという判断が、4週間で試験運用に入れた理由になっています。 文書がそろっている領域が1つでもあれば、そこから始められます。そろっていない領域は、対象を広げる段階であらためて足せば足ります。

条件③問い合わせの記録を残す仕組みがある

3つ目は、問い合わせの内容を記録として残せることです。原因③で触れたとおり、答えられなかった質問が集計されない状態では改善の判断ができません。記録が残る仕組みがあるか、これから作れる見込みがあるかは、続けられるかどうかを分けます。記録がなければ、対象を広げるべきなのか社内文書を直すべきなのかも決められません。

食品物流の企業では、Service Cloudで顧客からの問い合わせを管理していた経験がありました。どの問い合わせが何日で解決したかを残す運用が定着しており、社内問い合わせについても同じ考え方で記録を残せると判断できたことが、進めやすさにつながっています。

効果が出やすいのは、繰り返しの質問が多く、答えの元になる文書がそろい、対応の記録を残せる企業です。

記録の形式は、専用の仕組みでなくても構いません。答えられなかった質問の文面と日付が残っていれば、月に一度の見直しには足ります。表計算ソフトに1行ずつ書き足す形から始めても構いません。

社内向けエージェントを急がなくてよい3つのケース

社内向けエージェントが向いている企業の3つの条件を挙げましたが、当てはまらない場合に無理に進める必要はありません。今は着手を見送り、条件が整ってから検討したほうがよい状況もあります。見送るという判断は、社内問い合わせの負担を放置することとは違います。先に整理しておくべき作業があり、それを終えてから始めたほうが、結果として早く立ち上がるためです。ここでは、社内向けエージェントを急がなくてよい3つのケースを解説していきます。

ケース①問い合わせが月に数十件しかない

1つ目は、そもそも問い合わせの件数が少ないケースです。月に数十件であれば、担当者が対応しても大きな負担にはなりません。立ち上げにかかる工数と、削減できる時間を比べたときに、見合わない可能性があります。削減できる時間が月に数時間であれば、回答を確認する担当者を置く時間のほうが上回ることもあります。

食品物流の企業の場合、月480件という件数と、そのうち6割が繰り返しという構造が、着手を決めた理由でした。ステップ①で数えた2名で3日ぶんの工数も、480件という母数があるから成り立つ投資です。件数が10分の1であれば、同じ3日をかける判断にはなりません。

件数が少ない企業では、まず問い合わせの窓口を1つにまとめるといった整理のほうが、負担の軽減につながります。窓口が1つになるだけでも、転送1件あたり20分近くかかっていた作業はなくなります。判断に迷った質問をどこへ送るかで悩む時間も、あわせて減らせます。窓口をまとめる作業であれば、数日のうちに終えられます。

ケース②社内文書が個人の手元に散らばっている

件数は多くても着手を見送るべきなのが、規程やマニュアルが個人のパソコンや個別のフォルダに分散しているケースです。この状態では、どれが最新版なのかを判断できません。誤った版を読ませれば、誤った回答が返り続けます。

落とし穴②で触れた更新日の確認も、文書の所在が分からなければ実施できません。担当者に聞いて回れば集められるという見込みも、退職や異動があった領域では外れます。食品物流の企業で共有フォルダの申請手順が3年前のままだったことも、3種類を並べて確認するまで誰も気づいていませんでした。

この場合は、文書を1か所に集めて最新版を確定させる作業が先になります。その作業自体は、エージェントを入れるかどうかに関係なく必要なものです。人が探すときにも、どれが最新版かが分かる状態のほうが早く見つかります。集める作業を終えた時点で、対象にできる質問の種類も見えてきます。更新日を確認できた文書だけを対象にすると決めておけば、最初の範囲もそこで決まります。

ケース③制度の改定が続いて答えが定まらない

3つ目は、社内制度の改定が続いていて、答えが固まっていないケースです。人事制度の移行期や、システムの入れ替え期がこれに当たります。改定の途中で答えを固定してしまうと、古い内容を案内し続けることになります。

規程の内容が数か月ごとに変われば、そのたびに文書を改訂し、回答を確認し直す作業が発生します。改定が落ち着くまで待つほうが、やり直しの作業は少なくなります。動いている制度に合わせて文書を追いかけ続けると、確認を担当する社員のほうが先に続かなくなってしまいます。どの版が正しいかを人が判断する作業も、改定のたびに増えていきます。

食品物流の企業でも、拠点システムの統合が進行中だったため、その領域は対象から外しています。制度が動いている領域を避けて、安定している領域から始めるという選び方をとりました。 全社で改定が続いている場合は、落ち着く時期の見通しが立ってから計画を作るとよいでしょう。その間に問い合わせの件数を数えておけば、着手できる時期が来たときにすぐ動けます。

【一問一答】従業員エージェントに関するよくある質問

社内向けエージェントを急がなくてよい3つのケースまで、任せる範囲の決め方から測り方までを解説してきました。実際に検討を始めると、費用の見積もり方や自社だけで進められるかなど、判断の手前で確認しておきたい点が出てきます。従業員エージェントは日本語で使えるのか、そもそも何を読んで答えているのかといった、仕様に関する疑問も残るのではないでしょうか。最後に、社内向けエージェントについてよく寄せられる質問に答えていきます。

質問①Employee Agentに追加の費用はかかるのか

利用する構成によって変わります。実行した処理の量に応じて課金する形と、利用者数に応じて課金する形があり、どちらを選ぶかで、問い合わせが増えたときの費用の伸び方が違ってきます。従業員エージェントの課金の考え方については、ほか記事「Agentforce in Slackとは？できることや導入手順、Box for Agentforceの関係」で整理していますので、あわせてご確認ください。

質問②従業員エージェントは日本語で使えるのか

日本語での利用に対応しています。ただし、参照する社内文書が日本語で書かれていることと、社内で使われている用語の揺れを吸収できるかは別の問題です。原因②で触れたとおり、拠点ごとに呼び方が違う用語がある場合は、試験運用の中で答えられなかった質問を見ながら調整していく必要があります。

質問③社内問い合わせAIは自社だけで作れるのか

対象を絞れば、自社だけで立ち上げることは可能です。権限の設計がすでに運用されていること、参照する社内文書が整っていること、答えられなかった質問を見直す担当者を置けることの3つがそろっていれば進められます。権限設計から見直す必要がある場合は、外部の支援を組み合わせる判断も現実的です。

質問④Employee Agentは何を読んで答えるのか

管理者が指定した社内文書を読んで答えます。標準の構成にはナレッジから回答するトピックが含まれており、どの文書を対象にするかを設定します。指定していない文書は参照されません。対象を広げるほど答えられる範囲は広がりますが、更新の管理も同じだけ増えます。

質問⑤社内向けエージェントの誤答はどう扱うのか

誤答を前提に運用を組みます。回答を担当者が定期的に確認する時間を確保し、誤りが見つかったら元になった社内文書を直すという流れです。食品物流の企業では、試験運用中に週1時間ほどを確認に使い、見つかった誤りは1件でした。回答を1件ずつ直すより、参照元の文書を直すことが中心になります。

社内向けエージェントは誤答が社内にとどまるうちに運用を確かめられる出発点になる

Agentforce Employee Agentは、質問した本人の権限のまま社内の質問に答えるAIエージェントです。本記事では、社内問い合わせで担当者の時間が取られる状況から、AI化が続かない原因、社内向けを最初の対象に選ぶ理由、任せる範囲の判断軸、立ち上げの4ステップ、フェーズ別の指標までを、一連の流れとして解説してきました。

本記事で例として挙げた食品物流の企業の場合も、始めたのは大がかりな取り組みではありませんでした。月およそ480件の問い合わせのうち6割が繰り返しの質問で、1件あたり平均12分がかかり、情報システム部の業務時間のおよそ25%がここに使われていました。対象を8つの質問の種類に絞り、本社の管理部門40名で4週間動かした結果、エージェントだけで解決した割合は4割になっています。誤った回答は1件出ましたが、質問した本人が経理部へ確認し、その日のうちに規程の記載を直せました。

顧客対応から始めていれば、同じ4週間は回答文面の確認に費やされていたはずです。社内向けを先に選んだことで、運用にかかる負担を数字で把握したうえで次の判断に進めました。まずは自社の問い合わせのうち、過去にも答えたことのある質問がどれくらいを占めるかを数えるところから始めてみてはいかがでしょうか。

なお、任せる範囲を業務設計から一緒に整理し、定着まで伴走してほしい場合は、Agentforce導入・定着支援サービスにお気軽にご相談ください。1ユースケース×3ヶ月のスモールスタートから対応しています。