Next.jsで作成したWebサイトを、

ローカルで開発
GitHubでソースコード管理
Cloudflare Pagesで自動デプロイ
お名前.comで取得した独自ドメインを接続
Google Analytics 4を導入

というところまで実際に試してみました。

この記事では、単に「公開できた」という結果だけではなく、

ローカルでどこまで確認できるのか
GitHubとCloudflare Pagesをどう連携するのか
お名前.comとCloudflareをどう繋ぐのか
DNSは何を設定しているのか
GitHubへpushした後に何が起きるのか
ビルドエラーが出たときにどう切り分けるのか
Google Analyticsをどう追加するのか

まで一通りまとめます。

今回の構成は以下です。

Next.js
↓
GitHub
↓
Cloudflare Pages
↓
Cloudflare DNS
↓
お名前.comで取得した独自ドメイン

最終的には以下のような独自ドメインで公開することを目標にします。

https://example.com

※この記事では実際に使用したドメイン名、GitHubアカウント名、リポジトリ名などはすべてサンプルに置き換えています。

全体構成

今回構築した環境を簡単にすると以下です。

ローカルPC
│
│ npm run dev
│
▼
localhost:3000
│
│ git push
▼
GitHub
│
│ 自動連携
▼
Cloudflare Pages
│
│
├── xxxxx.pages.dev
│
▼
Cloudflare DNS
│
│ ネームサーバー
▼
お名前.com
│
▼
example.com

役割を分けると分かりやすいです。

サービス	役割
Next.js	Webサイトを作る
ローカルPC	公開前の動作確認
GitHub	ソースコード管理
Cloudflare Pages	ビルド・Web公開
Cloudflare DNS	DNS管理
お名前.com	独自ドメイン取得・管理
Google Analytics	アクセス解析

最初はCloudflareとお名前.comの役割が少し分かりにくかったのですが、

お名前.com
→ ドメインそのものを取得する

Cloudflare
→ そのドメインをどこへ接続するか管理する

Cloudflare Pages
→ 実際のWebサイトを配信する

と考えると理解しやすかったです。

1. Next.jsをローカルで起動する

まずはCloudflareやGitHubを触る前に、ローカル環境でNext.jsが動くことを確認します。

プロジェクトへ移動します。

cd sample-nextjs

依存パッケージをインストールします。

npm install

Next.jsを起動します。

npm run dev

ブラウザから以下へアクセスします。

http://localhost:3000

Webサイトが表示されればOKです。

普段の開発中は基本的に、

npm run dev

を使います。

2. 本番環境に近い状態をローカルで確認する

npm run devで動いたからといって、本番ビルドでも必ず成功するとは限りません。

そのためCloudflareへpushする前に、

npm run build

を実行します。

今回のpackage.jsonでは以下のような構成です。

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  }
}

つまり、

npm run build

を実行すると、

next build

が実行されます。

ここでエラーが出る場合は、Cloudflareへ送る前にローカルで修正できます。

これはかなり重要でした。

3. Cloudflare Pages向けにStatic Exportする

今回はNext.jsを静的サイトとしてCloudflare Pagesへ配置します。

next.config.mjsを以下のようにします。

const nextConfig = {
  output: "export",
};

export default nextConfig;

ポイントは、

output: "export"

です。

これを設定すると、ビルド時に静的ファイルが生成されます。

npm run build

を実行します。

成功すると、

out

ディレクトリが生成されます。

確認します。

ls

例えば以下のようになります。

app
components
node_modules
out
package.json
package-lock.json
next.config.mjs

4. 生成されたoutディレクトリもローカルで確認する

さらに確認したい場合は、Next.jsの開発サーバーではなく、

out

に実際に生成された静的ファイルを直接確認できます。

例えば、

npx serve out

を実行します。

表示されたURLへアクセスします。

例：

http://localhost:3000

ここで問題なく表示されれば、

Next.jsの開発モード

だけではなく、

実際にCloudflare Pagesへ配置する静的ファイル

も動作していることを確認できます。

問題の切り分けとして非常に便利です。

5. ローカルで確認できる範囲

Cloudflareへデプロイする前でもかなりの部分を確認できます。

npm run dev

では、

画面表示
CSS
JavaScript
ページ遷移
コンポーネント
レスポンシブ表示

などを確認できます。

さらに、

npm run build

では、

本番ビルドが成功するか
importエラーがないか
npmパッケージ不足がないか
Static Exportできるか

を確認できます。

最後に、

npx serve out

で、

実際に生成されたHTML
CSS
JavaScript
静的サイトとして正常に表示されるか

まで確認できます。

そのため、

npm run dev
↓
npm run build
↓
npx serve out

まで通してからGitHubへpushすると、Cloudflare側のトラブルをかなり減らせます。

6. GitHubへリポジトリを作成する

次にGitHubへコードを登録します。

GitHubで新しいRepositoryを作成します。

例：

sample-nextjs

ローカル側でGitを初期化します。

git init

変更を追加します。

git add .

コミットします。

git commit -m "initial commit"

ブランチ名をmainにします。

git branch -M main

GitHubのRepositoryを登録します。

git remote add origin https://github.com/USERNAME/REPOSITORY.git

GitHubへpushします。

git push -u origin main

これでローカルのコードがGitHubへアップロードされます。

7. GitHub連携を確認する

設定後は、

git remote -v

を実行します。

例えば以下のようになればGitHubと接続されています。

origin  https://github.com/USERNAME/REPOSITORY.git (fetch)
origin  https://github.com/USERNAME/REPOSITORY.git (push)

今後は基本的に、

git add .
git commit -m "update"
git push

だけで更新できます。

8. Cloudflare Pagesを作成する

Cloudflareへログインします。

Cloudflareの管理画面から、

Workers & Pages

へ移動します。

新しくPagesプロジェクトを作成します。

画面の表記は変更される可能性がありますが、GitHubの既存リポジトリをインポートする項目を選択します。

イメージとしては、

Workers & Pages
↓
Create
↓
Pages
↓
Import an existing Git repository

です。

GitHubとの接続を許可します。

その後、先ほど作成したRepositoryを選択します。

9. Cloudflare PagesのBuild設定

Next.jsのStatic Exportを利用する場合、今回設定した内容は以下のようなものです。

Production branch
main

Build command
npm run build

Build output directory
out

Root directoryは、Next.jsプロジェクトがRepository直下にある場合は基本的にそのままで問題ありません。

重要なのは、

Build command
npm run build

と、

Build output directory
out

です。

Next.js側で、

output: "export"

としているため、

out

がCloudflare Pagesへ公開するファイルになります。

10. Cloudflare Pagesで最初のデプロイ

設定が終わるとCloudflareが自動的にビルドします。

内部的にはおおよそ以下のような処理が行われます。

GitHub RepositoryをClone
↓
npm install
↓
npm run build
↓
outディレクトリをDeploy

ログを見ると、

Cloning repository...

のような表示から始まります。

その後、

Installing project dependencies

が実行され、

npm install

されます。

さらに、

Executing user command: npm run build

のようにビルドが実行されます。

成功すればCloudflare Pages用のURLが発行されます。

例：

https://sample-project.pages.dev

11. まずpages.devで確認する

独自ドメインを設定する前に、必ずCloudflare PagesのURLで確認します。

https://sample-project.pages.dev

ここでWebサイトが正常に表示されれば、

Next.js
↓
GitHub
↓
Cloudflare Pages

までは正常ということになります。

独自ドメインを後から設定することで、問題を切り分けやすくなります。

12. GitHubへpushするとCloudflareが自動デプロイする

GitHubとCloudflare Pagesを連携すると非常に便利です。

コードを修正したあと、

git add .

git commit -m "update site"

git push

します。

すると自動的に、

ローカルPC
↓
GitHub
↓
Cloudflareが更新を検知
↓
npm install
↓
npm run build
↓
Deploy

という流れになります。

つまり初回設定以降は、Cloudflareの管理画面から毎回手動でファイルをアップロードする必要がありません。

普段の更新作業は、

git push

まででほぼ完了します。

13. お名前.comで独自ドメインを取得する

次に独自ドメインを設定します。

今回はお名前.comで独自ドメインを取得した想定です。

この記事では例として、

example.com

を使用します。

この時点では、

example.com

と、

sample-project.pages.dev

はまだ繋がっていません。

14. Cloudflareへドメインを追加する

Cloudflareへ独自ドメインを追加します。

Cloudflareの管理画面から、

example.com

を追加します。

Cloudflareへ追加すると、Cloudflare用のネームサーバーが表示されます。

例えば以下のような形式です。

xxxx.ns.cloudflare.com
yyyy.ns.cloudflare.com

この値は利用するドメインによって異なります。

そのため、記事などに実際の値をそのまま公開するのではなく、

xxxx.ns.cloudflare.com
yyyy.ns.cloudflare.com

のように伏せておく方が分かりやすいと思います。

15. ネームサーバーとは

ここが最初かなり分かりにくかった部分です。

ドメインを取得しただけでは、

example.com

へアクセスしたときに、どのサーバーへ接続すればいいか分かりません。

そこでDNSを使います。

今回の構成では、

example.com
↓
Cloudflare DNS
↓
Cloudflare Pages

という流れにします。

そのため、

このドメインのDNS管理はCloudflareに任せます

という設定をお名前.com側で行います。

それがネームサーバー変更です。

16. お名前.comのネームサーバーをCloudflareへ変更する

お名前.com Naviへログインします。

対象のドメインを選択します。

ネームサーバーの変更画面へ進みます。

そこで、

その他のネームサーバーを使う

といった項目を選択します。

Cloudflareで表示された、

xxxx.ns.cloudflare.com
yyyy.ns.cloudflare.com

を登録します。

これで、

ドメインの所有・契約
→ お名前.com

DNS管理
→ Cloudflare

という役割分担になります。

17. ネームサーバー変更時の注意

すでにそのドメインで、

メール
サブドメイン
別サイト
TXTレコード
MXレコード
Aレコード
CNAMEレコード

などを使用している場合は注意が必要です。

ネームサーバーを変更すると、

DNS管理先そのもの

が変わります。

そのため既存のDNSレコードがある場合は、Cloudflare側へ必要なレコードを移行してから変更する方が安全です。

新規取得したドメインで、まだ何にも使っていない場合は比較的シンプルです。

18. DNSが切り替わったかローカルから確認する

DNSについてもブラウザだけではなくターミナルから確認できます。

MacやLinuxであれば、

dig NS example.com

を実行します。

シンプルに確認する場合は、

dig NS example.com +short

を使います。

Cloudflareのネームサーバーが表示されればOKです。

例：

xxxx.ns.cloudflare.com.
yyyy.ns.cloudflare.com.

これで、

お名前.com
↓
Cloudflare

のネームサーバー変更が反映されていることを確認できます。

19. Cloudflare Pagesへ独自ドメインを追加する

次にCloudflare Pages側へ戻ります。

対象のPagesプロジェクトを開きます。

Custom domainsから独自ドメインを追加します。

例：

example.com

Cloudflare DNSを利用している場合、PagesとDNSの接続をCloudflare内で管理できます。

設定が正常に完了すると、

https://example.com

からCloudflare Pages上のWebサイトへアクセスできるようになります。

20. 独自ドメインでアクセス確認する

ブラウザから、

https://example.com

へアクセスします。

正常にNext.jsのサイトが表示されれば成功です。

ターミナルから確認する方法もあります。

curl -I https://example.com

正常であれば例えば、

HTTP/2 200

などが返ってきます。

これで、

お名前.com
↓
Cloudflare DNS
↓
Cloudflare Pages
↓
Next.js

まで一通り繋がりました。

21. wwwあり・なしを決める

Webサイトには、

https://example.com

と、

https://www.example.com

があります。

どちらも使用できますが、SEOやURL管理を考えるとどちらかへ統一しておいた方が分かりやすいです。

例えば、

www.example.com
↓
example.com

へリダイレクトします。

これによりURLが分散するのを防げます。

22. pages.devも独自ドメインへ統一する

Cloudflare Pagesでは、

sample-project.pages.dev

というURLも使用できます。

ただし、本番サイトでは、

https://example.com

へ統一したい場合があります。

その場合、

sample-project.pages.dev
↓
example.com

へリダイレクトする構成にします。

これによって公開URLを独自ドメインに統一できます。

23. Google Analytics 4を設定する

サイトを公開したら、アクセス解析も設定してみました。

Google AnalyticsでWeb用のデータストリームを作成します。

設定するURLは、

https://example.com

です。

作成すると、

G-XXXXXXXXXX

という測定IDが発行されます。

このIDをNext.js側へ設定します。

24. Next.jsへGoogle Analyticsを追加する

Google AnalyticsをNext.jsへ追加するため、パッケージをインストールします。

npm install @next/third-parties

その後、

app/layout.js

へGoogle Analyticsを追加します。

例：

import "./globals.css";
import { GoogleAnalytics } from "@next/third-parties/google";

export const metadata = {
  title: "サンプルサイト",
  description: "サンプルサイトの説明"
};

export default function RootLayout({ children }) {
  return (
    <html lang="ja">
      <body>{children}</body>

      <GoogleAnalytics gaId="G-XXXXXXXXXX" />
    </html>
  );
}

以下を、

G-XXXXXXXXXX

自分のGoogle Analyticsの測定IDへ置き換えます。

25. Google Analytics追加後もローカルビルドする

Google Analyticsを追加したら、すぐpushするのではなく、

npm run build

を実行します。

ここで正常にビルドできるか確認します。

問題なければ、

git status

を確認します。

例えば、

modified: package.json
modified: app/layout.js

Untracked files:
package-lock.json

などが表示されます。

その後、

git add .
git commit -m "add google analytics"
git push

します。

Cloudflare Pagesが自動的に再デプロイします。

26. 実際に発生したGoogle Analyticsのビルドエラー

今回、Google Analyticsを追加した際にCloudflare Pagesでエラーが発生しました。

エラーは以下です。

Failed to compile.

./app/layout.js

Module not found:
Can't resolve '@next/third-parties/google'

最初はCloudflare側の問題かと思いました。

しかしログを確認すると、

Cloning repository
→ 成功

npm install
→ 成功

npm run build
→ 失敗

でした。

つまり、

GitHubとの接続

や、

Cloudflare Pages自体

ではなく、

Next.jsのビルド

で失敗していることが分かります。

27. Module not foundの原因

layout.jsには、

import { GoogleAnalytics } from "@next/third-parties/google";

を書いていました。

しかし、

@next/third-parties

がnpmの依存関係として登録されていませんでした。

そのためCloudflare上では、

このパッケージが存在しない

となり、

Module not found

が発生しました。

ローカルで、

npm install @next/third-parties

を実行して解決しました。

28. package.jsonだけでなくpackage-lock.jsonもpushする

パッケージを追加すると、

package.json

だけでなく、

package-lock.json

も変更されます。

確認します。

git status

その後、

git add package.json package-lock.json

git commit -m "install google analytics dependency"

git push

します。

これでCloudflare Pages側でも新しい依存パッケージがインストールされます。

29. npmとbunを混在させない

今回気になったポイントの1つです。

ローカルで、

bun add

を使用しているのに、Cloudflare側では、

npm install

が実行されていると、依存関係の管理が少し分かりにくくなります。

今回のCloudflare Pagesのログでは、

Installing project dependencies: npm install

となっていました。

そのため、このプロジェクトでは基本的に、

npm install
npm run dev
npm run build

へ統一しました。

パッケージマネージャーは混在させず、

npmならnpm
bunならbun
pnpmならpnpm

と統一した方がトラブルを減らせそうです。

30. Cloudflare Pagesのログの読み方

Cloudflare Pagesで失敗した場合は、最初からすべてを疑うのではなく、処理ごとに見ます。

例えば、

initialize
↓
clone repo
↓
install
↓
build
↓
deploy

という流れがあります。

もし、

clone repo

で失敗していれば、

GitHub接続

周辺を疑います。

npm install

で失敗していれば、

package.json
package-lock.json
Node.js
依存パッケージ

などを確認します。

npm run build

で失敗していれば、

Next.js
import
JavaScript
設定ファイル

などを確認します。

最後の、

deploy

で失敗していれば、Cloudflare側の出力ディレクトリなどを確認します。

31. 実際のログから切り分ける

例えば以下のログだった場合、

Cloning repository...
Success

Installing project dependencies: npm install
Success

Executing user command: npm run build

Failed to compile.

ここまでで、

GitHub
→ 正常

npm install
→ 正常

Next.js build
→ 異常

と分かります。

さらに、

Module not found

と出ていれば、

必要なパッケージがpackage.jsonに入っているか

を確認できます。

ログを上から順番に見るだけでもかなり原因を絞れました。

32. npmのwarningとerrorを分けて考える

npm installすると、以下のような表示が出る場合があります。

npm warn

または、

vulnerabilities

です。

例えば、

3 vulnerabilities

と表示されたとしても、それだけでビルド失敗とは限りません。

重要なのは、

warning

なのか、

error

なのかを見ることです。

今回も実際のビルド失敗原因は、

vulnerabilities

ではなく、

Module not found

でした。

33. npm audit fix --forceをいきなり実行しない

npmから、

npm audit fix --force

を提案される場合があります。

しかし、個人的にはいきなり実行しない方がいいと感じました。

--forceによって依存パッケージのバージョンが大きく変更される場合があるためです。

まず、

npm audit

を実行します。

内容を確認してから、

どのパッケージをアップデートする必要があるのか

を確認する方が安全です。

34. Next.jsのセキュリティ警告にも注意する

ビルド時に、

This version has a security vulnerability.
Please upgrade to a patched version.

のような警告が出る場合があります。

サイトが動いているからといって放置せず、Next.js公式のSecurity Advisoryを確認して、修正版へ更新する必要があります。

例えば、

npm outdated

で現在の依存パッケージを確認できます。

また、

npm audit

でも脆弱性情報を確認できます。

アップデートした後は必ず、

npm run build

で確認します。

35. package.jsonのバージョンも確認する

依存関係で問題が発生したときは、

package.json

を確認します。

例えば、

{
  "dependencies": {
    "next": "15.x.x",
    "react": "19.x.x",
    "react-dom": "19.x.x",
    "@next/third-parties": "15.x.x"
  }
}

のように、関連するパッケージのバージョンが極端にずれていないか確認します。

特に、

next
@next/third-parties
react
react-dom

周辺でpeer dependency warningが出る場合は、バージョンを確認した方がよさそうです。

36. Google Analyticsが動いているか確認する

Cloudflare Pagesへのデプロイが完了したら、

https://example.com

へアクセスします。

その後Google Analyticsの、

レポート
↓
リアルタイム

を確認します。

自分のアクセスが表示されればGoogle Analyticsの導入も完了です。

反映まで少し時間がかかる場合があります。

37. 開発から公開までの最終フロー

一度環境を作ってしまえば、普段の作業はかなりシンプルになります。

まずローカルで開発します。

npm run dev

完成したら本番ビルドします。

npm run build

必要であればStatic Exportされたサイトも確認します。

npx serve out

問題なければ、

git status

で変更内容を確認します。

その後、

git add .

git commit -m "update"

git push

します。

あとはCloudflare Pagesが自動的に、

GitHubから取得
↓
npm install
↓
npm run build
↓
Deploy

してくれます。

38. トラブル時の確認順序

今回一通り触ってみて、以下の順番で確認すると切り分けしやすかったです。

1. npm run devで動くか

↓

2. npm run buildが成功するか

↓

3. outディレクトリが生成されるか

↓

4. npx serve outで表示できるか

↓

5. GitHubへpushできるか

↓

6. CloudflareがRepositoryをCloneできているか

↓

7. Cloudflareのnpm installが成功しているか

↓

8. Cloudflareのnpm run buildが成功しているか

↓

9. pages.devで表示できるか

↓

10. Cloudflare DNSが正しいか

↓

11. ネームサーバーがCloudflareになっているか

↓

12. 独自ドメインで表示できるか

最初からDNSやCloudflareを疑うのではなく、

ローカル
↓
GitHub
↓
Cloudflare
↓
DNS
↓
独自ドメイン

と順番に確認するのが分かりやすかったです。

39. 今回理解できたこと

今回、実際にNext.jsのサイトを独自ドメインまで公開してみることで、それぞれのサービスの役割がかなり理解できました。

Next.js
→ Webサイトを作る

localhost
→ 開発中の確認

npm run build
→ 本番用にビルドできるか確認

Git
→ 変更履歴を管理する

GitHub
→ ソースコードを保管する

Cloudflare Pages
→ GitHubから取得してビルド・公開する

Cloudflare DNS
→ ドメインの接続先を管理する

お名前.com
→ ドメインを取得・契約する

Google Analytics
→ 公開後のアクセスを解析する

特に、

GitHubへpushする
↓
Cloudflare Pagesが自動でビルドする
↓
自動的に本番サイトが更新される

という一連の流れを実際に触れたのはかなり勉強になりました。

40. 構築前と構築後のイメージ

最初は、

Next.js
Cloudflare
GitHub
DNS
お名前.com

がそれぞれ独立したサービスに見えていました。

実際に構築してみると、

コードを書く
↓
GitHubへpush
↓
Cloudflareがコードを取得
↓
Next.jsをbuild
↓
静的ファイルを公開
↓
Cloudflare DNS経由で独自ドメインからアクセス

という1本の流れになっています。

Webサイト公開だけではなく、

Git
CI/CD
DNS
HTTPS
ホスティング
フロントエンド

あたりをまとめて触れる検証になりました。

まとめ

今回の最終構成は以下です。

ローカルPC
↓
Next.js
↓
Git
↓
GitHub
↓
Cloudflare Pages
↓
Cloudflare DNS
↓
お名前.comで取得した独自ドメイン
↓
Google Analytics

開発時は、

npm run dev

本番前には、

npm run build

必要であれば、

npx serve out

で静的ファイルも確認します。

そして、

git add .
git commit -m "update"
git push

すれば、Cloudflare Pagesが自動的に本番環境へ反映してくれます。

個人開発でも、

ローカル開発
↓
GitHub
↓
自動ビルド
↓
自動デプロイ
↓
独自ドメイン
↓
アクセス解析

まで比較的少ない構成で実現できました。

今回一番勉強になったのは、単純にサイトを公開できたことより、

どこで問題が起きているのか

をログから切り分けられるようになったことです。

例えば、

localhostでは動く
↓
npm run buildで失敗

ならNext.js側。

ローカルbuildは成功
↓
Cloudflareのnpm installで失敗

なら依存関係周辺。

pages.devでは表示できる
↓
独自ドメインでは表示できない

ならDNS周辺。

というように確認できます。

Next.jsから独自ドメイン公開まで一度自分で通してみると、Webサービスがどのように公開されているのか理解しやすくなりました。