> ※本記事にはプロモーションが含まれます（PR表示）。記載のサービスへのリンクには一部アフィリエイトリンクを含みます。

【中堅IT企業】社内ヘルプデスクAIエージェント——「PCが起動しない」「Outlookが開けない」を5分で解決する仕組み

月曜朝9時5分。ヘルプデスクの内線が鳴り止まない。「PCが起動しない」「Outlookが開けない」「VPNが繋がらない」が同時並行で5件。担当2名で全社200名のサポート、月の残業はすでに30時間を超えている。受話器を取りながら、隣の同僚が小さくため息をつく。「これ、AIに任せられないかな」と独り言が漏れる。火曜の朝、課長は本気でそれを検討し始める——本記事は、その火曜の朝に開いてほしい設計図です。

社内ヘルプデスクは、企業のIT基盤の最前線でありながら「成果が見えにくい部署」の代表格です。問い合わせの7割は既知トラブルの繰り返し、ナレッジは特定担当者の頭の中、離職の予兆は誰にも共有されない。本記事では、この構造をAIエージェントで解きほぐすための具体的な実装プロンプト4種を完全公開します。読み終えた頃には、「明日から試せる」段階まで降ろせる手応えを持ち帰っていただけるはずです。

なぜ今、社内ヘルプデスクにAIエージェントなのか

結論から言えば、社内ヘルプデスクは「同じ症状を、違う社員が、違う時間に、違う言葉で持ち込んでくる」業務であり、これは生成AIが最も得意とする領域だからです。

ヘルプデスクの問い合わせは、症状名だけ見れば10カテゴリほどに収束します。PC起動・メール・VPN・プリンター・アカウント・業務システム・Web会議・セキュリティ警告・周辺機器・要切り分け。月に数百件の問い合わせがあっても、その9割はこの10カテゴリのどこかに入ります。

それにも関わらず人手が逼迫する理由は、社員一人ひとりの表現が揺れるからです。「Outlookが開かない」と言う人もいれば「メールが見られない」と言う人もいる。「VPNが繋がらない」と「自宅から会社のサーバーに入れない」は同じ事象を指していることが多い。この「自然言語の揺れを、定型のカテゴリに射影する」工程を、AIエージェントは数秒でこなせます。

加えて、生成AIの真価は「対応手順を、その問い合わせ者のITリテラシーに合わせて言い換えてくれる」点にあります。新人事務員と、ベテラン経理部長と、現場の作業員に同じスクリーンショット指示を送るのは無駄です。AIなら、相手の文体・前提知識・端末環境に合わせて手順を再生成できます。

つまり、AIエージェントを正しく組み込めば、ヘルプデスクの一次対応は「人間が応答する仕事」から「AIが下書きし、人間が承認する仕事」へと役割が変わると考えられます。そして二次対応・三次対応に回せる時間が、情シスの本来業務（セキュリティ強化・基盤刷新・DX推進）を生み返します。

症状分類10カテゴリの完全マップ

ヘルプデスクAIエージェントを設計する第一歩は、自社の問い合わせを「漏れなく重複なく」カテゴライズすることです。本記事では下表の10カテゴリを推奨します。多くの中堅企業ではこの10で9割以上を吸収できます。

| No. | カテゴリ | 代表例 | 緊急度の目安 |
|—|—|—|—|
| 1 | PC・端末 | 起動不可・フリーズ・物理破損 | 中〜高 |
| 2 | メール | Outlook起動不可・送受信エラー・添付不可 | 中 |
| 3 | ネットワーク・VPN | 社外接続不可・速度低下・社内Wi-Fi不安定 | 中〜高 |
| 4 | プリンター・複合機 | 印刷不可・ドライバ不足・スキャン失敗 | 低〜中 |
| 5 | アカウント・権限 | パスワードリセット・新規権限申請 | 中 |
| 6 | 業務システム | ERP・販売管理・勤怠システムのエラー | 中〜高 |
| 7 | Web会議・コラボ | Teams/Zoom入室不可・SharePoint権限 | 中（会議直前は高） |
| 8 | セキュリティ警告 | ウイルス検知・不審メール・USB自動実行 | 常に最高（即人間対応） |
| 9 | デバイス・周辺機器 | マウス・モニター・USB認識せず | 低 |
| 10 | その他・要切り分け | 症状不明・複合要因・新規システム | 中（人間判断必須） |

ポイントは2点です。

第一に、カテゴリ8（セキュリティ警告）は常にAI完結させないこと。ウイルス検知・情報漏洩疑い・不審メールは、社員が「念のため聞いてきた」段階でも情シス責任者にエスカレーションする運用が安全です。AIには「このカテゴリに分類された瞬間、自動で人間にチケットを上げる」ロジックを組み込みます。

第二に、カテゴリ10（その他・要切り分け）は人間判断必須として設計すること。AIが分類に自信を持てない問い合わせを無理にどこかへ押し込むより、「分類不能」と返す方が事故が減ります。後段のプロンプトAでは、信頼度スコア（0〜1）を必ず返すよう指示しています。

Before / After 業務フロー比較

実装後、現場で何が変わるのかを具体化しておきます。

Before（現在の典型）
1. 社員が内線・チャット・メールで担当者に直接問い合わせ
2. 担当者が手を止めて症状を聞き出す（5〜15分）
3. 過去対応記憶を頼りに手順を案内（属人化）
4. 解決後、ナレッジ化されないまま終了
5. 同じ問い合わせが翌週・翌月に再来

After（AIエージェント導入後）
1. 社員が社内チャットボット窓口に問い合わせ
2. 症状分類エージェント（プロンプトA）が10カテゴリへ自動振り分け＋緊急度判定
3. 既知トラブル照合エージェント（プロンプトB）が過去履歴と一致度を算出し解決時間を予測
4. 対応手順生成エージェント（プロンプトC）が社員向け手順を生成（やさしい日本語＋スクショ指示）
5. 自己解決できなければ自動で担当者にチケット起票
6. 月次トレンド分析エージェント（プロンプトD）が経営層に多発トラブルと離職予兆を報告

担当者は「すべての一次対応を捌く」役割から「AIの一次対応を承認・例外を引き取る」役割へシフトします。これが本記事の中心となる設計思想です。

実装プロンプト4種完全公開

ここからが本記事の主題です。以下の4種は、貴社の情シス窓口でそのままコピペして検証を始められるように設計しています。プロンプト本文は社内チャットボット・社内Wiki連携・RPAなどに組み込めます。

> 動作環境注記: 以下はChatGPTで動作確認しています（2026年5月時点）。同等の生成AIサービス（Claude、Gemini等）でも動作しますが、出力フォーマットの厳密性に差が出る場合があります。モデルのアップデートにより出力が変わる可能性があるため、運用前に必ず自社環境でテストしてください。

プロンプトA：症状分類エージェント（10カテゴリ自動振分・緊急度判定）

役割: 社員からの自由記述の問い合わせを受け取り、10カテゴリへ振り分け、緊急度（低・中・高・最高）を判定。信頼度が低い場合は「要切り分け」を返します。

“`

役割

あなたは中堅企業の情報システム部に所属する一次受付AIです。社員からの問い合わせ（自然文）を読み、定義された10カテゴリへ正確に振り分けます。あなたの分類結果はチケット起票・FAQ誘導・エスカレーション判定の起点になるため、無理な押し込みより「分類不能」を選ぶ慎重さが評価されます。

入力

– 社員の問い合わせ本文（チャット・メール・電話文字起こし）
– 任意で過去問い合わせ履歴（社員ID単位、最大10件）

10カテゴリ定義（厳守）

1. PC・端末（起動不可・フリーズ・ハード故障）
2. メール（Outlook起動不可・送受信・添付）
3. ネットワーク・VPN（社外接続・社内Wi-Fi）
4. プリンター・複合機
5. アカウント・権限（パスワード・権限申請）
6. 業務システム（ERP・販売・勤怠）
7. Web会議・コラボ（Teams/Zoom/SharePoint）
8. セキュリティ警告（ウイルス検知・不審メール・USB）
9. デバイス・周辺機器（マウス・モニター・USB物理）
10. その他・要切り分け（症状不明・複合）

緊急度判定ルール

– 最高: カテゴリ8、または「業務全停止」「情報漏洩疑い」「全社影響」キーワード検出時
– 高: 業務システム停止、会議直前のWeb会議トラブル、複数社員同時発生
– 中: 個人作業の停止、午後以降の作業に支障
– 低: 周辺機器・代替手段あり

出力フォーマット（JSON厳守）

{
“category_no”: 1〜10,
“category_name”: “（カテゴリ名）”,
“confidence”: 0.0〜1.0,
“urgency”: “low|medium|high|critical”,
“auto_escalate_to_human”: true|false,
“extracted_symptoms”: [“症状1”, “症状2”],
“missing_info”: [“確認すべき情報1”, “…”],
“reasoning”: “120字以内の根拠”
}

禁則

– confidence < 0.6 の場合は category_no=10（その他・要切り分け）を返す - カテゴリ8と判定した瞬間、auto_escalate_to_human=trueを必ず返す - 個人情報（マイナンバー・パスワード本文・給与額）が入力に含まれていた場合、出力に転記せず「個人情報マスク済み」とだけ記述 - 推測で原因を断定しない（症状の抽出に留める）

例

入力: 「朝からTeamsに入れません。10時から客先と会議です」
出力: {“category_no”:7,”category_name”:”Web会議・コラボ”,”confidence”:0.92,”urgency”:”high”,”auto_escalate_to_human”:false,”extracted_symptoms”:[“Teams入室不可”,”会議直前”],”missing_info”:[“エラーメッセージ”,”端末種別”],”reasoning”:”Teams単体障害の可能性。会議10時で時間制約大”}
“`

プロンプトB：既知トラブル照合エージェント（過去履歴マッチング・解決時間予測）

役割: プロンプトAの分類結果と、社内ナレッジDB／過去対応履歴を照合し、最も近い解決事例を提示。あわせて推定解決時間と一次対応で完結する確率を返します。

“`

役割

あなたは社内ヘルプデスクのナレッジ照合AIです。プロンプトAが分類した問い合わせを、過去に同じカテゴリで対応した事例リストと照合し、最も近い解決事例トップ3を提示します。さらに、その事例で一次対応（社員自身の自己解決またはAI回答のみ）で完結した割合と、平均解決所要時間を返します。

入力

– プロンプトAの出力JSON
– ナレッジDB（過去対応履歴: チケットID・症状・対応手順・解決時間・一次完結フラグ・更新日時）
– 任意の制約（対象社員のITリテラシーレベル: 低・中・高）

処理ロジック

1. プロンプトAのextracted_symptomsとナレッジDBの症状欄をベクトル/キーワードで類似度照合
2. 類似度上位3件を抽出（同点の場合は更新日時が新しいものを優先）
3. 各事例の一次完結率と平均解決時間を集計
4. 提示順は「類似度 × 一次完結率」のスコア降順

出力フォーマット（JSON厳守）

{
“matched_cases”: [
{
“ticket_id”: “string”,
“similarity”: 0.0〜1.0,
“solution_summary”: “100字以内の解決手順要約”,
“first_resolution_rate”: 0.0〜1.0,
“avg_minutes”: 数値,
“last_updated”: “YYYY-MM-DD”
}
],
“predicted_first_resolution_rate”: 0.0〜1.0,
“predicted_minutes”: 数値,
“knowledge_gap_flag”: true|false,
“recommendation”: “self_service|ai_response|human_first|emergency”
}

禁則

– 類似度0.5未満の事例は提示せず、knowledge_gap_flag=true を返す（ナレッジ不足を経営層に報告するシグナル）
– 古い事例（更新2年以上前）は similarity から -0.1 補正
– 過去事例の社員氏名・部署名はマスクして solution_summary に転記しない
– 推定時間は5分単位で丸める（過剰な精度錯覚を避ける）

例

入力（要約）: カテゴリ7「Web会議・コラボ」、症状「Teams入室不可」、リテラシー中
出力（要約）: 類似事例3件提示、predicted_first_resolution_rate=0.78、predicted_minutes=10、recommendation=”ai_response”
“`

プロンプトC：社員向け対応手順自動生成エージェント（やさしい日本語・スクショ指示付き）

役割: プロンプトBの照合結果をもとに、問い合わせた社員のリテラシーに合わせた対応手順を生成。専門用語を避け、必要に応じて「ここでスクリーンショットを撮ってください」と指示を入れます。

“`

役割

あなたは社員向け対応手順の作家AIです。技術正確性を保ちつつ、IT専門用語を避け、誰でも実行できるステップに翻訳します。読み手は新人事務員から経理部長まで様々で、ITリテラシーレベル（低・中・高）が指定されます。

入力

– プロンプトA・Bの出力JSON
– 対象社員のリテラシーレベル
– 端末・OS情報（Windows/Mac/モバイル）

出力ポリシー

– 一文40字以内、漢字使用は中学生レベルまで
– 専門用語は初出時に「（〜のことです）」で必ず注釈
– 5ステップ以内に収める。超える場合は「ここまでで一旦お試しください」で区切る
– 各ステップに「期待される画面表示」を添える（読者が今どこにいるかを失わないため）
– スクリーンショット指示は「📸 この画面を撮影してください」と明示
– 解決しなかった場合の連絡先と、その時に伝えるべき情報を末尾に必ず記載

出力フォーマット（Markdown）

解決手順（所要時間: 約X分）

ステップ1: （見出し）

（手順本文）
期待される画面: （描写）
📸 この画面を撮影してください（任意）

ステップ2〜5: 同形式

それでも解決しないとき

– ヘルプデスク内線: （社内番号）
– 伝えてほしい情報: 1. エラーメッセージ全文 2. 撮影した画面 3. 直前にした操作

禁則

– 「〜と思います」「たぶん」など曖昧表現は禁止
– バックグラウンドのレジストリ・コマンドプロンプト操作はリテラシー「高」以外には絶対指示しない
– 端末再起動の前には必ず「保存していないファイルがないか確認してください」を入れる
– パスワード入力を伴う場合、「画面共有・スクリーンショットを停止してから入力してください」を必ず付記

例（リテラシー低・Outlook起動不可）

ステップ1: タスクトレイのOutlookアイコンを右クリック → 「終了」を選んでください。
期待される画面: アイコンが消える状態。
ステップ2: スタートメニューから再度Outlookを起動してください。
（以下省略）
“`

プロンプトD：月次トレンド分析＋離職予兆検知エージェント（経営層向けレポート）

役割: 月次でチケットデータを集計し、多発トラブル・ナレッジ不足領域・離職予兆を経営層向けレポートにまとめます。離職予兆は「同一社員が同種カテゴリの問い合わせを3回以上／月」を一次シグナルとし、文脈から精査します。

“`

役割

あなたは情報システム部の経営層向けアナリストAIです。月次のチケットデータ・問い合わせログを受け取り、経営層が10分で読める意思決定資料を作成します。中心テーマは(1)多発トラブル(2)ナレッジ不足領域(3)離職予兆検知の3点です。

入力

– 当月のチケット全件（カテゴリ・社員ID・症状・解決時間・一次完結フラグ・問い合わせ日時）
– 過去6ヶ月の同データ（比較用）
– 任意で人事マスタ（部署・在籍年数）※個人特定情報はIDで匿名化済みのもののみ

出力構成（必ずこの順）

1. エグゼクティブサマリー（200字以内・経営判断1行を含む）
2. カテゴリ別問い合わせ件数の前月比・前年同月比（テーブル）
3. 多発トラブルTop5（カテゴリ・症状・件数・推奨アクション）
4. ナレッジ不足領域（プロンプトBが knowledge_gap_flag=true を返した症状の集計）
5. 離職予兆アラート
6. 経営層への推奨アクション（次月の優先施策3つ）

離職予兆検知ルール（重要）

以下のいずれか2つ以上を同時に満たす社員を「要観察」として匿名IDで列挙する:
– 同種カテゴリの問い合わせが当月3回以上
– 業務システム（カテゴリ6）の問い合わせが過去3ヶ月で増加傾向
– 営業時間外（19時以降・休日）の問い合わせ比率が当月50%超
– 同一エラーメッセージの繰り返し（学習が定着していない可能性）

禁則

– 個人氏名・部署名・人事評価は出力しない（人事部の専権領域）
– 「離職する」と断定しない。「メンタル・業務適合の観点で人事と要連携」と表現する
– 数値断定は「当月の集計値」と必ず時点を明記する
– 経営判断（人員配置・採用増・退職交渉）は提案しない（情シスの越権を避ける）
– 出力サマリーは経営層が10分で読める量（A4 2枚以内）

出力フォーマット（Markdown見出し付き）

YYYY年MM月 ヘルプデスクAIエージェント月次レポート

1. エグゼクティブサマリー

2. カテゴリ別問い合わせ件数推移

3. 多発トラブルTop5

4. ナレッジ不足領域

5. 離職予兆アラート（要観察ID一覧）

6. 次月の推奨施策

例（離職予兆セクション）

要観察ID: EMP-04421
– 当月、業務システム（カテゴリ6）に5回問い合わせ（過去3ヶ月平均1.2回から大幅増）
– 19時以降の問い合わせ比率: 当月62%
– 推奨: メンタル・業務適合の観点で人事部と要連携（情シス内では追加対応せず）
“`

自己解決率KPIと離職予兆検知の運用設計

プロンプトを動かすだけでは、ヘルプデスク改革は「面白い試み」で終わります。指標で測ってこそ、経営層が予算を継続承認できる。本章では3つのKPIと、その計算式を提示します。

KPI1: 一次完結率（First Resolution Rate）
– 計算式: 一次完結チケット数 ÷ 全チケット数
– 目標: 導入半年で60%以上、1年で75%以上を目安と考えられます
– 一次完結 = 「AIの自動回答だけで解決した」または「社員自身がFAQで解決した」状態

KPI2: FAQ誘導率
– 計算式: AIがFAQを提示し、社員が閲覧後に追加問い合わせをしなかった件数 ÷ FAQ提示件数
– これが低い場合、FAQが古い／検索性が悪い／文体が難しいの3点を疑います

KPI3: 平均解決所要時間（MTTR：Mean Time To Resolve）
– 計算式: 解決時刻 − 問い合わせ受付時刻 の平均
– カテゴリ別に集計し、改善優先順位を決めます

これらを月次でプロンプトDに集計させ、経営層には「数字＋言葉」のセットで報告します。数字だけでは伝わらず、言葉だけでは説得できないからです。

離職予兆検知はもっと繊細な領域です。同一社員が同じカテゴリで3回以上の問い合わせを起こしている場合、ITリテラシー不足とは限らず、業務理解の停滞・メンタル不調・配置不適合のサインである可能性が指摘されます。情シスの仕事はこれを見つけることであって、解釈することではありません。プロンプトDが要観察IDを匿名で列挙し、人事部が個人を特定して面談につなげる——この役割分担を文書化することで、情シスは越権を避けつつ組織貢献ができると考えられます。

情報の線引き——AIに渡してよい情報・渡してはいけない情報

社内ヘルプデスクは個人情報・機密情報の通り道です。AIに何を渡し、何を渡さないかは導入前に決めておく必要があります。

渡してよい情報（AI入力OK）
– 症状の自由記述（「Outlookが起動しません」等）
– エラーメッセージ全文（コード番号・本文）
– 端末種別・OS・ソフトウェアバージョン（社外秘でない範囲）
– 社員ID（匿名化された内部識別子）
– 問い合わせ日時・部署種別

渡してはいけない情報（AI入力NG）
– マイナンバー・健康保険番号
– パスワード本文・トークン文字列
– 給与額・人事評価・面談記録
– 顧客個人情報（名前・連絡先・契約内容）
– 経営機密情報（M&A・採用計画・財務戦略）

線引きを徹底するため、社内チャットボットの入力欄に「ここに入力した内容はAIで処理されます。マイナンバー・パスワードは入力しないでください」という常時表示を出す運用が安全です。プロンプトA・Cでも、検出時にマスク処理する記述を入れています。

加えて、セキュリティインシデント疑い（ウイルス検知・情報漏洩・不審メール）はAI判定で完結させず、即座に情シス責任者・経営層に人間がエスカレーションする体制を必須とします。法令対応（個人情報保護法・労働関連法）の最終判断は法務部の専権事項であり、AIの出力はあくまで初動の参考情報という位置付けが妥当だと考えられます。

導入ステップ・限界・向き不向き

段階的な導入ステップ（4段階）

段階1: 影武者運用（1〜2ヶ月）
社員からの問い合わせを担当者が受けつつ、裏でプロンプトA〜Cを動かして「もしAIが答えていたら何と返したか」を記録します。AIの精度をログだけで観察し、人間の正答とどれだけ一致するかを測ります。

段階2: 限定カテゴリ自動応答（2〜3ヶ月）
カテゴリ4（プリンター）・カテゴリ9（周辺機器）など影響の小さい領域から、AI自動応答を開始します。社員には「AIが先に回答します。解決しなければ担当者にエスカレーションされます」と明示します。

段階3: 全カテゴリ展開（半年）
段階2の結果を踏まえ、カテゴリ8以外を自動応答化。担当者は二次・三次対応に集中する体制へ移行します。

段階4: 経営層レポート定常化（1年）
プロンプトDを月次運用に組み込み、経営層への報告を定例化。投資継続判断の根拠を毎月提示します。

限界・向き不向き

正直に書いておきます。AIエージェントが苦手な領域は確実にあります。

– 物理障害（電源コード抜け、ハードディスク故障）の特定——現場確認が要る
– 複数システムが絡む複合トラブル——ログ突合は人間が早い
– 感情的になっている社員の鎮静——AIは共感できても、雰囲気を読めない
– 新規導入直後のシステム——ナレッジが蓄積される前は精度が出ない

逆に得意な領域は以下です。

– 既知トラブルの繰り返し対応
– リテラシーレベルに応じた手順言い換え
– 月次集計・トレンド可視化
– 「同じ社員が同じ症状で何回問い合わせたか」のような人間が見落としがちなパターン検出

向き不向きを正しく見極めることが、AI導入失敗の最大の予防策と言えます。「AIに何でも任せる」発想ではなく、「AIに任せてよい領域を切り出す」発想で設計してください。

関連記事

社外向け／顧客向けの問い合わせ自動応答エージェントについては [コールセンターFAQ自動応答AIエージェント記事](callcenter-faq-agent-2026) を、医療・クリニックでの問い合わせ振り分け事例は [クリニック問い合わせ応答AIエージェント記事](clinic-inquiry-response-agent-2026) を参照してください。

社内DX推進の全体像から考えたい方には、Team αの [中小製造業のDXのはじめかた](https://ai-blog-company.example.com/chusho-seizogyo-dx-hajimekata) が業界横断で参考になります。情シス部門のDXもこの「小さく始める」原則は同じです。

まとめと次のアクション

社内ヘルプデスクをAIエージェントで再設計する核心は、3つに集約されます。第一に、症状を10カテゴリへ漏れなく射影すること。第二に、過去履歴と照合して解決時間を予測し、社員のリテラシーに合わせて手順を言い換えること。第三に、月次データから多発トラブルと離職予兆を経営層に届け、情シスの仕事を「コストセンター」から「組織観測の最前線」へ位置付け直すことです。

> ※以下、プロモーションリンクを含みます。

明日からの一歩として、2つの選択肢があります。

A. 担当者の学習から始める方
情シス担当者個人がAI業務活用の基礎を体系的に身につけたいなら、Udemyの実務系AI講座から取り組むのが現実的です。社内で誰か一人が動かないと、組織は動きません。
→ [Udemyで「AI業務活用」「ChatGPT実務」関連講座を見る](https://trk.udemy.com/c/7221214/3193860/39854)

B. チケット管理基盤から整える方
本記事のAIエージェントは「チケット起票・履歴蓄積基盤」とセットで真価を発揮します。Excelやメールで管理しているなら、まずチケット管理SaaSへ移行するのが先決です。情シスから現場業務まで横断的に使えるkintoneは選択肢の筆頭です。
→ [kintoneでヘルプデスクのチケット管理を始める]（kintoneアフィリエイトリンク）

どちらから始めても構いません。重要なのは、月曜朝9時5分の内線地獄をもう一週も繰り返さないために、今日のうちに小さな一歩を踏み出すことです。

—

*本記事の実装プロンプトはChatGPTで動作確認しています（2026年5月時点）。モデルのアップデートにより出力フォーマットや精度が変わる場合があります。導入前に必ず自社環境でテストし、社内のセキュリティポリシーと照合してください。*
*個人情報・機密情報をAIに入力しない運用設計、セキュリティインシデント時の即時人間対応、法令最終判断の法務部一任は、本記事の前提となる絶対ルールです。*