はじめに
「EmDash（エムダッシュ）」は、Cloudflareが開発したCMS（コンテンツ管理システム）です。
AIエージェントの手を借りて、EmDashでサイトを公開した経営者様・ご担当者様もいらっしゃると思います。
公開してしばらくすると、管理画面に新しい版が出たことを知らせる通知が表示されます。
EmDashのアップデートは、管理画面のボタンを押して終わるものではありません。
サイトのプロジェクト（サイトのプログラム一式）で更新し、公開し直す作業が必要です。
失敗したときにどこまで戻せるかも、データベースの作りの変更（移行）があるかどうかで変わります。
この記事では、EmDashのアップデートの基本、更新の前に確かめること、5つの手順、失敗したときの戻し方を順に紹介します。
あわせて、AIエージェントに任せるときの分担と、更新の記録の残し方、業種別に気をつけたいことも整理します。
なお、この記事で扱うのは、句読点の「エムダッシュ（—）」ではなく、CMSのEmDashです。
手順は、2026年11月7日時点の最新版EmDash 1.4.0の公式ドキュメントと、公式のAI向けの手順書に基づいています。
EmDashそのものの仕組みは、EmDashの全体像で解説しています。
EmDashのアップデートの基本
EmDashのアップデートは、プロジェクトで新しい版のパッケージに入れ替え、作業指示書に沿って直し、ビルドして公開し直す流れで行います。
手順に入る前に、管理画面の通知、版の番号の読み方、公式の更新ツールの役割の3つを押さえておきましょう。
管理画面の通知は「知らせる」だけ
新しい版が出ると、EmDashの管理画面に通知が表示されます。
EmDash 1.4.0の日本語表示では、「EmDash ○.○.○が利用可能です（現在のバージョン: ○.○.○）」の形で、新しい版と今の版が示されます。
通知には、「最新の修正を適用するには、プロジェクトのemdashパッケージを更新して再デプロイしてください。」という案内と、リリースノートへのリンクが添えられます。
WordPressのように、管理画面から本体を更新する仕組みではない点に注意が必要です。
版の番号の読み方と、これまでの間隔
EmDashの版の番号は、公式ドキュメントで次のように説明されています（2026年11月7日時点）。
| 種類 | 例 | 含まれるもの |
|---|---|---|
| パッチリリース | 1.3.0 → 1.3.1 | 互換性を保った不具合の修正と小さな改善 |
| マイナーリリース | 1.3 → 1.4 | 互換性を保った新しい機能 |
| メジャーリリース | 1.x → 2.0 | 既存のサイトに変更が必要になることがある。対象と必要な対応はリリースの項目に書かれる |
EmDashは、1.0の公開時に、互換性を壊す変更は新しいメジャーバージョンでだけ行う方針を示しています。
2026年9月28日の1.0.1から、10月29日の1.4.0までに、1.1.0・1.2.0・1.3.0・1.3.1が出ています（npmの公開記録）。
本体の emdash と、Cloudflare向けの @emdash-cms/cloudflare は、同じ版の番号で一緒に公開されます。
@emdash-cms/cloudflare は同じ版の emdash を前提にしているため、2つはそろえて更新します。
プラグインのパッケージは、それぞれ別の版の番号を持っています。
更新ツール upgrade-emdash がすること・しないこと
公式は、更新に upgrade-emdash という専用のツールを用意しています（2026年11月7日時点の最新は0.1.0）。
このツールが受け持つ範囲は、次のとおりです。
| する | しない |
|---|---|
プロジェクトが直接使っている emdash と @emdash-cms/ で始まるパッケージを、新しい版に入れ替える | サイト独自のコードや設定ファイルの書き換え（package.json や、pnpmのcatalogを使う場合の pnpm-workspace.yaml など、依存関係の更新に必要な変更を除く） |
| AI向けの手順書（Agent Skills）を新しくする | データベースの移行の適用 |
| またいだ版の変更点と、追加される移行をまとめた作業指示書を作る | サイトの公開（デプロイ） |
テンプレートからサイトを作ったときにコピーされたレイアウトやスタイル、astro.config.mjs などのファイルも、更新されません。
テンプレートの新しい変更を取り入れたい場合は、公式のテンプレートのファイルと見比べて、必要な部分を自分で写します。
更新の前に確かめること
アップデートのつまずきの多くは、始める前に確かめておけば防げるものです。
特に、データベースの移行が含まれる更新では、戻すための準備を先に済ませておく必要があります。
ここでは、作業の前に確かめたい5つの点を紹介します。
更新先までの変更点
まず、今の版から更新先の版までの変更点を確かめます。
途中の版を飛ばして上げる場合は、飛ばした版の変更点もすべて対象です。
変更点は、公式のリリースの一覧（GitHub Releases）に、パッケージと版ごとに載っています。
互換性を壊す変更には「Breaking」と書かれ、サイト側の対応が必要な項目には「What should I do?」の欄が設けられていることがあります。
互換性を保つマイナーやパッチの版にも、対応のお願いが含まれることがあります。
たとえば1.4.0では、メニューの翻訳に失敗したことがあるサイトに向けて、残った空のメニューを削除して翻訳し直すよう案内されています。
後で紹介する更新ツールの確認用の実行（--dry-run）でも、またぐ版の変更点の一覧が表示されます。
データベースの移行があるか。あれば復元点を先に作る
公式ドキュメントによると、更新ツールはサイトのデータベースに接続しないため、ツールを動かす前に専用のバックアップは要りません。
ただし、次のどれかに当てはまる場合は、新しい版を起動・公開する前に、確かに戻せる時点（復元点）を作るよう求められています。
- 作業指示書に、データベースの移行が追加されている
emdash migrate --statusで、前の更新の移行がまだ残っていると表示される- リリースの項目が、データを書き換える作業を求めている
管理画面の「バックアップ」で作られるJSON形式のファイルは、確認用です。
公式ドキュメントでは、JSONのバックアップからはサイトを復元できないと説明されています。
Cloudflareのデータベース（D1）の場合は、過去の時点に戻せる機能（Time Travel）の、更新前の時点の記録が復元点の一つになります。
更新の直前に pnpm wrangler d1 time-travel info データベース名 を実行すると、その時点を示す記録（ブックマーク）が表示されます。
このブックマークを、更新の記録に控えておきます。
Node.jsのサーバーで動かしている場合は、使っているデータベースに合った方法でバックアップを取ります。
Node.jsの版（作業するパソコンと、サーバー）
EmDashのビルドや更新の作業には、Node.js（サーバーでJavaScriptを動かす仕組み）を使います。
公式ドキュメントは、ビルドする機械と、Node.jsで動かす場合のサーバー（サーバーとは）の両方で、Node.jsの版を確かめるよう案内しています。
EmDash 1.4.0の時点で必要なのは、Node.js 22.23.4以上です。
Node.js 22のサポートは、2027年4月30日に終わる予定です。
また、Node.jsは、26.x・24.x・22.xの新しい版を2026年11月11日（またはその直後）に出すと予告しています（2026年11月7日時点）。
各系統で最も深刻な問題は「HIGH」とされているため、作業に使うパソコンやサーバーのNode.jsも、あわせて更新を検討しましょう。
0.35.0より前・0.xのまま止まっている場合
更新ツールが使えるのは、emdash 0.35.0以降のサイトです。
それより古いサイトは、復元点を作ってから、パッケージを手作業で0.35.0まで上げ、そこまでの変更点を読んでから更新ツールを使います。
0.xから1.0へ上げる場合は、互換性を壊す変更が含まれます。
公式ドキュメントの「Upgrade to EmDash 1.0」に、削除された機能と対応の方法がまとめられています。
Cloudflareで初期の設定（auto）のまま動かしていて、0.38以前から上げる場合も注意が必要です。
公式の変更履歴は、公開の前に emdash migrate で移行を当てるよう案内しています。
公開の仕組みを確かめる
サイトをどのような仕組みで公開しているかも、更新の前に確かめておきます。
CloudflareのGitHub連携（Workers Builds）では、本番用のブランチにプッシュするたびに、ビルドと公開が行われます。
Cloudflareの公式ドキュメントで、このように説明されています（2026年11月7日時点）。
この場合、更新の変更を本番用のブランチに入れた時点で、新しい版が本番に公開されます。
復元点は、本番用のブランチに入れる前に作っておきましょう。
公開前に試すための環境（プレビュー）を使う場合も、注意があります。
EmDashの公式ドキュメントは、プレビューには本番とは別のデータベースと保存先を用意し、本番のデータベースにつながないよう求めています。
EmDashをアップデートする5つの手順
ここからは、公式ドキュメントに沿って、Cloudflareで動かしているサイトの更新の流れを5つの手順で紹介します。
コマンドは、AIエージェントに実行を任せることもできます。
その場合も、各手順で人が確かめる点を押さえておくと、思わぬ公開を防げます。
なお、コマンドは公式ドキュメントの例（pnpm）です。
npmを使っている場合は、npm run build・npm run dev・npx wrangler deploy のように読み替えます。
ステップ1：変更点を確かめる
最初に、ファイルを変えずに更新の内容だけを確かめます。
サイトのプロジェクトのフォルダで、次のコマンドを実行します。
npx upgrade-emdash@latest --dry-run
各パッケージの更新先の版と、またぐ版の変更点が表示されます。
追加される移行は、パッケージを入れた後に計算されるため、この段階では表示されません。
更新先は、公開の系統（latest・next・beta など）で決まり、版の番号を直接指定することはできません。
通常は、最新版を表す latest のままで問題ありません。
ステップ2：パッケージとAI向けの手順書を更新する
内容を確かめたら、次のコマンドで実際に更新します。
npx upgrade-emdash@latest
更新ツールは、package.json の版の書き方（^ や ~ など）を保ったまま、パッケージマネージャーを動かしてパッケージを入れ替えます。
続けて、公式のAI向けの手順書（Agent Skills）も新しくします。
公式の更新ツールを使えば、手順書を別に更新する必要はありません。
手順書の更新に失敗した場合は、警告と、入れ直すためのコマンドが表示されます。
最後に、更新の前後でデータベースの移行の内容を比べ、作業指示書を作ります。
この段階では、移行はまだ適用されません。
ステップ3：作業指示書の対応をする
更新ツールが作った作業指示書（.emdash/UPGRADE.md）を開きます。
作業指示書には、またいだ版の変更点、追加される移行の名前、このサイトで使うビルドと移行のコマンドがまとめられています。
公式のAI向けの手順書は、変更点の一つひとつをサイトと照らし合わせ、使っていない機能の新しい要素は取り入れないよう定めています。
必要な修正だけを行い、関係のない変更でサイトを作り変えないことが大切です。
作業指示書に移行が含まれている場合は、確かに戻せる復元点を作るまで、新しい版を起動・公開しません。
ステップ4：ビルドして、手元で動かして確かめる
修正が終わったら、ビルドします。
pnpm build
ビルドでは、この版に必要な移行の一覧をまとめたファイル（マニフェスト）も作られます。
ビルドが失敗した場合は、後の「更新に失敗したときの戻し方」を参照してください。
次に、手元のパソコンでサイトを起動し、管理画面（/_emdash/admin）を開いて動きを確かめます。
pnpm dev
保留中の移行は、起動後の最初のアクセスで実行されます。
手元の環境から、保留中の移行があるデータベース（本番など）につないでいる場合は、起動の前に復元点を作っておく必要があります。
ステップ5：公開して、公開後に確かめる
手元で問題がなければ、いつもと同じ方法で公開します。
Cloudflareの場合は、次のコマンドです。
pnpm wrangler deploy
Node.jsのサーバーで動かしている場合は、新しいビルドでプログラムを起動し直します。
初期の設定（auto）では、公開した後の最初のアクセスで、保留中の移行が適用されます。
公開した後は、公式ドキュメントが挙げる次の項目を確かめます。
- 管理画面を開く
- 公開しているページを1つ以上表示する
- 捨ててよい記事を作り、編集して公開する
- 捨ててよい画像をアップロードし、表示できるかを確かめる
- 予約公開や、隔離して動かすプラグインを使っている場合は、それらも確かめる
公開したデータベースに、適用されていない移行が残っていないかは、emdash migrate --check で確かめられます。
移行が残っている場合、このコマンドはエラーとして終わります。
データベースの移行と「503」への備え
EmDash 1.3.1（2026年10月公開）から、更新後に移行を終えられないときの動きが変わりました。
Cloudflareで初期の設定（auto）のまま動かしているサイトでは、503（サービスを利用できない）を返すようになっています。
以前は、中身のないページを正常なページとして返してしまう不具合があったため、障害に気づきやすくする変更です。
ここでは、移行の性質と、503が出る2つの場合、公開の前に移行を当てる方法を紹介します。
移行は前に進むだけ
EmDashのデータベースの移行は、前に進むだけで、元に戻す処理は用意されていません。
公式ドキュメントによると、前の版のプログラムを公開し直しても、適用済みの移行は戻りません。
移行の記録を削除したり、移行を取り消す内部の処理を動かしたりして戻すことも、公式は避けるよう求めています。
戻す必要があるときは、後で紹介する「データベースとプログラムを一緒に戻す」方法をとります。
更新後にサイトが503を返す2つの場合
更新した後にサイトが503を返す場合、主な原因は次の2つです。
どちらかは、Workerのログ（Cloudflareのプログラムの動作記録）に出るエラーで見分けられます。
1つ目は、大きな移行が残っている場合です。
移行の中には、すべての記事と変更履歴を処理する種類のものがあります。
Cloudflareで初期の設定（auto）のまま動かしている場合、この種類の移行の対象が約5,000件を超えると、サイトの側では移行を始めません。
この場合、emdash migrate で移行を適用するまで、サイトは503を返します。
適用が終わると、30秒以内に表示が戻ります。
なお、Node.jsのサーバーや手元の開発用のサーバーでは、大きさにかかわらず、起動時に移行が適用されます。
2つ目は、移行のロック（同時に移行が走らないようにする仕組み）が残った場合です。
Cloudflareのデータベース（D1）で移行が途中で止まると、ロックが残ります。
ロックが1分を超えて残ると、初期の設定（auto）のサイトは503を返します。
emdash migrate --status で、ロックの状態を確かめます。
解消は、公式ドキュメントの「Release a stuck migration lock」の手順に沿って行います。
ロックの解消には、データベースを編集できる権限（D1 Edit）を持つAPIトークンが必要です。
ほかの移行が動いていないことを確かめずに操作すると、データを傷めるおそれがあるため、慣れていない場合は無理に進めないでください。
公開の前に移行を当てる流れと、3つのモード
公開した後の最初のアクセスで移行を当てるのではなく、公開の前に当てることもできます。
公式ドキュメントでは、次の順で行う方法が紹介されています。
pnpm buildでビルドするpnpm emdash migrate --statusで、対象のデータベースと保留中の移行を確かめるpnpm emdash migrateで移行を適用する（適用の前に、対象の確認を求められる）pnpm wrangler deployで公開するpnpm emdash migrate --checkで、移行が残っていないかを確かめる
Cloudflareのデータベース（D1）では、emdash migrate の各コマンドで、対象のデータベースを指定します。
指定には、--wrangler-config wrangler.jsonc などのオプションを使います。
あわせて、データベースを編集できる権限（D1 Edit）を持つAPIトークンを、コマンドを実行する環境の環境変数に設定します。
アカウントIDは、環境変数、--account-id オプション、または指定したWrangler設定ファイルの account_id で指定します。
このサイトで使う正確なコマンドは、作業指示書に書かれています。
サイトの側で移行をどう扱うかは、設定で選べます。
初期値の auto は起動時に確かめて適用し、check は保留中の移行があれば503を返し、manual は何もしません。
公式は、公開の仕組みが毎回の移行を確実に行えるようになってから、auto → check → manual の順に切り替えることを勧めています。
更新に失敗したときの戻し方
更新に失敗したときの戻し方は、データベースの移行が適用される前か後かで変わります。
慌てて操作する前に、まずどこまで進んだかを確かめ、2つのうち合う方法で戻しましょう。
まず、どこまで進んだかを確かめる
公式ドキュメントは、症状ごとに次の対応を案内しています（2026年11月7日時点）。
| 症状 | 公式の案内 |
|---|---|
| ビルドが失敗する、自分で作ったページがエラーになる | 飛ばした版も含めて「Breaking」の項目を読み、書かれた変更を行う |
| プラグインが読み込まれない | そのプラグインのリリースの項目と、「Upgrading plugins on your site」を読む |
| Astro（EmDashの土台の仕組み）のエラーが出る | EmDashはAstro 6以上が必要。Astroの更新の案内に沿って更新する |
| サイトが503を返す | 前の章の「更新後にサイトが503を返す2つの場合」を確かめる |
移行が適用されたかどうかは、emdash migrate --status で確かめられます。
このコマンドでは、適用済み・保留中の移行の一覧が表示されます。
【移行が適用される前】前の版を公開し直す
移行が適用されていなければ、前の版に戻すのは比較的簡単です。
公式ドキュメントでは、前の版のパッケージを入れ直し、そのビルドを公開し直す方法が案内されています。
Cloudflareの管理画面から戻す方法もあります。
Workers & Pagesで対象のWorkerを開き、「Deployments」で前の版の「Rollback」を選びます。
コマンドの場合は wrangler rollback で、直近の100の版まで戻せます（Cloudflare公式ドキュメント）。
ただし、Cloudflareのロールバックで戻るのはプログラムだけです。
公式ドキュメントによると、ロールバックの間、データベース（D1）や画像などの保存先（R2）など、Workerにつないでいるリソースは変更されません。
データの作りが変わっていると、古いプログラムがエラーになることもあります。
【移行が適用された後】データベースとプログラムを一緒に戻す
移行が適用された後で、前の版のプログラムが新しいデータベースの作りで動かない場合は、プログラムだけを戻しても直りません。
公式ドキュメントは、サイトへのアクセスを止めてから、更新前のデータベースとプログラムを一緒に戻すよう案内しています。
アクセスの止め方は公式ドキュメントに指定がないため、動かす場所ごとの止め方を事前に決めておきましょう。
D1の場合は、Time Travelで更新前の時点に戻せます。
pnpm wrangler d1 time-travel restore に、控えておいたブックマークか、戻したい日時を指定します。
Cloudflareの公式ドキュメントによると、この復元はデータベースをその場で上書きし、処理中の問い合わせは取り消されます。
戻した時点より後に行った記事の編集や公開も、データベースからは消えます。
更新の後に記事を書き足していた場合は、内容を控えてから戻しましょう。
復元すると、復元する直前の状態を示すブックマークが返されるため、それを使って復元を取り消すこともできます。
戻せる期間は、無料プランで7日、有料プランで30日です（2026年11月7日時点）。
画像などのファイルは、更新で変わった場合だけ戻します。
外部に書き出したバックアップから戻す場合、戻せるのは書き出した時点の状態です。
戻した後にやること
戻した後は、失敗した原因の項目を読み直し、必要な修正を済ませてから、あらためて更新します。
何が起き、どの時点に戻したかは、後で紹介する更新の記録に残しておきましょう。
アップデートをAIエージェントに任せるときの分担
更新ツールは、公式のAI向けの手順書（upgrading-emdash）もプロジェクトに入れます。
この手順書は、AIエージェントが更新のどこまでを行い、どこで人に確認するかを定めています。
任せる前に、AIと人の分担を確かめておきましょう。
公式の手順書が「先に確認する」と定めていること
公式の手順書は、データベースへの移行の適用や公開、そのほかの手元のパソコンの外への変更について、依頼に含まれていない限り、実行の前に確認するよう定めています。
「公開まで済ませて」とAIに頼むかどうかで、AIの動きが変わるということです。
ほかにも、次のような決まりがあります。
- 作業指示書の項目を一つずつサイトと照らし合わせ、使っていない機能の新しい要素は取り入れない
- 書式の確認やテスト、ビルドを行い、移行の状況を報告する
- データベースを変える作業の前に、復元できるデータベースのバックアップ、画像などの別のバックアップ、関係する暗号化キー（プラグインの設定に秘密の情報を保存している場合）がそろっていること、移行と公開に同じビルドを使うことを確かめる
人が決めること・確かめること
手順書の決まりを踏まえると、分担の目安は次のようになります。
| AIエージェントに任せやすいこと | 人が行うこと |
|---|---|
| 更新ツールの実行 | 更新してよいかの判断 |
| 作業指示書に沿った修正 | 復元点が作られたかの確認 |
| ビルドとテスト | 移行の適用と公開の承認 |
| 移行の状況の報告 | 公開後の確認と、APIトークンの権限の管理 |
AIエージェントにつなぐAPIトークンは、作業に必要な権限だけにしておくと安心です。
AIの使い方そのものは、EmDashの使い方で紹介しています。
更新の頻度と、更新の記録の残し方
アップデートは一度で終わる作業ではなく、新しい版が出るたびに続きます。
ここでは、更新の間隔の考え方と、毎回残しておきたい記録の項目を紹介します。
どのくらいの間隔で更新するか
EmDashのGitHubのセキュリティポリシーは、脆弱性の報告の対象を、開発中の版と最新の公開版としています（2026年11月7日時点）。
古い版を長く使い続ける前提にはなっていないため、新しい版はあまりためずに適用するのが基本です。
弊社では、月に1回程度まとめて適用し、重大なセキュリティの修正はその都度適用する方法をおすすめしています。
更新をためるほど、読むべき変更点が増えるためです。
更新以外の作業も含めた頻度の目安は、EmDashサイトの保守管理でまとめています。
更新の記録に残す項目
更新のたびに、次の項目を記録しておくと、不具合が出たときや担当が変わったときに役立ちます。
| 項目 | 記録する内容の例 |
|---|---|
| 日付と作業した人 | 作業の日付、作業した人、承認した人 |
| 版 | 更新前と更新後の emdash・@emdash-cms/cloudflare・プラグインの版 |
| Node.jsの版 | 作業したパソコンと、サーバーのNode.jsの版 |
| 作業指示書 | 対応した項目と、対応しなかった項目の理由 |
| 移行 | 移行の有無と、適用した方法（公開の前か、公開後の最初のアクセスか） |
| 復元点 | D1のブックマークや、バックアップの保存場所と取得日時 |
| 公開後の確認 | 確かめた項目と結果 |
| つまずき | エラーの内容と、直し方 |
業種別に見る、更新で気をつけたいこと
更新の手順そのものは共通ですが、気をつけたい点は業種によって変わります。
ここでは5つの業種を例に紹介します。
あくまで検討の目安としてご覧ください。
士業（税理士・社労士・行政書士など）
お知らせやコラムの更新が少なく、管理画面を開く機会が少ない業種です。
その分、新しい版の通知に気づかず、飛ばす版が増えがちです。
更新を行う日を毎月決めておき、またぐ版の変更点をまとめて読む流れにしておくと続けやすくなります。
飲食店・小売店
予約やネット販売の利用が多い時間帯に公開すると、不具合の影響が大きくなります。
公開は、利用の少ない時間帯を選びましょう。
外部の予約や決済のサービスと連携している場合は、公開後にその部分も動いているかを確かめます。
整骨院・クリニック
予約や問い合わせのフォームを置くことが多い業種です。
公開後の確認では、フォームを実際に送信し、通知が届くかまで確かめましょう。
掲載する表現には業界ごとのルールがあるため、判断に迷う内容は所管の窓口や専門家にご確認ください。
工務店・製造業
施工事例や製品の紹介の記事が多く、変更履歴も積み重なりやすい業種です。
記事と変更履歴の数が多いと、大きな移行の更新で、Cloudflareで初期の設定のまま動かしているサイトは、503を返すことがあります。
記事の多いサイトでは、公開の前に emdash migrate で移行を当てる流れを選ぶと、止まる時間を減らしやすくなります。
マンション管理組合・団体
役員や担当者が持ち回りで更新する組織では、交代のたびに手順が途切れがちです。
更新の記録と、APIトークンや管理者の権限を、組織として引き継げるようにしておきましょう。
総会の案内など、大切なお知らせを出す直前の更新は避けると安心です。
EmDashのアップデートに関するよくある質問
EmDashのアップデートについて、よくある疑問にお答えします。
仕様は変わることがあるため、記載の時点もあわせてご確認ください。
Q: 管理画面からワンクリックで更新できますか？
2026年11月7日時点のEmDash 1.4.0では、できません。
管理画面には新しい版の通知が表示されますが、更新はサイトのプロジェクトで行い、公開し直す必要があります。
Q: 何か月か飛ばして、最新版に上げても大丈夫ですか？
更新ツールを使えば、途中の版を飛ばして最新版に上げられます。
ただし、飛ばした版の変更点もすべて作業指示書に含まれるため、一つずつ確かめる必要があります。
emdash 0.35.0より前の版からは、先に0.35.0まで手作業で上げてから更新ツールを使います。
Q: 更新したらサイトが「503」になりました。どうすればよいですか？
主な原因は、大きな移行が残っている場合と、移行のロックが残った場合の2つです。
Workerのログに出るエラーで、どちらかを見分けられます。
大きな移行なら emdash migrate で適用し、ロックなら公式ドキュメントの手順に沿って解消します。
Q: Cloudflareのロールバックだけで元に戻りますか？
データベースの移行が適用される前なら、ロールバックで前の版のプログラムに戻せます。
移行が適用された後は、ロールバックだけでは戻りません。
Cloudflareのロールバックでは、データベース（D1）の中身は変わらないためです。
Q: プラグインも一緒に更新されますか？
更新ツールの対象は、プロジェクトが直接使っている emdash と、@emdash-cms/ で始まる公式のパッケージです。
管理画面から入れたプラグインは、「プラグイン」の画面の「更新を確認」から更新します（EmDash 1.4.0の日本語表示）。
それ以外のプラグインは、各プラグインの変更履歴と案内を確かめてください。
まとめ
EmDashのアップデートは、管理画面ではなくサイトのプロジェクトで行い、作業指示書に沿って直してから公開し直す作業です。
データベースの移行は取り消せないため、更新の前の準備と、失敗したときの戻し方をあわせて決めておくことが大切です。
この記事の要点を振り返ります。
- 管理画面の通知は知らせるだけで、更新は公式の更新ツール（
upgrade-emdash）を使ってプロジェクトで行う - 更新の前に、変更点・移行の有無と復元点・Node.jsの版・古い版かどうか・公開の仕組みを確かめる
- 手順は、変更点の確認、更新、作業指示書の対応、ビルドと手元の確認、公開と公開後の確認の5つ
- 更新後の503は、大きな移行かロックが主な原因で、Workerのログで見分ける
- 戻し方は移行の前後で変わり、移行の後はデータベースとプログラムを一緒に戻す
ホームページ制作・保守管理のご相談は、株式会社リヒトスまでお気軽にお問い合わせください。
EmDashで作ったホームページの保守管理に関するお問い合わせ
※EmDashのサービスやEmDashの制作方法などに関することはお答えできません。制作されたサイトの保守管理に関してのご相談窓口です。
