Unity U/Day Tokyo 2025 に参加してきた

こんにちは
UnityエンジニアとTechEvangelist(技術広報に近い役職)の業務を担当しているNARIです。
今回は、お休みをいただいてUnity開発者カンファレンス U/Day Tokyo 2025 に自主的に現地参加してきました。

場所は、ベルサール汐留で行われました。

参加費は無料で懇親会参加の場合は4000円必要になります。

Peatixから予約して参加しました。

受付をすますとパスとUnityトートバッグを受け取りました。

トートバッグはかなりしっかりしてました！無料カンファレンスですが素敵ですね！

最初は挨拶から始まりました。

---

Unityエンジンロードマップ

時間: 10:05 – 11:00

登壇: Unity Technologies / Adam Smith, Jason Mann

セッションは、Unityの今後の進化の方向性を示すロードマップの発表から始まりました。これは、今後、開発者がどの技術に投資し、どのような未来に備えるべきかを考える上で、非常に重要な指針となります。以下のような要点を紹介していました。

品質向上のためのプロセス改善

• プロダクション検証: 他社と連携して実際にタイトルをローンチし、その過程で得られたフィードバックをエンジン改善に活かす取り組みを強化。
• リグレッションの削減: 内部の課題検出率を60%から70%以上に向上させ、優先度の高いリグレッション（バージョンアップによる不具合）の解決時間を43%短縮するなど、品質安定に向けた具体的な成果を報告。

Unity 6の主要アップデート

• 開発者データフレームワーク: プレイヤーの同意に基づきデータを収集・分析し、開発者がクラッシュなどの問題を早期に発見しやすくなる新フレームワークを導入。
• パッケージ署名: UPM（Unity Package Manager）で配布されるパッケージに署名が導入され、公式パッケージか、アセットストア経由か、カスタム配布かなどが一目でわかるようになり、セキュリティと信頼性が向上。

開発ワークフローの進化

• ECSのコア化: Unity 6.4からECS（Entity Component System）がコアパッケージとなり、パフォーマンス重視の開発スタイルがより中心的な位置づけに。
• クロスプラットフォームAPI: 開発キットがなくても、各プラットフォーム（XBOXやSwitchなど）の固有設定をUnityエディタ上で検証可能に。認証プロセスもUnityが直接プラットフォーマーと連携。

グラフィックスとパフォーマンス

• 2D物理API: Box2D v3をベースにした、より低レベルで強力な2D物理APIがオプションとして追加。
• コンパイラの最適化: BurstコンパイラとECSの組み合わせにより、さらなる高速化を実現。
• ビルドの自動化: クラウドベースのビルド自動化サービスにより、ビルド時間を最大で58%高速化できるとのこと。

ネットワークとサービス

• Http2とgRPCの強化: UnityWebRequestがHttp2にデフォルトで対応。サーバー負荷の軽減や通信の効率化が期待され、特にモバイルやデスクトップ開発での恩恵が大きいとのこと。

このセッションは、Unityが今後どこへ向かおうとしているのか、その全体像を理解することができる内容でした。

講演の感想

冒頭の挨拶で、登壇者が「秋葉原のスーパーポテトでレトロゲームを買い漁った」というエピソードを披露していて、思わず親近感が湧きました。そんな和やかな雰囲気から始まった今回のロードマップ発表ですが、私が特に感銘を受けたのは、開発の根幹を支える地道な改善に多くの時間が割かれていた点です。

開発プロセスの透明化への期待 「プロダクション検証」や「パッケージ署名」といった取り組みは、一見すると地味ですが、開発者が安心してツールを使い続ける上で、これ以上ないほど重要です。Unityがツールの安定性と信頼性をいかに重視しているかが伝わってきて、非常に好感を持ちました。

クロスプラットフォーム開発の未来 特に驚いたのが、XBOXやSwitchといったコンシューマー機の認証をUnityが直接取得しているという話です。私自身、過去にUE（Unreal Engine）でプラットフォーム対応に苦労した経験があるので、この機能で多くの開発者が助かるんじゃないかと思いました。マルチプラットフォーム展開をしたい開発者はとても期待したい機能だと思います。

実務への応用 日々の業務に直結しそうな機能も満載でした。「開発者データフレームワーク」は、プレイヤーが遭遇した問題を特定する強力な武器になりそうですし、「ビルドの自動化による58%の高速化」は、チーム全体の生産性を劇的に向上させるインパクトがあります。

全体を通して、Unityが「開発者の体験」を第一に考えているという強いメッセージを感じ取ることができた、非常に有意義なセッションでした。

【プロジェクトセカイ】マイセカイの家具配置とNavmesh活用事例の紹介

時間: 11:10 – 11:50

登壇: 株式会社Colorful Palette / 大平 真也, 小林 大峰

大人気リズムゲーム『プロジェクトセカイ』におけるハウジング機能「マイセカイ」の実装事例です。プレイヤーが自由に家具を配置する動的な環境で、キャラクターを賢く移動させるための具体的な技術、特にNavMeshの活用法が詳細に解説されました。

移動処理の技術選定

• キャラクター移動の実装には、Unity標準のNavMeshAgentを採用。移動可能範囲が明確に定義でき、障害物回避などを自動で行える点が決め手となった。

NavMeshの動的生成と課題

• ハウジング機能では家具がリアルタイムで配置されるため、NavMeshSurfaceコンポーネントを使い、ランタイムで移動可能範囲（NavMesh）を再計算。
• しかし、家具の数が増えると再計算の負荷が大きくなり、ゲームが一瞬カクつくパフォーマンス問題が発生した。

パフォーマンス最適化

• IncludeLayerの活用: NavMeshビルドの対象を特定のレイヤー（家具や地形など）に限定することで、プレイヤーや不要なオブジェクトを計算から除外し、処理を軽量化。
• CollectObjectの活用: ビルド範囲をボリュームで限定。Y軸方向を狭め、XZ方向もエリアの広さに合わせることで、計算範囲を必要最小限に絞り込んだ。

NPCの移動制御

• NPCが家具に向かって移動し、特定のアクション（ベッドで寝るなど）を行う際、目的地が壁際などで移動不可能な場合がある。
• NavMesh.SamplePositionを使い、本来の目的地周辺で最も近い「移動可能な座標」を探索。その上で、目的地との距離が離れすぎていないかを確認し、実行不可能な行動を未然に防ぐロジックを実装。

自作による衝突判定

• NavMeshAgentを使用すると、Rigidbodyベースの物理的な衝突判定が機能しない。
• そこで、プレイヤーの正面方向のみに反応する四角い当たり判定を自作。「分離軸定理（SAT）」というアルゴリズムを活用し、軽量かつ要件に合った衝突判定を実現した。

このセッションは、多くのゲームで共通の課題となる「動的な環境下でのキャラクターナビゲーション」に対し、非常に実践的で具体的な解決策を示してくれました。

講演の感想

NavMeshのランタイムビルドや自作コリジョンといったトピックは、技術的に非常に興味深く、多くの学びがありました。以前の仕事でもNavMeshを使った移動処理は作っていたので他社事例での活をを知ることができて更に理解が深まりました。

パフォーマンス改善策の価値 自分がNavMeshのランタイムビルドをしていたときは「重い処理」だったため先入観がありましたが、IncludeLayerやCollectObjectといった具体的なパラメータを適切に設定するだけで、実用レベルまで軽量化できるとわかり聞いてよかったと思いました。今後の開発で動的なステージ生成を検討する際の大きな武器になります。

現場での応用イメージ 「NPCが移動先でアクションを行う場合、事前にそのアクションが可能な位置かをチェックする」というロジックは、極めて実践的に感じました。

複数タイトルの開発・運営で得られたAddressables活用術と課題解決事例

時間: 12:05 – 12:45

登壇: 株式会社Aiming / 金井 亮太, 吉田 杏平, 小野寺 真悠

Unityが推奨するアセット管理システム「Addressables」のヘビーユーザーであるAiming社による、現実的で良いノウハウが詰まったセッションでした。同社は『キャラバンストーリーズ』の時代からAddressablesを活用しており、とても長く運用している中での実用的な活用事例を話していただけました。

アセット管理とビルドパイプライン

• アドレス割り当て: アセットのパス情報から正規表現を使ってアドレスを自動で割り当てるルールを導入し、手作業によるミスを排除。
• ビルド環境: Jenkinsをトリガーに、ビルドされたアセットバンドルをGoogle Cloud Storageへアップロードするパイプラインを構築。

ユーザー体験向上のための工夫

• アセットのアプリ内蔵: 初回起動時の追加ダウンロードはユーザー離脱の大きな原因となるため、最大4GBまでアセットをアプリに内蔵する「アセットパック」機能を活用し、すぐに遊び始められる環境を提供。

クラウドビルド環境の構築

• 課題: プロジェクト増加に伴い、社内の物理ビルドマシンが不足。
• 解決策: Google Cloud上にビルド環境を構築。ジョブごとにインスタンスを起動・破棄する構成で、アイドル時のコストを削減。ランニングコストに足しても費用対効果は高い。

メモリ管理の共通化

• 課題: アセットの解放漏れによるメモリリーク。
• 解決策: アセットのロード処理をIDisposableインターフェースでラップ。usingスコープを抜けると自動で解放処理が呼ばれるシンプルなルールを導入し、解放漏れを構造的に防ぐ仕組みを共通パッケージとして提供。

アセットの最適化

• 課題: 異なるバンドルに同じシェーダーが含まれるなど、アセットの重複によるメモリやデータサイズの肥大化。
• 解決策: メモリプロファイラや依存関係の調査ツールを使い、重複しているアセットを特定。地道にパッキングルールを調整し、最適化を実施。

このセッションは、理想論ではなく、複数タイトルを並行して運営する現場から生まれた、非常に現実的で再現性の高いアプローチを提示してくれました。

講演の感想

大規模プロジェクトにおけるAddressables運用の「現実解」が詰まった、非常に密度の濃いセッションでした。

クラウドビルド環境の魅力 ビルド環境のクラウド化について、月額での具体的なランニングコストが提示されたことで、自社での導入検討が一気に現実味を帯びました。特に、ライセンス数を「必要並列数の1.5倍」で管理するという運用ルールは、非常に実践的で唸らされました。

シンプルなライフタイム管理の重要性 IDisposableとusingスコープで解放処理を統一するというアプローチは、天才的なアイデアだと感じました。複雑化しがちなアセットのライフタイム管理を、C#の言語機能を使ってここまでシンプルに保つ設計思想は、ぜひ見習いたいです。

地道な最適化の価値 派手さはありませんが、メモリレポートと依存関係を睨みながら、重複アセットを一つ一つ潰していくという堅実な最適化アプローチに、強い共感を覚えました。結局のところ、パフォーマンス改善はこうした地道な努力の積み重ねなのだと再確認しました。

複数タイトルを運営している企業ならではの、標準化・共通化された知見は、多くの開発チームにとって再現性の高いヒントに満ちた、非常に価値のあるセッションだったと感じます。

🍽️お昼休憩

お昼は、友人と一緒に数名で含めてとお昼ごはんに行きました。

新橋近くでのカンファレンスですが土地勘がないため色々回って決めました。

海鮮丼のお店に行きましたが豚汁の量が多く

海鮮丼も見た目は小さいのですが見た目以上にボリュームがあって美味しかったです。

友人の中には、登壇予定の方も一緒にいましたが午後からも発表の最終調整をするそうなので忙しそうでした。がんばってください！

海鮮のYODARE カレッタ汐留店 : https://www.caretta.jp/shop/index/173

それでは午後に閲覧したセッションを紹介していきます。

Cygames流 最新スマートフォンゲーム技術設計〜『Shadowverse: Worlds Beyond』におけるアーキテクチャ再設計への挑戦〜

• 時間: 15:15 – 15:55
• 登壇: 株式会社Cygames / 鈴木 元気, 安田 朋広, 元橋 智紀

Cygames社が放つ期待の新作『Shadowverse: Worlds Beyond』の技術設計に関するセッションです。長期運営タイトルの続編を開発するにあたり、過去の技術的負債をいかに解消し、将来の拡張性を見据えたアーキテクチャを構築したか。その大胆な再設計の全貌が語られました。

リアルタイム通信基盤

• ユーザー同士が交流する「パーク」機能など、リアルタイム性の高い体験を実現するため、通信ライブラリとしてgRPCベースのMagicOnionを採用。サーバーサイドもC#で開発できるメリットを活かした。

バトル配信機能の実現

• パーク内で他のプレイヤーのバトルを観戦できる機能を実装。動画ストリーミングではなく、バトル情報をリアルタイムに受信し、観戦者のクライアント側でバトルシーンを描画する方式を採用。
• RenderTextureにバトル画面を焼き付け、それをパーク内のモニターに表示することで、通信負荷を抑えつつ高品質な観戦体験を実現した。

バトルロジックのサーバー移行

• 前作では、クライアントとサーバーの両方にバトルロジックが存在し、サーバー側は主に不正な操作を検証する役割だった。
• 新作では、バトルロジックを完全にサーバー側へ移行。これによりクライアント改造による不正対策が簡素化されたほか、端末スペックによるAIの動作差異といった問題も根本的に解消された。

サーバー移行による開発効率化

• バトルロジックがサーバー側にあることで、クライアントの演出実装を待たずに、ブラウザ上でカードの挙動やバランスをテストプレイできる環境を構築。
• これにより、プランナーやデバッガーが早期にフィードバックを行えるようになり、開発サイクルが大幅に高速化した。

マスターデータの整理

• サーバー移行に伴い、複雑化していたカード能力のマスターデータを、サーバーが担う「能力ロジック」とクライアントが担う「演出」に明確に分離。
• これにより、データの見通しが良くなり、管理コストが大幅に削減された。

このセッションは、単なる続編開発に留まらず、過去の成功体験に安住することなく、より良いプロダクトのためにアーキテクチャレベルでの変革に挑んだ、Cygames社の高い技術力と開発思想を示すものでした。

講演の感想

このセッションで最も衝撃を受けたのは、バトルロジックをサーバーに移行したことによる圧倒的なメリットの数々です。今後の開発でもMagicOnion を採用するか判断していたため採用事例の一つとして話が聞けてとても参考になりました。

サーバーロジックの圧倒的なメリット 不正対策やAIの動作安定化といったメリットもさることながら、開発者として最も魅力を感じたのは「ブラウザでバトルロジックを遊べる」という点です。これにより、プランナーがエンジニアの実装を待たずに、アイデアを即座に試してバランス調整できる環境が生まれます。この開発スピードとフィードバックサイクルの速さは、コンテンツのクオリティを飛躍的に高める上で、とてつもなく強力な武器だと感じました。

技術選択の妙 リアルタイム通信基盤としてMagicOnionを選択したことで、サーバーサイドもC#で開発でき、クライアントとロジックを共有しやすくなるなど、多くのメリットが生まれています。プロジェクトの要件に合わせた適切な技術選定が、いかにプロジェクト全体に好影響を与えるかを示す好例でした。

ユーザー体験へのこだわり バトル配信機能を安易な動画ストリーミングではなく、クライアント描画で実装した点にも感心しました。これは通信負荷を最小限に抑え、ユーザーに快適な体験を提供しようという、配慮を感じました。

また、発表内容もさることながら、スライドの完成度が非常に高く、複雑なアーキテクチャの話を誰にでも分かりやすく伝える工夫が随所に見られました。プレゼンテーションそのものからも、多くの学びを得ることができました。

---

『怪獣８号 THE GAME』開発効率を究極まで高めるエディタ拡張の技術と思考

時間: 16:45 – 17:25

登壇: 株式会社アカツキゲームス / 高原 和啓

このセッションでは、アカツキゲームス社が『怪獣８号 THE GAME』の開発で開発を効率化するために実装したエディタ拡張の開発事例について語られました。単なる便利ツールの紹介に留まらず、なぜエディタ拡張を行うのか、その思想的な部分まで深く掘り下げた、示唆に富む内容でした。

背景と目的

• アニメ放送との連動、フルリモート体制といった厳しい制約の中で高品質なゲームを届けるためには、汎用的なUnityをプロジェクト専用の環境へと作り変える「適用」というプロセスが必要不可欠だった。

具体的なエディタ拡張事例

• プロジェクトウィンドウ: よく使うアセットを登録できる「お気に入り機能」や、アセットパスをSlack等で共有できるカスタムURLスキームを実装。
• Sceneビュー: カメラの位置や角度を保存・復元できる「カメラブックマーク」機能。
• インスペクター: 表示履歴をたどれるナビゲーションメニューや、プロパティを個別に初期値へリセットする機能を追加。

エディタ拡張の思想

• エディタ拡張がもたらす変化を「速度」「品質」「適用」の3つに分類。
• 中でも、Unityという「他社の製品」を自分たちのプロジェクトやチームに最適化させる**「適用」**のプロセスが最も重要である、という独自の思想を提唱。

実装のヒント

• UnityCsReferenceの活用: Unityの標準機能がどのように実装されているかを読み解くことが、高度な拡張を実装する上での最強の教材であると強調。
• プロパティリセットの実装: 一時的なGameObjectとコンポーネントを生成し、その初期値を取得して元のプロパティにコピーするという、力技ながらも確実なテクニックを紹介。

このセッションは、開発効率化というテーマを、ツールの思想という高次元な視点から捉え直す、非常に刺激的な内容でした。

講演の感想

「Unityは他社の製品と捉え、自分たちのプロジェクトに『適用』する」という思想と、それを実現する数々の取り込みが非常に素晴らしいと思いました。

後、スライドがとても見やすくて特にエディタークラスの構造がどうなってるかの図解がとても良くて今後の説明でも是非参考にしたいと思いました。

「適用」という考え方の重要性 エディタ拡張を単なる作業の効率化（速度）やミスの防止（品質）と捉えるのではなく、チームとプロジェクトにとって最も働きやすい専用ツールへと作り変える「適用」のプロセスと捉える視点は、非常に新鮮で、ハッとさせられました。これこそが、エディタ拡張の本質なのかもしれません。

開発者の課題解決能力 プロパティのリセット機能を実現するために、一時的なGameObjectを裏で生成して値をコピーするという実装方法は、言われてみれば確かに！と感じる良い対応アプローチに感じました。目的を達成するためならどんな手段も厭わないという開発者としての執念と、それを可能にするUnityへの深い知識に、とても素晴らしいと思います。ふと、「RequireComponentのような特殊な属性を持つコンポーネントでも、この方法で問題なくリセットできるのだろうか？」という技術的な興味も湧きました。

チームへの働きかけ スライドの端々から、登壇者が普段からチームメンバーに「何か困っていることはないか」と積極的に働きかけている様子が伺えました。価値あるエディタ拡張とは、こうした地道なコミュニケーションの土壌から生まれるのだと気づかされました。

セッションの最後を「どんなこともやればできる」という力強い言葉で締めくくった登壇者のスタンスに、同じ開発者として強いパッションを感じ、大いに勇気づけられました。

夜：懇親会

夜は開発者同士での懇親会に参加しました。

参加費追加で4000円でしたが業界同士で様々な懇親ができたため、支払う価値はあったと思います。

当日はビュッフェスタイルで食事を取って立食する懇親会となっていました。

非常に食事の種類が多く、また開催終了まで残っていたので食事もとても満足の行く内容でした。

デザートのエクレアが仲間でチョコたっぷりでお気に入りでした。

総括

一日を通して非常に多様なセッションを聴講し、Unityというツールの進化の速さ、それらを活用する現場の工夫、そして開発という行為そのものに対する深い思想に触れることができました。
「ツールの進化」「現場の工夫」「開発思想」といった複数の側面から、本当に多くの学びがあり、コミュニティ全体の熱量を再確認できた素晴らしい一日でした。
最後までお読みいただき、ありがとうございました。この記事が、皆さまの日々の開発における何かしらのヒントになれば幸いです。