Spring BootからQuarkusへの移行

Transcript

1. Jakarta EE&MicroProfileセミナー Spring BootからQuarkusへの移行 〜AIツールを活用したJakarta EEベースへの効率的なモダナイゼーション〜 宮崎 達也 ／ 日本アイ・ビー・エム株式会社 2026年 9月 10日
2. この時間で語ること 01 SpringとJakarta EEの関係をおさらいする 02 AI開発時代のアーキテクチャ選択 03 Supersonic な Quarkus 04 AIエージェントでQuarkusへ移行してみた 05 移行結果の評価と反省点 この時間の目標： 今月中にQuarkusへの移行を試したくなること © 2026 IBM Corporation 2
3. 免責事項 ・掲載内容の正確性には配慮していますが、内容の誤り等によって生じた損害 について、当方は一切の責任を負いかねます。 ・当セッションの内容は個人の見解であり、所属団体を代表するものではあり ません。 © 2026 IBM Corporation 3
4. 自己紹介 宮崎 達也 日本アイ・ビー・エム株式会社 カスタマーサクセスエンジニア https://www.linkedin.com/in/tatsuya-mi/ https://qiita.com/mi-ta SIerでさまざまな形態の開発を体験した後、IBMにてJava関連製品を担当中。 今夏のマイブームは たんぱく質が取れる食事とTBSドラマ（VIVANT、Tかわ） 資格 © 2026 IBM Corporation 技術士（情報工学部門） 情報処理安全確保支援士 IPA 情報処理技術者 高度試験（SA、DB） DX推進パスポート3（ITパスポート、G検定、DS検定） 4
5. SpringとJakarta EEの関係をおさらいする 01 © 2026 IBM Corporation 5
6. J2EE / JakartaEE と Springの歴史 重厚長大なJavaEEと軽快なプログラミングモデルであるSpring 1999〜2016 標準側 2017〜 財団へ移管し、標準側が動き出す 1999 2006〜13 2017 2019〜20 2022 2025〜 J2EE 1.2 EJB 2.xで重厚 Java EE 5〜8 軽いが、遅い Oracleが移管 Eclipse財団へ Jakarta EE 8・9 javax→jakarta Jakarta EE 10 Core Profile Jakarta EE 11 Jakarta Data Spring側 2004 重いEJBに、Springが軽さで応えた 2004 2014 2022 Spring 1.0 EJBなしで書く Spring Boot 1.0 jar 1つで起動 Spring Boot 3.0 jakartaへ追随 EJBを使わずに書く Rod Johnsonの『J2EE Development without EJB』が出ます。POJOにDIとAOPを組み合わせる 書き方が、ここから広まりました 2014 jar 1つで起動する アプリケーションサーバーに配備するモデル自体を なくしました。クラウドとコンテナの時代に合いま した 2017 単一ベンダーから財団へ OracleがJava EEをEclipse Foundationへ移しまし た。特定企業の判断で方向が変わりにくくなりまし た 2022 Springが標準に追随 Jakarta EE 9でjavaxがjakartaになり、Spring Boot 3.0が追随しました。今も仕様変更を追いかける立 場です Springが広まったのは、出せる速さの差でした 2017年と2022年が、後半の伏線になります 仕様は合意が要るぶん遅れます。その間もSpringは自分たちのペースで機能を出し続けました。この差が採用を決 めました 中立な財団が運営していること。そしてSpringが今も標準の変更を追いかけていること。この2つが後半につなが ります © 2026 IBM Corporation 6
7. JakartaEEとSpringの関係 同じ領域の機能でも、異なる実装であるケースも多い JakartaEEに存在する機能を基盤 技術として活用している点も多い © 2026 IBM Corporation 7
8. Springで利用されているJakartaEEの仕様 青の機能はSpring未使用（ただ し類似機能があることも多い） 緑の機能がSpringにも利用されている https://newsroom.eclipse.org/eclipse-newsletter/2024/march/why-spring-matters-jakarta-ee-and-vice-versa © 2026 IBM Corporation 8
9. Spring固有の機能とその先進性 記載は一部ですが、さまざまな機能を展開している プロジェクト 提供機能 先進性のポイント Spring AI LLM/生成AIとのエンタープライズ 統合フレームワーク ChatClient抽象化、RAG、Vector Store抽象 化、MCP(Model Context Protocol)サポート など。 Jakarta EEではAIIモジュールが開発中。 Spring Modulith モジュラーモノリスの構造化・検証 ドメイン駆動でのモジュール境界の可視 化・アーキテクチャテスト・イベント駆動 連携。Jakarta EEにアーキテクチャレベルの 規約はない。 Spring Cloud 分散システム/マイクロサービスパ ターン群 Config、Gateway、Circuit Breaker統合など。 MicroProfileの一部と重複するがJakarta EE 本体には無し。 Spring gRPC gRPCのSpringフレンドリーな抽象 化 HTTP/2ベースのRPC。 Jakarta EEには相当なし。 © 2026 IBM Corporation https://spring.io/projects 9
10. Springを参考にしたJakartaEEの機能 © 2026 IBM Corporation 10
11. この章のまとめ ・Springは先進性、JakartaEEは共通規格としての頼りがいが特徴 ・SpringとJakartaEEは対立ではなく協調関係にある ・Spring内でも多くの機能はJakartaEEの実装をベースとしている ・Springの機能をJakartaEEに反映するケースも多数存在する いまはどちらもエンタープライズ向けに同じ方向感で機能を提供している 両者は距離感が近い存在 © 2026 IBM Corporation 11
12. AI開発時代のアーキテクチャ選択 02 © 2026 IBM Corporation 12
13. AI時代に検討すべき2つの注目ポイント プラットフォーム選択基準の優先度が変わる ランニングコスト意識の重要性が変わる © 2026 IBM Corporation 13
14. プラットフォーム選択の優先順位 これまでの選択基準は「書きやすさ」と「デファクトスタンダード」 選定基準 1 開発者体験 書きやすいか、学習コストが低いか 2 エコシステムの広さ 使えるライブラリの多さ 3 採用市場 対象の技術者を確保できるか 4 サポート期間・標準準拠 長く利用できるか © 2026 IBM Corporation 優先度 AI時代の 優先度 14
15. AIの発展に伴うアプリケーションコスト構造の変化 ① AI活用によりアプリケーション開発コストは劇的に減少する → 開発工数「AIで28年以降に半減」 → これまで工数が確保できずに見送られていた小さな業務システムが、 次々と作られる → 2028年までに新しく10億のアプリケーションが生まれると予想 されている https://www.nikkei.com/article/DGXZQOUC0786S0X00C26A9000000/ https://newsroom.ibm.com/blog-how-ibm-enables-a-holistic-approach-to-help-improve-applicationresiliency-with-ai-powered-automation © 2026 IBM Corporation 15
16. AIの発展に伴うアプリケーションコスト構造の変化 ② アプリケーション実行環境のインフラコストは上がる → CPU、メモリ価格はAI需要に上昇し続けている → 半導体価格は2020年から26年で65％アップ → クラウド環境はドル建てのため為替の影響を受ける アプリケーション数 × インフラコスト ＝ ランニングコストの 増大 https://jp.gdfreak.com/public/detail/jp010501006000030252/1 © 2026 IBM Corporation 16
17. ランニングコスト増への対応 コンテナ運用による、ITリソースの有効活用 → 小さな業務システムへの、ゼロスケール含む柔軟なリソース割り当て © 2026 IBM Corporation 17
18. この章のまとめ AI時代の変化に対応するために大切なのは次の2点 ・サポートを重視したプラットフォームの選択 → JakartaEEは長期の対応が期待できる ・コンテナ技術によるITリソースの効率運用 → コンテナネイティブなアプリケーションの選択 © 2026 IBM Corporation 18
19. 改めてSpringとJakartaEEの比較 要旨： いまやJakartaEEは開発しにくい存在 ではない JakartaEE選択のメリット： ベンダーロックイン回避 エコシステムの安定性 既存EE資産とのシームレスな連携 Springのメリット： モダンな機能のリリース速度 スターターによる開発高速化 サーバー不要で実行可能 https://www.javacodegeeks.com/2026/03/jakarta-ee-11-vs-spring-when-the-right-answer-is-no-spring-at-all.html © 2026 IBM Corporation 19
20. Supersonic な Quarkus 03 © 2026 IBM Corporation 20
21. Quarkusとは SUPERSONIC / SUBATOMIC JAVA Supersonic → 超速い Subatomic → 超小さい コンテナ技術が台頭してから生まれた ・OSS ・コンテナネイティブ というJavaフレームワーク コミュニティサポートの他、Red Hatお よびIBMからディストリビューションお よびサポートを提供中 https://quarkus.io/ © 2026 IBM Corporation 21
22. QuarkusはMicroProfile＋Jakarta EEのJavaランタイム MicroProfile＋Jakarta EE（Core＋α） https://quarkus.io/standards/ © 2026 IBM Corporation 22
23. Spring Bootとの類似性 ビジネスロジックに注力した構造 フロントエンド技術はあまり注力しない 実行環境での事前のサーバーセットアップ不要 DI中心のアプリケーション構成 Initialzrから必要な機能を選択して進める開発者体験 © 2026 IBM Corporation 23
24. Quarkusの特徴 ネイティブコンパイル対応 → 当初からの設計方針、コンテナ上の運用に特に価値が高い → Springも現在はネイティブコンパイルに対応している 高いパフォーマンス → AOTコンパイル → 起動時のメモリ使用量、起動速度は同条件のSpringより約2倍良好 MicroProfile／JakartaEE ベース © 2026 IBM Corporation 24
25. この章のまとめ アプリケーションをSpringではなくQuarkusにすることのメリットはある 構造的にSpringと近い 標準規格への準拠、将来的なサポート ランニングコストの低減に寄与 © 2026 IBM Corporation 25
26. AIエージェントでQuarkusへ移行してみた 04 © 2026 IBM Corporation 26
27. マイグレーション手順の詳細 次のQiita記事に詳細を記載しています。 実践しよう IBM Quarkus：IBM Bobと進める Spring Bootからのマイグレーション https://qiita.com/mi-ta/items/aec9e2254630702ddff5 実践しよう IBM Quarkus：Bob Shellと進める Spring Bootからの最速マイグレーション https://qiita.com/mi-ta/items/dbb7d4f0876d4fda082a © 2026 IBM Corporation 27
28. Spring BootからQuarkusへの移行 いくつかのツールやガイドの他、 AIのスキルによる移行手順も提示 されている。 事前判断として、 ・ネイティブQuarkus API ・Spring互換 Extension のどちらに移行するかを決める。 Spring互換Extensionはソースコー ドを変更せずに動かすための選択 肢として提示されている。 https://quarkus.io/spring/migrate/ © 2026 IBM Corporation 28
29. migrate-spring-to-quarkus quarkusio/skills にて提供されているスキルの1つ。 インストール時に、多様なAIツールから利用対象を選択する。 実行は「このアプリをQuarkusに移行して」などで起動できる。 起動後に、ソース移行先とブランチ作成有無を指定する。 https://github.com/quarkusio/skills#migrate-spring-to-quarkus © 2026 IBM Corporation 29
30. migrate-spring-to-quarkus コードを垂直的な複数レイヤーに分けて、 段階的に移行処理を行う。 定型的な変換パターンはスキル内の文書で 具体的に指定されている。 （最終的にはAIが判断する） 変換できない箇所はTODOコメントを残す。 最終的に移行レポートを作成する。 © 2026 IBM Corporation 30
31. 移行対象アプリケーション：RealWorld Mediumと同じ投稿サイトのヘッドレス・バックエンドアプリケーション。RESTとGraphQLに対応。 いくつかのフロントエンドアプリが提供されている。 アーキテクチャの特徴 レイヤ構造 移行前の規模 Core層の分離 REST API GraphQL API 116 エンティティはフレームワーク非依存のPOJOです @RestController ／ 19本 Netflix DGS ／ 18操作 Javaファイル ｜ main 93 ／ test 23 読み書きの分離 Application Service 19 CQRSライクにReadServiceを分けています RESTとGraphQLが共有します RESTのエンドポイント デュアルAPI Core ドメイン層 18 RESTとGraphQLが同じApplication Serviceを共有し ます フレームワーク非依存のPOJO GraphQLのルート操作 ｜ Query 6 ／ Mutation 12 MyBatis Infrastructure 11 MapperとReadServiceの2系統です MyBatis Mapper ／ ReadService MyBatisのXMLファイル 認証と周辺 SQLite 68 JWTのステートレス認証・Flyway・Lombok・ Spotless Flywayでマイグレーションします テストの件数 ｜ 20クラス ライブラリのバージョン Spring Boot 2.6.3 © 2026 IBM Corporation JDK 11 Gradle 7.4 Netflix DGS 4.9.21 MyBatis 2.2.2 31
32. RealWorldの構造 SPAの基本的な構成。クライアントは常にフロントエンドサーバーと通信する。 Vue3によるSPA形式のフロントエンド実装 バックエンドのJavaアプリケーション © 2026 IBM Corporation 32
33. 今回使用するAI：IBM Bob IDE（VSCodeベース）とCLIの2つの提供 形態 複数のLLMを自律的に使い分ける スキルやMCPなどのモダンな機能を提供 愛嬌のあるマスコットキャラも含めて開 発パートナーとしての存在感あり Windows／Mac／Linuxに対応 Bobコインという単位での従量課金 （お試し無料コインあり） © 2026 IBM Corporation 33
34. スキルをIBM Bobで実行してみた結果 © 2026 IBM Corporation 34
35. スキル利用の反省点 度々レス待ちの状態になり、完了までの時間が長引く → ツール実行などの承認待ち → コマンド実行エラーで止まるときがある（ステータスは実行中…） → gradlewでexitステータスが出力されないパターンが多い テストは通過したが、手動のE2Eテストではエラー → セキュリティのハンドリングでエラーになることがあった © 2026 IBM Corporation 35
36. スキル利用の反省点 AI処理のため、結果にゆらぎがある → 同一環境で実施したが、2回で異なる結果になった → 1回目 122Bobコイン、精度的に若干難あり（Bob 2.0） → 通過できないテストを自主的に停止した。実施テスト数は全体の2/3。 → 2回目 176Bobコイン、テストをカットすることはなかった（Bob 2.1） → 全般的に精度が向上したが、SQLiteからH2にDBを指示なく移行した ※ BobコインはBobの課金単位。1コイン=0.5$であり、156円/$で換算すると 122Bobコイン = 約9,500円 176Bobコイン = 約13,800円 © 2026 IBM Corporation 36
37. スキル利用の反省点（Bobによるセルフレビュー 1/3） Quarkus のテストアーキテクチャを事前に理解していなかった ・@QuarkusTest は abstract クラスから継承しても機能しないことを、実際にエラーが出るまで知らなかった ・@InjectMock が @Singleton スコープ（Spring @Service の変換先）に使えないことを知らずに進めた ・@InjectMock を持つテストと DB テストが別 Quarkus コンテキストを起動するため競合することを 見落とした ↓ 移行開始前に Quarkus テストガイド を読み、以下を確認してから進めるべきだった： ・@QuarkusTest のコンテキスト共有ルール ・@InjectMock の CDI スコープ要件（normal scope のみ） ・@TestProfile による分離の必要条件 © 2026 IBM Corporation 37
38. スキル利用の反省点（Bobによるセルフレビュー 2/3） @Service → @ApplicationScoped 変換を後回しにした コード移行時に @Service/@Repository を Spring 互換アノテーションのまま残した。これが @InjectMock: invalid bean scope: Singleton エラーの直接原因となり、 テスト移行フェーズで大きく後退した。 ↓ コード移行（build/code モジュール）の段階で 「テストでモックが必要になる Bean は全て @ApplicationScoped にする」 というルールを最初から適用すべきだった。Spring 互換モードでも @ApplicationScoped は完全に使える。 © 2026 IBM Corporation 38
39. スキル利用の反省点（Bobによるセルフレビュー 3/3） キャッシュへの対応が甘かった application.properties を変更しても UP-TO-DATE で古いビルドが使われ、 「変更が効いていない」と誤診して同じ修正を繰り返す場面があった。 ↓ 設定変更後は必ず ./gradlew clean してから test を実行する、もしくは --rerun-tasks フラグを使う 習慣をつける。 © 2026 IBM Corporation 39
40. リトライ：より効率的な処理を目指して Bob Shellを使用する → ユーザー判断を最小限にする WSL2による隔離環境の構築 → 想定外のAIの挙動でも、ローカル環境に影響を及ぼさないようにする 自分用にカスタマイズするプロンプトの追加 → 自社用の知見を盛り込むようにする 最初から QuarkusネイティブAPIを移行先に指定する © 2026 IBM Corporation 40
41. Bob ShellとIDEの違い Bob IDEはホワイトリスト、 Bob Shellはブラックリスト方式。 同じ機能を持っていながら、用 途によって使い分けることがで きる。 IDE → 一緒に開発する Shell → ハーネスエンジニアリン グ © 2026 IBM Corporation 41
42. WSL2による隔離環境の構築 BobをWSL2の環境にインストール。 Windows WSL2 EXEコールを停止 プロセス 検証ではCentOS Stream10を使用。 プロセス ファイルシステム ファイルシステム （Ubuntuにあまり慣れていない…） 隔離は完全ではないが今回の検証用 途では及第点。 自動マウントを停止 © 2026 IBM Corporation 42
43. 反復実行を前提としたプロンプト Prompt.txt 図のスキル利用フローを定義。 Lessons.md AIが移行で得た知見またはユーザー 質問を出力する。 人は参照メイン。 Findings.md 前回以前の移行の知見をユーザーが まとめる。 AIは参照して効率的、揺らぎの少な い出力を行う。 © 2026 IBM Corporation 43
44. 移行結果の評価と反省点 05 © 2026 IBM Corporation 44
45. 移行工数（対IDE比） 移行処理には 70.48 Bobコインを使用している。 → IDE利用時の約6割。 → findingsの知見から陥りがちな問題を回避できた可能性。 実行時間は数時間から約1時間に短縮された。 → 2回実施した結果、1回目は途中停止無し、2回目は質問のため1回停止。 → ユーザーが介入する負担が軽減されたことも価値が高い。 Shell利用のほうが、コスト・時間の両面で効率的に対応できている。 © 2026 IBM Corporation 45
46. AIを使わない場合の移行見積り アノテーションの書き換えは約300か所。そのうち一括置換で済むのは19%です。 AIの試算で、フェーズごとに積み上げると17〜29人日、中央値でおよそ22人日になります。 アノテーションの書き換え箇所 手作業の場合の工数見積り ｜ Quarkus未経験の1名想定 @Autowired 41 @Inject 76 事前調査・技術選定 3〜5 @Service ／ @Repository ／ @Component 15 @ApplicationScoped 28 ビルド基盤 1.5〜2 REST系 ｜ @RestController など 約75 JAX-RS系 ｜ @Path など 約70 DI・コンポーネント 0.5〜1 DGS系 ｜ @DgsComponent など 84 SmallRye GraphQL系 52 REST層 2〜3 セキュリティ 1.5〜2.5 例外・バリデーション 1〜1.5 永続化 ｜ MyBatis 1.5〜2.5 GraphQL 3〜5 テスト 3〜4 結合デバッグ・仕上げ 2〜3 合計 17〜29 人日 @MockBean 23 @InjectMock 43 合計 約300か所。うち一括置換で済むのは19% 中央値で約22人日。1か月強です Quarkus経験者が担当するなら10〜15人日まで縮みます 読めないのはテストと結合デバッグです 未経験かつ全テストを通す制約だと、30人日を超えるリスクが現実的にあります © 2026 IBM Corporation 46
47. 移行工数（対人間比） 人間による対応 22人日 × 人月単価（20日稼働・100万円想定） = 110万円 AIによる対応 AIランニングコスト： 70.48Bobコイン × 78円(Bobコイン単価) = 5460円 準備対応（知見のテキスト化など） 2人日 × 人月単価（20日稼働・100万円想定） = 10万円 → AIによる対応が10倍コスト効率がよい（人力による検証タスクは除く）。 © 2026 IBM Corporation 47
48. 移行内容の評価 特に下2つは、findings.md に書いたルールが効いた結果 観点 Spring依存の除去 結果 実質完全。残存は ValidationErrors.java の Javadoc コメント1行のみ javax → jakarta テスト 完了 REST API 19エンドポイントの挙動を維持 MyBatis XML 11ファイルの再配置＋共有ResultMap問題を一発で正解 設定の意味保存 UNWRAP_ROOT_VALUE を ObjectMapperCustomizer でコードとして再現 68件すべて維持。@Disabled による回避は 0件 @Disabled 禁止ルールが機能した 設定の「無言の差し替え」を防げた 前回はテストをスキップして誤魔化されたの で、findings.md に明示的に禁止と書いた。 Quarkusに対応キーがない設定を、前回は意 味の違う設定に黙って置換。今回はコードで 挙動を再現した。 © 2026 IBM Corporation 48
49. 移行精度の限界 GraphQLはテストコードがないため検証できていない → テストコードが無いため、テスト全件OKとの認識がされている → 移行結果からは、型定義が欠落して動かないものと思われる → テストコード実行による気づきの機会が欠けている → テストエラーとなれば、型定義の欠落を認識した可能性が高い © 2026 IBM Corporation 49
50. 本日のまとめ Spring と Quarkus は色々な意味で似ている Spring Boot →Quarkus の移行はAIで効果的に実施できる テストコードの準備で移行精度は向上する 【挑戦してみましょう】 まずは小さいシステムからQuarkusで移行してみましょう © 2026 IBM Corporation 50