AIと一緒にレガシーに向き合ってみた

イベント概要
今回のNEWT Tech Talkは、"モバイルアプリ開発 x AI - 組織・技術課題と向き合い、AIとの走る"をテーマに開催します！
AIの進化が進む中で、モバイルアプリ開発の現場でも、AIとの付き合い方について話題にのぼることが増えてきています。

本イベントでは、モバイルアプリ開発の現場でAI活用に取り組む3社のエンジニアが、個人・チーム・技術課題それぞれの視点から、AIとどのように向き合い、どのように開発を前に進めてきたのかを率直に共有します。 抽象論だけでなく、実際の現場での工夫や失敗、学びを通して、モバイルアプリ開発におけるAIとの「現実的な走り方」を持ち帰っていただける場を目指します。

今回はクラシル株式会社からなぐもさん、株式会社ヤプリからにゃふんたさん、そして株式会社令和トラベルからやぎにいの3名のモバイルアプリエンジニアが集い、LT形式で発表を行います。

イベント当日は、みなさまからいただくご質問にもどんどんお答えしていきます！ また、LT会終了後はオフライン会場にて懇親会を開催します。オフライン参加いただける方はぜひともご参加いただき、ネットワーキングをお楽しみください！

https://reiwatravel.connpass.com/event/378543/

Transcript

1. AIと⼀緒にレガシーに 向き合ってみた NEWT Tech Talk vol.20 @nyafunta9858
2. SPEAKER プロダクト本部 Yappli開発部 YappliAndroidグループ マネージャー ⼩林 慶弘 / にゃふんた • 2024年4⽉にヤプリに⼊社 • 趣味：ガジェット集め、WFH環境づくり • 最近3つ折りFoldableが気になってる
3. INDEX ⽬次 1. 「レガシー」機能の更新 2. 調査開始 3. 試⾏錯誤してみた 4. まとめ
4. ⾃分の⽣成AIとの関わり⽅ 開発 • コードリーディング、設計‧実装、不具合解析 etc • PRでの⾃動レビュー、スラッシュコマンドの整備 etc 開発以外 • メンバーのスキル分析 • 原稿執筆アシスタント キャッチアップ • AI推進組織やアプリチーム内のメンバーから • Discoveryに流れてくるフィード 本題の前に
5. 注意書き • ゴリッゴリのコードとかは少なめです • どっちかというと「こう考えた」「こうしてみている」な体験談‧思考の共 有な話が多めです • ⼀部情報量が多いページもあるので、詳細や意⾒交換は資料やこのあとの懇 親会などでお願いします 本題の前に
6. 「レガシー」機能の更新
7. 「レガシー」機能？ レガシー（legacy） 英語で「遺産」を意味し、過去から引き継がれた技術、システム、仕組み、伝統 などを指す⾔葉 IT‧ビジネス分野では「時代遅れの」「負の遺産」といったネガティブなニュア ンスで使⽤されることが多い 「レガシー」機能の更新
8. 脱‧レガシー想定作業 ライブラリの更新 • 要件を満たすバージョンまでライブラリを更新 • 提供APIのインターフェース変更に対応 • 破壊的変更に伴うマイグレーション 別選択肢への転換 • ⾃分たちで開発‧運⽤する • 代替‧後継となるライブラリへリプレイスする 「レガシー」機能の更新
9. 16KBページサイズサポート？ 「レガシー」機能の更新
10. 補⾜）16KBページサイズサポート 16KBページサイズサポートとは？ 処理の⾼速化 • メモリ管理の最⼩単位が4 KB → 16 KBに拡⼤ • ⼀度に扱うデータ量が増えるため、システム全体の速度が5〜10%向上 • ただしシステム全体のメモリ使⽤ が約9%増加 開発者の対応 • C/C++（NDK）を使うアプリは、16 KB環境向けの再ビルドや修正が必須 • Java/Kotlinのみのアプリは影響なし 「レガシー」機能の更新
11. 脱‧レガシー想定作業 ライブラリの更新 • 要件を満たすバージョンまでライブラリを更新 • 提供APIのインターフェース変更に対応 • 破壊的変更に伴うマイグレーション 別選択肢への転換 • ⾃分たちで開発‧運⽤する • 代替‧後継となるライブラリへリプレイスする 「レガシー」機能の更新
12. 脱‧レガシー想定作業 ライブラリの更新 • 要件を満たすバージョンまでライブラリを更新 • 提供APIのインターフェース変更に対応 • 破壊的変更に伴うマイグレーション 別選択肢への転換 • ⾃分たちで開発‧運⽤する • 代替‧後継となるライブラリへリプレイスする 「レガシー」機能の更新
13. 調査開始
14. 調査開始 16KBページサイズ未サポート機能（AR）に対しての想定選択肢 • ライブラリの更新を待つ • 代替⼿段の模索（リプレイス） • ⾃作は運⽤的にも厳しいため考慮し（たく）ない 調査開始
17. 移⾏先は...？ 調査開始 Active!
18. 移⾏計画から始めてみたものの...？ 調査開始 • TBD
19. クラッシュ💣 調査開始
20. これは不穏😇 調査開始
21. TBD
22. Q.バグってる？ 調査開始
23. 調査開始 バグってる？ Before After
24. 調査開始 バグって...る？ Before After
25. A.バグってるっぽい 調査開始
26. 試⾏錯誤してみた
27. AR（AR Core / Filament） 試⾏錯誤してみた
28. AR（AR Core / Filament） 試⾏錯誤してみた 専⾨性⾼い + 難易度⾼い + 公式情報が古い ≒ イチからは流⽯に厳しい
29. 【システム・コンテキスト】 あなたはAndroidエンジニアリングのエキスパートです。Sceneformの安定したロジックをリファレンスとし、SceneView for Androidを用いて16KBページサイズ対応のAR顔拡 張サンプルプロジェクトを構築してください。 Step 1: プロジェクト基盤と16KB対応の厳格な定義 目的: 2026年時点の最新標準（16KBアライメント）に準拠したビルド環境を構築する。 • 実行内容: • build.gradle において、AGP (Android Gradle Plugin) 8.3以上、compileSdk 35以上を指定。 • packagingOptions または jniLibs 設定で、16KBページサイズデバイスでの動作を保証するためのアライメント設定（useLegacyPackaging = false等）を定 義。 • extractNativeLibs="false" を含む AndroidManifest.xml の生成。 • 検証（Gate 1）: • 16KB環境下でネイティブライブラリが正常にロードされる構成になっているか。 Step 2: Sceneformシーケンスの解析とライブラリ選定 目的: Sceneformの安定した処理の流れ（Sequence）を抽出し、対応するSceneViewの最新ライブラリを選択する。 • 実行内容: • Sceneformのシーケンス分析: 以下のフローをSceneViewでどう再現するか定義する。 • AugmentedFace オブジェクトの検出 → AugmentedFaceNode への紐付け → FaceMesh へのテクスチャ適用。 • ライブラリ選定: 上記フローを16KB環境で実行可能な io.github.sceneview:arsceneview の最新版（およびFilament 1.48.x以上）を選択。 • 検証（Gate 2）: • 選択したライブラリが「SceneformライクなNodeベースの操作」をサポートしており、かつ16KB対応済みであるか。 Step 3: ARCoreセッションと顔検出設定 目的: 顔拡張を有効にするためのARCore設定を実装する。 • 実行内容: • Sceneformで安定していた Config.AugmentedFaceMode.MESH3D の設定コードを、SceneViewのセッション管理フローに組み込む。 • フロントカメラ（Selfie）モードの有効化と、カメラ権限のハンドリング。 • 検証（Gate 3）: : : 試⾏錯誤してみた
30. Step 4: 顔形状テクスチャ描画の実装（コアロジック） 目的: Sceneformの描画安定性を参考に、SceneViewでのテクスチャマッピングを実装する。 • 実行内容: • テクスチャ・レンダラの実装: Sceneformの AugmentedFaceNode が行っていた「顔のメッシュ更新に合わせたテクスチャ再描画」のシーケンスを再現する。 • 不具合回避コード: feature/APP-2297 で発生した「描画消失」を防ぐため、毎フレームの onUpdate での TrackingState チェックと、マテリアルの永続化 （GC対策）を徹底する。 • サンプル用テクスチャをアセットから読み込み、顔に適用する最小限のコードを生成。 • 検証（Gate 4）: • コンパイル成功: コードにシンタックスエラーがなく、SceneViewのAPIを正しく叩いているか。 • ロジック整合性: Sceneformと同様の「検出→更新→描画」のループが壊れていないか。 Step 5: 統合検証とトラブルシューティング・レポート 目的: 最終的なソースコードの提示と、期待される挙動の解説。 • 実行内容: • 全ソースコード（build.gradle, MainActivity.kt, AndroidManifest.xml）を出力。 • Sceneformのシーケンスと今回の実装の対比表を作成（例：Sceneformの setFaceMeshTexture は SceneViewの XXX に相当）。 • 16KB環境でのビルド確認コマンドの提示。 • 検証（Gate 5）: • 既存の課題（クラッシュ、消失）に対する具体的な対策がコードに含まれているか。 運用ルール • 各ステップごとに必ず 「[Step X 完了チェック] コンパイル成功/要件適合を確認」 と明記すること。 • Sceneformのコードをそのままコピーするのではなく、「なぜSceneformでは安定していたのか」の理由（例：マテリアルのキャッシュ保持など）を抽出し、現代のライブ ラリで再実装すること。 試⾏錯誤してみた
31. 試⾏錯誤してみた
32. 気付いたらずっと使ってる デスクに向かってるとき... • Claude Code、Gemini CLI、もちろんAndroid Studioも使いつつ • 実機での動作確認、画像‧動画‧logcatを使っての不具合解析... 開発以外 • 移動中とか寝る前、Devinで仕込み • Gemini Appで壁打ち などなど 試⾏錯誤してみた
33. ここまでを振り返ってみると 試⾏錯誤してみた
34. 専⾨領域へのハードル打破 開発ステップは従来通りでも⾼い壁を感じる専⾨‧未経験領域も AIとなら 爆速な試⾏錯誤が可能に 「理解」先⾏ <「実践」先⾏ 理解が後追いでも、⾼速に試⾏錯誤‧アウトプット出来るポジティブさ 理解負債の解消 「意味を全く理解できていないコード」の咀嚼‧理解深耕の効率化が課題 試⾏錯誤を振り返り 試⾏錯誤してみた
35. まとめ
36. まとめ • 16KBページサイズのようなnativeの絡むレガシー機能の対応は⼤変 • AIなら理解に時間が掛かる領域でも、実践先⾏で爆速アウトプットが可能 • 理解しないで済む世界に出来ると嬉しいけど、当⾯は理解負債の効率的返済 が課題のひとつ