Techarm Blog【Django構造解説】プロジェクトとアプリの違い・フォルダ構成を図解で理解する
はじめに：Django の構造を理解しよう
前回は開発環境を整え、最初の Django プロジェクトを作成しました。ロケットが飛んでいる画面を見たときの感動、覚えていますか？
今回は、作成されたファイルやフォルダの意味を詳しく見ていきます。
「なぜこんなにファイルがあるの？」「それぞれ何をするファイル？」という疑問を、一つずつ解決していきましょう。
初めてこの記事を読む方へ：
この記事は連載の第3回目です。環境構築がまだの方は、第2回の記事をご覧ください。もしすぐにプロジェクト構造を学びたい方は、前回GitHubコードを参考にしながら進めることもできます。
この記事で学べること
- Django の「プロジェクト」と「アプリケーション」の違い
- 作成されたファイル構造の意味
- 各ファイルの役割と重要度
- リクエストがどのように処理されるか
- 実際にアプリケーションを作成する方法
それでは、Django の世界を探検していきましょう！
現在のファイル構造を確認
前回の最後に VSCode でプロジェクトを開きましたね。今後は、すべての作業を VSCode で行いましょう！
▶VSCode でファイル構造を確認
VSCode の左側にある「エクスプローラー」を見てください。前回作成した mysite プロジェクトの構造が表示されているはずです。
もし表示されていない場合は、左上のフォルダアイコンをクリックしてみましょう。
▶VSCode でターミナルを開く
これからコマンドを実行するときは、VSCode の内蔵ターミナルを使います。
ターミナルの開き方
- メニューから「ターミナル」→「新しいターミナル」を選択
- または、ショートカットキー：
Ctrl + Shift + `（バッククォート）
重要：Windows ユーザーは Cmd（コマンドプロンプト）に変更
VSCode のターミナルは、デフォルトで PowerShell が開きます。でも、PowerShell だと仮想環境の (venv) が表示されないことがあるので、コマンドプロンプトに変更してみましょう。
- ターミナルの右上にある「＋」の横の「∨」をクリック
- 「既定のプロファイルの選択」をクリック
- 「Command Prompt」を選択
- 現在のターミナルを閉じて（ゴミ箱アイコン）、新しくターミナルを開き直す
これで、仮想環境が有効な状態で (venv)が表示されるようになります！
(venv) C:\Users\techarm\Desktop\django_study\mysite>VSCode のターミナルを使うメリット：
- ファイルを見ながらコマンドを実行できる
- 複数のターミナルを開いて切り替えられる
- エラーが出たときにファイルをすぐ修正できる
- コマンドプロンプトを別で開く必要がない
これからは、すべて VSCode で完結できます！
前回作成した mysite プロジェクトの中身を見てみましょう。
コマンドプロンプトで以下のコマンドを実行：
こんな構造が表示されるはずです：
mysite/ # プロジェクトのルートディレクトリ
├── manage.py # 管理コマンド実行用スクリプト
└── mysite/ # プロジェクト設定ディレクトリ
├── __init__.py # Pythonパッケージとして認識させるファイル
├── settings.py # プロジェクトの設定ファイル
├── urls.py # URLパターンの定義
├── asgi.py # 非同期サーバー用の設定
└── wsgi.py # 本番サーバー用の設定最初は「なんだかファイルが多いな...」と感じるかもしれません。僕も最初はそうでした。でも、それぞれに明確な役割があるんです。
プロジェクトとアプリケーションの違い
Django には「プロジェクト」と「アプリケーション」という 2 つの重要な概念があります。
▶プロジェクトとは？
プロジェクトは、Web サイト全体の設定や構成を管理する単位です。
例えば「EC サイト」を作る場合：
- プロジェクト名：
myshop - データベース設定、セキュリティ設定、インストールするアプリの管理など、サイト全体に関わる設定を担当
▶アプリケーションとは？
アプリケーションは、特定の機能を持つ部品（モジュール）です。
同じ「EC サイト」の例では：
- 商品管理アプリ：
products（商品の登録・編集・削除） - カート機能アプリ：
cart（カートに入れる・決済） - ユーザー管理アプリ：
accounts（ログイン・会員登録） - ブログ機能アプリ：
blog（お知らせやコラム）
つまり、プロジェクトは「家」で、アプリケーションは「部屋」みたいなものです。家（プロジェクト）の中に、リビング、キッチン、寝室（アプリケーション）があるイメージです。
1 つのプロジェクトには複数のアプリケーションを含めることができます。アプリケーションは再利用可能で、他のプロジェクトでも使えるように設計することが推奨されています。
各ファイルの役割を詳しく解説
それでは、各ファイルの役割を見ていきましょう。
▶manage.py - 司令塔
manage.py は、Django プロジェクトを操作するための管理スクリプトです。
「えっ、またコマンド覚えるの？」と思うかもしれませんが、大丈夫！最初は 2〜3 個覚えれば十分です。
よく使うコマンド（これだけ覚えれば OK！）
開発サーバーの起動
これは前回も使いましたね！ローカルで Web サイトを確認するためのコマンドです。
python manage.py runserverアプリケーションの作成
新しい機能（アプリ）を追加するときに使います。今回も blog アプリを作るときに使いますよ。
python manage.py startapp アプリ名もう少し慣れたら使うコマンド
データベースの設計図を作成
python manage.py makemigrationsモデル（データ構造）を変更したら、まずこのコマンドで「設計図」を作ります。
データベースに反映
作成した設計図を実際のデータベースに反映します。makemigrations → migrate の順番が大切！
python manage.py migrate管理者ユーザーの作成
管理画面にログインするための特別なユーザーを作成します。
python manage.py createsuperuserコマンドが多くて混乱しそう？大丈夫です！
- 最初は
runserverとstartappだけ覚えれば OK - 他のコマンドは必要になったときに都度確認すれば大丈夫
- 僕も最初は「migrate」と「makemigrations」の順番をよく間違えていました（笑）
このファイルは基本的に編集する必要はありません。コマンドを実行するときに使うだけです。
▶settings.py - 設定の中枢
settings.py は、プロジェクト全体の設定を管理する最も重要なファイルの一つです。
実際に VSCode で開いて見てみましょう：
重要な設定項目
# デバッグモード（開発時はTrue、本番環境では必ずFalse）
DEBUG = True
# アクセスを許可するホスト
ALLOWED_HOSTS = []
# インストール済みアプリケーション
INSTALLED_APPS = [
'django.contrib.admin', # 管理サイト
'django.contrib.auth', # 認証システム
'django.contrib.contenttypes',
'django.contrib.sessions', # セッション管理
'django.contrib.messages', # メッセージフレームワーク
'django.contrib.staticfiles', # 静的ファイル管理
]
# データベース設定（デフォルトはSQLite）
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': BASE_DIR / 'db.sqlite3',
}
}▶urls.py - URL のルーター
urls.py は、URL とビュー（処理）を結びつける役割を持ちます。
from django.contrib import admin
from django.urls import path
urlpatterns = [
path('admin/', admin.site.urls), # 管理サイトへのURL
]現在は管理サイト（/admin/）へのルートだけが定義されています。
「なるほど、http://127.0.0.1:8000/admin/にアクセスすると管理サイトが表示されるのか！」と思った方、その通りです！
▶init.py - Python パッケージの印
このファイルは空ですが、重要な役割があります。Python に「このディレクトリはパッケージです」と認識させるためのファイルです。
削除しないでくださいね！
▶wsgi.py と asgi.py - 本番環境用の設定
- wsgi.py: Web Server Gateway Interface の設定（通常の Web アプリ用）
- asgi.py: Asynchronous Server Gateway Interface の設定（非同期処理用）
開発中はこれらのファイルを編集する必要はありません。本番環境にデプロイするときに使います。
リクエスト処理の流れ
ブラウザからリクエストが来たときの処理の流れを理解してみましょう。
開発サーバーを起動し、実際に管理サイトにアクセスしてみましょう。
ブラウザで http://localhost:8000/admin/ にアクセスすると...
ログイン画面が表示されました！（まだユーザーを作っていないのでログインはできません）
確認できたら、ターミナルで Ctrl + C を押してサーバーを停止してみましょう。これで次のコマンドが入力できるようになります。
開発サーバーの基本操作：
- 起動：
python manage.py runserver - 停止：
Ctrl + C - サーバー実行中は、そのターミナルで新しいコマンドは入力できません
- 複数のコマンドを同時に実行したい場合は、VSCode で新しいターミナルを開くこともできます（ターミナルの「＋」ボタン）
実際にアプリケーションを作ってみよう
プロジェクトの構造を理解したところで、実際にアプリケーションを作成してみましょう。
▶practice アプリケーションの作成
まずは、Djangoの基本を学ぶための練習用アプリを作ります。
サーバーが起動中の場合は、ターミナルで Ctrl + C を押して停止してみましょう。
なぜpracticeアプリから始めるの？
practiceアプリは、Djangoの基本機能を学ぶための練習用です。ここで：
- Hello Worldの表示
- 時刻の表示
- テンプレートの使い方 などの基礎を学びます。
実際のブログ機能は、基礎を学んだ後でblogアプリとして作成します。こうすることで、練習コードと本番のコードが混ざらず、学習がスムーズに進みます。
▶作成されるファイル構造
新しく practice フォルダが作成されます。中身を見てみましょう：
practice/
├── __init__.py
├── admin.py # 管理サイトの設定
├── apps.py # アプリケーションの設定
├── migrations/ # データベース変更履歴
│ └── __init__.py
├── models.py # データモデル定義
├── tests.py # テストコード
└── views.py # ビュー（処理）定義▶各ファイルの簡単な説明
- models.py: データベースのテーブル構造を定義
- views.py: URL に対する処理を記述
- admin.py: 管理サイトでの表示方法を定義
- tests.py: テストコードを記述
- apps.py: アプリケーションの設定
- migrations/: データベースの変更履歴を管理
「また新しいファイルが増えた...」と思うかもしれませんが、最初は models.py と views.py だけ理解していれば大丈夫です！
アプリケーションをプロジェクトに登録
作成したアプリケーションを使うには、settings.py に登録する必要があります。
mysite/settings.py を開いて、INSTALLED_APPS に追加します：
INSTALLED_APPS = [
"django.contrib.admin",
"django.contrib.auth",
"django.contrib.contenttypes",
"django.contrib.sessions",
"django.contrib.messages",
"django.contrib.staticfiles",
"practice", # ← 追加
]アプリケーションを作成したら、必ず settings.py の INSTALLED_APPS に追加することを忘れないでください！これを忘れると、Django がアプリケーションを認識してくれません。
プロジェクト構造のベストプラクティス
▶推奨されるディレクトリ構成
プロジェクトが大きくなってくると、以下のような構成にすることが多いです：
mysite/
├── manage.py
├── mysite/
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ ├── wsgi.py
│ └── asgi.py
├── practice/ # 練習用アプリケーション
├── blog/ # ブログアプリケーション（後で作成）
├── accounts/ # ユーザー管理アプリケーション（必要に応じて）
├── static/ # CSS、JavaScript、画像など
├── media/ # ユーザーがアップロードしたファイル
├── templates/ # 共通テンプレート
└── requirements.txt # 必要なパッケージ一覧今回はpracticeアプリのみ作成しました。blogアプリは、基礎を学んだ後の次回以降で作成します。
▶アプリケーション分割の目安
アプリケーションを分ける基準：
- 機能の独立性: 他の機能に依存しない
- 再利用性: 他のプロジェクトでも使える
- 責任の明確化: 1 つのアプリ = 1 つの責任
例：ブログサイトの場合
blog: 記事の投稿・表示comments: コメント機能accounts: ユーザー管理analytics: アクセス解析
僕の経験では、「迷ったら分ける」くらいがちょうどいいです。後から統合するより、分割する方が大変ですから。
開発サーバーで確認
設定を変更したら、開発サーバーを起動して確認してみましょう。
エラーが出なければ成功です！
もし以下のようなメッセージが表示されても大丈夫：
You have 18 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.これはデータベースの設定がまだ完了していないという意味です。次回以降で対応します。
よくある質問
▶Q1: プロジェクト名とアプリケーション名は同じでもいい？
A: 技術的には可能ですが、混乱を避けるため異なる名前にすることを推奨します。例えば、プロジェクト名が blog の場合、アプリケーション名は posts や articles にするなど。
▶Q2: アプリケーションはいくつまで作れる？
A: 制限はありませんが、管理しやすい範囲（10 個程度まで）に収めることをお勧めします。あまり多すぎると、どこに何があるか分からなくなってしまいます。
▶Q3: settings.py の設定を間違えたらどうなる？
A: エラーメッセージが表示されます。エラーメッセージをよく読んで、該当箇所を修正してみましょう。最悪の場合は、バックアップから復元するか、新しくプロジェクトを作り直せば大丈夫です。
まとめ
今回は、Django のプロジェクト構造について学びました：
- プロジェクトは全体の設定、アプリケーションは個別の機能
settings.pyで全体の設定を管理urls.pyで URL とビューを結びつけるmanage.pyでプロジェクトを操作- アプリケーションは
startappコマンドで作成
ファイル構造を理解することで、どこに何を書けばいいかが明確になりました。
最初は覚えることが多く感じるかもしれませんが、実際にコードを書いていくうちに自然と身につきます。僕も最初は「どのファイルに何を書けばいいの？」と迷いましたが、今では迷わず書けるようになりました。
完成したコード
もし実行でエラーが出たり、不明な点がある場合は、以下の完成後のコードと比較してみてください：
https://github.com/techarm/django-blog-tutorial/tree/03-project-structure
特にsettings.pyのINSTALLED_APPSの設定や、ファイル構成を確認することで、問題を解決できるでしょう。
次回予告
次回は、いよいよコードを書いて、ブラウザに文字を表示します。URL とビューの関係を実践的に学んでいきましょう！
「Hello Django!」を表示させる感動を、一緒に味わいましょう。
この記事はいかがでしたか？
もしこの記事が参考になりましたら、
高評価をいただけると大変嬉しいです！
皆様からの応援が励みになります。ありがとうございます！ ✨