（この記事は、Techブログに掲載したスライド付き記事のQiita版です。完全版はこちら: https://oosawak.github.io/tech/#/post/tech/doko-de-ugokasu ）
AIがWebサイトを運用する時代の話が、現実味を帯びてきました。
2026年9月28日、Cloudflareが新しいCMS「EmDash」の1.0を正式公開し、「WordPressか、EmDashか」という比較が語られ始めています。
けれど、選択肢は2つではありません。
この資料では、3つ目の選択肢として「Muse × GitHub × Markdown CMS」という組み合わせを提示します。
記事をMarkdownで書き、保管はGitHubに任せ、運用はAIエージェントに任せ、公開側ではプログラムを一切動かさない仕組みです。
しかもこれは机上の案ではなく、複数の実サイトがこの仕組みで公開され、日々の運用まで回っています。
WordPressという王道
WordPressは、世界で最も使われてきた王道のCMSです。
Webサイトの約3割がWordPressで作られていると言われています。
使い方は昔ながらの王道で、人が管理画面（ダッシュボード）を開き、記事やページを手で編集します。
テーマとプラグインのエコシステムは膨大で、カスタマイズの自由度は今も圧倒的です。
長年の運用実績と信頼性、大きなコミュニティも、他に代えがたい強みです。
技術の土台はPHPで、従来型のサーバー環境で動き、多くのレンタルサーバーに対応しています。
一方で、構造的な弱点もあります。
WordPressは、訪問者が来るたびにサーバー上でプログラムを動かしてページを生成します。
つまり公開サーバーの中で、実行環境が常時稼働し続けます。
プラグインは広い権限でシステムにアクセスできるため、利便性と引き換えに、セキュリティリスクの入口にもなります。
本体とプラグインの更新を止めれば危なくなり、更新すれば画面が崩れることもあります。
お知らせを1行直すだけの小さなサイトでも、掲示板のために小さな発電所を維持するような、大がかりな手間が付きまといます。
EmDashという挑戦者
EmDashは、Cloudflareが開発した「AI時代のCMS」です。
「WordPressの精神的後継」と位置づけられています。
最大の特徴は、管理画面に加えて、AIエージェントが直接、作成・編集・公開できる設計です。
MCPサーバーを標準搭載し、APIとCLIも備え、AIエージェントとの連携を前提に設計されています。
技術基盤はAstroとTypeScriptで、サーバーレスに対応します。
Cloudflare上だけでなく、一般のNode.js環境でも運用できます。
プラグインの扱いも、根本から見直されました。
プラグインはサンドボックスの中で隔離され、許可した権限だけが付与されます。
これにより、不正アクセスのリスクを構造的に抑えようとしています。
「EmDash Build」（アルファ版）では、文章で指示するだけで、数分でサイトを生成できます。
完全無料のMITライセンスで、オープンソースとして公開されています。
弱みもあります。
新しいプロジェクトのため、プラグインやテーマのエコシステムはまだ小さく、導入実績も限定的です。
そして、表示の裏側でプログラムが実行される構造そのものは、WordPressと同型です。
実行環境を公開側に置く以上、その更新と防御の責任からは自由になれません。
Muse × GitHub × Markdown CMS という選択
構成 ― 動かす場所を、公開側から外す
3つ目の選択肢は、特定の製品名ではありません。
「Muse（AIエージェント）× GitHub（保管と自動化）× Markdown CMS（静的生成）」という組み合わせです。
記事は、Markdownという文章ファイルで書きます。
GitHubがその正本を保管し、ファイルが置かれる（pushされる）と、自動ビルドが走ります。
ビルドでは、MarkdownをJSONに変換し、静的なHTMLとして組み上げます。
公開はGitHub Pagesで行い、公開サーバーではプログラムを一切動かしません。
訪問者が来ても、サーバー側では既製のファイルを渡すだけです。
AIが運用するとは、どういうことか
運用の担い手は、管理画面ではなく、AIエージェント「Muse」です。
人間は、言葉で頼みます。
「この文章で記事を作って」「デザインをこの形にして」「Facebookの投稿を記事にして」といった依頼を、Museが実行します。
記事の作成・編集・公開、デザインの変更、公開への反映までが、言葉の指示で進みます。
EmDashが「AIが操作できる管理の仕組み」を用意したのに対し、こちらは「仕組みの側を極限まで単純にして、操作そのものをAIに委ねる」発想です。
使う人は、GitHubもMarkdownも意識しなくて構いません。
難しい裏側の手順は、AIが引き受けます。
セキュリティの考え方 ― 守るのではなく、置かない
セキュリティの出発点が違います。
公開側でプログラムが動かないため、常時稼働の実行環境を突く攻撃の対象になりにくいのです。
2026年10月に話題になったphp2shellのように、公開サーバーで常時動く実行環境の欠陥を突く攻撃は、そもそも突く相手がいません。
プラグインという概念自体がないため、プラグイン経由の侵入経路も存在しません。
守るべきものは、公開された静的ファイルと、正本を置くGitHubのアカウントに絞られます。
更新してもしなくても、公開側の安全性は変わりません。
入口の考え方 ― 難しい道具を、使う人に見せない
編集の入口では、「使う人に難しい道具を見せない」ことが条件です。
現在の実装済みの入口は、GitHubとVS Codeです。
これはエンジニアには効率的ですが、普通の人にそのまま渡すものではありません。
そこで、Facebookにいつも通り投稿するだけで記事になる形を、実際に動かして実証しました。
さらに、Google Driveに文章ファイルを置くだけで更新できる形と、ブラウザ上の自分の作業場（WorkspaceWeb）から作れる形を、設計中です（構想）。
GitHubは裏側の保管庫として残し、表の入口は身近な道具に置き換えていく設計です。
実際に動いているサイト群
これは構想ではなく、すでに動いている仕組みです。
町のサイト「みどり野町」、パン屋「haru no tane bakery」、フルーツ店「果実日和」、グルメ案内「山形グルメ案内」、小説サイト「よむきく」が公開中です。
それらを束ねる統合ポータル「まちのつながり」も、自動更新で稼働しています。
ポータル本体のサイト「Lyre3 Games」（oosawak.github.io）と、その中のTechブログ・Gameブログも、同じ仕組みです。
日本の丁寧な暮らしのレシピ集「IKIGAI」も、この仕組みの上に乗っています。
仕組み自体はMITライセンスでGitHub（oosawak/markdown-cms）に公開しています。
SNSまで含めた運用実績
運用は、サイトの中だけにとどまりません。
Facebookへの投稿を記事化する連携は、実際に動かして確かめました。
小説作品の紹介動画を作り、InstagramとThreadsへ投稿する運用も行いました。
InstagramとThreadsの「いいね」を入口にして、レシピやグルメ情報を自動で集め、記事の下書きにするところまで、稼働を始めています。
書く、作る、公開する、SNSへ届ける。
その一巡を、AIと人の分担で回すのが、この方式の運用実感です。
3者の比較
| 比較の軸 | WordPress | EmDash | Muse × GitHub × Markdown CMS |
|---|---|---|---|
| 運用の担い手 | 人が管理画面で手動更新 | 人＋AIエージェント（MCP・API・CLIで連携） | AIエージェントに言葉で依頼 |
| 書くもの・正本 | データベース内の記事 | コンテンツ基盤（管理画面／AI経由） | Markdownファイル（正本はGitHub） |
| 公開側の実行環境 | PHPが常時稼働 | Node.js（サーバーレス含む）が実行される | なし（静的ファイルの配信のみ） |
| セキュリティの考え方 | 更新と防御で守り続ける | プラグインを隔離し、権限を絞って守る | 攻撃対象そのものを置かない |
| 拡張の方法 | プラグインを入れる | プラグイン（サンドボックス型）を入れる | 必要な機能だけ外部サービスを借りる（構想含む） |
| サーバー | レンタルサーバー等が必須 | Cloudflare、または Node.js 環境 | 不要（GitHub Pages） |
| コスト | サーバー代＋保守の手間 | ソフトウェアはMITで無料、基盤はCloudflare等 | GitHubの無料枠＋AIの利用料、サーバー代は不要 |
| エコシステム | 巨大（テーマ・プラグイン・制作会社） | 立ち上がり期で小さい | まだ小さい（仕組み自体はMITで公開） |
| 向いている用途 | 何でもできる汎用サイト | AI連携を前提にした新しいサイト | お知らせと読みもの中心のサイト、運用をAIに任せたいサイト |
| 弱み | 維持の重さ、攻撃対象の大きさ | 実績と生態系が未成熟 | 書き込み型の機能が単体ではできない |
できないこと・借りるもの
正直に言うと、この仕組みにはできないことがあります。
「プログラムを動かさない」という前提を守る限り、原理的に残る壁は3つです。
1つ目は、みんなで共有する書き込み状態です。
訪問者が書いたものを他の訪問者にも見せるには、書き込みを受けて保存する場所が、どこかに要ります。
2つ目は、秘密の強制です。
静的ファイルはURLが分かれば誰でも取れるため、会員限定の「中身そのものを守る」ことはできません。
3つ目は、信用の要る裁定です。
支払いが本当に済んだかの確認、在庫の引き当て、二重予約の防止には、信頼できる裁定者が必要です。
そのため、コメント、会員制、本物のEC、予約受付といった機能は、この仕組み単体では担えません。
ただし、だから全部が無理なわけではありません。
拡張の方針は、「必要な分だけ借りる」ことです（方針・構想）。
コメントは、Googleフォームで受け付け、スプレッドシートで運営が承認したものだけを、次のビルドで静かに表示する形が考えられます（構想）。
決済はStripeに任せ、サイト側は商品の表示に徹する形を想定しています（構想）。
問い合わせや申込も、フォームとシートに任せれば、サイト側はリンクを置くだけで済みます（構想）。
全部入りの実行環境を常時動かす代わりに、要る機能の分だけ他人のプログラムを借りる、という足し算です。
他の弱みもあります。
GitHubという保管場所への依存、AIの利用コスト、運用者がAIへの頼み方に慣れる前提、そしてエコシステムの小ささです。
裏方をAIに任せる分、頼む側の「言葉にする力」が問われます。
結論 ― 「どのCMSか」ではなく「どこで動かすか」
AI時代のサイト運用の問いは、「どのCMSを選ぶか」だけではありません。
「プログラムを、どこで動かすか」という問いです。
WordPressは、公開サーバーの中で全部を動かす王道です。
EmDashは、公開側で動かす前提のまま、AIが操作できる形へ作り替えた挑戦者です。
Muse × GitHub × Markdown CMSは、公開側では何も動かさず、作る・直す・運用する力仕事をAIに寄せた、第三の形です。
お知らせと読みものが中心のホームページなら、この身軽さは大きな武器になります。
逆に、書き込みや決済が本業の中心なら、無理に寄せず、外部サービスとの併用か、別の仕組みを選ぶのが正直です。
大切なのは、製品名ではなく、自分のサイトに本当に要るものを知ることです。
仕組みはMITライセンスで公開しています。
まずは触って、確かめてみてください。
参考リンク
この記事で紹介した、実際に動いているサイトです。
- みどり野町 ― 町のサイト
- haru no tane bakery ― パン屋のサイト
- 果実日和 ― フルーツ店のサイト
- 山形グルメ案内 ― グルメ案内サイト
- よむきく ― 小説サイト
- まちのつながり ― 上のサイトを束ねる統合ポータル
- IKIGAI ― 日本の丁寧な暮らしのレシピ集
- Lyre3 Games ― この記事のもとになったブログの本体サイト
- 仕組みの公開先 ― GitHub（oosawak/markdown-cms）