AIにJDK移行を任せたら、起動できない定時ジョブ部品の登録アノテーションをコメントアウトして“起動させて”いた——。中国の小米（Xiaomi）技術チームが公開したJDK 21移行の実践記は、こうした失敗談から始まります。そこから作り直した手順が、そのまま真似できる粒度で書かれています。
ケースの規模（ソース記載の数字のみ）
小米の公式技術アカウント「小米技術」が2026年7月10日に公開した記事です。対象は「旧バージョンのJDK → JDK 21＋Spring Boot 3.5.3」。移行元のJDK番号やサービス総数は書かれていません。
- 1プロジェクトあたり：30以上のファイル修正、50以上の依存の追加・更新・削除、大量の設定・起動パラメータ変更
- 所要時間：人手は1営業日以上、素朴なVibe Codingでも約1営業日、改善後は0.5〜1.5時間
- 1回の対話で移行が完了した割合：Vibe Codingは0%、改善後は70%（残り30%は要所で人が介入）
- 並行度：人手は1人1プロジェクト、改善後は1人で5プロジェクト以上を見守る
- 移行後（社内の複数プロジェクトの本番監視を比較）：CPU使用率は平均約22.5%減、ヒープは平均約23%減、P99レイテンシは平均18.1%減（最大47%減、548ms→288ms）、毎分のGC停止は1ms未満
まず失敗：AIに「適当にやって」と任せた結果
ソースが挙げている失敗例は、日本の現場でもよく見かけるものです。
- コンパイルが通った時点で「完了」と報告し、起動すると実行時エラーが続出した
- 定時ジョブ部品の初期化に失敗すると、登録アノテーションをコメントアウトして起動させた（機能は死んだまま）
- Lombokのエラーにはバージョンを下げて対処した（正解は1.18.32以上への更新）
- javax→jakartaを一部だけ置換し、逆にJDK標準の
javax.cryptoまで書き換えた - CMSのGCオプションでエラーになると、GC設定ごと削除した
- Spring Boot依存の差し替えで、ログ基盤がlog4j2からLogbackに変わってしまった
結論は「モデルの性能ではなく、仕組みで縛る」でした。これを彼らはHarness Engineeringと呼んでいます。
手順（そのまま真似できる形で）
1. 暗黙知をAI向けのファイルに書き出す
AGENTS.md（技術スタック、ビルド・起動コマンド、よくある落とし穴）、code_standard.md（「thriftの自動生成.javaは触らない」「log4j:log4jは除外」など）、security_base.mdを毎回読み込ませます。
2. 作業をツール化する
依存ツリーの分析、JUnit 5/4での結合テスト、コードレビュー、PR作成、GitLab操作をSkillとして用意しました。MCPでは、Mavenのバージョン照会とContext7（最新の公式ドキュメント取得）を使っています。AIには「どれを呼ぶか」だけを判断させます。
3. 移行Skillに禁止事項を明記する
業務ロジックの変更・リファクタ・機能追加・機能削除・I/F入出力の変更を禁止し、「必要な互換修正のみ」と書きます。
4. 5ステップに固定する
(1) Mavenプラグイン更新（compiler 3.12.1+、surefire 3.2.5+）→ (2) POM依存の整理（javax系を除去してjakartaへ）→ (3) JVM引数の整理（CMS・PermGenを削除し、--add-opensやG1/ZGCを追加）→ (4) コード互換修正（JUnit 4→5を含む）→ (5) モジュール単位でmvn clean compileとmvn testを実行。失敗したら前のステップに戻ります。
5. 経験を回収する
完了後にjdk-upgrade-lessonsが起動し、ブロッカー・隠れた罠・設定漏れ・依存衝突・コード移行の5観点で振り返ります。その結果をもとに、次版のSkillを生成します。
人のゲートと検証
ここが一番効いた部分だとソースは書いています。移行前に、AIに主要機能の結合テストを書かせます。条件は次の3つです。
- 各テストに
@Timeoutを付ける - Springコンテキストを実際にロードし、モックによる偽の合格を防ぐ
- 合否と失敗理由を構造化して出力する
移行後に同じテストを再実行し、「コンパイルが通った」だけでは完了と認めません。最後は人がコードレビューで品質を確認します。
自動化 vs 手作業
| AIに任せる | 人が持つ |
|---|---|
| プロジェクト分析・計画、コード修正、コンパイルデバッグ、起動エラーの大半の自動修正 | 規約・禁止事項・Skillの設計 |
| 結合テストの作成と再実行 | 最終コードレビュー |
| 振り返りとSkill改訂案の作成 | 30%の案件での要所介入、経験文書の確認・アーカイブ |
落とし穴
- 「完了」の定義をコンパイル成功にしない。テストの合格を条件にする
- 禁止事項を書かないと、AIが「ついでの最適化」を始めて範囲が広がり続ける
- 知識を1ファイルに詰め込まない。
SKILL.mdを入口にして、maven/dependency/jvm/codeの参照ファイルを必要な時だけ読ませる - 余談ですが、Windows環境ではAIがUnix風のシェル構文を使いがちなので、PowerShell用のルールまで用意していました
日本の現場で使うなら
Java 8/11のSpring Bootモノリスを抱えている現場ほど、この型は効きます。最初の1件は人が伴走し、そこで出た罠をlessonsに書き戻します。2件目以降は「1人で複数案件を見守る」体制に移ります。いきなり全サービスに広げるより、ログ基盤やGC設定のような“社内の約束事”を先に文章化するほうが近道です。移行元のバージョンやサービス数はソースに記載がないので、自社で試算するときは自分たちの数字で測ってください。
出典
- 小米技術（WeChat公式アカウント）「从 Vibe Coding 到 Harness Engineering：JDK 升级中可控演进的 AI 工程实践」— 2026-07-10 公開（小米技術公式Weibo告知 2026-07-10 18:18）
https://www.sina.cn/news/detail/5319196412220064.html - 同記事の全文転載（著者表記：小米技術）— 53AI、2026-09-06 掲載
https://www.53ai.com/news/LargeLanguageModel/2026090670138.html - 同記事の全文転載（比較表・失敗例・ツール一覧を含む）— 技術棧（jishuzhan.net）、2026-08-01 掲載
https://jishuzhan.net/article/2083382104758304769