>
>
公開日
最終更新日
ヘルプデスクとは、利用者の問い合わせやITトラブルを受け付け、解決・復旧を支援する窓口です。社内の従業員に加え、製品を使う顧客や取引先も対象になります。
窓口を設けても、個人チャットへの直接連絡や担当者への業務集中が残ると、対応漏れや長期化を防げません。まず対象利用者、受付範囲、優先度、引継ぎ先を決め、どのチャネルから届いた依頼も同じ履歴に残します。
本記事は、社内外の問い合わせ窓口を新設・改善する担当者に向けた基礎ガイドです。基礎を知りたい場合は「ヘルプデスクとは」と職種比較の章、運用改善の担当者は業務内容と役割の章、生成AIや外部委託を検討している場合は生成AIの章と外部委託の選定基準の章から読み進められます。最後に、過去1か月のログを使った改善計画も示します。
ヘルプデスクは困りごとの解決と利用再開の支援を目的とし、コールセンターは電話を中心とした案内・受付・連絡の体制を指します。詳しくは「コールセンターとの違い」の節に比較表があります。
ヘルプデスクとは
ヘルプデスクとは、利用者からの問い合わせやITトラブルを受け付けて迅速な復旧を支援する窓口機能です。
本記事のポイント
ヘルプデスクは、社員・顧客・取引先などの困りごとを受け付け、解決と利用再開を支援します。
サービスデスクは単一の窓口機能を担い、組織設計により問題管理や変更管理を兼担する場合と分業する場合に分かれます。
新設時には対象利用者、受付範囲、優先度、専門担当への引継ぎ基準を決めます。
生成AIや外部委託を使う場合も、権限の承認とナレッジの管理責任を社内に残します。
英語のhelp deskは、支援や相談を受け付ける窓口を意味します。helpdeskと続けて表記する場合もあります。日本語の「ヘルプデスク」「ヘルプ デスク」は通常、同じ窓口を指しますが、担当範囲は組織ごとに異なります。
利用者が連絡先を探し回らずに済むよう、入口と責任範囲を明示します。IPAは『ITパスポート試験シラバス Ver.6.5』で、サービスデスクをサービス利用者に単一の窓口機能を提供する役割として整理しています。
ヘルプデスクの目的と基本機能
この窓口は、その場の困りごとを解消し、次に同じ問題が起きたときの対応を短くします。
主な機能は、受付、記録、切り分け、担当割当、進捗連絡、解決策の蓄積です。パスワードを忘れた利用者には、本人確認のうえで再設定手順を案内します。複数の利用者が同時にログインできなくなった場合は、個人の設定問題として処理せず、認証基盤の障害として調査担当へつなぎます。対応後には手順や発生条件を残し、同じ調査の繰り返しを減らします。
機能 | 担当者の作業 | 記録する情報 |
|---|---|---|
受付・記録 | 問い合わせをチケット化します | 依頼者、対象サービス、症状、受付時刻 |
切り分け・割当 | 影響範囲と対応先を判断します | 優先度、担当者、引継ぎ理由 |
進捗・解決管理 | 次の対応と連絡時刻を伝えます | 対応期限、暫定策、解決方法 |
ナレッジ化 | 再利用できる手順に編集します | 対象者、条件、更新日、責任部署 |
社内ヘルプデスクと社外ヘルプデスクの比較
社内向けは従業員の業務継続を支え、社外向けは顧客や取引先の利用継続を支えます。
比較項目 | 社内ヘルプデスク | 社外ヘルプデスク |
|---|---|---|
主な利用者 | 従業員、派遣社員、グループ会社 | 顧客、取引先、製品利用者 |
主な目的 | 業務停止の削減、IT利用の定着 | 利用再開、顧客満足、継続利用 |
問い合わせ例 | PC、ネットワーク、ID、SaaS、端末貸与 | 製品操作、不具合、サービス仕様、契約に関する案内 |
受付経路の例 | 社内ポータル、Microsoft Teams、Slack、電話 | 電話、メール、フォーム、Webチャット |
優先度の判断軸 | 業務影響、影響人数、セキュリティ影響 | 顧客影響、障害範囲、契約上の応答期限 |
社外向けでは、連絡者が契約者本人なのか、操作対象の権限を持っているのかを切り分けます。契約内容の案内と技術調査を別チームが担う場合も、利用者への連絡担当は明確にします。社内向けでは、端末やアカウントの管理情報と照合できる受付項目を設けます。
専門領域別のヘルプデスク
IT、人事、総務などの専門領域によって、回答に使う情報と引継ぎ先を分けます。
IT分野は端末・ネットワーク・業務アプリ、人事分野は勤怠・給与・休暇、総務分野は設備・備品・施設利用などを扱います。共通窓口へ集約する場合も、人事の個別情報と一般的な操作案内は同じ閲覧権限にしません。
サービスデスクの代表的な種類
サービスデスクの組織形態は、利用者との距離、受付の集約方法、時間帯の分担から整理できます。
ITILで用いられてきた代表的な区分に、ローカル、中央、バーチャル、フォロー・ザ・サンがあります。以下は組織設計を検討するための分類であり、製品機能の区分ではありません。拠点に担当者を置くか、遠隔で共同対応するか、時差を使って引き継ぐかによって、必要な管理手順が変わります。
種類 | 体制 | 採用を検討する条件 | 設計時の注意 |
|---|---|---|---|
ローカル | 利用拠点の近くに窓口を置きます | 現物確認や現地の業務知識を使う場合 | 拠点間で回答や記録の形式をそろえます |
中央 | 複数拠点の受付を中央窓口へ集約します | 共通サービスへの問い合わせをまとめる場合 | 現地作業の依頼先と連絡経路を残します |
バーチャル | 離れた担当者が共通基盤で一つの窓口として対応します | 遠隔勤務や複数拠点の担当者が共同対応する場合 | 担当割当、重複対応、閲覧権限を統一します |
フォロー・ザ・サン | 時差のある地域の窓口へ順次引き継ぎます | 各地域の勤務時間をつないで長時間対応する場合 | 引継ぎ言語、責任移管の時刻、未完了作業を定義します |
中央窓口が受付し、現地担当が端末交換を行う組み合わせも可能です。フォロー・ザ・サンを採用するなら、次の拠点が引き受けた時点で担当を変更し、未受領の案件が無担当にならない仕組みを用意します。組織形態を変える前に、利用者に見せる入口と内部の作業分担を別々に図示します。
▲ 社内ヘルプデスクと社外ヘルプデスクにおける対象や目的の違い
ヘルプデスクの業務内容と役割
問い合わせ対応からナレッジ更新までの循環プロセスを確立することで、トラブル対応の属人化を防ぎます。
基本の流れは、受付、切り分け、解決または引継ぎ、利用者への結果連絡、ナレッジ更新です。受付担当が変わっても次の作業を判断できるよう、症状だけでなく、試した操作とその結果まで記録します。問い合わせ関連の作業を集計するときも、この流れのどこに時間を使ったかを分けます。
問い合わせ対応
問い合わせ対応では、依頼者の説明をそのまま受け取らず、対象・発生条件・業務影響を具体化します。
「システムが使えない」という連絡なら、ログイン前か後か、ほかの利用者にも起きているか、代替手段があるかを尋ねます。エラー画面を添付してもらう際は、パスワードや顧客情報を隠す方法も案内します。電話やチャットからの依頼にもチケット番号を発行し、次の連絡先と時刻を伝えます。
受付項目 | 記録例 | 判断への使い方 |
|---|---|---|
発生時刻と対象 | 本日9時から販売管理のログイン画面で発生 | 変更作業や障害の時刻と照合します |
症状と再現条件 | 特定の端末でのみ認証エラーが出る | 端末、アカウント、サービスを切り分けます |
影響範囲 | 同じ拠点の利用者にも発生している | 個別対応か共通障害かを判断します |
業務影響と代替手段 | 受注処理が停止し、別端末でも処理できない | 優先度と緊急連絡先を決めます |
実施済みの操作 | 再ログインは実施済みで、状況は変わらない | 同じ確認を繰り返さず次の調査へ進みます |
障害の調査と分析
障害の調査では、端末固有の問題と共通障害を切り分け、業務分析では対応の滞留箇所を特定します。
同じサービスの認証エラーが短時間に増えた場合は、問い合わせを関連付けて共通の障害記録へまとめます。調査担当は、影響範囲、暫定回避策、次回報告時刻を記録します。一方、月次の業務可視化では、症状の原因とは別に、誰の確認待ちで止まったかを調べます。技術調査が長い案件と、承認待ちが長い案件では対策が異なります。
窓口業務を可視化する際は、まずログを一つに集め、件数と工数を比べてから滞留箇所を確認します。
受付ログの集約：過去1か月のメール、電話メモ、チャット、フォームを同じ一覧にまとめます。チケットID、受付日時、分類、担当者、実作業時間、待ち時間、解決区分をそろえ、同じ依頼の重複を除きます。
工数・頻度マトリクス分析：分類別の件数と平均実作業時間を集計し、件数×平均時間で総工数を算出します。頻度の高低と1件当たり工数の大小を組み合わせ、FAQ化する業務と専門調査を改善する業務を分けます。
ボトルネックの抽出：受付、割当、調査、承認、利用者確認の各段階で滞留時間を比べます。最も長い段階について、担当、改善策、実施期限、再測定日を決めます。
分析結果 | 考えられる原因 | 最初の対策 |
|---|---|---|
高頻度・短時間 | 同じ操作質問や定型申請が多い | 検索しやすいFAQや入力フォームを整備します |
高頻度・長時間 | 設定や申請手順が複雑で、毎回調査が発生する | 手順の標準化と業務システム側の改善を進めます |
低頻度・長時間 | 専門知識や外部ベンダーの調査を要する | 調査情報のテンプレートと専門担当への直通経路を用意します |
割当待ちが長い | 分類が曖昧で担当部署を決められない | 受付分類と担当割当ルールを修正します |
承認待ちが長い | 承認者不在や差戻しが多い | 代理承認者と申請時の必須情報を定義します |
実作業時間と解決までの経過時間は分けます。担当者の作業が短くても、利用者の返信待ちで解決まで数日かかる場合があるためです。月次集計では平均値に加えて中央値と長期化案件を並べます。記録がない項目は推測値で埋めず、翌月から取得する項目として設定します。
解決策の提示
解決策は、利用者が実行する手順、担当者が行う作業、実施を避ける操作に分けて伝えます。
再起動を案内するなら、未保存データを保存してから実施する順序を示します。リモート操作では、接続目的と作業範囲を説明し、利用者の同意を得ます。暫定回避策で業務が再開しても、根本原因の調査が残る場合は別の管理記録へつなぎます。「利用再開」と「恒久対策完了」を同じ状態にすると、再発防止の作業が埋もれます。
エスカレーション
エスカレーションは、技術難度、業務への影響、セキュリティ上の危険を基に判断します。
優先度の例 | 判断例 | 一次対応 | 引継ぎ先・条件 |
|---|---|---|---|
高 | 全社システム停止、情報漏えいの疑い、重要業務の停止 | 影響範囲を把握し、緊急連絡網へ連絡します | 障害・セキュリティ担当へ即時に引き継ぎます |
中 | 部門単位の利用不可、代替手段がない端末故障 | 暫定策を案内し、専門担当へ割り当てます | 一次窓口の対応範囲を超える場合に引き継ぎます |
低 | 通常の操作案内、一般的な設定相談 | FAQと手順書で解決を支援します | 手順で解消しない場合や繰り返し発生する場合に引き継ぎます |
この表は運用設計用の例です。自社の契約と事業継続計画に緊急基準があるなら、その基準を優先します。役職の高さだけで順序を変えず、停止している業務と代替手段の有無を記録します。引継ぎ時には、症状、影響、実施済みの操作、取得ログ、利用者への最終連絡を一組にして渡します。
ナレッジの作成と更新
ナレッジは、解決済みチケットから個人情報や案件固有の記述を除き、再利用できる手順に編集します。
利用者向けFAQには対象者、発生条件、操作手順、注意点、更新日、責任部署を記載します。担当者向けには調査コマンド、内部の連絡先、引継ぎ条件を別管理します。解決時に「既存FAQで解決」「FAQ修正が必要」「新規作成の候補」を選べるようにすると、日々の対応から更新候補を拾えます。
業務品質を測るKPI
業務品質は、応答の速さ、解決の確実さ、再発の減少を組み合わせて測ります。
一次回答時間：受付から最初の有効な案内までを測ります。自動受付通知は別に扱います。
解決時間：受付から解決までを測り、社内作業、外部調査、利用者待ちを分けます。
一次解決率：一次窓口で解決した件数を、対象となる問い合わせ件数で割ります。
再オープン率：解決済みの案件が同じ問題で再開した割合を追います。
自己解決の指標：FAQ閲覧後の起票率と、利用者が回答した解決率を併せて確認します。
分類別総工数：問い合わせ分類ごとの実作業時間を合計し、改善対象を選びます。
FAQ閲覧後に起票しなかった利用者が、必ず解決したとは限りません。問い合わせを諦めた場合も含むため、解決確認の回答や利用者満足と照合します。集計対象、営業時間の扱い、計測開始・終了時点を固定し、月ごとに同じ条件で比較します。
▲ 問い合わせ対応からナレッジ更新までの基本プロセス
ヘルプデスクと類似職種の違い
ヘルプデスクと類似職種は、対応の目的、対象利用者、技術調査の範囲、作業責任で区別します。
「ヘルプデスクは一次受付だけ」「サービスデスクなら高度な技術対応まで行う」と名称から決めると、契約や担当分担にずれが生じます。利用者に見せる窓口名と、内部の専門チームの役割は分けて整理します。まず比較表で全体像を把握し、受付から解決までの責任を割り当てます。
職種・機能 | 主な対象 | 主な目的 | 対応範囲の例 |
|---|---|---|---|
ヘルプデスク | 社員、顧客、取引先 | 問い合わせの解決、利用再開の支援 | 操作案内、IDロック、端末不具合、専門担当への引継ぎ |
サービスデスク | ITサービスの利用者 | 単一窓口での受付と依頼調整 | インシデント、サービス要求、進捗連絡、障害情報の周知 |
コールセンター | 顧客、見込み顧客、利用者 | 電話を中心とする案内・受付・連絡 | 注文、予約、契約案内、問い合わせ、発信業務 |
カスタマーサポート | 顧客 | 製品・サービスの利用支援と関係維持 | 請求、契約、利用相談、苦情への対応 |
テクニカルサポート | 顧客、社内担当者 | 専門的な技術課題の調査と解決 | ログ解析、再現試験、設定検証、開発部門との連携 |
IT運用チーム | システムやIT基盤 | 安定稼働の維持 | 監視、保守、バックアップ、復旧作業 |
コールセンターとの違い
コールセンターは主に電話を中心とした対応体制を指し、問い合わせの解決を担う機能とは見る軸が異なります。
両者は別々の軸なので、コールセンターの中に技術的なヘルプデスクを置く場合があります。反対に、フォームとチャットだけで技術窓口を運営する場合もあります。技術的トラブルを扱うかどうかは「コールセンター」という名称では決まらず、契約と対応業務で決まります。
比較軸 | ヘルプデスク | コールセンター |
|---|---|---|
対応の目的 | 困りごとの解決と利用再開を支援します | 案内、注文、予約、相談、連絡などを受発信します |
対象 | 社内の利用者と社外の顧客・取引先です | 業務によって顧客、見込み顧客、利用者などです |
技術的トラブル | 切り分けや解決支援を対応範囲に含めます | 技術窓口として設計した場合に扱います |
対応チャネル | 電話、メール、フォーム、チャット、遠隔操作などです | 電話が中心です。複数チャネルを統合する体制はコンタクトセンターと呼びます |
評価指標の例 | 解決時間、一次解決率、再発率です | 応答率、待ち時間、放棄呼率、対応品質です |
委託する場合は、「電話を受ける業務」なのか、「技術的に切り分けて解決する業務」なのかを分けて見積条件にします。受付件数が同じでも、台本で案内する案件と、ログを取得して原因を調べる案件では必要な担当スキルが異なります。
サービスデスクとの違い
サービスデスクは、ITサービスの利用者と提供者をつなぐSPOC、つまり単一の窓口として受付と連絡を担います。
ヘルプデスクは個々の困りごとの解決に焦点を当て、サービスデスクはインシデントやサービス要求を受け付けて関係チームとの調整まで担う設計に向いています。サービスデスクの業務内容には、障害情報の周知、申請状況の連絡、未解決案件の追跡も含めます。ただし、実際の呼称と範囲は組織の規程で定義します。
ITILでは、問題管理は繰り返す障害の原因と再発防止を扱い、変更管理に相当する変更イネーブルメントは変更リスクや承認を扱います。窓口がこれらを兼担するなら、通常受付と専門判断の担当時間を分けます。分業するなら、窓口が関連チケットを集め、専門担当が原因分析や変更判断を担うように引継ぎ条件を定めます。
カスタマーサポートとの違い
カスタマーサポートは顧客の利用全般を支え、操作や不具合などの具体的な問題解決は技術窓口が担います。
SaaSでは、契約変更や請求の相談をカスタマーサポート、ログインや基本操作をヘルプデスク、APIエラーや詳細なログ解析をテクニカルサポートへ振り分ける設計ができます。利用者には窓口を一本化し、裏側で担当を変えます。引継ぎ時に同じ説明を求めないよう、履歴と添付資料を共有します。
サポートデスクとの違い
サポートデスクは、ヘルプデスクとほぼ同じ意味で使う場合も、より広い相談窓口を指す場合もあります。
委託契約や社内規程では、名称よりも対象サービス、受付時間、解決まで担う範囲、対象外の作業を列挙します。「操作案内は行うがデータ修復は行わない」など、境界を具体化します。緊急案件だけ別経路にする場合は、通常窓口からもその経路へ案内できる状態にします。
保守部門との違い
保守部門は製品や設備の維持・修理を行い、窓口側は利用者の困りごとを受け付けて作業につなぎます。
PCが故障した場合、ヘルプデスクは症状と業務影響を確認し、代替機の要否を判断します。保守部門やベンダーは部品交換や修理を担当します。私物端末や非承認ソフトウェアまで対応すると作業範囲が際限なく広がるため、対象外の依頼には案内可能な範囲と代替の相談先を示します。
担当者に必要なスキルとキャリアの接点
ヘルプデスク担当者には、聞き取り、ITの基礎知識、記録、優先度判断、説明のスキルを組み合わせます。
初任者には受付テンプレートと既知の解決手順を用意し、権限変更や未知の障害は専門担当へ渡す範囲から任せます。調査を担う段階では端末・認証・ネットワークの知識を、管理者には品質指標とナレッジ運用を学ぶ機会を設けます。キャリアを検討する場合は、現在の担当が受付中心か技術調査中心かを棚卸しし、次に担当したい職務との差を具体化します。
▶ 関連記事: サポートデスクとは？ヘルプデスクとの違いや役割・運用法を解説
生成AIおよびITツールによる業務効率化
自動化は、まず回答案の作成から始めます。権限変更やアカウント操作は、承認と監査ログを確認できる処理に限ります。
最初に自動化する対象は、問い合わせの分類、過去事例の検索、回答案の作成、会話の要約などです。利用者に直接回答する段階やシステムを操作する段階へ進む前に、人が修正した理由と例外案件を集めます。既存の手順が曖昧なままAIへ渡すと、担当者ごとの判断のばらつきまで自動化してしまいます。
チケット管理ツール
チケット管理ツールは、個人のメールやチャットに埋もれた依頼を、担当・期限・履歴のある共有作業へ変えます。
導入時には、メール、フォーム、チャット、電話から届いた内容を同じ管理単位にそろえます。利用者が同じ案件について電話とメールで連絡した場合は、既存チケットに追加するルールを設けます。担当変更のたびに新しいチケットを作ると、解決までの全体時間が分断されるため、内部の作業依頼と利用者の問い合わせを関連付けます。
製品選定では、受付の一元化だけで足りるのか、資産情報や変更作業まで扱うのかを先に決めます。ZendeskのITSMツール解説では、ITSMツールをサービスデスク運用、インシデント管理、変更管理、資産追跡を一元化する専用ソリューションとして整理しています。問い合わせ管理とITサービス全体の管理は、評価する範囲を分けます。
評価する軸 | 試験時の確認方法 | 運用の判断 |
|---|---|---|
受付の集約 | メール、電話メモ、チャットを同じ案件へ集約します | 連携できない経路には手動記録の担当を置きます |
担当割当・期限 | 分類別の割当と期限超過通知を試します | 例外が多い分類は自動割当前に整理します |
情報の分離 | 人事、顧客情報、通常の操作相談で閲覧者を分けます | 分離できない領域は別の管理場所に残します |
履歴の取得 | チケット、添付、変更履歴を出力します | 必要な履歴を取り出せる範囲で移行します |
集計 | 分類別の件数、時間、滞留状態を再現します | 不足する項目は入力項目か外部集計で補います |
FAQとナレッジベース
FAQは利用者の自己解決に、担当者向けナレッジは調査と引継ぎの標準化に使います。
FAQの見出しは製品の正式な機能名だけにせず、利用者が入力する表現を含めます。「認証情報の更新」だけでなく「パスワードを変更したい」などの言葉で探せるようにします。Helpfeelなどの検索型ヘルプデスクを検討する場合も、検索できなかった言葉、閲覧後に起票された内容、更新にかかる作業を測ります。記事を増やす前に、頻出テーマの不足や重複を直します。
利用者に公開する文章へ管理者用の復旧手順や内部の接続情報を混在させません。FAQには誰が実施できる手順なのかを明示します。画面の変更時には、該当するFAQを更新対象として作業計画へ入れ、システム側のリリースだけで完了にしない運用にします。
生成AIによる回答支援
生成AIによる回答支援は、承認済み文書を検索し、根拠を示した回答案を担当者へ返す範囲から始めます。
担当者は対象利用者、根拠文書の更新日、実施してよい操作を確認して送信します。評価用の質問は、頻出する質問、条件によって答えが変わる質問、回答できない質問、緊急時の質問に分けます。正答率だけでなく、根拠を付けた割合と、答えられないときに有人対応へ切り替えた割合を記録します。
過去チケットを検索対象にする場合、古い回避策や個人情報を含む記録をそのまま取り込みません。現在も使える手順へ編集した文書を優先します。回答の元になった文書と利用者が閲覧できる文書が一致しない構成では、検索結果から情報が漏れる可能性があるため、権限を継承する仕組みがない領域は対象外にします。
AIエージェントの統制
AIエージェントの操作範囲は、本人確認、最小権限、承認、監査ログ、復旧手順を満たした処理に限定します。
パスワードリセットでは、依頼者が本人か、対象アカウントが正しいか、再設定の送信先が安全かを照合します。依頼文に「管理者として処理して」と書かれていても、実行権限を広げない構成にします。検索した文書や問い合わせ文の中の命令で操作範囲が変わらないよう、検索対象の文章と実行ポリシーを分離します。
統制項目 | 確認内容 | 判断 |
|---|---|---|
本人確認 | 認証済みIDと対象アカウントを照合できるか | 照合できれば定型処理の対象にし、できなければ有人確認へ回します |
最小権限 | 起票、照会、リセットなどの操作を限定できるか | 限定できれば検証し、包括的な管理者権限しか渡せなければ自動実行しません |
承認フロー | 高リスク操作で上長や所有者の承認を挟めるか | 承認を組み込めれば対象を広げ、組み込めなければ回答支援にとどめます |
監査ログ | 依頼者、対象、承認者、実行内容、結果を追跡できるか | 追跡できれば限定運用へ進み、できなければ操作を自動化しません |
ロールバック | 誤った設定変更や権限付与を戻せるか | 復旧手順と担当が決まった操作だけを対象にします |
異常な件数の連続実行や、通常と異なる対象への操作を検知したら停止する条件も定めます。停止後は共通窓口へ戻し、未処理の依頼を人が引き継ぎます。復旧の判断者と再開条件を決めずに自動処理を広げると、障害時に利用者の依頼が行き場を失います。
対象範囲と試験運用の設計
AIとITツールは、最初から全社へ広げません。対象利用者と扱う文書、実行する操作、試験期間を限定して検証します。
契約上のデータ利用条件、保存場所、保持期間、権限継承、ログ出力を一つの要件表にまとめます。要件を満たすなら限定した利用者で試験し、満たさない領域は公開済みFAQの検索や要約にとどめます。料金比較は担当者ID数、AIの利用量、連携、資産管理、初期設定、保守を同じ条件にそろえ、非公開の料金は要問合せとして扱います。
試験前には従来の処理時間と回答品質を測り、試験中はAIの回答を修正した時間も記録します。送信前の確認に長時間かかるなら、回答対象を狭めるか文書を修正します。処理件数だけが増えても、誤回答の訂正や例外処理が増えている場合は、自動回答への移行を止めて回答支援を続けます。
対応チャネルと外部委託の選定基準
対応チャネルと外部委託は、緊急性、業務知識、情報の機密性、必要な受付時間を基に選びます。
入口を増やすほど、どこから連絡するかという利用者の迷いと、記録を統合する担当者の作業が増えます。通常依頼の入口と緊急時の入口を分け、それぞれの受付時間と用途を明記します。窓口業務を外部から調達する場合も、まず自社が提供する窓口の範囲を定義してから委託対象を切り出します。
電話対応
電話は、その場で状況を聞き取る必要がある障害や、文章での説明が難しい利用者への対応に使います。
ただし、通話が終わるまで担当者が占有され、記録を残さなければ後から分析できません。通話後にはチケットを作り、症状、案内、保留事項、次回連絡時刻を残します。PKSHA TechnologyのOsaka Metroデジタル推進部に関する紹介事例は、電話に集まる問い合わせを見直す例です。自社では電話でしか解決できない案件と、FAQやフォームへ移せる案件を分けます。
メールとフォーム対応
メールとフォームは、証跡を残して非同期で対応する問い合わせに向きます。
フォームでは対象サービス、発生時刻、症状、利用端末、業務影響を取得します。必須項目を増やしすぎると入力を諦める利用者が出るため、最初は割当と初動判断に使う情報に絞ります。受付完了画面と自動返信には、受付番号、回答の目安、緊急時の連絡方法を示します。通常フォームへ緊急障害を入力した場合も、一次受付で緊急経路へ移せるようにします。
チャットとリモート対応
チャットは短い確認の往復に、リモート対応は実際の画面や設定を調べる作業に使います。
個人宛てのメッセージだけで解決した案件も、件名と解決区分を共通台帳へ残します。画面共有では、不要なアプリを閉じてもらい、接続対象、操作内容、終了方法を伝えます。利用者の認証情報を聞き出して代理入力する手順にはしません。接続終了後は、実施した変更と利用者による動作確認の結果をチケットへ記録します。
依頼の状態 | 主な受付経路 | 補完する手段 |
|---|---|---|
全体障害や漏えいの疑いがある | 緊急電話、専用の緊急連絡経路 | チケットと一斉周知で状況を共有します |
通常の操作質問や申請 | フォーム、ポータル、メール | FAQと受付番号で進捗を案内します |
追加の聞き取りが必要 | チャット、電話 | 会話を元のチケットへ追記します |
画面や設定の確認が必要 | 同意を得たリモート対応 | 変更内容と確認結果を記録します |
アウトソーシングとBPO
BPOは、受付や定型処理を外部へ委託し、手順整備や品質管理まで含めて分担する選択肢です。
IT Leadersは、キヤノンマーケティングジャパンの2026年版調査について、中堅企業の社内ヘルプデスク業務の外部委託率が86.5％で、全体委託32.4％、部分委託54.1％だったと報じています。前年の74.0％からは12.5ポイント増えています。同記事が扱う対象は中堅企業の情報システム部門であり、社外向けの窓口全体へそのまま当てはめる数値ではありません。
全体を委託するか部分委託にするかは、手順の安定度と例外判断の量で決めます。一次受付、FAQ案内、定型申請の起票は切り出しやすい一方、事業停止の判断、特権IDの承認、社内制度の例外判断は責任者を社内に置きます。夜間だけ外部へ任せる場合も、夜間に判断できる範囲と翌営業日へ持ち越す条件を明記します。
委託範囲と責任分界
委託範囲は、作業単位ごとに実施者、承認者、最終責任者を割り当てます。
アカウント発行なら、委託先が申請内容を点検し、社内の所有者が承認し、定義済み手順で発行するように分けます。障害対応なら、受付と一次切り分けを外部、サービス停止や顧客周知の判断を社内に残す設計ができます。例外が発生したときの連絡先と応答期限を決め、窓口が判断待ちのまま止まらないようにします。
業務 | 委託先の担当例 | 社内に残す判断 |
|---|---|---|
一次受付 | 本人確認、チケット作成、定型の切り分け | 対象サービスと優先度基準の決定 |
FAQ案内 | 承認済み手順の案内、改善候補の報告 | 内容の承認、公開範囲、更新責任 |
アカウント操作 | 承認後の定型作業と結果記録 | 権限付与の承認、例外判断 |
重大障害 | 受付、情報収集、緊急連絡 | 事業影響の判断、対外説明、復旧方針 |
委託先評価の確認項目
委託先は、費用、対応品質、情報管理、契約終了時の移行条件を同じ評価表で比較します。
受付時間、祝日対応、対応言語、電話・メール・チャットの対応範囲
対象業務、対象端末、対象サービス、対応拠点、現地作業の有無
一次回答時間、解決時間、緊急連絡時間の定義と測定方法
担当者教育、手順変更時の研修、品質レビュー、欠員時の代替体制
個人情報と機密情報の閲覧権限、再委託、接続環境、監査ログ
対応履歴とナレッジの所有権、出力形式、終了時の引渡しとデータ削除
件数超過、対応時間延長、追加作業、移行支援の費用条件
障害時の連絡網、責任分界、月次報告、改善提案の担当
履歴を自社で取得でき、社内にナレッジの承認者を置けるなら、委託後も改善を続けられます。履歴を渡せない契約なら、自社のチケット基盤へ記録する条件に変えてから開始します。単価が安くても、調査のやり直しや社内への差戻しが多い場合は、社内の残作業を加えた総工数で評価します。
▲ 依頼の状態に応じた最適な受付チャネルの分岐フロー
ヘルプデスク運用で起こる失敗パターン
ヘルプデスクの負荷が減らないときは、人員やツールを増やす前に、受付の抜けと責任分担の曖昧さを直します。
個人チャットへの依頼を記録しない、FAQを更新しない、解決時間だけを評価するといった運用は、導入する製品が変わっても残ります。失敗を避けるには、担当者の注意に頼るのではなく、受付経路、入力項目、権限、定例レビューに対処策を組み込みます。
個人チャットへの依存
個人チャットに依頼が集まると、担当者の不在で対応が止まり、集計上の件数と実際の負荷がずれます。
共通窓口への誘導文を用意し、担当者はDMで受けた依頼をそのまま処理せず、チケット番号を発行します。役員や特定部門からの依頼も記録対象にします。急ぎの対応で後から記録する場合は、当日中に残す担当を決めます。入口を統一した後も、利用者が入力しづらいフォームになっていないかを調べ、直接連絡に戻る理由を取り除きます。
FAQの放置と更新漏れ
古いFAQは、利用者を誤った操作へ誘導し、AIが参照する回答の品質も下げます。
FAQごとに責任部署、更新日、見直し期限を設定し、制度やシステムの変更時に更新担当へ通知します。毎月は起票につながったFAQと検索で見つからなかった語を確認し、定期点検では閲覧されない記事の統合や削除も行います。修正前の版を残しておくと、過去の回答に使われた手順を追跡できます。
AIへの過剰な権限付与
AIへ包括的な管理者権限を渡すと、誤った判断が複数のアカウントや設定へ波及します。
やってはいけないのは、問い合わせ文だけを根拠にアカウント削除や権限付与を自動実行する設計です。AIは申請内容の整理や起票までにとどめ、承認後に定義済みの処理を実行します。異常を検知したときには自動処理を停止し、担当者が処理結果と対象範囲を調べる手順へ切り替えます。
対応速度だけに偏った評価
解決時間だけで評価すると、未解決のまま閉じる案件や、他部署へ早く渡す案件が増えるおそれがあります。
一次回答時間と解決時間に、再オープン率、利用者満足、再発件数を組み合わせます。難しい案件を扱った担当者が不利にならないよう、分類と難度を分けて比較します。件数が減った月も、自己解決が進んだのか、利用者が問い合わせを諦めたのかを区別し、未解決の声や業務停止の状況と照合します。
自動化と有人対応の分断
自動応答で解決しなかった利用者が、有人窓口で最初から説明し直す構成は避けます。
TechTarget Japanは、キヤノンマーケティングジャパンの2026年版調査の紹介で、外部委託を実施・検討する企業が重視する条件の首位を自動化と有人対応を組み合わせたハイブリッド運用の58.7％としています。AIから人へ渡す際には、会話履歴、参照したFAQ、実施済み手順、利用者が困っている点を引き継ぎます。有人窓口の受付時間外なら、起票と次回連絡の目安を提示します。
導入前後の運用チェックリスト
導入前後は、受付から改善までを一続きに点検し、未整備の項目に応じて開始範囲を狭めます。
すべての受付チャネルでチケットを作成でき、電話と口頭依頼も集計対象になっています。
影響範囲と緊急度から優先度を決める基準があります。
一次窓口、専門担当、承認者、最終責任者を区別しています。
引継ぎ時に、実施済みの調査と利用者への最終連絡を渡せます。
FAQに責任部署、更新日、公開範囲、見直し期限を設定しています。
個人情報や機密情報を含むチケットの閲覧者を限定しています。
AIが参照する文書、実行できる操作、停止条件を定義しています。
委託先を含む対応履歴と監査ログを自社で取得できます。
月次で件数、総工数、解決時間、再オープン率を比較できます。
問い合わせ上位の分類について、改善担当と期限を決めています。
FAQの責任者が決まらない場合は、対象テーマを絞って担当部署と合意してから公開します。ログを取得できない自動処理は使わず、回答案の作成だけに限定します。すべてを一度に導入するより、記録と引継ぎが成立する小さな範囲で開始し、月次の結果から広げます。
▶ 関連記事: 情シスの社内問い合わせ工数削減｜属人化を防ぐツール比較
国内企業の導入事例と効果の読み解き方
国内企業の導入効果は、対象業務と測定単位をそろえ、自社の件数・定型比率・対応時間へ置き換えて試算します。
以下の成果は各提供企業の公表内容です。問い合わせ件数、処理時間、FAQ運用工数はそれぞれ異なる指標なので、削減率の大小だけでは比較しません。比較期間、対象チャネル、同時に実施した窓口集約や手順整備を一度整理し、自社で再現する施策と測る指標を決めます。
数値を伴う国内企業の導入事例
検索による自己解決の促進と、チケット管理による処理時間の短縮は、別々の効果として評価します。
企業・業種と規模 | 導入・公表時期 | 課題と施策 | 公表された成果 | 自社で測る指標 |
|---|---|---|---|---|
NTTデータMSE／IT・ソフトウェア開発、社員2,000人が利用可能 | 2025年の公表事例 | 社内情報の検索と問い合わせ対応に対し、HelpfeelのAIヘルプデスクを構築しました | Helpfeelは、問い合わせ対応やFAQ運用の工数を最大70％削減と公表しています | 検索利用と対応・更新の総工数 |
パーソルプロセス＆テクノロジー／従業員約4,600人に3人のデスクで対応 | 2022年の公表事例（導入後1か月の測定） | 従業員からの問い合わせを受けるコンシェルジュデスクにHelpfeelを導入しました | Helpfeelの導入事例では、1か月で問い合わせ件数率が約25％減少しています | 対象者数をそろえた問い合わせ率 |
ベイシアグループソリューションズ／小売グループのIT、約4万7,000人規模に5人で対応 | 導入前後の比較 | 問い合わせ対応にServiceNowを導入し、処理を効率化しました | ServiceNowの事例では、1件当たりの処理時間を約15分から約5分へ短縮しています | 1件当たり実作業時間と月間総工数 |
NTTデータMSEの「最大70％」を、すべての問い合わせが同じ割合で減る数値として扱わないようにします。Helpfeelが公表したパーソルプロセス＆テクノロジーでの約25％の減少も、従業員数の違いを踏まえず総件数の減少として読まないようにします。ベイシアグループソリューションズの処理時間は、受付から解決までの経過時間ではなく、自社が比較する作業範囲に合わせて読み替えます。
窓口集約と定型対応の国内事例
数値による比較とは別に、問い合わせの入口と担当割当を変えた施策も自社の設計に使えます。
企業・対象業務 | 発信元と施策 | 公表内容の要点 | 運用へ取り入れる作業 |
|---|---|---|---|
株式会社リベロ／社宅代行業務の問い合わせ | Re:lationを提供するインゲージは、Re:lationで問い合わせ対応を集約した事例を公表しています（インゲージのプレスリリース） | 複数のやり取りをまとめ、問い合わせ対応の工数を削減しています | 履歴と担当割当を共有し、未対応を把握します |
株式会社デンソー／問い合わせ対応業務 | 日立ソリューションズは、ServiceNowの導入を支援した事例を紹介しています（日立ソリューションズの導入事例） | 1件当たりの対応時間短縮と月間の削減見込みを扱っています | 件数と処理時間を分けて導入前後を測ります |
三井不動産リアルティ／社内問い合わせ窓口 | PKSHA Technologyは、PKSHA AI ヘルプデスクによる窓口一本化の事例を紹介しています（IT Leadersの記事） | 定型質問への自動応答を実現しています | 共通窓口を作り、自動対応と有人対応の境界を定めます |
窓口集約では、メール、電話、チャットの同じ相談を重複して数えない利用者識別とチケット統合のルールを先に決めます。自動応答では、回答できなかった内容が有人側へ引き継がれるかを試します。ツール名を合わせるより、自社で残っている受付の分散や引継ぎの欠落に対応する施策を選びます。
事例の数値を自社試算へ置き換える方法
定型問い合わせに使う時間は、月間件数×定型比率×1件当たり対応時間で算出します。
定型対応工数＝月間問い合わせ件数×定型問い合わせの割合×平均実作業時間
試算例として、月間1,000件、定型比率30％、平均対応時間8分と仮定します。定型対応は1,000件×30％×8分＝2,400分で、月40時間です。その半分を自己解決や自動処理へ移せた場合の削減候補は月20時間になります。これは計算方法を示す仮定であり、企業の実績値ではありません。
試算の項目 | 計算例 | 使い方 |
|---|---|---|
定型対応の総工数 | 1,000件×30％×8分＝40時間 | 改善対象の上限となる作業量を把握します |
自己解決へ移す工数 | 40時間×50％＝20時間 | 限定試験で移行できる割合を測ります |
維持工数 | FAQ更新、回答レビュー、例外対応、監視を実測します | 導入後にも残る作業を加えます |
差引の削減工数 | 20時間－実測した維持工数 | 他業務へ振り向けられる時間を見積もります |
費用換算する場合は、差引の削減時間に自社で定めた時間単価を掛け、利用料と初期設定費用を別に並べます。削減した時間がそのまま人件費の削減になるとは限りません。担当者がセキュリティ点検や再発防止へ使うなら、振替先の作業量と完了状況も報告します。
導入効果の評価期間
導入前後を比べるときは、繁忙期や制度変更の影響を除外します。開始直後の問い合わせ増加も、通常運用の数値とは分けて記録します。
導入初月は利用方法の質問や入力の不慣れによって、問い合わせが増える場合があります。制度変更、入退社、大規模更新が重なった月は通常月と分けます。全体件数に加えて分類別件数、実作業時間、解決までの時間、利用者満足を並べると、電話が減ってチャットへ移っただけなのか、問い合わせ自体が減ったのかを判別できます。
試験の対象外となるチームや分類があるなら、その変化も比較します。全社的な業務量減少をツールの効果に含めないためです。期間終了時には、継続する施策、修正する手順、停止する自動化を決め、次の測定条件を固定します。
ヘルプデスク体制最適化に向けた取り組み
体制を見直すなら、最初に問い合わせログを集めます。そのうえで、定型対応と専門判断が必要な対応を分けます。
新しいツールや委託先を決める前に、過去1か月の問い合わせを分類し、最も時間を使っているテーマを一つ選びます。社内向けでも社外向けでも、最初にそろえる項目は受付範囲、記録、優先度、担当、引継ぎ条件です。既存の運用をすべて置き換えず、選んだテーマで効果を測ってから対象を広げます。
新設時の最小構成
新設時は、共通の入口、共有台帳、優先度基準、専門担当への連絡先を先に用意します。
専用ツールの導入前でも、閲覧権限を設定できる共有台帳で受付と担当を管理できます。ただし、個人情報や機密情報を含む内容は、必要な担当者だけが見られる場所へ分離します。受付時間外の連絡、対象外の依頼、担当者が不在のときの代理を決め、窓口の案内と内部手順に同じ内容を記載します。
最初に用意するもの | 記載する内容 | 運用開始の条件 |
|---|---|---|
窓口案内 | 対象者、対象サービス、受付時間、緊急時の経路 | 利用者が通常と緊急の入口を区別できます |
受付台帳 | ID、分類、影響、担当、期限、状態、解決方法 | 担当者が不在でも経緯を追えます |
優先度基準 | 影響人数、停止業務、代替手段、セキュリティ影響 | 受付担当が同じ条件で初動を決められます |
引継ぎ表 | 専門担当、承認者、連絡方法、代理、応答期限 | 範囲外の案件を無担当にせず渡せます |
過去1か月のログを使う改善タイムライン
明日からの改善は、ログ収集、分類、対策実施、再測定の順に進めます。
時期 | 主な担当 | 実施する作業 | 成果物と次の判断 |
|---|---|---|---|
明日 | 窓口責任者と各受付担当 | 過去1か月のメール、電話、チャット、フォームの記録を集めます | 未記録の経路と重複を洗い出し、収集対象を確定します |
最初の週 | 運用担当 | 分類、影響、対応時間、最終担当者、解決区分をそろえます | 件数と総工数の一覧を作り、対象テーマを一つ選びます |
翌週 | 窓口責任者と専門担当 | 定型作業と専門判断を仕分け、滞留の原因を調べます | FAQ化、フォーム修正、承認経路変更のどれを行うか決めます |
その後の試験期間 | テーマの担当部署 | 対象利用者を絞って改善策を試し、例外と維持工数を記録します | 誤案内や負荷増があれば範囲を狭め、手順を修正します |
月次レビュー | 窓口責任者とサービス所有者 | 件数、総工数、待ち時間、再オープン、満足度を比較します | 継続、修正、停止、対象拡大を決定します |
対応時間が過去の記録にない場合は、全件を推定せず、選んだ分類から実測を始めます。電話や口頭依頼が多い場合は、最初の週に記録を増やすだけでも受付件数が増えます。その増加は負荷の悪化と即断せず、従来見えていなかった作業が記録された分として区別します。
改善テーマの選定基準
最初の改善対象は、総工数が大きく、手順と責任者を決められるテーマから選びます。
高頻度で短時間の案件ならFAQやフォーム、高頻度で長時間の案件なら手順やシステム側の改善を検討します。件数が少なくても、漏えいや事業停止につながる案件は安全性を優先して別枠で対処します。対応工数の削減だけで優先順位を決めず、誤処理の影響と再発時の損失も評価表へ加えます。
改善候補が多数あるときは、担当部署が明確で、変更の影響範囲を限定でき、導入前後を測れるものを選びます。権限変更を伴う自動化の前に、申請項目の不足や承認経路の迂回を直せる場合もあります。大きなシステム変更を待たずに解消できる滞留から着手します。
役割分担と月次レビュー
窓口責任者は受付品質を、専門担当は原因調査を、サービス所有者は変更と改善の判断を担います。
同じ人が複数の役割を兼ねる場合も、どの立場で承認したかを記録します。月次レビューでは、すべての案件を読み上げるのではなく、件数上位、総工数上位、長期滞留、再発、重大な誤案内を抽出します。各テーマに担当者と完了予定日を付け、前月に決めた対策の結果から確認します。
外部委託やAIの運用を加えた後も、改善テーマを決める場は社内に残します。問い合わせログからサービス側の不具合や分かりにくい申請を見つけたら、窓口の回答を増やすだけで終えず、原因となる画面、手順、制度の担当へ改修を依頼します。窓口が処理を抱え続けないよう、対応と再発防止を別々の期限で管理します。
まとめ
ヘルプデスク運用の定着に向けた第一歩
ヘルプデスクの改善は、受付範囲を決め、問い合わせの記録をそろえるところから始めます。サービスデスクやコールセンターとの名称の違いより、誰が受け付け、調査し、承認するかを明確にします。
明日は過去1か月のログを集め、内容・影響・対応時間・最終担当者で分類します。総工数が大きいテーマを一つ選び、定型作業はFAQや回答支援へ、専門判断は担当部署へ分けます。月次で待ち時間と再発を測り、結果に応じてAIや外部委託の範囲を広げます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
