これはCloudflare上でAI関連プロダクトを運用する記録シリーズの1本である。自社プロダクト「カンタン補助金」は2026年9月にインフラをCloudflareへ全面移行した。前回までの記事ではD1コストとR2使用率の記録を扱った。今回はWorkerのルーティングにまつわる問題をまとめる。
この記事で分かること
- Workerのルートを広げた瞬間に何が起きたか
- 死活監視が気づけなかった理由
- 切替前に切替後の姿を検証する方法
この記事で分からないこと(正直に書く)
- 検証で見つかった食い違いのうち、公開時点で対応済みのもの以外の件数の詳細
- 同種の問題が他の経路にも残っていないかの全数保証
何をしたか
カンタン補助金のCloudflare移行では、Worker側にAPIの実装を進めながら、Cloudflareのルートをまずは狭く張って様子を見る進め方を取った。ルートが狭い間はWorkerに届かないリクエストが多く、既存の挙動と混在させながら段階的に置き換えられる(出所: 自社の運用記録、確認日2026-09-06)。2026年8月、カスタムドメインを付けてルートを広げる本番切替を行った。
何が起きたか
ルートを広げた直後の突き合わせで、26件中15件が旧サーバーの応答と食い違った(出所: 自社の運用記録、確認日2026-09-06)。原因は、Workerが持つ同名のパスが旧サーバーのパスを覆い隠したことだった。/health は旧サーバーでは詳細な死活情報を返していたが、Workerでは簡易な応答を返すエンドポイントとして先に実装されており、ルートを広げた瞬間にそちらが優先された。RSSフィードのパスも、末尾を動的パラメータとして受け取るルートに先に一致し、404を返すようになっていた。
なぜ気づけなかったか
/health は死活監視が見ているパスそのものだった。Workerが返す応答も200だったため、監視は「正常」と判定し続け、実際には旧サーバー側の状態を一切見ていないことに気づけなかった(出所: 自社の運用記録、確認日2026-09-06)。壊れているのに200を返す状態がそのまま放置される、最も気づきにくい形になっていた。
どう直したか
動的セグメントを受け取るルートの手前で、まだ移していないパスを明示的に除外する形に直した。除外リストのパスはWorkerが横取りせず、そのまま旧サーバー側へ流す。加えて応答ヘッダに処理経路を示す値を付け、Workerが自前で処理したのか旧サーバーへ中継しただけなのかを外から判別できるようにした(出所: 自社の運用記録、確認日2026-09-06)。対応は2026年8月中に完了している。
再発防止 — 切替前に切替後の姿を測る
もっとも有効だったのは、ルートを持たない複製をあらかじめ用意して検証する方法だった。ルートを持たない状態でWorkerだけを別のURLに配備すると、そのURLに届くリクエストは全て直接Workerが受け取り、実装していないパスは素通しに落ちる。これはカスタムドメインを付けた後の世界をルーティングに触れずに再現できる(出所: 自社の運用記録、確認日2026-09-06)。この複製に対して現行との応答を突き合わせ、差分をすべて洗い出してから本番のルートを広げるようにした。検証用の複製は確認が終わり次第削除している。
Workerのルーティングを巡るこの問題は、完走時INSERTだけのWorkflowの記事で扱う「見えているはずの状態が実は無い」という構造と近い。移行全体のコスト面はD1コストの記事を、ストレージの全体像は姉妹記事「コストとストレージの記事」を参照してほしい。
自社プロダクトのCloudflare移行・ルーティング設計について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. Workerがパスを覆い隠すとはどういう現象か
Cloudflareのルートを広げると、Workerが実装している同名のパスが、旧サーバーが持っていた同じパスより先にリクエストを受け取るようになる。旧サーバー側の実装は一切呼ばれなくなり、Workerの応答に置き換わる。
Q2. なぜ死活監視は異常に気づけなかったのか
死活監視が見ていた /health をWorkerが覆い隠し、Workerが返す簡易な応答も200だったため、監視は正常と判定し続けた。旧サーバー側を一切見ていない状態のまま、200が返り続けていた。
Q3. どうやって直したのか
動的セグメントを受け取るルートの手前で、まだ移していないパスを明示的に除外し、旧サーバー側へ流す形に直した。あわせて応答ヘッダに処理経路を示す値を付け、外から判別できるようにした。
Q4. 同じ問題を切替前に見つける方法はあるか
ルートを持たない複製を別のURLに配備し、カスタムドメイン付与後の状態を先に再現して現行との応答を突き合わせる。ルーティングそのものには一切触れずに検証できる。