保守を任せている開発会社から「システムで使っている技術のサービスが終わるそうです」と連絡が来ると、「うちのシステムも止まるのか」「移行にかかる費用は自社の負担なのか」と、不安になるのは当然です。
「開発会社が使っている技術のサービスが終わると聞きました。うちのシステムが対象なのか、移行費用は誰が払うのか分からなくて…」
先に結論をお伝えします。費用を誰が負担するかは、「終了の連絡を受けた時点」では決まりません。保守の契約書と仕様書に、どこまでが保守の範囲かがどう書かれているかで決まります。まず確認するのは、自社のシステムが対象かどうか、いつまで使えるか、移行しない場合の選択肢の3点です。
この記事は、システム開発を外部に依頼して運用している事業担当者に向けて、サービス終了の連絡を受けたときの確認の順番と、費用の話し合いの進め方をまとめたものです。技術の細かい仕組みには踏み込まず、発注・費用・契約の判断に絞ります。法律や契約の個別の判断はできないため、一般的な考え方の紹介にとどめます。
なぜ「使っている技術のサービス終了」は起こるのか
システムは、開発会社が一から作った部分だけでなく、他社が提供するクラウドのサービス、ランタイム（＝プログラムを動かすための土台となるソフトウェア）、ライブラリ（＝既製の部品）などを組み合わせて動いています。これらの提供元は、会社の方針転換や合併、利用者の減少などを理由に、サービスの提供を終えることがあります。
最近の例として、Deno（JavaScriptなどを動かすランタイム）の開発チームが2026年10月9日、Cloudflareに合流すると発表しました。公式ブログの記述によると、Denoのランタイムは今後約1年間、バグ修正とセキュリティ更新を含む月次リリースを続けたあと開発を終了する予定で、ホスティングサービスの「Deno Deploy」は約6か月の運用のあと終了する予定です（執筆時点：2026年11月）。ランタイムはオープンソースとして残り、開発を引き継ぐ人を歓迎するとも書かれています。
📰 出典：Deno公式ブログ「Deno joins Cloudflare」（2026-10-09）
ここで大切なのは、これは特定の会社の誰かが悪いという話ではなく、どのシステムにも起こりうる「前提の変化」だという点です。開発会社が事前に伝えてくれたこと自体は、むしろ良い兆候といえます。以前の記事では、同じニュースが自社システムに影響するかの確認を扱いました。
最初に確認する5つのこと
連絡を受けたら、費用の話の前に、次の5つを順番に確認します。
1. 自社のシステムが対象かどうか
「使っている技術のサービス」が、自社のシステムのどの部分を指すのかを聞きます。名前だけでは、画面の表示に使う部品なのか、データを保管する仕組みなのか、動かす土台そのものなのかが分かりません。
2. いつまで使い続けられるか
提供元の発表には、「新規受け付けの終了」「更新の終了」「サービスの停止」など、段階がある場合があります。終了予定日は、提供元の公式発表（日付つき）で確認します。「いつか終わるらしい」という噂では判断しません。
3. 終了後も使い続けると何が困るか
サービスが終わっても、すぐにシステムが止まるとは限りません。ただし、セキュリティの更新が止まる、障害時に問い合わせ先がなくなる、といったリスクが残ります。「使い続ける場合」と「移行する場合」の両方の影響を、開発会社に整理してもらいます。
4. 移行の選択肢と、それぞれの費用の目安
移行先の候補は、同じ提供元の後継サービス、別の会社のサービス、別の仕組みへの作り替えなど、複数あるのが普通です。費用や期間は、システムの規模と構成で大きく変わるため、一般的な相場で決めつけず、案件ごとの見積もりを依頼します。
5. 費用の負担を決める根拠（契約書・仕様書）
最後に、今の保守契約でどこまでが範囲かを確認します。ここが、費用を誰が負担するかの分かれ道です。
移行費用は誰が払う？契約で見るポイント
結論から言うと、「必ず発注者が払う」「必ず開発会社が払う」といった決まりはありません。多くの場合、次の点で整理されます。
| 見るところ | 確認する内容 |
|---|---|
| 保守の範囲 | 保守契約に「環境の変更への対応」「他社サービスの終了への対応」が含まれているか |
| 契約の種類 | 請負（＝完成させることを約束する契約）か、準委任（＝作業を行うことを約束する契約）か |
| 当初の見積もりの前提 | その技術を使い続けられることが前提だったか、前提条件に書かれているか |
| 提供元の終了時期 | 契約期間の内か外か |
| 追加作業の扱い | 範囲外の作業は、別見積もり・別契約になるか |
経済産業省とIPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」には、保守運用についてのひな型があり、共通のルールを基本契約に置き、業務の範囲や役割分担は個別の契約や仕様書で決めるという考え方が示されています。自社の契約書がこの形になっていれば、個別契約と仕様書に「どこまでが保守か」が書かれているかを見ることになります。
📰 出典：IPA「情報システム・モデル取引・契約書（第二版）」
契約書に何も書かれていない場合は、一方が負担すると決めつけず、「提供元の終了という、両者が予見しにくかった事情が出た」という事実を共有したうえで、範囲と費用を話し合うのが現実的です。契約の解釈そのものは個別の事情で変わるため、金額が大きい場合は弁護士などの専門家に相談してください。
やりがちな失敗
- 連絡を受けてすぐ「見積もりを出して」とだけ頼む：対象範囲の確認が抜けると、必要のない移行まで見積もりに入ることがあります。
- 「保守費を払っているのだから無償のはず」と考える：保守の範囲が不具合の修正までの契約もあり、環境変更への対応は別扱いのことがあります。
- 終了日まで何もしない：移行には、調査・開発・テスト・切り替えの時間が必要です。余裕がないと選択肢が減ります。
- 一社の説明だけで決める：金額が大きい場合は、他の開発会社の意見を聞く（セカンドオピニオン）ことも選択肢です。ただし、相手を疑う姿勢ではなく、判断材料を増やす目的で伝えましょう。
発注者がやることチェックリスト
- ☐ 連絡を受けた内容を、提供元の公式発表（日付つき）と照らして確認する
- ☐ 自社のシステムのどの部分が対象か、開発会社に書面でまとめてもらう
- ☐ 終了予定日と、終了までの段階（更新の停止、サポートの停止など）を確認する
- ☐ 「使い続ける場合」と「移行する場合」のリスクと費用を比べてもらう
- ☐ 保守契約書と仕様書で、保守の範囲と追加作業の扱いを確認する
- ☐ 移行の期限から逆算して、予算の確保と社内承認の時期を決める
- ☐ 話し合いの結果は、議事録かメールで残す
開発会社への質問例
- 「今回のサービス終了は、当社のシステムのどの部分に影響しますか。影響しない部分も教えてください」
- 「提供元の発表では、いつ、どの段階で何が使えなくなりますか。公式の情報の場所を教えてください」
- 「使い続けた場合と移行した場合で、リスクと費用、作業期間はそれぞれどう違いますか」
- 「今回の対応は、現在の保守契約の範囲に入りますか。範囲外の場合、見積もりの前提を教えてください」
- 「移行の候補が複数ある場合、それぞれの向き不向きと、あなたのおすすめの理由を教えてください」
まとめ
- サービス終了の連絡を受けたら、費用の話の前に、対象範囲・終了時期・使い続けた場合の影響を確認します。
- 移行費用を誰が負担するかは、保守契約と仕様書の範囲で決まります。一律の決まりはありません。
- 開発会社が早めに伝えてくれたなら、責める場面ではなく、一緒に選択肢を整理する場面です。
- 製品の終了時期や内容は変わることがあるため、最新の情報は提供元の公式発表で確認してください。
法律や契約に関わる判断は、一般的な考え方の紹介にとどまります。個別の契約については、弁護士などの専門家や公式の窓口に確認してください。
あわせて読みたい関連記事
