保守運営は、うまくいって当たり前で、何か起きて初めて注目される地味な領域です。失敗の中身は、責任分界の曖昧さ、ベンダーロックイン、移管の失敗、内製化の頓挫などで、多くは技術力より契約と体制の設計に原因があります。
全体像を把握していない方は、まずITシステム保守運営の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム保守運営の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
責任分界が曖昧になるクラウド時代のリスク
現代の保守運営で、もっとも見落とされがちなリスクは、責任分界点の曖昧さです。システムがクラウド基盤やSaaS、AI機能と複雑に連携する今、障害の原因が「ベンダーのコントロール内」とは限りません。
「コントロール外の障害」を契約で想定していないと、いざというときに誰も対応しない空白地帯が露呈します。
クラウド障害・API仕様変更・AIハルシネーションの空白地帯
典型的なのは、AWSなどのクラウド障害でシステムが停止したケースです。
クラウド事業者の障害なので保守ベンダーには復旧できませんが、「だから何もしない」となると、発注した企業は復旧を待つしかありません。
連携先SaaSのAPI仕様が予告なく変わって連携が壊れた場合や、AI機能がハルシネーション（誤った出力）を起こした場合も同様です。いずれも「ベンダーのコントロール外」を理由に、対応が宙に浮きがちです。
このリスクを避けるには、契約で「コントロール外の障害でもベンダーが何をするか」を定義しておくことが不可欠です。
クラウド障害やAPI仕様変更、AIハルシネーションを保守の範囲に含めておかないと、障害のたびに「それは契約外です」と押し問答になります。
競合の保守解説の多くはこの責任分界点に触れておらず、ここを契約で固めることが、現代の保守運営でもっとも効くリスク対策です。
契約で定める対応範囲は、事象ごとに分けて書いておきます。
- クラウド障害：一次切り分け、状況報告、復旧後の正常性確認まで
- API仕様変更：影響調査と改修見積もりの提示まで
このリスクが見えにくいのは、発注時に「障害はベンダーが直すもの」という素朴な前提で契約してしまうからです。
ところが、クラウドやSaaS、AIを組み合わせた現代のシステムでは、障害の発生源が自社の管理範囲を超えて広がっています。AWSの広域障害、決済SaaSの仕様変更、生成AIの予期せぬ出力は、いずれも従来の「アプリのバグを直す」という保守観では捉えきれません。
発注側が古い前提のまま契約すると、ベンダーも「コントロール外なので」と引き取らず、認識のずれが誰も対応しない空白地帯を生みます。
まず発注側が「障害の原因は自社の管理外にも及ぶ」という現実を理解することが、対策の出発点になります。
SLAペナルティが原因不明で適用されないリスク
責任分界の曖昧さは、SLAペナルティの実効性にも直結します。
稼働率99.9%や復旧4時間以内を保証し、減額条項まで設けた契約でも、いざ障害が起きると「原因がクラウド側か自社側か特定できない」を理由に、ペナルティが適用されないことがあります（出典：ripla）。減額相場は月額の数%程度ですが、適用されなければ減額はゼロです。
このリスクの本質は、ペナルティ条項があるかどうかより、未達をどう判定するかが決まっていないことにあります。
判定の前提を契約で詰めていないと、ペナルティは実際には使えない条項になります。
SLAは、未達のときに本当に適用されるかどうかが肝心です。判定の客観性を契約で担保しないまま安心していると、いざというときに救済を得られない失敗に直結します。
判定に関わる契約の詰めどころは、大きく二つあります。
- 判定の基準：稼働率の計測ツールと、ダウンタイムから除く条件
- 切り分けの手続き：ベンダー任せにしないための進め方
とくに注意したいのが、原因切り分けの主導権を誰が握るかです。
障害の原因究明をベンダー任せにすると、ベンダー自身に不利なペナルティが絡む局面で「原因はクラウド側にあった可能性が高い」と曖昧に結論づけられ、減額が適用されないまま終わることがあります。
これを防ぐには、監視ログやクラウド事業者の障害情報といった第三者的な判断材料の扱いを、契約の段階で定めておくことが有効です。
ペナルティは抑止力として意味を持ちますが、その効き目は未達が客観的に判定される仕組みがあって初めて出てきます。判定の透明性を欠いたSLAは、契約書の上では立派に見えても、現実には何の保証にもなりません。
ベンダーロックインと法的トラブルのリスク
保守運営の長期的なリスクの筆頭が、ベンダーロックインです。一社に保守を任せ続けるうちに、そのベンダーしかシステムを把握していない状態になります。そうなると、保守費が高止まりしても乗り換えられません。
ひどい場合には、ソースコードの権利を盾に移管そのものを拒否される、という法的トラブルに発展します。
ソースコード著作権を盾にした移管拒否の泥沼
もっとも深刻なのが、ソースコードの著作権がベンダーに帰属している場合の移管拒否です。
開発契約で著作権の帰属を明確にしていないと、ソースコードはベンダーのものとされ、別ベンダーへの提供を拒まれることがあります。
ベンダー独自のパッケージや派生フレームワークを土台にしていると、その部分の権利を理由に「移管できない」と主張され、契約解除の交渉が泥沼化します。
泥沼を避ける最善策は、契約の入口にあります。開発・保守契約の段階で、ソースコードの著作権を発注者に帰属させ、独自パッケージを採用するなら移管時の扱いを明文化しておくことです。
すでにロックインに陥っている場合は、後で述べる手順で移管を進めることになります。
法的ロックインは、起きてから解くより、起きないように設計するほうが圧倒的に安く済みます。
riplaはフルスクラッチ受託と国内運用保守の立場から、著作権を発注者に帰属させ、出口を塞がない契約を重視しています。
移管拒否を防ぐうえで確かめたいのは、大きく二つあります。
- 帰属の確認：ソースコードの著作権が発注者とベンダーのどちらにあるか
- 独自パッケージの扱い：移管時にその部分をどう取り決めているか
すでにロックインに陥った状態から抜け出すには、現実的な手順を踏む必要があります。まず、契約書を精査して著作権の帰属、解除条件、ドキュメント提供義務の有無を確認します。
次に、現行システムのソースコードと構成を可能な範囲で洗い出し、移管に必要な情報を整理します。ベンダーが協力的でない場合は、法務を交えて契約上の権利と義務を確認しながら交渉を進めます。
大事なのは、感情的に対立して関係を断つことより、移管に必要な協力を引き出す形で着地させることです。
ロックインの解消は時間も費用もかかるため、まだ陥っていない企業は、何よりも入口での契約設計で予防することが賢明です。
保守費が高止まりするベンダー側の利益構造
保守費がなぜ高止まりするのかを理解すると、交渉の糸口が見えます。背景には、ベンダー側の利益構造があります。
多重下請けの構造では、元請けから孫請けへ仕事が流れるたびにマージンが乗り、最終的な保守費が膨らみます。また、障害にすぐ対応できるよう要員を待機させるコストも、保守費に転嫁されています。
相手の事情を知らないまま「とにかく安くして」と言っても、交渉は進みません。
有効なのは、保守費の内訳を出させて、どこに費用がかかっているかを把握することです。
年間保守費は開発費の15〜20%が目安で、内訳は障害対応25〜35%、定期保守20〜30%、監視15〜25%などに分かれます（出典：ripla）。
たとえば、自社では月数件しか障害が起きないのに過大な待機費が乗っていれば、その項目を実態に合わせて見直せます。
高止まりは、相場より高いからというより、自社の利用実態に合っていないから起きることが多いものです。そのため、内訳の把握が是正の第一歩になります。
保守費の内訳を見るときの要点は、大きく二つあります。
- 内訳の割合：障害対応、定期保守、監視などの各費用が占める比率
- 実態との差：障害の発生件数に対して、待機費などが見合っているか
多重下請け構造を理解しておくと、交渉の現実も見えてきます。元請けが自社で対応せず孫請けに丸投げしている場合、間に立つ各社が取り分を得るため、実際の作業者に届く金額は保守費の一部に過ぎません。
この構造では、いくら値下げを求めても元請けの取り分が削られるだけで、肝心の対応品質はむしろ下がりかねません。
高止まりの是正は、値引き交渉より、「自社にとって不要なサービス水準を削る」「実態に合った体制へ組み替える」形で進めるのが正攻法です。
相手の事情を見ずに値下げを迫る交渉は、品質低下という別の失敗につながります。
保守移管の失敗と想定外費用のリスク
ベンダーを乗り換える際の保守移管には、固有の失敗パターンと想定外費用が潜んでいます。「安くなるはずだった」乗り換えが、移管の難航や隠れた費用でかえって高くついた、という事例は少なくありません。
移管を決める前に、これらのリスクを織り込んでおく必要があります。
二重コストとドキュメント不足で移管が難航するリスク
移管失敗の典型が、二重コストとドキュメント不足です。旧ベンダーから新ベンダーへ切り替える期間は、両方に保守費を払う「二重コスト」が一時的に発生します。
この並行期間を短く見積もりすぎると、引き継ぎが終わらないうちに旧ベンダーとの契約が切れ、システムの空白が生じます。
とくに新ベンダーは本番障害を一度経験して初めて知見が定着するため、並行期間は十分に取るべきです。
さらに深刻なのがドキュメント不足です。設計書や運用手順書が整備されていないと、新ベンダーはソースコードを読み解くところから始める必要があり、引き継ぎに想定の何倍もの工数がかかります。
この調査工数が見積もりに入っていないと、後から追加請求されやすく、想定外費用の温床になります。
移管を計画する際は、旧ベンダーにドキュメント提供と協力を契約上義務づけ、並行運用期間を現実的に確保することが、難航を防ぐ鍵になります。
皮肉なことに、ドキュメント整備をベンダー任せにしてきた企業ほど、いざ乗り換えようとした段階で「整備されていない」現実に直面します。
日頃からドキュメントの整備状況を確認しておくことが、将来の移管リスクを下げる地道な備えになります。
移管で押さえる点は、大きく二つあります。
- 二重コストの見積もり：並行期間を、本番障害の経験を踏まえて十分に取れているか
- ドキュメントの整備：設計書や運用手順書の有無と、旧ベンダーの提供義務
OSS保守・データ復旧・クラウド障害という想定外費用
保守運営で、もっとも家計を狂わせるのは、契約範囲に含まれていなかった想定外費用です。代表的なのが、OSS（オープンソースソフトウェア）保守です。
システムは多数のOSSライブラリに依存しており、脆弱性が公表されるたびに対応が必要になります。これを保守契約に含めていないと、「パッチ適用は別料金」と請求されます。
OSS保守は本体の改修とは別に継続的に発生するため、範囲外だと累積で大きな出費になります。
同じく見落とされるのが、データ復旧とクラウド側障害への対応費です。バックアップからの復元作業や、クラウド障害発生時の切り分け・復旧確認は、契約で明示していないと都度費用が発生しがちです。
さらにAIを組み込んだシステムでは、MLOps保守の相場（月50万〜200万円）が一般の運用（月60万〜150万円）より高くなります。専門性ゆえの上振れもあります（出典：ripla）。
これらは、契約段階で範囲に含めるか、含めないなら発生条件と単価を明記しておくことが、想定外費用というリスクを抑える決め手です。
想定外費用になりやすいものは、大きく二つに分けて考えられます。
- OSS保守：脆弱性のパッチ適用を、保守の範囲に含めるかどうか
- データ復旧とクラウド障害：復元作業と切り分けの費用を、どう扱うか
内製化移行の頓挫と塩漬けのリスク
保守運営の失敗には、ベンダーとの関係に起因するものだけでなく、自社の判断や放置から生じるものもあります。
代表的なのが、ブラックボックス化を嫌って内製化に踏み切ったものの頓挫するケースと、見直しを先送りしてシステムを塩漬けにしてしまうケースです。
いずれも、適切なタイミングで手を打たなかったことが、後の大きな損失につながります。外部要因だけでなく、自社の判断の遅れも、保守運営の失敗を生む大きな要因になります。
ノウハウ移転なき内製化が頓挫するリスク
ベンダーロックインや保守費の高止まりに嫌気がさし、「自社でやろう」と内製化を決断する企業は少なくありません。しかし、準備不足のまま内製化に踏み切ると、かえって運用が不安定になる失敗に陥ります。
最大の落とし穴は、既存ベンダーからのノウハウ移転を設計しないまま契約を切ってしまうことです。
ドキュメントも引き継ぎ計画もないまま内製チームに丸投げすると、障害対応の勘所が分からず、初動が遅れ、かえって障害が増えます。
内製化を成功させるには、既存ベンダーの保守を一定期間並行させながら、運用手順・障害履歴・設計思想を計画的に移転するロードマップが欠かせません。ノウハウを社内に移す内製化は、コストを下げる決断ではなく、数年がかりの移行プロジェクトとして扱うべきです。これを甘く見た企業が頓挫します。
内製化を準備するうえで詰める点は、大きく二つあります。
- 要員の確保：採用に時間がかかり、固定費の負担も生じること
- ノウハウ移転：既存ベンダーの保守を並行させる期間と、移す内容の計画
運用要員は、人月60万〜150万円の相場で複数名を確保する必要があります（出典：ripla）。採用できても、自社システムの固有事情を把握するまでには相応の期間が必要です。
塩漬けによる技術的負債とセキュリティリスク
もう一つの静かなリスクが、システムの塩漬けです。「動いているから触らない」という判断で、OSやミドルウェア、OSSライブラリのアップデートを長年放置すると、技術的負債が蓄積していきます。
古いバージョンには既知の脆弱性が残り、ある日それを突かれて不正アクセスやデータ漏えいに至る、という最悪のシナリオが現実味を帯びます。
定期保守は保守費の20〜30%を占める正規の投資ですが（出典：ripla）、これを削ると、より大きな代償を払うことになります。
塩漬けが厄介なのは、放置期間が長いほど、いざ更新しようとしたときの作業が膨大になる点です。何世代も古いバージョンから最新へ一気に上げると、互換性の問題が噴出し、改修費が跳ね上がります。
放置が続くと「更新したくても更新できない」状態に固定され、これもまた一種のロックインになります。
塩漬けは目先のコストを抑えるように見えて、将来の更新費とセキュリティ事故という二重の負債を積み上げる、もっとも避けたい失敗の一つです。
塩漬けを防ぐ更新の進め方は、大きく二つあります。
- 定期保守への組み込み：パッチやバージョンアップを、保守の範囲に含めること
- 小刻みな更新：古い版を長く放置せず、計画的に上げ続けること
まとめ
ITシステム保守運営の失敗・リスクは、大きく四つに整理できます。一つめは、クラウド障害やAPI仕様変更、AIハルシネーションといったコントロール外の障害で責任分界が曖昧になり、SLAペナルティも原因不明で適用されないことです。
二つめは、ソースコード著作権を盾にしたベンダーロックインと法的トラブル、保守費の高止まりです。三つめは、二重コストとドキュメント不足による移管の失敗と、OSS保守・データ復旧・クラウド障害という想定外費用です。
四つめは、ノウハウ移転なき内製化の頓挫と、更新を放置した塩漬けによる技術的負債・セキュリティリスクです。
いずれも技術ではなく契約と体制の設計、そして判断のタイミングに原因があります。
これらのリスクに共通する対策は、入口で契約を固め、定期的に見直すことです。責任分界点とペナルティの判定方法を明記し、ソースコード著作権を発注者に帰属させておくことが大切です。そのうえで、ドキュメント提供を義務づけ、想定外費用の発生条件と単価を定めておきます。
また、内製化や塩漬けの判断は先送りせず、計画的に手を打ちます。この一手間が、後の泥沼と出費を未然に断ちます。
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を創業。