社内ヘルプデスクのAI自動化｜構築方法・答えさせる範囲・費用

社内ヘルプデスクのAI自動化は、社内規程やマニュアルをAIが検索して回答するRAG（検索拡張生成）を土台に作ります。文書に答えが書いてある問い合わせをAIの一次対応に任せ、個別の判断が要る相談や人事・労務の相談は担当者へ引き継ぐ形です。構築は現状把握・PoC・実装・運用の4段階で、件数の多い1〜2種類の問い合わせから始めます。費用は対象範囲・部署数・文書の整備状況で決まり、FAQの文書化のように費用をかけない方法から個別構築まで幅があります。

社内ヘルプデスクの問い合わせ対応が「属人化」から抜け出せない理由

情報システム部門や総務・人事部門には、日々「PCが起動しない」「VPNにつながらない」「有給休暇の申請方法がわからない」「経費精算のやり方を教えてほしい」といった、社内の従業員からの問い合わせが絶えず届きます。これらの多くは過去に何度も聞かれた定型的な内容であるにもかかわらず、担当者はそのたびにメールやチャットの受信箱を確認し、社内規程やマニュアルを探し、個別に回答を作成しています。

問い合わせの内容自体は難しくなくても、件数が多いと対応時間は積み上がります。しかも同じ質問に何度も答える作業は、担当者の本来の業務（システムの企画・改善や制度設計など）を圧迫し、対応品質も担当者の知識量や在籍期間によってばらつきが出ます。特定のベテラン担当者に問い合わせが集中し、その人が休むと対応が止まる、という属人化も起きやすい業務です。

生成AI（LLM＝大規模言語モデル。文章を人のように理解して処理できる生成AIの中核技術）は、言い回しの違う質問でも意味をくみ取り、社内文書の該当箇所を探して回答を組み立てられます。そのため、同じ質問に担当者が何度も答える作業を、AIの一次対応に移せます。

なぜヘルプデスク対応は自動化しにくいのか：3つの壁

社内ヘルプデスクの問い合わせは一つひとつは単純でも、AIに任せようとすると次の3つの壁があります。

• 回答の根拠が複数の場所に散らばっている：社内規程・就業規則・システムのマニュアル・過去のFAQ・部署ごとの独自ルールなど、回答の根拠となる情報は複数の文書やツールに分散していることが多い。AIが正確に回答するには、これらを横断して参照できる状態にまとめる必要がある
• 質問の言い回しが従業員ごとにバラバラ：「有給の申請方法」と「休みを取りたいときはどうすればいい？」は同じ質問だが、表現は大きく異なる。決まったキーワードを拾う仕組みでは、表現の揺れに対応しきれない
• 答えられない質問と答えるべきでない質問の線引きが必要：個人の評価や人間関係が絡む相談、規程の解釈が分かれるグレーな案件など、AIが単独で回答すべきでない性質の問い合わせも一定数ある。これを事前に切り分けないと、誤った回答や不適切な回答が従業員に届く

この3つの壁を越えるには、社内文書を検索対象にしたRAG（検索拡張生成。社内の文書やデータをAIが検索し、その内容をもとに回答を組み立てる仕組み）を土台にしつつ、「AIが答えてよい範囲」と「人に引き継ぐ範囲」を業務設計として切り分ける作業が欠かせません。

社内ヘルプデスクの対応が属人的な手作業のまま残っていると、次のような形で業務や組織に影響が及びます。

• 担当者の本来業務の圧迫：定型的な問い合わせ対応に時間を取られ、システムの企画・改善や制度設計といった、本来注力すべき業務が後回しになる
• 対応品質のばらつきと属人化：担当者の知識量や経験によって回答の速さ・正確さが変わり、特定の担当者が不在になると対応が滞る
• 従業員側の待ち時間の発生：問い合わせから回答までに時間がかかると、従業員は業務を止めて回答を待つことになり、組織全体の生産性に影響する
• 情報システム部門・総務・人事の増員圧力：問い合わせ件数が組織の成長とともに増えていくと、対応のための人員を増やす必要が生じ、コストが積み上がる

どれも、問い合わせの件数が増えるほど、担当部門がシステムの企画や制度の見直しに使える時間が削られていく点で共通します。

社内ヘルプデスクAI化の進め方（4つのフェーズ）

社内ヘルプデスクのAI化は、全部署・全業務範囲を一度に対象にせず、次の4段階で進めます。

①現状の把握では、どの部署（情シス・総務・人事等）の、どんな種類の問い合わせが多いか、根拠となる社内文書・規程がどこにどんな形式で存在するか、月間の問い合わせ件数を洗い出します。ここで「もっとも件数が多く、かつ回答の根拠が明確な問い合わせ種別はどれか」を見極めることが、後工程の効果を左右します。

②PoC（概念実証。小規模に試して効果を確認する工程）では、全問い合わせ種別を対象にせず、件数の多い1〜2種別（例：総務・人事系のよくある質問）に絞ってAIによる一次回答を試します。実際の問い合わせを使い、どの程度の精度で回答できるか、反対にAIでは答えられず人に引き継ぐべき問い合わせがどの程度出るかを確認します。

③実装では、PoCで見えた精度・引き継ぎが必要なパターンの傾向を踏まえ、対象範囲を主要な問い合わせ種別へ広げます。根拠となる文書が見つからない場合や、規程の解釈が分かれる場合は自動で担当者へ引き継ぐ設計にし、「AIが答えてよい範囲」を明確に線引きします。

④運用は、社内規程の改定や新しい制度の導入のたびに、AIが参照する情報を更新する工程です。回答精度が落ちた場合や、従業員からの新しい種類の問い合わせが増えた場合に、継続的に参照データや回答範囲を見直す保守体制を維持します。

仕組みの構成は、①参照する社内文書の置き場所、②文書を検索して回答を組み立てるRAG、③従業員が質問する窓口（社内チャットツールやポータル）、④答えられないときの引き継ぎ先（担当者のチャットや申請フォーム）の4つです。窓口は従業員が普段使っている社内チャットに置くと、新しいツールの使い方を覚える手間がかかりません。

社内ヘルプデスクのAI化で多い3つの失敗

導入後に「使われない」「誤った回答が出る」状態になる原因は、次の3つに集約されます。

①「AIが答えてよい範囲」を決めずに始める：個人の評価や人間関係が絡む相談まで含めて何でも自動回答させようとすると、不適切な回答が従業員に届くリスクが生じます。現状把握の段階で、AIが単独で回答してよい範囲と、人が対応すべき範囲を各部署とすり合わせます。

②回答の根拠となる文書を見直さないまま導入する：社内規程やマニュアルが古い情報のまま放置されていると、AIも古い情報をもとに回答します。AI化と同時に、参照する文書を最新の状態に保つ運用体制を作ります。

③全部署・全業務を一気に自動化しようとする：部署ごとに問い合わせの性質も規程も異なるため、初めから全社一括で導入すると、部署固有のルールへの対応が追いつかず、従業員も担当者も混乱します。PoCで件数の多い部署・問い合わせ種別に絞り、精度を確認しながら対象を広げてください。

AIに答えさせてよい問い合わせ・いけない問い合わせ

社内ヘルプデスクの自動化は、対象範囲の線引きで成否が決まります。次の基準で仕分けると、最初に対象にすべき範囲が見えます。

最初は1行目の問い合わせに絞ります。答えが社内文書にある問い合わせは、文書を探す手間を省けば解決するため、AIの回答精度を確かめやすく、効果も測りやすいからです。

AIが答えられないときの引き継ぎ設計

社内向けの仕組みは、使い始めに誤った回答や行き止まりが続くと、従業員が再び担当者へ直接聞くようになります。次の3点を最初から組み込んでください。

• 分からないときは「分かりません」と返す：根拠のない回答を一度でも返すと、正しい回答まで疑われる
• 担当者へ引き継ぐ導線を置く：回答できなかった時点で、担当のチャットや申請フォームへ1クリックで移れるようにする
• 答えられなかった質問を記録する：この記録が、次に整備すべき文書の一覧になる。月に一度見直し、件数の多い質問から文書を追加する

費用の目安

費用は対象とする問い合わせ範囲・部署数・参照文書の整備状況で変わります。以下は市場の一般的な目安で、特定サービスの確定価格ではありません。

効果を測る指標は、問い合わせの総件数ではなく「担当者が対応した件数」です。総件数は仕組みを入れると一時的に増えることがあります（聞きやすくなるため）。担当者に届く前に解決した割合が上がっているかを見てください。

土台になるRAG（社内文書をAIが検索・参照する仕組み）を外注するときの費用の内訳と依頼前の確認事項は、RAG構築を外注する費用相場｜内訳と依頼前に確認すべき3つのことで確かめられます。対象が社外の顧客からの問い合わせ（返品・送料等）の場合は課題の性質が異なるため、生成AIのカスタマーサポート自動化｜失敗する3つの原因が役立ちます。どの業務からAI化に着手すべきか総論から確認したい場合は業務自動化のAI開発を外注するには｜業務の見極め・会社選び・費用も参考になります。

まとめ：AIに任せる範囲と人に引き継ぐ範囲を先に決める

社内ヘルプデスクのAI化の目的は、問い合わせの全件自動回答より、担当者が対応する件数を減らすことにあります。件数が多く根拠が明確な定型的な問い合わせをAIに任せ、個人の状況判断が必要な相談は人に引き継ぎます。この線引きを業務設計として決めてから、対象範囲を段階的に広げてください。

問い合わせの記録から件数の多い種類を拾い出し、FAQの文書化で足りるか、社内文書を参照する仕組みの構築が要るかを見極める段階から、awaiも手伝えます。