---
title: "Decap CMSとは：旧Netlify CMSの仕組みと導入手順、TinaCMSとの比較【3.17系】"
url: "https://www.issoh.co.jp/tech/details/19200/"
published: 2026-11-02
updated: 2026-11-02
categories: ["開発"]
publisher: "株式会社一創"
---

# 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とヘッドレスの違い](https://www.issoh.co.jp/column/details/15425/)で全体像を確認してください。

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

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

開発は続いています。[公式のリリース一覧](https://github.com/decaporg/decap-cms/releases)では、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はどちらとも違い、コンテンツはリポジトリのファイルとしてサイトのソースコードと同じ場所にあります。

| 観点        | Decap CMS     | API型ヘッドレスCMS | WordPress    |
| --------- | ------------- | ------------ | ------------ |
| コンテンツの置き場 | Gitリポジトリのファイル | ベンダーのDB      | 自社サーバーのMySQL |
| 常時動くサーバー  | 不要            | ベンダー側        | 必要           |
| 反映までの時間   | ビルド完了まで       | API取得なら即時    | 即時           |
| ライセンス費用   | 無料（MIT）       | プラン課金        | 無料（GPL）      |

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

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

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

[公式のインストール手順](https://decapcms.org/docs/install-decap-cms/)で用意するのは、`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とは？静的サイトジェネレーターの仕組みと企業サイト採用の判断基準](https://www.issoh.co.jp/column/details/17699/)を参照してください。Astroで組む場合の構成は[Astroフレームワークとは？](https://www.issoh.co.jp/tech/details/15369/)で触れています。

### 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`は[設定オプションのページ](https://decapcms.org/docs/configuration-options/)にある通り`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日の[公式ブログ](https://decapcms.org/blog/richtext-widget-replaces-markdown-widget/)で方針が変わりました。Plateエディタを使う`richtext`ウィジェットが追加され、従来の`markdown`ウィジェットは既存案件向けに残るものの非推奨で、積極的な保守は行われません。

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

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

### npx decap-serverを8081番で起動しlocal\_backendで接続

OAuthの準備をする前に、手元のリポジトリだけで編集画面を動かせます。[Decap Proxyのドキュメント](https://decapcms.org/docs/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](https://github.com/decaporg/decap-cms/blob/main/packages/decap-server/README.md)は、このプロキシに認証機能が無いことを明記しています。到達できる人は誰でもリポジトリのファイルを読み書きできるため、`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のドキュメント](https://docs.netlify.com/manage/security/secure-access-to-sites/git-gateway/)（2026年9月17日更新）には「deprecated」と表示され、既存サイトでは動き続けるものの新規の設定は推奨しない、重大なセキュリティ問題以外のバグは直さない、と書かれています。

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

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

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

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

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

2026年10月16日の[公式ブログ](https://decapcms.org/blog/decap-turbo-generally-available/)によると、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段階のステータスが付きます。[エディトリアルワークフローのドキュメント](https://decapcms.org/docs/editorial-workflows/)によると、下書きを保存すると`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の公式ドキュメント](https://tina.io/docs)によると、TinaCMSもGitにMarkdown・MDX・JSONを保存するGitベースのCMSで、保存のたびにコミットを作る点はDecap CMSと同じです。違いは設定とデータの取り出し方にあります。

| 観点         | Decap CMS 3.17系 | TinaCMS 3.15系        |
| ---------- | --------------- | -------------------- |
| スキーマ定義     | YAMLファイル        | TypeScriptファイル       |
| サイト側のデータ取得 | SSGがファイルを直接読む   | 生成されたGraphQLクライアント   |
| 編集中の見た目    | 横にプレビュー欄        | React製サイトならページ上で直接編集 |
| ライセンス      | MIT             | Apache-2.0           |

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

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

[TinaCloudの料金ページ](https://tina.io/pricing)では、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とは？](https://www.issoh.co.jp/column/details/3121/)で整理しています。

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

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

この規模なら、データベースを持つWordPressか、API型のヘッドレスCMS（[Strapi](https://www.issoh.co.jp/tech/details/8082/)や[Contentful](https://www.issoh.co.jp/tech/details/17724/)）の方が運用は安定します。CMSの方式選びから構築・移行まで相談したい場合は、一創の[WordPressサイト制作・CMS構築](https://www.issoh.co.jp/service/web/wordpress/)で、更新体制に合わせた構成を提案しています。

## よくある質問

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とは？従来型との違い・料金比較とプレビュー実装](https://www.issoh.co.jp/tech/details/1317/)：API型を含めたヘッドレスCMS全体の比較です
- [CMSとは？仕組み・種類・WordPressとヘッドレスの違いと選び方](https://www.issoh.co.jp/column/details/15425/)：CMSの方式を発注前に整理できます
- [SSGとは？静的サイトジェネレーターの仕組みと企業サイト採用の判断基準](https://www.issoh.co.jp/column/details/17699/)：Decap CMSと組み合わせるSSGの選び方です
- [Jamstackとは？仕組み・メリットとデメリット](https://www.issoh.co.jp/column/details/3121/)：静的サイト＋Git運用の構成全体を理解できます
- [Contentfulとは？API構成と料金の増え方・移行手順を実コードで解説](https://www.issoh.co.jp/tech/details/17724/)：API型ヘッドレスCMSを選ぶ場合の比較対象です

---

出典: [Decap CMSとは：旧Netlify CMSの仕組みと導入手順、TinaCMSとの比較【3.17系】](<https://www.issoh.co.jp/tech/details/19200/>)（株式会社一創）