翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amplify の一般的な問題のトラブルシューティング
以下の情報は、Amplify ホスティングの一般的な問題のトラブルシューティングに役立ちます。
**Topics**
+ [HTTP 429 ステータスコード (リクエストが多すぎる)](#429-request-error)
+ [Amplify コンソールにアプリのビルドステータスと最終更新時間が表示されない](#build-status-not-displayed)
+ [新しいプルリクエストのウェブプレビューが作成されていない](#pull-request-previews)
+ [手動デプロイが Amplify コンソールで保留中のステータスでスタックしている](#manual-deployment-pending)
+ [アプリケーションの Node.js バージョンを更新する必要がある](#update-node-version)
## HTTP 429 ステータスコード (リクエストが多すぎる)
Amplify は、受信リクエストが消費する処理時間とデータ転送に基づいて、ウェブサイトへの 1 秒あたりのリクエスト数 (RPS) を制御します。アプリケーションが HTTP 429 ステータスコードを返した場合、受信リクエストは、アプリケーションに割り当てられた処理時間とデータ転送の時間を超えています。このアプリケーション制限は、Amplify の `REQUEST_TOKENS_PER_SECOND` サービスクォータによって管理されます。クォータの詳細については、「[Amplify ホスティング Service Quotas](quotas-chapter.md)」を参照してください。
この問題を修正するには、アプリを最適化してリクエスト期間とデータ転送を短縮し、アプリの RPS を増やすことをお勧めします。例えば、同じ 20,000 トークンでは、100 ミリ秒以内に応答する高度に最適化された SSR ページは、レイテンシーが 200 ミリ秒を超えるページと比較しても、より高い RPS をサポートできます。
同様に、1 MB の応答サイズを返すアプリケーションは、250 KB の応答サイズを返すアプリケーションよりも多くのトークンを消費します。
また、特定の応答がキャッシュに保持される時間を最大化するように Cache-Control ヘッダーを設定して、Amazon CloudFront キャッシュを活用することをお勧めします。CloudFront キャッシュから送信されるリクエストは、レート制限にはカウントされません。各 CloudFront ディストリビューションは 1 秒あたり最大 250,000 件のリクエストを処理できるため、キャッシュを使用してアプリケーションを大幅にスケールアップすることができます。CloudFront キャッシュの詳細については、「*Amazon CloudFront デベロッパーガイド*」の「[キャッシュの最適化と可用性](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ConfiguringCaching.html)」を参照してください。
## Amplify コンソールにアプリのビルドステータスと最終更新時間が表示されない
Amplify コンソールで **[すべてのアプリ]** ページに移動すると、現在のリージョンのアプリごとにタイルが表示されます。**Deployed** などのビルドステータスや、アプリに関して表示される**最終更新**時間などが表示されない場合、アプリには `Production` ステージブランチが関連付けられていません。
コンソールでアプリケーションを一覧表示するために、Amplify は `ListApps` API を使用します。Amplify は `ProductionBranch.status` 属性を使用してビルドステータスを表示し、`ProductionBranch.lastDeployTime` 属性を使用して最終更新時間を表示します。この API の詳細については、「*Amplify Hosting API のドキュメント*」の「[ProductionBranch](https://docs.aws.amazon.com/amplify/latest/APIReference/API_ProductionBranch.html)」を参照してください。
次の手順に従って、`Production` ステージをアプリケーションのブランチに関連付けます。
1. [Amplify コンソール](https://console.aws.amazon.com/amplify/home)にサインインします。
1. **[すべてのアプリ]** ページで、更新するアプリケーションを選択します。
1. ナビゲーションペインで **[アプリの設定]** を選択してから、**[ブランチ設定]** を選択します。
1. **[ブランチ設定]** セクションで、**[編集]** を選択します。
1. **[プロダクションブランチ]** で、使用するブランチの名前を選択します。
1. **[保存]** を選択します。
1. **[すべてのアプリ]** ページに戻ります。これで、アプリのビルドステータスと最終更新時間が表示されます。
## 新しいプルリクエストのウェブプレビューが作成されていない
ウェブプレビュー機能を使用すると、プルリクエストからの変更を、統合ブランチにマージする前にプレビューできます。Web プレビューは、リポジトリに対して行われたすべてのプルリクエストを、メインサイトが使用している URL とはまったく異なる固有のプレビュー URL にデプロイします。
アプリのウェブプレビューを有効にしても、新しい PR 用に作成されていない場合は、次のいずれかが問題の原因であるかどうかを調べます。
1. アプリが最大 `Branches per app` のサービスクォータに達したかどうかを確認します。クォータの詳細については、「[Amplify ホスティング Service Quotas](quotas-chapter.md)」を参照してください。
アプリごとに 50 ブランチのデフォルトのクォータ内に収まるようにするには、アプリで自動ブランチ削除を有効にすることを検討してください。これにより、リポジトリに存在しなくなったブランチがアカウントに蓄積されなくなります。
1. パブリック GitHub リポジトリを使用していて、Amplify アプリに IAM サービスロールがアタッチされている場合、Amplify はセキュリティ上の理由からプレビューを作成しません。例えば、バックエンドを備えたアプリや`WEB_COMPUTE`ホスティングプラットフォームにデプロイされるアプリには IAM サービスロールが必要です。そのため、これらの種類のアプリのリポジトリが公開されている場合、ウェブプレビューを有効にすることはできません。
ウェブプレビューをアプリで機能させるには、サービスロールの関連付けを解除するか (アプリにバックエンドがないか、`WEB_COMPUTE` アプリでない場合)、GitHub リポジトリをプライベートにすることができます。
## 手動デプロイが Amplify コンソールで保留中のステータスでスタックしている
手動デプロイを使用すると、Git プロバイダーに接続しなくても、Amplify ホスティングでウェブアプリケーションを公開できます。次の 4 つのデプロイオプションの 1 つを使用できます。
1. Amplify コンソールでアプリケーションフォルダをドラッグアンドドロップする。
1. Amplify コンソールで .zip ファイル (サイトのビルドアーティファクトを含む) をドラッグアンドドロップする。
1. .zip ファイル (サイトのビルドアーティファクトを含む) を Amazon S3 バケットにアップロードし、そのバケットを Amplify コンソールのアプリに接続する。
1. Amplify コンソールで、.zip ファイル (サイトのビルドアーティファクトを含む) を指すパブリック URL を使用する。
Amplify コンソールで手動デプロイにアプリケーションフォルダを使用する場合、ドラッグアンドドロップ機能に関する問題が認識されています。これらのデプロイは、次の理由で失敗する可能性があります。
+ 一時的なネットワークの問題が発生する。
+ アップロード中にファイルに対するローカルの変更がある。
+ ブラウザセッションが、大量の静的アセットを同時にアップロードしようとする。
ドラッグアンドドロップによるアップロードの信頼性の向上に取り組んでいますが、アプリケーションフォルダをドラッグアンドドロップするのではなく、.zip ファイルを使用することをお勧めします。
Amplify コンソールからのファイルのアップロードを回避し、手動デプロイの信頼性を高めるため、.zip ファイルを Amazon S3 バケットにアップロードすることを強くお勧めします。Amplify と Amazon S3 の統合により、このプロセスが簡素化されます。詳細については、「[Amazon S3 バケットから Amplify への静的ウェブサイトのデプロイ](deploy-website-from-s3.md)」を参照してください。
## アプリケーションの Node.js バージョンを更新する必要がある
Node.js バージョン 14、16、18 を使用するアプリケーションの Amplify サポートは、2025 年 9 月 15 日に終了します。この日付以降の動作は、アプリケーションタイプによって異なります。
+ SSR アプリケーション: 非推奨の Node.js バージョンを使用すると、ビルドエラーが発生します。Node.js 20 以降にアップグレードするまで、更新をデプロイすることはできません。
+ SSR アプリケーション以外: buildspec またはライブパッケージの更新を通じて手動でインストールした場合、非推奨の Node.js バージョンを引き続き使用できます。
既にデプロイされているアプリケーションは、Node.js のバージョンに関係なく引き続き実行されます。
Amazon Linux 2023 ビルドイメージを使用している場合、デフォルトで Node.js バージョン 20 がサポートされています。2025 年 9 月 15 日以降、AL2023 イメージは Node.js 22 を自動的にサポートし、デフォルトの Node.js バージョンを 18 から 22 に変更します。
Amazon Linux 2 (AL2) は、Node.js バージョン 20 以降を自動的にはサポートしません。現在 AL2 を使用している場合は、AL2023 に移行することをお勧めします。Amplify コンソールでビルドイメージを変更できます。指定した Node.js バージョンをサポートするカスタムビルドイメージを使用することもできます。
アップグレードする前に、新しいブランチでアプリケーションをテストして、正しく機能することを確認することをお勧めします。
**アップグレードオプション**
**Amplify コンソール**
Amplify コンソールの [ライブパッケージのアップデート] 機能を使用して、使用する Node.js のバージョンを指定できます。手順については、「[ビルドイメージでの特定のパッケージバージョンと依存関係バージョンの使用](custom-build-image.md#setup-live-updates)」を参照してください。
**カスタムビルドイメージ**
カスタムビルドイメージを使用していて、NVM がイメージにインストールされている場合は、Dockerfile に `nvm install 20` を追加できます。カスタムビルドイメージの要件と設定手順の詳細については、「[ビルドイメージのカスタマイズ](custom-build-image.md)」を参照してください。
**ビルド設定**
preBuild コマンドセクションに `nvm use` コマンドを追加することで、アプリケーションの `amplify.yml` ビルド設定で使用する Node.js バージョンを指定できます。アプリケーションのビルド設定を更新する手順については、「[Amplify アプリケーションのビルド設定の構成](build-settings.md)」を参照してください。
次の例は、ビルド設定をカスタマイズしてデフォルトの Node.js バージョンを Node.js 18 に設定し、`node-20` という名前のテストブランチで Node.js バージョン 20 にアップグレードする方法を示しています。
```
frontend:
phases:
preBuild:
commands:
- nvm use 18
- if [ "${AWS_BRANCH}" = "node-20" ]; then nvm use 20; fi
```
`preBuild` コマンドは、ライブパッケージの更新後に実行されることに注意してください。`nvm use` コマンドで指定された Node.js バージョンは、ライブパッケージの更新で設定された Node.js バージョンを上書きします。