終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術～不思議な生き物リヴリーの体を借りて、終末世界を冒険！世界観を支えるURP描画設計・量産パイプライン・AI活用について～

CEDEC 2026 SESSION 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術〜不思議な生き物リヴリーの体を借りて、終末世界を冒険！世界観を支えるURP描画設計・量産パイプライン・AI活用について〜 ENSAPIA
Engineering 株式会社高野正也 / Masaya Takano

自己紹介 SPEAKER 高野正也 ENSAPIA Engineering 株式会社 LIVING with LIVLIES
グラフィックエンジニア兼テクニカルアーティスト担当範囲本日お話しする 4 つの基盤を横断して担当（描画処理・量産パイプライン・エディタ拡張・ AI 活用）経歴家庭用ゲームのタイトル開発・内製グラフィックエンジンの開発と運用・ Maya 起点のアセットデータパイプライン構築・運用 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 1 / 41

LIVING with LIVLIES — ゲーム紹介 CEDEC 2026 / 終末スローライフアプリ『LIVING with
LIVLIES』運用を支える技術 2 / 41

LIVING with LIVLIES — 終末世界で暮らす不思議な生き物リヴリー終末スローライフアプリ GAME OVERVIEW リヴリーとの暮らしジャンル
終末スローライフアプリプラットフォーム iOS / Android 世界観 3Dで表現された終末世界で、不思議な生き物リヴリーと暮らすマルチプレイエリアに最大 8 匹のリヴリーが集まるカスタマイズアバター × ハウス × エリアの自由度開発環境 Unity 6000.3.13f1 / URP [Screenshot] [Screenshot] Daily life with Livly Area / 8 players アバターハウス [Screenshot] Avatar customization CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術エリア（マルチプレイ） [Screenshot] House customization 3 / 41

LIVING with LIVLIESを開発する上での様々な課題世界観へのこだわり、膨大なアセットの量産。現場で直面した課題不思議な生き物、リヴリーの世界観表現数千を超えるアバター・ハウスデータの量産体型も動きも全く異なる、多種多様なリヴリーへの対応高品質でバリエーション豊かなエリアマップの作成リリース後も、継続的な追加と改修は止まらない全ては「運用で増え続けるコンテンツの量産を、どう支えていくか」という共通の課題
CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 4 / 41

AGENDA 本日のアジェンダ目安 1:00

本日のアジェンダ 01 世界観を守るグラフィック設計 02 C3D アセット量産パイプライン 03 制作を加速するエディタツール群 04 AI
Centricな開発体制へ 05 まとめ CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 5 / 41

CHAPTER 1 世界観を守るグラフィック設計目安 10:10 世界観の制約を制作に押し付けない描画設計

1-1. リヴリーは「重なってはいけない」対象「エリア」でのリヴリーのマルチプレイヤー表示に関する課題世界観リヴリーは「生き物」。だから決して重なってはいけない同時表示エリアには最大
8 匹が共存する問い: エリアの世界観を守りながら、最大8匹の前後関係をどう制御するかかわいいけど、かわいい問題ではない CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術同じ位置にリヴリーを配置すると埋まってしまう理想：優先度順に重ならず表示される 6 / 41

1-2. 素直な解法：エリアマップに 8 レーンを作るステージを上から見た図（Top-Down View）この案の問題点横スクロール方向奥 Z
= L8 8 Z = L7 7 Z = L6 6 Z = L5 5 Z = L4 4 Z = L3 3 Z = L2 2 Z = L1 1 ! エリアマップが 8 レーン前提に縛られる地形・障害物・装飾物の配置が、レーン構造を崩さない範囲に制限 ! 8 レーン × 3 要素を設計する負担各レーンに手前・通常・奥があり、見え方の制約が一気に増える ! 手前仕様変更への耐性が低い「人数増やしたい」「重なる場面を作りたい」等への対応が困難同じ X / Y 座標で、Z（奥行き）だけ違う 8 つの固定レーンに配置 8レーン × 3要素が制作負担とデザイン制約になる。負担をアセット制作側に押しつけただけの解決方法 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 7 / 41

1-3. エリア制作の自由度を奪う本当にやりたいのは、8レーン化ではなく「1レーンのままでも破綻しない」ことエリアマップのレイアウトが常に 8 レーン前提になるさらに各レーンで「手前・通常・奥」の3要素を意識する必要がある。アセット制作側に大きな負担本当にやりたいのは、エリアのリヴリー配置を1 レーンのままで作れること最大
8 匹が同じレーン上に来ても、表示時の前後関係で破綻させないエリアの描画問題を、エリアマップ制作の負担にしてはいけない CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 8 / 41

1-4. 制約をエリアマップから描画側へ移す制作物に制約を足すのではなく、ランタイムの描画設計で吸収する Before: エリアマップ側で保証 Area Map Asset
描画都合が地形・配置・改修に漏れる After: エリア専用の描画側で保証責任の移動 Area Map Runtime 1レーンのまま Stencil RenderQueue 重ならない保証を、表示時の描画処理へ閉じ込めるエリアマップは1レーンのまま、最大8匹の前後関係を描画側で制御する CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 9 / 41

1-5. ステンシルバッファを用いた3パスレンダリングによる解決 Unity URP（RenderGraph）に、エリアでのリヴリー描画専用の3パスを挿入 ① WriteStencil パスリヴリーごとの識別値を奥から順にステンシルバッファへ書き込む ②
Color パス ③ ClearStencil パスステンシル値と自身の識別値が一致するピクセル（領域）にのみ、カラーを描画する後続の描画処理に影響を与えないよう、ステンシルバッファをクリアする ※このパスではカラーの描画は行わない実行タイミング: URP BeforeRenderingOpaques / LayerMask でリヴリーレイヤーのみ対象各リヴリーのマテリアルのレンダーキューに、奥から順に描画される値を設定 → 前面が優先される → 識別値＋ RenderQueue で、同じ位置で重なっていても優先度をつけて描画 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 10 / 41

1-6. なぜこれで重ならないのかピクセル単位での動作（模式図） 1 2 3 4 ★ 各リヴリーに識別値を持たせる同じ画面内のリヴリーを
ステンシル上で区別できるようにする RenderQueue で前後関係を決める奥に見せたいものから先に処理し、前に見せたいものを優先する WriteStencil パスでステンシル書き込みリヴリー A リヴリー B Ref = 1 Ref = 2 ↓ 描画パイプラインを通った結果描画対象領域にZテスト無効で、そのリヴリーの識別値を奥から順に書き込む 2 2 2 2 2 2 2 2 2 2 1 2 1 2 2 2 2 1 1 1 1 1 2 2 2 2 1 1 1 1 1 2 2 2 2 1 1 1 2 2 Color パスで Comp=Equal 描画自分の識別値と一致する領域だけ色を描画する結果：同座標で重なっても優先度通りに描画前面リヴリーが優先 / 互いに重なり・埋まりが発生しない 2 1 1 2 B（大）が背面、A（小）が前面 → 重なる領域では A の Ref=1 が優先 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 11 / 41

1-7. URP実装：3パスを積むところ public override void Create() { string[] stencilTagName =
{ "WriteStencil" }; string[] colorTagNames = { "UniversalForward", "SRPDefaultUnlit" }; _stencilPass = new AreaLivlyRenderPass( "AreaLivly_WriteStencil", stencilTagName, settings.passEvent, settings.layerMask); _colorPass = new AreaLivlyRenderPass( "AreaLivly_Color", colorTagNames, settings.passEvent + 1, settings.layerMask); URP実装で見せたいこと 1 色を出さず、リヴリーごとの識別値をステンシルへ書く。 2 public override void AddRenderPasses( ScriptableRenderer renderer, ref RenderingData renderingData) { renderer.EnqueuePass(_stencilPass); renderer.EnqueuePass(_colorPass); renderer.EnqueuePass(_clearPass); } CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 Color UniversalForward / Unlit を描き、識別値が一致する領域だけ色を出す。 3 ClearStencil 次フレームへ持ち越さないよう、最後にステンシルを消す。 _clearPass = new ClearStencilPass( "AreaLivly_ClearStencil", settings.passEvent + 2); } WriteStencil 4 Enqueue順がそのまま意図 URPに Write → Color → Clear の順に積み、1フレーム内に処理を閉じる。 3パスを明示的に積むことで処理の意図を小さく保つ 12 / 41

1-8. まとめ：エリア制作の自由度を取り戻す描画側が吸収することで、エリア制作側の自由度を取り戻す B efore: エリアマップ8レーン案 After: エリア専用の描画側で保証 1レーン上に最大8匹
地形・装飾・通路が描画都合に引っ張られるエリアマップは1レーンのまま最大8匹を描画側で制御自由度改修安定性負荷 1レーンのまま既存エリアの負担減 Z-fighting回避処理負荷は小さい CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 13 / 41

CHAPTER 2 C3D アセット量産パイプライン目安 10:30 デザイナーに Unity セットアップを背負わせず、アセットを大量生産する

2-1. C3Dとは：Mayaの3DデータをUnity完成Prefabへ変換する仕組み C3Dは Cocone 3D の略称 MayaデータをUnity で使える Prefab をセットアップする内製パイプライン
デザイナーが本当に時間を使いたいのは、Unity セットアップではなく制作そのもの目的は「アセットの大量生産」と「デザイナー負担を増やさないこと」の両立 Maya CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 Unity 14 / 41

2-2. 手作業のセットアップが、大量生産を止める Material / Texture / Prefab / Variant /
Component の設定が毎回発生する人手に寄せるほど、設定漏れ・品質差・確認往復・依頼待ちが増える数が増えるほど、デザイナーにも TA / エンジニアにも負担が積み上がる作業者を増やしても、セットアップ手順が残る限り量産のボトルネックになる CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 15 / 41

2-3. C3DによるMayaからUnity完成Prefabまで Maya Unity C3Dでセットアップされる要素 Material Texture Prefab Component Variant
Shader / Property Import設定 / 命名判定生成 / Material割当意味付け / 参照解決色違い / 設定同期目的: Mayaで作った素材を、デザイナーの手順を増やさず大量生産へ乗せる CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 16 / 41

2-4. 仕組み ①：セットアップパラメータをjsonファイルに明記 Unity 上の手作業を、JSON と命名規則に移す実例: AR00001BK00BG02_Mat.json（抜粋） Shader
/ Queue Shader種別やRenderQueueをデータで指定 Texture BaseMapがTexture定義へつながる再生成 Unity側で毎回手設定しなくても同じ品質になる設定を人の記憶ではなく再実行できるデータにする CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 AR00001BK00BG02_Mat.json { "Materials": { "Mat_MatCapTransparent_AR00001BK00BG02": { "BaseMap": "file116", "ShaderType": "P3/Extra/MatCapTransparent", "Surface": "Transparent", "RenderQueue": 3000 } }, "Textures": { "file116": { "Name": ".../AR00001BK00BG02_B.png", "WrapU": true, "WrapV": true } } } 17 / 41

2-5. 仕組み ②：プロジェクト固有のComponentセットアップ C3D本体はComponentを知らず、JSON + Reflection で付加・設定する 1 2 3
4 5 PropertyList.Components PrefabImporter が配列として読む入力JSON例: PropertyList.Components（C3Dが処理する形式） { "PropertyList": { "Components": [ { "namespace": "Ftol.View.Area", "component": "AreaObjectSettings", "hierarchy": ["AreaObjectRoot"], "startActive": true, "useStartPositionY": true, "startPositionY": 0.15, "attachPoint": "Find:AttachPoint" } ] } namespace + component 型名を作り、実行時Assemblyから探す hierarchy 付加先の GameObject 階層を探す残りのキー Field / Property を Reflection で設定 Find: 参照階層やAsset参照を値として解決する } Component固有の情報はJSONへ。C3D本体は共通コードのまま、プロジェクト差分を吸収する CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 18 / 41

2-6. 仕組み ③：バリエーションデータの量産色違いはMaterialを差し替える。でも、Prefabの意味付けは失わない 1 VariationDataを読む入力 JSON例: VariationData（C3Dが処理する形式） OriginalPrefab/
MaterialAssignList 2 新しいMaterialを作る 3 元Prefabを複製する 4 Materialだけ差し替える 5 Componentなどの設定を同期する { "MaterialFile": "AA10012BDA00_01_Mat.json", "VariationData": { "OriginalFBX": "AA10012BDA00_00.fbx", "OriginalID": "AA10012BDA00_00", "MaterialAssignList": { "Mat_Body_00": "Mat_Body_01", "Mat_Accent_00": "Mat_Accent_01" } } variation側の mat.json をImport OriginalFBX由来のPrefabをInstantiate Renderer.sharedMaterialsを置換元PrefabVariantからコピー・参照再マップ } 見た目だけを増やし、Component設定・参照・レイヤーは元PrefabVariantから引き継ぐ CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 19 / 41

2-7. 章まとめ：C3D 背負わせない設計デザイナーからUnityセットアップの手間を徹底的に排除し、本来の「ものづくり」に集中できる環境を知恵と設計で突破する一見して技術的に困難な制約があっても疎結合な設計と工夫により、汎用的で持続可能なパイプラインを構築できるアセットデータパイプラインの性能１つでプロジェクト全体の生産性は劇的に変わるどんな壁があっても、エンジニアとして
最後まで諦めずに可能性を探し続ける CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 20 / 41

CHAPTER 3 制作を加速するエディタツール群目安 14:10 内製エディタツールの中から、代表的な二つの事例を紹介

3-1. 制作を成立させる二つのツール数ある開発ツールの中から、代表的な2つの開発事例を紹介 ① サムネイル生成ツール（量産化の仕組み）膨大な数のアセットサムネイルを、自動でバッチ生成するツール ② エリア用ツール（ワークフローの整備）ルートや必要データを扱う専用の編集基盤を構築し、複雑な制作を成立させた事例 CEDEC
2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 21 / 41

EDITOR TOOLS サムネイルツール

3-2. サムネイルとはゲーム内のUI処理や画面表示で使う小さな2D画像【役割と要件】プレイヤーが最も頻繁に目にする画像・一覧、ショップ、所持品など、UIの根幹を担う小さな2D画像・「見た目の品質」と、パッと見の「判別しやすさ」の両立が必須【制作上の課題】膨大な量と「品質の均一化」のジレンマ・アイテム数が膨大でも、全体で一定の品質・トーンを揃える必要がある・品質を追求するほど、どうしても手動での微調整（手作業）が多くなりがちだった実際のアイテムボックス画面

3-3. 大量のサムネイル制作を、自動作成に置き換える大量のサムネイル作成の制作工程を自動化【直面した現実】約7,000枚という圧倒的物量・総数は現時点で 6,980枚（アバター 3,663 / ハウス
2,302 / その他 1,015）・追加・差し替え・修正のたびに、手動対応では莫大なコストが発生【ツール目的】手作業の完全排除、バッチ自動化・高品質なサムネイル画像を、自動でまとめて一気に作成できる環境を目指した CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 23 / 41

3-4. でも、自動化は簡単ではなかった直面した技術的な壁：単純な一括処理では実用的な画像にならない【アバター用サムネイルの課題】「状態」による見え方の変化・装着部位に応じた下地マネキンの制御や、お勧め位置の反映・アニメーション、揺れ物、Particle（エフェクト）の影響【ハウス用サムネイルの課題】「形状・サイズ」の多様性・形や大きさが幅広く、固定の画角では収まりきらない・複雑な形状や階層構造により、バウンディングボックスが正確に取れない【結論】自動化を成立させるには
「アイテムごとの差」をシステムで吸収する必要があった CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 24 / 41

3-5. 差をツール側で吸収して、量産を成立させた「アイテムごとの差」を整理・分解し、分解した機能ごとにカスタム処理を実装し対応【解決方針】美しい汎用化を諦め、「泥臭い個別対応」を徹底する・理想（シンプルで汎用的）を追うと、結局は「人間のパラメータ調整」が残ってしまう・人間が「目で見て、どう撮るか判断する工程」をすべてシステム化すると決断【実装した「人間の判断」の具体例】・アバター：
ItemTypeからの画角判定、 Particle検知時はSeedを固定して連番撮影・ハウス：コード名からの種別判定、形状の破綻を検知して自動で頂点ベース計算へ切替【結果】ツール側が泥臭さを引き受けたことで、量産体制が成立・内部は条件分岐の塊だが、デザイナーにとっては「一発で実用的な画像が出る」ツールにツール導入前 → 導入後（1枚あたり）約5分 → 約5秒約98% 削減アバター＋ハウスで、手作業なら約400時間超を削減 ※再撮影は含まず CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 25 / 41

EDITOR TOOLS エリア用ツール

3-6. エリアとはリヴリーと暮らし・探索する、ゲーム体験の中核【役割】ゲーム体験の中核となる「探索の舞台」・すごろく状のマスを移動し、素材やアイテムを集めるゲームのメインコンテンツ・最大8匹で集まれるマルチプレイの場でもある【制作要件】「背景美術」と「ゲームロジック」の統合・単なる背景の見た目だけでなく、探索ルートや
マス属性（ゲーム情報）の構築が不可欠・これらを統合して作る「専用の編集基盤」がなければ、制作自体が成立しない CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 26 / 41

3-7. エリア編集のためのツールを整備し、ワークフローを構築全体像: エリア制作を、背景作成→ルート→検証→全体→出力の流れにする背景作成 JSON からエリアの土台シーンを作り、背景の見た目を作る
ルート作成配置チェックミニマップ作成データ出力マスとルートをつないで編集する配置の制約をScene 上で検証するエリア全体を2Dで俯瞰・調整するルート/マス情報を出力しマスターデータへ連携背景作成 → ルートを編集 → 制約を検証 → 全体を2Dで整える → マスターデータへ出力 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 27 / 41

3-8. ミニマップとは — 3D空間のルートから、2Dマップへ 3D空間に引いたルートを、ゲームに出る2Dミニマップに変換するミニマップエディタで変換 3D空間に引いたルート（マス/接続）ゲーム画面のミニマップ（赤枠） 3D空間の複雑なルートを、プレイヤーが現在地と道筋を把握できる2Dマップへ

3-9. ミニマップエディタで、2D配置とマス設定を行う【機能1：見た目の作成】3Dルートからの2D配置の自動生成・「エリア配置を再現」機能で、 3Dのマス/ルート情報から 2D配置を自動生成・エディタ機能で綺麗な整列・微調整を行える【機能2：ロジックの作成】マスごとのゲーム挙動の付与・インスペクタ上で、地形（ Terrain）やビネットなどのパラメータを設定
・メソッド呼び出しを設定し、特定マス到達時の演出（アニメのトリガー等）に活用【結果】「UIの見た目」と「ゲーム挙動」を1つのエディタで統合・編集結果はコンポーネントに保存され、そのままゲームへ反映される CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 29 / 41

3-10. 配置チェックツールで、見えない制約を見えるようにした目で見えない配置の制約を Scene 上に可視化し、破綻を防ぐ【重なりの検証】モンスター / リヴリーゴースト / 灯火
/ パワースポットが背景にめり込む箇所を検出【空間制約の可視化】天井までの距離や、マス間の高低差（ジャンプの要否）まで自動判定【修正へのシームレスな導線】違反箇所を SceneView 上に色分けの Bounds で表示し、クリックでその場所へジャンプ【結果】シーン名から対象データを自動で引き当て、「勘や記憶」ではなく「見ながら直せる」環境を実現左から: モンスターと地形の重なり／天井までの距離／マス間の高低差（赤＝要修正・黄＝閾値内） CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 30 / 41

3-11. エリア用ツールがもたらしたこと【情報の統合と可視化】・探索ルートやマス属性など、目に見えないゲーム情報をツール上で扱えるようにした・導線・制約・全体構造を「見ながら」編集できる環境を構築【分断のないワークフロー】・ベース作成からデータ出力までの5つのステップを、一連の流れとして連結・手順を追うだけで、勘や記憶に頼らずに確実にエリアを制作可能に【最大の成果】デザイナーが「空間づくり」に集中できるようになった・ツールの整備が、結果としてアプリの中核体験（エリア）のクオリティ向上に直結した

CHAPTER 4 AI Centricな開発体制へ目安 12:15 AI前提で開発を組み替える

4-1. AI大転換（AI Centric Transformation）会社として、AI前提の開発組織へ強く舵を切った AI First を行動原則にする。AIとどのように協業して業務を行っていくか新規プロジェクトは AI
Centric 、既存プロジェクトは AI-Ready という考え方を適応・AI Centric : AIを主軸とした開発ワークフロー・AI-Ready : AIが力を発揮できる構造へ寄せていく開発ワークフロー LIVING with LIVLIES は新規タイトルで、文脈としては AI Centric に近い LIVING with LIVLIESでのAIツールの導入・方針転換はスムーズに進んだ CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 32 / 41

4-2. 複数の選択肢がある中で、自然と Claude Code が中心になった標準採用というより、現場で主軸が決まっていった当時は Copilot / Cursor
/ Claude Code / Codex など、複数の選択肢があったチームで一律に決めたというより、使いながら自然と Claude Code が中心になったその後、中心になった使い方に合わせて rules や skills が整備されていった導入を議論するフェーズではなく、使いながら改善するフェーズに入れた CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 33 / 41

4-3. 主軸は Claude Code、でも他のツールも使えるように AIツールの使用は、1つに固定しない適材適所でのツールの使い分け・主軸（実装・タスク実行） : Claude Code
を中心に据える・別視点（検証・レビュー） : Codex を活用（PRレビュー、並列調査など） AI間の「共有資産」の構築・リポジトリ内の ai/ ディレクトリにルールやスキルを集約・Claude / Codex / Copilot のどれを使っても、同じ文脈で動けるように整備方針：中心を定めつつも、1つのAIに縛られない運用 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 34 / 41

4-4. AIで速くなった分、人間がボトルネックになった課題：ボトルネックになっているのは人間直面した新たな課題：人間の「確認待ち」による停滞・AIで実装は高速化したが、コンパイル、ログ確認、PRレビュー、Approveなど「人が見る」工程で作業が止まる・Unity開発は制約が多く、Playモードやログを毎回人が確認する運用は限界に解決へのアプローチ：AIが自走できる「環境」の構築・AIツール単体ではなく、AI自身が確認を進められる仕組みが必要だった・① ローカルループ：
AIが自分でコンパイルとログを確認・対応する仕組み・② PR側のAIフロー：レビューと承認の詰まりを解消する仕組み次ページ以降：この2つの環境をどう整えたか、具体的な仕組みを解説 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 35 / 41

4-5. rules と skills を、チームの共有資産に土台1: プロジェクト知識を、AIが読める形にするプロジェクト共通ルール（知識）の集約・ai/rules/shared/*.instructions.md に規約を集約
・Claude / Codex / Copilot が同じルールを参照できる環境を構築人間がやっていた作業の「Skill（行動）」化・ai/skills/ に16個の共有Skill（コマンド）を用意・unity-compile：Unity特有のコンパイル確認を自動化・fix-github-pr-review：PRのレビュー指摘への対応を自動化・self-review：実装後のセルフチェックを自動化繰り返しの「確認作業」をチームの資産に変え、AIの自律ループの土台に CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 36 / 41

4-6. unity-cli で、AIが Unity を操作できるように MCPではなく CLI で、実装から確認まで自走させる MCP運用時の課題（インジェクションリスク・トークン肥大化）からCLI方式へ移行
AIの役割を「提案」に限定し、システムへの「実行権限」を明確に分離 unity-cli コマンド一つで status / --compile / console / play / exec 等を網羅 exec で Editor C#（拡張）を実行し、Prefab・アセットの調査・修正から検証まで自走安全性を担保しながら、Unity固有の検証を含むフィードバックループを劇的に高速化 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 37 / 41

4-7. CI/CD への導入 CI/CDと連携した「PRレビュー工程」のAI自動化課題：ローカルでの実装高速化に伴う「人のレビュー・承認待ち」のボトルネック化解決： CI/CDフローに3つのAI機能を組み込み詰まりを解消・
Multi-AI Code Review: PRに対して複数AIによる多角的なコードレビューを実行・AI Review Feedback: レビュー時の誤検知や改善点を、AI 自身の rules に自動還元・Auto Approve: 自作のPR監視ツールがpushごとに検証し、安全なPRは即座にApprove（承認） AI活用を開発パイプライン全体に拡張し、チームの開発効率を飛躍的に向上 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 38 / 41

4-8. マルチAIレビューと自動Approveで、人の待ち時間を減らす Claude / Codex / Copilot を統合し、push ごとの自動Approve までつなぐ
ステップ1：複数モデルによる「並列レビュー」と「統合」・Codex / Copilot の個別レビューを、 Claudeがメタ分析して「統合レビュー」として集約ステップ2：指摘対応から承認（Auto Approve）までの自走・基本フローは「 AIの指摘に対応 → 自動Approve」で完結させ、人を待たせずに進行・人間の介入は、確認が必要なケースに絞って Slack通知でピンポイントに依頼目指した姿：すべての往復を人が担うのではなく、人が止まらなくても自律的に前に進むPRフロー CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 39 / 41

4-9. 章まとめ AIの「導入」から、AI Centricな「運用体制」の構築へ 1. スムーズな導入とツールの定着・会社の推進を追い風に、Claude Code を主軸とした複数AI環境を素早く日常化 2.
「人がボトルネックになる」新たな課題への対処・ローカル環境： unity-cli による実行権限の分離と、調査・修正から検証までの自走ループ構築・レビュー工程： GitHub Actionsでの複数AIレビューと、自作ツールによる自動Approve 3. 開発フロー全体へのAI組み込み・ rules / skills / unity-cli / CI・CD までをチーム資産化【結果】『LIVING with LIVLIES』における「AI Centricな開発体制」の実現 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 40 / 41

CHAPTER 5 まとめ目安 2:10

5-1. LIVING with LIVLIES 運用を支える技術とは世界観を守るグラフィック設計・世界観の制約をアセット制作者の負担にせず、 URPの描画処理で引き受けた C3Dアセット量産パイプライン・Unityセットアップの手間を排除し、デザイナーが「ものづくり」に集中できる状態を作った
制作を加速するエディタツール群・泥臭い処理はツールに吸収させ、中核体験であるエリア制作の基盤を整えた AI Centricな開発体制へ・人間がボトルネックにならないように、 AIが自走する開発フローへ組み替えた 4つは独立した工夫ではない。「制作者の負担を技術で引き受け、人間を本質に集中させる」その思想が、継続的な運営開発を支えている。 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 41 / 41

ご清聴ありがとうございました。

終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術～不思議な生き...

終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術～不思議な生き物リヴリーの体を借りて、終末世界を冒険！世界観を支えるURP描画設計・量産パイプライン・AI活用について～

More Decks by ENSAPIA Engineering株式会社

Other Decks in Technology

Featured

Transcript