Cloudflare が自社ブログを EmDash へ移行 — Astro × Workers の本番構成と、ブログ用 MCP server を公開

要約

Cloudflare が 2026-08-24、自社ブログを EmDash へ移行した経緯と本番アーキテクチャを公開しました。EmDash は同社が 2026-04-01 に発表した Astro ベース・TypeScript 製の CMS で、プラグインを Dynamic Workers の隔離環境で動かすことにより WordPress のプラグインセキュリティ問題を構造的に解こうとしているプロダクトです。移行の実施日は 2026-08-12、今回はその後日談にあたります。

製品リリースの告知ではありません。自社が Customer Zero として使った、という導入事例です。 ただし公開された内容の密度が高く、Astro と Cloudflare Workers でコンテンツサイトを運用する場合の一次情報として参照価値があります。

公開された本番構成は次のとおりです。EmDash を Cloudflare Worker 上で実行し、新しい Workers Cache の背後に配置（Cloudflare は「主要サイトとしてはおそらく初」と述べています）、Workers KV 上に構築された EmDash のオブジェクトキャッシュ（Cloudflare の用途向けに EmDash チームが作ったもの）を使い、Cloudflare が一次提供する Hyperdrive × PlanetScale 連携でデータベースへ接続します。フロントエンドは Kumo デザインシステムに沿って再構築し、ライト／ダークモードのネイティブ対応を入れています。

移行の安全策が具体的に書かれている点が、この記事のいちばんの価値です。 プロキシ Worker を前段に置いてレガシーブログと新サイトへトラフィックを振り分け、バージョン Cookie で経路を決め、新サイトが 500 系を返したらレガシーへフォールバックできるようにした。プロキシから新ブログ Worker へは NEW_BLOG という service binding による Worker 間直結を使い、公開ホスト名・DNS・TLS・外向き HTTP を経由しない分のレイテンシを削っています。ローンチ当日は 1% → 5% → 15% と段階的に引き上げ、その日のうちに 100% へ移しました。

エージェント向けの成果が2つ挙げられています。1つは Cloudflare Blog 用の MCP server を新たに公開したこと。 EmDash の API と AI search エンドポイントが Worker から公開されているため、MCP 化には数時間しかかからなかったと述べています。もう1つは EmDash 自体が持つ MCP server で、ブログ執筆者はコンテンツの閲覧・作成・編集、投稿の公開と予約、ファイル削除などを MCP 経由で行えます。

実測値も出ています。p95 レスポンスレイテンシは、旧構成にあった負荷時のスパイクが消えて平坦な応答プロファイルになったとしています。最大 850 RPS を処理し、Agents Week（9日間で18本、約300万ページビュー）ではフロントエンドの Worker が 最大 450 RPS を問題なく捌き、8月10日には 28,000 RPS の DDoS を標準の DDoS 防御で吸収したと報告しています。

課題も書かれています。予約投稿が EmDash 0.19.0 まで機能しなかったこと、編集体験まわりの細かな不具合が残っていることです。前者は「スケジュール時刻を過ぎてから気づきたくない類の問題だった」と率直に書かれています。

何が変わったか

• Cloudflare Blog 用の MCP server が新規公開された（EmDash API と AI search エンドポイントを Worker から公開。実装は数時間）
• EmDash 自体の MCP server により、執筆者は閲覧・作成・編集・公開・予約・ファイル削除を MCP 経由で実行できる
• 本番構成が実測値つきで公開: Workers 上の EmDash + 新 Workers Cache + Workers KV オブジェクトキャッシュ + Hyperdrive × PlanetScale
• 移行方式が公開: プロキシ Worker によるトラフィック振り分け、バージョン Cookie による経路決定、500 系でのレガシーへのフォールバック、NEW_BLOG service binding による Worker 間直結
• 段階ロールアウトの実際: 1% → 5% → 15% → 当日中に 100%
• 実測値: p95 レイテンシのスパイク解消、最大 850 RPS、Agents Week でフロントエンド 450 RPS、28,000 RPS の DDoS 吸収（2026-08-10）
• フロントエンドを Kumo デザインシステムで再構築し、ライト／ダークモードにネイティブ対応
• 既知の課題: 予約投稿が EmDash 0.19.0 まで動作しなかった、編集体験まわりに細かな不具合

業務インパクト（一般企業向け）

この記事の実務価値は、構成そのものより「切り替え方」にあります。 新旧2系統を並走させ、プロキシで振り分け、エラー時にフォールバックする。この形自体は目新しくありませんが、Workers の service binding を使うと、プロキシ層のコストがほぼ無視できるという点が具体的に示されました。公開ホスト名・DNS・TLS・外向き HTTP を経由しないため、プロキシを挟むことによるレイテンシ増を心配せずに済みます。「安全な切り替え方は分かっているが、二重構成のコストが見合わない」で止まっていた移行には、直接効く情報です。

1% から段階的に上げるという進め方も、そのまま真似できます。 重要なのは、当日中に 100% まで到達している点です。段階ロールアウトは慎重さの表明として何日もかけがちですが、フォールバックが確実に効くなら、当日中に振り切ってよい。慎重さの本質は時間の長さではなく、戻せることです。 この区別は、社内で移行計画を通すときの論拠になります。

CMS 選定の判断材料としても読めますが、そこは慎重に。 Cloudflare は自ら「Customer Zero」と書いており、EmDash チームは Cloudflare の用途向けに Workers KV のオブジェクトキャッシュを専用に作っています。この事例と同じ条件が一般の利用者に揃うわけではありません。 予約投稿が 0.19.0 まで動かなかったという記述からも、プロダクトとしての成熟度は読み取れます。構成の考え方は参考にし、採用の判断は自分の要件で行ってください。

MCP まわりは、コンテンツ運用の自動化を考えている組織に効きます。 EmDash が CMS 自体の MCP server を持つということは、記事の作成・編集・公開・予約をエージェントから操作できるということです。これは執筆の自動化というより、公開フローの自動化の話です。誰が承認して誰が公開するかという権限設計が、そのまま MCP のツール設計に反映されます。導入するなら、「エージェントに公開権限を渡すか」を先に決めてから構成を組んでください。

そして「MCP 化に数時間」という記述は、示唆として重い。 既に API と検索エンドポイントが整っていれば、MCP server の実装コストは小さい。逆に言えば、MCP 対応が重いと感じる場合、問題は MCP ではなく既存 API の側にあります。 自社システムをエージェントから触らせたい組織は、まず API と検索の整備状況を点検するのが順序として正しい、という読み方ができます。

副業・個人活用視点

Astro でサイトを作っている人にとって、これは同じ土俵の本番事例です。 個人サイトや小規模案件で Astro + Cloudflare を使っている場合、「この構成はどこまでスケールするのか」は常に不安として残ります。 850 RPS、Agents Week で 450 RPS、28,000 RPS の DDoS 吸収という数字は、その不安に対する具体的な回答になります。提案の場で「Cloudflare 自身が同じ構成でブログを運用しています」と言えるのは、それだけで説得力が違います。

受託で CMS 移行を扱うなら、切り替え方の型として持っておく価値があります。 プロキシ Worker で振り分け、Cookie で経路を決め、500 系でフォールバック。この設計を自分の手札にしておくと、「移行のリスクが怖い」という相談に対して具体的な手順で答えられます。 WordPress からの移行案件は当面なくなりませんが、多くは技術ではなく「切り替え当日が怖い」で止まっています。

MCP server の実装コストの話は、そのまま営業材料になります。 「API が整っていれば MCP 化は数時間」という Cloudflare の実例は、AI 連携の見積もりを説明するときに使えます。 高く感じる見積もりの内訳が、実は既存 API の整備であることは多い。その切り分けを最初に示せると、話が前に進みます。 逆に、API が整っていない状態で「MCP に対応したい」という相談が来たら、順序が違うと伝える根拠にもなります。

予約投稿が 0.19.0 まで動かなかった、という記述の扱い方も学びどころです。 新しいプロダクトを採用する提案をするなら、こうした未成熟さを自分から先に開示できるかどうかが信頼を分けます。Cloudflare がこれを記事に書いたのは、Customer Zero としての立場を明確にしているからです。同じ姿勢で「ここはまだ荒い」と言える提案は、後で揉めません。