WordPressからSanityへ|自社コーポレートサイトを移行して見えた本音とリアルな変化

このたび、山陽情報システムのコーポレートサイトをリニューアルしました。CMSには、初めてSanity(ヘッドレスCMS)を採用しています。
本記事では、これまで使い慣れたWordPressと、新たに導入したSanityを比較しながら、実際に使ってみて感じたことを率直にお伝えします。
「次のリニューアルでは、WordPress以外も検討してみたい」——そんなお考えをお持ちのWeb担当者の方にとって、判断材料の一つになれば幸いです。
なぜWordPressからの移行を決めたのか
まず最初に明確にしておきたいのは、当社ではお客様のホームページ制作において、多くの場合WordPressを主軸として採用しているということです。
- 圧倒的なシェア率による、情報・リソースの豊富さ
- 担当者様が更新しやすい簡易な管理画面
- 低いランニングコスト
- カスタマイズ性の高さによる、幅広い要件への対応
これらのメリットは依然として強力で、特に中小規模のコーポレートサイトでは、WordPressが最適解になる場面は数多くあります。
ただ、長年WordPressで制作・運用してきたからこそ、「ここを別のアプローチで解決できないか」と感じる課題も、同時に蓄積されていました。
WordPress運用で感じていた4つの構造的な課題
1. 動的生成による表示スピードの限界
WordPressは、ユーザーがアクセスするたびに、サーバー側のプログラム(PHP)がデータベースから情報を取り出し、その都度ページを組み立てる仕組みです。これを「動的生成」と呼びます。
表示を速くするためのキャッシュ機能や、構成の最適化で改善はできます。しかし、「リクエストが来てから組み立てる」という基本構造である以上、表示速度の限界がどこかで訪れます。
Googleはサイトの表示速度や使い心地を「Core Web Vitals(コア・ウェブ・バイタル)」という指標で評価しており、これが検索順位に直接影響するようになりました。表示が遅いサイトは、検索で見つけてもらいにくくなるだけでなく、訪れたユーザーがページを開いた瞬間に離れてしまう原因にもなります。こうした時代において、WordPressが抱える構造的な遅さは、無視できない課題です。
2. セキュリティ対策の継続的な負担
WordPressは世界で最も使われているCMSであるがゆえに、攻撃の標的にもなりやすい。本体・テーマ・プラグインの脆弱性情報が日々公開され、その都度の対応が必要になります。
不正ログインの試行、コメントスパム、ファイル改ざん、マルウェア感染。これらに対する備えは、運用フェーズで継続的にコストを発生させます。
3. 本体・プラグインのアップデート検証
WordPress本体のメジャーアップデート、プラグインのアップデート、PHPバージョンの更新。それぞれが互いに依存しているため、アップデート前後の動作検証が欠かせません。
プラグイン同士の相性によっては、ある機能を更新したら、別の機能が動かなくなるということも珍しくありません。そのため、公開中のサイトに反映する前に、毎回テスト環境で動作を確認する手間が発生します。
この作業の負担は、サイトを長く運用するほど積み上がっていきます。
4. サーバーのPHPバージョン依存
PHPバージョンの問題は、サーバー会社側の事情でも発生します。実際の現場では、「使っているレンタルサーバーのPHPバージョンが古く、最新のWordPressやプラグインの動作要件に追いつけない」というケースがむしろ多いのです。
山陽情報システムでも「サーバーが古くてサイトの動作が不安定になってきた」「WordPressをアップデートしたいのにサーバー側が対応していない」といったご相談をよくいただきます。
この「PHPバージョン × WordPress本体 × プラグイン」の三つ巴の互換性管理は、保守の難しさそのものでした。
もう一つの理由:AI活用との相性
加えて、当社がAI実装支援を主力サービスの一つとして位置づけている以上、自社サイトにもその思想を反映したいという考えがありました。
WordPressのブロックエディタ(ビジュアルエディタ)は、確かに編集者には直感的で素晴らしいUIです。ただ、コンテンツがHTMLとして書き出される構造上、後からデータとして再利用しにくい側面があります。
AIに記事を要約させたい、社内のナレッジを構造化データとして扱いたい、多言語展開したい——。こうした「コンテンツをデータとして扱う」用途を見据えたとき、ブロックエディタ以外のスタイルも模索したい、というのが移行を決断した最後のひと押しでした。
移行して変わったこと
新サイトは、フロントエンド(表示部分)にNext.js、コンテンツ管理にSanity、公開・配信にVercelという構成で組み直しました。
WordPressのように1つのレンタルサーバーですべてを完結させるのではなく、それぞれの役割を専門のサービスに分担させる作り方です。一つひとつのサービスが自分の領域に特化している分、性能・安定性・将来性で有利に働きます。
この構成変更により、サイト運営はどう変わったのか。具体的に見ていきます。
表示速度:パフォーマンス指標で実感する違い
旧サイト時代は、お恥ずかしながらPageSpeed Insightsの計測を継続的に行っていませんでした。そのため厳密な比較数値はお出しできないのですが、現在の新サイトでは以下のスコアを記録しています。
- モバイル:パフォーマンス 70over / その他カテゴリすべて 100
- PC:パフォーマンス 90over / その他カテゴリすべて 100
アクセシビリティ・ベストプラクティス・SEOの3項目で満点を取れているのは、新しい構成の素直な恩恵です。WordPressで同じスコアを出そうとすると、複数のプラグインの組み合わせと細かなチューニングが必要になります。
モバイルのパフォーマンス値はまだ改善余地があり、画像最適化や追加チューニングで詰めていく予定です。
セキュリティ運用の負担減
これは移行後にじわじわ効いてくる変化です。
- WordPress本体・プラグインのアップデート検証 → 大幅に軽減
- 不正ログイン試行への対策 → 認証基盤がSanity社に委ねられ、総当たり攻撃のリスクがほぼゼロに
- PHPバージョンの心配 → サーバーレス構成のため、そもそも無関係
- ファイル改ざん・マルウェア感染 → 事前生成されたHTMLを配信する仕組み(ISR)のため、感染リスクが極めて低い
これらは一つひとつは地味な変化に見えますが、運用フェーズで積み重なっていたストレスが、まとめて消える感覚があります。
※ Sanity StudioやNext.js本体のアップデート作業自体は残りますが、WordPressと比べて検証コストは大幅に低く済んでいます。
コンテンツが「データ」として扱える
新しい構成では、記事の各要素(タイトル、本文、カテゴリー、公開日、関連リンクなど)が、整理されたデータとして保管されます。
これにより、
- AIによる自動要約との連携がしやすい
- 多言語化(自動翻訳・サイト多言語展開)しやすい
- 社内ナレッジとしてAI検索(RAG)の素材として活用しやすい
といった、「コンテンツの二次活用」の道が開けました。こうした活用例はあくまで一例で、構造化データを基盤に持つことで、今後生まれる新しい活用方法にも柔軟に対応できるのが大きな価値です。WordPressのようにHTMLとして書き出される構造では、後からこうした活用をするのは難しい部分です。
Sanity導入で押さえておきたい3つの注意点
1. 管理画面が「ゼロから」始まる
これは移行プロジェクトでの最大の発見でした。
WordPressの管理画面は、インストールした瞬間から完成された編集環境が用意されています。投稿、固定ページ、メディアライブラリ、ユーザー管理。すべてが「とりあえず動く」状態で揃っています。
一方、Sanityの管理画面(Studio)は、何もない状態からのスタートです。
「記事には何の項目が必要か」「カテゴリーはどう分類するか」「公開前のプレビューはどう見せるか」「編集者の権限はどう分けるか」——これらをすべて、自分たちで定義(スキーマ設計と呼びます)しなければなりません。
これはメリットでもありデメリットでもあります。
- ✅ メリット:自社の運用フローに完全にフィットした管理画面を作れる
- ❌ デメリット:作り上げる工数とノウハウが必要
WordPressは「8割完成された服を着る」、Sanityは「自分の体に合わせて服を仕立てる」。この感覚の違いは、導入を検討する際にぜひ知っておいていただきたいポイントです。
2. 更新が反映されるまでに、少し時間がかかる
WordPressは、ユーザーがアクセスするたびにその場でページを組み立てる仕組みです。組み立てに毎回時間がかかる反面、管理画面で更新した内容は即座にホームページに反映されます。
一方Sanity + Next.jsの構成は、あらかじめ完成したページのデータをサーバー上に用意しておき、訪問者にはそれをそのまま配信する仕組みを採用しています。これが表示速度の速さの正体です。
ただし、編集者が記事を作成・編集すると、「完成したページデータ」を作り直す処理が必要になります。この処理をISR(インクリメンタル静的再生成)と呼びます。そのためホームページに変更が反映されるまで最大で約1分のタイムラグが発生します。
3. レンタルサーバー1つでは完結しない
「サーバー契約1本で全部入り」というWordPressの分かりやすさは、Sanity構成にはありません。
「コンテンツの保管」「ソースコードの保管」「公開・配信」といった機能が、それぞれ専門のサービスに分かれています。具体的には、
- コンテンツの保管:Sanity
- ソースコードの保管:GitHubなどのソースコード管理サービス
- 公開・配信:Vercel、Netlifyなどのホスティングサービス
という組み合わせを用意する必要があります。一つひとつのサービスが自分の領域に特化している分、性能や安定性で有利になりますが、運用上は複数のサービスを管理する手間が出てきます。
レンタルサーバーをひとつ用意したらOKなWordpressと比べるとすこしややこしいです。
WordPressとSanityの比較表
ここまでお読みいただいた内容を、判断材料として一覧できる形にまとめました。自社にとってどちらが合うかを考える際の参考にしていただければと思います。
| WordPress | Sanity | |
|---|---|---|
| 初期構築コスト | 中程度 | 中〜高程度 |
| 月額ランニングコスト | サーバー代 | 規模により無料〜段階課金 |
| 表示速度 | チューニングで改善 | 構造的に高速 |
| セキュリティ運用 | 継続的な対応が必要 | 大幅に軽減 |
| アップデート保守 | 本体・プラグイン・サーバー | 大幅に軽減 |
| 編集画面 | インストール直後から完成 | カスタマイズ前提 |
| デザインの自由度 | フルカスタム可能 | フルカスタム可能 |
| AI連携 | 後付け実装が必要 | 構造的に容易 |
| 向いている規模 | 小〜中規模 | 中〜大規模 |
まとめ:どんな企業に、どちらをお勧めするか
WordPressがベストな選択になるケースは今もたくさんあります。
WordPressをお勧めしたい企業
- 自社のレンタルサーバーで運用したい
- 既存のWordPressエコシステム(テーマ・プラグイン)を活用したい
- 小〜中規模コーポレートサイト
こうした要件であれば、WordPressの完成された使いやすさが最良の選択になります。
Sanityをお勧めしたい企業
- 表示速度・SEO・セキュリティで一段上のレベルを目指したい
- AI活用や多言語展開を見据えている
- コンテンツを「データ」として活用したい
- 5年後・10年後を見据えたサイト基盤を作りたい
こうしたお考えをお持ちの場合、Sanity(ヘッドレスCMS)という選択肢は強力な解になります。
山陽情報システムでは両方の構成をご提案できます
私たちのホームページ制作サービスでは、WordPressによるサイト構築と、Sanity + Next.jsによるヘッドレス構成のサイト構築の双方に対応しています。
お客様の規模・運用体制・将来構想を踏まえ、最適な構成を中立的にご提案します。
「WordPressとSanityの違いをもっと知りたい」「自社にはどちらが合うか相談したい」「サーバー移行を機に構成を見直したい」——などのご相談も歓迎です。お気軽にお問い合わせください。

著者
Shotaro Kawai
営業企画室 室長
客様の課題理解を起点に、ITの総合力で解決策を提案・実装。Web制作20年の経験を軸に、サイト構築から業務改善まで幅広く支援している。