情シス/ITヘルプデスクのAIエージェントの開発期間・スケジュール・納期について

情シス/ITヘルプデスクのAIエージェントの開発期間は、導入形態によって数日から1年超まで幅があります。既存ITSMツールの機能を使う導入は短期間で始めやすい一方、フルスクラッチ型は長期化しやすいため、まず導入規模と自律範囲を定めることが納期設定の出発点です。

「PCが起動しない」「パスワードを忘れてアカウントがロックされた」「経費精算ソフトの利用申請が通らない」といった社内従業員からの問い合わせが、情シス部門・ITヘルプデスクの窓口に日々殺到します。一次対応に追われる悩みは、企業規模を問わず共通しています。

全体像は下の全体ガイドで確認できます。

▼全体ガイドの記事
・情シス/ITヘルプデスクのAIエージェントの完全ガイド

情シス/ITヘルプデスクのAIエージェント開発の全体像と期間目安

情シス/ITヘルプデスクのAIエージェント開発の全体像と期間目安

既存のITSMツールに標準搭載されたバーチャルエージェント機能を有効化するだけの導入と、社内IT運用プロセスに合わせてゼロから設計するオーダーメイド開発とでは、必要な工数がまったく異なります。このため、期間にも大きな差が出ます。導入形態によっては数日で稼働する一方、フルスクラッチ型では1年超かかることもあります。

発注側は、まず導入形態別・規模別の目安を押さえ、自社が目指す姿がどのレンジに当たるかを把握しておくと、現実的なスケジュールを描きやすくなります。

導入形態・規模別の開発期間の目安

導入形態別に見ると、既存ITSMツールに標準搭載されたAIエージェント機能を有効化・設定するSaaS/バーチャルエージェント型は、最短で数日〜4週間程度で稼働を開始できます。代表例は、ServiceNow Virtual Agent・Now Assist、Freshservice Freddy AI、Zendesk AI agentsです。

この型が速いのは、既製の自然言語処理エンジンと業務テンプレートを使うため、要件定義から権限設定、テストまでの工程を大幅に短縮できるからです。次にカスタマイズ型は、既存のITSM・チケット管理システムとAPI連携し、既知障害のFAQ回答基準やエスカレーションの閾値を自社の運用ルールに合わせて設計する方式で、納期は1.5〜4か月程度が目安です。

フルスクラッチ・オーダーメイド型は、独自の社内IT運用プロセスに合わせ、複数の社内システムを横断するマルチエージェント構成をゼロから構築する方式で、納期は6か月〜1年超です。規模別では、単一機能の小規模導入(例:パスワードリセットの一次対応のみ)は数日〜1か月です。複数部署でITSM連携を伴う中規模導入は2〜4か月、複数システムを横断し、複雑な承認フローを含む大規模導入は4か月〜1年超です。

開発期間を左右する変数

同じ中規模のカスタマイズ型導入でも期間には差が出るため、見積もりの精度を上げるには、期間を左右する要素を先に確認しておくことが役立ちます。

  • 社内IT運用プロセスの標準化度合い:担当者の暗黙知に頼る手順ほど、言語化やルール化に時間がかかります。
  • ナレッジベース・FAQデータの品質:情報が古い、または散在していると、実装後にナレッジの整備が必要になります。
  • 連携先システムの数:ITSMツールやActive Directory/Entra IDなどが増えるほど、実装とテストの工数が膨らみます。
  • 自律範囲・権限設計の合意形成スピード:決裁が遅れると後工程が待ち状態になり、納期が1か月以上ずれることがあります。

ポイント

期間は導入形態と規模で大きく変わるため、既存ツールで足りるか、個別のAPI連携が要るかを見極めることが出発点です。連携先の数や運用ルールの標準化も期間を左右するため、見積もり前に確かめると役立ちます。

工程別スケジュールと期間配分

工程別スケジュールと期間配分

カスタマイズ型・フルスクラッチ型では、標準的なプロセスは「要件定義」「エージェント設計」「実装」「評価・チューニング」「パイロット運用」の5工程に大別されます。工程ごとの期間配分を知っておくと、開発会社から提示された見積もりが妥当かを判断する材料になります。

要件定義・エージェント設計フェーズ(合計4〜8週間)

要件定義フェーズは通常2〜4週間を要します。発注側と開発会社は、パスワードリセットやアカウント権限申請、ソフトウェアインストール依頼、既知障害の一次切り分けといった社内IT問い合わせのうち、どこを自動化するかを整理します。そのうえで、AIエージェントが自律的に対応する範囲と人が対応する範囲を切り分けます。

続くエージェント設計フェーズは2〜4週間程度です。ここでは、後述するマルチエージェント構成にするか、単一のエージェントで対応するかを決めます。あわせて、ITSMツールのどの操作を実行できるようにするかを「ツール定義」として整理し、「AIが自律的に実行してよい操作」と「人間の承認を経て実行する操作」を切り分ける権限設計を行います。

権限設計は、後述するとおりスケジュール全体の遅延要因になりやすい工程です。そのため、情報システム部門とセキュリティ部門の関係者を早い段階から巻き込み、丁寧に進める価値があります。

実装フェーズと評価・チューニングフェーズ

実装フェーズは規模に応じて2〜24週間程度を見込みます。

LLMの組み込みやITSM・Active Directory/Entra IDとのAPI連携を行い、後述するツール呼び出し(Function Calling)を実装したうえで、UIを構築します。実装が終わると、評価・チューニングフェーズに入ります。

評価では、正答率だけでなくIT運用の成果に直結する観点で見ることが欠かせません。具体的には、次の項目を確かめます。

  • 複数ステップのワークフロー:テストデータで、「問い合わせ内容の分類→既知障害の切り分け→チケット起票またはエスカレーション判断」の流れが通るかどうか
  • 一次対応での解決率:一次対応だけで問い合わせが解決できた割合
  • 誤ったエスカレーション判断の発生頻度:誤った判断がどの程度起きるか
  • 回答内容の正確性:業務水準を満たすかどうか

最後のパイロット運用フェーズは2〜4週間です。

パイロット運用では、特定の部署や問い合わせカテゴリに対象を絞って試験運用し、利用者へのトレーニングも行います。

ポイント

見積もりに含まれる工程ごとの期間が、この記事の目安から大きく外れていないかを確かめてください。特に権限設計は遅れやすいため、その根拠を開発会社に尋ねてください。

ITSM連携・権限操作の設計工程がスケジュールに与える影響

ITSM連携・権限操作の設計工程がスケジュールに与える影響

社内FAQに回答するだけのツールとは違い、情シス/ITヘルプデスクのAIエージェントには、人に代わって社内IT運用業務を実行するための固有の工程が発生します。

これらの工程はスケジュールのクリティカルパス(全体の遅延に直結する作業)になりやすく、しかも見積もり段階で見落とされがちです。そのため、事前に工数を確保しておくことが欠かせません。

ツール定義・ITSM/チケット管理連携設計

最初の関門は「ツール定義(Function Calling設計)」です。AIエージェントがITSM上で操作できるよう、チケットの参照・起票・更新やステータス変更、担当者への割り当て、社内ナレッジベースの検索を、機能ごとにAPIとして呼び出せる形に整える必要があります。

この工程は見た目以上に手間がかかります。というのも、対応する操作の種類が増えるほど、権限設定やエラーハンドリングの検証項目も比例して増えるからです。

ServiceNowやJira Service Management、Zendesk、Freshserviceといった、ITSM・チケット管理システムとの連携実装には2〜6週間を見込んでおく必要があります。連携先が複数にまたがる場合は、この工程が全体スケジュールの多くを占めることになります。

アカウント権限操作の自律範囲合意形成とガードレール設計・検証

もう一つの固有工程は、「AIが自律的に実行してよい操作」と「人間の承認を経てから実行する操作」を切り分ける自律範囲の設計です。

この線引きを決めるには、情シス部門・セキュリティ部門の責任者を交えた合意形成に1〜3週間程度を要します。

この線引きの分かれ目は、操作が及ぶ影響範囲の広さと、アカウント・権限に関わるかどうかです。下の2つに当てはめると、次のように分かれます。

  • 自律実行の対象にしやすい操作:社内FAQへの回答やチケットの自動起票、既知障害の切り分け案内のように、影響範囲が限定的なタスク
  • 承認ゲートを挟む操作:パスワードリセットやアカウントロック解除、ソフトウェア利用権限の付与など、アカウント・権限に関わる操作

承認ゲートでは、AIがドラフトを生成し、人間が確認・承認したうえで実行します。

さらに、意図しない操作が起きないよう、ガードレール(安全装置)を組み込み、テストケースで検証します。たとえば、本人確認が不十分なままのパスワードリセットや過剰な権限付与などが、ここでいう意図しない操作です。この作業は通常のシステム開発にはない工数のため、計画に織り込んでおく必要があります。

ポイント

ITSM連携と権限操作の設計は見積もりで見落とされやすいため、連携先の数と承認ゲートの対象を先に洗い出し、そのぶんの工数を確保しておくことが判断の目安になります。

開発手法による期間の違い

開発手法による期間の違い

情シス/ITヘルプデスクのAIエージェントの開発期間は、どの開発手法を選ぶかによっても大きく変わります。

素早く効果を検証したいのか、自社の社内IT運用プロセスに完全に合わせたいのかによって、適した手法は異なります。

ノーコード/エージェントビルダーによる立ち上げ加速

既に導入済みのITSMツールに標準搭載されたバーチャルエージェント機能や、Difyのようなノーコードのエージェント構築ツールを使えば、GUI操作中心で数時間〜数日でプロトタイプを立ち上げられます。さらに、1〜3か月程度で実用レベルまで持っていくことも可能です。

専門のAIエンジニアがいなくても、既存の社内ナレッジベースをもとにワークフローを組み立てられる点が魅力です。

まずは限定的な範囲でノーコードにより素早く立ち上げ、効果を見ながら本格導入や後述のフルスクラッチ開発へ広げる段階的な進め方も、納期短縮の観点では有効な選択肢になります。

フルカスタム・マルチエージェント構成の開発期間

一方、役割を分割したマルチエージェント構成をゼロから構築する場合は、6か月〜1年超の期間を要します。たとえば、「一次受付・分類エージェント」「既知障害切り分けエージェント」「アカウント権限申請処理エージェント」「エスカレーション判断エージェント」を置き、統括エージェントが全体を制御する構成が考えられます。

複数の社内システムと連携したり、独自のセキュリティ要件やコンプライアンス要件を組み込んだりするため、ノーコードより時間はかかります。その代わり、自社の社内IT運用プロセスに完全に合わせたエージェント体制を築けます。

どちらの手法でも共通して求められるのは、要件定義の段階で決裁権を持つ情シス責任者が短時間でも同席し、自律範囲や仕様を迅速に決められる体制を組むことです。

ポイント

素早く効果を確かめたいなら、ノーコードで限定範囲から始めて段階的に広げるのが目安です。自社の運用に完全に合わせる必要があるときに、フルスクラッチを検討してください。

納期遅延の典型要因と対策

納期遅延の典型要因と対策

ここまで見てきた期間・工程を理解していても、典型的な遅延要因を放置すればスケジュールは簡単に崩れます。

情シス/ITヘルプデスクのAIエージェントで納期が計画を超える主な原因は、ナレッジベース・FAQデータの未整備と、自律範囲の合意形成の難航です。

ナレッジベース未整備・FAQ品質不備による遅延

最も多い遅延要因の一つは、社内ナレッジベース・FAQデータの品質不備です。「まずは既存の社内Wikiやマニュアルをそのまま使えばよいだろう」という見込みで開発を始めると、実装フェーズで、情報の古さや部署ごとに矛盾する手順が次々と見つかります。そのため、想定外のナレッジ整備作業が発生し、スケジュールが崩れます。

対策としては、要件定義の段階でナレッジ整備の工数を独立したタスクとして見積もりに明示することが有効です。そのうえで、実装開始前に対象となる社内文書を洗い出して一覧にし、品質をチェックしておきます。

発注側は、後述するPoCの段階で実際の問い合わせ履歴の一部を使って検証しておくことで、本開発フェーズでの想定外の手戻りを大幅に減らせます。

自律範囲・承認フローの合意不足による手戻り

もう一つの典型的な遅延要因は、「AIエージェントにどこまで自律的に判断・実行させるか」という合意が情シス部門内で固まらないまま開発を進めてしまうことです。この合意が曖昧だと、実装や評価フェーズに入ってから「このアカウント操作は人が確認すべきではないか」という声が上がり、承認フローの設計をやり直す手戻りが発生します。

対策としては、開発着手前に自律範囲・承認フローの方針を、経営層やセキュリティ責任者を含めて合意しておくことです。

さらに、本開発の前に1〜2か月程度のPoC(概念実証)を実施し、実際の社内問い合わせデータでの精度や現場の受け入れやすさを確認しておくと、「想定外の仕様変更」による大幅な遅延を防げます。一方で、PoCを省略していきなり本開発に着手すると、一見スケジュールが短く見えても、現場従業員の反発や精度不足で手戻りが発生し、結果的にトータルの納期が延びるケースが多く見られます。

ポイント

遅延を防ぐには、ナレッジ整備の工数を見積もりに含めることと、自律範囲の合意を着手前に済ませることが目安です。1〜2か月のPoCで現場の受け入れやすさを確かめると、本開発の手戻りを抑えられます。

まとめ

情シス/ITヘルプデスクのAIエージェント開発期間まとめ

ここまで、期間の目安や工程別の配分、ITSM連携・権限操作の設計工程の影響を見てきました。開発手法による違い、納期遅延の典型要因と対策も取り上げています。

開発期間の目安は、SaaS/バーチャルエージェント型で数日〜4週間、カスタマイズ型で1.5〜4か月、フルスクラッチ型で6か月〜1年超です。工程配分は、要件定義・エージェント設計が4〜8週間、実装が2〜24週間、評価・チューニングとパイロット運用が4〜8週間で、これが一つの基準になります。

社内FAQボットとは違い、AIエージェントには、ツール定義・ITSM連携設計、権限操作の自律範囲の合意形成とガードレール設計・検証といった固有の工程が加わります。これらはスケジュールのクリティカルパスになりやすいため、計画の段階で理解しておく必要があります。

代表的な遅延要因であるナレッジベースの未整備と自律範囲の合意不足には、データを事前に洗い出すことと、PoCで早期に現場を検証することで備えます。この備えが、無理のない納期設定とリスク管理を両立させる鍵になります。

具体的なスケジュールを相談する際は、自社の社内IT運用プロセスとITSMツールの利用状況を複数の開発会社に示し、見積もりを取るところから始めるとよいでしょう。

▼全体ガイドの記事
・情シス/ITヘルプデスクのAIエージェントの完全ガイド

会社紹介

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

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

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

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

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

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