タグ
#EmDash
EmDashに関する記事を公開しています。
キャッシュを 30 日にしても D1 の読み取りが減らない原因
エッジキャッシュの保持時間を 5 分から 30 日へ延ばしても、データベースの読み取りが目標の 2 倍を超えたままでした。クエリ単位で分解すると 7 割がサイドバーの件数表示のための集計で、しかもサイドバーを消しても止まりませんでした。CMS のミドルウェアが全ページでターム一覧を先読みしていたためです。切り分けに使ったのは 1 起動あたりの読み取り行数と、クエリの実行回数がリクエスト数の何倍かという比率でした。
Cloudflare D1 の読み取りが 1 日 2,100 万行になった原因
1 つの Cloudflare アカウントで CMS のサイトを 8 つ運用していて、データベースの読み取りが 1 日 2,100 万行ありました。使用量は返した行数ではなくスキャンした行数で数えられるため、1 ページ表示するたびに数千行が乗っていたのが原因です。CMS を使っていてクエリを自分で書いていない状況で、キャッシュの保持時間とテンプレートの見直しだけで 91% 減らした記録です。1 リクエストあたりの単価が、1 アカウントに載せられるサイト数の上限を決めていました。
WordPress 移行後に本文に残った旧 URL を Portable Text から数える
WordPress から移行したあとに残る旧画像 URL を片付けようとして、公開 HTML から数えた 21 本とデータベースから数えた 58 本が食い違いました。差の正体は表示されないリンク注釈と、生 HTML ブロックの中の書き換え漏れでした。ついでに 5 記事で画像が 404 になっていたことも見つかりました。
Astro の routeRules から外してもページがキャッシュされる
エッジキャッシュから問い合わせページを外そうとして routeRules に書かずにデプロイしたら、本番では HIT が返ってきました。キャッシュの有効判定は maxAge かタグのどちらかで立ち、CMS のキャッシュヒントはタグだけを持つため、保持時間の指定が無いままキャッシュされます。外すには routeRules ではなくページ側の Astro.cache.set(false) が要ります。
Cloudflare で purge しても age が伸び続けるのは壊れていない
記事を更新してもページが変わらず、age が単調増加する。ここから「失効が壊れている」と結論しましたが、間違いでした。purge はキャッシュを消すだけで、再描画は次のアクセス時です。curl -I での確認はキャッシュから返るためサーバーに届きません。4 回続けて誤診した過程と、キャッシュのデバッグで守るべきことをまとめます。
Cloudflare で HTML がキャッシュされないのは既定の仕様
「Cloudflare を通しているからキャッシュは効いている」は静的ファイルの話でした。HTML には cf-cache-status ヘッダすら付きません。キャッシュミスではなく、判定の対象になっていない状態です。既定が拡張子ベースである理由と、Astro のサーバーレンダリングで HTML をエッジにキャッシュさせる方法を実測とあわせて書きます。
Cloudflare Workers 無料プランで 503 が出る原因は CPU 上限
毎分 10〜31 リクエストという低負荷で 4 回に 1 回が 503。同じサイトが 1 時間 2,516 リクエストをエラーゼロで捌いた実績もあり、負荷では説明が付きません。原因は無料プランの CPU 上限 10ms でしたが、この上限は「1 リクエストで超えたら落ちる」という単純な仕組みにはなっていません。実測ログとあわせて機構を整理します。
Cloudflare Workers 無料プランの 3 MB 上限に数えられるもの
Cloudflare Workers の無料プランには gzip 後 3 MB というバンドルサイズ上限があります。実運用中のサイトの実測値は約 2.1 MB で、残る余裕は 900 KB ほど。画像生成ライブラリを 1 つ足すだけで +680 KB 増えて 3 MB の上限の手前まで届く一方、11 MB ある静的アセットは 1 バイトも数えられません。何が数えられて何が数えられないのかを実測値で整理します。
WordPress の WXR エクスポートに画像が含まれない
WordPress のエクスポート機能が吐く WXR ファイルに画像のバイナリは含まれず、旧サーバーを解約すると原本ごと消えます。移行直後は完了に見えてしまう理由と事前チェックリスト、そして手遅れだった場合に Wayback Machine から 36 件の画像を実際に回収した手順・落とし穴・法とマナーの線引きをまとめます。
Google 検索結果の favicon が地球儀のままになる原因は robots.txt
favicon はブラウザのタブに表示されているのに、Google 検索結果ではデフォルトの地球儀アイコンのまま — 原因は robots.txt が favicon の配信 URL をブロックしていたことでした。ヘッドレス CMS やサイトビルダーの構成で構造的に起きるこの問題の診断手順と、静的 /favicon.ico 併設による対策をまとめます。
WordPress 移行後に記事内の画像が 404 になるときの対処
WordPress をヘッドレス CMS へ移行したあと、本文が旧 /wp-content/uploads/ を参照したままで記事内の画像が 404 になる問題。404 の 9 割超は実体が移行済みで URL だけが古いので、本文を書き換えずキャッチオール動的ルート 1 本でファイル名からメディアを引いて 301 する設計と、WordPress 命名（-WxH サムネイル・-e 編集版）や .gitignore の落とし穴をまとめます。
D1 の無駄なクエリを削ったらクエリ数が増えた原因
エッジ SSR（Cloudflare Workers + D1）ではレイテンシの支配項は CPU ではなく DB への往復回数です。明らかに無駄なクエリを削ったら本数が 19→22 に増えた原因であるリクエスト内キャッシュの重複排除と、推測で書き換えず「表示が変わっていないこと」を HTML のバイト一致で証明しながら最適化するウォーム A/B 計測の手順をまとめます。
Tailwind v3 で node_modules の CSS が @layer エラーになる原因
Tailwind v3 を PostCSS 経由で入れると、node_modules のビルド済み CSS まで処理対象になり、ネイティブの @layer を使う標準準拠の第三者 CSS がエラーになります。管理画面が 500 になった実例から、@tailwindcss/vite（v4）移行による解決と、実際に必要だったクラス名の書き換えをまとめます。
日本語 URL の 301 リダイレクトだけが効かない原因
WordPress 移行のリダイレクトで、英語スラッグは動くのに日本語スラッグだけ 404 になる原因は percent-encoding の大文字・小文字でした。ブラウザは大文字（RFC 3986 の正規形）で送り、WordPress は小文字で保存する。URL API が既エンコード文字列を正規化しない仕様と、decode→encode による正規化をまとめます。
独自ドメイン移行でパスキーのログインができなくなる原因
workers.dev などのステージング URL で登録したパスキーは、独自ドメインへ切り替えた瞬間に使えなくなります。WebAuthn の RP ID 束縛という仕様の話と、締め出されたときの復旧経路（メール配送の Slack すげ替え）、切り替え前にやるべき手順をまとめます。
Slack のリンクプレビューがワンタイムのログインリンクを消費する
マジックリンクを Slack Incoming Webhook に流すと、プレビュー生成クローラーが人間より先にリンクを GET してワンタイムトークンを消費し、invalid link になります。unfurl_links / unfurl_media の無効化による対策と、「GET でトークンを消費する」設計自体の問題点をまとめます。
EmDash の definePlugin を外すとビルドは通るのに機能が止まる
Vite の defineConfig のような define* ヘルパーを「型のための identity 関数」と思い込んでインライン化すると、実行時の capability 正規化がスキップされ、ビルド・型チェック・デプロイが全部成功したまま通知機能だけがエラーを出さずに止まる——その機構と、静的チェックで検出できない理由、対策をまとめます。
Astro で Webhook の署名検証に生ボディを渡す方法
Slack や Stripe の Webhook 署名検証は「生のリクエストボディ」に対する HMAC のため、フレームワークが body を先にパースすると検証が通らなくなります。原因と、Astro / Cloudflare Workers での生ボディ取得（request.text / clone）方法をまとめます。
WordPressに限界を感じたエンジニアが、EmDashにベットする理由
PHPベースの技術スタック、億劫な管理画面、サーバー保守のコスト。WordPressへの不満を抱えるエンジニアに向けて、CloudflareがAIエージェント中心に設計した新CMS「EmDash」への移行理由と、移行で同時に回収できる4つの価値を解説する。
Headless CMSとしてのWordPress
Headless CMSとしてのWordPressの強みは2026年も有効です。一方で私はこのブログをWordPressからAstroベースの構成に移行しました。ヘッドレス化する・しない・WordPressから出る、それぞれの判断軸を実体験から整理します。