synon.co.jp を STUDIO から
Cloudflare Workers へ移行する

0エグゼクティブサマリ

結論を3行で

実測した現状（2026-08-19 時点）

synon.co.jp   NS     ns1〜ns5.xserver.jp        ← Cloudflare ではない（前提条件に直結）
synon.co.jp   A      203.0.113.10            ← STUDIO（Google Cloud の共有IP）
*.synon.co.jp A      203.0.113.10            ← ワイルドカードが存在
www           A      198.51.100.10            ← Xserver。apex と別基盤を指している
synon.co.jp   MX     Google Workspace（5レコード）
CAA / AAAA / DS      なし

実測して気づいた4つのこと

この移行で同時に解決すること

着手前に必ず理解しておくこと

やってはいけないこと

1実測した現状

1.1 DNS レコード

$ dig +short NS synon.co.jp
ns1.xserver.jp.  ns2.xserver.jp.  ns3.xserver.jp.  ns4.xserver.jp.  ns5.xserver.jp.

$ dig +short A synon.co.jp
203.0.113.10                      # STUDIO（Google Cloud の共有IP）

$ dig +short A www.synon.co.jp
198.51.100.10                      # Xserver ← apex と別基盤

$ dig +short A zzq7x9-none.synon.co.jp
203.0.113.10                      # ワイルドカードが効いている

$ dig +short MX synon.co.jp
1 ASPMX.L.GOOGLE.COM.
5 ALT1.ASPMX.L.GOOGLE.COM.    5 ALT2.ASPMX.L.GOOGLE.COM.
10 ALT3.ASPMX.L.GOOGLE.COM.   10 ALT4.ASPMX.L.GOOGLE.COM.

$ dig +short CAA synon.co.jp        # なし
$ dig +short AAAA synon.co.jp       # なし

1.2 ページ構成（全20URL）

sitemap.xml
├── sitemap-static.xml                                   … 16件
├── sitemap-dynamic/sitemap-dynamic-topics-s--c-slug.xml … 2件
└── sitemap-dynamic/sitemap-dynamic-posts-s--c-slug.xml  … 2件

1.3 サイトの実装状況

2移行先の選定 — Workers を選ぶ理由を正しく言い直す

2.1 まず訂正：WebMCP はホスティング先を選びません

「サイトが WebMCP に対応しているので Workers にしたい」という理由付けは、技術的には成立しません。先に事実を確認します。

2.2 それでも Workers が正解である3つの理由

結論（Workers を選ぶ）は変えなくて構いません。理由を差し替えれば済みます。

2.3 Workers（Static Assets）と Pages の比較

2.4 【本命】リモート MCP サーバーを同居させる構成

wrangler.jsonc で両立させる書き方

{
  "name": "synon-corporate-site",
  "compatibility_date": "2026-08-19",
  "main": "./src/index.ts",
  "assets": {
    "directory": "./dist/",
    "binding": "ASSETS",
    "not_found_handling": "404-page",
    "html_handling": "auto-trailing-slash",
    "run_worker_first": ["/mcp", "/mcp/*"]   // このパスだけ Worker に流す
  }
}

run_worker_first にグロブ配列を指定すると、そのパスだけ Worker コードに流れ、それ以外はすべて静的アセットとして直接配信されます。* は深いマッチ、! プレフィックスで否定を書けます。

MCP サーバー側の最小実装

// src/index.ts
import { McpServer } from "@modelcontextprotocol/server";
import { createMcpHandler } from "agents/mcp/server";
import { z } from "zod";

function createServer() {
  const server = new McpServer({ name: "synon-site", version: "1.0.0" });
  server.registerTool(
    "list_services",
    { description: "シンオン株式会社が提供するサービスの一覧を返す", inputSchema: {} },
    async () => ({ content: [{ type: "text", text: "受託開発 / ..." }] })
  );
  return server;
}

const mcp = createMcpHandler(createServer);

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const url = new URL(request.url);
    if (url.pathname === "/mcp" || url.pathname.startsWith("/mcp/")) {
      return mcp(request, env, ctx);
    }
    return env.ASSETS.fetch(request);   // run_worker_first があれば通常ここには来ない
  },
};

2.5 WebMCP を実装する場合の実際

// ❌ 古い情報。ブログ記事に多い
navigator.modelContext.registerTool(...)

// ✅ 現行仕様
document.modelContext.registerTool(...)

素の HTML/CSS/JS への組み込み例（プログレッシブエンハンスメント）

// src/assets/js/webmcp.js
(function () {
  // 非対応ブラウザでは何もしない。通常のUIはそのまま機能する
  if (!document.modelContext || typeof document.modelContext.registerTool !== 'function') return;

  document.modelContext.registerTool({
    name: 'get_company_profile',
    description: 'シンオン株式会社の会社概要（所在地・設立・従業員数など）を返す',
    inputSchema: { type: 'object', properties: {} },
    execute: async () => ({
      content: [{ type: 'text', text: document.querySelector('#company-profile').innerText }]
    })
  });

  document.modelContext.registerTool({
    name: 'search_works',
    description: '開発実績をキーワードで検索する',
    inputSchema: {
      type: 'object',
      properties: { query: { type: 'string', description: '検索キーワード' } },
      required: ['query']
    },
    execute: async ({ query }) => {
      const hits = [...document.querySelectorAll('[data-work]')]
        .filter(el => el.innerText.includes(query))
        .map(el => el.innerText.trim());
      return { content: [{ type: 'text', text: hits.join('\n---\n') || '該当なし' }] };
    }
  });
})();

Chrome 公式ドキュメントによれば、標準の <form> 要素に属性で注釈を付ける「宣言的API」も用意されており、こちらは静的サイトと相性が良い方式です（正確な属性構文は Chrome の該当ドキュメントで要確認）。

3前提条件 — 先に DNS を Cloudflare へ移管する

3.1 これは選択肢ではなく必須条件です

3.2 synon.co.jp の DNS 移管が簡単な理由

3.3 移管と本移行の順序

W1  DNS 棚卸し・DKIM 退避・TTL を 300 秒へ
W2  Cloudflare ゾーン作成 → 全レコードをグレー雲で1:1再現 → 旧NSと突合
W2  NS 切替（apex A は 203.0.113.10 = STUDIO のまま・グレー雲）
    └ ここでは何も壊れない。STUDIO は今までどおり動く
W3  48時間の観察。メール送受信・サイト表示を確認
    ※ apex はグレー雲のまま。STUDIO 公式が「Cloudflare の DNS Proxy を無効に」
      と明記しているため、STUDIO を使い続ける間はオレンジ雲にしない
────────── ここまでが既存資料の Step 1 ──────────
W4〜 新サイトを GitHub で構築（本書 4章）
W6   Workers へデプロイ、プレビューURLで検証（本書 5〜6章）
W7   apex A を削除し、Workers のカスタムドメインへ切替（本書 7章）
W8   STUDIO を解約（本書 7.4節）

4リポジトリとサイトの再構築（素の HTML / CSS / JS）

4.1 ディレクトリ構成

synon-corporate-site/
├── .github/workflows/
│   ├── deploy.yml              # main への push → 本番デプロイ
│   └── preview.yml             # PR → プレビューデプロイ
├── src/
│   ├── pages/                  # 各ページの「中身だけ」を書く
│   │   ├── index.html
│   │   ├── about.html
│   │   ├── service.html
│   │   ├── development.html
│   │   ├── works-system.html
│   │   ├── work-app.html
│   │   ├── company-org.html
│   │   ├── topics.html
│   │   ├── contact.html
│   │   ├── privacy.html
│   │   ├── termsofuse.html
│   │   ├── topics/{dify,info}.html
│   │   └── posts/{zsFXXiMM,renew}.html
│   ├── partials/               # 共通パーツ
│   │   ├── head.html
│   │   ├── header.html
│   │   └── footer.html
│   ├── assets/
│   │   ├── css/{reset,style}.css
│   │   ├── js/{main,webmcp}.js
│   │   ├── img/                # STUDIO から回収した画像
│   │   └── fonts/
│   └── static/                 # そのままコピーされるもの
│       ├── robots.txt
│       ├── favicon.ico
│       ├── _headers            # Cloudflare のレスポンスヘッダ設定
│       └── _redirects          # Cloudflare のリダイレクト設定
├── scripts/
│   ├── build.mjs               # partials を差し込んで dist/ を作る（約60行）
│   └── sitemap.mjs             # sitemap.xml を生成
├── dist/                       # ビルド成果物（.gitignore する）
├── src/index.ts                # 任意：MCP サーバー等（2.4節）
├── wrangler.jsonc
├── package.json
└── README.md

4.2 STUDIO からデザインとアセットを持ち出す — 何ができて何ができないか

4.2.1 前提となる事実

4.2.2 スクレイピングで持ち出すことの是非

4.2.3 推奨する進め方 — 「著作物」と「生成物」を分けて考える

実務的な手順

/* src/assets/css/style.css 冒頭 */
:root {
  /* --- 実測した値をここに集約する --- */
  --color-text:      #1a1a1a;
  --color-bg:        #ffffff;
  --color-accent:    #0b5fff;   /* ← DevTools の Computed から拾った実際の値に置き換える */
  --color-muted:     #6b7280;

  --font-base: "Noto Sans JP", "Hiragino Kaku Gothic ProN", "Yu Gothic UI", Meiryo, sans-serif;
  --fs-h1: clamp(28px, 5vw, 48px);
  --fs-h2: clamp(22px, 3.5vw, 32px);
  --fs-body: 16px;
  --lh-body: 1.9;               /* 日本語は 1.8〜2.0 が読みやすい */

  --space-1: 8px;   --space-2: 16px;  --space-3: 24px;
  --space-4: 40px;  --space-5: 64px;  --space-6: 96px;

  --container: 1080px;
  --bp-tablet: 768px;
  --bp-desktop: 1024px;
}

4.2.4 日本語サイトでの注意点

4.3 20ページの棚卸し — 作り直す前に必ずやる

4.4 共通パーツをどうするか — 「素の HTML」の唯一の弱点

20ページに同じヘッダー・フッターをコピペで20回書くと、メニューを1つ変えるのに20ファイルを直すことになります。これが素の HTML の唯一かつ最大の弱点です。

案B の実装（scripts/build.mjs・依存パッケージなし）

// scripts/build.mjs
// src/pages/**/*.html を読み、<!--#include partial="xxx"--> を展開して dist/ へ出力する。
// src/assets, src/static はそのままコピーする。依存パッケージなし（Node.js 20+）。
import { readFile, writeFile, mkdir, readdir, cp, rm } from 'node:fs/promises';
import { join, dirname, relative } from 'node:path';

const SRC = 'src';
const OUT = 'dist';

/** ディレクトリを再帰的に走査して .html を列挙 */
async function walk(dir) {
  const out = [];
  for (const e of await readdir(dir, { withFileTypes: true })) {
    const p = join(dir, e.name);
    if (e.isDirectory()) out.push(...await walk(p));
    else if (e.name.endsWith('.html')) out.push(p);
  }
  return out;
}

/** partials を読み込んでおく */
async function loadPartials() {
  const dir = join(SRC, 'partials');
  const map = {};
  for (const e of await readdir(dir)) {
    map[e.replace(/\.html$/, '')] = await readFile(join(dir, e), 'utf8');
  }
  return map;
}

/** <!--#include partial="header"--> を展開（入れ子も許可） */
function expand(html, partials, depth = 0) {
  if (depth > 3) throw new Error('include の入れ子が深すぎます');
  return html.replace(/<!--#include\s+partial="([\w-]+)"\s*-->/g, (_, name) => {
    const p = partials[name];
    if (p === undefined) throw new Error(`partial が見つかりません: ${name}`);
    return expand(p, partials, depth + 1);
  });
}

/** {{ title }} の変数展開（front matter 相当を HTML コメントで書く） */
function applyVars(html) {
  const m = html.match(/^<!--\s*meta\s*([\s\S]*?)-->\s*/);
  const vars = {};
  if (m) {
    for (const line of m[1].trim().split('\n')) {
      const i = line.indexOf(':');
      if (i > 0) vars[line.slice(0, i).trim()] = line.slice(i + 1).trim();
    }
    html = html.slice(m[0].length);
  }
  return html.replace(/\{\{\s*(\w+)\s*\}\}/g, (_, k) => vars[k] ?? '');
}

await rm(OUT, { recursive: true, force: true });
await mkdir(OUT, { recursive: true });

const partials = await loadPartials();
const pages = await walk(join(SRC, 'pages'));

for (const file of pages) {
  const raw = await readFile(file, 'utf8');
  const html = applyVars(expand(raw, partials));
  const rel = relative(join(SRC, 'pages'), file);
  const dest = join(OUT, rel);
  await mkdir(dirname(dest), { recursive: true });
  await writeFile(dest, html, 'utf8');
  console.log('build:', rel);
}

await cp(join(SRC, 'assets'), join(OUT, 'assets'), { recursive: true });
await cp(join(SRC, 'static'), OUT, { recursive: true });

console.log(`\n${pages.length} pages built into ${OUT}/`);

ページ側の書き方

<!-- src/pages/about.html -->
<!-- meta
title: 会社概要 | シンオン株式会社
description: シンオン株式会社の会社概要です。
path: /about
-->
<!DOCTYPE html>
<html lang="ja">
<head>
<!--#include partial="head"-->
</head>
<body>
<!--#include partial="header"-->

<main>
  <h1>会社概要</h1>
  <!-- ここだけ書けばよい -->
</main>

<!--#include partial="footer"-->
</body>
</html>

<!-- src/partials/head.html -->
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>{{ title }}</title>
<meta name="description" content="{{ description }}">
<link rel="canonical" href="https://synon.co.jp{{ path }}">
<meta property="og:title" content="{{ title }}">
<meta property="og:description" content="{{ description }}">
<meta property="og:url" content="https://synon.co.jp{{ path }}">
<meta property="og:type" content="website">
<meta property="og:image" content="https://synon.co.jp/assets/img/ogp.png">
<meta name="twitter:card" content="summary_large_image">
<link rel="icon" href="/favicon.ico">
<link rel="stylesheet" href="/assets/css/reset.css">
<link rel="stylesheet" href="/assets/css/style.css">

// package.json
{
  "name": "synon-corporate-site",
  "private": true,
  "type": "module",
  "scripts": {
    "build":  "node scripts/build.mjs && node scripts/sitemap.mjs",
    "dev":    "npm run build && wrangler dev",
    "deploy": "npm run build && wrangler deploy"
  },
  "devDependencies": { "wrangler": "^4.0.0" }
}

4.5 CMS コンテンツ4件の扱い

「CMS 不要・開発者が git push」という方針は、4件なら成立します。そのまま静的 HTML として書き起こしてください。

一覧ページ（/topics）も記事4件なら手書きで構いませんが、記事を追加したときに一覧の更新を忘れるのがよくある事故なので、ビルドスクリプトで自動生成しておくと安全です（src/pages/topics/ 配下の HTML を列挙して一覧を組み立てる、20行程度の追加）。

4.6 sitemap.xml / robots.txt / OGP / 構造化データ

sitemap.xml を生成する

現行 robots.txt が Sitemap: https://synon.co.jp/sitemap.xml を指しているので、同じパスで出す必要があります。ただし STUDIO のようなインデックス形式にする必要はなく、単一ファイルで構いません。

// scripts/sitemap.mjs
import { readdir, writeFile } from 'node:fs/promises';
import { join } from 'node:path';

const SITE = 'https://synon.co.jp';
const OUT = 'dist';

async function walk(dir, base = '') {
  const out = [];
  for (const e of await readdir(join(OUT, dir), { withFileTypes: true })) {
    if (e.isDirectory()) {
      if (['assets'].includes(e.name)) continue;
      out.push(...await walk(join(dir, e.name), `${base}/${e.name}`));
    } else if (e.name.endsWith('.html')) {
      const slug = e.name === 'index.html' ? '' : '/' + e.name.replace(/\.html$/, '');
      out.push(`${base}${slug}` || '/');
    }
  }
  return out;
}

const urls = (await walk('')).sort();
const today = process.env.BUILD_DATE ?? new Date().toISOString().slice(0, 10);

const xml = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${urls.map(u => `  <url>
    <loc>${SITE}${u}</loc>
    <lastmod>${today}</lastmod>
  </url>`).join('\n')}
</urlset>
`;

await writeFile(join(OUT, 'sitemap.xml'), xml, 'utf8');
console.log(`sitemap: ${urls.length} urls`);

robots.txt

# src/static/robots.txt
User-agent: *
Allow: /

Sitemap: https://synon.co.jp/sitemap.xml

構造化データ（JSON-LD）— 新サイトで追加する価値あり

実測では現行サイトに構造化データが確認できませんでした。移行のついでに入れておくと、検索結果でのブランド表示に効きます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "シンオン株式会社",
  "alternateName": "Synon Inc.",
  "url": "https://synon.co.jp/",
  "logo": "https://synon.co.jp/assets/img/logo.png",
  "description": "ビジネスにおける時短サービスを提供",
  "address": {
    "@type": "PostalAddress",
    "addressCountry": "JP",
    "addressRegion": "大阪府"
  },
  "sameAs": []
}
</script>

OGP 画像

4.7 /contact フォームの扱い（参考 — 本書のスコープ外だが必須事項）

Turnstile を必ず併用してください。既存資料（synon.co.jp 版 Step 5）で「社内標準部品」として整備済みのものが、そのまま使えます。

// src/index.ts に追記（run_worker_first に "/api/*" を追加すること）
if (url.pathname === '/api/contact' && request.method === 'POST') {
  const form = await request.formData();

  // 1. Turnstile 検証（既存資料 Step 5.4 と同じ）
  const verify = await fetch('https://challenges.cloudflare.com/turnstile/v0/siteverify', {
    method: 'POST',
    body: new URLSearchParams({
      secret: env.TURNSTILE_SECRET,
      response: String(form.get('cf-turnstile-response') ?? ''),
      remoteip: request.headers.get('CF-Connecting-IP') ?? '',
    }),
  }).then(r => r.json<any>());

  if (!verify.success || verify.hostname !== 'synon.co.jp' || verify.action !== 'contact') {
    return new Response('Bad Request', { status: 400 });
  }

  // 2. メール送信（Resend の例）
  await fetch('https://api.resend.com/emails', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${env.RESEND_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      from: 'noreply@synon.co.jp',
      to: 'info@synon.co.jp',
      subject: `【お問い合わせ】${form.get('name')} 様`,
      text: [...form.entries()].map(([k, v]) => `${k}: ${v}`).join('\n'),
    }),
  });

  return Response.redirect('https://synon.co.jp/contact/thanks', 303);
}

5Cloudflare Workers の設定

5.1 wrangler.jsonc（完全版）

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "synon-corporate-site",
  "compatibility_date": "2026-08-19",

  // 静的アセットのみの構成では "main" は不要。
  // MCP サーバーやフォーム API を足す段階でコメントを外す。
  // "main": "./src/index.ts",

  "assets": {
    "directory": "./dist/",

    // Worker コードから env.ASSETS.fetch() でアセットを読むための binding
    "binding": "ASSETS",

    // 一致するアセットが無いとき、最も近い 404.html を 404 ステータスで返す。
    // 取りうる値: "none"(既定) / "404-page" / "single-page-application"
    "not_found_handling": "404-page",

    // 個別ファイル(foo.html)はスラッシュなし、フォルダ配下はスラッシュ付きで配信。
    // 取りうる値: "auto-trailing-slash"(既定) / "force-trailing-slash"
    //           / "drop-trailing-slash" / "none"
    "html_handling": "auto-trailing-slash"

    // MCP サーバーやフォーム API を足す段階で有効化する。
    // "run_worker_first": ["/mcp", "/mcp/*", "/api/*"]
  },

  "observability": { "enabled": true }
}

5.2 assets 各オプションの意味

not_found_handling

dist/404.html を必ず用意してください。用意しないと存在しない URL で素っ気ない画面が出ます。

html_handling

run_worker_first

"run_worker_first": ["/mcp", "/mcp/*", "/api/*", "!/api/docs/*"]

• true を指定すると全リクエストが Worker を経由します（課金対象の実行回数が増えるので避ける）
• グロブ配列で指定するのが正解。* は深いマッチ、! プレフィックスで除外
• 指定しなければ静的アセットが Worker より先に配信される（＝この構成のデフォルト）

5.3 _headers と _redirects

どちらも静的アセットディレクトリ直下（＝ dist/ 直下）に置きます。本構成では src/static/ に置いておけばビルド時にコピーされます。

src/static/_headers

# ============================================
# 全ページ共通のセキュリティヘッダ
# ============================================
/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: geolocation=(), microphone=(), camera=()
  X-Frame-Options: SAMEORIGIN

# ============================================
# 静的アセットは長期キャッシュ
# ============================================
/assets/*
  Cache-Control: public, max-age=31536000, immutable

# ============================================
# HTML は短めに（更新をすぐ反映させたい）
# ============================================
/*.html
  Cache-Control: public, max-age=0, must-revalidate

src/static/_redirects

# 形式:  [source]  [destination]  [code]
# code を省略すると 302。恒久移転は必ず 301 を明示すること。

# --- STUDIO 時代の重複ページを統合 ---
/1              /                 301
/service-1      /service          301
/development-1  /development      301
/work-1         /works-system     301
/company-1      /about            301

# --- 記事系を1本化する場合 ---
/posts/renew      /topics/renew      301
/posts/zsFXXiMM   /topics/zsFXXiMM   301

# --- STUDIO 固有のサイトマップURL（Search Console 登録済みの可能性）---
/sitemap-static.xml    /sitemap.xml  301
/sitemap-dynamic/*     /sitemap.xml  301

5.4 カスタムドメインの設定

前提：synon.co.jp が Cloudflare 上のアクティブなゾーンであること（3章）。

5.5 ローカル開発

npm ci                # 依存インストール
npm run dev           # ビルド + ローカルサーバ（http://localhost:8787）
npm run build         # ビルドのみ
npx wrangler deploy   # 手動デプロイ（通常は GitHub Actions に任せる）

# デプロイ前のローカル確認
npx linkinator dist --recurse --skip "^https://"   # リンク切れ
npx html-validate "dist/**/*.html"                 # HTML 構文
find dist -type f | sort                           # 生成物の目視

5.6 Free プランの制限（本件で意識すべきもの）

6GitHub Actions で自動デプロイ

6.1 全体像

6.2 Cloudflare API トークンの作成（最小権限）

Cloudflare ダッシュボード
  → 右上のアカウントアイコン > My Profile > API Tokens
  → Create Token > Custom token > Get started

【Permissions】
  Account │ Workers Scripts       │ Edit    ← 必須
  Account │ Account Settings      │ Read    ← 推奨
  Zone    │ Workers Routes        │ Edit    ← CI からルートを操作する場合のみ

【Account Resources】
  Include │ <対象アカウント>

【Zone Resources】
  Include │ Specific zone │ synon.co.jp     ← 全ゾーンにしない

【Client IP Address Filtering】
  空欄のまま                                 ← GitHub-hosted runner は IP が変動するため

【TTL】
  開始日〜終了日を設定（推奨: 1年）           ← 期限切れ日をカレンダーに登録すること

Account ID の取得：クイック検索（Cmd/Ctrl + K）で「Copy account ID」／ Compute (Workers) セクションの「Account Details」／ 任意のドメインの Overview ページ下部「API」セクション。

6.3 GitHub Secrets と Environments

GitHub リポジトリ > Settings > Environments > New environment

【production】
  Secrets:
    CLOUDFLARE_API_TOKEN   = <6.2 で作ったトークン>
    CLOUDFLARE_ACCOUNT_ID  = <Account ID>
  Protection rules:
    ☑ Required reviewers        … 1〜2名（本番デプロイの承認者）
    ☑ Deployment branches       … Selected branches → main のみ
    □ Wait timer                … 不要

【preview】
  Secrets:
    CLOUDFLARE_API_TOKEN   = <同じ、または別トークン>
    CLOUDFLARE_ACCOUNT_ID  = <Account ID>
  Protection rules:
    （なし。PR ごとに自動デプロイさせる）

6.4 本番デプロイ用ワークフロー（完全版）

# .github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [main]
  workflow_dispatch:          # 手動実行も可能にしておく

# 同時実行を防ぐ。本番は進行中のデプロイをキャンセルしない
concurrency:
  group: deploy-production
  cancel-in-progress: false

permissions:
  contents: read

jobs:
  # ---------- 1. ビルドと検証 ----------
  build:
    name: Build & Verify
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Build
        run: npm run build

      - name: Validate HTML
        run: npx --yes html-validate "dist/**/*.html"
        continue-on-error: true     # 最初は警告のみ。安定したら外す

      - name: Check for broken internal links
        run: npx --yes linkinator dist --recurse --skip "^https?://"
        continue-on-error: true

      - name: Verify required files exist
        run: |
          set -e
          for f in dist/index.html dist/404.html dist/robots.txt dist/sitemap.xml; do
            [ -f "$f" ] || { echo "::error::missing $f"; exit 1; }
          done
          echo "file count: $(find dist -type f | wc -l)"

      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/
          retention-days: 7

  # ---------- 2. デプロイ ----------
  deploy:
    name: Deploy
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://synon.co.jp/
    permissions:
      contents: read
    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Download build artifact
        uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist/

      - name: Deploy to Cloudflare Workers
        id: deploy
        uses: cloudflare/wrangler-action@v4
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: deploy

      - name: Smoke test
        run: |
          set -e
          sleep 10
          for path in / /about /service /topics /contact /sitemap.xml /robots.txt; do
            code=$(curl -sS -o /dev/null -w '%{http_code}' "https://synon.co.jp${path}")
            echo "${path} → ${code}"
            [ "$code" = "200" ] || { echo "::error::${path} returned ${code}"; exit 1; }
          done
          # 404 が正しく 404 を返すこと
          code=$(curl -sS -o /dev/null -w '%{http_code}' "https://synon.co.jp/zzq7x9-nonexistent")
          [ "$code" = "404" ] || { echo "::error::404 handling broken (got ${code})"; exit 1; }

      - name: Rollback on smoke test failure
        if: failure()
        uses: cloudflare/wrangler-action@v4
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: rollback --message "CI: smoke test failed, auto rollback"

6.5 プレビュー用ワークフロー（完全版）

# .github/workflows/preview.yml
name: Deploy Preview

on:
  pull_request:
    types: [opened, synchronize, reopened]

concurrency:
  group: preview-${{ github.event.pull_request.number }}
  cancel-in-progress: true      # PR は最新のみ有効

permissions:
  contents: read
  pull-requests: write

jobs:
  preview:
    name: Preview
    # フォークからの PR ではシークレットが渡らないためスキップする
    if: github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-latest
    environment:
      name: preview
    steps:
      - uses: actions/checkout@v6

      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: npm

      - run: npm ci
      - run: npm run build

      - name: Upload preview version
        id: preview
        uses: cloudflare/wrangler-action@v4
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: versions upload --preview-alias pr-${{ github.event.pull_request.number }}

      - name: Comment preview URL
        uses: actions/github-script@v7
        with:
          script: |
            const alias = `pr-${context.payload.pull_request.number}`;
            const body = [
              '### 🔍 プレビューをデプロイしました',
              '',
              `**Preview alias:** \`${alias}\``,
              '',
              '```',
              `${{ steps.preview.outputs.command-output }}`.trim().slice(0, 1500),
              '```',
              '',
              '<sub>上のログの Preview URL を開いて確認してください。push のたびに更新されます。</sub>',
            ].join('\n');

            const { data: comments } = await github.rest.issues.listComments({
              owner: context.repo.owner, repo: context.repo.repo,
              issue_number: context.issue.number,
            });
            const existing = comments.find(c =>
              c.user.type === 'Bot' && c.body.includes('プレビューをデプロイしました'));

            if (existing) {
              await github.rest.issues.updateComment({
                owner: context.repo.owner, repo: context.repo.repo,
                comment_id: existing.id, body,
              });
            } else {
              await github.rest.issues.createComment({
                owner: context.repo.owner, repo: context.repo.repo,
                issue_number: context.issue.number, body,
              });
            }

6.6 セキュリティ上の必須事項

# ❌ タグは移動可能
- uses: cloudflare/wrangler-action@v4

# ✅ フルレングスのコミットSHAで固定し、コメントでバージョンを残す
- uses: cloudflare/wrangler-action@0123456789abcdef0123456789abcdef01234567  # v4.0.0

# SHA の調べ方
git ls-remote https://github.com/cloudflare/wrangler-action refs/tags/v4.0.0

6.7 なぜ Workers Builds（Cloudflare の Git 連携）ではなく GitHub Actions か

7DNS 切替とロールバック

7.1 切替前チェックリスト

すべてにチェックが付くまで切り替えないでください。

新サイト側

• 20URL の棚卸しが完了し、「残す / 統合 / 廃止」が確定している（4.3節）
• プレビューURL で全ページを目視確認した（PC / タブレット / スマホ）
• dist/404.html が存在し、存在しないURLで 404 が返る
• dist/robots.txt が存在し、sitemap.xml を指している
• dist/sitemap.xml が生成され、URL がすべて新サイトのもの
• _redirects に旧URLからの 301 が全件入っている（8.1節）
• OGP 画像が自社ドメイン配下にあり、SNS のプレビューで表示される
• 画像アセットをすべて STUDIO から回収済み（storage.googleapis.com への参照がゼロ）
• /contact フォームの代替が動作する（4.7節）
• Google Analytics 等の計測タグを移植した

Cloudflare 側 ／ DNS 側 ／ STUDIO 側

• synon.co.jp が Cloudflare 上のアクティブなゾーンである
• Worker がデプロイ済みで、*.workers.dev で正常に表示される
• 主要レコードの TTL を 300 秒に下げてある（48時間前までに）
• 現在の全レコードをエクスポート済み（切り戻し用）
• MX（Google Workspace の5レコード）に手を触れていない
• STUDIO は有料プランのまま維持している（解約していない）
• フォーム回答を CSV でエクスポート済み
• CMS 4件の本文を控えてある

7.2 切替手順

7.3 ロールバック

# #1 のコマンド
npx wrangler rollback                    # 対話モードで直近のバージョンから選ぶ
npx wrangler deployments list            # バージョン一覧
npx wrangler rollback <VERSION_ID>       # ID を直接指定

# #2 の手順（手順書として印刷しておくこと）
1. Cloudflare > Compute (Workers) > synon-corporate-site
   > Settings > Domains & Routes
   → synon.co.jp の Custom Domain を Remove

2. Cloudflare > synon.co.jp > DNS > Records > Add record
   Type    : A
   Name    : @
   IPv4    : 203.0.113.10
   Proxy   : DNS only（グレー雲）★必ずグレー
   TTL     : Auto

3. dig +short A synon.co.jp が 203.0.113.10 を返すまで待つ（数分）

4. https://synon.co.jp/ で STUDIO のサイトが表示されることを確認

7.4 STUDIO の解約タイミング 🔴

切替当日      apex を Workers へ。STUDIO は有料プランのまま維持
      ↓
+2週間        Search Console のクロールエラーがゼロ、
              Analytics のトラフィックが移行前と同水準であることを確認
      ↓
+1ヶ月        主要な検索キーワードでの順位が落ちていないことを確認
      ↓
解約          ここで初めて STUDIO を解約する

8SEO ・ 既存URL維持 ・ リダイレクト設計

8.1 URL マッピング表（実測20URL・全件）

この表を埋めることが、SEO を落とさないための唯一の作業です。

8.2 リダイレクトの実装手段 — 3つの選択肢

if (url.pathname === '/1') {
  return new Response('Gone', { status: 410 });
}

8.3 www とワイルドカードの扱い

【現状の問題】
synon.co.jp      A  203.0.113.10   ← STUDIO
www.synon.co.jp  A  198.51.100.10   ← Xserver（apex と別基盤！）
*.synon.co.jp    A  203.0.113.10   ← ワイルドカード

# www → apex の 301（Redirect Rules）
Cloudflare > synon.co.jp > Rules > Redirect Rules > Create rule

Rule name : www to apex
When incoming requests match:
  Field    : Hostname
  Operator : equals
  Value    : www.synon.co.jp

Then:
  Type              : Dynamic
  Expression        : concat("https://synon.co.jp", http.request.uri.path)
  Status code       : 301
  Preserve query string : ON

8.4 sitemap.xml と robots.txt

8.5 canonical・OGP・構造化データ

8.6 Search Console でやること

移行前

移行直後

移行後 1〜4週間

8.7 移行後の確認スクリプト

#!/bin/bash
# post-migration-check.sh ── 移行直後と、その後1週間毎日実行する
SITE=https://synon.co.jp

echo "=== 1. 主要ページが 200 を返すか ==="
for p in / /about /company-org /service /development /works-system /work-app \
         /topics /topics/dify /topics/info /contact /privacy /termsofuse; do
  printf "%-24s %s\n" "$p" "$(curl -sS -o /dev/null -w '%{http_code}' "$SITE$p")"
done

echo "=== 2. リダイレクトが 301 で正しい先へ飛ぶか ==="
for p in /1 /service-1 /development-1 /work-1 /company-1 \
         /posts/renew /posts/zsFXXiMM /sitemap-static.xml; do
  printf "%-24s %s → %s\n" "$p" \
    "$(curl -sS -o /dev/null -w '%{http_code}' "$SITE$p")" \
    "$(curl -sS -o /dev/null -w '%{redirect_url}' "$SITE$p")"
done

echo "=== 3. www が apex へ 301 するか ==="
curl -sS -o /dev/null -w '%{http_code} → %{redirect_url}\n' https://www.synon.co.jp/

echo "=== 4. 存在しないURLが 404 を返すか ==="
curl -sS -o /dev/null -w '%{http_code}\n' "$SITE/zzq7x9-nonexistent"

echo "=== 5. sitemap / robots ==="
curl -sS -o /dev/null -w 'sitemap.xml %{http_code}\n' "$SITE/sitemap.xml"
curl -sS -o /dev/null -w 'robots.txt  %{http_code}\n' "$SITE/robots.txt"

echo "=== 6. STUDIO への参照が残っていないか ==="
curl -sS "$SITE/" | grep -io "storage.googleapis.com\|studio.design" || echo "  参照なし: OK"

echo "=== 7. ワイルドカードが消えているか ==="
dig +short A zzq7x9-none.synon.co.jp || echo "  NXDOMAIN: OK"

echo "=== 8. メールが壊れていないか ==="
dig +short MX synon.co.jp

9既存 Cloudflare 資料との整合・訂正

9.1 🔵 訂正B（STUDIO と Origin CA）が根本解決します

今回の調査で、この懸念は事実だと確認できました。

9.2 🔵 訂正C（www のダングリング）が確定・解消します

既存資料の訂正C（www.synon.co.jp は Xserver を指すが HTTP 応答を確認できなかった → ダングリングの可能性）について、実測で apex（STUDIO）と www（Xserver）が別基盤を指していることが確定しました。8.3節の手順で apex への 301 に統一されます。

9.3 既存資料のどこを書き換えるか

9.4 3つの構成の整理

社内に「Cloudflare の下にあるもの」が3系統になります。混同しないよう整理しておきます。

9.5 運用カレンダーへの追加項目

10未確定事項（着手前に潰すこと）

10.1 🔴 最優先

10.2 ⚠️ 重要

10.3 📋 技術的な要検証事項（実装時に確認）

10.4 経営判断が必要な論点

11まとめ

この文書の要点

着手順序

【今すぐできること（DNS 移管を待たずに）】
  □ 20ページをブラウザで開き、棚卸し表を作る（10.1 の #2 #3 #4 を潰す）
  □ 画像アセットを全部ダウンロードする
  □ フォーム回答を CSV エクスポートする
  □ Search Console でベースラインを取る
  □ GitHub リポジトリを作り、design token を決めてトップページだけ作ってみる
       → *.workers.dev で表示できるところまでは、DNS 移管なしで到達できます

【DNS 移管後】
  □ Workers にカスタムドメインを設定
  □ www で先行検証 → apex を切替
  □ 1ヶ月観察 → STUDIO 解約

【移行完了後・別フェーズ】
  □ WebMCP の実装（Chrome Origin Trial の動向を見て判断）
  □ リモート MCP サーバー（/mcp）の追加

関連文書