EmDashの料金は無料？運用費と見積もりの注意点

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

EmDashの料金を調べると「無料で使える」という説明と、Cloudflareの有料プランの話が両方出てきます。WordPressから移れば毎月の支払がなくなるのか、AIに任せれば保守の費用も不要なのか。ここを一緒に考えると、契約後の見積もりがずれてしまいますね。

結論は、CMS本体の利用料と、公開基盤・データ・追加機能・保守の費用を分けることです。この記事は2026年10月24日に確認した公式資料とXの公開投稿を基にした調査記事です。私自身の請求額や移行成功談ではありません。Cloudflareに配置する構成を中心に、何を足すと費目が増えるか、読者が記入できる確認票に整理します。

記事のポイント

• CMS本体が無料でも残る費用
• 隔離型プラグインと有料基盤の条件
• PVだけでは決まらない従量料金の見方
• 現金支出と保守工数を分ける見積もり票

EmDashの料金と無料範囲を分ける

まずは「何が無料なのか」を固定しましょう。本体、稼働する場所、追加機能を分けると、必要のない契約まで一緒に見積もることを防げます。

CMS本体と公開する費用は別

EmDashは公式リポジトリでMITライセンスとして公開されています。ここで確認できるのは、ソフトウェアのライセンスです。自分のドメインで24時間公開するサーバーや、画像を保存する場所、問い合わせ先の運用まで一律に無償で提供されるという意味ではありません。無料の道具を使っていても、置く場所や維持の仕事は別に必要になります。自分が使う配布物と追加サービスの契約を一組ずつ確認することが、料金比較の出発点です。

例えば、手元のPCで検証するだけの場合と、Cloudflare上で記事・画像を公開する場合では、費用の対象が変わります。EmDashのCloudflare配置ガイドは、Workersでアプリを動かし、D1をデータベース、R2をメディア保存に使う構成を説明しています。この構成を選ぶなら、EmDashという名前の請求だけを探すのではなく、それぞれの基盤の利用条件を読みます。無料枠の中で収まるかどうかも、公開後の利用量と、同じアカウントのほかの利用状況を含めて確かめる必要があります。

見積もりには「本体ライセンス」「公開基盤」「データ保存」「任意機能」「運用作業」の五つの欄を作ると整理しやすいです。既存のドメインを継続するなら、その更新費用も消えません。すでに別サービスを契約している人は、EmDash専用の追加支出と、元から払っている共有費用を分けてください。追加支出がないことと、その仕組みに原価がないことは別です。EmDashそのものの概要から確認したい場合は、EmDashの導入条件と注意点も合わせて読むと、料金だけでは決められない部分を見つけられます。

隔離型プラグインの有料条件

費用が分かれる重要な条件が、隔離型プラグインを使うかどうかです。公式のプラグインサンドボックス資料では、Cloudflare Workers上の実行にWorkers Paidプランが必要とされています。Worker Loaderなどの構成も前提になります。つまり「CMS本体の利用料は不要」と「使いたい拡張を含む構成が無料枠で動く」は同じ説明ではありません。必要な機能を先に書き出し、その機能がどの方式で動くかを確かめてから基盤プランを選びます。

同資料は、サーバープロセス内で動くネイティブ型と、隔離された実行環境を使う型を区別しています。ネイティブ型まで同じ隔離を受けるわけではありません。また、Cloudflare向けテンプレートの案内には、隔離型を有効にしない場合に無料プランから配置する説明がありますが、テンプレートや生成時の選択、依存関係で構成は変わります。すべてのEmDashサイトが同じ設定で無料になる、という一行にはまとめられません。この記事では実際の配置試験をしていないため、特定のテンプレートで無料公開できた実績とも表現しません。

「有料になるなら隔離を外せばよい」と考える前に、その拡張が必要か、信頼境界と運用担当をどう決めるかを確認します。費用を減らすために保護を弱めるのは、料金の最適化とは別の変更です。Node.js向けには別の実行方式も案内されていますが、そちらにもサーバー費や保守作業が残ります。見積もり票にはプラグイン名、実行方式、必要なプラン、更新担当を並べ、分からない欄は未確認と残しましょう。追加機能を使う予定がない段階で、すべての有料サービスを先に契約する必要もありません。

WorkersはPVだけで計算しない

Workersの費用を考えるとき、月間PVだけで請求額を決めないようにします。記事を読む回数と、サーバー側のプログラムが動く回数やCPU処理の量は同じではないためです。画像などの静的なファイル、管理画面、記事の動的な表示、予約公開の処理など、サイトの仕事には違いがあります。同じ一万PVでも、どの処理を何回呼ぶかによって基盤の利用量は変わります。まずは閲覧の規模ではなく、選んだ構成が利用する課金指標へ置き換えることが必要です。

Workersの現行料金資料は、Paidプランのアカウント最低料金を月5米ドルと案内し、含まれるリクエスト数とCPU時間、超過時の料金を分けています。2026年10月24日の確認時点では、Standardに月1,000万リクエストと3,000万CPUミリ秒の枠があります。一方、静的アセットへのリクエストには別の扱いがあります。このため、アクセス数をそのまま一律単価へ掛けるだけでは正確な見積もりになりません。金額は米ドルで記載し、税やカードの換算条件を無視した固定の日本円にはしていません。

小さなサイトでも、予約処理や検証用環境が動くことがあります。反対に、静的に配信できる部分が多ければ、同じ見た目のサイトでも動的な処理を減らせる場合があります。ただし、当サイトがEmDashでどれだけ削減できるかを実測したわけではありません。契約前は「動的表示」「定期実行」「管理・インポート」の想定を書き、公開後は実際のWorkersの指標と請求内訳で補正する手順にします。すでにPaidを使っているアカウントなら最低料金をサイトごとに二重計上せず、共有費と増分を別欄へ置くと、比較の条件を保てます。

データベースと画像の費用

記事を保存するデータベースと、画像を置くストレージは、別の仕事をしています。D1で見るのは読み書きした行数や保存量、R2で見るのは保存量と操作の種類などです。記事が百本あるから必ずこの金額、画像が千枚だから必ず無料、といった本数だけの見積もりは避けます。管理画面での検索、一覧表示、データ移入、バックアップも利用量に関係し得ます。閲覧時だけを見るのではなく、作成・保存・取得・加工のどの段階に料金が生まれるかを書き分けると整理できます。

D1専用の料金資料は、読み取った行数と返された件数が必ずしも同じではないことを説明しています。R2の料金資料も、保存量、Class AとClass Bの操作、ストレージクラスを分けています。転送費が無料という説明を、保存やすべての操作まで無料と読み替えないでください。また、R2のStandard向け無料枠をInfrequent Accessへそのまま適用することもできません。本文では料金表の全数値を複製せず、自分の構成の対象指標と、その専用資料を対応させます。

画像の変換サービスを追加する場合は、保存費と別に確認します。Imagesの料金資料では、元画像と変換条件の組み合わせを基に数えます。例えば同じ写真を複数サイズへ変換する構成では、元画像の枚数だけを数えると見積もりが不足します。画像をR2へ置くだけなのか、変換を使うのか、Imagesに保存するのかを先に固定しましょう。D1の超過保存単価は横断的な紹介表と専用資料の記載が異なる箇所もあるため、契約時は専用料金資料と自分のアカウントの表示を照合します。未確認の単価で総額を確定しないことも、見積もりの品質です。

AIとメールは採用分だけ加える

AIと連携できるCMSだからといって、すべてのAI利用料がCMS本体に含まれているわけではありません。サイトを作るために使うAI、記事の下書きに使うAI、公開サイト上で検索や回答を提供するAIは、用途も支払先も違います。どれを採用するか決まっていない段階で、一律にAI費をゼロとすることも、全部を必須として加算することも避けます。まず必要な機能を一文で書き、その実行先と契約単位を追う方法が使えます。

例えば、すでに契約している制作支援ツールでコードを整えるだけなら、公開サイトに来訪者向けのAI機能を付ける場合と同じ費用ではありません。既存契約の中で使える範囲、別APIの従量支払、新しいプラグイン等の契約をそれぞれ確認します。メールも同じで、通知や問い合わせに何を使うかを決めてから送信先サービスの条件を見ます。EmDashのメール設定の公式資料は構成を確認する入口ですが、ここに設定方法があるだけで、読者の契約に必要な送信量が無料になるとはいえません。

費目に迷ったら「採用する」「使わない」「まだ未定」の三つへ分けてみてください。使わない機能の料金を実運用費へ足さず、未定のものを無料と決めないことが大切です。外部AIのAPIキーやメールの認証値を見積もり相手へ渡す必要もありません。サービス名、プラン、利用量の想定だけで比較できる範囲を選びます。追加機能を後から有効にすると費用の構成が変わるため、見積もりの確認日と変更した機能を残しておきましょう。契約の数を減らすこと自体を目的にせず、必要な機能にだけ費用と管理責任を対応させると、見直しやすい予算になります。

EmDashの料金を自分の構成で見積もる

必要な費目が分かったら、現在のサイトと同じ条件で比較します。最低料金だけで移行を決めず、年次支払、移行期間、更新や復旧の担当も一緒に確認しましょう。

三つの構成から費目を選ぶ

見積もりの最初に、どの運用を想定しているかを固定します。ここでは手元での検証、Cloudflareで基本機能を公開する構成、隔離型プラグインや追加サービスを使う構成の三つへ分けます。これは公式の商品ランクではなく、費目の取り違えを避けるための当サイトの分類です。最も小さい構成を、実際に必要な機能がないまま本番向けと判断しないようにしてください。使いたい機能の条件を満たせなければ、安い試算でも導入判断には使えません。

下表は契約案内ではなく記入の入口です。ローカルだけの検証なら新しい公開基盤の契約をしない場合もありますが、既存PCや作業時間の負担は残ります。Cloudflareの基本公開も、選択したテンプレートや設定、利用量によって無料範囲が変わります。隔離型を使う場合はWorkers Paidの条件を先に確認し、それに付随する利用量と外部サービスを別に見積もります。公式の最低額を、バックアップやメールを含む万能な月額へ変換しないことが大切です。

例えば、隔離型プラグインが必要でPaidを新規に契約し、ほかの従量利用がすべて含まれる範囲なら、Workersの部分は最低月5米ドルから考えられます。ただし、これはEmDash全体の総額ではありません。D1、R2、画像変換などを実際に含まれる範囲へ収められるかを確認し、ドメインや保守は別欄にします。PVからその状態を保証することもできません。条件が決まらない項目は「後で請求がない」と決めず、見積もりの未確定事項へ残してください。

月額と年間を同じ条件で比べる

今のサイトとEmDashを比べるなら、比較する期間をそろえます。WordPress側の年払い金額をそのまま月額と比べたり、初年度の割引価格だけを使ったりすると、長く運営した場合の差が見えません。既存契約の更新時期、ドメイン、追加サービス、移行中の二重支払を同じ期間に置く必要があります。支払をやめられる費目と、どちらへ移っても続く費目を分けると、実際の節約分がどこにあるかを確認しやすくなります。

試算では、初期の移行作業と月ごとの維持費を別々に書きます。例えば月5米ドルの部分だけを十二か月続ける計算なら60米ドルですが、それはWorkers基盤の最低料金だけの算数です。外部サービス、超過分、ドメイン更新、税、為替の扱いまで含む年間総額ではありません。自分のカードの換算条件が分からないなら、米ドル欄と日本円で支払う費用欄を無理に合算しない方法もあります。金額の空欄を都合のよいレートで埋めないようにしましょう。

保守も、現金支払と時間を分けておくと判断が変わります。自分で更新・復元・問い合わせの確認をするなら請求書には出なくても作業があります。外注するなら、その見積もりの対象を確認します。現行CMSの保守が付いた契約と、自主管理の基盤だけを比較すれば、安く見えるのは当然かもしれません。移行の適否全体はEmDashとWordPressを比較する条件へ分け、本稿では「同じ機能、同じ期間、同じ担当範囲」で費用を照合します。契約の解約や本番移行を試算のために実行する必要はありません。

無料というX投稿の条件を読む

Xの利用報告は、どんな目的でEmDashが試されているかを知る入口になります。一方で、短い投稿には請求対象や保守担当まで書かれていないこともあります。無料、簡単、費用が下がったという言葉を見るときは、何を作り、どの契約を置き換え、何の費用を比較したかを分けて読みます。話題の大きさや表示回数を、そのまま読者の節約額の根拠にはできません。投稿者が発信や事業を行う立場であることも、内容の条件として確認します。

今回確認した2026年10月12日のポートフォリオ再構築の投稿は、AI活用を発信する方による利用紹介です。また、9月11日の自社サイト移行準備の投稿には、年間運用費を約八割削減したという本人申告があります。ただし、請求書、移行前後の全機能、保守時間の内訳は今回確保できていません。動画本編の全工程を検証したわけでもありません。これを一般の平均削減率や、自分のサイトも同じ比率になるという予測に使うことはできません。

後者の可視の会話には、後から修正できる担当と作業時間を残すべきだという返信もありました。これは別の削減成功例ではなく、保守を見積もりへ入れる観点として扱います。使える問いは「何の契約がなくなるか」「追加したサービスは何か」「翌年に直すのは誰か」の三つです。好意的な利用報告も留保も、公式の仕様や実際の請求の代わりにはしません。本人の体験をosukeの実績へ書き換えず、読者の比較票に足す質問へ変える。それが少数の公開投稿を役立てる読み方だと考えています。

予算通知と課金停止を分ける

見積もりを作った後も、予定した金額と実際の利用量はずれる可能性があります。記事が読まれる回数だけでなく、管理操作、画像加工、定期実行、検証環境の仕事もあるからです。そこで必要なのは、使った量に気付く仕組みと、予想外に増えたときの対応を分けて決めることです。予算を知らせる通知があるだけで、設定額を超える前にすべてのサービスが停止するとは判断できません。サービスごとの制限や反映条件を読み、何を誰が確認するかを決めておきます。

WorkersにはCPU時間などの制御、各サービスには利用枠や上限がありますが、それぞれ対象と効果が違います。一つのCPU上限が、D1の保存、R2の操作、外部AI、メールなどの請求を一括して止めるものではありません。無料プランで新しい処理が実行できなくなる場合も、それは請求が増える現象とは別です。例えばImagesの無料枠では、新しい変換が上限に達した後のエラー条件が案内されています。無料だから無制限に表示できるとも、有料化すればどの制限もなくなるとも考えないようにします。

確認票には「見る指標」「通知先」「確認担当」「見直す条件」を書きます。例えば画像を増やした日や新しいサイズを追加した日を残せば、後から変換数が増えた理由を調べやすくなります。公開時だけでなく、機能を追加した後にも見積もりを更新しましょう。具体的な上限の設定を行う場合は、その時点の公式手順と対象サービスを確認します。本稿は読者の本番設定を変更する操作記事ではありません。費用の制御をさらに整理したい場合は、Cloudflareの上限管理の考え方と現行公式資料を合わせて、通知と停止の違いを確認してください。

EmDashの料金確認票で判断

最後に、金額が分からない項目も残せる確認票へまとめます。すべての欄を無理に埋めることではなく、どこまで確かめたかが分かる状態にするのが目的です。CMS本体が無料という事実は出発点になりますが、必要な機能と担当をそろえなければ、サイト全体の費用は決まりません。とくに公開サイトの運用を誰かへ任せている場合は、現在の契約に何の保守が含まれるかを先に確認してください。安い基盤を見つけたことだけで同じ仕事を引き継げたとはいえません。

この票に確認日と想定期間を付けると、料金や構成が変わった後にも比べ直せます。例えば毎月の基盤費が低くても、移行直後の二重契約と作業が大きければ、初年度の支出は別の形になります。一方、今の契約が不要な機能を多く含んでいて、維持作業を自分で引き受けられるなら、見直す余地があるかもしれません。どちらも結論を先に決めず、同じ機能を続ける条件で比べます。外注の見積もりがない項目を想像の時給や日数で確定せず、依頼範囲を整理してから確認してください。

今日の作業は、今のサイトで外せない機能を三つ書き、その機能をEmDashで実現するための契約と担当を対応させるところまでで十分です。Cloudflare上の隔離型にはPaid要件があること、月5米ドルは総運用費の保証ではないこと、DBや画像はPV以外の指標を見ることを押さえます。Xの個別報告は参考にしても、本人の請求条件をそのまま借りないでください。無料か有料かの二択より、自分に必要な機能を維持できる予算かどうか。その問いへ戻せる見積もりなら、後からサービスや料金が変わっても判断の土台を残せます。