・Payload CMSの採用を決める前に、弱点を知っておきたい
・公開した後に、誰が何をし続けるのかを見積もりたい
・4.0や公式クラウドの状況が、自社にどう響くかを知りたい
Payload CMSは、無料で使えて、Next.jsのアプリの中で動くCMSとして候補に挙がることが増えました。ところが導入の判断材料として語られるのは機能と作りやすさが中心で、公開した後に背負う仕事はあまり書かれていません。
Payload CMSの仕組みと料金は別記事で解説しています。この記事で最初に押さえたいのは、Payloadの弱点は機能の不足より、動かし続ける仕事をすべて自社で持つことだという点です。本記事では、合う組織と合わない組織、自社で用意するもの、更新と脆弱性への対応、4.0の影響、導入前のチェック表を、2026年10月時点の公式情報で整理します。
この記事のゴール(読了目安 約7分)
Payload CMSを導入した後に自社が持つ仕事を洗い出し、自社で回せるかを判断できるようになる。
Payloadが合う組織・合わない組織
合うのは開発者が社内にいる組織
Payloadは、入力欄の追加も版の更新も、開発者がコードを書き換えて行います。Postgresなどの関係データベースを使う場合は、項目を足すたびにデータベースの移行が必要です。この作業を社内で回せる組織であれば、データの形を自由に決められる利点を生かせます。
合わないのは記事を出すだけの組織
更新担当が画面の操作だけで回したい組織には、版を上げる人がいない時点で止まる作りです。記事を公開するだけなら、別の選択肢があります。WordPressとの比較は別記事で解説しています。
公式クラウドの停止と自社で用意するもの
Figmaへの参加後、公式クラウドは今も新しいプロジェクトの受け付けを止めたままです。既存の利用者は動き続けていますが、いずれ移行が要ると案内されており、再開の時期は示されていません。Next.jsが動くサーバーであれば、置き場所は自由に選べます。そのぶん本番の環境は自社で組む前提になり、公式は次の4つを別に用意するよう挙げています。

更新と脆弱性への対応
2025年12月には、ReactとNext.jsの重大な脆弱性について、Payloadの利用者にも影響しうると告知されました。2026年9月18日の3.90.0は重大なセキュリティ修正を含む版で、影響がなくても早く上げるよう案内されています。
9月18日から10月8日までにGitHubで公開されたセキュリティ勧告は39件で、うち6件が最も重い区分でした。いずれも3.90.0までの版で直っており、版を上げてあれば対応は済んでいます。版を上げるたびに要る作業は次のとおりです。
- リリースノートを読む: 自社に関係する変更と手順を確かめる
- 型を作り直す: 設定から生成する型の定義を更新する
- データベースを移行する: 関係データベースでは移行を作って流す
- 検証環境で試す: 本番の前に、同じ構成で動きを見る

4.0で変わること
2026年10月9日、次の4.0がベータ版になりました。動かすにはNode.jsは24.15.0以上、Next.jsは16.4.0以上が要り、サーバーの実行環境から上げ直すことになります。
権限の扱いも見直されました。サーバーの中から呼ぶLocal APIは、3.xでは既定で権限の確認を飛ばしますが、4.0では確かめる側に変わります。移行ガイドによると、呼び出しを書き換えないままでもコンパイルは通り、動きだけが変わります。
書き換えを自動で行う道具も公開されています。正式版の時期は発表されていないため、今から導入するなら3.xで始めて、4.0への移行を予定に入れておきます。

管理画面の日本語と引き継ぎ
初期状態の管理画面は英語表示です。公式の翻訳パッケージを入れ、設定で日本語を読み込むと、ボタンやメニューが日本語になります。読み込んでいない言語のブラウザでは英語に戻ります。記事の中身を複数の言語で持つ機能は、画面の言語とは別の設定です。
編集担当に渡す前に、日本語の設定を入れた状態で、実際の入力画面を担当者に触ってもらうと、引き継ぎで迷う所が先に見つかります。
開発者がいなくなったときのリスク
Payloadでは、入力欄の定義も、使う版も、対応するNext.jsの範囲も、すべてコードの中にあります。作った開発者が抜けると、入力欄を1つ足すことも、脆弱性の修正を当てることも止まります。
3.xでは、対応するNext.jsの版も範囲で決まっています。Next.jsだけを上げることもできないため、担当が抜けた時点の版で固まりがちです。
手当ては3つです。版を上げる手順を文書にしておくこと、2人以上がコードに触れる状態にしておくこと、社内で持てない場合の保守の委託先を決めておくことです。
導入前チェック
採用を決める前に、次の6つに答えを書けるかを確かめます。
1つでも空欄が残るなら、その項目を埋めてから採用を決めます。
【プロの視点】作る速さより版を上げる手間
Payloadの導入は、機能と作る速さで語られがちです。確かに作るのは速く、waltsuがメディアサイトの試作をPayloadで組んだときは、片手間で1時間もかかりませんでした。
ところが、導入の判断を分けるのは公開した後です。3.90.0では、型の作り直しとデータベースの移行を伴う更新が出ました。4.0では実行環境も権限の既定も変わります。AIで作るのが速くなるほど、作る日数では差がつかず、動かし続ける体制の差がはっきり出ます。版の更新と脆弱性への対応を担い、AIの書いたコードを読んで止められる人がいるかどうかです。見積もるべきは作る日数より、1年に何回版を上げ、1回に何をするかです。
明日やる最初の一歩は、直近3か月のリリースノートを読み、自社の構成で必要になる作業を数えることです。

【waltsu視点】自社で回せるかの線引き
版の更新は、溜めるほど1回の確認が重くなります。小さく刻んで上げれば、1回で確かめる範囲が狭くなり、直して出し直す回数を重ねられます。waltsuが導入の相談で最初に聞くのは、その更新を誰が刻むかです。
waltsuが受けない依頼
- 更新の担当がいないまま自社で動かす依頼: 公開後の版の更新と脆弱性への対応を、誰も担当しない形でPayloadを自社で動かす依頼は受けていません
他社を薦める場合
- 記事を公開するだけのブログ: microCMSのようなクラウド型のヘッドレスCMSを薦めます。本体の運用と更新を提供側が持ち、全プランに標準的なWAFがあり、AIエージェントとつなぐ仕組み(ベータ版)も無料プランから使えます
よくある質問
Payload CMSのデメリットは?
本体は無料ですが、サーバーや版の更新、脆弱性への対応をすべて自社で持つ点です。公式のクラウドも新規の受け付けを止めています。
開発者がいなくても運用できる?
記事の入力は画面でできますが、入力欄の追加や版の更新はコードの作業です。開発者がいない体制では止まります。
公式クラウドはいつ再開する?
2026年10月時点で、再開の時期は示されていません。公式は、移行先となる仕組みを準備中と案内しています。
4.0にはすぐ上げるべき?
2026年10月時点ではベータ版です。本番は3.xの最新を保ち、検証環境で4.0を試すのが安全です。
脆弱性の情報はどこで見る?
公式ブログのお知らせと、GitHubのセキュリティ勧告に出ます。勧告には影響する版と、直った版が書かれています。
この記事の要点
・Payloadの弱点は、動かし続ける仕事をすべて自社で持つこと
・公式クラウドは新規停止中で、データベースなど4つを自社で用意する
・3.90.0は重大な修正を含み、型の作り直しや移行を伴った
・4.0は実行環境と権限の既定が変わるため、移行を予定に入れる
移行の向き不向きの相談
今のCMSからPayloadへ移すかどうかを決めかねている場合は、次の4点で相談を受け付けています。
- 渡すもの: 今のCMSの構成(使っている機能、入力欄、つないでいるデータ)
- 返ってくるもの: Payloadへの移行の向き不向き
- いつまでに: 依頼をいただいてから5営業日
- その後: 結果をもとにした打合せ
相談は相談の依頼フォームからお送りください。
まとめ
Payload CMSは無料で作りやすい一方、公式クラウドが止まっている今は、データベースなどの用意から版の更新、脆弱性への対応までを自社で持ちます。4.0では実行環境と権限の既定も変わります。
採用を決める前に、導入前チェックの6項目に答えを書き、版を上げる担当を決めてください。自社で回せるかの判断に迷ったときは、今の構成をもとにwaltsuが移行の向き不向きをお返しします。
