Seasar2のシステム開発は、現行資産と業務ルールを棚卸しし、段階的な移行または刷新を選んで進める方法が安全です。
Seasar2は長年稼働している業務システムで採用例が多い一方、公式プロジェクトのサポート終了後も使われ続けています。そのため、単に新しいフレームワークへ置き換えるのではなく、要件整理、技術選定、設計開発、テスト、稼働、定着までを一つの計画にすることが重要です。この記事では、既存のSeasar2システムを移行・刷新するときの進め方、費用相場、見積もりの確認項目を実務の順番に沿って解説します。
▼全体ガイドの記事
・Seasar2のシステム開発の完全ガイド
Seasar2のシステム開発の全体像

Seasar2のシステム開発を考えるときは、「新規にSeasar2を採用する案件」と「既存のSeasar2を持つ企業の刷新案件」を分けて考えます。Seasar2はDIとAOPを軸に、SAStrutsやJSPなどのWeb層、S2DaoやS2JDBCなどのデータアクセス層、バッチや外部連携を組み合わせて使われてきました。見た目が一つのWebアプリケーションでも、実際には複数の技術と運用手順が結び付いている場合があります。
Seasar2とはどのような技術ですか?
Seasar2は、Javaで業務Webシステムを構築するために国内で広く利用された軽量フレームワークおよびDIコンテナです。S2ContainerがサービスやDAOなどの依存関係を組み立て、AOPによってトランザクション、ログ、認証といった共通処理を業務ロジックから分離しやすくしていました。S2Daoではデータベースアクセスの定型処理を減らせるため、画面のAction、dicon設定、SQL、バッチ処理が業務機能の裏側で連携する構成になりやすい点が特徴です。
ただし、The Seasar Project公式サイトでは、多くのプロダクトが2016年9月26日にEOLとなり、プロジェクトによるメンテナンスとサポートが終了したと案内されています(出典:The Seasar Project公式「EOLについて」)。ドキュメントやソースコードが公開されていても、現在のJava、OS、APサーバー、データベースとの互換性や新たな脆弱性への公式対応が保証されるわけではありません。2026年時点で新規開発に採用する場合は、短期の検証用途を除き、Spring MVCやSpring Bootなどの現行技術と比較して判断します。
新規開発と既存システムの移行はどう違いますか?
新規開発では業務要件に合う技術を選びやすいのに対し、既存Seasar2システムの移行では、現在動いている処理を壊さずに業務知識を引き継ぐ必要があります。特に問題になりやすいのは、ソースコードだけでは分からない締め処理、例外時の手作業、夜間バッチ、帳票、権限、外部API、運用担当者だけが知る復旧手順です。画面を新しくしても、計算結果や承認経路が変われば業務上は失敗となります。
したがって、選択肢は全面再構築だけではありません。現行環境を一時的に延命しながら診断する方法、機能単位でSpringなどへ置き換える方法、API境界を作って段階的に切り替える方法、標準業務をSaaSやパッケージへ寄せて独自業務だけを再開発する方法があります。停止できる時間、業務の独自性、データ移行の難しさ、社内に残したい運用知識を基準に、方式を選びます。
Seasar2のシステム開発の進め方・流れ・手順

Seasar2の移行・刷新は、要件整理、技術や製品の選定、設計開発、テスト、稼働、定着の6フェーズに分けると判断しやすくなります。各フェーズで成果物と合否条件を決め、次の工程へ進む前に確認することがポイントです。先にコード変換を始めると、不要な機能や曖昧な業務ルールまで新環境へ持ち込むため、最初に現行資産と業務上の重要度を整理します。
フェーズ1:要件整理と現行資産の棚卸しを行います
最初に、何を残し、何を変え、何を廃止するかを決めます。Seasar2本体のバージョン、SAStrutsやS2Struts、S2DaoやS2JDBC、dicon、JSP、JavaとJDK、APサーバー、OS、RDBMS、ジョブ管理、帳票、外部連携、認証・権限、ログ、バックアップを一覧にします。画面数やソース行数だけでなく、バッチ本数、連携先、月次・年次処理、ピーク時の利用者数も記録します。
棚卸しでは、実際に使われている機能を業務部門へ確認します。チェック項目は「担当者が説明できるか」「入力から出力までの業務ルールが文書化されているか」「締め処理や取消処理を再現できるか」「障害時の切り戻し手順があるか」「個人情報や決済情報を扱うか」「停止可能な時間帯はいつか」です。成果物として、構成図、機能一覧、データ項目一覧、外部連携一覧、リスク一覧、移行対象と廃止対象の判定表を残します。
フェーズ2:移行先と開発方式を選定します
選定では、フレームワーク名よりも業務を安全に引き継げるかを優先します。標準的な業務はSaaSやパッケージ、独自性の高い業務はSpring MVCやSpring Bootを使った再構築、変更範囲を抑えたい機能は段階移行というように、業務単位で方式を分けることも有効です。全面再構築、部分移行、延命のそれぞれについて、費用、期間、停止時間、将来の保守性、データ移行リスクを並べて比較します。
S2Daoを利用している場合は、MyBatisなどへ移すのか、既存インターフェースをどこまで再利用するのかを確認します。公開事例では、Seasar2のS2DaoからSpring 5へ移行する際、既存インターフェースを再利用してMyBatisへ移植し、データアクセス層を画面から分離してJUnitで確認しています(出典:株式会社スタイルズ「ケース4」)。このように、技術選定の段階から移行単位とテスト単位を合わせて考えると、変換後の不具合を切り分けやすくなります。
フェーズ3:設計・開発とデータ移行を進めます
設計では、機能要件だけでなく非機能要件を先に明文化します。目標の応答時間、同時利用者数、稼働時間、障害復旧目標、バックアップ世代数、監査ログの保存期間、権限分離、暗号化、個人情報のマスキングを決めます。古いJDKやAPサーバーを残すのか、JavaのLTS版やクラウドへ同時に更新するのかも、基本設計の時点で確定させます。
開発では、画面、サービス、DAO、バッチ、帳票、外部連携を一度に変えず、機能のまとまりごとに移行します。コード変換ツールを使う場合でも、変換できないdicon設定、独自インターセプター、SQL、JSPの画面遷移、例外処理を人手で確認します。データ移行は、項目対応表、変換ルール、欠損時の扱い、重複排除、移行リハーサル、件数照合、金額照合を決め、移行後に旧データを参照できる期間も設計します。
フェーズ4:旧新比較を含むテストを実施します
テストは、単体、結合、総合、性能、権限、脆弱性、業務受入、障害復旧に分けます。特にSeasar2の移行では、旧システムと新システムへ同じ入力を与え、処理結果、明細件数、金額、ステータス、出力帳票、連携ファイルを比較する現新比較テストが有効です。画面が表示されることだけを合格条件にせず、締め処理や例外処理まで一致していることを確認します。
テストデータは、通常ケースだけでなく、空欄、上限値、過去日、取消、重複、権限外操作、連携先停止、タイムアウトを含めます。テスト結果には、実施者、実施日時、入力条件、期待値、実績値、差異、修正番号を残します。合格基準は「重大障害ゼロ」「重要業務の現新差異ゼロ」「未解決の中軽微障害は責任者承認済み」など、発注側と開発側で合意してからリリース判定に使います。
フェーズ5:稼働判定と切り替えを行います
稼働前には、リリース判定会議で業務、情報システム、開発会社、運用担当者が確認します。判定材料は、テスト完了率、重要機能の合格状況、データ移行リハーサル結果、性能試験結果、脆弱性対応状況、問い合わせ窓口、監視設定、バックアップ復元結果、利用者向け手順書です。切り替え当日に判断が揺れないよう、延期や中止の条件も事前に決めます。
切り替え方式は、一括リリース、部門単位の段階リリース、旧新並行稼働から選びます。停止できる時間が短い基幹業務では、先に読み取り機能を移し、次に登録や更新機能を切り替える方法が現実的です。切り戻しでは、どの時点のデータを旧環境へ戻すか、二重登録をどう防ぐか、誰が経営判断をするかを決めます。切り替え後の最初の締め処理までを安定稼働期間として、開発会社の待機体制を契約に含めます。
フェーズ6:運用定着と保守体制を整えます
稼働して終わりではなく、利用者が新しい画面と手順を使い、社内で障害対応や改善を継続できる状態を定着と考えます。利用者向け操作説明、管理者向け設定手順、障害時の一次切り分け、問い合わせ分類、変更申請、リリース手順を整備します。旧システムに詳しい担当者から新しい担当者へ、処理の背景や例外運用を引き継ぐ場も設けます。
保守契約では、問い合わせ受付時間、重大障害の初動時間、復旧目標、脆弱性情報の確認方法、JDKやミドルウェアの更新方針、バックアップ監視、追加改修の単価、成果物の引き渡し範囲を明記します。2026年のIPA「情報セキュリティ10大脅威」では、組織向けの4位にシステムの脆弱性を悪用した攻撃、2位にサプライチェーンや委託先を狙った攻撃が挙げられています(出典:IPA「情報セキュリティ10大脅威 2026」、2026年)。EOL技術の保守では、担当者の善意に頼らず、脆弱性対応と委託先管理を運用の正式な項目にします。
Seasar2のシステム開発にかかる費用相場と内訳

Seasar2専用の公的な価格表はないため、費用は画面数やソース行数だけで断定できません。診断に必要な調査量、S2Daoや独自設定の複雑さ、外部連携、データ移行、現新比較テスト、停止できない時間、JavaやDBやインフラの同時更新によって大きく変わります。以下の金額は、リサーチノートと2026年時点で公開されている一般的な相場・移行事例から整理した目安であり、個別案件の確定見積もりではありません。
移行診断から大規模刷新までの費用目安はいくらですか?
移行診断・資産棚卸しは、100万円から500万円程度、期間は2週間から6週間程度が一つの目安です。ソース、設定、DB、実行環境、画面、帳票、バッチ、外部連携を調査し、残す機能と廃止する機能を切り分けます。小規模な業務Webシステムの部分移行は300万円から1,500万円程度、中規模の移行・刷新は1,200万円から4,000万円程度、大規模・基幹システムは3,000万円から1億円超になる可能性があります。これらは作業範囲による推定レンジで、税、クラウド利用料、ライセンス、第三者診断などを含むかで変わります。
2026年7月更新のSIA株式会社の公開記事では、一般的な受託開発の平均人月単価を小規模100万〜180万円、中規模150万〜220万円、大規模180万〜250万円と整理し、保守費を新規開発費の年15〜25%としています(出典:SIA株式会社「受託開発の費用相場」、2026年7月更新)。同社はレガシー技術では単価が10〜15%高くなりやすいとも説明しているため、Seasar2移行では現行資産の解析とテストの分を新規CRUD開発より厚めに見込みます。
費用はどのような項目に分かれますか?
見積もりは、移行診断、要件整理、基本設計、詳細設計、コード変換・実装、データ移行、テスト、リリース、教育、プロジェクト管理に分けて確認します。加えて、JDK・APサーバー・DB・OSの更新、クラウド環境、監視、バックアップ、脆弱性診断、ライセンス、旧環境の並行稼働が別費用になる場合があります。「移行一式」とだけ書かれた金額では、何が含まれないのかを判断できません。
参考になる公開事例として、株式会社スタイルズは、Seasar 2.4のS2DaoからSpring 5へ移行した案件について、Webアプリケーション3本、約300メソッド、約16万ステップ、約5か月、約20人月と公表しています(出典:株式会社スタイルズ「ケース4」、公開情報)。この規模を、上記の人月単価100万〜250万円で機械的に計算すると2,000万〜5,000万円程度になりますが、これは同社の見積額ではなく、公開された作業規模を使った参考試算です。自社案件では、画面数よりも業務ルール、連携、テスト、切り替え条件をそろえて見積もります。
Seasar2のシステム開発で見積もりを取る際のポイント

相見積もりでは、合計金額の安さよりも、前提条件と工数の根拠がそろっているかを見ます。Seasar2の移行は、調査を省くほど安く見えますが、後半で仕様漏れやテスト不足が表面化しやすい領域です。3社程度へ同じ資料を渡し、同じ質問をして、工程別の工数、成果物、除外事項、追加費用の条件を比較します。
発注前にどのような資料を準備しますか?
RFPや見積依頼書には、現行のSeasar2構成、JDKとミドルウェアのバージョン、画面数、Action数、ソース規模、diconやJSPの量、DAOとSQL、バッチ、帳票、外部API、認証方式、利用者数、ピーク時間、データ件数、停止可能時間、法令・監査要件を記載します。分からない項目は空欄にせず、「調査で確定する項目」と明示します。
加えて、業務部門から、必須機能、廃止候補、手作業で補っている処理、月次・年次の締め、障害時の代替手段を集めます。特に「長年使っていないように見えるが、特定の担当者だけが使う機能」「年に一度だけ必要な帳票」は、アクセスログとヒアリングの両方で確認します。提出資料は、ソースコードのコピーだけでなく、テストデータ、過去障害票、運用手順、監査記録を含めると診断の精度が上がります。
開発会社は技術名以外に何を比較しますか?
候補会社には、Seasar2の構成要素別の実績を確認します。「Seasar2対応」と書かれていても、S2Dao、S2JDBC、SAStruts、独自dicon、バッチ、帳票、外部連携まで扱った経験があるとは限りません。確認質問は「類似案件の画面数・連携数・工期」「移行後のSpringやMyBatisのバージョン」「コード変換後の手動修正比率」「現新比較テストの方法」「データ移行リハーサル回数」「担当者交代時の引き継ぎ方法」です。
また、発注側が成果物を受け取れるかを確認します。設計書、ソース、設定ファイル、テストコード、テスト結果、IaC、OSS一覧、脆弱性対応記録、運用手順、教育資料を納品対象に含めます。再委託の範囲、知的財産権、終了時の引き継ぎ、保守終了後のデータ返却、障害時の責任分界も契約前に確認します。安価な会社を選ぶ場合でも、安さの理由が調査やテストの省略になっていないかを見極めます。
見積もりの抜け漏れを防ぐチェック項目は何ですか?
見積書を受け取ったら、まず工程が「要件整理、設計、実装、データ移行、テスト、教育、稼働支援、保守」に分かれているかを確認します。次に、画面・機能だけでなく、バッチ、帳票、外部連携、監査ログ、権限、性能、バックアップ、障害復旧が対象に含まれているかを確認します。SIA株式会社が公開する2026年の相場情報でも、人月単価と工数に加えて、外部連携、性能、可用性、セキュリティ、短納期が費用を押し上げる要素として整理されています。
次に、「一式」「別途」「想定外」の言葉を洗い出します。移行診断後に追加費用が発生する条件、仕様変更の扱い、データ不整合が見つかった場合の責任、クラウド費用の上限、脆弱性が検出された場合の対応期限を、質問票で回答してもらいます。契約形態が請負か準委任かによって完成責任と進捗リスクの分担が変わるため、納品物と受入基準を契約書や仕様書に結び付けます。
Seasar2のシステム開発に関するよくある質問

ここでは、既存のSeasar2システムを持つ企業から寄せられやすい質問に回答します。結論だけでなく、判断するときに確認したい条件も併記します。
Seasar2は2026年に新規開発へ使えますか?
技術的に動かせる可能性はありますが、通常の業務システムの新規開発では慎重な判断が必要です。Seasarプロジェクト公式が多くのプロダクトを2016年9月26日にEOLと案内しているため、公式サポート、現行JDKとの互換性、脆弱性対応、人材確保、将来の保守費を含めて比較します。既存システムとの互換性など明確な理由がなければ、Spring Bootなど現行技術を選ぶほうが長期運用の選択肢を確保しやすくなります。
Springへ移行するとデータや業務機能は失われませんか?
移行方式とテストを適切に設計すれば、データや業務機能の消失リスクは抑えられますが、自動的に保証されるわけではありません。項目対応表、変換ルール、旧新比較、移行リハーサル、件数・金額照合、利用者受入を実施し、重要業務の合格基準を決めます。特にS2DaoのSQL、diconの設定、バッチの実行順、例外処理、帳票の端数計算は、画面単位の確認だけでは漏れやすい項目です。
Seasar2の移行を急がずに保守し続けてもよいですか?
短期的な延命は選択肢になりますが、期限と条件を決めないまま先送りすることはおすすめできません。まず脆弱性、担当者不在、JDKやOSのサポート期限、障害時の復旧可否、監査要件を診断し、最低限のパッチ適用、アクセス制御、ログ監視、バックアップ、保守要員の確保を行います。そのうえで、診断から部分移行へ進む時期と、延命を終了する判断基準を経営層と共有します。
まとめ:Seasar2のシステム開発は段階的に進めます

Seasar2のシステム開発・移行では、技術を置き換えること自体を目的にせず、業務を止めずに安全性と保守性を高めることを目的にします。要件整理では現行資産と業務ルールを棚卸しし、選定では延命、部分移行、全面刷新、SaaS・パッケージ化を比較します。その後、設計開発、旧新比較テスト、切り戻し計画、利用者教育、保守契約までを一続きにして進めます。
最初に押さえる3つのポイント
第一に、Seasar2は公式EOL済みのため、現行環境が動いていることと安全に使い続けられることを分けて判断します。第二に、S2Dao、dicon、JSP、バッチ、帳票、外部連携までを対象にし、コードだけで業務を再現しないことです。第三に、費用は診断、移行、テスト、並行稼働、保守を含めた総保有コストで比較し、工程別の人月と除外事項が分かる見積もりを選びます。
次に行うべきアクション
まずは、現行構成図、利用中の画面とバッチ、外部連携、データベース、担当者、障害履歴を集め、2週間から6週間程度の移行診断を依頼します。診断結果をもとに、同じRFPで複数社から見積もりを取り、費用だけでなく、移行方式、テスト計画、成果物、保守体制、脆弱性対応を比較します。業務部門と情報システム部門が同じ判断基準を持てれば、Seasar2のシステムを無理なく段階的に刷新しやすくなります。
▼全体ガイドの記事
・Seasar2のシステム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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


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