ディレクトリ構造・ファイル命名規約の指針

by

構築・運用時に困らないLinux系OSのディレクトリ構造・ファイル名の基本ルールについての考察

1. はじめに

システム構築や運用をするときディレクトリ構造やファイル名の命名規則に困ったことはありませんか。

実際の現場では「命名規約」が軽視されがちです。しかしながら、ディレクトリ構造やファイル名に一貫性がないと、後から混乱や工数増につながります。特にVPSやオンプレサーバを独力で構築・運用する場合、最初のルール設計がチーム全体の作業効率や保守性を左右します。
本記事では、筆者が実務で試行錯誤した結果を踏まえて、ディレクトリ構造やファイル名の規約を設計する際の指針を整理します。
なお、RockyLinux9(RHEL系)を基準に記事を作成しています。Ubuntu(Debian系)など別の系列のディストリビューションをお使いの場合は、各ディストリビューションの流儀に読み替えてご覧ください。

2. 命名規約を設ける目的

命名規約は単なる「きれいに見せるためのルール」ではなく、運用全体の品質を高めるための仕組みです。

  • 可読性の向上：誰が見ても役割がわかる
  • 再現性の確保：新しい環境構築でも迷わず展開できる
  • 保守性の向上：障害対応時に検索・管理が容易
  • 引継ぎの円滑化：外部委託や人員交代時の摩擦を減らす

3. FHS(Filesystem Hierarchy Standard)とは

FHS(Filesystem Hierarchy Standard)は、Linuxを含むUnix系OSにおけるディレクトリ構造の標準規格です。
「どの用途にどのディレクトリを使うか」を定めており、OSやミドルウェア、アプリケーションが一貫した場所にファイルを配置できるようにするための指針となっています。

これを理解しておくと、自作アプリを配置する場所やログ・設定ファイルの分け方の基準となります。

FHSの基本的なディレクトリ

以下は運用でよく関わる主要なディレクトリと、その役割です。

  • /bin , /sbin
    • システムの基本コマンドを配置
    • /bin は一般ユーザが使う最低限のコマンド(例：ls, cp)
    • /sbin は管理者向けコマンド(例：ifconfig, reboot)
  • /etc
    • 設定ファイルの置き場
    • サービスの起動スクリプト、アプリ設定ファイルなどが格納される
  • /var
    • 可変データを保存するディレクトリ
    • ログ(/var/log/)、スプール(メールや印刷待ちデータ)、キャッシュなど
  • /usr
    • OSやアプリケーションの共有可能な読み取り専用データ
    • /usr/bin や /usr/sbin に多くのコマンドが配置される
  • /opt
    • サードパーティ製ソフトウェアの配置場所
    • 自作アプリやベンダ提供物を入れるのに適している
  • /home
    • 各ユーザのホームディレクトリ
  • /tmp
    • 一時ファイル置き場(再起動で自動削除されることが多い)

FHSと命名規約の関係

FHS自体は「トップ階層の役割」を決める規格ですが、その下の命名は各組織のルールに委ねられます。
例えば：

  • /opt/<vendor>/<app>/
  • /var/log/<vendor>-<app>/
  • /etc/<vendor>/<app>/

このように「どのトップディレクトリを使うか」はFHSに従い、その下の名前付けを命名規約で統一すると、標準に準拠しつつ独自ルールも持てる設計になります。
FHSは「トップ階層の役割分担」を規定するものと捉え、自作アプリやログの配置は、このFHSを土台に命名規約を組み合わせると運用が安定します。
特に /opt 、/var/log、/etc、の3箇所は 命名規約を予め決めておきたい場所です。

4. ディレクトリ構造の基本方針

ディレクトリ構造は最初にルールを決めておくことで、後から整理する手間を削減できます。

筆者の基本方針を紹介します。

  • 原則1：トップディレクトリはデフォルトから増やさずに原則的にFHSに従う
    例：
    • /opt（サードパーティ製ソフトウエア、ベンダ提供物や自作アプリの置き場所）
    • /var（可変データを保存）
    • /etc（設定ファイルの置き場所）
  • 原則2：サードパーティ製ソフトウエアやベンダ配布物と自作アプリをディレクトリで分ける
    例：
    • /opt/<3rd-party-software>/
    • /opt/<vendor>/<app>/
  • 原則3：ログや設定ファイルは明示的に分離する
    • /var/log/<vendor>-<app>/
    • /etc/<vendor>/<app>/

「なぜ/var/log/<vendor>/<app>/ではなく「/var/log/<vendor>-<app>/なの？」とお気づきの方もいらっしゃると思いますが、これは自作アプリをサービスとして起動するときの仕様のためです。
詳細は別の記事で解説予定です。

5. 命名規約のルール例

名前の付け方は日常的に目にするものなので、打ちやすさや一貫性を意識することが重要です。

筆者の基本方針を紹介します。

  • グループとメンバの関係を1ワードで表すときは英小文字＋ハイフン区切りを原則とする
    例：<vendor>-<app>
  • バッティングしない名付け
    • 例えば「example株式会社」製のアプリ「sampleapp」であれば<vendor>を”example”に、<app>を”sampleapp”置き換え、、他メーカのプロダクトとの名称衝突を避ける
      • 例：example-sampleapp
  • バージョンは末尾に付与する(必要時)
    例：<vendor>-<app>-v1.0
  • 避けるべきパターン
    • CamelCase(キャメルケース)
      • キャメルケースとは”英語の複合語やフレーズ、文をひと綴りとして、各構成語（要素語）の最初を大文字で書き表すことを言います。 * wikipediaより引用・一部編集
      • ディレクトリ名やファイル名に大文字小文字が混在する場合、システム運用作業でのキーボード操作で打鍵ミスを誘発します。(vscodeのような開発ツールを使って入力補助がある場合とは打鍵ミスの頻度がかなり変わります。）
    • 既に使用されているワードや意味不明な略語など
      • 例えば”test”,”root”,”abc”,”123″作成した本人が作業している内は問題が顕在化しないもしれませんが、後々誰かが作業を代行したり引き継ぐときに混乱を引き起こす可能性があります。

6. 実運用でのディレクトリ命名例

以下は筆者の自作アプリに関するファイルの配置場所と命名の例です。参考にされる場合は <vendor>の部分をご自身の所属組織やプロジェクト名に、<app>の部分をご自身の自作アプリ名に置き換えてください。

  • /opt/<vendor>/ … 自作アプリの実行ファイルやソースコードをまとめる親ディレクトリ
  • /opt/<vendor>/<app>/ … 各自作アプリの実行ファイルやソースコードの設置場所
  • /var/log/<vendor>-<app>/ … 各自作アプリのログ出力先
  • /etc/<vendor>/ … 自作アプリの実行ファイルやソースコードをまとめる親ディレクトリ
  • /etc/<vendor>/<app>/ … 各自作アプリの設定ファイルの設置場所

筆者の環境を紹介すると<vendor>はドメイン名略称の”geni”を使用しています。自作アプリを”app_a”,”app_b”とすると以下のようになります。

  • /opt/geni/ … 自作アプリの実行ファイルやソースコードをまとめる親ディレクトリ
  • /opt/geni/app_a/ … 自作アプリ”app_a”の実行ファイルやソースコードの設置場所
  • /opt/geni/app_b/ … 自作アプリ”app_b”の実行ファイルやソースコードの設置場所
  • /var/log/geni-app_a/ … 自作アプリ”app_a”のログ出力先
  • /var/log/geni-app_b/ … 自作アプリ”app_b”のログ出力先
  • /etc/geni/ … 自作アプリの設定ファイルをまとめる親ディレクトリ
  • /etc/geni/app_a/ … 自作アプリ”app_a”の設定ファイルの設置場所
  • /etc/geni/app_b/ … 自作アプリ”app_b”の設定ファイルの設置場所

7. 規約策定の進め方

命名規約は一度で完璧に仕上げる必要はないですが、予め指針があると作業に迷いが生じません。

  • 最初は「暫定ルール」でよい（ただし必ず明文化しておく）
  • システムが増えた段階で随時見直す
  • 1人運用でも「将来の引継ぎ」を前提に残す

8. まとめ

命名規約は「迷ったときに戻れる指針」として機能します。一貫性 と 説明できる理由 が大切だと思います。

小規模な環境であっても、早めにルール化しておくことで作業時の迷いを減らし、将来の保守・見直し工数を削減できます。