EmDashのセキュリティリスクを解説。導入前に確認したい5つのこと
EmDashには、パスキー認証や、対応するプラグインを専用の環境で動かす仕組みがあります。ただし、サイトをEmDashへ変えるだけで、不正アクセスや誤公開のリスクがなくなるわけではありません。
確認したいのは、プラグインの動かし方、AIに渡す権限、端末の管理、更新とバックアップです。これらが何を守り、どの部分を担当者が確認する必要があるのか、実際の運用に沿って説明します。
1. プラグインは、すべて同じ方法で隔離されるわけではない
プラグインは、CMSに機能を追加する部品です。EmDashには「サンドボックス型」と「ネイティブ型」の2種類があります。
サンドボックス型は、専用の実行環境でプラグインを動かし、サイト本体とのやり取りを制限します。記事を読む、外部に通信するといった操作には、あらかじめ申告した権限が必要です。通信先を限定する仕組みもあります。権限とセキュリティの公式説明
一方、ネイティブ型はサイト本体と同じ環境で動きます。管理画面を大きくカスタマイズするなど、深い連携ができる反面、サンドボックスと同じ隔離はありません。また、サンドボックス型として配布されたものでも、隔離用の実行環境を使わずに組み込めば、同じ保護は受けられません。プラグイン形式の違い
制作会社には「どのプラグインを、どの方式で動かしていますか」と確認してください。製品名だけを見て安全性を判断せず、権限・配布元・更新方法まで把握しておくと、公開後の点検もしやすくなります。
2. パスキーは入口を守る。端末と復旧手段も確認する
EmDashの標準的なログイン方法はパスキーです。指紋・顔認証・端末のPINなどを使い、パスワードを入力せずに本人確認できます。パスキーはサイトのドメインと結びつくため、偽のログイン画面に認証情報を入力させる攻撃への耐性があります。認証の公式ガイド
画面はRealAIzeのコーポレートサイトで使っているログイン画面です。ログイン方法は、サイトごとの設定によって異なります。
運用では、担当者ごとにアカウントを分け、端末を失った場合の連絡先と復旧手順を残しておきます。担当者の異動時にはアクセス権を見直すこと。パスキーを使っていても、端末やブラウザに残ったログイン状態まで無条件に安全になるわけではありません。
3. AIの接続トークンは、管理画面のログインとは別に守る
EmDashとAIをMCPで接続すると、AIが記事や画像を操作できます。MCPはModel Context Protocolの略で、AIと外部ツールをつなぐ仕組みです。この接続には「認証トークン」が使われます。AIから接続するための鍵に当たる情報です。管理画面のログイン状態だけではMCPを操作できません。
トークンには操作範囲が設定され、ユーザー自身の権限も別に確認されます。下書き担当として使うなら、公開できないユーザー権限と必要な操作範囲を組み合わせる設計が考えられます。広い管理者権限を配り、指示文だけで「公開しないで」と抑える運用は避けたいところです。MCPの認証・権限仕様
接続情報を記事の本文、誰でも閲覧できるコードの保管場所、スクリーンショットに写さないことも基本です。不要になった接続のトークンは無効にします。制作担当者が変わるときは、人のアカウントとAIの接続を両方確認してください。
4. AIの誤操作は、不正アクセスとは別に起こりうる
正しく認証されたAIでも、日付を取り違えたり、確認していない実績を文章に含めたりすることがあります。これは、外部から侵入された場合とは別の問題です。
外部の資料やWebページに書かれた文を、AIが作業指示として誤って扱う可能性も考えておきます。記事の材料は材料として読み、掲載先や公開範囲を勝手に変えない運用にする必要があります。
RealAIzeが企業向けに勧めるのは、AIが下書きを作り、人が次の点を確認する流れです。
- 会社名・人名・日付・料金に誤りがないか
- 公開してよい写真や実績だけを使っているか
- リンク先と問い合わせ先が正しいか
- スマートフォンでも画像と本文が読めるか
AIによるコード点検も補助にはなりますが、それだけで安全性を証明できるわけではありません。扱う情報や機能に応じて、開発担当者による確認を組み合わせます。
5. 更新とバックアップは、移行後も続く
EmDashにも本体や依存するソフトウェアの更新があります。Cloudflareを使えばサーバー設備の管理を任せられますが、サイトのコード、CMS、プラグイン、権限設定まで自動で保守されるという意味ではありません。EmDashの更新手順
バックアップについても、「記事をエクスポートできる」と「サイトを障害前に戻せる」は同じではありません。公式ガイドでは、サイトの書き出しデータにユーザー情報・認証トークン・プラグイン専用のデータなどが含まれない点を説明しています。データベース、画像、設定をどう復元するかまで決めておきます。バックアップと復旧
更新前に検証環境で試す、バックアップから戻せるか確かめる。この手順はEmDashでもWordPressでも役立ちます。WordPressにも自動更新やバックアップを含む安全対策があり、製品名だけで危険・安全を二分するのは適切ではありません。WordPress公式の安全対策
制作を依頼するときに確認すること
見積もりや引き継ぎでは、機能一覧に加えて「誰が何を守るか」を聞いてください。CMSやプラグインの更新担当、AIの権限、バックアップの対象と保存期間、復旧の連絡先。この4点が決まっていれば、問題が起きたときに担当者を探すところから始めずに済みます。
よくある質問
EmDashのプラグインは、すべて安全に隔離されますか？
すべてではありません。サンドボックス型は専用の実行環境で動かすことで権限を制限しますが、ネイティブ型はサイト本体と同じ環境で動きます。プラグインの種類だけでなく、実際の実行設定と配布元を確認してください。
パスキーを使っていれば、不正アクセスの心配はありませんか？
パスキーは偽サイトへ認証情報を入力させる攻撃に強い仕組みですが、端末の紛失やログイン済みブラウザの管理は別に必要です。担当者ごとにアカウントを分け、端末を失ったときの連絡先と復旧手順を残します。
AIに下書きだけを任せることはできますか？
公開できないユーザー権限と、AI接続用の鍵（認証トークン）に設定する操作範囲を組み合わせる設計が考えられます。管理者権限を渡して指示文だけで公開を止めるのではなく、設定で制限できているかを制作担当者と確認します。
EmDashに移行したあとも保守は必要ですか？
必要です。CMS・プラグイン・関連ソフトウェアの更新、権限の見直し、バックアップと復旧の点検を続けます。記事のエクスポートだけでは、ユーザー情報やプラグイン専用データなどを含むサイト全体の復旧には足りません。