EmDashの始め方｜無料枠で初回公開する手順と注意点

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

EmDashを試したいけれど、最初のコマンドを普段使いのパソコンで実行してよいのか、無料と書かれていても契約が必要なのか、迷いませんか。管理画面が表示されることと、記事を公開して読めることも別です。

今回はGitHub Codespacesを作業場所にし、CloudflareのWorkers無料プラン、D1、R2、KVを使って、テスト記事1本の公開と画像表示、公開後の修正まで確認しました。この記事では、その順番とつまずいた箇所を整理します。手順の確認日は2026年10月26日、検証したEmDashは1.3.1です。

配置や編集はAIの操作支援を使い、管理者アカウントとパスキーの登録は私が行いました。本人限定の認証を付けた検証サイトでの結果であり、不特定多数へ開放したサイトの負荷や長期運用まで確かめたものではありません。

記事のポイント

• PCへ開発ソフトを入れずに進める作業場所と前提条件
• 無料枠と契約・認証権限を確認するタイミング
• 下書き保存から初回公開、画像表示までの操作
• 修正の公開、認証エラー、検証後の片付けの確認方法

EmDashの始め方と導入前の準備

最初は本番サイトの移行をせず、消しても困らない記事を1本公開するところを目標にします。作業場所、無料枠、変更する対象を先に決めてから、Cloudflareへの配置へ進みましょう。

今回できたことと検証の範囲

今回の到達点は、EmDashの管理画面で日本語の下書きを作り、画像を付けて公開し、閲覧ページで読み直せる状態です。さらに本文を追記し、更新の公開後に表示が変わることまで確認しました。Hello Worldや初期設定画面が出た時点を、ブログの完成とは数えていません。投稿する側と読む側の両方を確かめることで、「保存したのに見えない」という迷いを減らせます。

構成はCloudflare公式の配置方法を土台に、初回公開に必要な機能へ絞りました。WorkersはEmDashを動かす場所、D1は記事などの保存先、R2は画像の保存先、KVはログインに関わるセッションの保存先です。GitHub Codespacesはこれらへ配置するための作業場で、公開サイトそのものではありません。役割を分けると、作業場を停止した後も、配置済みのサイトが動く理由が分かります。

一方、確認した記事は1本、画像は約3.45KBのPNG1点です。予約投稿、独自ドメイン、外部へのメール送信、既存WordPressからの移行、復元試験は行っていません。Cloudflare Accessで閲覧できる人も限定しました。少量で成功した結果を「大きなサイトも問題なく動く」「誰でもずっと無料」と広げることはできません。まずは同じくらい小さな範囲で、自分が必要とする操作を確かめるのがよいと思います。

無料枠と必要なアカウント

この方法ではCloudflareとGitHubのアカウントを使います。Workersが無料プランでも、周辺サービスの条件まで同じになるわけではありません。特にR2は、無料枠のある従量課金サービスです。利用開始の申込みや支払方法に関する画面が出たら、その内容を確認してから進めてください。「無料枠内で試すこと」と「課金できる契約を一切結ばないこと」は、別の条件として考える必要があります。

GitHub Freeの個人アカウントには、Codespacesの計算時間120コア時間と保存容量15GB-monthの月間無料枠があります。2コアを使う場合、120時間そのまま作業できるという意味ではありません。また、停止すると計算時間の消費は止まりますが、残したファイルの保存容量は枠を消費します。作りっぱなしを避け、ほかのCodespacesと合算した利用状況を見ることが大切です。今回は有料分を使わない予算条件を確認したうえで、小さな環境を使いました。

Cloudflare上の隔離型プラグインにはWorkersの有料プランが必要ですが、今回は使わず、画像変換や定期処理も無効にした構成です。R2管理画面の料金は確認時点で$0.00でした。ただし、これは最終請求書ではありませんし、利用量が増えた後の料金を保証する数字でもありません。料金全体の判断はEmDashの料金と運用費を見積もる際の注意点へ分け、本稿では初回公開に必要な契約と利用量をそろえます。

料金の確認先は、CloudflareのR2公式料金とGitHub Codespacesの公式課金説明です。R2では保存量だけでなく読み書きの操作も対象になります。予算通知を、あらゆる請求を必ず止める機能だと考えないでください。契約や支払方法の登録をAIへ任せる場合も、その操作だけは内容を見てから承認する形にしておくと、意図しない範囲へ進みにくくなります。

PCに入れず作業場所を用意

普段使いのPCへNode.jsや開発ツールを入れたくない場合は、ブラウザで開くGitHub Codespacesを作業場所にできます。ただし、何も導入しない方法ではありません。EmDashや依存ライブラリを導入する先が、PCからリモートの作業環境へ変わる方法です。ブラウザのファイル一覧やターミナルが、どの環境のものなのかを最初に確認してください。ローカルのターミナルへ同じコマンドを貼らないことが、最初の分かれ道です。

GitHubで検証専用の非公開リポジトリを1つ作り、そのリポジトリからブラウザ版Codespacesを開きます。今回は2コアの環境を使いました。最初にフォルダーを信頼する確認が出た場合も、対象は今回のリモート作業フォルダーに限定します。ほかのリポジトリやPC全体の信頼設定へ広げる必要はありません。アカウントや契約の確認は本人が済ませ、作業用ファイルと公開データを区別して扱います。

リモートのターミナルでは、まずpwdとnode --versionで作業場所と実行基盤を確認します。今回の配置準備は/workspaces/…以下で行いました。公式の一般的な入門手順には、PC上でNode.jsとSQLiteを使う経路もありますが、ここではCloudflare向けテンプレートを選びます。WordPressの管理画面のように、ブラウザから登録するだけですべての配置設定が済むサービスではない点は、先に理解しておくと戸惑いにくいですね。

AIへ操作を頼むなら、「このリモートフォルダーだけを対象にする」「PCへのインストールや設定変更はしない」「契約・支払・新しい認証権限では一度止まる」と、変更の境界を明示します。本人が自分で作業する場合にも、この三つは確認票として使えます。手元のPCへの影響を減らしても、外部サービスにファイルや設定は残ります。作業が終わったら停止し、不要になった環境を片付けるところまでが、この方法の準備に含まれます。

Cloudflareの保存先と権限

Cloudflare側では、既存サイトと混ざらない名前でWorker、D1データベース、R2バケット、KV名前空間を用意します。今回はそれぞれ1件ずつ、検証専用として作成しました。新しい独自ドメインは取得せず、Workerに付くworkers.devのURLを使っています。R2のバケットを一般公開する操作も行わず、EmDash経由で画像を表示できることを確かめました。公開範囲を広げなくても、保存と表示の基本確認は進められます。

初期登録前の入口には、Cloudflare Accessで本人のメール認証を設定しました。これはEmDashの管理者ログインとは別の門です。今回はWorker全体とプレビューを対象に、本人だけを許可する設定にしています。入口のメール認証と、EmDash側のパスキーが二つ必要になるのはこのためです。一般向けサイトを公開するときの最終設定とは違うので、本人限定のまま閲覧できた結果を、匿名の読者にも見える状態とは扱いません。

配置の認証には、既存の検証用Worker1件だけを対象にした短期間のAPIトークンを使いました。権限はIndividual Workers Editorです。先に管理画面で保存先を作成して識別子を設定したため、配置ツールへアカウント全体の作成権限を渡す方法は採っていません。権限が足りない警告が出ても、すぐに全サービスを編集できる権限へ変えるのではなく、何の確認や操作ができないのかを見ます。Cloudflare公式のWorker単位の権限説明が判断の基準になります。

トークンは配置先のコードを変更できる認証情報です。記事やスクリーンショット、リポジトリ、コマンド履歴へ値を載せず、一時入力で扱います。作業後は使ったトークンを削除し、リモート環境の入力用変数からも消しました。認証文字列を正しく渡せず、最初の配置が失敗したこともありましたが、その際に権限を広げて解決したわけではありません。対象、できる操作、有効期限、渡す先を一組で確認してから使うことが大切です。

テンプレートを作成して配置

以下は、今回リモートの作業場所で実行した生成コマンドです。バージョンは検証した1.3.1へ固定し、Cloudflare向けのブログテンプレートを選び、隔離型プラグインは使わない指定にしています。将来の最新版でも同じ結果になることを保証するコマンドではありません。再現するときは生成ツールの案内と現行の公式手順を照合し、未対応の選択肢や追加契約が出たらそこで内容を確認してください。

npm create emdash@1.3.1 site -- --template cloudflare:blog --pm npm --install --no-sandboxed-plugins --yes

生成後はsite/wrangler.jsoncのWorker名を先ほど作ったものに合わせ、アカウント識別子、D1のdatabase_id、R2のbucket_name、KVのidを指定します。接続名はDB、MEDIA、SESSIONです。識別子を設定せずに進めると、自動作成を試みる経路と、既存の保存先を使う経路が混ざります。公式資料には自動作成の方法もありますが、今回は権限を限定するため、先に作ったものを明示する方法で配置しました。

無料プランで試す条件に合わせ、worker_loadersとsandboxRunnerを使わず、triggers.cronsは空にしました。画像変換も使わないよう、AstroのCloudflareアダプターをcloudflare({ imageService: "passthrough" })へ変更しています。これはプラグインや予約機能まで備えた完成形ではなく、即時公開を確かめるための構成です。EmDash公式のCloudflare配置手順と照らし、不要な機能を外した理由も一緒に記録してください。

npm --prefix site run build
WRANGLER_SEND_METRICS=false ./site/node_modules/.bin/wrangler deploy --cwd site

今回の依存関係には警告があったため、そのまま配置せず、Zodとundiciの間接依存を同じメジャー版の修正版へ合わせました。変更後の監査は0件、ビルドも成功していますが、これで安全性全体が証明されたわけではありません。別環境へ同じ上書き指定を無条件にコピーするのではなく、対象版と警告を確認します。ビルド成功後も、表示された配置先が検証用Workerか、DB・画像・セッションが意図した保存先かを確かめ、配置済みURLの表示まで進めてください。

EmDashの始め方を初回公開で確認

サイトが配置できたら、管理者登録と投稿操作へ進みます。画面上の「保存済み」と、閲覧ページへ変更が出る状態は同じではありません。下書き、公開、修正公開を順番に確認しましょう。

管理者とパスキーを登録

配置したサイトの/_emdash/admin/setupを開くと、初期設定を進められます。今回はサイトタイトルとキャッチフレーズを入力し、サンプル記事を追加する選択ではなく、Empty siteを選びました。最初からサンプルがあると、自分が作った記事の件数や表示を取り違えることがあるためです。すでに初期設定が完了したサイトでは、セットアップをやり直すのではなく通常の管理画面へ進みます。

次に管理者の名前とメールアドレスを登録します。検証用の表示名はダミーでも構いませんが、メールは本人が管理できるものを使います。今回は本人がアカウント登録とパスキーの作成を行いました。AIへ作業を頼んでいても、パスキーの保存先を選ぶ操作まで自動的に任せる必要はありません。端末やパスワード管理サービスの案内を見て、今回の検証サイト用だと分かるように保存先を控えます。

先に決めたいのは、初期登録に使うサイトの住所です。EmDash公式は、初期設定時の住所とパスキーの関係を説明しています。workers.devで作ったパスキーが、後で変更する独自ドメインにもそのまま使えると考えないでください。今回は独自ドメインへ移さず、同じ検証用URLで操作しました。アカウントができたら、ダッシュボードが出ることと、Postsやメディアのメニューを開けることを確認します。

「また認証が出た」と感じたときは、どちらの画面なのかを見ます。Cloudflare Accessのメールコードはサイトの入口、EmDashのパスキーはCMSの管理者ログインです。片方を通ったことが、もう片方の登録完了を意味するわけではありません。コードやパスキーを共有して解決しようとせず、画面のサービス名とURLを確認します。この切り分けをしておくと、後で入口の認証期限が来ても、CMSが壊れたと早合点しにくくなります。

日本語の下書きと画像を保存

管理画面でPostsを開き、新しいPostを作成します。今回は日本語のタイトル、短い本文、Excerptという抜粋、英字の識別名を入力しました。検証記事の識別名にはfirst-post-verificationを使っています。これはEmDash側のテスト記事の例であり、このWordPressブログの記事URLの設定とは別です。最初は日常の仕事や顧客情報を持ち込まず、消しても支障のない文章で操作を確かめます。

Featured Imageの選択画面ではライブラリからファイルをアップロードしました。画像は個人情報を含まない640×360のPNGで、元ファイルは3,454バイトです。アップロード後、管理画面にファイル名と画像寸法が出ること、メディア一覧が1件になることを確認しました。R2側でも対応するオブジェクトを1点確認しています。アップロード中の表示が終わる前に画面を閉じず、画像を選択して記事へ設定するところまで進めます。

本文と画像を設定したら保存し、保存済みの表示を確認します。この段階で記事にはIDが付き、今回の画面ではDraft versionと表示されました。下書きの内容が管理画面へ戻っても残ることが確認のポイントです。ファイルを選んだだけ、入力欄へ文章を貼っただけ、という状態と区別してください。操作を繰り返すときも、同じ下書きを開き、画面が止まったからと新しい記事をもう1本作らないようにします。

日本語を入力できることと、サイト全体の言語設定が日本語になることも別です。今回の管理画面には日本語の案内がありましたが、コンテンツ言語はEnglish、閲覧ページの日付等には英語表示が残りました。本文が日本語でも、すべての表示やメタ情報が自動で日本語向けに整うと考えないでください。初回検証では日本語の保存と閲覧を確認し、言語設定や検索向け出力の細かな整備は次の確認項目として残します。

公開と修正の反映を確かめる

下書きを公開する操作はPublish nowです。確認画面で、すぐにサイトへ表示されることを確認して実行します。今回も保存後の下書きから進め、公開済みの通知が出た後にライブビューを開きました。見るのはタイトルだけではなく、本文が途中で欠けていないか、抜粋と本文を取り違えていないか、画像が読み込まれているかです。管理画面側の成功表示と、閲覧ページ側の実際の表示を一組で確認します。

公開できた後は、本文末尾へ更新確認の一文を加えて保存しました。ここで重要だったのが、保存だけでは読者の見る版が切り替わらない点です。管理画面にはDraft changesと、訪問者には公開済みの版が表示される旨が出ました。続けてPublish changesを実行し、閲覧ページを再読み込みすると追記が出ています。元の公開ページが表示されるからといって、保存が失敗したとは限らないわけですね。

この流れは、EmDash公式のコンテンツ編集ガイドでも確認できます。ただし、記事を非公開にする操作や予約投稿は別の機能です。今回、定期処理を無効にした環境で即時公開できたことを、予約投稿まで動く根拠にはしません。修正が見えないときは、先に公開状態と閲覧URLを確かめ、その後にキャッシュ等を調べます。最初から一括削除や再配置へ進まず、変更した箇所だけを追う方が原因を絞りやすくなります。

エラーの切り分けと後片付け

今回、最初の公開操作では「保存に失敗しました」と表示されました。再読み込みするとCloudflare Accessのメール認証へ移動し、本人の認証後にも一度、認証トークンの期限切れという画面が出ています。その後、期限切れの認証URLを使い続けず、通常の管理画面URLから入り直すと復帰し、同じ下書きの公開が成功しました。ソフトやPCのクラッシュが起きたことまでは確認していません。

この経過から「失敗は必ずAccessのせい」「無料プランのCPU不足だった」と断定することはできません。通信応答まで含めた直接の原因は確定していないためです。読者が同じような画面になったら、表示文、起きた時刻、どの操作の直後か、下書きが残っているかを先に記録します。Accessの認証画面なのか、EmDashのエラーなのか、Cloudflareの実行エラーなのかを分け、保存状態が不明なまま公開ボタンを何度も押さないようにしてください。

Xでも、2026年10月12日のポートフォリオ再構築の紹介のような好意的な利用報告がある一方、10月17日のホスティング上の問題解決に関する申告も確認しました。後者は契約構成や原因、解決まで確認できた事例ではありません。前者の手軽さの評価も一般保証には使わず、まず自分の保存・公開・修正を確かめる、という判断材料として読んでいます。

検証が終わったら、配置用のトークンを無効化し、Codespacesを停止します。停止した作業環境のファイルや、Cloudflare側のWorker・D1・R2・KV・Access設定は自動で全部消えるわけではありません。不要になったら対象名を照合し、必要なデータを保全してから削除します。本人が保存したパスキーも別の保存物です。既存サイトと共用している設定やアカウント全体の契約まで、一括して消さないでください。記事公開の確認と、検証環境の完全な片付けを、別々の完了項目にしておくと安心です。

EmDashの始め方の最終確認

EmDashの始め方として、今回確認できたのは「PCへ開発ソフトを入れず、リモートで配置を準備し、Cloudflareの無料プランと各サービスの無料枠の範囲で小さな記事を公開する」という経路です。クリックだけですべて終わるわけではありませんが、作業場所と契約、認証権限の範囲を一つずつ決めれば、どこで本人の判断が必要なのかを整理できます。既存のWordPressを止めずに試せることも、この小さな検証の利点です。

「本当に0円で運営できるのか」という問いへの答えは、今回の少量の確認ではR2の料金表示が$0.00で、Workersも無料プランだった、という範囲です。将来の利用量、請求の確定、追加機能の費用は別です。「PCへの導入なしなら安全なのか」についても、リモート側の依存関係、アカウント、認証情報、公開範囲の管理は残ります。どちらも単純な安心の言葉にまとめず、何を使い、どの量で、何を確認したかを残してください。

「これで本番サイトへ移ってよいか」は、もう一段先の問いです。必要なプラグイン、独自ドメイン、バックアップと復元、検索向けの出力、運用担当がそろってから判断します。全体像を確認するならEmDashの導入条件と注意点、既存ブログを移すか迷うならEmDashとWordPressの比較で確認したい条件へ進んでください。初回公開の成功は、その比較に使える材料が一つ増えた段階です。

最後の確認は、管理画面の表示、記事の公開状態、閲覧ページの本文、画像の表示、修正の反映、料金と残存環境の六つです。どこかが未確認なら、その項目だけを残せば十分です。今回も匿名の一般公開、長期の安定性、検索流入の成果は未確認としています。まずはダミー記事1本で、作る側と読む側を行き来してみる。そこで得た具体的な確認結果が、次の機能追加や本番運用を決める土台になります。