EmDashのプラグイン｜互換性と安全性の注意点

こんにちは。Osukeラーニング、運営者の「osuke」です。

EmDashのプラグインを調べていて、「WordPressで使っていた機能も移せるのか」「隔離して動くなら、入れても安心なのか」と迷っていませんか。名前が似た機能を見つけても、必要な権限やサイト側の作業まで同じとは限りません。

先に確認したいのは、プラグインの数ではなく、必要な機能・実行方式・権限・追加作業の4点です。この記事は2026年10月28日時点の公式資料と公開レジストリ、Xの元投稿を照合した調査記事です。紹介する拡張を実サイトへ導入した動作レビューや、安全性を保証する評価ではありません。実行環境を作らずに使える、導入前の確認票を用意しました。

EmDashのプラグインを選ぶ前の基礎

最初に、現在のサイトで必要な機能を整理します。CMSの名前が変わっただけで、これまでの拡張や契約が同じように使えるとは考えないことが出発点です。

WordPressのプラグインはそのまま使えない

WordPressのプラグインを、そのままEmDashへ持ち込んで動かす前提では計画できません。公式のWordPressプラグインの移植資料も、処理、保存データ、通信、管理画面を分け、新しい仕組みに合わせて移植する考え方を示しています。「移行機能がある」と「PHPの拡張まで無修正で動く」は別の話です。

例えば問い合わせフォームなら、入力欄の表示だけでなく、送信内容の保存、担当者への通知、迷惑投稿の対策、外部サービスへの転送までが仕事です。同じ「フォーム」という名前の候補でも、その全てを担当するとは限りません。WordPressで追加したプラグイン名を並べるより、読者や担当者が実際にしている作業を書き出す方が、抜けを見つけやすくなります。

「AIに頼めば移植できるのでは」という期待があっても、実装できる可能性と、引き継ぎを確認できた状態は分けましょう。通知先へ届くか、既存の記録を読めるか、失敗時に誰が対応するかまで確認が必要です。この記事では移植コードや操作手順を示さず、まず必要機能を整理する段階を扱います。

引き継ぐ項目には、画面に見えない仕事も含めてください。例えば「申込完了後に担当者へ通知し、対応履歴を残す」という一文にすれば、入力欄があるだけの候補との違いが見えます。旧プラグインを停止しても過去データを読める必要があるかも確認します。機能の一覧と、保存済みデータの扱いを別にしておくと、表示だけを再現して業務が止まる見落としを減らせます。

標準機能で足りるか先に確認する

現在の機能を全てプラグインで置き換える必要があるとは限りません。公式の移植資料は、AstroやEmDashが担う機能まで移植しないことを勧めています。投稿の種類や項目を管理するだけなら、コレクションなどで表現できる場合があります。WordPress側の構成を、そのまま新しいサイトの必須構成にしないことが大切です。

SEOも確認例になります。EmDashの標準SEO資料には、記事ごとの情報、サイトマップ、リダイレクトなどが説明されています。ただし、コレクションのSEO対応やページ側の出力条件があります。「標準機能があるから、自分のページでも全項目が正常に出る」と確認前に決めるのは早計です。

表の判定を「標準で足りる」「拡張候補あり」「追加実装が必要」「未確認」の4つに分けると整理できます。例えばタイトルと説明文は標準機能を確認し、特殊な申込処理は別に調べるという進め方です。標準対応の有無と、採用したテーマでの表示確認は別の欄に残し、不要な重複拡張を減らしましょう。

棚卸しの資料には、現在の管理画面の項目名と、公開ページで期待する結果を一組で書きます。例えば「説明文を入力できる」と「公開HTMLに期待する説明文が出る」は別の確認です。前者の存在だけを見て作業完了にしないため、後者は未検証欄に置きます。標準機能だけで要件を満たせそうなら、候補を追加する前にその条件を調べる順番にできます。

隔離型とネイティブ型は信頼する範囲が違う

EmDashには、隔離された実行環境を使うサンドボックス型と、サイト本体と同じプロセスで動くネイティブ型があります。公式のプラグイン概要で両方が区別されています。EmDash全体の紹介で「プラグインを隔離できる」と読んでも、採用する全ての拡張が同じ境界で守られるとは限りません。

隔離型は、利用できる実行基盤と設定を前提に、宣言したAPIや資源の制限を受けます。一方、ネイティブ型はサイトと同じ環境で動くため、直接の通信や実行環境へのアクセスなども含め、コードへの信頼が必要です。管理画面の独自表示や公開ページへの組込みなど、必要な機能によって形式が変わる点も確認します。

公式の形式の選択資料は、ネイティブ型の権限宣言を隔離の境界とは扱っていません。「権限が表示されるから、そこにない動作は一切できない」と読むのは避けましょう。動かない拡張を使うためだけに隔離を外すのではなく、必要機能と信頼できる実装・担当者を先に確かめることが判断の中心です。

無料プランと隔離型の利用条件を分ける

EmDash本体のライセンス、サイトを動かす費用、プラグインの実行条件は別々に確認します。Cloudflare上でサイトを表示できたことだけでは、隔離型プラグインの利用条件まで満たしたとはいえません。公式のプラグイン用sandbox資料では、CloudflareのrunnerにWorkers Paidプラン等の条件を挙げています。

Node.js上の構成にも別のrunnerや実行基盤が必要で、「Cloudflareの有料条件を避ければ準備不要になる」という話ではありません。利用先の保守、更新、障害対応まで含めた比較が必要です。プラグインが無料公開されている場合でも、外部のメール配信やAI機能などに費用や別契約が発生し得ることも分けて調べます。

例えば「記事だけ公開する構成」と「隔離型のフォーム拡張と外部通知を使う構成」を別の見積もりにします。無料で試したい場合は、必要機能と条件が一致しない段階で保留にして構いません。金額や利用量を含む全体の見積もりは、既存のEmDashの料金と運用費の記事と、その時点の公式料金を合わせて確認してください。

費用の確認先も分けておきましょう。実行基盤のプランは基盤提供元、拡張のライセンスや追加機能は公開者、外部通知やAI処理の料金はそのサービスの現行条件が確認先です。記事の古い無料表記だけを根拠にせず、必要な契約と利用量を記録します。追加契約を許容しない方針なら、その条件を満たさない候補は有料化を前提にせず保留できます。

Xの利用報告を安全性の証明にしない

Xでは、隔離やAI連携への期待と、既存サイトの置換に慎重な見方の両方を確認できます。WordPress講師による10月10日の投稿は、プラグインの隔離に関心を示す一方、全てが隔離されるわけではないという留保を付けています。注目点を知る材料にはなりますが、安全性の試験結果ではありません。

AIディレクターによる10月12日の投稿は、自分のポートフォリオを作り直した利用申告です。使いやすさや費用を評価していますが、可視の返信には理解を前提とする補足もあります。その人のサイトの評価を、会員情報、決済、複雑な外部連携を持つサイトへそのまま当てはめることはできません。

今回再確認したのは元投稿の本文2件と可視の返信の一部で、動画・画像の検証やX全体の網羅調査ではありません。個人の「安全」「楽」「無料」という評価から、採用プラグイン、契約、権限、保守範囲まで推定しないようにしましょう。仕様は公式資料で照合し、自分のサイトに必要な条件へ戻して判断します。

投稿を参考にする際は、「どの用途で」「何を使い」「どの時点で評価したか」をメモにします。実行方式や権限が書かれていなければ、その欄を推測で補わないでください。新規の個人サイトを公開した報告と、既存顧客の情報を引き継いだ検証では確かめる範囲が違います。自分と条件が似ていない事例も、比較の限界を知る材料として読むことができます。

EmDashのプラグインで失敗を防ぐ確認方法

ここからは、公開資料を読むだけでも進められる確認です。導入ボタンを押す前に、候補の正体、許可する処理、残る作業を一つずつ記録します。

レジストリで公開元と版を特定する

公式の公開カタログでは、プラグイン名だけでなく、公開元を含む識別名、版、説明、要求権限などを確認できます。レジストリの公式説明に沿って、同じ機能名の別パッケージや、記事で紹介された古い版と取り違えないようにします。「フォームがある」という情報だけでは、比較の対象がまだ定まっていません。

例えば候補の記録には、確認日、完全な公開名、版、提供元、ソースへの案内、必要な実行方式を残します。掲載ページの「公式カタログにある」と「提供元がEmDash本体の開発元である」も別の確認です。第三者の説明を本体側の動作保証と読み替えず、追加条件は提供元の資料で確かめます。

レジストリは導入前にバンドルの整合性や名前、版、権限などを確認する仕組みを説明しています。ただし、その確認を「コードに欠陥がない」「自分の用途に適する」という意味に広げないでください。識別や整合性の確認と、機能・運用・安全性の評価を別の欄にすると、掲載表示への過信を避けられます。

また、本文に出てくるサンプル名と、実際に公開されたパッケージを区別してください。公式の画面説明にも例示用の名前が登場します。例示の画像だけを見て、その拡張が現在配布されていると判断しないようにします。候補を決めるときは、個別の掲載ページが開けるか、公開元と版、ソースの案内がつながるかを確認し、検索結果の断片だけで一覧を作らないことが大切です。

権限の数より対象と送信先を見る

権限は数を数えるだけでなく、何に触れられるかを読みます。公式の権限資料では、記事の読み取り・書込み・公開、メディア、ユーザー、ネットワーク通信などが分かれています。記事を読む機能と、削除や公開に関係する機能では、許可した結果として起こり得ることが違います。

外部通信を求める候補なら、送信先が限定されるのか、利用者が指定する任意の宛先に通信するのか、どんなデータを送るのかを確認します。例えば通知用のフォームと、サイト内の記事を検索する機能では、必要な通信もデータも違います。権限名だけでは目的が分からなければ、分からないまま許可しない判断ができます。

「隔離されているから承認しても問題ない」とは考えないことが重要です。隔離は境界を設ける仕組みであり、許可した範囲で行われる処理の妥当性まで自動で判断するものではありません。問い合わせ内容や未公開記事などを扱う場合は、取得対象、保存先、外部送信の必要性を、自分の掲載方針や担当者の責任と合わせて確認してください。

確認票には「その機能が使う情報」と「その機能に許可する処理」を並べて書きます。例えば問い合わせ通知なら、送信者の連絡先や本文がどこへ渡るのかが論点です。読者が入力する情報を扱う用途では、通知の便利さだけを理由に広い通信権限を選ばないようにします。資料で処理の範囲を確かめられなければ、提供元への確認事項として残し、動作可能という結論を先に置かないでください。

フォームと日本語検索の掲載例を比べる

2026年10月28日に公開レジストリで確認した例を2件挙げます。以下は掲載情報の比較であり、当サイトがインストールした結果ではありません。どちらも「2権限」の表示でしたが、その内容は違います。少ない権限数を共通の安全点数にできないことが、この比較で見たい点です。

Freeformの掲載ページは、フォーム管理に加えて、公開側の表示に別のAstroパッケージを案内しています。AI機能には別のAPIキーが必要とも説明しています。「レジストリに入れたら、現在のページへ完成形のフォームが出る」とは読み取らないでください。誰が表示を組み込み、通知と送信内容を確認するかを残します。

jp-searchの掲載ページは、FTS5が使えないNode環境などを想定した日本語検索と説明し、Cloudflare Workersなら公式AI Searchを先に検討する案内もあります。これは提供元の用途説明であり、当サイトによる検索精度の評価ではありません。自分の実行環境が候補の想定と一致するかが、名前に「日本語検索」があることより先の確認です。

更新時の追加権限と削除後のデータを確認する

選定は初回だけで終わりません。公式レジストリ資料では、更新で権限やMCPツールが追加される場合、認証が必要な経路が公開に変わる場合などに、再確認を求める仕組みが説明されています。更新通知を「数字が一つ上がっただけ」と扱わず、以前より何ができるようになるのかを読む必要があります。

例えば記事を読むだけだった拡張が、新しい版で外部へ通知する機能を加えるなら、変更した目的と送信先を確認します。これは実際に上記2例で権限が増えたという報告ではなく、更新判断の想定例です。自動的な互換性を期待せず、版ごとの変更点と、サイト側で確認する担当を決めておくと、判断を他人任せにしにくくなります。

アンインストールとデータ削除も同じではありません。公式資料は、プラグインの保存データを残す扱いと、合わせて削除する選択を区別しています。無効化、削除、外部サービスに保存した記録の消去は、それぞれ確認してください。フォームの過去申込や検索索引など、何を残す必要があるかを先に決め、取り消せない消去を試験の代わりに行わないようにします。

停止時の確認も、候補を選ぶ段階で予定しておきます。「止めたらフォームを閉じるのか」「過去の申込を誰が保管するか」「外部通知の契約は残るか」などを担当者が説明できる状態にします。確認のために本番で削除してみる必要はありません。資料で判明した範囲と、後日必要な動作確認を分けておけば、未検証のまま戻せない変更を行わずに準備できます。

必須機能の確認票で導入と保留を決める

ここまでの確認を、まず必須機能3件だけで試してみてください。例えば「問い合わせを受ける」「記事を検索する」「検索向け情報を出す」です。これは当サイトの整理例で、全サイト共通の必須構成ではありません。プラグイン名を決める前に、標準機能で足りるか、候補が何を求めるかを並べます。

資料だけで分かるのは、機能の説明や前提条件までです。実際の通知到達、日本語の検索結果、更新後の表示や停止時の挙動は、別に動作確認する項目です。分からない欄は未確認のまま残してください。導入候補に入れることと、本番利用を承認することを分ければ、情報不足を勢いで埋めずに済みます。

サイト全体を移すかの判断はEmDashとWordPressの比較記事、全体像から確認したい場合はEmDashの導入前の条件と注意点につなげてください。今日の作業は、拡張を増やすことより、自分が任せたい仕事と許可する範囲を言葉にすることです。その確認が済んでから、必要な検証の範囲と担当を決めましょう。