Ameba Owndの終了から考える、CMSを持たないWebサイト運用

2026.11.05#Web開発 #生成AI #受託開発 #セキュリティ

2026年11月2日、Ameba Owndが2026年12月24日（木）11:00でサービスを終了すると発表されました。発表と同時にサイトの更新は停止され、現在は閲覧のみが可能な状態です。

運営元の案内によれば、10月22日からの緊急メンテナンスで脆弱性の調査を進めた結果、今後もデータを長期にわたり安全に守り続けることは難しいと判断し、終了を決めたとのことです。

移行の実務については、先日の記事「Ameba Owndが終了する影響をうける人のためにホームページを止めないための移行、お手伝いします」でご案内しました。この記事では一歩引いて、移行先を検討するにあたり、そもそもCMSが必要なのかという前提から整理します。

CMSが担ってきた役割

WordPressやAmeba OwndのようなCMSが広く使われてきたのは、HTMLを書けない人でもWebサイトを更新できるようにするためでした。管理画面でテキストを入力し、画像をアップロードし、公開ボタンを押す。その裏側で、データベースとサーバー上のプログラムがHTMLを組み立てて配信しています。

便利な反面、CMSを使うということは、常に動き続けるプログラムとデータベースを抱えることでもあります。プログラム本体やプラグイン、実行環境の言語（PHPなど）に脆弱性が見つかれば、利用者側にもアップデートや監視が求められます。2026年10月にもPHPの重大な脆弱性が公表され、対応に追われた方も多かったはずです（重大脆弱性への備えから考える、開発と運用の境界をなくすセキュリティ体制）。

Ameba Owndのようなホスティング型のサービスであれば、その負担は運営元が引き受けてくれます。ただし今回のように、運営元が「守り続けられない」と判断すれば、サイトはサービスと一緒に止まります。

更新の担い手がAIに変わりつつある

ここ1〜2年で大きく変わったのが、「HTMLを書けない人がWebサイトを更新する」方法です。

ClaudeやChatGPTに「営業時間を年末年始用に変えて」「このお知らせを追加して」と頼めば、HTMLの該当箇所を書き換えた結果を返してくれます。さらにMCP（Model Context Protocol）などの仕組みを使えば、AIがファイルを直接編集し、変更を反映するところまで任せることもできます。実際にこのブログも、ClaudeからMCP経由で下書きを作成する運用をしています。

更新手段がAIに代替されるのであれば、小規模なWebサイトにおいて従来のCMSは必須ではなくなります。

静的サイトをCloudflareでホスティングするという最小構成

CMSを持たない場合、Webサイトは「HTML・CSS・画像のファイル一式」になります。これをそのまま配信するのが静的サイトです。

静的サイトには次のような利点があります。

サーバー上で動くプログラムやデータベースがないため、攻撃を受ける箇所が少ない
プラグインやCMS本体のアップデート作業が発生しない
リクエストごとにHTMLを動的生成せず、静的ファイルを直接配信するため表示速度が向上する
運営元のサービス終了に左右されにくい（ファイルを別の場所に置けば、そのまま動く）

配信先としては、Cloudflare（Cloudflare Pages / Workers の静的アセット配信）が有力です。小規模なサイトであれば無料の範囲で運用できることが多く、独自ドメインやHTTPSの設定もまとめて扱えます。まずはCloudflareを採用することが、運用負荷を抑えた現実的な構成になります。

もちろん、従来のレンタルサーバーにHTMLを置く運用でも同じ考え方は成り立ちます。既存の契約を活かしたい場合は、そちらを配信先にする選択も合理的です。

AIに更新を任せるときに必要な仕組み

AIに直接ファイルを編集させるだけの運用には、2つのリスクがあります。AIが意図と違う箇所を変えてしまうこともありますし、誰がいつ何を変えたのかが残らなければ、元に戻すこともできません。

そこで私たちは、次のような仕組みを組み合わせることを想定しています。

サイトのファイル一式をGitリポジトリで管理し、変更履歴をすべて残す
AIによる変更は、まずプレビュー用のURLで確認できるようにする
確認して問題がなければ、本番のCloudflareやレンタルサーバーへ自動でデプロイする
問題があれば、ひとつ前の状態にすぐ戻せるようにする

この形にしておけば、サイトの持ち主がやることは「AIに頼む」「プレビューを見て承認する」の2つだけになります。HTMLを読める必要はありません。

CMSがまだ必要なケース

すべてのサイトでCMSが不要になるわけではありません。たとえば次のような場合は、引き続きCMSやヘッドレスCMSを使うほうが向いています。

複数の担当者が毎日のように記事を投稿し、承認フローや権限管理が必要
記事数が非常に多く、検索・絞り込み・予約公開などの機能が欠かせない
会員機能やEC機能など、サイト自体が動的な処理を必要とする

一方で、静的サイトへの移行にあたっては、サーバー側で処理を受け持つプログラムが存在しないため、問い合わせフォームの設置が課題になりやすいという側面があります。これについては、弊社のinqboxを使えば、HTMLにフォームを埋め込むだけで受付から管理まで対応できます（WordPressをやめてサイトを静的化したい——残る「お問い合わせフォーム問題」をinqboxでシンプルに解決する）。

会社概要、サービス紹介、営業時間、たまに更新するお知らせといった情報で構成される規模のサイトであれば、フォームの課題を外部サービスで補うことで、静的HTMLとAIによる更新で十分に運用できます。Ameba Owndで運用されていた多くのサイトは、この構成で代替可能です。