AIと⼀緒にレガシーに 向き合ってみた NEWT Tech Talk vol.20 @nyafunta9858 

SPEAKER プロダクト本部 Yappli開発部 YappliAndroidグループ マネージャー ⼩林 慶弘 / にゃふんた ● 2024年4⽉にヤプリに⼊社 ● 趣味：ガジェット集め、WFH環境づくり ● 最近3つ折りFoldableが気になってる 

INDEX ⽬次 1. 「レガシー」機能の更新 2. 調査開始 3. 試⾏錯誤してみた 4. まとめ 

⾃分の⽣成AIとの関わり⽅ 開発 ● コードリーディング、設計‧実装、不具合解析 etc ● PRでの⾃動レビュー、スラッシュコマンドの整備 etc 開発以外 ● メンバーのスキル分析 ● 原稿執筆アシスタント キャッチアップ ● AI推進組織やアプリチーム内のメンバーから ● Discoveryに流れてくるフィード 本題の前に 

注意書き ● ゴリッゴリのコードとかは少なめです ● どっちかというと「こう考えた」「こうしてみている」な体験談‧思考の共 有な話が多めです ● ⼀部情報量が多いページもあるので、詳細や意⾒交換は資料やこのあとの懇 親会などでお願いします 本題の前に 

「レガシー」機能の更新 

「レガシー」機能？ レガシー（legacy） 英語で「遺産」を意味し、過去から引き継がれた技術、システム、仕組み、伝統 などを指す⾔葉 IT‧ビジネス分野では「時代遅れの」「負の遺産」といったネガティブなニュア ンスで使⽤されることが多い 「レガシー」機能の更新 

脱‧レガシー想定作業 ライブラリの更新 ● 要件を満たすバージョンまでライブラリを更新 ● 提供APIのインターフェース変更に対応 ● 破壊的変更に伴うマイグレーション 別選択肢への転換 ● ⾃分たちで開発‧運⽤する ● 代替‧後継となるライブラリへリプレイスする 「レガシー」機能の更新 

16KBページサイズサポート？ 「レガシー」機能の更新 

補⾜）16KBページサイズサポート 16KBページサイズサポートとは？ 処理の⾼速化 ● メモリ管理の最⼩単位が4 KB → 16 KBに拡⼤ ● ⼀度に扱うデータ量が増えるため、システム全体の速度が5〜10%向上 ● ただしシステム全体のメモリ使⽤ が約9%増加 開発者の対応 ● C/C++（NDK）を使うアプリは、16 KB環境向けの再ビルドや修正が必須 ● Java/Kotlinのみのアプリは影響なし 「レガシー」機能の更新 

脱‧レガシー想定作業 ライブラリの更新 ● 要件を満たすバージョンまでライブラリを更新 ● 提供APIのインターフェース変更に対応 ● 破壊的変更に伴うマイグレーション 別選択肢への転換 ● ⾃分たちで開発‧運⽤する ● 代替‧後継となるライブラリへリプレイスする 「レガシー」機能の更新 

脱‧レガシー想定作業 ライブラリの更新 ● 要件を満たすバージョンまでライブラリを更新 ● 提供APIのインターフェース変更に対応 ● 破壊的変更に伴うマイグレーション 別選択肢への転換 ● ⾃分たちで開発‧運⽤する ● 代替‧後継となるライブラリへリプレイスする 「レガシー」機能の更新 

調査開始 

調査開始 16KBページサイズ未サポート機能（AR）に対しての想定選択肢 ● ライブラリの更新を待つ ● 代替⼿段の模索（リプレイス） ● ⾃作は運⽤的にも厳しいため考慮し（たく）ない 調査開始 

No content

No content

移⾏先は...？ 調査開始 Active! 

移⾏計画から始めてみたものの...？ 調査開始 ● TBD 

クラッシュ💣 調査開始 

これは不穏😇 調査開始 

TBD 

Q.バグってる？ 調査開始 

調査開始 バグってる？ Before After 

調査開始 バグって...る？ Before After 

A.バグってるっぽい 調査開始 

試⾏錯誤してみた 

AR（AR Core / Filament） 試⾏錯誤してみた 

AR（AR Core / Filament） 試⾏錯誤してみた 専⾨性⾼い + 難易度⾼い + 公式情報が古い ≒ イチからは流⽯に厳しい 

【システム・コンテキスト】 あなたは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）: : : 試⾏錯誤してみた 

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では安定していたのか」の理由（例：マテリアルのキャッシュ保持など）を抽出し、現代のライブ ラリで再実装すること。 試⾏錯誤してみた 

試⾏錯誤してみた 

気付いたらずっと使ってる デスクに向かってるとき... ● Claude Code、Gemini CLI、もちろんAndroid Studioも使いつつ ● 実機での動作確認、画像‧動画‧logcatを使っての不具合解析... 開発以外 ● 移動中とか寝る前、Devinで仕込み ● Gemini Appで壁打ち などなど 試⾏錯誤してみた 

ここまでを振り返ってみると 試⾏錯誤してみた 

専⾨領域へのハードル打破 開発ステップは従来通りでも⾼い壁を感じる専⾨‧未経験領域も AIとなら 爆速な試⾏錯誤が可能に 「理解」先⾏ <「実践」先⾏ 理解が後追いでも、⾼速に試⾏錯誤‧アウトプット出来るポジティブさ 理解負債の解消 「意味を全く理解できていないコード」の咀嚼‧理解深耕の効率化が課題 試⾏錯誤を振り返り 試⾏錯誤してみた 

まとめ 

まとめ ● 16KBページサイズのようなnativeの絡むレガシー機能の対応は⼤変 ● AIなら理解に時間が掛かる領域でも、実践先⾏で爆速アウトプットが可能 ● 理解しないで済む世界に出来ると嬉しいけど、当⾯は理解負債の効率的返済 が課題のひとつ