Cloudflareのエッジ設計: サービス境界とデプロイの証拠

最初にサービスの境界をそろえる

エッジのサービスは、URL、Workerの設定、保存先のbinding、スキーマのmigration、動作確認が同じプロダクトを指していると調査しやすい。静的な学習書庫に必要なのは、記事からHTMLとアセットを作るビルドである。操作を伴うプロダクトならWorkerのAPIやデータベースが加わる。同じリポジトリに入っていても、デプロイの契約はサービスごとに分ける。

1. 1ソースと記事
2. 2ビルドと静的検証
3. 3バージョン付きデプロイ

1. 1Workerの宛先
2. 2静的アセットまたはAPI
3. 3bindingで結び付けた保存先

1. 1本番URL
2. 2HTTPと画面での動作確認
3. 3配信の証拠

プラットフォームがデプロイを受け付けたことと、期待するURL、認証境界、保存処理が動くことは別の証拠である。公開後に、それぞれを意図して確かめる。保存を検証する場合は、小さな合成データを使い、再読み込み後の状態も観察する。

データの変更を明示する

D1のスキーマmigrationはプロダクトのリリースの一部として扱う。順序を保ち、対象環境の通常の手順で適用する。ローカルのテストを通すために本番のスキーマを置き換えない。secretはプラットフォームの保存領域へ入れ、ソースとブラウザ向けのbundleには名前と設定の契約だけを残す。

独自ドメインは安定した入口になり、Worker名とbindingは配信先を明示する。DNS、Workerのルーティング、Accessのポリシーはそれぞれ異なる制御である。適用した設定を記録し、本番のURLを確かめる。ローカル開発サーバーが動くことを、同等の本番の証拠として扱わない。

演習: 一つの要求を最後まで追う

小さなサービスで、ブラウザの要求から変更され得る全ての保存先まで線を引く。その後、静的ページ、正常なAPI要求、不正な要求、存在しないURLの四つを確かめる。これで境界が見えるようになる。

たとえば学習書庫では、記事本文がHTMLに含まれ、JavaScriptを実行する前に読めることを確認する。存在しない記事ならHTTPは404である。200を返してからブラウザで「見つかりません」と表示する実装では、HTTPの契約を満たしていない。非公開サービスでは、未認証の要求が認証画面へ進むこと、Workerを直接呼んでも署名を検証することを別々に確認する。

リリースを小さく、観察できる単位に保つ

一つのサービスの契約を変えるリリースは、全プロジェクトを一度に変えるリリースより原因を調べやすい。ビルド結果、配信バージョン、本番の要求は異なる問いに答える。それぞれを記録する。失敗したらURLと応答の種類を証拠に残し、その観測された境界を次の変更で直す。

この習慣は性能の設計にもつながる。小さな静的ページは短い要求で確かめられる。一方、APIは応答と保存の検証が必要になる。一方の成功から他方の成功を推測しない。

性能と認証を同じ経路で考える

公開の読み物なら、HTMLをエッジから直接返し、静的な本文を毎回データベースから取り出さない。ファイル名に内容のハッシュが入るアセットには長いcacheを使える。記事のJSONやHTMLは、変更を反映する契約に合わせて再検証する。不要な外部フォント、追跡、画面全体の定期pollingは、表示時間と調査対象を増やす。

非公開の画面では、cacheより認証が先に必要となる。認証済みのHTMLや個人のJSONを公開cacheへ保存しない。Accessは入口のポリシーを評価し、Workerは受け取ったJWTの署名、issuer、audience、有効期限を検証する。クライアントが任意に付けたidentity headerを、そのまま本人の証拠として信じない。APIの保存はサーバー側でも所有者を確かめ、入力サイズと許可する形式を明示する。

ここで全ての処理に同じ設定を使う必要はない。公開の読み物と、非公開の操作画面は実際に違う要求を持っている。性能のために認証を飛ばすことも、静的ページのために不要な実行基盤を作ることも避ける。

再現できる引き継ぎの形

サービス名、公開URL、Worker名、保存先の名前、適用済みmigration、必要なsecret名、配信バージョン、検証日時を一つの記録にそろえる。secret値や個人の保存内容は含めない。「実装済み」「ビルド合格」「デプロイ成功」「本番挙動を確認済み」を区別して書く。

無料プランの制限、有料機能の利用条件、本人の認証操作が未完なら、その境界も記録する。別の保存先へ黙って切り替えて成功を装わない。小さく具体的な構成なら、次に直すべき対象と必要な操作が分かる。保守性は設定項目の数ではなく、一つの要求を説明できることから生まれる。

次に確かめる小さな変更

教材の文を一つ変え、ビルドから本番のHTMLまでその変更を追う。次に未知のURLを一つ要求し、404を確かめる。保存を持つサービスでは、正常な書き込み、古い版の書き込み、再読み込みを順に観察する。結果だけでなく、どの配信バージョンとどの保存先に対する操作だったかも残す。同じリポジトリ内で隣のサービスが動いていても、このサービスの成功の証拠にはならない。

一つの利用しかない時は、具体的な設定と関数で十分である。共通化したくなったら、実際に二つの利用があり同じ契約なのか、あるいは調査やテストで具体的な問題が出たのかを確認する。将来の可能性だけで配信の経路を増やすと、現在の要求がどこで処理されたか分かりにくくなる。現在の正しい契約へ呼び出し側を同時に更新し、不要になった旧経路を残さない。

2024〜2026年の変化: 配信済みのエッジサービスは権限境界になった

WorkersとStatic Assetsは配信を解決しますが、2026年にはAI対応ルート、秘密、外部ツールにより、デプロイメントを権限グラフとしてレビューする必要があります。Cloudflareの2026-09-29のセキュリティ記事はこの広い面に対するベンダーの現在の見解です。いかなるデプロイメントの認証でもありません。

一つのサービスでは、デプロイ前にルートからbindingへの対応を書きます。公開ルート、認証規則、asset path、Worker binding、データストア、secret名、外向きホスト、削除／ロールバック担当です。静的HTMLの変更が、動的ルートに新しいDBやAPIトークンを黙って付与してはいけません。外部から試験します。対応ロケールは意図した静的ページを返す、未知ルートは本物の404、非公開ルートはfail closed、ヘッダーは想定外のscript originを禁止、秘密を露出せず新しい配信版を識別できることです。データ書込みでは、検証、所有者確認、revision競合、再読込後の永続化を別に証明します。

2026-09-24 の自己ホスト文書をエージェントが読むことについての r/selfhosted 議論は未検証の実務者文脈である。route単位のアクセスと検索traceの確認は促せるが、Cloudflareのcontrolを証明しない。

Cloudflareの2024年4月のPython Workers releaseは、Workers AI、R2、Durable Objectsなどのbindingを第二のlanguage runtimeへ公開した。実装の選択肢が増えてもauthority boundaryは統合されない。route-to-binding tableを実行可能に保つ。各bindingについて、未認可principalのrequestを1件送り、runtime languageを変えた後も同じfail-closed結果を要求する。