Seasar2はサポート終了から10年：SAStruts・S2JDBCで作られた業務システムの現在地

Seasar2は、2016年9月26日にサポートを終了しました。本稿の時点で、ちょうど10年が経過したことになります。

それでもなお、Seasar2とその関連プロダクトであるSAStruts・S2JDBCで構築された業務システムは、国内で数多く稼働し続けています。2000年代後半、Seasar2は国産のJavaフレームワークとして広く採用され、会員数百万規模のサイトや複数拠点にまたがる業務システムでの導入実績がありました。当時に構築されたシステムの多くが、現在も現役です。

2026年9月、改めて注目が集まった背景

2026年9月下旬、大手カーシェアリングサービスで約660万件のアカウント情報が第三者に取得されたことが公表されました。この事案では、外部の技術者がサイトの公開HTMLを調べ、Seasar2の一部であるTeedaの痕跡と、2008年公開の古いjQueryが読み込まれていることを指摘しました。この指摘はSNSで大きく拡散しています。

ただし、本稿の更新時点（2026年10月10日）で、侵入経路と原因は公式に公表されていません。 Seasar2やTeedaが原因だと確認されたわけではなく、Teeda固有の既知の脆弱性も公開データベースでは見つかっていません。

それでもこの指摘が多くの関心を集めたのは、同じ構成の業務システムを抱える企業が少なくないためです。マクニカの集計では、Webシステムからの情報漏えいの公表は2025年の84件に対し、2026年は10月6日時点ですでに119件に達しています。

重要なのは、脆弱性が見つかったときに直す手段があるかどうかです。サポートが終了したフレームワークには、その手段がありません。

自社のシステムでSeasar2やTeedaがどこまで使われているかは、ソースコードを解析すれば短期間で特定できます。無料コード診断では、使用範囲と移行規模の概算をご提示しています。

Seasar2が使われているかを確認する方法

担当者が入れ替わり、使用フレームワークが把握できていないケースも珍しくありません。次の点を確認すれば、Seasar2系のプロダクトが含まれているかを判断できます。

• JARファイル: WEB-INF/lib 配下に s2-framework、s2-extension、s2-tiger（Seasar2本体）、sa-struts（SAStruts）、teeda（Teeda）で始まるファイルがある
• 設定ファイル: app.dicon、convention.dicon、s2jdbc.dicon など、拡張子 .dicon のファイルがある
• 画面: 公開ページのHTMLやJavaScriptに teeda の文字列が含まれている

最後の項目は、外部から誰でも確認できるという点に注意が必要です。攻撃者にとっても、古いフレームワークを使っているサイトを見分ける手がかりになります。

「動いているから問題ない」で済まなくなる理由

Seasar2で動いているシステムに、いま明確な障害が出ているとは限りません。むしろ安定して稼働しているケースのほうが多いはずです。だからこそ後回しにされてきました。

ただし、サポートが終了しているということは、次の状態にあるということです。

• 脆弱性が見つかっても修正されない。 公表されるかどうかにかかわらず、対処の手段がありません。
• 周辺環境の更新に追従できない。 Javaランタイム、アプリケーションサーバ、OSのバージョンアップに際して、動作を保証する主体が存在しません。
• 実装を理解できる技術者が減り続ける。 Seasar2を実務で扱った経験のある技術者は、新たに増えることがありません。

3点目が、実務上はもっとも重い問題になります。システムが壊れたときではなく、それを直せる人がいなくなったときに、はじめて問題として認識されるからです。

典型的な構成

国内でSeasar2が使われている業務システムは、おおむね次のような組み合わせになっています。

コンポーネント	役割	状況
Seasar2	DIコンテナ・AOP	2016年9月26日サポート終了
SAStruts	Webアプリケーションフレームワーク	Seasar2に依存
S2JDBC	データベースアクセス	Seasar2に依存
Apache Struts 1系	併用されている場合がある	2013年4月サポート終了
Teeda	JSFベースのWebフレームワーク	Seasar2と同時にサポート終了
JSP / JSTL	画面	構成による

注目すべきは、サポート終了済みのコンポーネントが複数積み重なっている点です。Strutsの対応を検討したところ、その下でSeasar2も同じ状態にあることが判明する、という順序で問題が発覚することも少なくありません。

Apache Strutsのサポート終了と2026年に公表された脆弱性については、Apache Struts 2.5 サポート終了とCVE-2026-73635で扱っています。

移行の選択肢

Spring Frameworkへの移行

もっとも一般的な移行先です。DIコンテナとしての考え方が近く、S2JDBCからSpring Data JPAやMyBatisへの置き換えも定石があります。画面構成や業務ロジックの構造を維持したまま、基盤だけを入れ替える方針が取れる場合には有効です。

ただし、SAStrutsからSpring MVCへの移行はアクション定義や画面遷移の書き換えを伴い、機械的な置換では完了しません。また、この移行で解決するのはフレームワークの部分だけです。JSPで作られた画面や、Struts 1系が併用されている部分は別途検討が必要になります。

アプリケーション全体の刷新

フレームワークを追いかけるのではなく、システムそのものを現行の技術スタックへ移行する方法です。

次のいずれかに該当する場合、こちらのほうが現実的です。

• サポート終了済みのコンポーネントが複数混在している
• 稼働開始から15年以上が経過し、構築当時の担当者が在籍していない
• 仕様書が現行システムに追いついておらず、コードが唯一の正確な仕様になっている
• 画面が古く、スマートフォンやタブレットでの利用に対応できていない

移行規模は大きく見えますが、サポート終了のたびに発生する対応を繰り返さずに済むため、長期で見ると総コストが下回ることがあります。手法ごとの比較は再構築か、自動変換かで詳しく解説しています。

仕様が残っていないシステムをどう移行するか

Seasar2世代のシステムでもっとも多い課題は、正確な仕様が残っていないことです。構築から十数年が経ち、改修が重なり、ドキュメントは初期のものしかない。結果として、コードだけが唯一の正確な仕様になっています。

この状態で人手による再実装を行うと、長年の運用で積み上がった例外処理や業務ルールが移行の過程で失われます。稼働後になって「以前はできていた処理が通らない」という形で表面化し、収束までに時間がかかります。

日本ビビファイでは、既存のソースコードを解析してシステムの構造と業務ロジックをモデルとして抽出し、そのモデルから新しいアプリケーションを生成するモデル駆動型のアプローチを採っています。人が読み取って書き直すのではなく、構造として引き継ぐ方式です。詳しくはSeasar2やStrutsで書かれたレガシーコードを自動変換するコード変換サービスをご覧ください。

さらに、移行後のシステムが移行前と同じ動作をすることを自動テストで検証します。新旧を突き合わせて結果を比較するため、「動くはず」ではなく「同じ動作をすることを確認した」状態で移行できます。

現状把握から始める

Seasar2のバージョン、SAStrutsやS2JDBC、Teedaの使用範囲、Struts 1系の併用有無、画面数、外部公開の範囲。この5点が整理できれば、対応方針と概算規模は見えてきます。

この整理はソースコードの自動解析によるコード分析サービスで行います。規模・依存関係・サポート終了済みコンポーネントの分布を実数で把握したうえで、移行方式を判断する順序です。これまでの実績は導入事例で紹介しています。

サポート終了から10年が経過した環境を運用されている場合は、無料コード診断をご利用ください。現行コードを解析し、移行対象の全体像と概算の移行規模をご提示します。