EmDashが動かない？エラー確認の順番と注意点

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

EmDashを配置できたのに記事が開かない。管理画面には入れるのに画像や予約投稿だけ動かない。そんなとき、設定を何から見直すべきか迷いますよね。

この記事では、EmDashが動かない時の確認先を公式資料に沿って整理します。すぐに復旧するコマンド集ではなく、症状を分け、不要な変更を避けるための診断票です。実機のエラー再現や修復試験は行っていない調査記事で、例は想定例と区別しています。

記事のポイント

• ビルド・配置・公開後のエラーを分ける
• D1・R2・認証・画像の確認先が分かる
• 結果不明の書込みを繰り返さず止める
• 秘密を除いた相談用の記録を作れる

EmDashが動かない時の切り分け

まず症状を分けます。どの機能がどこまで動くのかを、操作を増やす前に整理しましょう。

最初に残す症状と変更履歴

サイトが白くなったり、保存ボタンで失敗したりすると、すぐ更新や再配置を試したくなりますよね。まず残したいのは、発生時刻、開いたURL、画面に出た文言、直前に行った変更の4点です。原因がまだ分からないうちに操作を重ねると、最初の失敗と後から起きた変化が混ざり、担当者へ状況を説明しにくくなります。分かる範囲を記録し、分からない欄は空欄のままにします。

たとえば「配置処理は成功と表示されたが、公開記事は503、管理画面も503、画像だけは開く」という想定例なら、単に全部が停止したと書くより調べる範囲を狭められます。画像の経路と通常ページでは、起動時のチェックを通る条件が異なる場合があるからです。一方、画像が表示されたことだけで、データベースやログインも正常だとは言えません。これは当サイトで再現した障害ではなく、記録方法の例です。

記録をそろえるためだけに、本番へ新しいテスト記事を投稿したり、接続先を変更したりする必要はありません。既に見えている結果と、保存済みの配置記録から始めます。復旧までの時間を急ぐ場面ほど、何を変えないで止まるかも判断材料になります。バックアップ、影響範囲、作業権限が分からない場合は、診断票を担当者へ渡すところまでにして、修復操作を始めないでください。

配置エラーと表示エラーの違い

ファイルをまとめるビルド、サーバーへ届ける配置、アクセスに応じて動く実行時処理は、それぞれ確認する場所が違います。ビルドが止まったのか、配置が失敗したのか、配置後のページで失敗したのかを先に分けます。「デプロイできた」という表示は、その後のデータベース参照、画像の取得、認証、予約処理まで試せたという意味にはなりません。成功と表示された工程を限定して記録することが大切です。

公式のNode.js配置資料は、単純なヘルスチェックが200を返しても、データベース、ストレージ、移行状態、プラグイン隔離環境の正常までは証明しないと説明しています。たとえばトップ画面だけ開くのに記事詳細が失敗するなら、入口が生きていることと記事を取得する処理を分けて調べます。CloudflareのWorkerでも、配置結果だけから全機能の復旧を判定しない、という整理は同じです。

「いったん全部作り直すほうが早いのでは」という疑問もあると思います。ただ、作り直す操作で接続先や保存場所まで変わると、元の症状を追いにくくなる場合があります。まず成功した工程と失敗した工程を横に並べ、該当する公式資料へ進むほうが、不要な変更を減らせます。この記事はその入口を整理する調査記事です。個別のサイトのログや実構成を見ずに、復旧できる手順を確定するものではありません。

根拠：EmDash公式・Node.js配置の確認範囲。

D1とR2の接続先を区別する

Cloudflare構成で「D1 binding not found」と出る場合、公式資料はデータベース設定とWrangler設定のバインディング名が一致するかを確認先にしています。「R2 binding not found」は画像などを保存するバケット側の名前を照合する例です。D1はデータベース、R2はオブジェクト保存という役割の違いがあります。同じ接続エラーという言葉でまとめず、どちらのメッセージが出たかをそのまま記録します。

たとえばDBという名前のD1設定と、別名を参照するアプリ設定が組み合わさっていれば、名前の不一致を調べる手掛かりになります。ただし、表示された文言だけで原因を確定したり、名前を変えれば直ると断定したりはできません。アカウント、環境、データベース、バケットが意図した対象かという確認も必要です。特に本番とプレビューの取り違えでは、名前だけを合わせる修正が別の問題を招くおそれがあります。

新しいDBやバケットを作ればよい、という案内にはしません。公式の配置資料も、プレビューに本番のデータベースやバケットを向けないよう注意しています。まず既存の構成記録と、現在参照している環境を担当者が照合できる形へまとめます。接続先の識別情報を公開コメントへ貼る必要はありません。トークンや鍵を含む設定ファイルを丸ごと共有せず、必要な項目だけ秘密を除いて確認してください。

根拠：EmDash公式・Cloudflare配置とトラブルシュート。

ログインと公開URLを切り分ける

公開ページが開かないことと、管理画面へ入れないことは、同じ原因とは限りません。Cloudflare Accessなどのサイト入口で止まるのか、EmDashのログイン画面まで届くのか、ログイン後の保存処理で失敗するのかを分けます。ここをまとめて「認証エラー」とだけ書くと、入口の制限を変更すべきなのか、サイト側のURLや認証方式を確認すべきなのか、判断する材料が不足してしまいます。

公式資料では、パスキーの利用先となるオリジンとサイトURLの関係が説明されています。異なるドメインへ移した後のログイン、プレビューのSITE_URL_REQUIRED、メール送信を設定していない場合のEmail is not configuredは、別々の確認項目です。どの文言も、この記事を読んだだけでパスキーを作り直す理由にはなりません。認証方式、使っていたURL、変更の前後を整理し、現在の設定と照合する必要があります。

ログインできないからといって、Accessを外したり、権限を広げたり、秘密の値を入れ直したりするのは、この診断票の範囲外です。入口の保護を弱めずに、表示された画面とURLの種類を記録してください。メール認証では認証コードそのものを相談文へ載せません。読者本人の登録や端末操作が必要な場面は、本人が内容を理解して実施する段階として分けます。設定を変える前に、誰が何を承認する必要があるかも確認しましょう。

画像だけ表示されない時の見方

文章は読めるのに画像だけ欠ける場合、最初に確認したいのは対象が1点なのか、複数なのか、管理画面の一覧でも同じなのかという範囲です。ファイルが保存されていない場合と、保存済みの画像を配信・変換する途中で失敗する場合では、見る場所が異なります。画像のURL、返ってきたエラー、元画像とサイズ違いの表示結果を記録し、すぐに全画像を再アップロードする判断とは分けます。

公式Cloudflare配置資料には、画像変換の無料プランの枠を超えると、新しい変換が9422エラーとなる条件が説明されています。これはすべての画像エラーを料金不足と決めつける根拠ではありません。同じ資料はR2バインディングや配信方法も扱っています。表示されない画像があっても、保存データの消失、変換条件、公開経路のどれかを記録から切り分ける必要があり、課金すれば直るとは言えません。

見えるようにするためにR2の保存領域全体を公開する方法には注意が必要です。公式は同じ保存領域に自動JSONバックアップが置かれる場合の公開範囲も警告しています。画像だけの問題を解決するつもりで、バックアップまで外から届く状態にしないでください。まず現在の配信経路と対象エラーを記録し、費用・公開範囲・設定変更の必要性を別々に確認します。料金条件全体は既存の費用記事へ分けて案内します。

費用条件はEmDashの無料範囲と運用費の見積もりも参照してください。

EmDashが動かない時の注意点

変更が必要に見えても、結果不明や対象違いでは止まる判断が必要です。復旧の保証と診断の手掛かりを分けます。

503とデータベース移行を確認

503が表示されると、ホスティング全体の障害を想像しやすいと思います。ただ、現行のEmDash公式資料では、未適用のコア移行があるときに503を返す動作も説明されています。runtimeのcheck設定と、Cloudflare上で大きなコンテンツ移行が残る場合など、条件を伴う説明です。503という番号だけで移行が原因と決めず、更新時刻、実行中の版、移行状態に関するメッセージを合わせて整理します。

公式のcore migration資料は、対象の識別情報が変わった場合には止まって確認すること、未知の移行記録を削除したり適用を繰り返したりしないことを示しています。D1への書込み結果が曖昧になった場面も、単純に同じ操作を再実行する扱いではありません。特定の移行に例外があるため、この記事では万能の復旧コマンドを載せず、正確な文言と対象を担当者へ渡す判断に絞ります。

「エラーなので失敗して何も変わっていないはず」とは考えないでください。通信が切れた場合には、処理の結果が分からないだけのこともあります。移行の記録を消す、ロックを強制解除する、古いプログラムだけを戻すといった操作は、データとの整合性を確認する工程を伴います。必要な保存点と責任者が確認できるまでは、追加の書込みを止めて調べます。復旧を早めるためにも、不明を未実行と置き換えないことが大切です。

根拠：EmDash公式・コア移行のトラブルシュートと停止条件。

予約投稿と定期処理を区別する

予定時刻を過ぎても記事が出ない場合、記事の状態や日時の設定と、それを実行する定期処理を別々に確認します。管理画面へ入れることや、通常の記事を公開できることは、予約処理まで動いている証明にはなりません。対象記事の予定日時とタイムゾーン、現在の公開状態、定期処理の実行記録を並べると、時刻の読み違いなのか、実行経路の問題なのかを担当者が確認しやすくなります。

Cloudflare向けの公式資料では、Cron Triggerだけでなくscheduledハンドラーも必要な確認対象です。新規または変更したトリガーの反映には最大15分かかる場合があるとしています。これは既に稼働している予約処理が必ず15分遅れるという意味ではありません。また、実行記録のOkは捕捉されないエラーなく終了したという意味で、意図した記事が公開されたことそのものとは分けて確かめます。

診断ツールにも対象の限界があります。公式はD1構成でdoctorのdatabase項目がローカルSQLiteを探して失敗する場合でも、定期処理の検査に影響しないと説明しています。検査名、対象環境、結果をセットで残し、分からない表示は正常にも異常にもまとめないでください。別の環境で出た結果を本番の状態へ転用しないことも大切です。1つの失敗表示だけで全機能を壊れていると判定せず、何を検査した結果かを読みます。予約を何度も作り直す、同じ記事を手動で重複投稿する前に、公開済みかどうかと処理記録を照合することが先です。

更新直後は版と構成を照合する

更新直後から動かなくなった場合は、更新したパッケージと、配置した成果物が何だったかを確認します。EmDash本体、Cloudflare向けパッケージ、プラグイン、サイト固有のテンプレートは、すべてが同じ仕組みで更新されるわけではありません。公式更新資料は本体とCloudflareパッケージの対応、プラグイン固有の版、テンプレートが自動で置き換わらない点を説明しています。更新ボタンの有無だけでは整理できない部分です。

Xでも、WPTuts氏が管理画面内から更新する方法を質問し、EmDashの保守に関わるとプロフィールに記載するKevin Kyburz氏が、配置済みバンドルとしての更新を説明する会話を確認しました。別の開発者Happy Monkey AI氏は開発中のバグを申告しています。ただし、これらはそれぞれの時点の発言で、読者の障害原因や製品全体の不具合率を示すものではありません。仕様は現行公式資料を基準にします。

前のプログラムへ戻せばデータも元どおり、とは限らない点にも注意してください。公式は、以前の成果物を再配置してもコア移行は逆戻りしないと説明しています。復旧の保存点や版の組合せを詳しく整理したい場合は、既存のバックアップ・更新記事へ進んでください。ここでは更新前後の版、最後に正常だった成果物、エラー文言を記録するところまで扱い、実証していない巻戻し操作を勧めません。

確認した原典：Kevin Kyburz氏の10月30日の元投稿と会話、Happy Monkey AI氏の開発中の申告。仕様の根拠はEmDash公式更新資料です。保全と戻す判断はEmDashのバックアップと更新の確認事項へ。

相談前に秘密を除いて記録する

不具合を相談するときに、設定ファイルやログを丸ごと貼れば早いとは限りません。ログには認証情報、個人情報、接続情報、記事の非公開内容が含まれる可能性があります。公開のIssueやSNSへ出す前に、秘密を除いた最小の情報へ整理します。エラーの意味を保ちながら、鍵、トークン、認証コード、個人のメールアドレス、非公開のコンテンツを出さないことを優先してください。

相談票には、使用しているEmDashの版、配置先の種類、症状、発生時刻、直前の変更、期待した結果と実際の結果を記載します。たとえば「公開記事は200、画像1点は9422、前日は表示できた」といった形です。この例は想定例であり、当サイトの発生記録ではありません。相談用のスクリーンショットも同じ扱いです。ブラウザの別タブ、アカウント名、非公開記事、接続情報が映り込んでいないか、送信前に画像そのものを確認してください。エラーの一部を伏せたら、何を伏せたかも伝えると、原因調査に必要な情報が抜けているかを相手が判断しやすくなります。

公式のトラブルシュートに同じ文言があっても、読者のサイトで同じ原因とは限りません。対象の版と構成、再現条件をそろえ、実施できる人へ相談します。情報を追加するために秘密ファイルを開いたり、不具合を本番で繰り返し再現したりする必要があるなら、その作業は別に影響と権限を確認します。焦って大きな変更を重ねるより、既に分かっていることと未確認を分けた記録が、次の一手を選ぶ助けになります。

EmDashが動かない時の判断票

最初の判断は、どの修復操作をするかではなく、どの工程で止まっているかを特定できる記録があるかどうかです。ビルド、配置、通常ページ、認証、画像、定期処理を別々の欄にして、確認できた結果だけを入れます。全部を調べ終わるまで何もできない、という話ではありません。既に分かっている失敗工程を絞れば、関係しない設定を変えずに公式の該当箇所や担当者へ進めます。

たとえば、記事の表示とログインは正常で予約だけが出ないなら、DBを作り直すより先に日時と定期処理の記録を確認する、という考え方になります。逆に、更新直後の移行で書込み結果が不明なら、同じ操作を繰り返さず止めます。いずれも診断の想定例です。実際の対処は対象サイトの状態を確認して決める必要があり、表の行を選ぶだけで安全や復旧が保証されるわけではありません。

この記事は2026年11月1日に確認した公式資料と公開投稿を整理した調査記事です。今回、PCへの導入、検証サイトの起動、設定変更、エラーの再現、復旧試験は行っていません。新しく確認できた結果が出たら、元の発生時刻を残したまま記録へ追記し、何を変更して何が変わったかを分けてください。EmDashが動かない時こそ、原因が分かった範囲と分からない範囲を分け、次の変更を小さくすることから始めましょう。