情シス/ITヘルプデスクのAIエージェント開発/構築の進め方/やり方/流れや方法/手法/工程/手順

情シス・ITヘルプデスクのAIエージェント開発は、企画から始め、データを整えたうえで設計・開発と評価を行い、運用改善へ進みます。対象業務と社内データを絞り、実行できる権限を回答のみから段階的に広げると、安全な定型業務の自動化につながります。

情シス・ITヘルプデスク向けAIエージェントの全体像

AIエージェントは、生成AIに社内データと業務ツールをつないだ業務実行システムです。

AIエージェントは、質問の意図を捉え、必要な情報や次の処理を選びます。

Microsoftの2025年Work Trend Indexは、31か国の3.1万人を対象に調査しました。

81%のリーダーは、今後12〜18か月でAIエージェントを自社のAI戦略に中程度以上組み込むと回答しています(出典: Microsoft Work Trend Index 2025)。

AIエージェントとRPA・シナリオ型チャットボットの違い

問い合わせを扱う技術は、それぞれ得意な入力と処理の範囲が違うため、目的に応じて使い分けます。

  • RPA:決められた画面操作やデータ転記を繰り返す
  • シナリオ型チャットボット:想定した質問と回答の組み合わせに対応する
  • AIエージェント:自然言語を受け付け、社内文書を検索してRPAやAPIを呼び出す

シナリオ型は、質問の表現が変わると選択肢に戻ることがあります。一方で、AIエージェントはRAG(検索拡張生成)で社内文書を参照するため、異なる言い回しからも意図を推定できます。

AIには自由な権限を持たせず、定義済みのワークフローの中で処理させます。アカウントロック解除では、まず本人確認を行い、対象を特定したうえで、実行してよいかを判定します。必要な承認を経て、Active DirectoryなどのAPIを実行し、結果を通知します。

判断が必要な例外は、AIが無理に回答せず有人窓口へ引き継ぐ設計が安全です。

基本アーキテクチャの4つの層

情報の準備から利用者との対話までを4つの層に分けると、構成を整理できます。

  • データソース:FAQ、操作マニュアル、過去チケット、障害情報、申請規程
  • 検索基盤:文書を分割・ベクトル化し、関連情報を取り出す
  • 生成AIモデル:検索結果を根拠に、回答や次の処理を提案する
  • 利用画面:Teams、Slack、社内ポータルなどで対話する

実行系では、生成AIと業務システムの間にツール層を置きます。このツール層で認証と入力検証、権限確認を行い、監査ログも残します。

ツールは、「チケットを起票する」「端末交換を申請する」「パスワードリセットを承認待ちにする」のように、狭い機能単位で作ります。

ツールでは、引数の型と許可範囲を固定しておけば、誤った値を実行前に拒否できます。

導入で任せられる業務

情シスでは、受付と回答のほか、申請と承認、チケット更新、定型処理を一連のサービスとして設計できます。

Microsoftも、ITヘルプデスク向けエージェントの役割を、受付と振り分け、定型実行、例外時の引き継ぎとして整理しています(出典: Microsoft Learn、Workplace and IT services pattern)。

一次対応に適したパスワード関連の業務

最初の対象業務には、パスワード忘れ、アカウントロック、MFA不通の3業務をおすすめします。

  • パスワード忘れ:本人確認のあと、FAQを示すかリセットへ案内する
  • アカウントロック:対象と実行の可否を確かめてから処理する
  • MFA不通:利用状況を聞き分け、適切な手順へつなぐ

「ログインできない」という相談では、エラーの種類と利用サービス、本人確認の状況を聞き取ります。

聞き取った内容によって、FAQを示すか、リセット処理へ進むかを決めます。

候補には、VPNやWi-Fi、端末初期設定のほか、ソフトウェア申請やプリンター、会議室機器もあります。ただし、人事・給与・個人情報・退職者の処理まで初期に広げると、権限と例外が増えます。

月間件数が多く、解決手順が標準化された業務であれば、導入効果を測りやすくなります。

他社事例の対象範囲と件数の見方

他社の事例は、問い合わせの規模と対象範囲を分けて読み、自社と比べます。

  • ソフトバンク:約3.6万件の質問・回答データを活用
  • LIXIL:導入初期に約250通りの質問・回答を整備
  • SCSK:月1万件を対象に適用範囲を絞り、担当者対応件数を20〜25%削減

他社の成果は、対象業務を限定し、回答データと運用を整えた結果として捉える必要があります。

コマニーでは若手社員がAIエージェントを作成・運用し、400アカウント以上で稼働しています。

東亜建設工業はTeamsのAIヘルプデスクとUiPathを連携させ、アカウント登録などを自動化しています。

自社と比べるときは、利用者数や問い合わせ件数に加えて、削減の対象、有人対応の残し方、ナレッジの更新体制を見ます。

情シス・ITヘルプデスクAIエージェント開発の進め方

情シス向けAIエージェント開発が、企画、データ整備、設計・開発、評価、運用改善へ進む流れ図。
運用改善までを一続きの工程として捉えられます。

開発は、企画からデータ整備、設計・開発、評価を経て、運用改善へ進めます。

PoCをデモだけで終わらせないため、認証やログ、権限、問い合わせ対応も小さく含めます。

最初は3〜5業務程度から始めると、精度と業務効果を同時に確かめられます。

要件定義・企画での対象業務と成功条件

はじめに問い合わせログと評価指標をそろえ、対象範囲と達成条件を決めます。

  • ログ分析:直近3〜6か月の件数、カテゴリ、解決時間、再問い合わせ、移管先を整理
  • 目標設定:一次解決率と誤案内件数の目標、平均初回応答時間の短縮幅を決める
  • 評価指標:正答率、根拠提示率、適切な有人移管、利用者満足度も見る

回答率だけを見ると、自信のある誤答を見逃すおそれがあります。そのため、業務上の正しさと安全性も評価に含めます。

利用するチャネルも決めます。Teams中心ならTeamsアプリ、Slack中心ならSlack bot、全社員が使う社内ポータルならWeb画面が候補になります。

チャネルを増やすほど、認証やログ、履歴が分散します。このため最初は一つに絞り、既存のITSMへチケットを集めると、運用を回しやすくなります。

RAG用データの整備と検索精度

検索の品質を保つには、文書の鮮度と内容を整え、形式に合わせて分割します。

  • 文書管理:所有者、更新日、対象システム・社員、機密区分を付け、廃止文書を除く
  • 形式変換:Word・PDFは見出し単位、Excelは行列関係を保ってテキスト化
  • 検索補助:画面画像に説明を付け、略語や言い換えをメタデータにする

古い手順や重複したFAQ、部署ごとに違う呼び方、前提の書かれていない文は、誤答を招きます。モデルの性能だけでなく、参照文書の質が回答を大きく左右します。

Excelの情報は、「対象OS」「手順」「例外」「問い合わせ先」などの項目に組み替えます。また、パスワード忘れやログイン情報不明、認証失敗は、同じ意図の質問として結び付けます。

一つのチャンクに複数の質問の回答を詰め込まず、質問・条件・手順・注意事項が一緒に検索される粒度にします。

設計・開発・テストでの実行権限の段階的な解放

回答の検証から始め、取り消しやすい処理を経て、承認付きの変更処理へ進みます。

  • 回答のみ:質問の分類や検索結果、回答の根拠、未解決率を見る
  • 下書き・起票:チケットの起票や申請の下書きを加える
  • 変更処理:本人確認と人の承認を経て、一部の利用者へ広げる

パスワードリセットやアカウントロック解除は、本人確認と承認を必須にしたうえで試します。

テストには、匿名化した実際の問い合わせに加えて、曖昧な質問や誤った前提を含む質問、悪意ある指示を含む質問を使います。正答率のほか、根拠がないときに回答を控えるか、権限外の情報を見せないか、依頼を二重に実行しないかも確かめます。

RAGASなどの評価フレームワークを使う場合でも、業務上の正しさは情シスの担当者が確認します。

ポイント

権限を広げる段階は、回答の正答率と誤答の傾向を確かめてから進めるのが目安です。要件と評価指標を先に決めておくと、次の段階へ進むかどうかの判断がつきやすくなります。

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

社内データを中心に、根拠表示、権限外の文書、監査ログ、多要素認証を配置した安全設計図。
回答の根拠とアクセス制御、実行記録を組み合わせています。

情シスでは、何を見せるか、何を実行するか、失敗時の責任者を先に決めておきます。そのうえで、回答には根拠を添え、権限外の文書は検索対象から外し、実行を監査できる状態にします。

契約で閉域クラウドや学習転用なしを確かめるとともに、実際のデータの流れと管理者権限も確認します。

ハルシネーションの抑制と回答制約・評価セット

回答ルールとシステム側の制御を組み合わせると、根拠のない回答や誤操作を抑えられます。

  • 回答条件:根拠がないときは回答せず、条件不足なら追加質問する
  • 根拠表示:参照した文書名と更新日を表示する
  • 実行制御:検索スコア、許可ツール、回答形式、危険操作の承認を定める

プロンプトだけに頼るのは危険です。そこで、モデルの自由度は複数の制御で制限します。

本番の前に、代表的な質問を100〜200問集め、正解、許可された根拠、期待する移管先を決めておきます。モデルを変えたときやFAQを更新したときには、そのたびに再テストします。

正答率、誤答率、未回答率を比べるほか、引用の正確さや個人情報の出力の有無も確認します。利用者の権限を超えた情報を表示した場合も、失敗として扱います。

プロンプトインジェクションへの多層防御

プロンプトインジェクションは、文書や利用者の入力に含まれた指示によって、AIに本来と異なる行動をさせる攻撃です。

  • 指示を分離:信頼できる指示と参照データを分け、文書の命令を実行しない
  • 情報を制限:外部入力を整え、ツールの戻り値を必要最小限にする
  • 高リスク操作:画面確認や担当者承認を求め、ログとテストで防御を更新する

OpenAIは、外部コンテンツに潜んだ悪意ある指示がAIの判断を誘導するリスクを、ソーシャルエンジニアリングに近い課題として説明しています(出典: OpenAI「Understanding prompt injections」、2025年)。

社内FAQに「この指示を最優先せよ」といった文が混入する場合も想定しておきます。さらに、パスワード変更や権限付与、データ削除は、AIだけで完了させないようにします。

失敗した入力と実行のログを保存し、定期的なレッドチームテストで防御を見直します。

SSO・権限・監査ログの運用設計

認証とアクセス制御を設け、利用者や担当者の情報を適切に扱えるようにします。

  • アクセス管理:SSOと多要素認証を基本とし、部署・役職・端末状態で検索対象とツールを制御する
  • 監査記録:利用者、質問、参照文書、回答、ツール、承認者、結果、移管先を残す
  • 個人情報:入力上の注意を示し、権限管理された申請フォームへ案内する

一般社員に管理者向けの解除手順や例外対応を見せないよう、利用者向けの説明と管理者向けの手順は、データベース上でも分けます。

チャットに氏名や社員番号、電話番号、画面上のパスワードを入力しないよう、注意文を表示します。また、スクリーンショットへの写り込みに関するルールも決めておきます。

ポイント

安全性は、回答の根拠、権限、実行の監査、人への移管を重ねて確かめるのが目安です。どの失敗をどの制御で止めるかを一覧にしておくと、本番前の確認で抜けが出にくくなります。

人とAIの役割分担と有人へのエスカレーション

未解決の質問から有人の回答、ナレッジ、FAQの改善へつなぐ循環図。
有人対応で得た内容を次の問い合わせに生かします。

導入の目的は、担当者を減らすことより、人が判断する案件に集中できる状態をつくることにあります。定型の質問はAIが受け持ち、高リスクの変更や例外は人が扱います。

また、AIで解決できない場合も、利用者に同じ質問を繰り返させないようにします。会話履歴や利用者情報、エラー、実施済みの手順、参照文書をチケットへ引き継いでおくと、利用者の体験の向上につながります。

有人へ渡す条件と引き継ぐ情報

移管の判断条件と、担当者が次の対応を続けられる情報を、あらかじめ決めておきます。

  • 移管条件:根拠不足、低い検索スコア、本人確認失敗、質問の反復
  • 重大事象:重大障害や情報漏えいが疑われる場合
  • 案内内容:担当グループ、優先度、SLA、次の連絡方法

利用者には、「担当者に確認してください」で終わらせず、移管先と次の連絡方法まで伝えます。

担当者の画面には、会話や利用者情報、エラー、実施済みの手順、参照文書を表示します。加えて、AIの提案を修正した場合は、その理由も記録します。

新しい言い回しや例外への対応を記録しておけば、FAQの改善に活かせます。

未解決ログをFAQへ戻すナレッジ循環

未解決の質問を定期的に見直し、有人の回答を検証してから、ナレッジに戻します。

  • 確認頻度:未解決質問を週次または隔週で確認する
  • 分類項目:FAQ候補、文書の重複、誤回答、移管の遅れに分ける
  • 公開前の整理:対象者、前提、手順、例外、更新日、問い合わせ先をそろえる

有人担当者の回答は、そのまま公開せず、内容を整えてから登録します。こうした循環を回すと、FAQ作成の負担を抑えられます。

PCセットアップやアカウント発行が問い合わせの原因になっている場合は、回答を増やすだけでなく、その業務の自動化やBPOも検討します。

ポイント

AIに任せるのは定型の質問に限り、高リスクの変更や例外は人が扱うのが目安です。移管の条件と引き継ぐ情報を先に決めておくと、有人対応への切り替えで利用者が迷いにくくなります。

情シス・ITヘルプデスクAIエージェントの費用相場と内訳

費用は、モデル利用料よりも、要件整理やナレッジ整備、認証・権限、連携の工数で大きく変わります。評価や運用設計の工数も、費用に影響します。

国内の公開情報では、外注PoCが約100万〜500万円、小規模PoCが150万円前後から、本番開発が1,000万円以上という例があります(出典: WEEL、Cloudpack、2025〜2026年公開情報)。

これらは固定の価格ではなく、対象範囲をそろえて比べるための目安です。

PoCの費用の仮置き(100万〜500万円程度)

PoCの費用は、検証する業務、連携の範囲、評価の内容によって変わります。

  • 基本範囲:業務選定、数本のFAQ、チャット画面、RAG検索、基本評価、簡易ログ
  • 下限に近い条件:認証や実行連携を含めず、回答を検証する
  • 上限に近い条件:チャット連携、ITSM、匿名化、評価データ作成を含める

TeamsやSlackへの組み込み、評価セットの問題数、改善サイクルの回数は、見積もりの段階で確認します。

本番化の費用の想定(500万〜1,500万円以上)

本番化では、回答機能に加えて、認証や権限、連携、復旧、監査に対応します。

  • 運用基盤:利用者認証、部署別権限、監査ログ、管理画面、障害復旧
  • 業務連携:ITSM、Active Directory、RPA、有人引き継ぎ
  • 品質確認:負荷試験、セキュリティレビュー

社内検索だけであれば、費用は比較的抑えられます。一方で、パスワード変更や権限申請を実行させると、設計・テスト・承認の工数が増えます。

運用費には、LLM・埋め込みモデルのAPIやベクトル検索、ログ保管が含まれます。さらに、監視や保守、FAQ更新、評価・改善、ライセンスも対象になります。

月額だけでなく、問い合わせ件数と1回あたりのモデル呼び出し回数をもとに、利用が増えた場合の上限を試算します。

運用・保守を本開発費の5〜10%程度とする公開された目安もありますが、実際の額は契約の範囲によって異なります。

ポイント

費用はモデル利用料よりも工数で大きく変わるため、PoCと本番化を分けて見積もりを比べるのが目安です。対象範囲がそろっていない金額同士は、単純に比べないようにします。

見積もりを取る際のポイント

FAQ検索だけのものと、認証・承認・システム操作まで含むエージェントでは、必要な工数が大きく異なります。そこで、見積もりを取る前に前提をそろえておきます。

  • 規模:対象ユーザー数、月間問い合わせ件数、目標KPI
  • 対象範囲:チャネル、業務、利用文書、連携先、実行権限
  • 未確定事項:未確定の点は、複数の前提条件を置いて見積もりを依頼する

見積もりの作業範囲と成果物

費目ごとの作業内容と、FAQ整備の数量を確かめておくと、追加費用を見落とさずに済みます。

  • 設計・開発:要件定義、RAG・プロンプト設計、画面、API連携
  • データ作業:棚卸し、文書清掃、表記統一、PDF・Excel変換、個人情報のマスキング
  • 導入・運用:テスト、セキュリティレビュー、教育、運用引き継ぎ

「FAQ整備一式」とだけ書かれた見積もりは、対応する文書やページ、質問数が不明確になりがちです。よって、数量を成果物に明記してもらいます。

開発会社の選定と業務連携の実績

技術の実績に加えて、失敗時に安全に止める方法を説明できるかを確かめます。

  • 連携実績:RAG、Teams・Slack・ITSM、Active Directory・RPA、SSO
  • 運用実績:監査ログと継続的な改善
  • デモ確認:曖昧・根拠なし・権限外・承認が必要な依頼への対応

デモでは、拒否や追加質問、有人への移管の方法を見ます。流暢な回答よりも、失敗時の制御を重視します。

契約で決めるリスク分担と本番後の改善費用

誤回答や障害への対応責任と、継続運用に必要な費用を、契約で明確にします。

  • 障害対応:ログ調査、何時間以内に修正するか、サービス停止の条件
  • 変更対応:モデル・API変更、利用増加、文書更新、脆弱性対応の分担
  • 総額比較:初期費用、月額、従量課金、保守、追加作業を分けて比べる

改善の受け皿がなければ、初期費用を抑えても、エージェントは陳腐化します。そこで、1年目と3年目の総額を比べます。

追加のFAQ、連携、監査、データ移行も費用に含めて確認します。あわせて、PoCの成功条件と本番への移行条件、未達のときの成果物も決めておきます。

ポイント

見積もりは、規模、対象範囲、未確定事項をそろえてから依頼するのが目安です。作業範囲と成果物の数量、障害対応と費用の分担まで確かめておくと、後からの追加費用を防ぎやすくなります。

よくある質問(FAQ)

導入前に多い疑問として、費用、FAQの量、セキュリティ、連携を取り上げます。

情シス向けAIエージェントの開発費用はいくらですか?

回答だけを行う小規模なPoCなら100万〜500万円程度、本番運用まで含めると500万〜1,500万円以上が、一つの目安になります。

費用は、対象業務やFAQの量、認証、ITSMやActive Directoryとの連携、承認、セキュリティ要件によって変わります。成果物と前提条件も比べてください。

FAQが少なくてもAIエージェントを作れますか?

作れます。パスワード忘れやアカウントロック、MFA不通など3〜5業務の手順を整え、数十〜200問程度の評価データを用意する方法が現実的です。

FAQを増やす前に古い文書を除き、前提条件と例外を加えるほうが、回答品質を改善しやすくなります。

AIにパスワードリセットを任せても安全ですか?

本人確認と対象の照合、許可されたAPI、承認、監査ログを組み合わせれば、範囲を限って自動化できます。

初期は申請の作成や承認待ちまでにとどめ、失敗の条件と停止の手順を確かめてから、自動実行へ進むことをおすすめします。

TeamsやSlackと連携できますか?

連携できます。チャットを入口にして、RAG検索やITSMのチケット、承認、RPAやAPIの呼び出しを組み合わせる構成が一般的です。

連携先が増えるほど、認証と障害対応は複雑になります。まずは、利用頻度の高いチャネルと優先する業務を、一つずつ選びます。

まとめ

開発・構築で押さえる要点

対象業務を絞り、RAG用のデータを整えたうえで、回答、承認、実行の順に権限を段階的に広げます。精度の評価と安全対策は後回しにせず、人への引き継ぎとナレッジの更新も設計に含めます。

導入前の確認事項

導入前には、デモだけで判断せず、現場で安全に使い続けられる体制かどうかを見極めます。

  • 段階的な実装:定型業務を選び、ログとFAQを整え、回答から承認付きAPI実行へ進める
  • 品質と安全性:データ前処理、根拠提示、定量評価、多層防御、人への移管、未解決ログの再利用を行う
  • 費用:API利用料、保守、改善、監査、FAQ更新を含め、初期費用と1年目・3年目の総額を比べる
  • 責任と移行条件:業務・ナレッジ・セキュリティの責任者と維持担当を決め、PoCから本番へ進む条件を数値で合意する

主な情報源は、Microsoft Work Trend Index 2025、Microsoft LearnのWorkplace and IT services pattern、OpenAIのPrompt injections解説、ServiceNowのITSMエージェント資料、WEELの生成AI受託開発費用情報です。企業事例と現場ノウハウは、ripla が調査した内容をもとに整理しています。

会社紹介

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

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

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

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

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

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