Seasar2の移行費用は、規模や業務ルール、テストの範囲によって大きく変わります。目安は、移行診断が100万〜500万円程度、大規模な刷新が1億円超です。
費用の内訳と見積もりの読み方は、移行の進め方とあわせて説明します。全体像は下記の完全ガイドで確認できます。
▼全体ガイドの記事
・Seasar2のシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Seasar2の概要と費用を考える前提
Seasar2は、Javaの業務Webシステムで使われてきた軽量フレームワークとDIコンテナです。S2Containerによる依存性注入とAOPによる共通処理の分離を担います。
S2DaoやS2JDBCはデータアクセスを担い、SAStrutsやJSPは画面処理に使われます。こうした要素が組み合わさって業務システムを構成していることが多いため、フレームワークの置換作業だけで費用を見積もると、重要な業務処理を取りこぼす可能性があります。
費用に影響するSeasar2の主要構成
構成の棚卸しでは、Seasar2本体だけでなく、画面やデータアクセスにも目を向けます。バッチや帳票、外部連携まで含めて確認する必要があります。
- 画面と設定：SAStruts、S2Struts、Teeda、JSP、dicon、インターセプター
- データ処理：S2Dao、S2JDBC、バッチ、帳票、ジョブ管理
- システム連携：認証・認可、外部API、データ連携
たとえばS2DaoからMyBatisへ移す場合は、SQL変換に加えて、暗黙のマッピングや例外処理も確かめる必要があります。トランザクションの境界についても、確認が欠かせません。
特に費用を押し上げるのは、コードに明記されていない業務ルールです。締め処理や在庫引当などがその例で、休日計算や権限制御、外部システムの再送処理も含まれます。
こうした業務ルールは、画面数やステップ数からは読み取れません。そのため、現場担当者へのヒアリングや過去障害の確認、テストデータの再現を診断に含めると、追加費用のリスクを抑えられます。
EOLが費用と判断に与える影響
The Seasar Projectの公式サイトは、除外対象を除く多くのプロダクトが2016年9月26日にEOLになったと案内しています。さらに、同じ日に保守とサポートも終了したとされています（出典：The Seasar Project、2016年）。
ドキュメントやソースコード、Mavenリポジトリが公開されていても、現行のJDK、OS、APサーバー、DBや脆弱性への公式サポートが続くわけではありません。
- 保守負担：担当者の退職時の引き継ぎ、脆弱性調査、古いJavaやAPサーバーの例外対応（費用に含める対象）
- 復旧と移行時期：障害時の復旧時間と、短期延命が合理的かどうかの判断
- 先送りの費用：移行期限がない場合の、診断費用と緊急対応費用の増加
Seasar2のシステム移行・刷新の進め方
Seasar2の移行方式は、現行資産と業務の重要度を確かめてから決めます。いきなり新しいフレームワークで作り直すと、重要な業務処理を取りこぼしやすいため、その進め方は避けます。移行方式の選択肢は、既存システムを延命する案から、SaaS・パッケージへ置き換える案までの4通りです。
- 延命：既存システムの維持と、監視・バックアップの補強
- 部分移行：機能単位での新基盤への置き換え
- 全面刷新：業務要件とデータモデルからの再設計
- SaaS・パッケージ：標準化できる業務の既製サービスへの移行
業務停止が難しい場合は、旧システムを動かしたまま新機能を隣に置く段階移行が候補になります。
現行資産と業務仕様の洗い出し
最初に、システムの構成要素と運用状況を整理します。低頻度でも重要な処理があるため、見落とさないことが欠かせません。
- 技術資産：Java・JDK、Seasar2関連ライブラリ、dicon、Javaクラス、JSP、SQL、DBスキーマ
- 業務機能：バッチ、帳票、外部連携、認証、権限、ログ、監視、ジョブ
- 利用状況：未使用画面、代替可能な帳票、日次処理、月次・年次の締め処理
手作業の運用や障害時の復旧手順は、ソースの機械的な解析では把握しにくいものです。そのため、成果物には構成図と一覧を含めます。一覧は、機能や連携、データ項目、業務ルールを対象にします。
移行の難易度、廃止の候補、未確認の事項も、あわせて記録します。特に、ソースが少なくても業務ルールが不明なら、見積もりの不確実性は高くなります。また、テストデータと受入条件を整理しておくと、後の工程で追加される工数も抑えられます。
延命・部分移行・全面刷新の比較
方式を選ぶときは、業務停止をどこまで許容できるかと、解消したい課題に照らして比べます。方式によって、停止の抑えやすさも、保守性の改善の度合いも、そのあとに必要な作業も異なります。
- 延命：短期の継続には向くが、EOLの問題は解消しない
- 部分移行：停止を抑えやすいが、旧新連携と二重管理が必要
- 全面刷新：保守性やセキュリティは改善しやすいが、教育や切り戻しも要る
- SaaS・パッケージ：標準業務が多い場合に、独自開発の範囲を減らせる
全面刷新では、業務仕様を再確認し、不要な機能を整理してから新しい基盤を設計します。この範囲には、データ移行や教育、切り戻しの計画も含まれます。
また、SaaSやパッケージと組み合わせると、独自性の高い部分の開発に集中できます。
テストと切り替えの先行設計
テストは最後に追加せず、初期段階から対象と範囲を見積もります。業務への影響が大きい結果を確かめる必要があるためです。
- 機能確認：単体・結合・総合テスト、業務受入
- 業務継続確認：旧新比較、権限、性能、外部連携の再送
- 運用確認：脆弱性、バックアップからの復旧
金額計算や締め処理、在庫では、同じデータを旧新両方に流して結果を比べます。請求と給与も、同じ方法で確かめます。
リリースでは、切り替えの時間や最終データの同期、切り戻しの条件を決めます。ほかに、利用者への告知や旧環境の停止時期も決めておきます。24時間運用や外部連携があると、止められる時間が短いほど、並行稼働や段階リリースの工数が増えます。
この工数を削ると、本番障害のリスクが高まります。そのため、見積もりではテストを事業継続に必要な経費として扱います。
Seasar2のシステムの費用相場とコストの内訳
Seasar2専用の公的な料金表はありません。そこで、2025〜2026年に公開された業務システム相場と人月単価、Seasar2からSpringへの移行事例をもとに、概算を組み立てています。
これは特定の見積金額ではなく、社内予算の初期検討や、提案額を左右する要素の確認に使うための幅です。
規模別に見た費用と期間の目安
規模別の目安は次のとおりです。費用と期間をあわせて見ると、予算を組みやすくなります。
- 診断・棚卸し：100万〜500万円程度、2〜6週間程度
- 小規模部分移行：300万〜1,500万円程度、3〜8か月程度
- 中規模移行・刷新：1,200万〜4,000万円程度、6〜15か月程度
- 大規模基幹システム：3,000万円〜1億円超、12か月〜数年
診断では、ソースや設定、DBなどの技術面を調べます。画面や帳票、外部連携などは、業務上の重要度とあわせて確かめます。ただし、資料が少ない場合や、資産が複数社に分散している場合は、期間が延びることがあります。
小規模移行は、数十画面と単一DB、少ない外部連携を想定し、一つの機能群を新基盤へ移す場合です。
2026年の業務システム相場では、単機能の小規模開発が50万〜300万円、複数機能の中規模開発が300万〜1,500万円と紹介されています（出典：株式会社Fuji of Innovation、2026年）。Seasar2の移行では、診断や旧新比較、データ整合性の確認が加わります。そのため、単純な新規CRUD開発と比べると、費用は高くなる可能性があります。
中規模の場合は、複数のWebアプリやバッチを想定します。さらに、S2DaoやS2JDBCを使う処理、帳票、外部APIも含めます。認証・権限、データ移行、受入テストも対象です。
複数部門や複数DB、24時間運用が重なる大規模案件では、監査要件や段階リリースも加わります。こうした案件は、上限側かそれ以上で予算化します。
人月単価と工数で見る料金体系
受託開発費は、「人月単価×工数」を基本に、管理費や環境費などを加えて見積もります。2026年7月更新の公開単価は次のとおりです（出典：SIA株式会社、2026年7月）。
- 小規模：人月単価100万〜180万円
- 中規模：人月単価150万〜220万円
- 大規模：人月単価180万〜250万円
- 必要な人材：レガシー解析、Java、DB、インフラ、テスト、業務設計を担う人材。役割別の単価も確認します。
株式会社スタイルズは、Seasar 2.4とS2Daoを使うWebアプリのSpring 5移行事例を公開しています。対象は3本、約300メソッド、約16万ステップで、期間は約5か月、約20人月です（出典：株式会社スタイルズ、公開移行事例）。
人月単価を掛けた単純計算では、1,200万〜4,000万円程度になります。専門性の高い人員の単価を使うと、さらに上振れします。ただし、これは同社の見積額ではなく、規模感の推定です。
初期費用以外のランニングコスト
移行後の運用費も、初期費用と合わせて見積もります。契約範囲と対応時間によって金額が変わるためです。
- 基盤：クラウドやサーバー、DB、監視、バックアップ、ログ保管
- 保守：脆弱性診断、障害対応、追加改修、教育、保守契約
保守費を初期に検討するときは、開発費の年15〜25％程度を基準にする場合があります。ただし、契約範囲によって変わるため、一律の正解として扱うものではありません。
クラウド費は、サーバー代を含む基盤全体で比べます。冗長化やバックアップ、監査ログも含めます。さらに、検証環境やアクセス制御、復旧演習も対象です。
移行直後は、旧環境と新環境が並行して動くことが多くなります。そのため、二重のインフラ費用と運用工数を計上する期間を、見積書に明記しておきます。
Seasar2のシステム費用が変動する要因と見積もりの読み方
同じSeasar2からSpringへの移行でも、見積額は案件ごとに異なります。そのため、総額だけでなく、対象資産や納品物、テストの条件を確かめます。追加費用が生じる条件も、あわせて見ておきます。
現行仕様が不明な案件では、診断と本開発を分けて二段階で見積もると、不確実性を管理しやすくなります。
画面数より業務ルールと連携の確認
費用は、複雑な業務処理や外部接続の有無によって工数が変わります。画面数やソース行数からは、その差が見えにくくなります。
- 業務処理：権限、締め処理、決済、在庫連携
- システム量：大量データ、帳票出力、利用者数、ピーク時の処理量
- 移行条件：停止可能時間、データ保持年数、外部連携本数
似た画面が多く、共通部品やテストが整っている場合は、変換と検証を効率化できる可能性があります。
見積依頼では、API・ファイル・メッセージの連携本数、バッチ頻度、帳票種類などを示します。また、外部連携は、相手先の日程や仕様変更にも左右されます。相手システム側の調整担当や接続試験の回数が、見積もりに含まれるかも確かめます。
非機能要件とセキュリティの見積もり範囲
性能や可用性、監査ログ、権限は、後から追加しにくい要件です。バックアップや災害復旧、脆弱性対応も、あとからの追加が難しい領域です。
IPAの「情報セキュリティ10大脅威2026」では、ランサム攻撃、サプライチェーンや委託先を狙った攻撃、脆弱性を悪用した攻撃が挙げられています（出典：IPA、2026年）。そのため、見積もりでは、どこまでを確認対象に含めるかを領域ごとに分けて決めておきます。
- 基盤の脆弱性：Seasar2と依存ライブラリ、JDK、OS、APサーバー、DBの調査、責任分界の見積もり
- 情報保護：個人情報や決済情報を扱う場合の入力検証、認証・認可、TLS
- 攻撃対策：SQLインジェクション、XSS、CSRFへの対応範囲
- 運用要件：監査ログ、最小権限、バックアップからの復旧
- 法令対応：個人情報保護法や電子帳簿保存法に応じた、保存期間と改ざん防止の整理
給与や取引記録を扱う場合も、守る対象に入ります。セキュリティ診断や性能試験は、オプションにせず範囲を明細化します。検索性と運用証跡は、法務や税務の担当者とあわせて確かめます。
見積書の確認項目
見積書が工程や納品対象ごとに分かれているかを、まず見ます。「一式」と書かれた項目には、作業内容や成果物、前提条件を尋ねたうえで、対象外の作業も確かめます。
- 開発工程：要件定義、資産解析、設計、変換・実装、データ移行
- 品質と移行：単体・結合・総合、性能・セキュリティ、リリース、教育
- 費用と管理：PM・品質管理、環境、クラウド、ライセンス、出張、運用引き継ぎ
要件が固まっている範囲は請負とし、調査や仕様変更が見込まれる工程は準委任にするなど、契約方式を分けて考えます。
追加変更の単価や承認方法、納期変更の条件は、契約前に定めておきます。成果物の引き渡しも、契約に明記します。ソースや設定、テストコードなどが対象です。IaCや設計書、OSS一覧も、引き渡しに含めます。
脆弱性対応や再委託、終了時の引き継ぎを定めておくと、将来の保守費用やベンダーロックインのリスクを抑えられます。
Seasar2のシステムのコスト最適化のポイント
コスト最適化では、移行対象と品質条件を整理し、不要な作業を減らしながら重要業務を守ることが目的です。比べる際は、単価だけでなく、費用とリスクを同じ表に並べます。
テストや引き継ぎが不足すると、本番障害や緊急改修、二重運用が起き、結果として総額が高くなることがあります。
機能の優先順位付けと段階移行
移行対象は、業務への影響とコストを照らし合わせて、優先順位を決めます。判断では、外せる機能の有無や、最初に試す業務の範囲も見て決めます。
- 対象の優先度：業務影響、変更頻度、セキュリティ、依存関係、難易度
- 廃止機能：未使用の画面や帳票を外すことによる、設計・実装・テストの工数削減
- 廃止判断：低頻度の締め処理や障害対応を含む、現場責任者による確認
- パイロット：一業務での、変換ルール、テストデータ、共通認証、ログの検証
- リリース準備：CI/CDと切り戻し手順の、パイロットでの確認
初回は割高に見えることがあります。ただし、テンプレートと自動テストを後続の移行で再利用できれば、手戻りを抑えられる可能性があります。
自動変換と自動テストの使い分け
定型的な構成には自動化を使い、変換作業と業務上の検証は分けて考えます。自動化が効く範囲と、人が確かめる箇所では、確認の仕方が変わります。
- 自動変換：コード解析が効くのは、定型クラス、設定、SQL、API呼び出し
- 品質確認：変換率に加え、コンパイル、テスト、業務結果の一致を個別に評価
- 手動レビュー：dicon、独自インターセプター、トランザクション境界、特殊なS2Dao設定
- 自動テスト：代表業務の計算や権限の反復確認を減らせるが、初期工数が必要
- 対象の絞り込み：対象が少ない場合の重要シナリオの旧新比較、全画面自動化の費用対効果の判断
RFPと相見積もりの条件の統一
複数社に同じ資料を渡しておくと、診断込みの提案と開発のみの提案を混同しにくくなります。
各社に渡す情報が違うと、A社は診断込み、B社は開発のみという比較になります。その状態で安い方を選ぶと、後から追加費用が発生します。
- 現行情報：構成、画面・帳票・バッチ数、ソース規模、DB、外部連携
- 移行条件：停止時間、データ移行、Java・Springの希望版、テスト範囲
- 契約条件：成果物、保守条件、担当範囲
価格に加えて、構成要素ごとの実績と、業務仕様を読み解く体制を確かめます。Java・DB・APサーバーを同時に更新した経験も、確認の対象です。
テスト計画や担当者の継続性、ソースやテスト成果物の引き渡しも、評価の対象です。また、未確認事項や上限を超える条件、障害時の判断者を説明できる会社は、不確実性を管理しやすい傾向があります。
Seasar2のシステムの見積もりを取る際のポイント
見積もりの精度は、発注前に共有する条件によって変わります。資料が不足しているなら、まず診断の成果物と費用を定義しておきます。
診断のあとに本開発の見積もりを更新すると、業務ルールを確かめたうえで、延命・部分移行・刷新を比べられます。
発注前に用意する資料
発注資料は、現行の構成と運用を把握できる範囲で揃えます。資料が欠けている事実も、記録しておきます。
- 技術資料：構成図、Java・JDK・APサーバー・DB、リポジトリ、dicon
- 業務資料：画面・帳票・バッチ、外部連携、利用者と権限、データ量、月次・年次処理
- 運用資料：障害履歴、運用手順、未整備資料の有無
資料がない場合は、ヒアリングやコード解析も見積もりの対象に含めます。ソースに秘密情報が含まれるなら、NDAやアクセス権、持ち出し・保管・廃棄の条件も確認します。
移行後の目標は、「Springにする」という表現で止めず、具体的に書きます。JDKのサポートや応答時間、稼働率を記述します。加えて、復旧目標や監査ログ、データ保持を書きます。さらに、利用者教育と運用引き継ぎも含めます。
目標が具体的であれば、必要なテストと環境を見積もりやすくなります。発注者も、価格の根拠を確かめられます。
開発会社に確認する質問
移行実績は、Seasar2本体だけでなく、利用中の構成要素と照らし合わせて確かめます。
- 実績の規模：対象ステップ数、画面・アプリ数、期間、人月、移行先
- 移行の品質：テスト方法、リリース後の保守範囲、手動修正の基準
- 自動変換：未対応構成、レビュー担当、ツール利用料
S2DaoやS2JDBC、SAStrutsの実績があるかも尋ねます。JSPや独自拡張の実績も、あわせて確認します。公開事例がある場合は、対象範囲や移行先と照らし合わせます。
担当体制と責任分界も確かめます。業務ヒアリングを担う人と、Java・Springを担う人は、別々に特定しておきます。DB・インフラとテスト・移行の担当者についても、誰が受け持つかを決めておきます。
再委託の有無や、担当が替わるときに更新する資料も確認します。業務知識を持つ人が契約後に参加できない場合、追加ヒアリングや手戻りが増える可能性があります。
安さだけで決める失敗の回避
価格の低い提案では、見積もりに含まれていない作業がないかを確かめます。発注者側が担う作業なら、社内の人件費や別会社への発注費も加えて比べます。
- 調査と品質：要件定義、仕様調査、データ整理、旧新比較、性能試験、脆弱性診断
- 移行後の支援：利用者教育、切り戻し、安定稼働支援
「完全自動変換」「短期間で移行」といった表現を見たら、自動化の範囲と業務仕様の確認範囲を分けて確かめます。重要業務の受入条件は、契約前に決めておきます。
不具合時の無償対応期間や瑕疵の扱いを確かめます。追加変更の単価と、保守契約へ移る条件も確認します。これらを押さえると、初期費用と将来費用を一体で判断できます。
よくある質問（FAQ）
費用は現行資産と移行方式によって幅が出るため、公開相場の数字を発注額としてそのまま使うことはできません。ここでは、費用、移行時期、データ、保守に関する質問に答えます。
Seasar2のシステム移行費用はいくらですか？
目安は、移行診断が100万〜500万円程度、部分移行が300万〜1,500万円程度、中規模刷新が1,200万〜4,000万円程度です。
これは公開相場と移行事例から組み立てた概算です。実際の額は、画面数や業務ルール、外部連携で変わります。S2Daoやバッチ、データ移行、テスト範囲によっても変わるため、診断費用と成果物を確かめてから本開発を見積もる方法が現実的です。
2026年にSeasar2で新規開発しても問題ありませんか？
原則として、新規開発ではSpring MVCやSpring Bootなど、保守・更新が続く技術を比べることをおすすめします。
The Seasar Projectは、多くのプロダクトが2016年9月26日にEOLになったと案内しています。公開ソースがあることと、公式サポートがあることは別の話です。
既存システムを短期で延命するなら、脆弱性や保守担当の体制を確かめます。JDKやOS、APサーバー、DBの状況も、あわせて見ておきます。そのうえで、移行期限を含む計画にします。
Springへ移行するとデータはそのまま使えますか？
DBを継続して使える場合はありますが、無条件にそのまま使えるとは限りません。
確認するのは、スキーマや文字コード、日付・金額の扱いです。さらに、不要データやマスタ統合のほか、外部連携と移行中の更新差分も確認します。
同じテストデータを旧新両方で処理し、計算結果や件数、残高、締め処理が一致してから、本番へ移行します。
移行しない場合は保守費用だけで済みますか？
移行しない場合も、保守費用以外の出費が生じる可能性があります。EOL後のライブラリや実行環境では、脆弱性調査や暫定パッチ、旧環境のサーバー維持、担当者不足を補う調査費などが発生することがあります。
延命する場合は、対応できる脆弱性の範囲や復旧目標、バックアップを決めます。担当会社の体制と、移行を始める判断基準も定めます。そのうえで、将来の刷新費用を中期計画に組み込みます。
まとめ
費用相場を判断する要点
診断は100万〜500万円程度、部分移行は300万〜1,500万円程度、中規模刷新は1,200万〜4,000万円程度が初期の目安です。
これは公開相場と約20人月の事例によるレンジで、特定企業の料金ではありません。
見積もりでは、S2Daoやdiconなどの構成要素と、JSP、バッチ、外部連携を明細にします。データ移行や旧新比較、停止時間、セキュリティ要件も明細にすると、根拠を確かめやすくなります。
最初に取るべき行動
まず現行資産と業務仕様を棚卸しし、延命や部分移行、全面刷新、SaaS・パッケージへの置き換えを、同じ条件で比べます。
診断の成果物と本開発の見積もりを分けたうえで、複数社に同じRFPを渡します。EOLの脆弱性や人材、復旧、業務停止のリスクまで含めて考えると、初期費用だけに左右されない計画を立てられます。
▼全体ガイドの記事
・Seasar2のシステム開発の完全ガイド
▼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を創業。