開発会社から「今のシステムは言語が古いので、新しい言語で作り直しませんか」と提案されて、本当に必要なのか判断できず、困っている発注者の方もいるのではないでしょうか。
「稼働中のシステムの言語が古いと言われました。流行の言語に作り直すべきなのか、使い続けていいのか、判断の基準が知りたいです。」
先に結論をお伝えします。「言語が古い」「流行ではない」だけを理由に、作り直しを決める必要はありません。見るべきなのは、言語の人気ではなく、「保守できる人がいるか」「サポート期限が切れていないか」「事業の変化に追いつけているか」の3点です。この3点に問題がなければ、使い続けながら部分的に直す選択肢も十分あります。
この記事は、執筆時点（2026年11月）の公的機関の資料にもとづく一般的な考え方をまとめたものです。個別の契約や見積もりの妥当性は、専門家や開発会社との打ち合わせで確認してください。
なぜ「言語が古い」と言われるのか
開発会社が「古い」と言うとき、言葉の中身は次のように分かれることが多いです。同じ「古い」でも、緊急度がまったく違います。
| 「古い」の中身 | 意味 | 緊急度の目安 |
|---|---|---|
| 言語やフレームワーク（＝開発の土台になる部品）のサポート期限が切れている | 公式の修正（セキュリティ上の不具合の修正など）が出なくなる | 高い。放置すると事故につながりやすい |
| その言語を扱える技術者が減っている | 保守や改修を頼める会社・人が見つかりにくくなる | 中。費用や納期に効いてくる |
| 設計書がなく、中身が分かる人がいない（ブラックボックス化） | 変更のたびに調査が必要になり、費用が上がる | 中〜高 |
| 流行から外れている | 話題になる機会が少ないだけ | 低い。それだけでは作り直す理由にならない |
経済産業省の「DXレポート」は、老朽化・複雑化し、中身が分からなくなった既存システム（レガシーシステム）が、企業のDX（＝デジタル技術による業務や事業の変革）の足かせになりうると指摘しています。ここで問題にされているのは、言語の流行ではなく、システムの中身が分からなくなっていることや、変化に対応しにくくなっていることです。
📰 出典：経済産業省「DXレポート」（2018年）
また、開発会社の側にも事情があります。古い言語の案件は、担当できる技術者が限られ、社内の体制を保つのが難しくなることがあります。提案の背景に「自社の保守体制を維持しやすくしたい」という理由が含まれることもありますが、それ自体は自然なことで、悪意とは限りません。大切なのは、理由を言葉にして説明してもらうことです。
判断する5つの基準
1. サポート期限が切れていないか
言語やフレームワークには、公式のサポート期限があります。期限を過ぎると、セキュリティ上の問題が見つかっても公式の修正が出ません。まず、今使っているものの名前とバージョン、サポート期限を一覧にしてもらいます。期限が切れている、または1〜2年以内に切れるなら、対応を計画する理由になります。
2. 保守を頼める人・会社が確保できるか
今の開発会社が保守できていても、担当者の異動や退職、契約の終了はあり得ます。別の会社に引き継ぐことになったとき、その言語を扱える会社が見つかるかどうかを確認します。市場に少ない言語でも、現在の開発会社が長期で保守を約束できるなら、すぐに困るとは限りません。
3. 事業の変化に追いつけているか
「新しい機能がつけられない」「他のシステムとつなげない」「スマートフォンで使えない」など、事業側の要望に応えられないことが続いているかを見ます。言語そのものより、システムの構造が理由であることも多いです。その場合、言語を変えるだけでは解決しません。
4. 中身が分かる状態か（設計書・テスト・担当者）
設計書が残っていて、動作を確かめるテスト（＝プログラムが正しく動くかを確認する仕組み）があれば、言語が古くても、安全に直しやすくなります。逆に、新しい言語で作り直しても、設計書やテストが残らなければ、数年後に同じ悩みを繰り返すことになります。
5. 作り直し以外の選択肢と比べたか
「作り直す」か「そのまま使う」かの二択にしないことが大切です。主な選択肢を整理すると、次のようになります。費用や期間は案件ごとに大きく変わるため、ここでは書きません。
| 選択肢 | 内容 | 向く場合 | 注意点 |
|---|---|---|---|
| そのまま使い続ける | 現状を維持し、保守を続ける | サポート期限に余裕があり、業務に支障がない | 期限と保守体制を定期的に見直す |
| バージョンアップ | 同じ言語のまま、新しい版に更新する | 期限が近いが、中身は大きく変えたくない | 動かなくなる部分の確認とテストが必要 |
| 部分的な置き換え | 困っている部分だけを新しく作り直す | 一部の機能だけが事業の足かせになっている | 古い部分と新しい部分をつなぐ作業が増える |
| 全面的な作り直し（リプレイス） | 新しい言語や構成で作り直す | 構造そのものが限界で、部分的な対応では解決しない | 費用・期間・移行のリスクが大きい |
作り直しの前には、現行のシステムが何をしているかを調べる作業が必要になります。この調査が別料金になるかどうかは、別の記事で整理しています。
「流行の言語」は判断材料になるのか
GitHubの年次レポート「Octoverse 2026」では、TypeScriptが2年連続で1位だったと報じられています。人気の言語は、情報が多く、技術者も集まりやすいという利点があります。一方で、順位は開発者の活動量の集計であり、お使いのシステムに向くかどうかを示すものではありません。また、このニュースだけで稼働中のシステムの言語を変える必要がないことは、別の記事で整理しています。
やりがちな失敗
- 「古い＝危険」と思い込んで、急いで作り直す。 サポート期限や保守体制を調べる前に決めると、不要な費用がかかることがあります。
- 「新しい言語にすれば、すべて解決する」と考える。 設計書やテストが残らない作り直しは、将来また同じ状態になりやすいです。
- 提案の理由を聞かずに、承認も反対もしない。 理由を聞いたうえで、必要なら別の開発会社にも意見を求めると、比べて判断しやすくなります。
- 開発会社の提案を「売りたいだけ」と決めつける。 理由を聞いて、事実と見解を分けて受け止めるほうが、対等に話せます。
発注者がやること チェックリスト
- ☐ 今のシステムが使っている言語・フレームワークの名前とバージョンを、開発会社に一覧にしてもらった
- ☐ それぞれのサポート期限を確認した
- ☐ 保守を引き継げる会社・人が市場にいるか、今の開発会社の保守体制と合わせて確認した
- ☐ 事業側で「できなくて困っていること」を書き出し、言語が原因か、構造が原因かを聞いた
- ☐ 設計書とテストが残っているかを確認した
- ☐ 「そのまま使う」「バージョンアップ」「部分的な置き換え」「全面的な作り直し」を並べて比べてもらった
- ☐ 提案の内容について、必要なら別の開発会社の意見も聞くことを検討した
開発会社への質問例
- 「『言語が古い』というのは、サポート期限の問題ですか、技術者が減っている問題ですか、それ以外ですか。具体的に教えてください。」
- 「今の言語とフレームワークのサポート期限はいつですか。期限が切れた場合、どんなリスクがありますか。」
- 「作り直す以外に、バージョンアップや部分的な置き換えという選択肢はありますか。それぞれの費用感と期間の違いを教えてください。」
- 「作り直した場合、設計書とテストは納品に含まれますか。将来、別の会社が引き継げる状態になりますか。」
- 「今のまま使い続けた場合、1〜2年後に起こりうる問題は何ですか。いつまでに判断すればいいですか。」
まとめ
- 「言語が古い」だけで作り直す理由にはなりません。サポート期限・保守できる人・事業の変化への対応・中身の分かりやすさの4点で判断します。
- 作り直しは「そのまま使う」「バージョンアップ」「部分的な置き換え」と比べたうえで、必要なときに選びます。
- 提案を受けたら、理由を言葉にしてもらい、チェックリストと質問例を使って打ち合わせに臨みましょう。
法律や契約に関わる判断は、一般的な考え方の紹介にとどまります。個別の契約は、弁護士などの専門家や公式の窓口に確認してください。
あわせて読みたい関連記事
