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

Seasar2のシステムは、Javaで業務Webシステムを構築するために広く使われたフレームワークですが、現在は公式サポートが終了しているため、新規採用よりも既存資産の棚卸しと段階的な移行・刷新を判断することが重要です。

「今も稼働しているSeasar2をいつまで使えるのか」「Springなどへ移行すると何が変わるのか」「費用や期間はどれくらいか」「開発会社やサービスをどう選べばよいのか」と悩む方に向けて、Seasar2の構成、EOL後のリスク、選択肢、進め方、費用相場、発注時の確認事項、セキュリティ、FAQまでを一つにまとめます。

Seasar2のシステムとは何ですか？

Seasar2は、Javaによる業務Webシステムの開発で利用されてきた軽量なフレームワークとDIコンテナの組み合わせです。画面、業務ロジック、データベース、共通処理を分けて管理しやすくする設計が特徴で、販売管理、契約管理、社内申請、顧客管理などのシステムに組み込まれてきました。

S2Containerが担うDIとAOP

中心的な部品であるS2Containerは、Dependency Injection（DI）とAspect Oriented Programming（AOP）を支援します。DIでは、サービス、DAO、設定などの依存関係をコンテナが組み立てるため、業務クラスが他のクラスを直接生成する処理を減らせます。AOPでは、トランザクション、ログ、認証など複数の機能に共通する処理を業務ロジックから分離しやすくなります。

SAStruts・S2Dao・S2JDBCの役割

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やJDK、Servlet・JSP、アプリケーションサーバー、データベース、OS、ビルドツール、ログ出力、認証方式、外部API、ジョブ管理、バックアップを一覧にします。どれか一つが古いまま残ると、フレームワークを移行しても脆弱性やサポート切れが解消されないため、依存関係を一枚の構成図にまとめることが出発点です。

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

移行で最も大きな失敗は、画面を新しくしたのに業務の意味が失われることです。締め処理、休日計算、例外的な承認、請求金額の丸め、帳票の出力条件などは、ソースコードやSQL、バッチに埋め込まれている場合があります。仕様書が不足しているシステムでは、担当者へのヒアリング、過去障害の確認、旧システムの実データを使った現新比較を診断工程に含めます。

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

2026年の情報セキュリティ10大脅威では、組織向けに「システムの脆弱性を悪用した攻撃」や「サプライチェーンや委託先を狙った攻撃」が挙げられています（出典: IPA「情報セキュリティ10大脅威2026」、2026年）。Seasar2の延命や移行を外部に委託する場合は、脆弱性の調査・報告・修正の分担、再委託の可否、ソースコードやテスト成果物の引き渡し、契約終了時の引き継ぎを契約書に明記します。

Seasar2のシステムをどうするか？4つの選択肢

選択肢は、すぐに全面再構築するか、何もせず使い続けるかの二択ではありません。業務の重要度、停止できる時間、変更頻度、データ量、担当者の有無、予算、将来の拡張を基準に、延命、部分移行、全面刷新、パッケージ・SaaSへの置換を比較します。

短期的に延命する

業務停止が難しく、移行準備に時間が必要な場合は、現行環境を隔離し、アクセス制御、監視、バックアップ、脆弱性診断、ログ保全を強化して短期的に延命します。ただし、延命は恒久対策ではありません。何年延命するのか、どの条件で次の移行工程へ進むのかを経営判断として決め、保守できる技術者がいなくなる前に診断を始めます。

機能単位で段階的に移行する

全面刷新のリスクを抑えるなら、画面や業務機能を一つずつ新しい構成へ移す方法が向いています。例えば、参照系の画面から移し、次に登録・更新、最後に締め処理や外部連携へ進めます。旧システムと新システムを一定期間並行稼働させ、APIやデータ連携の境界を明確にすることで、業務を止めずに知見を蓄積できます。

Springなどへ刷新する

既存の業務を維持しながら保守性を高める場合は、Spring MVCやSpring Bootなど現行のJavaエコシステムへ移行し、データアクセスを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万円程度が一つの目安です。小規模な業務Webシステムの部分移行は300万〜1,500万円、期間は3〜8か月程度です。複数アプリ、S2DaoやS2JDBC、バッチ、帳票、外部API、権限、データ移行を含む中規模の刷新では1,200万〜4,000万円、6〜15か月程度を見込みます。複数部門や24時間運用、並行稼働、厳格な監査を含む大規模・基幹系では3,000万円〜1億円超、12か月から数年に及ぶ場合があります。

一般的なシステム開発の人月単価は60万〜200万円程度とする2026年の公開情報があります（出典: 2026年版のシステム開発費用相場に関する公開情報、2026年）。ただし、これはSeasar2移行の価格を保証する数字ではありません。EOL調査、旧新比較、データ移行、プロジェクト管理、セキュリティ確認が加わるため、単純な新規CRUD開発より高くなると考えます。

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

公開された移行事例には、Seasar 2.4とS2Daoを使ったWebアプリケーション3本、約300メソッド、約16万ステップを、約20人月、約5か月で移行した例があります。これは特定案件の実績値であり、すべてのシステムに当てはまるものではありません。それでも、20人月に人月単価60万〜200万円を掛けると1,200万〜4,000万円となるため、規模感を考える起点になります。中間の80万〜150万円で計算すれば1,600万〜3,000万円です。

見積書では、調査、要件定義、変換・実装、テスト、データ移行、リリース、教育、保守を分けて確認します。クラウド利用料、ライセンス、脆弱性診断、監視、バックアップ、旧環境の並行稼働が別費用になっていないか、追加変更の単価と上限が明示されているかも確認します。

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

移行後も、保守、監視、バックアップ、脆弱性診断、OSやJavaの更新、障害対応、追加改修の費用が発生します。初期開発費の年15〜25％を保守費の仮置きにすることはありますが、サポート範囲や対応時間によって変わるため、月額だけで比較しないことが大切です。EOLフレームワークを延命する場合は、対応できない脆弱性、担当者の退職、復旧不能の停止時間など、金額に表れにくい事業継続コストも含めて判断します。

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

Seasar2の案件では、新規開発の実績だけでなく、既存システムの読み解きと移行後の保守体制が重要です。「Seasar2に詳しい」と書かれているかだけでなく、SAStruts、S2Dao、dicon、JSP、バッチ、外部連携、データベース、Java、アプリケーションサーバーをどこまで扱えるかを質問します。

構成要素別の経験を確認する

実績を聞くときは「Seasar2の経験がありますか」だけで終わらせず、S2Daoから別のデータアクセス方式へ移した経験、diconや独自インターセプターを読み解いた経験、JSPや帳票を含む画面移行、バッチと外部APIの検証、旧新比較テストの実施内容を確認します。公開できる範囲で、対象規模、期間、体制、担当範囲、移行後の障害対応まで説明できるかが判断材料です。

診断と提案の具体性を比較する

初回提案で、ソース行数だけから金額を出す事業者には注意が必要です。良い提案には、現行資産の調査項目、未使用機能の切り分け、業務ヒアリング、移行単位、テスト方針、データ移行、切り戻し、リスクと前提条件が書かれています。診断を2〜6週間程度の独立した工程にし、診断後に本開発へ進む条件を決めると、見積もりの精度を高められます。

成果物・契約・保守の責任分界を明記する

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

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

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

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

Seasar2からの移行は、フレームワークの更新だけでなく、認証、認可、入力値検証、ログ、通信、データ保護、委託先管理を見直す機会です。移行期間中は旧環境と新環境が並行して存在するため、通常時よりもアクセス経路と権限を厳密に管理します。

依存関係・認証・入力値を点検する

依存ライブラリとJDKを一覧化し、既知の脆弱性、サポート期限、更新方法を確認します。認証・認可では、管理者権限と一般権限の分離、セッション管理、多要素認証の必要性、パスワードの保管方法を点検します。入力値検証、SQLインジェクション、クロスサイトスクリプティング、クロスサイトリクエストフォージェリ、ファイルアップロード、エラーメッセージの情報漏えいもテスト項目に含めます。

監査ログ・バックアップ・復旧を設計する

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

法令・監査・委託先の要件を落とし込む

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

よくある質問（FAQ）

Seasar2のシステムを保有する担当者から特に多い疑問を、判断条件と合わせて回答します。結論だけでなく、自社の規模や停止条件に当てはめて検討してください。

Seasar2は今も使えますか？

技術的に稼働し続けることはありますが、公式サポートが終了しているため、新規開発への採用は慎重に判断します。既存システムを短期的に使う場合も、構成と脆弱性を調査し、移行期限と暫定対策を決めておくことが安全です。

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

DI、共通処理、Web層、データアクセス、設定方法、テスト方法が変わります。業務データや業務ルールを必ず失うわけではありませんが、旧システムの仕様がコードに埋め込まれている場合は、移行前に業務要件を可視化し、旧新比較テストで結果を確認する必要があります。

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

多くの場合は既存データを移行できますが、文字コード、日付、NULL、コード体系、桁数、履歴、削除データ、添付ファイル、暗号化の扱いを確認する必要があります。移行前後の件数・金額・状態を照合し、バックアップと切り戻し手順を用意してから本番移行を実施します。

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

比較可能な要件をそろえたうえで、2〜3社程度に診断または概算を依頼するのが現実的です。金額だけでなく、調査範囲、テスト計画、担当者の経験、成果物、保守、追加費用の条件を同じ基準で比較します。要件が不明な段階で総額だけを競わせると、後から前提条件が変わりやすくなります。

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

現行資産、依存ライブラリ、JDK、実行環境、アカウント、外部連携、バックアップを棚卸しし、アクセス制御と監視を強化します。脆弱性への対応方針、障害時の連絡先、復旧手順、保守担当者の引き継ぎを文書化し、延命の期限と移行判断の条件を経営層と共有してください。

まとめ

Seasar2のシステムは、過去に多くの業務を支えてきた一方で、公式EOL後の保守・脆弱性・人材・実行環境のリスクを抱えています。最初にSAStruts、S2Dao、dicon、JSP、バッチ、外部連携、データベース、Java、OSまでを棚卸しし、業務知識を失わない移行計画を作ります。

自社に合う選択肢を決める

短期延命、機能単位の段階移行、Springなどへの刷新、パッケージ・SaaSへの置換には、それぞれ向き不向きがあります。業務停止の許容時間、独自性、データ量、将来の変更、予算、社内の保守体制を基準に比較し、診断工程、旧新比較テスト、切り戻し、移行後保守までを含めた総保有コストで判断します。

まずは診断と比較の準備から始める

発注前には、現行構成、画面・帳票・バッチ、ソース規模、外部連携、停止可能時間、データ移行、希望する移行先、必要なテスト、保守条件を整理します。その資料をもとに2〜3社から提案を受け、会社名や価格だけでなく、Seasar2の構成要素を読み解く力、業務理解、テストの具体性、成果物、責任分界で比較することが、失敗しない第一歩です。