LASSIC Media らしくメディア
Delphi製アプリはいつまで使える？移行と外注の判断軸
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Delphi自体はEmbarcadero社の現行製品として販売・開発が継続しており、「廃止された技術」ではなく、老朽化した個別資産と開発者の高齢化が継続リスクの本体です。
- 移行の選択肢には最新Delphiへのアップグレード、.NET/C#への刷新、Web/SPA化があり、業務要件と保有スキルに応じた選定が求められます。
- 内製と外注では必要なスキルやリスク対応の重心が異なるため、自社資産の棚卸しと判断軸の整理が最初の一歩になります。
目次
Delphiとは？老朽化と混同されがちな「現行製品」としての実像
Delphiとは、Object Pascalという言語をベースにした統合開発環境（IDE）で、Windows向けデスクトップアプリケーションの開発に長く使われてきたツールです。1990年代からBorland社が提供し、現在はEmbarcadero Technologies社が開発・販売を続けています。公式製品ページでは2026年7月時点の最新版として「Delphi 13.1」が案内されており、Windows・macOS・iOS・Android・Linuxに対応するクロスプラットフォーム開発ツールという位置づけです*1。
ここで押さえておきたいのは、Delphiという製品そのものが終息・廃止されたわけではないという点です。Windows向けアプリのフレームワークとしては「VCL（Visual Component Library）」が中心に位置づけられており、公式サイトでも「Windows 11向けにVCLアプリを最新のUIコントロールやWinRT APIで現代化する」といった、既存Windowsアプリの現代化を後押しする方向性が明示されています*1。つまり多くの企業が抱える課題は「ツールが消えた」ことではなく、「古いバージョンで作られた個別資産」と「それを保守できる人・体制」の側にあると整理できるでしょう。
「動くから」で放置できない理由―継続リスクの正体
開発者の高齢化・退職によるObject Pascal属人化
Delphi（Object Pascal）は1990年代から2000年代にかけて国内の業務システム開発で広く採用された経緯があり、当時から携わってきた技術者が定年退職や転職の時期を迎えつつあります。設計書が整備されないまま「動くコード」だけが残っている場合、後任者が仕様を把握するまでに時間がかかり、軽微な改修すら着手できない状態に陥りやすくなります。特定の担当者しかソースコードの構造を理解していない属人化は、退職や異動という一度きりの出来事で保守が止まってしまうリスクをはらんでいるといえるでしょう。
動作環境の制約―32bit依存・周辺ミドルウェアの世代差
古いバージョンのDelphiで作られたアプリには、32bit専用でビルドされている、特定バージョンのデータベースドライバーやODBC接続に依存している、といった制約が残っているケースが見られます。Windows自体は新しいバージョンでも動作を継続できることが多い一方、周辺のミドルウェアやハードウェア（バーコードリーダー・専用プリンター等の周辺機器ドライバー）が新しいOS環境で提供されなくなると、業務アプリ全体の入れ替えを迫られる事態につながります。こうした制約は日常の運用では表面化しにくく、OSの大型更新やハードウェアの故障といったタイミングで一気に顕在化する傾向があるでしょう。
Embarcadero公式が示す現行Delphiの位置づけ
エディション体系とライセンス条件
Embarcadero公式サイトによると、Delphiは「Community・Academic・Professional・Enterprise・Architect」という5つのエディションで提供されています*3。無料のCommunity版は、個人開発者・フリーランス・スタートアップ・学生・非営利団体を主な対象としており、年間売上高が一定水準（公式表記で米ドル5,000ドル）に達した場合、または開発チームの人数が5名を超えた場合には、Professional以上のエディションへ切り替える必要があるとされています*3。自社が現在利用しているDelphiのエディションとバージョンを把握することは、移行を検討する際の出発点になるでしょう。
サポートは「現在有効な契約」が前提
公式サポートページでは、「製品サポートは、現在サポート契約を結んでいる顧客の製品関連の問題を対象とする」旨が案内されており、Standard Update SubscriptionとPremium Update Subscriptionという2種類の更新サブスクリプションが用意されています*2。裏を返せば、保守契約を更新していない、あるいは長期間バージョンアップを行っていない古い環境については、Embarcadero公式のサポートを受けられるとは限らないということです。「昔購入したDelphiのライセンスがある」ことと「現在サポートを受けられる状態にある」ことは、別の問題として確認する必要があります*2。
モダナイゼーションの選択肢を整理する
選択肢①最新Delphiへのアップグレード
最も移行コストを抑えやすいのは、既存のObject Pascal資産を活かしたまま最新のDelphiへアップグレードする選択肢です。公式サイトでは、AI支援機能「Kai for RAD Studio」がIDEに組み込まれ、コーディング・ビルド・既存アプリの現代化を支援すると案内されており*1、公式ブログでも「2003年当時のような見た目のままのアプリを刷新する」ことをテーマにした発信が見られます。ソースコード資産をそのまま活用できる可能性がある一方、旧バージョン固有の記法や非推奨APIへの対応、動作検証は避けて通れない工程です。
選択肢②.NET/C#への移行
Windows業務アプリの刷新先として広く採用されているのが、Microsoftの.NETです。Microsoft公式ドキュメントでは、.NETは無料でオープンソースのクロスプラットフォーム開発基盤であり、Microsoftとグローバルコミュニティによって共同管理され、年1回（11月）の新バージョンリリースと月次の更新が継続的に行われていると説明されています*4。C#はDelphiのObject Pascalと同じくオブジェクト指向言語であるため、設計思想としての親和性はありますが、言語・フレームワークの書き換えが発生するため、Delphi版とは別の実装として作り直す前提での計画が必要になります。
選択肢③Web/SPAへの刷新
社内の複数拠点や在宅勤務からのアクセスを想定する場合は、デスクトップアプリからWebアプリ・SPA（シングルページアプリケーション）へ刷新する選択肢もあります。ブラウザさえあれば利用できるためクライアント側の配布・更新作業が不要になる一方、印刷制御や周辺機器連携など、デスクトップアプリならではの機能をどう代替するかが設計上の論点になります。業務フローの何をWeb化し、何をデスクトップに残すかの切り分けが、刷新の成否を左右するでしょう。
内製と外注のコスト構造比較
移行を内製で進める場合と外部パートナーへ委託する場合では、必要なスキル・費用構造・リスク対応の重心が異なります。以下の表に主な違いを整理しました。
| 比較項目 | 内製で進める場合 | 外注委託する場合 |
|---|---|---|
| 必要な専門知識 | Object Pascalの読解に加え、移行先（.NET/C#やWeb技術）双方のスキルが必要です | レガシー言語と移行先技術の双方に精通したパートナーへ調達を任せられます |
| 仕様の把握 | 設計書がない場合、社内の記憶とソースコード解読に頼ることになります | リバースエンジニアリングや仕様書起こしを含めて委託できます |
| ライセンス・体制コスト | Delphi公式のエディション・サブスクリプション費用に加え、育成コストが発生します*3 | 開発体制の確保・維持は委託先の責任範囲になります |
| 移行後の保守 | 新技術の保守体制を自社で新たに構築する必要があります | 移行後の運用保守までを一貫して依頼できる場合があります |
移行を進める標準的なステップ
現状棚卸しと影響範囲の整理
最初に行うべきは、対象アプリが利用しているDelphiのバージョン・エディション、依存しているデータベースやドライバー、連携している周辺システムの洗い出しです。ソースコード自体は残っていても、ビルド環境や過去に使っていたコンポーネント（部品）が入手困難になっているケースもあるため、実際にビルドが通るかどうかの確認も早い段階で行っておく必要があります。
PoCと機能単位の段階移行
アプリ全体を一度に作り直す前に、利用頻度の高い一部機能でPoC（概念実証）を実施し、移行方式の妥当性を検証する進め方が現実的です。検証後は、業務影響が小さい機能から段階的に新環境へ切り替え、旧アプリと並行運用する期間を設けることで、切替時の業務停止リスクを抑えられます。全機能の移行が完了するまで旧環境を安定的に稼働させられる体制を並行して確保しておくことも欠かせません。
外注先選定で確認すべきポイント
外部パートナーへ移行を委託する場合、確認したいポイントはいくつかあります。第一に、Object Pascal・Delphiの読解実績があるか。第二に、移行先として想定する.NET/C#やWeb技術の開発実績を併せ持っているか。第三に、Embarcadero公式のサポート契約が現在有効かどうかなど、ライセンス・サポート面の現状確認まで含めて対応できるかという点です*2。移行だけでなく、切替後の運用保守まで一貫して依頼できるかどうかも、パートナー選定における重要な判断材料になるでしょう。
まとめ：Delphi資産の継続リスクと向き合う3つの判断軸
本稿ではDelphi製業務アプリの継続リスクと移行の選択肢を、Embarcadero公式情報とMicrosoft公式ドキュメントに基づいて整理しました。要点は次の3つに集約されるでしょう。第一に、Delphiという製品自体は現行版として販売・開発が継続しており、リスクの本体は個別資産の老朽化と開発者の高齢化にあります*1。第二に、移行の選択肢には最新Delphiへのアップグレード・.NET/C#への刷新・Web化があり、それぞれ活かせる資産と作り直しの範囲が異なります*4。第三に、内製と外注では必要なスキルと体制コストの重心が異なるため、現状棚卸しを経たうえでどちらに委ねるかを判断する必要があります。
よくある質問
Delphiは今も使われている現行の開発ツールですか。
はい。Embarcadero公式の製品ページでは、2026年7月時点の最新版としてDelphi 13.1が案内されており、Windows・macOS・iOS・Android・Linuxに対応するクロスプラットフォーム開発ツールとして販売・開発が継続しています。「廃止された技術」ではなく、老朽化した個別の資産や開発体制の側にリスクが生じている点に注意が必要です。
古いバージョンのDelphiで作られたアプリはサポートを受けられますか。
Embarcadero公式のサポートページでは、製品サポートは現在有効な保守契約（サポートコントラクト）を結んでいる顧客向けと案内されています。保守契約が切れている、または長期間バージョンアップしていない場合は、公式サポートを受けられるかどうか個別に確認が必要です。
Delphiのライセンス体系はどうなっていますか。
公式サイトによると、Community・Academic・Professional・Enterprise・Architectの5エディションが用意されています。Community版は年間売上高が一定水準（公式表記で米ドル5,000ドル）に達するか、開発チームが5名を超える場合はProfessional以上への切り替えが必要とされているとのことです。自社の利用規模がどのエディション相当かの確認が移行検討の前提になります。
.NET/C#への移行はDelphiと比べてどのような違いがありますか。
Microsoft公式ドキュメントによれば、.NETは無料でオープンソースのクロスプラットフォーム開発基盤であり、Microsoftとコミュニティによって継続的に保守され、年1回の新バージョンリリースと月次更新が行われています。Delphiと同様にオブジェクト指向言語（C#）を採用しますが、言語・フレームワークとしては別物であり、書き換えを前提とした計画が必要です。
内製と外注、どちらで移行を進めるべきですか。
一概にどちらが優れているとは言えません。社内にObject Pascalと移行先技術の双方に精通した人材がいるか、既存アプリの仕様書やソースコードがどの程度整備されているかによって、適した進め方は変わります。まずは自社アプリの現状棚卸しを行い、必要なスキルとリスクの所在を整理したうえで判断することが出発点になるでしょう。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Embarcadero公式サイト「Delphi」製品ページ（https://www.embarcadero.com/products/delphi）
- *2 出典：Embarcadero公式サイト「Support」ページ（https://www.embarcadero.com/support）
- *3 出典：Embarcadero公式サイト「Delphi Community Edition」ページ（https://www.embarcadero.com/products/delphi/starter）
- *4 出典：Microsoft Learn「.NET の概要」（https://learn.microsoft.com/ja-jp/dotnet/core/introduction）
