情シス/ITヘルプデスクのAIエージェントの活用事例/実例/具体例について

情シス・ITヘルプデスクのAIエージェントとは、社内ナレッジを検索して回答するだけでなく、本人確認や承認を経てパスワードリセット・チケット起票などの処理まで実行する業務支援の仕組みです。

問い合わせ件数の増加、担当者への属人化、夜間や拠点からの問い合わせ対応に悩む企業では、AIエージェントの導入が有力な選択肢になります。本記事では、情シス・ITヘルプデスクで実際に想定できる業務別・シーン別の活用事例を、課題、導入内容、効果の順で具体的に解説します。RAGのデータ整備、Active DirectoryやITSMとの連携、有人エスカレーション、2026年時点で確認すべきセキュリティ要件までまとめています。

情シス・ITヘルプデスクにAIエージェントが求められる背景

情シス部門は、社内システムの運用、アカウント管理、端末のトラブル対応、セキュリティ対策を同時に担います。利用するSaaSや拠点が増えるほど、問い合わせは増えますが、担当者の人数を同じ割合で増やすことは難しい状況です。AIエージェントは、問い合わせ窓口と業務システムの間に入り、回答と処理を一つの流れにまとめます。

シナリオ型チャットボットは、あらかじめ登録した選択肢や質問への回答を返す仕組みです。RPAは決められた画面操作やデータ移送を正確に繰り返すことが得意です。一方、AIエージェントは「VPNにつながらない」「出張先で認証アプリが使えない」といった曖昧な相談から意図を推定し、ナレッジを検索して、必要に応じて複数のツールを呼び出します。回答だけで終わらず、本人確認、端末情報の取得、チケット起票、担当者への引き継ぎまでつなげられる点が大きな違いです。

基本構成は、社内FAQ・手順書・過去チケットなどのデータソース、検索用のベクトルデータベース、生成AIモデル、TeamsやSlackなどのチャット画面です。問い合わせを受けると、検索システムが関連情報を取り出し、生成AIが根拠を踏まえて回答します。NISTはRAGを、別の検索システムが知識ベースから関連情報を取り出し、その情報をモデルの文脈として回答に利用する構成と定義しています（出典：NIST「Retrieval-augmented generation」、2025年）。

情シス・ITヘルプデスクのAIエージェント活用事例

活用効果が出やすいのは、発生頻度が高く、本人確認や手順が標準化しやすい業務です。ここでは、問い合わせを受けてから解決または有人引き継ぎまでの流れを、現場で使える粒度に分けて紹介します。

課題は、パスワード忘れやアカウントロックが営業時間外にも発生し、担当者が本人確認とリセット作業に追われることです。特に、パスワード忘れ、アカウントロック、MFA不通の3本は問い合わせが多く、対応手順も整理しやすい領域です。

導入内容として、AIエージェントが社員番号などの入力を求めるのではなく、SSOや多要素認証済みのユーザー情報を引き継いで本人確認を行います。その後、Active DirectoryやIDaaSのAPIを呼び出し、許可された操作だけを実行します。管理者権限をAIに直接渡さず、リセット要求を一時トークンに変換し、条件を満たした場合だけワークフローが実行する構成が安全です。MFA不通のように乗っ取りリスクが高いケースは、AIが復旧方法を案内して有人窓口へ送ります。

効果は、一次対応の待ち時間短縮と、夜間・休日の自己解決率向上です。Microsoftが紹介するCommonwealth BankのChatITでは、Teamsから相談を受け、端末の遅延に対するセッションリセットなどを実行し、1回の修正が平均2分、従来のITサービスデスクへの電話は平均17分でした。自動化機能の開始後6か月で230万件超のメッセージと12,000件超のIT修正を処理したと報告されています（出典：Microsoft Source Asia「Commonwealth Bank’s ChatIT」、2025年）。

課題は、「ネットワークにつながらない」「PCが遅い」という相談だけでは、OS、端末、VPN、認証、拠点ネットワークのどこに原因があるか分からず、担当者が何度も聞き返すことです。利用者も、画面のスクリーンショットやエラーコードを探す負担があります。

導入内容として、AIエージェントが症状、発生時刻、利用場所、端末ID、ネットワーク種別を会話形式で収集します。MDMや監視ツールから取得した端末状態を参照し、再起動、キャッシュ削除、VPNプロファイル再配布など、影響範囲が限定された処理を順番に提案します。実行前に対象端末と処理内容を表示し、利用者または担当者の承認を必須にします。改善しない場合は、集めた情報と実施済み手順をITSMのチケットに添えてエスカレーションします。

効果は、聞き取り時間の削減と、担当者ごとの切り分け品質の平準化です。回答だけを生成するのではなく、実施した診断と結果を記録できるため、同じ利用者が再度問い合わせた場合も引き継ぎが容易です。Microsoftの事例のように、チャットから限定的な自動修正までつなげると、電話を待つ時間そのものを減らせます。

課題は、Microsoft 365、Slack、営業管理ツールなどの利用方法や権限申請が、製品ごとに異なることです。マニュアルを読めば分かる質問でも、急いでいる利用者は情シスへ連絡し、担当者は同じ説明を繰り返します。

導入内容として、AIエージェントが利用者の部署、役職、申請目的を確認し、対象サービスの手順や申請フォームを案内します。権限付与まで行う場合は、申請内容をITSMやワークフローに登録し、上長承認後にだけアカウント作成APIを呼び出します。業務上の例外や高権限ロールは自動承認の対象外にし、エージェントは不足情報の回収と申請状況の通知に限定します。

効果は、申請の不備を減らし、情シスが個別説明ではなく高リスク案件に集中できることです。申請受付、承認待ち、処理中、完了という状態をAIが追跡し、利用者へ完了報告まで行えば、「申請したが今どうなっているか」という追加問い合わせも減らせます。

課題は、FAQや手順書が複数の場所に散らばり、表記ゆれや古い情報が混在していることです。担当者は経験で正しい資料を選べますが、新任者や各拠点の担当者は検索に時間がかかります。

導入内容として、過去の問い合わせ、解決済みチケット、正式なマニュアルを収集し、サービス名、対象OS、対象者、更新日、機密区分をメタデータとして付与します。AIは回答だけでなく、参照した文書名と更新日を示し、根拠が見つからない場合は「確認できない」と返します。SCSKの社内ヘルプデスク事例では、月間1万件の問い合わせに対応し、AIチャットボット導入で問い合わせ件数が25%削減されたと紹介されています（出典：SCSK「AIチャットボット PrimeAgent」、2022年掲載・2026年閲覧）。

効果は、自己解決率の向上とナレッジの属人化解消です。ただし、FAQの件数を増やすだけでは精度は上がりません。古い手順を削除し、ひとつの質問にひとつの答えを対応させ、利用者が使う言い換えを登録することが重要です。解決できなかった質問を毎週確認し、正式回答へ反映する循環を作ると、導入後も回答品質が上がります。

AIエージェントの導入はどのように進めますか？

結論から言うと、最初から全社の問い合わせを自動化せず、頻度が高く、失敗時の影響を限定できる業務でPoCを行う進め方が適切です。AIエージェントはモデルを導入すれば完成する製品ではなく、対象業務、ナレッジ、権限、評価方法を一体で設計する必要があります。

PoCの候補は、パスワード忘れ、アカウントロック、MFA不通のように、利用者が困る頻度が高く、業務手順を定義しやすいものです。次に、VPN切り分け、SaaS申請、端末の簡易診断へ広げます。給与、人事評価、重大なセキュリティインシデントなど、機密性や判断の影響が大きい業務は、最初から自動実行の対象にしません。

PoCでは、過去の問い合わせから代表的な質問を数十から200問程度選び、正答率、根拠提示率、有人転送の適切さ、1件あたりの対応時間を測定します。テストには正常な質問だけでなく、曖昧な質問、古い手順を含む質問、権限外の依頼、悪意のある指示も含めます。実運用に近い評価データを先に作ることが、導入後の「思ったより使えない」を防ぎます。

アクション実行では、AIの回答精度よりも、誤った処理を実行させない制御が重要です。AIには「パスワードリセットを実行する」という権限を直接与えず、ユーザーID、対象システム、依頼理由を検証する関数だけを公開します。関数側で入力値の形式、対象者の所属、実行回数、許可された時間帯を再確認し、条件外なら処理を拒否します。

さらに、権限付与や端末消去など取り消しにくい処理は、AIが提案を作り、人が承認してから実行するHuman-in-the-loop方式にします。承認画面には、利用者、対象資産、処理内容、根拠、影響範囲、ロールバック方法を表示します。実行後は、入力、検索文書、関数呼び出し、承認者、結果を監査ログへ保存します。

KPIは、AI利用率だけでなく、自己解決率、一次解決率、有人転送率、平均解決時間、再問い合わせ率、誤回答率、根拠提示率で設定します。自動化した件数だけを追うと、AIが無理に回答して誤案内を増やす危険があります。安全に「分からない」と言えた件数や、正しい担当部署へ引き継げた割合も評価対象にします。

週次または月次で未解決ログを分類し、原因を「ナレッジ不足」「検索失敗」「権限不足」「質問が曖昧」「そもそも業務フローの問題」に分けます。回答文を修正するだけでなく、PCセットアップやアカウント発行のように問い合わせを生む業務そのものを標準化すると、問い合わせの発生源を減らせます。

RAGの精度を高めるナレッジ整備の実務

AIエージェントの回答品質は、モデルの性能だけで決まりません。情シスが正しい手順を管理し、検索しやすい形へ整えることが成果の前提です。WordやExcelをそのまま読み込ませるのではなく、回答に必要な単位へ分解して、更新日と対象範囲を付けて登録します。

まず、同じ手順の重複、旧製品名、廃止されたURL、担当者個人のメモを整理します。Excelの表は、列見出しと行の意味が失われないよう、サービス名、条件、手順、例外、問い合わせ先を文章または構造化データに変換します。図解PDFは画像だけを切り出さず、図の前提と分岐条件をテキスト化します。

チャンクは「文書を一定文字数で機械的に切る」のではなく、「利用者の質問に対して一つの回答が成立する」単位にします。例えば、VPN接続の手順、エラーコード別の対処、管理者向けの例外対応を別々に登録します。サービス名、OS、拠点、公開対象、更新日、機密区分を付けると、検索結果を絞り込めます。

評価データには、実際の言い換えを含めます。「パスワードを変えたい」「ログインできない」「認証が通らない」は、同じ業務でも検索語が異なります。正答率だけでなく、適切な文書が上位に出た割合、回答に含めた根拠、禁止情報を出さなかった割合も確認します。RAGASなどの評価手法を使う場合も、最終的には自社の問い合わせと業務ルールで人が判定します。

コストは、モデルの利用料だけでなく、検索基盤、ログ保存、API実行、監視、ナレッジ更新の工数で見積もります。すべての質問を高性能モデルへ送らず、定型分類は軽量モデル、複雑な切り分けや要約だけ高性能モデルへ振り分ける設計にすると、回答品質と費用のバランスを取りやすくなります。

精度とセキュリティを両立する設計

情シスのAIエージェントは、社内情報へアクセスし、場合によってはアカウントや端末を操作します。そのため、便利さだけでなく、誰が何を見て、何を実行できるかを設計段階で決めます。回答の正しさと権限の正しさは別の問題として管理します。

ハルシネーション対策では、検索結果が一定の信頼度に達しない場合に回答を止める閾値を設定します。回答には参照文書のタイトル、更新日、該当手順を表示し、ナレッジにない内容を一般知識で補完しないよう指示します。製品の仕様や社内ルールが変わる業務では、回答の有効期限も管理します。

誤回答を完全にゼロへできない領域では、AIの役割を「質問の整理」と「担当者への引き継ぎ」に限定します。利用者が何を試したか、エラーコード、端末ID、緊急度、希望期限を自動でまとめれば、有人担当者は最初から調査に入れます。AIが回答しないことを失敗とみなさず、安全な転送を成功として評価する考え方が重要です。

プロンプトインジェクションは、利用者の入力や検索対象の文書に、AIの指示を乗っ取る文章を混ぜる攻撃です。NISTは、AIエージェントが外部データへ取り込んだ悪意ある指示によって意図しない行動を取る「エージェント・ハイジャック」の評価を進めています（出典：NIST「Strengthening AI Agent Hijacking Evaluations」、2025年）。情シス向けの手順書に管理者用の秘密情報や解除方法を混在させないことも、重要な予防策です。

対策として、入力と取得文書を命令として扱わない境界を設け、HTMLやスクリプト、埋め込まれた指示を無害化します。ツール呼び出しは許可リスト方式とし、ユーザーの権限を超える検索を禁止します。関数の引数をサーバー側で検証し、出力をそのままシェルや管理APIへ渡しません。NISTの内部向けRAGチャットボットの報告でも、プロンプトインジェクション、ハルシネーション、データ露出、未承認アクセスが主要な検討対象として挙げられています（出典：NIST IR 8579、2025年）。

利用者認証はSSOと多要素認証を基本にし、部署・役職・担当サービスに応じて検索範囲を制御します。全社員に同じFAQを見せるのではなく、一般利用者向け、情シス担当者向け、管理者向けにナレッジを分けます。氏名、社員番号、電話番号、スクリーンショットに写り込んだ個人情報をチャットへ入力しない注意文も、画面に明記します。

監査ログには、ユーザー、時刻、質問、検索結果、回答、アクション、承認者、APIの結果を残します。ログの保存先と保存期間は、社内規程や個人情報の扱いに合わせて決めます。外部モデルへの学習転用の有無、データの保管場所、暗号化、障害時の停止方法、ベンダーのインシデント報告手順も、稟議前に確認します。

人とAIの役割分担・エスカレーション設計

AIエージェント導入の成否は、AIがどれだけ回答できるかだけでなく、回答できない案件をどれだけ早く適切な人へ渡せるかで決まります。定型対応はAI、例外判断と高リスク操作は人、という境界をあらかじめ決めておくと、利用者も担当者も安心して使えます。

エスカレーション条件は、回答の信頼度だけでなく、業務影響とセキュリティリスクで定義します。例えば、複数ユーザーに影響する障害、特権アカウント、個人情報を含む相談、3回試しても解決しない相談、緊急度が高い相談は、即時に担当者へ送ります。利用者には、担当部署、受付番号、次の連絡時刻を返します。

担当者へ渡す情報は、質問の要約、利用者の所属、対象サービス、端末情報、エラーコード、実施済み手順、AIが参照した根拠、利用者が希望する期限です。これをITSMのチケットへ自動登録すれば、担当者が同じ質問を聞き直す必要が減ります。エスカレーション導線は、権限管理できる別フォームやチケット画面へ分離し、チャット欄に機密情報を自由入力させない設計にします。

有人担当者が解決した案件は、そのままFAQへ公開するのではなく、質問、原因、解決手順、適用条件、例外、公開対象を整理してから登録します。AIが解決できなかった質問を人が対応し、その履歴を次のFAQ候補にする循環を作ると、ナレッジ更新の負担を抑えられます。

一方で、情シス担当者だけが詳しい解除手順や例外対応を入力すると、一般社員に見せるべきでない情報が検索対象に入ることがあります。公開レベルを分け、ユーザー向け回答と管理者向け手順を別文書にします。導入後は、回答の評価だけでなく、ナレッジの所有者、レビュー期限、廃止ルールを運用に組み込むことが大切です。

導入判断のためのチェックリスト

製品や開発会社を比較するときは、生成AIのデモ画面だけで判断しないことが重要です。自社の問い合わせログを使い、回答、根拠、権限、エスカレーション、API連携まで確認します。次の観点をRFPや提案依頼書へ具体的に記載すると、見積もりと提案を比較しやすくなります。

利用者が普段使うTeams、Slack、社内ポータルのどこに窓口を置くかを決めます。そのうえで、ITSMのチケット作成・更新、Active DirectoryやIDaaSのアカウント操作、MDMや監視ツールの参照が可能か確認します。連携できるかだけでなく、読み取りと書き込みの権限を分けられるか、失敗時に再実行や取り消しができるかまで確認します。

クラウド型、閉域環境、既存ITSMを活用するハイブリッド型では、導入期間と運用負担が異なります。モデルの学習転用、データ保管地域、暗号化、SSO、監査ログ、バックアップ、障害時の有人窓口を比較表にして、セキュリティ部門と情シス部門の双方で確認します。

費用を比較するときは、AIモデルの利用料だけでなく、ナレッジ移行、RAG基盤、チャットUI、API連携、認証、監査ログ、テスト、運用保守を分けて見積もります。特に、Active DirectoryやITSMとつなぐ処理は、認証方式、エラー処理、承認画面、監査要件によって工数が変わります。「AIチャットを導入する費用」と一括りにせず、どの業務をどこまで自動化するかで比較します。

稟議では、削減できる問い合わせ件数だけでなく、平均対応時間、夜間の自己解決、重大インシデントへの集中、担当者の引き継ぎ時間を効果として示します。PoCの期間、対象ユーザー、対象FAQ、成功基準、撤退基準を明記すると、導入後に効果を説明しやすくなります。

よくある質問（FAQ）

情シス・ITヘルプデスクへのAIエージェント導入では、費用や精度だけでなく、既存システムとの連携と安全な運用がよく質問されます。代表的な疑問に、導入判断の基準を直接回答します。

パスワード忘れ、アカウントロック、MFA不通、VPN接続など、頻度が高く手順を標準化しやすい業務が適しています。最初は回答と申請受付から始め、本人確認や承認を組み込んだ自動実行へ段階的に広げます。

漏えいリスクはゼロではないため、SSO、権限分離、データ保管場所、学習転用の有無、入力と出力の監査ログを確認して導入します。RAGの検索範囲をユーザー権限に合わせ、機密情報を一般FAQへ混ぜないこと、AIから管理APIへ直接つながないことも必須です。

FAQを検索して回答することが目的なら、チャットボットやRAG検索で十分な場合があります。アカウント操作、ITSM起票、状態確認、承認など、複数の処理をつなぐ必要がある場合はAIエージェントが適しています。業務の複雑さとリスクを基準に、単純な検索はシンプルな仕組みで、アクションが必要な箇所だけエージェント化する判断が現実的です。

自己解決率、一次解決率、平均解決時間、有人転送率、再問い合わせ率、誤回答率、処理の成功率を組み合わせて測定します。削減件数だけでなく、担当者が高難度案件へ使える時間が増えたか、利用者の待ち時間が短くなったかも確認します。

まとめ

情シス・ITヘルプデスクのAIエージェントは、FAQの回答だけでなく、本人確認、ナレッジ検索、ITSM起票、API実行、完了報告までをつなげる仕組みです。成果を出すには、パスワードリセットなどの小さな業務から始め、課題、導入内容、効果を測定しながら対象範囲を広げます。

第一に、問い合わせ頻度が高く、失敗時の影響を限定できる業務から始めます。第二に、RAG用の文書を整理し、回答の根拠と更新日を示します。第三に、AIへ過剰な権限を与えず、承認、入力検証、監査ログ、有人エスカレーションを組み込みます。これらを満たして初めて、AIエージェントは現場で使い続けられる業務基盤になります。

最初の一歩は、過去3か月から6か月程度の問い合わせを分類し、件数、対応時間、再問い合わせ、本人確認の有無、システム連携の必要性を確認することです。その中から3業務を選び、200問程度の評価データと成功基準を作ります。自社に合うAIエージェントの構成、既存ツールとの連携、ナレッジ整備、運用体制まで一体で検討することで、導入効果を説明できるプロジェクトにできます。

参考にした公開情報：SCSK「AIチャットボット PrimeAgent」、Microsoft Source Asia「Commonwealth Bank’s ChatIT」、NIST「Retrieval-augmented generation」、NIST IR 8579、NIST「Strengthening AI Agent Hijacking Evaluations」

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。