AIを使ってSpring-BootアプリケーションをJSF on JBoss EAPに移行する

Red Hat のソリューションアーキテクトの瀬戸です。

最近のAIはすごいですよね。毎月のように新しいモデルが発表され、毎日のように新しい驚きがあります。(再)

前回の AIを使ってJBoss EAP 6.4で動作するStruts 1アプリケーションをJBoss EAP 8.1に移行する - 赤帽エンジニアブログという記事では古いStruts 1アプリケーションをAIを使って最新のJBoss EAP 8.1に移行してみました。続く今回の記事では、Spring BootアプリケーションをJBoss EAP 8.1上のJSFへ移植してみます。

なんでSpring BootをわざわざJBoss EAPへ？

と思われる方も多いでしょう。実は最近、Spring Boot周辺のライセンスや商用サポートモデルの変更（いわゆるMythosの話題など）をきっかけに、「コミュニティサポートのみのOSSのまま運用を続けるのはリスクがある」「Spring Bootの商用サポートは期間やコストの面で要件に合いにくい」といった課題に直面し、Jakarta EEサーバーへの移行を具体的に検討されるお客様が増えています。また、この話題の前からも、同様の理由ですでに移行を進められているお客様もいらっしゃいます。

Jakarta EEサーバーは古臭いとか、重いとか、そういうイメージが付いていますが、実際にはSpring-Bootと比べて明確にパフォーマンスが劣るようなことはありません！今後追加が予定されているJakarta MVCなど、現時点では足りない機能もありますが、自由にライブラリを追加する事もできるので、実用上は十分に強力な選択肢になります。

使用したAI

今回は Claude Sonnet 4.5を使用しています。前回のHaikuよりも高い性能を持つモデルです。現在（2026年）となっては一世代前のモデルにあたります。現行の最新AIであれば、同様のアプローチで移行を進められると推察されます。ただし、どのようなAIでも出来るわけではない点ご注意ください。また、AIの特性上、同じClaude Sonnet 4.5を使っても同じような結果を得られないこともあります。

サンプルアプリケーション

今回は移行元のサンプルとして、お馴染みのSpring PetClinicを使用しました。動的なHTMLの生成からDB アクセスまで一通りの処理が実装されているアプリケーションです。前回の画面だけのものに比べたら実際の業務アプリケーションに近い、実践的な構成と言えます。

また、実際の業務アプリケーションに近いという事で、今回はOSSのPrimeFacesを使って移植をしてみました。PrimeFacesはJSF上で有名なUIライブラリです。簡単にリッチな画面を作ることができます。Red HatではPrimeFacesのサポートは行っておりませんが、有償サポートを契約することも可能です。

移行前のサンプルアプリケーションは以下にあります。

github.com

移行後のサンプルアプリケーションは以下にあります。JBoss EAP 8.1+OpenJDK 21で動作確認をしています。

github.com

なお、今回はせっかくの機会ですので、画面も「JSFらしいモダンな見た目」にリニューアルしてみました。*1

移行の指示

今回も前回と同様、以下のようなシンプルなプロンプトからスタートしました。

JBoss EAP 8.1で動くようにしてください。その際にSpringからJSFに変更します。また、pom.xmlは次のリポジトリのpom.xmlを参
    考にしてbootable jarとして実行できるようにしてください。
  https://github.com/ssetoredhat/eap8.1-bootablejar

ただし、今回の構成ではこれだけでは明らかに不十分で、これ以外に多くの追加の指示、修正が必要になりました。Spring BootからJSFへ移行する際のノウハウとして、直面したポイントをいくつか紹介します。

追加で指示が必要だった点

全体として、実装方法が複数あってAIの判断が曖昧になる点や、「SpringとJSFでアノテーションや書き方は似ているものの、挙動や機能が異なる場合」に、詳細な移行指示を出す必要がありました。

GET/POSTなどのHTTPメソッドを維持する

もともとのSpring PetClinicでは、データ登録はPOST、データ検索はGETで実装されていました（RESTのベストプラクティスに沿った形です）。しかし、AIがJSFに移行する際、すべてを一律でPOSTに変更してしまったため、ページング処理などで値がうまく引き継げなくなる問題が発生しました。GET/POSTの役割はそのまま維持するよう、明示的に指示すべきポイントです。

EJBよりもCDIを使用する

旧来のJava EEではEJBとServletを中心にアーキテクチャが構築されていましたが、モダンなJakarta EE（JBoss EAP 8.1）では、DIコンテナとしてCDIを中心に据えることが推奨されています。今回、AIは初期化処理をまずEJBに移植しようとしたため、最初から「CDIを使用すること」を指定しておくのが正解でした。

スコープの指示

@RequestScoped と @ViewScoped など、スコープの問題が多く発生しました。挙動がフレームワークに隠蔽されているため、実際にどういう挙動になるかがAIからわかりにくかったためと推察されます。

基本的には @RequestScoped を使用して、特定の場合のみ @ViewScoped に変更するなどすればいいのですが、それはAIに追加での指示が必要でした。

そのほか

今回、問題が発生したところに関しては、修正指示を出し、その結果をテキストにまとめてもらいました。一部記述が怪しい部分も残っていますが、「AIにナレッジをまとめさせると、リアルにこのくらいの精度になる」という参考として、あえて手を加えずにそのまま公開しています。

次回、同様の移行を行う際はこのテキストをそのまま「AIへの指示書（コンテキスト）」としてインプットできるため、今回よりも遥かにスムーズに移行できるようになるはずです。ぜひ皆様も移行を試された際は、ご自身用の指示書を作って公開してみてください！

なお、前回記事で触れた考慮事項（移行時の注意点）については、今回も引き続き意識する必要があります。

まとめ

いかがでしたでしょうか？今回のアプリケーションは前回に比べるとCRUDすべてが実装されているという事もあり、さすがに簡単なプロンプト1回で移行するというわけにはいきませんでした。しかし、思っていたよりはずっと簡単に移行する事ができました。

また、ナレッジ自体もAIが勝手にまとめてくれるため、次回はもっと簡単に移行する事ができるようになります。

AIによって気軽にフレームワークを切り替えられるような時代になりました。ぜひSpring-Bootに不満がある場合はJBoss EAPを検討いただき、ぜひご利用ください。

*1:決して見た目を同じにする労力を省いたわけではありません。