LASSIC Media らしくメディア
Seasar2からの移行先と移行を判断する4つのポイント
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- Seasar2本体と主な周辺プロダクトは2016年9月26日にEOLとなり、プロジェクトによる保守は終わっています。
- 移行先はSpring BootやJakarta EE、データベース部分だけならDomaやDBFluteなど、置き換える範囲で選びます。
- 移行の判断は、使っている部品・Javaとサーバーの版・置き換える範囲・確かめ方の4点から始めます。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
Seasar2で作った業務システムがいまも動いているが、中身を分かる担当者が少なくなってきた。Javaやサーバーの更新を求められても、フレームワークが対応しているかどうか分からない——。Seasar2で作られた社内システムでは、こうした悩みが起こりがちです。Seasar2は、Javaで業務アプリケーションを作るためのフレームワークで、すでにプロジェクトによる保守は終わっています。
保守が終わっても、システムがその日に止まるわけではなく、急いで作り直すことだけが正解でもありません。本記事では、システムの保守や刷新を判断する情報システムの担当者に向けて、保守終了の事実、移行先の選択肢の違い、移行を判断する4つのポイント、使い続ける場合の注意、そして外部に頼むときに確認したい点を整理します。
目次
Seasar2とは
Seasar2は、Seasarプロジェクトが開発したJavaのフレームワーク（アプリケーションを作るための土台となる部品のまとまり）です。2004年3月にDI・AOPコンテナとして公開されました。*1 DI（部品どうしのつなぎ方を外から設定する仕組み）とAOP（ログ出力などの共通の処理を後から差し込む仕組み）を支える軽量な土台で、画面やデータベースを扱う周辺のプロダクトと組み合わせて使います。
- 画面側：SAStruts（Strutsを使った開発のためのフレームワーク）やTeedaなど*2
- データベース側：S2JDBCやS2Daoなど
- ライセンス：Apache License 2.0*3
- S2Containerのサイトに載っている最新の版：2014年12月に公開された2.4.48*2
Seasarプロジェクトは、提供するプロダクトの多くを2016年9月26日をもってEOL（提供の終了）とし、メンテナンスとサポートを終えると告知しています。*1 対象から外れたのはDBFlute、Doma、Mayaaなど一部のプロダクトだけで、Seasar2本体やSAStruts、S2JDBCは対象に含まれます。一方で、ドキュメントのサイト、GitHub上のソースコード、Mavenリポジトリ（部品の配布場所）からのダウンロードは、EOLの後も引き続き提供されると案内されています。
移行先の選択肢の違い
Seasar2からの移行先は、システムのどこを置き換えるかで変わります。下の表は、公式の情報で確かめられる事実の違いを並べたものです。どれが優れているかではなく、自社のシステムの事情に合うかどうかで選びます。
| 選択肢 | 位置づけ | 動かす環境の前提 |
|---|---|---|
| Spring Boot | Spring Frameworkの上で動くフレームワーク。システム全体の移行先になる | Java 17以上が必要。Tomcatなどを組み込んで動かすことも、Servlet 6.1以上に対応したサーバーに載せることもできる*4 |
| Jakarta EE | Eclipse Foundationで定められている、Javaの業務アプリケーション向けの標準仕様 | 仕様に対応した製品（アプリケーションサーバーなど）の上で動かす*5 |
| Doma | データベースを扱うためのフレームワーク。SeasarのEOLの対象外 | 最新のメジャー版はJava 17以上。Java 8ならDoma 2を使う*6 |
| DBFlute | データベースを扱うためのフレームワーク。SeasarのEOLの対象外 | 2026年1月にJava 8対応の版が出ている*7 |
| Seasar2を使い続ける | プロジェクトによる保守は終了。資料・ソースコード・配布は公開が続く | いまの環境のまま。新しい版は出ない |
Seasar2のドキュメントは、J2EE 1.4やJava EE 5に対応したアプリケーションサーバーを前提に書かれています。*2 移行先がJava 17以上を求める場合、フレームワークだけでなく、Javaの版とアプリケーションサーバーも同時に新しくすることになります。Javaの版の選び方はJava 17のサポート期限と21 LTS移行の判断軸で扱っています。
移行を判断する4つのポイント
移行するかどうか、どこまで移すかは、次の4つの点を順に確かめると決めやすくなります。
- ポイント1：使っている部品を洗い出す（Seasar2本体のほか、SAStruts、Teeda、S2JDBC、S2Daoのどれを使っているか）
- ポイント2：Javaとアプリケーションサーバーの版を確かめる（移行先の前提に合わせて上げる必要があるか）
- ポイント3：置き換える範囲を決める（全体を一度に移すか、データベースを扱う部分から移すか）
- ポイント4：移行の前後で同じ動きになったことを確かめる方法を決める（画面・帳票・バッチの結果を比べる）
つまずきやすいのはポイント1です。SAStrutsはStrutsを使った開発のためのフレームワークなので、Seasar2と一緒にStrutsの扱いも考える必要があります。*2 Struts側の対応はStruts脆弱性を解消、Spring Boot移行を外注で扱っており、本記事ではSeasar2全体の移行先と判断に絞っています。また、仕様書が古いシステムでは、いまの動きそのものが仕様の代わりになるため、移行の前に比べる対象を残しておきます。
使い続ける場合の注意
すぐに移行できない場合、当面はSeasar2のまま動かすという判断もあり得ます。ドキュメントやソースコードは公開されたままなので、いま動いているシステムが急に止まるわけではありません。*1 ただし、プロジェクトによる修正はもう出ないため、次の点を自社で受け持つことになります。
- 不具合や弱点（脆弱性）が見つかっても、プロジェクトからの修正は出ない
- Javaやアプリケーションサーバーを新しくしたときの動作は、自社で確かめる
- 配布元に頼らず使えるよう、使っている版の部品を社内に保管しておく
- Seasar2を理解している担当者の作業と知識を、文書に残しておく
使い続けるなら、サーバーの保守期限やJavaの版のサポート期限に合わせて、いつまで使うかを決めておくことが大切です。
外部に頼むときに確認しておきたい点
Seasar2の移行や保守を外部に頼むときは、見積もりの前に次の点を確かめておきます。
- Seasar2の経験：SAStrutsやS2JDBCなど、自社が使っている部品を扱った経験があるか
- 調査の進め方：使っている部品と、Javaやサーバーの版をどう洗い出すか
- 移行前後の比べ方：画面・帳票・バッチの結果を何で比べるか
- 移行中の保守：移行が終わるまでの間、いまのシステムの不具合対応を誰が受け持つか
- 移行後の運用：新しいフレームワークの版の更新を誰がいつ行うか
移行と保守を別の会社に分けると、同じ不具合を新旧の両方で直す作業が二重になることがあります。レガシーシステム全体を刷新する場合の費用の考え方はレガシーシステム刷新の費用相場にまとめています。
まとめ：Seasar2の移行で確かめておきたい3つの点
Seasar2の移行を考えるうえで、確かめておきたい点は3つに整理できます。第一に、Seasar2本体や周辺のプロダクトの保守がすでに終わっていることを前提に、自社が使っている部品を洗い出すこと。第二に、移行先の前提に合わせて、Javaとアプリケーションサーバーの版も一緒に見直すこと。第三に、すぐに移行しない場合も、修正を自社で受け持つ体制と移行の期限を決めておくことです。この3点を踏まえておけば、「サーバーを更新する直前になって、Seasar2が動くかどうか分からない」という事態を避けやすくなります。調査や移行の進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
Seasar2のまま新しいJavaの版で動かせますか
Seasar2のドキュメントは、J2EE 1.4やJava EE 5の時代のサーバーを前提に書かれています。*2 プロジェクトの保守は終わっているため、新しいJavaの版で動くかどうかは、自社のテスト環境で確かめる必要があります。
移行にはどのくらいの期間がかかりますか
システムの規模、使っている部品の数、移行の前後で比べる画面や帳票の数によって大きく変わります。まず部品の洗い出しと、比べる対象の一覧を作ると、期間の見積もりが立てやすくなります。
保守が終わったSeasar2の部品はどこから手に入りますか
EOLの後も、ソースコードはGitHubで、部品はMavenリポジトリから引き続き提供されると案内されています。*1 使っている版の部品は、社内にも保管しておくと確実です。ライセンスの条件の個別の解釈は、契約や法務の担当者に確かめてください。
Seasar2で作られたシステムの移行のご相談
Seasar2で作られたシステムの部品の洗い出しから、移行先の選定、移行中の保守まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：The Seasar Project 公式サイト（トップページ「EOLについて」）（https://www.seasar.org/）。出典：2016年9月26日をもってのEOL、EOLの対象外のプロダクト、EOL後もドキュメント・GitHubのソースコード・Mavenリポジトリが提供されること、Seasar2の公開（2004年3月）の記述を参照（2026年10月確認）
- *2 参考：Seasar2（S2Container）ドキュメント「Welcome」「セットアップ」、SAStruts 公式サイト（https://s2container.seasar.org/2.4/ja/）。出典：プレゼンテーション層（SAStruts・Teeda）と永続化層（S2JDBC・S2Dao）の組み合わせ、2.4.48の公開（2014年12月）、J2EE 1.4・Java EE 5対応のサーバーを前提にした設定方法、SAStrutsの説明（https://sastruts.seasar.org/）を参照（2026年10月確認）
- *3 参考：The Seasar Project「Seasarファウンデーションソフトウェアライセンス」（https://www.seasar.org/license/）。出典：Apache License, Version 2.0 を使用している旨の記述を参照（2026年10月確認）
- *4 参考：Spring Boot Reference Documentation「System Requirements」（https://docs.spring.io/spring-boot/system-requirements.html）。出典：必要なJavaの版（Java 17以上）、Spring Frameworkが必要なこと、組み込みのサーブレットコンテナ（Tomcat等）とServlet 6.1以上に対応したコンテナへの配置の記述を参照（2026年10月確認）
- *5 参考：Eclipse Foundation「Jakarta EE」（https://jakarta.ee/about/jakarta-ee/）。出典：Jakarta EEがベンダーに依存しない業務向けJavaの標準仕様であること、仕様に対応した製品の記述を参照（2026年10月確認）
- *6 参考：domaframework/doma（GitHub）（https://github.com/domaframework/doma）。出典：データベースアクセスのフレームワークであること、最新のメジャー版がJava 17以上に対応しJava 8ではDoma 2を使う旨、ライセンス（Apache-2.0）を参照（2026年10月確認）
- *7 参考：DBFlute 公式サイト（https://dbflute.seasar.org/）。出典：DBFlute-1.3.1（Java8対応）のリリース（2026年1月1日）の記述を参照（2026年10月確認）
