WordPress、
目次
WordPress、実は何でもできる説。Webサイト以外に何が作れるのかAIに聞いてみた
自分はこれまでWordPressをかなり触ってきました。
ただ、使い方を振り返ると、ほとんどがWebサイト制作です。
企業サイトを作る。 記事を投稿できるようにする。 カスタム投稿や管理画面を使いやすくする。
そういう使い方が中心でした。
でも、改めてWordPressを見ると、最初からかなり多くのものを持っています。
投稿を管理する仕組み。 ユーザー管理。 権限。 データベース。 管理画面。 URLのルーティング。 プラグインで機能を増やす仕組み。 そしてREST API。
そこでふと、
WordPressって、普通のWebサイト以外だと何が作れるんだろう？
と思いました。
AIにも聞きながら公式ドキュメントを確認してみると、思っていた以上に守備範囲が広いです。
一方で、ここまでできるなら別の疑問も出ます。
そんなに何でもできるなら、なぜNext.jsやAstroでフロントを分ける構成があるの？
今回は、WordPressで何ができるのかを整理しつつ、最後に「何でもできる」と「何でもWordPressだけで作るべき」は別、というところまで考えてみます。
WordPressは「ブログを書くもの」だけではなかった
WordPress公式のFeaturesページでは、開発者向け機能の中でWordPressをApplication Frameworkとして使えることにも触れています。
ユーザー管理、HTTPリクエスト、データベース、URLルーティングなど、アプリケーションを作るときに必要になる機能をWordPressが持っているからです。
参考: https://wordpress.org/about/features/（外部サイト）
もちろん、WordPressをLaravelやNode.jsのような汎用Webアプリケーションフレームワークとまったく同じものとして扱うわけではありません。
ただ、
記事を投稿するCMS
だけで考えると、WordPressの機能をかなり狭く見ていることになります。
自分も長く使っているのに、そこはあまり意識していませんでした。
ECサイトも作れる
分かりやすい例がECです。
WordPressはプラグインで機能を追加できるので、商品、カート、注文、決済などを持ったECサイトへ拡張できます。
ここで面白いのは、WordPressの「投稿を管理する」という考え方が、記事以外のデータにも広げられることです。
たとえば、
商品
ブランド
店舗
キャンペーン
お知らせ
のようなデータを管理画面から扱えるようにできます。
単純なブログCMSより、かなりアプリ寄りの使い方です。
会員サイトや限定コンテンツ
WordPressはユーザーと権限の仕組みを持っています。
そのため、
ログインした人だけ見られるページ
会員ランクによって表示を変える
ユーザーごとのマイページ
管理者だけ編集できるデータ
のような仕組みも作れます。
WordPress REST APIのUsersエンドポイントにもユーザーやrole、capabilityに関する仕組みがあります。
参考: https://developer.wordpress.org/rest-api/reference/users/（外部サイト）
もちろん、認証や個人情報を扱うなら、セキュリティ設計は別途しっかり考える必要があります。
「ユーザー機能があるから簡単に安全な会員サービスが完成する」という話ではありません。
それでも、ユーザー管理をゼロから作らなくていいのはWordPressの強いところです。
予約・求人・店舗検索のような「データベース型サイト」
WordPressにはCustom Post TypeやTaxonomyがあります。
たとえば、
式場
求人
店舗
イベント
物件
スタッフ
講座のようなデータを、それぞれ独立したコンテンツとして管理できます。
Custom Post TypeをREST APIへ公開することもでき、公式ドキュメントでは register_post_type の show_in_rest を有効にする方法が案内されています。
自分はWordPressを使うとき、こうした「記事ではないデータ」を扱うこともあります。
よく考えると、ここまで来るとかなりCMSというより管理システムに近いです。
社内ツールの管理画面として使うこともできる
WordPressの管理画面は最初からかなり完成しています。
一覧。 編集。 ユーザー。 権限。 メディア。 検索。
そのため、小規模な社内ツールや情報管理の画面として使う考え方もできます。
たとえば、
案件情報
店舗データ
FAQ
マニュアル
イベント情報
などです。
ただし、複雑な承認フロー、大量データ、高いリアルタイム性、細かい業務ロジックが必要になるほど、専用のシステムを作った方が自然になるケースも増えます。
ここは「作れる」と「向いている」を分けて考えたいところです。
モバイルアプリの裏側としてWordPressを使う
ここでREST APIが効いてきます。
WordPress公式はREST APIについて、WordPressのコンテンツを完全に別のアプリケーションへ持っていく使い方もできると説明しています。
参考: https://developer.wordpress.org/rest-api/（外部サイト）
REST APIからJSONでデータを取得できるので、
WordPress
↓ REST API
Webフロント
モバイルアプリ
別システムのように、WordPressを「コンテンツを管理する裏側」として使えます。
つまりWordPressのテーマで画面を表示しなくてもいい。
ここで初めて、自分の中でWordPressの見え方がかなり変わりました。
WordPressは画面までWordPressで作らないといけないわけではない。
ということです。
Headless WordPressという使い方
WordPressをCMSとして残し、画面をNext.jsやAstroなど別のフロントエンドで作る構成は、Headless WordPressと呼ばれます。
イメージとしては、
WordPress
管理画面・コンテンツ・ユーザー
↓ API
Next.js / Astro
フロントエンドです。
WordPress側では編集者がいつもの管理画面を使える。
一方、フロント側はReactなどを使って自由に作れる。
これはかなり魅力があります。
じゃあ、そんなに何でもできるのに、なぜNext.jsやAstroを使うの？
ここが今回一番気になったところです。
WordPressだけでWebサイトを完成させられるなら、わざわざ構成を分ける必要はないようにも見えます。
でも、フロントを分離したい理由はいくつかあります。
フロントエンドの設計をWordPressから独立させたい
Reactなどのコンポーネント設計を中心に開発したい場合、Next.jsのような環境の方が自然なことがあります。
Webサイト以外でも同じコンテンツを使いたい
同じ記事や商品データを、
Web
アプリ
デジタルサイネージ
別サービスへ配信するなら、CMSと表示側を分けた方が扱いやすくなることがあります。
レンダリングやキャッシュの設計を選びたい
Next.jsは静的・動的なレンダリングを使い分けられます。
Astroも標準では静的HTMLを生成しつつ、必要なページだけオンデマンドレンダリングする構成を選べます。
つまり、表示側の技術選定をWordPressテーマの仕組みから切り離せます。
フロントとCMSを別々に進化させたい
CMSはWordPressのまま。
フロントはNext.jsから別のものへ。
あるいはWebとは別にモバイルアプリを追加する。
APIを境界にすると、それぞれを分けて考えやすくなります。
ただしHeadlessにすれば全部良くなるわけではない
ここは重要です。
分けるということは、管理するものも増えます。
WordPressだけなら、
WordPress
↓
公開で済んでいたものが、
WordPress
↓ API
フロントエンド
↓
ビルド・デプロイになります。
さらに、
プレビューをどうするか
CMS更新時にどう再生成するか
API認証をどうするか
キャッシュをどう更新するか
障害時にどこを見るか
なども考える必要があります。
小さなサイトなら、普通にWordPressテーマで作った方がシンプルなことも多いです。
WordPress公式のREST APIドキュメントにも、すでにWordPressサイトが期待どおり動いているなら、無理にREST APIを使う必要はないという趣旨の説明があります。
参考: https://developer.wordpress.org/rest-api/（外部サイト）
ここはかなり納得しました。
「何でもできる」と「何でもWordPressでやる」は別
今回整理して一番感じたのは、
WordPressって思っていた以上に何でもできる。
ということです。
Webサイトだけではなく、
EC。 会員サイト。 予約。 求人。 店舗検索。 管理ツール。 モバイルアプリのCMS。 Headless CMS。
かなり幅があります。
一方で、
できるから、それを選ぶ。
では足りません。
小さな企業サイトならWordPressだけの方がシンプルかもしれない。
React中心のWebアプリならNext.jsの方が自然かもしれない。
静的な部分が多く、必要なところだけJavaScriptを使いたいならAstroが合うかもしれない。
結局大事なのは、
WordPressで作れるかではなく、今回の要件なら何をWordPressに任せるのが一番楽か。
だと思います。
自分もこれまではWordPressを「Webサイトを作るもの」として見ることが多かったのですが、今後は、
管理画面 + データ + APIを持った基盤
として考える場面も増えそうです。
