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

by makun

Embed

Start on current slide

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Masahiro Saito 齊藤正宏／ピクシブ株式会社スマホアプリエンジニア兼エンジニア採用リーダー本セッション対象アプリのCompose移行の計画・実行を担当 2

Slide 3

Slide 3 text

昨年はテストを AIに委ねる話をしました DroidKaigi 2025 「テストコードはもう書かない：JetBrains AI Assistantに委ねる非同期処理のテスト自動設計・生成」 3

Slide 4

Slide 4 text

数年かけた Compose移行を、 LLMでもう一度やってみた出発点今のLLMなら、かなり自動で進められるのでは？ ▼ 調べていくとうまくいかない理由には、いくつかのパターンがあった ▼ たどり着いた問いでは、AIにどう任せれば効率よく移行できるのか？ 4

Slide 5

Slide 5 text

今日の流れ 1 実際の検証の内容 2 検証の結果 3 検証結果の考察 4 不足を補えば任せられるのか 5 仕組みを作る価値 6 まとめ 5

Slide 6

Slide 6 text

対象は実プロダクト pixivと講談社が協業で開発するマンガアプリ Palcy。2018年から運用し、今年8月で8周年。すでに人手でCompose移行済み。つまりサンプルコードではなく、実プロダクトの XML移行をどこまでAIに任せられるかを試した。 ©株式会社講談社 6

Slide 7

Slide 7 text

対象範囲検証の対象現在 Compose 移行済みのコード巻き戻す ▶ 移行前の XMLレイアウト全279件 7

Slide 8

Slide 8 text

今日の流れ 1 実際の検証の内容 2 検証の結果 3 検証結果の考察 4 不足を補えば任せられるのか 5 仕組みを作る価値 6 まとめ 8

Slide 9

Slide 9 text

今回の検証の問い 1 LLMは Compose コードを書けるか？ 2 build error を自力で直せるか？ 3 見た目を近づけられるか？ 4 人間が移行したCompose実装と比べると、何が欠けるか？ 9

Slide 10

Slide 10 text

移行済みの Composeが既にあるが・・・実際のCompose実装やDesign Systemといった、答えに近い情報は渡さない。観測したいのは、与えた情報だけでどこまで進めるか。予め決めた範囲の情報だけを渡して検証します。 10

Slide 11

Slide 11 text

検証の流れ入力 XML ＋限定コンテキスト ▼ 生成 LLM が Compose を生成 ▼ 修正① コンパイルエラーを返して直してもらう ▼ 修正② スクリーンショットを見せて直してもらう ▼ 答え合わせ実際の移行結果との比較 11

Slide 12

Slide 12 text

まず30件で試し、 279件全件へ先行検証 30件やり方を比較して決める最終的な対象展開 → 249件同じ方法を残りのXMLへ → 279件デモではなく全件 12

Slide 13

Slide 13 text

今日の流れ 1 実際の検証の内容 2 検証の結果 3 検証結果の考察 4 不足を補えば任せられるのか 5 仕組みを作る価値 6 まとめ 13

Slide 14

Slide 14 text

279/279 エラーを返して直す工程を含め、 100% build PASS 14

Slide 15

Slide 15 text

結果を返して繰り返せば、直る問題がある高い効果一部改善 build error 大きさや配置エラーログを返せば、LLM自身で直せたスクリーンショットを見せると近づくことがある 15

Slide 16

Slide 16 text

今日の流れ 1 実際の検証の内容 2 検証の結果 3 検証結果の考察 4 不足を補えば任せられるのか 5 仕組みを作る価値 6 まとめ 16

Slide 17

Slide 17 text

これを「移行成功」とは呼べない Build PASS 100% ≠ Production-ready 100% 17

Slide 18

Slide 18 text

「似ているか」だけでは判定しない UI要素の有無、画面構造の整合性実行時の状態変化、要件や仕様を満たした設計人間が実際に移行した際に1対1の置き換えをしたのか 18

Slide 19

Slide 19 text

情報がXMLに閉じていれば、骨格は上手く再現人手移行 LLM生成 ※ original (XML) はPaparazziの制約で撮影できず、人手移行の実装を基準に比較 19

Slide 20

Slide 20 text

include先を渡していなかったケース元のXML × 8 LLM生成 repeat(8) + // TODO ... (計8つ) Column(...) { repeat(8) { index -> // TODO: include @layout/... // の rank{index+1} を後続生成 Box(...) { Text("rank${index + 1}") } } } → 20

Slide 21

Slide 21 text

見た目は近いのに、構造が欠けていた人手移行 LLM生成 21

Slide 22

Slide 22 text

WebViewを含む画面今回のルールでは AndroidView 禁止。実際には既存のWebViewをComposeから使う選択肢もある。＝こちらが決めたルールの影響 22

Slide 23

Slide 23 text

MotionLayoutを使った画面実際の人手移行では、XMLを写すのではなく画面全体を再設計していた。＝何を作るべきかの仕様判断 23

Slide 24

Slide 24 text

LLMだけでは上手くいかなかった理由入力情報の不足 resource / Design Systemの不足実行時に決まる画面の状態が不明実験ルールによる制約画像比較の役不足移行のスコープ判断の有無 24

Slide 25

Slide 25 text

今日の流れ 1 実際の検証の内容 2 検証の結果 3 検証結果の考察 4 不足を補えば任せられるのか 5 仕組みを作る価値 6 まとめ 25

Slide 26

Slide 26 text

本当にLLMの能力が原因なのか？ include のケース include先を渡していない WebView のケース AndroidView をルールで禁止した LLMそのものではなく、入力やルールの設定が原因なのでは？ 26

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

raw pixel diff（画像内で違っているピクセルの割合）元XML LLM生成差分ピクセル before 70.75% ↓ include先を渡した後 32.35% 28

Slide 29

Slide 29 text

tools:text の文言を補うと、内容は正しくなった元XML after（文言を補った後） before（生成Compose） → 29

Slide 30

Slide 30 text

内容は良くなったのに、数値は悪化した → before → after raw pixel diff：4.34% → 9.20% before after edge SSIM：0.871 → 0.719 30

Slide 31

Slide 31 text

画像比較の数値に影響した複数の要因コンテンツが正しく入っているか見た目のテーマが合っているか配置が合っているか比較方法そのものの影響なのか 31

Slide 32

Slide 32 text

自動評価が十分なのかの考慮が追加で必要 32

Slide 33

Slide 33 text

完全自動化には「生成」以外も必要になる入力収集 ▶ 生成 ▶ build ▶ 評価 ▶ 採否 33

Slide 34

Slide 34 text

今日の流れ 1 実際の検証の内容 2 検証の結果 3 検証結果の考察 4 不足を補えば任せられるのか 5 仕組みを作る価値 6 まとめ 34

Slide 35

Slide 35 text

仕組みを一つずつ作れば、人の作業はさらに減らせそう入力補完評価関連ファイルを自動で集める不足な値を自動で入力に加える生成結果も自動で評価する 35

Slide 36

Slide 36 text

Compose移行は、基本的に一方通行の作業 XML → Compose ↩ 移行済みの画面を再度XMLから変換することはない 36

Slide 37

Slide 37 text

専用の仕組みを追加で作ることは、その開発の時間に見合うのか？ 37

Slide 38

Slide 38 text

人が毎回やる場合と、仕組みを作る場合を比べる人が毎回やる場合対象件数 × 1件ごとに必要な人の作業時間専用の仕組みを作る場合仕組みを作る時間＋自動化しても残る人の作業時間 38

Slide 39

Slide 39 text

追加対応が必要になりそうな件数は、要因ごとに全然違う tools_only_content 151 件 style_refs 77 件 runtime_list_content 74 件 custom_view 38 件 include_dependency 10 件 39

Slide 40

Slide 40 text

人の手で移行した際の時間を計測小さい単位で AIへ移行を依頼 → 出てきた結果をレビュー → 必要なら追加指示 / 手動修正 40

Slide 41

Slide 41 text

人の手で移行した際の時間 27分必要な情報を確認・収集 21分 LLMへの指示 10分 20分生成結果のレビュー最終確認 10分 3分ケース1 ケース2 ケース3 コードを直接修正 3件とも0分 41

Slide 42

Slide 42 text

仕組みで減らせそうなのはどこか必要な情報を確認・収集 LLMへの指示 3件では1件あたり 5〜10分 42

Slide 43

Slide 43 text

まず「1日で作れるなら」で計算する作る時間（ 1日 = 8時間） 480分 ÷ 1件あたり減らせる時間 5〜10分＝見合い始める件数 48〜96件作る時間が増えるほど、見合いに必要な件数も増えていく 43

Slide 44

Slide 44 text

include 該当候補 10件人間供給 1.5分（1ケース）単純外挿で総 15分オーダー大きな開発コストはかけにくい 44

Slide 45

Slide 45 text

tools 該当候補 151件人間供給 6分（1ケース）単純外挿で総約15時間追加検証の価値が高い可能性あり 45

Slide 46

Slide 46 text

「技術的に改善できるか」だけでは足りない。何件に効き、人間の作業を何分減らせるかまで考える 46

Slide 47

Slide 47 text

今日の流れ 1 実際の検証の内容 2 検証の結果 3 検証結果の考察 4 不足を補えば任せられるのか 5 仕組みを作る価値 6 まとめ 47

Slide 48

Slide 48 text

今回の検証から、 LLMへの任せ方が見えてきた 1 XMLの特徴を分ける ↓ 2 特徴に合わせて必要な情報を集める ↓ 3 特徴に合わせた方法で AIに移行を依頼する ↓ 4 生成結果を人が確認する 48

Slide 49

Slide 49 text

① まず、XMLの特徴を分ける XMLだけで情報がそろっている include先の情報が必要 toolsにしか値がない実行時に内容が決まる独自Viewを使っている WebView / MotionLayout …… 49

Slide 50

Slide 50 text

② 特徴に合わせて、 AIへの渡し方を変える includeがある → include先のXMLも渡す toolsに値がある → 必要なサンプル値も渡す実行時に内容が決まる → 状態やデータの情報を補う WebViewなど → 使える実装方法・ルールを見直す再設計が必要 → 人が方針を決める 50

Slide 51

Slide 51 text

③ 繰り返す対応だけ、さらに仕組み化を考えるパターンが分かった ≠ 全部を自動化する仕組みを作る何件あるか × 1件あたり何分減らせるかを見て判断 51

Slide 52

Slide 52 text

今回のCompose移行で見えた進め方 XML ↓ 特徴を分類 ↓ 必要な情報を集める ↓ 分類に合わせて AIへ移行を依頼 ↓ 人がレビュー ↘ 繰り返し数が多い対応 → 追加で仕組み化を検討 52

Slide 53

Slide 53 text

AIに任せる方法は、パターンごとに変える。仕組みにするかは、規模を見て決める。 53

Slide 54

Slide 54 text

AIに仕事を任せるときに考える 3つ 1 2 3 うまくいかない理由を分ける理由に合わせて任せ方を変える繰り返す部分だけ仕組み化を考える何が原因でAIだけでは進まないのか？どんな情報・ルール・判断が必要なのか？何件に効き、人の作業をどれだけ減らせるのか？ 54

Slide 55

Slide 55 text

Masahiro Saito 55