Seasar2のシステム開発の完全ガイド - ブログ

Seasar2のシステムは、現行資産と業務ルールを棚卸しし、移行先と移行単位を決めて段階的に移すと、業務を守りながら保守性を高められます。

EOL後のリスクや移行の選択肢に続いて、進め方と費用、発注先、セキュリティへ進みます。

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

Seasar2のシステムの概要

Seasar2は、Javaで業務用のWebシステムを開発するために使われてきた、軽量フレームワークとDIコンテナの組み合わせです。

画面、業務ロジック、データベース、共通処理を分けて管理しやすい設計になっています。そのため、販売管理、契約管理、社内申請、顧客管理などの業務システムに組み込まれてきました。

S2Containerが担うDIとAOP

中心となる部品はS2Containerで、Dependency Injection（DI）とAspect Oriented Programming（AOP）を支援します。

DIでは、サービス、DAO、設定などの依存関係をコンテナが組み立てます。そのため、業務クラスが他のクラスを直接生成する処理を減らせます。

AOPでは、トランザクション、ログ、認証など複数の箇所に共通する処理を、業務ロジックから切り離しやすくなります。

SAStruts・S2Dao・S2JDBCの役割

Seasar2の主な部品は、次のように役割が分かれています。

Web層：SAStruts、S2Struts、Teeda、JSPなどが、画面の表示、入力チェック、画面遷移を受け持ちます。
データアクセス層：S2Dao、S2JDBC、S2Hibernateなどが、データベースへの接続を担います。
業務処理：dicon、Action、サービスなどが連携して組み立てます。
DAO・SQL・バッチ・帳票：業務処理と同じ仕組みの一部です。

このため、移行ではSeasar2本体だけでなく、これらの部品をまとめて捉えることが欠かせません。

現在も動く理由と新規採用を慎重にする理由

Seasar2のシステムが今も動き続けているのは、完成した業務ロジックと実行環境が維持されているからです。

ソースコードや資料が公開されていても、現行のJavaやOSはもちろん、アプリケーションサーバーやデータベースに公式サポートがあるとは限りません。

2026年時点で新規開発を考えるなら、保守人材、依存ライブラリの更新、監査対応まで含めて、現行フレームワークを採用する合理性を確かめます。

Seasar2のEOL後に確認すべきリスク

Seasarプロジェクトの公式サイトは、多くのプロダクトが2016年9月26日にEOLとなり、メンテナンスとサポートが終了したと案内しています（出典: The Seasar Project公式サイト、2016年）。

今も稼働しているという事実だけでは安全とは言えないため、技術、業務、契約の面に分けてリスクを確認します。

技術面のリスクの対象範囲

確認は、次の範囲に分けて進めます。

Seasar2とJava：Seasar2のバージョンに加えて、Java、JDK、Servlet・JSPが対象です。
実行環境：アプリケーションサーバー、データベース、OSを一覧にします。
周辺の要素：ビルドツール、ログ出力、認証方式、外部API、ジョブ管理、バックアップです。

まず構成図に依存関係を書き出すことが、出発点になります。古い要素が一つでも残ると、フレームワークを移行しても、脆弱性やサポート切れが解消されないことがあります。

業務知識がブラックボックス化するリスク

移行で大きな失敗につながるのは、画面を刷新した結果として、業務の意味が失われる場合です。

締め処理、休日計算、例外承認は、コードやSQL、バッチに埋め込まれていることがあります。請求額の丸めや帳票条件も、同じように埋め込まれている場合があります。

仕様書が足りない場合は、開発会社が担当者への聞き取り、過去障害の確認、旧システムの実データを使う現新比較を、診断工程に含めます。

脆弱性と委託先管理のリスク

2026年の情報セキュリティ10大脅威では、組織を狙う攻撃として、脆弱性を悪用した攻撃や、サプライチェーン・委託先を狙う攻撃が挙げられています（出典: IPA「情報セキュリティ10大脅威2026」、2026年）。

延命や移行を委託する場合は、脆弱性の調査・報告・修正の分担と、再委託の可否を、契約書に明記しておきます。

契約が終わるときに備えて、ソースコードやテスト成果物の引き渡し、引き継ぎの方法も決めておきます。

ポイント

稼働中であることだけで安全とは判断せず、技術・業務・契約の各面で、サポート切れの影響がどこまで及ぶかを見てから方針を決めます。

Seasar2のシステムの4つの選択肢

移行準備や業務の独自性に合わせて、進め方を見比べられます。

全面再構築か現状維持かで迷う前に、業務の重要度、停止可能時間、変更頻度を軸に選びます。

データ量と担当者の体制、予算と将来の拡張も考慮します。

短期延命：移行準備に必要な時間を確保する選択です。
段階移行：機能単位で、新しい構成へ移していく形です。
全面刷新：Springなど現行のJava環境へ移すことです。
パッケージ・SaaS：標準化しやすい業務を、サービスへ置き換える選択です。

短期的な延命

業務を止めにくく、移行準備に時間がかかる場合は、現行環境を隔離して短期の延命をはかります。

延命の間は、アクセス制御、監視、バックアップ、脆弱性診断、ログ保全を強化します。ただし、延命は恒久的な対策ではありません。

延命できる年数と、次の移行工程へ進む条件は、経営判断として決めておきます。特に、保守できる技術者がいなくなる前に診断を始めることが欠かせません。

機能単位での段階的な移行

全面刷新のリスクを抑えるには、画面や業務機能を一つずつ新しい構成へ移す方法があります。

参照系の画面を先に移します。
続けて、登録・更新機能へ進みます。
最後に、締め処理や外部連携へ進みます。

旧新システムを一定期間並行稼働させ、APIやデータ連携の境界を明確にします。そのため、業務を止めずに知見を蓄積できます。

Springなどへの刷新

業務を維持したまま保守性を高めたい場合は、次の2つが候補になります。

基盤：Spring MVCやSpring Bootなどへの移行です。
データアクセス：MyBatisなどに置き換えます。

S2ContainerのDI、dicon設定、インターセプター、S2DaoのSQLやマッピングは、単純な文字列置換では終わらないため、移行先の仕組みと個別に対応づけます。

移行先のバージョンは、サポート期間、JavaのLTS版、脆弱性情報から選びます。社内人材が習得できるかどうかも、あわせて見ておきます。

パッケージやSaaSへの置き換え

業務を標準化しやすく、独自の処理が競争力に直結しない場合は、パッケージやSaaSで長期の運用負担を抑えられることがあります。

既存画面をそのまま再現するより、業務プロセスを新サービスに合わせる必要があります。そのうえで、残す業務、変える業務、廃止する業務に分けます。

データの保持期間、権限、帳票を確認します。さらに、外部連携や、契約終了時のデータ返却も見ておきます。

ポイント

業務の重要度、停止可能時間、変更頻度を軸に、延命・段階移行・刷新・置き換えのうちどれが業務ごとに合うかを選びます。

Seasar2のシステム移行・開発の進め方

実装前の把握と設計が、後続のテストにつながります。

移行の成否は、実装に入る前に稼働中の機能と守るべき業務を把握できるかで決まります。

作業は診断から始まり、要件定義と設計・実装、テストとデータ移行を経て、リリース、保守へと進みます。

各工程の完了条件は、あらかじめ決めておきます。

▶ 詳細はこちら：Seasar2のシステム開発の進め方/やり方/流れや方法/手法/工程/手順

1. 現行資産の棚卸し

棚卸しでは、次の現行資産を一覧にまとめます。

アプリ資産：ソースコード、dicon、JSP、SQL、設定ファイル、ライブラリが対象です。
実行環境：Java・JDK、アプリケーションサーバー、データベースの構成。
業務・運用資産：バッチ、帳票、外部API、認証・権限、ジョブ、監視、バックアップ。

工数は、画面数やソース行数だけでは判断できません。業務処理数、外部連携数、定期処理の本数を記録します。

データ量と停止可能時間も残しておきます。

使われていない機能を移行対象から外すだけでも、費用と期間を抑えられます。

2. 業務要件と非機能要件の可視化

担当者への聞き取りでは、通常処理と例外処理、締め処理の流れを確認し、承認経路や権限も確かめます。通知、帳票、障害時の復旧手順も押さえておきます。

非機能要件では、同時利用者数、応答時間、稼働時間を定義します。さらに、復旧目標、監査ログ、データ保持期間も決めておきます。

個人情報の扱いとネットワークの制約も決めておきます。要件が曖昧なまま見積もると、追加要望やテスト範囲の拡大によって、予算が膨らみます。

3. 移行方式と新しい構成の設計

S2ContainerのDIは移行先のDIへ、インターセプターは共通処理やアスペクトへと対応づけます。

S2Daoの定義も、新しいデータアクセス方式へ対応づけます。そのうえで、自動変換できる部分と、業務判断が必要な部分を分けます。

計画では、変換率を見るだけでなく、Java、データベース、OSの更新も踏まえます。実行環境も更新するなら、変更の影響を組み合わせた検証環境を早期に作ります。

4. 旧新比較テストと切り戻しの設計

移行後の品質確認では、次のテストを行います。

機能：単体、結合、総合、業務受入の各テスト。
非機能・運用：性能、権限、脆弱性、障害復旧の確認。

同じ入力を旧新システムに与え、金額、在庫、契約状態を比べます。締め結果、帳票、外部連携の出力も対象です。

リリース時は、データ移行の完了条件と利用者の切り替え手順を決めます。監視項目や障害時の連絡先も、定めておきます。また、旧環境へ切り戻す期限も決めておきます。

ポイント

棚卸しから旧新比較まで、各工程の完了条件を満たしたかを見て次へ進みます。実装前に稼働中の機能と守るべき業務を把握できているかも、判断の基準になります。

Seasar2の移行費用相場と内訳

規模が大きくなるほど、費用レンジも広がります。

Seasar2専用の公的な価格表はありません。そのため、2026年時点の業務システム開発の公開相場と、公開されたSeasar2移行事例から組み立てた推定レンジを示します。

費用は画面数より、業務ルール、外部連携、テストデータによって変わります。停止可能時間、既存資料の量、データ移行の難しさも影響します。

▶ 詳細はこちら：Seasar2のシステム開発の見積相場や費用/コスト/値段について

規模別の費用と期間の目安

規模ごとの移行費用と期間は、次の範囲が目安です。

診断・棚卸し：2〜6週間、100万〜500万円程度。
小規模の部分移行：3〜8か月、300万〜1,500万円。
中規模の刷新：6〜15か月、1,200万〜4,000万円。S2Dao・S2JDBC、バッチ、帳票、外部API、権限、データ移行を含む規模の案件です。
大規模・基幹系：12か月から数年、3,000万円〜1億円超。複数部門、24時間運用、並行稼働、厳格な監査がある場合の規模です。

2026年の公開情報では、一般的なシステム開発の人月単価は60万〜200万円程度です（出典: 2026年版のシステム開発費用相場に関する公開情報、2026年）。

ただし、この単価がそのままSeasar2移行の価格になるわけではありません。EOL調査、旧新比較、データ移行が加わり、管理やセキュリティ確認も必要になります。そのため、新規CRUD開発より高くなると考えられます。

公開事例から見る見積もりの考え方

これは特定案件の実績です。すべてのシステムに当てはまるとは限らないため、規模感を考える材料として、次の実績を見ます。

移行対象：Seasar 2.4とS2Daoを使ったWebアプリケーション3本、約300メソッド、約16万ステップ。
実績工数・期間：約20人月、約5か月。
単価を掛けた試算：人月60万〜200万円なら1,200万〜4,000万円、中間の80万〜150万円なら1,600万〜3,000万円。

見積書では、調査や要件定義、変換・実装、テストの項目を見ます。データ移行とリリースは別に確認します。教育と保守も、項目が分かれているかを見ます。

クラウド利用料、ライセンス、脆弱性診断は、別費用かどうかを確認します。監視、バックアップ、旧環境の並行稼働も、別費用に含まれるかを確かめます。加えて、追加変更の単価と上限も確認します。

移行後のランニングコスト

移行後も、保守や監視、バックアップに費用がかかります。脆弱性診断、OSやJavaの更新、障害対応も続きます。さらに、追加改修も費用の対象です。

保守費は、初期開発費の年15〜25％を仮に置いて考える場合があります。実額はサポート範囲や対応時間で変わるため、月額だけで比べないようにします。

EOL環境を延命する場合は、対応できない脆弱性、担当者の退職、復旧できない停止時間など、金額に出にくい事業継続のコストも含めて判断します。

ポイント

費用は画面数よりも、業務ルール、外部連携、データ移行の難しさで見積もり、移行後の保守費まで含めて比べます。単価の数字だけで判断しないようにします。

Seasar2の開発会社・ベンダーの選び方

Seasar2の案件では、新規開発の実績に加えて、既存システムを読み解く力と移行後の保守体制を見ることが大切です。

SAStruts、S2Dao、diconの対応範囲を質問します。JSPやバッチ、外部連携、データベースについても聞きます。Javaやアプリケーションサーバーも確かめます。

構成要素別の経験の確認

経験を聞くときは、Seasar2を扱った経験の有無で済ませず、構成要素ごとに確認します。

データアクセス：S2Daoを別方式へ移した経験。
設定・共通処理：diconや独自インターセプターの読解経験。
画面・帳票：JSPや帳票を含む画面移行の経験。
検証：バッチ、外部API、旧新比較テストの実施経験。

公開できる範囲で、対象規模、期間、体制を説明できるかも判断材料になります。担当範囲と移行後の障害対応についても確かめます。

診断と提案の具体性の比較

ソース行数だけで金額を示す初回提案には、注意が必要です。提案書で、調査や移行の前提を確かめます。

調査：現行資産と未使用機能の洗い出し。
移行：業務ヒアリングと移行単位の提示。
品質：テスト方針、データ移行、切り戻し計画。
前提：リスクと前提条件の明記。

診断を2〜6週間程度の独立した工程にして、診断後に本開発へ進む条件を決めておくと、見積もりの精度を高められます。

成果物・契約・保守の責任分界

契約時には、次の3点を具体化します。

成果物：ソースコード、設定、設計書、テストコード・結果、インフラ定義、第三者ライブラリ一覧、脆弱性対応履歴。
契約条件：準委任か請負か、仕様変更、障害判定、対応時間、再委託、知的財産権。
終了時の引き継ぎ：技術移転と運用手順の作成を納品条件に含め、別の担当者も保守できる状態にしておきます。

▶ 詳細はこちら：Seasar2のシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Seasar2のシステム開発の発注/外注/依頼/委託方法について

ポイント

新規開発の実績に加えて、既存システムを読み解く力と移行後の保守体制で比べます。Seasar2の構成要素ごとの経験の有無も判断材料になります。

移行前後のセキュリティと運用チェック

移行は、フレームワークの置き換えだけでなく、認証と認可、入力値検証を見直す機会です。ログ、通信、データ保護に加え、委託先管理も見直す対象になります。

移行中は旧環境と新環境が並行して動くため、通常時より、アクセス経路と権限を厳しく管理します。

依存関係・認証・入力値の点検

次の観点で点検し、対応の漏れを防ぎます。

依存関係：ライブラリとJDKの脆弱性、サポート期限、更新方法。
認証・認可：管理者と一般利用者の権限分離、セッション、多要素認証の必要性、パスワード保管。
入力・表示：入力値検証、SQLインジェクション、クロスサイトスクリプティング、クロスサイトリクエストフォージェリ。
ファイル・エラー：ファイルアップロードとエラーメッセージ経由の情報漏えい。

監査ログ・バックアップ・復旧の設計

監査ログ、バックアップ、移行前のデータ保全は、次の点を決めておきます。

監査ログ：誰がいつ何を変更したかを追えるよう設計します。改ざん防止、保存期間、閲覧権限を決めます。
個人情報のマスキング：監査ログとあわせて決めておきます。
バックアップ：取得に加えて、復元テストを定期的に行い、目標復旧時間と目標復旧時点を満たすかを確かめます。
移行前のデータ保全：元データをバックアップし、照合用の件数と金額の集計を保存しておきます。移行後の差分を説明できるようにするためです。

法令・監査・委託先の要件

法令や監査への対応は、次の点を押さえて進めます。

個人情報の取り扱い：扱う場合は、個人情報保護法のガイドラインを確認します。
電子取引データや帳簿：扱う場合は、電子帳簿保存法の要件を、法務・経理・税務の担当者と一緒に確かめます。
システム要件：保存期間、検索性、改ざん防止を含めます。権限、操作履歴、出力形式も、要件に入れます。
法令対応の分担：開発会社に任せきりにせず、自社の業務ルールとシステムが実装する機能を分けて合意します。

よくある質問（FAQ）

Seasar2を保有する担当者から寄せられることの多い疑問に、判断の条件を添えて回答します。

自社の規模や停止条件に当てはめて検討してください。

Seasar2は今も使えますか？

技術的には稼働し続けることもありますが、公式サポートの終了後であるため、新規採用は慎重に判断します。

既存システムを短期間使う場合も、構成と脆弱性を調べ、移行期限と暫定対策を決めます。

Springへ移行すると何が変わりますか？

DIや共通処理、Web層が変わります。

データアクセス、設定、テストの方法も変わります。

業務データやルールは、移行で必ず失われるとは限りません。ただし、仕様がコードに埋め込まれている場合は、要件を可視化し、旧新比較テストで確認します。

移行するとデータはそのまま使えますか？

多くの場合は既存データを移行できますが、文字コードや日付、NULLの扱いを確認します。コード体系、桁数、履歴も確かめます。

削除データ・添付ファイル・暗号化：扱いも対象になります。
件数・金額・状態：移行前後で照合します。
本番移行前の準備：本番移行の前に、バックアップと切り戻し手順を用意しておきます。

何社に見積もりを取ればよいですか？

比較できるよう要件をそろえたうえで、2〜3社程度に診断または概算を依頼するのが現実的です。

調査範囲、テスト計画、担当者の経験は、同じ基準で比べます。成果物、保守、追加費用も、同じ基準に含めます。

要件が不明なまま総額だけで競わせると、後から前提条件が変わりやすくなります。

移行しない場合に最低限すべきことは何ですか？

現行資産、依存ライブラリ、JDKを一覧にします。そのうえで、実行環境と外部連携、アカウント、バックアップを洗い出します。

アクセス制御と監視も強化します。

脆弱性対応方針、障害時の連絡先、復旧手順を文書にまとめます。保守担当の引き継ぎも文書に残し、延命期限と移行判断の条件を経営層と共有します。

まとめ

Seasar2のシステムは業務を支えてきました。一方で、公式EOL後は、保守と脆弱性、人材、実行環境にリスクがあります。

まず、SAStruts、S2Dao、diconなどの資産と、JavaやOSなどの実行環境を棚卸しします。そのうえで、業務知識を保つ移行計画を作ります。

自社に合う選択肢の決定

短期延命や段階移行、Spring刷新、パッケージ・SaaS置換には、それぞれ向き不向きがあります。

停止できる時間、独自性、データ量で比べます。さらに、将来の変更、予算、保守体制も比べる材料になります。判断は総保有コストで行い、診断や旧新比較、切り戻しに加えて、移行後の保守も見ます。

診断と比較の準備

発注前に、現行構成、画面・帳票・バッチ、ソース規模を整理します。外部連携と停止可能時間、データ移行、希望する移行先も、書き出しておきます。

必要なテストと保守条件も、あわせてまとめます。その資料をもとに2〜3社から提案を受けます。価格だけでなく、Seasar2の読解力と業務理解、テスト、成果物、責任分界も見ることが第一歩です。

▼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を創業。