ITシステム保守管理で起こりがちな失敗は、責任分界の曖昧さや、ベンダーロックインによる塩漬けです。ほかにも、保守移管の失敗、想定外の費用、SLAの形骸化と属人化などがあります。保守管理は、うまくいっているときは目立ちません。一方で、つまずくと事業全体に深刻な影響を及ぼします。
全体像をまだ把握していない方は、まずITシステム保守管理の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム保守管理の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
責任分界が有耶無耶になる現代特有のリスク
現代のITシステム保守で、もっとも深刻化しているのは、責任分界点が有耶無耶になるリスクです。
今のシステムは、クラウド（AWS等）の上で複数のSaaSと連携し、ときにはAI機能も組み込んで動いています。
そのため、障害が起きたときに「誰の責任で、誰が直し、誰が費用を負担するのか」は、オンプレミス時代より格段に複雑になりました。この境界が契約で定められていないと、障害のたびに責任の押し付け合いが起き、対応も遅れます。
クラウド障害・API仕様変更というコントロール外の罠
もっとも見落とされやすいのが、ベンダーのコントロールが及ばない障害です。たとえば、クラウド事業者のリージョン障害でシステムが止まったとき、保守ベンダーは原因を直接修正できません。それでも、発注側は「保守を頼んでいるのに動かない」と感じます。
また、連携先SaaSのAPI仕様が予告なく変わって連携が止まることもあります。その改修が通常保守に含まれるのか、別料金なのかが曖昧だと、対応をめぐって揉めてしまいます。これらはベンダーの過失ではありませんが、放置すれば事業が止まりかねない、厄介な領域です。
こうした「コントロール外」の障害について、責任と費用の考え方が保守契約で不足しているのが実態です。たとえば、SLAで稼働率99.9%を約束していても、原因がクラウド側の障害なら、その未達はペナルティの対象外とされることが多いのです。その結果、発注側は保証されているつもりが、実は守られていないという事態に陥ります（出典：ripla）。
特に、最新の環境ほど、障害時の責任の範囲を先に決めておく必要があります。決めないまま障害を迎えると、有耶無耶のまま費用と信頼を失いかねません。
リスクを避けるには、契約段階で、クラウド側や連携先側の障害時に保守ベンダーが何をどこまで行うのかを、責任と費用の両面から明文化しておくことが欠かせません。
- 障害時の対応範囲：クラウド側や連携先側の障害で、保守ベンダーが担う作業と、その限界
- API変更の費用負担：連携先の仕様変更に伴う改修が、通常保守に含まれるか別料金か
AI連携時のハルシネーションという新しい課題
AI機能を組み込んだシステムでは、さらに新しい課題が加わります。
AIが学習に基づいて誤った出力（ハルシネーション）をしたとき、それが「障害」なのか「仕様の範囲内」なのかは、線引きが難しいのです。
AIが事実と異なる回答を返した場合、保守ベンダーがそれを是正する責任を負うのか、AIモデル提供元の問題なのか、利用者の使い方の問題なのか、判断が分かれます。そのため、責任が三者に分散して有耶無耶になりがちです。
MLOps保守の費用が月50万〜200万円と幅広く設定されるのは（出典：ripla）、こうしたAI特有の運用の難しさと、責任の不明確さを反映しているためです。
AIを組み込むシステムでは、出力品質の保証範囲と、誤りが出たときの是正の担当を保守契約に織り込んでおく必要があります。織り込まないと、トラブル時に対応が宙に浮きます。
AI連携は便利である一方で、責任分界の難しさという新しいリスクを抱えています。
保守の段階で、この点を正しく認識しておくことが大切です。
AI連携の保守では、誤りへの対応を契約でどう決めておくかが問われます。
- 品質の基準：AIの回答に、どの水準まで保証を求めるか
- 是正の担い手：誤りへの対応を、ベンダー、モデル提供元、利用者のどこが負うか
ベンダーロックインによる塩漬けと法的トラブル
保守管理の長期的なリスクとして根深いのが、ベンダーロックインです。特定のベンダーに依存しすぎた結果、保守費が高止まりしても、品質に不満があっても、簡単には乗り換えられない状態に陥ります。
乗り換えられないと分かっているベンダーは、改善の動機を失い、システムは塩漬けになります。
塩漬けは、コストだけの問題にとどまらず、事業の柔軟性そのものを縛る構造的なリスクです。
ソースコード著作権を盾にした法的ロックイン
ベンダーロックインの中でも、特に泥沼化しやすいのが法的ロックインです。
ソースコードの著作権がベンダー側にあったり、独自パッケージの派生物として作られていたりすると、ベンダーが移管を拒むケースがあります。
「このシステムの著作権は当社にあるため、他社に渡すことはできない」と言われると、発注側はソースコードを手にできず、他のベンダーに保守を引き継ぐ道が閉ざされます。これは、契約時に権利の所在を曖昧にしたツケが出口で噴き出す典型例です。
法的ロックインから抜け出すには、契約解除に向けた法務の手続きを踏む必要があり、時間も労力もかかります。
開発・保守の契約段階で、ソースコードの著作権の帰属と、契約終了時の引き継ぎ義務を明確にしておくべきでした。
riplaは、フルスクラッチ受託と国内運用保守の立場から、権利関係を入口で明確にし、発注側が将来も選択肢を持ち続けられる契約づくりを重視しています。
すでにロックインに陥っている場合は、まず契約書を確認し、権利の所在を法務と照らし合わせることが、塩漬けを解く第一歩になります。
法的ロックインの場面で確認したいのは、ソースコードの権利と移管の条件です。
- 著作権の帰属：ソースコードの権利が、発注側とベンダーのどちらにあるか
- 契約終了時の引き継ぎ：契約が終わるときに、ベンダーが引き継ぎに応じる義務があるか
保守費が高止まりする利益構造の本音
保守費が高止まりする背景には、ベンダー側の利益構造があります。多重下請け構造では、発注側が払った保守費が中間業者を経るたびに目減りし、実際に手を動かす技術者に届く割合は小さくなります。
また、いつでも対応できるよう人員を確保しておく待機要員のコストも、保守費に上乗せされています。つまり、保守費の一部は作業そのものより「体制の維持」への対価であり、これが高止まりの構造的な要因です。
発注側が相手の内情を理解しておくことが、交渉の武器になります。
年間保守費は開発費の15〜20%が目安とされますが（出典：ripla）、この相場より高い場合は、多重下請けや過剰な待機コストが乗っている可能性があります。そのうえで、内訳の開示を求めるべきです。
保守費の内訳（定期保守20〜30%、監視15〜25%、障害対応25〜35%など）に照らして、払っている額が実態に見合っているかを点検します。
構造を知らないまま「相場だから」と払い続けると、ロックインと高止まりが助長されます。相手の利益構造を理解したうえで交渉することが、健全な保守費を目指す出発点になります。
保守費を見直すときは、内訳と請け負いの構造を押さえておきます。
- 内訳の開示：定期保守、監視、障害対応のそれぞれに、どれだけの費用が配分されているか
- 請け負いの構造：多重下請けになっているか、待機要員のコストが含まれているか
保守移管の失敗と想定外費用というリスク
ロックインを脱して別のベンダーへ移管しようとすると、今度は移管そのものの失敗リスクが待ち受けています。
保守移管には、二重コスト、ドキュメント不足、引き継ぎ難航という三つの壁があります。計画が甘いと、移管できずに元のベンダーへ出戻ったり、品質が一時的に下がったりする事態を招きます。
移管は、「安いベンダーに替えれば終わり」という単純な話ではありません。
ドキュメント不足で移管が難航する失敗
保守移管がもっとも難航するのは、引き継ぎに必要なドキュメントが整っていない場合です。
システムの構成情報、障害対応の手順、独自の業務ロジックが現行ベンダーの頭の中にしかないと、新しいベンダーはゼロから解読することになります。その分、引き継ぎに膨大な時間と費用がかかります。
現行ベンダーと新ベンダーの両方に支払う二重コストの期間も長引き、想定より大幅にコストが膨らみます。
移管の失敗を避けるには、現行ベンダーがいるうちにドキュメントの提供を求め、引き継ぎへの協力義務を契約で確認しておくことが大切です。
移管を成功させた企業は、二重コストの期間を見込んだ多年度のTCOで計画し、引き継ぎの節目を明確にしています。
逆に、月額の安さだけで飛びついて移管を始めると、ドキュメント不足で立ち往生し、結果的に高くつくことになります。移管では、「出口の準備」を契約を結ぶ入口の段階から仕込んでおくことが、失敗を防ぐうえでもっとも重要な備えです。
移管で引き継ぎを進める前に、ドキュメントの状況と協力の取り決めを確認しておきます。
- 構成情報と手順書：システムの構成や障害対応の手順が、文書として残っているか
- 引き継ぎへの協力：現行ベンダーの協力義務が、契約書に書かれているか
OSS保守・データ復旧などの想定外費用
保守管理で見落とされがちなリスクが、契約に含まれていない想定外費用です。たとえば、システムが利用しているオープンソースソフトウェア（OSS）のサポート切れに伴う移行費用や、重大障害時のデータ復旧費用があります。
また、前述のクラウド側障害への対応費用なども、通常の月額保守に含まれていないことが多く、いざ発生すると別途の高額請求になります。これらを想定せずに予算を組むと、不測の事態で資金繰りが圧迫されます。
意思決定の段階では、こうした想定外費用の手当てを契約に織り込んでおくべきです。また、クラウド側の障害時にかかる対応費用をどう扱うかも、あらかじめ取り決めておきます。
年間保守費（開発費の15〜20%、製造系の基幹で年500万〜1,500万円など）を見積もる際は、こうした不測の費用のバッファも含めて考えることが現実的です（出典：ripla）。
想定外を想定しておくことが、保守管理で最後に効いてくるリスク対策です。
想定外費用を見積もるときは、契約の外に出やすい費用の負担先を押さえておきます。
- OSSのサポート切れ：バージョンアップや移行の負担を、保守ベンダーと発注側のどちらが持つか
- データ復旧：費用と範囲を、事前にどこまで定めておくか
SLAが形骸化し属人化が放置されるリスク
責任分界やロックインと並んで見過ごされやすいのが、SLAが形だけになってしまうリスクと、保守の現場が特定の担当者に依存する属人化のリスクです。
前者は「保証されているつもりが守られていない」状態、後者は「その人がいなくなると回らない」状態です。どちらも、契約や運用の作り方を誤ると静かに進み、気づいたときには手遅れになりかねません。障害のように突然表面化するのではなく、平時に少しずつ蓄積するため、見つけにくく根が深いリスクです。
ペナルティが適用されずSLAが飾りになる失敗
保証型のSLAを結んだのに、いざ未達が起きてもペナルティが適用されない失敗は少なくありません。減額条項があっても、減額幅が月額のごくわずかであれば、ベンダーにとって痛みは小さく、品質を改善する動機にはなりにくいのです。
稼働率99.9%や復旧4時間といった目標を掲げていても（出典：ripla）、障害の原因が「クラウド側の問題」や「利用者の操作ミス」とされると、未達の判定そのものが回避される現実があります。
この失敗の根本には、SLAの条項は作ったものの、「何をもって未達とするか」「原因をどう切り分けるか」が曖昧なままだったことがあります。
判定基準と原因の切り分け方法が定められていなければ、ペナルティは絵に描いた餅になり、保証型を選んだ意味も失われます。
SLAを飾りにしないためには、減額幅が実態として意味のある水準か、未達の判定と原因の切り分け手順が明確かを、契約前に確認しておくことが欠かせません。
数値目標を並べるだけでは足りず、その数値が守られなかったときに本当に効くのかまで見極めることが、形骸化を防ぐうえでもっとも有効です。
SLAの実効性を見るときは、減額の水準と未達の判定の仕組みを確認しておきます。
- 減額の水準：未達のときの減額幅が、月額に対して意味のある大きさか
- 未達の判定：何をもって未達とし、原因の責任をどちらに置くか
担当者頼みの属人化を放置する失敗
保守の現場で静かに進行するのが、特定の担当者にノウハウが集中する属人化です。これは社内のひとり情シスだけの問題ではなく、委託先のベンダーでも起こります。
「このシステムのことはあの担当者しか分からない」という状態を放置すると、その人が異動・退職した瞬間に、障害対応の質が急落したり、改修が止まったりします。
属人化は平時には表面化せず、人が抜けて初めて被害が見えるため、もっとも見落とされやすいリスクです。発注側からは委託先の内部体制が見えにくいため、ベンダー側の属人化はとりわけ気づきにくく、放置されがちです。
属人化を放置した失敗の典型は、運用ドキュメントが整備されないまま年月が過ぎ、システムの構成や障害対応の手順が誰の頭の中にしかない状態になることです。
ドキュメント不足は、ベンダーの乗り換えや引き継ぎが難航する最大の原因でもあります。また、属人化とロックインは互いに関わり合う問題です。
属人化を避けるには、保守契約に運用ドキュメントの整備と更新を義務として盛り込み、「いま、この運用は誰の頭の中にあるか」を定期的に点検しておくことが大切です。
riplaは、フルスクラッチ受託と国内運用保守の立場から、作った後の運用を文書にして標準化し、人に依存しない持続可能な保守体制づくりを重視しています。
属人化は、見えないうちに手を打つことが、唯一の対策です。
属人化の状況を見るときは、ドキュメントの整い方と、担当者への仕事の偏りを確認しておきます。
- 運用ドキュメント：構成や障害対応の手順が、最新の状態で文書に残っているか
- 担当者への集中：特定の人にしか対応できない作業が、どれだけあるか
「作ったベンダーに丸投げ」が招く緩やかな失敗
これらの失敗の多くに共通する根っこは、「作ってくれたベンダーに、そのまま何となく保守も任せている」という受け身の姿勢です。開発が終わった安心感から、保守の中身を点検しないまま年月が過ぎ、SLAは形だけ、内訳は不明、ドキュメントは未整備という状態が固定化します。
突発的に起きる大失敗とは違い、何も起きないがゆえに見直されないまま進む、緩やかな失敗です。この失敗が厄介なのは、平時には何の問題も表面化しないことです。しかし、障害が起きたとき、ベンダーを変えたいとき、費用を見直したいときになって初めて、責任分界の曖昧さやロックインが表面化し、属人化やSLAの形骸化も一斉に噴き出します。
年間保守費が開発費の15〜20%という相場を知らずに払い続けることも（出典：ripla）、この受け身の姿勢の表れです。
失敗を避ける出発点は、保守を「お任せ」にせず、内訳・契約・ドキュメントを定期的に洗い出す、主体的な姿勢に切り替えることです。
受け身の姿勢から抜けるために、保守の点検項目を決めておきます。
- 内訳の確認：保守費が、定期保守、監視、障害対応にどう配分されているか
- 契約の実効性：未達のときに効く減額や、責任の範囲が契約に書かれているか
この点検は、特別なタイミングを待つ必要はありません。たとえば、契約更新の前、年度予算の策定時、担当者が変わるタイミングなどが挙げられます。
節目ごとに、「責任分界は明確か」「権利の所在は確認済みか」「ドキュメントは最新か」「SLAは実効性があるか」を点検するだけで、緩やかな失敗の芽を早いうちに摘めます。
すでにロックインや高止まりに陥っている場合でも、内訳を見える形にし、契約と権利を確認するという地道な作業から、状況は必ず立て直せます。
失敗の構造を知ることは、それ自体が最大の予防策であり、立て直しの第一歩でもあるのです。
まとめ
ITシステム保守管理の失敗・リスクを整理すると、その多くは「責任分界の曖昧さ」「ベンダーロックインによる塩漬けと法的トラブル」「移管失敗と想定外費用」という三つの構造的な問題に集約されます。具体的には、クラウド・SaaS・AI時代のコントロール外障害、ソースコード著作権を盾にした移管拒否、ドキュメント不足による引き継ぎ難航などが挙げられます。
OSS保守やデータ復旧の想定外費用は、いずれも契約段階で手を打てたはずの問題が、出口で噴き出したものです。
保守費の相場（開発費の15〜20%）やSLAの実効性を知らないまま払い続けると、これらのリスクが助長されます。
失敗を避けるために大切なのは、「作ってくれたベンダーにそのまま任せる」という受け身の姿勢を改めることです。そのうえで、責任分界、権利の所在、出口の条件を、入口の契約時点で明文化しておくことが求められます。
ロックインや高止まりに陥っていても、契約と権利の確認から、状況は立て直せます。
riplaは、フルスクラッチ受託と国内運用保守の組み合わせで、作った後も継続して伴走する立場から、責任分界の整理や権利関係の明確化を支援します。想定外費用まで見据えた持続可能な保守体制づくりも、あわせて支援しています。
全体像を確認したいときは、あらためて完全ガイドをご覧ください。
▼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を創業。