# EmDashのセキュリティはやばい？プラグインの隔離で守れる所と自分で守る所

- URL: https://www.waltsu.co.jp/magazine/security/emdash-security/
- カテゴリ: セキュリティ > 脆弱性対策
- 執筆: 藤井 俊輔（代表取締役）
- 公開日: 2026-10-05 / 最終更新日: 2026-10-29
- 発行: waltsu株式会社（waltsu MAGAZINE）

## こんな人におすすめ

- EmDashを試したいが、セキュリティが不安
- プラグインの隔離で何が守られるのかを正確に知りたい
- AIにコードや管理を任せて開発する予定がある

2026年4月にCloudflareが公開したCMS「EmDash」は、プラグインを隔離して動かす点を売りにしています。一方で「新しいCMSはやばいのでは」「隔離されているなら安全なのでは」と、評価は両極端に分かれがちです。 EmDashのセキュリティは、プラグインの隔離という強い仕組みと、隔離の外で自分が守る範囲の組み合わせで決まります。EmDashは安全でも危険でもなく、守る範囲の線がはっきりしたCMSです。本記事では、隔離が防ぐこと、隔離の外で動くもの、AIに開発や管理を任せるときの注意を、2026年10月時点の公式文書で整理します。

**この記事のゴール（読了目安 約8分）**：隔離で守られる範囲と自分で守る範囲を区別し、自社の開発とAIに渡す権限を絞れるようになる。

## この記事の結論

- 隔離は強いが、対象は隔離形式のプラグインだけ
- ネイティブ形式・自社のコード・差し込むスクリプトは隔離の外で、守るのは自分
- 隔離は設定しないと動かず、Node.jsでは強制される制限が少ない
- AIには要る権限だけを渡し、変更は小さく、差分を読んで確かめる

## EmDashのセキュリティはやばいのか

プラグインの隔離は強い一方、隔離されるのは決められた形式のプラグインだけです。書き足したコードの安全は、作った側が守ります。

### プラグインの隔離は強い

EmDashは、プラグインを1つずつ隔離された環境で動かし、宣言した権限の範囲でしか動けないようにしています。WordPressでは新しく見つかる脆弱性の[9割超がプラグイン由来](https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/)とされ、その弱点に設計で対処する仕組みです。EmDashの全体像と[WordPressの脆弱性の内訳](https://www.waltsu.co.jp/magazine/security/wordpress-security/)は、それぞれ別記事で解説しています。

### 隔離の外は自分で守る

ただし隔離の対象は、決められた形式で作られたプラグインだけです。EmDashはAstroで作るWebアプリそのもので、ページや部品、独自の処理を自由に書き足せます。**書き足したコードは隔離されず、その安全は作った側の責任**です。

![左に隔離された囲いの中で動くプラグイン、右に囲いの外で動くネイティブ形式のプラグイン・自社のコード・AIが書いた変更を並べ、右側は自分で守る範囲だと示した左右比較の図](https://www.waltsu.co.jp/wp-content/uploads/2026/10/emdash-security01.png)

## 隔離が防いでくれること

[公式文書によると](https://docs.emdashcms.com/plugins/creating-plugins/capabilities/)、隔離の仕組み（サンドボックス）が動いている間は、次の4つが実行環境によって強制されます。

- **宣言した権限だけ**: 記事の読み取りやメール送信など、宣言していない機能はプラグインから呼び出せない
- **サーバーの中身が見えない**: 環境変数・ファイル・サーバー側の接続設定に触れられない
- **通信先の限定**: 外部への通信は、宣言した宛先にだけ届く
- **権限の追加は再承認**: 更新で権限が増えると、差分を示して改めて承認を求める

プラグインに不具合や悪意があっても、**パスワードなどの秘密情報や他のデータにアクセスできない**のが、この仕組みの強みです。

## 隔離が働く条件

隔離は設定しないと動きません。動かす場所によって、必要なものと強制される制限が違います（2026年10月時点）。

| 項目 | Cloudflare Workers | Node.jsのサーバー |
|---|---|---|
| 必要なもの | 有料プラン（ 月5ドルから ） | Workersの実行環境を追加で入れる |
| 処理時間の上限 | 強制される | 強制される |
| CPU時間・外部通信の回数 | 強制される | 強制されない |
| メモリ | 基盤全体の上限のみ | 強制されない |

仕組みが用意されていないと、[隔離形式のプラグインは読み込まれず](https://docs.emdashcms.com/deployment/plugin-sandbox/)、管理画面からの追加も失敗します。Cloudflare向けの雛形は、作成時に有効にしない限り隔離なしの設定で始まります。**「EmDashだから隔離されている」ではなく、隔離を有効にしたかを確かめる**のが最初の確認です。

## 隔離の外で動くもの

EmDashのプラグインには、隔離して動かす形式と、[サイトと同じ処理の中で動く](https://docs.emdashcms.com/plugins/overview/)「ネイティブ形式」の2つがあります。公式文書は、[ネイティブ形式の権限の宣言は安全の境界ではない](https://docs.emdashcms.com/plugins/creating-plugins/choosing-a-format/)と明記しています。

| コード | どこで動くか | 誰が守るか |
|---|---|---|
| 隔離形式のプラグイン | 隔離された環境 | 実行環境が強制する |
| ネイティブ形式のプラグイン | サイトと同じ処理 | 作った人と入れる人 |
| 自社で書くページ・部品・処理 | サイトと同じ処理 | 自社 |
| 公開ページに差し込むスクリプト | 訪問者のブラウザ | 作った人（ネイティブ形式だけが使える） |
| 隔離の仕組みが無く、同じ処理に移したプラグイン | サイトと同じ処理 | ネイティブ形式と同じ扱い |

公開ページに差し込むスクリプトは訪問者のブラウザで実行され、公式文書も隔離の境界の外だと書いています。動作確認のために隔離を切る設定もありますが、公式文書は本番に使わないよう警告しています。**表の下の4行は、WordPressのプラグインと同じく中身を信頼できるかで決まる**領域です。

## 許可した権限の中は防げない

隔離が防ぐのは「宣言していない操作」です。宣言して許可した操作の中身までは制限しません。公式文書は例として次を挙げています。

- **記事の書き込み**（content:write）: プラグイン自身が作った記事に限らず、どの記事でも編集・削除できる
- **転送の書き込み**（redirects:write）: 訪問者をどこへ転送するかを書き換えられる

そのうえで、[信頼できる発行元のものだけを入れる](https://docs.emdashcms.com/plugins/installing/)よう注意しています。更新で権限が増えたときの再承認も、中身を読まずに押せば意味がありません。**権限の一覧を見て、その機能に本当に要るかを1つずつ確かめる**のが入れる側の仕事です。

## 自由に作れるぶんの責任

EmDashは、管理画面と公開ページが[1つのAstroアプリ](https://docs.emdashcms.com/concepts/architecture/)として動きます。デザインも機能も自社のコードで自由に作れ、テーマやプラグインの作りに縛られません。たとえば自社で書いた問い合わせの受け付けや外部サービスとの連携では、入力の確かめ方も、鍵やパスワードの置き場所も、すべて自社のコードが決めます。

その代わり公式文書は、データベース・画像の保存先・バックアップ・更新・管理画面を配る仕組みを、[運用するチームの責任](https://docs.emdashcms.com/why-emdash/)に挙げています。**自由度が高いぶん、守る対象も自社のコードの量だけ増えます**。

## AIに管理を任せるときの権限

EmDashは、AIから記事や画像を操作できるMCPサーバーを備え、[初期設定で有効](https://docs.emdashcms.com/guides/ai-tools/)です。つなぐときは次の3点を確かめます。

- **同意画面**: AIが求めた権限は、初めから全部チェックされた状態で開く。要らないものを外してから承認する
- **ロール**: 権限の範囲と、つないだ人のロールの両方で判定される。下書きを作るだけなら、公開できないロールでつなぐ
- **使わないなら止める**: 設定（mcp: false）で無効にできる

項目の定義を変える操作は管理者だけに許され、保存済みのデータを消すことがあります。**AIには、その作業に要る最小の権限だけを渡す**のが基本です。[AIエージェントに渡す権限の段階の考え方](https://www.waltsu.co.jp/magazine/security/ai-agent-security/)は、別記事で解説しています。

## AIにコードを書かせるときの注意

EmDashの新しいプロジェクトには、AIのコーディング支援にEmDashの作法を教える[手引き（Agent Skills）](https://docs.emdashcms.com/agent-skills/)が最初から入っています。AIに頼めば、ページもプラグインも短時間で書けます。だからこそ守るのは次の4つです。

- **依頼を小さく**: 1回の依頼で変える範囲を1つの機能に絞る
- **差分を読む**: 頼んでいない処理や設定の変更が混ざっていないかを確かめる
- **依存の追加を疑う**: 新しく入るパッケージが実在し、意図したものかを確かめる
- **まず隔離形式**: 公式文書も、ネイティブ形式でしかできない機能以外は隔離形式を勧めている

3つ目には根拠があります。[2024年に公開された研究](https://arxiv.org/abs/2406.10279)では、コード生成AIが提案したパッケージのうち実在しないものの割合が、平均で商用モデル5.2%以上、オープンソースのモデル21.7%でした。**実在しない名前を第三者が先に登録すれば、そのまま攻撃の入口**になります。

![コード生成AIが提案したパッケージのうち実在しないものの割合を、商用モデル平均5.2%以上、オープンソースのモデル平均21.7%の横棒で比べたグラフ](https://www.waltsu.co.jp/wp-content/uploads/2026/10/emdash-security02.png)

## 【プロの視点】隔離の有無より境界の位置

EmDashの評価は「隔離があるから安全」か「新しいから危険」かで語られがちです。ただ、見るべきは隔離の有無ではなく、**隔離の外に何がどれだけ置かれているか**です。隔離は設計どおりに働きますが、境界の外はWordPressと同じく、書いたコードの質で決まります。

AIで開発すると、この外側が速く広がります。OWASPは、[生成AIを組み込んだシステムのリスク](https://www.waltsu.co.jp/magazine/security/generative-ai-security/)の1つに「[過剰な権限委譲](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)」を挙げ、原因を機能・権限・自律の3つの過剰に分けています。対策の最初は、要らない拡張を持たせないことです。サイトのコードも同じで、**AIが気を利かせて足した「頼んでいない機能」は、そのまま隔離の外に残ります**。

明日やる最初の一歩は、プロジェクトの設定ファイルを開き、ネイティブ形式で入っているプラグインと自作の処理を書き出すことです。

![AIに持たせすぎると事故につながる「機能」「権限」「自律」の3つを横並びのカードで示し、頼んだことだけに絞るべきだと示した図](https://www.waltsu.co.jp/wp-content/uploads/2026/10/emdash-security03.png)

## 【waltsu視点】変更は本番と同じ環境で見る

このブログもWordPressで運用しています。制作では、デザインの確認もデザインツールの画面ではなく、本番とまったく同じ仕様の確認用環境で行うようにしています。検索エンジンに載らず、パスワードで守った環境です。静止画では、スマートフォンでの見え方や動きまでは確かめられないからです。

AIが書いた変更も同じ考え方で扱えます。差分を読んだうえで本番と同じ環境で動かせば、頼んでいない動きに気づけます。waltsuが軸にしているのは試行回数です。**確かめる場があれば、AIに小さな変更を何度も任せられます**。

明日やる最初の一歩は、本番と同じ設定で動く確認用の環境が1つあるかを確かめることです。

![AIが書いた変更を、差分を読み、本番と同じ確認用環境で動かして確かめてから公開する4段階を、左から右への流れで示した図](https://www.waltsu.co.jp/wp-content/uploads/2026/10/emdash-security04.png)

## まとめ

EmDashのセキュリティは、やばくも万全でもありません。プラグインの隔離は設計どおりに強く働きますが、自由に書き足せるコードは隔離の外で動き、その安全は作る側と運用する側が持ちます。

AIに開発や管理を任せるほど、隔離の外は速く広がります。依頼を小さくし、差分を読み、権限を絞ることが、EmDashを安心して使い続ける条件です。隔離の外のコードやAIに渡す権限の線引きに迷う場面が出てきたら、運用に長けたメンバーがいるwaltsuが、試す環境づくりから公開後の運用までご支援します。

## よくある質問

**Q. EmDashはWordPressより安全？**  
A. プラグインが原因の被害を構造で抑えられる点では有利です。ただしネイティブ形式のプラグインや自社のコードは隔離されないため、作り方と運用しだいで差は縮まります。WordPressとどちらを選ぶかは、運用する人で決める考え方を別記事で解説しています。

**Q. 無料プランでも隔離は使える？**  
A. Cloudflare Workersで隔離を使うには有料プランが必要です。無料プランでもEmDash自体は動きますが、隔離形式のプラグインは読み込まれません。

**Q. Node.jsでも同じように守られる？**  
A. Workersの実行環境を入れれば、権限の制限と通信先の限定は同じように働きます。ただし強制される資源の制限は処理時間だけで、CPUやメモリの上限はかかりません。

**Q. AIをMCPでつないで大丈夫？**  
A. 同意画面で要らない権限を外し、ロールを絞ればリスクは下げられます。公開や削除の前には、下書きと公開中の差分をAIに出させて人が確かめます。

**Q. 自作プラグインはどちらの形式？**  
A. 公開ページにスクリプトを差し込むなど、ネイティブ形式でしかできない機能が無ければ隔離形式です。公式文書も同じ順で勧めています。

## 執筆者

**藤井 俊輔**（代表取締役）ベンチャー企業の外部CMOや水族館のマーケティング担当などに従事。オンライン/オフライン問わず集客を中心としたマーケティング施策に強み。

プロフィール: https://www.waltsu.co.jp/magazine/supervisor/shunsuke-fujii/

この記事は waltsu 公式ブログの記事（https://www.waltsu.co.jp/blog/emdash-security/）をもとに再編集したものです。