インシデント管理システムの発注は、現状整理、RFPとPoC、見積比較、段階導入の順に進めます。この進め方をとると、現場に定着し、MTTAやMTTRの改善につながります。
発注形態と要件整理、契約と費用、委託先の選定の順に、各段階で決めておきたいことを見ていきます。
▼全体ガイドの記事
・インシデント管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
インシデント管理システムを発注・外注する前の全体像
インシデント管理システムは、障害やサービス停止、性能劣化、IT問い合わせを記録する運用基盤です。担当者への割り当てから、復旧後の再発防止までをつなぎます。
発注時は、機能だけでなく委託範囲も決めておく必要があります。重大度や当番、エスカレーションを委託に含めるかどうかが論点になります。加えて、顧客告知やポストインシデントレビューについても、委託の範囲を決める必要があります。
外注する対象の範囲
重大度や担当グループが曖昧なままだと通知が乱れ、現場がメールやチャットへ戻ってしまいます。そのため、発注書には開発の納品物に加えて、運用設計と定着支援の範囲も記載します。
- 導入準備：製品選定と業務フロー設計
- 構築と連携：画面・フォーム設定、監視ツール・Slack・Teams・SSOとの連携
- 定着支援：過去チケット移行、操作教育、リリース後の保守
導入成功を測る指標
成功条件は、チケットを作れることより、受付漏れや担当者不明を減らし、復旧を早めて再発を防げることに置きます。導入前に現状の指標を計測しておくと、導入後に何が変わったかを比べられます。
- 応答と復旧：MTTA（検知・受付から認知までの時間）とMTTR（復旧までの平均時間）
- 対応品質：重大インシデントのSLA達成率とアラート重複率
- 再発防止：再発率とナレッジによる自己解決率
目標値は最初から断定せず、過去3〜6か月の実績を基準に、段階的な改善目標をRFPに記載します。
インシデント管理システムを外注する発注形態の選び方
発注形態には、SaaSとITSMパッケージ、自社運用型パッケージ、独自開発があります。どれを選ぶかは、必要な運用を早く安全に始め、将来の連携や改善を止めない視点で決めます。
既存の開発チケットや監視基盤を活用できる場合は、SaaSを標準設定で使い、不足する部分だけをAPIやローコードで拡張する方法が有力です。
SaaS・パッケージ導入による短期立ち上げ
SaaSやパッケージには、受付フォームやキュー、優先度といった仕組みがあります。SLAやオンコール、エスカレーション、レポートも備わっているため、ゼロから作るより早く運用を始められます。
- 向く企業：情シスが少ない企業や、障害対応を見える状態にしたい企業
- 既存基盤の活用：JiraやConfluenceを使う企業
- 確認事項：標準機能が業務に合うかと、移行・教育の担当
総額は、ユーザー数やエージェント数、通知数で変わります。さらに、アセットやCMDBの数、AI利用量によっても変わり、SSOの利用、データ保管地域、サポートレベルの違いも影響します。このため、月額料金だけで判断しないことが大切です。
独自要件が明確な場合のスクラッチ開発の検討
既製品が業務に合わない場合に検討します。たとえば、複数拠点の特殊な承認や顧客向けステータスページ、独自の構成管理、固有の監査要件などです。
構築では画面に加えて、権限分離や監査証跡、バックアップを設計します。冗長化や通知再送、障害時の代替連絡手段も、設計の対象です。
また、独自開発でも、受付、重大度、担当割当、通知、履歴、SLAを最小構成で先に稼働させます。問題・変更管理、AI要約、自動修復は運用データの蓄積後に追加します。そうすることで、要件の作り直しを減らせます。
RFPと要件整理の進め方
RFPは製品名を指定する文書ではありません。そのため、業務課題、必要な運用、制約条件、評価基準を候補企業へ同じ条件で伝えます。
まず、過去の障害や問い合わせを洗い出します。受付経路や影響サービス、重大度、夜間対応、復旧時間、再発原因をまとめると、提案を比較しやすくなります。
MUSTとWANTに分けた業務要件
MUSTには導入初日に必要な機能を、WANTには将来の要件を記します。必須要件と将来要件を分けておくと、提案の比較がしやすくなります。
- 受付と分類：メール・Webフォーム・チャット・監視API、カテゴリ・緊急度
- 対応管理：自動割当、オンコール通知、エスカレーション、履歴、SLA計測
- 将来要件：AI要約・分類、顧客向けページ、自動修復、予測分析
また、障害対応とセキュリティインシデントを同じデータモデルで扱うか、SOC・SIEM・SOARと分けるかも明記しておきます。
IPAの「中小企業の情報セキュリティ対策ガイドライン第4.0版」は、障害やセキュリティ問題に備える考え方を示しています。たとえば、平時にシステムの重要度を評価し、稼働継続や復旧を計画することです（出典: IPA、2026年）。
発注先には、重大度ごとの復旧目標と判断者を質問します。連絡先や手順書、演習の扱いについても確かめます。
連携要件と非機能要件の記載漏れ防止
RFPでは、監視・ログ・EDRからイベントを受け、重複を抑えてチケットを作り、SlackやTeamsで協働する流れを示します。CMDBやナレッジ、ランブックを参照して復旧する流れも書き添えます。連携と非機能の条件を明記すると、費用や運用上の見落としを抑えられます。
- 連携：製品名、API・認証方式、データ項目、再送、通知遅延の許容時間
- システム要件：可用性、バックアップ・復旧、監査ログ、権限、SSO・MFA、保管地域、暗号化、ログ保存期間、同時アクセス
- データ保護：代替連絡手段、海外リージョン、再委託、データ返却・消去の条件
個人情報や顧客情報を扱う場合は、上に挙げた条件を契約前に確かめておきます。
契約形態と発注後の進め方
契約では、要件が固まった部分と、検証しながら決める部分を分けておきます。そのうえで、現状調査と運用設計を先に進め、PoCで通知や割り当てを試します。こうすると、現場とのずれを見つけやすくなります。
準委任・請負・保守契約の使い分け
作業時間や専門知識の提供に報酬を払う準委任は、上流の作業に適する場合があります。
納品物と完成条件を明確にできる作業は、請負で管理しやすい領域です。
このため、上流は準委任、合意した機能の構築は請負、稼働後は保守・運用契約に分ける構成が現実的です。
- 準委任：現状調査、要件整理、運用設計、PoC
- 請負：設定、画面開発、移行プログラム、テスト
- 保守・運用：稼働後の支援と問い合わせ対応
契約書では、納品物と検収、仕様変更、遅延、再委託を確認します。さらに、秘密保持や個人情報、知的財産、脆弱性は、預けるデータの扱いに関わる項目です。また、障害時に誰がどこまで受け持つか、SLA、サポート時間、解約時のデータ返却も押さえます。
24時間365日の監視や電話通知を求める場合は、平日日中の窓口と分けて考えます。そのうえで、対応時間と一次切り分けの範囲を具体的に決めます。
調査・PoC・本番展開・定着支援の区切り
各段階は順に進めます。段階ごとに区切って検証すると、通知過多や入力項目の多さ、責任者不明、古いCMDB情報を本番前に見つけられます。
- 過去のチケット、メール、チャット、監視アラートの収集と、重大度や受付漏れ、エスカレーションの遅れの分析
- 代表的な障害を数件選び、アラート集約、担当割当、当番通知、Slack・Teams連携、復旧後のPIRを試すこと
- 本番環境への展開
- 教育、運用レビュー、KPI確認、改善バックログの作成
委託先には、各段階の終了条件を示します。その条件は、検収できる表現にします。たとえば、重大度1のテストで、指定当番へ設定時間内に通知され、対応履歴と復旧時刻を記録できることです。
インシデント管理システムの費用相場と内訳
費用は、ライセンスと初期設定、連携、移行に分けて見積もります。さらに、教育や保守、通知料金も別に見ておきます。
公開定価が確認できるSaaSと、要件で変わる導入・開発費は、性質が異なります。後者は、類似業務システムの公開情報をもとにした推定です。
ただし、ここで示す金額は個別案件の価格を保証するものではありません。RFPで各社を比べるための目安です。
ライセンス数と機能範囲を分けて読む公開価格
公開価格は、プラン条件と追加機能を合わせて読みます。外貨建ての価格は、見積取得時の為替レートで円に換算します。
- 無料枠：利用できるエージェント数やユーザー数
- 基本料金：契約単位、契約期間、月額単価
- 追加費用：追加機能、アセット、為替、税
AtlassianのService Collectionでは、Jira Service Managementを含む無料プランが3エージェントまでです。Standardは1エージェント月額20ドル、Premiumは同51.42ドルです（出典: Atlassian公式料金表、2026年8月確認）。
Premiumには、高度なAIOpsやリアルタイム監視、インシデント・問題管理、変更管理などが含まれます。支払額は、為替や契約期間、税、追加アセット数によって変わります。
PagerDutyのIncident Managementは無料プランが5ユーザーまでです。Professionalは年契約表示で1ユーザー月額21ドル、Businessは同41ドルです（出典: PagerDuty公式料金表、2026年8月確認）。
オンコールやエスカレーション、電話・SMS通知、監視連携は、各社を比べる材料です。一方で、AI、AIOps、ステータスページ、関係者向けライセンスは追加費用になり得ます。
初期設定からスクラッチ開発までの推定レンジ
初期費用と期間は、導入方式や連携範囲で変わります。下に挙げるのは、推定の目安です。
- SaaS標準設定：30万〜150万円、2〜6週間
- 監視・API・Slack・Teams・SSO連携：100万〜500万円、1〜3か月
- CMDB・移行・問題変更管理・教育を含むITSM：500万〜1,500万円、3〜6か月
- 小〜中規模の独自開発：1,000万〜3,000万円以上、6〜12か月
- 大規模なエンタープライズ案件：2,000万〜5,000万円以上となる可能性
標準設定には、受付フォームや重大度、キュー、SLAを想定します。基本通知と権限設定も想定に入ります。なお、ライセンスは別です。
連携費用は、アラート重複排除や自動割当の有無で増減します。認証やテスト、運用手順作成も、費用の増減に関わります。
大規模案件の推定には、高可用性や複数拠点、顧客向けページを含みます。加えて、SOC・SIEM連携や24時間365日の運用委託も入ります。この数字は、対象専用の統計ではなく、類似業務システムの公開情報に要件を加味した推定です。
AWS Systems Manager Incident Managerは、既存顧客向けにレスポンスプラン1件あたり月額7ドルでした。また、SMS・音声通知は100件まで無料でしたが、2025年11月7日から新規顧客への提供を終了しています（出典: AWS公式料金表・ドキュメント、2026年8月確認）。
提供を終えたサービスがあるため、新規発注では、提供継続性、代替機能、データ移行方針を確認します。過去の価格表だけで候補に残さないよう注意します。
委託先の選定と見積比較で確認するポイント
製品を提供するベンダーと、導入・連携・運用を担うSIerは分けて評価します。ServiceNowやAtlassian、PagerDuty、BMCなどの製品知識に加え、自社環境をつなぐ経験も確認します。
実績・体制・対応範囲を同じ質問で比べる方法
類似規模の実績は、担当した工程や機能まで確認します。さらに、重大インシデントのシナリオを渡して、検知から通知、指揮、顧客連絡、復旧、レビューまでのデモを求めます。同じ質問で各社を比べると、違いがはっきりします。
- 対応実績：受付統合、ノイズ抑制、オンコール、CMDB、PIR、問題・変更管理
- 担当体制：PM、運用設計、連携エンジニア、セキュリティ、教育の担当者
- 移管と支援：24時間運用、内製化支援、保守窓口、納品物の受け渡し
再委託がある場合は、会社名や役割、品質管理、情報管理を聞きます。また、設定情報やAPI仕様、運用手順、テスト結果、管理者教育を受け取れるかも評価します。
見積書の初期費用とTCOの比較
見積書では、初期費用と継続費用を分けて見ます。1年目の初期費用だけでなく、継続費用を含めた3年程度のTCO（総所有コスト）で比べます。また、ライセンス数や通知量などの前提もそろえます。
- 作業費：要件定義、設定・開発、連携、移行、テスト、教育、管理、リリース、保守
- ライセンス：エージェント、閲覧者、当番、顧客ユーザー、通知、アラート、CMDB、AI、SSO、サポート
- 継続費用：2年目以降の月額、追加通知、ストレージ、更新、運用改善
安い見積もりでも、監視連携や移行、教育、夜間対応、障害時の再作業が対象外のことがあります。反対に、高い見積もりには、不要なカスタマイズや過剰なライセンスが含まれる可能性もあります。
そこで、各社へ同じ前提条件と質問票を渡します。さらに、価格差が工数、範囲、品質、体制のどれから生じるか、説明を求めます。
ベンダーロックインと導入後の放置の防止
外注時のリスクは、設定が特定の担当者に依存すること、仕様変更や値上げで予算が膨らむこと、通知過多で使われなくなることです。
- 引き継ぎ性：API、データ出力、設定一覧、権限、運用手順の文書化
- 契約終了：データ返却の条件と、障害時の代替連絡先
- AI利用：誤分類・誤修復に備えた承認、人へのエスカレーション、操作ログの要件
月次または四半期ごとに、MTTAやMTTR、SLA達成率、アラート重複率を確認します。さらに、再発率や未完了チケット、ナレッジ利用も見ていきます。
数字が改善しない場合は、すぐに製品を替えず、まず重大度や当番、通知先を見直します。ランブックや入力項目、問題管理との連携も確認します。また、定例会と改善支援時間を保守契約に含めると、導入後の放置を防ぎやすくなります。
よくある質問（FAQ）
発注形態、費用、製品の提供状況に関する疑問をまとめます。運用時間や既存ツール、セキュリティ要件、将来の内製化方針と照らし合わせて読んでください。
インシデント管理システムはSaaSとスクラッチ開発のどちらがよいですか？
多くの企業ではSaaSやITSMパッケージを標準導入し、不足部分を連携や拡張で補う方法が始めやすいです。一方で、独自承認、顧客画面、規制対応、高度な可用性などが既製品に合わない場合は、スクラッチ開発を検討します。
発注・外注すると開発費はいくらかかりますか？
標準設定は初期30万〜150万円、監視・API・SSO・チャット連携は100万〜500万円程度が推定レンジです。また、CMDB、移行、教育、問題・変更管理を含むパッケージは500万〜1,500万円、独自開発は1,000万〜3,000万円以上が目安です。
ただし、いずれも公開定価ではなく要件に基づく推定です。ライセンス、通知、保守、運用委託を含むTCOで見積もります。
RFPには最低限何を記載すればよいですか？
まず、受付経路や過去の障害件数と対応時間、重大度、担当体制を記載します。次に、受付・通知・連携の要件や、権限・監査要件、MUSTとWANTを書きます。さらに、予算、希望時期、評価基準も示します。
代表的な障害シナリオや移行件数、連携対象、検収条件、導入後の教育と保守の希望も添えると、見積と提案を比べやすくなります。
AWS Incident Managerを新規導入候補にしてもよいですか？
AWSの公式情報では、Incident Managerは2025年11月7日から新規顧客への提供を終了しています。既存顧客は継続利用できます。
新規発注では、AWS Systems Manager OpsCenterなどの代替機能や、他社サービスも候補に含めます。選定にあたっては、提供状況、移行性、通知、ランブックの実装範囲を確認します。
まとめ
発注前には、機能数や月額料金だけでなく、監視から通知、復旧、PIRまでの業務をどこまで変えるかを決めます。そのうえで、過去3〜6か月の障害と問い合わせを洗い出し、MUSTとWANTに分けます。
RFPには、重大度や当番、エスカレーション、SLAを書きます。連携やセキュリティ要件もまとめます。こうして社内情報をそろえておくと、不要なカスタマイズを避け、現実的な提案を受けやすくなります。
発注前に社内でそろえる情報
候補企業に相談する前に、過去のインシデントや受付経路、担当グループ、当番を一覧にします。復旧目標、監視・チャット・認証基盤も一覧に加えます。
要件は最初から完璧にそろえなくても構いません。困っている状態と目指す状態を共有すれば、不要なカスタマイズを避けられます。
小さなPoCと同条件の見積依頼
本番導入の判断材料は、順を追ってそろえます。
- 大規模な本番構築をすぐ決めず、代表的な障害シナリオで通知、割り当て、復旧記録、PIRを試します。
- 同じRFPを複数社へ渡し、初期費用とライセンス、連携・移行、教育・保守・運用委託を分けた見積を受け取ります。
- 製品提供元か、導入・連携・運用会社かを見分け、実績と体制、移行、教育、保守、内製化支援を比べます。
- TCOは数年分で判断し、検収条件を満たしてから本番展開すると、現場への定着につながります。
▼全体ガイドの記事
・インシデント管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。