1. はじめに
ラクスが開発する請求書受領システム「楽楽請求」では、Web アプリケーションフレームワークとして Spring Boot を使用しています。
当時使用していた Spring Boot の 3 系 が2026年6月で EOL になるため、バージョンアップ（3系 → 4系）を実施しました。
バージョンアップに関する影響調査を AI（Devin）に任せてみたので、その実践内容を共有します。
この記事で書くこと
- メジャーバージョンアップの影響調査を AI に任せる具体的なやり方
- どこまで効いて、どこは人間が必要だったか
この記事で書かないこと
- メジャーバージョンアップ対応自体の詳細
前提
今回のバージョンアップ対象は以下のとおり。いずれもメジャー更新。
※Spring Boot に依存するライブラリなどのバージョンアップを含む
| 対象 | Before | After |
|---|---|---|
| Spring Boot | 3系 | 4系 |
| Spring Framework | 6系 | 7系 |
| Jackson | 2系 | 3系 |
2. バージョンアップ作業フロー
今回行ったバージョンアップ作業フローは大きく分けて以下の３ステップです。
| Step | 作業内容 | 自動化レベル |
|---|---|---|
| 1 | メジャーバージョンアップによる影響調査 | 自動 |
| 2 | Step 1 の調査結果から対応が必要かどうかの判断と方針検討 | 手動 |
| 3 | 更新作業 | ほぼ手動 |
Step 1：メジャーバージョンアップによる影響調査
Spring Boot やそれ以外の、リリースノートを含めた膨大な情報量を整理して、自プロダクトへの影響を洗い出すStep。
Devin の Playbook を作成する
使用した Playbook（一部抜粋）
### Required from User - mw name: 対象のMW名 - current version: 現在利用中のMWバージョン - target version: アップデート後のMWバージョン ### Procedure 1. mw name と current version, target versionを確認する 2. mw nameで指定されたMWのGitHubリポジトリまたは公式ドキュメントにアクセスする。 3. GitHubリポジトリも公式ドキュメントも存在しない場合、ユーザーにエラーメッセージを返して終了する。 4. GitHubリポジトリまたは公式ドキュメントが存在する場合、そのURLをユーザに返す。両方存在する場合はGitHubリポジトリを優先する。ユーザはURLを受け取った後、次のステップに進むよう指示する。 5. リリースノートページにアクセスし、current versionからtarget versionまでのリリースノートを確認する。 6. 5.で確認したリリース内容の@で指定したリポジトリに対する影響を調査する。 7. 以下の形式で影響調査結果を出力する。1. markdown形式の表 2. CSVファイル - カラム1: バージョン - カラム2: 変更内容(原文) - カラム3: 変更内容(日本語訳) - カラム4: 変更内容種別(ex: 破壊的変更、機能追加、バグ修正など) - カラム5: 影響度(高・中・低・なし) - カラム6: 影響度の根拠
参考：Devin Playbook の概要 - 公式ドキュメント
※使用した Playbook は今回のバージョンアップ用途で作成していないため、Spring Boot のバージョンアップに特化したものではない
Devin の Playbook を実行して一覧化する
依存関係がある MW の数だけ繰り返し Playbook を実行する。
- 対象 MW と前後バージョンを明示し、MW の公式 GitHub リポジトリ or 公式ドキュメントを参照
- 指定したリポジトリ（今回は楽楽請求リポジトリ）に対する影響を調査
- 調査結果を一覧化
| 列 | 内容 |
|---|---|
| バージョン | その変更が入ったバージョン |
| 変更内容（原文） | リリースノートの記載 |
| 変更内容（日本語訳） | 上記の和訳 |
| 変更内容種別 | 破壊的変更／機能追加／バグ修正 など |
| 影響度 | 高・中・低・なし |
| 影響度の根拠 | なぜその影響度と判断したか |
Step 2：対応が必要かどうかの判断と方針検討
Devinの調査結果を見て実際に対応する必要があるか、どのように対応するかの方針を検討するStep。
- 変更内容の種別・影響度から、楽楽請求プロダクトへの対応要否を判断
- 要対応箇所をどのように対応するかを方針レベルで検討
Step 3：更新作業
実際にバージョンアップを行い、破壊的変更に対応するStep。
- 個別判断が必要な箇所が多く、ほぼ手作業
→ ただし、修正パターンが決まりきっている変更はAIに委譲
3. AI 活用の所感
影響度判定の精度評価
- 影響度「なし」判定が正しかった割合・・・93.5%
- 影響度「高／中／低」判定が正しかった割合・・・49.3%
良かった点
- 情報量が多く定型的な 「読む・分類・一覧化」を AI に寄せられた
- 影響度の根拠まで出力させたことで人間のレビュー判断が速くなった
- 実際の更新作業でも 機械的な修正を AI に委譲でき、人は判断に集中できた
微妙だった点・反省
- AI の影響度判定（特に「中」「低」）に見逃しがあり、鵜呑みにできなかった
→ だが一次調査としての精度は十分
→ AI は「たたき・一覧化」までは強力なので、最終判断は人間が持つ前提で運用する
4. まとめ
- メジャーバージョンアップの影響調査で、AI は「読む・分類する・一覧化する」までを自動化できた
- ただし「影響度の判定」はそのまま信用せず、人間の確認を前提に使うのが現実的
- 作業全体の AI と人間の作業比率は体感で 1:9 程度で、気持ち少し楽できたくらいだった
5. 今後の展望
- 対応当時は主に一覧化作業にのみ AI を活用していたが、調査〜修正PR作成までを一気通貫で完全自動化する
- ラクス社内で AI の導入がどんどん進んでいるので、Devin に限らず Claude Code, Codex 等を用いた自動化を検討する
