Webサイトの安全性を考えるとき、私たちは更新や監視に目を向けます。では、機能を追加する仕組みそのものから、与える権限を小さくできたらどうでしょうか。
Cloudflareが公開したCMS「EmDash(エムダッシュ)」には、プラグインを隔離して動かす仕組みと、AIエージェントからサイトを操作するための機能が用意されています。公式発表
【仮説】この組み合わせを、AIによる開発とセキュリティの変化への備えとして読むと、EmDashが登場した意味が見えてきます。
公開時期と設計、そしてCloudflareの周辺施策をたどり、その戦略を考察します。
※本記事は2026年10月27日時点の公式発表・公式ドキュメントに基づきます。Cloudflareの意図を読み解く箇所には【仮説】を付けています。
画像は生成AIで制作した解説用イメージです。実際のサービス画面ではありません。
この記事の要点
- EmDashは、プラグインの隔離と、申告した権限に基づくアクセス制御を採用しています。
- AIエージェント向けの操作窓口があり、認証と操作範囲も確認する必要があります。
- 【仮説】公開時期と周辺施策から、CloudflareのAI時代への備えを読み解きます。
EmDashの公開時期を時系列で整理する
EmDashは、2026年4月1日に開発者向けベータとして公開され、9月28日に安定版1.0が発表されました。その間、Cloudflareは自社ブログをEmDashへ移行しています。

| 日付 | 確認できる出来事 |
|---|---|
| 2026年4月1日 | EmDash v0.1.0のプレビューを公開 |
| 2026年8月12日 | Cloudflare BlogをEmDashへ移行。移行記事は8月24日に公開 |
| 2026年9月3日 | AIを活用する脆弱性発見・修復支援サービスの早期アクセスを発表 |
| 2026年9月28日 | EmDash 1.0とプラグインレジストリを発表 |
| 2026年9月29日 | AI時代のアプリケーションセキュリティ方針を発表 |
| 2026年10月21日 | PHPの脆弱性「php2shell」に対するWAF保護を説明 |
出典:ベータ公開、自社ブログ移行、脆弱性発見・修復支援、1.0公開、セキュリティ方針、PHP脆弱性への対応
【仮説】この順序から読み取れるのは、CMSの刷新とAI時代の防御を、Cloudflareが並行して進めていたという戦略的なつながりです。個別のPHP脆弱性に対する対応より前に、EmDashの開発と安定版公開は進んでいました。
AIで欠陥を見つける速度が変わるという問題意識
9月3日の公式発表で、Cloudflareは、AIが脆弱性の発見や悪用の一部を加速させ、防御側が判断して対応する時間を短くしていると説明しています。
同日発表した「Vulnerability Discovery and Remediation」は、許可されたコードをAIで調査し、修正案やWAFによる緩和策を顧客の確認に回すサービスです。発表時点では招待制の早期アクセスでした。公式発表
ここには、単に「発見したら更新する」という運用を速めるだけでなく、発見結果を実際の通信や防御と結び付ける姿勢があります。
さらに9月29日の方針では、Cloudflareは、依存ライブラリのリスクや、人間・AIエージェントの権限管理を含めた防御を説明しています。公式解説
【仮説】EmDashを見るうえで、この問題意識は重要です。欠陥が見つかる速度に人の確認が追い付かなくなるなら、確認を速める工夫に加えて、ひとつの拡張機能に与える力を抑える設計にも意味が出てくるからです。
EmDashの注目点はプラグインに与える権限
EmDashのサンドボックス型プラグインは、隔離された実行環境で動きます。コンテンツへのアクセスや外部通信などは、プラグインが申告した権限に基づいて提供されます。

例えば、記事を読んで外部サービスへ送る機能なら、コンテンツの読み取りや通信先の指定を確認できます。公式資料は、インストール時の権限表示と、更新で権限が増える際の再承認も説明しています。権限とセキュリティ
【仮説】この仕組みの価値は、拡張機能を信用するかどうかという判断に加えて、「何を許可するか」を具体的に選べる点にあります。欠陥や不適切な動作への備えを、権限の範囲から考えられます。
ただし、隔離されていても、許可した権限の使い方は確認が必要です。読み取りと外部通信を認めるなら、そのデータをどこへ、何のために送るのかという判断は残ります。公式資料も、権限を許可する前にコードと提供者を評価するよう求めています。公式資料
AIが操作するCMSとしても設計されている
EmDashは、AIエージェントが操作に使うMCPサーバー、CLI、Agent Skillsを用意しています。AIによるサイト管理を、公開当初から設計に取り込んでいる点が特徴です。ベータ公開時の説明

ここで分けたいのは、プラグインの権限制御と、AIエージェントの操作権限です。プラグインが隔離されていることだけで、AIによるすべての操作が適切になるわけではありません。
【仮説】AIへの操作窓口と、拡張機能への権限制御を同じCMSで用意することには、長期的な意味があります。サイトを操作する主体が人間だけではなくなるとき、便利に動かせることと、許す範囲を管理できることの両方が必要になるためです。
EmDashを評価するなら、「AIを使えるか」に加えて、誰の認証で、どの操作を許すのかまで見る必要があります。
この時期に作れた理由にもAIがある
時期を考えるうえでは、防御側の事情とともに、開発側の変化も見逃せません。
Cloudflareは4月の公開記事で、AIコーディングエージェントを使った開発に言及しています。EmDashはTypeScriptで記述され、Astroを基盤とするオープンソースCMSです。公式発表
また9月の1.0発表では、AIサイトビルダー「EmDash Build」のアルファ版も公開しました。AIがサイトを作り、その後は管理画面から人が内容を編集する流れを説明しています。1.0公開時の説明

【仮説】「なぜ今なのか」には、AIによるリスクの変化と、AIによってCMSを作り直しやすくなったことの、両方が関わっていると考えられます。防御の必要性と開発の実現性が重なる時期として、EmDashの登場を捉えることができます。
Cloudflareの事業とのつながりを考える
EmDashはMITライセンスで公開されています。一方、そのプラグイン実行基盤にはCloudflare Workersを利用する構成があり、公式ドキュメントでは、Cloudflare上でサンドボックス型プラグインを動かす場合にWorkers Paidプランが必要とされています。プラグインの導入
【仮説】CMSの利用が広がれば、Cloudflareの開発基盤を選ぶ機会も増えるでしょう。EmDashの登場を考える際は、セキュリティ設計への問題意識と、自社プラットフォームの利用拡大という事業上の狙いを、併せて見るのが自然です。
これは、公開時期を特定の事件と結び付けるよりも、製品の構成から検討しやすい仮説です。どの機能を、どの基盤で提供するかに、利用者への提案と事業の接点が表れています。
安全性を評価するときに確認したい条件
EmDashには、サンドボックス型のほかに、サイト本体と同じプロセスで動くネイティブ型プラグインがあります。ネイティブ型には、サンドボックスによる隔離はありません。
現在の公式資料では、Node.js環境でもworkerdを使うサンドボックス実行方式が説明されていますが、Cloudflare環境とはリソース制限の適用範囲が異なります。実行環境の公式資料
そのため、「EmDashだから安全」と一括りにせず、導入するプラグインの種類と実際の設定を確認する必要があります。

| 確認対象 | 確認する内容 |
|---|---|
| プラグインの実行方式 | サンドボックス型か、ネイティブ型か |
| 許可する権限 | 読み書きするデータと、外部通信の必要性 |
| ホスティング環境 | 隔離機能と制限が実際に有効か |
| AIとの接続 | 認証と操作権限が運用目的に合っているか |
プラグインの隔離はCMS本体や実行基盤に欠陥が生じないという保証ではありません。隔離の対象と範囲を確認することが、安全性を評価する出発点になります。
EmDashの登場をAI時代への布石として読む
【仮説】EmDashは、AIでWebサイトを作り、AIがその運用にも参加する時代を見据え、拡張性と権限の関係を組み直す試みと捉えられます。
その読み解きを支えるのは、公開日だけではありません。プラグインの隔離、申告に基づく権限制御、AIからの操作への対応、そして同時期にCloudflareが示した脆弱性発見と防御の方針です。
CMSを選ぶ際には、使える機能の数とともに、その機能へ何を許可するのかにも目を向けたいところです。
【仮説】Cloudflareがこの時期にEmDashを送り出した意味は、AIを活用するWebの利便性と、その権限を制御する設計を、ひとつの製品で提案したことにあるのではないでしょうか。



