【チーム開発向け】Unityプロジェクトのフォルダ構成と命名規則のベストプラクティス

Unityで個人開発をしているうちは、多少フォルダ構成が雑でも意外と何とかなります。
でも、チーム開発に切り替えた瞬間、こんな悩みが一気に出てきませんか？

• どこに何のファイルがあるのか分からない
• このPrefab、勝手に触っていいのか不安
• 途中参加の人が毎回フォルダ説明から入っている

これらはスキル不足ではなく、フォルダ構成と命名規則が「チーム前提」になっていないことが原因で起きるケースがほとんどです。

Unityはフォルダ構成や命名規則を強制しない分、自由度が高い反面、
ルールを決めないまま人数や期間だけが増えると、プロジェクトは簡単に“触るのが怖い状態”になります。

この記事では、

• チーム開発・中長期運用で破綻しにくいフォルダ構成の考え方
• 最低限決めておくべき命名規則の軸
• よくある失敗例と、その回避ポイント

を中心に解説します。

「この構成が絶対正解」という形を押し付けるのではなく、
なぜそう考えるのか、どういう状況で崩れやすいのかを整理する、実務寄りの記事です。

すでに少し荒れてしまったプロジェクトでも、
「今からでも最低限整えたい」「ルールを決め直したい」という人に、判断の軸として役立つ内容を目指しています。

---

結論：チーム開発で破綻しないための最重要ポイント

先に結論からお伝えします。

チーム開発におけるフォルダ構成・命名規則で最も大切なのは、
「綺麗さ」や「オシャレさ」ではなく、「迷わなさ」です。

つまり、

• どこに何があるか、名前を見ただけで分かる
• 触っていい範囲・触ると危険な範囲が直感的に伝わる
• 途中参加のメンバーでも、説明なしで把握できる

この状態を作れているかどうかが、プロジェクトが長期的に破綻するかどうかを大きく左右します。

よく「Unityの正しいフォルダ構成」「おすすめの命名規則」を探したくなりますが、
残念ながら、すべてのプロジェクトに当てはまる正解は存在しません。

ただし、

• 最低限守るべき共通ルール
• 多くの現場で実際に問題になるポイント
• 規模が大きくなると破綻しやすい構成

こうした「避けるべき地雷」や「判断の軸」ははっきりしています。

この記事では、

• まず何を揃えれば“事故が起きにくくなる”のか
• どこから先はプロジェクト規模に応じて考えればいいのか

を切り分けて解説していきます。

---

なぜフォルダ構成と命名規則が「開発効率そのもの」になるのか

「多少フォルダが散らかっていても、動いているなら問題ないのでは？」
チーム開発を始めたばかりの頃は、こう感じる人も少なくありません。

でも実際には、フォルダ構成と命名規則の乱れは、
じわじわと、しかし確実に開発効率を奪っていきます。

まず起きるのが、探す時間の増加です。

PrefabやScriptを探すたびに、

• 「これ、どのフォルダだったっけ？」
• 「同じような名前のファイルが多すぎる…」

と迷う時間が積み重なります。 1回あたりは数十秒でも、人数×作業回数で見ると、かなりのロスになります。

次に深刻なのが、心理的なブレーキです。

構成や命名が曖昧だと、

• このPrefabを編集して大丈夫か分からない
• 影響範囲が読めず、変更が怖い
• 結果的に「触らない」という選択をしてしまう

こうした状態が生まれます。 これはスキルの問題ではなく、情報が構造として整理されていないことが原因です。

さらに厄介なのが、仕様変更やバグ修正時の影響範囲が見えなくなる点です。

役割が名前から判断できないファイルが増えると、 「この修正でどこが壊れるか分からない」状態になります。 その結果、

• 変更をためらって後回しにする
• 小さな修正のはずが、大きな不具合につながる

といった悪循環に入りがちです。

つまり、フォルダ構成と命名規則は「整理整頓」の話ではありません。
判断を早くし、安心して手を入れるための土台なんです。

---

Unityフォルダ構成の基本思想（考え方の土台）

Unityのフォルダ構成について調べると、
「この形が正解」「この構成がおすすめ」といった例をよく見かけます。

ですが、チーム開発を前提に考えるなら、
まず押さえるべきなのは具体例よりも“考え方”です。

なぜなら、プロジェクトの規模・人数・期間によって、
最適なフォルダ構成は必ず変わるからです。

フォルダ構成に正解はないが、NGパターンは存在する

Unityにはフォルダ構成を強制するルールがありません。 そのため、極端な話、どんな構成でも動いてしまいます。

ただし、実務でよく問題になるNGパターンははっきりしています。

• Assets直下に大量のフォルダやファイルが並んでいる
• フォルダ名が抽象的で、中身を開かないと役割が分からない
• 同じ種類のアセットが、あちこちに点在している

この状態になると、「探す」「判断する」「変更する」すべてのコストが跳ね上がります。

「誰が見ても役割が分かる」構成を目指す

チーム開発では、フォルダ構成は自分のためではなく、
他人のために作るものだと考えると判断しやすくなります。

理想は、
フォルダ名・ファイル名を見ただけで8割くらい状況が分かる状態です。

たとえば、

• ここはUI関連が入っていそう
• ここはプレイヤー機能専用っぽい
• ここは外部アセットだから触らない方がよさそう

といった判断が、説明なしでできるかどうかが重要です。

この「名前を見ただけで判断できる」という感覚は、
途中参加のメンバーや、久しぶりに触る自分自身を確実に助けてくれます。

---

フォルダ構成パターン別の考え方

ここからは、チーム開発でよく使われる
フォルダ構成の代表的なパターンを整理していきます。

大切なのは「どれが正解か」ではなく、
どの段階・規模で、どの考え方が合いやすいかを理解することです。

種類別フォルダ構成（小〜中規模向け）

Unityを触り始めた人が、まず採用しやすいのが
アセットの種類ごとに分ける構成です。

代表的には、次のような形です。

• Scenes
• Scripts
• Prefabs
• Materials
• Textures
• Audio

この構成は、

• プロジェクト初期
• 人数が少ないチーム
• 機能の境界がまだ曖昧な段階

では、とても扱いやすいのが特徴です。

「どこに何を置くか」で迷いにくく、
Unity初心者が混ざっていても理解しやすいのもメリットです。

ただし、プロジェクトが成長してくると、

• Scriptsフォルダが肥大化する
• 特定機能の関連ファイルが散らばる

といった問題が起きやすくなります。

機能・モジュール別フォルダ構成（中〜大規模向け）

プロジェクトがある程度育ってきたら、
機能単位でまとめる構成を検討するタイミングです。

例えば、

• Player
• Enemy
• UI
• Title

といったフォルダを作り、
その中に Scripts / Prefabs / Materials などをまとめます。

この構成のメリットは、

• 1つの機能に関わるファイルが1か所に集まる
• 影響範囲が把握しやすい
• 分業しやすく、触っていい範囲が明確になる

という点です。

また、機能単位で整理しておくと、
スクリプトの責務も自然と分かれやすくなります。

スクリプト設計とフォルダ構成は密接に関係しています。
責務分離の考え方については、こちらの記事も参考になります。

自作アセットと外部アセットを分離する考え方

チーム開発では、
自分たちで作ったものと、外部アセットを明確に分けることがとても重要です。

よく使われるのが、

• _Project
• ThirdParty
• Plugins

といったフォルダです。

こうしておくことで、

• 外部アセットを誤って編集する事故を防げる
• アップデート時の影響範囲が分かりやすい
• 「触っていい／触らない」が直感的に伝わる

特に、最初から構成が整理されたテンプレート系アセットは、
「良い構成の実例」として非常に参考になります。

Spaceship Explorer 3D – Complete Game Template
✅アセットストアでチェックする

Warriors vs Orcs 2D – Complete Game Template
✅アセットストアでチェックする

---

命名規則で「触っていいか怖い」問題をなくす

フォルダ構成を整えても、
命名規則がバラバラだと、チーム開発の不安は残ったままです。

特に多いのが、

• このScript、何をしているのか分からない
• 似た名前のファイルが多くて区別できない
• 変更したらどこに影響するのか想像できない

といった「触っていいか怖い」状態です。

命名規則の目的は「検索性」と「安全性」

命名規則というと、
「見た目を揃えるためのルール」と思われがちですが、本質は違います。

チーム開発における命名規則の目的は、

• 検索しやすくすること
• 不用意な変更を防ぐこと

この2点に集約されます。

例えば Manager.cs のような名前は一見便利ですが、
プロジェクトが進むほど「何のManagerなのか分からない」地雷になります。

代わりに、

• AudioManager
• SaveDataManager
• UIInputManager

のように、
責務が名前から特定できることが重要です。

最低限決めておきたい命名ルール

すべてを厳密に決める必要はありません。
まずは、チーム全体で最低限ここだけは揃えるというラインを決めましょう。

• 英数字のみを使用する（日本語・全角は使わない）
• クラス名・ファイル名は PascalCase
• フォルダ名は複数形で統一（Scripts / Prefabs など）

これだけでも、可読性と安全性は大きく向上します。

接頭辞（Prefix）はいつ使うべきか？

接頭辞は、使いすぎると逆に読みづらくなりますが、
アセット系には非常に効果的です。

例えば、

• T_〇〇（Texture）
• M_〇〇（Material）
• P_〇〇（Prefab）

のようにしておくと、

• 検索結果で一瞬で判別できる
• 差分レビューや整理作業が楽になる

といったメリットがあります。

逆に、Scriptには無理にPrefixを付けず、
名前そのものに役割を含める方が実務では扱いやすいケースが多いです。

---

チーム開発で必須の「運用ルール」

フォルダ構成や命名規則は、
決めただけでは意味がありません。

実際のチーム開発では、
「ルールはあるけど守られていない」という状態が一番危険です。

ここでは、構成や命名を形骸化させないための最低限の運用ルールを整理します。

フォルダ・ファイル操作は必ずUnityエディタ内で行う

チーム開発で最も多い事故のひとつが、
エクスプローラー／Finder上での移動・リネームです。

Unityでは、すべてのアセットに .meta ファイルが紐づいています。 エディタ外で操作すると、この対応関係が壊れ、

• 参照切れ
• Prefabのリンク崩壊
• 原因不明のエラー

といったトラブルにつながります。

そのため、
フォルダ作成・移動・リネームは必ずUnityエディタ内で行うことを、
チームの共通ルールとして明文化しておくのがおすすめです。

また、こうした問題はGitなどのバージョン管理と強く関係しています。 UnityプロジェクトをGitで扱う際の注意点については、 以下の記事で詳しく解説しています。

ルールは最初に決めて、後から厳しくしすぎない

もうひとつ重要なのが、
最初から完璧なルールを作ろうとしないことです。

あまりに細かい命名規則やフォルダルールを決めると、

• 覚えきれない
• 守るのが面倒になる
• 結果的に無視される

という状態になりがちです。

おすすめなのは、

• まずは「事故を防ぐ最低限」だけ決める
• プロジェクトの成長に合わせて見直す

というスタンスです。

フォルダ構成も命名規則も、
プロジェクトと一緒に育てていくものだと考えると、
無理なく運用しやすくなります。

---

よくある失敗例と回避策

ここでは、チーム開発のUnityプロジェクトで
実際によく起きる失敗例と、その回避策をまとめます。

どれも「最初は問題なかったけど、途中から地獄になる」パターンなので、
心当たりがあれば早めに手を打つのがおすすめです。

Manager.csが量産される

とりあえず Manager を付けておけばよさそう、という判断は、
ほぼ確実に後で後悔します。

• Managerが何を管理しているのか分からない
• 責務が肥大化しやすい
• 誰が触っていいのか判断できない

回避策としては、

• 役割を名前に含める（AudioManager / InputManager など）
• 管理対象が増えたら分割する前提で設計する

フォルダを細かく分けすぎて迷子になる

整理しようとして、
フォルダ階層を深くしすぎるのもよくある失敗です。

• 1フォルダに1〜2ファイルしかない
• 何階層も掘らないと目的のファイルに辿り着けない

この状態になると、
逆に探すコストが増えてしまいます。

目安としては、

• 1フォルダに3〜5ファイル程度
• それ以上増えたら分割を検討

という感覚が、実務では扱いやすいです。

日本語（全角）ファイル名を使ってしまう

Unity自体は日本語ファイル名を扱えますが、
チーム開発・長期運用ではトラブルの元になりやすいです。

• 外部ツールでエラーになる
• ビルド環境差で問題が出る
• OS依存の不具合が発生する

回避策としてはシンプルで、
英数字のみを使用すると決めておくことです。

1つのシーンを複数人で触ってしまう

巨大なシーンを複数人で編集すると、
Gitのコンフリクトが頻発します。

• 誰かの作業を上書きしてしまう
• マージが地獄になる

回避策としては、

• シーンを機能ごとに分割する
• Additive読み込みを使う
• Prefab単位で作業を分担する

といった方法があります。

---

シーンとヒエラルキー整理も「構成の一部」

ここまでフォルダ構成と命名規則を中心に解説してきましたが、
チーム開発ではシーン内のヒエラルキー整理も同じくらい重要です。

プロジェクトウィンドウが綺麗でも、
ヒエラルキーが無秩序だと、結局「触るのが怖い」状態になります。

ヒエラルキーが荒れると何が起きるか

ヒエラルキーが整理されていないシーンでは、

• どのオブジェクトが何の役割なのか分からない
• 削除・移動していいか判断できない
• 実行中に生成されたオブジェクトで埋もれる

といった問題が起きやすくなります。

特にチーム開発では、
他人が作ったシーンを後から触るケースが多いため、
ヒエラルキーの分かりにくさはそのまま作業ストレスにつながります。

空オブジェクトを使って役割ごとにまとめる

ヒエラルキー整理でまずやっておきたいのが、
コンテナ役の空オブジェクトを用意することです。

例えば、

• @Systems
• World
• UI
• Lights

といった空オブジェクトをルートに置き、
その配下に関連オブジェクトをまとめます。

こうすることで、

• ヒエラルキーを一目で把握できる
• 不要なオブジェクトを誤って触りにくくなる
• 実行中に生成されるオブジェクトも整理しやすい

というメリットがあります。

ヒエラルキー整理を補助するツールを活用する

ヒエラルキーの整理はルールだけでも可能ですが、
補助ツールを使うと運用がかなり楽になります。

特にチーム開発では、「整理しやすい環境」を作っておくことが重要です。

Hierarchy Folders
✅アセットストアでチェックする

Hierarchy Organizer
✅アセットストアでチェックする

---

まとめ：完璧を目指さず「迷わない状態」を作る

チーム開発におけるフォルダ構成や命名規則は、
綺麗に揃えること自体が目的ではありません。

本当に大切なのは、

• どこに何があるか迷わない
• 触っていいかどうか判断できる
• 変更の影響範囲を想像できる

この「安心して作業できる状態」を作ることです。

正解のフォルダ構成や命名規則を探し続けるよりも、
チーム内で一貫したルールを決め、それを守ることの方が、
はるかにプロジェクトを安定させてくれます。

また、

• 最初から完璧を目指さない
• プロジェクトの成長に合わせて見直す
• 「事故を防ぐ最低限」を優先する

この考え方を持っておくと、
フォルダ整理や命名ルールが重荷になりにくくなります。

すでに少し荒れてしまったプロジェクトでも、
今から整えれば十分に立て直せます。

まずは「迷うポイント」を1つ減らすところから、
少しずつ整理していきましょう。

フォルダ構成・命名規則・運用ルールをまとめて見直したい場合は、
以下の記事も参考になります。

---

参考文献・参考リンク

• Organizing your project（Unity公式・日本語）
• Organizing your project（Unity公式・英語）
• Unityプロジェクトのフォルダ構成について考える（Qiita）
• Unityのフォルダ構成・命名規則の考え方（CEW Games）
• Unityプロジェクトのシーン・フォルダ構成整理メモ（Uhiyama Lab）
• Unity Folder Structure Best Practices（Anchorpoint）
• Unityプロジェクト整理のヒント（ONES）
• Unityプロジェクト構成・設計メモ（Zenn）
• UI Toolkit Naming Conventions（Unity公式ドキュメント）
• Unity Style Guide（GitHub）
• Unity3D Best Practices: Folder Structure & Source Control（LinkedIn）
• How do you organize your Assets folder in Unity?（Reddit）

---

よくある質問（FAQ）