企業サイトを新しい仕組みに移すとき、記事や画像を移せたか、見た目が崩れていないかに目が向きがちです。しかし、公開の翌日に担当者が情報を直せるか、問い合わせが届くか、問題が起きたときに誰へ連絡するかも、移行の成否を左右します。
ギブリーがWordPressからの移行支援を発表
ギブリーは2026年10月30日、企業サイトなどを対象とする「Givery Next for CMS」の提供開始を発表しました。同社によると、Contentful・Next.js・Vercelを使い、WordPressからの移行とAI検索対策、公開後のセキュリティ運用の見直しを一体で支援するサービスです。
ただし、同社はAIサービスでの掲載・引用・推薦を保証していません。また、移行は現在の環境に必要な緊急更新の代わりにはならず、支援範囲や役割分担は調査と契約で決まるとしています。新しい基盤にすれば保守が不要になる、という話ではありません。発表原文
同社の公式案内でも、既存コンテンツを活かした基盤刷新と、公開後の運用設計をテーマに挙げています。ギブリー公式案内
まず「普段の更新」を書き出す
ここからは、発表を踏まえたXEROTTAの実務上の考察です。サービスの効果を検証した結果ではありません。
移行計画を立てる前に、日常の更新作業を具体的に書き出してみます。お知らせの掲載、価格表の差し替え、担当者の変更、古い資料の取り下げなどです。それぞれについて、誰が原稿を作り、誰が確認し、誰が公開するのかを並べます。
新しい管理画面を使えることと、実際の更新業務を回せることは別です。試験公開の段階で、普段更新する人に一連の作業を試してもらうと、権限不足や確認待ち、操作手順の抜けを見つけやすくなります。
ページ数だけで移行完了を判断しない
例えば、資料請求ページが表示されても、入力内容が担当部署へ届かなければ業務は完了しません。主要なページについて、訪問から次の行動までを通して確認する観点が必要です。
- 古い案内メールや印刷物のURLから、目的の情報へたどり着けるか
- スマートフォンでも必要な説明や入力欄を確認できるか
- フォーム送信後に担当者が受け取り、対応を開始できるか
- 下書きや社内向け資料が、意図せず公開対象に入っていないか
- 掲載終了した情報を、検索やリンク経由で案内し続けていないか
表示確認と業務確認の担当者を分ける方法もあります。制作側だけでなく、営業や広報など利用部門が判断する項目を残しておくことが大切です。
AI向けの前に、人が誤解しない説明を
AI検索への対応を考える際も、まず自社の情報に不足や食い違いがないかを確認したいところです。サービス紹介とFAQで利用条件が違う、料金の更新日が分からない、古い導入事例を現在の仕様として読めてしまう、といった状態は人にとっても分かりにくいものです。
「誰向けか」「何が含まれるか」「対象外は何か」を社内で確認し、更新責任者を決めます。引用された回数だけでなく、問い合わせの内容が意図したサービスに合っているかも、改善を考える材料になります。
これは特定のAIへの掲載を約束する方法ではなく、自社の情報を正確に保つための運用です。
公開後の窓口と、旧環境の扱いを決める
移行後に「制作会社の担当か、自社のIT担当か分からない」という状態を残さないよう、契約や引き継ぎ資料には連絡先と責任範囲を明記します。日々の文章修正、基盤の更新、不具合調査、障害時の連絡は、同じ窓口がすべて担うとは限りません。
旧サイトについても、いつまで残すか、誰が管理するか、停止を何で確認するかを決めます。切り替え直後に問題が見つかった場合の判断者と対応手順も、公開前に共有しておくとよいでしょう。
費用は初期の移行作業だけでなく、利用サービス、保守、追加改修を分けて確認します。安さや新しさだけではなく、今の担当者が継続して扱える構成かを比較することが重要です。
まとめ
CMSの移行は、データの引っ越しだけでなく、更新と確認の仕事を引き継ぐ機会です。新しいサイトが開くことに加え、担当者が直せること、問い合わせを受け取れること、問題発生時に動けることまでを完了条件に含めてみてください。
AI検索対策や基盤刷新を検討するときも、現在の保守を止めず、公開後の役割まで決める。その積み重ねが、運用し続けられるWebサイトにつながります。
※公開情報を基にした解説です。XEROTTAによる製品検証、発表企業との提携・取引関係を示すものではありません。
※アイキャッチはAI生成のイメージであり、実在企業の従業員や製品画面ではありません。
