ヘッドレスCMS×AIで「運用しないWebサイト」へ。アンダーワークス自社コーポレートサイトを実質3か月弱でリニューアル

基本情報

事例概要

アンダーワークスは、自社のコーポレートサイトを全面リニューアルし、2026年5月19日に公開しました。テーマは、人間が運用作業をしなくてもコンテンツが生成・更新され続ける「運用しないWebサイト」です。

WordPressからヘッドレスCMS「Sanity」へ移行し、インフラもAWS上の自社サーバーからVercelのサーバーレス環境に切り替えました。既存コンテンツの移行は約9割を自動化し、作業自体はほぼ1日で完了。実働は非エンジニア1名で、AIと対話しながら設計・実装を進め、再始動から公開まで実質3か月弱で仕上げました。

こんな企業の参考に

• コーポレートサイトの更新が、制作会社への依頼や担当者の兼務によって滞りがちになっている
• AI検索（LLM）に自社の情報を正しく引用してもらえるサイト構造にしたい
• ヘッドレスCMSへの移行を検討しているが、製品選定の基準や進め方が分からない

背景と課題

兼務体制では、サイトの情報鮮度を保てなかった

旧サイトは数年前のリニューアルでリード獲得を主目的に設計されたもので、AWS上のWordPressで運用していました。サーバーの保守は外部ベンダーに委託し、更新はコンサルタントがクライアント業務と並行して担う体制です。

この体制では、次の3つの課題が積み重なっていました。

• 運用の手間： 予約投稿の不便さや、デザインパーツの反映に専門知識が必要な場面が多く、更新が滞りがちだった
• インフラの制約： デプロイは手作業で、新しい技術を試すための開発環境もなく、外部ベンダーへの保守委託費もかかっていた
• 企業方針とのずれ： 「AIネイティブカンパニー」への変革と「グローバルマーケティング推進」という重点方針が、サイトの構造や英語コンテンツに反映されていなかった

WordPressの構造では、AIを実用的に使えなかった

もう1つの根本的な課題が、コンテンツの持ち方です。WordPressは本文を「HTMLの文字列」として保存します。そのため、AIから見るとタイトル・リード文・CTAなどの区別がつかず、「このサービスの価格だけ更新して」といった指示を正確に実行できません。

クライアントにAI時代のWeb基盤を提案する立場として、まず自社サイトで実証する必要がありました。

プロジェクトの経緯

一度立ち止まり、方針を切り替えて再始動

プロジェクトは2025年夏にキックオフしました。当初はNotionで作成したコンテンツを、自動化ツールのMakeを介してWebflowに反映する構成を検証していました。

しかし検証を進めると、仕様上の壁が次々に見つかり、想定以上の工数がかかりました。メンバーが通常案件を抱えていたこともあり、2025年秋から冬にかけてプロジェクトの動きを一度緩めることにしました。

転機は2026年初頭です。複数のAIエージェントが分担して作業を進める「Claude Code Agent Teams」が登場し、AIとの対話だけで構造設計からコーディング、CMS連携まで現実的に進められる見通しが立ちました。そこで社内のAI活用研究の一環として「非エンジニアがどこまで実装に踏み込めるか」を検証する題材にリニューアルを据え、Sanityを軸にした構成で2026年2月末に再始動しました。

進め方

再始動後は、次の3フェーズで進めました。

情報設計では、サイト全体を「トピッククラスター構造」で組み直しました。トピッククラスター構造とは、大きなテーマを扱うピラーページと、具体的なテーマを扱うクラスターページを相互にリンクさせ、関連情報を体系化するサイト設計の手法です。

アンダーワークスのサイトでは、顧客の課題を「戦略」「Web基盤」「マーケティング施策」「データ」「ガバナンス」の5つの業務レイヤーに整理してピラーページとし、その下に18のサービスページを配置しました。AIとグローバルは複数の課題にまたがるテーマのため、課題ページではなく横断的な「ソリューションページ」として新設しています。

主要な判断ポイント

なぜヘッドレスCMSの中でもSanityを選んだのか

結論：AIを入稿画面そのものに組み込めるヘッドレスCMSだったからです。

2026年時点では、主要なヘッドレスCMSの多くがMCP（AIから外部ツールを操作するための接続規格）に対応しており、「AIからCMSを操作できる」こと自体は差別化要因ではなくなっています。

そこで重視したのは、AIをどこまで深く組み込めるかです。Sanityは管理画面がReactアプリとして作られているため、Claude APIを入稿画面から直接呼び出せます。また、本文を「CTA」「事例参照」といった意味を持つブロックの配列として保存できるため、「全記事のCTAの文言を差し替えて」といった横断的な編集もAIが正確に実行できます。

ページの項目構造をコードで定義し、Gitで変更履歴を管理できる点も、AIに改修を任せる運用と相性が良いと判断しました。

なぜワイヤーフレームを作らず、実物で議論したのか

結論：AIで実物をすぐに作れるなら、設計意図を文書化して別の人が実装する「翻訳工程」を省けるからです。

再始動後の初回定例では、デザインイメージやワイヤーフレームの代わりに、Sanityで作成したページのプロトタイプを提示しました。動くものを前に「このセクションを上に移動したい」「CTAの文言を変えたい」と議論できたため、合意形成の期間が大幅に短縮されました。

新規ページも、ワイヤーフレームを作らずにAIでHTMLのページ案を作成し、それを調整する方式を採用しています。レビュー担当の3名も、実物を見ながらフィードバックできました。ただし、情報設計やコンテンツモデルといった上流の構造設計は省略せず、入念に検討しました。

なぜ見た目より構造を先に作ったのか

結論：見た目は後からAIで変えられますが、構造は後から整えるのが難しいからです。

AI時代のWebサイトには、人間が見て分かりやすいことに加えて、AIが正しく理解できることが求められます。そこで「人間向けのUI、AI向けの構造」をコンセプトに、同じコンテンツデータから、人間が見る画面とAIが読む構造化データ（JSON-LD、llms.txt、セマンティックHTML）の両方を生成する仕組みにしました。

デザインは外部デザイナーを起用せず、Figma Makeで生成したデザインとコードをもとに内製しています。限られたリソースは構造の正確さに集中させ、見た目は今後Claude Codeで段階的に磨き込む方針です。

成果

コンテンツ制作・移行のスピードが大きく向上

• 開発期間： 再始動から公開まで実質3か月弱（コーポレートサイトのフルリニューアルは一般に半年〜1年かかるとされる）
• コンテンツ移行： 移行専用のAIエージェントを作成し、約9割を自動化。移行作業はほぼ1日で完了し、ロゴや画像などAPIで取得できない約1割のみ手作業で対応した
• 新規ページ制作： 新規の10ページ弱を1〜2営業日で制作。従来は制作会社に依頼して数週間かかっていた
• やり直しのしやすさ： 移行結果を見て構造を変えたい場合も、現実的な時間でやり直せるようになった

運用の仕組みが根本から変わった

一方で、レイアウトの細かな調整やデザイン意図の再現には依然として手作業が必要で、AIの出力を試行錯誤しながら調整する場面も多くありました。それでも全体のスピードは、従来のリニューアルと比べて大幅に速いという実感を得ています。

今後の展開

今回構築したのは、Webサイト単体ではなく、Sanityを中心とした「コンテンツハブ」です。Webサイトはその最初の配信先にすぎず、今後は同じハブからメール配信、SNS投稿、ホワイトペーパー、MA連携、パーソナライズへと展開していきます。

あわせて、公開前にブランドトーンや表記ゆれをAIが自動チェックする仕組みや、アクセスデータをもとにAIが改善案を提案する仕組みも段階的に整えていく予定です。自社サイトで得た知見は、クライアント企業のWebサイト・マーケティング基盤の支援に還元していきます。