サーバーは、要らないはずだった
ヘッドレス構成の作り方を調べると、だいたい「Next.jsをVercelに置く」と出てきます。無料枠で動きます。
それを読んで、サーバーは借りなくていいのだと思っていました。実際には借りました。何を勘違いしていたのか、そして借りるときに何を見て決めたのかを書いておきます。
WordPressをVercelに置けない理由、無料の選択肢を外した判断、そして「安いほうで足りる」と結論した根拠です。
ヘッドレスは、置き場所が2つ要る
ヘッドレスという言葉は「WordPressの見た目を切り離す」という意味です。切り離すだけで、WordPress自体が消えるわけではありません。
| 部分 | 役割 | 置き場所 |
|---|---|---|
| Next.js | 読者が見る画面を作る | Vercel |
| WordPress | 記事を書いて保管する | レンタルサーバー |
調べていた記事の多くはNext.js側の話をしていて、WordPress側は「すでにある前提」で書かれていました。既存サイトをヘッドレス化する人が多いので、当然といえば当然です。これから作る人だけが、置き場所の話に気づかないまま進みます。
VercelにWordPressは置けない
置けないかどうか、最初に確かめました。結論は置けません。
WordPressはPHPというプログラムで動き、記事はMySQLというデータベースに入ります。Vercelはどちらも常時動かす場所ではありません。仕組みが違うので、無理に寄せる話ではありませんでした。
無料で済ませる道を、ひととおり見た
お金をかけずに済むなら、そのほうがいい。いくつか検討して、どれも外しました。
外した理由は共通していて、止まると記事が書けなくなることでした。
無料の枠には、一定時間アクセスが無いと停止するものがあります。読者が見るのはVercel側なので、CMSに人が来ない時間は長くなります。書こうと思ったときに毎回起動を待つのは、書く回数が減る方向に効きます。
費用を抑えるほど、手間か不便さのどちらかに移ります。移った先が「書くたびに発生する手間」だと、書くこと自体が減ります。
月に数百円で消える手間なら、消したほうが結果的に安いと判断しました。
何が要らなかったか
ここが今回いちばん効いた整理でした。
ふつうWordPressをサーバーに置くときは、表示速度と同時アクセス数を気にします。読者が直接そこへ来るからです。
ヘッドレスだと、読者はCMSに一度も来ません。来るのは自分と、ページを組み立てるときのNext.jsだけです。
そうすると、こうなります。
| ふつうのWordPress | ヘッドレスのCMS側 |
|---|---|
| 表示速度が読者体験に直結 | 自分しか見ないので、多少遅くても困らない |
| アクセス集中に耐える必要がある | 同時に使うのは1人 |
| 止まると全部見えなくなる | 止まっても、公開済みのページは見え続ける |
いちばん下が大きい違いです。ページはあらかじめ組み立てて配っているので、CMSが止まっている間も、読む側には何も起きません。影響が出るのは新しい記事を出すときだけです。
つまり、上位プランを選ぶ理由がほとんどありません。いちばん安い共用プランで足ります。
逆に、確認したこと
安ければ何でもいいわけではなく、これだけは満たしていないと動きません。
ひとつめはPHPのバージョンを自分で選べること。古いまま固定されていると、必要な機能が動かないことがあります。
ふたつめはサブドメインを独自ドメインで作れて、SSLが付くこと。表側とCMSを分けるので、cms. のようなサブドメインを1つ切ります。ここに鍵マークが付かないと、ブラウザ側で通信が弾かれます。
みっつめはデータベースが使えること。記事の本体はここに入ります。個数が1つでも足ります。
この3つはどれも、契約後に「入っていなかった」と分かるものです。仕様のページに必ず書いてあるので、申し込み画面に進む前に見ておくと、あとで移す手間がなくなります。
上の3点(PHPのバージョンを選べる・サブドメインにSSLが付く・データベースが使える)を満たしていて、いちばん安い共用プランで足りました。上位プランを検討する理由が、ヘッドレスだと出てきません。
ドメインと同じ会社にまとめたのは、請求と管理画面を1つに収めたかったからです。ただしこれには落とし穴があって、DNSの設定画面が2か所に増えます。片方は参照されないのにエラーも出ません。ここで丸一日使いました。
実際に困ったこと
安いプランで足りる、とは書きましたが、共用サーバー特有の引っかかりはありました。
ひとつはセキュリティの仕組みによる誤検知です。記事の本文にHTMLのタグが多く含まれていると、攻撃だと判定されて保存が弾かれることがありました。これは別記事に書いています。
もうひとつは予約投稿の時刻がずれることです。WordPressの予約投稿は、時計ではなくアクセスをきっかけに動きます。誰も来ないCMSでは、指定した時刻をしばらく過ぎてから公開されます。
どちらも、ヘッドレスにしたから起きたというより、「人が来ないサーバー」であることの副作用でした。安さの問題ではありません。
今回の学び
まず、解説記事は前提を書かないこと。「Vercelに置く」という説明は正しいのですが、それはNext.js側の話でした。書いた人にとって当たり前すぎる前提ほど、文章から抜け落ちます。
次に、要件は「誰が使うか」から決まること。同じWordPressでも、読者が来るのと自分しか来ないのとでは、必要なものがまったく違いました。製品の比較表を見る前に、自分の使い方を書き出すほうが早いです。
そして、費用を削った先がどこに移るかを見ること。無料にすると、たいてい手間か待ち時間に移ります。それが「書くたびに発生する手間」なら、削らないほうが続きます。
関連記事

上げる先が、ひとつしかなかった
脆弱性28件のうち23件がNext.jsに集約されていた。あとは上げるだけ、のはずが「どこまで上げるか」で手が止まった。サポート期限を調べたら選択肢は実質1つだけ。コードモッドが入れた不要な設定を消し、プレビューで確認してから本番へ入れた記録。

依存の中の依存
脆弱性の警告が29件。数字だけ見ると手のつけようがないが、分類すると実質3つの問題だった。自動で出てくる更新PRの危険度の見分け方と、直接の依存を上げたのに警告が消えなかった理由。
追従する目次と、画面の取り合い
PCで右側に追従させていた目次を、スマホでは上部に貼り付けた。ところが貼り付くものは画面を占め続けるため、本文を読む場所が足りなくなる。情報を消さずに縦を横へ並べ替えた話と、「飛んだ先がバーの裏に隠れる」という副作用への対処。