Seasar2のサポート終了から10年。後継の選び方と移行の費用・期間の考え方

Seasar2のサポートは2016年9月に終了し、2026年9月で10年になります。2000年代後半から2010年代前半に国内で広く採用されたフレームワークなので、基幹システムや社内の業務システムとして今も動いている例は珍しくありません。10年動き続けてきたのだから、もうしばらくは大丈夫ではないか。そう考えるのは自然です。

ただ、いつまで使えるかを決めているのは、開発が止まったSeasar2本体よりも、その下で動くJava 8とアプリケーションサーバーの期限です。延命・移行・再構築のどれを選ぶかは、この期限とコードを実測した規模を並べれば判断でき、どちらも今から調べられます。

Seasar2と周辺プロダクトのサポート状況

Seasar2は、DI(部品同士の依存関係をフレームワーク側で組み立てる仕組み)とAOPを核にした国産のJavaフレームワークです。Seasarプロジェクトの公式サイトは、提供するプロダクトの多くが2016年9月26日をもってEOL(End of Life)になったと告知しています。以後は脆弱性が見つかっても修正版は出ません。終了は2015年秋の最後のSeasar Conferenceで1年前に予告され、開発者は後継フレームワークをあえて指名しませんでした。公式な移行先は今もありません。

本体のS2Containerの最終版は2014年12月の2.4.48です。GitHubに残るビルド設定では本体はJava 1.4向けにコンパイルされていて、設計の世代はJava 1.4から5の時代のものです。周辺プロダクトも同じ日に終わっています。とくにWeb層のSAStrutsはStruts 1.2.9に依存していて、そのStruts 1自体が2013年4月にサポート終了を宣言済みです。

例外はSeasarプロジェクト発のDomaとDBFluteで、この2つは今も開発が続いています。Javaのバージョンは、現実的な上限をJava 8と考えてください。Java 8で動かすだけでも古い同梱ライブラリの差し替えが必要だったという報告が2016年と2018年に出ています。Java 11以降での動作を裏付ける公式情報はなく、動かせたとしても保証はありません。

使い続けた場合のリスク

Seasar2のシステムが明日突然止まるわけではありません。問題は、周囲の環境が更新されるたびに選択肢が減っていくことです。

稼働環境の期限：
Java 8は、Oracleの有償サポートの第一段階(Premier Support)が2022年3月に終わり、延長サポートも2030年12月までです。OpenJDKを配布するEclipse TemurinもJava 8の提供を少なくとも2030年12月まで続ける計画で、Java 8自体はすぐには消えません。先に切れるのはアプリケーションサーバーで、Tomcat 8.5は2024年3月末でサポートが終了しました。サーバー更新やクラウド移行のたびに、古い環境を残すための手間が増えていきます。

修正されない脆弱性：
Seasar2本体は2016年から、SAStrutsが依存するStruts 1は2013年から、脆弱性が見つかっても修正されていません。同じ時代のライブラリも一緒に固定されている例が多く、一つだけ上げようとすると他が連鎖的に動かなくなります。外部に公開している画面があるシステムでは、これが最も直接的なリスクです。

技術者の減少：
Seasar2を新しく学ぶエンジニアはほとんどいません。構築時の担当者や保守ベンダーの技術者が離れると、次に触る人は何も知らない状態からdiconファイルと命名規約を読み解くことになります。

改修費用の上昇：
画面に項目を一つ足すような改修でも、どの部品がどこから呼ばれているかを調べる時間が先にかかり、見積が膨らみます。ドキュメントが古く、ライブラリも上げられない状態が続くほど、この調査の比重は大きくなり、いずれ移行のための調査を担える人も見つけにくくなります。

この構図はサポートが終了したFuelPHPなど他のフレームワークと共通です。Javaに特有なのは、フレームワーク、Java本体、アプリケーションサーバーの3層が別々の期限を持つことで、棚卸しでは3層を分けて見る必要があります。

延命、移行、再構築の選び方

Seasar2のシステムをどうするかは、延命、移行、再構築の3つから選ぶことになります。

延命は「何もしない」ことではありません。ネットワークの分離やコンテナ化で古い環境を閉じ込めたうえで、期限を決めて使う方法です。廃止が決まっているシステムには合っていますが、期限を決めずに延命すると、Java 8やサーバーのサポートが切れた時点で、準備のないまま移行を迫られます。

移行はいわゆるリライトで、画面も帳票も業務ルールもそのままに、フレームワークをSpring Bootなどへ置き換えます。方式ごとの費用の違いはシステムマイグレーションの費用相場で、規模別の期間と工程の内訳はシステムマイグレーションの期間で整理しています。Seasar2の場合、工数は行数だけでは決まりません。画面の数はWeb層とテンプレートの書き換え量に、外部SQLファイルの数はデータベースアクセス層の作り直しの量に、diconファイルの数はDI設定を明示的に書き起こす量に、それぞれ直結します。外部連携の数も含め、いずれも後述の棚卸しで実測できます。

再構築は業務そのものを見直す場合の選択肢です。使われていない画面が半分以上あるような状態なら作り直したほうが早いこともありますが、要件定義からやり直すため費用も期間も最も大きくなります。

3つは排他ではなく、移行を軸にしながら使っていない機能を落とし、一部の画面だけ再設計するように組み合わせることもできます。

後継となるSpring Boot

Javaのまま移行するなら、移行先はSpring Bootが第一候補になります。Seasar2とSpringは同じ時代にDIとAOPを軸に生まれ、部品を登録して依存関係を注入する考え方が共通しているので、設計を組み替えずに置き換えやすい組み合わせです。求人も技術情報もSpring Bootが中心で、移行後の保守を引き継げる技術者も探しやすくなります。開発も活発に続いていて、Spring Bootは2025年11月に4.0、2026年6月に4.1がリリースされ、メジャーバージョンは3年以上、マイナーバージョンは12か月以上サポートする方針が公開されています。現行の4.1系はJava 17以降で動作し、最新のLTSであるJava 25にも対応しています。

Seasar2の部品とSpring Bootの対応関係

置き換えの難所

DI設定とトランザクションの置き換え：
Seasar2はdiconファイルとSMART deployの規約で部品を自動登録していました。命名規則に従えば設定なしで動く反面、どの部品がどこで使われているかがコードに明示されていません。暗黙の登録関係を明示的な設定に起こす作業は、規約に頼っていたシステムほど重くなります。トランザクションも同じで、SMART deployではcustomizer.diconに書いた命名規則でクラスをまとめてトランザクションの対象にできます。Spring Bootでは@Transactionalを付けたクラスやメソッドを対象にするのが一般的で、既定でロールバックするのは非検査例外のときだけです。どのメソッドにトランザクションがかかり、どの例外でロールバックしていたかを洗い出さずに置き換えると、エラー時に更新の一部だけが残る不具合につながります。

S2JDBCの自動生成と外部SQL：
S2JDBC-Genで生成したエンティティや、SQLファイルの中に条件分岐を書く2Way SQLは、Spring Data JPAに直接の対応物がありません。SQLを書き直すか、SQLをほぼそのまま使えるMyBatisやDomaへ寄せるかは、移行前に決めておく設計判断です。Domaを選んでもSQLコメントで書いた条件分岐の記法は異なり、MyBatisではXMLの条件要素に書き直すことになるため、SQLファイルの数だけ記法の変換が発生します。実際に移行した企業の技術ブログでも外部SQLの扱いが壁になったと報告されています。

SAStrutsの規約とライフサイクル：
SAStrutsのアクションはリクエストごとに生成され、画面の入力値をフィールドで直接受け取る作りです。Spring MVCのコントローラーは既定で一つのインスタンスを全リクエストで共有するため、入力値をフィールドに持たせたまま移すと、同時に届いたリクエストの値が混ざります。入力値はメソッドの引数やフォームのオブジェクトで受け取る形に改めることになり、@Executeなど独自アノテーションの置き換えとあわせて画面ごとに手が入ります。

Javaそのものの世代差：
Java 11ではJAXBなどJava EE由来のモジュールが標準から外れ、Spring Boot 3以降はjavax.*からjakarta.*へパッケージ名が変わりました。フレームワークの移行と同時にJavaを8から17や21へ上げることになるため、言語レベルの修正も工数に見込む必要があります。

移行の進め方とAIの使いどころ

Seasar2からの移行では、Javaのバージョンアップとフレームワークの置き換えが同時に起き、その中に画面テンプレートの書き換えとデータベースアクセス層の作り直しが含まれます。当社では、延命か移行かを議論する前に、コードを解析して前の節で挙げた画面やSQLファイル、diconファイルの数と、使われていない機能を実測することをお勧めしています。この数字がないまま議論しても、費用の桁が決まらないためです。見積の内訳と根拠の読み方は別の記事で整理しています。

移行に入る場合、AIが担うのはSeasar2固有の仕組みを新しいフレームワークの流儀に置き換える変換です。diconの暗黙の登録関係をSpringの設定に起こす作業も、SAStrutsのアクションをコントローラーに書き換える作業も、2Way SQLをMyBatisやDomaの記法に直す作業も、変換の規則は決められる一方で対象の数が多く、AIに向いています。Java 8時代の書き方を17以降に合わせる修正も同様です。人が担うのは、変換結果のレビュー、業務上どちらの挙動が正しいかの判断、受け入れテストです。Struts系からSpring Bootへの移行は、当社の対応パターンにも含めています。

当社が公開している移行実績は、ウイズ・ワンと共同で行ったPHPのFuelPHPからLaravelへの移行で、Seasar2の移行実績はまだありません。その案件は変換対象約25万行のシステムを、従来手法の見積と比べて金額・工期を約60%削減して移行したもので、フレームワークのサポート終了をきっかけにした点はSeasar2と同じです。ただ、言語もフレームワークも違うため、この削減率をSeasar2にそのまま当てはめることはできません。そのため実績の少ない構成では無料診断を通常より厚めに実施し、代表的な画面と処理をサンプル変換して技術的に適用できることを確かめてから、次の工程に進むかどうかをご判断いただきます。対応が難しい場合は、その旨をそのままお伝えします。

判断の前に行う棚卸し

依存関係の一覧化：
Seasar2本体と周辺プロダクトのバージョン、Java、アプリケーションサーバー、データベースとJDBCドライバー、OSを一覧にし、サポート状況、後継候補、移行の難易度を書き込みます。次の表はそのサンプルです。

※実案件のものではなく、当社で作成したサンプル資料です。

一覧にすると、Javaにはまだ更新があるのにTomcatが先に切れる、といった層ごとの期限の違いが見えます。最初に来る期限が移行時期の上限です。

Javaバージョンと稼働環境の確認：
本番のJavaのバージョンと配布元、セキュリティ更新が当たっているかを確認します。Oracle JDK 8の更新は2019年4月以降、商用利用では有償契約が前提です。

仕様書の有無と鮮度の確認：
設計書が残っているか、現行のコードと一致しているかを確認します。仕様書がなくても移行は進められますが、業務上の正解を判断できる担当者は必要です。進め方は仕様書がないシステムはAIで移行できる？で解説しています。

移行の要否と時期の判断：
棚卸しで分かった最初の期限と、システムをあと何年使うかを突き合わせ、延命・移行・再構築のどれにするか、いつまでに切り替えるかを決めます。切替日は決算期や繁忙期を避ける必要があり、そこから開発とテストの期間を逆算すると、着手時期は想定より前倒しになります。

まとめ

最初に確かめるのは、自社のシステムでフレームワーク、Java、アプリケーションサーバーのどの期限が最初に来るかと、そのシステムをあと何年使うかの2点です。数年で廃止するなら期限を決めて延命し、業務のやり方を変えたいなら再構築を選びます。どちらでもなく、この先も同じ業務で使い続けるなら、Spring Bootへの移行が候補になります。移行を選ぶ場合は、画面、外部SQLファイル、diconファイルの数を数えると、費用の桁の見当がつきます。

DEN-NOのAIマイグレーションサービスでは、NDA(秘密保持契約)を締結のうえシステム概要とソースコードの一部をお預かりし、無料診断を行っています。Seasar2のように当社の移行実績が少ない構成では、代表的な画面と処理をサンプル変換し、Spring Bootへの置き換えが技術的に可能かを実際のコードで確かめたうえで、現状リスクと移行可能性をまとめた診断レポートと概算費用をご提示します。仕様書・設計書のご準備は必須ではありません。

AIマイグレーションサービスの詳細はこちら

よくある質問

Q. Seasar2のまま、Javaだけを17や21に上げることはできますか？

Java 8で動かすだけでも依存ライブラリの差し替えが必要だったという報告があり、それ以降の動作に保証はありません。動かせたとしてもフレームワークの更新が止まっている状況は変わらないため、Javaのバージョンアップが目的であっても、フレームワークの移行とあわせて検討することをお勧めします。

Q. Spring Boot以外の移行先はありますか？

Java EEの後継であるJakarta EE 11準拠のアプリケーションサーバーへ移す方法や、DIコンテナをGoogle Guiceに、データベースアクセスをDomaに置き換えるように部品ごとに入れ替える方法もあります。ただし情報量と人材の面でSpring Bootが有利です。

Q. 移行の費用と期間はどのくらいかかりますか？

規模と状態によって異なります。規模別の相場観は費用相場と期間の目安の記事にまとめています。Seasar2の場合は画面数や外部SQLファイル数も工数を左右するため、無料診断でコードを実測してから概算をご提示します。

Q. Seasar2の移行実績はありますか？

Seasar2からの移行を公開事例としてお見せできる案件は、まだありません。公開している実績はFuelPHPからLaravelへの基幹システム移行で、同じくフレームワークのサポート終了を理由にした案件として参考値にはなります。無料診断を通常より厚めに行い、サンプル変換で適用可能性を確かめてから、次の工程に進むかをご判断いただいています。