Decap CMSとは：旧Netlify CMSの仕組みと導入手順、TinaCMSとの比較【3.17系】

Decap CMSは、HugoやAstroなどの静的サイトに、ブラウザで記事を書ける編集画面を後付けするオープンソースのCMSです。保存先はデータベースではなくGitリポジトリで、編集画面で「公開」を押すとMarkdownファイルがコミットされます。この記事では2026年11月時点の3.17系を前提に、admin/index.htmlとconfig.ymlの書き方、decap-serverを使ったローカルでの確認、Git Gatewayが非推奨になった後の認証方式の選び方を、コード付きで説明します。後半で扱うのはTinaCMSとの違いと、採用を見送るべき運用条件です。

まとめ：Decap CMSが向く案件と本番で使う認証方式の選び方

Decap CMSが向くのは、更新者が数名で、技術者がリポジトリを管理している静的サイトです。導入はadminフォルダに2ファイルを置くだけで、サーバーもデータベースも増えません。月額のライセンス費用もかかりません。

迷いやすいのは本番の認証です。Netlifyの公式ドキュメントはGit Gatewayを非推奨としているため、新規案件では選びません。編集者が開発者ならGitHubのOAuth、Gitアカウントを持たない広報担当が編集するなら3.17.0で一般提供になったDecap Turboを選ぶ、という分け方で決まります。React製のサイトで編集中の見た目をその場で確認したい場合は、TinaCMSの方が合います。

Decap CMSとは：Gitリポジトリを編集するCMSの仕組みと改名の経緯

管理画面は/adminで動くSPA、記事はMarkdownのままGitにコミット

Decap CMSの本体は、サイトの/adminに置くReact製のシングルページアプリです。編集者がブラウザで/admin/を開いてログインすると、GitホストのAPI経由でリポジトリ内のMarkdownやYAML、JSONを読み込み、フォーム形式で編集できるようにします。保存するとそのままコミットが作られ、Netlify・Cloudflare Pages・GitHub Actionsなど既存のビルドが動いて公開に反映されます。

記事の差分はコミット履歴に残り、ロールバックもgit revertで済みます。CMSそのものの定義や種類から整理したい場合は、CMSとは？仕組み・種類・WordPressとヘッドレスの違いで全体像を確認してください。

2023年2月にNetlify CMSから改名、最新版は3.17.3

Decap CMSは、Netlifyが開発していたNetlify CMSが2023年2月に別チームへ引き継がれ、改名したものです。GitHubのdecaporg/decap-cmsリポジトリはMITライセンスで、2026年11月2日時点のスター数は約1.9万でした。npmのnetlify-cmsパッケージは2022年4月の2.10.192で更新が止まっているため、古い記事のコードをそのまま写すと旧パッケージを入れてしまいます。

開発は続いています。公式のリリース一覧では、2026年10月14日に3.17.0、10月26日に3.17.3が公開されたことを確認できる一覧です。CDNで^3.0.0を指定していれば、3系の新しい版が自動で読み込まれます。

WordPressやヘッドレスCMSとの違いはデータベースとAPIサーバーを持たない点

WordPressはPHPとMySQLのサーバーを常時動かし、ContentfulやmicroCMSのようなAPI型のヘッドレスCMSは、ベンダーのデータベースにコンテンツを預けてAPIで取り出します。Decap CMSはどちらとも違い、コンテンツはリポジトリのファイルとしてサイトのソースコードと同じ場所にあります。

弱点は反映までの時間で、保存のたびにサイト全体のビルドが走ります。API型の料金や構成の比較はヘッドレスCMSとは？従来型との違い・料金比較とプレビュー実装に譲り、ここではDecap CMS固有の導入手順に進みます。

Decap CMSを静的サイトへ導入する手順：adminフォルダと設定ファイル

SSG別のadminフォルダ配置先：Hugoはstatic、Astroはpublic

公式のインストール手順で用意するのは、admin/index.htmlとadmin/config.ymlの2ファイルだけです。置き場所は、ビルド時にそのまま公開ディレクトリへコピーされる静的ファイル用フォルダになります。

• Hugo・Gatsby・SvelteKit・Docusaurus：static/admin/
• Next.js・Nuxt 3・Astro：public/admin/
• Jekyll：プロジェクトルートのadmin/
• 11ty：_site/admin/

表にないジェネレーターでも、CSSや画像を置くフォルダと同じ階層に置けば動きます。SSGそのものの仕組みと企業サイトでの採用判断はSSGとは？静的サイトジェネレーターの仕組みと企業サイト採用の判断基準を参照してください。Astroで組む場合の構成はAstroフレームワークとは？で触れています。

CDNからdecap-cms.jsを読み込む管理画面の最小構成

最小構成では、jsDelivrからスクリプトを1本読み込むだけで管理画面が立ち上がります。検索エンジンに管理画面を拾わせないよう、noindexも入れておきます。

<!-- static/admin/index.html（Hugoの場合） -->
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta name="robots" content="noindex" />
    <title>Content Manager</title>
  </head>
  <body>
    <script src="https://cdn.jsdelivr.net/npm/decap-cms@^3.0.0/dist/decap-cms.js"></script>
  </body>
</html>

プレビュー用のテンプレートやカスタムウィジェットを足すなら、npm install decap-cms-app --saveで入れてCMS.init()を呼ぶ形に切り替えます。npm版は読み込んだページ全体を置き換えるので、管理画面用のエントリーだけで読み込むようにしてください。

config.ymlでバックエンドとコレクション、記事のフィールドを定義する例

編集画面の入力欄は、すべてconfig.ymlのコレクション定義から作られます。下はGitHubのリポジトリにあるブログ記事を編集する例です。publish_modeは設定オプションのページにある通りsimpleかeditorial_workflowを指定します。

# static/admin/config.yml
backend:
  name: github
  repo: example-org/corporate-site   # owner/repo の形式
  branch: main                        # 省略すると master になる

publish_mode: editorial_workflow      # 下書き→レビュー→公開の3段階
media_folder: static/images/uploads  # アップロード画像の保存先
public_folder: /images/uploads       # 公開サイト上のパス

collections:
  - name: news
    label: お知らせ
    folder: content/news
    create: true
    slug: "{{year}}-{{month}}-{{day}}-{{slug}}"
    fields:
      - { label: タイトル, name: title, widget: string }
      - { label: 公開日, name: date, widget: datetime }
      - { label: アイキャッチ, name: thumbnail, widget: image, required: false }
      - { label: 本文, name: body, widget: richtext }

この設定で、content/news/2026-11-02-xxx.mdのようなファイルが作られ、フロントマターにtitle・date・thumbnailが入ります。branchを省略すると既定値はmasterなので、main運用のリポジトリでは必ず明記します。

markdownウィジェットは非推奨、新規のコレクションはrichtextで定義

本文欄のウィジェットは、2026年4月16日の公式ブログで方針が変わりました。Plateエディタを使うrichtextウィジェットが追加され、従来のmarkdownウィジェットは既存案件向けに残るものの非推奨で、積極的な保守は行われません。

移行作業はwidget: markdownをwidget: richtextに書き換えるだけで、他の設定項目はそのまま使えます。ただしrichtextはまだBeta扱いで、表示の細部が変わる可能性があると公式が明記しています。既存記事が多いサイトでは、表・脚注・HTML混在の記事を数本選び、書き換え前後でビルド結果の差分を確かめてから切り替えてください。

ローカルで編集画面を確かめる手順：decap-serverの起動と設定

npx decap-serverを8081番で起動しlocal_backendで接続

OAuthの準備をする前に、手元のリポジトリだけで編集画面を動かせます。Decap Proxyのドキュメントの手順では、config.ymlに1行足し、リポジトリのルートでプロキシを起動します。Node.jsは20以上が必要です。

# config.yml に追記
local_backend: true

# リポジトリのルートで実行（既定のポートは 8081）
npx decap-server

# 8081 が使用中なら PORT で変える
PORT=8082 npx decap-server

ポートを変えたときは、local_backendをurl: http://localhost:8082/api/v1のように書き換えます。SSGの開発サーバーを別に起動し、http://localhost:1313/admin/（Hugoの場合）を開くと、ログインなしで編集画面に入れます。保存した内容はディスク上のファイルに直接書かれるので、変更内容の確認にはgit diffを使ってください。

decap-serverは認証が無い、既定のfsモードでは承認フローも試せない

decap-serverのREADMEは、このプロキシに認証機能が無いことを明記しています。到達できる人は誰でもリポジトリのファイルを読み書きできるため、BIND_HOSTを0.0.0.0にして社内LANへ開くのは信頼できるネットワークの中だけにとどめます。

もう1つの制約は動作モードです。既定のMODEはfsで、ファイルを書き換えるだけでコミットはしません。前章のeditorial_workflowを手元で試すにはgitモードで起動する必要があり、このモードは編集のたびにコミットを作るので、作業中の変更を先にコミットかstashしておきます。

本番の認証方式を選ぶ：GitHub OAuthとDecap Turboの使い分け

Git GatewayはNetlify公式が非推奨、新規案件では採らない構成

Netlify CMS時代の定番は、Netlify IdentityでユーザーをログインさせGit Gateway経由でコミットする構成でした。編集者がGitHubアカウントを持たなくてよいのが利点です。しかしNetlifyのGit Gatewayのドキュメント（2026年9月17日更新）には「deprecated」と表示され、既存サイトでは動き続けるものの新規の設定は推奨しない、重大なセキュリティ問題以外のバグは直さない、と書かれています。

古い導入記事の多くはこの構成が前提です。既存サイトでも、次の2方式への移行を計画に入れてください。

githubバックエンドは編集者全員にpush権限とOAuthの中継が必要

バックエンドの一覧には、github・gitlab・gitea・forgejo・bitbucket・azure・git-gateway、それにturbo-githubとturbo-gitlabが並んでいます。開発者だけで更新するサイトなら、name: githubが最も単純です。

条件は2つあります。1つ目は、GitHubバックエンドのページにある通り、編集する人全員がリポジトリへのpush権限を持つこと。2つ目はOAuthの中継で、Netlifyでホストする場合はNetlifyの認証プロバイダー設定で済みますが、Cloudflare PagesやVercel、CloudFrontとS3で静的サイトを公開する構成では、/authと/callbackを処理するOAuthプロキシを自前で用意し、base_urlにそのURLを指定します。

Decap Turboは3.17.0でGA、Gitアカウント無しで編集者を招待できる

2026年10月16日の公式ブログによると、Decap公式のホスト型バックエンド「Decap Turbo」が3.17.0で一般提供になりました。編集者はメールで招待され、GitアカウントもNetlify Identityのアカウントも持たずにログインできます。GitHubやGitLabへのAPI呼び出しはTurboのプロキシがキャッシュするため、記事数が多いサイトでもAPIのレート制限に当たりにくくなります。

# config.yml（Decap Turbo を使う場合）
backend:
  name: turbo-github     # GitLab.com なら turbo-gitlab
  turbo_site_id: your-site-id

料金はFreeが1サイト1シート、Proが月額19ユーロで1サイト5シート、追加サイトは月額10ユーロ、追加シートは月額6ユーロです。対応するのはGitHubとGitLab.comで、セルフマネージドのGitLabは使えません。社内GitLabでソースを管理している企業は、この時点で候補から外れます。

editorial_workflowでプルリクエスト経由の承認フローを組む

publish_mode: editorial_workflowを指定すると、未公開の記事に「Draft・In review・Ready」の3段階のステータスが付きます。エディトリアルワークフローのドキュメントによると、下書きを保存するとcms/コレクション名/スラッグのブランチにコミットされてプルリクエストが作られ、「承認して公開」でマージとブランチ削除が行われます。広報が書いて法務がReadyにする、といった承認の流れを、Gitの履歴に残る形で運用できる仕組みです。

対応するのはgithub・gitlab・bitbucket・azure・forgejo・git-gateway・Decap Turboで、giteaバックエンドは非対応です。GitHubで履歴を1コミットにまとめたいときは、backendにsquash_merges: trueを足します。

Decap CMSとTinaCMSの比較：設定方式・プレビュー・料金で選び分ける

設定はYAMLかTypeScriptか、データ取得はファイル直読みかGraphQLか

TinaCMSの公式ドキュメントによると、TinaCMSもGitにMarkdown・MDX・JSONを保存するGitベースのCMSで、保存のたびにコミットを作る点はDecap CMSと同じです。違いは設定とデータの取り出し方にあります。

実務での分かれ目はプレビューです。Next.jsやAstro＋Reactのサイトで、編集者がページの見た目そのものを触りながら書きたいならTinaCMSが合います。HugoやJekyllのようにReactを使わないSSGなら、TinaCMSのビジュアル編集は使えないため、設定が軽いDecap CMSで十分です。

TinaCloudとDecap Turboの料金：編集者5名以下か6名以上かが分岐点

TinaCloudの料金ページでは、Freeが2ユーザーまで無料、Teamが1プロジェクトあたり月24ドルで3ユーザー込み・上限10ユーザー、Businessが月249ドルです。プルリクエスト経由の承認フロー（editorial workflow）はTeam以上でしか使えません。

Decap CMSはgithubバックエンドなら人数による課金が無く、承認フローも無料で使えます。編集者が全員GitHubアカウントを持てるなら、費用面ではDecap CMSが有利です。Gitアカウントを配れない編集者が6名以上になる場合は、Turbo Proの追加シート代とTinaCloud Teamの料金を同じ人数で並べて比べてください。

Decap CMSを採用する条件と見送る場面：更新頻度と編集者の顔ぶれで判断

採用する条件：週数回の更新で技術者がリポジトリを持つ企業サイト

Decap CMSを選んでよいのは、次の条件がそろう場合です。お知らせやブログの更新が週に数回程度で、ビルドに数分かかっても困らない。サイトのソースを自社か委託先の技術者がGitで管理している。編集者は数名で、GitHubのアカウントを配るかDecap Turboで招待できる。

この条件なら、WordPressのようなサーバー保守やプラグイン更新の手間が消えます。静的サイト構成の利点はJamstackとは？で整理しています。

見送る場面：日に何本も公開する多人数メディアと細かな権限管理

反対に、編集者が10名を超え、1日に何本も記事を公開するメディアには採用しません。保存のたびにビルドが走るため、記事数が数千本になるとビルド時間が公開の待ち時間になり、同時編集のコンフリクトもGitの操作として表に出ます。執筆者ごとにカテゴリ単位で権限を分けたい運用も苦手です。githubバックエンドではリポジトリへのpush権限の有無でしか分けられず、コレクション単位のロールはDecap Turboのカスタムロール（有料アドオン）が前提になります。

この規模なら、データベースを持つWordPressか、API型のヘッドレスCMS（StrapiやContentful）の方が運用は安定します。CMSの方式選びから構築・移行まで相談したい場合は、一創のWordPressサイト制作・CMS構築で、更新体制に合わせた構成を提案しています。

よくある質問

Decap CMSの導入前によく確認される5つの疑問に、2026年11月時点の公式情報をもとに答えます。

Decap CMSは無料で使えますか？

本体はMITライセンスのOSSで、商用サイトでも無料で使えます。githubやgitlabのバックエンドで自前の認証を用意する構成なら、ライセンス費用は発生しません。費用がかかるのは、公式のホスト型バックエンドDecap Turboを使う場合で、Freeは1サイト1シート、Proは月額19ユーロで5シートです。

Netlify CMSとDecap CMSの違いは何ですか？

同じソフトウェアで、2023年2月に開発が別チームへ移った際に名前が変わりました。設定ファイルの書き方はほぼ同じですが、npmのパッケージ名はnetlify-cmsからdecap-cms・decap-cms-appに変わっています。netlify-cmsは2022年4月の2.10.192が最終版なので、既存サイトで旧パッケージを読み込んでいる場合は、CDNのURLをdecap-cms@^3.0.0に差し替えるところから始めます。

Netlify以外のホスティングでもDecap CMSは使えますか？

Netlify以外のホスティングでも利用可能です。Cloudflare Pages・Vercel・GitHub Pages・S3などでも、管理画面自体は静的ファイルなので動作する仕組みです。必要になるのは認証の中継で、githubバックエンドなら/authと/callbackを処理するOAuthプロキシを用意し、base_urlに指定します。プロキシを運用したくない場合は、Decap Turboを使えばOAuthアプリの管理自体が不要になります。

Decap CMSは日本語の管理画面に対応していますか？

日本語の管理画面にも対応したCMSです。公式リポジトリのdecap-cms-localesにはjaを含む30以上の言語があり、config.ymlにlocale: jaと書いて切り替えます。既定は英語で、設定オプションのページは英語以外の言語をCMS.registerLocaleで登録するための手順を示したものです。翻訳が欠けた文言は英語で表示されます。コレクションやフィールドのlabelは自由な文字列なので、入力欄の見出しは日本語で書けます。

画像はどこに保存されますか？

既定ではmedia_folderで指定したリポジトリ内のフォルダにコミットされます。画像が増えるとリポジトリが重くなるため、写真の多いサイトではmedia_library設定でUploadcareなどの外部メディアライブラリにつなぐか、Decap TurboのProプラン以上で使えるS3互換のメディアライブラリ（Beta）を検討します。public_folderは公開サイト上のパスなので、SSGが静的ファイルを配信するパスと一致させてください。

関連記事

• ヘッドレスCMSとは？従来型との違い・料金比較とプレビュー実装：API型を含めたヘッドレスCMS全体の比較です
• CMSとは？仕組み・種類・WordPressとヘッドレスの違いと選び方：CMSの方式を発注前に整理できます
• SSGとは？静的サイトジェネレーターの仕組みと企業サイト採用の判断基準：Decap CMSと組み合わせるSSGの選び方です
• Jamstackとは？仕組み・メリットとデメリット：静的サイト＋Git運用の構成全体を理解できます
• Contentfulとは？API構成と料金の増え方・移行手順を実コードで解説：API型ヘッドレスCMSを選ぶ場合の比較対象です