情シス/ITヘルプデスクのAIエージェント開発/構築の発注/外注/依頼/委託方法について

情シス・ITヘルプデスクのAIエージェント開発は、対象業務を絞り、ナレッジを整え、PoCで品質を測ってから連携範囲を広げる流れで進めると、定着につながります。

AIシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。

情シス・ITヘルプデスクのAIエージェントの概要

情シス・ITヘルプデスクのAIエージェントは、利用者の質問を理解して社内ナレッジを検索し、回答する仕組みです。条件によっては業務システムを操作したり、担当者へ引き継いだりすることもできます。

発注時には、「生成AIを導入する」と決めるだけでは足りません。どの問い合わせを、どの権限で、どこまで完了させるかを定義しておきます。

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

従来型の回答や操作と比べると、AIエージェントは判断できる範囲が広くなります。そのぶん、実行時の権限設計も欠かせません。

• シナリオ型チャットボット：用意した選択肢やキーワードに沿った回答。
• RPA：決められた画面操作を、正確に繰り返す仕組み。
• AIエージェント：「VPNにつながらない。昨日までは使えた」という相談から意図を推定し、関連手順を検索して必要な確認を挟み、次の処理を選ぶ。
• 権限設計：自律性が高いほど誤操作の影響も大きいため、回答と実行は別の権限で扱う必要があります。

基本アーキテクチャと発注範囲

構成要素と発注範囲をそろえておくと、本番運用まで含めた見積もりを検討できます。

• データと検索：FAQ、マニュアル、過去チケットをデータソースに、ベクトルデータベースと生成AIモデルを組み合わせる形。
• 利用者と業務システム：TeamsやSlackなどのチャットUIと、ITSMやActive Directoryへ接続するツール層も含めます。
• 外注範囲：画面開発に加えて、データ整備や認証・権限、監査ログ、テスト、運用引き継ぎまで範囲に含めます。
• 見積もりへの影響：発注範囲が曖昧だと、安いPoCの見積もりが本番運用で大きく膨らみます。

AIエージェントの発注形態の選び方

問い合わせ削減を早く検証するならSaaS型か短期PoCが、既存システムの操作まで求めるなら個別開発型が候補になります。さらに、ナレッジ更新や一次対応の人手も不足していれば、BPOを組み合わせます。

方式は、製品名で選ぶのではなく、業務の標準化度、社内の運用担当者、セキュリティ要件、将来の拡張性をもとに決めます。

SaaS型・PoC型・BPO型の使い分け

方式ごとに適用範囲と制約が異なるため、比べたうえで自社に合う発注形態を選びます。

• SaaS型：初期構築を抑えやすく、標準的なFAQ検索や有人への引き継ぎを短期間で始められる。
• PoC型：対象を絞ったうえで、回答率や有人転送率を検証する。
• BPO型：AIで解決できない問い合わせ対応と、FAQへの履歴反映も委託できる。

SaaS製品は、独自の承認ルールやActive Directory操作に仕様が合わないこともあります。

PoCの対象は、パスワード忘れ、アカウントロック、MFA不通など、3本程度が目安です。

準委任・請負・月額運用契約の選択

工程ごとに何を成果とするか、要件がどこまで確かかに応じて契約を使い分けると、発注範囲を整理できます。

• 準委任契約：企画、データ整備、PoCなど、要件が変わりやすい業務に合います。
• 請負契約：完成機能と受入条件を明確にできる本番開発で、候補になります。
• 月額運用保守契約：プロンプト調整、FAQ更新、ログ分析の業務を切り分け、開発費と継続費を別々に管理します。

契約を一本にまとめる場合も、開発、データ更新、障害対応、追加開発の単価は分けて記載してもらいます。

RFPと要件整理で決めること

RFPでは機能一覧に加えて、業務設計を示します。まず、対象ユーザーと問い合わせ量、業務の完了条件を書きます。そのうえで、参照データと連携先、権限を明記し、品質指標と運用体制も示します。

ベンダーごとに前提が違うと、見積もりを同じ条件で比べられません。そのため、共通条件と、提案してほしい選択肢を分けて記載します。

対象業務とKPIの定義

初期対象を選ぶには、まず問い合わせログから業務量と処理状況を把握します。そのうえで、成果を測るKPIを決めます。

• ログの確認：直近3か月から12か月の件数、対応時間、再問い合わせ率、解決時間、引き継ぎ先を分類する。
• 初期対象：頻度が高く、手順が決まり、誤操作の影響を限定できる業務。
• KPI：一次解決率、正答率、適切な有人転送率、平均対応時間、誤操作件数、FAQ更新日数を組み合わせて測る。

成果は「AI利用者数」だけでは測れません。たとえばSCSKの事例では、対象を絞ったことで担当者の対応件数が20〜25％減ったとされています。

データ・連携・非機能要件の明文化

データの検索精度と連携時の安全性を保つために、RFPに何を書くかを整理します。

• データ：FAQ、操作マニュアル、過去チケット、社内規程について、保存場所と更新者を定める。
• 連携先：TeamsやSlack、ServiceNowなどのITSM、Active Directory、RPAの有無を示す。
• 非機能要件：SSOや多要素認証、保管地域、学習利用の有無、監査ログの保持期間を指定する。

WordやPDFは、見出しや表、注記が崩れると検索精度が下がります。一方、Excelは一行に一質問を書き、製品名や部署、適用版、公開範囲などを付けます。

受入条件とテストデータ

受入条件には、平均正解率と重要質問の最低正答率を置きます。さらに、根拠提示率や回答不能時の案内を含め、権限外情報の拒否や実行前の承認表示も確認できるようにします。

テストに使う質問は、個人情報を除いて匿名化します。そのうえで、表記ゆれや誤字、攻撃的な入力も含めてテストします。

RAGの検索評価と生成回答の評価は、分けて行います。評価には、RAGASなどの評価フレームワークを使うか、同じ質問をリリース前後で比べる方法があります。

発注からリリースまでの進め方

発注後は、企画、データ整備、PoCの順に進めます。そのあとは、本番設計、テスト、段階リリース、運用改善へと続きます。

各工程の終了条件を決めておき、次の工程へ進むかどうかは発注側と委託先が共同で判断します。工程ごとに判断すれば、回答が少し良いだけで本番に投入してしまう事故を防げます。

パスワード関連の最小構成によるPoC

PoCでは、本人確認や実行条件を決めやすく、問い合わせ件数と処理時間で効果を測れる業務から始めるのが基本です。パスワード関連は、対象アカウントや失敗時の案内も定義しやすい業務です。

• 対象業務：パスワード忘れ、アカウントロック、MFA不通など、3本程度に絞る。
• FAQ：数本から200問程度を用意し、実際の利用者に試してもらう。
• 記録：正答率に加えて、回答できなかった内容と、人へ渡すべき質問を残す。

RAGの精度を左右するナレッジ前処理

RAGは、質問に近い文書を検索して生成AIへ渡す仕組みです。ただし、元データが古かったり、重複していたり、部署ごとに呼び方が違ったりすると、高性能なモデルでも回答が安定しません。

発注先には、文書を一覧にして古いものを見分ける方法を確認します。あわせて、版数の管理や重複の排除、表記の統一、チャンク分割、アクセス権の引き継ぎ方も確かめます。

「全文をベクトル化する」だけでなく、表や図解PDFのテキスト化と、検索対象から外す文書まで説明できる会社を選びます。

API連携とHuman-in-the-loop承認

AIが実行できる操作権限と承認の流れ、処理結果の扱いを決めて、安全な連携範囲を設計します。

• 権限：Active DirectoryのパスワードリセットやITSM起票の場合でも、LLMに管理者権限を直接持たせない運用。
• API検証：AIの意図とパラメータを制限付きAPIに渡す前に、対象者、操作、入力値、実行回数を検証する。
• 高リスク操作：アカウント無効化や権限変更では、本人確認と担当者承認を必須にする。
• 処理結果：東亜建設工業のようなTeamsとRPAの連携では、成否やタイムアウトをITSMへ返し、利用者へ通知する形。

AIエージェント開発・構築の費用相場

2026年時点の費用は、ナレッジ整備や認証、連携、テスト、運用体制などを積み上げて決まります。利用人数やモデル料金は、その一部にすぎません。

「AIチャットボットはいくら」と一つの金額で比べるのは危険です。次に示すのは発注計画の実務上の目安で、実際の見積もりでは、対象範囲と品質条件をそろえて比べます。

PoC・本番構築・連携開発の目安

構成ごとの予算目安を比べたうえで、連携範囲やデータ量に応じて見積もることになります。

• 小規模PoC：FAQ検索とチャットUIの検証は、一般に数十万円から数百万円程度が検討帯です。
• 本格PoC：SSO、権限管理、評価用テストセット、Teams連携を含み、100万円台から500万円前後のケースがあります。
• 本番構築：複数部署のナレッジとITSM、Active Directory、RPAを含み、500万円から1,500万円程度です。
• 複雑な構成：複雑な業務フローや複数システムを含む場合は、1,500万円超も想定しておきます。

ここでの金額は相場を断定するものではなく、データ量と連携数を基準にした予算の目安です。

ランニング費用と見積書で分ける項目

月額費用と見積書で分ける項目を整理しておくと、継続費を比べやすくなります。

• 利用料：AIモデル、検索基盤、ユーザー数や実行回数に応じたSaaS料金。
• 運用費：監視、FAQ更新、調整、有人対応、障害対応。
• 見積項目：初期費用、月額固定費、従量課金、追加連携、データ更新、定例会、緊急対応。
• 費用抑制：簡単な質問に軽量モデルを使い、高性能モデルを全件には使わない設計。

PwC Japan「生成AIに関する実態調査2026 春」では、ランニングコストを初期開発費や導入費と分けて集計しています（出典：PwC Japan、2026年）。

ROIと損益分岐点の計算

ROIには、対応時間の削減に加えて、夜間の一次回答や品質の均一化、属人化の解消、チケット情報の欠落防止も含めて見ます。

たとえば、月3,000件のうち30％をAIが適切に処理し、1件あたり8分削減できる場合、月720分、つまり12時間分の削減です。

人件費単価や運用費、再問い合わせによる増分を入れて、投資回収期間を計算します。あわせて、KPIの母数と計測期間をRFPに記載しておくと、自社の効果と他社事例を分けて見られます。

委託先選定と見積比較のポイント

見積金額の安さだけでなく、同じ業務範囲と受入条件をそろえて比べます。そのうえで、現行業務を理解しているか、データをどう扱うか、連携をどう実装するか、テストと運用の役割をどこまで受け持つかを確認します。

業界名より業務の近さで見る実績

生成AIの導入社数は、判断材料として十分ではありません。確認したいのは、情シス・ITヘルプデスクで、問い合わせ分類、ナレッジの版管理、本人確認、ITSM連携、アカウント操作まで実装した事例です。

たとえば、ソフトバンクには、約3.6万件のQ&Aデータを使った社内特化型生成AIの事例があります。LIXILは導入初期に約250通りの質問と回答を用意しました。

導入事例は、データ量と初期設計がどの程度具体的かを確かめる材料になります。

セキュリティとガバナンスの確認

提案を比べるときは、データ保護、認証、権限、監査がどう扱われるかを確認します。

• データ保護：学習利用、暗号化、保管地域、テナント分離、バックアップの扱い。
• 認証と権限：SSO、多要素認証、権限の継承、委託先による再委託の可否。
• 運用統制：監査ログ、エージェントの所有者と目的、付与した権限、停止手順。

Microsoftは2025年にEntra Agent IDを案内しました（出典：Microsoft Learn、2025〜2026年）。Entra Agent IDは、AIエージェントを人やアプリと同様に識別し、認証・認可・ライフサイクルを管理します。また、AIエージェントを共有管理者アカウントとして扱う提案は避けます。

見積比較表で確認する作業の範囲

各社の見積は、工程と作業項目をそろえて並べたうえで、費用に含まれる範囲を比べます。

• 企画からRAG：企画・要件定義、データクレンジング、UI、RAG、モデル設定を、それぞれ分けて書く。
• 連携と移行：API連携、認証、テスト、移行、教育の範囲をそろえる。
• 運用：FAQ登録、初期データ投入、追加データ更新、API保守の範囲を明確にする。

開発後に誰が自社で担当するのか、障害時の一次窓口はどこか、モデル変更時の再テストは誰が行うのか、ログを閲覧できるのは誰かも確認します。

提案会社には同じ質問を投げかけ、回答の具体性やリスクをどこまで説明できるかも評価します。

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

ITヘルプデスクは、社員や端末、権限、障害の情報を扱います。そのため、回答の便利さだけでなく、誤開示と誤操作も管理する必要があります。

セキュリティ要件は後付けせず、RFP、設計、テスト、運用の各工程に配置します。

ハルシネーション対策と回答根拠

回答は社内ナレッジに限り、参照した文書のタイトルや版数、更新日を表示します。根拠がない場合は推測せず、担当者へ引き継ぐルールを設けます。

テストでは、古い手順や似た製品名、部署ごとに異なるルール、回答できない質問を入れます。そのうえで、正答率に加えて、根拠の妥当性、回答不能時の安全性、再現性を評価します。

プロンプトインジェクションと過剰な権限への対策

利用者の入力や検索対象の文書に、AIへの指示を装った悪意ある文章が混ざるおそれがあります。OWASP「Top 10 for LLM Applications 2025」ではPrompt InjectionがLLM01:2025として掲載されています（出典：OWASP、2025年）。

プロンプトへの禁則文の記載は、防御の一部にすぎません。入力と取得文書を信頼境界で分け、ツールの許可リストやパラメータ検証、出力のサニタイズ、実行回数制限、重要操作の承認、攻撃ログの監視を組み合わせます。

利用ルールと監査ログ

利用者には、氏名や社員番号、電話番号、パスワードを入力しないこと、機密情報を画面に写さないことを伝えます。

AIが参照してよい文書と、担当者だけが見られる文書は分けておきます。そのうえで、所属や役職に応じて検索結果を制御します。

質問者、質問内容、参照文書、実行ツール、承認者を記録します。また、ログの保存期間と閲覧権限を決め、定例レビューで不要な権限や古いナレッジを削除します。

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

導入の目的は、担当者をなくすことではありません。定型の質問をAIに寄せて、人が判断すべき案件に集中できる状態を作ることです。

質問や利用者、端末、試した手順、エラー、参照したFAQを引き継げば、利用者が同じ説明を繰り返す負担を減らせます。

失敗時に情報をそろえた引き継ぎ

引き継ぎ条件と緊急時の連絡経路を決めておけば、AIで解決できない相談も滞りなく担当者へ回せます。

• 引き継ぎ条件：根拠がない、本人確認に失敗、高リスク操作、同じ質問が二度未解決、感情的な不満の検知。
• 通常の対応：ITSMへ起票し、優先度とカテゴリを付けたうえで担当部署へ振り分ける。
• 緊急時：緊急障害や情報漏えいの疑いは通常フローから切り離し、電話や専用フォームへ案内する。

AIは「担当者へ連絡してください」とだけ返すのではなく、必要な情報を添えて引き継ぎます。

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

回答できなかった質問は、次のFAQを作る材料になります。そのため、有人対応のあとに、質問の言い換えや正しい手順、対象範囲、例外、公開可否を記録しておきます。

ナレッジへ反映するのは、承認された情報だけです。ハイブリッドBPOに委託する場合は、月次のFAQ追加数や更新リードタイムもサービスレベルに含めます。

問い合わせを生むPCセットアップやアカウント発行そのものを見直すと、定型作業の自動化以上の削減につながります。

よくある質問（FAQ）

発注前によく聞かれる質問に答えます。回答は、RFPの要件確認にもそのまま使えます。

情シスのAIエージェント外注費用は最初にいくら見ておけばよいですか？

小規模なFAQ検索PoCは、数十万円から数百万円が目安です。一方、本番の認証やITSM、Active Directory連携を含む場合は、初期予算が500万円から1,500万円程度の検討帯になります。ただし、金額はナレッジの状態や連携数、セキュリティテスト、運用支援によって変わるため、金額だけでなく作業項目と受入条件も比べます。

FAQが整理されていなくても発注できますか？

発注はできますが、データ整備の費用と期間は別工程として見積もります。過去チケットやマニュアル、社内ポータルを一覧にしたうえで、古い情報や重複、アクセス権、表記ゆれを整えてからRAGへ登録します。整備を自社と委託先のどちらが担うかを決め、社内に更新担当者を置きます。

AIにActive Directoryの操作を任せても安全ですか？

管理者権限をAIへ直接渡す設計は避けます。制限されたAPIや最小権限のエージェントID、入力値検証、実行ログ、承認フローを組み合わせます。パスワードリセットと権限変更は、別々の扱いにします。

発注側は、提案を受ける際に、失敗時のロールバックや緊急停止の方法も確認します。

委託先は何社から見積を取るとよいですか？

要件をそろえたうえで、少なくとも3社程度に相談すると比べやすくなります。候補には、SaaS、個別連携、運用やBPOなど、得意分野の異なる会社を含めます。

提案金額や実績、セキュリティ、運用体制、引き継ぎ、将来の拡張費を、同じ評価軸で採点します。

まとめ

発注前に決めること

発注前には、対象業務とKPI、データ範囲を決めます。さらに、連携先と権限、承認者、テスト条件も決めておきます。条件がそろえば、SaaS、個別開発、BPOを同じ条件で比べられます。

委託先選定で重視すること

外注時の判断事項をそろえておくと、委託先の実務力と導入後の運用体制を比べられます。

• 委託先の実務力：ナレッジ整備や最小権限のAPI連携、有人引き継ぎ、運用改善までの実力。
• 役割分担：AIへ任せる問い合わせと、人が承認する操作を先に決めておくこと。
• 導入手順：対象を絞って品質を測ってから、ITSMやActive Directoryとの連携を段階的に広げる。
• RFP：対象業務、KPI、データ範囲、RAG前処理を記載する。認証、API連携、攻撃テスト、運用体制も含める。
• 費用と運用：初期費と月額費を分けたうえで、更新、モデル変更、障害対応の責任範囲を確かめる。

見積の安さだけでなく、自社で運用できる仕組みを重視します。有人対応からナレッジ改善へ戻せる体制が、定着につながります。

参考ソース: PwC Japan「生成AIに関する実態調査2026 春」を参照しています。

OWASP「Top 10 for Large Language Model Applications 2025」を参照しています。

Microsoft Learn「What is Microsoft Entra Agent ID?」を参照しています。

Microsoft Security Blog「Microsoft unveils Security Copilot agents and new protections for AI」

▼RFP作成前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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