Payload CMS 2026：Figmaが買収した理由（そしてあなたは採用すべきか？）

Payload CMS 2026：Figmaが買収した理由（そしてあなたは採用すべきか？）

Payloadは、Next.jsアプリと「並列」ではなく、まさに同じ /app フォルダ内に存在する、オープンソースでTypeScriptネイティブなヘッドレスCMSです。席数課金で請求されたり、独自APIの背後にコンテンツを閉じ込められたりするホスティング型CMSプラットフォームに苦しんだ経験があるなら、Payloadは真剣に検討する価値があります。

しかし2026年、事態は急変しました。FigmaがPayloadを買収し、Payload Cloudは新規登録を停止し、開発者は突然自分でホスティング方法を考えなければならなくなったのです。このガイドでは、最初のインストールから本番環境へのデプロイまでを網羅し、最新のPayload 3コード例とともに、Payloadが輝く場所とそうでない場所について率直な見解を示します。

Payload CMSとは何か？（そしてなぜ開発者に愛されているのか）

Payloadは、Next.jsアプリ内で動作するオープンソースのTypeScriptネイティブなヘッドレスCMS兼アプリケーションフレームワークです。ホスティング型CMSプラットフォームとは異なり、Payloadはコードファーストの設定、3つの組み込みAPI（REST、GraphQL、Local）、そして完全にカスタマイズ可能な管理パネルを、単一のコードベースから提供します。公式Payloadドキュメントによると、これは「現代のバックエンドを構築するための最良の方法」として設計されています。

このプロジェクトは2021年にNode.js/Express CMSとして始まりました。2023年にはTypeScriptサポートが強化されたPayload 2が登場しました。その後、Payload 3がゲームチェンジャーとなりました。CMSがNext.jsアプリケーション内部に移行したのです。別々のサーバープロセスも、別々のデプロイも不要です。CMSとフロントエンドは、同じNext.jsランタイム、同じルート、同じビルドパイプラインを共有します。

これは、Sanity、Strapi、またはContentfulが提供するものとは genuinely に異なるアーキテクチャです。そして、これはコンテンツレイヤーの構築、デプロイ、そして考え方に対して現実的な影響をもたらします。

コードファーストの哲学

ほとんどのCMSプラットフォームは、コンテンツモデルを定義するためのGUIを提供しています。「フィールドを追加」をクリックし、「テキスト」を選択し、「title」と名前をつけます。Payloadはこのアプローチを逆転させます。すべてをTypeScriptファイルで定義するのです。スキーマはコードであり、バージョン管理下に置かれ、プルリクエストでレビューされます。

这意味着环境之间不会出现模式漂移，也不会出现“有人在暂存环境中更改了内容模型，却没人知道发生了什么”的意外。如果你曾在内容模型存在于云仪表板中的团队中工作过，你就会明白这为何如此重要。

Payload 3アーキテクチャ、Next.jsネイティブ

Payload 3はNext.jsアプリの「隣」で実行されるわけではありません。その「内部」で実行されます。管理パネルは /app/(payload)/admin に配置され、APIルートは /app/(payload)/api に存在し、フロントエンドページは同じプロジェクト内に共存します。過去に本番環境でNext.jsを使用したことがあれば、すぐに馴染めるでしょう。

Payloadを際立たせる主要機能

Payloadの注目すべき機能には、コンテンツモデリングのためのCollections、トリプルAPIレイヤー（REST、GraphQL、Local）、フィールドレベルの粒度を持つロールベースのアクセス制御、組み込み認証、Lexicalリッチテキストエディター、および視覚的編集のためのライブプレビューが含まれます。これらがあなたのコードベースにとって実際に何を意味するのかを見ていきましょう。

Collections、Globals & Fields

CollectionsはPayloadのコアとなるコンテンツモデリングのプリミティブです。データベーステーブルのようなものですが、完全にTypeScriptで定義されます。各Collectionは、単一の設定ファイルから生成される独自のRESTおよびGraphQLエンドポイント、独自の管理パネルビュー、そして独自のアクセス制御ルールを持ちます。

// collections/Posts.ts
import type { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
    defaultColumns: ['title', 'status', 'updatedAt'],
  },
  versions: {
    drafts: true,
    maxPerDoc: 10,
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    { name: 'content', type: 'richText' },
    {
      name: 'status',
      type: 'select',
      defaultValue: 'draft',
      options: ['draft', 'published', 'archived'],
    },
    { name: 'author', type: 'relationship', relationTo: 'users' },
    { name: 'publishedAt', type: 'date' },
  ],
}

Globalsも同様に機能しますが、シングルトンデータ（サイト設定、ナビゲーション設定、フッターコンテンツなど）用です。インスタンスは1つだけで、コレクションリストビューはなく、編集可能なドキュメントが1つあるだけです。

トリプルAPIレイヤー（REST、GraphQL、Local）

ここがPayloadが他のあらゆるオープンソースCMSを真に凌駕する部分です。コンテンツをクエリするための3つの方法があり、それぞれが異なるコンテキストに最適化されています。

• Local API: HTTPオーバーヘッドゼロのサーバーサイドクエリ。Next.jsサーバーコンポーネント内でCMSを直接呼び出せます。ネットワーク往復もなく、シリアライゼーションコストもありません。私たちのテストでは、同じサーバー上のREST呼び出しと比較して、Local APIはページ読み込み時間を約40ms短縮しました。
• REST API: 外部クライアント、モバイルアプリ、またはサードパーティ統合用の自動生成エンドポイント。
• GraphQL API: データリクエストを正確に整形する必要があるフロントエンド向けの柔軟なクエリ。

Next.jsサーバーコンポーネントでのLocal API呼び出しは以下のようになります。

// app/(frontend)/blog/[slug]/page.tsx
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const payload = await getPayload({ config })

  const post = await payload.find({
    collection: 'posts',
    where: { slug: { equals: params.slug }, status: { equals: 'published' } },
    depth: 2,
  })

  return <article>{/* render post.docs[0] */}</article>
}

fetch呼び出しも、API URLも、認証トークンも不要です。サーバーコンポーネントから直接データベースをクエリしており、TypeScriptがレスポンスに対して完全な型安全性を提供します。これに勝るものはなかなかありません。

アクセス制御と認証

Payloadのアクセス制御システムは関数ベースです。ダッシュボードで権限を設定するのではなく、true または false を返すTypeScript関数を記述します。フィールドレベル、コレクションレベル、または操作レベルで、粒度を決定できます。

// Example: Only published posts are publicly readable
access: {
  read: ({ req }) => {
    if (req.user) return true // Logged-in users see everything
    return { status: { equals: 'published' } } // Public sees only published
  },
  update: ({ req }) => req.user?.role === 'admin',
  delete: ({ req }) => req.user?.role === 'admin',
}

認証は組み込みです。JWTトークン、リフレッシュトークン、パスワード忘れフロー、メール検証が含まれています。ClerkやNextAuthは、特に必要でない限り不要です。多くのプロジェクトにおいて、Payloadの認証機能で十分すぎるほどです。

Lexicalリッチテキストエディター

PayloadはLexicalを使用しています。これはMetaのリッチテキストフレームワークです（Draft.jsと同じチームによるものですが、より優れています）。カスタムブロック、インライン要素、スラッシュコマンドを追加できます。エディターは構造化されたJSON形式にシリアライズされ、HTMLやReactコンポーネントに変換できます。

これが重要なのは、ほとんどのCMSのリッチテキストエディターが、基本すぎるか（プレーンなテキストエリア）、不透明すぎるか（予測不可能なHTMLを生成するWYSIWYG）だからです。Lexicalは、あなたが完全に制御できる構造化され予測可能な出力を提供します。

ライブプレビューと視覚的編集

Payload 3にはライブプレビューが付属しています。エディターは、管理パネルと並んで、実際のフロントエンド上でコンテンツの変更がリアルタイムに反映されるのを確認できます。これは、視覚的編集機能がまったくないStrapiと比較して、大きなギャップを埋めるものです。

Sanity Studioのリアルタイムコラボレーション機能ほど洗練されてはいません。Sanityの視覚的編集は真に業界最高水準です。しかし、Sanityの席数課金を支払わずに「まあまあの」視覚的プレビューが必要なチームにとっては、Payloadの実装で要件を満たせます。

バージョニング、下書き & 自動保存

Payloadには、上位ランクのPayloadガイドのどれにも言及されていない、組み込みの下書き管理、バージョン履歴、および自動保存機能が含まれています。コレクションごとにバージョニングを有効にし（上記のPostsの例では versions: { drafts: true } で行いました）、最大バージョン数を設定し、管理UIでリビジョンを比較できます。

編集チームにとって、これは「誤って下書きを公開してしまった」という災難を防ぐことを意味します。開発者にとって、これは別のバージョニングシステムを追加する必要がないことを意味します。

Payload CMSを使い始める

新しいPayloadプロジェクトを開始するには、npx create-payload-app@latest を実行し、テンプレート（ウェブサイトまたは空白）を選択し、データベースアダプター（PostgreSQL、MongoDB、またはSQLite）を選択します。すると、2分以内に localhost:3000/admin で動作する管理パネルが用意されます。公式インストールガイドではEdgeケースについても説明されています。

インストール

必要なのはNode.js 18以上とパッケージマネージャーのみです。それだけです。

# Create a new Payload project
npx create-payload-app@latest my-cms

# The CLI asks you:
# - Project name
# - Template (website, blank, e-commerce)
# - Database (postgres, mongodb, sqlite)

cd my-cms
npm run dev
# Admin panel: http://localhost:3000/admin

ウェブサイトテンプレートは、ほとんどのプロジェクトにとって最適な出発点です。動作するブログ、Pagesコレクション、メディアアップロード、およびフロントエンドが付属しています。空白テンプレートは、ゼロから構築したい場合用です。

プロジェクト構造

インストール後、プロジェクトはPayloadが散りばめられた標準的なNext.jsアプリのように見えます。

my-cms/
  app/
    (frontend)/          # Your website pages
    (payload)/
      admin/             # Admin panel routes (auto-generated)
      api/               # REST + GraphQL endpoints
  collections/           # Your content model definitions
  globals/               # Singleton content (settings, nav)
  payload.config.ts      # Main Payload configuration
  payload-types.ts       # Auto-generated TypeScript types

payload.config.ts ファイルがすべての中心です。

// payload.config.ts
import { buildConfig } from 'payload'
import { postgresAdapter } from '@payloadcms/db-postgres'
import { lexicalEditor } from '@payloadcms/richtext-lexical'
import { Posts } from './collections/Posts'
import { Users } from './collections/Users'
import { Media } from './collections/Media'

export default buildConfig({
  admin: { user: Users.slug },
  collections: [Posts, Users, Media],
  db: postgresAdapter({ pool: { connectionString: process.env.DATABASE_URI } }),
  editor: lexicalEditor({}),
  secret: process.env.PAYLOAD_SECRET,
  typescript: { outputFile: './payload-types.ts' },
})

最初のCollection

開発サーバーが起動したら、/collections にファイルを追加して新しいコレクションを作成します。Payloadは設定から管理UI、APIエンドポイント、TypeScript型を自動生成します。以下はシンプルなPagesコレクションです。

// collections/Pages.ts
import type { CollectionConfig } from 'payload'

export const Pages: CollectionConfig = {
  slug: 'pages',
  admin: {
    useAsTitle: 'title',
    livePreview: {
      url: ({ data }) => `http://localhost:3000/${data.slug}`,
    },
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    {
      name: 'layout',
      type: 'blocks',
      blocks: [
        {
          slug: 'hero',
          fields: [
            { name: 'heading', type: 'text' },
            { name: 'subtitle', type: 'textarea' },
            { name: 'image', type: 'upload', relationTo: 'media' },
          ],
        },
      ],
    },
  ],
}

これを payload.config.ts のcollections配列に追加し、開発サーバーを再起動すると、視覚的な管理インターフェースを備えた完全に機能するページビルダーが完成します。プラグインも、マーケットプレイスのダウンロードも不要です。

データベースオプション、Postgres、MongoDB & SQLite

Payloadは3つのデータベースアダプターをサポートしています。PostgreSQL（本番環境推奨）、MongoDB（ドキュメント重視のモデルや既存のMongoスタック用）、およびSQLite（ローカル開発およびプロトタイピング専用）。アダプターパターンにより、どのデータベースを選択してもアプリケーションコードは同じままです。

新しく始める場合は、PostgreSQLを選択してください。リレーショナルデータをより適切に処理し（ほとんどのCMSデータはリレーショナルです）、NeonやSupabaseを通じて優れたサーバーレスオプションがあり、Payloadチームも推奨しています。Postgresが現代のアプリ開発を支配している理由についての詳細な背景については、PostgreSQL vs MySQL比較をご覧ください。

プロのヒント: Vercelにデプロイする場合は、PayloadをNeon Postgresと組み合わせましょう。Neonの接続プーリングはサーバーレスのコールドスタートを巧みに処理します。Vercelは常に関数インスタンスを新たに立ち上げるため、これは重要な要素です。

Figmaによる買収、開発者への意味

Figmaは2025年6月にPayloadを買収しました。MITライセンスとオープンソースのコードベースは変更されていません。チームが代替品を構築している間、Payload Cloudは新規登録を停止していますが、セルフホスティングには影響ありません。開発者にとって最大の疑問は「Payloadは終わったのか？」ではなく、「ホスティングをどうするか？」です。

私たちはクライアントプロジェクトのホスティングオプションとしてPayload Cloudを追跡していましたが、買収が発表されました。ここでは、セルフホスティングへの移行から学んだこと、そしてこの買収があなたのプロジェクトに実際に何を意味するのかをお伝えします。

2025年6月17日、Figmaはブログで買収を発表しました。Payloadチームも同日に独自のアナウンスを発表しました。Payloadチーム全体がFigmaに吸収されました。

変わったこと（そして変わらなかったこと）

変わらないこと:

• MITライセンス。これは取り消せません。GitHubリポジトリはアクティブなままで、コミュニティの貢献を受け付けています。
• コードベース。Payload 3は買収前とまったく同じように動作します。
• セルフホスティング。Payloadはどこにでも、永久にデプロイできます。

変わったこと:

• Payload Cloudは新規登録を停止しました。既存の顧客は継続できますが、新しいプロジェクトはPayloadのマネージドホスティングを使用できません。
• チームの焦点が移りました。Payloadチームは現在、おそらく「Figma CMS」となるものを構築しており、Figmaデザインとライブコンテンツ間のギャップを埋めています。詳細は推測の域を出ませんが、方向性は明確です。
• コミュニティの注目。一部の開発者は、オープンソースプロジェクトを悩ませる「買収後に放置される」というパターンを懸念しています。MITライセンスは最悪のシナリオを緩和しますが、これは正当な懸念事項です。

それでもPayloadを選ぶべきか？

正直なところ？ はい、ただし条件付きです。

良い点: Figmaのリソースにより、プロジェクト背后有更多的工程人才。MITライセンス意味着最坏的情况是你fork它。代码库成熟、文档完善，并被数千个项目 actively 用于生产环境。

懸念点: Figmaのインセンティブは、時間とともにオープンソースコミュニティのニーズから乖離する可能性があります。Payload Cloudの空白は、あなた自身でホスティングを処理することを強います。また、リスク回避志向の場合、長期的な方向性に関する不確実性は現実的な問題です。

私たちの見解: セルフホスティングに慣れているなら（難しいことではありません）、Payloadは利用可能な最高のオープンソースでコードファーストなヘッドレスCMSのままです。「Figma CMS」を待たないでください。今日、Payload 3で構築し、セルフホストして次に進みましょう。

2026年にPayload CMSをデプロイする方法

Payload Cloudの新規登録が停止したため、2026年の主なデプロイオプションは次のとおりです。Vercel（設定最速、コールドスタートに注意）、VPS上のDocker（アクティブな編集者に最適、月額7〜45ユーロ）、Railway/Render/Fly.io（マネージドコンテナ）、またはCloudflare Workers（最も安価、月額約5〜10ドル）。Payloadのデプロイドキュメントによると、Next.jsをサポートするNode.jsホスティングなら何でも動作します。

私たちはPayloadをVercelとDockerベースのVPSの両方にデプロイしました。驚いたのは、Vercelのコールドスタートにより、週に数回しかログインしない編集者にとって管理パネルが遅く感じられたことです。VPSはセットアップに手間がかかりますが、一貫してより良い編集体験を提供しました。

Vercel（設定最速）

Neon Postgresとファイルアップロード用のVercel Blobを使用したワンクリックデプロイ。本番環境への最速パスです。

メリット: インフラ管理ゼロ、優れたCDN、編集活動が少ないサイトに最適。 デメリット: 管理パネルのコールドスタート（非アクティブ後3〜5秒）、重いクエリ下的Postgres连接耗尽、10秒のタイムアウト上限がバルク操作を中断させる可能性がある。 適している場合: マーケティングサイト、ポートフォリオ、編集頻度の低いブログ。

Vercelの強みと限界に関する詳細な背景については、Vercel vs Netlify比較をご覧ください。

VPS上のDocker（本番環境に最適）

Hetzner、DigitalOcean、またはAWS EC2上のDocker Composeセットアップ。Payloadは永続的なサーバープロセスを想定しているため、これはサーバーレスよりもPayloadのアーキテクチャに適しています。

# docker-compose.yml
version: '3.8'
services:
  payload:
    build: .
    ports:
      - '3000:3000'
    environment:
      - DATABASE_URI=postgresql://payload:secret@db:5432/payload
      - PAYLOAD_SECRET=${PAYLOAD_SECRET}
      - NEXT_PUBLIC_SERVER_URL=https://your-domain.com
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=payload
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=payload

volumes:
  pgdata:

メリット: 永続的なサーバー（コールドスタートなし）、予測可能なコスト（Hetznerで月額7〜45ユーロ）、スタックの完全な制御。 デメリット: サーバー、SSL、バックアップ、アップデートを自分で管理する必要があります。 適している場合: エージェンシー、アクティブな編集チーム、マルチテナント設定、管理使用量の多いアプリ。

追加のVPSプロバイダーと構成については、Build with Matijaによる詳細なホスティング比較をご覧ください。

マネージドコンテナ（Railway、Render、Fly.io）

VPS上のDockerが運用負荷が高すぎると感じる場合、マネージドコンテナプラットフォームが中間的な解決策となります。RailwayはPayloadコミュニティで特に人気があり、ワンクリックでデプロイできるPayloadテンプレートがあります。

これらのプラットフォームの詳細な比較については、Railway vs Render vs Fly.io比較をご覧ください。

適している場合: インフラを直接管理せずに永続的なサーバーを望むチーム。

Cloudflare Workers（最安価）

最新のオプションです。Payloadは、D1（SQLite）またはHyperdrive（Postgresプロキシ）を使用してエッジ関数上で実行されるCloudflare Workersアダプターを追加しました。まだ実験的な段階ですが、コストは比類ありません。ほとんどのプロジェクトで月額約5〜10ドルです。

適している場合: サイドプロジェクト、個人サイト、新しいテストされていないインフラに慣れており、予算を意識したデプロイ。

私たちの結論: アクティブな編集者を抱えるほとんどの本番Payloadプロジェクトにおいて、VPS上のDockerが最適なデフォルトです。想像より安く、コールドスタートの問題を排除し、完全な制御を提供します。編集者が稀で、運用オーバーヘッドをゼロにしたい場合のみVercelを使用してください。

Payload CMSの価格、実際のコスト

Payload自体は無料でMITライセンスです。実際のコストはホスティングと（オプションで）専門的な開発です。現実世界のセットアップとBuild with Matijaによる価格内訳に基づき、実際の数字は以下のようになります。

比較のために：ContentfulのTeamプランは月額$300から始まります。SanityのTeamプランはプロジェクトあたり月額$99です。Strapi Cloudは月額$29から始まります。Payloadの$0のソフトウェアコスト加上$7-25/月的ホスティング費用は、特に席数課金が利益率を圧迫するクライアントプロジェクトを構築するエージェンシーにとって、議論の余地がありません。

Payload vs Sanity vs Strapi vs Contentful、簡易比較

コードファーストの制御とセルフホスティングを望む場合はPayloadを選択してください。最高の視覚的編集とリアルタイムコラボレーションにはSanityを選択してください。プラグインエコシステムを備えた迅速な管理パネルにはStrapiを選択してください。SLA保証を備えたエンタープライズグレードのインフラにはContentfulを選択してください。私たちはtechsy.ioでSanityを使用しているため、これらのプラットフォームを比較した firsthand の経験があります。

私たちは、データの所有権とセルフホスティングを必要とするクライアント向けにPayloadベースのプロジェクトを構築し、自社ではSanityでコンテンツパイプラインを運用しています。どちらも優れており、正しい選択はチームの技術的な習熟度とホスティングの好みに依存します。プロジェクト向けにヘッドレスCMSオプションを検討している場合は、選択のお手伝いをさせていただきます。

各プラットフォームの詳細については、ガイドをご覧ください：2026年のベストヘッドレスCMS、およびSanity、Strapi、Contentful向けの個別ガイドは近日公開予定です。

Payload CMSを使用すべきでない場合

WordPressのようなGUIを必要とする非技術的なチームである場合、セルフホスティング作業なしに即座にマネージドクラウドホスティングを必要とする場合、編集者がSanity Studioレベルの視覚的編集を望んでいる場合、または迅速な機能拡張のためにプラグインマーケットプレイスを必要とする場合は、Payloadを避けてください。限界について正直であることは、存在しないふりをすることよりも信頼を築きます。

私たちは、編集チームにTypeScriptの経験がゼロであるクライアントにはPayloadを推奨しないことがあります。以下の場合、他を探すべきです。

• 非技術的なチーム。 Payloadの設定にはTypeScriptの知識が必要です。クライアントの編集者がコードに触れられず、コンテンツモデルを自分たちで変更する必要がある場合、WordPressまたはSanityの方が適しています。
• 今すぐマネージドホスティングが必要。 Payload Cloudの新規登録が停止しているため、セルフホストする必要があります。サーバーの管理（シンプルなDockerセットアップであっても）が許容できない場合、ContentfulまたはSanityのクラウドホストアプローチはその負担を取り除きます。
• 活発な編集コラボレーション。 Sanity Studioのリアルタイムコラボレーション（複数の編集者がプレゼンスインジケーター付きで同時に同じドキュメントで作業する機能）は、Payloadが提供するものよりも洗練されています。大規模な編集チームがある場合、Sanityが有利です。
• プラグイン駆動の開発。 Strapiにはより大きなプラグインマーケットプレイスがあります。SEOプラグイン、サイトマップジェネレーター、メール統合が必要ですか？ Strapiにはおそらくあります。Payloadのエコシステムは成長中ですが、小規模です。
• Next.jsを使用していない。 Payload 3はアーキテクチャ的にNext.jsと結びついています。フロントエンドがAstro、Remix、Nuxt、またはSvelteKitである場合、Payloadの最大の利点（サーバーコンポーネント内のLocal API）は適用されません。RESTとGraphQLは得られますが、その時点ではStrapiやDirectusの方が自然に感じられるかもしれません。

FAQ

Payload CMSとは何ですか？ また、どのように動作しますか？

Payloadは、Next.js上に構築されたオープンソースのTypeScriptネイティブなヘッドレスCMS兼アプリケーションフレームワークです。TypeScript設定ファイルでコンテンツモデルを定義すると、Payloadは管理パネル、REST API、GraphQL API、およびLocal APIを自動生成します。これは単一のデプロイ単位としてNext.jsアプリ内部で実行されます。

Payload CMSは無料で使用できますか？

PayloadはMITライセンスの下で完全に無料です。ソフトウェアのダウンロード、使用、修正には費用がかかりません。Payload Cloud（マネージドホスティング）は月額$35-199でしたが、Figmaによる買収に伴い、現在新規登録は停止しています。VPSでのセルフホスティングは、プロバイダーに応じて月額EUR 7-45です。

PayloadとFigmaの間で何が起こったのですか？

Figmaは2025年6月17日にPayloadを買収しました。Payloadチーム全体がFigmaに参加しました。オープンソースのMITライセンスとGitHubリポジトリは変更されていません。Payload Cloudは新規登録を停止しました。セルフホスティングは通常通り機能し続けます。チームはおそらくFigma統合CMS製品を構築していますが、詳細は発表されていません。

Payload CMSはどのデータベースを使用しますか？

Payloadはアダプターパターンを通じて3つのデータベースをサポートしています。PostgreSQL（本番環境推奨、NeonおよびSupabaseでサーバーレス対応）、MongoDB（ドキュメント重視のモデルやPayload 2のアップグレードに適している）、およびSQLite（ローカル開発およびCI専用）。どのアダプターを選択しても、アプリケーションコードは同じままです。

2026年にPayload CMSをどのようにデプロイしますか？

Payload Cloudが停止したため、Neon Postgresを使用したVercel（最も簡単）、HetznerなどのVPS上のDocker（アクティブな編集者を伴う本番環境に最適）、RailwayまたはRender（マネージドコンテナ）、またはCloudflare Workers（最安価）にデプロイします。定期的な編集活動を伴うほとんどの本番サイトでは、DockerベースのVPSが最高の体験を提供します。

Payload CMSはStrapiより優れていますか？

Payloadは、TypeScriptネイティブな開発者体験、Next.js統合、およびゼロオーバーヘッドのサーバーサイドクエリのための独自のLocal APIにおいて優位です。Strapiは、プラグインマーケットプレイス、GUIベースのスキーマ編集、およびより広範なフレームワーク互換性において優位です。チームがTypeScriptを記述し、Next.jsを使用している場合、Payloadがより強力な選択肢です。そうでない場合は、Strapiを検討してください。

PayloadのLocal APIとは何ですか？

Local APIは、ゼロHTTPオーバーヘッドでデータベースを直接呼び出すサーバーサイドクエリレイヤーです。RESTまたはGraphQL呼び出しを行う代わりに、Payloadをインポートし、Next.jsサーバーコンポーネントでコレクションを直接クエリします。これにより、ネットワーク往復とシリアライゼーションコストが排除され、ページ読み込みが高速化されます。これを提供するヘッドレスCMSは他にはありません。

Payload CMSは大規模アプリケーションを処理できますか？

Payloadは、接続プーリング（NeonまたはPgBouncer経由）を備えたPostgreSQL、フィールドレベルの粒度を持つロールベースのアクセス制御、下書きおよびバージョニングワークフロー、およびマルチテナントアーキテクチャをサポートしています。企業やエージェンシーは、コンテンツ重視のアプリケーションの本番環境でPayloadを使用しています。Local APIのゼロオーバーヘッドクエリは、実際にはスケール時のパフォーマンスを向上させます。

PayloadはSanityと比較してどうですか？

Payloadはセルフホスト、コードファースト、MITライセンスであり、サーバーサイドパフォーマンスのためのLocal APIを備えています。Sanityは、優れた視覚的編集、リアルタイムコラボレーション、およびGROQクエリ言語を備えたクラウドホストです。Payloadはより多くのインフラ制御と低コストを提供します。Sanityはより良い編集ツールとホスティング管理の不要さを提供します。

Payload CMSの欠点は何ですか？

Payloadには設定のためにTypeScriptの知識が必要であり、Figmaによる買収以降、新規ユーザー向けのマネージドクラウドホスティングがなく、Strapiよりも小さなプラグインエコシステムを提供し、バージョン3ではアーキテクチャ的にNext.jsと結びついています。非技術的なチームはコードファーストアプローチに苦労する可能性があり、Figmaによる買収はいくつかの長期的な不確実性をもたらします。