PythonでWebアプリを作ってみたいと思ったとき、最初に名前を聞くのはたいていFlaskかDjangoではないでしょうか。求人票にも、この2つはよく並んで載っています。
ただ、Djangoのほうは調べ始めると急に言葉が難しくなります。MTV、ORM、マイグレーション。そのあたりで手が止まってしまった方も多いはずです。
実のところ、Djangoが分かりにくいのは機能が多いからです。裏を返せば、それだけ自分で用意するものが少なくて済みます。
この記事では、Djangoがどんな道具なのかを、実際に動かす手順と一緒に順番にほどいていきます。
Djangoは、必要なものが最初から揃っているフレームワーク¶
まずは立ち位置から整理しましょう。DjangoはPython製のWebフレームワークで、2005年に公開されてから20年以上にわたって使われ続けています。
いちばんの特徴は、Webアプリに必要な部品がはじめから同梱されている点です。データベースを扱う仕組み、ログイン機能、管理画面、入力内容の検証まで、追加のライブラリなしで揃っています。
この考え方は、電池付きと表現されることがあります。買ってきた玩具に乾電池まで入っている、あの状態を思い浮かべてもらうと近いです。
対してFlaskは、必要最小限だけを持つ設計です。土台だけを渡されて、あとは自分で選んで足していくスタイルになります。
Flask側の考え方をまだ見ていない方は、先にこちらを読んでおくと違いがくっきりします。【関連記事】PythonのFlaskとは？WebアプリをPythonで動かす仕組みを初心者向けに解説
どちらが優れているという話ではありません。作りたいものの大きさで、選ぶ道具は変わります。
最初のプロジェクトを動かすまで¶
説明を読むより、画面が出たほうが早いはずです。ここから手順を追っていきます。
インストールとPythonのバージョン¶
Djangoは標準ライブラリではないので、pipで入れるところから始めます。プロジェクト専用の仮想環境を作ってから入れるのが安全です。
python -m venv venv
source venv/bin/activate
pip install Django
仮想環境という言葉がまだ曖昧なら、先にここを押さえておくと事故が減ります。【関連記事】Pythonの仮想環境（venv）って何のためにある？プロジェクトごとに混ぜない管理法
執筆時点の最新版は6.1です。動かすにはPython 3.12以降が必要で、3.14まで対応が明示されています。
古いPythonのまま入れようとすると、ここで弾かれます。入らないときは、まず自分のPythonのバージョンを確かめてみてください。
startproject と runserver¶
入ったら、プロジェクトを作ります。Djangoには、最初の一式をまとめて用意してくれるコマンドがあります。
django-admin startproject mysite
cd mysite
python manage.py runserver
ここまで打つと、開発用のサーバーが立ち上がります。ブラウザで http://127.0.0.1:8000/ を開くと、インストールがうまくいったことを知らせるお祝いのページが出てくるはずです。
この時点では、まだ自分では何も作っていません。それでもWebアプリとしては動いていて、ここから中身を足していく形になります。
MTVという、Djangoの部品の分け方¶
Djangoの解説で必ず出てくるのがMTVという言葉です。これは、どのコードをどこに書くかを決めた住所のようなものだと考えてください。
3つの頭文字が何を指すのかを、表にまとめます。
| 記号 | 名前 | 担当する仕事 |
|---|---|---|
| M | Model | データの形と、データベースとのやりとり |
| T | Template | 画面に表示するHTMLの見た目 |
| V | View | 受け取った要求を処理して、返すものを決める |
一般にMVCと呼ばれる考え方と、中身はほぼ同じです。ただDjangoでは、MVCのViewにあたるものをTemplateと呼び、ControllerにあたるものをViewと呼びます。
名前がずれているので、他の言語から来た方ほど混乱しやすいところです。最初はMVCと比べず、Djangoの中の言葉だけで覚えたほうが早く馴染みます。
モデルとマイグレーションで、データベースを扱う¶
Djangoを選ぶ理由の半分は、ここにあると言っていいでしょう。データベースの操作を、SQLを書かずにPythonのまま進められます。
モデルはPythonのクラスで書く¶
保存したいデータの形は、クラスとして書きます。ブログ記事を保存するなら、こんな具合です。
from django.db import models
class Post(models.Model):
title = models.CharField(max_length=200)
body = models.TextField()
published_at = models.DateTimeField(auto_now_add=True)
def __str__(self):
return self.title
このクラスが、そのままデータベースの表になります。表を作るためのSQLは、こちらで書く必要がありません。
こうしてPythonのクラスと表を結びつける仕組みを、ORMと呼びます。取り出すときも Post.objects.filter(title__contains="Python") のように、Pythonの書き方のまま検索できるのが利点です。
makemigrations と migrate¶
モデルを書いただけでは、まだ表はできていません。2つのコマンドを順に打って、はじめて反映されます。
python manage.py makemigrations
python manage.py migrate
前者は設計図を作るコマンドで、後者はその設計図を実際のデータベースに当てるコマンドです。設計図がファイルとして残るので、チーム全員が同じ形を再現できます。
マイグレーションという言葉自体に馴染みがなければ、こちらで基本を押さえておくと理解が早くなります。【関連記事】マイグレーションってどういう意味？flask db migrateで使う時に理解できるように解説
私の失敗も書いておきます。以前、作ったマイグレーションのファイルをGitに入れ忘れたままリリースし、本番だけ表の形が古いという状態を作ってしまいました。
原因にたどり着くまで半日かかりました。マイグレーションのファイルはコードと同じくらい大事、これは痛い目を見てようやく体に入った教訓です。
ビューとテンプレートで、画面を作る¶
データを入れる箱ができたら、次は見せる側です。ここでMTVのVとTが登場します。
ビューは、要求を受け取って返すものを決める関数です。さきほどのモデルから記事を取り出して、テンプレートに渡すところまでを書きます。
from django.shortcuts import render
from .models import Post
def post_list(request):
posts = Post.objects.order_by("-published_at")
return render(request, "post_list.html", {"posts": posts})
渡した posts は、テンプレート側で受け取って並べます。HTMLの中に専用の記法を混ぜて書く形です。
最後に、どのURLでこのビューを呼ぶかを urls.py に登録します。この3点セットが揃って、はじめて画面が表示されます。
管理画面が、Djangoのいちばんの魅力¶
ここがFlaskとの差がもっともはっきり出るところです。Djangoには、データを追加したり編集したりできる管理画面が最初から付いてきます。
使うには、作ったモデルを登録するだけです。
from django.contrib import admin
from .models import Post
admin.site.register(Post)
あとは python manage.py createsuperuser で管理者を作り、/admin/ を開けば画面が出ます。一覧、検索、追加、削除まで、画面のコードを1行も書かずに使えます。
社内向けの小さなツールなら、これだけで完成してしまうこともあります。管理画面がほしいならDjango、この一点で選ぶ現場は珍しくありません。
ただし、便利さには裏側もあります。私は以前、社内用だからと管理画面を外から見える場所に置いたままにして、ヒヤリとしたことがありました。
入口が分かりやすいということは、狙う側にとっても分かりやすいということです。公開する場所とURLの扱いは、設計の段階で決めておくべきでした。
FlaskやFastAPIと、どう使い分けるか¶
3つとも人気があるので、迷って当然です。ざっくりした選び方を表にまとめます。
| フレームワーク | 得意なこと | 向いている場面 |
|---|---|---|
| Django | 画面もDBも管理画面もまとめて面倒を見る | 会員機能やデータ管理が必要なWebサービス |
| Flask | 小さく始めて、必要なものだけ足す | 小規模なアプリ、学習、既存への追加 |
| FastAPI | 型ヒントを土台にしたAPIづくり | 他のプログラムから呼ばれるAPI |
判断の軸はひとつです。作るものに、ログインやデータ管理の画面が必要かどうかを考えてみてください。
必要ならDjangoが早く、いらないならFlaskのほうが身軽です。JSONを返すだけならFastAPIが素直で、その違いはこちらで詳しく書いています。【関連記事】PythonのFastAPIとは？型ヒントだけで動くWeb APIの作り方をFlaskと比べながら初心者向けに解説
バージョンの選び方と、これからのDjango¶
Djangoには、長く使えるLTSという区分があります。長期サポートの略で、新機能より安定を優先したい場面で選ばれるものです。
執筆時点では5.2がLTSにあたり、セキュリティ修正が2028年4月まで続く予定になっています。仕事で長く動かすものなら、最新版より先にこちらを検討する価値があります。
新しく学ぶだけなら、最新の6.1で構いません。書き方の基本は、バージョンが上がってもそこまで変わらないからです。
もうひとつ、2026年8月に大きな方針が発表されました。2028年からは年1回のリリースに変わり、すべての機能リリースが3年のサポートを持つ形になります。
バージョン番号も年をそのまま使い、Django 2028、Django 2029と続いていく予定です。ただし2028年までは、いまの仕組みのまま進みます。
初学者がつまずきやすいところ¶
最後に、よく引っかかる点を3つ挙げておきます。どれも、知っていれば数分で抜けられるものばかりです。
ひとつ目は、プロジェクトとアプリの違いです。プロジェクトは全体の入れ物で、アプリはその中にある機能のかたまりを指します。
startproject で入れ物を作り、startapp で機能を足していく。この関係を掴むまでは、どのファイルを触ればいいのか迷いやすいところです。
ふたつ目は、作ったアプリを設定に登録し忘れることです。settings.py の INSTALLED_APPS に名前を追加しないと、モデルもテンプレートも認識されません。
みっつ目は、runserver を本番でもそのまま使ってしまうことです。あれは開発中に手元で試すためのもので、公開するときは別の仕組みに載せ替える前提になっています。
サーバーまわりの言葉が曖昧なままだと、この判断はできません。土台を固めておくと、公開の手前で迷わなくなります。【関連記事】そもそもサーバーって何？Pythonアプリを公開する前に知りたい基礎知識
まとめ¶
Djangoは、Webアプリに必要な部品が最初から揃っているフレームワークです。自分で選んで組み合わせる手間が、大きく減ります。
覚える順番も決まっています。モデルでデータの形を決め、マイグレーションで反映し、ビューとテンプレートで画面を作る。この流れさえ掴めば、あとは応用の繰り返しです。
Flaskと迷ったら、管理画面やログインが必要かどうかで考えてみてください。必要ならDjangoを選んだほうが、確実に近道になります。
まずは startproject と runserver を打って、あのお祝いのページを出すところまで試してみましょう。動く画面をひとつ持てると、学習の景色は思ったより大きく変わります。
ここまでお読みいただきありがとうございました。
