HarnessのCloudflare本番運用｜Cron・R2・独自ドメイン・月次点検

HarnessのWorker、Pages、D1、Cron、R2、独自ドメインを確認し、利用量と本番入口を月次点検する方法です。 bindingと定期処理をWrangler実設定から把握します。 Worker error、D1、Cron、外部API失敗を同じ順序で確認します。 無料枠だけを見ず、subscription、支払い方法、予算通知、binding、削除事故まで準備します。

この記事はHarness Academyの教材データを基に、各Harnessの公式リポジトリにある実装箇所と照合して構成しています。秘密情報や本番データを記事・AIチャットへ貼らず、外部送信は必ず検証対象を限定してください。

最初に確認すること

• Cloudflare構成とCronを確認する: Cronを増やす前に、既存処理・時間・二重実行リスクを理解する
• ログと利用量を月次点検する: 問題が顧客申告まで放置されない運用にする
• R2の支払い設定・上限・運用を整える: IG Harnessの画像ギャラリーがR2へ安全に保存でき、想定外請求とデータ損失を監視できる
• L Harness・IG Harnessに独自ドメインを付ける: 独自ドメインで管理画面、/r、/t、LIFF、Webhookが動き、再deployでも設定が消えない
• Harness本番の入口を月次点検する: URL変更や更新後も、管理画面だけを閉じて公開導線を壊さない

Cloudflare構成とCronを確認する

bindingと定期処理をWrangler実設定から把握します。

この工程のゴール: Cronを増やす前に、既存処理・時間・二重実行リスクを理解する

LINE Workerは現行設定で5分ごとと6時間ごとの2 trigger、IGは5分ごとの1 triggerを持ちます。

Cron時刻はUTCです。処理本体はscheduled handlerを読み、何が毎回動くかを確認します。

手順

1. binding一覧

Worker名、D1、R2、assets、vars、secrets名を抽出します。

2. Cron追跡

wrangler triggerからscheduled handler、各jobへ進みます。

3. 運用表

頻度、処理、再実行、監視、重複防止を整理します。

完了条件

• LINE/IGの実Cronが判明
• scheduled handlerまで追跡
• 二重実行と再試行の扱いが分かる

Academy教材: Harnessの入口とCloudflareを安全にする / Lesson 9-1

ログと利用量を月次点検する

Worker error、D1、Cron、外部API失敗を同じ順序で確認します。

この工程のゴール: 問題が顧客申告まで放置されない運用にする

見る順番を固定すると、障害時に原因不明の変更を重ねずに済みます。deployment→Worker error→外部API→DB→UIの順で追います。

手順

1. Cloudflare

deployment、Worker logs、D1/R2利用量、Cronを確認します。

2. LINE/Meta

API error、token期限、Webhook statusを確認します。

3. Harness

失敗delivery、滞留queue、未返信、重複を確認します。

完了条件

• 対象resourceを取り違えない
• 個人情報を出力しない
• 問題が優先度別に整理される

Academy教材: Harnessの入口とCloudflareを安全にする / Lesson 9-3

R2の支払い設定・上限・運用を整える

無料枠だけを見ず、subscription、支払い方法、予算通知、binding、削除事故まで準備します。

この工程のゴール: IG Harnessの画像ギャラリーがR2へ安全に保存でき、想定外請求とデータ損失を監視できる

R2を有効化するにはCloudflareでR2 subscriptionのcheckoutと、有効な請求プロフィール・主要支払い方法が必要です。一般的にはクレジットカードですが、Cloudflareが現在対応する他の支払い方法もあります。

Standard storageには月次無料枠がありますが、subscriptionを有効にしない理由にはなりません。容量、Class A/B操作、環境別bucket、予算通知、支払い失敗時の運用を決めます。

手順

1. R2 subscription

DashboardのStorage & databases → R2 → Overviewからcheckoutし、請求プロフィールと主要支払い方法を登録します。

2. bucketとbinding

本番・検証を分け、wrangler.tomlのbinding名と実bucketを照合します。

3. 予算と監視

Standardの無料枠、操作回数、ストレージ量を理解し、予算通知と月次確認日を決めます。

4. 保存・取得・削除

小さい検証画像で一往復し、公開範囲、Content-Type、削除権限、復旧方針を確認します。

完了条件

• R2 subscriptionと主要支払い方法が有効
• 本番/検証bucketとbindingが一致
• 検証画像の保存・取得が成功
• 予算通知と月次確認担当が決定

注意: 無料枠内でもR2有効化時のbilling setupは省略しません。支払い情報の入力は受講者自身がCloudflare画面で行います。

Academy教材: Harnessの入口とCloudflareを安全にする / Lesson 9-4

L Harness・IG Harnessに独自ドメインを付ける

長いpages.dev／workers.devを、admin・apiの分かりやすい自社サブドメインへ変更します。

この工程のゴール: 独自ドメインで管理画面、/r、/t、LIFF、Webhookが動き、再deployでも設定が消えない

L Harness／IG Harnessでは、Workerをapi.example.com、管理画面Pagesをadmin.example.comのように分けます。同じ親ドメインにすると、Harnessの管理画面cookieがsame-siteになり、pages.devとworkers.devをまたぐ構成よりブラウザ制限へ強くなります。

Worker自身がoriginなので、既存サーバーの前へ置くRoutesではなくCloudflare Workers Custom Domainを使います。管理画面はPages projectのCustom domainsから関連付けます。CNAMEを手作業しただけではPagesへ関連付かず、522になる場合があります。

ドメインを付けるだけでは終わりません。L HarnessではWORKER_URL、ADMIN_ORIGIN、Pages build時のNEXT_PUBLIC_API_URL、LINE DevelopersのWebhook/OAuth/LIFF URLを新URLへ揃えます。IG連携がある場合はIG Harness側の接続Worker URLも更新します。

独自ドメインの動作確認後にCloudflare AccessのOTPを管理画面へ付けます。Accessは原則Pages管理画面だけを保護し、WebhookやLIFFが通るWorker全体を閉じません。

手順

1. ホスト名設計

Worker/APIと管理画面を別サブドメインへ分け、Cloudflare zoneと既存DNSを確認します。

2. Cloudflareへ追加

Worker Custom DomainとPages Custom domainを設定し、証明書がActiveになるまで待ちます。

3. アプリ設定更新

WORKER_URL、ADMIN_ORIGIN、NEXT_PUBLIC_API_URL、外部サービスのcallback/webhookを更新します。

4. 旧URLと新URLを検証

認証、CORS、/rのQR、/t、LIFF、Webhook、IG接続を通し、pages.dev／workers.devのredirect方針を決めます。

5. Accessは最後に追加

独自ドメインのE2E成功後、管理画面だけへメールOTPを追加します。

完了条件

• WorkerとPagesの証明書がActive
• 管理画面認証とCORSが成功
• /rのQR・/t・LIFF・Webhookが独自ドメインで成功
• 設定が次回deployでも維持される

注意: 既存CNAMEやcallback URLを先に消しません。新URLのE2E成功後に旧URLの廃止を判断します。

Academy教材: Harnessの入口とCloudflareを安全にする / Lesson 9-5

Harness本番の入口を月次点検する

独自ドメイン、Access、Pages迂回、API、Webhook、秘密情報を一枚で監査します。

この工程のゴール: URL変更や更新後も、管理画面だけを閉じて公開導線を壊さない

Harnessは、閉じる管理画面と、外部から受ける必要があるWebhook・LIFF・流入リンクを同じCloudflare上で扱います。全部をAccessで閉じるのではなく、hostnameとpathの役割を先に分類します。

毎月、Pages production・preview、独自ドメイン、Worker custom domain、Access application、許可メール、CORS、cookie、Webhook署名、MCPキー、R2公開範囲を確認します。

手順

1. URL台帳

admin、api、LIFF、pages.dev、workers.dev、previewを一覧化します。

2. 閉じる／公開を分類

管理画面はAccess、Webhook等は公開＋署名検証、MCPはBearer認証に分けます。

3. 迂回と期限を確認

標準URL、古いURL、Preview、退会メール、失効キーを確認します。

4. 復旧方法を記録

Access誤設定、証明書失敗、CORS不一致時の戻し方を残します。

完了条件

• 管理画面と公開導線を分類
• 標準URLからの迂回なし
• Webhook・LIFF・MCPが正常
• 退会者と古いキーを確認
• rollbackを記録

Academy教材: Harnessの入口とCloudflareを安全にする / Lesson 9-8

公式ソース

• L Harness / apps/worker/wrangler.toml — LINE bindings/Cron
• IG Harness / apps/worker/wrangler.toml — IG bindings/Cron
• Cloudflare R2 Get started — subscription checkout
• Cloudflare billing profile — 主要支払い方法
• Cloudflare R2 pricing — 料金と無料枠
• Cloudflare billing policy — 支払い失敗時の扱い
• IG Harness / apps/web/src/app/images/page.tsx — 画像ギャラリー
• Cloudflare Workers Custom Domains — Workerをoriginとして独自ドメイン化
• Cloudflare Pages Custom domains — Pagesの独自ドメイン
• L Harness / packages/create-line-harness/src/steps/admin-auth.ts — WORKER_URL・ADMIN_ORIGIN・cookie/CORS
• L Harness / packages/create-line-harness/src/steps/deploy-admin.ts — NEXT_PUBLIC_API_URL
• L Harness / apps/web/src/components/accounts/account-setup-urls.tsx — Webhook/OAuth/LIFF URL
• Cloudflare Workers / Routes — 既存originの前段で使うRouteとの違い
• L Harness / docs/ADMIN-AUTH.md — same-site custom domain推奨構成
• L Harness / apps/worker/src/middleware/admin-auth-config.ts — cookie・CORSの設定ガード
• IG Harness / apps/web/src/lib/api.ts — IG管理画面のAPI接続先

関連ガイド

• Harnessシリーズ公式ガイド索引
• L Harness操作マニュアル