「脱WordPress」と言われた制作会社が、最初に確認すべきこと

エンドクライアントから「WordPress以外で作れませんか」と言われる場面が増えています。理由を聞くと、情報システム部門から脆弱性対応の負荷を指摘された、同業他社の改ざん事故を見て不安になった、といった話が多いようです。

判断の材料は、意外と手元にありません。実装を外部に任せていれば、長く付き合っているWordPress専門の会社からはWordPress前提の回答が返ってきます。社内に実装者がいる場合も、WordPressで積み上げてきた知見がそのまま流用できるわけではありません。

TamaTはWordPressからmicroCMSへの移行や、Next.js／Astroを使ったmicroCMS構成の実装を、制作会社からの実装受託という形で数多く手がけてきました。実際の商談でよく聞かれる論点を、順に整理します。

セキュリティが変わるのは、構造が変わるから

「ヘッドレスCMSはセキュリティが高い」という説明はよく見かけますが、なぜそう言えるのかまで書かれていることは多くありません。

WordPressは、サイトを表示するサーバーと、コンテンツを管理するデータベースが同じ場所に置かれています。訪問者が見ている画面と、管理者が記事を書く画面が、同一のアプリケーションの表と裏の関係にあるということです。

このため、表側から裏側へ到達する経路が構造的に存在します。極端な例で言えば、URLの末尾に /wp-admin を付けるだけでログイン画面まで辿り着けてしまうサイトは、今も珍しくありません。ログイン画面が公開されているということは、そこが攻撃の的になるということでもあります。

ヘッドレスCMSでは、この関係が変わります。

• コンテンツはmicroCMS側のサーバーで管理される
• 公開サイトはVercelやNetlifyなど別のサーバーに置かれる
• 両者はビルド時やAPI経由でしか接続されない

公開サイト側には管理機能そのものが存在しないため、公開サイトを入口とした管理画面への攻撃という経路が成立しません。「守りを固くした」のではなく、「守るべき入口が公開側に無い」という状態です。

念のため補足すると、これはWordPressが危険なCMSだという話ではありません。WordPressは適切に運用すれば十分に安全に使えますし、そのための情報も蓄積されています。ただし「適切に運用する」の中身は、コアとプラグインの継続的な更新、管理画面へのアクセス制限、WAFの設定、定期的なバックアップといった作業の集合です。この運用を誰が責任を持って続けるのか。情報システム部門が懸念しているのは、多くの場合そこです。

パフォーマンスの差は、プラグインの数だけの問題ではない

「記事が増えたので表示が遅くなるのは仕方ない」という説明を受けたことがある方は多いと思います。

WordPressは、ページにアクセスがあるたびにサーバー側でデータベースを参照し、テーマとプラグインの処理を通してHTMLを組み立てます。コンテンツ量やプラグインが増えれば、この組み立て処理が重くなります。閲覧側だけでなく、管理画面の操作が重くなるのも同じ理由です。

microCMS構成では、ページを事前に生成して静的ファイルとして保管しておきます。アクセス時に行われるのは、出来上がったファイルを返すことだけです。コンテンツが増えても、閲覧時の処理量は基本的に変わりません。

更新頻度の高い部分については、ISR（Incremental Static Regeneration）やオンデマンドの再生成を使い、CMSの更新に連動して該当ページだけを作り直す実装が可能です。「静的だからリアルタイム更新ができない」というのは、現在の構成ではあまり当てはまりません。

更新のしやすさは、事前の設計で決まる

導入検討で最も議論になるのがここです。広報担当者が一人で更新しているようなサイトで、「WordPressのほうがよかった」と言われないか。

リッチエディタでの編集

microCMSにもリッチエディタがあり、画像の差し込み、見出し、太字といった操作は問題なく行えます。カスタムフィールドやCSSの組み込みもできるため、表現の自由度が足りないという場面は多くありません。

UIはWordPressと異なるので「同じ感覚」にはなりませんが、これは必ずしもマイナスではありません。長く運用されたWordPressサイトでは、増改築を重ねたカスタムフィールドが管理画面に散らばり、担当者が代わると誰も全体像を把握できない状態になりがちです。microCMSはAPIとスキーマの単位で構造が定義されるため、「どこを触ればどこが変わるか」が対応しやすくなります。

プレビュー

microCMSにはプレビュー機能が標準では備わっていません。ただし、下書き状態のコンテンツを取得して実際のレイアウトで表示する画面は、実装で用意できます。

プレビューは、実務上ほぼすべての案件で必要になります。判断すべきなのは入れるかどうかではなく、どのコンテンツを対象にするかです。お知らせだけでいいのか、CMS管理にしたすべての箇所で確認できる必要があるのか。ここで範囲が変わります。

いずれにしても、見積もりに最初から含めておく項目として扱ってください。「後から付けられる機能」として保留すると、公開直前に問題になります。

記事以外の部分の更新

「トップページのメインビジュアルだけ差し替えたい」といった、記事以外の箇所に関する要望も出てきます。これも、該当箇所をCMS管理対象として設計しておけば更新できます。

WordPressの固定ページのように「ブロックを自由に足したり並べ替えたりする」ほどの自由度はありません。その代わり、どの箇所をどう更新するかを事前に決めておけば、その範囲での作り込みには制約がありません。

ここが、ヘッドレスCMS導入で最も重要な工程です。どこをCMS管理にし、どこを固定するかを、デザイン確定と同じタイミングで決める。この定義が曖昧なまま進むと、運用開始後に「ここも更新したかった」という話になりがちです。

プラグインで賄っていた機能はどうなるか

microCMSが提供するのはコンテンツ管理の部分です。それ以外の機能は自前の実装になります。

プラグインを入れれば済んでいたものが工数に変わるので、その分のコストは発生します。一方で、実装である以上カスタマイズの制約がありません。

たとえばフォームであれば、送信内容をSlackに通知する、Salesforceに商談として起票する、条件によって送信先を振り分ける、といった処理を組み込めます。「WordPressだと難しい」と言われて流れた要望が、この構成なら通ることがあります。フォームまわりの相談が来たときは、単なる置き換えではなく拡張の余地として提案してみる価値があります。

この考え方は、フォーム以外にも当てはまります。会員登録やログイン、予約、決済といった機能は、プラグインではなくSupabaseやStripeなどのサービスと組み合わせて実装します。設計から作ることになるので初期の検討事項は増えますが、権限の設計やデータの持ち方を要件に合わせて決められるため、後から要件が育っていく前提の機能では有利に働きます。TamaTでも、Next.jsとSupabaseを組み合わせた不動産の物件・契約管理システムや、福祉施設の内部管理システムを手がけています。サイトと業務システムが地続きになる案件は、この構成のほうが素直に組めます。

どの機能にどのくらいの工数がかかるかは、要件によって変わります。TamaTでは「この機能はmicroCMS構成で実現できるか」「だいたいいくらくらいか」という段階のご相談も承っていますので、提案内容を固める前でもお気軽にお声がけください。

既存サイトの移行は、記事数が多くても可能

新規案件だけでなく、納品済みのWordPressサイトからの乗り換えを提案したい。しかし記事が数百本あり、移し替えの手間を考えると切り出せない。よくある状況だと思います。

検索すると「WordPressの記事をCSVで書き出してmicroCMSにインポートする」という手順が出てきます。この方法は、記事数が少なく構造が単純な場合には有効です。ただし現実的には次のような壁があります。

• 1回のCSVインポートで登録できる件数に上限がある（プランにより1,000〜10,000件）。分割すれば投入自体は可能だが、その都度の手作業が発生する
• 本文中の画像パスがWordPressのメディアライブラリを指したままになる
• ショートコードがそのままテキストとして残る
• カスタムフィールドやタクソノミーの構造が落ちる
• 記事同士の関連付けや著者情報が引き継がれない

TamaTでは、案件ごとにカスタムの移行スクリプトを組んで対応しています。WordPress側のデータを直接読み取り、microCMSのマネジメントAPI経由で投入する方式です。この方法であれば、画像の再アップロードとパス書き換え、ショートコードの変換、カスタムフィールドのマッピング、カテゴリ・タグの再構築、コンテンツ間のリレーションまで含めて移行できます。

過去には約15,000件の記事移行を実施した実績があります。件数が多いことは、この方式では障害になりません。むしろ件数が多いほど、手作業やCSVとの差が開きます。

移行時に必ず設計が必要になるのは、URL構造とリダイレクトです。既存のパーマリンク構造を維持するのか、変更して301リダイレクトを敷くのか。オウンドメディアの移行では検索流入への影響が直接効いてくるため、ここは初期段階で決めておく項目です。

費用とランニングコスト

初期費用の目安として、10ページ程度＋お知らせ機能のコーポレートサイトで、デザイン支給を前提とした実装のみの受託であれば 80〜90万円程度、デザイン確定から納品までおよそ1ヶ月というのが標準的な線です。

WordPressで作る場合と比べて大幅に高くなるということはありません。TamaTはWordPress制作を行っていないため直接比較はできませんが、初期費用が数倍になるような性質の差ではない、という認識で問題ないと思います。運用の手間が減ること、機能追加がしやすいことを含めれば、長期では下がる可能性もあります。

ランニングコストは、以下の組み合わせになります。

microCMS（2026年9月時点の公開価格・税抜）

• Hobby：0円 / API 5個・メンバー3名・コンテンツ10,000件
• Team：4,900円〜 / API 10個・メンバー3名・コンテンツ20,000件
• Business：75,000円〜 / API 30個・メンバー20名・権限管理・IP制限あり

ホスティング（VercelまたはNetlify）

• 商用利用の有料プランで、1シートあたり月20ドル前後

一般的なコーポレートサイトであればTeamプランで足りるケースがほとんどで、合計すると月1万円前後に収まります。

ただし、Team → Business の価格差は大きく開いています。管理画面のIP制限、閲覧・編集の権限分離、複数環境の切り替えといった機能はBusiness以降です。情報システム部門が関与する規模のエンドクライアントでは、これらが要件に入ってくる可能性があります。API数もスキーマ設計次第で追加費用（1個2,000円）が発生するため、CMS管理範囲を決める段階でプランの当たりを付けておくと、後から見積もりが動きません。

※価格は改定される可能性があります。提案前に各サービスの公式サイトで最新の内容をご確認ください。

移行しないほうがいい場合もあります

すべてのサイトがmicroCMS構成に向いているわけではありません。次のような場合は、WordPressを継続するほうが合理的です。

運用予算が月1,000円程度しかない場合

共用サーバー代だけで運用してきたサイトを、月1万円の構成に載せ替えると、ランニングは確実に上がります。守られる範囲や運用工数の削減と釣り合うかどうかは、サイトの重要度次第です。金額だけを比較して不利になるのであれば、無理に勧める理由はありません。

更新担当者がページ構成そのものを自由に変えたい場合

ブロックを追加してランディングページを都度組み立てるような運用は、WordPressのほうが向いています。microCMS構成は、更新箇所を事前に定義することで安定性を得る仕組みなので、この使い方とは相性が良くありません。

WordPressの運用体制がすでに機能している場合

保守契約があり、コアとプラグインの更新、バックアップ、アクセス制限の責任者がはっきりしているサイトであれば、この記事の冒頭に挙げた懸念はすでに解消されています。運用が回っている状態をわざわざ作り替える理由は、表示速度や機能追加といった別の動機が出てくるまで生まれません。

制作会社との分担について

デザインを制作会社が担当し、実装をTamaTが受け持つ形の進行は、実際に多くの案件で採用している体制です。社内に実装者がいる場合も、microCMSのスキーマ設計と移行部分だけを切り出す、初回案件のみ伴走する、といった分担が可能です。

必要なものはFigmaのデザインデータで十分です。加えて、着手前に一度決めておきたいのが、繰り返しになりますが どの箇所をCMS管理にするか の定義です。ここだけは、デザインと並行して詰めておく必要があります。

この打ち合わせには、エンドクライアントを交えた場にTamaTが同席する形でも構いません。実装の可否や工数の話は、間に立って伝えるより直接やり取りしたほうが早く、認識のずれも起きにくくなります。制作会社の名義で入る形でも問題ありません。

また、実装がGitHubで管理されるため、更新履歴と変更内容がすべて残ります。「担当者しか知らないFTPで直接ファイルを差し替える」という状態から抜けられるので、パートナーが変わった場合の引き継ぎも現実的になります。

ご相談いただく前に

見積もりを固める段階では、CMS管理にする範囲やプレビューの対象、フォームの連携先、移行対象の記事数とURLの扱い、管理画面の権限分離の要否といったあたりが論点になります。

「エンドクライアントからWordPress以外でと言われている」という段階でも、想定される構成と概算はお出しできます。

TamaTでは、WordPressからの移行可否の判断や、既存サイトの構成を踏まえた概算のご相談を承っています。制作会社様からの実装受託、エンドクライアント様との打ち合わせ同席にも対応していますので、案件の入口段階でもお気軽にご相談ください。