社内ヘルプデスク・IT問い合わせ対応のAI内製化——SaaSの「AIエージェント化」と何が違うのか

「またこの質問か」——情シス・総務が抱える、日々の問い合わせ疲弊の実態

ある中堅製造業の情報システム部門があります。パスワードリセットの申請、VPN(仮想プライベートネットワーク: 社外から社内システムに安全に接続する仕組み)の設定方法、備品購入の稟議フローの確認といった問い合わせが、毎日十数件寄せられていました。担当者はその都度、社内規程やマニュアルを検索して回答していましたが、後から集計すると、質問の8割近くは過去にも同じ内容が寄せられていたことが分かったといいます。

私たちが支援している中堅企業でも、似たような光景をよく目にします。情シスや総務の担当者は、日々の問い合わせ対応に追われるあまり、本来やるべき企画業務や改善業務に手が回らなくなっています。しかも、回答のノウハウは担当者の頭の中にしかありません。異動や退職があれば、過去にどんな質問にどう答えてきたかという記録ごと消えてしまいます。

なぜ今、社内ヘルプデスクのAI内製化が現実的になったのか

マネーフォワードは2026年4月6日、新サービスを発表しました(出典)。AIが従業員からの問い合わせに自動回答し、パスワードリセットやアカウント発行などの定型作業まで代行する「Admina AIヘルプデスク」です。対応内容を自律的に学習し、回答や実行の精度を継続的に高める仕組みで、2026年5月からの提供開始を予定しているといいます。

つまり、社内問い合わせの一次対応をAIが担い、担当者はマニュアル更新の手間から解放されるという段階に、実運用のレベルで入ってきたということです。DeNAも、社内AIヘルプデスクでRAG(社内のドキュメントをAIに読み込ませて回答精度を上げる技術)の精度を改善し、正答率80%を達成したとの発表があります。私たちの現場経験では、こうした技術は既存のFAQやマニュアルさえ整理できていれば、内製でも十分に再現できる段階に来ています。

ここで誤解のないように言っておきたいのは、この技術が「あらゆる問い合わせを自動化できる」ものではないという点です。AIが実際に得意なのは、定型的で頻度の高い質問への一次回答です。人事考課や懲戒に関わる相談、規程の解釈が分かれるような判断は、また別の話になります。

SaaS型AIヘルプデスクと、内製は何が違うのか

社内ヘルプデスクの仕組み化を検討すると、多くの場合、最初に候補に挙がるのはPKSHA AIヘルプデスク、Helpfeel、HiTTOといった専門ベンダーのAIヘルプデスクSaaSです。これらのサービスは月額数万円から利用できる比較的手頃なプランもありますが、全社員分のライセンス費用を積み上げると、中堅企業でも年間数百万円規模になるケースが少なくありません。

観点	SaaS型(AIヘルプデスク)	AI-Path型(内製)
初期投資	月額ライセンス費+初期構築・ナレッジ移行・教育の隠れコストが別途積み上がる	1つの問い合わせカテゴリ・1つの窓口から数十万円規模で検証可能
対象範囲	全社員・全カテゴリへの一括導入が前提	頻度が高く、機密度の低いカテゴリからだけ着手できる
データの扱い	ベンダーのクラウド基盤に社内規程・人事情報を預ける	自社データを外部に出さない設計も選択可
拡張性	ライセンス数・利用部門数に応じた段階課金	検証結果を見ながら段階的にカテゴリを広げられる

正直に言えば、大手ベンダーのAIヘルプデスクSaaSには、既製のFAQテンプレートやエスカレーション機能を短期間で導入できる利点があります。ですが、私たちが相談を受ける中堅企業の多くは、まず1つのカテゴリで「本当に対応工数が減るか」を確かめたいと考えています。「社内ヘルプデスク AI 内製化」を検討する企業にとって必要なのは、全社一斉導入の縮小版ではなく、既存の問い合わせフローを壊さずに試せるアプローチだというのが私たちの実感です。「情シス AIヘルプデスク SaaS 比較」で情報を集めている方の多くが本当に知りたいのも、機能の一覧表ではなく、既存の問い合わせフローを壊さずに導入できるかどうかだと私たちは考えています。

PoC(概念実証: 小規模な検証で効果を確かめること)で確認すべき5つのパターン

社内ヘルプデスクAIを検証する際、私たちが欠かさずチェックする観点があります。1つ目は機密度の混在で、パスワードリセットのような軽い質問と、人事考課のような機密性の高い質問が同じ窓口に届く場合、AIがどこまでを一次対応し、どこから人に引き継ぐかです。2つ目は部門・拠点差で、本社と工場で異なる社内規程やローカルルールを混同せずに案内できるかです。3つ目は社内独自の略語で、正式名称ではなく現場の通称で質問された場合に、意図を正しく汲み取れるかです。4つ目は情報の鮮度で、規程が改定された直後に、更新前のマニュアルを参照して誤った案内をしないかです。5つ目はエスカレーションの見極めで、AIが答えられない質問を、答えられないと自覚した上で人に渡せるかです。

「IT問い合わせ対応 AIエージェント 比較」の記事の多くは機能の一覧を並べますが、私たちの経験では、この5パターンで実際に試してみるまで、本当に使えるかどうかは分かりません。特に5つ目のエスカレーションの見極めは見落とされがちで、AIが自信満々に誤った回答を返してしまうと、かえって現場の信頼を損ないます。

内製型で始める、3つのステップ

私たちが社内ヘルプデスクの内製化を支援するときは、次の3段階で進めます。

第1段階は、対象カテゴリの選定です。全ての問い合わせを同時に対象にするのではなく、「頻度が高く、機密度が低い」カテゴリを1つ選びます。目安期間は1〜2週間、主担当は現場とAI-Pathの共同です。この段階でつまずく企業の多くは、対象を絞りきれずに「情シス業務全体」を選んでしまいます。まずは1つのカテゴリで十分です。

第2段階は、既存のFAQ・マニュアル・過去の回答ログを、そのままの形でデジタル化して蓄積することです。回答の仕方を変える必要はありません。目安期間は2〜4週間で、既存のExcelやチャットの過去ログをそのまま流し込む作業が中心になります。整形や標準化を急ぐと現場の負担が増えて協力が得られにくくなるため、私たちはあえて「まずは汚いデータのまま入れる」ことを推奨しています。

第3段階で、蓄積したデータをAIに検索させ、一次回答とエスカレーション動線を試験的に確認する運用を始めます。目安期間は4〜8週間で、AIが提示した回答案を担当者にレビューしてもらう運用が中心です。この順序を守る理由は、いきなり全カテゴリ共通の回答フォーマットに統一しようとすると、カテゴリごとの対応の勘所が失われてしまうためです。

この3段階の進め方は、私たちが製造業のバックオフィスAI内製化で提案している「1つの窓口業務から始める」考え方とも共通しています。総務の社内問い合わせ対応と、情シスのヘルプデスク対応は、どちらも「範囲を絞った窓口業務から着手する」という点で構造が似ています。

「最終エスカレーションは人間が行う」という譲れない一線

社内ヘルプデスクの内製化を提案すると、決まって出てくる質問があります。「問い合わせ対応を全てAIに任せてよいのか」というものです。私たちの答えは明確です。任せません。AIが担うのは定型的な一次回答と、既存マニュアルの検索・要約までです。人事考課や懲戒、規程の解釈が分かれる相談への最終判断は、担当者と管理者が行います。

冒頭で紹介したQC発表の報告は、私たちも考えさせられる事例です。技術的にコールを30%削減できても、その成果を社内が正しく評価するとは限りません。AIは効率化の道具であり、その成果を誰にどう見せるかという設計まで含めて、初めて仕組みとして定着すると私たちは考えています。

「自社の人事・給与情報が外部に漏れるのではないか」という懸念

もう一つ、社内ヘルプデスクならではの懸念があります。問い合わせの窓口には、給与・評価・懲戒といった機密性の高い相談も紛れ込みます。この情報が外部のクラウド基盤に流れれば、従業員のプライバシー侵害につながりかねません。

ある大手建材・シャッターメーカーの情報システム部長がいます。複数のAIシステムを別々に導入する方針について「最適なやり方とセキュリティ要件を見定めないと、正直、一時の投資になってしまう」と警戒していました。さらに「一社集中がいいのか、数社で組む方がいいのか、正直悩ましい」とも率直に語っていました。私たちの現場経験でも、この悩みは特別なものではありません。

SaaS型のAIヘルプデスクは多くの場合、ベンダーのクラウド基盤にこれらのデータを預ける形になります。私たちが提案する内製型のアプローチでは、自社のサーバーや閉域環境にデータを置いたまま分析する設計も選べます。硬いデータ(基幹システムの人事台帳)と柔らかいデータ(AIが活用する過去の問い合わせログ)を分けて整理する方法があります。基幹システムの横にデータ空間を設けてバッチでコピーする設計にすれば、AIはインフラを選ばず、オンプレでもクラウドでも、閉域環境でも動かせます。誰が・どの範囲の問い合わせ内容を見られるかを最初に決めておくことが、この領域ではとりわけ欠かせません。

私たちも自社で、問い合わせ対応の「一次受け」をAIに任せている

正直に言えば、この「AIに一次対応させ、人が最終判断する」という構造は、私たちAI-Path自身が社内で実践していることでもあります。自社プロダクトのAIPLA(業務アプリ・ナレッジ・AIエージェントをひとつの業務空間にまとめる基盤)があります。勤怠・経理・ナレッジといった業務データを統合し、社内からの定型的な問い合わせにAIがまず答える運用を回しています。判断が分かれる相談や、機密性の高い内容は、そのまま担当者にエスカレーションされる設計です。

本番への反映も、いきなり全社に展開するのではなく、先に一部の部門で試して回帰テストが通ってから広げるという二段階を徹底しています。トレーニング環境は背景色を変え、本番と一目で区別できるようにしているのも工夫の一つです。社内ヘルプデスクの内製化も、この考え方と構造は同じです。AIが一次対応を高速にこなし、人が最終的な判断を行う。私たちはこの役割分担を、自社の運用で日々実践しています。

SaaS・パッケージのままで良いケースもある、という正直な話

ここまで内製化の利点を述べてきましたが、誤解のないように言っておきたいことがあります。あるシステム部長は、自社で作った仕組みについて「スクラッチで作った方が使い勝手は間違いなくいい」と述べつつも、制度改定への追随負荷から、今ではほとんどの業務をパッケージに切り替えたと明かしていました。

社内ヘルプデスクも同じです。法改正や規程改定の頻度が高い領域、あるいは対象人数が少なく開発コストを回収しにくい領域は、内製よりもSaaSやパッケージに任せたほうが合理的な場合があります。私たちの経験では、内製化に向くのは「自社独自のルールが複雑に絡み、かつ問い合わせ頻度が高い」領域に限られます。ここを見誤ると、せっかく作った仕組みの保守コストが、SaaSの利用料を上回ってしまいかねません。

導入でつまずくポイントと私たちの対処

社内ヘルプデスクAIの導入には、技術面以外の壁もあります。私たちが現場で見てきた壁を整理すると、大きく3つに分かれます。

1つ目は、成果が評価されにくいという壁です。先述のQC発表の例のように、コール削減や対応時間短縮といった数字を出しても、社内で「すごい」と受け止められるとは限りません。私たちが顧客企業に提案しているのは、削減した時間を「誰の、どの業務の時間か」まで分解して報告し、その時間を次に何に使ったかまでセットで示すという方法です。数字だけでなく、浮いた時間の使い道まで示すことで、成果の実感が変わります。

2つ目は、ナレッジ整備の負荷が最初に集中することです。既存のFAQやマニュアルが整理されていない企業ほど、デジタル化の作業量が想定を超えて膨らみます。ある合成樹脂メーカーの業務担当者は、社内の原価表を「中身は7割くらいブラックボックス化していて、部材を一つ変えるにも全シートのセルを一個一個探して変える」と明かしていました。問い合わせ対応の根拠になるマニュアル類も、多くの企業で似た状態にあります。私たちの経験では、最初から全カテゴリを整備しようとせず、対象カテゴリを1つに絞り込むことが、この負荷を現実的な範囲に収める確実な方法です。

3つ目は、現場の抵抗感です。長年その窓口を担当してきた担当者ほど、「自分の対応ノウハウが可視化されることで役割が失われるのでは」という不安を持ちやすいものです。私たちが導入時に現場へ伝えているのは、この仕組みが個人評価のためではなく、対応ノウハウの継承のためのものだという運用方針です。経営層は「全社で使えるツール」を期待しがちですが、現場の担当者が見ているのは「自分の対応が楽になるかどうか」だけです。このズレを放置したまま仕組みを作っても、どんなに優れた設計であっても定着しません。

費用感——内製ならではのコスト構造

既存のFAQ・マニュアルをAIで整理・検索できる最小構成であれば、初期費用数十万円程度、月額数万円からという水準で始められます。先に触れたAIヘルプデスクSaaSの多くは、月額ライセンス費に加え、初期構築・既存データ取込・教育・継続運用という4つの隠れコストが積み上がります。全社員向けに一括導入する仕組みと、1つのカテゴリから問い合わせ対応を検索できるようにする仕組みでは、そもそも解決しようとしている課題の規模が違います。

ただし、違いは初期費用の大小だけではありません。SaaS型はライセンス数や利用部門数を広げるたびに追加費用が発生する設計になっていることがほとんどです。一方、内製で仕組みを作っておくと、1カテゴリで固めた回答ロジックを、2カテゴリ目・3カテゴリ目に展開する際の追加コストを抑えられます。正直に言えば、この差が効いてくるのは2カテゴリ目以降であり、1カテゴリだけで比べれば大手SaaSの機能のほうが充実している場面もあります。そこは率直にお伝えしておきたい点です。

もう一つのコスト構造は、開発の速さそのものです。私たちは自然言語でAIに指示を出すだけで、従来の10分の1程度のコストでオーダーメイドの仕組みを作る開発手法を用いています。動くプロトタイプをまず1日で作り、それを叩き台に現場と要望をすり合わせていくため、「思っていたのと違う」という手戻りが起きにくいのが特徴です。

ある樹脂成形機メーカーでは、FAQ回答と送客を兼ねる問い合わせAIをこの進め方で立ち上げ、リリース準備の段階まで進めています。全56画面の性能基盤も同時に刷新し、表示速度を10.6秒から3.4秒に改善したといいます。1つの仕組みを内製で作り込む過程で、周辺の基盤ごと整理できるのも、内製ならではの副次的な効果だと私たちは考えています。

よくある質問

Q1. 問い合わせ対応そのものをAIに任せられますか。 任せません。AIが担うのは定型的な一次回答と、既存マニュアルの検索・要約までです。最終的な判断は、担当者と管理者が行います。

Q2. 既存のAIヘルプデスクSaaSを使っている場合でも、内製化する意味はありますか。 あります。定型的なFAQ対応はSaaSに残したまま、自社特有のカテゴリ(独自の稟議フローや社内略語が絡む質問など)だけを内製で補うという組み合わせも可能です。役割を分けて考えることをお勧めします。

Q3. FAQやマニュアルがほとんど整理されていなくても対応できますか。 最初の試験運用では、比較的整理されているカテゴリから始めることをお勧めします。整備されていないカテゴリへの対応は、PoCの5パターンの1つとして別途検証が必要です。

Q4. 導入にはどのくらいの費用・期間がかかりますか。 1つのカテゴリから始める最小構成であれば、初期費用数十万円程度、1〜2ヶ月の試験運用から着手できます。最新の費用感は、無償の業務プロセス診断でご確認いただくのが確実です。

Q5. 情シスにAI専門人材がいなくても始められますか。 始められます。重要なのは専門知識よりも、日々の問い合わせ内容や回答を丁寧に残す現場の協力体制です。

Q6. 拠点ごとに規程が異なる場合でも展開できますか。 できます。ただし、最初から全拠点共通のルールに統一しようとせず、まず主要な拠点でルールを言語化し、「拠点ごとの差分」として管理できる設計にしておくと、展開がスムーズになります。

Q7. 法改正や規程改定が頻繁な領域でも内製化すべきですか。 慎重に判断すべきです。改定頻度が高い領域は、更新の手間が継続的にかかるため、SaaSやパッケージに任せたほうが合理的な場合があります。内製化は、自社独自のルールが絡み、かつ改定頻度が低い領域から検討することをお勧めします。

まず試すなら

1. 頻度が高い、または対応工数がかさんでいる問い合わせカテゴリを1つ選び出す
2. そのカテゴリの過去1年分のFAQ・回答ログを、そのままの形で1か所に集めてみる
3. 集めたデータのうち、どの判断が「担当者の経験」に依存しているかを棚卸しする

AI-Pathでは、無償の業務プロセス診断(BPR)を実施しています。社内ヘルプデスクのどこから内製化すべきか、まずは棚卸しからご相談ください。

筆者プロフィール

櫻井 文雄(さくらい ふみお) 株式会社AI-Path 代表取締役CEO

関西大学法学部法律学科卒業。財務コンサルティング会社(エフアンドエム)、外資系生保営業(Prudential)でコンサルティング営業の経験を積んだ後、起業し様々な企業のCTO/CMOを歴任。その後、デロイトトーマツコンサルティング(Big4)、ABEJA(AI研究開発の国内リーディングカンパニー)にて官公庁・製造業・金融業・小売業・不動産業を中心に延べ20社以上のDX推進や業務システム刷新をPM/SMとしてリード。利用者目線での現場の課題解決にフォーカスしたものづくりに拘り、導入ではなく「定着化」を目的とした伴走型のプロジェクト推進・システム導入を得意とする。2025年にAI駆動開発(VibeCoding)と出会い、より多くの人・企業に価値提供するためにAI-Pathを創業。

参考リンク

• マネーフォワードｉ、新サービス『Admina AIヘルプデスク』を2026年5月より提供開始予定(2026年4月6日)
• 社内AIヘルプデスク 正答率80%達成 RAG精度改善の軌跡