Pages、Workers、opennextjs。3つを行き来して6時間かかりました。失敗の多くは、技術の難しさではなく設計の順序ミスとして整理できます。「何を使うか」より「どの順番で判断するか」が先にある、という構造が見えた記録です。
この記録を残す理由
前回の記事では、ローカルでアプリが動くまでの約2時間の記録を書きました。
この記事はその続きです。ローカルで動いたアプリを本番公開（Cloudflareへのデプロイ）するまでに、約6時間かかりました。
6時間の内訳はこうです。
- Cloudflare Pages での失敗：約1時間
- Cloudflare Workers への切り替えと失敗：約2時間
- WSLのインストールと設定：約1時間
- WSLからのビルド＆デプロイ成功まで：約2時間
これは単純な「手間取り」ではなく、判断の分岐点を間違えた時間の積み重ねです。どこで判断を誤ったか、正しい判断は何だったかを整理します。
実際の数値（デプロイ作業の記録）
作業のタイムライン：
- Cloudflare Pagesでの最初のデプロイ試み →
npm run deployが存在しないエラー - ChatGPTの提案でPages設定を変更 → ページは表示されず404エラー
- Cloudflare Workersに切り替え → Internal Server Errorが継続
- wrangler tailでエラーログを確認 → ChunkLoadErrorを発見
- 原因判明：Windowsビルドの非互換
- WSLインストール → Ubuntuセットアップ → LinuxのNode.jsインストール
- WSLからビルド＆デプロイ → 成功
数値として重要なのは「6時間のうち4時間以上が、根本原因を把握するまでの時間だった」という点です。原因が特定できてからの解決は1〜2時間でした。
判断基準として整理すると：
エラーが出たとき、最初にやるべきはログの確認です。
wrangler tailによるリアルタイムログを最初から使っていれば、根本原因の特定は大幅に速くなります。
失敗の構造（何がずれていたか）
今回の失敗を「現象」ではなく「構造」で整理すると、3つに分類できます。
構造ミス①：環境選定を「推測」で決めた
「PagesかWorkersか」という選択を、正確な技術情報ではなく複数のAIからの断片的な情報で判断しました。ClaudeはPagesを提案し、ChatGPTはWorkersを推奨した。どちらが正しいかを自分で判断できず、「まず試してみる」という進め方をしました。
構造として言うと「環境選定の判断基準が設計されていなかった」です。
構造ミス②：ビルドログの警告を見落とした
OpenNextのビルドログには最初から WARN OpenNext is not fully compatible with Windows. が出ていました。この警告を見落としたまま、Windowsでのビルドを繰り返しました。
構造として言うと「ログを確認する習慣が設計に組み込まれていなかった」です。
構造ミス③：問題の切り分けができていなかった
「Pagesで動かない」→「Workersに切り替える」という判断をしましたが、実際の根本原因は「PagesかWorkersか」ではなく「Windowsでビルドしている」ことでした。症状への対処を繰り返し、原因の特定が遅れました。
構造として言うと「問題の切り分け（原因と症状の分離）が設計されていなかった」です。
判断の分岐点（どこで誤り、正しい判断は何か）
分岐点①：PagesかWorkersか
誤った判断：複数のAIの情報を混在させたまま、どちらかを「試してみる」
正しい判断：Next.jsのAPIルートを使う場合はWorkersを選ぶ（Pagesの設計上の制約を先に把握する）
なぜ誤ったか：「どちらが適切か」を判断するための基準を持っていなかったため、情報を受け取るだけで終わりました。
判断基準として残すなら：
Next.jsのAPIルート（サーバーサイド処理）を使う場合、Cloudflare PagesはSSRを想定していない設計です。Workers + OpenNextの組み合わせが適切です。
分岐点②：エラーが出たとき、何を先に確認するか
誤った判断：エラーの症状に対して次の手を打つ（Pagesを変更→Workersに切り替え）
正しい判断：まずログ（wrangler tail）でエラーの原因を特定してから動く
なぜ誤ったか：「動かないから設定を変える」という行動が先にあり、「なぜ動かないか」の確認が後回しになっていました。
判断基準として残すなら：
エラーが出たとき、設定変更より先に wrangler tail でリアルタイムログを確認する。ログにChunkLoadErrorが出ているなら、Windowsビルドの非互換を疑う。
分岐点③：WindowsかWSL（Linux）か
誤った判断：Windowsのコマンドラインからビルドを繰り返す
正しい判断：OpenNextのビルドはLinux環境（WSL）から実行する
なぜ誤ったか：WARN OpenNext is not fully compatible with Windows. というビルドログの警告を見落としていました。
OpenNextのビルドログに `WARN OpenNext is not fully compatible with Windows.` が出ている場合、Windowsからのビルドでは動作しません。このWARNは「警告」ではなく「使用環境が違います」という通知です。
再現条件（この方法が機能する条件）
WSLからのCLIデプロイで解決した、という結果は以下の条件が揃っているときに再現できます。
条件①：WSL（Ubuntu）がインストールされていること
Windows上でLinux環境を使うためWSLが必要です。wsl --install でインストールできます。
条件②：WSL内にLinux用Node.jsがインストールされていること
WindowsのNode.jsではなく、WSL内のLinuxネイティブなNode.jsを使う必要があります。which node が /usr/bin/node を返す状態。
条件③：export PATH=/usr/local/bin:/usr/bin:/bin を実行してからビルドすること
これを実行しないと、WSL内でWindowsのコマンドが呼ばれてしまいます。毎回のビルド前に必要です。
条件④：App directory: がLinuxパスで表示されること
ビルドログに App directory: /home/uracc/rehapro のようなLinuxパスが表示されれば、Linux環境でビルドされています。C:\ から始まるパスが表示された場合は失敗です。
やり直したこと：WSL導入からCLIデプロイまで
PowerShellで `wsl –install` を実行してWSL（Ubuntu）をインストール。PC再起動後、スタートメニューから「Ubuntu」を起動してユーザー名とパスワードを設定する。 判断基準：`wsl –version` でWSLのバージョンが表示されればインストール完了
WSLターミナルで以下を実行： “` curl -fsSL https://deb.nodesource.com/setup_22.x | sudo bash – sudo apt-get install -y nodejs “` `which node` が `/usr/bin/node` を返せば成功。 判断基準：`/usr/bin/node` と表示されれば成功。`/mnt/c/` から始まるパスならWindowsのNode.jsを参照している（失敗）
`cp -r /mnt/c/Users/uracc/webproject/01_rehapro-lab/app/. ~/rehapro/` でプロジェクトファイルをWSLのLinux領域にコピーする。 判断基準：`ls ~/rehapro/app/` でapp/フォルダの中身が見えれば成功
`export PATH=/usr/local/bin:/usr/bin:/bin` を実行してからビルドする。ビルドログの `App directory:` がLinuxパスになっていることを確認する。 判断基準：App directoryがLinuxパスならOK。`C:\` から始まるパスならWindowsでビルドされている（失敗）
`npx @opennextjs/cloudflare deploy` を実行。`Deployed rehapro-app triggers` が表示されればデプロイ成功。 判断基準：カスタムドメインでページが表示されれば完了
セルフチェック
環境の確認
□ `which node` が `/usr/bin/node` を返しているか → `/mnt/c/` から始まるならWindowsのNode.jsを参照している（失敗）
□ `export PATH=/usr/local/bin:/usr/bin:/bin` を実行したか → 毎回のビルド前に必要
□ ビルドログの `App directory:` がLinuxパスになっているか → `C:\` から始まるならWindowsでビルドされている
エラー発生時の確認順序
□ `wrangler tail` でリアルタイムログを確認したか → 設定変更より先にログを見る
□ ChunkLoadErrorが出ているか → Windowsビルドの非互換を疑う
□ `WARN OpenNext is not fully compatible with Windows.` が出ているか → 出ている場合はWSLでのビルドが必要
この後どうなったか
カスタムドメイン app.rehapro-lab.com での表示確認まで完了しました。
CSS（Tailwind CSS v4）の表示崩れが残っていましたが、globals.css に @source ディレクティブを追加し、全ファイルを同期してビルドし直すことで解決しました。
現在は本番で正常に動いています。今後の課題として、アクセス制限（有料ユーザーのみ使用可能にする仕組み）とPush通知のCron設定が残っています。
ここまでかかった総時間は、ローカル開発の2時間とデプロイの6時間を合わせて約8時間です。一気に進めようとしたためClaudeのセッション制限に引っかかり追加クレジットも投入しました。「時間をかければ費用は抑えられた」と思いますが、作業の勢いと記憶の鮮度を優先してそうしました。
よくある質問
- PagesとWorkersはどちらを選べばいいですか？
-
Next.jsのAPIルートを使う場合は、Cloudflare WorkersとOpenNextの組み合わせが適切です。PagesはSSRを想定していない設計のため、Next.jsの動的処理が正常に動きません。「どちらを試すか」ではなく「APIルートを使うか使わないか」で判断してください。
- WSLのインストールは難しいですか？
-
PowerShellで `wsl –install` を実行するだけでインストールできます。ただし、WSL内のパスとWindowsのPATHが混在する問題があるため、`export PATH=/usr/local/bin:/usr/bin:/bin` を毎回実行する習慣をつけると安定します。デプロイの手順はREADMEに記録しておくことをおすすめします。
構造まとめ
今回のデプロイ失敗を構造化すると、以下の3点に集約されます。
① 環境選定の判断基準が設計されていなかった
「PagesかWorkersか」を決める前に「APIルートを使うか」という条件を確認する必要があります。条件が先にあり、ツール選択はその後です。
② ログを確認する習慣が設計に組み込まれていなかった
エラー発生時に「設定を変える」より前に「ログを見る」ステップが必要です。wrangler tail を使えば、根本原因の特定にかかる時間を大幅に短縮できます。
③ 問題の切り分けができていなかった
「症状（動かない）」への対処ではなく「原因（Windowsビルドの非互換）」の特定が先です。切り分けができていれば、Pages→Workers→WSLという迂回路を歩かずに済みました。
この3つの構造ミスを避けるだけで、同じ6時間は2時間以下に短縮できます。 技術力の問題ではなく、確認の順序の問題です。ログを先に見る、条件を先に確認する、この2つの習慣が設計されていれば、迂回路は大幅に減ります。
関連記事
このシリーズを順番について読む
同じ構成でアプリを作りたい方へ
実際に使用した設計・判断基準・プロンプトをまとめています。
この記録を読んで「自分はどの段階から始めればいいか」と感じた方は、まず判断軸を確認してみてください。
- デプロイでエラーが出ている → この記事のセルフチェックから確認してみると絞り込みやすいです
- ローカルがまだ → 前の記事（ローカル開発編）の判断の分岐点から始めてみてください
Jogtimeは、設計によって変わりました。
では、あなたは今どの段階でしょうか？
- まず全体像を整理したい
- 構造を整えて伸ばしたい
- 設計から見直したい
今の状態に合わせて、次の一手を選んでください
コメント