Django レビュー：まだ使う価値はあるか、それとも FastAPI の勝ちか

Django は 2025 年 12 月から 2026 年 8 月までの 8 か月間に、フィーチャーリリースを 2 回出し、リリースサイクル全体を書き換えた。

それが起きたのは、2023 年以来ほとんど評判の変わっていないフレームワークだ。必要なものがひと通り揃い、生産性が高く、方針がはっきりしていて、同期専用で、FastAPI に押されている Python フレームワーク、という評判である。同期専用というレッテルはもう古く、人気をめぐる話も見出しの数字が示すより複雑だ。

というわけで、6.1 の時点で Django に価値があるかどうかについての私の結論はこうだ。評点つきの判断、向いているプロジェクトの形、そして今は FastAPI のほうが適している形である。

短いバージョン

条件つきでイエスだ。管理画面、認証、フォーム、ORM が仕事の大半を占めるなら、Django 6.1 は今も最も堅い既定の選択肢であり、非同期の差も「同期専用だから」という理由で外すほどではなくなった。管理画面を持たない単一の高並行 API には向かない。 5 段階で 4。

買っているのは一式そのものだ。 ORM、マイグレーション、権限つきのセッション認証、フォーム層、そして自動生成される管理画面が、すでにかみ合った状態でまとめて手に入る。五つのライブラリとその継ぎ目、という形ではない。
バックグラウンド処理が弱い軸だ。 Django 6.0 の Tasks フレームワークはデコレータとキュー投入の呼び出しは用意するが、worker は用意しない。だから Celery なりその同等品なりは、依然として自分で決める話だ。
非同期はかなり良くなったが、明らかに未完成だ。 Django は非同期ビューと非同期の ORM 呼び出しをサポートするが、トランザクションは非同期モードでは動かない。WSGI の下でも非同期ビューは 1 リクエスト内で並行した非同期 I/O を実行できるものの、完全な非同期リクエストスタックの恩恵は得られない。長時間かかるリクエストや高い接続並行性には ASGI が要る。
2027 年より先の計画が立てやすくなった。 2028 年 1 月から、Django はフィーチャーリリースを年 1 回出し、それぞれに 3 年のサポートがつく。すべてのリリースがその約束を得るため、「LTS」というラベルはなくなる。
管理画面と CRUD が中心の製品、そして小さなチームには向いている。 管理画面もフォームもない単一の高スループット API やストリーミング API には向かない。そこでは FastAPI のほうが自然な選択だ。

このレビューの作り方： 本稿は Django 6.1 の評価であり、プロジェクト自身のリリースノートとドキュメント、Django Software Foundation による 2026 年 8 月のガバナンス発表、2024 年の JetBrains/PSF 開発者調査と 2025 年の Django 開発者調査、そして自らの本番運用経験を公に書いている実名の実務者を根拠としている。この記事のために数週間の本番試用は行っておらず、ベンチマークも一切ない。負荷試験はしていない。Django は無料で BSD ライセンスであり、私はこのプロジェクトと何の関係もない。

2025 年以降、Django で実際に何が変わったのか

Django のリリースとサポート期間のタイムライン。Django 5.2 LTS は 2028 年 4 月までサポート、Django 6.0 は 2025 年 12 月 3 日に Tasks フレームワークとともに登場、Django 6.1 は 2026 年 8 月 5 日でメインストリームサポートは 2027 年 4 月まで・延長サポートは 2027 年 12 月まで、Django 6.2 LTS は 2027 年 4 月で延長サポートは 2030 年 4 月まで、そして 2028 年 1 月からは年 1 回のフィーチャーリリースに 3 年のサポートがつき、LTS ラベルは廃止

Django 6.0 は 2025 年 12 月 3 日に、公式の Tasks フレームワークとコアへのその他の追加を携えて登場した。非同期 ORM インターフェースはもっと前からある。Django 4.1 が 2022 年に非同期の QuerySet 操作を導入していた。Django 6.1 は 2026 年 8 月 5 日に現行の安定版となった。そして 2026 年 8 月 10 日、プロジェクトは年 1 回のフィーチャーリリースを 2028 年 1 月から出すこと、各リリースに 3 年のサポートをつけること、そして LTS ラベルを廃止することを発表した。

6.1 のリリースノートによれば、6.1 は Python 3.12、3.13、3.14 に対応し、メインストリームサポートは 2027 年 4 月に、延長サポートは 2027 年 12 月に終了する。

それに合わせてバージョン番号も変わる。年号を持つようになり、Django 2028、続いて Django 2029 となる（少なくとも「いまどのバージョンか」には答えやすくなる）。3 年の内訳は、通常のバグ修正が 1 年、その後セキュリティとデータ損失の修正が 2 年だ。それはまさに以前 LTS が意味していたものなので、ラベルはなくなる。

そのせいで、いまから始めるプロジェクトには据わりの悪い期間が残る。Django 5.2 は現行の LTS で、2028 年 4 月までサポートされる。Django 6.1 は現行の安定版だが、その延長サポートは 2027 年 12 月に終わる。Django 5.2 のサポート期間が終わる 2028 年 4 月より 4 か月ほど早い。

つまり、最長のサポート期間を狙うなら 5.2 で始めることになる。Tasks フレームワークと 6.x の最新機能がほしいなら 6.1 で始め、より早い時期のアップグレードを受け入れることになる。どちらも間違いではないし、この据わりの悪い選択は 2027 年 4 月に Django 6.2 LTS が出れば消える。

私はこのサイクル変更を良い兆候と読む。衰退しているプロジェクトはサポートの約束をこっそり引き延ばすもので、日付入りの計画を公にして組み直したりはしない。これはすでに守っていた約束を整理しただけだ。

Django が今も何より得意なこと

Django 6.1 でプロジェクトを始めれば、機能を一つも書かないうちに、権限システムつきの動くセッション認証、検証とレンダリングをこなすフォーム層、モデルに結びついたマイグレーション、ORM、そして自動生成の管理画面が手に入る。それがこのフレームワークの売りのすべてであり、変わる必要のなかった部分でもある。

価値は、それらの部品が存在することではない。互いを見据えて設計されたことにある。同じモデル権限が管理画面を動かし、モデルを変えれば一息でマイグレーションが生成され、管理画面のフォームも更新される。

同等のカバー範囲を独立したライブラリから組み立てても、最終的にはたどり着ける。ただし継ぎ目ごとに恒久的な保守面も抱えることになり、バグが住みつくのはその継ぎ目だ。

管理画面は社内スタッフ向けのツールだ。管理画面のリファレンスによれば、その推奨用途は組織の内部管理ツールにとどまり、フロントエンド全体をその周りに構築するためのものではない。中に入ったスタッフが何をできるかはモデル権限が決め、そもそも中に入るために必要なのは is_staffだ。それを制約と捉えるなら、良い制約だ。まともな社内バックオフィスがただで手に入り、顧客向けの UI は手に入らないので、それを世に出そうと誘惑される人も出ない。

セキュリティの既定値は、同じ主張のもう半分だ。CSRF 対策、ORM 経由の SQL パラメータ化、テンプレートでの XSS エスケープ、クリックジャッキング対策は、いずれも既定で有効になっている。ベテラン開発者がレビューで忘れずに求めるべき事項ではないのだ。小さなチームは、10 年分のセキュリティ報告を読んできた人たちの判断をそのまま受け継ぐ。

次に年季の話がある。これは負債として読まれるが、私はエコシステムの論拠として読む。Django REST Framework は存在していて、インフラにこうあってほしいという意味で退屈だ。

4 か月目にぶつかる問題に対応する成熟したパッケージも同様だ。フィルタリング、スロットリング、ストレージバックエンド、マルチテナントのパターン、監査証跡。そして、どのパッケージも扱っていないほど珍しい問題なら、たいていそれについて 15 年前のメーリングリストのスレッドがある。幅という点で Python の中に近づけるものはないと思うし、そもそも人が Django を選ぶ理由はこの軸だ。

Django が足りていないところ

Django には今もフレームワーク全体を覆う公式の型付けがなく、慎重な歩みは「全部入り」という言葉が警告してくれない穴を残し、6.0 の Tasks フレームワークには worker がない。6.1 時点での欠けはこの三つだ。型の穴は毎日いらつかせるほうで、Tasks はアーキテクチャ図を書き換えるほうである。

型まわりの大半は、いまも外部ツールを寄せ集めて自分で組むことになる。 django-stubs は型スタブと、Django の動的な振る舞いに対応した専用の mypy プラグインを提供する。現在のドキュメントには mypy の完全対応と、pyright・pyrefly・ty の基本対応が挙げられている。以前より良い状況ではあるが、依然として別立ての互換レイヤーであって、Django 本体に備わった包括的な型付けではない。

型ヒントを軸に作られたフレームワークから来ると、これは日々のエディタ体験における明確な後退だ。

慎重な歩みは美点であると同時にコストでもある。Django は物事を注意深く、遅れて追加する。だからこそ 2019 年に学んだフレームワークを今日も読める。同じ理由で、電池は止まるところで止まる。コアに WebSocket 層はなく、スケジューラもなく、非同期タスクのオーケストレーションについての意見もない。その線を一つでも越えれば、また自分で組み立てることになる。

Django 6 に今も Celery は必要か

Celery でなければならないわけではない。Django 6.0 の Tasks フレームワークは、タスクの定義とキュー投入の仕方を標準化するが、キューに入った処理を自分で実行することはない。本番では、タスクを実行するバックエンドなり worker プロセスなりが依然として必要だ。Celery は選択肢の一つであって、フレームワークの要件ではない。 Django 6.0 のリリースノートはこの境界について率直だ。Django はタスクの作成とキュー投入は担うが worker の仕組みは提供せず、実行は別プロセスや別サービスといった外部インフラが管理しなければならない、と書かれている。

手に入るのはインターフェースだ。

from django.core.mail import send_mail
from django.tasks import task

@task
def email_users(emails, subject, message):
    return send_mail(subject, message, None, emails)

email_users.enqueue(...) は、設定済みのバックエンドにタスクを送る。6.0 に同梱される 2 つのバックエンドは開発とテスト向けだ（つまり、期待していたものではない）。スケジューリング、定期実行、リトライ、耐久性は、いずれも範囲外である。

現役の Django 開発者である Kevin Renskers が、これを最も鋭く言い当てた。出典は彼の Tasks レビュー:

その代わりに我々が手にしたのは、実装のない抽象だった。

形については彼が正しい。ただ、意図の捉え方は私なら違う。 DEP 14 に関する Steering Council の投票では、この機能の土台となった Django 拡張提案について、Simon Charette が「Celery や RQ のようなフレームワークが差し込んでくる先であるべきだ」と主張し、提案者自身もこれをランタイムではなくバックグラウンドワーカーのインターフェースだと説明していた。だから公平な批判は、Tasks が壊れているというものではない。「全部入り」が期待させたものよりずっと狭いということ、そして塞いだ穴が退屈なほうの穴だということだ。つまり、アプリのコードが特定のキューライブラリを import せずに仕事をキューへ入れられる、という点である。

だから、リトライや定期実行、失敗の可視化が要る Django 6.1 のプロジェクトには、タスクキューの予算を見込んでおくこと。6.0 より前と同じ項目のままであり、このリリースがそれをアーキテクチャ図から消してくれると期待していたなら、消えはしない。

Django が合うと既に決めていて、サーバー層をゼロから組み立てたくはないなら、 Cloudzy の Django VPS なら、Django、Gunicorn、Nginx、PostgreSQL を備えた自己管理型の出発点が手に入り、Redis や Celery が必要になったときのための root 権限もついてくる。運用するのは変わらず自分のサーバーだ。省けるのは真っさらな箱からのセットアップであって、運用責任ではない。

Django の非同期対応はもう十分か

「同期専用だから」という理由でもう足を止めなくてよい程度には十分で、その上に完全な非同期データ層を築けるほどには十分でない。6.1 では両方が同時に正しい。どちらが自分に当てはまるかは、何を作るのか、そしてそれを ASGI と WSGI のどちらで動かすのかで決まる。完全な非同期リクエストスタックと、長寿命の接続の効率的な扱いが得られるかどうかを決めるのは、その選択だからだ。

能力の面に議論の余地はない。SQL を発行する QuerySet のメソッドにはすべて、先頭に aが付いた非同期版がある。 async for は QuerySet 全般で使え、非同期のデータベース API にはモデルメソッドの asave() や、QuerySet メソッドの acreate()などが含まれる。クエリと、並行する外向きの HTTP 呼び出しを await する非同期ビューを、スレッドプールのラッパーなしで書ける。「同期専用」という批判が書かれた当時の Django と比べれば、これは別物のフレームワークだ。

挙動を決めるのはフレームワークのバージョンではなくデプロイのプロトコルであり、Django 自身のフォーラムが何度も説明し直すはめになっているのはまさにこの点だ。非同期のトピックガイドによれば、WSGI サーバーの下では非同期ビューはそれぞれ使い捨てのイベントループで動く。つまり非同期機能は使えるが、「非同期スタックの恩恵は得られない」。

Python のスレッドを使わずに数百の接続をさばくこと、遅いストリーミング、ロングポーリング。これらには ASGI が要る。同じコードでも並行性の挙動は変わり、いまどちらになっているのかをフレームワークは教えてくれない。

この混乱は寿命が長い。tomcypress という名で投稿したユーザーが立てたのが Django フォーラムのスレッドだ。非同期ビューへの連続したリクエストが、なぜ全部はバックグラウンド処理を走らせないのかを尋ねたもので、フォーラムの常連 KenWhitesell が WSGI のイベントループを指し示した。このやり取りは 2021 年のもので、6.1 になっても何一つ変わっていない。

しかもこの混乱は外側からも補強されている。TechVidvan の Django の長所と短所のページは、読者に Django は「複数のリクエストを同時に処理できない」と説明している。Django 6.1 についてこれは誤りであり、評価が始まる前に評価を終わらせてしまう類の主張だ。並行性はフレームワークに欠けているものではない。デプロイが決めるものだ。

決定的な行き止まりはトランザクションであり、 Django 自身の非同期ドキュメントがはっきりこう書いている。

トランザクションは非同期モードではまだ動作しません。トランザクションの振る舞いが必要なコードがある場合は、その部分を単一の同期関数として書き、次を使って呼び出すことを推奨します。 sync_to_async().

同じページはフレームワークの特定の重要部分を「非同期安全でない」と分類し、非同期コンテキストで実行されるのを止める。試みたときに送出されるのが SynchronousOnlyOperation だ。つまり Django 6.1 の非同期アプリケーションの形は、非同期ビューと非同期の読み取りに加えて、書き込みに原子性が要る箇所ごとに同期の島を置く、というものになる。実用にはなるが、生まれつき非同期のフレームワークと同じものではない。この軸についての私の評価は、はっきり良くなった、まだ完成していない、そして並行性を最優先にしないものなら明確に合格、である。

FastAPI は Django を誤った既定の選択にしたのか

「実際のところ何を作っているのか」を問う判断図。Django は、管理画面を中核に、認証と権限、フォーム、CRUD の多い製品を小さなチームで作る場合に向き、社内ツール、マーケットプレイス、バックオフィス SaaS、管理画面中心の製品を含む。一方 FastAPI は、型付きのリクエスト・レスポンスモデル、非同期優先のワークロード、ストリーミング、高い接続並行性を備え、管理画面もフォームも持たない API 専用サービスに向く。2024 年の Python 開発者調査のバーは、全回答者で FastAPI 38%、Django 35%、ウェブ開発が主の回答者で Django 61%、FastAPI 56% を示している

特定の、しかも増えつつある種類のプロジェクトについては、そうだ。 2024 年の Python 開発者調査は、JetBrains と Python Software Foundation によるもので、2024 年 10 月から 11 月にかけて 3 万人を超える参加者から集められ、全回答者では FastAPI が 38%、Django が 35%、Flask が 34% だった。Python を最も使う用途としてウェブ開発を選んだ回答者に限ると、Django が 61%、FastAPI が 56%、Flask が 39% である。

この設問は計画会議に持ち込む前によく見てほしい。複数選択だからだ。回答者が聞かれたのは「どのフレームワークを使っているか」であって「どれを選んだか」ではない。Django のモノリスを保守しながら FastAPI のサービスも書いている開発者は、両方に計上される。これらは排他的な市場シェアではないし、ここで市場の 38% を握っている者などいない。示しているのは分かれた信号だ。全回答者では FastAPI が Django を上回り、Python を主にウェブ開発に使う回答者では依然として Django が FastAPI を上回っていた。

Django に特化した調査は、すでにこのフレームワークを使っている人たちからの、もう一つの信号を加えてくれる。 2025 年の Django 開発者調査は、Django Software Foundation が JetBrains と共同で実施し、2024 年 11 月から 2025 年 1 月に集めた 4,655 件の絞り込み済み回答を対象としている。そこでは 82% が業務として Django を書き、77% が最もよく使うフレームワークとして挙げ、48% が安定版が出るたびにアップグレードしていた。1 年前の 40% からの上昇だ。回答者は自ら手を挙げた人たちなので、これは市場ではなく現在のユーザー層を描いている。利用の広さと関与の深さは別々の信号であり、Django の二つ目の数字は一つ目より健康だ。

FastAPI が勝つ場面は、調査の開きが示すよりも狭く、そして鋭い。型が主導する API 表面、つまり Pydantic のモデルが検証層で、生成された OpenAPI スキーマが契約になる形は、Django にシリアライザ層を足したものに勝る。FastAPI はリクエスト層では生まれつき非同期だが、その公式ドキュメントは、パスオペレーションはどちらの書き方でもよいと明記している。素の def で宣言されたハンドラや依存関係は、外部のスレッドプールで実行される。

そして、管理画面もフォームもテンプレートも持たないサービスは、Django の電池を死荷重として抱えることになる。フレームワークの見解に金を払い、その 4 分の 1 しか使わないわけだ。作っているのがそういうものなら、その勢いは誇大宣伝ではなく、乗るべきだ。

Django を選ぶべきなのは誰か

管理画面、認証、フォーム、ORM がこれからやる仕事の大半を占めるなら、6.1 の Django に手を伸ばすといい。社内ツール、マーケットプレイス、バックオフィス SaaS などだ。それらが初日から動いている必要のある小さなチームにも、2029 年のサポート期間がどうなっているかを今知っておく必要があるチームにも合っている。

フレームワークの見解が、実際の仕事の大半を覆ってくれる製品。 権限マトリクスがあり、ログインの向こう側に CRUD が大量にあるもの全般。ここではフレームワークが構造上の判断を下してくれることこそが要点であってコストではない。どのみちその判断が、自分で作るはずだったものの大半だからだ。

初日から生産的でなければならない小さなチーム。 開発者 3 人でプラットフォームエンジニアがいない状況なら、一方のチームは機能を書き始め、もう一方は認証ライブラリの選定を始める。その差はそこから複利で開いていく。

すでに Django を使っていて、これからの 3 年を計画しているチーム。 Django 5.2 は 2028 年 4 月まで支えられる床を与えてくれ、年次の刊行ペースはその後の見通せる床を与えてくれる。読み取れるサポートの滑走路は計画時には金銭的価値があり、これほど明快に手渡されるのは珍しい。

Django を選ぶべきでないのは誰か

背後に管理画面のない高スループット API やストリーミング API に Django を選ばないこと。その形の案件では FastAPI のほうがすっきりした既定の選択だ。トランザクションを含む非同期のデータアクセスが今年必要なら選ばないこと。6.1 にはない。そして、電池がバックグラウンドジョブを走らせてくれると期待して選ばないこと。

管理画面もフォームも持たない、単一の高スループット API またはストリーミング API。 この形の案件では、Django が得意なことのほとんどが荷重を受け持たない。つまり、ルーターとバリデータがあれば済むサービスのために、フレームワーク丸ごとの構造を保守することになる。

トランザクションを含めた完全な非同期データアクセスが今すぐ必要なチーム。 Django 6.1 は非同期モードでトランザクションをサポートしない。書き込みを sync_to_async() で包むのは正当なパターンであって、今年のうちに卒業できる回避策ではない。それが許容できない場面では、かすり傷ではなく行き止まりになる。

「全部入り」を、バックグラウンドジョブの実行まで含むものと読むチーム。 Tasks に worker は付いてこない。6.0 がスタックからキューを取り除いてくれた、という前提の計画だったなら、このフレームワークに賭ける前に計画へキューを戻す必要がある。

どのウェブフレームワークを最初に学ぶかは、別の答えを持つ別の問いだ。短い答えは下の FAQ にある。

Django がどこで止まるかを知っていることこそ、安心して始められる理由だ。ここまでに挙げた出口は、コミットしたあとに見つかるのではなく、コミットする前から見えている。

よくある質問

Django はもう終わったのか

終わっていない。Django は 2025 年 12 月から 2026 年 8 月のあいだにフィーチャーリリースを 2 回出し、2030 年代まで届く再構成されたリリース計画を公表した。FastAPI は速く成長し、2024 年の Python 開発者調査の全回答者では 38% 対 35% で Django を上回った。一方、Python を主にウェブ開発に使う回答者では Django が 61% 対 56% で上回っている。新しいフレームワークが急成長していることと、古いフレームワークが死んだこととは、別の主張だ。

Django は初心者に向いているか

向いている。ただし、一度に学ぶ量が最も多いという但し書きつきだ。Django を生産的にしているのはその幅の広さで、それはつまり、初心者が何かを世に出す前に ORM、マイグレーション、テンプレート層、管理画面にぶつかるということでもある。逆張りの意見も読む価値がある。 Bite Code! の記事は、初心者こそ Django から始めるべきだと論じている。理由はまさにその既定値にあり、最小限のフレームワークなら一人で犯すに任されるアーキテクチャ上の失敗を、それが防いでくれるからだ。

Django は Flask より速いのか

普遍的な答えはない。このレビューのためにベンチマークは実行していないし、ワークロードとデプロイの中身がわからないベンチマークは私なら信用しない。多くのアプリケーションでは、データベースのクエリ、N+1、外部 API 呼び出しのほうがフレームワークのオーバーヘッドより効いてくる。素のリクエストスループットが判断材料として重要なら、実際に動かすつもりのアプリケーションとサーバー構成を自分で計測すること。

新しいプロジェクトはどの Django バージョンで始めるべきか

サポート期間の長さが最重要なら 5.2 で始めるとよい。現行の LTS で、2028 年 4 月までサポートされる。Tasks フレームワークと 6.x の最新機能がほしいなら 6.1 で始め、メインストリームサポートがおよそ 2027 年 4 月まで、延長サポートが 2027 年 12 月までであることを受け入れたうえで、2027 年 4 月に出る Django 6.2 LTS へのアップグレードを計画しておく。Django 6.2 は延長サポートが 2030 年 4 月までの予定だ。2028 年 1 月以降は、毎年のフィーチャーリリースがそれぞれ 3 年のサポートを持つ。

Django と FastAPI、先に学ぶべきはどちらか

自分がやりたい仕事に合うほうを学べばいい。Django は、ウェブアプリケーション全体がどう組み合わさっているかを教えてくれる。データモデリング、マイグレーション、認証、フォーム、テンプレート、管理画面まで、構造はあらかじめ決められている。FastAPI は型付きの API 設計と非同期 Python を教えてくれるが、決められていることはほとんどない。抽象論としてはどちらも初心者向けとは言えず、目指す仕事に近いほうを選ぶことが、楽なほうを選ぶことに勝る。

ディスカッション

ログインしてディスカッションに参加してください。

Django レビュー：今も使う価値はあるか？