2026.08.29 開発

django CMSとは：Page・Placeholder・pluginの構造と後付け判断

Djangoで作った業務システムに「文言と画像を非エンジニアが直せる画面を付けたい」という要望が来たとき、答えは二つに割れます。WordPressを別に立てて連携するか、Djangoプロジェクトの中にCMSを載せるかです。django CMSは後者の代表格で、Djangoとは？Python製Webフレームワークの特徴・MVT・始め方を入門解説で扱ったMVT構造の上に、編集レイヤーをアプリとして追加します。ただし日本語の解説はほとんどが3.x時代のもので、4.0の内部構造変更と5.1の対応Django下限引き上げが反映されていません。ここでは2026年8月時点の版を前提に、構造・後付けの条件・比較・見送る場面を整理しました。

まとめ：django CMSは既存Djangoに載せる編集レイヤー

django CMSは独立した製品ではなく、Djangoプロジェクトに追加するアプリ群です。DjangoのORMもテンプレートもそのまま使えます。
構造はPage・PageContent・Placeholder・CMSPluginの4層です。テンプレートに置いたスロットへ、編集者がプラグインを差していく形になります。
4.0で内部設計が入れ替わりました。TitleはPageContentへ改称し、公開と下書きの管理はdjangocms-versioningへ外へ出ています。
2026年8月時点の最新は5.1.2、LTSは5.0系です。3.11と4.1は2026年4月にサポートが切れました。
既存プロジェクトへはpip installとdjangocmsコマンドで後付けできます。既存アプリはapphookでページツリーへぶら下げる形です。
編集者が10人を超える、あるいは日本語の運用ドキュメントを社内で用意できない場合は、WordPressへ倒すほうが総保有コストは下がります。

django CMSを構成する4つのモデル層と編集の単位を先に押さえる

まず押さえるべきは、django CMSが「CMS製品」ではなくDjangoアプリの集合だという点です。pip install django-cmsで入るのはcmsアプリと周辺パッケージで、データベースもプロジェクトのものを使います。DjangoとPostgreSQLの接続設定｜DATABASES定義と接続プールと固有フィールドの判断で扱った接続設定の書き換えは不要です。

PageとPageContentが4.0で分けられた理由と版管理

3.x系では、ページの多言語コンテンツを表すモデルがTitleという名前でした。4.0でPageContentへ改称され、持ち物も変わっています。旧構造では複数のTitleが同一のPlaceholderを共有していましたが、4.x以降は各PageContentが専用のPlaceholderセットを持ちます。

この分離が効くのは版管理です。PageContentが独立していれば、同じページに下書き・公開済み・アーカイブを並べられます。公式も「モデル構造を変えたことでdjangocms-versioningのようなパッケージが無数のPageContentを作れるようになった」と説明しており、版管理をコアから外すための前提がこの構造変更でした。5.0ではさらにTreeNodeモデルがPageへ統合され、page.node.siteがpage.siteに、page.node.pathがpage.pathになっています。3.x向けのコードをそのまま持ち込むと、ここで壊れます。

Placeholderはテンプレート側の名前付きスロットとして働く

Placeholderは、テンプレートに置く「ここは編集可能」という宣言です。タグを1行書くと、その位置が編集画面でドラッグ可能な領域になります。

{% load cms_tags %}
{% cms_toolbar %}
{% placeholder "content" %}
{% placeholder "sidebar" %}

スロット名はslot属性としてデータベースに残り、テンプレート側の記述と対応づきます。編集可能な範囲を決めるのは編集者ではなく実装者で、テンプレートを書き換えない限り編集領域は増えません。ここが後述するWordPressとの分水嶺です。継承やコンテキストの渡し方は通常のDjangoと同じで、Djangoテンプレートの書き方：継承とコンテキスト・JSへの値渡しの作法がそのまま通用します。

モデル側にPlaceholderを持たせたい場合は、4.0でPlaceholderFieldが廃止され、GenericForeignKeyベースのPlaceholderRelationFieldに置き換わりました。自作モデルへCMS編集を差し込む既存コードがあるなら、ここは書き換えが要ります。

CMSPluginが本文の最小単位を決める仕組みとツリー構造

Placeholderの中に入るのがプラグインです。テキスト・画像・カラムといった部品がそれぞれCMSPluginのサブクラスで、モデルとフォームとテンプレートを持ちます。自作プラグインを足せば、社内の定型ブロック（料金表、事例カード）をそのまま編集部品にできます。

4.0でプラグインツリーの実装がtreebeard依存から親子関係フィールドとCTEクエリへ移りました。positionの数え方も変わり、v4以降は最初の子プラグインで1にリセットされません。子は親のpositionに1を足した位置へ入る形です。APIから操作するときはget_next_plugin_position()で位置を計算し、追加はadd_plugin()、削除はdelete_plugin()を使ってツリーの整合を保ちます。生の削除メソッドで消すと壊れます。

層	役割	実装者が触る場所
Page	ページツリーの節	管理画面での作成
PageContent	言語ごとの中身	版管理パッケージ経由
Placeholder	編集可能なスロット	テンプレートタグ
CMSPlugin	本文の部品	自作プラグイン

2026年8月時点の版と対応バージョンの地図を実装前に確認する

django CMSは版によって別物と言えるほど内部が違うため、記事や書籍を読む前にそれが何系の話かを確認する手順が要ります。

3.11と4.1のEOLで発生する移行の判断と公式の推奨経路

2026年4月に、3.11と4.1のLTSが揃ってサポート終了しました。最終パッチは3.11.11と4.1.11です。既存サイトがこのどちらかで動いているなら、セキュリティ修正が供給されない前提で計画を立て直すことになります。Djangoの脆弱性への対応｜セキュリティリリースの追い方と標準で防げない穴で書いたとおり、本体だけ追ってもCMS側が止まっていれば穴は残ります。

公式が示す移行経路は、3.11からは4.1を経由して5.0へ、4.1からは5.0へ直接という二本立てです。3.11から直接飛ばさないのは、4.1で入ったアーキテクチャ変更を一度に受け止めるとデータ移行の失敗点が特定できなくなるためでした。見積もりでは、この中間ステップを1本のマイルストーンとして数えてください。

既存Djangoプロジェクトへ後付けする手順と成立条件を整理する

現場で多いのは、動いているDjangoアプリに編集機能を後から足したいという相談です。公式はこの経路を正面から用意しています。

djangocmsコマンドが既存の設定ファイルへ書き込む範囲

手順自体は2行です。プロジェクトルート、つまりmanage.pyのある場所で実行します。

pip install django-cms
djangocms . --dry-run
djangocms .

このコマンドが自動で書き込むのは、INSTALLED_APPSへのcmsアプリとアドオン追加、ミドルウェアとテンプレートコンテキストプロセッサの追加、SITE_ID・LANGUAGES・CMS_TEMPLATESの補完、ROOT_URLCONFへのURLパターン追加、テンプレートディレクトリが無い場合の最小ベーステンプレート作成、の5点です。既存の設定ファイルへ機械的に手を入れる以上、先に--dry-runで差分を見てから実行してください。

省略できるものもあります。版管理が不要なら--no-versioning、HTMLを配信せずAPIだけ使うなら--mode headlessです。既定ではdjangocms-versioningが入り、下書きと公開の二段階が有効になります。

apphookで既存アプリをページツリーの下へマウントする方法

後付けで本当に効くのはapphookです。これは既存のDjangoアプリのURL群を、CMSのページの下にマウントする仕組みになります。アプリ側にcms_apps.pyを置き、CMSAppのサブクラスを登録してください。

from cms.app_base import CMSApp
from cms.apphook_pool import apphook_pool

@apphook_pool.register
class OrderApphook(CMSApp):
    app_name = "orders"
    name = "受注アプリ"

    def get_urls(self, page=None, language=None, **kwargs):
        return ["orders.urls"]

app_nameはURL名前空間と一致させます。get_urls()が返すのはURLモジュールのパスです。登録したら管理画面でページを開き、高度な設定タブのApplicationから選んで保存してください。新しいPythonファイルを追加しているので初回だけサーバの再起動が必要です。ファイル名は3.2以降がcms_apps.pyで、3.1までのcms_app.pyという記述は古い情報になります。

これが噛み合うと、会社概要やお知らせはCMSで編集し、受注一覧や見積画面は既存のDjangoビューのまま、同一のURLツリーとテンプレート継承の下に並びます。ヘッダーとフッターを二重管理せずに済むのが後付けの実利です。入口の分け方はDjango管理画面の設計：admin標準の範囲とModelAdminと権限の実装も併読してください。django adminは運用担当者向け、CMSツールバーは編集者向けと分けます。

後付けが成立する三つの条件と、噛み合わない二つの構成パターン

成立するのは、Djangoが5.2以上（5.1系を使う場合）で、テンプレートがbase.htmlからの継承で組まれ、認証がDjango標準のユーザーモデルに乗っているケースです。この三つが揃えば、作業は設定追記とタグ挿入で収まります。

噛み合わないのは二つです。フロントエンドをReactやVueのSPAで作りDjangoテンプレートをほぼ使っていない場合、Placeholderを差す場所がありません。この構成ならヘッドレス側の選択です。もう一つはDjangoが4.2以下で止まっている場合で、django CMS 5.0系を選ぶか本体の移行を先に済ませる順序になります。

WordPress・ヘッドレスCMS・Wagtailとの比較で決める軸

CMS選定そのものの考え方はCMSとは？仕組み・種類・WordPressとヘッドレスの違いと選び方を発注視点で解説にまとめてあります。ここでは、Djangoが既にある前提での比較に絞ります。

WordPressと比べて最後に残るのは運用体制の二重化コスト

機能面での比較は、実のところ勝負になりません。プラグイン数、日本語の運用情報、扱える制作会社の数、編集者の習熟度、どれもWordPressが上です。django CMSを選ぶ理由は、PHPとPythonの二系統を運用したくないという一点に尽きます。

サーバもデプロイもログ基盤も監視も二重になり、脆弱性情報も二系統を追うことになります。この二重化コストがCMSの機能差より大きいと判断できるときだけ、django CMSが勝ちます。コーポレートサイトが独立していて業務システムとデータを共有しないなら、WordPressサイト制作・CMS構築のようにWordPress側で組んで運用を分けたほうが素直です。

ヘッドレス構成は5.0以降のdjango CMS側でも組める

「ヘッドレスCMSを使いたいからdjango CMSは対象外」という判断は、5.0以降は成り立ちません。5.0でフルヘッドレス対応が入り、HTMLページを配信せずAPIだけを提供する構成が公式にサポートされています。HTMLとAPIを併用するハイブリッドも可能です。

APIを担うのがdjangocms-restで、1.0が2025年12月31日にリリースされました。Django REST Frameworkベースの読み取り専用REST/JSON APIで、OpenAPIスキーマを自動生成し、ページ・プラグイン・多言語コンテンツをJSONで返します。SaaS型との違いは、コンテンツが自社のデータベースに残り業務データと結合できる点です。製品比較はヘッドレスCMSとは？従来型CMSとの違い・主要サービス比較と選び方【2026年最新】を参照してください。月額課金とAPI呼び出し上限が無い代わりに運用は自分たちで見る、というトレードオフです。

Wagtailとの本質的な差はコンテンツ構造を誰が決めるかにある

Python製CMSのもう一方の柱がWagtailです。バージョン8.0が2026年8月25日にリリースされ、対応Djangoは5.2・6.0・6.1、対応Pythonは3.10から3.14でした。django CMS 5.1.2と対応マトリクスが完全に一致しており、この軸では差がつきません。

差が出るのは設計思想です。Wagtailは開発者がPythonのモデルでページ型を定義し、編集者はその型の穴を埋めます。構造は実装者が握るので、編集者がレイアウトを壊すことは起きません。django CMSはテンプレートのPlaceholderへ編集者がツールバーから部品を差す方式で、自由度は高い代わりに、放っておくとページの作りがばらつきます。

選び分けはこうです。ページの型が決まっていて数百ページ量産するメディアならWagtail。ページごとに構成が違い、編集者にレイアウトの裁量を渡す制作案件ならdjango CMS。既存のDjangoアプリをページ配下へマウントしたいなら、apphookを持つdjango CMSが素直に収まります。

受託開発の現場で採用を見送るべき条件と、それでも選ぶ判断の順序

ここまで構造と条件を並べましたが、受託開発の現場で実際に提案するかというと、見送る判断のほうが多くなります。理由を条件の形で示します。

この4条件のどれかひとつでも当たるなら採用は見送ると判断する

第一に、編集者が10人を超える、あるいは入れ替わりが年単位で起きる組織です。django CMSの日本語の運用情報は実質的に存在せず、新任担当者の教育コストを自社で持つ前提になります。WordPressなら書籍とWeb記事が代替する部分が、丸ごと内製コストとして乗ります。

第二に、保守フェーズの体制がPythonエンジニア1名以下になる案件です。4.0と5.1で二度の破壊的変更が入った実績があるとおり、このプロダクトは版を上げるたびに移行作業を要求します。3.11と4.1のEOLで移行を迫られた既存ユーザーの状況が、そのまま将来の自分たちの姿になりかねません。片手間の保守では追随できないでしょう。

第三に、コーポレートサイトが業務システムとデータを共有しない案件です。同居させる利点が消え、二系統運用を避けるという唯一の採用理由も消えます。

第四に、サードパーティ製プラグインへの依存を織り込んだ見積もりです。4.0でCMSAppConfigとCMSAppExtensionによる登録体系が導入され、cms_configへのcms_enabled = True指定が必須になりました。未対応のプラグインは動きません。エコシステムの規模はWordPressと二桁違うため、必要な部品は探せばあるという前提は置けず、自作する工数で見積もることになります。

それでも採用する価値が残る三つの場面と、最後に踏む判断の順序

逆に、次の条件が揃うなら採用します。ひとつめは、既にDjangoで業務システムが動き、その画面と地続きの公開サイトが必要な場合です。認証・権限・マスタデータを共有できる利点は、CMSの機能差を上回ります。

ふたつめは、Content Security Policyを厳密に運用する案件でしょう。5.0で編集モードのインラインJavaScriptが全廃され、厳密なCSPヘッダーの下でも編集画面が動くようになりました。この要件を満たすCMSは多くありません。金融・医療・公共系で効きます。

みっつめは、編集画面そのものを作り込みたい場合でしょう。プラグインはただのDjangoモデルとフォームなので、自社の業務語彙に合わせた部品を定義できます。5.1で追加されたallowed_modelsを使えば、特定のモデルにだけ使えるプラグインという制限もかけられます。汎用CMSのカスタムフィールドで無理やり表現するより、コードとして読める形に落ちる点が利点です。

判断の順序としては、まず「二系統運用を避ける必要があるか」を問い、次に「保守にPythonエンジニアを2名以上置けるか」を確認し、最後に「編集者が構造を壊さない運用ルールを敷けるか」を見ます。三つとも通ればdjango CMS、ひとつでも落ちるならWordPressかヘッドレスSaaS、という切り分けが実務的です。

よくある質問

django CMSとDjangoの違いは何ですか？

Djangoはフレームワーク、django CMSはその上に載せるアプリ群です。導入してもDjangoのモデル・ビュー・テンプレートはそのまま使え、既存のURLルーティングも生きています。追加されるのはページツリーの管理、編集者向けツールバー、Placeholderとプラグインによる本文編集の3つです。データベースも共用します。

WordPressから乗り換える価値はありますか？

公開サイト単体で見るなら、ありません。プラグイン数も日本語情報もWordPressが上で、乗り換えは純粋なコスト増です。価値が出るのは、同じ組織がDjangoの業務システムを動かし、サイトとシステムでユーザーやマスタを共有したいときだけになります。判断基準はPHPとPythonを二系統運用するコストの大小です。

既存のDjangoプロジェクトに後から入れられますか？

入れられます。manage.pyのある場所でdjangocmsコマンドをドット指定で実行すると、INSTALLED_APPS・ミドルウェア・CMS_TEMPLATES・ROOT_URLCONFへの追記が自動で行われます。実行前に--dry-runで差分を確認し、コミット済みの状態から作業してください。既存アプリの画面はapphookでページ配下へマウントできます。Django 5.2未満だと5.1系は入りません。

django CMSとWagtailはどちらを選ぶべきですか？

ページ構造を誰が決めるかで分かれます。実装者が型を定義して編集者が穴を埋める運用ならWagtail、テンプレートのスロットへ編集者が部品を差す運用ならdjango CMSです。既存アプリをページ配下へマウントしたい要件があるなら、apphookを持つdjango CMSが収まります。対応DjangoとPythonは2026年8月時点で同一のため、環境要件では選べません。

3.11や4.1のまま運用を続けても問題ありませんか？

セキュリティ修正が供給されないため、公開サイトで使い続けるのは避けてください。両系列とも2026年4月にサポートが終わり、最終パッチは3.11.11と4.1.11です。移行は3.11からなら4.1を経由して5.0へ、4.1からは5.0へ直接が公式の推奨で、4.0のPageContent分離をどこで受けるかが工数の山になります。計画はDjango本体のEOLと並べて引いてください。