維持運用は成果が目に見えにくく、気づいたときには深刻になりがちです。発注側が直面しやすい失敗は、責任分界、ロックイン、保守移管、想定外費用の四つに集約されます。本記事は、維持運用で実際に起きる失敗・課題・注意点・リスクに絞り、発注企業の視点で掘り下げる「リスク特化」の解説です。
契約の段階で備えていれば防げたものがほとんどです。まず、ITシステム維持運用の完全ガイドで全体像を押さえておくとよいでしょう。
▼全体ガイドの記事
・ITシステム維持運用の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
責任分界が有耶無耶になるリスク
現代の維持運用で最も深刻化しているのが、責任分界が曖昧になるリスクです。システムがクラウド基盤や外部SaaSと連携して動くようになった結果、障害が起きても「どこが原因で、誰の責任か」がすぐに分からない事態が増えています。特に、ベンダーのコントロールの外で起きる障害では、対応が宙に浮くのが典型的な失敗です。
クラウド・SaaS障害でベンダーが動かないリスク
典型的な失敗は、利用しているクラウド基盤で大規模障害が起きたときです。自社システムに問題がなくても、土台のクラウドが落ちればサービスは止まります。
このとき、運用ベンダーが「当社の責任範囲外です」と言って静観してしまうと、発注側はクラウド事業者と直接やり取りする術もなく、ただ復旧を待つしかありません。
連携先の外部SaaSがAPI仕様を予告なく変え、連携が突然動かなくなるケースもあります。さらに近年は、AIが想定外の出力（ハルシネーション）を返すことによる障害も、新しいリスクとして加わっています。
これらに共通するのは、ベンダーが直接コントロールできない領域で起きる障害だという点です。そのため、失敗を避けるには、契約の段階で障害への備えを決めておくことが欠かせません。
責任範囲外だから何もしない、という姿勢のベンダーには、モダンなIT環境の運用は務まりません。ここは、競合の解説では踏み込まれにくい、現実の最重要論点です。
契約で決めておきたい点を挙げます。
- 支援の範囲：コントロール外の障害が起きたとき、原因究明と暫定対応をどこまで担うか
- 問い合わせの窓口：クラウド事業者や外部SaaSへの連絡を、発注側と運用ベンダーのどちらが受け持つか
SLAペナルティが原因不明で適用されないリスク
SLAに稼働率保証やペナルティ条項を入れていても、それが実際には機能しないという失敗もあります。減額ペナルティは、障害の原因がベンダーの責任であることが確定して初めて適用されるものです。
ところが、原因が自社設備かクラウド側か連携先かの切り分けがつかず、有耶無耶になることがあります。その結果、「当社の責任とは断定できない」としてペナルティが見送られるケースが少なくありません。
稼働率99.9%や復旧4時間といった立派な数値を契約に書いても、未達時の判定方法と原因切り分けの手順が曖昧なら、絵に描いた餅になります（出典：ripla）。
失敗を避けるには、SLAの数値だけでなく、誰がどの手順で原因を切り分け、どの状態を「ベンダー責任」と判定するのかまで契約で具体化しておく必要があります。
ペナルティの相場は月額の数%程度とされますが、その実効性は条文の作り込み次第で変わります。SLAは設定すること自体が目的化しやすいため、形だけのSLAになっていないかを常に問い直すことが大切です。
ペナルティの効き目は、未達の判定基準と原因の切り分けを契約書でどこまで具体的に決めているかで分かれます。そこで確かめたいのは、次の2点です。
- 未達時の判定：稼働率や復旧時間が未達だったとき、どの基準で判定するか
- 原因の切り分け：自社設備、クラウド側、連携先のどこを「ベンダー責任」とするか
ベンダーロックインで塩漬けになるリスク
維持運用が長期化するほど深刻になるのが、特定ベンダーへの依存が進み、抜け出せなくなるベンダーロックインのリスクです。保守費が高いと感じても、システムの中身が分からないため他社へ乗り換えられず、結局は今のベンダーに払い続けることになります。この塩漬け状態は、多くの企業が陥る典型的な失敗です。
保守費が高止まりする構造的リスク
保守費が高止まりする背景には、ベンダー側の利益構造があります。多重下請けの構造では、元請けから二次・三次へと外注されるたびにマージンが乗ります。そのため、発注側が払う金額に対して、実際に手を動かす人材のコストは一部に過ぎない、ということが起こります。
また、障害に備えて待機する要員のコストが、障害がほとんど起きなくても固定費として上乗せされ続けます。これが、保守費が下がりにくい構造的な理由です。
年間保守費は開発費の15〜20%が目安とされますが（出典：ripla）、この相場を超えていても、内訳が開示されなければ気づけません。
失敗を避けるには、保守費の内訳（障害対応25〜35%、定期保守20〜30%、監視15〜25%など）の開示を求めたうえで、自社の実態と照らして妥当性を検証することが必要です（出典：ripla）。
相手の台所事情、つまりなぜ保守費が高くなるのかという構造を理解しておくことが、交渉の出発点になります。言われるがままに払い続けることが、最大の失敗パターンです。
保守費の中身を確かめる着眼点を挙げます。
- 内訳の開示：障害対応、定期保守、監視などの費用が、それぞれどれだけかを示してもらう
- 実態との照合：示された内訳を、自社の運用の実態と照らし合わせる
ソースコード著作権を盾にした法的ロックイン
ロックインの最も厄介な形が、法的な縛りです。開発したシステムのソースコードの著作権がベンダー側にあると、発注側はそのコードを他社に渡して保守させることができません。
さらに、ベンダー独自のパッケージを派生させて作られたシステムだと、その派生物の取り扱いを盾に、移管そのものを拒まれることがあります。こうなると、乗り換えは契約解除に向けた法務対応の泥沼に発展しかねません。
この失敗の根は、開発・契約の段階で成果物の権利帰属を曖昧にしたことにあります。
すでにロックインに陥っている場合は、契約書の権利条項を法務とともに精査し、移管に向けた解除のステップを慎重に踏む必要があります。
維持運用のリスク管理は、運用が始まってからではなく、開発・契約の段階から始まっているのです。
riplaはフルスクラッチ受託の立場から、権利帰属を発注側に整理し、ロックインを生まない契約のあり方を重視しています。
権利の扱いで確認したい項目を挙げます。
- 権利帰属：ソースコードの著作権が、発注側と開発側のどちらにあるか
- 保守目的の利用：第三者への開示や保守の委託を認める条項があるか
保守移管に失敗するリスク
ロックインを脱して別ベンダーへ乗り換える際、移管のプロセスそのものでつまずくのも、よくある失敗です。乗り換えを決断しても、進め方を誤ると、かえって品質が崩れ、二重コストだけがかさむ結果になりかねません。
移管は、契約を切り替える事務作業ではなく、知識を移すプロジェクトだと捉えないと失敗します。
ドキュメント不足で引き継ぎが難航するリスク
移管失敗の最大の原因が、ドキュメントの不足です。旧ベンダーが残した設計書や運用手順書が古かったり、そもそも存在しなかったりするため、システムの仕様が担当者の頭の中にしかない、というケースが頻発します。
この状態で新ベンダーに引き継ぐと、新ベンダーは手探りで運用を始めることになります。その結果、障害が起きても原因を特定できず、復旧が長期化します。
旧ベンダーが移管に非協力的な場合、知識の引き継ぎが意図的に妨げられることもあります。
失敗を避けるには、移管を急がず、現行システムの中身を洗い出してドキュメントを整備する時間を十分に取ることが欠かせません。
移管プロジェクトは、ドキュメントという「知識の器」がなければ成立しないことを肝に銘じるべきです。
引き継ぎを確実にするため、契約と作業の両面で押さえたい点を挙げます。
- 引き継ぎ協力の義務：移管時の協力を、契約上の義務として旧ベンダーに課す
- ドキュメントの鮮度：設計書や運用手順書が最新かを確かめ、足りない部分を補う
二重コストと品質低下が重なるリスク
移管期間中は、旧ベンダーと新ベンダーの両方に費用を払う二重コストが発生します。この一時コストを惜しんで並行稼働期間を削ると、知識の空白期間が生まれます。その間に障害が起きれば、誰も対応できないという最悪の事態を招きます。
コストを抑えようとした判断が、かえって品質低下と余計な障害対応費を生むという、皮肉な失敗です。
失敗を避けるには、二重コストを「移管リスクを下げるための必要経費」と割り切ることです。そのうえで、新旧ベンダーが一定期間並行稼働し、知識を確実に移す段階移行を選ぶ必要があります。
最初は旧ベンダーが主担当、新ベンダーが副担当として障害対応に同席し、徐々に主従を入れ替えていきます。この丁寧な進め方が、移管後の品質低下を防ぎます。
移管の成否は、速さや安さより、いかに知識を欠落なく移すかで決まります。この原則を忘れないことが大切です。
二重コストを抑えすぎないために、確かめたい点を挙げます。
- 並行稼働の期間：新旧ベンダーが同じ障害対応に関わる期間を、十分に確保できているか
- 主担当の交代：主と副を段階的に入れ替える計画が、事前に決まっているか
想定外費用が発生するリスク
維持運用の予算を立てたものの、契約に含まれていなかった作業が次々に発生し、想定を超える費用がかかる、という失敗もよくあります。
月額の保守費だけを見て予算を組むと、いざというときの追加費用に足元をすくわれます。何が月額に含まれ、何が別料金になるのかという境界を、契約の段階で詰めておかないと、想定外費用のリスクが表に出てきます。
OSS保守・データ復旧の想定外費用リスク
見落とされがちな想定外費用の一つが、オープンソースソフトウェア（OSS）の保守です。システムに組み込んだOSSのバージョンが古くなり、脆弱性対応のためにアップデートが必要になると、その検証や改修に相応の工数がかかります。OSSは無料で使えるという認識が、保守局面で思わぬ費用として跳ね返ってくることがあります。
もう一つが、大規模なデータ復旧の費用です。日常のバックアップ取得は月額に含まれていても、実際に障害でデータが失われ、大がかりな復旧作業が必要になった際は、別途の作業費が発生することが少なくありません。
失敗を避けるには、OSSの保守方針やデータ復旧の費用負担を、契約段階で確認しておくことが重要です。
契約に書かれていなかったことが、そのまま想定外費用になります。だからこそ、グレーゾーンを事前に潰しておくことが最大の防御です。
契約の段階で詰めておきたい費用の扱いを挙げます。
- OSSの保守方針：脆弱性対応やバージョンアップの工数を、誰がどの費用で受け持つか
- データ復旧の費用負担：大がかりな復旧作業が、月額の範囲に含まれるかどうか
軽微改修と本格改修の境界をめぐるリスク
想定外費用が最も頻発するのが、軽微改修と本格的な機能追加の境界です。「これくらいは月額の範囲でやってくれるだろう」と思っていた改修が、ベンダーから「これは別途の開発案件です」と言われ、追加の見積もりを請求される、というケースが起きます。
維持運用費の内訳では、軽微改修が10〜15%とされますが（出典：ripla）、どこまでが軽微で、どこからが本格改修かの線引きが曖昧だと、この境界をめぐって認識の食い違いが生じます。
失敗を避けるには、契約の段階で軽微改修の範囲を具体的に定義しておくことです。たとえば「一定工数以内の改修は月額に含む」といった形で、線引きを明文化します。
IT予算を増額する企業が49.5%にのぼり攻めのIT投資が進むなか（出典：JUAS）、運用フェーズでの想定外費用は、その投資余力を削る隠れたリスクです。
維持運用は、目に見える月額だけでなく、見えにくい追加費用まで含めた総額で捉えることが、失敗しないための鉄則になります。riplaはフルスクラッチ受託と国内運用保守の立場から、こうした費用の境界を最初に明確にし、想定外を生まない運用設計を重視しています。
契約に書く線引きの中身を挙げます。
- 軽微改修の範囲：画面の文言修正や軽微なバグ修正など、無償で対応する作業の範囲
- 別見積もりの対象：新機能の追加など、別見積もりとする作業の条件
まとめ
ITシステム維持運用の失敗・リスクを整理すると、四つの落とし穴に集約されます。
一つ目は、クラウド・SaaS連携時代に責任分界が有耶無耶になり、ベンダーが動かなくなるリスクです。二つ目は、保守費の高止まりと法的ロックインによる塩漬けのリスクです。
三つ目は、ドキュメント不足や二重コストによる保守移管の失敗です。四つ目は、OSS保守・データ復旧・改修の境界をめぐる想定外費用のリスクです（出典：ripla、JUAS）。
ここで挙げた失敗の多くは、運用が始まってからではなく、開発・契約の段階で備えていれば防げたものです。
失敗を避ける鍵は、責任分界点を契約で明確にし、ソースコードの権利帰属やドキュメント納品義務でロックインを構造的に防ぐことです。そして、費用の境界を最初に詰めておくことに尽きます。
維持運用のリスク管理は、目に見える月額の安さではなく、見えにくい責任・権利・費用の設計で決まります。
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を創業。