--- title: "Djangoで作られたWebアプリの例｜向く4類型と実採用事例・見積もりの見方" url: "https://www.issoh.co.jp/column/details/16918/" published: 2026-08-24 updated: 2026-08-28 categories: ["Webシステム"] publisher: "株式会社一創" --- # Djangoで作られたWebアプリの例｜向く4類型と実採用事例・見積もりの見方 Djangoを選ぶかどうかは、フレームワークの性能比較ではなく案件の形で決まります。データを登録し、権限で見せ分け、承認して回す。この作業が仕様の中心にある案件なら、Django標準の管理画面がそのまま成果物の一部です。本記事では、Djangoで作られたWebアプリを4つの類型に整理したうえで、GitHubでコードまで読める実際の採用例、テンプレート方式とAPI分離方式の分かれ目、そして見積もり金額を動かす要素を発注する側の視点で扱います。Djangoそのものの定義やMVTの仕組みは[Djangoの特徴とMVTの仕組みを扱った入門解説](https://www.issoh.co.jp/tech/details/3275/)に譲り、ここでは「自分の案件に当てはまるか」だけを判断できるようにします。 ## まとめ：Django採用が向く案件条件と見送りの分岐 結論から書きます。Djangoの採否は「管理画面と権限管理をどれだけ作る必要があるか」でほぼ決まる、と考えて差し支えありません。`django.contrib.admin`がモデル定義から管理画面を生成するため、一覧・検索・登録・編集・権限による表示制御といった画面が仕様の大半を占める案件では、他のフレームワークなら見積もりに積まれる工程がまるごと消えます。標準の管理画面をそのまま本番で使ってよい条件と、別画面へ作り直しに切り替える条件は[Django管理画面の設計：admin標準の範囲とModelAdmin・権限の実装](https://www.issoh.co.jp/tech/details/17078/)で整理しています。 向く類型は4つあります。社内の申請と承認を回す業務システム、会員機能と検索を持つメディアやポータル、蓄積データを見せる集計ダッシュボード、そしてDjango REST Frameworkを挟んだAPI分離構成。共通するのは、認証・権限・データ管理という土台が厚い点です。 見送る条件もはっきりしています。公開するエンドポイントが数個しかないマイクロサービスの断片、WebSocketの常時接続が主役になるアプリ、標準の管理画面を一切使わず独自UIだけで完結する案件。ここでDjangoを選ぶと、使わない標準機能の分だけ構成と学習コストが乗ります。 発注前に確かめることは1つで足ります。標準の管理画面をどこまで業務画面として使い、どこからスクラッチで作るのか。この線引きを開発会社に言わせてください。線が引けていない見積もりは、後から画面のスクラッチ開発が積み上がる形になります。 ## Djangoで作られるWebアプリの4類型と標準機能が効く条件 「Djangoで何が作れるか」を機能一覧で並べても採否の判断にはつながりません。実務で意味を持つのは、標準機能が仕様の何割を吸収するかという観点での分類です。以下の4類型は、その吸収率が高い順に並べています。 ### 申請と承認と権限分けが中心になる社内向け業務システムの具体例 経費申請、稟議、勤怠の修正依頼、在庫の入出庫記録、顧客マスタの保守。これらは画面の見た目より、誰がどのデータを見て、誰が承認できるかというルールが仕様の本体になります。Djangoは利用者・グループ・権限の3モデルを標準で持ち、モデル単位の追加・変更・削除・閲覧という4種類の権限を自動生成します。 この類型では、管理画面をそのまま担当者の作業画面として渡す判断が現実的な選択肢になります。一覧の絞り込み、検索対象のフィールド、編集できる項目の範囲は、モデルごとの設定クラスに数行書くだけで変わるためです。画面を1枚ずつHTMLから起こす前提で組んだ見積もりと比べると、初期構築の工数は目に見えて違ってきます。 ### 会員登録と検索と公開制御を伴う会員制サイトやポータルの具体例 会員登録があり、ログイン状態で見えるものが変わり、記事や物件や求人といったデータを検索させる。この形はDjangoが生まれた経緯そのものです。Djangoは2005年に米国の新聞社の内製ツールとして公開されており、締め切りに追われるニュースサイトを短期間で立ち上げる用途が出発点にあります。 会員データの持ち方、公開と非公開の状態管理、下書きと公開版の切り分けは、いずれも標準のモデルとフォームで組み立てられます。検索・権限管理・会員機能を備えたサイトを外部に委託する場合の進め方については、[会員・検索・権限管理に対応したポータルサイト開発](https://www.issoh.co.jp/service/system/portal/)のページで扱う要件整理が下敷きになります。 ### 蓄積データの集計と可視化を主目的とするダッシュボードの具体例 基幹システムに溜まった受注データや設備の稼働ログを、部門ごとに切り替えて見せる社内向けの画面。この類型でDjangoが効く理由は、ORMが集計処理を素直に書けるからです。グループ単位の合計や件数をデータベース側に寄せる書き方が標準で用意されており、Python側で全件を読んでから集計する構成を避けられます。 ただしグラフ描画そのものはDjangoの守備範囲ではありません。表示側はJavaScriptのライブラリに任せる構成になるため、「Djangoだけで完結する」と説明された見積もりがあれば、描画部分の担当を必ず確認してください。ここは後から追加費用になりやすい箇所です。 ### 外部公開APIとフロントエンド分離を前提とするSPA構成の具体例 スマートフォンアプリからも社内画面からも同じデータを触る案件では、DjangoをAPIサーバとして置き、画面はReactやVueで別に作る構成です。この構成の標準的な選択肢がDjango REST Frameworkで、モデルからJSONへの変換、認証、ページング、権限判定を担います。実装の入り口は[Django REST Frameworkの使いどころと最小構成](https://www.issoh.co.jp/tech/details/3277/)で整理しています。 注意したいのは、この構成にすると先の3類型で効いていた管理画面の恩恵が半減する点です。画面をすべてフロントエンド側で作るなら、Djangoに残るのはORMと認証だけになります。それでもDjangoを選ぶ理由は、社内の運用担当者が触るデータ保守画面を管理画面で賄い、利用者向けの画面だけをSPAにするという二層構成が組めるからです。 ## コードまで検証できる国内外の採用実例と読み取れる設計の範囲と判断軸 「Instagramが使っている」という説明は採用判断の材料になりません。規模も要件も違うからです。判断に効くのは、自分の案件に近い規模の実装を、コードとして確認できるかどうか。ここではソースが公開されていて実際に読める例を中心に挙げます。 ### 数千のエンドポイントを抱えるInstagramのモノリス構成の到達点 Instagramのバックエンドは、数千のDjangoエンドポイントを持つ単一の巨大なコードベースとして運用されていることが、同社のエンジニアリング発信から明らかです。性能が要求される処理はC++とCythonの拡張に切り出す一方で、サービスを細かく分割する方向へは積極的に舵を切っていません。 ここから読み取れるのは、Djangoが規模の上限で行き止まりになるフレームワークではないという一点だけです。中小規模の受託開発で参考になる設計上の示唆はほとんどありません。この事例は「将来スケールしなくなるのでは」という懸念への回答としてだけ使うのが正確な扱い方になります。 ### 公開リポジトリでコードが読めるaddons.mozilla.orgの運用規模 Mozillaのアドオン配布サイトであるaddons.mozilla.orgは、バックエンドがDjangoアプリとAPIとしてGitHubのmozilla/addons-serverで公開されています。masterブランチのコミット数は64,637件、ライセンスはBSD-3-Clauseです。審査ワークフロー、バージョン管理、開発者向けの投稿画面といった実務的な機能が、動いているサービスのコードとして読めます。 投稿されたコンテンツを審査して公開する仕組みを作る案件なら、この実装は仕様検討の下敷きになります。参照するときはモデル定義のファイルから入るのが早く、画面から入ると規模に押し流されます。 ### Django製CMSとして開発が続くWagtailの対応バージョンと採用条件 WagtailはDjango上で動くコンテンツ管理システムで、GitHubのスター数は20.5k、ライセンスはBSD-3-Clauseです。2026年8月時点でDjango 5.2系・6.0系・6.1系に対応し、Python 3.10から3.14までをサポートしています。データベースはPostgreSQL、MySQL、MariaDB、SQLiteが選べます。 編集画面と公開ワークフローが最初から用意されているため、記事や固定ページの更新を担当者が自分で行うメディア系の案件では、Djangoをゼロから組むより早く到達できます。逆に、更新頻度が低く画面数も少ないサイトにWagtailを入れると、構造を覚える手間だけが残る結果になりがちです。 ### ECサイト向けdjango-oscarで確認すべきサポート期限と採用可否 ECに寄せた実装としてはdjango-oscarがあり、スター数は6.6k、ライセンスはNew BSDです。商品カタログ、カート、注文の各モデルを差し替え前提の設計で持つため、標準的な通販の枠に収まらない業態でも組み替えられます。 採用には条件が付きます。公式にサポート対象として案内されている3.2 LTSは2026年1月までのサポートと示されており、期限を過ぎた版に乗せる判断は保守計画とセットでしか成立しません。新規案件で選ぶなら、リポジトリの更新状況と対応Djangoバージョンを発注前に開発会社へ確認させてください。確認せずに採用すると、Django本体のバージョンアップ時に足枷になります。 ## テンプレート方式とAPI分離方式を分ける判断材料と構成の境界 同じDjango案件でも、画面をDjango側で作るか、フロントエンドを分離するかで見積もりも保守体制も変わります。ここは発注段階で決まっていないことが多く、後から揺れると費用に直結する箇所です。 ### 画面をDjango側で組むテンプレート方式が費用面で有利になる条件 利用者が社内の担当者に限られ、画面遷移が申請から承認まで直線的で、スマートフォンアプリの予定がない。この3条件が揃うなら、テンプレート方式で組むほうが安く仕上がります。フロントエンドの開発者を別に立てる必要がなく、認証やフォーム検証をDjango側で一元管理できるためです。 判断を鈍らせるのが「将来SPAにするかもしれない」という留保です。予定が具体的な時期と予算を伴っていないなら、その留保は捨ててください。使うかどうか分からない分離構成のために初期費用を上げるのは、回収の見込みが立たない投資になります。 ### API分離とSPAを選ぶべき要件と追加で発生する開発範囲の内訳 分離を選ぶ理由になるのは、モバイルアプリや外部システムから同じデータを使う予定が確定している場合と、画面の操作性が受注の要件そのものになっている場合の2つです。この2つに当てはまらない分離は、費用対効果が合いません。 分離すると、認証トークンの受け渡し、別ドメイン間の通信許可設定、フロントエンドのビルドと配信という工程が追加される構成です。ReactとDjangoをつなぐ実装の具体は[DRF・CORS・JWT認証を含むReactとDjango連携の実装手順](https://www.issoh.co.jp/tech/details/4421/)で確認できます。見積書にこれらの工程名が現れていなければ、分離構成の作業量が見落とされている可能性があります。 ### 標準管理画面を業務画面へ流用できる範囲と作り込みが必要な境界 標準の管理画面が通用するのは、1つのデータを1つの画面で編集する形に収まる業務までです。項目の並べ替え、絞り込み条件の追加、一覧に出す列の指定、簡単な一括処理までは設定の範囲で足ります。 境界を越えるのは、複数のモデルを1画面でまとめて更新する業務、入力途中の値によって次の入力項目が変わる業務、そして担当者ごとに画面の見た目自体を変える必要がある業務です。ここに該当する画面が仕様に3枚以上あるなら、その部分は最初からスクラッチで見積もるほうが結果的に安く済みます。管理画面を無理に拡張した実装は、Django本体のバージョンアップで壊れやすい箇所でもあります。 ## Djangoを選ぶべきでない要件と代替フレームワークへの切り替え基準 採用しない判断を先に持っておくと、開発会社の提案を評価しやすくなります。ここでは条件を明示して言い切ります。 ### エンドポイントが少数のマイクロサービスでDjangoが過剰になる理由 公開するAPIが10本に満たず、データベースのテーブルも数個で、管理画面を誰も開かない。この条件ならDjangoは採用しないでください。プロジェクト構成、設定ファイル、マイグレーション管理という一式が、得られる利益に見合いません。型ヒントを前提に設計されたFastAPIか、軽量なFlaskのほうが構成が短く済みます。 この分岐を実装の粒度で詰めた内容は[DjangoとFlaskの違いと選定条件の解説](https://www.issoh.co.jp/tech/details/17084/)で扱っています。 判断の目安を1つ挙げておきます。管理画面を開く運用担当者が組織内に1人もいないなら、Djangoの最大の利点は使われないまま残ります。 ### 常時接続と大量並行処理が主役になるアプリで生じる構造上の制約 チャット、共同編集、リアルタイムの位置追跡のように、WebSocketの接続を長時間維持し続ける処理が主役になるアプリでは、Djangoは第一候補になりません。非同期対応は進んでいるものの、標準構成は同期処理を前提に組まれており、周辺のライブラリも同期前提のものが多く残っています。 ただし全面的な除外ではありません。データ管理と管理画面はDjangoで持ち、常時接続の部分だけを別プロセスに切り出す構成は成立します。切り分けの線をどこに引くかを設計段階で決めてあるかどうかが、この判断の分かれ目です。 ### 独自UIだけで完結する案件でDjangoの利点が消える具体的な条件 デザイン会社が作った画面をそのまま実装する前提で、管理画面は使わず、データ登録も利用者が画面から行うだけ。この形では、Djangoが提供する管理画面・フォーム生成・テンプレートのいずれも出番がありません。残るのはORMと認証だけで、それは他の選択肢でも代替が利きます。 この条件で「開発会社がDjangoに慣れているから」という理由づけが出てきたら、それは正当な理由として受け取ってかまいません。慣れた道具は見積もりの精度を上げるからです。ただし技術的な必然性があるかのような説明を受けた場合は、根拠を掘り下げて聞いてください。 ## 見積もり金額を動かす要素と発注前に固めておくべき仕様の範囲と判断軸 Django案件の見積もりは、画面数だけを数えても妥当性が判断できません。金額を動かすのは、標準機能でどこまで賄うかという設計判断のほうです。費用の内訳と人月単価の読み方そのものは[業務システム開発の費用相場と見積書の読み方](https://www.issoh.co.jp/column/details/15779/)で扱っているため、ここではDjango固有の変動要素に絞ります。 ### 管理画面の流用範囲が初期構築費に与える差と確認すべき記載内容 見積書に「管理画面構築」という項目が画面数ぶん並んでいたら、それが標準機能の設定で済む範囲なのか、スクラッチなのかを分けて示すよう求めてください。前者と後者では1画面あたりの工数が数倍変わります。 実務で使える確認の言い方を挙げておきます。「この画面のうち、管理画面の設定で対応するものと、独自に作るものの内訳を出してください」。この質問に即答できる開発会社は、Django案件の見積もり経験があると判断してよいはずです。 ### バージョン選択とサポート終了時期が保守費用に及ぼす影響の実際 2026年8月時点の最新安定版はDjango 6.1で、メインストリームのサポートは2027年4月に終わります。長期サポート版の5.2は拡張サポートが2028年4月まで続き、長く運用するシステムはこちらが基本線です。次の長期サポート版となる6.2は2027年4月のリリース予定で、拡張サポートは2030年4月までと案内されています。 この期限は保守契約の設計に直結する要素です。5年使う前提のシステムを最新版で作ると、期間内に大きなバージョンアップが確実に必要になり、その費用が後から発生する形になります。なお2028年以降は方式が変わり、すべての機能リリースが同じ3年のサポート期間を持つ運用へ移行する予定が示されています。長期の保守を含む契約では、この移行を織り込んだ見積もりかどうかを確認してください。 ### 認証と外部連携の要件が工数に跳ね返る箇所と事前確定の効果範囲 標準の認証はメールアドレスとパスワードによるログインです。シングルサインオン、多要素認証、社内のディレクトリサービスとの連携が要件に入ると、それぞれ追加のライブラリ選定と検証の工程が乗ります。これらを後から足すと、既に作った利用者モデルの作り直しにつながることがあります。 発注前に確定させておくべきものを挙げます。ログイン方式、権限の段数、外部システムとの連携先と方向、帳票やファイル出力の有無、そして同時に触る利用者の想定人数。この5点が決まっていれば、見積もりの精度は大きく上がります。Webアプリ開発全体の進め方や言語選定の考え方は[Webアプリ開発の仕組みと種類・費用と外注判断の解説](https://www.issoh.co.jp/column/details/15430/)にまとめています。 ## よくある質問 Djangoで作られたWebアプリの実例や採用判断について、検索でよく調べられている質問に答えます。 ### Djangoで作られた有名なサイトやサービスは何がありますか？ コードまで確認できるものとしては、Mozillaのアドオン配布サイトであるaddons.mozilla.orgのバックエンドがGitHubで公開済みです。Instagramのバックエンドも数千のDjangoエンドポイントを持つモノリスとして知られています。ただし採用判断の材料にするなら、規模の大きいサービス名より、自分の案件に近い機能を持つ公開リポジトリを読むほうが有効です。CMSならWagtail、ECならdjango-oscarが実装の参照先になります。 ### Djangoで作ったWebアプリの開発期間はどれくらいかかりますか？ 期間を左右するのは画面数よりも、標準の管理画面をどこまで使うかという設計判断です。データ登録と検索が中心で管理画面を業務画面として使える案件なら、同じ機能を1画面ずつ作る場合より短縮が可能です。逆に、複数モデルを1画面で更新する業務や入力に応じて項目が変わる画面が多いと、標準機能の恩恵が薄れて期間は伸びます。見積もり時は「管理画面の設定で済む画面」と「独自に作る画面」の内訳を出してもらうと、期間の妥当性を判断できます。 ### DjangoとLaravelはどちらを選ぶべきですか？ 言語の選択がそのまま答えになる場面が多くあります。機械学習やデータ処理を同じシステム内で扱う予定があるならPython側のDjango、既存の社内資産やエンジニアの経験がPHPに寄っているならLaravelです。フレームワークとしての機能範囲は近く、性能差が決め手になる案件はほとんどありません。保守を担当する体制がどちらの言語に慣れているかで決めるほうが、運用開始後の総費用は下がります。 ### Djangoは個人開発や小規模なアプリでも使えますか？ 使えますが、規模が小さいほど構成の重さが相対的に目立ちます。ページが数枚でデータベースをほとんど使わないなら、より軽量なフレームワークのほうが手数の少ない選択です。一方で、ログイン機能とデータ登録画面が必要な個人開発なら、認証と管理画面が最初から動くDjangoは短時間で形になります。判断の目安は、管理画面を自分で開いてデータを触る場面があるかどうかです。 ### Django製のアプリで実際のコードを確認する方法はありますか？ GitHubで公開されているプロジェクトを読むのが確実です。Wagtailはスター数20.5kのDjango製CMSでライセンスはBSD-3-Clause、addons-serverは実運用中のサービスのバックエンドで同じくBSD-3-Clauseです。読む順番としては、モデル定義のファイルから入ると全体のデータ構造が把握しやすくなります。開発会社を選ぶ場面では、過去のDjango案件について構成の説明を求め、この記事で挙げた類型のどれに当たるかを聞くと実力が見えます。 ## 関連記事 - [Djangoとは？特徴・メリットとMVTの仕組みを入門解説【最新版対応】](https://www.issoh.co.jp/tech/details/3275/)：フレームワークの定義・MVTの仕組み・インストール手順を扱っています。 - [Django REST Framework（DRF）とは？使いどころと最小構成](https://www.issoh.co.jp/tech/details/3277/)：API分離構成を選んだ場合の実装の入り口です。 - [ReactとDjango連携の実装手順｜DRF・CORS・JWT認証](https://www.issoh.co.jp/tech/details/4421/)：SPA構成で追加になる認証と通信設定の具体を解説しています。 - [Webアプリ開発とは？仕組み・種類・開発言語から費用と外注判断まで発注者視点で解説](https://www.issoh.co.jp/column/details/15430/)：フレームワーク選定の前段にある全体像を整理しています。 - [業務システム開発の費用相場は？規模別の目安と内訳・見積書の読み方を発注者視点で解説](https://www.issoh.co.jp/column/details/15779/)：見積書の内訳と人月単価の読み方を扱っています。 --- 出典: [Djangoで作られたWebアプリの例｜向く4類型と実採用事例・見積もりの見方]()（株式会社一創）