去年の 10 月、あるクライアントから少し慌てた様子で電話がかかってきました。彼らはマーケティングプラットフォーム全体をホスト型 CMS で構築していたのですが、ベンダーが突然料金体系を見直すと発表したのです。一晩にして、請求額は月額 £180 から £900 を超える金額に跳ね上がったのです。コンテンツは複雑ではありませんでした。ブログ、商品カタログ、3 つのコレクション全体にわたる約 40 個のカスタムフィールド。その金額を正当化するものは何もありませんでした。その電話がきっかけで、次の 3 ヶ月間、2 つの Seahawk プロジェクトを Payload CMS に移行し、それを中心に適切なコスト モデルを構築することになったのです。
では、実際に何が分かったのかをお話しします。
Payload CMS が実際に何であるか（そしてそうでないか）
Payload は TypeScript ファーストで、コード駆動型のヘッドレス CMS です。コレクション、グローバル、フィールドをすべて設定ファイルで定義します。スキーマ設計のためにクリックする GUI はありません。管理パネルはコードから生成され、その逆ではありません。この反転がポイントそのものであり、また WordPress や Contentful から移行してくる場合は、あなたをつまずかせる原因にもなります。
これは SaaS ではありません。月額料金を払う Payload ホスト型のティアはありません。デプロイメント全体を自分で所有します。これは状況に応じた機能でもあり、制約でもあります。
Payload 2.0 は MongoDB と並行して PostgreSQL の完全なサポートを提供開始し、NoSQL の複雑な操作なしにリレーショナルデータを望むクライアントにとって、本当に実行可能なものになったのです。2026 年初頭までに、周辺のエコシステムが成熟し、以前のような注釈を付けずに本番環境での利用を確信を持って推奨できるようになりました。
実際に何の上に構築されているか
内部的には、管理 UI に Next.js 15、全体を通じて TypeScript、Postgres 用の Drizzle ORM または MongoDB 用の Mongoose を選択できます。REST と GraphQL API はスキーマから自動生成されます。また、毎回まだ驚かせてくれる速さを持つサーバーサイドクエリ用のローカル API も利用できます。
2026 年のどこに適合するか
正直に言うと、Payload は特定のスイートスポットに位置しています。すべてのプロジェクトがそこに属するわけではありません。Seahawk を通じて 1 ダース以上のビルドで実行した後、気付いたパターンを紹介します。
以下の場合は強力な適合です：
- プロジェクトが最初からデベロッパー主導である。つまり、本当のエンジニアが設定しており、「自分たちで全て管理できる」と言われたクライアントではないということです。
- カスタムフィールドロジック、条件付きフィールド、または Contentful のようなもので機能ごとの料金として高い代償を払うような複雑なリレーションシップチェーンが必要です。
- クライアントが 2 〜 3 年の時間軸で費用に敏感である。数学上、Payload の方が 14 ヶ月目以降はほぼ常に有利になります。
- すでに Next.js または Node アプリケーションを実行していて、CMS を同じ場所に配置するか、少なくともインフラストラクチャを共有したいと考えています。
以下の場合は不適切です：
- クライアントが非技術者であり、エンジニアサポートなしに新しいコンテンツタイプを設定する必要があります。
- 完全に引き継ぐ必要があり、受け取る側にデベロッパーがいないものを構築しています。
- 本番公開まで2週間未満で、クローンする準備ができたPayloadプロジェクトスキャフォルドがない。
その2番目のポイントは身をもって学びました。2022年にPayload(当時はv1)で小規模なチャリティサイトをスコープしました。計画は社内のボランティアコーディネーターに引き継ぐというものでした。3ヶ月後、フィールドが表示されない理由についてWhatsAppのメッセージをまだ受け取っていました。CMSは技術的にはプロジェクトに間違っていませんでした。ハンドオフモデルが間違っていたのです。
Payloadを2026年に実行するための実際のコスト
これはほとんどのブログ記事がスキップするか、曖昧な範囲で粉飾する部分です。実際に実行してきた数字をお見せします。
インフラストラクチャ
Nodeサーバーをホストする場所とデータベースを保存する場所が必要です。それらは2つのハードコストです。
オプションA: Railway 中程度のトラフィック未満のほとんどのPayloadプロジェクトでRailwayを使用しています。典型的なPayloadアプリ(Nodeサービス + Postgresインスタンス)は使用状況に応じて月額12〜35ドルで実行されます。編集コンテンツを含むマーケティングサイトの場合、ほぼ確実に月額15〜20ドルの範囲内です。デプロイはGitHubリポジトリから簡単で、Postgresのバックアップは自動です。
オプションB: Render Railwayと同様の価格設定です。無料ティアは存在しますが、本番環境に使用しないでください(コールドスタートはクライアントの前であなたに恥をかかせます)。有料プランはWebサービスで月額7ドル、マネージドPostgresで月額7ドルから始まります。したがって最低でも月額約14ドル、トラフィックが増えるにつれてCPUとメモリでスケーリングします。
オプションC: 自己管理VPS 複数のPayloadプロジェクトを実行している場合、DigitalOceanまたはHetzner VPSが魅力的に見え始めます。Hetzner CX32(4vCPU、8GB RAM)は月額€8.29で、Nginxプロキシの背後で3〜4つのPayloadインスタンスを快適に実行できます。小規模クライアント向けの共有Postgresインスタンスを同じボックスで実行します。気が弱い人向けではありませんが、完全に安定しています。
メディアストレージ
Payloadはストレージアダプターを設定しない限り、画像を処理しません。本番環境で使用した2つは次のとおりです。
- スケーリングに関しては、AWS S3 + CloudFront。典型的なマーケティングサイトの場合、月額5〜15ドルの予算を計画します。
- S3互換ストレージとしてのCloudflare R2で、エグレス料金がゼロです。これが私のデフォルトになりました。約50GBのメディアアセットをプッシュしているサイトの場合、エグレスではほぼ何も支払わず、ストレージで月額約1.50ドルを支払っています。payload-cloud-storageプラグインを使用してR2をポイントします。
開発者時間(人々が忘れるコスト)
認証、メディア、クライアントが必要なコレクション、そして合理的なアクセス制御モデルで適切にスキャフォルドされたPayloadプロジェクトの初期設定:経験豊富な開発者の場合は12〜20時間の予算。これはオプションの複雑さではなく、コードファーストCMSの性質です。1日の料金が£400〜600(ロンドン中堅フリーランス)の場合、フロントエンドコードの行を書く前に£4,800〜12,000の前払いです。
Contentfulスペースを立ち上げて、3時間でUIを通じてコンテンツタイプを設定することと比較してください。前払いコストは実際です。継続的なコストはPayloadが勝つ場所です。
総所有コスト、1年目対3年目
Railwayに関するPayloadと、ContentfulのGrowthプランを比較するための中規模マーケティングサイトのラフモデルは次のとおりです。
- Payload on Railway、1年目: £18/月のインフラ + 約£5,000のセットアップ時間 = 合計約£5,216
- Payload on Railway、3年目: £18/月のインフラ + 最小限のメンテナンス = 3年目のインフラで約£648
- Contentful Growthプラン、1年目: £320/月 = £3,840、カスタムセットアップコストなし
- Contentful Growthプラン、3年目: £320/月 = 再度£3,840
クロスオーバーは1日のレートに応じて月20〜22日目のどこかで発生します。その後、Payloadは実質的に安くなります。2028年に同じサイトを実行するクライアントにとって、これは重要です。
正直な用語での開発者エクスペリエンス
Payload での仕事は心から楽しめます。config-as-code のアプローチにより、スキーマはバージョン管理され、プルリクエストでレビュー可能で、他のコード変更と同じようにデプロイできます。それだけで、コンテンツモデラーが GUI をクリックしていて、誰も実際の変更内容やタイミングを把握していない CMS ツールより優れています。
TypeScript の推論は優れています。コレクション型がローカル API クエリにシームレスに流れ込み、手動の型生成ステップは不要です。Seahawk は昨年、深くネストされた関係データをクエリするフィンテック向けコンテンツプロジェクトを進めており、型安全性がステージング環境に到達する前にデータ形状のバグを 2 つ検出しました。これは大きな役割を果たします。
管理画面はクリーンで高速です。派手さはなく、機能的です。フィールドにラベルが適切に付いていれば、技術者以外のエディターは通常 1〜2 回のセッション内で使い慣れます。もう 1 つ強調したいのは Hooks です。before-change、after-read といったライフサイクルフックにより、データレイヤーで処理できることが増え、カスタム API ミドルウェアを構築する必要がなくなります。
粗い部分
マイグレーション。Postgres を使用していてスキーマを変更する場合、Drizzle マイグレーションを実行する必要があります。やり方を知っていれば問題ありませんが、知らないと少し怖いです。Seahawk の下請け契約の ジュニア開発者がマイグレーション差分をきちんと読まずにカラムを削除してしまったことがあります。常にレビューし、必ず先にバックアップを取ってください。
プラグインエコシステムは WordPress より小さいのは明らかです。ただし、Payload プラグインディレクトリは大幅に成長しています。フォームビルダー、ネストされたドキュメント、SEO フィールド、リダイレクト。重要な部分はカバーされています。確立されたプラットフォームより多くのカスタムコードを書くことになります。
他の Headless オプションとの比較
別のものを選ぶべきケースをはっきり申し上げます。
コンテンツチームが大きく、技術者以外のエディターが独自のコンテンツ構造を作成している場合は Sanity.io。Sanity の Studio はそのような利用者にとってより使いやすく、ホスティング型バックエンドは信頼性が高く、GROQ クエリ言語は本当に書きやすいです。正式なプランは月額 $99 以上かかりますが、クライアントによっては価値があります。
Strapi は長年の間 Payload の代替案でした。今でも実用的で、セルフホスト型のモデルも同様ですが、TypeScript の体験はぎこちなく、メジャーバージョン間のアップグレードパスは歴史的に苦労が多いです。Payload のコードベースはより意図的に感じます。
WordPress with ACF またはブロックベースのセットアップ（既に WordPress に慣れている技術者以外の管理者に引き継ぐ必要があるもの向け）。エージェンシーが構築するもののうち大部分には今でも正しい選択肢です。誰があなたに何と言おうと気にしないでください。
Directus は注目する価値のあるダークホース、特に既存のデータベーススキーマがあり、その周囲に CMS をラップする必要がある場合。Payload とは哲学が異なりますが、その特定の役割で本当に優れています。
FAQ
Payload CMS は無料で使用できますか？
はい。Payload は MIT ライセンスの下でオープンソースです。ライセンス料はありません。ホスティング インフラストラクチャ自体の費用を負担します。これは、ホスト型 SaaS CMS との折り合いです。
技術者以外のクライアントは Payload の管理画面を使用できますか？
フィールドにラベルが適切に付いていて、合理的なデフォルトがあり、基本的なトレーニングが行われていれば、可能です。管理画面はクリーンなため、エディターは比較的すぐに習得できます。できないのは、開発者なしで新しいコレクションを作成したり、スキーマを変更することです。これは設計上の制約です。
Payload は Next.js で動きますか？
はい。特に よく動きます。Payload 2.x は Next.js で再構築されているため、CMS とフロントエンドを同じ Next.js アプリから実行できます。この「単一リポジトリ内のモノレポ」セットアップは小〜中規模プロジェクトに適切に機能し、インフラストラクチャ オーバーヘッドを削減します。
Payload ではどのデータベースを使用すべきですか？
2026 年の新規プロジェクトでは、Drizzle ORM 経由で PostgreSQL をデフォルトにしています。テストが十分で、適切なリレーショナル制約が得られ、慎重に使用されればマイグレーション ツール は堅牢です。MongoDB は依然としてオプションで、データが本質的にドキュメント形状の場合は良い選択肢ですが、Postgres が最初のお勧めです。
Payload はメディアアップロードをどのように処理しますか？
デフォルトでは、Payload はアップロードをサーバーファイルシステムにローカル保存します。開発環境では問題ありませんが、本番環境では適切ではありません。本番環境の場合は、S3、Cloudflare R2 などを指すストレージアダプターを構成する必要があります。公式の @payloadcms/plugin-cloud-storage パッケージがこれを処理し、初回セットアップには約 1 時間かかります。
Payload は大規模な本番サイト向けに準備できていますか？
複数の企業で本番環境の大規模なトラフィックを処理しています。ただし、月間1000万ページビューかつ編集チーム20名規模のサイトに選ぶCMSではありません。そのスケールでは専任サポート契約を備えたエンタープライズ向けソリューションが必要です。Seahawk Mediaの大半を占めるエージェンシー構築・中堅市場向けプロジェクトでは、Payloadは安定性と機能性を備えています。
正直な評価
2026年のPayload CMSは、長期コストが重要で、スタック全体の所有に対応できるエンジニアリング能力を持つ開発者主導プロジェクト向けの成熟した優れたツールです。セットアップ時間への初期投資は現実的です。継続的なインフラストラクチャコストは低い。開発者体験は良好です。
WordPressの代替ではありません。そもそもそれを目指していません。しかし適切なプロジェクト、適切なチームであれば、12,000件以上のビルド経験の中で最もコスト効率的なヘッドレスCMSオプションです。問題は「優れているか」ではなく「あなたの状況に合っているか」です。