プロジェクトのフォルダ名はサービス名にすべき？用途名との使い分けを整理

最初に: 正解は1つではないが、基準はある

プロジェクトのフォルダ名を決めるとき、サービス名にするべきか 用途名にするべきか で迷うことはかなり多いです。
結論から言うと、そのフォルダが長く識別される単位ならサービス名、短期の作業目的が前面に出る単位なら用途名 が基本です。

たとえば、本番運用する Web サービスの本体なら、フォルダ名はサービス名に寄せたほうが安定しやすいです。
一方で、画像変換用の一時スクリプト、検証用の小さな作業ディレクトリ、移行専用の補助ツールなら、用途名のほうが中身を理解しやすいことがあります。

つまり大事なのは、今この瞬間に分かりやすいか だけではなく、数か月後に見ても何の単位か分かるか です。
フォルダ名はローカルでしか見ないようでいて、Git のクローン先、ターミナルのパス、エディタのワークスペース名、レビュー時の会話、運用手順書、Docker Compose の既定プロジェクト名など、意外と多くの場所に影響します。

この記事では、2026年4月24日時点で GitHub Docs、Docker Docs、npm Docs の公開情報を確認しながら、一般的な開発現場で使いやすい判断基準として整理しています。

まず結論: 基本はサービス名、補助フォルダは用途名

最初にざっくり整理すると、次の考え方が実務では扱いやすいです。

フォルダの性質	向いている名前	例
本番で育てる製品本体	サービス名	`engineer-notes`, `billing-api`, `admin-console`
一時的な検証や補助作業	用途名	`image-migration`, `csv-import-test`, `ogp-generator`
社内共通テンプレートや土台	用途名か領域名	`laravel-base`, `infra-modules`, `ui-kit`
複数サービスを束ねる親ディレクトリ	組織的なまとまり名	`client-a`, `product-suite`, `platform`

迷ったときにまず押さえたいのは、そのフォルダ自体が何として呼ばれるべきか です。

ユーザーやチームがその単位をサービス名で呼ぶなら、サービス名
チーム内で 移行ツール 検証環境 作業用スクリプト と呼ぶなら、用途名

フォルダ名は説明文ではなく、識別子です。
そのため、何をしているか より 何として存在しているか を先に見るとぶれにくくなります。

サービス名にすべき場面

1. そのフォルダが製品本体のルートである

一番分かりやすいのはここです。
Web サービス、アプリ、SaaS、社内システムなど、継続して運用する本体なら、サービス名に寄せるのが基本です。

たとえば、請求管理サービスの本体なのにフォルダ名が laravel-test や customer-tool だと、後から見た人が「これが本番の何なのか」を把握しづらくなります。
逆に billing-app や invoice-console のようにサービス単位で呼べる名前なら、会話でもドキュメントでも揃えやすくなります。

特に次のような場面では、サービス名のほうが強いです。

新メンバーへの引き継ぎ
サーバーやCI設定との対応付け
複数リポジトリの一覧管理
エディタやターミナルでの検索
デプロイ手順書との照合

2. 用途が変わっても中身の正体は変わらない

フォルダの中身は、時間がたつと役割が少しずつ広がります。
最初は LP作成用 だったものが、途中で API を持ち、管理画面を持ち、運用バッチを持つことも普通にあります。

このとき、用途名ベースだと名前が先に古くなります。
campaign-site がいつの間にか本体サービス化している、prototype が半年後も本番の土台になっている、といったことは珍しくありません。

それに対してサービス名は、用途が増えても比較的ぶれません。
そのため、長生きする前提のフォルダほどサービス名が向いています。

3. URL、リポジトリ名、デプロイ対象とそろえたい

GitHub Docs でも、リポジトリ名は短く覚えやすい単位で扱われ、必要なら後からリネームできますが、完全に影響ゼロではありません。
リポジトリ名変更後も多くのリンクはリダイレクトされる一方、GitHub Actions の一部参照などは注意が必要です。

つまり、後で変えられるから適当でよい とは言い切れません。
フォルダ名、リポジトリ名、サービス名がある程度そろっていると、認知負荷がかなり下がります。

たとえば次のようにそろっていると強いです。

フォルダ名: engineer-notes
リポジトリ名: engineer-notes
本番URLやサービス呼称: Engineer Notes

この状態だと、パス、会話、設定、デプロイ先の対応が直感的です。

用途名にすべき場面

1. そのフォルダが補助作業のためのもの

用途名が向くのは、製品本体ではない フォルダです。
たとえば次のようなものです。

データ移行専用スクリプト
画像生成や整形ツール
CSV インポート検証
負荷試験用コード
公開前の一次検証用サンプル

これらは、サービス名より 何のためにあるか が先に分かったほうが助かります。
ogp-generator や customer-import-check のような名前なら、開いた瞬間に用途が伝わります。

2. 複数サービスにまたがって再利用する

一つのサービス専用ではなく、横断的に使うものも用途名向きです。
たとえば infra-modules shared-design-tokens log-archive-tool のようなものです。

こういうものを特定サービス名で置くと、他チームが再利用しづらくなります。
billing-tools という名前の中に、実は全社共通の CSV 整形スクリプトが入っていると、初見では取りにくいです。

3. 短命な検証フォルダである

数日から数週間で捨てる前提の検証なら、用途名で十分です。
むしろサービス名に寄せすぎると、本体と見分けづらくなることがあります。

たとえば

session-fix-repro
ec2-cost-check
new-ogp-layout-test

のように、何を確かめるためのディレクトリかが分かる名前のほうが安全です。

なぜフォルダ名がそんなに大事なのか

フォルダ名は見た目の好みの話に見えますが、実際は運用に影響します。

Docker Compose ではディレクトリ名が既定の project name に使われる

Docker Docs では、Docker Compose は Compose ファイルを含むディレクトリ名を既定の project name に使うと案内されています。
つまり、フォルダ名がそのままネットワーク名、ボリューム名、コンテナ名の接頭辞に影響することがあります。

このため、ローカルの気分で test tmp new のような雑な名前を付けると、後から見たときに何の環境か分かりにくくなります。

パスでの会話が増える

チーム開発では、実際によくこういう会話が起きます。

その修正、 billing-app のほうです
client-a 配下の import-tool です
いま見ているのは prototype じゃなくて本番側です

このとき、名前が役割を表していないと説明コストが毎回増えます。
フォルダ名は短いですが、コミュニケーションコストにはかなり効きます。

検索しやすさと一覧性に差が出る

エディタ、ターミナル、ファイル同期、バックアップ、CI、スクリーンショット共有など、開発ではフォルダ名を一覧で見る場面が多いです。
new-project-final tool2 tmp-app のような名前が並ぶと、中身を毎回開かないと判断できません。

一方で、customer-portal media-import-tool infra-modules のように、識別子として意味がある名前なら一覧性がかなり上がります。

迷ったときの判断基準

答えを出しやすい順に、次の5つで考えるのがおすすめです。

1. そのフォルダは何として長く残るか

最重要です。
製品本体として残る ならサービス名、補助用途として残る なら用途名が基本です。

2. 呼び名として自然なのはどちらか

チームが普段どう呼んでいるかも重要です。

このサービスを直す
この移行ツールを回す

後者なのにサービス名を付けるとズレますし、前者なのに用途名を付けると弱いです。

3. 用途が変わっても名前が耐えるか

いまの説明だけで名前を付けると、用途変更で一気に古くなることがあります。
今しか正しくない名前 なら、一段抽象度を上げたほうがよいです。

4. 他のサービスでも使うか

横断利用するなら、特定サービス名を避けたほうが再利用しやすいです。

5. 既存の命名規則とそろうか

個人最適より、チームの一貫性のほうが長期的には効きます。
すでに 本体はサービス名、補助ツールは用途名 でそろっているなら、そのルールに寄せたほうがよいです。

ありがちな失敗

1. とりあえず `new` `test` `final` にする

一時的には便利でも、数週間後には意味を失います。
final は次の final2 を呼びやすいので危険です。

2. 本体なのに用途名が強すぎる

たとえば admin-renewal という名前で始まったものが、そのまま正式な管理画面本体になることがあります。
この場合、早めにサービス単位の名前へ寄せたほうが後の混乱が少ないです。

3. 共通ツールなのに特定サービス名を背負わせる

将来の再利用性を自分で削るパターンです。
共通部品なら、用途や領域で呼んだほうが広げやすいです。

4. ローカルだけの名前とリポジトリ名がずれすぎる

ローカルフォルダ名とリポジトリ名が多少違うのは問題ありません。
ただ、まったく別物だと手順書や会話で混乱しやすくなります。

実務ではどう決めると楽か

おすすめは、最初に次の3行ルールを決めることです。

製品本体のルートはサービス名
補助ツールや検証用は用途名
迷ったら 半年後の自分が一覧で分かるか で決める

この程度でも、かなりぶれにくくなります。

さらに、複数人で触る環境なら次も決めておくと安定します。

小文字ベースにするか
単語区切りを - に寄せるか _ に寄せるか
省略語をどこまで許すか
本体と補助ツールの接尾辞をどうするか

npm Docs の package name guidelines のように、名前は短く、分かりやすく、他人が見ても意味を推測しやすいことが強く効きます。
フォルダ名もまったく同じで、凝った名前より、誤読しにくい名前のほうが運用しやすいです。

最初に押さえるべきか

最初は次の5つで十分です。

本体サービスのルートなら、基本はサービス名
補助ツール、移行、検証なら、用途名でよい
フォルダ名は 中身の正体 を表す識別子として考える
いま分かりやすいより、半年後にも分かるかを見る
チームの命名規則とそろえる

まとめ

プロジェクトのフォルダ名は、常にサービス名が正しいわけでも、常に用途名が正しいわけでもありません。
ただし、長く育てる本体はサービス名 補助用途のディレクトリは用途名 という基準を持つと、かなり迷いにくくなります。

特に重要なのは、何をしているか より 何として存在しているか で考えることです。
そのフォルダが製品本体として呼ばれるならサービス名、移行ツールや検証用として呼ばれるなら用途名のほうが自然です。

最初の名前は小さな話に見えますが、引き継ぎ、検索、運用、ツール連携では地味に効きます。
迷ったら、半年後に一覧で見て迷わないか を基準にすると外しにくいです。

この記事と一緒に読みたい

参考リンク

GitHub Docs: Renaming a repository
GitHub Docs: Quickstart for repositories
Docker Docs: Specify a project name
npm Docs: Package name guidelines