2026年、ウェブサイトを何で運用するか

長年、コンテンツ管理システムの選択は人の問題でした。社内の誰がウェブサイトを編集し、どこまで壊してしまう可能性があるのか。2026年、そこに2人目の読み手が加わりました。いまではアシスタントやコーディングエージェントがページを書き、翻訳し、変更しています。そしてあらゆる種類のシステムが、エージェントとどれだけうまく連携できるかを軸に作り直され、あるいは売り込まれています。市場の現状、AIがそれぞれの領域で何を変えたのか、そして私たちならどう選ぶかを見ていきます。

いまも標準のWordPress

W3Techsの2026年10月13日時点のデータによると、WordPressはすべてのウェブサイトの40.1パーセントで使われており、W3Techsがシステムを特定できるサイトに限れば58.6パーセントです。これに続くのがShopifyの5.4パーセント、Wixの4.2パーセント、Squarespaceの2.4パーセントです。全サイトのほぼ3分の1にあたる31.6パーセントでは、W3Techsが検出できるコンテンツ管理システムが見当たりません。

WordPressはAIをコアに取り込みました。5月20日に公開されたバージョン7.0では、サイトが生成モデルとやり取りできるAI Clientが加わり、接続はひとつの画面で管理できます。これと組み合わせるのがAbilities APIで、プラグインはこれを通じて自分に何ができるかを記述します。オプションのAIプラグインは、タイトルや抜粋を書き、画像を生成・編集し、代替テキストを提案します。

昔からの負担は残っています。Patchstackは2025年にWordPressのエコシステムで11'334件の新しい脆弱性を数えました。2024年より42パーセント多い数です。91パーセントはプラグインにあり、コアにあったのはわずか6件で、46パーセントは公表時点で修正が用意されていませんでした。

トップをめぐる争いも決着していません。始まりは2024年9月、プロジェクトと企業Automatticを率いるMatt Mullenweg氏が、ホスティング企業WP Engineの貢献が少なすぎると公に批判し、WordPress.orgへのアクセスを遮断したことでした。WP Engineは10月に提訴し、12月には裁判所がアクセスの回復を命じました。2026年9月28日、Search Engine Journalは、判事がWP Engineの4つの反トラスト法上の請求すべてについて審理の継続を認め、Automatticの反訴も少なくとも一部は維持されたと報じました。2年が経っても結論は出ず、裁判が長引いているだけです。

ヘッドレス、そしてエージェントのために

ヘッドレスCMSは、コンテンツをウェブサイトから切り離して管理します。構造化されたエントリーをひとつのストアに置き、APIを通じてサイト、アプリ、その他求めるあらゆるものに届けます。Sanity、Contentful、Storyblok、Payloadが代表的な名前です。W3Techsの数字では、Sanity、Storyblok、Payloadはいずれもウェブサイトの0.1パーセント未満ですが、こうした集計ではヘッドレスシステムは見えにくいものです。完成したページにほとんど痕跡を残さないからです。

AIは、これらのシステムに新しい論拠を与えました。3月、SanityのCEO、Magnus Hillestad氏はこう書きました。「コンテンツはコンテキストになりました。そしてコンテキストはインフラになりました」。顧客に答えたり価格を提示したりするエージェントに必要なのは、解釈すべきページではなく正確な事実であり、コンテンツはウェブサイトだけでなく、APIやMCPサーバーを通じてもエージェントに届くべきだと彼は主張します。ベンダーのエッセイではありますが、私たちの経験でもこの指摘は当たっています。エージェントは、書式付きのテキストが並ぶページよりも、整ったフィールドを相手にしたほうがはるかにうまく働きます。

この分野では統合も進んでいます。2025年6月、Next.js向けに作られたオープンソースのCMS、PayloadがFigmaに加わりました。Payloadは、今後もオープンソースであり続け、セルフホストもできるとしています。

一文から始まるビルダー

残りの多くを占めるのはサイトビルダーです。小規模な企業向けのWixとSquarespace、デザイン主導のチーム向けの0.8パーセントのWebflowと0.2パーセントのFramer。その多くが、いまではレイアウトやテキストの下書きを作るAIを備えています。テンプレートではなく説明文から始める新しいグループもあり、Wixはそのひとつ、Base44を所有しています。

8月、WixはBase44が売上の伸びを牽引したと報告する一方、Base44は年初の時点で調整後粗利益率がほぼゼロだったことも明らかにしました。自社モデルBase 1はAIの運用コストを下げるためのもので、Wixは下半期には約60パーセントになると見込んでいます。買い手にとって、これは役に立つシグナルです。私たちの見方では、こうしたビルダーは最初のサイトを作る最速の方法であり、その価格は背後にある計算資源のコストに連動していくでしょう。サイトが大きくなる前に、何を持ち出せるかを確認しておいてください。

CMSを使わないという選択

その反対の端には、CMSをやめたチームもあります。2025年12月、Cursorで働くLee Robinson氏は、cursor.comをヘッドレスCMSから素のコードとMarkdownファイルに移しました。1〜2週間かかると見込んでいましたが、エージェントを使ったところ3日で終わり、エージェントへのリクエストは344回、トークン代は260.32ドルでした。

彼の理由はこうです。「AIとコーディングエージェントがある時代に、抽象化のコストはかつてなく高くなっています」。リポジトリの中なら、エージェントはどのファイルでも変更できます。CMSの向こう側では、他人のインターフェースを経由しなければなりません。

彼が離れたシステムであるSanityは、彼が結局CMSをひとつ作り直したのだと応じました。画像やファイルを管理する画面、GitHubの権限によるユーザー管理、gitによるバージョン管理、ローカライズのツール、そしてMarkdownのフロントマターによるコンテンツモデルです。SanityのKnut Melvær氏は「奇妙なことに、私たちはLeeの考えにある程度同意しているのです」と書きました。

どちらも正しいのです。開発者が運用し、編集者が少なく、ページの数も限られるサイトなら、リポジトリとエージェントで足りることが多いでしょう。5つの言語で20人の編集者が働くなら、Sanityが挙げた機能こそが仕事そのものです。

私たちならどう選ぶか

まず3つの問いから始めます。誰がどのくらいの頻度でサイトを編集するのか。変更が人によるものかエージェントによるものかにかかわらず、公開前にどう確認するのか。そして、自社が離れる日に、コンテンツを所有しているのは誰なのか。

編集者がひとりの小さなサイトなら、コンテンツを一緒に持ち出せる限り、ビルダーで十分です。WordPressがうまく機能していて、プラグインが少なく、それを最新に保つ担当者が決まっているなら、急いで移る必要はありません。コンテンツが複数のチャネル、編集者、言語にまたがる場合は、ヘッドレスシステムの構造化されたコンテンツが、人にもエージェントにも役立ちます。そして開発者が運用するサイトは、エージェントが編集し、すべてのリリースを人がレビューするかたちで、コードの中に置いておけます。

私たちがStudioを作ったのは、その中間のケースのためです。毎日編集するマーケティングチームと、それを助けるエージェント。StudioはNext.js、Vite、TanStackで作られたサイトの上に載るCMSで、公開サイトにはプラグインもPHPもありません。編集者は言葉をクリックして変更し、アシスタントが下書きを作り、人が決めます。すべての公開はチェックされ、一度ビルドされ、テストされ、公開され、検証され、何かが失敗すれば自動で元に戻されます。コンテンツは会社自身のリポジトリにコミットされます。Studioは先行アクセスの段階にあります。