変更管理システム開発の見積相場や費用/コスト/値段について

変更管理システムの費用は、利用規模、連携範囲、統制要件によって変わり、初年度150万〜500万円程度から1,000万〜3,000万円超までの幅があります。

製造業の設計変更管理や、組織変革を指すチェンジマネジメントとは対象が異なります。

▼全体ガイドの記事
・変更管理システム開発の完全ガイド

変更管理システムの全体像

変更管理システムを中心に、OS、ネットワーク機器、クラウド、業務アプリ、データベースを結んだ図。
対象を一元化すると、変更の記録を追いやすくなります。

変更管理システムは、サーバー、ネットワーク、クラウド設定、業務アプリ、データベースなどの変更を一元管理します。申請、影響評価、承認、実施、検証、クローズまでを一つの記録に残すため、メールやExcelだけの運用に比べて、担当者や理由、対象サービスを追跡しやすくなります。

管理する変更の範囲

まず、どの変更を登録対象にするかを決めます。登録の対象には、次のような作業があります。

  • OS:パッチ適用
  • ネットワーク機器:設定変更
  • クラウド:権限変更
  • 業務アプリ:リリース
  • データベース:スキーマ変更

登録するのは、サービスに直接または間接に影響する作業です。一方で、単なる文書修正や利用者に影響しない検証環境の作業まで同じ承認にすると、入力負荷が増えます。

変更は、定型的で低リスクな標準変更、個別評価と承認が必要な通常変更、障害や脅威へ即応する緊急変更に分ける設計が一般的です。この分け方は、Atlassianの公式ガイドでも示されています(出典:Atlassian「Jira Service Managementにおける変更管理の仕組み」、2026年確認)。

申請管理と変更の証跡の連携

申請の記録で終わらせず、関連サービスや変更後の証跡まで追える形にします。そうすると、変更の結果を後から見返せます。

  • 評価と承認:申請フォーム、リスク・影響範囲の評価、承認ルート、変更カレンダー
  • 実施と記録:実施手順、テスト結果、バックアウト条件、実施後レビュー、監査ログ
  • 関連情報:CMDBや資産管理の対象サービスを、インシデントやリリースと紐付けた情報

開発組織では、GitHub、GitLab、Jenkins、Bitbucketなどと連携して、変更レコードを自動作成できます。また、デプロイ情報から影響サービスやリスクを取り込めます。統制のために開発者が別画面へ同じ内容を入力する負担も抑えられます(出典:Atlassian公式ガイド、2026年確認)。

変更管理システムの費用相場の目安

小規模導入、中規模連携導入、大規模統合やスクラッチ開発の初年度費用目安を横棒で並べた図。
連携や統合の範囲が広がるほど、費用帯も上がります。

申請・承認・履歴だけなら初年度150万〜500万円程度が目安です。これにCMDB、SSO、複数部門、カレンダー、インシデント連携を含めると、500万〜1,500万円程度になります。

大規模なITSM統合や複数拠点、24時間運用などを含む場合は、1,000万〜3,000万円超まで広がります。脆弱性管理や深いCI/CD連携も、費用を押し上げる要素です。これは製品単体の公的統計ではなく、公開料金と一般的な導入作業から整理した目安です。

小規模なクラウド導入の初年度費用(150万〜500万円程度)

小規模導入では、担当者数と機能を絞ったうえで、初期費用と初年度総額を分けて見積もります。

  • 対象規模:担当者5〜20人程度で、申請、承認、通知、履歴、簡易レポートを導入
  • 初期費用:業務設計・設定・テスト・教育に100万〜300万円程度
  • 初年度総額:ライセンスを含め150万〜500万円程度

導入期間は4〜8週間ほどが目安です。ただし、承認ルールの整理状況やSSO、メール通知の設定範囲によって変わります。

Freshserviceの年契約価格は、Starterが1エージェント月19ドル、Growthが49ドル、Proが99ドルです。変更管理はProに含まれます(出典:Freshworks「Freshservice Pricing & Plans 2026」、2026年確認)。

1ドル150円、10エージェントで単純換算すると、年約34万円、88万円、178万円です。この換算には為替、税、契約条件、追加機能、導入支援が含まれていないため、製品料金と導入費を合わせて判断します。

中規模の連携導入の初年度費用(500万〜1,500万円程度)

連携範囲が広くなると、必要な作業も初年度の総額も増えるため、両方を合わせて確認します。

  • 対象範囲:CMDB、資産管理、複数部門の承認、カレンダー、インシデント管理、SSO、監視、CI/CD連携
  • 導入作業:業務棚卸し、権限設計、データ移行、API開発、結合テスト、教育
  • 費用目安:初期作業300万〜1,000万円程度、初年度総額500万〜1,500万円程度

ManageEngine ServiceDesk Plusのクラウド年間ライセンスは、5オペレーターの場合で29.1万円からです。10オペレーターではStandardが48.5万円、Professionalが63.9万円、Enterpriseが122.4万円です。構築支援は187万円からです(出典:ゾーホージャパン「ServiceDesk Plus 価格一覧」、2026年確認)。

公開価格がある製品でも、オペレーター数、管理ノード数、サービスカタログ、連携、オンボーディングによって総額は変わります。

大規模統合やスクラッチ開発の費用(1,000万〜3,000万円超)

大規模導入では、統合する範囲に応じて費用と導入期間を見積もる必要があります。

  • 大規模化の要件:複数拠点・グループ会社で統一し、24時間運用、監査、冗長化、複数インスタンス、脆弱性管理、ITOM、データ分析を統合
  • 費用目安:該当する場合は1,000万〜3,000万円超

要件定義は1〜2か月、設計・開発は2〜6か月、連携・移行・テストは1〜3か月が目安です。これらを合算すると、導入期間は6〜12か月以上になることがあります。

ServiceNowの料金ページはITSM Foundation、Advanced、Primeを示しています。変更管理はAdvancedに含まれますが、価格は個別見積もりです(出典:ServiceNow「IT Service Management Pricing」、2026年確認)。

大規模製品では、ライセンス、導入支援、連携開発、運用保守を分けたRFPを作ります。そのうえで、初年度費用だけでなく、5年間の総保有コストで比較します。

ポイント

迷ったときは、連携範囲と利用規模を先に決め、どの金額帯に当たるかで見積もりを比べます。費用の幅は、ITSM統合や24時間運用などの条件で大きく動きます。

変更管理システムの費用内訳

変更管理システムの費用を、ライセンス、設計・設定・開発、移行・連携・テスト、教育・保守などの4区分に整理した図。
費目を分けると、初年度以降にかかる作業も見渡せます。

見積書を「システム導入費」と一括りにすると、中身が見えません。そのため、費目ごとに確認します。

製品を契約しても、自社のリスク基準と承認ルールを製品に設定する作業が残ります。既存IT資産や開発ツールとの連携も必要です。さらに、利用者に使ってもらう工程も導入作業に含まれます。

ライセンス・クラウド利用料

ライセンス料は、エージェント数、オペレーター数、利用者数、管理対象ノード数、エディション、契約期間で決まります。また、申請者、承認者、閲覧者に有料ライセンスが必要かも確認します。

変更管理が上位エディションだけに含まれる製品もあります。そのため、最安プランだけで比べると、必要な機能を追加した時点で価格が上がる場合があります。

業務設計・初期設定・開発費

導入時の費用は、変更ルールの設計と製品上の設定に分けて見ていきます。

  • 業務設計:変更分類、リスクスコア、承認者、CAB条件、実施禁止時間、バックアウト、事後レビュー、KPIを決定
  • 初期設定:フォーム、ワークフロー、通知、権限、レポート、カレンダーを構成

製品標準に合わせるFit to Standardの方式なら、費用を抑えやすくなります。一方で、独自の承認分岐や画面を多く作るほど、開発費が増えます。

スクラッチ開発は、申請と承認だけなら数百万円規模から検討できます。ただし、監査証跡や権限分離、CMDB、SSOまで再現すると、費用が増える可能性があります。CI/CD、API、可用性、レポートまで含めると、さらに増えることもあります。

類似する業務システムの範囲から推定すると、中規模開発は500万〜1,500万円程度、大規模開発は1,000万〜3,000万円超です。ただし、これは変更管理システム固有の公開統計ではありません。

データ移行・外部連携・テスト費

既存記録の移行やCMDBの整備では、まず対象データと必要な作業を一覧にします。

  • 履歴データ:変更履歴、サービス、構成情報、担当者、承認履歴を抽出・名寄せ・整理・変換・検証
  • CMDB新設:サーバーやクラウド資産に加え、サービスとの関係や責任者を定義

対象システム数や履歴年数が増えるほど、移行費も大きくなります。

連携先には、SSO、Active Directory、Microsoft Entra IDが含まれます。Slack、Teams、監視ツール、GitHub、Jenkinsも対象です。さらに、資産管理、脆弱性管理、分析基盤との接続も対象になり、工数が変わります。

APIの有無と認証方式も工数に影響します。そのため、見積書には連携先ごとに、対象データ、送受信方向、リアルタイムかバッチか、エラー時の再送、監査ログの保管方法を記載してもらいます。

教育・運用保守・追加費用

導入後も使い続けるため、教育、日々の運用、保守にかかる費用も見ておきます。

  • 利用者教育:申請者、承認者、変更マネージャー、運用・監査担当者に、標準変更や緊急記録、失敗時の判断を説明
  • 運用保守:問い合わせ、ワークフロー変更、権限棚卸し、バックアップ、ログ保管、更新、障害対応、KPI作成
  • オンプレミス:サーバー、冗長化、パッチ、監視の費用も発生

教育を省くと、メールやチャットでの抜け道が残り、導入効果が出にくくなります。

ManageEngineの価格表では、2年目以降の年間保守や追加ノード、サービスカタログが別料金になっています(出典:ゾーホージャパン公式価格表、2026年確認)。5年TCOの算出には、更新や追加の費用も含めます。

ポイント

見積書は費目ごとに分けて比べ、初年度の金額だけで判断しないようにします。教育や保守、追加費用の扱いも、比較の対象に含めます。

変更管理システムの費用が変動する要因

同じ製品でも、企業ごとに見積額は異なります。その差は、ユーザー数だけで決まるわけではありません。

対象サービスや変更件数、データ品質は、価格に影響します。連携先や監査要件、可用性、運用体制も、価格を左右する条件です。これらの条件を整理すると、見積額の差の理由を把握できます。

ユーザー数と対象サービス数

料金は、課金単位となるエージェント、申請者を含む利用者、管理対象ノードのどれかで変わります。見積もりの前に、月間変更件数、対象サービス数、承認者数、同時利用者数を整理しておきます。

本番・検証・開発環境を別インスタンスにする場合や、グループ会社ごとに権限領域を分ける場合は、ライセンスと設定工数が増えます。海外拠点を追加する場合も、権限領域と設定の対象が広がります。

セキュリティ・監査・可用性の要件

セキュリティや監査の要件は、必要な機能と構築範囲に反映されます。

  • 認証・権限:SSO、多要素認証、職務分掌、承認者と実施者の分離
  • 証跡・可用性:改ざん防止ログ、保存年数、保管地域、バックアップ、災害対策、SLA、24時間サポート

認証・権限や証跡・可用性の要件を多く求めるほど、上位プランや追加の構築が必要になります。

必要な証跡と保存期間を要件定義で決めておくと、後から追加する際の手戻りを抑えられます。経済産業省やIPAの公式情報も、管理体制や役割分担を明確にする考え方を示しています(出典:経済産業省・IPAの公式情報、2026年確認)。

システムを導入しただけでは、監査に自動的に適合するわけではありません。監査に対応するには、システムに加えて承認・実施・事後確認の担当を運用で定めます。この担当の決め方は、費用対効果にも関わります。

独自ワークフローとカスタマイズの量

部門ごとの申請書、例外的な承認経路、独自スコア、細かな帳票を再現すると、設定やテスト、保守の工数が増えます。さらに、「念のため」の承認者を加えると、承認待ちが長くなる可能性があります。

承認のワークフローは、標準変更を自動承認し、高リスク変更だけを追加承認に回すなど、リスクに応じて段階に分けます。

ポイント

同じ製品でも、対象サービスや連携先、監査要件、運用体制によって見積額は変わります。見積もりを比べる前に、これらの条件を揃えておきます。

変更管理システムの導入・開発の進め方

費用を抑えるには、製品を先に決めず、現状の変更業務と目指す統制を整理することから始めます。

最初から全社のCMDBを完璧に作ろうとせず、重要サービスを対象に小さく稼働させるのが現実的です。入力負荷と承認リードタイムを測りながら、範囲を広げていきます。

直近6〜12か月の変更実績の棚卸し

現状を把握するため、変更の発生状況と記録の不足を一覧にします。

  • 変更の実績:直近6〜12か月の申請経路、承認者、種別、緊急・失敗変更、変更起因インシデント
  • 記録の状態:対象サービス、実施時間、事後レビューの記録の有無
  • 経路と不足情報:メール、Excel、チケット、チャット、口頭による連絡の経路と、件数だけでは分からない欠けた情報

棚卸しをしないまま高機能製品を選ぶと、使わない機能に費用を払うことになり、入力項目だけが増えます。

たとえば、変更件数が少ない部門は簡易ワークフローから始め、変更頻度が高い開発部門はCI/CD連携を優先するなど、実態に基づいて範囲を決めます。

分類・承認・バックアウトのルール設計

まず、標準・通常・緊急の判定基準を決めます。そのうえで、影響度と発生確率、承認者、CAB条件を決めます。実施禁止時間、テスト、バックアウト、事後レビュー期限も決めておきます。

  • 標準変更:手順が固定され、影響範囲が限られたパッチ適用
  • 通常変更:業務停止を伴う基幹システム更新
  • 緊急変更:重大障害の封じ込め

緊急変更に通常と同じ事前承認を求めると、復旧が遅れます。一方で、緊急時に記録を省くと、監査証跡と再発防止の材料を失います。

このため、緊急変更は事後レビューを必須にし、標準変更はテンプレート化して自動承認するなど、速さと統制を両立させます。

1部門・1サービスからの試験導入

重要度が高く件数を把握しやすい1部門または1サービスで、申請、承認、カレンダー、実施記録、KPIを稼働させます。4〜8週間程度の導入の中で、入力時間、承認待ち、標準変更への移行件数、事後レビュー完了率を見ていきます。

改善点を設定に反映してから、CMDBや資産管理、脆弱性管理へ連携を広げます。その後、監視、CI/CD、チャット、分析も順に加えます。一括で導入する場合に比べると、要件の膨らみや不要なカスタマイズを抑えやすくなります。

KPIの月次見直し

月次では、変更成功率、緊急変更率、変更起因インシデント率、承認リードタイム、標準変更比率、事後レビュー完了率を見ていきます。そのうえで、失敗や手戻り、低リスク変更の承認速度、重要変更の証跡を評価します。

目標値は、導入前の自社実績を基準にします。ベンダーの事例にある改善率は、そのまま自社の成果とは見ず、対象サービスや運用体制の違いを踏まえて現状値を測ります。

ポイント

費用を抑えるには、製品を決める前に現状の変更業務と目指す統制を整理します。範囲の拡大は、入力負荷と承認リードタイムを測って判断します。

変更管理システムのコストを最適化するポイント

コストを抑えるには、使わない高機能を避け、二重入力を減らし、後から作り直すことになるリスクを小さくします。そのとき、初期費用だけでなく、運用負荷や障害・監査対応にかかる間接コストも含めて考えます。

製品標準の活用と独自開発の絞り込み

費用を抑えるには、標準機能で賄う範囲と、独自に設定する範囲を分けて決めます。

  • 標準機能を優先:既存帳票に合わせて申請項目や承認画面を作り込みすぎると、カスタマイズ費と更新時の検証費が膨らむ
  • 追加設定を限定:法令、監査、業界固有の統制に必要な部分に絞るFit to Standardを基本とする
  • 共通キーを定義:変更ID、サービスID、リスク区分、実施日時、担当者を決め、細かな画面より他システムから参照できる設計を優先

標準変更のテンプレート化と承認の自動化

承認の速さと統制を両立させるには、標準変更の条件と事前準備を整理します。

  • 承認工数を抑える:低リスクで繰り返す変更を毎回CABに回すと、承認工数と待ち時間が増えます
  • 手順を定型化:対象範囲、テスト、バックアウト、実施者をテンプレートに組み込みます

Atlassianの公式ガイドも、標準変更の自動承認で通常変更の滞留を減らす考え方を紹介しています(出典:Atlassian公式ガイド、2026年確認)。

自動化では、リスク評価を残したまま承認を速めます。対象サービス、時間帯、手順、担当者、バックアウト条件をすべて満たす場合だけ承認し、外れた場合は通常変更に戻します。

この条件を設けることで、統制を弱めずに承認者の作業量を減らせます。

初年度費用と5年TCOの比較

5年間で比べる場合は、初年度のライセンス、設定、連携、移行、教育を含めます。さらに、2年目以降の保守と更新、社内の運用工数も加えます。ほかに次の項目も加わります。

  • 追加のユーザーやノード
  • ストレージ
  • AIやレポートのオプション

クラウドは初期費用を抑えやすい一方、利用者や機能の増加で月額が伸びることがあります。オンプレミスは買い切りでも、サーバー、冗長化、バックアップ、パッチ、監視、障害対応が必要です。

SaaS、パッケージ、ローコード、スクラッチを同じ費目で並べて比べ、5年間でどの業務リスクを減らせるかまで評価します。

変更管理システムの見積もりを取る際のポイント

見積もりの精度は、依頼の時点で前提条件を揃えられるかで決まります。そのため、変更対象、利用者、連携先、監査要件、導入時期、運用体制を共有します。

複数社から同じ前提で提案を受けたうえで、価格だけでなく対象範囲と成果物も比べます。

見積もり依頼書に書く対象範囲

同じ条件で提案を比べられるように、依頼書に記載する情報を整理しておきます。

  • 利用規模と業務:対象部門、利用者・承認者数、月間件数、サービス数、変更種別の比率
  • 既存環境:ITSM、CMDB、資産台帳、SSO、CI/CD、チャット、監視、脆弱性管理との連携
  • 運用条件:ログ保存年数、SLA、開始時期を記載し、変更サンプルを数件添付して必要項目や分岐を伝える
  • 成果物:要件定義、業務フロー、設定・権限・連携仕様、移行・テスト計画、マニュアル、教育、運用設計、KPIダッシュボード

成果物が曖昧だと、教育や移行が追加請求になる場合があります。そのため、どの作業が見積もりに含まれるかを確認しておきます。

製品・導入会社・開発会社の比較

製品の得意領域と導入会社の支援力を分けて見ると、候補の違いが見えてきます。

  • 製品の前提:ServiceNowは大規模なITSM・ITOM統合に、Jira Service Managementは開発・DevOps連携に向く候補
  • 小規模導入:ManageEngineやFreshserviceは公開価格を確認しながら始めやすく、導入規模や前提は候補ごとに異なります
  • 導入会社:同規模・同業界の実績、ITIL・製品資格、業務設計の範囲、API連携や移行の経験
  • 運用支援:セキュリティ・監査、保守、追加費用の扱いに加え、入力定着やKPI改善まで支えてくれる会社かどうか

安すぎる見積もりと高すぎる見積もりの確認点

安い見積もりは、ライセンスだけで、初期設定、移行、連携、教育、保守が含まれていないことがあります。一方で、高い見積もりでは、全社展開、高度なCMDB、不要なカスタマイズが入っていないかを確かめます。

含む作業と含まない作業、前提条件、変更時の単価を表にして比べます。

要件が固まっていない場合は、本開発の一括見積もりより先に、現状分析と基本設計を行う方法もあります。調査費用はかかりますが、要件の膨らみや手戻り、追加開発を抑えやすくなります。

ポイント

同じ前提条件で複数社から提案を受け、価格だけでなく対象範囲と成果物の違いも比べます。成果物が曖昧な見積もりは、追加請求になる作業の有無を確かめます。

よくある質問

変更管理システムの費用を考える際は、料金表だけでなく、自社の運用に必要な機能と作業を確認します。導入前によくある疑問を、順に取り上げます。

変更管理システムは10人程度の情シスでも導入できますか?

導入できます。申請、承認、通知、履歴、カレンダーに絞り、標準変更をテンプレート化すれば、4〜8週間程度の小規模導入から始められます。

最初からCMDBや全社連携を完成させようとせず、1部門・1サービスで効果と入力負荷を確かめてから広げます。

パッケージ導入とスクラッチ開発はどちらが安いですか?

一般的な申請、承認、監査ログ、通知を使うなら、パッケージやSaaSのほうが初期費用と期間を抑えやすいです。

一方で、独自承認、業界固有の統制、既存基幹との深い統合が必要な場合は、スクラッチも候補になります。その際は、ITILの知見や権限、ログ、通知、更新対応を自社で作る費用も含めて比べます。

ライセンス料金だけで変更管理システムを使えますか?

使い始められる製品はありますが、効果を出すには、初期設定、権限設計、移行、連携、テスト、教育が必要になることが多いです。

変更管理が上位プランに含まれる製品や、ノード、サービスカタログ、監査ログが別料金の製品もあります。そのため、ライセンス、初期費用、保守、追加オプションを分けて確認します。

費用を抑えるには何から始めればよいですか?

直近6〜12か月の変更実績を棚卸しし、対象を重要サービスに絞って、申請、承認、実施記録、事後レビューを小さく始めます。

標準変更をテンプレート化し、製品標準に合わせ、効果の高い連携から段階的に加えると、初期カスタマイズ費と運用負荷を抑えられます。

まとめ

申請・承認中心の小規模導入は初年度150万〜500万円程度、CMDBやSSO、複数部門、CI/CD連携を含む中規模導入は500万〜1,500万円程度が目安です。

大規模統合やスクラッチ開発は、1,000万〜3,000万円超になる場合があります。いずれも公開料金と作業範囲から整理したレンジで、ユーザー数、サービス数、連携先、監査要件、カスタマイズ、運用体制によって変動します。

費用判断で確認する項目

見積もりでは、ライセンスと業務設計を分けて書いてもらいます。さらに、次の項目も別々に見ます。

  • 設定、移行、連携
  • テスト、教育
  • 保守、更新
  • 追加ユーザー・ノード
  • 社内運用工数

初年度価格だけでなく、5年TCO、導入期間、成果物、追加費用の条件を比べると、後から予算が膨らむリスクを抑えられます。

小さく始める運用の改善

変更管理システムは、導入後も運用を続けることで効果を出します。その運用には、標準・通常・緊急の使い分け、承認の自動化、実施後の検証、KPIの月次改善が含まれます。

まずは直近の変更実績を整理し、必要な範囲を定めます。そのうえで、複数の製品・導入会社へ同じ条件で相談します。

▼全体ガイドの記事
・変更管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

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