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