情シス/ITヘルプデスクのAIエージェントのフルスクラッチ・オーダーメイド開発について

情シス/ITヘルプデスクのAIエージェントをフルスクラッチ・オーダーメイドで開発するのは、複雑な社内申請や複数システムとの深い連携、独自の障害切り分けロジックが必要な企業に適しています。

標準的な問い合わせなら既製ツールが有力ですが、標準機能の制約を超えたい場合は専用設計を検討します。

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

情シス/ITヘルプデスクのAIエージェントにおけるフルスクラッチ・オーダーメイド開発の定義

情シス/ITヘルプデスクのAIエージェントにおけるフルスクラッチ・オーダーメイド開発とは

フルスクラッチ・オーダーメイド開発は、既製のパッケージ製品やテンプレートを使わず、要件定義から設計・実装までをすべて自社専用に作り上げる開発の進め方です。

情シス/ITヘルプデスクのAIエージェントでこの方式が検討されるのは、既製ツールの制約を超えて、自社の社内IT運用プロセスや業務システムに完全に合わせたい場合です。

既製SaaS/バーチャルエージェントとの違い

既製のSaaS/バーチャルエージェント(ServiceNow Virtual Agent・Now Assist、Freshservice Freddy AI、Zendesk AI agents等)は、有力な選択肢です。標準的な社内IT問い合わせなら、短期間・低コストで導入できることが強みです。また、モデルの改善やセキュリティ対応は、ベンダー側が継続して行います。

一方で、カスタマイズできる範囲はベンダーの提供機能の枠内に限られます。複雑な条件分岐や独自のワークフローも組み込みにくく、自社独自のロジックがベンダーのプラットフォームに依存してしまいます(ベンダーロックイン)。

フルスクラッチ開発では、この制約がなくなり、無制限に近いカスタマイズができます。標準技術スタックを採用すればベンダーロックインも避けられ、APIのない古い社内システムも独自のラッパーで接続できます。ただし、費用や学習コストは高く、開発期間も数時間〜数日のSaaS型に対し、数か月単位になります。

フルスクラッチが適するケース

フルスクラッチ開発が適するのは、標準機能では解けない業務上の制約がある場合です。特に、次の条件が重なるほど専用設計の必要性は高まります。

  • 複雑な申請:多段階の稟議承認や複数部署の合議を経る、ソフトウェア利用申請フローがある。
  • 複数システム連携:ITSMに加えて、Active Directory/Entra ID、資産管理システムなどの周辺システムや、勤怠システムと接続する。
  • 独自ロジックの内製管理:障害切り分けやエスカレーション基準を、自社で改善し続けたい。
  • 厳格な監査要件:金融・医療業界などで、アカウント・権限操作に強いコンプライアンス要件がある。

逆に、これらに当てはまらない場合は、既製SaaSやカスタマイズ型の導入を優先したほうが、投資対効果の面で合理的なことが多くあります。

エージェント設計パターン

エージェント設計パターン

フルスクラッチで情シス/ITヘルプデスクのAIエージェントを構築するとき、その品質を大きく左右するのが設計パターンです。特に重要なのは、次の2つの考え方です。

マルチエージェント構成(役割分担)

近年の情シスAIエージェント設計では、マルチエージェント構成が主流になりつつあります。問い合わせ受付からアカウント操作、エスカレーション判断までを、役割ごとに分けたエージェントが担う構成です。

役割ごとに専門化すると、各エージェントは担当領域に特化したロジックやプロンプトを持てます。そのため、精度の向上とメンテナンス性の両立がしやすくなります。

たとえば、既知障害切り分けエージェントの判断基準を見直すとき、アカウント権限申請処理エージェントのロジックに影響を与えずに調整できます。単一の大きなエージェントを運用するより保守しやすいという、実務上の利点があります。

役割分担を設計するときは、問い合わせの受付から実行、エスカレーションまでの流れを、担当を分けやすい所で区切ります。区切った役割は、たとえば次のように整理できます。

  • 一次受付・分類:問い合わせを受け付け、担当する処理へ振り分ける。
  • 既知障害切り分け:過去の対応基準に沿った、障害状況の整理。
  • アカウント権限申請処理:アカウントや権限に関する申請の処理。
  • エスカレーション判断:専門担当者へ引き継ぐ必要があるかの判断。

これらを束ねるのがオーケストレーター(統括エージェント)で、全体のワークフローを制御します。

ツール呼び出し設計とHuman-in-the-Loop

ツール呼び出し(Function Calling)の設計も重要です。ITSMのチケット操作、Active Directory/Entra IDのアカウント操作、社内ナレッジ検索などを「ツール」として個別に定義します。資産管理システムとの連携も、同じく個別のツールとして扱えます。エージェントが状況に応じてそれらを呼び出すことで、拡張性と保守性を両立できます。

ツール連携の標準規格であるModel Context Protocol(MCP)に準拠して設計するケースも増えています。将来のツール追加や他システムとの接続に、柔軟に対応できます。さらに、情シス/ITヘルプデスクのAIエージェントに特有の設計原則が、Human-in-the-Loopです。

アカウントや権限に関わる操作(パスワードリセット、権限付与、ソフトウェアインストール許可など)は、AIがドラフトを作り、人が確認・承認してから実行する「承認ゲート」を挟むのが基本です。一方、影響範囲の小さいタスク(FAQ回答、チケット起票、既知障害の案内など)は、自律実行の対象にしやすいのが実務上のセオリーです。

ポイント

役割を分けるかは業務の複雑さで、人の承認を挟むかは操作の影響範囲で判断すると、設計の方向をつかみやすくなります。

ITSM・社内システムとの統合設計

ITSM・社内システムとの統合設計

フルスクラッチ開発の価値が最も発揮されるのは、ITSMツールだけでなく、複数の社内システムを横断して統合設計するときです。ここでは、連携設計とガバナンス設計の2つの観点から見ていきます。

ITSM・Active Directory/Entra IDとのAPI連携設計

ITSMツールとの連携は、ServiceNow REST API、Jira Service Management API、Zendesk APIなどの標準APIを介して行うのが基本です。フルスクラッチ開発では、さらに周辺システムとの連携まで含めて設計できます。

周辺システムには、Active Directory/Entra ID(アカウント・権限管理)、資産管理システム、社内チャットツール(Slack、Microsoft Teamsなど)があります。

社内マニュアルや過去の障害対応記録を検索対象にするなら、ベクトルDBを併用したRAG(検索拡張生成)構成を組み合わせられます。たとえば、エージェントは過去の類似障害の対応履歴を参照しながら、新しい問い合わせへの回答を生成できます。こうした統合設計は、既製SaaSでは実現しにくい、フルスクラッチ開発ならではの価値です。

権限・セキュリティ・監査ログ設計

複数システムを横断して AIエージェントが動く以上、権限管理とセキュリティ設計は欠かせません。エージェントがアクセスできるデータの範囲と実行できる操作は、役割ごとに厳しく制御します。さらに、いつ、どのツールを、どのような判断根拠で呼び出したかを、監査ログとして記録します。

特にアカウント情報や社内システムの機密情報を扱い、クラウドLLM APIを利用するなら、オプトアウト契約(学習データとして利用されない契約)の確認が必須です。金融・医療関連の情報を扱う場合は、データの保存場所を自社テナント内に完結させる設計が求められることもあります。

重要な操作の前に人の承認を必須とするHuman-in-the-Loop設計と組み合わせれば、操作の経緯を後から追えるようにしながら、安全に運用できます。

ポイント

既製ツールの範囲を超えるかは、連携先の数や監査要件の厳しさを見て判断すると、統合設計の方向を決めやすくなります。

開発費用・期間の目安と技術構成

開発費用・期間の目安と技術構成

フルスクラッチ開発を検討する際に最も気になるのは、費用・期間の水準と技術構成です。

費用・期間相場

費用と期間は、統合するシステム数やエージェント構成の規模で変わります。見積もりでは、初期開発だけでなく、工程ごとの期間と運用費まで分けて確認します。

  • 初期開発:400万〜2,500万円程度が目安で、大規模案件では2,500万円〜8,000万円規模になることもある。
  • 開発期間:全体で6か月〜1年超が目安で、要件定義からパイロット運用まで段階的に進める。
  • 月額運用:40万円以上(年間換算で500万円以上)を見込む。
  • 年間TCO:既製SaaS型の40万〜350万円程度に対し、フルスクラッチ型は150万〜800万円以上になりやすい。

開発期間の内訳は、要件定義が4〜8週間、エージェント設計・ツール定義が4〜8週間、実装が8〜24週間です。さらに、評価・チューニングに4〜8週間、パイロット運用に2〜4週間を見込みます。この工程配分も、投資判断の材料になります。

技術スタック(フレームワーク・LLM選定)

マルチエージェント構成のオーケストレーションには、厳密なフロー制御ができるLangGraphなどのフレームワークが、事実上の標準として使われることが多いです。社内マニュアルや過去の障害対応記録の検索には、LlamaIndexなどのRAG特化フレームワークが併用されます。

LLMは用途に応じて使い分けるのが一般的です。複雑な障害切り分けや文章生成には高性能モデルを、定型的な問い合わせ分類やチケット要約には軽量モデルを使います。

ベクトルDBの選択肢は、導入の規模によって変わります。大規模な導入ならPinecone、Milvus、Azure AI Searchなどが、プロトタイプや小規模導入ならFaiss、Chromaなどが候補になります。また、技術選定は開発会社によって得意分野が違うため、提案の時点でどの構成を推奨するのか、その理由とあわせて確認することが大切です。

ポイント

費用は初期開発費だけでなく、運用費を含めた年間TCOで既製SaaS型と比べて判断します。見積もりに運用費が含まれているかも、確認の目安になります。

発注・契約時の注意点

発注・契約時の注意点

フルスクラッチ開発は投資額が大きくなります。そのぶん、発注・契約時の確認事項を押さえておくことが、プロジェクトの成否を左右します。

契約形態とラボ型開発

社内IT運用プロセスの言語化や、エージェントの自律範囲の設計は、開発を進めながら仕様が固まっていく性質が強いものです。そのため、要件の確定を前提とする一括請負契約より、「ラボ型(準委任)」でのアジャイル開発が推奨されます。

一括請負で範囲を厳密に固定すると、開発途中で判明した例外パターンや現場のフィードバックを仕様に反映する際に、仕様変更として扱われます。その結果、見積もりが当初の2倍以上に膨張するリスクがあります。

ラボ型契約なら、優先度の高いタスクから柔軟に着手でき、社内システムの変更にも対応しやすくなります。

PoCを経た段階的移行の徹底

投資額が大きいフルスクラッチ開発では、必ずPoC(1〜2か月・250万円前後が目安)を挟んでから、本開発に進みます。PoCの結果は、定量的なGo/No-Go基準で評価し、本開発へ移るかを判断します。

相見積もりを取る際は、3〜5年のTCOで比べる視点を持ちます。たとえば、API利用料が保守費用に含まれるか実費精算か、保守費の範囲が監視のみか機能追加まで含むかを確認します。

丸投げ外注を避けるには、契約時の確認が欠かせません。確認したいのは、ソースコードの所有権が自社に帰属するか、特定ベンダーに依存しない標準技術スタックを採用しているか、プロジェクト終了時に技術移転セッション(自社エンジニアへのノウハウ引き継ぎ)が用意されているかの3点です。これらを確かめておくと、長期的に自社でエージェントを育て続ける体制を築けます。

ポイント

仕様が固まりにくい案件はラボ型を選び、PoCの結果を定量的なGo/No-Go基準で見てから本開発へ進むかを決めるのが目安です。

まとめ

情シス/ITヘルプデスクのAIエージェントフルスクラッチ・オーダーメイドまとめ

情シス/ITヘルプデスクのAIエージェントにおけるフルスクラッチ・オーダーメイド開発について、既製SaaSとの違いから設計、統合、費用、発注時の注意点までを見てきました。

既製ツールは短期間・低コストで導入できます。一方、複雑な社内申請や複数の社内システムとの深い連携、独自ロジックの内製管理を求める企業には、フルスクラッチが適しています。

初期費用は400万〜2,500万円程度(大規模案件では2,500万円〜8,000万円)、開発期間は6か月〜1年超が目安です。精度とリスク管理を両立させるうえで鍵になるのは、役割を分けたマルチエージェント構成と、アカウント・権限操作に人の承認を挟むHuman-in-the-Loop設計です。

契約形態は、ラボ型(準委任)でのアジャイル開発を基本にします。必ずPoCを経て、定量的な基準で本開発への移行を判断することは、大きな投資を無駄にしないために欠かせません。

自社の社内IT運用プロセスに合った進め方を見極めるためにも、まずは複数の開発会社に自社の要件と現状のシステム構成を伝えて相談することをお勧めします。

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

会社紹介

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

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

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

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

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

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