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

『LIVING with LIVLIES：もしもの世界』は、終末世界を舞台に、不思議な生き物リヴリーとのスローライフを楽しむゲームライクアプリです。多様な探索エリア、自由に着せ替えられるアバター、多彩なアイテムを配置できるハウスを通じて、自分だけの居場所を作りながら過ごせます。
本セッションでは、リヴリーの表現解説に加え、大量かつ多様なアセットを継続的に追加、更新するためにテクニカルアーティストが行った取り組みを発表します。
・8匹のリヴリーが集まっても重なりを自然に見せるURP描画制御
・大量の3Dアセットを安全に更新するDCCとUnityのJSON連携
・アイテムやエリア制作を効率化するUnity Editor Tool群
・規約、skill、unity-cliを組み合わせたAI活用

Transcript

1. CEDEC 2026 SESSION 終末スローライフアプリ 『LIVING with LIVLIES』運用を支える技術 〜不思議な生き物リヴリーの体を借りて、終末世界を冒険！ 世界観を支えるURP描画設計・量産パイプライン・AI活用について〜 ENSAPIA Engineering 株式会社 高野 正也 / Masaya Takano
2. 自己紹介 SPEAKER 高野 正也 ENSAPIA Engineering 株式会社 LIVING with LIVLIES グラフィックエンジニア兼テクニカルアーティ スト 担当範囲 本日お話しする 4 つの基盤を横断して担当 （描画処理・量産パイプライン・エディタ拡張・ AI 活用） 経歴 家庭用ゲームのタイトル開発・内製グラフィックエンジンの開発と運用 ・ Maya 起点のアセットデータパイプライン構築・運用 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 1 / 41
3. LIVING with LIVLIES — ゲーム紹介 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 2 / 41
4. 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
5. LIVING with LIVLIESを開発する上での様々な課題 世界観へのこだわり、膨大なアセットの量産。現場で直面した課題 不思議な生き物、リヴリーの世界観表現 数千を超えるアバター・ハウスデータの量産 体型も動きも全く異なる、多種多様なリヴリーへの対応 高品質でバリエーション豊かなエリアマップの作成 リリース後も、継続的な追加と改修は止まらない 全ては「運用で増え続けるコンテンツの量産を、どう支えていくか」という共通の課題 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 4 / 41
6. AGENDA 本日のアジェンダ 目安 1:00
7. 本日のアジェンダ 01 世界観を守るグラフィック設計 02 C3D アセット量産パイプライン 03 制作を加速するエディタツール群 04 AI Centricな開発体制へ 05 まとめ CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 5 / 41
8. CHAPTER 1 世界観を守るグラフィック設計 目安 10:10 世界観の制約を制作に押し付けない描画設計
9. 1-1. リヴリーは「重なってはいけない」 対象 「エリア」でのリヴリーのマルチプレイ ヤー表示に関する課題 世界観 リヴリーは「生き物」。だから決して重 なってはいけない 同時表示 エリアには最大 8 匹が共存する 問い: エリアの世界観を守りながら、最大8匹の 前後関係をどう制御するか かわいいけど、かわいい問題ではない CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 同じ位置にリヴリーを 配置すると埋まってしまう 理想：優先度順に重ならず 表示される 6 / 41
10. 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
11. 1-3. エリア制作の自由度を奪う 本当にやりたいのは、8レーン化ではなく「1レーンのままでも破綻しない」こと エリアマップのレイアウトが常に 8 レーン前提になる さらに各レーンで「手前・通常・奥」の3要素を意識する必要がある。アセット制作側に大きな負担 本当にやりたいのは、エリアのリヴリー配置を1 レーンのままで作れること 最大 8 匹が同じレーン上に来ても、表示時の前後関係で破綻させない エリアの描画問題を、エリアマップ制作の負担にしてはいけない CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 8 / 41
12. 1-4. 制約をエリアマップから描画側へ移す 制作物に制約を足すのではなく、 ランタイムの描画設計で吸収 する Before: エリアマップ側で保証 Area Map Asset 描画都合が地形・配置・改修に漏れる After: エリア専用の描画側で保証 責任の移動 Area Map Runtime 1レーンのまま Stencil RenderQueue 重ならない保証を、表示時の描画処理へ 閉じ込める エリアマップは1レーンのまま、 最大8匹の前後関係を描画側で制御 する CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 9 / 41
13. 1-5. ステンシルバッファを用いた3パスレンダリングによる解決 Unity URP（RenderGraph）に、エリアでのリヴリー描画専用の3パスを挿入 ① WriteStencil パス リヴリーごとの識別値を奥から順 にステンシルバッファへ書き込む ② Color パス ③ ClearStencil パス ステンシル値と自身の識別値が 一致するピクセル（領域）にの み、カラーを描画 する 後続の描画処理に影響を与えない よう、ステンシルバッファをクリア する ※このパスではカラーの描画は 行わない 実行タイミング: URP BeforeRenderingOpaques / LayerMask でリヴリーレイヤーのみ対象 各リヴリーのマテリアルのレンダーキューに、奥から順に描画される値を設定 → 前面が優先される → 識別値 ＋ RenderQueue で、同じ位置で重なっていても優先度をつけて描画 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 10 / 41
14. 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
15. 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
16. 1-8. まとめ：エリア制作の自由度を取り戻す 描画側が吸収することで、 エリア制作側の自由度を取り戻す B efore: エリアマップ8レーン案 After: エリア専用の描画側で保証 1レーン上に最大8匹 地形・装飾・通路が 描画都合に引っ張られる エリアマップは1レーンのまま 最大8匹を描画側で制御 自由度 改修 安定性 負荷 1レーンのまま 既存エリアの負担減 Z-fighting回避 処理負荷は小さい CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 13 / 41
17. CHAPTER 2 C3D アセット量産パイプライン 目安 10:30 デザイナーに Unity セットアップを背負わせず、アセットを大量生産する
18. 2-1. C3Dとは：Mayaの3DデータをUnity完成Prefabへ変換する仕組み C3Dは Cocone 3D の略称 MayaデータをUnity で使える Prefab をセットアップする内製パイプライン デザイナーが本当に時間を使いたいのは、Unity セットアップではなく制作そのもの 目的は「アセットの大量生産」 と「デザイナー負担を増やさないこと」 の両立 Maya CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 Unity 14 / 41
19. 2-2. 手作業のセットアップが、大量生産を止める Material / Texture / Prefab / Variant / Component の設定が毎回発生する 人手に寄せるほど、設定漏れ・品質差・確認往復・依頼待ちが増える 数が増えるほど、デザイナーにも TA / エンジニアにも負担が積み上がる 作業者を増やしても、セットアップ手順が残る限り量産のボトルネックになる CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 15 / 41
20. 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
21. 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
22. 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
23. 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
24. 2-7. 章まとめ：C3D 背負わせない設計 デザイナーからUnityセットアップの手間を徹底的に排除し、本来の「ものづくり」に集中できる環境を 知恵と設計で突破する 一見して技術的に困難な制約があっても疎結合な設計と工夫により、汎用的で持続可能なパイプラインを構築できる アセットデータパイプラインの性能１つで プロジェクト全体の生産性 は劇的に変わる どんな壁があっても、エンジニアとして 最後まで諦めずに可能性 を探し続ける CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 20 / 41
25. CHAPTER 3 制作を加速するエディタツール群 目安 14:10 内製エディタツールの中から、代表的な二つの事例を紹介
26. 3-1. 制作を成立させる二つのツール 数ある開発ツールの中から、代表的な2つの開発事例を紹介 ① サムネイル生成ツール（量産化の仕組み） 膨大な数のアセットサムネイルを、自動でバッチ生成するツール ② エリア用ツール（ワークフローの整備） ルートや必要データを扱う専用の編集基盤を構築し、複雑な制作を成立させた事例 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 21 / 41
27. EDITOR TOOLS サムネイルツール
28. 3-2. サムネイルとは ゲーム内のUI処理や画面表示で使う小さな2D画像 【役割と要件】プレイヤーが最も頻繁に目にする画像 ・一覧、ショップ、所持品など、UIの根幹を担う小さな2D画像 ・「見た目の品質」と、パッと見の「判別しやすさ」の両立が必須 【制作上の課題】膨大な量と「品質の均一化」のジレンマ ・アイテム数が膨大でも、全体で一定の品質・トーンを揃える必要がある ・品質を追求するほど、どうしても手動での微調整（手作業）が多くなりがちだった 実際のアイテムボックス画面 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 22 / 41
29. 3-3. 大量のサムネイル制作を、自動作成に置き換える 大量のサムネイル作成の制作工程を自動化 【直面した現実】約7,000枚という圧倒的物量 ・総数は現時点で 6,980枚 （アバター 3,663 / ハウス 2,302 / その他 1,015） ・追加・差し替え・修正のたびに、手動対応では 莫大なコストが発生 【ツール目的】手作業の完全排除、バッチ自動化 ・高品質なサムネイル画像を、自動でまとめて一気に作成 できる環境を目指した CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 23 / 41
30. 3-4. でも、自動化は簡単ではなかった 直面した技術的な壁：単純な一括処理では実用的な画像にならない 【アバター用サムネイルの課題】「状態」による見え方の変化 ・装着部位に応じた下地マネキンの制御や、お勧め位置の反映 ・アニメーション、揺れ物、Particle（エフェクト）の影響 【ハウス用サムネイルの課題】「形状・サイズ」の多様性 ・形や大きさが幅広く、固定の画角では収まりきらない ・複雑な形状や階層構造により、バウンディングボックスが正確に取れない 【結論】自動化を成立させるには 「アイテムごとの差」 をシステムで吸収する必要があった CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 24 / 41
31. 3-5. 差をツール側で吸収して、量産を成立させた 「 アイテムごとの差」を整理・分解し、分解した機能ごとにカスタム処理を実装し対応 【解決方針】美しい汎用化を諦め、「泥臭い個別対応」を徹底する ・理想（シンプルで汎用的）を追うと、結局は「人間のパラメータ調整」が残ってしまう ・人間が「目で見て、どう撮るか判断する工程」をすべてシステム化する と決断 【実装した「人間の判断」の具体例】 ・アバター： ItemTypeからの画角判定、 Particle検知時はSeedを固定して連番撮影 ・ハウス： コード名からの種別判定、形状の破綻を検知して自動で頂点ベース計算へ切替 【結果】 ツール側が泥臭さを引き受けた ことで、量産体制が成立 ・内部は条件分岐の塊だが、デザイナーにとっては「一発で実用的な画像が出る」ツールに ツール導入前 → 導入後（1枚あたり） 約5分 → 約5秒 約98% 削減 アバター＋ハウスで、手作業なら 約400時間超 を削減 ※再撮影は含まず CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 25 / 41
32. EDITOR TOOLS エリア用ツール
33. 3-6. エリアとは リヴリーと暮らし・探索する、ゲーム体験の中核 【役割】ゲーム体験の中核となる「探索の舞台」 ・すごろく状のマスを移動し、素材やアイテムを 集めるゲームのメインコンテンツ ・最大8匹で集まれるマルチプレイの場でもある 【制作要件】「背景美術」と「ゲームロジック」 の統合 ・単なる背景の見た目だけでなく、探索ルートや マス属性（ゲーム情報）の構築が不可欠 ・これらを統合して作る 「専用の編集基盤」 がなければ、制作自体が成立しない CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 26 / 41
34. 3-7. エリア編集のためのツールを整備し、ワークフローを構築 全体像: エリア制作を、背景作成→ルート→検証→全体→出力の流れにする 背景作成 JSON からエリアの 土台シーンを作り、 背景の見た目を作 る ルート作成 配置チェック ミニマップ作成 データ出力 マスとルートを つないで編集する 配置の制約をScene 上で検証する エリア全体を2Dで俯 瞰・調整する ルート/マス情報を 出力しマスターデー タへ連携 背景作成 → ルートを編集 → 制約を検証 → 全体を2Dで整える → マスターデータへ出力 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 27 / 41
35. 3-8. ミニマップとは — 3D空間のルートから、2Dマップへ 3D空間に引いたルートを、ゲームに出る2Dミニマップに変換する ミニマップ エディタで変換 3D空間に引いたルート（マス/接続） ゲーム画面のミニマップ（赤枠） 3D空間の複雑なルートを、プレイヤーが現在地と道筋を把握できる2Dマップへ CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 28 / 41
36. 3-9. ミニマップエディタで、2D配置とマス設定を行う 【機能1：見た目の作成】3Dルートからの2D配置の自動生成 ・「エリア配置を再現」機能で、 3Dのマス/ルート情報から 2D配置を自動生成 ・エディタ機能で綺麗な整列・微調整を行える 【機能2：ロジックの作成】マスごとのゲーム挙動の付与 ・インスペクタ上で、地形（ Terrain）やビネットなどのパラメータを設定 ・メソッド呼び出しを設定し、特定マス到達時の演出（アニメのトリガー等）に活用 【結果】「UIの見た目」と「ゲーム挙動」を1つのエディタで統合 ・編集結果はコンポーネントに保存され、そのままゲームへ反映される CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 29 / 41
37. 3-10. 配置チェックツールで、見えない制約を見えるようにした 目で見えない配置の制約を Scene 上に可視化し、破綻を防ぐ 【重なりの検証】モンスター / リヴリーゴースト / 灯火 / パワースポットが背景にめり込む箇所を検出 【空間制約の可視化】天井までの距離や、マス間の高低差（ジャンプの要否）まで自動判定 【修正へのシームレスな導線】違反箇所を SceneView 上に色分けの Bounds で表示し、クリックで その場所へジャンプ 【結果】シーン名から対象データを自動で引き当て、「勘や記憶」ではなく「見ながら直せる」環境 を実現 左から: モンスターと地形の重なり ／ 天井までの距離 ／ マス間の高低差（赤＝要修正・黄＝閾値内） CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 30 / 41
38. 3-11. エリア用ツールがもたらしたこと 【情報の統合と可視化】 ・探索ルートやマス属性など、目に見えないゲーム情報をツール上で扱えるようにした ・導線・制約・全体構造を「見ながら」編集できる環境を構築 【分断のないワークフロー】 ・ベース作成からデータ出力までの5つのステップを、一連の流れとして連結 ・手順を追うだけで、勘や記憶に頼らずに確実にエリアを制作可能に 【最大の成果】デザイナーが「空間づくり」に集中できるようになった ・ツールの整備が、結果としてアプリの中核体験（エリア）のクオリティ向上に直結した CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 31 / 41
39. CHAPTER 4 AI Centricな開発体制へ 目安 12:15 AI前提で開発を組み替える
40. 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
41. 4-2. 複数の選択肢がある中で、自然と Claude Code が中心になった 標準採用というより、現場で主軸が決まっていった 当時は Copilot / Cursor / Claude Code / Codex など、複数の選択肢があった チームで一律に決めたというより、使いながら自然と Claude Code が中心 になった その後、中心になった使い方に合わせて rules や skills が整備されていった 導入を議論するフェーズではなく、使いながら改善するフェーズに入れた CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 33 / 41
42. 4-3. 主軸は Claude Code、でも他のツールも使えるように AIツールの使用は、1つに固定しない 適材適所でのツールの使い分け ・主軸（実装・タスク実行） : Claude Code を中心に据える ・別視点（検証・レビュー） : Codex を活用（PRレビュー、並列調査など） AI間の「共有資産」の構築 ・リポジトリ内の ai/ ディレクトリにルールやスキルを集約 ・Claude / Codex / Copilot のどれを使っても、同じ文脈で動けるように整備 方針：中心を定めつつも、1つのAIに縛られない運用 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 34 / 41
43. 4-4. AIで速くなった分、人間がボトルネックになった 課題：ボトルネックになっているのは人間 直面した新たな課題：人間の「確認待ち」による停滞 ・AIで実装は高速化したが、コンパイル、ログ確認、PRレビュー、Approveなど「人が見る」工程で作業が止まる ・Unity開発は制約が多く、Playモードやログを毎回人が確認する運用は限界に 解決へのアプローチ：AIが自走できる「環境」の構築 ・AIツール単体ではなく、AI自身が確認を進められる仕組みが必要だった ・① ローカルループ： AIが自分でコンパイルとログを確認・対応する仕組み ・② PR側のAIフロー： レビューと承認の詰まりを解消する仕組み 次ページ以降：この2つの環境をどう整えたか、具体的な仕組みを解説 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 35 / 41
44. 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
45. 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
46. 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
47. 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
48. 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
49. CHAPTER 5 まとめ 目安 2:10
50. 5-1. LIVING with LIVLIES 運用を支える技術とは 世界観を守るグラフィック設計 ・世界観の制約をアセット制作者の負担にせず、 URPの描画処理で引き受けた C3Dアセット量産パイプライン ・Unityセットアップの手間を排除し、デザイナーが「ものづくり」に集中できる状態を作った 制作を加速するエディタツール群 ・泥臭い処理はツールに吸収させ、中核体験であるエリア制作の基盤を整えた AI Centricな開発体制へ ・人間がボトルネックにならないように、 AIが自走する開発フローへ組み替えた 4つは独立した工夫ではない。 「制作者の負担を技術で引き受け、人間を本質に集中させる」 その思想が、継続的な運営開発を支えている。 CEDEC 2026 / 終末スローライフアプリ『LIVING with LIVLIES』運用を支える技術 41 / 41
51. ご清聴ありがとうございました。