2026年のPayload CMSとDirectusの比較：コードファーストかデータベースファーストか

2026年にヘッドレスCMSを使ったプロジェクトを構築していて、選択肢をPayload CMSとDirectusに絞り込んだのであれば、おめでとうございます。あなたは素晴らしいセンスを持っています。どちらもオープンソース、セルフホスト可能、Node.js上に構築されています。どちらも活発なコミュニティを持ち、機能を素早くリリースしています。しかし、コンテンツスキーマがどのようにして存在するべきかについて、根本的に異なる哲学を表しており、その違いはプロジェクトで行うすべての決定に波及します。

過去2年間、両方を使った本番サイトをリリースしてきました。ここに、マーケティングページが言うことではなく、実際に私が考えていることを記します。

コア哲学の分岐点
スキーマ設計：コードファーストVSデータベースファースト
TypeScriptと開発者体験
APIレイヤーとクエリ機能
管理画面とコンテンツ編集
認証とアクセス制御
パフォーマンスとスケーラビリティ
デプロイメントとホスティング
2026年の価格設定とライセンス
どちらを選ぶべきか
FAQ

Payload CMS vs Directus in 2026: Code-First vs Database-First

コア哲学の分岐点

これを明確に述べておきます。なぜなら、これは理解すべき最も重要なことだからです。

Payload CMSはコードファーストです。 スキーマをTypeScript設定ファイルで定義します。データベースはコードに適合します。

Directusはデータベースファーストです。 既存のデータベースに指定でき、スキーマをイントロスペクトします。管理UIはデータベースに適合します。

どちらのアプローチが客観的に優れているわけではありません。しかし、一方はあなたのプロジェクトにとって劇的に優れており、これを間違えると後で苦痛が生じます。

グリーンフィールドプロジェクトを構築していて、CMSスキーマをアプリケーションコードと一緒にバージョン管理したい開発者であれば、Payloadは家のように感じるでしょう。200のテーブルを持つ既存のPostgreSQLデータベースがあり、その上にコンテンツ管理レイヤーが必要な場合、Directusは数週間節約できます。

スキーマ設計：コードファーストVSデータベースファースト

Payloadのコードファーストアプローチ

Payload 3.x（2026年現在の最新メジャーバージョン）では、TypeScript設定ファイルでコレクションを定義します。

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

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
  },
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'content',
      type: 'richText',
    },
    {
      name: 'author',
      type: 'relationship',
      relationTo: 'users',
    },
    {
      name: 'publishedAt',
      type: 'date',
    },
    {
      name: 'status',
      type: 'select',
      options: [
        { label: 'Draft', value: 'draft' },
        { label: 'Published', value: 'published' },
      ],
      defaultValue: 'draft',
    },
  ],
}

この設定はあなたの情報源です。Payloadが開始されると、自動的にデータベースマイグレーションを生成します（Payload 3.xはPostgreSQLまたはSQLiteでDrizzle ORMを使用し、MongoDBのサポートも続けています）。スキーマはGitに保存されます。PRでスキーマ変更をレビューします。アプリケーションコードで使用するのと同じワークフローであり、それが要点です。

Payloadはこれらの設定からTypeScriptの型も自動生成します。したがって、Next.jsフロントエンドでpostsをクエリするとき、個別の型定義を維持することなく完全な型安全性が得られます。

Directusのデータベースファーストアプローチ

Directusは逆の立場を取ります。以下のことができます。

既存のデータベースにDirectusを指定し、スキーマを読み取る
管理UIを通じてコレクションを作成し、SQLマイグレーションを生成する
Directus SDKを使用してスキーマをプログラムで管理する

// Directus SDKを使用したコレクション作成
import { createDirectus, rest, createCollection } from '@directus/sdk'

const client = createDirectus('http://localhost:8055').with(rest())

await client.request(
  createCollection({
    collection: 'posts',
    schema: {
      name: 'posts',
    },
    meta: {
      icon: 'article',
      note: 'Blog posts',
    },
  })
)

Directus 11（2025年末にリリース）はスキーママイグレーションツールを大幅に改善しました。YAMLファイルとしてスキーマスナップショットをエクスポートおよびインポートできるようになりました。これにより、バージョン管理がこれまでよりも実用的になります。

# 現在のスキーマをエクスポート
npx directus schema snapshot ./schema-snapshot.yaml

# スキーマの差分を別の環境に適用
npx directus schema apply ./schema-snapshot.yaml

しかし、正直なところ：これらの改善にもかかわらず、Directusスキーマ管理はPayloadのアプローチと同じようにGitワークフローで自然に感じられません。意図を宣言するのではなく、状態をスナップショットしています。

スキーマ比較表

項目	Payload CMS	Directus
スキーマの情報源	TypeScript設定ファイル	データベース自体
スキーマバージョン管理	ネイティブGitワークフロー	YAMLスナップショット（v11で改善）
既存データベースサポート	限定的（マイグレーションパス）	優秀（イントロスペクション）
自動生成型	設定から生成	SDK + CLIを使用して生成
データベースサポート	PostgreSQL、SQLite、MongoDB	PostgreSQL、MySQL、MariaDB、SQLite、MS SQL、CockroachDB、OracleDB
ORM / クエリレイヤー	Drizzle ORM（v3）	カスタムクエリエンジン（Knex基盤）
マイグレーション生成	設定変更から自動	スキーマ差分スナップショット

TypeScriptと開発者体験

PayloadのTypeScriptストーリー

Payloadはボーンイン・イン・TypeScriptです。プロジェクト全体がTypeScriptで書かれ、TypeScriptで設定され、TypeScriptを生成します。payload generate:typesを実行すると、すべてのコレクションのインターフェースが得られます。

// 自動生成
export interface Post {
  id: string
  title: string
  content?: RichTextContent
  author?: string | User
  publishedAt?: string
  status?: 'draft' | 'published'
  createdAt: string
  updatedAt: string
}

これらの型は、ローカルAPI、REST APIレスポンス、GraphQLクエリを通じて流動します。Payload 3.xでは、Next.jsアプリの内部で実行されるため、これらの型を直接インポートして使用できます。個別のSDKは不要です。サーバーサイドレンダリング用のAPIコールはありません。データベースを直接クエリしています。

// Next.jsサーバーコンポーネント内
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function BlogPage() {
  const payload = await getPayload({ config })
  
  const posts = await payload.find({
    collection: 'posts',
    where: {
      status: { equals: 'published' },
    },
  })
  // posts.docsは完全にPost[]として型付けされている
  
  return <PostList posts={posts.docs} />
}

これは本当に優れたDXです。ネットワークホップなし、完全な型、そしてそれはただ関数です。

DirectusのTypeScriptストーリー

DirectusはそのTypeScriptサポートを大幅に改善しています。@directus/sdkパッケージはジェネリック型パラメータをサポートしています。

import { createDirectus, rest, readItems } from '@directus/sdk'

interface Schema {
  posts: Post[]
  users: User[]
}

interface Post {
  id: number
  title: string
  content: string
  author: number | User
  published_at: string
  status: 'draft' | 'published'
}

const client = createDirectus<Schema>('http://localhost:8055').with(rest())

const posts = await client.request(
  readItems('posts', {
    filter: { status: { _eq: 'published' } },
    fields: ['id', 'title', 'content', 'author.*'],
  })
)

問題は何か？これらの型定義を自分で書いて維持する必要があります（またはdirectus-typescript-genのようなコミュニティツールで生成します）。型はPayloadが行うのと同じ第一級の方法でスキーマから自動導出されません。これはデータベースファーストのトレードオフです。データベースはTypeScriptについて知りません。

Payload CMS vs Directus in 2026: Code-First vs Database-First - architecture

APIレイヤーとクエリ機能

どちらもREST APIとGraphQL APIを生成しますが、異なるフレーバーです。

Payloadは以下を提供します：

関係の深さ制御を備えたREST API
GraphQL API（設定から自動生成）
ローカルAPI（直接データベースクエリ、HTTPオーバーヘッドなし）
完全なクエリ演算子：equals、not_equals、greater_than、in、contains等

Directusは以下を提供します：

粒度の高いフィールド選択を備えたREST API
GraphQL API（スキーマイントロスペクションから自動生成）
Directus SDK（REST をラップ、インターフェースを提供するとき型付け）
_eq、_neq、_gt、_in、_contains、論理_and/_or演算子を備えた豊富なフィルタリング
APIに組み込まれた集計クエリ（count、sum、avg等）

Directusは複雑なクエリ、特に集計のAPIの柔軟性でわずかに有利です。GROUP BYスタイルのクエリをAPI経由で実行する必要がある場合、Directusはそれをネイティブに処理します。Payloadを使用する場合は、通常、Drizzle ORMレイヤーにドロップするか、カスタムエンドポイントを書きます。

Payloadの極めて有利な点はローカルAPIです。CMSとNext.jsフロントエンドが同じプロセスの場合、HTTPをスキップします。サーバーレンダリングされたページの場合、これはより高速なビルドと低いレイテンシを意味します。

管理画面とコンテンツ編集

Payload 3.xの管理画面はReactで構築され、Next.jsアプリケーションの一部として出荷されます。Reactコンポーネントでカスタマイズ可能です。UIのほぼすべてのピースをオーバーライドできます。ブロックベースのリッチテキストエディタ（v3の時点でLexicalに基づいている）は強力で拡張可能です。

DirectusのUIはスタンドアロンVue.jsアプリケーション（Directus Data Studio）です。磨かれており、強いビジュアルデザインがあり、非技術者は通常、すぐに習得します。DirectusのフローやオートメーションビルダーはPayloadのフックシステムよりも明らかにビジュアルで、アクセスしやすくなっています。

機能	Payload CMS	Directus
管理フレームワーク	React（Next.js）	Vue.js（スタンドアロン）
リッチテキストエディタ	Lexical基盤	TipTap / WYSIWYG
カスタムフィールド	Reactコンポーネント	Vue拡張
ワークフロー/オートメーション	フック+カスタムエンドポイント	Directus Flows（ビジュアルビルダー）
ローカライゼーション	ビルトイン・フィールドレベルi18n	ビルトイン・フィールドレベルi18n
コンテンツバージョン管理	ドラフト/公開+バージョン	コンテンツバージョン管理+リビジョン
ファイル管理	ビルトインメディアライブラリ	ビルトインメディアライブラリ（変換機能付き）

正直なところ：開発者に重い量のチームの場合、PayloadのUIの拡張はReactを書いているため、より自然に感じられます。コンテンツエディタが主要なユーザーであり、低摩擦UXを望むチームの場合、Directusの管理画面はそのまま、わずかにアクセスしやすくなっています。

認証とアクセス制御

どちらのシステムも成熟した認証を持ちますが、異なる方法で機能します。

Payloadはコレクションベースの認証を使用します。コレクションを認証コレクション（通常はusers）としてマークすると、ログイン、登録、パスワードリセット、メール検証、JWT/クッキーベースのセッションが取得されます。アクセス制御は関数を使用してコレクションごとおよびフィールドごとに定義されます。

{
  slug: 'posts',
  access: {
    read: () => true, // 公開
    create: ({ req: { user } }) => Boolean(user), // 認証済み
    update: ({ req: { user } }) => user?.role === 'admin',
    delete: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    {
      name: 'internalNotes',
      type: 'text',
      access: {
        read: ({ req: { user } }) => user?.role === 'admin',
      },
    },
  ],
}

これは非常に強力です。アクセス制御関数は完全なリクエストコンテキストを受け取るため、あらゆるパターンを実装できます。RBAC、ABAC、マルチテナンシー、行レベルセキュリティ。

Directusはロールベースの権限システムを使用して、管理パネルで構成します。ロールを作成し、粒度の高い権限（コレクションごとのCRUDS）を割り当てて、フィルタを使用してカスタム権限を追加します。ビジュアルで直感的ですが、ロールモデルに適さない複雑なパターンについては、柔軟性がありません。

ほとんどのプロジェクトでは、両方で十分です。マルチテナントSaaSまたは複雑な認可ロジックの場合、Payloadのコードベースのアクセス制御は打ち負かすことが難しいです。

パフォーマンスとスケーラビリティ

PostgreSQLバックエンドでリアルな条件下で両方をロードテストしています。ここで観測したことです。

メトリクス	Payload CMS 3.x	Directus 11
シンプル読み取り（単一項目）	~2-5ms ローカルAPI、~15-25ms REST	~15-30ms REST
リストクエリ（100項目、関係なし）	~8-15ms ローカルAPI、~30-50ms REST	~25-50ms REST
リストクエリ（100項目、2レベル深い）	~20-40ms ローカルAPI、~60-100ms REST	~50-120ms REST
コールドスタート時間	~3-6s（Next.js起動）	~2-4s（スタンドアロン）
メモリベースライン	~200-350MB（Next.js使用）	~150-250MB

PayloadのローカルAPIアドバンテージは実在し、SSR/SSGワークロード向けに重要です。10,000の静的ページを生成する場合、すべてのクエリのHTTPをスキップすることは急速に増加します。

Directusは怠惰ではありません。高スループットRESTワークロードをうまく処理し、キャッシュレイヤー（Redisバックアップ）は成熟しています。

デプロイメントとホスティング

Payload 3.xはNext.jsアプリケーションです。つまり、Next.jsが実行されるすべての場所にデプロイできます。Vercel、Netlify、AWS、Docker等。Payload Cloud（管理ホスティング）は2026年初頭の本番プロジェクトの場合、月額$30から開始します。

DirectusはスタンドアロンのNode.jsアプリケーションとして実行されます。Dockerが推奨デプロイメント方法です。Directus Cloudは月額$29から開始します。VPS上のセルフホスティングは簡単です。データベース接続が必要なDockerコンテナです。

注目する価値がある1つのこと：Payload 3.xはあなたのNext.jsアプリであるため、CMSとフロントエンドは一緒にデプロイされます。これはインフラを簡素化しますが、CMSアドミンパネルがフロントエンドと共にスケールすることを意味します。フロントエンドとCMSが非常に異なるスケーリングニーズを持つ高トラフィックサイトの場合、それらを別々に実行することを検討したいかもしれません。

Directusはスタンドアロンサービスであるため、これらの関心事は自然に分離されます。フロントエンド（Next.js、Astroまたはその他）はHTTP経由でDirectusに接続されます。これはより伝統的なヘッドレスアーキテクチャです。

Social Animalでは、クライアント向けの両方のアーキテクチャをデプロイしています。Payload-in-Next.jsアプローチはほとんどのマーケティングサイトと中規模アプリケーションにうまく機能します。複数のフロントエンドコンシューマを持つエンタープライズセットアップの場合、分離されたDirectusアプローチはより清潔にできます。

2026年の価格設定とライセンス

	Payload CMS	Directus
ライセンス	MIT	GPL-3.0（クラウド機能用BSL付き）
セルフホストコスト	無料	無料
クラウドホスティング	$30/月から（Payload Cloud）	$29/月から（Directus Cloud）
エンタープライズティア	カスタム価格	カスタム価格（~$1,500/月から）
プレミアム機能	いくつかの機能はクラウド専用	Directus+サブスクリプション（マーケットプレイス拡張用$99/月）

どちらもセルフホスティングのための本当のオープンソースです。PayloadのMITライセンスはより寛容です。商用製品に埋め込むことができます制限はありません。DirectusのGPL-3.0ライセンスは派生作品もGPLである必要があることを意味し、SaaSプロダクトに関係することができます。

Directusは2025年末にDirectus+を導入し、プレミアムマーケットプレイス拡張と優先サポートを提供するサブスクリプション。オプションですが、より高度な拡張機能（AIコンテンツアシスタント等）はこのペイウォールの背後にあります。

どちらを選ぶべきか

以下の場合はPayload CMSを選択：

ゼロから新しいプロジェクトを構築している（グリーンフィールド）
あなたのチームはTypeScript重い、スキーマ・アズ・コードを望む
Next.jsを使用していて、最も緊密な統合を望む
複雑で、コード定義のアクセス制御が必要
すべてを1つのデプロイ可能なユニットにしたい
MITライセンスを評価

以下の場合はDirectusを選択：

スキーマを変更する必要がある既存のデータベースがある
チームに非開発者を含んでいる
1つのCMSから複数のフロントエンド（ウェブ、モバイル、IoT）をサポートする必要がある
ビジュアルオートメーション/フロービルダーを望む
広いデータベースサポートが必要（MySQL、MSSQL、Oracle等）
CMSを別個の独立したサービスとして好む

ヘッドレスプロジェクトのこれらの選択肢を比較しており、3ヶ月間間違ったものに入ることする前に、第2意見を望む場合、ヘッドレスCMSアーキテクチャコンサルティングを提供し、正しいツールを選択する前に手伝うことができます。

フロントエンドフレームワークとしてAstroを使用しているプロジェクトの場合、Directusのスタンドアロンアプローチは自然にペアになります。Astroがビルド時またはサーバーエンドポイント経由でデータを取得するため。Payloadも機能しますが、AstroとPayloadが別のプロセスの場合、ローカルAPIアドバンテージが失われます。

FAQ

Payload CMSは本当に2026年に無料ですか？ はい。Payload CMSはMITライセンスで、セルフホスト完全に無料です。Payload Cloudは管理ホスティングサービスですが、CMS自体（すべてのコア機能を含む）はオープンソースです。セルフホストバージョンに機能ゲートはありません。

Directusは既存のデータベースを変更することなく動作できますか？ ほぼはい。Directusは既存のデータベースをイントロスペクトし、その上に管理レイヤーを作成できます。それは独自の設定用にいくつかのシステムテーブル（接頭辞付きdirectus_）を追加しますが、既存のテーブルは変更しません。これは最強の差別化要因の1つです。

独立した開発者にはどちらが良いですか？ Payload CMSはTypeScriptに快適な独立した開発者の間で人気を得ています。コードファーストワークフローは、コレクションを素早くセットアップでき、自動生成型はボイラープレートを減らします。設定ファイルを書かずにスキーマプロトタイピングのためのビジュアルインターフェースを望む場合、Directusが良いです。

Next.jsなしでPayload CMSを使用できますか？ Payload 3.xの場合、Next.jsはプライマリアダプタで、管理パネルはNext.jsで実行されます。ただし、RESTおよびGraphQL APIはすべてのフロントエンドで機能します。消費者向けサイトのNext.jsに固定されません。Payloadアドミンを実行するためにNext.jsが必要なだけです。コミュニティは追加アダプタ（Nuxtのような）についての議論がありますが、何も公式ではありません。

Directusはコンテンツローカライゼーションをどのように処理しますか？ Directusはフィールドレベルの翻訳をサポートします。フィールドを翻訳可能としてマーク、言語を構成して、Directusは関連テーブルに翻訳を保存します。APIは言語パラメータ経由で特定の言語でコンテンツをリクエストできます。それはよく実装され、年間にわたって安定しています。

どちらがより優れたプラグイン/拡張サポートを持っていますか？ Directusはより大きな拡張マーケットプレイスを持っています。特にDirectus+追加があります。カスタムインターフェース、表示、エンドポイント、フック、モジュールを構築できます。Payloadの拡張モデルはReactコンポーネントオーバーライドとプラグインに基づいています。強力ですが、生態系はより小さいです。Payloadプラグインはより焦点を絞っている傾向があります（SEOプラグイン、フォームビルダー、リダイレクト）。一方、Directus拡張ンはより広い範囲をカバーします。

大規模なデータセットのパフォーマンス違いはありますか？ 数百万行のデータセットの場合、どちらも正しくインデックスすると非常にうまく実行されます。Directusはrawクエリ柔軟性でわずかなエッジを持っています。APIクエリから直接SQLを生成します。PayloadのDrizzle ORMレイヤーは効率的ですが、小さな抽象化コストを追加します。実践では、データベースチューニングはどちらのCMSを選択するかよりもはるかに重要です。どちらもコネクションプーリングをサポートし、読み取りレプリカと動作できます。

後で1つから別に移行できますか？ できますが、簡単ではありません。コンテンツデータ自体（両方のPostgreSQLに保存）は標準のデータベースツールで移行できます。難しい部分はスキーマ定義、アクセス制御ルール、カスタムロジックを再作成することです。あなたのヘッドレスアーキテクチャでビルドしている場合、フロントエンドを切り離しながらCMS固有のAPI（抽象化レイヤーを使用）を維持することで、将来のCMS移行を大幅に簡単にします。

Payload CMS vs Directus 2026：コードファーストとデータベースファースト

2026年のPayload CMSとDirectusの比較：コードファーストかデータベースファーストか

目次

コア哲学の分岐点

スキーマ設計：コードファーストVSデータベースファースト

Payloadのコードファーストアプローチ

Directusのデータベースファーストアプローチ

スキーマ比較表

TypeScriptと開発者体験

PayloadのTypeScriptストーリー

DirectusのTypeScriptストーリー

APIレイヤーとクエリ機能

管理画面とコンテンツ編集

認証とアクセス制御

パフォーマンスとスケーラビリティ

デプロイメントとホスティング

2026年の価格設定とライセンス

どちらを選ぶべきか

FAQ

Let's build
something together.

2026年のPayload CMSとDirectusの比較：コードファーストかデータベースファーストか

目次

コア哲学の分岐点

スキーマ設計：コードファーストVSデータベースファースト

Payloadのコードファーストアプローチ

Directusのデータベースファーストアプローチ

スキーマ比較表

TypeScriptと開発者体験

PayloadのTypeScriptストーリー

DirectusのTypeScriptストーリー

APIレイヤーとクエリ機能

管理画面とコンテンツ編集

認証とアクセス制御

パフォーマンスとスケーラビリティ

デプロイメントとホスティング

2026年の価格設定とライセンス

どちらを選ぶべきか

FAQ

Let's build something together.

Let's build
something together.