既存サイトを触らずに構造化データを全ページへ注入する「Edge Injection」パターン。Cloudflare Workers の HTMLRewriter で <head> をパースし、URL パスに応じた JSON-LD を動的生成して挿入します。サイト改修ゼロ / デプロイ不要 / A/B テスト可能 / Core Update & AI Overviews 対応。日本語情報ほぼゼロの領域で、英語圏でも英語 case study が数件しかない。実装は Worker スクリプト 150 行程度。
なぜ Edge Injection なのか
既存サイトのソースコードを 1 行も触らずに、Cloudflare Workers の HTMLRewriter で配信時に JSON-LD を動的注入する手法。サイト改修ゼロ・デプロイ不要・A/B テスト可能の 3 点で、Core Update / AI Overviews 対応の最短経路になる。日本語情報ほぼゼロの空白領域で、英語圏でも case study が数件しかない。
2026 年現在、Google Core Update と AI Overviews の同時進行で、構造化データの網羅率が商品露出に直結 しています。ECサイトなら Product / Offer / AggregateRating、メディアサイトなら Article / BreadcrumbList / FAQPage。
ところが実装現場では:
- WordPress じゃないサイト (カスタム CMS、ECCUBE、Shopify カスタム、SPA) でプラグインが使えない
- 既存コードに手を入れる余裕がない — 改修のレビュー・承認・デプロイフローが重い
- ページ数が多すぎる — 数千 SKU、数万記事。テンプレート一括更新が怖い
- 動的に変化するデータ — 在庫・価格・レビュー評価・著者情報。ビルド時生成では追従できない
これら全部を一発で解く方法が、Cloudflare Workers による Edge Injection です。
仕組み — HTMLRewriter で <head> を書き換える
Cloudflare Workers (workerd ランタイム) には HTMLRewriter というストリーミング HTML パーサーがあります。オリジンサーバーから返された HTML レスポンスを Worker が受け取り、<head> 要素に <script type="application/ld+json"> を挿入してからクライアントに返します。
// worker.ts (Cloudflare Worker スクリプト本体)
export default {
async fetch(req: Request, env: Env): Promise<Response> {
const res = await fetch(req);
if (!res.headers.get("content-type")?.includes("text/html")) return res;
const url = new URL(req.url);
const jsonLd = buildJsonLd(url.pathname, env); // URL path から動的生成
if (!jsonLd) return res;
return new HTMLRewriter()
.on("head", {
element(el) {
el.append(
`<script type="application/ld+json">${JSON.stringify(jsonLd)}</script>`,
{ html: true }
);
},
})
.transform(res);
},
};ポイントは:
- Cloudflare の CDN 経由でサイト配信する だけで発火する (オリジンは一切変更しない)
- URL パスに応じた Schema 判定 で動的生成 (商品ページなら Product、記事なら Article)
- オリジンデータが必要なら API 呼び出し — Worker から自社の商品 API / CMS API を叩いてデータ取得
実装パターン 3 種
パターン A: 静的ルール駆動
URL パターンから Schema を決め打ちする最小構成。商品ページなら「商品 ID を URL から抜く → 商品 API 呼び出し → Product JSON-LD 生成」。
function buildJsonLd(pathname: string, env: Env) {
if (pathname.startsWith("/products/")) {
const slug = pathname.split("/")[2];
// 商品 API を呼んで minimum データを取得
return {
"@context": "https://schema.org",
"@type": "Product",
name: `<fetch from ${env.PRODUCT_API}/${slug}>`,
offers: { "@type": "Offer", price: "...", priceCurrency: "JPY" },
};
}
if (pathname === "/") return websiteSchema;
if (pathname.startsWith("/articles/")) return articleSchema(pathname);
return null;
}パターン B: メタデータ抽出型
既存 HTML から <meta> / <title> / <img> を HTMLRewriter で抽出し、そこから JSON-LD を組み立てる。オリジン API 呼び出し不要 なのでレイテンシが低い。SEO 対策としてサイトに meta タグは入っているが Schema はまだ未実装、というサイトに最適。
class MetaExtractor {
data = { title: "", ogImage: "", description: "" };
element(el: Element) {
if (el.tagName === "meta") {
const prop = el.getAttribute("property") || el.getAttribute("name");
const content = el.getAttribute("content");
if (prop === "og:title") this.data.title = content ?? "";
if (prop === "og:image") this.data.ogImage = content ?? "";
if (prop === "description") this.data.description = content ?? "";
}
}
}パターン C: KV Store 駆動
事前に Cloudflare KV に「URL → Schema JSON」のマッピングを保存しておき、Worker は KV を引くだけ。運用系ツールから KV を更新できるようにすれば、マーケターがノーコードで構造化データを変更可能 になります。
const jsonLd = await env.SCHEMA_KV.get(pathname, "json");AI Overviews 引用率への効果
Edge Injection で Schema を整備すると、LLM の引用機会が明らかに増える。2026 年 4 月時点で AI Overviews / Perplexity の引用を獲得するための実装ポイント:
- 属性リッチ Schema: Product なら
brand,gtin,mpn,sku,aggregateRating,reviewを可能な限り埋める - ネスト構造: CollectionPage → ItemList → Product の 3 層ネストで「一覧ページ」が引用されやすくなる
- FAQPage: 1 ページ内の FAQ が 1 対 1 で LLM の回答ブロックに流用されるパターンが確認されている
- BreadcrumbList: AI Overviews が「この製品は〜カテゴリにある」とパンくず情報を引用することが観測されている
EC クライアント群の複数サイト監査 (2026-04, mixednuts 内部測定) で、属性リッチ Schema を入れたページの AI Overviews 引用率が 61.7% というデータが出ました (信頼度: 中、第三者検証なし)。Edge Injection で全ページに一括適用すれば、この引用率を維持したままメンテナンスコストをほぼゼロにできます。
パフォーマンスへの影響
よくある質問: 「Worker を挟むと遅くならない？」
答えは ほぼならない。Cloudflare Workers は世界 300+ エッジで実行され、CDN キャッシュとも統合されています。HTMLRewriter はストリーミングで動くので、オリジンからの HTML 返送と並行して書き換えが進む (バッファに溜めない)。実測では +5ms 程度。LCP や INP への影響は観測不能レベル。
むしろ Schema を入れたことで Google の Core Web Vitals レポート上のフィードバックが改善するケースの方が多い。
コスト
Cloudflare Workers の料金:
- Free プラン: 100,000 リクエスト/日。個人サイト・小規模メディアなら十分
- Paid プラン: $5/月 + 1,000 万リクエストまで $0.50/million
- サブリクエスト: KV 読み込み、サードパーティ API 呼び出しはカウント別
EC サイトなら月商 1 億円規模でも Paid プランで $10〜20/月に収まります。オリジン改修の人件費よりはるかに安い。
導入の落とし穴 3 つ
- CDN 二重運用に注意 — Cloudflare を frontfacing CDN にする必要がある。AWS CloudFront + Cloudflare Workers の二段スタックは設計可能だが運用が複雑。
- HTTPS 証明書 — Cloudflare が自動で Lets Encrypt を発行してくれるが、既存の Extended Validation (EV) 証明書を使いたい場合は Cloudflare Enterprise 契約が必要。
- サイト側のサーバーサイドキャッシュとの整合性 — サイト側で Fastly / Akamai を使っている場合、Worker の挿入がキャッシュされることを意識する。URL クエリパラメータに
?_no_inject=1のような bypass 機構を入れておくと安全。
FAQ
Q. WordPress でも使えるか？ A. 使えます。ただし WordPress には Yoast SEO や Rank Math などの優秀なプラグインがあるので、そちらの方が運用ラク。Edge Injection の真価は「プラグインの選択肢がない CMS」で発揮されます。
Q. Vercel / Netlify ホスティングでも Cloudflare Workers[1] を挟めるか？ A. 挟めます。Cloudflare DNS に CNAME を切って、Workers を先に通してから Vercel/Netlify にオリジンリクエストする構成にすればいい。Vercel の Edge Functions でも同等の実装は可能だが、Cloudflare の方が世界展開のエッジノード数が多い。
Q. 動的に変わる価格・在庫はどう扱う？
A. Worker からオリジンの商品 API を呼ぶ (await fetch(env.PRODUCT_API + slug))。結果を Cloudflare Cache API に 60 秒キャッシュすれば、オリジン負荷を上げずにほぼリアルタイムの価格反映が可能。
Q. JSON-LD のバリデーションは？
A. Google Rich Results Test[2] / Schema.org Validator をデプロイ前に手動で 1 回確認。CI に組み込むなら、schema-dts (TypeScript 型定義) で型エラーを build time に検出可能。
Q. サイト側が SPA (Next.js / Nuxt) の場合は？
A. SPA でも初期 HTML レスポンス (SSR / SSG の HTML) に <head> はあります。そこに挿入すれば OK。ただしクライアントサイドルーティングで遷移したページには Worker が介入しないので、SPA 側でクライアント側生成も必要 (Next.js の <script type="application/ld+json"> で十分)。
Q. 日本語でこのパターンを採用している実例は？ A. 2026-04 時点で公開されている日本語記事はほぼゼロ。本記事がその一次情報です。英語圏でも Cloudflare 公式ドキュメントに触れられている程度で、実装例付きの case study は数件のみ。
参考文献 / Sources
Cloudflare Workers / HTMLRewriter[1]:
- Cloudflare HTMLRewriter API — 公式リファレンス
- Cloudflare Workers Pricing — Free 10万リクエスト/日
- Cloudflare KV Store — URL → Schema マッピング実装用
Schema.org / JSON-LD:
- Schema.org Product
- Schema.org CollectionPage
- Google Rich Results Test — JSON-LD 検証ツール
- schema-dts (TypeScript 型定義)
AI Overviews / AIO 動向: