Cloudflare Pages の Preview 環境で Google Cloude API の OAuth2 認証 を利用する際の Redirect URI 問題
Cloudflare Pages は、GitHub などの Git リポジトリと連携し、コミットやプルリクエスト (PR)に基づいて自動的にデプロイできる機能が備わっています。特に、PR 作成時などに本番環境とは異なる Preview 環境が自動的にデプロイされる機能は、開発効率を大きく向上させます。
一方で、Pages で構築したウェブアプリケーションから Google Cloud API を利用する場合、通常は OAuth 2.0 認可フローを用いた認証・認可が必要となります。この Google OAuth 2.0 の仕様と、Pages の Preview 環境の特性との間で、特に「承認済みのリダイレクト URI (Authorized Redirect URI)」の設定で課題が生じることがあります。本記事では、その問題点と、Cloudflare Pages の設定を活用した解決策について解説します。
Cloudflare Pages の Preview デプロイメント
Cloudflare Pages は、Git リポジトリを接続すると、デフォルトで「All non-Production branches」（すべての非プロダクションブランチ）に対してコミットごとに自動的に Preview デプロイメントを実行します。この自動デプロイの挙動は、Pages プロジェクトの設定画面から変更できます。
Preview デプロイメントの制御方法として、「All non-Production branches」「None」「Custom branches」の3つのオプションがあり、「Custom branches」を選択することで、自動デプロイに含める、あるいは除外するブランチを詳細に指定できます。この際、設定には「Static branch names」（特定のブランチ名）または「Wildcard syntax」（ワイルドカード文字 *）を使用することが可能です。例えば、fix/* や feat/* といった特定のプレフィックスを持つブランチのみを含めたり、dependabot/* のような特定のブランチを除外したりできます。
Google Cloud API OAuth 2.0 と Redirect URI の制約
ウェブサーバーアプリケーションが Google API にアクセスする場合、多くは OAuth 2.0 を利用しアクセス権を取得します。この OAuth 2.0 認可フローでは、Google の OAuth 2.0 サーバーにアプリケーション自身の身元を示すために認証情報が必要であり、その設定の一部として**「承認済みのリダイレクト URI」**を事前に Google Cloud API Console で登録する必要があります。リダイレクト URI は、認可フローが完了した後に Google の OAuth 2.0 サーバーがユーザーをリダイレクトする先の URL です。
Google は、このリダイレクト URI に対して厳格な検証ルールを設けています。その中で特に重要な制約として、リダイレクト URI にワイルドカード文字 (*) を含めることはできないという点があります。
Preview 環境の URL と Redirect URI のミスマッチ
Cloudflare Pages の Preview 環境の URL は、通常、デプロイされたブランチ名に基づいて動的に生成されます。例えば、https://[ブランチ名].[プロジェクト名].pages.dev、https://[commit hash].[プロジェクト名].pages.devのような形式になります。
もし、Pull Request ごとに作成される feature ブランチ（例: feat/user-auth, fix/layout-bug など、ブランチ名が可変なもの）に対してデフォルト設定のまま Preview デプロイメントが行われる場合、それぞれの Preview 環境の URL は異なるブランチ名を含む動的なものになります。
この動的に変化する URL を Google Cloud API の承認済みリダイレクト URI として事前にすべて登録することは現実的ではありません。そして、前述の通り、Google の検証ルールではリダイレクト URI にワイルドカードを使用できない ため、https://*.your-project-name.pages.dev/oauth2callback のように柔軟なパターンで登録することも不可能です。これが、Pages の Preview 環境で Google Cloud API と連携する際の課題となります。
Static Branch Control を活用した解決策
この問題を回避するためには、Cloudflare Pages の**「Custom branches」設定を利用し、Preview デプロイメントの対象を特定の静的なブランチ名**に限定するアプローチが有効です。
- Pages のデプロイ設定を「Custom branches」に変更。
-
Preview デプロイメントの対象を特定の静的なブランチ名に限定する。例えば、テストやステージング用のブランチとして
stagingという名前のブランチを運用している場合、Pages の設定で「Include Preview branches」にstagingのみを指定します。これにより、stagingブランチへのコミットや PR のみが Preview デプロイメントをトリガーするようになります。ワイルドカード（*）は使用せず、特定の静的ブランチ名のみを指定するのがポイントです。 -
Google Cloud API Console に静的ブランチ用の Redirect URI を登録する。もし Cloudflare Pages が、このように特定の静的なブランチ名に対して固定された、予測可能な Preview URL を提供するのであれば（※注）、その固定された URL（例:
https://staging.your-project-name.pages.dev/oauth2callback）を Google Cloud API Console の承認済みリダイレクト URI として正確に登録します。
この方法により、staging ブランチの Preview 環境は常に同じ URL でアクセスできるようになり、その固定 URL は Google のリダイレクト URI 検証ルール（ワイルドカード禁止、完全一致要求）を満たせます。結果として、特定の安定した Preview 環境で Google API 連携機能の開発やテストを行うことが可能になります。
設定手順の概要:
-
Cloudflare Pages:
- プロジェクトの Settings > Builds & deployments に移動。
- Configure Production deployments 内の Preview branch control を「Custom branches」に設定。
- 「Include Preview branches」に Google API 連携をテストしたい特定の静的なブランチ名（例:
staging）を入。
-
Google Cloud API Console:
- 対象プロジェクトの「APIとサービス」>「認証情報」ページに移動。
- 使用する OAuth 2.0 クライアント ID を選択または新規作成し、「承認済みのリダイレクト URI」セクションに、Cloudflare Pages のその静的ブランチに対応する Preview URL（例:
https://staging.your-project-name.pages.dev/oauth2callback）を追加。
まとめ
Cloudflare Pages の GitHub Preview 機能は、プルリクエストごとに自動デプロイされるPreview環境の柔軟な URL が、Google Cloud API の OAuth 2.0 における Redirect URI のワイルドカード禁止 および完全一致要求 という厳格な制約と衝突するという課題があります。この課題に対し、Pages の「Builds & deployments」設定で Preview デプロイメントの対象を特定の静的なブランチ名に限定し、その静的ブランチに対応する固定の Preview URL を Google Cloud API Console の承認済みリダイレクト URI として登録する アプローチが有効な解決策となります。これにより、Preview 環境での Google API 連携テストが可能となります。