548 Views
March 02, 26
スライド概要
リアルタイム3Dコンテンツを制作・運用するための世界的にリードするプラットフォームである「Unity」の日本国内における販売、サポート、コミュニティ活動、研究開発、教育支援を行っています。ゲーム開発者からアーティスト、建築家、自動車デザイナー、映画製作者など、さまざまなクリエイターがUnityを使い想像力を発揮しています。
Unity開発におけるバグとの向き合い方 (Unity由来のバグが発生した時の分析と報告の方法) Tokyo December 11
講演者 Yusuke Kurokawa Katsumasa Kimura Koji Ohno Partner Engineer Manager, Software Engineering Developer Relation Manager, Tech Lead Tokyo December 11
→ 写真撮影禁止 お願い → 動画撮影禁止 → SNS投稿禁止 Tokyo December 11
→ Unityでのゲーム開発で、 どうバグと向き合うのか? Unityでバグが出たけどどうしたらいい のかわからない → Unityにバグの連絡をしたけど、それ から報告がない → 締切まで時間がないのに、バグにどの ように対処して良いのかわからない Tokyo December 11
なぜ、バグはすぐ 修正されないのか? → 膨大なバグ報告数がある → ユーザーへの影響度の高いものから 修正している → 安定化に向けた開発改善は常に行っ ているが、どうしても反映までに時間 がかかる。 Tokyo December 11
安定性への取り組み (Unite 2025のRoadmap講演のスライドから) Tokyo December 11
7 アジェンダ 第1部 Unity でのバグの扱いと修正の流れ 黒河 優介 第2部 再現プロジェクトから始めるバグレポート提出のプロセス 木村 勝将 第3部 コンソール開発におけるバグとの向き合い方について 大野 功二 Tokyo December 11
Unityでのバグの扱いと 修正の流れ 第1部 Yusuke Kurokawa Tokyo December 11
Unity プロジェクトでの一般的にバグとは? Unity Editor・Runtimeエンジン上で意図しない挙動となった場合、バグに遭遇したという 事になります。 例: ・描画バグ:点滅する描画など意図しない状況になってしまう ・機能バグ:ボタンを押しても反応しない ・性能バグ:CPUやメモリを過剰に消費してしまう ・クラッシュバグ: EditorやRuntimeがクラッシュしてしまう ・環境依存バグ:特定の端末や環境でのみ起きる不具合 Tokyo December 11
Unity のバグとは? Unityプロジェクトで発生するバグには、 UnityEngine以外が原因 で発生するバグがあります。 ・開発者の皆様が構築したアプリケーションそのもののバグ ・アセットやオープンソースソフトウェア、 外部ミドルウェアによるバグ ・動作しているプラットフォーム自体の問題 アプリケーション アセット/ OSS Unity Engine Plugin プラットフォーム Tokyo December 11
Unity のバグとは? Unity自体のバグであると言うためには、アセットやプラグインなどを除いた状態である必要が あります。 「Unityのこの機能をこういう使い方をすると、このような時にバグが発生します」と 言えるようにする事が重要です。 Tokyo December 11
Unity のバグとは? ・特定のUnity APIを呼び出すと、 EditorやRuntimeがクラッシュしてしまう ・ビルドが途中で進行しなくなる ・Unityのバージョンアップを行った際に、特定の処理が大幅にパフォーマンス低下 ・特定のGraphicsAPIを使用したときに表示崩れが起きてしまう ・特定の端末でのみ何らかの問題が発生するバグ Tokyo December 11
Unity のバグ公開情報 Unity Issue Trackerでバグの情報を公開しています。 不具合には以下の Statusがあります。 Active :現在対応中です Fixed :修正対応済みです Fix in Review : 修正が行われ、反映待ちです Postponed :修正見送り中です Duplicate :別Issueと重複しています Not Reproducible:Unity側で再現出来ません Wonʼt Fix :修正の予定はありません By Design :その挙動は仕様です https://issuetracker.unity3d.com/ Tokyo December 11
Release Note とIssue Tracker Issue TrackerのIssueには個別のIDが振られています。 Release Noteに書いてある IDとIssue TrackerのIDはリンクしています。 Tokyo December 11
Unity のバグ修正の流れ 1.バグ報告者様から 不具合を確認できる再現プロジェクトが送信されます 2.Unity QAチームが、再現プロジェクトを元に不具合が起こるか確認します 3.不具合が確認されたら、 Unity開発チームにバグチケットを起票します (この時、Issue Trackerに不具合が掲載されます ) 4.開発チームが Unityの最新バージョン (αバージョン等) で不具合の修正を行います 5.Unity QAチームが再現プロジェクトを用いて、不具合が修正されたことを確認します 6.その後、サポート中の LTSバージョン等に修正内容をバックポート処理を行います 7.再度Unity QAチームがLTSバージョンで不具合が修正されたかを確認します Tokyo December 11
Unity のバグ修正において重要な点 ・Unity側で報告情報を元に、同じバグを再現・確認できないと、修正のプロセスに 入りません ・お使いいただいている Unityバージョンに対して修正を行うのではなく、 まず初めに開発中の最新 Unityバージョンに修正が入ります → そのため、バグ修正がお手元のバージョンに反映されるまで時間が掛かります Tokyo December 11
うまく前に進まないパターン ・Crash Dump等のみのクラッシュ系のバグ報告です → バグ修正前に、 Unity側でも状況を再現することが大切だと考えていますので、 再現確認が行えない報告は残念ながら対応することが出来ません ・Unity Discussions等でのみ、書き込まれた不具合報告 → Unity Discussionsだけでなく、正式にバグレポートをお願いします Tokyo December 11
不具合を再現するための 再現プロジェクトが とても大事です Tokyo December 11
再現プロジェクトから始めるバ グレポート提出のプロセス 第2部 Katsumasa Kimura Tokyo December 11
なぜ「再現プロジェクト」が必要か Unityのバグ修正の簡易プロセス 1. 2. 3. 再現プロジェクトで問題の発生を確認 修正を実施 再現プロジェクトで問題が発生しない事を確認 →再現出来ない問題は修正出来ない Tokyo December 11
再現プロジェクトの作り方 再現プロジェクトの作り方には大きく分けて2種類 ● ● 新規プロジェクトを作成し、問題と核となる部分だけを組み込む 既存のプロジェクトをリダクションし、問題とは無縁な部分を削り取る 問題の切り分けが出来ているのであれば前者 出来ていないのであれば後者で問題の切り分けを行っていく。 Tokyo December 11
作り方① ゼロから再現 1. 2. 3. 4. 新規プロジェクトの作成 : バグ報告用のまっさらな 3D(または2D)プロジェクトを立ち上げる。 現象の分離: 既存の巨大なプロジェクトから、バグを再現するために最低限必要な要素を取り込みます。 a. 元のプロジェクトから最低限必要な要素 Script、Asset、Scene)のみをコピー b. 元のプロジェクトから問題が発生する SceneをExport、新規プロジェクトに Import 必要であれば ProjectSettings等も調整(もしくはコピー ) 同じ手順で問題が発生するか確認 Tokyo December 11
作り方② 既存プロジェクトのリダクション 1. 2. 3. 5. 6. 既存のプロジェクトを複製 問題が発生する為の再現手順に含まれない、Scene,Asset類を削除する 問題が発生しなくなる手前まで削除しても問題の無いGameObjectやAssetを少しずつ削除する a. GameObjectについているコンポーネントScriptはオフにして動作に影響が無ければ削除 削除は出来ないが差し替えても良いAssetはSimpleなものに差し替える a. 特にIP関連などプロジェクト外秘のものが含まれている場合 b. サイズが大きいTexture等は小さいサイズのものに差し替えてしまうことでプロジェクトサイズを大幅に圧縮で きる 必要のないPackageも削除 同じ手順で問題が発生するか確認 ➔ 余裕があれば改めてゼロから再現プロジェクトを作る 4. Tokyo December 11
再現プロジェクトの注意事項 ● ● ● ● 可能な限りプロジェクトをコンパクトに ○ 可能な限り問題の本質とは関係ないものを含めない サードパーティ製のミドルウェアやライブラリを含めない ○ 開発元にお問い合わせください 外部通信(サーバー依存)を行う実装を含めない ○ サーバーが外部(社外)に公開されておらずアクセスできない ○ 通信周りの仕様が変わってしまっている カスタムされたビルドプロセスを含めない ○ 問題切り分けの為にも可能な限り素の状態で Tokyo December 11
バグレポート → バグレポートはUnity Bug Reporterで行う → Unity EditorのTopMenuから Help→Report a Bug…でUnity Bug Reporter が起動 → Unity Editorで開いているプロジェクトが再現プ ロジェクトとしてバグレポートに自動的に添付され る Tokyo December 11
完璧なバグレポートの 6大要素 ● Title:タイトル(重要) ● What is this problem related to ?分類 ● How often does it happen ? :再現頻度 ● Primary Contact Unity ID : 連絡先 ● Details :詳細(重要) ● Attachments:添付ファイル この6つが揃うと、あなたの Bug Reportを 提出出来ます。 Tokyo December 11
Title ● ● 発生している問題を簡潔に説明 ○ 何をしたら+どうなるか+(補足) 例) ○ 何をしたら+どうなるか ■ ライトをベイクすると、Unity Editorがクラッシュする ○ 何をしたら+どうなるか+(補足) ■ macOS26においてライトをベイクすると、グローバルイルミネーションの ポストプロセス処理時でUnity Editorがクラッシュする Tokyo December 11
What is this problem related to ? ● ● 関係する項目を以下の5個の選択肢から最も近いものを一つ選択 ○ A problem with the Editor(エディター自体の問題) ○ A problem with the Player(ビルド後の実行環境の問題) ○ Performance (パフォーマンスの問題) ○ Crash (クラッシュの問題) ○ Services Unityサービス関連の問題) 複数該当する場合は? ○ Crashが最優先、後は気持ち次第 y Ads、Everyplay、マルチプレイヤー、Analytics、Cloud Build Tokyo December 11
How often does it happen ? ● 以下の選択肢から最も近いものを一つ選択 ○ This is the first time (1回だけ) ○ Sometimes but always (時々だが、手順を踏めば再現する) ○ Always(常に) Tokyo December 11
Primary Contact Unity ID Unityからの連絡先 ➔ ➔ 現在Unity Editorを使用しているUnity IDが自動的に入力済み このバグレポートと他の人と共有したい場合 1. Share this bug report with someone elseにチェックを入れ 2. Additional Contact Emailの項目に共有するメールアドレスを入力する ※バグレポーター上は追加のメールアドレスは1件までだが、バグレポート提出後、ス テータスの確認画面から追加可能 Tokyo December 11
Detail ● 問題の詳細を解説する為に以下の4要素で細分化 ➔ ➔ Steps to reproduce (再現手順) Actual result / Expected result (「今何がおきているか」/「何が起きて欲しいの か」) Reproducible on / Not Reproducible on(環境依存の切り分け情報) Notes (補足情報) ➔ ➔ Tokyo December 11
Detail - Steps to reproduce 曖昧さを排除!明確な再現手順の記述 ● ● ● 例) 1. 2. 3. 4. 5. 問題の発生を確認する為の再現手順 手順の番号付け : 「1. 2. 3....」と番号を振り、箇条書きで記述。 具体的な操作 : 例えば「1. Hierarchy WindowからCubeを選択、2.インスペクターから Cubeの TransformのPosition Xを5に変更する...」 再現プロジェクトを開く SampleSceneを開く Light Windowを開くTopMenuからWindow > Rendering > Lighting を選択) Generate Lighting]ボタンを押す グローバルイルミネーションのポストプロセスの段階で、「 Hold on」Windowが表示されることを確 認する Tokyo December 11
Detail - Actual result / Expected result ● 例) ● ● 再現手順の結果、実際の起きる結果 (不具合)と期待している結果を記載 Expected result : ライトマップのベイクが成功する Actual result : Hold on Windowsが表示された状態で Unity Editorがフリーズしライトマップの ベイクが完了しない Tokyo December 11
Reproducible on / Not Reproducible on ● ● ● ● Reproducible on : 問題が再現する環境 Not Reproducible on : 再現しない環境(オプション) Unity Editorのバージョン・デバイス名(型番)・OSのバージョン等を記載 例) ○ モバイルデバイス ■ Reproducible on : Google Pixel 3 XLAndroid 11,Google Pixel 4 Android 12 ■ Not Reproducible on : Google Pixel 2 Android 11,Oneplus OnePlus 6 ONEPLUS A6003Android 10,Galaxy S25 SMS931B Android 15 ○ Unity Editorのバージョン ■ Reproducible on : 2022.3.58f1,6000.0.60f1 ■ Not Reproducible on : 2022.3.57f1,6000.0.59f1 ○ OSのバージョン ■ Reproducible on : Windows 11 25H2 ■ Not Reproducible on : macOS 26.0.1,macOS 18 Tokyo December 11
Notes ● ● 補足したい内容があればなんでも記載する 再現頻度でSometimes but alwaysを選択した場合、具体的な再現率を記載する ○ 再現率 10回中7回 ○ エージング中、10分前後で発生 Tokyo December 11
Attachments ● ● ● ➔ Unity Editor Log,Player Log…(ログファイル) ○ 問題が起きた時のログファイル 動画 ○ 再現手順を動画で撮影 スクリーンショット ○ 期待される結果と実際の結果のスクリーンショット 百聞は一見に如かず Tokyo December 11
英語に翻訳する ● ● ● Unity Issue Tracker(https://issuetracker.unity3d.com/)を参考にして自力で 翻訳する 翻訳ソフトを活用する AIを活用する(おすすめ) ○ プロンプトの例 ■ 「Unityへのバグレポート提出用に以下の文章を英語に翻訳して!」 ○ AIによる翻訳結果は必ずしも正確とは限りません。文脈の誤解や不自然な 表現が含まれる可能性があるため、内容を必ずご確認の上、必要に応じて 修正を行ってください。 Tokyo December 11
38 AIでの翻訳結果 Title: Title : macOS26においてライトをベイクする時、グローバルイルミネーショ Unity Editor Crashes During Global Illumination Post-processing When ンのポストプロセス処理時で Unity Editorがクラッシュする Baking Lights on macOS 26 Step to Reproduce : 1. 再現プロジェクトを開く 2. SampleSceneを開く 3. Step to Reproduce: 1. Open the attached reproduction project. Light Windowを開くTopMenuからWindow > Rendering 2. Open the scene named "SampleScene." > Lighting を選択) 3. Open the Light Window Select Window > Rendering > Lighting from the Top Menu). 4. Generate Lighting]ボタンを押す 5. グローバルイルミネーションのポストプロセスの段階で、 4. Press the Generate Lighting] button. 「Hold on」Windowが表示されることを確認する 5. Observe the "Hold on" window appearing during the Global Expected result : ライトマップのベイクが成功する Actual result : Hold on Windowsが表示された状態で Unity Editorが フリーズしライトマップのベイクが完了しない Illumination Post-processing stage. Expected Result: Lightmap baking completes successfully. Actual Result: The Unity Editor freezes (hangs) while the "Hold on" window is displayed, and lightmap baking does not complete. Tokyo December 11
まとめ ➔ 問題の切り分け ➔ シンプルな再現プロジェク ト ➔ 明確なバグレポート 再現プロジェクトは自分のため! Tokyo December 11
コンソールゲーム開発におけるバ グとの向き合い方 第3部 Koji Ohno Tokyo December 11
コンソール開発とバグ ● コンソールにはNDAがある ○ オープンな場では相談や情報共有はできません ● 相談先も限られている ○ プラットフォーマーから承認されている場所でしか相談はできない ○ コンソール特有の問題はナレッジ検索が難しい ● だから、バグの早めの対処が鍵となる ○ バグの発見や対応が遅くなるほど、解決も遅くなる Tokyo December 11
コンソールでのバグの原因の切り分け方のコツ ● 既存バグがないか、まずは調べる ○ Unity Issue Tracker ○ Unity Discussions →既存バグなら、VoteするかDiscussionsで影響の大きさを理論的に説明することがポイントになる ● 他のプラットフォームでも発生するか調べる ○ Windows,iPhone,Androidなど ● プラットフォーム情報やSDKマニュアルを調べる ○ プラットフォーマーが提供するサポート掲示板 ○ SDKドキュメントの更新履歴 ● その他 ○ UnityやSDKを最新版にしてみる。または古いバージョンを試してみる Tokyo December 11
バグを見つけた時の報告先は、プラットフォーマー次第 ● バグを見つけた時の報告先は、プラットフォーマー次第になります。 ○ そのコンソール特有のバグの場合は、プラットフォーマーが指定している方法で報告 ○ コンソール特有のバグかどうかわからない場合は、一旦、プラットフォーマーが指定している方法 で報告(可能ならハードウェアの切り分けはお願いしたいです) ○ どのプラットフォームでも発生するバグは、Issue Truckerへ ただし、Bug Reporterで投稿する場合は慎重に なるべく最小プロジェクトで、可能ならコンソールのNDAに触れる部分は削除していただけると助 かります また、試したプラットフォームを明確にしてもらえると助かります 例:iPhone 16 Pro Max,Android(Galaxy s25 Ultra),そしてコンソールで発生します ● Tokyo December 11
バグを見つけた時 : コンソールならではのバグレポートの書き方 コンソール独自のバグを見つけた場合、以下の点に気をつけてプラットフォーマーが提供するサポート掲示板で連絡してく ださい。 ● ● ● ● ● ● ● Unityバージョン,SDKバージョン,ファームウェアバージョン,バグを見つけたハードウェアタイプ Unityパッケージバージョン、特にコンソール専用のパッケージがある場合はそのパッケージバージョン 再現頻度 バグの再現方法。Unity EditorやPCでの再現方法ではなく、コンソールハードでの再現方法をわかりやすく明記 バグの影響度。そのバグによって、ゲーム開発にどれくらい影響があるか また、どれくらいのゲーム開発者に影響があるか、インパクトがあるか コンソールハードから出力されるデバッグログ ○ デバッグログやエラーログがあるものは、可能なら添付をお願いします ○ これらのログは解決を早くする場合があります 最小プロジェクトがあれば、バグ対応を早く行えます Tokyo December 11
コンソールでバグに困らないための対策 ● 早い段階から実機での動作確認を行う ○ Unityのバグ修正は、基本的に最速でも連絡をいただいてから2週間はかかります ○ LTSのバージョンによっては1ヶ月待ちになります ○ コンソールハードによってはデバッグモードでメモリが多い状態でテストが可能 ■ これはバグ発見が遅くなるので、定期的に製品版モードでテスト ■ デバッグモードでプレイする時はエラーやワーニングがないかチェック ● UnityやSDKのバージョンを可能な限り最新のものを使う ○ UnityやSDKの最新版で修正されている可能性もあるので、試してみることをお勧め ○ それで直ったら、UnityとSDKどちらに原因があるのか問題を切り分ける Tokyo December 11
ワークアラウンドも並行して探そう ● コンソールのバグ修正は結構大変 ○ コンソールは他のプラットフォームに比べてバグ修正の難易度が高い場合があります ○ 特にネットワーク系のバグは、再現手順が複雑なものが多いです ○ 再現プロジェクトがあることが修正のプライオリティに影響します ● なので、ワークアラウンドを並行して探しましょう ○ バグを報告したからといって、必ずしも修正されるとは限りません ○ なので、ワークアラウンドも並行して見つけましょう ● ワークアラウンドの見つけ方のコツ ○ 最小プロジェクトを作ることでワークアラウンドを見つける近道になります ○ 問題となっている処理を他の方法で実装できないか検討してください ○ 場合によってはネイティブプラグインでの実装も検討してください Tokyo December 11
ワークアラウンドの見つけ方 実例:コンソールのみキャラクタが特定の箇所に移動すると強制終了する [症状] コンソールの3 Dゲームにおいて、プレイヤーキャラが特定の場所に移動すると強制終了する エラーログには、例外エラーしか出ておらずソースコードデバッグにも引っかからない。 [調査] 1. 問題のシーンを実行して、まずどのゲームオブジェクトが強制終了するのか、 二分木探索で Enable,Disableしながら割り出す 2. 問題の地形のゲームオブジェクトを発見したので、そのゲームオブジェクトのコンポーネントを1つずつ Disable して問題のコンポーネントを見つける 3. NavMeshが原因であることが判明したので、その地形オブジェクトだけを Exportして、最小プロジェクトを作る 4. 上記の最小プロジェクトを添付してバグチケットを作成 5. 並行してNavMeshのデータを解析して、何が問題かを特定( NavMeshの放線がおかしいものがあった) 6. 上記のデータを修正してワークアラウンドとして対応 上記のような最小プロジェクトを作成してワークアラウンドを見つける作業は、 お手数ですが基本的にユーザーの皆様にお願いしております。 Tokyo December 11
Unity Japan からも 皆様の声を社内に伝えていきますので、 引き続きご協力のほどお願いします! Tokyo December 11
Thank you! Tokyo December 11