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

情シス・ITヘルプデスクのAIエージェント開発を外注するなら、FAQを答えるだけのチャットボットではなく、ナレッジ検索から本人確認、チケット起票、承認付きのアカウント操作までを一つの業務フローとして設計することが重要です。

本記事では、発注形態の選び方、RFPと要件の整理、契約形態、2026年時点での費用の見方、委託先の比較方法を、情シス・ITヘルプデスク向けに解説します。ソフトバンクやLIXIL、SCSKなどの事例、RAG用データの整備、Active DirectoryやITSMとの連携、プロンプトインジェクション対策まで、稟議と見積比較に使える粒度で整理します。

情シス・ITヘルプデスクのAIエージェントとは何ですか?

情シスのAIエージェント全体像

情シス・ITヘルプデスクのAIエージェントとは、利用者の自然な質問を理解し、社内ナレッジを検索して回答するだけでなく、条件に応じて業務システムの操作や有人担当者への引き継ぎまで実行する仕組みです。発注時は「生成AIを導入する」という表現ではなく、「どの問い合わせを、どの権限で、どこまで完了させるか」に置き換えて定義します。

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

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

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

一般的には、FAQやマニュアル、過去チケットなどのデータソース、検索用のベクトルデータベース、生成AIモデル、TeamsやSlackなどのチャットUI、そしてITSMやActive Directoryへ接続するツール層で構成します。外注範囲には、画面開発だけでなく、データ整備、認証、権限、監査ログ、テスト、運用引き継ぎを含めます。ここを曖昧にすると、安いPoCの見積もりが本番運用時に大きく膨らみます。

AIエージェントの発注形態はどれを選べばよいですか?

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

結論として、問い合わせ削減だけを早く検証したい場合はSaaS型または短期PoC、既存システム操作まで求める場合は個別開発型、ナレッジ更新や一次対応の人手も不足している場合はBPOを組み合わせた形が適しています。製品名から選ぶのではなく、業務の標準化度、社内の運用担当者、セキュリティ要件、将来の拡張性で発注方式を決めます。

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

SaaS型は初期構築を抑えやすく、標準的なFAQ検索や有人へのエスカレーションを短期間で始められます。ただし、独自の承認ルールやActive Directoryの操作が製品仕様に合わない場合があります。PoC型は対象をパスワード忘れ、アカウントロック、MFA不通の3本程度に絞り、回答率や有人転送率を検証する方法です。BPO型はAIが解決できない問い合わせを人が受け、対応履歴をFAQへ戻す運用まで外注できます。

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

要件が変わりやすい企画、データ整備、PoCは、作業時間や専門人材を確保する準委任契約と相性がよいです。完成させる機能と受入条件を明確にできる本番開発は、成果物と検収を定義した請負契約が候補になります。リリース後のプロンプト調整、FAQ更新、ログ分析は月額の運用保守契約に分けると、開発費と継続費を管理しやすくなります。契約を一つにまとめる場合も、開発、データ更新、障害対応、追加開発の単価を分けて記載してもらいます。

RFPと要件整理では何を決めますか?

AIエージェントのRFP要件整理

RFPでは、機能一覧だけでなく、対象ユーザー、問い合わせ量、業務の完了条件、参照データ、連携先、権限、品質指標、運用体制を一枚の業務設計として示します。ベンダーごとに前提が変わると見積比較ができないため、最低限の共通条件と、提案してほしい選択肢を分けて書くことが大切です。

対象業務とKPIの定義

まず直近3か月から12か月の問い合わせログを分類し、件数、対応時間、再問い合わせ率、解決までの時間、エスカレーション先を確認します。頻度が高く、手順が決まっていて、誤操作の影響を限定できる業務を初期対象にします。KPIは「AI利用者数」だけでなく、一次解決率、正答率、有人転送の適切率、平均対応時間、誤ったアクションの件数、FAQ更新までの日数を組み合わせます。SCSKの事例では、対象範囲を意図的に絞って担当者の対応件数を20〜25%減らしたとされています。

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

データ要件には、FAQ、操作マニュアル、過去チケット、社内規程の保存場所と更新者を記載します。WordやPDFは見出し、表、注記が崩れたまま取り込まれると検索精度が下がります。Excelは一行一質問に変換し、製品名、対象部署、適用バージョン、公開範囲などのメタデータを付けます。連携要件ではTeamsやSlack、ServiceNowなどのITSM、Active Directory、RPAの有無に加え、SSO、多要素認証、データの保管地域、学習への利用有無、監査ログの保持期間まで指定します。

受入条件とテストデータ

受入条件には、正解率の平均だけでなく、重要質問の最低正答率、根拠文書の提示率、回答不能時の案内、権限外情報の拒否、ツール実行前の承認表示を含めます。実際の質問を個人情報が含まれない形で匿名化し、表記ゆれや誤字、攻撃的な入力も含めたテストセットを作ります。RAGの検索評価と生成回答の評価を分け、RAGASなどの評価フレームワークを使うか、同じ質問をリリース前後で比較できるようにします。

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

AIエージェント開発の進め方

発注後は、企画、データ整備、PoC、本番設計、テスト、段階リリース、運用改善の順で進めます。各工程の終了条件を決め、次の工程へ進む判断を共同で行うと、AIの回答が少し良いだけで本番投入してしまう事故を防げます。

PoCはパスワード関連の最小構成から始めます

最初から全社の問い合わせを扱うのではなく、パスワード忘れ、アカウントロック、MFA不通の3本から始めます。利用者の本人確認、対象アカウント、実行条件、失敗時の案内が比較的定義しやすく、効果も問い合わせ件数と処理時間で測れるためです。PoCでは数本から200問程度のFAQを用意し、実際の利用者に試してもらいます。正答率だけでなく、「何を答えられなかったか」「人へ渡した方がよかった質問は何か」を記録します。

RAGの精度はナレッジ前処理で決まります

RAGでは、質問に近い文書を検索して生成AIへ渡しますが、元データが古い、重複している、部署ごとに呼び方が違う状態では、モデルを高性能にしても回答は安定しません。発注先には、文書の棚卸し、版数管理、重複排除、表記ゆれの統一、チャンク分割、アクセス権の継承方法を確認します。「全文をベクトル化する」だけの提案ではなく、表組みや図解PDFをどのようにテキスト化し、どの文書を検索対象から外すかまで説明できる会社を選びます。

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

AIがActive DirectoryのパスワードリセットやITSMのチケット起票を実行する場合、LLMに管理者権限を直接与えてはいけません。AIは意図とパラメータを作り、制限されたツールAPIへ渡し、API側で対象者、対象操作、入力値、実行回数を検証します。アカウント無効化や権限変更のような高リスク操作は、利用者の本人確認と担当者承認を必須にします。東亜建設工業の事例のようにTeams上の問い合わせとRPAを連携する場合も、成功・失敗・タイムアウトをITSMへ返し、処理結果を利用者へ通知するところまでを要件に含めます。

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

AIエージェント開発費用の考え方

2026年時点の費用は、利用人数やモデルの料金だけでなく、ナレッジ整備、認証、連携、テスト、運用体制で決まります。したがって「AIチャットボットはいくら」と一つの金額で比較するのは危険です。以下は発注計画を作るための実務上の目安であり、実際の見積もりでは対象範囲と品質条件をそろえて比較します。

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

FAQ検索とチャットUIを検証する小規模PoCは、一般に数十万円から数百万円程度が検討帯になります。SSO、権限管理、評価用テストセット、Teams連携まで含む本格PoCでは、100万円台から500万円前後になるケースがあります。複数部署のナレッジを統合し、ITSMやActive Directory、RPAなどのアクション実行を含む本番構築は、500万円から1,500万円程度、複雑な業務フローや複数システムを含むと1,500万円超も想定します。金額は相場の断定ではなく、データ量と連携数を基準にした予算策定の目安です。

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

月額費用には、AIモデルや検索基盤の利用料、ユーザー数や実行回数に応じたSaaS料金、監視、FAQ更新、チューニング、有人対応、障害対応が含まれます。PwC Japanの「生成AIに関する実態調査2026 春」では、生成AIのランニングコストは初期開発費や導入費とは別に集計されています(出典: PwC Japan、2026年)。この区分に合わせ、見積書では初期費用、月額固定費、従量課金、追加連携、データ更新、定例会、緊急対応を分けてもらいます。高性能モデルを全問い合わせに使わず、簡単な質問は軽量モデルへ振り分ける設計も、継続費を抑える手段です。

ROIと損益分岐点の計算

ROIは、削減できる対応時間だけでなく、夜間の一次回答、対応品質の均一化、属人化の解消、チケット情報の欠落防止も含めて評価します。たとえば月3,000件のうち30%をAIが適切に処理し、1件あたり8分を削減できるなら、月720分、つまり12時間分の削減です。実際の人件費単価、運用費、再問い合わせによる増分を入れて、投資回収期間を計算します。KPIの母数と計測期間をRFPに書いておくと、ベンダーの成功事例と自社の効果を混同しにくくなります。

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

AIエージェント委託先の比較

見積金額が安い会社を選ぶのではなく、同じ業務範囲と同じ受入条件で比較します。提案書を読むときは、AIモデルの説明より、現行業務の理解、データの扱い、連携の実装、テストと運用の責任分界を確認します。

実績では業界名より業務の近さを見ます

「生成AI導入実績が何社あるか」だけでは判断できません。情シス・ITヘルプデスクで、問い合わせ分類、ナレッジの版管理、本人確認、ITSM連携、アカウント操作まで実装した事例があるかを確認します。ソフトバンクでは約3.6万件のQ&Aデータを使った社内特化型生成AI、LIXILでは導入初期に約250通りの質問・回答を用意した事例があり、データ量と初期設計の具体性を確認する材料になります。

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

確認項目は、データの学習利用、暗号化、保管地域、SSOと多要素認証、テナント分離、権限継承、監査ログ、バックアップ、委託先の再委託です。Microsoftは2025年にAIエージェントを人やアプリと同じように識別し、認証・認可・ライフサイクルを管理するEntra Agent IDを案内しました(出典: Microsoft Learn、2025〜2026年)。AIエージェントを共有管理者アカウントとして扱う提案は避け、エージェントごとの所有者、目的、付与権限、停止手順を確認します。

見積比較表で確認する責任分界

各社の見積を、企画・要件定義、データクレンジング、UI、RAG、モデル設定、API連携、認証、テスト、移行、教育、運用の行に分けて並べます。特に「FAQ登録」「初期データ投入」「追加データの更新」「APIの保守」がどこまで含まれるかを揃えます。開発後に自社が何を担当するか、障害時の一次窓口、モデル変更時の再テスト、ログの閲覧者を確認します。提案会社へ同じ質問をし、回答の具体性とリスクの説明力も評価対象にします。

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

AIエージェントの精度とセキュリティ

ITヘルプデスクは、社員情報、端末情報、権限、障害状況を扱うため、回答の便利さだけでなく誤開示と誤操作を管理しなければなりません。セキュリティ要件は後から付け足すのではなく、RFP、設計、テスト、運用の全工程に配置します。

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

回答を社内ナレッジに限定し、参照文書のタイトル、版数、更新日を表示します。根拠が見つからない場合は推測で答えず、「担当者へ引き継ぐ」と返すルールを設けます。テストでは、古い手順、似た製品名、複数部署で異なるルール、回答不能な質問を意図的に投入します。評価指標は正答率だけでなく、根拠の妥当性、回答不能時の安全性、再現性を含めます。

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

利用者の入力や検索対象文書に、AIへの指示を装った悪意ある文章が混ざる可能性があります。OWASPの「Top 10 for LLM Applications 2025」ではPrompt InjectionがLLM01:2025として掲載されています(出典: OWASP、2025年)。対策は禁則文をプロンプトに書くだけでは不十分です。入力と取得文書を信頼境界で分け、ツールの許可リスト、パラメータ検証、出力のサニタイズ、実行回数制限、重要操作の承認、攻撃ログの監視を組み合わせます。

利用ルールと監査ログ

利用者には、氏名、社員番号、電話番号、パスワードをチャットへ入力しないこと、スクリーンショットに機密情報を写さないことを明示します。AIが見られる文書と、担当者だけが見られる文書を分け、社員の所属や役職に応じて検索結果を制御します。誰が何を質問し、どの文書を参照し、どのツールを実行し、誰が承認したかを記録します。ログの保存期間と閲覧権限を決め、定例レビューで不要な権限や古いナレッジを削除します。

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

AIと有人ヘルプデスクの連携

AIエージェントの導入目的は、担当者をなくすことではなく、定型質問をAIへ寄せ、人が判断すべき案件に集中できる状態を作ることです。有人へ渡すときに質問内容、利用者、端末、試した手順、エラー、参照したFAQを引き継げると、利用者が同じ説明を繰り返す負担を減らせます。

失敗時に情報をそろえて担当者へ渡す

エスカレーション条件は、回答根拠がない、本人確認に失敗した、高リスク操作を含む、同じ質問が二度解決しない、感情的な不満が検知された場合などです。AIは「担当者へ連絡してください」とだけ返すのではなく、ITSMへチケットを起票し、優先度とカテゴリを付け、担当部署へ振り分けます。緊急障害や情報漏えいの疑いは通常フローから切り離し、電話や専用フォームへ案内します。

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

AIが答えられなかった質問は失敗ではなく、次のFAQを作るための材料です。有人担当者が対応した後、質問の言い換え、正しい手順、対象範囲、例外、公開可否を記録し、承認されたものだけをナレッジへ反映します。ハイブリッドBPOでこの作業まで委託する場合は、月次のFAQ追加数や更新リードタイムをサービスレベルに含めます。定型作業の自動化だけでなく、問い合わせを生むPCセットアップやアカウント発行自体を見直すと、より大きな削減につながります。

よくある質問(FAQ)

AIエージェント外注のよくある質問

ここでは、発注前によく寄せられる質問へ直接回答します。自社のRFPを作る際は、回答をそのまま要件確認の観点として利用できます。

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

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

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

発注できますが、データ整備の費用と期間を別工程として見積もる必要があります。過去チケット、マニュアル、社内ポータルを棚卸しし、古い情報、重複、アクセス権、表記ゆれを整理してからRAGへ登録します。ナレッジ整備を自社で行うか委託するかを決め、更新担当者を社内に置くことが重要です。

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

管理者権限をAIへ直接渡す設計は避けるべきです。制限されたAPI、最小権限のエージェントID、入力値検証、実行ログ、承認フローを組み合わせ、パスワードリセットと権限変更を同じ扱いにしないことが安全性を高めます。提案時に、失敗時のロールバックと緊急停止の方法まで説明してもらいます。

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

要件をそろえたうえで、少なくとも3社程度へ相談すると比較しやすくなります。SaaS導入に強い会社、個別連携に強い開発会社、運用やBPOに強い会社など、異なる得意領域を含めると選択肢を評価できます。提案金額、実績、セキュリティ、運用体制、社内への引き継ぎ、将来の拡張費を同じ評価軸で採点します。

まとめ

情シスAIエージェント外注のまとめ

発注前に決めること

発注前は、対象業務、KPI、データの範囲、連携先、権限、承認者、テスト条件を決めます。ここが明確であれば、SaaS導入、個別開発、BPOの提案を同じ土台で比較できます。

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

委託先は、生成AIの華やかなデモだけでなく、ナレッジの泥臭い整備、最小権限のAPI連携、有人エスカレーション、運用改善まで説明できる会社を選びます。見積の安さより、導入後に自社で回せる仕組みと責任分界を重視します。

情シス・ITヘルプデスクのAIエージェントを外注するときは、製品やモデルの比較から始めず、問い合わせ業務のどこをAIに任せ、どこから人が承認するかを先に決めます。最初はパスワード関連など対象を絞り、ナレッジを整備し、回答品質を測り、ITSMやActive Directoryとの連携を段階的に広げる進め方が現実的です。

RFPには、対象業務とKPI、データの範囲、RAG前処理、認証と権限、API連携、プロンプトインジェクションを含むテスト、契約後の運用体制を記載します。見積は初期費用と月額費用を分け、データ更新やモデル変更、障害対応の責任分界まで確認します。最終的に、AIが答えられない質問を有人対応とナレッジ改善へ戻せる会社を選ぶことが、定着するITヘルプデスクにつながります。

参考ソース: 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」を参照しています。

会社紹介

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

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

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

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

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

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