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

情シス・ITヘルプデスクのAIエージェントの活用方法は、問い合わせの頻度、本人確認や承認の要件、既存システムとの連携範囲によって変わります。

効果が出やすいのは、頻度が高く手順を標準化しやすい業務です。パスワード対応、VPNや端末のトラブル、SaaS申請、社内FAQの一次回答が代表例です。

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

画面、社内FAQや手順書、過去チケット、ベクトルデータベース、生成AIモデルで構成するAIエージェントの基本アーキテクチャ図。
回答の根拠は検索対象のナレッジにあります。

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

従来のRPA・シナリオ型チャットボットとの違い

違いは、問い合わせへの回答方法と、後続処理まで実行できるかにあります。

  • シナリオ型チャットボット:登録済みの選択肢や質問に答える仕組みです。
  • RPA:決められた画面操作やデータ移送を繰り返す処理です。
  • AIエージェント:曖昧な相談から意図を推定し、ナレッジ検索や複数ツールの呼び出しを行います。

たとえば、「VPNにつながらない」「出張先で認証アプリが使えない」といった相談が、処理の起点になります。従来の仕組みとの違いは、本人確認、端末情報の取得、チケット起票、担当者への引き継ぎまでつなげられる点です。

AIエージェントの基本アーキテクチャ

AIエージェントの中心は、社内FAQや手順書を検索する仕組みと生成AIモデルです。周辺では、検索に使う情報の保存や問い合わせの受け付けを、次の要素が担います。

  • 過去チケット:解決済みの問い合わせ記録も検索対象です。
  • ベクトルデータベース:文書を検索しやすい形で保存する仕組みです。
  • 画面:TeamsやSlackなどからの問い合わせを受ける窓口です。

問い合わせに応じて、まず検索システムが関連情報を取り出します。そのうえで、生成AIが根拠を踏まえて回答します。

NISTはRAGを、検索システムが知識ベースから情報を取り出し、モデルの文脈として回答に使う構成と定義しています(出典:NIST「Retrieval-augmented generation」、2025年)。

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

パスワード対応、VPN・端末の切り分け、SaaS申請、社内FAQの一次回答を4枚のパネルで示した活用事例図。
定型的な問い合わせから申請とナレッジ活用まで広がります。

発生頻度が高く、本人確認や手順を標準化しやすい業務は、効果が表れやすい領域です。事例では、問い合わせを受けてから解決または有人への引き継ぎまでを現場で使える粒度に分け、課題、導入内容、効果の順に紹介します。

事例1:パスワードリセットとアカウントロックの自動化

パスワード忘れやロックは営業時間外にも起き、そのたびに担当者が本人確認とリセットに追われます。MFA不通を含む3業務は問い合わせが多く、手順を整理しやすい領域です。自動化では、本人確認と権限の制御を組み合わせます。

  • 本人確認:社員番号などの入力を求めず、SSOや多要素認証済みの情報を引き継ぎます。
  • 許可操作:Active DirectoryやIDaaSのAPIを呼び出す処理です。
  • 高リスク相談:MFA不通の場合は、復旧方法を案内したうえで有人窓口へ送ります。

この仕組みにより、一次対応の待ち時間が短くなり、夜間・休日の自己解決率の向上につながります。

AIには管理者権限を渡さず、リセット要求を一時トークンに変換します。そのうえで、条件を満たした場合だけワークフローを実行します。

MicrosoftのCommonwealth Bank ChatITでは、端末遅延へのセッションリセットなどを実行します。1回の修正は平均2分で、従来の電話では平均17分かかっていました。

自動化の開始後6か月で、230万件超のメッセージと12,000件超のIT修正を処理したと報告されています(出典:Microsoft Source Asia「Commonwealth Bank’s ChatIT」、2025年)。

事例2:VPN・端末トラブルの切り分け支援

「つながらない」「PCが遅い」といった訴えからは、原因を特定しにくく、聞き返しが増えます。原因がOSや端末にある場合もあれば、VPNや認証、拠点網にある場合もあるためです。また、利用者には画面やエラーコードを探す負担もあります。

  • 情報収集:症状、時刻、場所、端末ID、ネットワーク種別を聞き取ります。
  • 診断・提案:端末の状態を確認し、影響範囲の限られた処理を示します。
  • 承認・引き継ぎ:実行前の承認を取り、解決しなければITSMへ送る流れです。

MDMや監視ツールから、端末の状態を取得します。提案する処理は、再起動、キャッシュ削除、VPNプロファイルの再配布などです。

実行前には、対象端末と処理を画面に表示し、利用者または担当者の承認を必須とします。改善しない場合は、情報と実施済みの手順をITSMチケットに添えて引き継ぎます。

診断結果を記録しておけば、聞き取りの時間を減らし、担当者ごとの切り分けの質をそろえやすくなります。同じ利用者から再度問い合わせがあった際も、診断結果をそのまま引き継げます。さらに、Microsoftの事例のように、チャットから限定的な自動修正までつなげると、電話を待つ時間も減らせます。

事例3:SaaSの利用方法とアカウント申請の連携

Microsoft 365、Slack、営業管理ツールは、それぞれ使い方や権限申請の手順が異なります。急ぐ利用者は、マニュアルで解決できる質問も情シスへ尋ね、担当者は同じ説明を繰り返します。

AIエージェントを使えば、案内から承認後の処理までをつなげられます。

  • 申請案内:部署、役職、目的の確認と、手順やフォームの提示。
  • 承認後の処理:権限付与まで行う場合の、ITSM等への登録と上長承認後のAPI呼び出し。
  • 例外管理:例外や高権限は自動承認せず、不足情報の回収と申請状況の通知に限る。

申請の不備が減り、情シスは高リスク案件に集中できます。受付、承認待ち、処理中、完了の状況を追跡して報告すれば、状況確認の追加問い合わせも減らせます。

事例4:社内FAQと過去チケットからの一次回答の作成

FAQや手順書に表記ゆれや古い情報が混在していると、新任者や拠点担当者は、正しい資料の検索に時間がかかります。一次回答の基盤になるのは、資料の整備と根拠の提示です。

  • 資料を整える:過去の問い合わせ、解決済みチケット、正式マニュアルを集める作業です。
  • 根拠を示す:回答への参照文書名と更新日の表示。
  • ナレッジを更新する:未解決の質問の洗い出しと、正式回答への反映。

文書には、サービス名や対象OS、対象者を示すとともに、更新日と機密区分を付けておきます。根拠がなければ、AIは「確認できない」と答えます。

精度を上げるには、FAQを増やすより、古い手順を削除し、質問と答えを一対一に対応させ、利用者の言い換えも登録する方が効果的です。

SCSKの事例では、月間1万件に対応し、問い合わせが25%減ったと紹介されています(出典:SCSK「AIチャットボット PrimeAgent」、2022年掲載・2026年閲覧)。未解決の質問を毎週確認して正式回答に反映すると、自己解決率の向上とナレッジの属人化の解消につながります。

ポイント

パスワード対応やVPN・端末のトラブル、SaaS申請など、頻度が高く手順を標準化しやすい業務から選ぶと効果が出やすくなります。自動化する範囲は、本人確認や承認が必要かどうかで決めます。

AIエージェントの導入の進め方

PoC対象の絞り込みから承認を含むAPI連携の設計、KPIと未解決ログによる改善へ進む導入フロー。
評価と改善を重ねながら対象業務を広げます。

まずは、頻度が高く失敗時の影響を限定できる業務でPoCを行います。モデルの導入は出発点で、対象業務、ナレッジ、権限、評価方法を一体で設計しながら、段階的に広げます。

PoC対象の絞り込み(パスワードリセットなど3業務)

PoCでは対象を絞り、評価用の質問と確認項目を先に用意しておきます。

  • 初期候補:頻度が高く手順を定義しやすい、パスワード忘れ、ロック、MFA不通のいずれかです。
  • 段階拡大:VPN切り分け、SaaS申請、端末診断へと範囲を広げます。
  • 評価:数十から200問程度の質問で、正答率、根拠提示率、有人転送の適切さ、1件あたりの対応時間を測ります。

給与、人事評価、重大なセキュリティインシデントなど、機密性や判断の影響が大きい業務は、初期の自動実行の対象から外します。

正常な質問に加えて、曖昧な質問、古い手順、権限外の依頼、悪意ある指示もテストします。実運用に近い評価データを先に作れば、導入後の「思ったより使えない」を防げます。

API連携とHuman-in-the-loop承認の設計

アクションを実行する場合は、誤処理を防ぐ制御が欠かせません。AIにリセット権限を直接与えず、検証関数だけを公開します。

  • 入力検証:依頼の内容や範囲を、関数側で確かめます。
  • Human-in-the-loop:権限付与や端末消去を、人の承認後に実行する仕組みです。
  • 記録:監査ログによる追跡。

関数側では、ユーザーID、対象システム、依頼理由を確認します。さらに、入力形式や所属、実行回数、許可時間帯も確認し、条件外であれば拒否します。

承認画面では、利用者と対象資産、処理の内容を示します。根拠や影響範囲、ロールバック方法も、承認前に見えるようにします。

監査ログには、入力と検索文書を保存します。関数呼び出し、承認者、結果もあわせて残します。

KPIの設定と未解決ログによる改善

実運用の質を測るには、AIの利用率に加えて、安全な回答と適切な引き継ぎも評価します。そのうえで、ログから改善点を探します。

  • 解決状況:自己解決率、一次解決率、有人転送率の測定。
  • 回答品質:再問い合わせ率、誤回答率、根拠提示率の確認。
  • ログ改善:未解決の原因の分類と、業務フローの見直し。

指標には、平均解決時間も含めます。自動化件数だけを追うと、誤案内が増えるおそれがあります。

「分からない」と安全に答えた件数や、適切な引き継ぎの割合も評価します。未解決ログは、週次または月次で確認します。

未解決の原因は、ナレッジ不足、検索失敗、権限不足などに分けて見ます。曖昧な質問や業務フローの問題も、同じ分類で捉えます。さらに、PCセットアップやアカウント発行を標準化すれば、問い合わせの発生源そのものを減らせます。

ポイント

導入は、失敗時の影響を限定できる業務のPoCから始め、対象業務やナレッジ、権限、評価方法を一体で設計します。評価データを先に作ると、段階的な拡大の判断がしやすくなります。

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

回答品質は、モデルの性能に加えて、情シスが正しい手順を管理しているかで決まります。成果を出すには、この管理が前提になります。

WordやExcelの文書は、回答に必要な単位に分け、更新日と対象範囲を付けて登録します。

古い文書の削除とFAQの検索単位への分解

重複した手順や旧製品名、廃止されたURLを整理し、個人メモも対象に含めます。Excelの表は、列と行の意味を保つことが大切です。そのうえで、サービス名や条件、手順は文章か構造化データとして書き直し、例外と問い合わせ先も同じように整えます。

図解PDFは、画像の中の前提と分岐条件をテキストにして残します。文書は、一定の文字数で区切らず、質問に一つの答えが成り立つ単位に分けます。

VPN手順、エラー別の対処、管理者向けの例外対応は、別々に登録します。検索を絞るため、サービス名やOS、拠点を付けます。加えて、公開対象、更新日、機密区分も付けておきます。

正答率とコストの同時評価

評価データには、実際の言い換えを含めます。たとえば、「パスワードを変えたい」「ログインできない」「認証が通らない」は、それぞれ検索語が異なります。

  • 検索評価:適切な文書が上位に出る割合。
  • 回答評価:根拠提示の状況と、禁止情報の抑制。
  • 費用評価:利用料と運用工数をあわせた比較。

正答率の測定には、RAGASなどの手法を使うこともできます。その場合も、自社の問い合わせと業務ルールに照らして、人が最終判定します。

費用には、モデル利用料や検索基盤、ログ保存を含めます。さらに、API実行や監視、ナレッジ更新の工数も見ておきます。

定型の分類は軽量なモデル、複雑な切り分けや要約は高性能なモデルに振り分けると、品質と費用のバランスを取りやすくなります。

ポイント

回答の精度は、モデルの性能に加えて、文書の整え方で決まります。古い文書を削り、更新日と対象範囲を付けて、質問に答えられる単位に分けることが出発点です。

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

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

根拠の提示と、回答できない場合の有人への引き継ぎ

回答の信頼性を保つために、検索の基準、参照情報、有人転送の扱いを定めておきます。

  • 根拠提示:文書名、更新日、該当手順の表示。
  • 回答制御:検索結果の信頼度が一定の閾値に届かないときは、回答を止めます。
  • 有人転送:質問内容と緊急度をまとめた引き継ぎ。

ナレッジにない内容は、一般知識で補わないよう指示します。仕様や社内ルールが変わる業務では、回答の有効期限も管理します。

誤回答が起こりうる領域では、AIの役割を質問の整理と担当者への引き継ぎに限ります。

試した内容、エラーコード、端末IDを、緊急度や希望期限とあわせてまとめておけば、担当者は最初から調査に入れます。安全に転送できた場合も、成功として評価します。

プロンプトインジェクションと過剰権限の防止

プロンプトインジェクションは、入力や検索文書にAIの指示を乗っ取る文章を混ぜ込む攻撃です。NISTは、外部データに仕込まれた悪意ある指示でAIが意図しない行動を取る「エージェント・ハイジャック」を評価しています(出典:NIST「Strengthening AI Agent Hijacking Evaluations」、2025年)。

  • 文書管理:秘密情報や解除方法を、手順書に混ぜないこと。
  • 入力対策:埋め込まれた指示やスクリプトの無害化。
  • 実行制御:許可リストとサーバー側検証の併用。

入力や取得した文書は、命令として扱わないようにします。ユーザー権限を超える検索も禁止します。関数の引数はサーバー側で検証し、出力をシェルや管理APIへ直接渡さないようにします。

NISTの内部向けRAGチャットボットに関する報告も、プロンプトインジェクション、ハルシネーション、データ露出、未承認アクセスを主要な課題に挙げています(出典:NIST IR 8579、2025年)。

SSO・権限管理・監査ログの最低要件

導入前に、認証、検索権限、個人情報、監査記録を設計し、社内規程や利用者の役割に合わせます。

  • 認証と検索範囲:SSO・多要素認証と役割別権限の設定。
  • 個人情報:チャットへの入力を控えてもらう、画面上の案内。
  • 記録と保管:操作ログとデータ保管条件の決定。

検索範囲は、部署や役職、担当サービスで制御します。あわせて、一般利用者、情シス、管理者のナレッジを分けておきます。

画面には、氏名や社員番号、電話番号、画像内の個人情報を入力しないよう注意文を示します。監査ログには、誰がいつ何を質問し、どの情報をもとに回答したか、どんな操作や承認、API結果があったかを残します。

ログの保存先と期間は、社内規程に合わせて決めます。稟議前には、学習転用や保管場所、暗号化を確認します。さらに、障害時の停止方法と、ベンダーの事故報告手順も確認します。

ポイント

回答の正しさと権限の正しさは別々に管理し、AIに直接の管理者権限は持たせません。実行は承認と入力検証を経た処理に限り、監査ログで追える状態にします。

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

定型対応はAIに任せ、例外判断と高リスクの操作は人が担うように分けます。回答できない案件を適切な担当者へ早く渡せるかで、導入の成否が左右されます。

有人引き継ぎに必要な情報の整理

引き継ぎの判断は、回答の信頼度だけでなく、業務への影響やセキュリティリスクで行います。あわせて、担当者がすぐ調査を始められる情報もそろえておきます。

  • 即時転送:複数ユーザー障害、特権、個人情報、緊急案件に当たる場合。
  • 利用者への連絡:担当部署、受付番号、次の連絡時刻の提示。
  • 担当者への情報:質問の要約、所属、端末、手順、希望期限の共有。

3回試しても解決しない相談は、即時に送ります。そのうえで担当者には、対象サービスやエラーコード、参照根拠を渡します。ITSMチケットに情報を登録しておけば、聞き直しを減らせます。

引き継ぎ先は、権限管理されたフォームや画面に分けます。また、チャットでは、機密情報を自由に入力させない運用とします。

未解決チケットのFAQへの反映とナレッジ育成

解決した案件は、すぐに公開せず、質問や原因、手順を整理して登録します。適用条件や例外、公開対象も合わせて整えます。

未解決質問の対応履歴をFAQ候補にすると、更新にかかる負担を抑えられます。解除手順や例外対応は、一般社員向けの検索に入らないよう公開レベルを分けておきます。利用者向けの回答と管理者向けの手順は、別々の文書にします。

回答評価に加えて、ナレッジの所有者やレビュー期限、廃止ルールも運用に組み込みます。

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

製品や開発会社は、生成AIのデモ画面を判断材料の一つとして見たうえで、自社のログを使って回答、根拠、権限、引き継ぎ、API連携を確認します。

確認項目をRFPや提案依頼書に具体的に書いておくと、見積もりや提案を比べやすくなります。

Teams・Slack・ITSM・ID基盤との連携の確認

窓口の場所と連携先を確かめ、権限や障害時の扱いまで含めて選びます。

  • 窓口と業務連携:チャット、ITSM、ID基盤、MDM等との接続可否。
  • 権限と復旧:読み書き権限の分離、再実行、取り消しの可否。
  • 環境と安全性:SSO、構成、データ保護、監査、バックアップの比較。

窓口は、Teams、Slack、社内ポータルから選びます。加えて、ITSMの作成や更新、Active DirectoryやIDaaSの操作、MDMや監視ツールの参照が可能かも見ます。

読み書きの権限を分けられるか、失敗時に再実行や取り消しができるかも確かめます。構成によっても差が出ます。クラウド、閉域、既存ITSMを組み合わせるハイブリッド型では、導入期間や運用負担が異なります。

学習転用や保管地域、暗号化といった項目は、比較表にまとめます。障害時の有人窓口も同じ表に入れ、セキュリティ部門と情シス部門で確認します。

稟議に向けた費用の内訳(初期構築・連携・運用)

見積もりでは、構築・連携・運用の費目を分けます。効果測定の条件も、稟議に含めておきます。

  • 費用内訳:モデル、ナレッジ、基盤、連携、認証、保守の区分。
  • 効果指標:問い合わせ、対応時間、自己解決、引き継ぎの指標。
  • PoC条件:期間、対象、成功基準、撤退基準の明記。

モデル利用料のほか、ナレッジ移行やRAG基盤、チャットUIを見積もります。さらに、API連携や認証、監査ログ、テスト、保守も見積もります。

Active DirectoryやITSMとの連携工数は、認証方式やエラー処理、承認画面、監査要件によって変わります。「AIチャット導入費」とひとまとめにせず、自動化する業務の範囲をそろえて比べます。

効果は、問い合わせ数や平均対応時間で示します。加えて、夜間の自己解決や重大案件への集中、引き継ぎ時間も示します。

ポイント

製品や開発会社は、自社のログを使って回答、根拠、権限、引き継ぎ、API連携を確かめて比べます。費用を初期構築・連携・運用に分けておくと、稟議で比べやすくなります。

よくある質問(FAQ)

費用や精度、既存システムとの連携、安全な運用について、代表的な疑問に導入判断の基準から答えます。

情シスのAIエージェントで最初に自動化すべき業務は何ですか?

パスワード忘れやロック、MFA不通など、頻度が高く標準化しやすい業務です。まずは回答と申請受付から始め、本人確認や承認を伴う自動実行へ広げていきます。

社内情報をAIに入力しても情報漏えいしませんか?

情報漏えいのリスクは、ゼロにはなりません。そのため、SSO、権限分離、保管場所、学習転用の有無、入出力ログを確認します。

RAGの検索範囲はユーザー権限に合わせ、機密情報は一般FAQに混ぜません。AIから管理APIへ直接つながない設計にします。

AIチャットボットとAIエージェントはどちらを選ぶべきですか?

FAQ検索と回答が目的であれば、チャットボットやRAG検索で足りる場合があります。

アカウント操作やITSM起票、状態確認、承認など、複数の処理をつなぐ必要がある場合は、AIエージェントが適しています。

判断の基準は、業務の複雑さとリスクです。単純な検索はシンプルな仕組みで済ませ、アクションが必要な部分だけをエージェント化します。

AIエージェントの導入効果は何で測ればよいですか?

導入効果は、解決の面と品質の面を組み合わせて測ります。解決の面では、自己解決率、一次解決率、平均解決時間、有人転送率を見ます。品質の面では、再問い合わせ率、誤回答率、処理成功率を確認します。

削減件数だけでなく、高難度案件に使える担当者の時間や利用者の待ち時間も確認します。

まとめ

情シス向けのAIエージェントは、FAQへの回答にとどまらず、本人確認や検索、ITSM起票、API実行、完了報告までをつなぎます。

小さな業務から始め、課題や導入内容、効果を測りながら、対象範囲を広げていきます。

導入で押さえる3つの原則

導入を現場で続けるには、対象業務、回答根拠、実行権限の3点を合わせて設計します。

  • 対象を絞る:頻度が高く、失敗時の影響を限定できる業務からの着手。
  • 根拠を整える:RAG文書の整理と、回答への根拠・更新日の表示。
  • 権限を制御する:承認、入力検証、監査ログ、有人引き継ぎの組み込み。

これらを満たせば、AIエージェントを現場で使い続けられる業務基盤になります。

問い合わせログからのPoC対象の決定

まずは、過去3か月から6か月程度のログを分類します。件数、対応時間、再問い合わせ、本人確認、連携の必要性を確認します。

そのうえで、3業務を選び、200問程度の評価データと成功基準を作ります。構成や既存ツール連携、ナレッジ、運用体制を一体で検討すれば、効果を説明できるプロジェクトになります。

参考にした公開情報: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実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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