LLMは4年分のCompose移行を再現できるのか？実プロダクト279件のXMLで探る自動化の境界線

情報 : https://2026.droidkaigi.jp/timetable/1231173/

English edition : https://speakerdeck.com/makun/makun-20260902-droidkaigi-2026-english

Transcript

1. LLMは4年分のCompose移行を 再現できるのか？ 実プロダクト279件のXMLで探る自動化の境界線 Masahiro Saito
2. Masahiro Saito 齊藤 正宏 ／ ピクシブ株式会社 スマホアプリエンジニア 兼 エンジニア採用リーダー 本セッション対象アプリのCompose移行の計画・実行を担 当 2
3. 昨年はテストを AIに委ねる話をしました DroidKaigi 2025 「テストコードはもう書かない：JetBrains AI Assistantに委ねる非同期処理のテスト自動設 計・生成」 3
4. 数年かけた Compose移行を、 LLMでもう一度やってみた 出発点 今のLLMなら、かなり自動で進められるのでは？ ▼ 調べていくと うまくいかない理由には、いくつかのパターンがあった ▼ たどり着いた問い では、AIにどう任せれば効率よく移行できるのか？ 4
5. 今日の流れ 1 実際の検証の内容 2 検証の結果 3 検証結果の考察 4 不足を補えば任せられるのか 5 仕組みを作る価値 6 まとめ 5
6. 対象は実プロダクト pixivと講談社が協業で開発するマンガアプリ Palcy。2018年から運用し、今年8月で8周年 。 すでに人手でCompose移行済み。つまりサンプルコード ではなく、実プロダクトの XML移行をどこまでAIに任せら れるかを試した。 ©株式会社講談社 6
7. 対象範囲 検証の対象 現在 Compose 移行済みのコード 巻き戻す ▶ 移行前の XMLレイアウト 全279件 7
8. 今日の流れ 1 実際の検証の内容 2 検証の結果 3 検証結果の考察 4 不足を補えば任せられるのか 5 仕組みを作る価値 6 まとめ 8
9. 今回の検証の問い 1 LLMは Compose コードを書けるか？ 2 build error を自力で直せるか？ 3 見た目を近づけられるか？ 4 人間が移行したCompose実装と比べると、何が欠けるか？ 9
10. 移行済みの Composeが既にあるが・・・ 実際のCompose実装やDesign Systemといった、 答えに近い情報は渡さない。 観測したいのは、与えた情報だけでどこまで進めるか。 予め決めた範囲の情報だけを渡して検証します。 10
11. 検証の流れ 入力 XML ＋ 限定コンテキスト ▼ 生成 LLM が Compose を生成 ▼ 修正① コンパイルエラーを返して直してもらう ▼ 修正② スクリーンショットを見せて直してもらう ▼ 答え合わせ 実際の移行結果との比較 11
12. まず30件で試し、 279件全件へ 先行検証 30件 やり方を比較して決める 最終的な対象 展開 → 249件 同じ方法を残りのXMLへ → 279件 デモではなく全件 12
13. 今日の流れ 1 実際の検証の内容 2 検証の結果 3 検証結果の考察 4 不足を補えば任せられるのか 5 仕組みを作る価値 6 まとめ 13
14. 279/279 エラーを返して直す工程を含め、 100% build PASS 14
15. 結果を返して繰り返せば、直る問題がある 高い効果 一部改善 build error 大きさや配置 エラーログを返せば、LLM自身で直せた スクリーンショットを見せると近づくことがある 15
16. 今日の流れ 1 実際の検証の内容 2 検証の結果 3 検証結果の考察 4 不足を補えば任せられるのか 5 仕組みを作る価値 6 まとめ 16
17. これを「移行成功」とは呼べない Build PASS 100% ≠ Production-ready 100% 17
18. 「似ているか」だけでは判定しない UI要素の有無、画面構造の整合性 実行時の状態変化、要件や仕様を満たした設計 人間が実際に移行した際に1対1の置き換えをしたのか 18
19. 情報がXMLに閉じていれば、骨格は上手く再現 人手移行 LLM生成 ※ original (XML) はPaparazziの制約で撮影できず、人手移行の実装を基準に比較 19
20. include先を渡していなかったケース 元のXML <include> × 8 LLM生成 repeat(8) + // TODO <LinearLayout ...> <include ... /> <include ... /> <include ... /> ... (計8つ) </LinearLayout> Column(...) { repeat(8) { index -> // TODO: include @layout/... // の rank{index+1} を後続生成 Box(...) { Text("rank${index + 1}") } } } → 20
21. 見た目は近いのに、構造が欠けていた 人手移行 LLM生成 21
22. WebViewを含む画面 今回のルールでは AndroidView 禁止 。 実際には既存のWebViewをComposeから使う選択肢もある。 ＝ こちらが決めたルールの影響 22
23. MotionLayoutを使った画面 実際の人手移行では、XMLを写すのではなく 画面全体を再設計 していた。 ＝ 何を作るべきかの仕様判断 23
24. LLMだけでは上手くいかなかった理由 入力情報の不足 resource / Design Systemの不足 実行時に決まる画面の状態が不明 実験ルールによる制約 画像比較の役不足 移行のスコープ判断の有無 24
25. 今日の流れ 1 実際の検証の内容 2 検証の結果 3 検証結果の考察 4 不足を補えば任せられるのか 5 仕組みを作る価値 6 まとめ 25
26. 本当にLLMの能力が原因なのか？ include のケース include先を渡していない WebView のケース AndroidView をルールで禁止した LLMそのものではなく、入力やルールの設定が原因なのでは？ 26
27. include先を渡すと、生成できる内容が増えた before repeat(8) + // TODO after repeat(8) + Row Column(...) { repeat(8) { index -> // TODO: include @layout/... // の rank{index+1} を後続生成 Box(...) { Text("rank${index + 1}") } } } repeat(8) { Row(...) { Box(...) Column(...) { ... // tools:text のみで // 実文言は入力に無い Text(text = "", ...) } } } → 27
28. raw pixel diff（画像内で違っているピクセルの割合） 元XML LLM生成 差分ピクセル before 70.75% ↓ include先を渡した後 32.35% 28
29. tools:text の文言を補うと、内容は正しくなった 元XML after（文言を補った後） before（生成Compose） → 29
30. 内容は良くなったのに、数値は悪化した → before → after raw pixel diff：4.34% → 9.20% before after edge SSIM：0.871 → 0.719 30
31. 画像比較の数値に影響した複数の要因 コンテンツが正しく入っているか 見た目のテーマが合っているか 配置が合っているか 比較方法そのものの影響なのか 31
32. 自動評価が十分なのかの考慮が追加で必要 32
33. 完全自動化には「生成」以外も必要になる 入力収集 ▶ 生成 ▶ build ▶ 評価 ▶ 採否 33
34. 今日の流れ 1 実際の検証の内容 2 検証の結果 3 検証結果の考察 4 不足を補えば任せられるのか 5 仕組みを作る価値 6 まとめ 34
35. 仕組みを一つずつ作れば、人の作業はさらに減らせそう 入力 補完 評価 関連ファイルを自動で集 める 不足な値を自動で入力 に加える 生成結果も自動で評価 する 35
36. Compose移行は、基本的に一方通行の作業 XML → Compose ↩ 移行済みの画面を再 度XMLから変換するこ とはない 36
37. 専用の仕組みを追加で作ることは、 その開発の時間に見合うのか？ 37
38. 人が毎回やる場合と、仕組みを作る場合を比べる 人が毎回やる場合 対象件数 × 1件ごとに必要な人の作業時間 専用の仕組みを作る場合 仕組みを作る時間 ＋ 自動化しても残る人の作業時間 38
39. 追加対応が必要になりそうな件数は、要因ごとに全然違う tools_only_content 151 件 style_refs 77 件 runtime_list_content 74 件 custom_view 38 件 include_dependency 10 件 39
40. 人の手で移行した際の時間を計測 小さい単位で AIへ移 行を依頼 → 出てきた結果をレ ビュー → 必要なら追加指示 / 手動修正 40
41. 人の手で移行した際の時間 27分 必要な情報を確認・収集 21分 LLMへの指示 10分 20分 生成結果のレビュー 最終確認 10分 3分 ケース1 ケース2 ケース3 コードを直接修正 3件とも0分 41
42. 仕組みで減らせそうなのはどこか 必要な情報を確認・収集 LLMへの指示 3件では1件あたり 5〜10分 42
43. まず「1日で作れるなら」で計算する 作る時間（ 1日 = 8時間） 480分 ÷ 1件あたり減らせる時間 5〜10分 ＝ 見合い始める件数 48〜96件 作る時間が増えるほど、見合いに必要な件数も増えていく 43
44. include 該当候補 10件 人間供給 1.5分（1ケース） 単純外挿で 総 15分 オーダー 大きな開発コストはかけにくい 44
45. tools 該当候補 151件 人間供給 6分（1ケース） 単純外挿で 総 約15時間 追加検証の価値が高い可能性あり 45
46. 「技術的に改善できるか」だけでは足りない。 何件に効き、人間の作業を何分減らせるかまで考える 46
47. 今日の流れ 1 実際の検証の内容 2 検証の結果 3 検証結果の考察 4 不足を補えば任せられるのか 5 仕組みを作る価値 6 まとめ 47
48. 今回の検証から、 LLMへの任せ方が見えてきた 1 XMLの特徴を分ける ↓ 2 特徴に合わせて必要な情報を集める ↓ 3 特徴に合わせた方法で AIに移行を依頼する ↓ 4 生成結果を人が確認する 48
49. ① まず、XMLの特徴を分ける XMLだけで情報がそろっている include先の情報が必要 toolsにしか値がない 実行時に内容が決まる 独自Viewを使っている WebView / MotionLayout …… 49
50. ② 特徴に合わせて、 AIへの渡し方を変える includeがある → include先のXMLも渡す toolsに値がある → 必要なサンプル値も渡す 実行時に内容が決まる → 状態やデータの情報を補う WebViewなど → 使える実装方法・ルールを見直す 再設計が必要 → 人が方針を決める 50
51. ③ 繰り返す対応だけ、さらに仕組み化を考える パターンが分かった ≠ 全部を自動化する仕組みを作る 何件あるか × 1件あたり何分 減らせるか を見て判断 51
52. 今回のCompose移行で見えた進め方 XML ↓ 特徴を分類 ↓ 必要な情報を集める ↓ 分類に合わせて AIへ移行を依頼 ↓ 人がレビュー ↘ 繰り返し数が多い対 応 → 追加で仕組み化 を検討 52
53. AIに任せる方法は、 パターンごとに変える。 仕組みにするかは、 規模を見て決める。 53
54. AIに仕事を任せるときに考える 3つ 1 2 3 うまくいかない理由を分 ける 理由に合わせて任せ方 を変える 繰り返す部分だけ仕組 み化を考える 何が原因でAIだけでは進まない のか？ どんな情報・ルール・判断が必要 なのか？ 何件に効き、人の作業をどれだ け減らせるのか？ 54
55. Masahiro Saito 55