Delphiのシステムを発注・外注するときは、開発言語を先に決めるのではなく、既存資産と将来の利用形態を調査し、保守・段階更新・再構築のどれを選ぶか明確にすることが重要です。
「Delphi 7やXEで作られた業務システムを誰に依頼すればよいか分からない」「RFPには何を書けばよいか」「見積書の金額をどう比較すればよいか」と悩む企業に向けて、発注形態の選び方、要件整理、契約形態、費用相場、委託先の見極め方、相見積もりの確認項目を実務の順番に沿って解説します。古いDelphiを無条件に捨てるのでも、担当者に依存して使い続けるのでもなく、業務を止めずにリスクを下げる発注方法を考えます。
▼全体ガイドの記事
・Delphiのシステム開発の完全ガイド
Delphiのシステムを発注・外注する前の全体像

Delphiのシステム開発を依頼する場合、最初に「何を作るか」だけでなく、「何を残し、何を変えるか」を決めます。既存のソースコード、データベース、帳票、外部連携、担当者の知識が残っているかによって、同じ機能を作る場合でも発注方法と費用が大きく変わります。
発注前に既存資産を棚卸しします
まず確認するのは、Delphiのバージョン、VCLかFireMonkeyか、32ビットか64ビットか、利用中の第三者コンポーネント、BDEなどの古いデータアクセス方式、データベースの種類、帳票ツール、バッチ、外部API、EDI、専用機器との接続です。ソースコードがあっても、開発環境やコンポーネントのライセンス、ビルド手順、テストデータがなければ、すぐに改修できるとは限りません。
画面一覧だけでなく、利用者、拠点、ピーク時間、手作業、Excelや紙との二重管理、障害時の復旧方法も整理します。設計書に書かれていない業務ルールが、画面イベントや担当者の経験に埋め込まれていることがDelphiの長期運用システムでは珍しくないためです。棚卸しの成果物は、発注先へ渡せる現行資産一覧と、残したい機能・改善したい機能・廃止候補の一覧にします。
残す・更新する・作り直すの判断を分けます
Windowsの現場端末、専用プリンター、バーコードリーダー、オフライン運用、高速な大量入力が重要で、既存の業務ロジックも活用できるなら、現行Delphiの保守やバージョンアップが候補になります。古いコンポーネントを置き換え、データベースへの直接接続をAPIやサービス層へ段階的に分離すれば、画面を一度に全廃棄せずにセキュリティと連携性を高められます。
ブラウザ利用、スマートフォン対応、クラウドネイティブな運用、採用しやすい技術、外部サービスとのAPI連携が最優先なら、.NET、Java、Web技術などへの再構築も比較します。会計や勤怠のように標準化しやすい領域はパッケージやSaaSを利用し、Delphiは固有業務や既存機器との連携に限定する方法もあります。発注先には一つの方式だけを売り込ませず、少なくとも「現行保守」「段階的なモダナイズ」「別技術への再構築」の3案を同じ要件で比較してもらいます。
Delphiのシステムはどの発注形態で外注しますか?

発注形態は、業務側の関与度、要件の確定度、既存資産の不確実性、責任範囲で選びます。Delphiのシステムでは、単に人手を借りるのか、成果物の完成まで任せるのか、現行調査から伴走してもらうのかを曖昧にすると、見積もりと責任の境界が崩れやすくなります。
請負型は完成物と責任範囲を明確にします
請負型は、開発会社が要件定義書、設計書、プログラム、テスト結果、移行手順などの成果物を完成させ、発注側が検収する形態です。画面数、帳票数、連携先、対応OS、性能、受け入れ条件が比較的固まっている新規開発や、対象範囲が明確な改修に向いています。
ただし、古いDelphiの解析結果が契約前に分からない場合、最初から全工程を固定価格にすると、想定外のコンポーネント交換やソース解析が追加変更になりがちです。その場合は、最初に現行調査と基本構想を請負で発注し、調査結果をもとに本開発の見積もりを更新する二段階方式が安全です。請負でも、発注側が業務判断と受け入れ試験を担うことは契約書に明記します。
準委任型は調査・保守・伴走に向いています
準委任型は、一定期間の作業や専門知識の提供に対して報酬を支払う形態です。現行ソースの読解、開発環境の再現、障害調査、バージョンアップの影響分析、要件定義の支援など、作業量を契約時点で完全に確定しにくい業務に適しています。担当者の退職で知識が失われた場合や、社内にDelphiを理解できる人がいない場合の技術顧問にも使われます。
準委任型では、時間を使ったことだけを成果とせず、月次の作業報告、解析した対象、判明したリスク、作成した設計資料、次月の計画を提出してもらいます。常駐かリモートか、担当者のスキル、月の稼働時間、緊急対応の扱い、成果物の著作権と利用権、契約終了時の引き継ぎを確認します。保守契約も同じ考え方で、問い合わせ、障害、軽微改修、制度対応、大規模改修を分けておくと追加費用を管理しやすくなります。
二段階発注で不確実性を小さくします
おすすめしやすいのは、第一段階で現行調査・業務整理・PoCを行い、第二段階で本開発または移行を発注する進め方です。PoCでは、代表画面、代表帳票、データベース接続、認証、ログ、外部連携、性能を小さな範囲で検証します。ここで「現行コードが現行版でビルドできるか」「古い部品を代替できるか」「想定した業務ルールを再現できるか」を確認すると、実装後の大幅な見積もり増額を抑えやすくなります。
発注側は、第一段階の終了条件も決めます。例えば、資産一覧の完成、重要画面の依存関係の可視化、移行方式の比較、代表データでの性能確認、主要リスクと対策の提示を成果物にします。調査の結果、Delphiを残さない方が合理的になっても、別技術へ移行する判断材料が手元に残るため、委託先の提案に流されにくくなります。
RFPと要件整理では何を伝えますか?

RFPは、開発会社に提案と見積もりを依頼するための資料です。「Delphiで販売管理を作りたい」だけでは会社ごとの前提が変わるため、目的、対象範囲、現行環境、業務上の制約、希望時期、予算の考え方、提案してほしい内容を同じ粒度で渡します。既存システムの問題点を隠さず、分からないことは未確定事項として明記することが、後の追加請求を減らします。
RFPに記載する基本項目
基本項目は、発注の背景と目的、対象業務、利用者と拠点、現行システムの構成、対象画面・帳票・バッチ・外部連携、改善したい課題、必須機能、将来対応、希望する稼働時期です。既存Delphiについては、バージョン、VCLまたはFMX、ソースコードの有無、開発環境、コンポーネント、DB、ソースと設計書の保管場所、現在の保守会社、障害履歴を記載します。
提案依頼の条件には、現行保守・段階更新・再構築を比較すること、現行調査の範囲を示すこと、想定する開発期間と前提を記すこと、標準機能と追加開発を分けること、成果物と検収方法を示すことを含めます。見積もりは一式ではなく、調査、要件定義、設計、開発、テスト、移行、教育、インフラ、ライセンス、保守に分けてもらいます。
非機能要件とセキュリティを先に決めます
業務画面の機能だけでなく、同時利用者数、応答時間、稼働時間、バックアップ頻度、復旧目標、保存期間、認証方式、権限、監査ログ、暗号化、個人情報の扱いを要件に含めます。「快適に動く」ではなく、例えば通常操作の大半を何秒以内に表示するか、障害から何時間以内に復旧するかのように、検証できる表現にします。Delphiの既存システムでDB直結や接続情報のハードコードがある場合は、改修対象とリスクをRFPの時点で開示します。
IPAが2026年3月に公開した製品利用者向けガイドでは、自社開発だけでなく委託開発を含むシステム・サービスについて、委託先に求めるセキュリティ対策を確認できるとしています(出典: IPA「製品開発者向け・製品利用者向けガイド」、2026年)。受託開発会社には、脆弱性情報の確認、依存コンポーネントの管理、秘密情報の分離、ビルド環境の保護、ログの保管、インシデント発生時の報告期限を提案書と契約書に明記してもらいます。
納品物と引き継ぎ条件を明確にします
納品物には、要件定義書、画面・帳票一覧、基本設計書、詳細設計書、データベース定義、API仕様、ソースコード、テスト仕様書と結果、移行計画、操作マニュアル、運用手順、バックアップ・復旧手順、ビルド手順を含めます。Delphiでは開発ツールだけでなく、第三者コンポーネントの名称・バージョン・ライセンス、インストーラー、証明書、環境変数、設定ファイルの管理方法も引き渡し対象にします。
さらに、発注先を将来変更できるよう、ソースコードと設計書の利用権、リポジトリの管理者、開発環境の再現方法、問い合わせ履歴の共有、担当者退職時の引き継ぎ、契約終了時のデータ返却を決めます。委託先が自社で保守できる体制を持っているか、再委託先の一覧と管理方法を開示できるかも確認します。納品物を受け取るだけでなく、自社または第三者が再ビルドしてテストできることを検収条件にすると、ベンダーロックインを抑えられます。
Delphiのシステムの契約形態と費用相場

Delphiだけを対象にした公的な開発費統計は見当たらないため、費用相場は予算取りの目安として扱います。金額は人件費、必要工数、ライセンスやインフラなどの付帯費用で決まり、要件定義の精度によって倍以上動く場合もあります(出典: イー・ジーシステム「システム開発の費用相場と見積書の読み方」、2026年)。とくに既存Delphiの解析と移行では、画面数だけでなく、古い部品とデータ品質が工数を左右します。
規模別の費用と期間はレンジで考えます
既存Delphiの帳票追加、項目変更、不具合対応、限定的なOS対応は、ソースと開発環境がそろっている前提で50万〜300万円程度、期間は2週間〜3か月程度が初期検討のレンジです。10〜40画面ほどで、RDB、権限、CSVやAPI連携、帳票を含む部門向け新規アプリは、300万〜1,000万円程度、3〜8か月程度を目安にします。いずれも個別見積もりではなく、調査範囲と前提を伴う参考値です。
販売・在庫・受発注など中規模の業務システムは、500万〜2,000万円程度、4〜12か月程度のレンジで検討されることがあります。Delphi 7などから現行版へのマイグレーション、64ビット化、コンポーネント交換、API分離、回帰テストを含める場合は、500万〜3,000万円程度まで広がる可能性があります。複数拠点、履歴移行、並行稼働、教育、IBM i連携を含む基幹再構築は、数千万円から1億円超まで幅があるため、PoCと段階発注で不確実性を分けます。これらのレンジはリサーチノートに整理したDelphi開発関連記事と業務システム一般の2026年相場を組み合わせた編集上の目安で、特定案件の価格を保証するものではありません。
ライセンス・移行・保守費を別枠で確認します
開発ツールの料金と開発会社の費用は分けて見積もります。エンバカデロの2026年4月1日適用価格では、Delphi 13 Professionalの保守1年付きが税別23万円、Enterpriseが56万円、Architectが86万円です(出典: エンバカデロ・テクノロジーズ「エンバカデロ製品価格表」、2026年)。これは開発者1人分のIDEと保守の価格であり、要件定義、設計、開発、テスト、移行、インフラ、運用保守を含みません。必要なエディションと開発者数、RAD ServerやDBなどの追加ライセンスを分けて確認します。
ランニングコストには、DelphiやDBの保守更新、クラウドやサーバー、監視、バックアップ、脆弱性対応、問い合わせ、障害対応、軽微改修を含めます。業務システムの保守は初期開発費の10〜20%程度をたたき台にする考え方がありますが、対応時間、対象範囲、含まれる改修量によって変わるため、年額だけで判断しません。移行後に旧環境を並行稼働させる期間、教育、データクレンジング、切り戻し訓練も別項目で計上してもらいます。
契約書で変更・検収・知財の扱いを定めます
契約書では、対象範囲、前提条件、成果物、納期、検収期間、瑕疵や不具合への対応、仕様変更の手続き、遅延時の連絡、再委託、秘密保持、個人情報、知的財産権、ソースコードの利用権、損害賠償の範囲を確認します。請負では、検収基準が曖昧なまま納期だけを固定しないことが大切です。準委任では、作業報告と体制、時間外対応、成果物の著作権を明確にします。
追加要望が出たときは、口頭のまま作業を始めず、変更内容、影響する画面・データ・テスト、追加費用、納期への影響を双方で承認します。検収は画面が表示されることだけでなく、権限、帳票、性能、データ件数、障害時の復旧、操作手順、再ビルドの可否まで確認します。業務システムの発注では、安い金額よりも、後から比較と説明ができる契約の透明性を優先します。
Delphiの委託先選定と見積比較のポイント

Delphi対応を掲げる会社でも、得意分野は異なります。現行Delphiの保守、古いバージョンの移行、業務アプリの新規開発、Delphi/400とIBM iの連携、.NETやWebへの再構築では、必要な経験が変わります。会社名や言語名だけで選ばず、今回のシステムと近い資産・業務・移行経験を、担当者の説明と成果物のサンプルで確認します。
委託先への質問で実力を確認します
候補会社には、Delphi 7やXEなどの旧版をどこまで読めるか、現行版への移行でBDEや第三者コンポーネントをどう扱うか、VCLとFireMonkeyの使い分け、64ビット化の経験、SQL ServerやOracleなどのDB移行経験を質問します。Delphi 13.1ではWindows on Armのネイティブコンパイラ、最新のモバイルプラットフォーム対応、VCLとFireMonkeyの品質改善が案内されています(出典: Embarcadero「RAD Studio 13.1 Florence 提供開始のお知らせ」、2026年)。新機能を使えるかだけでなく、現行資産を安全に更新する検証方法を聞くことが重要です。
また、担当するエンジニアが提案後も参加するか、現行調査を誰が行うか、業務担当者との打ち合わせ頻度、テストと移行を誰が担うかを確認します。「Delphiに詳しい」という回答だけでなく、過去案件で作成した設計書、テスト仕様、移行リハーサル、保守引き継ぎの実例を説明できる会社を選びます。IBM iやRPG資産がある企業では、Delphi/400、RPG、5250画面の経験を別々に確認します。
公開事例は進め方と体制を読み取ります
実案件の確認では、金額が公開されているかだけでなく、対象範囲、期間、既存ロジックの再利用、利用者側の体制、移行後の保守体制を見ます。ミガロ.が公開する日綜産業の事例では、出荷・返却・レンタルの主要基幹システムを2017年から段階的に開発し、2023年にプロジェクトが終了しました。Delphi/400を使い、RPGのロジックを活かしながらGUI化を進め、日綜産業側も開発に加わって保守できる人材を育てています。
同事例では、日々利用するアプリケーションの約7割以上が新しいGUI画面へ移行したと報告されています(出典: ミガロ.「日綜産業株式会社 RPGのビジネスロジックを流用しユーザー・インターフェースを刷新」、2024年公開)。費用は公開されていないため推測してはいけませんが、既存ロジックを活用し、利用頻度の高い領域から段階的に進め、発注側も保守に参加するという進め方は、Delphiのシステムを外注する際の具体的な検討材料になります。
見積書は同じ条件と工程別内訳で比較します
相見積もりでは、まず同じRFPと現行資産一覧を渡し、各社の前提条件を揃えます。その上で、要件定義、基本設計、詳細設計、開発・単体テスト、結合・総合テスト、データ移行、教育、インフラ、ライセンス、保守を工程別に比較します。2026年の見積解説でも、開発一式ではなく工程・人月・付帯費用を分け、総額ではなく内訳の透明性を見ることが推奨されています(出典: イー・ジーシステム、2026年)。
極端に安い見積もりは、要件の解釈が狭い、テストが薄い、データ移行が別料金、保守が含まれない、調査を省略している可能性があります。反対に高い見積もりでも、何人月で何を作るかが不明なら比較できません。各社へ、含むもの・含まないもの、想定する画面数と帳票数、テストデータ、移行対象、受け入れ条件、追加変更の単価、保守の応答時間を表形式で示してもらいます。
提案評価は価格だけで決めず、技術適合性、業務理解、移行リスクへの説明、担当者の経験、開発体制、セキュリティ、納品物、保守継続性を総合して行います。最終候補には、代表画面または代表帳票の技術検証を依頼し、見積もりの前提と実際の成果物に差がないかを確認します。必要であれば、評価表に配点を設定し、社内の業務部門と情報システム部門が同じ基準で比較できるようにします。
よくある質問(FAQ)

最後に、Delphiのシステムを発注・外注するときに特に多い質問へ回答します。いずれも、委託先へ相談する前に社内で整理しておくと、調査範囲と見積もりの前提を合わせやすくなります。
古いDelphiでも外注できますか?
外注できますが、Delphiのバージョン、コンポーネント、DB、ソースコード、ビルド環境、テスト資産を確認してから依頼します。Delphi 7やXEであっても、現行環境で再現できるとは限らないため、最初に現行調査や代表画面のPoCを発注し、改修可能性と移行方針を確認すると安全です。
Delphiのシステムを外注する費用はいくらですか?
小改修は50万〜300万円程度、新規の部門向け業務アプリは300万〜1,000万円程度、中規模の販売・在庫・受発注システムは500万〜2,000万円程度が初期検討のレンジです。Delphiのバージョンアップ、データ移行、複数拠点、外部連携、並行稼働、教育を含むと、数千万円以上になる場合もあります。公的なDelphi専用統計ではないため、RFPと現行調査に基づく個別見積もりで確定します。
Delphiに強い開発会社はどう選びますか?
Delphiの対応実績だけでなく、今回の業務領域、旧版の解析、DB・帳票・外部機器連携、移行、保守、引き継ぎまで経験があるかを確認します。公開事例では、ミガロ.のDelphi/400による日綜産業のように、既存ロジックを活用しながら利用者側も保守へ参加した進め方があります。提案時の担当者が開発・保守にも関わるか、成果物と相見積もりの前提を説明できるかを確認して選びます。
まとめ

発注前に決めること
Delphiのシステムを発注・外注するときは、最初に現行資産を棚卸しし、現行保守、段階的なモダナイズ、別技術への再構築、パッケージ併用の選択肢を比較します。発注形態は、要件と成果物が固まっている部分には請負、調査や保守のように作業量が読みにくい部分には準委任、判断に必要な調査には二段階発注を使い分けます。
見積比較で確認すること
RFPには、Delphiのバージョン、VCL・FireMonkey、第三者コンポーネント、DB、ソースとビルド環境、画面・帳票・連携、非機能要件、セキュリティ、移行、納品物を記載します。見積もりは総額だけでなく、調査・要件定義・設計・開発・テスト・移行・教育・ライセンス・保守の内訳と前提条件をそろえて比較します。古いDelphiを残すかどうかは、技術の新旧だけでなく、業務資産、利用形態、セキュリティ、人材、移行リスク、将来の運用費を合わせて判断することが大切です。
委託先選びでは、Delphiの実績数よりも、今回の資産を読める担当者、業務を理解する体制、移行とテストの方法、ソースとビルド環境の引き渡し、契約終了後の保守継続性を確認します。まずは代表画面と代表データを対象に現行調査やPoCを依頼し、業務を止めない段階的な発注計画へ落とし込むことが、費用と品質の両方を管理しやすい進め方です。
▼全体ガイドの記事
・Delphiのシステム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。
