The Harness ／公式情報・ツール比較

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

· 執筆: The Harness 編集部
THE HARNESS LAB
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になる場合があります。

    ドメインを付けるだけでは終わりません。LINE 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

    公式ソース

    関連ガイド

    Academy会員はコピペ実行用プロンプトと演習を開くと、同じ手順をAIへ渡して実機で進められます。