# Payload CMSの導入前に知っておきたい注意点｜デメリットと確認表

- URL: https://www.waltsu.co.jp/magazine/website/payload-cms-before-adopting/
- カテゴリ: Webサイト > CMS
- 執筆: 藤井 俊輔（代表取締役）
- 公開日: 2026-10-14 / 最終更新日: 2026-10-29
- 発行: waltsu株式会社（waltsu MAGAZINE）

## こんな人におすすめ

- Payload CMSの採用を決める前に、弱点を知っておきたい
- 公開した後に、誰が何をし続けるのかを見積もりたい
- 4.0や公式クラウドの状況が、自社にどう響くかを知りたい

Payload CMSは、無料で使えて、Next.jsのアプリの中で動くCMSとして候補に挙がることが増えました。ところが導入の判断材料として語られるのは機能と作りやすさが中心で、公開した後に背負う仕事はあまり書かれていません。 Payload CMSの仕組みと料金は別記事で解説しています。この記事で最初に押さえたいのは、Payloadの弱点は機能の不足より、動かし続ける仕事をすべて自社で持つことだという点です。本記事では、合う組織と合わない組織、自社で用意するもの、更新と脆弱性への対応、4.0の影響、導入前のチェック表を、2026年10月時点の公式情報で整理します。

**この記事のゴール（読了目安 約7分）**：Payload CMSを導入した後に自社が持つ仕事を洗い出し、自社で回せるかを判断できるようになる。

## この記事の結論

- Payloadの弱点は、動かし続ける仕事をすべて自社で持つこと
- 公式クラウドは新規停止中で、データベースなど4つを自社で用意する
- 3.90.0は重大な修正を含み、型の作り直しや移行を伴った
- 4.0は実行環境と権限の既定が変わるため、移行を予定に入れる

## Payloadが合う組織・合わない組織

分かれ目は、入力欄の追加や版の更新を社内の開発者で回せるかです。回せる組織には合い、画面の操作だけで記事を出したい組織には合いません。

### 合うのは開発者が社内にいる組織

Payloadは、入力欄の追加も版の更新も、開発者がコードを書き換えて行います。Postgresなどの関係データベースを使う場合は、**[項目を足すたびにデータベースの移行が必要](https://payloadcms.com/docs/database/migrations)**です。この作業を社内で回せる組織であれば、データの形を自由に決められる利点を生かせます。

### 合わないのは記事を出すだけの組織

更新担当が画面の操作だけで回したい組織には、**版を上げる人がいない時点で止まる**作りです。記事を公開するだけなら、別の選択肢があります。WordPressとの比較は別記事で解説しています。

## 公式クラウドの停止と自社で用意するもの

Figmaへの参加後、[公式クラウド](https://payloadcms.com/payload-has-joined-figma)は今も**新しいプロジェクトの受け付けを止めたまま**です。既存の利用者は動き続けていますが、いずれ移行が要ると案内されており、再開の時期は示されていません。Next.jsが動くサーバーであれば、置き場所は自由に選べます。そのぶん本番の環境は自社で組む前提になり、公式は[次の4つを別に用意する](https://payloadcms.com/docs/production/deployment)よう挙げています。

| 用意するもの | 使い道 | 決めておくこと |
|---|---|---|
| データベース | 記事や利用者のデータ | バックアップの取り方 |
| ファイル置き場 | 画像やPDF | 保存先と容量 |
| メール | パスワード再設定などの通知 | 送信に使うサービス |
| 配信網 | 画像やページの配信 | 古い表示の消し方 |

![データベース、ファイル置き場、メール、配信網の4つを、使い道と決めておくことともに2列2段のカードで並べた図](https://www.waltsu.co.jp/wp-content/uploads/2026/10/payload-cms-before-adopting01.png)  
*公式クラウドが新規停止中のため、データベースなど4つを自社で用意し、それぞれの決めごとを先に置く。*

## 更新と脆弱性への対応

2025年12月には、[ReactとNext.jsの重大な脆弱性](https://payloadcms.com/posts/blog/critical-security-notice-affecting-react-19-and-nextjs)について、Payloadの利用者にも影響しうると告知されました。[2026年9月18日の3.90.0](https://github.com/payloadcms/payload/releases/tag/v3.90.0)は**重大なセキュリティ修正を含む版**で、影響がなくても早く上げるよう案内されています。

9月18日から10月8日までに[GitHubで公開されたセキュリティ勧告](https://github.com/payloadcms/payload/security/advisories)は39件で、うち6件が最も重い区分でした。いずれも3.90.0までの版で直っており、版を上げてあれば対応は済んでいます。版を上げるたびに要る作業は次のとおりです。

- **リリースノートを読む**: 自社に関係する変更と手順を確かめる
- **型を作り直す**: 設定から生成する型の定義を更新する
- **データベースを移行する**: 関係データベースでは移行を作って流す
- **検証環境で試す**: 本番の前に、同じ構成で動きを見る

![2025年12月の脆弱性の告知、2026年9月18日の3.90.0、9月18日から10月8日までのセキュリティ勧告39件、10月9日の4.0ベータを並べた年表](https://www.waltsu.co.jp/wp-content/uploads/2026/10/payload-cms-before-adopting02.png)  
*重大な修正を含む3.90.0のあとも勧告の公開が続き、10月には実行環境と権限が変わる4.0がベータになった。*

## 4.0で変わること

2026年10月9日、次の[4.0がベータ版](https://github.com/payloadcms/payload/releases/tag/v4.0.0-beta.0)になりました。動かすには[Node.jsは24.15.0以上、Next.jsは16.4.0以上](https://payloadcms.com/docs/beta/getting-started/installation)が要り、**サーバーの実行環境から上げ直す**ことになります。

権限の扱いも見直されました。サーバーの中から呼ぶLocal APIは、3.xでは[既定で権限の確認を飛ばします](https://payloadcms.com/docs/local-api/overview)が、4.0では確かめる側に変わります。[移行ガイド](https://payloadcms.com/docs/beta/migration-guide/v4)によると、呼び出しを書き換えないままでもコンパイルは通り、動きだけが変わります。

書き換えを自動で行う道具も公開されています。正式版の時期は発表されていないため、今から導入するなら3.xで始めて、4.0への移行を予定に入れておきます。

![左に3.x、右に4.0を置き、Node.jsとNext.jsの必要な版、Local APIの権限の既定の違いを3項目ずつ並べた左右比較の図](https://www.waltsu.co.jp/wp-content/uploads/2026/10/payload-cms-before-adopting03.png)  
*4.0では必要なNode.jsとNext.jsの版が上がり、Local APIは既定で権限を確かめる動きに変わる。*

## 管理画面の日本語と引き継ぎ

初期状態の管理画面は英語表示です。[公式の翻訳パッケージ](https://payloadcms.com/docs/configuration/i18n)を入れ、設定で日本語を読み込むと、ボタンやメニューが日本語になります。読み込んでいない言語のブラウザでは英語に戻ります。[記事の中身を複数の言語で持つ機能](https://payloadcms.com/docs/configuration/localization)は、画面の言語とは別の設定です。

編集担当に渡す前に、**日本語の設定を入れた状態で、実際の入力画面を担当者に触ってもらう**と、引き継ぎで迷う所が先に見つかります。

## 開発者がいなくなったときのリスク

Payloadでは、[入力欄の定義](https://payloadcms.com/docs/getting-started/what-is-payload)も、使う版も、対応するNext.jsの範囲も、すべてコードの中にあります。作った開発者が抜けると、**入力欄を1つ足すことも、脆弱性の修正を当てることも止まります**。

3.xでは、[対応するNext.jsの版も範囲で決まっています](https://payloadcms.com/docs/getting-started/installation)。Next.jsだけを上げることもできないため、担当が抜けた時点の版で固まりがちです。

手当ては3つです。版を上げる手順を文書にしておくこと、2人以上がコードに触れる状態にしておくこと、社内で持てない場合の[保守の委託先](https://www.waltsu.co.jp/service/website/)を決めておくことです。

## 導入前チェック

採用を決める前に、次の6つに答えを書けるかを確かめます。

| 項目 | 確かめること |
|---|---|
| 版を上げる担当 | 名前と、上げる頻度 |
| 脆弱性の情報 | 誰がどこで、どの間隔で見るか |
| 動かす場所 | データベース・ファイル置き場・メール・配信網 |
| 4.0への移行 | いつ、誰が試すか |
| 管理画面の言語 | 日本語の設定と、担当者の確認 |
| 引き継ぎ先 | 開発者が抜けたときに頼む先 |

1つでも空欄が残るなら、その項目を埋めてから採用を決めます。

## 【プロの視点】作る速さより版を上げる手間

Payloadの導入は、機能と作る速さで語られがちです。確かに作るのは速く、waltsuがメディアサイトの試作をPayloadで組んだときは、片手間で1時間もかかりませんでした。

ところが、導入の判断を分けるのは公開した後です。3.90.0では、型の作り直しとデータベースの移行を伴う更新が出ました。4.0では実行環境も権限の既定も変わります。AIで作るのが速くなるほど、作る日数では差がつかず、動かし続ける体制の差がはっきり出ます。版の更新と脆弱性への対応を担い、AIの書いたコードを読んで止められる人がいるかどうかです。**見積もるべきは作る日数より、1年に何回版を上げ、1回に何をするか**です。

明日やる最初の一歩は、直近3か月のリリースノートを読み、自社の構成で必要になる作業を数えることです。

![左に作るときの手間、右に動かし続けるときの手間を置き、試作は1時間以内でも、版を上げるたびに作業が続くことを比べた図](https://www.waltsu.co.jp/wp-content/uploads/2026/10/payload-cms-before-adopting04.png)  
*作るのは速くても、版を上げるたびに型の作り直しや移行が続くため、見積もるのは動かし続ける側の手間になる。*

## 【waltsu視点】自社で回せるかの線引き

版の更新は、溜めるほど1回の確認が重くなります。小さく刻んで上げれば、1回で確かめる範囲が狭くなり、直して出し直す回数を重ねられます。waltsuが導入の相談で最初に聞くのは、その更新を誰が刻むかです。

### waltsuが受けない依頼

- **更新の担当がいないまま自社で動かす依頼**: 公開後の版の更新と脆弱性への対応を、誰も担当しない形でPayloadを自社で動かす依頼は受けていません

### 他社を薦める場合

- **記事を公開するだけのブログ**: [microCMS](https://microcms.io/)のようなクラウド型の[ヘッドレスCMS](https://www.waltsu.co.jp/magazine/website/headless-cms/)を薦めます。本体の運用と更新を提供側が持ち、[全プランに標準的なWAF](https://microcms.io/features/security)があり、[AIエージェントとつなぐ仕組み（ベータ版）も無料プランから使えます](https://microcms.io/mcp-server)

## 移行の向き不向きの相談

今のCMSからPayloadへ移すかどうかを決めかねている場合は、次の4点で相談を受け付けています。

- **渡すもの**: 今のCMSの構成（使っている機能、入力欄、つないでいるデータ）
- **返ってくるもの**: Payloadへの移行の向き不向き
- **いつまでに**: 依頼をいただいてから5営業日
- **その後**: 結果をもとにした打合せ

相談は[相談の依頼フォーム](https://www.waltsu.co.jp/form-contact/)からお送りください。

## まとめ

Payload CMSは無料で作りやすい一方、公式クラウドが止まっている今は、データベースなどの用意から版の更新、脆弱性への対応までを自社で持ちます。4.0では実行環境と権限の既定も変わります。

採用を決める前に、導入前チェックの6項目に答えを書き、版を上げる担当を決めてください。自社で回せるかの判断に迷ったときは、今の構成をもとにwaltsuが移行の向き不向きをお返しします。

## よくある質問

**Q. Payload CMSのデメリットは？**  
A. 本体は無料ですが、サーバーや版の更新、脆弱性への対応をすべて自社で持つ点です。公式のクラウドも新規の受け付けを止めています。

**Q. 開発者がいなくても運用できる？**  
A. 記事の入力は画面でできますが、入力欄の追加や版の更新はコードの作業です。開発者がいない体制では止まります。

**Q. 公式クラウドはいつ再開する？**  
A. 2026年10月時点で、再開の時期は示されていません。公式は、移行先となる仕組みを準備中と案内しています。

**Q. 4.0にはすぐ上げるべき？**  
A. 2026年10月時点ではベータ版です。本番は3.xの最新を保ち、検証環境で4.0を試すのが安全です。

**Q. 脆弱性の情報はどこで見る？**  
A. 公式ブログのお知らせと、GitHubのセキュリティ勧告に出ます。勧告には影響する版と、直った版が書かれています。

## 執筆者

**藤井 俊輔**（代表取締役）ベンチャー企業の外部CMOや水族館のマーケティング担当などに従事。オンライン/オフライン問わず集客を中心としたマーケティング施策に強み。

プロフィール: https://www.waltsu.co.jp/magazine/supervisor/shunsuke-fujii/

この記事は waltsu 公式ブログの記事（https://www.waltsu.co.jp/blog/payload-cms-before-adopting/）をもとに再編集したものです。