社内ヘルプデスクの自動化｜情シスの一次対応をAIに何割任せられるか

社内ヘルプデスクのどの問い合わせを引き受けられるか

最初に任せられるのは、答えが規程やマニュアルにそのまま書いてある質問です。条件で分岐するもの、個別の状態を見ないと答えられないもの、決裁が絡むものは人が持ちます。

情シスや管理部門が担う社内ヘルプデスクに集まる問い合わせは、内容の難しさよりも「同じ質問が繰り返し届く」ことで時間を取ります。答えは規程やマニュアルに書いてあり、担当者は毎回同じ箇所を探して同じ説明を返しています。

一方で、すべてを機械に渡せるわけではありません。個別の契約や権限の状態を見ないと答えられないもの、例外の承認が必要なものは残ります。自動化を検討するときは、まず届いている問い合わせを性質で分けます。

1行目だけが自動化の対象で、2行目以降は人が持つ、という切り方から始めると設計が単純になります。件数の内訳を数えると、1行目が想定より多いことも、逆に少ないことも分かります。数える前に対象を決めると、答えられない質問ばかり届く仕組みができます。

過去の問い合わせがチャットやメールに散っている場合は、直近1か月分を読んで分類するだけで足ります。全期間を集計する必要はありません。

質問の種類ごとに、自動で返す部分と人へ渡す部分を分ける

性質で分けたあと、実際に届いている質問の種類に当てはめます。ここで多いのは「この種類は自動、この種類は人」と種類ごと丸ごと振り分けてしまう形です。同じ種類の質問でも、案内で足りる部分と判断が要る部分が混ざっているため、種類の中で線を引きます。

上4行は、答えが文書に書かれている限り一次対応を機械に寄せられます。情シスの手元に残るのは、条件が揃わなかったときと、記述に無いことを聞かれたときだけになります。

下3行は、扱いを間違えやすい行です。不具合の相談は「既知かどうか」で分かれます。記録のある事象なら対処手順を返せますが、記録に無い事象に対してそれらしい手順を返すと、利用者が試したうえで解決せず、担当者への連絡が遅れます。自分の状況の照会は、数値を返そうとすると人事や勤怠のシステムへつなぐ話になるため、最初の段階では画面の場所と見方の案内までにとどめます。前例のない相談は、受け付けた事実だけを返して人へ渡します。

種類ごとに線を引いておくと、公開後に「答えられなかった」記録を見たときに、文書が足りないのか、そもそも人が持つと決めた範囲なのかを区別できます。区別が付かないと、人が持つと決めた質問への対応を機械へ足す作業に時間を使うことになります。

何割を寄せられるかを自社の内訳から出す

他社の比率を当てにしても判断材料になりません。同じ「社内問い合わせ」でも、規程の整備状況と扱う業務で内訳が変わります。自社の数字は上の分類から2つ出せます。

上限は着手前に出せます。直近1か月分を分類して、1行目に入った件数を全件で割るだけです。この値が、仕組みが完全に動いたときに人の手から離れる件数の見込みになります。

実際に寄る割合は必ず上限より低く出ます。入口が使われない、文書に記述はあるが引けない、質問の書き方が想定と違うといった理由で差が生まれます。上限を先に出しておくと、公開後にこの差が何件分あるかを見て、文書側と入口側のどちらを直すかを決められます。上限そのものを上げたい場合は、2行目以降の性質の問い合わせに対応する文書を書き足す作業になり、仕組み側の調整では動きません。

散在する文書を検索できる形に整える

回答の質は、参照する文書の状態でほぼ決まります。文書が整っていない状態で検索の仕組みだけを作っても、答えられない質問が増えるだけです。整える手順は次の順です。

1. 対象を棚卸しする。 規程、マニュアル、申請の手引き、過去の問い合わせへの回答が、どこに何件あるかを一覧にします。この時点で同じ内容の資料が複数の場所にあることが見えます。

2. 正本を1つに決める。 同じ主題の文書が複数あるなら、どれを有効な版とするかを決め、それ以外は検索の対象から外します。ここを飛ばすと、古い版を根拠にした回答が出ます。

3. 検索の単位に分割する。 100ページの規程を丸ごと1件として扱うと、質問に関係のない箇所まで一緒に引かれます。見出し単位で区切り、どの文書のどの節かが分かる形にします。

4. 文書に適用範囲を書く。 対象者、適用される期間、対象外の条件を文書の側に明記します。「誰に当てはまるか」が書かれていない文書は、質問者ごとに違う答えを返せません。

5. 更新の担当を決める。 文書ごとに、内容を直す責任を持つ人を1人決めます。文書の追加より、この割り当てのほうが後々効きます。

表形式の資料や画面の操作手順を画像で説明している資料は、そのままでは検索に乗りません。文章として書き直すか、当面は対象外にするかを決めます。全部を整えてから始めようとすると着手できないため、件数の多い質問に対応する文書から順に進めます。

文書のアクセス権が部署や役職で分かれている場合は、検索の時点で質問者の権限を反映させます。権限を無視して全文書を対象にすると、本来見えない情報が回答として出ます。権限で絞れない文書は、対象から外しておくほうが安全です。

回答の根拠を示す作りにする

社内の問い合わせでは、答えの内容だけでなく「どの規程のどこに書いてあるか」が必要になります。回答を受けた人が自分で確かめられ、後から経緯を追えるためです。回答には次を添えます。

• 参照した文書の名称と、該当する節へのリンク
• 引用した箇所そのもの（要約ではなく原文）
• 文書の最終更新日
• 該当する記述が見つからなかった場合は、その旨

最後の項目が重要です。根拠が見つからないときに、それらしい文章を返してしまう作りにすると、間違いが混ざったまま社内に流通します。「見つからなかった」と返して人へ渡す動作を、正常な結果として扱います。

回答の言い回しを整えることより、根拠の提示と「答えない」判断のほうが先です。文面の調整は後から効きますが、根拠のない回答は一度出ると信用が戻りません。

人へ渡す境界を決める

境界は質問の難しさではなく、根拠を示せるかどうかで引きます。文書の該当箇所を出せない質問は、答えの見当が付いていても人へ渡します。

答えられない質問を人へ渡す経路を、最初から作り込みます。ここが無いと、答えの出なかった質問がそのまま宙に浮きます。

渡す先が社外になる問い合わせは、同じ考え方でも自動で返してよい範囲が狭くなります。フォームやメールで届く社外からの問い合わせを一次返信し、面談の日程調整まで進める設計は「問い合わせの一次返信と面談の日程調整をAIで自動化する」で扱っています。

関連記事：問い合わせ自動返信と日程調整の自動化｜自動で返す範囲と、人が送信を決める問い合わせの分け方

渡すときに決めておくのは3点です。誰に渡るか（担当者個人ではなく、チャネルや窓口に渡す形にする）、渡す情報（質問の文面と、検索で当たった候補まで引き継ぐ）、戻す期限（一定時間で応答が無い場合の扱い）です。

人が答えた内容を文書へ戻す経路も、この段で決めます。戻す仕組みが無いと、同じ質問が翌月も人へ渡ります。回答した本人が文書を直すのか、内容を記録して別の担当が月次でまとめて直すのかを決めておきます。

精度が合わないときの切り分け

公開後に「答えが合わない」という声が出たとき、原因は文書側と検索側のどちらかに寄ります。混ぜて対処すると直し方を間違えます。

切り分けの材料になるのは、実際に来た質問と返した回答、そのとき参照した文書を対にして残した記録です。これを残していないと、原因の議論が「精度を上げる」という漠然とした話に流れます。記録は最初から取ります。

直す優先順位は、件数の多い質問から決めます。1件しか来ていない質問に合わせて仕組みを変えると、多くの質問に対する答えが崩れることがあります。

更新が止まった資料をどう扱うか

社内文書を集めると、必ず「いつの内容か分からない資料」が出てきます。数年前に作られ、その後の運用が変わっているかどうかが本人にも分からないものです。これを放置すると、根拠を示した回答が結果的に誤りになります。

扱い方は3つに分かれます。内容が今も有効だと確認できたものは、確認日を記録して対象に残します。有効でないと分かったものは、検索の対象から外します。判断が付かないものが問題です。無理に有効と決めず、対象から外して質問が来たら人へ渡す形にします。「答えられる範囲を狭める」判断は、間違った根拠を出すより安全です。

一定期間更新されていない文書に印を付け、担当者へ確認を促す運用を組んでおくと、判断が付かない文書が増え続けるのを抑えられます。文書の量が多い場合は、実際に参照された回数の多いものから確認します。参照されていない文書を先に整えても、回答は変わりません。

着手の順序

進める順序は次の形になります。

1. 直近1か月分の問い合わせを分類し、文書に答えがあるものが何件かを数える
2. その件数の多い質問に対応する文書だけを整える。全文書を待たない
3. 根拠の提示と、答えられないときに人へ渡す経路を作る
4. 対象者を限って公開し、質問と回答の記録を取る
5. 記録を見て、文書側と検索側のどちらを直すかを判断する
6. 対象の質問を広げる

3の経路を作る前に公開すると、答えられない質問が行き止まりになり、使われなくなります。4で対象者を限るのは、初期の回答品質が低い段階で全社に開くと、一度離れた人が戻らないためです。

社内で生成AIを使う前提としての入力ルールや利用可否の線引きは、「生成AIの社内利用ルールをどう作るか」で扱っています。QAチャットは社内文書を扱うため、どの機密度の文書までを対象にするかをここで決めておきます。

関連記事：生成AIの社内ルールの作り方｜利用規定9章のひな形と入力可否の判定表

検証から本番運用へ進める際の判断基準や見積の考え方は、「AIエージェント開発の進め方」を参照してください。問い合わせ対応は入口と出口が明確なため、最初の題材にしやすい業務です。

関連記事：AIエージェント開発の進め方｜対象業務の選び方と4工程の全体像、次へ進む前に決めること

削減できた時間をどう測るかは、「AI導入の効果測定と投資判断」の考え方が使えます。問い合わせの件数と、人へ渡った割合の推移が判断の材料になります。

関連記事：AI導入の効果測定｜KPIの例と導入前後の比べ方、継続・中止の判断

まとめ：社内ヘルプデスクをAIに引き受けさせるときの要点

• 届いている問い合わせを性質で分け、文書に答えがそのまま書いてあるものだけを最初の対象にする
• 質問の種類ごとに、案内で足りる部分と判断が要る部分の線を引く。種類を丸ごと機械側か人側かに振り分けない
• 何割を寄せられるかは直近1か月分の内訳から出す。着手前に上限を出し、公開後に実際に寄った割合と比べる
• 人へ渡す境界は質問の難しさではなく、根拠を示せるかどうかで引く
• 文書は「棚卸し→正本を決める→検索の単位に分割→適用範囲を書く→更新の担当を決める」の順で整える。全部を整え終える前に着手する
• 回答には参照した文書と原文、最終更新日を添える。根拠が見つからないときは答えずに人へ渡す
• 人へ渡す経路は、渡す先と引き継ぐ情報と戻す期限を決めておく。人が答えた内容を文書へ戻す経路も同時に作る
• 答えが合わないときは文書側と検索側に切り分ける。そのために質問と回答と参照文書の記録を最初から取る
• 有効か判断が付かない資料は対象から外す。答えられる範囲を狭めるほうが、誤った根拠を出すより安全

Augueでは、社内ヘルプデスクの一次対応を担うAIエージェントの開発に対応しており、社内文書を検索できる形に整えるところから、どこまでを自動で回答しどこから人が引き取るかの線引きまで一緒に設計できます。自社の問い合わせのどれを対象にできるか判断したい方は、是非ご相談ください。

自社専用のAIエージェントを作りませんか？

作るか既製品を使うか、費用の目安から相談できます。使うほど育ち、成果が続くAIエージェントの開発をご支援します。開発の進め方と事例はサービス資料でご覧いただけます。

資料をダウンロードする無料相談に申し込む

よくある質問

社内Wikiの検索機能を強くするのと、AIのQAチャットを作るのはどちらが先ですか？

文書の置き場所が複数に分かれている場合は、正本をどこに置くかを決める作業が先になります。検索の仕組みを変えても、同じ内容の資料が別の場所に残っていれば、どちらが有効か分からないという状態は解消しません。置き場所と更新の担当が決まっていれば、QAチャットの構築と並行して進められます。

従来のキーワード検索型の社内FAQシステムとの違いは何ですか？

キーワード検索は、質問者が使った語が文書に含まれているかで当たり外れが決まります。社内では同じ対象を人によって違う語で呼ぶため、正しい語を知っている人しか探せません。文章で質問できる形にすると、語が一致しなくても意味の近い箇所を引けます。代わりに、引いた箇所が本当に根拠になっているかを確かめる仕組みが必要になります。

導入の費用と期間の目安はどれくらいですか？

一律の金額は出せません。対象文書の量と形式、既存システムとの接続の有無で変わります。見積を比べる材料としては、文書を整える工程が誰の作業として含まれているか、公開後に回答の記録を見て直し続ける費用が入っているかを確認します。この2つが抜けた見積は、動き出したあとで追加になります。

社外のAIサービスに社内文書を渡してよいかは、どう判断しますか？

文書の機密度と、利用するサービスの契約形態を突き合わせて判断します。入力したデータが学習に使われない契約になっているか、保存場所と保存期間がどうなっているかを確認します。最も機密度の高い区分は当面対象から外し、扱える区分だけで始める形が取りやすいです。

チャットを用意したのに、担当者へ直接聞く人が減らない場合は何を見ますか？

見るのは3つです。質問件数がどう推移しているか、回答できずに人へ渡った割合、そして人へ渡ったあとの質問がどんな内容かです。回答できない質問が多いなら文書側の不足、回答はできているのに使われないなら入口の場所か初回の体験に原因があります。切り分けずに機能を足すと、使われないまま残ります。

関連する記事

生成AIの社内ルールの作り方｜利用規定9章のひな形と入力可否の判定表生成AIの社内ルールの作り方を、現状の把握から周知と見直しまでの4つの手順で示します。最初に配るA4で1〜2枚の短い版のひな形、利用規定9章の章立て、機密度と利用形態で決める入力可否の判定表まで整理します。AIエージェント開発の進め方｜対象業務の選び方と4工程の全体像、次へ進む前に決めることAIエージェント開発を検証で終わらせないための進め方です。対象業務の選び方、4つの工程で次へ進む前に決めること、本番に乗せる判断、運用開始後に続く作業までを、順にたどれる形で整理しました。PoC止まりの原因とPoCを本番化する6条件｜3つの型と撤退の線引きPoC止まりの原因を見分け、PoCを本番化するか撤退するかを判断できます。生成AIのPoCが止まる3つの型を早見表にし、本番化の前に埋める6条件をチェックリストにしました。費用と期間の見積り方も扱います。