2026.08.29 開発

Djangoの将来性を2026年8月の数値で判断｜FastAPI台頭後の採用条件

「Djangoは今から採用しても大丈夫か」という問いは、人気があるかどうかではなく、これから3年から5年動かすシステムを載せて保守が回るかどうかで決まります。2026年8月時点のDjangoは、8か月サイクルを守って6.1を2026年8月5日にリリースし、2028年1月からは年次リリースへ移行することが決まっています。一方でJetBrainsの調査では利用率がFastAPIに抜かれ3位になりました。この記事では、公式の一次情報とGitHub APIの実測値をもとに、その2つの事実をどう読み、長期保守案件で採用してよい条件と見送る条件をどこで線引きするかを示します。求人や年収の話は扱わず、技術選定の判断材料に絞ります。

まとめ：Djangoを新規案件で採用してよい条件と見送る条件

結論を先に書きます。2026年8月時点のDjangoは、開発の継続性という観点では新規採用に耐えます。8か月ごとのリリースが守られ、6.1ではN+1を構造で潰すfetch modeのような設計に踏み込んだ変更が入り、リポジトリの直近52週のコミットは1,029件ありました。2028年からは全リリースが3年サポートに揃うため、保守計画はむしろ立てやすくなります。

採用してよいのは、管理・入力系の画面が全体の6割以上を占め、年0.5〜1人月のバージョン追従予算を確保でき、Pythonがチームの守備範囲にある案件。見送るべきなのは、リアルタイム双方向通信が主機能の案件、HTML画面を持たない外部公開API専業の案件、そして3年後の移行工数を今の見積もりに載せられない案件です。

利用率でFastAPIに抜かれたことは、Djangoが置き換えられたという意味にはなりません。増えた分母がAI・データ領域からの新規参入で、その層が作るのはAPI単体だからです。管理画面・認証・ORM・マイグレーションを1つのフレームワークで抱える必要がある業務システムでは、置き換え先が今も存在しません。以下、この判断の根拠を数値で開きます。

開発の継続性を実測値で確認する：リリース間隔とリポジトリの活動量

将来性の議論は印象論になりがちですが、フレームワークの継続性は3つの数字で測れます。リリースが予定どおり出ているか、コードが動いているか、この先のリリース計画が公表されているか。フレームワーク自体の構造はDjangoとは？特徴・メリットとMVTの仕組みで押さえた前提で進めます。

8か月サイクルが守られ、6.1で設計に踏み込んだ変更が入った

公式のリリースプロセスでは、フィーチャーリリースは約8か月ごとと定められています。直近では6.0が2025年12月3日、6.1が2026年8月5日で、間隔は8か月ちょうど。予定どおりです。

問題は中身が保守的な微修正で埋まっていないか。6.1には、モデルフィールドの取得挙動を制御するfetch modeが入りました。Book.objects.fetch_mode(models.FETCH_PEERS) と書くと、同じQuerySetから取れた全インスタンスの関連フィールドをまとめて取得し、ループ内の参照が2クエリで完結します。FETCH_RAISE を指定すれば、遅延ロードが発生した時点で例外を投げられる。これはORMの利用者が長年N+1問題を自力の select_related 運用で回避してきた領域に、フレームワーク側が仕組みを持ち込んだ変更です。

同じく6.1では、外部キーの削除に DB_CASCADE などDB側の ON DELETE 句へ落とす選択肢が加わり、メール設定は CACHES や DATABASES と同じ辞書形式の MAILERS になりました。いずれも既存の書き方を壊さずに、規模が大きい案件で問題になっていた箇所を埋める変更です。手を入れる場所が枯れていないことは、この先も改善が続く材料になります。

リポジトリの活動量から測る継続性：直近52週で1,029コミット

GitHub APIで django/django を2026年8月29日に取得した値は次のとおりです。

指標	実測値（2026年8月29日時点）
Star	89,029
Fork	34,197
直近52週のコミット	1,029件（週平均約20件）
直近12週のコミット	189件
最終push	2026年8月27日
Open issue	477件

Star数は人気の指標にはなっても継続性の指標にはなりません。見るべきは下の3行です。週平均20件のコミットが52週続き、直近12週も同じペースを保ち、最終pushが2日前。フレームワークの衰退は、まずコミット間隔が開き、次にリリース間隔が延びる形で現れますが、そのどちらも起きていません。

2028年からの年次リリース移行は保守計画にとって追い風になる

2026年8月10日、Djangoは年次リリースサイクルへの移行を公表しました（DEP 20）。2028年1月に出る版は従来なら7.0となるところが Django 2028.0 となり、以降は毎年1月にフィーチャーリリースが出ます。

保守を請け負う側にとって効くのはサポート期間の変更です。これまでは通常リリースが16か月、LTSだけが3年という二階建てでしたが、新サイクルでは全リリースが一律3年サポート（1年目がメインストリームのバグ修正、続く2年がセキュリティとデータ損失修正のみ）になり、LTSという特別区分は廃止されます。「LTSを追うか、通常リリースを追うか」という運用方針の分岐が消え、どの版に乗っても3年後に上げるという1本の計画になる。

移行期の位置づけも確認しておきます。従来型のLTSは2027年4月予定の6.2が最後で、そのサポートは2030年4月まで。今から着工するシステムは、6.1で始めて6.2 LTSへ上げるか、6.2 LTSを待って着工するかの二択になります。各バージョンの終了日と確認手順はDjangoのEOLとサポート期限一覧にまとめてあるので、期日の詰めはそちらを参照してください。

利用率3位の読み方：FastAPI 38%・Django 35%・Flask 34%

「Djangoはオワコンか」という問いの背景にあるのは、たいていこの数字です。JetBrainsが2025年9月に公開した「State of Python 2025」（調査実施は2024年）で、Webフレームワークの利用率はFastAPI 38%、Django 35%、Flask 34%となり、Pythonの歴史で初めてDjangoもFlaskも首位を外れました。

Djangoは減っていない：分母が増えた結果としての順位変動

数字を分解します。2023年比でFastAPIは+9ポイント、Djangoは+2ポイント、Flaskは+1ポイント。減った枠はどこにも無く、3つとも増えたうえで伸び幅の差が順位を入れ替えました。Pythonの利用者そのものがAI・データ分析側から大量に流入し、その新規層が最初に触るWebフレームワークとしてFastAPIを選んだ、という説明がJetBrains側の見立てです。

この読み方が実務にとって何を意味するか。既存のDjango案件がFastAPIへ置き換わっているのではなく、これまでWebフレームワークを使っていなかった人がAPIを立て始めた、ということです。置き換えのシェア争いなら移行コストの話になりますが、新規流入なら既存資産の寿命には直結しません。

DjangoとFastAPIで用途が重なる範囲は狭く、選定時は内蔵機能で判断する

両者を並べる前に、何が競合していて何が競合していないかを実装単位で切り分けます。

機能	Django	FastAPI
管理画面	admin が標準同梱	無し（自作かSaaS併用）
ORM・マイグレーション	標準同梱	SQLAlchemy等を別途選定
認証・権限	ユーザー・グループ・権限が標準	ライブラリを組み合わせて実装
非同期処理	ASGI対応だがORMは同期が中心	async 前提の設計
OpenAPI仕様の生成	DRF等の追加で対応	標準で自動生成

競合するのは「JSONを返すエンドポイントを書く」という一点だけで、そこはDjango側もDjango REST Frameworkで補完済みです。逆に管理画面・権限・マイグレーションを含む業務システムをFastAPIで組むと、Djangoが標準で持っている部分を選定して組み立てる工程が先に来ます。FastAPIとはで扱っている強みは、Djangoの内蔵範囲とほぼ排他の位置にあります。どちらを選ぶかの分岐そのものはDjangoとFlaskの違いで案件規模別に整理したので、選定作業に入る段階ではそちらを使ってください。

シェアの数字が選定の判断材料になる採用場面と、要件を優先する場面

利用率が効くのは、採用と学習リソースの調達という一点です。使う人が多いほど、情報が出回り、ライブラリの保守も続きます。その意味でDjangoの35%は十分な水準で、3位に落ちたこと自体は運用上の不利にはなりません。

逆に利用率が判断材料にならないのは、目の前の要件に合うかどうか。38%のFastAPIを選んでも、管理画面を200画面作る案件なら工数はDjangoより増えます。順位ではなく、内蔵範囲と要件の重なりで決めるべき局面です。

Python・AI領域との親和性が将来性を支える条件と、支えない条件

Djangoの将来性を語るとき「AIブームでPythonが伸びるから安泰」という説明をよく見かけますが、これは条件付きでしか成り立ちません。言語が同じであることが実装上どう効くのかを分けて考えます。

AI連携が効く場面：モデルと業務画面を1つのリポジトリに置ける

推論結果を人が見て判断し、その判断を業務データとして残す種類のシステム、たとえば書類の自動仕分けや検査結果の一次判定では、モデル側のコードと画面側のコードが同じPythonで書けることが効きます。前処理のロジックを両方から呼べる、依存関係の管理が1つのツールで済む、型やデータ構造の定義を共有できる。別言語で組むと、この境界にAPIとスキーマ定義が1枚挟まります。

Djangoのモデル定義をそのままデータの正とし、学習用のデータ抽出も同じORMで書けることも、小規模なチームでは工数差になって出ます。Python本体の動向はPython 3.14新機能まとめで押さえておくと、対応バージョンを決めるときの判断が早くなります。

AI連携を効かせるための構成：推論をリクエストプロセスに載せない

同じ言語で書けることと、同じプロセスで動かしてよいことは別です。Djangoのリクエスト処理は同期のワーカーで動くのが基本形で、そこに数秒かかる推論を同居させると、ワーカーが1つずつ埋まっていきます。

実務では、推論は別サービスへ切り出してHTTPかキュー越しに呼ぶか、Celery等のワーカーへ非同期で投げる構成にします。この分離を最初にやっておくと、後からモデルだけGPUインスタンスへ移す、推論部分をFastAPIで書き直す、といった変更がDjango側を触らずに済む。Pythonで揃えることの利点は、この分離をしたうえでライブラリとデータ処理コードを共有できる点にあります。

AI連携が効かない場面：親和性を理由に選ぶと外しやすい案件要件

チャットやダッシュボードの常時更新のように、長時間接続と双方向通信が主機能の場合、Python同士であることの利点よりもASGIまわりの構成コストが上回ります。LLMの応答をトークン単位で流すストリーミングも同様で、同期ワーカー前提の構成では素直に書けません。この種の要件が機能の中心にあるなら、言語の一致は選定理由として弱いと判断してください。

長期保守案件でDjangoを採用してよい4条件と見送る3条件

ここまでの材料を、着工前のチェックリストに落とします。数値で書けるものは数値にしました。

Djangoを採用してよい案件を見極めるための具体的な4条件

条件1：管理・入力系の画面が全体の6割以上を占める。一覧・検索・登録・承認といったCRUDと権限制御が機能の中心なら、admin と認証まわりの内蔵分がそのまま工数削減になります。逆に公開向けの表示画面ばかりで管理機能が数画面なら、フルスタックである利点が出ません。向く案件の類型はDjangoで作られたWebアプリの例に実採用例を並べてあります。

条件2：年0.5〜1人月のバージョン追従予算を確保できる。2028年以降は3年ごとに移行が来ます。1回の移行で、リリースノートの後方互換性のない変更の確認、非推奨警告の解消、依存パッケージの追随、回帰テストが発生する。中規模の業務システムなら1回あたり1〜2人月、これを3年で割ると年0.5〜1人月が目安です。この枠を見積もりに載せられない案件は、フレームワークを問わず3年後に止まります。

条件3：ピーク時の同時リクエストが数百件/秒に届かず、長時間接続が主機能でない。社内業務システムや会員向けサービスの多くはこの範囲に収まります。超える見込みがあるなら、非同期化の設計を先に決めるか、負荷が集中する経路だけ別構成にする判断が要ります。

条件4：チームにPython経験者がいる、または既存資産がPython側に寄っている。データ処理やスクリプトがすでにPythonで書かれているなら、言語を揃えることで保守要員の融通が利きます。

この4条件のうち、着工後に埋め合わせが利かないのは条件2です。稼働後にバージョン追従の予算だけ後から取るのは通りにくく、結果としてEOL版のまま数年動かす状態になります。着工時点で保守の体制まで含めて設計しておく必要があり、社内に追従の担い手を置けない場合は保守運用・内製化支援のように、バージョン追従と改修を継続的に受ける契約で外に置く選択肢もあります。

Djangoの採用を見送るべき案件を見極めるための具体的な3条件

見送り1：リアルタイム双方向通信が主機能。チャット、共同編集、常時更新のダッシュボードが機能の中心なら、Django Channels で組むより最初からASGI前提のフレームワークを選ぶほうが構成が素直になります。付随機能として一部にWebSocketが要るだけなら、この条件には当たりません。

見送り2：HTML画面を持たない外部公開API専業。OpenAPI仕様の自動生成と非同期処理が要件の中心で、管理画面も認証画面も無いなら、Djangoの内蔵分がそのまま使われない重さになります。

見送り3：3年後の移行工数を見積もりに計上できない。予算の都合で保守費を削る前提の案件では、どのフレームワークでも同じ問題が起きますが、Djangoは3年で確実に期限が来る分、放置した場合の脆弱性リスクが明確に積み上がります。

Django案件の着工時に決めておく長期保守を見据えた実装上の3点

採用を決めた後に効いてくるのは、5年後の移行コストを左右する初期の設計判断です。3点に絞ります。

バージョン追従を年次の定期作業として着工時の保守計画に組み込む

移行を「気づいたときにやる作業」にすると必ず後回しになります。着工時点で、次のリリース時期と自社の上げ先を保守計画へ書き込み、テストを非推奨警告付きで流す設定を最初から入れておく。Djangoは非推奨化から削除まで2リリース分の猶予があるため、毎年テストで警告を潰していれば移行そのものは軽く済みます。上げ方の手順はサポート期限と移行判断の記事で詳しく扱っています。

Django本体より先にサポートが切れる依存パッケージを管理する

実務でアップグレードを止めるのは、Django本体ではなく周辺ライブラリです。認証系、管理画面の拡張、帳票、決済といったサードパーティは、Djangoの新版へ追随するまでに数か月かかるものがあり、保守が止まったまま放置される例もあります。着工時に依存パッケージを数え、それぞれの最終更新日と対応バージョンの表を作っておくと、後の移行で詰まる箇所が事前に見えます。数が多いほど移行の難度は上がるので、標準機能で足りるものはライブラリを入れない判断も含めて設計してください。

将来の部分移行に備えてフレームワークに寄せすぎない層を1枚残す

業務ロジックをビューとモデルへ全部書き込むと、将来どこかを別サービスへ切り出すときにコードが動かせません。金額計算や判定ロジックのように仕様として独立している処理は、DjangoのAPIに依存しない関数として分けておく。この1枚があるだけで、推論部分を別プロセスへ出す、一部エンドポイントを他のフレームワークで書き直すといった部分的な移行が現実的な工数に収まります。

よくある質問

Djangoはオワコンだと言われますが、実際のところ衰退していますか？

実測値では衰退の兆候は出ていません。2026年8月29日時点でリポジトリの直近52週コミットは1,029件、最終pushは2日前で、リリースも8か月サイクルどおりに6.1が2026年8月5日に出ています。JetBrains調査の利用率でFastAPIに抜かれたのは事実ですが、Django自体も2023年比で+2ポイントと増えており、順位の変動は新規参入層の流入によるものです。

これから新規開発を始めるなら、6.1と5.2 LTSのどちらを選ぶべきですか？

開発期間が長く、稼働後しばらくバージョンを固定したい案件なら拡張サポートが2028年4月まで残る5.2 LTSが基準になります。着工から稼働までが短く、6.1の新機能を使う予定があるなら6.1で始め、2027年4月の6.2 LTSへ上げる計画にしてください。どちらの場合も、上げ先とタイミングを着工時に決めておくことが条件です。

2028年の年次リリース移行で、既存プロジェクトに改修は発生しますか？

バージョン体系の変更そのもので既存コードが動かなくなることはありません。変わるのは番号の付け方とリリース間隔、そして全リリースが3年サポートに揃う点です。従来型LTSの最後となる6.2は2030年4月までサポートされるため、そこまでに年次リリースへ追従する計画を立てれば足ります。

Django案件はこの先も出続けますか？

管理機能が主役の業務システムや会員サイトという用途がある限り、需要の構造自体は変わりません。この領域では、認証・権限・管理画面・マイグレーションを標準で持つフレームワークの選択肢が限られるためです。ただしAPI単体の開発案件は、Python側ではFastAPIへ寄る傾向が続くと見ておくのが妥当でしょう。

他の言語のフレームワークと比べて、Djangoの継続性はどの水準ですか？

リリース間隔とサポート期間の明文化という点では上位に入ります。8か月サイクルと3年サポート、2028年以降の年次3年固定はいずれも公式に日付付きで公表されており、5年先の保守計画を数字で書ける状態です。同じ観点での他フレームワークの状況は、Laravelの将来性やSvelteの将来性と並べて比べると判断しやすくなります。