保守契約を結んでいるのに、「フレームワークのバージョンアップは保守の対象外なので、別途お見積もりです」と言われた。毎月の保守費で、更新作業まで面倒を見てもらっていると思っていたのに、どこからが別料金なのか分からない。そんなご相談は少なくありません。
「保守契約に含まれる更新作業と、別料金になる大きなバージョンアップの境目が分からない」
先に結論をお伝えします。境目は「バージョン番号の桁」と「契約書の文言」の2つで決まります。 多くのフレームワークでは、小さな更新（パッチ、マイナー）は互換性を保つ約束になっていて、大きな更新（メジャー）は動かなくなる変更を含みます。そのため、小さな更新は保守に含め、大きな更新は別見積もりにする、という線引きがよく見られます。ただし、これは慣習であり、実際の範囲は契約書に何と書かれているかで決まります（執筆時点：2026年11月）。
この記事では、線引きの考え方と、契約書で確認する5つのポイントを、チェックリストと質問例つきで解説します。契約の個別の解釈は一般論にとどまるため、必要に応じて弁護士や専門家にご確認ください。
更新作業とバージョンアップの違い
まず、言葉をそろえます。システムの部品（フレームワークやライブラリ）には、「8.1.2」のようにドット区切りのバージョン番号が付いています。多くの製品が採用しているセマンティックバージョニング（＝バージョン番号の付け方の決まり）では、3つの数字に意味があります。
| 桁 | 呼び方 | 上げる場面 | 例（8.1.2 の場合） |
|---|---|---|---|
| 左（8） | メジャー | 以前のバージョンと互換性のない変更を入れたとき | 8 → 9 |
| 真ん中（1） | マイナー | 互換性を保ったまま、機能を足したとき | 8.1 → 8.2 |
| 右（2） | パッチ | 互換性を保ったまま、不具合を直したとき | 8.1.2 → 8.1.3 |
📰 出典：Semantic Versioning 2.0.0（日本語）
たとえば PHP のフレームワークである Laravel は、この決まりに従っていると公式に説明しています。マイナーとパッチの更新は互換性を壊さない前提で、週単位で出ることもあります。一方でメジャーは年に1回ほどのペースで出て、動かなくなる変更を含みます。
📰 出典：Laravel 12.x Release Notes（Versioning Scheme）
つまり、パッチとマイナーは「部品を差し替えて、動作を確かめる」作業が中心で、メジャーは「プログラムを書き直す」作業が入りうるということです。作業量が大きく違うため、料金の扱いが分かれやすいのです。
境目が分かりにくくなる3つの理由
境目が曖昧になるのは、開発会社と発注者のどちらかが悪いからとは限りません。多くの場合は、次のような構造的な理由があります。
- 「更新」の言葉の意味が人によって違う：発注者は「最新にすること全般」を想像し、開発会社は「パッチとマイナーの適用」を想像していることがあります。
- メジャーの更新は作業量に幅がある：Laravel 12 は公式が「ほとんどのアプリはコードを変えずに上げられる」と説明しています。一方で、何世代も飛ばして上げる場合は、書き直しが大きくなります。
- サポート期限が作業のタイミングを決める：バージョンごとに、不具合の修正やセキュリティの修正が提供される期間が決まっています。期限が近づくと、メジャーの更新が必要になります。
サポート期間の例を挙げます。Laravel は、すべてのリリースで不具合の修正を18か月、セキュリティの修正を2年提供する方針で、12 は2027年2月24日までセキュリティの修正が提供される予定です。Ruby on Rails も、マイナーリリースごとにバグ修正を1年、セキュリティ修正を2年とする方針です。
こうした期限は製品によって異なります。そのため、契約を結ぶ時点で、使っているフレームワークの期限を開発会社と一緒に確認しておくのが安全です。
契約書で線引きする5つのポイント
1. 「保守の対象」に何が書かれているか
保守契約書や仕様書で、作業の一覧（保守の範囲）を探します。次のような書き方が多く見られます。
- 「軽微な修正」「ソフトウェアの更新」とだけ書かれていて、範囲の定義がない
- 「パッチ・マイナーバージョンの適用」と具体的に書かれている
- 「メジャーバージョンアップは別途協議」と書かれている
1つ目のように曖昧だと、後から解釈が分かれやすくなります。「何を」「どの桁まで」含めるかが書かれているかを見てください。
2. 「バージョンアップ」の定義と、別料金になる条件
「バージョンアップ」「アップグレード」という言葉が、契約書の中でどう定義されているかを確認します。特に次の点です。
- メジャーバージョンを上げる作業は、保守に含まれるのか、別見積もりなのか
- 別見積もりの場合、見積もりの出し方（作業の調査を先に有償で行うのか、など）
- 発注者の都合ではなく、サポート期限切れなど外部の事情で必要になったときの扱い
3. 作業の前後に何が付くか（調査・動作確認・テスト）
「更新を適用する」だけでなく、前後の作業が含まれるかも金額に響きます。
- 更新前の影響調査（動かなくなる部分がないかの確認）
- 更新後の動作確認とテスト（どの画面や機能まで確かめるか）
- 更新に失敗したときの元に戻す手順（ロールバック＝更新前の状態に戻すこと）
「適用は含むが、テストは別料金」という契約もあります。テストの範囲まで書かれているかを確かめましょう。
4. セキュリティの更新の扱い
セキュリティの修正は、期限を守れないと被害に直結するため、別扱いになっていることがあります。「緊急のセキュリティパッチは保守に含む」と書かれているか、含まれる場合の対応時間の目安があるかを確認します。この論点は、次の記事で詳しく解説しています。
5. 見直しの時期と費用の見通しの共有
バージョンアップは、いつか必ず発生する前提で計画するのが現実的です。契約を結ぶときや、更新のたびに、次のことを共有してもらうと安心です。
- 使っているフレームワークとライブラリの一覧と、それぞれのサポート期限
- 次のメジャーバージョンアップが必要になる時期の目安
- そのときの作業量の見込み（概算でよい）
サポート期限切れが近いと言われたときの判断の手順は、こちらの記事で解説しています。
やりがちな失敗
- 「保守費を払っているから全部含まれる」と思い込む：範囲は契約書で決まります。口頭の説明だけで判断しないでください。
- バージョンアップを先送りし続ける：何世代も飛ばすと、一度に必要な作業が大きくなり、費用も膨らみやすくなります。
- 金額だけで妥当性を判断する：作業の内訳（調査・書き換え・テスト）が分からないと、高い安いの判断ができません。
- 開発会社が儲けるための言い分だと決めつける：メジャーの更新は、実際に作業量が大きいことがあります。内訳を聞く姿勢で話すと、協力を得やすくなります。
費用の提示を受けた場面での確認点は、こちらの記事も参考になります。
発注者がやること チェックリスト
- ☐ 保守契約書の「保守の範囲」を読み、更新作業の記載を探した
- ☐ 「パッチ」「マイナー」「メジャー」のどこまでが保守に含まれるか、書面で確認した
- ☐ 別料金になる条件と、見積もりの出し方（調査が有償か）を確認した
- ☐ 更新前の影響調査と、更新後のテストが保守に含まれるか確認した
- ☐ セキュリティの緊急更新の扱いと、対応時間の目安を確認した
- ☐ 使っているフレームワークとライブラリのサポート期限の一覧をもらった
- ☐ 次のメジャーバージョンアップの時期と、概算の費用感を聞いた
開発会社への質問例
- 「保守に含まれる更新は、パッチ、マイナー、メジャーのどこまでですか。契約書のどの条文に書かれていますか。」
- 「メジャーバージョンアップが別料金になる場合、見積もりの前の調査は有償ですか。内訳（調査・修正・テスト）も教えてください。」
- 「更新を適用したあとの動作確認は、どの画面や機能まで行いますか。保守の範囲に入っていますか。」
- 「今使っているフレームワークのサポート期限はいつですか。次のメジャーバージョンアップは、いつ頃までに必要になりそうですか。」
- 「緊急のセキュリティ更新が出たときは、どのくらいの時間で対応いただけますか。費用は保守に含まれますか。」
まとめ
保守に含まれる更新と別料金のバージョンアップの境目は、バージョン番号の桁（パッチ・マイナーかメジャーか）と、契約書の文言で決まります。慣習として、小さな更新は保守に含め、大きな更新は別見積もりとされることが多い一方、実際の範囲は契約ごとに違います。
まずは保守契約書を開き、「更新」「バージョンアップ」の記載を探してみてください。曖昧な点は、金額の話になる前に、開発会社に質問して書面に残しておくのがおすすめです。
あわせて読みたい関連記事
