---
title: デバッグ機能を作るときに考えていること
tags: 
author: [いも](https://www.docswell.com/user/imo)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/8EDLRQ24JG.jpg?width=480
description: UnityFukuoka18でのLT資料です https://unityfukuoka.connpass.com/event/338153/
published: February 08, 25
canonical: https://www.docswell.com/s/imo/54VLLQ-think_debug
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/8EDLRQ24JG.jpg)

デバッグ機能を作るときに
考えていること
@いも
2025/02/08 Unity Fukuoka 18
1


# Page. 2

![Page Image](https://bcdn.docswell.com/page/V7P2WL1V78.jpg)

自己紹介
いも(@adarapata)
株式会社ミラティブ
Unityエンジニアやってます
趣味でゲーム開発お手伝い中
幻想戦略録
2025/02/08 Unity Fukuoka 18
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/2JVD8QYRJQ.jpg)

話すこと
UnityDebugSheetの紹介
デバッグ機能を作る際に考えていること
2025/02/08 Unity Fukuoka 18
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/5EGY5W96EL.jpg)

デバッグ機能
チートとかフラグ設定とか様々な機能
開発するうえで必須
どこのご家庭にもあるけどあんまり表に出ないやつ
ゲームによって違いすぎるからね！
でも知りたくない！？
まずは自分からだよね
ということで、自分がデバッグ機能を作る際に意識していることを共
有します。
2025/02/08 Unity Fukuoka 18
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/4JQMZ3W27P.jpg)

UnityDebugSheet
2025/02/08 Unity Fukuoka 18
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/K74V31KPJ1.jpg)

UnityDebugSheet
@harumak_11さんが公開しているデバッグ画面を簡単に作れるライブ
ラリ
モバイルネイティブっぽいUIを簡単に作れる
ページの階層化が簡単
UI追加がめっちゃ簡単
AddButton("Example Button", clicked: () => { Debug.Log("Clicked"); });
2025/02/08 Unity Fukuoka 18
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/LJ131GXX7G.jpg)

MemoryPackでゲームのリプレイデータを作った話
リプレイを保存したりなどなど。
2025/02/08 Unity Fukuoka 18
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/GJWP8KNK72.jpg)

デバッグ機能を作る際に考えていること
本番に影響を与えない
なるべくフローは変えない
ユースケースを１つは用意する
2025/02/08 Unity Fukuoka 18
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/4EZK8Z3NE3.jpg)

本番に影響を与えない
デバッグ機能をリリースビルドに含めると、割と良くない事が起こ
る。
うっかり機能を使えてしまう
悪意ある人が使えるようにしてしまう
なので絶対に本番ビルドからは抜いておきたい。
Unityではasmdefを分離することで対応可能
2025/02/08 Unity Fukuoka 18
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/Y76QPZX97V.jpg)

asmdefの分離
✕
○
アプリケーションコードとデバッグ機能の依存関係を整える
2025/02/08 Unity Fukuoka 18
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/G75RKWXDE4.jpg)

設定を変える
define constraintsでアセンブリをオミットする
任意のシンボルがあるときのみアセンブリを加えることができる。
コードを丸ごと取り除けるので確実にデバッグ機能は使えなくなる。
Prefabは消えないのでコンポーネントが消えたPrefabがシーンに残っ
てしまうのは注意。
2025/02/08 Unity Fukuoka 18
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/9J2DWQQMJR.jpg)

依存の向きが Development -> Game になると、外側からゲームのデー
タや機能にアクセスできるような構造にしないといけない。
DIコンテナで管理してたりすると取得しやすい。
var repository = LiftimeScope.Find<LifetimeScope>().Container.Resolve<UserRepository>();
repository.UpdateMoney(manyManyMoney);
デバッグ画面は雑にこういうの書きがち
2025/02/08 Unity Fukuoka 18
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/DEY2LWWPEM.jpg)

なるべくフローは変えない
ドラクエのようなRPGで「バトルをすぐ終わらせてスキップさせた
い」という要望があったときに、どう実装するか。
バトル終了条件は「敵モンスターが存在しなくなったとき」と仮定す
る
1. ForceBattleEnd 的なものを作ってデバッグから呼び出し強制的に終
了させる
2. プレイヤーのパラメータを超強くするor敵のパラメータを超弱くす
る
2025/02/08 Unity Fukuoka 18
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/VJN8499M78.jpg)

1は通常のバトルの流れとは完全に違う新たなフローをデバッグ用に
作り出すことになるので、メンテナンスが難しくなりがち
本体の機能追加に伴い動かなくなる危険性が高い
前のバージョンでは使えてたんですがというあるある
2はデータを更新するのでゲームシステムの範疇で想定される結果に
なる。そこで問題が発生するならむしろ解決されるべき課題であるこ
とが多い。
最大HP1の相手にHP割合攻撃したら0ダメージになった！
ほぼありえない状況だけどシステム的には対処しておくべき
2025/02/08 Unity Fukuoka 18
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/YE9KQ22WE3.jpg)

フローの変更よりデータの変更
フローを変更する ≒ 新たにメンテナンスすべき対象が増える
極力データの変更だけで要件を満たせるようにしたほうが開発中は楽
になる。
-> データのハードコードは開発中であっても基本避けたほうがお得。
ScriptableObjectにするだけでも十分。
2025/02/08 Unity Fukuoka 18
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/GE8RG55RJD.jpg)

ユースケースを一つは作る
主にQAなど非エンジニアの他者が機能を使う場合に汎用的な要件を
満たすだけでは使いづらくなりがち。
例：プレイヤーの所持金を変更できるデバッグ機能
2025/02/08 Unity Fukuoka 18
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/LELKGYY2JR.jpg)

入力画面を作り、数値を自由に設定できる実装にする
汎用性はあるが、毎回入力させるのは手間もかかる
2025/02/08 Unity Fukuoka 18
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/4JM2QNN9JW.jpg)

なぜその機能がほしいのかを考える
アイテム購入を速やかに行えるようにしたいから？
大量に所持したときのUI崩れを見たいから？
なんらかの理由があるなら、最低限それを簡単に満たせるデバッグを
作る
2025/02/08 Unity Fukuoka 18
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/PJRM8DD9E9.jpg)

例えば買い物に困らないだけあればいいのなら、入力させずにそうい
うショートカットボタンを用意してあげる
入力を自動で上限いっぱいにするだけの「お金持ち」ボタン。
実装工数に対して効果は高い。
2025/02/08 Unity Fukuoka 18
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/PEXV81137X.jpg)

不要なユースケースはすぐに消す
利用者がどの機能を活用しているのかは定期的にヒアリングしてお
く。
しばらく使ってないけど全面に出てる機能がないか
頻繁に使うのに奥の階層に機能がないか
デバッグ機能は増え続けるものなので粛々と精査するしかない
UnityDebugSheetは並び替え、削除がしやすいのでオススメ
2025/02/08 Unity Fukuoka 18
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/3EKQK22NED.jpg)

まとめ
デバッグ機能とコードはasmdefを切ろう
フローを変更する前にデータ変更だけで解決できないかがんばる
目的に応じた親切なユースケースを作ってあげよう
UnityDebugSheetはいいぞ
2025/02/08 Unity Fukuoka 18
21