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

Seasar2で構築した業務システムが、今も現役で動いている。2000年代後半から2010年代前半に国内で広く採用されたフレームワークですから、こうしたシステムは珍しくありません。サポートは2016年9月に終わり、2026年9月で丸10年になります。Javaは8のまま上げられず、改修を頼める技術者も年々減ってきた。そろそろ手を打たなければと感じている担当者の方は多いはずです。

この記事では、Seasar2と周辺プロダクトの現状を一次情報で確認したうえで、使い続けるリスク、延命・移行・再構築の向き不向き、後継となるSpring Bootへの対応関係と難所、費用と期間の考え方、判断の前に今すぐできる棚卸しの方法を整理します。

Seasar2は本体も周辺プロダクトも2016年で止まっている

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以降での動作を裏付ける公式情報はなく、動かせたとしても保証はありません。

「動いているから大丈夫」が崩れる4つの場面

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ファイルと規約を読み解くことになり、保守は属人化していきます。

改修の単価が上がる。 技術者が減り、ドキュメントが古く、ライブラリが動かせない。この3つが重なると小さな改修にも調査工数が乗り、気づいたときには移行のための調査すら難しくなっています。

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

選択肢は3つ。延命、移行、再構築

Seasar2のシステムをどうするかは、突き詰めると3つの選択肢のどれかになります。

延命は「何もしない」ではありません。ネットワークの分離やコンテナ化で古い環境を閉じ込めたうえで、期限を決めて使う方法です。廃止が決まっているシステムでは合理的ですが、期限を決めない延命は先送りと同じです。

移行はいわゆるリライトで、画面も帳票も業務ルールもそのままに、フレームワークをSpring Bootなどへ置き換えます。方式ごとの費用の違いはシステムマイグレーションの費用相場で、規模別の期間と工程の内訳はシステムマイグレーションの期間で整理しています。Seasar2の場合、工数を左右するのは行数だけではなく、画面の数、外部SQLファイルの数、diconファイルの数、外部連携の数が効いてきます。いずれも後述の棚卸しで実測できます。

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

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の対応関係

対応表どおりには置き換えられない4つの難所

DI設定の置き換え。 Seasar2はdiconファイルとSMART deployの規約で部品を自動登録していました。命名規則に従えば設定なしで動く反面、どの部品がどこで使われているかがコードに明示されていません。暗黙の登録関係を明示的な設定に起こす作業は、規約に頼っていたシステムほど重くなります。

S2JDBCの自動生成と外部SQL。 S2JDBC-Genで生成したエンティティや、SQLファイルの中に条件分岐を書く2Way SQLは、Spring Data JPAに直接の対応物がありません。SQLを書き直すか、SQLをほぼそのまま使えるMyBatisやDomaへ寄せるかは、移行前に決めておく設計判断です。実際に移行した企業の技術ブログでも外部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の形式に変換する、Java 8時代の書き方を17以降に直す。規則はあるが量が多い作業はAIに向いています。人が担うのは、変換結果のレビュー、業務上どちらの挙動が正しいかの判断、受け入れテストです。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で移行できる？で解説しています。

移行の要否と時期の判断。 棚卸しで分かった最初の期限と、システムをあと何年使うかを突き合わせ、延命・移行・再構築のどれにするか、いつまでに切り替えるかを決めます。切替日は業務カレンダーの制約を受けるため、逆算すると着手時期は思ったより早くなります。

まとめ: 期限は3層で見る。判断の材料はコードの中にある

Seasar2は本体も周辺プロダクトも2016年9月に止まり、Java 8と当時のアプリケーションサーバーに縛られたまま10年が経ちました。使い続けるなら期限を決めた延命、この先も使うなら機能を変えないSpring Bootへの移行、業務を変えるなら再構築。判断の材料は、3層の期限とコードを実測した規模の数字です。

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

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への基幹システム移行で、同じくフレームワークのサポート終了を理由にした案件として参考値にはなります。無料診断を通常より厚めに行い、サンプル変換で適応可能性を確かめてから次の工程に進むかを判断いただいています。