--- title: "ITヘルプデスクの仕組みを作る：受付窓口・チケット管理・ナレッジ化の設計手順" url: "https://www.issoh.co.jp/column/details/18291/" published: 2026-10-12 updated: 2026-10-12 categories: ["DX"] publisher: "株式会社一創" --- # ITヘルプデスクの仕組みを作る：受付窓口・チケット管理・ナレッジ化の設計手順 ITヘルプデスクに寄せられる問い合わせは、パスワードのロック、PCの不調、SaaSのアカウント発行、権限の申請といった、IT部門でなければ答えられない内容に偏ります。担当者がメールとチャットと口頭で個別に受けていると、件数が増えた時点で「誰が何を抱えているか」が見えなくなり、同じ質問に毎回ゼロから答えることになりがちです。この記事では、情報システム部門のITヘルプデスクを、受付チャネルの一本化、インシデントとサービス要求を分けるチケット管理、優先度とSLAの決め方、解決内容をその場で記事にするナレッジ化の順に、設計の手順として整理します。ヘルプデスクという業務の定義やサービスデスクとの呼称の違いから確認したい場合は、[ヘルプデスクの仕事内容と種類を解説した記事](https://www.issoh.co.jp/column/details/13555/)を先にご覧ください。 ## まとめ：ITヘルプデスクは受付・チケット・ナレッジの三工程を一本の流れで組む ITヘルプデスクの仕組みは、問い合わせを「受ける」「記録して流す」「答えを残す」の三工程に分けて設計すると組み立てやすくなります。受付で優先するのは、チャネルを増やすことより、どの経路から来ても同じチケットに落ちる仕組みです。チケット管理では、壊れたものを直すインシデントと、新しく何かを用意するサービス要求を最初に分け、優先度は影響範囲と緊急度の掛け合わせで機械的に決めます。SLAは「最初の応答まで」と「解決まで」の二本から始め、営業時間のカレンダーを付けて測るのが現実的です。 ナレッジ化は、対応が終わってから別の担当者がまとめる方式では続きません。解決した担当者がその場で、問題・環境・解決策の型に沿って短い記事を残す運用に切り替えます。パスワードリセットのように件数が多く手順が決まっている依頼は、記事化より先にセルフサービス化を検討してください。逆に、問い合わせが月に数十件程度で担当者が一人なら、専用のITサービス管理ツールを入れる前に、共有の受付フォームと一覧表で流れを固めるほうが早く効果が出ます。 ## ITヘルプデスクが受ける問い合わせの範囲と一般のヘルプデスクとの違い 同じ「ヘルプデスク」でも、人事や総務の窓口とITの窓口では、問い合わせの性質が違います。仕組みを作る前に、何を受ける窓口なのかを決めておきます。 ### アカウント・端末・ネットワーク・SaaSの四領域に問い合わせが集まる構造 ITヘルプデスクの問い合わせは、おおむね四つの領域に分かれます。一つ目はアカウントで、パスワードのリセット、ロック解除、多要素認証の再設定、入退社に伴う発行と削除が含まれます。二つ目は端末で、PCやスマートフォンの故障、OSやソフトウェアの更新、周辺機器の接続です。三つ目はネットワークで、VPNやWi-Fiにつながらない、特定のサイトが開けないといった相談が該当します。四つ目はSaaSで、Microsoft 365やGoogle Workspace、業務アプリの使い方と権限の申請です。 この四領域の比率は会社ごとに違いますが、どの会社でもアカウント系の依頼が件数の上位に入りやすい傾向があります。窓口の対象を決める際は、四領域のどこまでを受け、どこから先を外部の保守業者や各SaaSの管理者に回すのかを、一覧にして社内へ公開しておくと受付時の迷いが減ります。 ### 人事・総務の窓口と比べたITヘルプデスク特有の三つの前提条件 一つ目の違いは、問い合わせの多くが「いま仕事が止まっている」状態で届くことです。経費精算の質問は翌日に答えても業務は回りますが、ログインできない社員はその間なにもできません。応答時間の目標を、他の窓口より短く設定する根拠がここにあります。 二つ目は、本人確認が要る依頼が多いことです。パスワードのリセットや権限の付与を電話一本で受けると、なりすましによる不正アクセスの入口になります。三つ目は、同じ原因から同時に大量の問い合わせが来ることです。メールサーバーの障害が起きれば、数十人が同じ内容を一斉に送ってきます。この三つの前提が、後の章で扱う優先度の決め方とチケットの親子関係の設計につながっていきます。 ## ITヘルプデスクの受付チャネルを一本化する設計と必須入力項目の決め方 受付の設計で目指すのは、チャネルを減らすことではなく、どのチャネルから来ても同じ形の記録になることです。ここが揃わないと、後工程のチケット管理とナレッジ化が成り立ちません。 ### ポータル・チャット・メール・電話を一つのチケットへ集める受付の流れ 社員にとって手軽なのは、普段使っているチャットや電話です。これを禁止してポータルだけに絞ると、利用者は窓口を避けて詳しい同僚に直接聞くようになり、問い合わせが記録に残らなくなります。現実的なのは、チャネルごとの役割を決めたうえで、受けた担当者が必ずチケットを起票する運用です。 | チャネル | 向いている依頼 | チケット化の方法 | | ----------- | ------------------- | -------------- | | 受付フォーム・ポータル | アカウント発行、権限申請、機器の貸出 | 送信と同時に自動起票 | | ビジネスチャット | 使い方の質問、軽微な不具合 | 専用チャンネルの投稿から起票 | | メール | 社外の業者や取引先を含むやり取り | 受付用アドレスへの着信で起票 | | 電話 | ログイン不能など他の手段が使えない場合 | 担当者が通話中に代理起票 | 電話を残す理由は、ログインできない社員はチャットもポータルも開けないからです。電話は「他の手段が使えないときの窓口」と位置づけ、受けた担当者が代理で起票すれば記録は一本にまとまります。問い合わせを一元管理する仕組みそのものの機能と選び方は、[問い合わせ管理システムの機能とExcel管理の限界を整理した記事](https://www.issoh.co.jp/column/details/15376/)で詳しく扱っています。 ### 初回応答の手戻りを減らす受付フォームの必須項目と選択肢の作り方 受付時に情報が足りないと、担当者は「どのPCですか」「エラー画面を送ってください」と聞き返すところから始めることになります。この往復を減らすには、受付フォームの必須項目を絞って用意します。 - 依頼の種類（困っている／新しく用意してほしい、の二択） - 対象の領域（アカウント・端末・ネットワーク・SaaS・その他） - 影響を受けている人数（自分だけ／部署内の複数人／全社） - 業務が止まっているかどうか（止まっている／回避策で続けられる） - エラーメッセージや画面の写し（任意） 一つ目の二択は、次の章で扱うインシデントとサービス要求の区分にそのまま対応します。三つ目と四つ目は優先度の判定材料で、利用者に選ばせておけば担当者が受付時に判断する手間が減ります。項目を増やしすぎると入力を嫌って電話に流れるため、必須は五つ前後にとどめるのが無難です。 ## インシデントとサービス要求を分けるITヘルプデスクのチケット管理と優先度 チケットを一つの一覧で管理していても、性質の違う依頼が混ざっていると、急ぐべきものが埋もれます。最初に区分を分け、そのうえで優先度と期限を決めます。 ### ITIL 4の区分に沿ってインシデントとサービス要求を別の流れにする理由 ITサービス管理のフレームワークであるITIL 4は、ITの問い合わせ対応を複数のプラクティスに分けて整理しています。ヘルプデスクの仕組みづくりで押さえておきたいのは、そのうちのインシデント管理とサービス要求管理の区別です。インシデントは、本来使えるはずのサービスが止まったり品質が落ちたりした状態で、目的は一刻も早く元に戻すことにあります。サービス要求は、アカウントの発行やソフトウェアの導入のように、あらかじめ決まった手順で提供する依頼です。 両者を同じ一覧に並べると、権限申請が十数件たまっている間にネットワーク障害の連絡が埋もれる、といった事態が起こります。流れを分ける実務上の効果は、サービス要求の側を承認と作業の手順に落とし込めることにあります。手順が決まっている依頼は定型化して担当者を選ばずに処理し、人の判断が要るインシデントに担当者の時間を回す。この振り分けが、少人数の情シスで窓口を回す前提になります。 ### 影響範囲と緊急度の掛け合わせで優先度を機械的に決めるマトリクス 優先度を担当者の感覚で決めると、声の大きい依頼者のチケットが先に処理されます。避けるには、受付フォームで集めた「影響を受けている人数」と「業務が止まっているか」の二軸で、優先度を表から引く形にします。 | 影響範囲＼緊急度 | 業務が止まっている | 回避策で続けられる | | -------- | --------- | --------- | | 全社・複数部署 | P1（最優先） | P2 | | 部署内の複数人 | P2 | P3 | | 本人のみ | P3 | P4 | この表は例であり、段階の数や名称は自社の体制に合わせて変えて構いません。決めておくべきなのは、P1が発生したときに誰へ通知し、同じ原因の問い合わせをどう束ねるかです。メール障害のように数十件が同時に届く場合は、最初の一件を親チケットとし、残りを子として紐づけて、復旧の連絡を親から一斉に送る運用にします。役員からの依頼を一段上げるといった例外ルールを作る場合も、表の外に明文化しておかないと、担当者ごとに扱いがぶれます。 ### 応答と解決の二本で始めるSLAの目標設定と営業時間カレンダー SLAは、社外向けの契約に限らず、社内の窓口でも「いつまでに返すか」の約束として使えます。Jira Service Managementの公式ドキュメントでは、新しいサービスプロジェクトを作ると「Time to first response」「Time to resolution」などのSLAが既定で設定されること、SLAごとに計測を始める条件（Start）、一時停止する条件（Pause on）、止める条件（Stop）を指定すること、チームの勤務時間に合わせたカレンダーを割り当てて不在時間の計測を止められることが説明されています（[Jira Service Management「Setting up SLAs」](https://confluence.atlassian.com/servicemanagementserver112/setting-up-slas-1688900960.html)・Data Center 11.2系のドキュメント、2026年10月時点）。 製品を使うかどうかにかかわらず、この構造はそのまま社内SLAの設計に使えます。始めるのは「最初の応答まで」と「解決まで」の二本だけで十分です。利用者の返信待ちの間は時計を止める条件を入れないと、担当者の責任ではない待ち時間で目標を割り込みます。目標値は優先度ごとに置き、たとえばP1は応答30分・解決4時間、P4は応答1営業日といった形で、現状の対応実績を数週間測ってから無理のない値に決めてください。測り始める前に目標を宣言すると、守れない数字が独り歩きします。 ## 解決した対応をその場で記事にするITヘルプデスクのナレッジ化の手順 チケットが流れるようになっても、答えが担当者の頭の中にしか無ければ、同じ質問への対応時間は縮みません。ナレッジ化は、仕組みの三工程目として最初から設計に組み込みます。 ### KCSのSolve Loopに沿って対応しながら記事を書く運用への切り替え 社内のナレッジ化が止まる典型は、「月末にまとめて手順書を更新する」という運用です。忙しい月ほど後回しになり、手順書は数か月前の状態で止まります。この問題に対する方法論として、Consortium for Service InnovationがまとめるKCS（Knowledge-Centered Service）があります。KCS v6のPractices Guideは、依頼に応じて解決する日々の流れをSolve Loopと呼び、対応者が解決の経験を記録して組織の共有の記憶にすると説明しています（[KCS v6 Practices Guide「The Solve Loop」](https://library.serviceinnovation.org/KCS/KCS%5Fv6/KCS%5Fv6%5FPractices%5FGuide/030/030)・2026年10月時点）。Solve Loopの外側には、蓄積された記事とチケットの集まりを振り返ってパターンを分析するEvolve Loopが置かれています。 運用に落とすと、チケットを閉じる操作と記事の作成または更新を一つの手順にする、ということです。既存の記事で解決できたらその記事をチケットに紐づけ、記事が無ければ短い下書きを作ってから閉じる。完成度の高い手順書を目指さず、まず下書きの状態で公開し、次に同じ問い合わせを受けた担当者が足りない部分を書き足していく流れを作ります。 ### 問題・環境・解決策・原因の四項目で書く記事テンプレートの作り方 記事の書き方が担当者ごとにばらばらだと、検索しても見つからず、見つかっても読みにくくなります。KCSは記事の構造として、依頼者の言葉で書く問題（Issue）、解決後も変わらない製品名やバージョンなどの環境（Environment）、答えや手順を書く解決策（Resolution）、根本原因を書く原因（Cause）の四項目を示し、原因は記事の種類によっては不要な任意項目としています（[KCS v6「Technique 5.1: KCS Article Structure」](https://library.serviceinnovation.org/KCS/KCS%5Fv6/KCS%5Fv6%5FPractices%5FGuide/030/040/010/020)・2026年10月時点）。 ITヘルプデスクの記事に当てはめると、問題欄には「Teamsで会議に入れない」のように社員が実際に書いてきた文をそのまま入れます。担当者の言葉に言い換えると、利用者が検索したときに引っかかりません。環境欄にはOSの版や利用しているSaaSのプランを書き、解決策は手順を番号付きで並べます。原因欄は、パスワードの再設定方法のような単純な質問なら空欄で構いません。記事をためる器として、社内向けのFAQやナレッジベースを検索できる形で整えたい場合は、[社内ナレッジ共有に対応したQA・FAQサイト開発](https://www.issoh.co.jp/service/system/qa/)のように、自社の問い合わせ分類に合わせて作る選択肢があります。既製の仕組みで足りるかを先に比べたいなら、[社内FAQシステムの作り方と選び方をまとめた記事](https://www.issoh.co.jp/column/details/15660/)が判断の材料になります。 ### パスワードリセットなど件数の多い依頼はセルフサービス化を先に検討 件数が多く、手順が完全に決まっている依頼は、記事を書いて社員に読ませるより、社員自身が操作できるようにするほうが効きます。代表例がパスワードのリセットです。Microsoft Entra IDのセルフサービスパスワードリセット（SSPR）は、管理者やヘルプデスクを介さずにユーザーが自分でパスワードを変更・リセットできる機能で、リセットに必要な認証方法の数を1つまたは2つに設定できます。ユーザーが必要な数の認証方法を登録していないとSSPRは使えず、管理者にリセットを依頼するよう案内されます（[Microsoft Learn「セルフサービス パスワード リセットの詳細解説」](https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-sspr-howitworks)・2026年10月時点）。 この最後の点が導入時の落とし穴です。機能を有効にしただけでは、認証方法を登録していない社員からの電話は減りません。同ドキュメントにはサインイン時に登録を求める設定も用意されているため、有効化と同時に登録を必須にし、未登録者の一覧を定期的に確認する運用までを一つの作業として計画してください。オンプレミスのActive Directoryでパスワードを管理している環境では、パスワードライトバックを構成しない限りリセットできない点も、事前に確認が要ります。 ## ITヘルプデスクの仕組みを自社で作る場合とツール導入に進む場合の判断 ここまでの設計は、表計算と共有フォームでも、専用のITサービス管理ツールでも実現できます。どちらで始めるかを、規模と問い合わせの性質から決めます。 ### 月数十件・担当一人の窓口でフォームと一覧表による運用を先に固める判断 問い合わせが月に数十件で、受ける担当者が一人か二人なら、専用ツールの導入は急がなくて構いません。受付フォームを一つ作り、送信内容が共有の一覧表に行として追加されるようにすれば、受付の一本化とチケットの記録は実現できます。優先度の表とSLAの目標値も、一覧表の列として持てば運用を試せます。 この段階で先に固めたいのは、区分と項目の定義です。どの依頼をインシデントとして扱うか、受付フォームに何を必須にするかが決まらないままツールを入れると、ツールの初期設定に引きずられた区分で運用が始まり、後から直す手間がかかります。仕組みを動かしてみて、一覧表の行数が手に負えなくなった時点が乗り換えの目安です。 ### ITサービス管理ツールへ移るべき条件と自社開発を検討する場面 専用ツールへ移る条件は、次のいずれかに当てはまったときです。担当者が三人以上になり、誰がどのチケットを持っているかを一覧表で追えなくなった場合。SLAの計測を営業時間で正しく止めたい、あるいは承認フローを伴うサービス要求が増えた場合。そして、障害時に同じ原因の問い合わせを親子で束ねる操作が頻繁に発生する場合です。ツールの種類と選び方の比較軸は、[ヘルプデスクツールの4タイプと選び方を解説した記事](https://www.issoh.co.jp/column/details/15692/)で整理しています。 既製ツールが合わないのは、問い合わせの起点が社内の基幹システムや独自の業務アプリにあり、エラー情報や利用者の権限を自動でチケットに取り込みたい場合です。この連携を既製品の設定だけで実現しようとして、手作業の転記が残る例は少なくありません。逆に、問い合わせの大半がMicrosoft 365やGoogle Workspaceの使い方で占められているなら、自社開発に進む理由は薄く、既製ツールと前章のセルフサービス化で十分です。誰がどの段階で受けるかという体制側の設計は、[社内ヘルプデスクの立ち上げとL1・L2・L3の体制設計を解説した記事](https://www.issoh.co.jp/column/details/15700/)と合わせて検討してください。 ### 仕組みを作っても窓口の運用が回らなくなる三つの失敗パターンと避け方 一つ目は、受付チャネルを一本化した直後に電話とチャットを閉じてしまう失敗です。利用者が窓口を避け、詳しい同僚に直接聞く「隠れヘルプデスク」が生まれ、記録に残らない対応が増えます。代理起票を前提に、既存のチャネルは残してください。 二つ目は、優先度を利用者に自由に選ばせる設計です。ほぼ全員が最優先を選ぶため、判定の意味がなくなります。利用者に選ばせるのは影響範囲と業務停止の有無という事実だけにし、優先度は表から決めます。三つ目は、ナレッジ化を専任者の仕事にする運用で、対応した担当者が書かない限り記事は増えません。チケットを閉じる手順に記事の紐づけを組み込むことが、三つの中で最も効果の大きい対策です。施策の着手順序や効果を測る指標まで踏み込みたい場合は、[ヘルプデスク効率化の施策と進め方をまとめた記事](https://www.issoh.co.jp/column/details/15696/)が続きの参考になります。 ## ITヘルプデスクの仕組みづくりでよくある質問と回答（受付・チケット・ナレッジ） ITヘルプデスクの受付窓口とチケット管理、ナレッジ化を設計する際に、情報システム部門からよく挙がる質問をまとめました。 ### ITヘルプデスクとサービスデスクは何が違うのですか？ 実務上は同じ窓口を指して使われることが多く、厳密に分けなくても仕組みづくりには支障ありません。ITIL 4ではサービスデスクを利用者との単一の窓口として位置づけ、インシデントやサービス要求の受付を担う役割として扱います。呼称の違いや窓口の種類を詳しく確認したい場合は、[ヘルプデスクとサービスデスクの違いを解説した記事](https://www.issoh.co.jp/column/details/13555/)を参照してください。 ### チケット管理は表計算ソフトでも始められますか？ 表計算ソフトでも開始は可能です。受付フォームの送信内容が一覧表に追加される形にすれば、受付の一本化と記録は実現できます。区分、優先度、担当者、状態、応答日時、解決日時の列を用意しておけば、SLAの実績も集計できます。担当者が三人以上になる、承認を伴う依頼が増える、障害時に同じ原因の問い合わせをまとめる操作が多いといった状況になったら、専用ツールへの移行を検討する時期です。 ### ナレッジの記事は誰がいつ書くのがよいですか？ 問い合わせを解決した担当者が、チケットを閉じる時点で書くのが基本です。後でまとめて書く運用は忙しい時期に止まります。完成した手順書を目指さず、問題・環境・解決策の三項目を埋めた短い下書きで公開し、次に同じ問い合わせを受けた担当者が足りない部分を追記していく形にすると、記事の作成と更新が日々の対応の中で回るようになります。 ### SLAの目標値はどのように決めればよいですか？ 先に現状を測ってから決めます。数週間分のチケットについて、最初の応答までと解決までの時間を優先度別に集計し、その実績より少し短い値を目標に置くのが無理のない始め方です。利用者からの返信を待っている間は時計を止める設定にしておかないと、担当者の責任ではない待ち時間で目標を割り込むため、計測の一時停止条件もあわせて決めておきます。 ### チャットボットはどの段階で入れるべきですか？ チケットの区分とナレッジの記事がある程度そろってからです。チャットボットは参照する記事が無ければ正しく答えられず、引き継ぎ先のチケット管理が無ければ答えられなかった質問の行き場がありません。件数の多い質問の上位に対応する記事がそろい、未解決の会話をチケットとして起票できる状態になれば、一次受けの自動化に進めます。設計の詳細は[チャットボットでヘルプデスクを一次受けする設計の記事](https://www.issoh.co.jp/column/details/17486/)で解説しています。 ## 関連記事 - [ヘルプデスクとは？仕事内容と種類、サービスデスクとの違い](https://www.issoh.co.jp/column/details/13555/)：ヘルプデスクの定義と業務範囲を押さえる親記事 - [社内ヘルプデスクの立ち上げと体制設計（L1・L2・L3）](https://www.issoh.co.jp/column/details/15700/)：誰がどの段階で受けるかという体制側の設計 - [問い合わせ管理システムとは？機能・種類とExcel管理の限界](https://www.issoh.co.jp/column/details/15376/)：チケットを一元管理する仕組みの機能比較 - [ナレッジマネジメントとは？意味とSECIモデル、導入手順](https://www.issoh.co.jp/column/details/13288/)：組織として知識をためる考え方の全体像 - [チャットボットでヘルプデスクを一次受けする設計](https://www.issoh.co.jp/column/details/17486/)：ナレッジ整備後に進む一次受けの自動化 --- 出典: [ITヘルプデスクの仕組みを作る：受付窓口・チケット管理・ナレッジ化の設計手順]()（株式会社一創）