フレームワークのバージョンが古いと言われ、アップデートに高額な費用を提示された時に発注者が確認すること

2026年10月1日2026年10月4日

数年前に作ってもらったWebシステムの保守を相談したら、「使っているフレームワークのバージョンが古いので、アップデートに大きな費用がかかります」と言われた。技術的な話で、高いのか妥当なのかも判断できない。そんな状況で戸惑う発注者の方は少なくありません。

「使っているフレームワークのバージョンが古く、アップデートに大きな費用がかかると言われた。払うしかないのでしょうか？」

先に結論をお伝えします。費用の大小を判断する前に、「何がいつまでサポートされるのか」「アップデートしない場合に何が起きるか」「費用の中身はどう分かれているか」の3つを開発会社に書面で説明してもらってください。この3つが分かれば、「今すぐ全部やる」「段階的に進める」「当面は見送る」のどれを選ぶべきかを、発注者として判断できます。

この記事では、バージョンアップに費用がかかる理由、確認すべきこと、進め方の選択肢を、そのまま使えるチェックリストと質問例とあわせて解説します。なお、本記事は執筆時点（2026年10月）の一般的な考え方であり、個別の契約や見積もりの妥当性を判断するものではありません。

フレームワークのバージョンアップに費用がかかる3つの理由

まず、「なぜ費用がかかるのか」を知っておくと、見積もりの読み方が分かります。

フレームワーク（＝Webシステムを作るときの土台になる部品のセット。Ruby on Rails、Laravel、Django などがあります）は、定期的に新しい版が公開されます。そして古い版は、一定期間を過ぎると公式の修正（特にセキュリティの修正）が提供されなくなります。

理由1：古い版との間に「互換性のない変更」が積み重なっている

新しい版では、機能の書き方が変わったり、古い機能が廃止されたりします。何年も更新していないと、その差が積み重なり、「1段階ずつ」上げていかないと動かないことがあります。大きな差を一度に埋める作業になるほど、工数は増えます。

理由2：土台に合わせて、周辺の部品も入れ替えが必要になる

システムはフレームワーク単体では動かず、検索・決済・認証などの外部部品（ライブラリ）を組み合わせています。土台を上げると、これらの部品も対応版へ入れ替える必要があり、それぞれに修正と確認が発生します。

理由3：「動いているものを壊さない」ための確認作業が必要

見た目は変わらなくても、内部の動きが変わっていないかを確かめる作業（テスト）が欠かせません。自動テストが少ないシステムでは、人の手での確認が増え、費用の大半がここに使われることもあります。

「コードを書き換える時間より、元と同じように動くかを確かめる時間のほうが長くなることも珍しくありません。見積もりの内訳でテストの割合を見ると、費用の理由が分かりやすいです」

「古いまま使い続ける」と何が起きるのか

費用を抑えたくて見送りたくなる気持ちは自然なことです。ただ、見送る場合は、起きうることを理解した上で決めましょう。

最も大きいのは、サポート期間が終わった版では、新しく見つかった脆弱性（＝悪用されうる弱点）の修正が公式から出なくなることです。たとえば Ruby on Rails の公式サイトでは、保守ポリシーとして次のように説明されています。

📰 出典：Ruby on Rails「Maintenance Policy」

この公式ページによると、各版はバグ修正が公開から約1年、セキュリティ修正が約2年提供され、サポートが終わった版については「バグやセキュリティの問題に自分たちで対処する責任がある」とされています（執筆時点の記載）。他のフレームワークや言語にも、それぞれ同様の考え方のサポート期間があります。

つまり古いまま使い続けるとは、「不具合や弱点が見つかっても、公式の修正を受け取れない状態で運用する」ということです。個人情報や決済を扱うシステムでは、特にリスクが高まります。一方で、外部に公開されていない社内システムで、取り扱う情報も限られるなら、当面の判断が変わることもあります。リスクの大きさはシステムごとに違うため、「一律で今すぐ必須」とも「不要」とも言えません。

費用の中身を分けて確認する4つのステップ

ステップ1：現在のバージョンとサポート状況を書いてもらう

まず、「いま使っているフレームワーク・言語・主要な部品の名前とバージョン」と「それぞれのサポート終了時期」を一覧にしてもらいます。ここが曖昧なまま見積もりが出ているなら、先にこの整理を依頼しましょう。

ステップ2：見積もりの内訳を分けてもらう

「バージョンアップ一式」ではなく、次のように分けてもらうと比較しやすくなります。

作業の種類	内容	見るポイント
調査・影響確認	どこに修正が必要かを洗い出す	先に小さく依頼できるか
土台のバージョンアップ	フレームワーク本体の更新	何段階に分けて上げるか
周辺部品の入れ替え	ライブラリ等の対応	対応版が無い部品はあるか
テスト・動作確認	元と同じ動きかの確認	自動テストの有無・人手の量
公開作業・切り戻し準備	本番への反映と、失敗時の対処	停止時間はどのくらいか

ステップ3：選択肢を並べて比較する

アップデートの進め方は一つではありません。目的と予算に合わせて選びます。

選択肢	向いている状況	注意点
一度にまとめて最新版へ	大きな改修も予定している／サポート切れが近い	費用と一時的な負担が大きい
段階的に上げる	予算を分けたい／止められる時間が短い	全体の期間は長くなる
当面は見送り、期限と条件を決める	情報が限られた社内システム等	期限を決めないと先送りが続く
作り直す・別の仕組みへ置き換える	古さ以外の問題も多く、改修が大きい	移行の費用と期間を別に見積もる

ステップ4：「いつまでに何をするか」を計画に落とす

どれを選んでも、「いつ、どの版まで上げるか」を決めておくことが大切です。サポート終了の時期から逆算して、予算を来期に計上しておけば、突然の高額請求に見えにくくなります。

やりがちな失敗パターン

「高いから」と理由を確認せずに断る：サポート切れのまま運用が続き、後から更に費用が膨らむことがあります
「言われたまま」一式で発注する：内訳が分からないと、必要な作業と、ついでの改修が混ざっても判断できません
保守契約に何が含まれるかを確認していない：軽微な更新は保守に含まれ、大きなバージョンアップは別料金という契約も一般的です。契約書の「保守の範囲」を先に見ましょう
先送りに期限をつけない：「そのうち」が数年続くと、差が開いて費用が増えやすくなります

なお、費用が高く見えるのは開発会社が不当に上乗せしているからとは限りません。上の3つの理由のとおり、作業の性質上、工数がかかることが多いのです。まずは内訳の説明を求め、納得できるまで対話するのが近道です。