H2 Databaseのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

H2 Databaseのシステム開発は、要件整理から定着まで6フェーズで順に進みます。各フェーズで成果物を確かめると、稼働後の手戻りを抑えられます。

先にH2の役割と本番利用の判断を確かめてから進めます。全体像はH2 Databaseのシステム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・H2 Databaseのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

H2 Databaseのシステムの全体像

H2 Databaseは、Javaで実装されたオープンソースのリレーショナルデータベース管理システムです。

ここで扱うのは、H2を保存層に組み込んだJava業務システムや、Spring Bootの開発・テスト用DBです。業務システムには、画面やAPI、業務ロジックが必要です。さらに、認証・認可、帳票、外部連携、監視、バックアップも欠かせません。

データ保存層としてのH2と業務システム全体の範囲

たとえば顧客管理システムでは、データの保存だけでなく、業務機能と運用も決めておく必要があります。

• 業務機能：顧客テーブルや重複防止の入力ルール、閲覧権限、更新履歴、CSV出力、メール通知、削除依頼への対応を設けます。
• 業務・見積もり範囲：確定業務や変更権限はアプリと運用で決め、金額はシステム全体を対象に算出します。

H2公式は、標準SQLやJDBCに加え、複数接続、トランザクション、行ロックを案内しています。外部キー、ビュー、トリガーも挙げられています。

H2公式の資料では、ユーザー・ロール管理や暗号化ファイル、SSLの機能も案内されています（出典：H2 Database公式「Features」、2026年8月確認）。

ただし、機能があっても、24時間稼働や災害復旧、監査要件が自動で満たされるわけではありません。そのため、非機能要件を設計書と運用手順に落とし込む必要があります。

組み込み・サーバー・混在の接続モードと用途の使い分け

接続方式は、利用環境と運用条件に合わせて選びます。

• 組み込み：同じJVMからJDBCで接続します。構成が小さく起動も速いため、ローカル開発や単体テスト、単一プロセスの配布に向きます。
• サーバー：別プロセスや別ホストへTCP/IPで接続し、複数のアプリや端末から使う方式です。
• 混在：最初のアプリは組み込みで開き、他プロセスからの接続も受け付けます。

インメモリ型は、起動時に初期データを作り、終了時に破棄できます。そのため、テストを何度も繰り返せます。一方、ファイル型は終了後もデータを保持するので、バックアップとロックの設計が必要です。

サーバー方式では、ネットワーク、認証、TLS、障害監視の準備が欠かせません。選定時は利用者数だけでなく、同時更新、停止許容時間、復旧手順、将来のDB移行も比べます。

要件に基づく本番利用の判断

本番DBは、利用環境と可用性などの要件に合わせて決めます。

• 小規模・閉域：単一端末やDBサーバーを置きにくいエッジ環境で、利用者とデータ量が限られるなら、組み込みH2が候補になります。
• 複数拠点：多数の利用者が接続するなら、PostgreSQLやMySQLを本番に、H2をテスト用にする構成が有力です。
• 高可用性：厳しい可用性や災害対策が求められる場合は、別のDBを本番にする構成が候補に上がります。
• 高度なDB機能：DB固有の高度な機能を使う場合は、別のDBを本番にする構成が適しています。

H2公式は、敵対的な環境で動かす設計ではないため、信頼できない接続元へ公開しないよう注意しています（出典：H2 Database公式「Securing your H2」、2026年8月確認）。

H2 TCPサーバーやH2 Consoleは、インターネットへ直接公開せず、localhostか閉域網に限り、管理者だけが踏み台経由で使います。

個人情報や会計情報を扱う場合は、認証と秘密情報の管理、監査ログ、バックアップの保護も確かめておきます。

H2 Databaseのシステム開発の進め方と6フェーズ

まずは業務目的と将来の運用を決めます。そのうえで、H2の接続設定や技術方式を選びます。

各段階の成果物と次へ進む条件を決めておくと、利用者数や本番DBとのSQL差分、復元不能などによる手戻りを抑えられます。小規模な案件でも、判断は一覧表や議事録に残しておきます。

1. 要件整理：H2を使う目的と業務の合格条件

「Javaで作る」「H2を使う」という技術要件と、解決する業務課題は分けて整理します。

• 対象：利用者や拠点、データ量、検索・帳票、外部連携、保存期間を洗い出します。
• 業務目標：紙の申請を半日に短縮するのか、在庫差異を月1回から毎日に減らすのかで、必要な機能が変わります。
• 件数・利用条件：1日あたりの登録件数、総レコード数、ピーク時の同時利用者数、検索条件を確認します。CSV・帳票、外部API、利用時間、保持年数も見ます。
• 非機能要件：目標応答時間、許容停止時間、目標復旧時間（RTO）、許容できるデータ損失時間（RPO）を決めます。

必要な画面や承認、履歴、通知、権限は、決めた業務目標に応じて変わります。

要件整理で作るものは、業務フロー、機能一覧、データ項目一覧、非機能要件、優先順位、概算日程です。

2. 選定：接続モードと本番DBの方針の比較

要件に応じて、H2の使い方と本番DBを比べます。

• テスト：開発者が個別に起動するなら、インメモリ型が候補になります。
• 単体配布：単体のアプリでは、組み込みのファイル型を候補に挙げます。
• 複数接続：複数のアプリや端末から使うなら、サーバーまたは混在モードを比べます。

H2を本番に使うか、PostgreSQLなどを本番にしてH2をテストに限るかは、可用性や同時接続、バックアップ、監視、移行方針を含めて決めます。

選定表には、データ量、同時接続数、SQL方言、トランザクション、復旧方法を書きます。さらに、バックアップ方式、監視性、運用スキル、将来の移行先も並べます。

互換モードは、他DBに近いSQLを書く助けになります。ただし、型や予約語、NULL、関数、索引、トランザクションの挙動が、本番DBと完全に一致するとは限りません。移行の可能性があるなら、早い段階で本番DBを使った結合テストを行います。

3. 設計・開発：環境ごとに分けた接続先の実装

まず、画面・API、業務ロジック、テーブル、主キー・外部キーを設計します。さらに、索引や権限、ログ、バックアップも決めます。

• 接続先の分離：開発・検証・本番の環境ごとに分け、Spring Bootのプロファイルや環境変数で切り替えます。
• 誤接続の防止：設定ファイルを分け、起動時に接続先を表示して、インメモリDBの情報が混入していないかを見つけます。

SQLの初期化やマイグレーション、シードデータは、いつでも同じ形で再現できるようにしておきます。JPAの自動DDLだけに頼ると、環境ごとにスキーマが変わるおそれがあります。

テーブルの変更は版で管理し、ロールバック、初期データ、文字コード、時刻の扱いを確認します。

個人情報を保存する場合は、PreparedStatementや最小権限、環境変数での秘密情報管理、操作ログのマスキングも設計に含めます。

4. テスト：H2と本番DBの差分の検証

テストは段階ごとに分け、H2と本番DBの差や異常時の動作を検証します。

• テスト段階：単体、結合、総合、受入テストに分けます。
• DB差分：本番がPostgreSQLやMySQLなら、主要SQL、制約、NULL、日付、ページング、同時更新を本番DBで確かめます。
• 異常系：同時更新、重複登録、途中切断、長時間クエリを想定します。さらに、ロック待ち、プロセス異常、容量不足も含めます。
• 復旧・変更：復元、データ移行、版更新も合格条件に含めます。

H2のインメモリ環境は速く、テストデータも作り直しやすいものです。一方で、本番DBとの完全な互換性までは保証されません。

Spring Boot公式は、H2 Consoleを開発用途として案内しています。本番では有効化しないよう注意もしています（出典：Spring Boot公式「SQL Databases」、2026年8月確認）。

実行条件、データ件数、期待値、実測値、未解決課題、再テスト日を記録します。そのうえで、現場の担当者が帳票や例外処理を確かめる受入テストを早めに行い、稼働直前の仕様追加を抑えます。

5. 稼働：移行・バックアップ・切り戻しの準備

移行と復元、切り戻しは、本番稼働の前に確かめておきます。

1. 移行データを確定し、不要データや名寄せ、欠損値、文字コード、日付・金額の変換ルールを決めます。
2. 移行リハーサルを少なくとも1回行い、件数、業務キー、合計金額、履歴、添付ファイル、権限を照合します。
3. H2ファイルをコピーしただけで済ませず、アプリから参照できる状態かを検証します。
4. バックアップの頻度、保存先、暗号化、世代数、アクセス権、復元担当者を決めます。
5. 「何分停止したら旧システムへ戻すか」「何件の不整合が出たら中止するか」を決め、連絡網と判断者も記載します。

H2 2.4.240は2025年9月22日に公開された版で、暗号化DBのコンパクションなど複数の修正を含みます（出典：H2 Database公式GitHub Releases、2026年8月確認）。

採用する版を固定し、Java、ORM、Spring Boot、既存SQLとの互換性を確かめてから、本番に反映します。

6. 定着：運用担当者が迷わない仕組みづくり

稼働後は、利用定着と運用の見直しを続けます。

• 利用支援：操作説明会、簡易マニュアル、よくある質問、問い合わせ窓口、障害時の連絡先を用意します。
• 利用状況の確認：稼働後の30日・60日・90日の時点で、利用率や入力漏れ、処理時間、エラー、問い合わせ件数を確認します。
• 改善：確認結果をもとに、未利用の機能や入力しにくい画面を見直します。

保守契約では、監視時間や一次受付、復旧目標、月次の改修枠を分けて記載します。さらに、H2やJavaの更新、脆弱性対応、バックアップ確認、将来のDB移行調査も、別の項目として書いておきます。

H2を使い続ける場合も、データ量と同時利用の変化を半年または年1回確認します。要件を超えたときに備えて、接続方式や本番DBの変更、移行候補と手順を平時から文書にしておきます。

H2 Databaseのシステム開発費用相場とコストの内訳

H2本体のライセンス料と業務システムの開発費は、分けて考えます。H2はMPL 2.0またはEPL 1.0のデュアルライセンスで、商用アプリに組み込める無償のOSSです。

ただし、改変や再配布のときは、表示やソース公開などの条件を確認する必要があります。ライセンス費が0円でも、要件定義やJava開発、テスト、クラウドの費用は発生します。移行や監視、保守の費用もかかります。

規模別の初期費用の幅：20万円から1.5億円超まで

ここに示す金額は、業務システム一般の相場とH2対応案件の公開例をもとにした、2026年時点の編集用推定レンジです。H2単体の価格表ではありません。

金額は、要件や利用者数、データ量によって変わります。さらに、連携や移行、可用性、保守範囲も金額に影響します。そのため、要件定義の後に再算定します。

テスト用にH2を使う場合でも、画面やAPIが増えれば、費用はDBの選択だけで決まりません。規模別の初期費用と期間、含まれる作業を確認します。

• 検証・小規模PoC：20万〜100万円程度、2〜6週間。最小画面、DB設計、テストデータ、簡易認証、環境構築を含みます。
• 社内の小規模業務システム：300万〜800万円程度、2〜4か月。要件定義、画面・帳票、CRUD、権限、バックアップ、操作説明が目安です。
• 部門横断の中規模Web業務：800万〜3,000万円程度、4〜10か月。外部API、承認、監査ログ、移行、性能・障害テスト、クラウド構築が加わります。
• 重要業務・既存連携：3,000万〜1.5億円超、8か月〜2年程度になることがあります。

このレンジは公開統計ではなく、相場情報と作業範囲から整理した推定です。特定の金額を保証するものではありません。

見積書の開発・テスト・移行・運用の内訳

案件ごとの見積もりを比べる際は、次の工数配分が目安になります。

• 要件・設計：要件定義10〜15%、基本設計15〜20%、詳細設計10〜15%程度。
• 開発・単体テスト：30〜40%程度。
• 結合・総合テスト、移行・導入：それぞれ15〜20%、5〜10%程度。

この配分はH2公式の統計ではありません。また、要件定義が薄く開発費だけ大きい見積もりでは、追加仕様やテスト不足が起きやすくなります。

H2対応企業の公開情報には、業務システムの初期導入費を合計500万円とする例があります（出典：発注ナビ掲載の株式会社ムクイル費用例、2026年8月確認）。

内訳は、要件定義・基本設計が40万円、詳細設計が80万円、設計・製造が120万円です。このほか、クラウド構築が100万円です。残りは、製造・単体テストが50万円、結合・総合・運用テストが80万円、移行・操作説明が30万円です。

この例は業務システム全体の比較材料として見るもので、H2のライセンス料や単体の価格を表すものではありません。

ランニングコストの保守とインフラの分け方

ランニングコストは、インフラ、保守内容、対応時間を分けて確認します。

• インフラ・運用：クラウド・サーバー、監視、バックアップ・ログ保管、証明書、脆弱性対応を含みます。
• 保守範囲：問い合わせ、改修、バージョンアップのほか、平日か24時間か、月の改修時間、障害対応の開始時間を確認します。
• 費用の目安：初期開発費の年15〜20%程度が起点です。初期開発費が500万円なら、年75万〜100万円、月6.25万〜8.3万円程度になります。

これは保守範囲を比べるための計算例です。ただし、組み込みH2でもバックアップや復元訓練、監視を加えると、サーバー構築費との差は小さくなることがあります。

監視やSLA、休日対応、改修枠、移行支援が付けば保守の費用は上がり、問い合わせ受付だけなら下がる可能性があります。

金額だけでなく、障害時の責任範囲も契約で明確にしておきます。

H2 Databaseのシステムで見積もりを取る際のポイント

見積もりは、開発会社のH2知識だけでなく、発注側が業務と非機能要件をどこまで伝えるかで変わります。

まず、H2を本番に使うかテストだけに使うかを明記します。利用者、データ量、接続モード、外部連携などの業務条件を、各社へ同じ前提で渡します。加えて、移行やバックアップ、RTO・RPO、保守時間の条件も示します。

RFPに書く項目：データ量・利用者・接続方式・移行条件

各社が同じ条件で見積もれるよう、RFPに業務、技術、非機能要件を記載します。

• 業務と規模：目的、対象部門、利用者数、同時利用者数、拠点数、画面数。帳票数、1日あたりの登録・検索件数、保存期間、移行元、外部システム、認証方式。
• H2と技術構成：インメモリ型かファイル型か、組み込み・サーバー・混在のどれか、バージョン、Java・Spring Boot・JPA、本番DB候補。
• 非機能要件：応答時間、同時接続数、稼働時間、RTO・RPO、バックアップ世代、監視。ログ期間、暗号化、権限、脆弱性診断、障害受付時間。

会計・取引データを扱う場合は、社内規程に加えて、電子帳簿保存法などの適用可能性も確認します。適用が未確定なら、要件定義を独立して見積もり、その後に本開発費を再算定します。

開発会社の評価：H2対応だけでなく上流から保守まで

「H2 Database対応」という検索タグだけで発注先を決めるのは危険です。そのため、上流から運用までの担当範囲を確認します。

• 開発・検証：要件整理、Java・Spring Boot・JPA、SQL互換性への対応力。
• 移行・基盤：データ移行、クラウド・ネットワーク、バックアップ復元の対応範囲。
• 運用・保護：個人情報保護と障害対応まで担当できるかどうか。

発注ナビのH2対応企業一覧には複数社が掲載されています。ただし、掲載だけでは本番実績や対応版、保守範囲は分かりません。そのため、提案の場で具体的な質問をします。

面談では、本番DBとの差分検証やバックアップ復元訓練の頻度を尋ねます。あわせて、H2 ConsoleやTCP接続の閉じ方、PostgreSQLへ移行するときに避けるSQLや型も聞きます。

製品機能の説明だけでなく、設計書やテスト計画、運用手順、契約上の責任分界まで具体的に示せる会社を選びます。

追加費用と移行リスクの責任の分け方

見積もりや運用で、追加費用や移行リスクにつながりやすい条件を確認します。

• 契約範囲：作業範囲、前提、除外項目、納品物、検収基準。変更管理、再テスト、移行の責任分界。
• 別料金の条件：帳票追加、API仕様変更、欠損修正、別DB移行、休日リリース。「要件定義後に別途見積もり」なら、再見積もりの時点も明記します。
• DB差分対策：本番DBの結合テスト、互換SQL規約、マイグレーション、性能試験を見積項目に含めます。
• 必須の運用条件：H2 ConsoleやTCP接続を外部に公開せず、バックアップを実際に復元して確かめます。

H2 Databaseのシステム開発でよくある質問

H2は軽量で始めやすい一方で、本番利用や費用、将来の移行について誤解が生じやすいデータベースです。発注前によくある質問に答えます。

H2 Databaseは本番環境で使えますか？

要件を満たせば使える場合があります。ただし、すべての本番システムに適するとは限りません。単一プロセスの配布型アプリや、利用者・データ量が限られた閉域の小規模システムでは候補になります。

多数の同時接続や厳しい可用性、災害復旧、複雑なDB固有機能が必要な場合は、PostgreSQLやMySQLを本番にし、H2をテスト用に限る構成を比べます。

H2 Databaseを使うとシステム開発費は安くなりますか？

ライセンス料や一部のサーバー構築費を抑えられる可能性はあります。ただし、開発費全体が必ず安くなるわけではありません。

費用の大半を占めるのは工数です。業務要件や画面、外部連携の工数に加えて、移行の工数もかかります。テスト、監視、保守の工数も費用に含まれます。そこで、H2のライセンス料と、Java開発やクラウド、テスト、運用費を分けて比べます。

H2をテスト用にして本番DBへ移行するときの注意点は何ですか？

SQL方言、データ型、NULL、日付、ページングの差分を確認します。さらに、制約や索引、トランザクションも差分の対象になります。

互換モードは便利ですが、本番DBを再現しきれないことがあります。そのため、開発の初期から本番DBの結合テストを行います。件数や合計値、重要キーを確認します。さらに、移行リハーサルや切り戻し、性能、接続先の分離も見ておきます。

H2 Consoleは本番環境で公開しても問題ありませんか？

原則として、本番では外部に公開しません。H2公式は、H2 Consoleを含むネットワーク公開について、信頼できない接続元へ露出させない考え方を示しています。

開発時だけ有効にし、本番では無効化するか、管理ネットワーク内の限られた経路だけで使います。TCP接続も、localhostや閉域網、接続元制限、TLS、強い認証情報、最小権限を組み合わせて守ります。

H2 Databaseのシステム開発の進め方まとめ

業務目的、データ量、同時利用者数、可用性、移行方針を整理し、そのうえでH2の使い方を決めます。

要件整理から定着までの6段階で、成果物と合格条件を確かめることが、品質と費用のぶれを抑える基本です。

無料・軽量という長所と本番運用の責任

H2は、JavaやSpring Bootとの相性がよく、組み込みやインメモリでの利用も手軽です。さらに、ライセンス費を抑えやすい点も魅力です。

無料であっても、開発費まで無料になるわけではありません。本番の可用性やバックアップ、監査、セキュリティ、障害対応は、システム全体で設計します。

テストにH2を、本番に別のDBを使う場合は、差分テストを早い段階から行います。

発注前のRFPと6フェーズの確認表

利用者数、データ量、接続モード、本番DBを1枚にまとめます。さらに、外部連携やRTO・RPO、バックアップ、H2の範囲も書き込みます。

要件定義から定着までの作業、納品物、検収条件、保守範囲は、複数社へ同じ条件で提示します。そのうえで、互換性検証や移行リハーサル、復元訓練、セキュリティ、将来の移行方針まで説明できる会社を選びます。

▼全体ガイドの記事
・H2 Databaseのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

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