https://wuyukwi.duckdns.org/tags/%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3/Recent content in アーキテクチャ on Wuyukwi's NotebookHugojaWed, 18 Feb 2026 13:18:23 +0900https://wuyukwi.duckdns.org/posts/zenn-2d31ee3e52b29e/Wed, 18 Feb 2026 13:18:23 +0900https://wuyukwi.duckdns.org/posts/zenn-2d31ee3e52b29e/<blockquote> <p>📌 <em>この記事は <a href="https://zenn.dev/wuyukwi/articles/2d31ee3e52b29e">Zenn</a> に投稿した内容のアーカイブです。</em></p> </blockquote> <h1 id="はじめに">はじめに</h1> <p>Unity で開発していると、<br> <strong>実行中にパラメータを触りながら挙動を確認したい</strong><br> という場面は、ほぼ毎日のように出てきます。</p> <p>最初のうちは、Unity 標準の仕組みを使って<br> 簡単な Runtime Debug UI を用意すれば十分でした。</p> <p>ただ、プロジェクトが進み、</p> <ul> <li> <p>デバッグ項目が増える</p> </li> <li> <p>調整対象が増える</p> </li> <li> <p>複数人で同時に触る</p> </li> </ul> <p>という状況になるにつれ、<br> <strong>「その場しのぎ」で作ったデバッグ UI が、確実に足を引っ張る</strong><br> ようになってきます。</p> <p>この段階で欲しくなったのが、</p> <blockquote> <p><strong>壊れにくく、拡張しやすく、<br> プロジェクトと一緒に「育てていける」デバッグ基盤</strong></p> </blockquote> <p>でした。</p> <p>この記事では、<br> そのために設計した <strong>自作 Runtime Debug システム</strong> について、<br> <strong>設計意図と実装の要点</strong> を中心にまとめます。</p> <h1 id="何が問題だったのか">何が問題だったのか</h1> <p>問題の本質は、<strong>「UI をどう実装するか」</strong> ではありませんでした。</p> <p>本当に困っていたのは、</p> <ul> <li> <p>Debug 項目の追加・削除が面倒</p> </li> <li> <p>どこに何のデバッグ設定があるのか分からない</p> </li> <li> <p>不要になった項目が整理されず、蓄積していく</p> </li> </ul> <p>という <strong>運用面の破綻</strong> です。</p> <p>特に後半になると、</p> <blockquote> <p><strong>「デバッグ環境のせいで、デバッグそのものがやりにくい」</strong></p> </blockquote> <p>という、本末転倒な状態になりがちでした。</p> <h1 id="目指したゴール">目指したゴール</h1> <p>今回の設計で目指したゴールは、かなり明確です。</p> <ul> <li> <p>UI を書かずに Debug 項目を追加できる</p> </li> <li> <p>構造が自然に整理され続ける</p> </li> <li> <p>無効化・除去が簡単</p> </li> <li> <p>プロジェクト規模が大きくなっても破綻しない</p> </li> </ul> <p>つまり、</p> <blockquote> <p><strong>「運用しても壊れない設計」</strong></p> </blockquote> <p>を最優先にしました。</p> <h1 id="全体構成">全体構成</h1> <p>全体の流れは、次のようになります。</p> <pre><code>起動 ↓ RuntimeInitializeOnLoadMethod ↓ DebugManager 自動生成 ↓ DebugOption 自動登録 ↓ Reflection による項目収集 ↓ UI 自動生成 &amp; バインディング </code></pre> <p>ここで重視したのは、</p>