Apache Derbyのシステム開発は、現行資産を整理し、継続・移行・再構築のどれにするかを選んだうえで、要件整理から定着までの6つのフェーズを順に実行します。Derbyは退役済みのため、この流れで退役後の保守リスクを管理します。
▼全体ガイドの記事
・Apache Derbyのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Apache Derbyのシステム開発で最初に押さえる全体像
Apache Derbyの開発では、作るシステムの中身に加えて、今後もDerbyを使い続けるかどうかを決める必要があります。新規と既存のシステムでは、確認すべきリスクと用意する成果物が異なります。そのため、相談前に構成やJavaのバージョンを整理し、利用者数やデータ量、復旧条件も書き出しておくと、見積もりの精度が上がります。
2026年時点のApache Derbyの利用状況
Apache Derbyの配布物は利用できますが、プロジェクトは退役済みです。
公式Downloadsページによると、2025年10月10日に退役が決議され、プロジェクトは読み取り専用になりました（出典: Apache Derby Downloads、2025年）。
Derbyでは、開発、バグ修正、新しいリリースは終わり、ダウンロードは現状有姿で提供されています。
- 新規開発：指定理由を確かめたうえで、無条件には採用しない
- 既存資産：対応JDKと責任者、移行期限を決めて、短期利用にとどめる
指定理由が互換性や配布物の軽さ、ライセンス条件、オフライン動作のどれかなら、代替のRDBMSでも要件を満たせる可能性があります。
既存資産を維持する場合は、脆弱性対応の責任者と移行期限を発注側と開発会社で合意し、限定的な延命計画として扱います。
EmbeddedとNetwork Serverの選び方
構成は、接続するJava仮想マシンや端末の範囲に応じて選びます。
- Embedded：1つのJava仮想マシン内で動くため、ネットワーク不要の単一端末やテスト向け
- Network Server：別のJava仮想マシンや端末から接続できる
Embeddedは、アプリが止まるとDBも止まりやすいため、複数サーバーや複数利用者の高可用性設計には向きません。
Network Serverは、DRDAドライバーを使って遠隔から接続できます（出典: Apache Derby 10.17 API Documentation、2026年確認）。
Network Serverでは、認証、TLS、権限の設計が欠かせません。ファイアウォールや監視、バックアップも合わせて設計し、停止許容時間と運用体制をもとに判断します。
Apache Derbyのシステム開発の進め方
開発は6つのフェーズに分けて進めると、抜け漏れを確認しやすくなります。フェーズは、要件整理から定着まで、この順で並んでいます。Derbyは退役しているため、設計に入る前に、継続利用にするか移行するかを決めておく必要があります。
各フェーズには承認条件と成果物を決めておき、次の工程に進む前に判断を固めます。
フェーズ1：要件整理による現行資産と非機能要件の把握
要件整理では、業務の目的と現行資産を確かめ、非機能条件と移行後の運用方針も見ていきます。
- 業務範囲：担当者、登録データ、帳票の出力時点
- 現行資産：既存環境の情報を集める
- 非機能要件：性能、稼働、復旧、セキュリティの数値化
- 将来方針：更新期限、停止条件、移行時期、担当者の取り決め
「在庫管理」のような抽象的な表現では作業の中身が見えないため、業務を操作の単位まで分けて確かめます。
既存資産は、ソースコードやDDL、JDBCドライバーを中心に調べ、DerbyとJDKの版も確かめます。設定や起動停止の手順、バッチ、外部連携は一覧にし、障害履歴も確認します。資料がなければ、担当者へのヒアリングと実機調査を先に行います。
非機能条件は数値で定めます。同時接続数や1日あたりの処理件数、データ量と年間増加率などが対象です。
バックアップ頻度やRTO（目標復旧時間）、RPO（目標復旧時点）を確認します。個人情報の扱いや監査ログ、障害通知も確かめます。
チェックリストには、JDKの更新期限や停止可能時間、許容データ損失を書き込みます。復旧担当者や3年後の移行方針も含めます。要件が曖昧なままだと、高可用性や移行作業が後から加わり、費用と期間が膨らみます。
フェーズ2：継続利用・移行・再構築の比較と選定
この段階では、Derbyの利用を前提にせず、現行資産に合う案を比べます。
- 限定継続：既存のDerbyを限られた期間だけ使う
- 段階移行：PostgreSQLなど保守中のRDBMSへ、段階を踏んで移す
- 再構築：業務アプリやパッケージも含めた刷新
各案は初期費用だけでなく、3〜5年の保守費用でも比べます。JDK更新や脆弱性調査、障害対応、将来移行の費用も含めます。
開発会社には、JavaとJDBCの調査力や移行実績、移行先の設計力があるかを確かめます。SQL方言やデータ型の差分分析ができるかも見ます。そのうえで、バックアップ復元試験や切替リハーサル、運用引き継ぎの範囲も確かめます。
提案依頼書には、DerbyのバージョンやJDK、データ容量を記載します。テーブル数と主要SQLも書き、外部連携と目標停止時間も加えたうえで、各社へ同じ条件を示します。
Derby専用の現行サポートを公式に確認できない場合は、その事実を各社に伝え、対応の可否を契約前に確かめます。
フェーズ3：交換可能なデータアクセスの設計と開発
設計・開発では、継続利用のための運用設計と、移行しやすいデータアクセスの実装を進めます。
- 継続利用：安全な接続や権限、監視、復旧の設計
- 将来移行：DB固有の差分を整理し、交換可能な層を作る
継続利用では、EmbeddedかNetwork Serverかの構成を決めたうえで、認証、権限、通信経路を定めます。ログや容量監視に加えて、バックアップとリストアの手順も決めておきます。
Network Serverでは、初期設定の平文通信を避け、TLSやネットワーク分離を設計します。
未設定時の平文通信、広い権限、テーブルの無制限な増大は、公式ガイドで注意点とされています（出典: Apache Derby Security Guide、10.17）。
移行を見込むなら、SQLの呼び出しを分散させず、データアクセス層を整理します。予約語やNULL、日付・時刻の扱いを一覧にします。
採番やLOBに加え、トランザクション分離と例外コード、インデックスも一覧に加えます。そのうえで、移行先へ変換できる構造にします。
10.17.1.0は、Java SE 21以上とJDBC 4.2に対応し、Java 21未満は対象外です（出典: Apache Derby 10.17.1.0 Release Notes、2023年）。
既存環境がJava 8やJava 11の場合は、JDK更新とDB移行を同時に行うか、段階を分けるかを決めます。
フェーズ4：データ互換性と業務結果のテスト
テストでは、データ互換性と業務結果、非機能要件の達成を確かめます。単体テストだけで終わらせません。
- 移行データ：変換後の値と業務結果が一致するか確かめる
- 非機能：性能、障害時の復旧、監視の動作を試す
移行案件では、スキーマや件数、主キーと外部キーを確認します。NULLや文字コード、日付、金額の値も、移行元と移行先で照合します。LOBやインデックス、権限、トランザクションも見ます。
同じ入力で、画面や帳票、CSVの出力を照合します。外部APIとバッチも対象に加えます。
件数が合っていても、桁あふれや日付のタイムゾーン差が起きることがあります。そのため、代表データと境界値を使います。
非機能テストでは、ピーク時の同時接続数や検索時間、更新競合を確認します。長時間稼働や容量増加、ネットワーク断やプロセス停止も試します。加えて、バックアップやリストア、監視通知の動作も確かめます。
RTOが4時間なら、障害を発生させて4時間以内に復旧できるかを測ります。結果は、仕様書に合否基準やデータ、実施者、証跡を記録します。未解決事項の扱いも書き残し、口頭の確認だけで本番に進まないようにします。
フェーズ5：切替とロールバック条件の明確化
稼働時は、事前確認、切替作業、ロールバックの条件を一体で定めます。
- 事前確認：不具合、移行件数、バックアップ、体制の確認
- 切替計画：全量・差分移行から業務確認までの順序
- 復帰条件：戻す期限と対象データ、判断責任者
判定会議では、利用者アカウントや監視、連絡網、作業手順も確かめます。作業票には、実行者と承認者、中止条件を記します。
移行は分単位で計画します。全量移行と直前の差分移行から始め、アプリ停止と接続先変更、疎通と業務確認へと順に進みます。
旧環境をどの期間残すか、二重更新をどう防ぐか、利用者にどう知らせるかも決めておきます。さらに、主要業務の照合不能、RTO超過の見込み、個人情報ログの欠落を、中止の基準にします。
小規模なPoCでも本番と同じ手順で試すと、想定外の作業を早く見つけられます。
フェーズ6：運用担当者への引き継ぎと将来移行の備え
稼働後は開発会社から運用担当者へ引き継ぎ、日常運用と将来移行を続けられる状態にします。
- 納品・引き継ぎ：構成、設計、復旧、監視、開発情報を共有する
- 継続点検：環境、脆弱性、容量、復旧、移行計画を見直す
納品物には、構成図やER図、DDL、設定値を含め、JDBC接続情報の管理方法も記します。バックアップと復元、監視、障害時の一次対応は、運用担当者へ引き継ぎ、問い合わせ先も示します。
また、テスト仕様書とソースコード、ビルド手順も渡します。パスワードは文書に平文で残さず、保管場所と更新手順を示します。
Derbyを継続する場合は、Javaの版やOS、ライブラリを定期的に点検します。脆弱性や容量、バックアップ復元も確かめ、移行計画を更新します。
月次では、障害件数や処理時間、容量増加、バックアップ成功率を確かめ、四半期ごとに代替DBのPoCや移行準備を見直します。担当者が判断と復旧を再現できる状態になれば、定着したといえます。
Apache Derbyのシステム開発にかかる費用相場とコストの内訳
Apache Derby単体の開発費や保守費を示す公的な価格表はありません。そのため、以下は2026年の一般的な業務システム相場に、Java、JDBC、データ移行の作業を加えた参考レンジです。
この金額はDerbyの公式価格ではなく、概算です。画面数やデータ量、外部連携によって変わり、可用性や移行の難易度も影響します。
規模別の初期費用の目安
初期費用の目安は、規模や移行内容によって異なります。
- 業務システム相場：小規模100万〜300万円から大規模800万円〜数千万円
- Derby新規案件：PoC 50万〜150万円、社内向け150万〜500万円
- Derby移行・刷新：移行300万〜1,200万円、基幹連携や高可用性を含む刷新1,000万〜3,000万円超
一般の業務システム相場では、中規模が300万〜800万円とされています（出典: 「業務システム開発の費用相場｜2026年最新」、2026年）。
Derby案件の金額は、類似のJava業務システムから推定したもので、確定した金額ではありません。なお、部門向けシステムは500万〜1,500万円程度です。
移行額には、現行調査やSQL差分の修正、データ変換を含む想定です。並行稼働や切替リハーサルも含みます。
データ量やテーブル数が少なくても、古いJDKや資料不足、複雑なバッチがあると、調査とテストの工数が増えます。また、停止できない業務がある場合も、工数の増加につながります。
費用の工程別内訳
見積もりでは、開発や移行の作業費と、運用や将来対応にかかる費用を分けて確認します。
- 開発・移行：調査、設計、実装、移行、各種テスト、切替
- 運用・継続：インフラ、監視、保守、脆弱性評価、将来移行
主な内訳は、現行調査と要件定義、方式選定です。画面とAPIの設計やDB設計、Javaアプリの開発または改修も含まれます。
データ移行や各種テスト（単体・結合・総合、性能・障害）も含みます。インフラ構築やセキュリティ設定に加えて、切替や教育、保守も内訳に入ります。
Derbyを継続する場合は、調査と運用設計の比重が高くなります。移行する場合は、SQL差分やデータ変換、検証、切替の比重が高まります。
OSSのライセンス費は原則として不要ですが、人件費やVM、ストレージにはかかります。バックアップや監視、ログ保管、脆弱性評価も発生します。加えて、退役後はJDK更新や代替DBへの準備もTCOに含め、3〜5年の総費用を比べます。
ランニングコストと保守費用の比較
運用費と保守費は、含める環境や対応範囲によって変わります。
- 小規模なクラウド運用：月額5万〜30万円程度の仮説レンジ
- 監視・冗長化を含む運用：月額30万〜100万円以上の可能性
- 年間保守：初期開発費の10〜20%を目安にする考え方
小規模運用費は、VMやストレージを含めた想定です。バックアップや監視、ログ保管も含みます。24時間監視や冗長化、休日対応、複数環境を加えると、費用が高くなる可能性があります。
いずれも一律の料金ではなく、予算を比べるための仮説です。実額は、リージョンやインスタンス、保存期間、監視方法によって見積もります。
年間保守の目安は、Derbyの公式料金ではありません。対応が問い合わせだけか、障害対応や脆弱性調査まで含むかによって変わります。JDK更新や性能改善、移行準備まで入るかでも、差が出ます。
見積書では、月次点検や対応時間、一次切り分け、復旧作業を分けて書きます。加えて、追加開発の単価や終了時の引き継ぎも、別の項目にします。
Apache Derbyの見積もりで確認すべきポイント
見積もりの妥当性は、技術者の人数だけでなく、調査と不確実性をどこまで含むかで変わります。「開発一式」や「データ移行一式」とだけ書かれていると、追加費用の範囲を判断できません。
依頼時には、資料の有無と前提条件を伝えます。そのうえで、作業、成果物、除外事項を分けて示してもらいます。
見積書に反映する要件と現行調査の範囲
見積書では、共有する現行情報と調査の担当範囲を明らかにします。成果物や承認事項も、あわせて書いておきます。
- 共有情報：業務やシステムの一覧、データ量、環境、障害履歴
- 成果物：業務・機能・非機能要件、構成、移行・テスト・運用方針、概算日程
- 承認事項：Derby採用、移行時期、継続利用時にどこまでを誰が受け持つか
一覧は、業務や利用者・権限、画面、帳票の単位で作ります。外部連携やバッチ、テーブルも洗い出し、DerbyとJDKの版も伝えます。
資料がなければ、発注側で作るか、開発会社の調査に含めるかを決めます。調査を省くと、移行差分が見つかった後に増額につながります。
採用や移行時期の理由を承認記録に残しておけば、担当者が代わっても計画がぶれにくくなります。
複数社の同一条件での比較
各社の提案を、技術領域をまとめる力や複数案の説明、共通条件での総額で比べます。
- 提案力：技術と業務運用を一つの計画にまとめられる
- 選択肢：継続・移行・再構築の前提とリスクを示せる
- 比較条件：同じ資料で費用、期間、体制、納品、保守を回答する
各社がJavaや移行、クラウドを含めて一つの計画にまとめられるかを見ます。PoCで検証する項目も確かめます。
RFPやサンプルデータ、主要SQLを各社へ渡し、同じ順で回答してもらいます。画面一覧や目標停止時間も、同じ資料に含めます。
見積もりでは、人月単価に加えて、調査やテスト、移行リハーサル、管理工数も確かめます。
復元試験や切替後支援が別料金なら、総額が高くなる場合があります。
契約と納品物によるベンダーロックインの防止
契約では、成果物の引き渡し、権利と引き継ぎ、退役後のセキュリティ対応を確かめます。
- 成果物：設計、テスト、運用、移行、教育に必要な資料を受け取る
- 契約条件：コードの権利、OSS、リポジトリ、ビルド、引き継ぎを定める
- 安全管理：脆弱性の調査担当と対策を決めておく
納品対象には、ソースコードやDDL、ER図、設計書を含めます。テスト仕様と証跡、運用手順書、構成情報も対象です。さらに、移行スクリプトやバックアップ手順、教育資料も納品に含めます。
成果物がなければ、別の会社へ移るときに再調査費が発生しやすくなります。契約書には、権利と第三者OSSのライセンスを記します。リポジトリやビルド環境、退任時の引き継ぎも、同じ契約書に含めます。
新しい脆弱性が見つかった場合の調査担当や、修正版がない場合の判断方法も、あらかじめ決めておきます。
認証や最小権限、TLS、ファイアウォールを確かめます。監査ログや容量監視、プロシージャ権限、バックアップ暗号化も見ます。
通信暗号化はIPAのTLS暗号設定ガイドラインなどを参照し、JavaやOSのサポート期間も見ます。
Apache Derbyのシステム開発でよくある質問
よくあるのは、「今動いているから問題ないか」「費用はいくらか」「移行をどこから始めるか」といった質問です。退役後の状況を踏まえて、判断材料を整理します。
Apache Derbyで新規の業務システムを開発しても問題ありませんか？
無条件での採用はおすすめしません。配布物は利用できますが、Derbyは2025年10月に退役し、開発とバグ修正も終わっています。
保守責任や将来の移行費用も含めて、PostgreSQLなど保守中のRDBMSと比べます。Derbyが必要な場合は、利用期間、セキュリティ対策、移行期限を決めます。
既存のApache Derbyシステムはすぐに停止すべきですか？
まずは現行資産と業務への影響を調べ、延命期間と移行計画を決めます。ただし、単一JVMで限定的に使い、外部に公開しておらず、復元と運用体制を確認できる場合は、短期利用が合理的なこともあります。
個人情報や複数拠点、停止できない業務がある場合や、JDK更新の必要性や脆弱性対応の不足がある場合は、早めに代替DBのPoCを始めます。
Apache Derbyから別のデータベースへ移行する場合は何から始めますか？
まずは、DerbyとJDKの版、JDBCドライバー、保存場所を一覧にします。テーブル・インデックス・制約や主要SQLを洗い出し、バッチと外部連携も確かめます。データ容量や停止許容時間も確認します。
移行先候補では、スキーマ変換や代表データ、主要業務を検証します。性能やバックアップ復元も、同じ候補で確かめます。JARの差し替えで済むと見込まず、差分を先にまとめてから本開発を見積もります。
Apache Derbyのシステム開発費を抑える方法はありますか？
要件を絞り、現行調査とPoCで不確実性を減らす方法が有効です。そのうえで、画面や帳票、権限、外部連携などに優先順位をつけます。移行やテスト、教育も、同じ基準で並べます。
全機能を一度に作らず、重要な業務から段階的に導入します。ただし、バックアップ復元やセキュリティ、切替リハーサルを削ると、稼働後の障害費用が増えるため、削減の対象にはしません。
まとめ：6フェーズとTCOによるApache Derbyの進め方の決定
要件整理で現行資産と非機能要件を確認し、継続・移行・再構築のどれにするかを選びます。その後、設計・開発、テスト、稼働、定着へと進みます。
2026年時点でDerbyは退役済みです。構成だけでなく、JDK更新や脆弱性、バックアップ、運用者、将来移行も判断材料にします。
着手前に確認するチェックリスト
着手前には、DerbyとJDKの版、構成、データ量を確かめます。そのうえで、増加率や同時接続数、停止許容時間を押さえます。RTO・RPO、個人情報、外部連携も確認します。
バックアップの復元や監視、どこまでを誰が受け持つかも点検します。見積書には、調査や要件定義、移行、テストが含まれるかを確かめます。切替や教育、保守、納品物も含まれているかを見ます。
結果を発注者と開発会社で共有し、未確認事項はPoCの課題として残します。
最初の一歩は現行調査と小規模PoC
まずは現行調査と小規模なPoCから始め、大規模な作り直しは、その結果を見てから判断します。代表データと主要業務を使って、継続利用の安全性や移行先との互換性を測ります。
必要なテスト工数と切替時間も確かめます。初期費用だけでなく3〜5年のTCOを比べ、利用者が運用できる計画を選びます。
▼全体ガイドの記事
・Apache Derbyのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。