保守契約で更新作業をしてもらったら、翌日から画面が表示されない、ボタンを押しても反応しない。そんなとき、「更新を頼んだのはこちらだけど、動かなくなったのは誰の責任なのか」と迷う方は少なくありません。
「保守の更新作業のあとで画面が動かなくなった。テストは保守に入っているのか、誰が直すのか分からない…」
先に結論をお伝えします。費用を負担する人は、契約書の「保守の範囲」と「更新後の動作確認を誰がどこまでやるか」の書き方で決まります。原因が更新作業にあるのか、元からあった不具合が表に出ただけなのかによっても変わるため、まずは慌てずに「何をしたあとに、どの画面が、どう動かないか」を記録して、開発会社に連絡することが最初の一手です。
この記事では、更新後に不具合が出たときの考え方を、発注者がそのまま使えるチェックリストと開発会社への質問例とあわせて解説します（執筆時点：2026年11月）。法律・契約の個別判断は、弁護士など専門家にご確認ください。
更新のあとに動かなくなる3つの理由
まず、なぜ更新で動かなくなることがあるのかを押さえます。理由が分かると、誰に何を聞けばいいかが見えてきます。
理由1：更新した部品が、他の部品とぶつかる
システムは、フレームワーク（＝開発の土台になる部品群）やライブラリ（＝機能ごとの部品）を組み合わせて作られています。ひとつを新しくすると、それに依存している別の部品が想定外の動きをすることがあります。
部品のバージョンは「メジャー.マイナー.パッチ」の3つの数字で表すルール（セマンティックバージョニング）が広く使われています。メジャーは「互換性のない変更」、マイナーは「互換性を保った機能追加」、パッチは「互換性を保った不具合修正」で上がる、という考え方です。
📰 出典：Semantic Versioning 2.0.0 日本語版
ただし、これは部品の作者が守る約束事であって、「パッチだから絶対に安全」という保証ではありません。実際には小さな更新でも、使い方によっては影響が出ることがあります。
理由2：テストの範囲が決まっていない
更新のあと、開発会社が「更新が成功したこと」だけを確認して終わる場合と、「主要な画面を一通り操作して確認する」ところまでやる場合があります。どちらが保守の標準かは会社と契約によって違い、書かれていなければ、お互いに「相手がやる」と思い込みやすいのが実情です。
理由3：本番環境でしか起きない差がある
開発会社の検証用の環境と、実際に使っている本番環境では、データの量や設定が少し違います。検証では問題がなくても、本番のデータで初めて不具合が出ることがあります。これは誰かの手抜きというより、構造的に起こりうることです。
契約書で確認したい「保守の範囲」と「テスト」
IPA（情報処理推進機構）は、システム開発や保守・運用の取引で使えるモデル契約書を公開しています。保守・運用の契約では、発注側と受注側の役割分担や、対象となる範囲などを個別に決めておく考え方が示されています。
自社の契約書に次の項目があるか、まず見てみましょう。
| 確認する項目 | 書かれていないと起きやすいこと |
|---|---|
| 保守の対象範囲（どのサーバー・部品・画面か） | 「それは保守の対象外です」と言われる |
| 更新作業に含まれる作業（適用・動作確認・戻し） | 動作確認が別料金になる |
| 動作確認の範囲（主要画面だけか、全画面か） | 確認していない画面で不具合が出る |
| 不具合が出たときの対応（連絡先・時間・費用） | 誰が直すか揉める |
| 元に戻す手順（ロールバック＝更新前の状態へ戻すこと） | 復旧に時間がかかる |
動かなくなったときの対処5ステップ
ステップ1：状況を記録する
いつ、どの更新のあとに、どの画面で、何が起きたかをメモします。画面のスクリーンショットとエラーメッセージも残してください。社内で原因を決めつけず、事実だけを書くのがコツです。
ステップ2：業務への影響を伝えて、優先度を決める
「受注入力ができず、今日の出荷が止まる」のように、業務への影響を具体的に伝えます。影響が大きいときは、原因調査より先にロールバックで業務を再開させる判断もあります。
ステップ3：ロールバックできるか聞く
更新前の状態に戻せるなら、まず戻して業務を止めない方法があります。戻せるかどうかは、更新前にバックアップ（＝更新前の状態の控え）を取っているかに左右されます。
ステップ4：原因を切り分けてもらう
次の3つのどれかを、開発会社に確認します。
- 更新作業そのものが原因か
- 元からあった不具合が、更新で表に出たのか
- 発注者側の操作・データ・別の機器など、保守の外にある原因か
ステップ5：費用と再発防止を書面で残す
誰の費用で直すかは、契約書の範囲と原因の切り分けで決まります。合意した内容は、メールなど記録に残る形で確認しておきましょう。そのうえで、次回の更新からテストの範囲を決めておくと、同じ揉めごとを防げます。
やりがちな失敗
- 「保守に入っているはず」と思い込み、契約書を読まないまま責任を問う
- 原因が分かる前に、開発会社に「そちらのミスですね」と断定する
- 更新の前に、動作確認してほしい画面を伝えていない
- 口頭で話を済ませ、合意が記録に残っていない
開発会社側にも、限られた保守費の中で作業している事情があります。責任の追及より、次から何を確認するかを一緒に決める姿勢のほうが、結果として早く解決しやすくなります。
なお、保守の範囲と、別料金になる大きなバージョンアップの境目については、詳しくは次の記事で解説しています。
発注者がやることチェックリスト
- ☐ 契約書の「保守の対象範囲」と「更新作業に含まれる作業」を読む
- ☐ 更新前に、必ず動かしてほしい主要な画面・業務の一覧（5〜10項目）を作って共有する
- ☐ 更新の日時を事前に聞き、業務が止められない時間帯を避ける
- ☐ 更新前にバックアップがあるか、戻す手順があるかを確認する
- ☐ 更新後の動作確認の結果を、報告として受け取る
- ☐ 不具合時の連絡先と、対応時間を控えておく
- ☐ 合意した内容はメールなど記録に残す
開発会社への質問例
- 「今回の更新作業には、更新後の動作確認は含まれていますか。含まれる場合、どの画面まで確認しますか」
- 「更新前の状態に戻すことはできますか。その場合、どのくらいの時間がかかりますか」
- 「今回の不具合は、更新作業が原因でしょうか。それとも、元からあった不具合が表に出たものでしょうか」
- 「保守費の範囲で直せますか。別料金になる場合は、その理由と見積もりを教えてください」
- 「次回の更新から、確認してほしい画面の一覧を事前にお渡ししてもよいでしょうか」
まとめ
- 更新後に動かなくなった場合の費用負担は、契約書の「保守の範囲」と「動作確認の範囲」で決まる
- 原因は、更新作業・元からの不具合・保守の外、の3つに切り分けてもらう
- 先に状況を記録し、業務への影響を伝え、必要ならロールバックで業務を止めない
- 今後は、確認してほしい画面の一覧を事前に共有し、テストの範囲を文章で決めておく
契約書の読み方や、開発会社とのやり取りに迷ったときは、第三者の目で確認すると安心です。
あわせて読みたい関連記事
