無限スクロールの実装を通して見る、Unity上の共通基盤を作り始める際の考え方

本資料は、2026年5月14日に開催された「ゲームクリエイターズトレーニングキャンプ主催 春のLT大会＆交流会」（運営：クラスメソッド）で登壇した際に使用したスライド資料です。
LTでは、弊社で進行中のプロジェクト内で並行して開発を進めているUnity用UI共通基盤「ApUI」を作成する流れで得た知見の紹介を行いました。
OSSの採用や基盤の学習コスト、設計ミスの実例について触れております。基盤を作り始めた際にぶつかった事例の一例として、ご覧いただけると幸いです。

1. 無限スクロールの実装を通して⾒る Unity上の共通基盤を作り始める際の考え⽅ 株式会社オルトプラス 永薗 朋弥
2. ⾃⼰紹介 永薗 朋弥 Tomomi Nagasono 株式会社オルトプラス 技術部テックリード Unityクライアントエンジニア 2024年に中途⼊社。 新規開発プロジェクトに参画中。 並⾏して共通基盤の開発や、社内の Unity勉強会の運営を担当。 この前、プライベートで東京ゲームダンジョン 12に出展してきました 2
3. 株式会社オルトプラスとは 「笑顔あふれるセカイを増やす」 ➢ ゲーム開発‧運営（ゲーム領域） ➢ IT × エンタメ（⾮ゲーム領域） ➢ 共同開発‧開発⽀援（⼈材/コンサル事業他） などの事業にて、 頼れる技術集団として活動しています 3
4. 本⽇の流れ ➢ UI共通基盤「ApUI」の概要 ◦ 無限スクロール機能の概要 ➢ 基盤開発について考えるポイント ◦ 便利なアセット/OSSについて ◦ ラーニングコストについて ➢ まとめ 4
5. UI共通基盤「ApUI」 • 内製のUnity UI共通基盤パッケージ ◦ ◦ • 進⾏中のプロジェクトと並⾏する形で開発中 導⼊済みプロジェクト：2つ 現在の機能(抜粋) ◦ ◦ ◦ ポップアップの表⽰制御 無限スクロール UI タッチ⼊⼒へのインタラクション 5
6. 無限スクロール機能の概要 ➢ クラス名: ReusedScroll ◦ 表⽰要素（セル）をオブジェクトプールで管理する スクロールビュー ◦ Inspector上から挙動のカスタマイズが可能 ▪ スクロール⽅向 （縦/横） ▪ ループ設定 ▪ 慣性 ◦ 拡張コンポーネントを付与して機能を追加できる ▪ カルーセルUI 6
7. 基盤開発について考えるポイント 7
8. 便利なアセット/OSSについて • Unityの機能はアセットやOSSで拡張可能 ◦ ◦ • 普段の開発では積極的に使いたい ◦ ◦ • LoopScrollRect ▪ 無限スクロールUI DOTween / LitMotion ▪ イージング挙動を簡易に書けるライブラリ ⼯数削減 ⼀般に公開された知識が使える 共通基盤に導⼊する際は慎重な検討が必要 8
9. 共通基盤にOSSを導⼊する際の検討事項 • Unityの機能だけで実装できないか ◦ Unityの機能は都度追加されている ▪ ▪ ◦ • Unity2021〜：オブジェクトプール追加 (UnityEngine.Pool) Unity6〜 ：async/awaitのサポート (Awaitable) 数年前できなかったことが、最新だとできるかもしれない アセット/OSSのライセンス、サポートの問題 ◦ ◦ 基盤に含まれるライセンスの効⼒は基盤を利⽤するプロジェクト全てに及ぶ 使えなくなった際、移⾏のためにコストがかかる ▪ ものによっては全プロジェクトで対応を迫られる 9
10. ApUIの実装⽅針 • Unityの機能のみで⼗分に要件を満たせると判断した • サポート終了の際の差し替えコストをかけたくない 以上から、ApUIはUnityの機能のみで実装する⽅針を取った 10
11. 使えるときには使いたい • 利⽤側で導⼊したOSSの挙動を基盤内に反映させたいケースもある ◦ ◦ イージング : LitMotion 処理効率化 : ZString など 11
12. 使えるときには使いたい • 基盤の⼀部処理を外部から上書きできる構造で実装 ◦ ◦ 基盤側）ActionのSetterを公開 ▪ そのままで動くよう、基盤内の関数で初期化しておく 利⽤側）公開されたActionにOSSを使⽤した処理を上書き public class ApUICarousel { // 基盤側 public Action<float, Vector3> DoSnapAction { private get; set; } } void Awake(){ DoSnapAction = DoSnapDefault; // ApUICarousel内定義の挙動を登録 } public class Project { // 利用側 ApUICarousel _carousel; } public void Construct(){ // LitMotionのイージング処理で上書き _carousel.DoSnapAction = (time, EndPosition) => LMotion.Create(... } 12
13. 基盤の学習コストについて 基盤の学習コストは、個々のプロジェクトより注意が必要 • 基盤の学習コストは⼤⼈数に影響する ◦ ◦ • 基盤はプロジェクトを横断するため、触れる⼈が多い 同じ箇所で躓く場合、その部分がもたらす負債は必然的に⼤きくなる AIコーディングエージェントを⽤いる場合、さらに影響が⼤きくなる ◦ ◦ 現状のコーディングAIはセッションごとに毎回コードを読み込む必要がある → 新しいセッション ≒ 新しく基盤を触る⼈が増える 少⼈数チームでも起こりうる問題 13
14. 学習コストを下げるためにできること • 既存の知識にならって使えるようにする ◦ ◦ ◦ • 新しい操作、使い⽅は学習を要求する 似た機能があるなら、使い勝⼿を寄せた⽅が使いやすくなる ≒ 直感的 コーディングルールに沿って⾃動で矯正される環境を⽤意する ◦ ◦ Lint, Github Actions等 品質の保証 + ルールの学習コストの低減 14
15. ReusedScrollの実装 Unityのコンポーネント指向に沿った設計 • コアコンポーネント（ReusedScroll） ◦ 各機能の最⼩要件 ▪ ▪ ▪ • セルの位置計算処理 セルのオブジェクトプール管理 スクロール操作 拡張コンポーネント（Carousel） ◦ 最⼩要件に含まれない機能 コンポーネントの付け外しで動作を変えられる 15
16. 学習コストについての失敗例 前提知識（ReusedScroll） • コンテント座標 ◦ ◦ スクロール内の各セルの位置を保持する仮想の座標 コンテント座標上の位置を基にRectTransformを制御する これを仮想的に作ったもの→ 16
17. 学習コストについての失敗例 ReusedScroll(コアコンポーネント)の作成初期 １．作成時：縦⽅向スクロールのみ • コンテント座標の軸を下⽅向が＋になるように定義 ◦ 考えやすかったため ◦ Unityとは逆⽅向 0 +200 +300 +500 （コンテント座標） 内部動作： 上（ー⽅向）にスクロールされたら、 全てのセルのRectTransform.Y座標を＋する処理を⾏う 17
18. 学習コストについての失敗例 ２．横⽅向スクロール対応追加 • • コアコンポーネントに切り替えパラメータを追加 ◦ 縦スクロール/横スクロール コンテント座標の実装を流⽤ ◦ 0 +330 +660 （コンテント座標） 右⽅向が+となり、Unityと座標系が⼀致する 内部動作： 左（ー⽅向）にスクロールされたら、 全てのセルのRectTransform.X座標をーする 18
19. 学習コストについての失敗例 その結果 • • コアコンポーネントに縦、横の実装がどちらも含まれる 同じー⽅向へのスクロール時、 ◦ 縦スクロール ▪ 全てのセルのRectTransform.Y座標を＋する ◦ 横スクロール ▪ 全てのセルのRectTransform.X座標をーする 0 +200 +300 +500 （コンテント座標） → コアコンポーネントが縦/横の機能をどちらも含んでしまっている ＋ スクロール⽅向ごとにUnity上の座標計算が反転している 19
20. どうなった？ 問題：コアコンポーネントが縦/横の機能をどちらも含んでしまっている ＋スクロール⽅向ごとにUnity上の座標計算が反転している • 追加実装時、作業者が↑の問題を前提に作成する必要が⽣まれた // こんな処理が頻発 return _reusedScroll.Direction switch { ScrollDirection.Horizontal => pointInCanvasPosition - zeroPosition, ScrollDirection.Vertical => zeroPosition - pointInCanvasPosition, _ => throw new ArgumentOutOfRangeException() }; → 学習コストの増加、作業量、思考量の増加を招いてしまった （社内全体に広める前でまだよかった） 20
21. 今ならどうする？ 原因：コアコンポーネント内で縦と横の位置計算が混ざったこと • コアコンポーネントをさらに分割し、縦横の処理が混ざらないようにする ◦ ◦ ◦ • コンテント座標の管理 縦スクロール / 横スクロール (どちらか) セルのオブジェクトプール管理 Unityの座標系に沿った部分以外は表に出ないようにする ◦ 全てコアのコンテント座標管理内で⾏い、表に出す場合はUnity座標系に必ず変換 これらを基に、v2の設計、実装を考え中（懇親会等で意⾒などあればお聞かせください） 21
22. まとめ • 基盤にOSSを採⽤する際は以下の点を検討しよう ◦ ◦ • 基盤の学習コストを意識しよう ◦ ◦ • Unityの機能で対応できないか ライセンス、サポート終了のリスク ⼀ヶ所の難解さは多くの⼈に影響する 少⼈数チームでもAIを⽤いる際は注意 失敗したら振り返ろう ◦ 原因、対策が理解できれば経験値に変わる 22
23. ご清聴ありがとうございました！ 23