← health-moniter 目次へ ／ サイトトップ

HM-003

health-moniter Cloudflare Dashboard設定手順

作成: 2026-06-27 ／ 対象: Cloudflare Dashboard・Zero Trustの再現手順

要約。 GitHubからWorkerをビルドし、D1をbindingし、health.lunelukkio.comだけをGoogle認証で保護するまでの設定を再現可能な形で整理します。設定はWorkers DashboardとZero Trust Dashboardの二か所に分かれます。
本ノートでの用語規約。「Domains」はWorkerをどのURLで公開するかを決める設定、「Destinations」はAccessがどのURLを認証対象にするかを決める設定です。似ていますが別の設定です。画面名は2026-06-27時点です。

1. 設定全体の地図

中心用語はBuild、Binding、Accessです。Buildはコードを配備し、BindingはWorkerからD1へ名前付きで接続し、AccessはWorkerより手前で本人確認を行います。

Cloudflare設定全体の関係 GitHubmain / frontend Workers Buildsbuild → deploy WorkerHono + React assets D1DB binding Google IdPGoogleアカウント Zero Trust AccessOnly me / 24時間 Custom Domainhealth.lunelukkio.com
図1. 上段は配備とデータ接続、下段は公開URLと認証。両方が揃って本番経路になる。

2. Workers BuildsをGitHubへ接続

Workers & Pages → health-moniter → Settings → Build

項目設定値意味
Git repositorylunelukkio/health-moniterデプロイ元
Root directory/frontendコマンドを実行する基準
Build commandnpm run buildReactとWorker成果物を生成
Deploy commandnpx wrangler deploy -c dist/health_moniter/wrangler.json生成された設定で配備
Production branchmain本番自動デプロイの対象
GitHub pushから本番デプロイまで mainへpushGitHub Rootを選択/frontend npm run builddistを生成 wrangler deploydist/health_moniter/wrangler.json 本番Workerを更新BuildログとDeploymentsで成否を確認
図2. mainへのpushを起点に、frontend配下のビルド成果物をWranglerが配備する。

3. D1 databaseとbinding

Storage & databases → D1 ／ Workers & Pages → health-moniter → Bindings

  1. D1にhealth-moniter-dbを作成する。
  2. WorkerのDB bindingをD1へ接続する。binding名はWorkerコードとWrangler設定の名前に一致させる。
  3. 現在のbindingに対してmigrationを適用し、必要なテーブルとインデックスを確認する。

ローカルD1はMiniflareがSQLiteとして管理します。ファイル名はD1の識別子に対応するため、database_idを差し替えると同じbinding名でも別のローカルSQLiteを参照します。

D1 binding変更時のローカルSQLite分離 旧database_id最初のmigration 旧SQLiteスキーマあり・現在は孤立 現在のdatabase_id現binding 新SQLite作成直後は空 現bindingへ再適用migrationを確認旧ファイルは保全
図3. database_id変更はローカルDBの参照先変更になる。データ消失と決めつけず両ファイルを確認する。

4. DomainsとZero Trust Access

4.1 Workerの公開経路

Workers & Pages → health-moniter → Domains

項目設定
Custom Domainhealth.lunelukkio.com
workers.devworkers_dev = false
Preview URLpreview_urls = false

4.2 Zero Trustの認証

Zero Trust → Settings → Authentication ／ Access → Applications

項目設定
Identity providerGoogleのみ
ApplicationSelf-hosted health-moniter
Destinationhealth.lunelukkio.comのみ
Policy名前: Only me、Action: Allow、Include selector: Emails、Value: 本人のGoogleメールアドレス1件
AuthenticationAccept all identity providers: Off、Googleのみ、Instant authentication: On
Session Duration24 hours
本人限定を確認済み。 Policy名のOnly meは表示名ですが、実際のAllow条件はInclude selectorのEmailsで、本人のGoogleメールアドレス1件だけが指定されています。本ノートには実際のアドレスを記載しません。
Access callback障害とcustom domain一本化 修正前: Destinationが二つ Google認証 Access custom domain workers.devWorker側では無効 callback先が無効There is nothing here yet 修正後: custom domainだけ ブラウザAccessGoogle / Allow policyhealth.lunelukkio.comWorker / D1 WorkersのDomainsとAccessのDestinationsを同じ入口へ揃える
図4. workers.devをDestinationから削除し、公開経路と認証経路をcustom domain一本に揃えた。

5. 検証と保守判断

確認期待結果判定
custom domainへ未認証アクセスAccessログインへ302確認済み
Google認証後health-moniterが表示される確認済み
旧workers.dev公開されず404確認済み
別GoogleアカウントEmails条件に一致せず拒否される設定確認済み。別アカウントでの実試験は未実施
Worker側のAccess JWT二重検証。 custom domainだけを入口にし、workers.devとpreview URLを無効化した単一利用者構成では必須ではありません。別経路の追加、複数ユーザー化、外部API化を行う時に再検討します。

通常のWebアクセスで第三者がWorkerコードを書き換えることはできません。主要な残存リスクはCloudflare/GitHubアカウントの侵害、デプロイトークンの流出、依存パッケージの供給網です。多要素認証、最小権限トークン、依存更新レビューを継続します。

確信度: 高。設定値は2026-06-27の実作業と疎通確認に基づく。Cloudflareの画面名称は変更される可能性があるため、見つからない場合は同じ機能名でDashboard内を検索する。

参考資料

関連項目

← health-moniter 目次へ ／ 更新履歴