😸

Next.js + PlaywrightアプリをAzureにデプロイする際にハマった5つの罠と解決策

に公開
Azure
deloy
tech

はじめに 👋

こんにちは！ 普段、Windows上のWSL2 (Ubuntu) 環境で開発している私ですが、最近Next.js + TypeScriptでAIツールの利用規約をPlaywrightを使ってリアルタイムにサーバーサイドでスクレイピングし、安全性などを評価するアプリを試作しました📝

ローカル（WSL）では順調に動作し、「さあ、これをAzure App Serviceにデプロイしよう！🚀」と作業を始めてエラー多発👼

この記事は、WSL上で開発したNext.js + Playwrightアプリを、GitHub Actionsを使ったCI/CDでAzure App Service (Linux) にデプロイする過程で、私が直面した5つの具体的なエラー（罠）とその解決策をまとめたものです。

同じような構成で開発している方の助けになれば幸いです！

罠1：App Service作成ウィザードの三重苦 😵

Azure PortalからApp Serviceリソースを作成しようとした最初のステップで、立て続けに3つのエラーに遭遇しました。

発生した問題 😫

  1. Quotaエラー: SubscriptionIsOverQuotaForSku - 「東日本」リージョンで作成しようとしたら、契約上のサーバー上限に達していると怒られました。
  2. 検証エラー: フォームの検証に失敗しました - Quotaを避けるためリージョンを変えても、今度はアプリ名が原因でエラーに。
  3. 権限エラー: 「継続的デプロイの有効化」ボタンがグレーアウトして押せず、CI/CDの自動設定ができない。

解決策 💡

これらの問題は、Azureの仕様を一つずつ理解することで解決できました。

  • Quotaエラー対策 ➡️ リージョン（地域）を変更する！
    エラーメッセージの通り、上限に達した「東日本」ではなく、「米国西部 (West US)」など、まだリソースを作成していない別のリージョンを選択することで、あっさり解決しました🌍

  • 検証エラー対策 ➡️ 世界でユニークな名前をつける！
    App Serviceの名前はURL (<名前>.azurewebsites.net) になるため、世界中の誰とも重複してはいけません。my-cool-appのような名前ではなく、my-cool-app-pompompurin-20250819のように、日付やニックネームを加えてユニークにすることで解決しました。✍️

  • 権限エラー対策 ➡️ 「先にリソース作成、後からデプロイ設定」の順番にする！
    アプリ作成と同時にCI/CD設定を行うには強い権限が必要な場合があります。そこで、一旦「継続的デプロイ」は無効のままApp Serviceリソースの作成を完了させ、その後に作成されたリソースの**「デプロイセンター」からGitHub連携を設定**することで、問題を回避できました。✅

罠2：「ローカルでは動くのに…」CI/CDでの厳格なビルドエラー 👮

リソース作成の問題をクリアし、いざGitHub Actionsで最初のデプロイ！…と思いきや、ビルドの段階で失敗。ログを見ると、TypeScript/ESLintからのエラーでした。

発生した問題 😱

The usage of require() for importing deepl-node is forbidden.
Avoid using any as a type.
The variable e is defined but never used in the catch block.

ローカルのnpm run devでは許容されていたコードの書き方が、本番用の厳格なビルドプロセスではルール違反と判断されてしまいました。

解決策 🔧

エラーログの指示に素直に従い、コードを修正する！
CI/CD環境は、コード品質を担保する「真面目な編集長」のようなものです。以下の修正を行い、コードをクリーンにしました。

  • require() ➡️ import 文に修正。
  • 安易な any 型の使用 ➡️ deepl.Translator のような具体的な型を指定。
  • catch(e) で使っていない変数 e ➡️ catch { ... } に変更。

この修正をgit pushすると、ビルドは無事に成功しました。✨

罠3：サーバー上でブラウザが見つからない！Playwrightのための追加設定 🤖

WSLというLinux環境で開発していたので、本番サーバーもLinuxを選んだのは自然な流れでした。しかし、Playwrightを動かすにはもう一手間必要でした。

発生した問題

Playwrightは、実行環境にChromiumなどのブラウザバイナリが必要です。Azure App Service (Linux) のビルド環境には、デフォルトではこれらがインストールされていません。

解決策 🛠️

postinstall スクリプトで、ビルド時にブラウザをインストールさせる！
package.jsonに以下のスクリプトを追加することで、npm installが実行された後に、Playwrightのブラウザと、Linux環境で必要な依存ライブラリを自動でインストールするようにしました。

package.json
"scripts": {
  "dev": "next dev",
  "build": "next build",
  "start": "next start",
  "lint": "next lint",
  "postinstall": "npx playwright install --with-deps"
}

--with-deps がLinux環境での安定動作の鍵です。忘れずに付けなければ！

罠4：デプロイ成功！のはずが「:( Application Error」🔥

GitHub Actionsで緑のチェックマークが付き、デプロイ成功！🎉 URLにアクセスすると、「Application Error」画面が…。

発生した問題

デプロイは完了したが、アプリが起動に失敗してクラッシュしていました。

解決策 🔑

環境変数を本番環境に設定する！
原因は、ローカルの.env.localファイルで管理していたAPIキー（DEEPL_API_KEY）が、Azureの環境に存在しなかったことでした。アプリは起動時にAPIキーを読み込もうとして失敗し、クラッシュしていたのです。

Azure Portalで、対象のApp Serviceの**「構成」→「アプリケーション設定」**を開き、DEEPL_API_KEYという名前でキーの値を設定し、保存することで解決しました。

教訓： process.env で読み込んでいる変数は、すべて本番環境の「アプリケーション設定」に登録が必要！

罠5：エラーの原因がわからない… Azureの「ログストリーム」が頼みの綱 📜

「Application Error」の原因がAPIキーだとすぐに分かったわけではありません。最初は本当に途方にくれました。その時に助けてくれたのが「ログストリーム」機能です。

発生した問題

「Application Error」という画面だけでは、なぜアプリがクラッシュしたのか具体的な理由が全く分からない。

解決策 👨‍🏫

「ログストリーム」で、アプリの生の声（ログ）を聞く！
App Serviceのメニューにある**「ログストリーム (Log stream)」**は、アプリの console.log やエラー出力をリアルタイムで表示してくれる、デバッグの命綱です。

実際にこの画面を開いてアプリにアクセスすると、TypeError: Cannot read properties of undefined のような、APIキーがundefinedであることに起因する具体的なエラーメッセージが表示され、原因を特定することができました。

まとめ

Azureでの初めてのデプロイ。何とかうまくいきました🎯
Happy Deploying! 🚀

Discussion