「どう作り続けるか」 ― 9年目のREALITYが挑んだアセット制作フローの再設計

GREE Tech Conference 2026で発表された資料です。
https://techcon.gree.jp/2026/session/TrackC-3

Transcript

1. 「どう作り続けるか」 9年目のREALITYが挑んだ アセット制作フローの再設計 REALITY株式会社 テクニカルアーティスト 池谷駿弥
2. 池谷 駿弥 (Shunya Iketani) REALITY株式会社 テクニカルアーティスト • 2022年、グリー株式会社（現 グリーホールディングス株式会社）へ 新卒入社し、REALITY株式会社に配属 Unityエンジニアとしてアバター機能の開発やアセット運用を担当 • 約1年半の社内プロジェクトを経て、2025年7月のTechnical Artチーム 発足に寄与 • 現在はTAとして、アセット制作パイプラインの整備からアプリ機能の 開発まで幅広く担当 2
3. 目次・アジェンダ • アプリ「REALITY」と、REALITYのアセット • アセットを「どう作り続けるか」 • アセット制作パイプラインの改善 • ◦ 品質担保の安定化 ◦ 管理の安定化 まとめ 3
4. アプリ「REALITY」 4
5. 自分好みのアバターで ライブ配信 REALITY（リアリティ）は、 誰でもスマホ１台でアバターの姿になり、 顔出しナシでライブ配信、ゲームやチャットなど コミュニケーションを楽しむことができるアプリで す。 2018年8月リリース 今年、9年目 🎉
6. 楽しみは盛りだくさん！ 6
7. 膨大なアセット制作 Unityを用いて開発されており、アバター・家具 アイテム合わせて • 毎月340以上の新規アイテム、 2800以上の新規ファイルを制作 • 月10本前後の新規ガチャがリリースされ、 平均1ガチャ/3日ペースで新作ガチャが登場 毎週アセットリリースが行われる体制 7
8. 急激な制作加速 事業方針の変化に伴い、アセット制作数が爆発的に増加し、現在では過去の 約5倍の制作量 へ アバターガチャ 家具ガチャ 過去3年は⽉1~2本で推移 家具ガチャ開始 新たなアバターアイテム 制作チーム発⾜ 新シリーズの アバターガチャ開始 8
9. How We Build? 9
10. How We Build? 長期運用のため、「どう作るか」だけでなく... 10
11. 「どう作り続けるか」 11
12. REALITYアバターアイテム制作パイプライン 企画 2D (Photoshop) 3D (Maya) マスタ データ入稿 Unity 組み込み ビルド 実機確認 PR レビュー リリース • パイプライン / 各工程の具体的なフローともに、リリース当初から 5年の間に大きな変化なし • 工程によっては、長期運用に伴って属人化が発生し、制作加速の ボトルネックに... 12
13. 運用期間が長いと、なぜ属人化するのか 多くの機能開発・アセット制作により、アセット仕様・データが複雑化・多様化 全ての仕様・機能を詳細に把握した上で、アセットの制作とチェックが必要 他開発環境・他アセットへの影響を回避しながら、 制作物がデータ格納・ビルド・リリースされる 「運用事故を回避し安定的な制作を行うこと」が目的 13
14. 矛盾する二大命題への直面 制作加速 効率的にアセットを作り続け、 量産する 安定化 VS 運用事故を起こさず アセットを制作する 効率化による制作加速を行ってきたが、制作現場は限界を迎えた 矛盾する2つを高い次元で両立させる必要がある 14
15. 効率性を維持しながら、安定性を実現する 制作加速 効率的にアセットを作り続け、 量産する 安定化 VS 運用事故を起こさず アセットを制作する 効率化はすでに行ってきたので、済み 品質担保の安定化 誰もが高水準なアセット制作が可能で、 「必然的な」 安定性を醸成させる 管理の安定化 「ミスが起こり得ない」管理体制 の実現 15
16. 制作パイプラインへの反映 2つに分離してアプローチできることが、制作パイプラインからもわかる • アセットそのものを作る工程に対して、品質担保の側面から • 制作したアセット・メタ情報の共有・ビルド・リリースなどの工程に対して、管理の側面から 企画 2D (Photoshop) 3D (Maya) マスタ データ入稿 品質担保の安定化 誰もが高水準なアセット制作が可能で、 「必然的な」 安定性を醸成させる Unity 組み込み ビルド 実機確認 PR レビュー リリース 管理の安定化 「ミスが起こり得ない」管理体制 の実現 16
17. 2つの「安定化」の側面から各工程の改善を実施 品質担保の安定化 誰もが高水準なアセット制作が可能で、 「必然的な」 安定性を醸成させる 管理の安定化 「ミスが起こり得ない」管理体制 の実現 効率的なアセット制作を維持しながら 「事故のない安定的な制作」を実現する！ 17
18. 品質担保の安定化 18
19. 品質担保の安定化 3Dデータにおける事例 企画 2D (Photoshop) 3D (Maya) マスタ データ入稿 Unity 組み込み ビルド 実機確認 PR レビュー リリース 19
20. 品質担保の安定化 Mayaで破綻が確認できない問題 REALITYでは柔軟な体型変更が行え、 どのような体型でも耐えうる3D制作が要求される 突き抜け回避などの調整がより困難となり、 Unity組み込み後に破綻が判明し、 Maya ⇔ Unityの往復作業に... 20
21. 品質担保の安定化 Maya上で「Unityの見た目」を再現 Unity上の体型変更機能と同等機能を、Maya上に実装 → 破綻をMaya上で再現でき、即座に修正可能に 21
22. 品質担保の安定化 Maya上で「Unityの見た目」を再現 Unity上の体型変更機能と同等機能を、Maya上に実装 → 破綻をMaya上で再現でき、即座に修正可能に 突き抜けが発生している メッシュが赤くハイライトされる 22
23. 品質担保の安定化 Unity組み込みにおける事例 企画 2D (Photoshop) 3D (Maya) マスタ データ入稿 Unity 組み込み ビルド 実機確認 PR レビュー リリース 23
24. 品質担保の安定化 Unity組み込みにおける改善 • アバターアイテムアイコンの作成 • 組み込み状態のチェック 24
25. 品質担保の安定化 Unity組み込み事例共通の問題点 アバターアイテム仕様の多様性・複雑性が 非常に高く、仕様により組み込み方法が大 きく異なる！ 約30のカテゴリ数、約50の種別数 シェーダの種別/マテリアルプロパティ値の違い 約30のカテゴリ REALITY独自の特殊効果/機能の有無 マニュアル化しても膨大すぎるため、組み込み対象の 仕様がどれに該当するかの照合自体が困難 同カテゴリにおける 装着部位などのによる種別違い 25
26. 品質担保の安定化 アバターアイテムアイコン • • アイテム仕様ごとに異なる作成手法 デザインに応じて柔軟に撮影をカスタマイズできる手法が必要 アイテムに応じて、撮影・作成手法が異なる アプリUI上に表示される 26
27. 品質担保の安定化 以前のアイコン作成手順(服アイテム) 以前は、「グリーンバッグ + 緑肌で撮影 → Photoshopで編集」と言う作業だった → 定型的な作業にもかかわらず、非常に手間な作業 網⽬など、複雑な形状の肌部分を 透過させることは⾮常に困難 27
28. 品質担保の安定化 アイコン撮影ツール • 常時制作する全仕様に対応し、種別ごとに全く異なる手法を1ボタンで実現 • 一部アイテムは魅力的な表現を可能とするため、画角調整も可能 服アイテムの場合、 実際に生成された画像 撮影用シェーダにより 肌を透過させている 28
29. 品質担保の安定化 以前の組み込み状態のチェック • 組み込み対象がどの仕様に該当するのかの照合すら難しい ◦ → チェック作業は、シニアアーティストやアバター担当エンジニアで すら一苦労 • 目視でのチェック体制だったが、膨大すぎて工数・心理面ともに限界だっ た... ◦ ガチャの場合、「月3~6本」 × 「約30アイテム、500ファイル」 × 「修正回数」 ◦ 20営業日換算の単純計算で、最低でも150ファイル/日の工数が必要 29
30. 品質担保の安定化 チェックツール • • • 膨大な仕様の組み合わせによるバリ エーション全仕様に対応 ビジュアル的制約・システム制約・暗 黙知(ノウハウ)まで総合的に踏まえ実 装した、完全自動チェック 仕様自動判別から、データ間参照、 ファイル内の詳細なパラメータに至る まで、非常に詳細なチェックを実現 対象を選択 するだけ ファイル間の 整合確認 • 作業者自身でチェック • 「ツールがOKを出せば問題ない」というルール という体制へ 30
31. 品質担保の安定化 「品質担保の安定化」におけるポイント 確信度の向上 100%正しく動く・見える状態へ近づけ、パイプラインの各工程ごとの品質向上と手戻り防止 思考の単純化 複雑・多様な仕様を隠蔽し、「思考の単純化」を図り、本来の「創造的作業」に専念させる システムからルールを作る 暗黙知・ノウハウまで含めた総合システムにより、システムに従えば「必然的に」ルール通りに 31
32. 管理の安定化 32
33. 管理の安定化 ビルド・実機確認における事例 企画 2D (Photoshop) 3D (Maya) マスタ データ入稿 Unity 組み込み ビルド 実機確認 PR レビュー リリース 33
34. 管理の安定化 REALITYアセットのブランチ構成とAssetBundle • REALITYでは、Git, GitHubによってバージョン管理。リリース単位ごとにブランチ作成 • アセット確認者がAssetBundleのバージョンを意識しなくとも済むように、後方互換性を 保つブランチツリー構成が組まれており、専用ブランチまで順番にマージしてビルド メインブランチ 次にリリースのアバターガチャ その次にリリースのアバターガチャ シリーズごとのツリー (アバターショップ, 家具ガチャ, ギフトアセット, etc…) 開発環境ABビルド用ブランチ 順番にマージを行い、 マージ後のブランチでABビルド 合計約30以上のブランチで 並行的に制作されている 34
35. 管理の安定化 以前の開発環境ABビルド体制 • 各ガチャシリーズの責任Art担当者から、アセット担当エンジニアへビルド依頼 • アセット担当エンジニアが順番に手動マージした上で、ビルドを実施 なぜエンジニアがマージ？ 課題・リスク • 約30以上のブランチ全てを把握し、適切に制御する必要性 • ブランチ間マージ時におけるコンフリクト解消対応 • マージ順のミスによるチーム全体成果の消失リスクの回避 35
36. 管理の安定化 開発環境ABビルド体制の改善 自身で ビルド可能 API経由で起動 GitHub Actions Slack Bot Art develop asset/gacha-kamikoma エンジニア ブランチツリーを 定義するだけ asset/gacha-love-illumination マージ順を提供 assetbundle-lab マージ後のブランチで ABビルド 定型作業のみをシステム移譲し、 本来人間が行うべき制御部のみを分離 36
37. 管理の安定化 PRレビューにおける事例 企画 2D (Photoshop) 3D (Maya) マスタ データ入稿 Unity 組み込み ビルド 実機確認 PR レビュー リリース 37
38. 管理の安定化 以前のPRレビュー体制 • Unity組み込み時と同様、どの仕様に該当するのかの照合すら難しい • Unity Editorで1ファイルずつ詳細に目視でチェックする体制 ◦ ガチャの場合、「月3~6本」 × 「約30アイテム、500ファイル」 × 「修正回数」 ◦ 1回あたり5時間以上の工数をかけることも多々あり 膨⼤すぎて⼯数‧⼼理⾯ともに限界 38
39. 管理の安定化 PRレビュー体制の改善 • • Unity組み込み時のチェックツールを 流用し、GitHub ActionsでPRレ ビューを自動化 ビジュアル的制約・システム制約・暗 黙知(ノウハウ)まで総合的に踏まえ、 全仕様に対応 PRに特定ラベルをつけるだけ アイテムごとに レビュー結果が確認可能 5時間以上の工数が5分に！ 39
40. 管理の安定化 ファイルごとの詳細なチェック結果もPR上で確認可能 Unity Editorでのチェックと同じ内容 GitHubで確認困難なバイナリデータやデータ間参照なども問題なし！ 40
41. 管理の安定化 GitHub Actionsチェックの恩恵 • 変更差分全てを調べている & 全仕様対応ツールなので、不要データの混入を検知可能 • アイテムごとの結果をアセット制作目的と比べることで、意図しない変更を検知可能 不要データ混入 制作企画として、 追加予定のものでないなら、 意図しない変更発生と判断可能 41
42. 管理の安定化 GitHub Actionsチェックの恩恵 • 変更差分全てを調べている & 全仕様対応ツールなので、不要データの混入を検知可能 • アイテムごとの結果をアセット制作目的と比べることで、意図しない変更を検知可能 リリース前の最後の工程として、 絶対に壊れたアセットを「リリースできない」 ゲートキーピング体制を実現 42
43. 管理の安定化 リリースにおける事例 企画 2D (Photoshop) 3D (Maya) マスタ データ入稿 Unity 組み込み ビルド 実機確認 PR レビュー リリース 43
44. 管理の安定化 以前のリリース体制 アバター・ルーム・ワールド・ギフトなどの各領域担当エンジニアが、PdM定義のスケジュール と、Art提出のPRを手動照合し、リリースビルド前にマージを行う 4/13にガチャリリースしたいらしいので、 該当のPRを探して4/8にマージして、 4/10のABリリースに載せる 44
45. 管理の安定化 以前のリリース体制 リリース作業担当エンジニアが、各領域担当エンジニアにマージ済みかを確認してからビルドする リリースReady? OK! アバター担当 エンジニア リリースReady? No… リリース作業 エンジニア ルーム担当 エンジニア アセット進捗いかがでしょう？ ルーム担当 Art リリースReady? OK! ギフト担当 エンジニア 45
46. 管理の安定化 リリース体制の改善 PdMはリリース日のNotion登録だけ。エンジニアはPRレビューだけ。 → Notion, GitHub PR、どちらかが不正の場合は、マージ & リリースが強制ストップ リリース日 対象のPR PdM判断のリリース可否 (PdM) 確認中... (エンジニア) Approve！ リリース準備できてない！ PRはApproveされているが、NotionでWIPがついてるのでストップ 46
47. 管理の安定化 リリース体制改善による効果 • マージ・取りまとめ・リリース意思確認など、定型作業をシステム移譲し、 本来人間が行うべき判断部分のみを分離 • 各領域担当、PdM・エンジニアそれぞれが、Notion / GitHubを通じて独立 してリリース可否判断が行え、本来の自身の責任範囲のみに注力できる体制 に 47
48. 管理の安定化 「管理の安定化」におけるポイント 定型作業のシステム移譲と、制御部への人の集中 「制御部」を見極め分離することで、一括管理体制と分散稼働を両立可能 人に依存しない検知と、強制停止の仕組みをつくる 新規仕様や意図しない変更を後続工程に流さないゲートキーピングを行う体制 責任範囲の分散 属人化を徹底排除しながら適切な責任範囲分割を行うことで、独立した作業を可能に 48
49. まとめ 49
50. 矛盾する二大命題を高い次元で両立！ 制作加速 安定化 効率的にアセットを作り続け、 量産する 運用事故を起こさず アセットを制作する 品質担保の安定化 誰もが高水準なアセット制作が可能で、 「必然的な」 安定性を醸成させる 管理の安定化 「ミスが起こり得ない」管理体制 の実現 効率的なアセット制作を維持しながら 「事故のない安定的な制作」が可能に！ 50
51. まとめ 「人」に依存しないことが、最大の「人を活かす」道 個人の経験や知識をシステムに移植し、チェック・管理から解放。 本来の「創造的作業」に集中でき、責任と作業負荷を適切に分散できる。 「システムからルール」を作り、思考の単純化を図る 暗黙知まで含めた広範な知見のシステム組み込みと、システム自体をルールとする 運用により、複雑・多様な仕様を隠蔽し、スケーラブルで長期的な安定性を支える基盤へ アセット制作の加速と安定は、両立できる 矛盾しトレードオフとされる効率化と安定性は、適切なプロセス設計により高い次元で統合可能 スケール可能なチーム体制を実現し、「作り続ける」長期運用でも問題なし！ 51
52. ご案内 改善に至った組織としての経緯などは別セッションにて発表しています REALITYにTAチームができるまでの軌跡 〜ミッション：ガチャ本数５倍に対応せよ！〜 Track C 14:00~ 52
53. ご清聴ありがとうございました 53