1. JSON:APIを有効化してみる
Drupal 11でJSON:APIを利用する最初のステップはシンプルです。
- 管理画面「拡張機能」で JSON:API にチェックを入れる
- ブラウザで
/jsonapiにアクセス
これだけで、公開可能なエンティティごとのリソース一覧が返ってきます。
通常、APIを構築するにはルーティングやコントローラを設計し、認証やシリアライズまで考えなければなりません。
しかしDrupalでは、モジュールを有効化するだけで一通りの仕組みが揃います
表向きは「有効化するだけ」ですが、裏では以下の仕組みが動いています。
- ルーティング生成：各エンティティごとにエンドポイントを作成
- シリアライズ：データをJSON:API仕様に整形
- アクセス制御：既存の権限をそのまま反映
- キャッシュタグ付与：更新時に関連するキャッシュのみを無効化
開発者がゼロからAPIを設計する場合、これらを自前で実装しなければなりません。
Drupalはそれを「標準機能」として提供しているのです。
2. 権限管理
「APIを使うなら専用の権限があるのでは？」と考えがちですが、JSON:APIは違います。
Drupalの既存の権限をそのまま尊重する設計になっています。
- 匿名ユーザーに記事を公開する → 匿名ロールに「公開済みコンテンツを閲覧」を付与
- 権限を与えなければ、API経由でも403が返る
つまり、サイトで表示できるものだけがAPIからも見えるという直感的なルールです。
新しい仕組みを学ばなくても運用できるため、編集担当者にとっても負担が少なく済みます。
3. 書き込み操作（CRUD） ― 有効化は任意
権限設定の話をもう少し・・・
JSON:APIは標準では 読み取り専用です。
記事の作成や更新、削除といった操作をAPI経由で行いたい場合は、/admin/config/services/jsonapi にある設定画面で「CRUD操作を許可」をオンにする必要があります。
これはセキュリティの観点からも理にかなっています。意図せず書き込みが外部に開放されるのを防ぐためです。
実際の運用では、認証（Basic Auth、OAuth、JWTなど）と組み合わせ、どのユーザーがどの操作を行えるのかをきちんと設計する必要があります。
4. エンティティAPI ― Drupalを支える共通モデル
ではなぜそもそもDrupalでは、ヘッドレスCMSとして向いているのか？
それは[あらゆるデータを エンティティ として扱う]からです。
- タイプ：ノード、ユーザー、タクソノミー、メディア
- バンドル：タイプの下位分類（例：ノード → 記事、固定ページ）
- フィールド：タイトル、本文、画像、タグなどの属性
このモデルのおかげで、新しいコンテンツタイプを追加すると自動で /jsonapi/node/{bundle} のようなエンドポイントが生成されます。
拡張しても一貫性のあるAPIが維持されるのは、他のCMSにない強みです。
5. 翻訳とリビジョン ― エンタープライズ運用に必須の要素
またDrupalの大きな特徴である多言語機能に関してはどうでしょうか？
そちらも問題ありません。
Drupalではフィールド単位で翻訳が管理され、APIでも langcode を指定するだけで特定の言語のデータを取得できます。
※以下は"/jsonapi/node/article?filter[langcode]=en "にアクセスし英語の記事コンテンツのみ表示
さらに、リビジョン機能により過去の編集履歴が保持され、差分確認や復元が可能です。
「翻訳が未反映の状態をどう扱うか」「誤った更新を元に戻す」といった課題に対応できるのは、ヘッドレスCMSとして大きなアドバンテージです。
6. キャッシュ制御 ― 更新が即座に反映される仕組み
ヘッドレス運用でしばしば問題になるのが「編集したのにフロントに反映されない」という状況です。
Drupalは キャッシュタグ と キャッシュコンテキスト によってこれを解決します。
- キャッシュタグ：レスポンスに「node:5」のようなタグが付与され、ノード更新時にそのタグを持つキャッシュが自動失効
- キャッシュコンテキスト：権限や言語ごとにキャッシュを分割し、条件ごとに最適なレスポンスを返す
この仕組みにより、保存ボタンを押した直後にフロントが更新される体験を担保できます。
7. 実運用で注意すべきこと
ここまでDrupalのJSON:APIの設定について説明してまいりました。
とはいえ、実案件で使用するのであれば以下のような注意点もございます。
- CORS設定：
services.ymlのcors.configに、フロントで利用するドメインを追記。ローカルは緩め、本番は限定的に。 - 認証：開発時はBasic Authで十分だが、本番はOAuthやJWTを推奨。
- 不要データの整理：JSON:API Extrasを利用すれば、エンドポイントやフィールド単位で公開・非公開を柔軟に管理可能。
まとめ
Drupalは「ただのAPIサーバー」ではありません。
- JSON:APIを有効化するだけで即利用可能
- 権限はDrupal標準を利用（新しい仕組みを学ぶ必要なし）
- CRUDはオプションとして必要に応じて追加
- エンティティAPIで統一モデルを維持
- 翻訳・リビジョン・キャッシュ制御をそのまま活用
ヘッドレスCMSとしてのDrupal 11 の真価は、モジュールを「有効にするだけ」で API が使えるようになるだけでなく、既存の CMS 機能である権限・翻訳・リビジョン・キャッシュ制御も自然に使える点にあります。
特に、読み取り専用状態から CRUD を必要に応じて有効化できる設定の柔軟性、匿名ユーザーなどのロールによるアクセス制限の明快さ、そしてキャッシュタグやキャッシュコンテキストによる更新の即時反映などが強みです。
このように、DrupalのJSON:API は「ただデータを出すだけの仕組み」ではなく、運用性・セキュリティ・拡張性を兼ね備えたヘッドレス基盤として、大規模ヘッドレスプロジェクトでも安心できる選択肢です。
今回は Drupal コアに標準搭載されている JSON:API の基本を整理しましたが、ヘッドレス化の実践はこれで終わりではありません。
Next.js やNuxt.jsなどのフロントエンドとの具体的な連携、認証やCORS設定のベストプラクティス、大規模運用でのパフォーマンスチューニングなど、掘り下げることのできるテーマはまだ多くあります。
これらについては、また別の記事で詳しく書いていこうと思いますので楽しみにお待ちいただけると幸いです！
