流行りのSupabaseローカル環境が気になる？

モダンなWebアプリケーション開発において、Firebaseに代わるOSSのBaaS（Backend as a Service）として確固たる地位を築いた「Supabase」。特にそのローカル開発環境（Supabase CLI + Docker）は、マイグレーション管理の手軽さや型定義の自動生成など、エンジニアにとって魅力的なワードが並びます。

「これからはSupabaseローカルで環境を作って、スマートにシステムを構築するのがモダンで正解だ」

もしあなたがそう信じて、限られたインフラリソースの中でシステムを組もうとしているなら、少しだけ手を止めてこの記事を読んでほしい。

結論から言おう。
僕たちが本当に使うべきは、Supabaseではなく、あの「WordPress（しかもマルチサイト機能）」だ。

「は？今さらWordPress？正気か？」と思ったモダンフロントエンドエンジニアのあなたにこそ、この泥臭くも圧倒的に合理的で、現代のインフラコストをハックする生存戦略を捧げたい。

聞こう！
動画も用意しました！

1. 結論：僕たちが本当に使うべきは、Supabaseではなく「WordPress（マルチサイト）」だ
2. Supabaseローカル（CLI + Docker）という、現代開発の「甘い罠」
- 裏で蠢く「10個以上のコンテナ」という現実
- 「VPS 4GB」の限界点という壁
3. なぜ「WordPressマルチサイト × Headless」が、現代の最強BaaSになり得るのか（前編）
- 1. VPS（4GB）のリソースを100%アプリに集中できる
- 2. 「マルチサイト機能」によるマルチテナントの神技
3. なぜ「WordPressマルチサイト × Headless」が、現代の最強BaaSになり得るのか（後編）
- 3. 世界最強の「管理画面」と「エディタ」が最初からタダで手に入る
4. 「WP GraphQL」と「JWT認証」を添えて、モダンに飼い慣らせ
5. まとめ：有限なリソースで戦うエンジニアの「生存戦略」

1. 結論：僕たちが本当に使うべきは、Supabaseではなく「WordPress（マルチサイト）」だ

タイトルでこの記事を開いた読者に、最初から最大のカウンターを喰らわせておく。

「Supabaseローカルのオーバーヘッドやマシンスペック、運用コストに悩むくらいなら、今すぐWordPressをHeadless BaaSとして、それも『マルチサイト機能』を使って運用しなさい」

これが、実務とコストの限界を見据えたエンジニアが行き着く、2026年現在の隠れた大正解アプローチの1つである。

今さらWebサイト制作ツールのWordPressをバックエンドに使うなんて、時代逆行も甚だしいと感じるかもしれない。しかし、私たちがBaaSに求めている本質的な機能とは何だろうか。

認証（Auth）の仕組み
データの保存とAPI（REST / GraphQL）による高速な読み書き
画像やファイルを保存する大容量のストレージ
そして、非エンジニアの運用メンバーやクライアントがデータを入力するための「洗練された管理画面」

これらがすべて揃っており、かつ、レンタルサーバーが提供する「数百GB（中には700GB〜無制限）のSSDストレージ」をフル活用でき、さらに1つのシステムで複数の独立したサービスをマルチテナント管理できるチートツール。それが、Headless（バックエンド専用）としてハックされたWordPress、それも「マルチサイト」モードなのだ。

これから、なぜ流行りのSupabaseローカル環境が僕たちを苦しめるのか、そしてなぜWordPressマルチサイトがその救世主になり得るのかを、具体的な数値を交えて丁寧に証明していこう。

2. Supabaseローカル（CLI + Docker）という、現代開発の「甘い罠」

個人開発や、地方自治体のデジタル化（DX）、あるいは中小規模のスタートアップで「とりあえずモダンにSupabaseローカルで環境を作ろう」と意気揚々とスタートする開発者は多い。公式ドキュメントに従い、<code>supabase init</code> を実行し、<code>supabase start</code> を叩く。

一見、ローカルPCの中にクラウドと同等の強力な環境が立ち上がったかのように見えて、テンションが上がる瞬間だ。しかし、ここからが「現代開発の甘い罠」の始まりである。

裏で蠢く「10個以上のコンテナ」という現実

Supabaseローカル環境は、単にPostgreSQLが1つ立ち上がるわけではない。その裏では、以下のような膨大なサービスがそれぞれ個別のDockerコンテナとして同時に起動する。

PostgreSQL: データベース本体
GoTrue: 認証・Auth機能（Go製）
Kong: すべてのAPIリクエストを捌くゲートウェイ
PostgREST: SQLスキーマからREST APIを自動生成する魔術的ツール
Realtime: WebSocketsを用いたリアルタイム同期サーバー
Storage: ファイルアップロードを管理するストレージAPI
Studio: ブラウザからDBを操作できる、あの美しい管理画面
Vector / Logflare: ログ収集やエッジファンクション実行環境、ベクトル検索基盤

お分かりだろうか。これらは通常、開発者が16GBや32GBの潤沢なメモリを積んだMacBook Proなどで動かすことを想定してパッケージングされている。そのため、メモリの最小化（最適化）チューニングがほとんど施されていない。デフォルトのまま起動するだけで、Supabase関連のコンテナだけでメモリを2GB〜3GB以上、容赦なく食いつぶす。

「VPS 4GB」の限界点という壁

もしあなたが、開発したシステムを本番環境、あるいはステージング環境として「月額1,000円前後の軽量なLinux VPS（メモリ4GBクラス）」にDocker Composeでそのままデプロイしようとしたらどうなるか。

結果は目に見えている。Supabaseのシステムだけでメモリの7割以上が埋まり、そこにあなた自身がNext.jsやNode.js、あるいはPythonで構築した「独自のアプリケーション本体（APIサーバーやフロントエンド）」を同居させた瞬間、Linuxの生命維持装置である OOM Killer（Out of Memory Killer） が発動する。

昨日まで動いていたデータベースやAPIサーバーが、ある日突然、何のログも残さず強制終了する。メモリ4GBのVPSにSupabaseを丸ごとセルフホストしてアプリケーションと同居させるのは、運用上の自殺行為に等しいのだ。

さらに、新しいサービスや実験的なアプリを立ち上げるたびに、Supabaseのプロジェクト（またはコンテナ群）をもう1セット増やす？ 4GBのVPS環境では、1つのサービスを維持するだけで文字通り「カツカツ」なのである。この「取り回しの重さ」「リソースのオーバーヘッド」こそが、Supabaseローカル環境が抱える最大の罠だ。

3. なぜ「WordPressマルチサイト × Headless」が、現代の最強BaaSになり得るのか（前編）

では、視点を180度変えてみよう。私たちが昔から知っている、あの「PHP + MariaDB (MySQL)」で動くレガシーなWordPressを、モダンなフロントエンドの「裏方（BaaS）」として使うアプローチだ。

これがなぜ、Supabaseローカルの重厚なオーバーヘッドに対する「完全なアンサー」になるのか。理由は、インフラリソースの物理的な分離と、WordPressに隠された強力なアーキテクチャにある。

1. VPS（4GB）のリソースを100%アプリに集中できる

この構成において、一番のキモとなるのは「物理的な役割分担」だ。

サービス本体・フロントエンド（Next.js / Node.js等）: あなたのVPS（メモリ4GB）で動かす。
データ・管理画面・ファイルストレージ（WordPress）: 格安の「レンタルサーバー」に丸投げする。

レンタルサーバー（ConoHa WING、エックスサーバー、ロリポップなど）は、月額1,000円前後で、信じられないことに 300GB〜700GB（プランによってはそれ以上）の高性SSD容量を提供している。さらに、PHPやMySQLの実行環境、毎日の自動バックアップ体制まで、レンタルサーバー側が完璧に管理・保守してくれている。

WordPressをこのレンタルサーバー側で起動するため、あなたのVPS側のメモリ・ストレージ消費は文字通り「完全なゼロ」になる。4GBのメモリすべてを、あなたのNext.jsアプリケーションのSSR（サーバーサイドレンダリング）や、高負荷なAPI処理に100%集中させることができるのだ。Dockerコンテナの爆音ファンに怯える日々は、ここで終わりを告げる。

2. 「マルチサイト機能」によるマルチテナントの神技

「でも、レンタルサーバーの中にサービスを作るたびに、新しくサブドメインを切って、新しくWordPressをインストールして、プラグインを個別にアップデートしていくなんて、管理のオーバーヘッドが酷すぎる」

そう思うかもしれない。だからこそ、通常モードではなく「マルチサイト機能（Network Mode）」を使うのだ。

WordPressの <code>wp-config.php</code> に設定を1行追加するだけで有効化できるこの機能は、1つのWordPressシステム（1つの管理画面、1つのコアファイル）の中に、完全に独立した「子サイト」をボタン1つで無限に作成できるようになる。

裏側のMariaDB（MySQL）内では、子サイトが作られるたびに <code>wp_2_posts</code>、<code>wp_3_posts</code> のように、プレフィックス（接頭辞）が自動で分離された独立したテーブル群が生成される。データが混ざる心配はシステムレベルで一切ない。

あなたが管理するWordPressの親画面から、1クリックで全サービスのプラグインをインクルード・一括アップデートしつつ、VPS側からは全く異なる独立したBaaSとして複数のサービス（テナント）を同時にコントロールできる。APIのエンドポイントも、

サービスA：<code>
https://api.yourdomain.com/site-a/wp-json/wp/v2/
api.yourdomain.com
(https://api.yourdomain.com/site-a/wp-json/wp/v2/)…</code>
サービスB：<code>
https://api.yourdomain.com/site-b/wp-json/wp/v2/
api.yourdomain.com
(https://api.yourdomain.com/site-b/wp-json/wp/v2/)…</code>
のように自動で美しく分離される。

3. なぜ「WordPressマルチサイト × Headless」が、現代の最強BaaSになり得るのか（後編）

前編では、インフラのコストパフォーマンス、そして物理的なメモリ消費の観点からWordPressマルチサイトの優位性を説いた。しかし、私たちがWordPressをBaaSとしてハックすべき理由は、単なる「サーバー代の節約」だけではない。開発スピードそのものを爆上げする、強力なエコシステムがそこにあるからだ。

3. 世界最強の「管理画面」と「エディタ」が最初からタダで手に入る

システム開発において、エンジニアが最も過小評価しがちで、かつ実際に作ると死ぬほど面倒なのが「非エンジニアの運用メンバーやクライアントがデータを入力するための管理画面（ダッシュボード）」の構築である。

Supabaseの「Studio」は確かに美しい。しかし、それはあくまでエンジニアが生のデータベースを操作するためのツールだ。非エンジニアの一般ユーザーに「ここに直接JSONを入れてね」「このIDをコピーして、あっちのテーブルの外部キーに紐付けてね」と言うわけにはいかない。結局、別途管理画面をスクラッチで実装するか、高価なCMSツールを組み合わせる羽目になる。

対してWordPressはどうだ。世界中のWebサイトの4割以上を支えてきた、あの洗練されたブロックエディタ（Gutenberg）とメディア管理画面が、インストールした瞬間から無料で使える。

さらに、「Advanced Custom Fields (ACF)」や「Custom Post Type UI (CPT UI)」といった、これまた何年も洗練され続けてきた神プラグインを親サイトに1つ入れるだけで、どんな複雑なデータ構造（リレーション、画像ギャラリー、リピーターフィールド）も、GUIのポチポチ操作だけで1分以内に定義できてしまう。

この「管理画面を一瞬で生成できる」というアドバンテージだけで、フロントエンドエンジニアがバックエンドのUI作成に割く時間は完全にゼロになる。これ以上の開発速度の「ショートカット」が他にあるだろうか。

4. 「WP GraphQL」と「JWT認証」を添えて、モダンに飼い慣らせ

「WordPressマルチサイトのポテンシャルは分かった。でも、WordPressのREST APIってデータ構造がグチャグチャで重いし、セキュリティやモダンな認証はどうするんだ？」

当然の疑問だ。普通にWordPressをHeadlessとして使うと、標準のREST API（<code>/wp-json/v2/</code>）のオーバーヘッドにぶち当たる。1つの記事を取得したいだけなのに、不要な著者情報やCSSのメタデータ、大量のリンク配列が返ってきて、レスポンスのJSONが肥大化するのだ。

これを2026年現在のモダン開発に耐えうる「超一級品のBaaS」へと変貌させるために、以下の2つの強力なプラグインをマルチサイトのネットワーク（親）にインストールし、全子サイトに一括適用する。これが、WordPressを完全に飼い慣らすための具体的なアーキテクチャだ。

① 「WPGraphQL」でデータ伝送量を極限まで削ぎ落とす

WordPress標準のREST APIを捨て、「WPGraphQL」プラグインを導入する。これにより、WordPressが瞬時に「GraphQLサーバー」へと進化する。

Next.jsなどのフロントエンド（VPS側）からは、以下のように「本当に欲しいデータだけ」をピンポイントで要求するクエリを投げる。

query GetServiceData {
  posts(where: { categoryName: &quot;news&quot; }) {
    nodes {
      id
      title
      slug
      customFields {
        price
        location
      }
    }
  }
}

必要なデータだけが極小のJSONとして返ってくるため、VPSとレンタルサーバー間の通信量は劇的に削減され、パフォーマンスはSupabaseやハイスペックなNoSQLと遜色ないレベルまで跳ね上がる。また、ACFで定義したカスタムフィールドも自動でスキーマに組み込まれるため、フロントエンド側の型定義（TypeScript）との相性も抜群だ。

② 「JWT Authentication for WP-API」で安全なトークンベース認証を実装する

BaaSとして機能させるためのもう1つの絶対条件が「認証（Auth）」だ。WordPress標準のクッキー（セッション）ベースの認証は、異なるドメイン（VPS側のアプリ）からのクロスドメインリクエストに対応しづらく、セキュリティ的にも脆弱になりやすい。

そこで、「JWT Authentication for WP-API」（または互換性のあるモダンなJWTプラグイン）を導入する。

これにより、アプリのユーザーがログインする際、VPS経由でレンタルサーバーのWordPressへユーザー名とパスワードを送信すると、WordPressが安全に署名されたJWT（JSON Web Token）を発行して返してくれるようになる。

以降、ユーザーが「自分のデータをマイページで更新する」「新しい投稿を作成する」といった認可が必要な操作を行うときは、フロントエンドからリクエストの <code>Authorization: Bearer <TOKEN></code> ヘッダーにこのJWTを添えてWordPressのGraphQLエンドポイントを叩けばいい。WordPress側は自動でトークンを検証し、そのユーザーの権限（ロール）に応じたデータの書き込みを許可・拒否してくれる。

マルチサイト機能と組み合わせれば、「子サイトAのユーザーは、子サイトBのデータには絶対にアクセスできない」というテナント隔離も、WordPressの標準的なユーザー権限グループの仕組みだけで安全に完結する。

③ アーキテクチャの仕上げ：ドメインの「裏方化」

この構成を実戦で投入する際、スマートに見せるための最後のエッセンスがドメイン設計だ。

一般のユーザーがアクセスするメインのWebサービス（例：<code>https://myservice.com</code>）は、アプリが動いているVPSに向ける。そして、裏方であるレンタルサーバーのWordPressマルチサイトには、<code>https://api.myservice.com</code> や <code>https://admin.myservice.com</code> といったサブドメインを割り当てておく。

エンドユーザーからは、裏側でWordPressが動いていることなど1ミリも気づかれない。彼らの目に見えるのは、VPS（メモリ4GB）のパワーをフルに活かして超高速で描画されるモダンなWebアプリケーションと、完全に独立した快適なユーザー体験だけである。

5. まとめ：有限なリソースで戦うエンジニアの「生存戦略」

私たちはいつの間にか、「新しいサービスを作るなら、最新のモダンな技術スタック（BaaS、Docker、サーバーレス）で固めなければならない」という固定観念に囚われてはいないだろうか。

しかし、インフラ費用も、マシンスペックも、開発期間も、すべてが「有限」である現実のプロジェクトにおいて、技術の選定基準は「流行り」ではなく「費用対効果（ROI）」であるべきだ。

Supabaseローカル環境は素晴らしい。しかし、10個以上のコンテナが蠢くその重厚なシステムは、スペックの低いVPS（4GB）や開発環境に牙を剥く。インフラのチューニングやメモリ管理という「本質ではないオーバーヘッド」に時間を奪われるのは本末転倒だ。
WordPressマルチサイトをHeadlessとしてハックする構成は、一見すると泥臭いレガシーの再利用に見える。しかしその実態は、レンタルサーバーの圧倒的な「ギガバイト単価の安さ（大容量ストレージ）」を泥棒しつつ、1つのシステムで複数の独立したBaaS（マルチテナント）を瞬時に生み出す、極めて知的で合理的なハック（裏技）なのだ。

枯れた技術（WordPress）の圧倒的な安定性とエコシステムを、モダンなフロントエンド（VPS）の力で解放する。

もしあなたが、次のプロジェクトのバックエンド構成や、Supabaseローカルの取り回しの重さに悩んでいるなら、悪いことは言わない。今すぐレンタルサーバーを開き、WordPressのマルチサイト機能をONにしてみてほしい。そこには、想像以上に快適で、お財布にもパソコンにも優しい、新時代の開発体験が待っているはずだ。