業務システムの保守費用はなぜ発生するのか
保守費は "何もしていない費用" ではなく、システムを止めないための費用である。
この記事の結論
- 保守費は 「リリース後にシステムを止めないための費用」 です。何もしていないように見えても、監視・障害対応・セキュリティ更新・外部 API 対応が常に発生しています。
- 保守費には 監視・障害対応・軽微改修・セキュリティ更新・外部 API 対応・問い合わせ対応・運用相談 が含まれます。
- 保守をしないとシステムは 3〜6 ヶ月で動かなくなる リスクが顕在化します (依存ライブラリの脆弱性、外部 API の仕様変更、認証プロバイダの更新など)。
- 月の保守費用は 開発予算の 15〜25% が相場感です。
- 契約時に確認すべきは、対応時間・対応範囲・優先度・SLA・追加費用の発生条件。
「保守費が毎月かかるけど、何もしてもらってない感じで……」
リリース後の発注者からよく出る不満です。実際は何もしていないわけではなく、内訳が見えにくいだけのことが多くあります。
保守費は「何もしていない費用」ではなく、「システムを止めないための費用」 です。発注者がこれを理解した上で契約すると、保守会社との関係性も健全に保てます。
この記事では、保守費の内訳、保守をしないと起きること、相場感、契約時の確認項目を整理します。
保守に含まれる作業
「月額固定で何もしていない」と思われがちですが、実際には以下の作業が常に発生しています。
1. 監視
- エラー監視 (Sentry / Datadog)
- パフォーマンス監視
- 外部 API の状況確認
- バッチ実行状況の確認
- セキュリティアラート対応
2. 障害対応
- 緊急障害時の対応
- 軽微障害の修正
- 根本原因の調査
- 再発防止策の実装
- 障害報告書の作成
3. 軽微改修
- 文言の修正
- 項目の追加
- 表示順の変更
- データ抽出依頼への対応
- ユーザー追加・削除
4. セキュリティ更新
- 依存ライブラリの脆弱性対応
- セキュリティパッチの適用
- 認証プロバイダの更新対応
- 暗号化アルゴリズムの更新
5. 外部 API 対応
- Stripe のバージョンアップ対応
- 認証プロバイダ (Clerk / Auth0) の仕様変更
- 連携先 SaaS の API 変更
- 廃止される API の代替実装
6. 問い合わせ対応
- 開発内容に関する質問への回答
- 運用上の相談
- 機能改善のアイデア出し
- ベストプラクティスの共有
7. 運用相談・改善提案
- 月次の振り返り会議
- KPI レビュー
- 次の打ち手の提案
- 内製化計画への協力
これらが、月額固定の中に含まれています。
保守をしないと起きること
「コスト削減のため、保守契約を切ろう」と判断するとき、起きうるリスク:
短期 (1〜3 ヶ月)
- 軽微なバグが放置される
- 依頼の対応に時間がかかる
- 障害発生時の連絡先が不明
- 操作方法の質問に答えられる人がいない
中期 (3〜6 ヶ月)
- 依存ライブラリの脆弱性が放置され、セキュリティリスク
- 外部 API の変更でシステムが止まる
- 認証プロバイダの仕様変更でログインできなくなる
- バッチが失敗していても気づかない
長期 (6 ヶ月以上)
- システムが「触れる人がいない」状態
- 改修を依頼しようとしても、現状把握から再見積もり
- 移行先を探すのに数ヶ月
- 業務がシステム外に逃げて、Excel・LINE に戻る
OpenAI が AWS との提携で強調しているのも、エンタープライズ AI 導入では 既存のセキュリティ・コンプライアンス・ガバナンスのワークフロー に乗ることが鍵だ、というポイントです (OpenAI frontier models and Codex on AWS / OpenAI)。AI でないシステムでも、運用と保守は同じく組織と運用フローに組み込む必要があります。
Anthropic のセキュリティ解説でも、AI を使った脆弱性管理のボトルネックは 「発見」ではなく「検証・トリアージ・修正」 に移っていると整理されています (Using LLMs to Secure Source Code / Anthropic)。保守が「修正」の役割を担う以上、止めると累積していくのが普通です。
保守費用の相場感
「いくらが妥当か」の目安:
| 規模 | 月の保守費用 | 開発予算比 |
|---|---|---|
| 小規模 SaaS (利用者 100 人以下) | 10〜30 万円 | 15〜20% |
| 中規模 SaaS (利用者 1,000 人) | 30〜80 万円 | 15〜25% |
| 大規模 SaaS / 業務システム | 80〜200 万円 | 15〜30% |
| エンタープライズ / 24h 対応 | 200 万円〜 | 30%〜 |
開発予算の 15〜25% が、月の保守予算の現実的な目安です。これより安いと、軽微改修対応が遅くなる傾向があります。
ここまでで「保守契約の見直しが必要」と感じたら、保守内容の整理から相談するのが現実的です。
契約時に確認すべきこと
保守契約を結ぶときに、確認すべき項目:
| 項目 | 確認すること |
|---|---|
| 対応時間 | 平日のみ / 24h / 営業時間 |
| 対応範囲 | 軽微改修の上限時間、セキュリティ更新の含む範囲 |
| 優先度 | 緊急障害は何時間以内に対応か |
| SLA | 稼働率の保証 (例: 99.5%) |
| 報告 | 月次レポートの内容 |
| 追加費用 | 軽微改修上限を超えた場合、緊急対応 |
| 契約解除 | 解除時の引き継ぎ、ドキュメント引き渡し |
| 内製化への協力 | 将来的に社内に引き継ぐ場合の協力範囲 |
特に 「対応時間」「優先度」「SLA」 は曖昧にしないことが重要です。「夜中に動かなくなった時にどうなるか」を契約時に決めます。
SLA を約束しすぎない
発注者は「99.99% 稼働」を期待しがちですが、それを保証するにはインフラ費用と人件費が膨らみます。
| SLA | 月の許容ダウンタイム | 必要な体制 |
|---|---|---|
| 99% | 約 7 時間 | 平日対応 |
| 99.5% | 約 3.5 時間 | 平日 + 夜間オンコール |
| 99.9% | 約 43 分 | 24h オンコール |
| 99.99% | 約 4 分 | 24h チーム + 冗長化 |
「99.9% 必要」と言う前に、自社の業務にとって本当に必要かを確認します。多くの BtoB SaaS では 99% で十分です。
月次レビューの活用
保守契約には、月次の振り返りミーティング を組み込むのがおすすめです。
- 当月の障害・対応一覧
- 軽微改修の実施内容
- 外部 API・ライブラリの状況
- セキュリティアップデートの実施
- 翌月の予定 / 検討事項
これがあると、「保守費用が何に使われているか」が定期的に可視化されます。発注者と保守会社の信頼関係 を保つ上で重要です。
内製化のサポートも保守の一部
「将来的に内製化したい」場合、保守会社は その移行を支援する役割 も担えます。
- 内製チームへのトレーニング
- ドキュメント (Runbook、設計図) の整備
- コード解説・ペアプログラミング
- 段階的な引き継ぎ
これを契約時に明示しておくと、内製化を進めるときにスムーズです。
min's の保守支援スタイル
min's では、保守契約を以下の 3 パターンで提供しています。
パターン 1: ライトな保守
- 月 10 時間の対応枠
- 平日対応のみ
- 月次レビュー (オンライン)
- 費用: 月 10〜20 万円
パターン 2: スタンダードな保守
- 月 30〜50 時間の対応枠
- 平日 + 夜間オンコール
- 月次レビュー (対面)
- 軽微改修込み
- 費用: 月 30〜80 万円
パターン 3: フルマネージド
- 月 80 時間以上の対応枠
- 24h 対応
- 週次レビュー
- 改善並走 (機能追加含む)
- 費用: 月 100 万円〜
事業フェーズと運用ニーズに合わせて選びます。
保守契約について相談したい方へ
min's では、保守内容の整理、新規契約、既存契約のセカンドオピニオン、内製化への移行支援を行っています。
以下のような状態であれば、ご相談ください。
-
保守費用が妥当か判断したい
-
既存の保守契約を見直したい
-
これから保守契約を結ぶ前に相談したい
-
内製化に向けた段階的な引き継ぎを進めたい
次に読む記事
参考
- OpenAI frontier models and Codex on AWS / OpenAI — エンタープライズ運用におけるガバナンス・運用フロー
- Using LLMs to Secure Source Code / Anthropic — セキュリティ管理での検証・トリアージ・修正の重要性