ディレクトリ構造とは？Unix/Windows別の基本・設計例とセキュリティ対策を徹底解説
エバープレイ編集部ディレクトリ構造とは何か — 基本概念と目的
ディレクトリ構造とは、ファイルシステム上でファイルやディレクトリ（フォルダ）を階層的に配置するルールとその実際の配置を指します。階層化することで論理的にデータを分類でき、人間やプログラムが目的のファイルを効率よく見つけられるようになります。OSや用途によって推奨される構造や慣習があり、サーバ運用や開発プロジェクト、Webサイト、アプリ配布などで重要な役割を果たします。
階層構造の基本要素
- ルート（root）: すべての起点。Unix系では「/」、Windowsではドライブレター（例：C:\）がルートです。
- ディレクトリ（フォルダ）: ファイルや他のディレクトリを格納する容器。ツリー構造を形成します。
- パス: ファイルやディレクトリの位置を示す文字列。絶対パス（ルートからの位置）と相対パス（カレントディレクトリからの位置）があります。
- シンボリックリンク／ジャンクション: あるディレクトリやファイルへの参照（ショートカット）。
- マウントポイント: 別のファイルシステムやデバイスを既存のディレクトリに結合する箇所（Unix系で多用）。
OSごとの典型的なディレクトリ構造
代表的にはUnix/Linux系とWindows系で慣習が異なります。
- Unix/Linux（FHS: Filesystem Hierarchy Standard）:
主要なディレクトリは以下のようになります。
- / (root) — システム全体のルート
- /bin — 基本コマンド（シェルなど）
- /sbin — 管理者用コマンド
- /usr — アプリケーションやライブラリ（/usr/bin, /usr/libなど）
- /etc — 設定ファイル
- /var — 可変データ（ログ /var/log、メール /var/mailなど）
- /home — ユーザーごとのホームディレクトリ
- /tmp — 一時ファイル
- /dev, /proc, /sys — デバイスや仮想ファイルシステム
FHSは長年の慣習と標準化の結果であり、ディストリビューション間で互換性を保つために重要です。
- Windows:
代表的なディレクトリは以下です。
- C:\ — ドライブルート
- C:\Windows — OS本体
- C:\Program Files, C:\Program Files (x86) — インストールされたプログラム
- C:\Users\<ユーザー名> — ユーザーのプロファイルとドキュメント
- C:\ProgramData — 全ユーザー共通のアプリデータ
Windowsはデフォルトでファイル名を大文字小文字区別しない（case-insensitive）点や、従来のパス長制限（MAX_PATH）のような特徴があります（近年は拡張可能）。
パスの種類と表記の違い
- 絶対パス: ルートから始まるパス。例：/etc/passwd（Unix系）、C:\Windows\system32（Windows）。
- 相対パス: 現在のディレクトリからの相対位置。例：./config/settings.json または ../images/logo.png。
- パス区切り: Unix系は「/」、Windowsは「\」が標準。URLでは常に「/」。
- 正規化（canonicalization）: 「../」や「./」を解決して一意の絶対パスに変換する処理。セキュリティでも重要（後述）。
Web/サーバ環境におけるディレクトリ構造の実務例
WebサーバやCMS（例：WordPress）では、ディレクトリ構造の適切な設計が機能性とセキュリティに直結します。
- ドキュメントルート（DocumentRoot）:
Web公開用のルート。Apacheなら /var/www/html、nginxなら設定次第で任意のディレクトリ。サーバはこの下にあるファイルのみを公開する。ドキュメントルート外に機密データや設定ファイルを置けば直接アクセスを防げる。
- WordPress の典型構造:
- wp-admin/ — 管理画面関連ファイル
- wp-includes/ — コア機能のライブラリ
- wp-content/ — ユーザー固有（テーマ、プラグイン、アップロード）
- wp-config.php — 設定ファイル（DB接続情報を含むため保護が必須）
wp-config.php は通常ドキュメントルートの外または適切にアクセス制限して保護します。また、wp-content/uploads のファイルアップロードはパーミッションとファイル種を制限すべきです。
ディレクトリ設計のベストプラクティス（開発・運用向け）
- 一貫性を保つ: 命名規則（スネークケース、ケバブケースなど）と階層のルールをチームで決め、文書化する。
- 深さと幅のバランス: 階層が深すぎるとパスが長くなり管理が難しくなる。逆に幅が広すぎると検索が複雑に。適切な分類で2〜5階層程度に収めることが多い。
- 機密情報は公開領域から隔離: 設定ファイルやバックアップはWeb公開領域の外に置くか、サーバ設定でアクセス禁止にする。
- パーミッション管理: 最小権限の原則を適用（例：Webサーバが書き込みするディレクトリのみ書き込み許可を与える）。
- バージョン管理の取り扱い: ソースはGit等で管理し、不要なアーティファクト（node_modulesやビルド成果物）は.gitignoreで除外する。
- 可搬性を考慮: スクリプトや設定ファイルでは絶対パスに依存しすぎない設計（環境変数や設定ファイルでパスを切り替え）。
セキュリティ上の注意点
- パストラバーサル攻撃: 入力されたパスに ../ を含めてサーバ内の想定外ファイルにアクセスさせる攻撃。ユーザー入力でファイルを開く場合は正規化とホワイトリスト検証を必ず行う（参考: OWASP）。
- ディレクトリリスティングの無効化: サーバ設定でディレクトリリスト表示（Indexing）を無効にする。公開したくないファイル構造が見えてしまう危険がある。
- 機密ファイルの配置: 設定ファイルや秘密鍵は公開ドキュメントルートの外に置くか、サーバでアクセス制御を行う。
- .git ディレクトリの露出防止: リポジトリの .git ディレクトリが公開されると履歴から機密が漏れる恐れがある。公開環境では除外またはアクセス禁止にする。
ツールとコマンド（運用で便利な操作）
- mkdir -p: 深い階層を一括作成する
- ls -la, tree: ディレクトリ一覧表示（tree はツリー形式）
- find: 指定条件でファイル／ディレクトリを検索
- du -sh: ディスク使用量を確認
- chmod/chown: パーミッションと所有者を設定
- rsync, tar, zip: バックアップや配布用のパッケージング
プロジェクト構成の具体例（Webアプリ）
小規模Webアプリの例（概念的）:
- project/
- app/ — アプリケーションコード（MVCの各層）
- public/ — ドキュメントルート（index.php, assets/）
- config/ — 環境ごとの設定（prod、staging）
- logs/ — ログ（外部公開不可）
- storage/ — アップロードやキャッシュ（権限管理）
- vendor/ — サードパーティ依存（Composer等）
ポイントは「公開するもの（public）」と「公開しないもの（config, logs, storage）」を明確に分けることです。
ファイル名と文字コード、長さの注意
- OSによりファイル名の扱いが異なる（大文字小文字の区別、使用禁止文字）。例：Windowsでは「\ / : * ? " < > |」はファイル名に使用不可。
- 予約語: Windowsには CON, PRN, AUX, NUL, COM1..COM9, LPT1..LPT9 などの予約名があります。
- ファイル名の長さ制限に注意（例：NTFSは理論上長いが、アプリや互換性で制限がある、従来の MAX_PATH = 260 など）。
- 国際文字（UTF-8等）は扱えるが、環境によって表示や操作で問題が出ることがあるため、システムファイル等はASCIIベースで統一するのが無難。
まとめ — 運用で意識すべきこと
ディレクトリ構造は単なる整理術ではなく、可用性・保守性・セキュリティに直結します。OSや用途に応じた標準（FHSなど）に従うこと、公開領域と非公開領域を明確に分けること、命名・階層の一貫性を保つことが重要です。さらに、権限設定や入力パスの正規化などセキュリティ対策も必ず実施してください。
参考文献
- Filesystem Hierarchy Standard (FHS) 3.0 — Linux Foundation
- Naming Files, Paths, and Namespaces — Microsoft Docs
- Path Traversal — OWASP
- WordPress Files — WordPress.org
- GNU Coreutils — manual (ls, mkdir, etc.)
投稿者プロフィール
