こんにちは。AI・ノーコード開発を手がける成長支援カンパニーWalkersです。
弊社では多くの企業様からAI開発やWebサイト運営に関するご相談をいただいていますが、その中でも「EmDashのセキュリティは本当に安全なのか」という質問が増えています。
EmDashはCloudflareが公開したオープンソースのCMSで、プラグイン経由の被害を防ぐ設計を最大の特徴に掲げています。一方で、公開から日が浅いこともあり、業務で使うサイトを任せてよいのか慎重に見極めたいというご相談も少なくありません。
実は、EmDashのセキュリティは決して弱くありません。むしろ適切に設定すれば、強固なセキュリティ体制を実現できます。
そこで今回は、EmDashのセキュリティについて以下の内容を解説していきます。
- EmDashのセキュリティが安全な5つの理由
- 代表的なEmDashのセキュリティ設定
- セキュリティが安全でも情報漏洩が起きる理由
- セキュリティを万全にするための解決策
Walkersでは「AIを用いたシステム開発のノウハウがない」「最大限に効率よく開発を進めたい」企業さまに、事業を成功に導くAI開発×補助金支援を行っています。⇒サービス概要はこちら

執筆者:山口 鳳汰
累計100万PV以上のAI・ノーコード開発メディアの編集長。
アプリ開発の電子書籍を3冊出版し、1冊はAmazonベストセラーを獲得。
その他、受託開発や教育など多数のノーコード事業に参画している。

運営会社:株式会社Walkers
AI・ノーコード開発を手がける成長支援カンパニー。
300件以上の開発/制作実績、200件以上の企業様を支援。
マーケティングやUI/UXと掛け合わせたサービス開発を得意としている。

執筆者:山口 鳳汰
累計100万PV以上のAI・ノーコード開発メディアの編集長。
アプリ開発の電子書籍を3冊出版し、1冊はAmazonベストセラーを獲得。

運営会社:株式会社Walkers
AI・ノーコード開発を手がける成長支援カンパニー。
これまでに300件以上の開発/制作実績、200件以上の企業様を支援。
EmDashのセキュリティは安全なのか?

初めにも言いましたが、EmDashのセキュリティは決して弱くありません。
EmDashは、Cloudflareが2026年4月に早期ベータ版として公開し、同年9月28日に安定版の1.0が発表されたCMSです。CMSとは、専門知識がなくてもWebサイトの記事やページを作成・更新できる管理システムのことです。
最大の特徴は、WordPressで被害の多くを占めるとされる「プラグイン経由のリスク」を、仕組みの側で抑え込んでいる点です。セキュリティ企業Patchstackの調査「State of WordPress Security in 2025」では、2024年に新たに見つかったWordPressの脆弱性7,966件のうち、約96%がプラグインに由来していました。Cloudflareもこの調査を引いて、WordPressのセキュリティ問題の96%がプラグインから来ていると説明しています。
※プラグインとは「CMSに機能を後から追加するための拡張部品」を指す。
その対策として、EmDashには次のような仕組みが用意されています。
- プラグインを1つずつ隔離された環境で動かす
- 使える機能を、あらかじめ宣言した権限だけに限る
- 追加や更新で権限が増えるときは、管理者が再承認する
- 管理画面のログインは、パスワードに頼らないパスキーが中心
※パスキーとは「パスワードの代わりに、端末の生体認証などで本人確認を行う仕組み」を指す。
ただし、この隔離の仕組みは、設置先やプランによって使えるかどうかが変わります。「入れただけで自動的に守られる」ものではない点は、後半で詳しく触れます。
»出典:Cloudflare公式ブログ「Introducing EmDash」
EmDashのセキュリティが安全と言える5つの理由とは?

ここからは、EmDashのセキュリティが安全と言える理由を、Cloudflareの公式ブログとEmDashの公式ドキュメントの記載にもとづいて5つ紹介します。
【理由①】プラグインを1つずつ隔離された環境で動かす設計になっている

WordPressでは、プラグインはサイト本体と同じ仕組みの中で動き、データベースやファイルへ広く触れられます。Cloudflareは、1つのプラグインを信頼することが、サイト全体への権限を渡すことになる点を問題視しています。
EmDashでは、プラグインごとに独立した実行環境を用意します。Cloudflare上では、「Dynamic Workers」と呼ばれる隔離環境がその役割を担います。
※Dynamic Workersとは「実行する時点で用意できる、Cloudflareの隔離された小さな実行環境」を指す。
公式ブログによれば、隔離されたプラグインが持つのは自分専用の保存領域だけです。サイトの記事やメディア、ユーザー情報、ネットワークには、管理者が承認した範囲でしか触れられません。環境変数やファイルには、承認しても触れられない仕組みです。
この仕組みにより、あるプラグインに不具合や悪意があっても、被害がそのプラグインに許された範囲を超えて広がりにくくなります。
企業の情報システム部門にとっては、「どのプラグインが何に触れられるのか」を導入前に説明できることが、稟議や監査対応で大きな意味を持ちます。
»出典:Cloudflare公式ブログ「EmDash 1.0: the stable CMS with a secure plugin registry」
【理由②】プラグインが使える権限を、導入前に宣言させて管理者が承認する

EmDashのプラグインは、使いたい機能を「権限」として事前に宣言しなければ、その機能を呼び出すこと自体ができません。たとえば、記事の読み取りだけを宣言したプラグインには、書き換えの機能がそもそも渡されません。
Cloudflareは、この考え方を公式ブログで次のように説明しています。
This security model has a strict guarantee: an EmDash plugin can only perform the actions explicitly declared in its manifest. You can know and trust upfront, before installing a plugin, exactly what you are granting it permission to do, similar to going through an OAuth flow and granting a 3rd party app a specific set of scoped permissions.
(このセキュリティモデルには厳格な保証があります。EmDashのプラグインは、マニフェスト(設定ファイル)に明示的に宣言した操作しか実行できません。インストールの前に、どの権限を与えるのかを正確に把握して判断できます。これは、第三者のアプリに限定された権限を与えるOAuthの流れに似ています。)
※OAuthとは「外部のサービスに、パスワードを渡さずに限られた権限だけを与える仕組み」を指す。
権限は用途ごとに細かく分かれています。公式ドキュメントに載っている主な権限は次のとおりです。
- 記事の読み取り(content:read)
- 記事の作成・更新・削除(content:write)
- メディアの情報の読み取り(media:read)
- 宣言した通信先への接続(network:request)
- メールの送信(email:send)
通信先も、プラグインごとに許可するドメインを指定する仕組みです。宣言していない通信先への接続は、隔離環境の外に出る前に止まると公式は説明しています。
さらに、レジストリ経由の更新で権限が増える場合は、管理者が改めて承認するまで新しい版は有効になりません。導入後に、気づかないうちに権限が広がる事態を防げます。
»出典:EmDash公式ドキュメント「Capabilities and security」
【理由③】通信や環境情報を遮断し、使える資源の上限も固定されている

隔離された環境の中のプラグインは、サイトの環境変数やファイル、プラットフォームの各種接続先を見ることができません。自前で外部へ通信する手段も塞がれていて、外部との通信は、通信先を検査する専用の窓口を通した場合に限られます。
プラグイン同士も分けられています。あるプラグインが、別のプラグインの保存データを読むことはできません。
実行できる量にも上限があります。Cloudflare上では、1回の呼び出しあたりの既定値が次のとおりです。
- CPU時間:50ミリ秒
- 外部へのリクエスト:10回
- 実行の待ち時間:30秒
これらの上限は固定で、設定で緩めるための項目は用意されていません。暴走したプラグインがサイト全体を巻き込みにくい設計であり、Cloudflare上では、運用側が誤って上限を外してしまう余地も小さくなっています。
»出典:EmDash公式ドキュメント「Capabilities and security」
【理由④】公開元の署名と配布物の検証を通ったプラグインだけが読み込まれる

プラグインは、管理画面の「Registry」から探して導入できます。導入の前に、EmDashが公開元の署名つきの記録を確認し、ダウンロードした配布物がその記録と一致するかをチェックします。
確認する項目は、チェックサム、パッケージ名、バージョン、要求している権限です。公開元が求めている場合は、ビルドの来歴証明も検証し、どれか1つでも通らなければインストールは止まります。
※チェックサムとは「ファイルの中身から計算する照合用の値。1文字でも変わると結果が変わるため、改ざんの検知に使う」を指す。
※ビルドの来歴証明とは「そのファイルが、どのソースコードから、どの手順で作られたかを示す証明」を指す。
公開元は「Atmosphereアカウント」という共通の識別の仕組みで管理されます。ハンドル名(handle)が公開元の確認に通らなくなった場合は、新規のインストールが止まる仕様です(導入済みのものはそのまま動きます)。
出所の分からないプラグインを、気づかないまま導入してしまうリスクを下げる仕組みと言えます。
»出典:EmDash公式ドキュメント「The plugin registry」
【理由⑤】管理画面はパスキー中心の認証と、役割ごとの権限で守られている

管理画面のログインは、パスキーが標準です。パスワードを使わず、端末の生体認証などで本人確認を行い、公式はこれをフィッシング(偽サイトでの入力)に強い方式だと説明しています。パスキーは、作成したドメインでしか使えません。
パスキーのほかに、GitHub・Google・Microsoftのアカウントでのログインを追加できます。Cloudflare上では、社内のIDプロバイダと連携する「Cloudflare Access」も選べ、本番ではこちらが唯一のログイン方式になります。
ユーザーの役割は、購読者・寄稿者・投稿者・編集者・管理者の5段階です。上位の役割は下位の権限を引き継ぎ、寄稿者は下書きまでで、公開には承認が必要です。
ログイン試行にも回数制限があります。たとえばメールで送るログインリンクは、5分間に3回までしか送れず、リンク自体も使い切りで、15分で失効します。
»出典:EmDash公式ドキュメント「Authentication」
ここまでを整理すると、EmDashでは
- プラグインごとの隔離
- 宣言した権限だけを使わせる仕組み
- 署名と配布物の検証
- パスキー中心の認証と役割管理
といった形で、複数の観点からセキュリティが設計されています。

\特典:最適な開発方法をご提案/
EmDashで設定できる主なセキュリティ機能とは?

EmDashは、利用者側の設定で安全性の水準が大きく変わります。代表的な設定は次の3つです。
① 隔離の有効化(プラグインを閉じた環境で動かす設定)

プラグインの隔離は、EmDashに最初から入っているわけではなく、設置先ごとに有効化の設定が必要です。
Cloudflareでは、Workersの有料プラン、Worker Loaderの設定、専用の窓口(PluginBridge)の公開が要件です。Node.jsで運用する場合は、オープンソースの実行基盤「workerd」を追加し、実行基盤(runner)を指定します。
設定が欠けていると、隔離を前提にしたプラグインは読み込まれず、管理画面からの新規導入も拒否されます。隔離なしで黙って動き出すのではなく、止まる側に倒れる設計で、サイトの他の部分には影響しないと公式は説明しています。
»出典:EmDash公式ドキュメント「Configure the plugin sandbox」
② ログイン方式とユーザーの役割(本人確認と操作範囲の設定)

ログイン方式は、パスキー、外部アカウント、Cloudflare Accessから選びます。Cloudflare Accessを使うと、社内のIDプロバイダの条件で利用者を管理でき、IDプロバイダのグループをEmDashの役割に対応づけることもできます。
役割は上位ほど強い権限を持ち、最初に登録したユーザーは必ず管理者になります。招待リンクは1回限りで、7日で失効します。
退職者への対応には注意が必要です。公式は、たとえばMicrosoftアカウントでログインしている場合、そのアカウントを無効にしても、EmDash側で開いているセッションや登録済みのパスキーは残るため、EmDash側のユーザーも無効にするよう案内しています。
»出典:EmDash公式ドキュメント「Authentication」
③ AI連携のトークンの範囲(AIに任せる操作を絞る設定)
EmDashは、標準でMCPサーバーを備えています。ClaudeなどのAIから、管理画面に近い操作を任せられる仕組みです。
※MCPとは「AIが外部のツールやサービスを操作するための共通規格」を指す。
接続にはトークンが必要で、ブラウザで承認する方式、長期間使える個人用のトークン、コマンドライン用の方式が用意されています。トークンには「スコープ」という使える操作の範囲があり、ユーザーの役割とは別に確認されます。
スコープで広い範囲を指定しても、そのユーザーが持たない権限は得られません。AIには必要最小限の役割と範囲だけを与えます。公開の判断を人に残すなら、AIを寄稿者の役割で接続します。
»出典:EmDash公式ドキュメント「MCP server」
このように、EmDashは「安全に作られている」だけでなく、利用者自身が安全性の水準を選べる仕組みが用意されている点が特徴です。
セキュリティが強くても情報漏洩が起きるのはなぜか?

ここまでの解説の通り、EmDashは高いセキュリティ水準を目指して設計されています。
しかし、それでも情報漏洩のリスクが完全になくなるわけではありません。
隔離の仕組みが防ぐのは、プラグインが「許された範囲を超えて動くこと」です。許された範囲の中の操作そのものは防げないためです。実際、公式ドキュメントでも以下のように明記されています。
A plugin with content:write can edit any content, not only its own.
(content:writeを持つプラグインは、自分のものだけでなく、あらゆるコンテンツを編集できます。)
同じページでは、権限は大まかな単位であり、承認する前に運用者がプラグインのコードと公開元を評価する必要があると説明されています。つまり、「ツールが安全かどうか」だけでなく、「どの権限を誰に承認するか」が重要ということです。
プロジェクトの若さにも触れておく必要があります。EmDashは2026年4月に公開されたばかりで、安定版の1.0が発表されたのは9月28日です。
公式のREADMEでは、コアのパッケージは本番利用できる安定版とされています。一方、公式プラグインとプラグイン用のツールは、まだ0.x(正式版の前の番号)で、更新のたびに仕様が変わる可能性があると明記されています。
GitHub上で公開されているセキュリティアドバイザリ(脆弱性の公式な通知)は、2026年10月26日の確認時点で0件でした。ただしこれは「問題がない」ことの証明ではなく、公開された報告がまだ少ない段階とも読めます。
なお、EmDash本体は運用者が自ら設置するオープンソースのソフトウェアです。公式ドキュメントには、EmDash本体の第三者認証(SOC 2など)に関する記載を確認できませんでした。認証の有無は、設置先のクラウドの資料で確認する必要があります。
»出典:GitHub「emdash-cms/emdash」README
注意すべきポイントは何か?

EmDashを安全に使うために、特に気をつけたい行動は次の5つです。いずれも、ツールの欠陥ではなく、設定と運用の見落としから生まれます。
① 隔離を有効にしないまま、プラグインを追加してしまう

公式ドキュメントによれば、Cloudflare向けのテンプレートは、新規プロジェクトがWorkersの無料プランでも動くよう、隔離用の設定をコメントアウトした状態で用意されています。隔離を使うには、有料プランへの切り替えと設定の追加が必要です。
隔離が使えない状態で、動かしたいプラグインをネイティブ形式(サイトと同じプロセスで動く形式)に載せ替えると、隔離も資源の上限もなくなります。公式はこの状態を「ネイティブ並みの信頼」と表現しています。プラグインが外部へ直接通信したり、環境変数を読み取ったりできるためです。
- 無料プランのまま、隔離なしでプラグインを増やす
- 隔離できないからと、プラグインをネイティブ形式に移して動かす
- 業務で使うなら、最初から有料プランか、自社運用のNode.jsとworkerdの構成を選ぶ
- ビルド時や起動時のログに、隔離が無効という警告が出ていないかを確認する
隔離を使うために必要な有料プランの費用については、【2026年最新】EmDash(エムダッシュ)の料金プランを完全解説!でまとめておりますので、そちらをご覧ください。

»出典:EmDash公式ドキュメント「Configure the plugin sandbox」
② 権限の同意画面を読まずに承認してしまう

隔離があっても、承認した権限の範囲内の操作は実行されます。公式ドキュメントも、信頼できる公開元のコードだけを導入するよう注意しています。たとえば、転送ルールの書き込み権限(redirects:write)は、訪問者の飛び先を変えられる権限です。
要求されている権限が、そのプラグインの用途に見合うかを、承認の前に確認します。通信先を限定せずに許可する権限は、運用者が通信先を入力する用途に限られるとされており、特に慎重な判断が必要です。
- 内容を読まずに「承認」を押す
- 用途に不要な権限や、通信先が無制限の権限を求めるプラグインを入れる
- 公開元と検証状況を確認し、要求権限が用途と一致するかを見る
- 更新のたびに、増えた権限がないかを確認する
»出典:EmDash公式ドキュメント「Installing plugins」
③ 本番環境でデバッグ用の設定を使い続ける
隔離を切るための設定(sandbox: false)は、プラグインの不具合か隔離の不具合かを切り分けるためのデバッグ用です。公式は、本番に展開してはいけないと明記しています。この設定では、プラグインがサーバーそのものの権限を持ち、許可ドメインや資源の上限にも縛られなくなります。
Cloudflare上では、この設定を指定すると起動が拒否されます。一方、Node.jsで自社運用する場合、workerdの説明書き(README)には、workerdは単体では十分な多層防御を備えていないと記されています。
Node.jsの隔離は、Cloudflare上と同じ強さではありません。CPU時間などの上限は適用されず、待ち時間だけが適用されます。OSやコンテナ、ネットワークの分離と監視を重ねる前提で設計します。
- 本番の設定に、隔離を切る項目が残っていないかをリリース前に確認する
- サーバー側でも、分離と監視を組み合わせる
»出典:EmDash公式ドキュメント「Configure the plugin sandbox」
④ 最新版への更新を止めたまま運用する
EmDashのセキュリティポリシーでは、報告の対象は最新の開発ブランチと、最新の公開パッケージとされています。追加の対象版が文書化されない限り、最新版を使い続けることが前提です。
実際、10月だけでも1.1.0、1.2.0、1.3.0、1.3.1と4回の更新が出ています。GitHubのリリースノート(emdash@1.2.0)には、編集用ツールバーを経由した保存型のクロスサイトスクリプティングを修正したという記載があります。
※クロスサイトスクリプティングとは「Webページに不正なプログラムを紛れ込ませ、閲覧した人の画面で実行させる攻撃」を指す。
更新の確認は、リリースノートの確認とセットで行うのが実践的です。1.0への移行では、廃止された機能もあったため、更新前に変更点を読む手間を運用に組み込んでおきます。
- 更新の担当と頻度を決め、変更履歴を確認してから反映する
- 更新前に、別環境で動作を確かめる
»出典:GitHub「emdash-cms/emdash」セキュリティポリシー
⑤ 暗号鍵とバックアップを別々に管理しない
プラグインの設定のうち、APIキーのような秘密情報は、AES-GCMという方式で暗号化されて保存されます。暗号化の鍵(EMDASH_ENCRYPTION_KEY)は運用者が生成して環境変数などに置き、データベースには保存されません。
※AES-GCMとは「データを暗号化すると同時に、改ざんされていないかも検出できる方式」を指す。
そのため、データベースのバックアップだけでは、鍵は復元できません。鍵がないまま復元すると、暗号化されたプラグインの設定値は読めなくなります。公式は、鍵を秘密情報の管理サービスに置いたうえで、別の復旧用バックアップにも保管するよう案内しています。
Cloudflare D1の復旧点(Time Travel)の保存期間は、無料プランで7日、有料プランで30日です。それより長く戻せる必要があるなら、別途ダンプ(全体の書き出し)を保管します。
- 鍵を、秘密情報の管理サービスとは別の復旧用バックアップにも保管する
- 別環境へ復元して、プラグインの設定値が読めることまで確かめる
»出典:EmDash公式ドキュメント「Manage secrets and keys」
EmDashは、
- プラグインの隔離
- 権限の宣言と承認
- 署名と配布物の検証
といった観点から、安全性の高い設計のCMSです。
しかし、
セキュリティは「ツールだけで完結するものではない」
最終的には「ユーザーの使い方」が重要になる
という点は、必ず押さえておく必要があります。
【解決策】EmDashでの開発を外注する場合は信頼性の高い会社を選ぶ

ここまで見てきた通り、EmDash自体は高いセキュリティを備えたツールです。
しかし実際の開発においては、「誰がどのように設定し、運用するか」によって、安全性や品質は大きく変わります。
特に外注する場合は、開発会社の選び方が、そのままセキュリティや開発品質に直結すると言っても過言ではありません。
- 信頼できる実績があるか
- ブログやSNS、YouTubeで有益な発信がされているか
- 問い合わせた際の対応が丁寧か
- サポート体制は十分か
- 自社の事業・課題を踏まえて提案してくれるか
【ポイント①】信頼できる実績があるか

まず最も重要なのが、実績の有無とその中身です。
EmDashは、プラグインの隔離という強みを得られる一方で、単にツールを使うだけでは安全にはなりません。1.0が発表されたばかりの新しいCMSでもあり、「EmDashを触ったことがある」だけでは判断材料として足りません。
重要なのは、
- CloudflareとNode.jsのどちらで、どの設定で運用した経験があるのか
- 隔離の有効化や、権限の承認基準を、どのように確認しているのか
- WordPressからの移行や、既存システムとの連携を、どのように検証しているのか
といった「設定と運用の設計」です。
そのため開発会社に依頼する際は、「EmDashを使っています」という表面的な説明ではなく、具体的な運用の手順や成果事例まで確認することが重要です。
特に、自社の目的に近い領域(コーポレートサイト、オウンドメディア、社内向け情報サイトなど)での実績がある会社であれば、認識のズレが起きにくく、プロジェクトもスムーズに進めやすくなります。
【ポイント②】ブログやSNS、YouTubeで有益な発信がされているか

EmDashを扱う領域は、変化のスピードが非常に速い分野です。
そのため、開発会社が
- ブログ
- 技術記事
- SNS
- YouTube
などで継続的に情報発信しているかどうかは、最新の版や仕様変更、セキュリティ動向を追えているかの判断材料になります。
【ポイント③】問い合わせた際の対応が丁寧か

問い合わせ段階の対応は、そのままプロジェクト中のコミュニケーション品質に表れます。権限や隔離の設定のような専門的な質問に、分かりやすく答えてくれるかどうかを見ておきます。
【ポイント④】サポート体制は十分か

EmDashのセキュリティ対応は、最新版を使っていることが前提です。リリース後に更新の確認や、セキュリティ上の問題が見つかったときの対応を、どこまで任せられるかを事前に確認しておきます。
【ポイント⑤】自社特有の課題を踏まえて提案してくれるか

EmDashは魅力的なCMSですが、「新しいから使う」という判断に陥ると失敗しやすいのも事実です。
そのため重要なのは、
- どこにEmDashを使うべきか
- あえて使わない方がいい部分はどこか
- 事業として意味があるか
といった視点で提案してくれるかどうかです。
単なる開発ではなく、
- 壁打ち
- 仮説検証
- PoC設計
まで伴走してくれる会社であれば、スピードと事業価値の両立がしやすくなります。
本記事では、EmDashのセキュリティについて、安全と言える理由と、あわせて押さえておきたい注意点を解説しました。
EmDashは、プラグインの隔離、権限の宣言と承認、署名と配布物の検証など、複数の観点から安全性が考慮されたCMSです。
一方で、どれだけセキュリティ機能が整っていても、設定ミスや運用方法によっては情報漏洩などのリスクが発生する可能性があります。
だからこそ、「EmDashは安全か危険か」を二択で考えるのではなく、どのような仕組みで安全性が担保されているのか、そして安全に使うために何を意識すべきかを理解した上で活用することが重要です。
この記事が、EmDashの導入や活用を検討する際の参考になれば幸いです。
Walkersでは成果が実証されたノウハウをもとに、事業を成功に導くためのAI開発×補助金支援を行っています。新規事業・システム開発でお悩みがある方はお気軽にご相談下さい。
無料セルフチェック
費用も、AI活用の効果も。まず無料でチェック
開発の概算費用と、業務のAI効率化診断。条件を選ぶだけで、その場で結果を確認できます。会社への問い合わせは不要です。
無料でチェックを始める →