AI時代のサイト運営はなぜVPSが必須なのか

## はじめに

AIGPは「AIプロンプト × ライブコードプレビュー × AIカスタマイズ」を軸にした体験型リファレンスサイトです。公開当初から現在にかけて、運営インフラはひとつの大きな方針で貫かれています。

**「WordPress はレンタルサーバー、Next.js フロントエンドは VPS」というハイブリッド構成です。**

「なぜ全部レンタルサーバーで動かさないのか」「なぜ全部VPSに寄せないのか」— 本記事では、この選択の裏にある技術的理由を、Core Web Vitals・LLMO・運用コストの3つの観点から解説します。

—

## 1. 構成の全体像

[ブラウザ]
↓
[Next.js フロントエンド] ← VPS（Docker, Node.js 20）
↓ REST API
[WordPress CMS] ← レンタルサーバー（エックスサーバー）

– **WordPress**：記事データ・管理設定・生成物DBを保持するヘッドレスCMS
– **Next.js**：SSR/ISRで高速配信、管理ダッシュボード、AI連携、Stripe決済を担当

それぞれ得意分野に特化させ、REST APIで疎結合に繋ぐ設計です。

—

## 2. なぜレンタルサーバーだけでは不可能だったか

### 致命的なブロッカー3点

**① Next.js の常駐プロセスが動かせない**
Server Components / ISR / App Router はすべて Node.js が常時稼働していることを前提にしています。共用サーバーは長時間プロセスの実行権限がなく、Node.js対応プランでもプロセス再起動の保証がありません。

**② LLMの長時間ジョブが PHP の実行時間制限で落ちる**
DeepSeek V3 や Gemini 2.5 Flash への問い合わせは、応答が30〜60秒を超えることがあります。共用サーバーの `max_execution_time`（多くが60秒）ではタイムアウト多発で、AI記事自動生成や画像/コードのAIカスタマイズが実用にならないのです。

**③ Docker が使えない**
自動投稿オーケストレーターは Docker cron で日次実行されます。複数APIの並列制御・リトライ・著作権ブロックリスト処理を安定運用するには、コンテナ前提の設計が不可欠でした。

—

## 3. なぜVPS単体にせず、WordPressはレンタルサーバーに残したか

ここが本記事の核心です。一見「全部VPSに寄せた方がシンプル」に見えますが、実際には以下の理由で役割分担した方が合理的です。

### コンテンツ編集の安定性
WordPress はエックスサーバー上で10年以上の稼働実績を持つ枯れた構成です。記事データという最重要資産を、自前運用のVPSに載せるより、**バックアップ・メール・DB管理が自動化された共用サーバー**に任せた方が事故率が圧倒的に低い。

### REST API を叩くだけならレンタルサーバーで十分
Next.js側が叩くのは `wp/v2/webdev`・`aigp/v1/options/*` などのREST APIです。リクエストに対するPHPレスポンスは数百ms〜1秒以内で完結するため、共用サーバーのリソース制約に抵触しません。

### 運用コスト最適化
VPS上にMySQLやWordPressまで載せると、バックアップ・セキュリティパッチ・DBチューニングがすべて運用者負担に。既存のエックスサーバー契約をそのまま流用することで、**月額コストも作業負荷も半減**させています。

—

## 4. SEO / LLMO 観点でのメリット

この構成は、単なる「動くから採用した」ではなく、検索流入の最大化にも直結しています。

### Core Web Vitals（Googleランキング要因）
– **LCP**：Next.js Server Components が必要な要素だけをサーバーレンダリング → モバイルLCP 1.5秒以下を維持
– **INP**：自動コード分割＋RSCでクライアントJSを最小化 → 応答時間200ms以下
– **画像最適化**：`next/image` によるAVIF/WebP自動出し分け

WordPress単独でも Yoast＋キャッシュプラグインで近い数値は出せますが、**同等パフォーマンスに到達するまでの設定工数が桁違い**に増えます。

### LLMO（AI検索対応）
– **構造化データの一元管理**：Product + Offer（¥100 JPY）、FAQPage、Article、SoftwareApplicationを`generate*JsonLd`関数で統一出力、XSS対策も横断適用
– **4言語 hreflang の完全自動生成**：sitemap.ts で x-default 付き
– **AIクローラ向け最適化**：GPTBot/ClaudeBot/PerplexityBot/Google-Extended など19種を robots.ts で明示許可

AI検索（ChatGPT・Perplexity・SGE）は**構造化データの一貫性**を強く評価するため、この一元管理はそのまま流入の質に跳ね返ります。

—

## 5. 「PaaS（Vercel等）に全部寄せる」選択肢は？

この構成を検討する過程で、Vercel に寄せる案も当然ありました。結論から言うと、**AIGP規模ではVPSの方が経済合理性が高い**という判断です。

### VPS優位のポイント
– 月額固定のため、トラフィック増加でコストが跳ねない
– Docker で他プロジェクトと同じデプロイ手順を使える（運用標準化）
– 長時間LLMジョブ・cron・ファイルシステム永続化に制約がない
– 管理者権限を握れるため、セキュリティヘッダやIP制限を自由に設計できる

### Vercel優位のポイント（今回は不採用）
– 初期構築が早い
– Edge対応で地理分散が自動

「運用が成熟フェーズに入った技術サイト」かつ「AI長時間ジョブが主力」である AIGP のような特性では、VPSの自由度と予測可能なコスト構造が勝ちました。

—

## 6. まとめ：適材適所こそが最適解

| 役割 | 担当 | 理由 |
|——|——|——|
| コンテンツ管理 | エックスサーバー（WordPress） | 枯れた安定運用、自動バックアップ |
| フロント配信 | VPS（Next.js + Docker） | SSR/ISR、Core Web Vitals、長時間ジョブ |
| AI連携 | VPS 側に集約 | LLMタイムアウト耐性、cron自由度 |
| 決済・Webhook | VPS 側 | Stripe署名検証・レート制御 |

「モダンなAI連携サイトをレンタルサーバーで作れるか？」という問いへの答えは、**「機能の7〜8割は作れるが、体験の質と運用の安定性で致命的に落ちる」**というものでした。

AIGPの構成は、この現実的な制約を踏まえて「何をどのレイヤに置くか」を最適化した結果です。同じような「AI × リッチUI × 多言語」サイトを検討している方の参考になれば幸いです。

—

## 参考：関連記事
– サイト診断ツールの実装（/tools/audit/）
– WordPress ヘッドレス化の実装メモ
– Next.js App Router の多言語ルーティング設計