Directus(ディレクタス)は、既存のSQLデータベースにREST・GraphQLのAPIと、ノーコードの管理画面「Data Studio」をかぶせる、ソースコード公開型のデータ基盤です。ヘッドレスCMSとして使われることが多いものの、CMS専用ではなく、社内の管理画面やアプリのバックエンドにも使えます。公式サイトはdirectus.com、ソースはGitHubのdirectus/directusです。なお同じ読みの「株式会社ディレクタス」(国内企業)とは無関係です。
2026年6月10日公開のDirectus 12で、ライセンスがBSL 1.1からMSCL-1.0-GPLへ変わり、セルフホストでも利用枠(ユーザー席数・コレクション数)が実際に制限されるようになりました。古い解説記事の「セルフホストなら無制限で無料」は、もう成り立ちません。この記事では2026年10月14日時点の最新版12.5.0を基準に、仕組み・ライセンスと料金・Dockerでの起動・APIの使い方・CMSとしての入稿画面の作り方を、ローカルで動かした結果を交えて整理します。
まとめ:Directusを選ぶ前に押さえる要点
- Directusは「データベースファースト」。PostgreSQL・MySQL・MariaDB・SQLite・MS SQL Server・OracleDB・CockroachDBの既存テーブルをそのまま管理画面とAPIに載せられる
- 最新版は12.5.0(2026年10月7日公開)。ライセンスの更新に失敗しても現在のライセンスを維持して再試行するようになった。IPの許可リストの書式チェックが厳しくなったので、ポリシーにIP制限を設定している環境は更新前に値を確認する
- ライセンスキー無しのセルフホストはCore枠=Studioユーザー3席・コレクション25個・Flow 5本で、操作履歴と変更履歴(リビジョン)は30日分まで。超える場合はTeam(月額499ドル〜)かEnterprise、または年間売上500万ドル未満かつ従業員50人未満ならOpen Innovation Grantで無償利用できる
- API専用ユーザーは、App Access・Admin Accessのどちらも付与されていなければ席数に数えない。翻訳や多対多の中間テーブルはコレクションに数えるため、CMSとして多言語・ブロック構成を組むと25個は早く埋まる
- v11から上げると、SSO・カスタム権限ルール・独自LLM接続はライセンスが無いと30日の猶予後に止まる
- 起動はDocker Composeが公式推奨。
SECRETとPUBLIC_URLは必ず設定し、生存確認は/server/pingを使い、/server/healthはトークン付きで叩く(v12から未認証は403)
Directusの仕組み:既存DBにAPIと管理画面を重ねる構造
多くのヘッドレスCMSは、CMS側が決めたスキーマでデータを持ちます。Directusは逆で、データベースのテーブルが主、Directusはその上に乗る層です。テーブルを「コレクション」、列を「フィールド」として扱い、Data Studioで作ったコレクションも実体は普通のテーブルになります。Directusを外しても、データはそのままSQLで読めます。
Data StudioとAPI(REST・GraphQL・WebSocket)の関係
コレクションを作った時点で、コード生成やビルドの手順なしにREST(/items/<コレクション名>)とGraphQL(/graphql)のエンドポイントが使えるようになります。WEBSOCKETS_ENABLED=trueにすれば、同じデータをWebSocket経由で購読するRealtime機能も有効になります。Data Studio自体もこのAPIを使って動いているため、管理画面でできる操作はほぼすべてAPIからも実行できます。
対応データベースとスキーマの制約
公式の要件ページは、PostgreSQL・MySQL・SQLite・MS SQL Server・MariaDB・CockroachDB・OracleDBの各LTS版に対応すると書いています。MySQL 5.7はv11.7.0で正式に対象外になりました。注意したいのは「1つのデータベースで複数スキーマを使う構成には対応していない」と明記されている点です。PostgreSQLでスキーマを分けて運用している既存システムに後付けする場合は、対象を1スキーマに寄せる設計が要ります。
Directus自身の設定はdirectus_で始まるシステムテーブルに保存され、既存テーブルは「登録」するまで管理画面に出てきません。
Directus 12のライセンスと料金
ここが2026年に入って最も大きく変わった部分です。旧版の記事やZenn・Qiitaの解説の多くはBSL 1.1時代の前提で書かれているため、読み替えが必要です。
BSL 1.1からMSCL-1.0-GPLへの変更内容
Directusのライセンスはこれまでに2回変わっています。v9まではGPLv3、2023年4月26日公開のv10.0.0からBSL 1.1(総収入・総予算・調達額のうち最も大きい値=Total Financesが直近12か月で500万ドル以下なら本番利用も無償、各版は3年後にGPLv3へ移行)、そして2026年6月10日公開のv12.0.0からMSCL-1.0-GPL(Monospace Sustainable Core License)です。リポジトリのlicenseファイルによると、利用・改変・再配布は「Competing Use(Directusそのものを、ライセンス料を取る公式の商用提供と競合する形で第三者に提供すること)」以外なら認められます。自社利用、非商用の教育・研究、顧客向けにDirectusを導入・ホスティングする受託サービスは、明示的に許可された目的に入っています。
一方で、ライセンスキーの仕組みを無効化・回避する改変は禁止です。また各版は公開から4年後にGPL-3.0でも使えるようになると定められています(Grant of Future License)。OSI認定のオープンソースライセンスではないため、社内規程で「OSSのみ可」としている組織では、法務確認の対象になります。
Core枠と有料プランの上限
ライセンスキーを設定しないセルフホストは、自動的にCoreティアで動きます。料金ページ(2026年10月14日取得)の上限は次のとおりです。価格は変わることがあるため、契約前にDirectus公式の料金ページで確認してください。
| 項目 | Core | Team | Enterprise |
|---|---|---|---|
| 料金 | 0ドル | 月499ドル(年契約)・月契約は599ドル | 個別見積 |
| Directus Cloudで運用 | 月99ドルを追加 | 月99ドルを追加 | 個別見積 |
| Studioユーザー席 | 3 | 10(SSO)〜・追加50ドル/席/月 | 個別 |
| コレクション | 25 | 50(100まで拡張可)・追加25個で100ドル | 200以上 |
| Flow | 5 | 20 | 無制限 |
| 操作履歴・変更履歴の保持 | 30日 | 90日 | 設定可 |
| SSO(SAML・OIDC) | 不可 | 可 | 可 |
| 独自LLM・オフライン認証 | 不可 | 不可 | 可 |
CMSとして使う場合に見落としやすいのが履歴の保持期間です。Core枠では、記事の変更履歴(リビジョン)から差し戻せるのは30日以内の版だけです。Teamでも履歴保持は90日なので、半年前の版に戻すには、必要な保持期間を設定できるEnterpriseを検討するか、別途保存したバックアップから復元する運用が必要です。
年間売上500万ドル未満かつ従業員50人未満の組織は、Open Innovation Grantに申請するとライセンスキーを無償で受け取れます。料金ページは「機能制限なし」と説明していますが、OIGの公式ガイドには上位商用ティア限定の機能もあると記載されています。セルフホストは0ドル、Directus Cloudのホスティングは月99ドルで、必要な機能が付与されるかは契約前に確認してください。BSL時代の無償条件はTotal Finances(総収入・総予算・調達額の最大値)500万ドル以下という金額基準で、v12では「従業員50人未満」も条件に入りました。売上が小さくても人数の多い組織は対象外になる点に注意してください。
2026年9月に公式ブログで条件が明確化されています。判定対象はData Studioにログインする企業で、受託開発で顧客もStudioにログインするなら、顧客側も売上500万ドル未満・従業員50人未満でなければなりません。グラントのキーは無期限・席数無制限で、1つのキーにアクティベーションが5回分(同一プロジェクトのローカル・開発・ステージング・本番と予備の1環境分)あります。アクティベーションはプロジェクトのDBとPUBLIC_URLに結び付くため、レプリカを増やしても消費は1回分ですが、インスタンスを破棄する前にライセンスを無効化しないと、その枠は消費されたまま残ります。
席数とコレクション数の数え方
公式のライセンス解説で、見積もりを誤りやすい定義がはっきり書かれています。
- 席:App AccessかAdmin Accessを持つポリシーが付いた、アクティブなユーザーを数える。ログインしたことがあるかどうかは関係ない。アプリの会員やトークンで接続する連携用アカウントのように、API経由だけで使うユーザーは何人いても数えない(公式例:編集者2人と会員5万人なら2席)
- コレクション:Data Studioに登録された利用者のコレクションを数える。
articles_translationsのような翻訳用コレクションや、多対多・多対任意リレーションの中間テーブルも1個ずつ数える - 数えないもの:
directus_で始まるシステムコレクション、フォルダ、Directusに登録していないDBだけのテーブル
今どれだけ使っているかは、管理者のトークンでGET /licenseを叩くと確認できます。12.5.0で上限まで埋めた状態では次のように返りました(抜粋)。
{"data":{"name":"Core","status":"active","invalid_reason":null,
"entitlements":{"seats":{"limit":3},"collections":{"limit":25},"flows":{"limit":5},
"revision_historical_timeframe":{"limit":2592000},"sso_enabled":{"default":false}, ...},
"usage":{"seats":3,"collections":25,"flows":0}}}
2592000は秒で、30日に当たります。12.5.0のリリースノートは/server/licenseの応答が変わったと書いていますが、手元の12.5.0では/server/licenseは404(ROUTE_NOT_FOUND)で、ソースでも/licenseにマウントされていました。監視やCIで上限の手前を検知したい場合は、usageとlimitの差を見るのが確実です。
v11から上げるときに止まる機能と30日の猶予
v12のライセンス強制で、ライセンスが無いと次の機能が止まります。新規インスタンスでは即時、v11から上げたインスタンスは更新から30日の猶予期間の後です。
- SSOログイン(SSOだけで入っていたユーザーは、メールとパスワードの利用者に切り替えないとログインできない)
- アクセスポリシーのカスタム権限ルール(無視される)
- 独自・セルフホストのLLM接続、AI翻訳
猶予期間が過ぎても上限を超えたままだと、/itemsなどの主要APIが止まり、GraphQL・WebSocket・MCPも無効化され、管理者以外はログインできなくなります。データは削除されません。解消するには、ライセンスを追加するか、管理者がStudioに表示される解消手順(Resolution Flow)で無効化するユーザーやコレクションを選び、上限内に収めます。無効化したコレクションは「Inactive」になり、12.4.0以降はAPIからの読み書きがCOLLECTION_INACTIVE(403)で拒否されます。本番で動いているv11を上げる場合は、先に席数とコレクション数を数え、ライセンスの手配を済ませてから更新してください。変更点の全体はDirectus 12の破壊的変更一覧にまとまっています。
有料キーやグラントのキーを入れた環境で気になるのが、ライセンスサーバーに届かなかったときの動きです。12.5.0のリリースノートによると、ライセンスの取得に失敗しても現在のライセンスは有効なまま残り、定期チェックで再試行されます。Studioには更新できなかった理由と失効する日時が警告として出ます。公式のライセンス解説によると、再検証は少なくとも12時間ごとにlicensing.directus.comへ送られ、失効日までに成功しなければCore枠に戻ります。そのときに使用量がCore枠を超えていれば、上で述べたロックダウンの状態になります。外向き通信を閉じた環境では、Enterprise限定のオフライン用トークンが必要です。
Dockerでのセルフホスト手順(Directus 12.5.0)
公式の要件ページは「DirectusはDockerイメージとして配布している」と書いており、セルフホストの前提はDockerです。npmパッケージ(directus)も公開されていますが、enginesでNode.js 22以上を要求します。macOS(Intel)のNode.js 26.5.0でnpm i [email protected]を実行したところ、依存パッケージisolated-vm 5.0.3にビルド済みバイナリが無くビルドに失敗しました。Node.js 22.23.3では[email protected]が1,061パッケージ・約2分で入りました。手元で試すだけでも、Dockerを使うかNode.js 22系を選ぶのが無難です。
docker-compose.ymlの最小構成と必須の環境変数
公式の「Create a Project」ページの構成を、最新版12.5.0のタグに合わせたものです。空のディレクトリにdatabase・uploads・extensionsの3つのサブディレクトリを作り、次のファイルを置いてdocker compose upを実行します。
services:
directus:
image: directus/directus:12.5.0
ports:
- 8055:8055
volumes:
- ./database:/directus/database
- ./uploads:/directus/uploads
- ./extensions:/directus/extensions
environment:
SECRET: "replace-with-random-value"
DB_CLIENT: "sqlite3"
DB_FILENAME: "/directus/database/data.db"
WEBSOCKETS_ENABLED: "true"
PUBLIC_URL: "http://localhost:8055/"
LICENSE_KEY: ""
http://localhost:8055を開くと最初の管理者アカウントを作る画面が出ます。各変数の役割は次のとおりです。
SECRET:アクセストークンの署名に使う必須の値。長いランダム文字列にするDB_CLIENT:pg・mysql・sqlite3・mssql・oracledb・cockroachdbのいずれか。SQLite以外はDB_HOST・DB_PORT・DB_DATABASE・DB_USER・DB_PASSWORDを足すPUBLIC_URL:外部から見たURL。ライセンスキーは最初の有効化時にこのURLへ結び付くため、/のような相対値のままだと有効化できないLICENSE_KEY:空ならCore枠。Open Innovation Grantや有料プランのキーをここに入れる
イメージのタグはlatestではなく版番号で固定します。Directusはおおむね月1回リリースされ、DBのマイグレーションは更新時に自動で走ります。latestのままだと、docker compose pullで新しいイメージを取得してコンテナを作り直した時点で、破壊的変更を読まないうちにスキーマが上がってしまいます。
本番に出す前に変える設定
上の構成は公式も「本番向けではない」と書いています。本番ではDBをPostgreSQLなどに替えるほか、v12で変わった次の既定値に注意してください。
- ヘルスチェックの宛先:v12.0.0から
/server/healthは認証が必要。ローカルで12.5.0を起動して未認証で叩くと403 FORBIDDENが返り、/server/pingはpong(200)が返った。ロードバランサーやコンテナの死活監視が/server/healthをトークン無しで叩いていると、更新後は正常なインスタンスが異常扱いになる。プロセスの生存確認は/server/pingへ移し、DB・Redis・ストレージの状態まで見たい監視は、専用ユーザーの静的トークンを付けて/server/healthを叩く(/server/pingはDBなどを確認しない) - IP_TRUST_PROXY:既定が
trueからfalseに変わった。リバースプロキシの後ろでX-Forwarded-Forから利用者のIPを取っている場合は明示的に設定する - ポリシーのIP制限:12.5.0でIP許可リストの書式チェックが厳しくなり、
10.0.0.0/ 24のようにプレフィックスの書き方が崩れた値は受け付けなくなった。すでにそうした値を保存しているポリシーは、そのポリシーを持つユーザーのリクエストがすべて失敗するので、更新前にip_accessの値を見直す - スキーマ構築のタイムアウト:12.5.0で
CACHE_SCHEMA_MAX_ITERATIONSが廃止され、CACHE_SCHEMA_SYNC_TIMEOUT(既定60000ミリ秒)がスキーマの構築そのものにも効くようになった。コレクションが多い環境でこの値を小さく設定していると、起動時に構築が終わらない - コンテナ内のnpm:12.1.0でイメージが堅牢化され、
npmとnpxが含まれなくなった。起動時に拡張機能をnpmで入れる運用は動かないので、拡張はイメージのビルド時に組み込む。distrolessの-dhiタグも用意されている - リソースとRedis:公式の最低要件は0.25 vCPU・512MBのコンテナ1つ、推奨は1 vCPU・2GBを2つ。Redisは任意だが、キャッシュ用途に推奨され、水平スケールする場合は必須
Directusの使い方:コレクション作成からAPIでの取得まで
ここからは、Directus 12.5.0をSQLiteでローカル起動し、APIから操作した結果をもとに基本の流れを示します。Data Studioで同じ操作をしても、裏側では同じAPIが呼ばれます。
コレクション作成時に実行されるSQLとテーブル
コレクションを作ると、DBに実際のテーブルが作られます。管理者のアクセストークンで、自動採番の整数主キーid・文字列title・テキストbodyを持つarticlesを作ります。
curl -X POST http://localhost:8055/collections \
-H "Authorization: Bearer <アクセストークン>" -H "Content-Type: application/json" \
-d '{"collection":"articles","schema":{},"meta":{},"fields":[
{"field":"id","type":"integer","schema":{"is_primary_key":true,"has_auto_increment":true}},
{"field":"title","type":"string"},{"field":"body","type":"text"}]}'
応答には、実行されたSQLがそのまま入っていました。
CREATE TABLE `articles` (`id` integer not null primary key autoincrement, `title` varchar(255) null, `body` text null)
Directusを使わなくなっても、このテーブルは普通のSQLで読めます。逆に、既存DBにすでにあるテーブルは、Data Studioの「Data Model」設定から登録すればコレクションとして扱えます。なおschemaとmetaのどちらも付けずにPOST /collectionsすると、12.5.0では400 INVALID_PAYLOAD("schema" or "meta" is required)が返ります。12.4.1以前は同じ誤りが403として返り、権限の問題と見分けがつきませんでした。
RESTとGraphQLのクエリと応答形式
RESTは/items/<コレクション名>に対して、fields(取得する列)・filter・sort・limitなどのクエリを付けます。
curl -g "http://localhost:8055/items/articles?fields=id,title&filter[title][_contains]=Hello" \
-H "Authorization: Bearer <静的トークン>"
# => {"data":[{"id":1,"title":"Hello Directus"}]}
この応答は、事前に次のリクエストで2件を登録した状態のものです(管理者でログインして得たアクセストークンを使用)。
curl -X POST http://localhost:8055/items/articles \
-H "Authorization: Bearer <アクセストークン>" -H "Content-Type: application/json" \
-d '[{"title":"Hello Directus","body":"first"},{"title":"Second","body":"two"}]'
curlでは-gを付けてください。付けないとfilter[title]の角括弧がcurl側のURL展開として解釈され、リクエストが送られません。GraphQLは/graphqlに1本でまとまっています。
curl -X POST http://localhost:8055/graphql \
-H "Authorization: Bearer <静的トークン>" -H "Content-Type: application/json" \
-d '{"query":"{ articles(sort:[\"id\"]) { id title } }"}'
# => {"data":{"articles":[{"id":"1","title":"Hello Directus"},{"id":"2","title":"Second"}]}}
同じidが、RESTでは数値の1、GraphQLでは文字列の"1"で返ってきます。GraphQLの主キーはID型で、JSONでは文字列として出力されるためです。フロントエンドでRESTとGraphQLを混ぜて使う場合は、IDの比較を型に依存させないようにします。なお主キーの型はv11.6.0でStringからIDに変わっており、主キーを変数で渡すクエリは変数の型をIDに直す必要があります。
ファイルのアップロードと配信
画像や添付ファイルは/filesにmultipart形式で送ります。次の例では、実行ディレクトリにhello.txtを用意し、トークンを実際の値へ置き換えてください。
curl -X POST http://localhost:8055/files \
-H "Authorization: Bearer <アクセストークン>" \
-F "title=hello" -F "[email protected];type=text/plain"
# => {"data":{"id":"ae52efec-...","storage":"local","filename_disk":"ae52efec-....txt",
# "filename_download":"hello.txt","type":"text/plain","filesize":15, ...}}
ファイルのIDはUUIDで、ディスク上の名前もUUIDに置き換わります。中身は/assets/<ID>で取り出せますが、手元の12.5.0では未認証だと403でした。ファイルの実体はdirectus_filesというシステムコレクションで管理されており、Public用のポリシーにこのコレクションの読み取り権限を足さない限り、公開サイトから画像を直接表示できません。
権限とトークン:既定ではすべて非公開
作ったばかりのコレクションを未認証でGET /items/articlesすると、403 FORBIDDENが返ります。公開サイトから読ませるなら、Public用のアクセスポリシーにそのコレクションの読み取り権限を足します。12.5.0からは、Publicポリシーを編集している間は常に警告が出て、システムコレクションの権限を保存するときに確認ダイアログが挟まるようになりました。サーバー間の連携では、連携専用ユーザーを作って静的トークン(ユーザーのtokenフィールド)を発行し、Authorization: Bearerヘッダーで送るのが基本です。v11.0.0で権限はロールに直接付ける方式からポリシー単位に移ったため、v10以前の解説にある「ロールの権限画面」は今の画面と一致しません。
Core枠の上限に達したときの応答
ライセンスキー無しで、管理者ロールのユーザーとコレクションを上限まで作ってみました。12.4.1でも12.5.0でも、26個目のコレクションと、Data Studioにアクセスできる4人目のユーザーは、どちらも403で拒否されました。
{"errors":[{"message":"collections limit exceeded.","extensions":{"category":"collections","code":"LIMIT_EXCEEDED"}}]}
{"errors":[{"message":"seats limit exceeded.","extensions":{"category":"seats","code":"LIMIT_EXCEEDED"}}]}
一方、ロールもポリシーも付けないAPI専用のユーザーは、上限に達した後でも作成できました。会員登録をDirectusのユーザーで受ける構成でも、管理画面の席だけを数えればよいことが動作でも確かめられます。アプリやCIでユーザーやコレクションを自動作成している場合は、LIMIT_EXCEEDEDを通常のエラーと区別して扱う処理を入れておくと、原因の切り分けが早くなります。
DirectusのCMS設計:記事の入稿画面と入力形式
Directusには「記事」や「ページ」といった既定の型がありません。入稿画面は、コレクションとフィールドの組み合わせで自分で作ります。自由度が高い分、どの入力形式と関係(リレーション)を選ぶかで、保存されるデータの形とCore枠の消費が変わります。
本文の入力形式:WYSIWYG・Markdown・Block Editorの保存形式
本文フィールドに使える主な入力部品(インターフェース)は3つで、公式のインターフェース一覧によると保存される型が違います。
| 入力部品 | 保存される型 | フロント側の処理 |
|---|---|---|
| WYSIWYG | HTML(Text型) | HTMLを無害化して表示 |
| Markdown | Markdown(Text型) | Markdownを変換して表示 |
| Block Editor | JSON | ブロック種別ごとに描画 |
選ぶ基準ははっきりしています。外部ライターや非エンジニアが装飾まで自由に触るならWYSIWYG、エンジニアが中心でGitの文書と同じ書き方をしたいならMarkdown、デザインの崩れを防ぎたいサイトならBlock Editorです。WYSIWYGは保存されたHTMLをそのまま描画するとレイアウトが崩れやすく、許可するタグをツールバーの設定とフロント側の両方で絞る必要があります。12.5.0ではWYSIWYGで画像にリンクを付けられるようになり、貼り付けた内容から対応しないマークアップを取り除いて、その場で知らせる動きも加わりました。
多言語とブロック構成で増えるコレクション
CMSで使う2つの定番の構成は、どちらもコレクションを自動で追加します。
- 翻訳(Translations):翻訳フィールドを作ると、
languagesコレクションと、articles_translationsのような中間コレクションが作られる。公式の翻訳ガイドによると、自動作成されるlanguagesに最初から入っている言語は英語・アラビア語・ドイツ語・フランス語・ロシア語・スペイン語・イタリア語・ポルトガル語で、日本語は自分で追加する - Builder(M2A):見出し・本文・画像などのブロックを並べてページを組む部品。追加すると多対多の中間コレクションが作られ、ブロックの種類ごとにもコレクションが要る
たとえば「記事・カテゴリ・タグ」を多言語化し、ページをヒーロー・本文・画像・CTAの4種類のブロックで組むと、記事系でarticles・categories・tags・articles_tags・languagesと翻訳用の3つで8個、ページ系でpages・中間コレクション・ブロック4種で6個になり、それだけで14個、Core枠の残りは11個です。サイト数ではなく、追加するコンテンツ型・翻訳用コレクション・中間テーブルの合計で収まるかを判断してください。
プレビューと公開前の確認
Live Previewを使うと、公開前の変更をブラウザの再読み込みなしにフロントエンドの画面で確かめられます。設定はSettings → Data Modelで対象のコレクションを選び、「Preview URL」にフロントエンドのURLと、記事を特定するフィールド(slugなど)を指定します。12.5.0ではプロジェクト設定に「Preview Base URL」が加わり、Preview URLの中で変数として選べるようになりました。本番・ステージングでフロントのドメインが違う場合も、コレクションごとにURLを書き換えずに済みます。画面はiframeで埋め込まれるため、Directus側の環境変数CONTENT_SECURITY_POLICY_DIRECTIVES__FRAME_SRCにフロントのURLを設定し、フロント側はContent-Security-Policy: frame-ancestors 'self' <DirectusのURL>を返すようにします。どちらかが欠けると、プレビュー欄は空白のままです。
管理画面の日本語表示
Data Studioの表示言語は、ユーザーごとの設定で日本語(ja-JP)に切り替えられます。ただし翻訳はコミュニティの有志がCrowdinで進めているもので、すべては訳されていません。12.5.0のソースで翻訳ファイルを数えると、英語の翻訳キー約2,980個のうち日本語訳があるのは約2,050個(およそ7割)で、残りは英語で表示されます。日本語訳が無いキーにはlicense_keyやcollection_inactiveなど、v12で加わったライセンスキーの入力やコレクションの無効化に関わる文言が含まれ、新しい画面ほど英語が残っています。そのため、編集担当者向けの手順書は日本語と英語の表示名を併記しておくと迷いません。
Flows・MCP・拡張:自動化とAI連携の機能
Flowsは、データ変更・スケジュール・Webhook・手動実行などをトリガーに、条件分岐・HTTPリクエスト・メール送信・アイテム更新といった操作をノーコードでつなぐ自動化機能です。Core枠では5本までです。12.3.0で「Update Items」「Delete Items」操作の対象を空にしたときの動作が変わり、以前は全件が対象になっていたのが、何もせずnullを返すようになりました。全件更新が必要なFlowは{"limit": -1}を明示的に指定しないと動かなくなっています。
MCPサーバーはv11.12以降のDirectusに組み込まれています。既定では無効で、管理者が「Settings → AI → Model Context Protocol」で有効化し、https://<DirectusのURL>/mcpをClaudeやChatGPTなどのMCPクライアントに登録します。認証は、ブラウザで承認するOAuth(セルフホストではMCP_OAUTH_ENABLED=trueと登録方式の有効化が必要)か、静的アクセストークンのどちらかを設定します。AIが扱えるのは接続に使ったユーザーの権限の範囲だけです。ツール定義が多すぎてクライアントの文脈を圧迫する場合は、?tool_mode=registryを付けると公開ツールがsearch・execute・schemaの3つに絞られます。ただし公式はexecuteの自動承認をしないよう警告しています。読み書きどちらも実行できるためです。
独自機能はExtensions(エンドポイント・フック・インターフェース・レイアウトなど)で足せます。v12でData Studioのデザインが刷新され、テーマ系のプロパティがshellスコープへまとめ直されたため、テーマ拡張やインターフェース拡張を自作している場合は更新前に動作を確認してください。
Strapi・Contentful・Hasuraとの違いと選び方
同じ「APIを自動で用意する」系統でも、データの持ち方と課金の軸が違います。
| 製品 | データの持ち方 | 主なAPI | セルフホストの条件 |
|---|---|---|---|
| Directus | 既存SQL DBを直接 | REST・GraphQL・WebSocket | MSCL・Core枠あり |
| Strapi | Strapiが定義したスキーマ | REST・GraphQL | Community版はMIT(ee/は除く) |
| Contentful | SaaS側に保持 | REST・GraphQL | 不可(SaaSのみ) |
| Hasura | 既存DBを直接 | GraphQL中心 | v2本体はApache-2.0 |
Directusが向くのは、すでに業務データがSQLデータベースにあり、そこへ管理画面とAPIを後付けしたい場合です。既存のテーブルを作り直さずに登録して使える点が、比較表の中ではHasuraと並ぶDirectusの特徴です。既存システムへのAPIの後付けや連携の設計から相談したい場合は、API開発・システム連携の支援も行っています。
逆に、採用を避けたほうがよい場面もはっきりしています。管理画面を使う担当者が4人以上いて、売上規模がOpen Innovation Grantの条件を超える組織が、ライセンス費用ゼロを前提に選ぶのは誤りです。Core枠の3席では回らず、Teamの最低料金(月499ドル)がかかります。また、Directusを組み込んだCMSを自社サービスとして他社に有償提供する事業は、Competing Useに当たらないか法務で確認が必要です。コンテンツモデル中心で一から作るならStrapiの使い方と料金、運用をすべてSaaSに任せたいならContentfulのAPI構成と料金の増え方、GraphQL中心で、Apache-2.0のHasura v2本体をセルフホストしたいなら既存DBからGraphQL APIを生成するHasuraが比較対象になります。ヘッドレスCMS全体の分類から選び直したい場合はヘッドレスCMSと従来型CMSの違いを参照してください。
よくある質問
Directusは無料で使えますか?
ライセンスキー無しのセルフホストはCore枠(Studioユーザー3席・コレクション25個・Flow 5本)の範囲で無料です。超える場合は有料プランが必要ですが、年間売上500万ドル未満かつ従業員50人未満ならOpen Innovation Grantで無償のライセンスキーを受け取れます。
Directusはオープンソースですか?
ソースコードはGitHubで公開されていますが、v12のライセンスMSCL-1.0-GPLはOSI認定のオープンソースライセンスではありません。各版は公開から4年後にGPL-3.0でも利用できるようになります。
Directus Cloudとセルフホストの違いは何ですか?
Directus Cloudは開発元が運用するマネージド環境で、15以上のリージョンから選べ、14日間の無料試用があります。料金ページではクラウドでのホスティングは各プランへのアドオン扱いです。セルフホストはDockerイメージを自分の環境で動かし、DBやRedis、バックアップも自分で用意します。
MySQLの既存データベースにつなげますか?
つなげます。DB_CLIENT=mysqlと接続情報を設定して起動し、既存テーブルをコレクションとして登録すると管理画面とAPIに出てきます。MySQL 5.7はv11.7.0で対象外になったため、MySQL 8.4などのLTS版が前提です。1つのDBで複数スキーマを使う構成には対応していません。
SSO(OIDC・SAML)は使えますか?
v12からSSOはライセンスが必要な機能です。Core枠では使えず、Team以上かOpen Innovation Grantのライセンスキーが要ります。v11でSSOを使っていたインスタンスは、更新後30日の猶予期間を過ぎるとSSOログインが止まります。