diff --git a/docs/01-app/01-getting-started/11-deploying.mdx b/docs/01-app/01-getting-started/11-deploying.mdx
index d4c44ae0..d6f48c08 100644
--- a/docs/01-app/01-getting-started/11-deploying.mdx
+++ b/docs/01-app/01-getting-started/11-deploying.mdx
@@ -1,19 +1,19 @@
---
-title: 'Next.js アプリケーションのデプロイ方法'
+title: 'Next.jsアプリケーションのデプロイ方法'
nav_title: 'デプロイ'
-description: 'Next.js アプリケーションのデプロイ方法を学びましょう。'
+description: 'Next.jsアプリケーションのデプロイ方法を学びましょう。'
---
-Next.js アプリのデプロイ準備が整ったら、[マネージドインフラストラクチャプロバイダー](#managed-infrastructure-providers)を選択するか、アプリケーションを[セルフホスティング](#self-hosting)することができます。
+Next.jsアプリのデプロイ準備が整ったら、[マネージドインフラストラクチャプロバイダー](#managed-infrastructure-providers)を選ぶか、アプリケーションを[セルフホスティング](#self-hosting)することができます。
## マネージドインフラストラクチャプロバイダー {#managed-infrastructure-providers}
-マネージドプラットフォームは、Next.js アプリをデプロイするための実用的なオプションです。これらのプロバイダーは、ホスティング、スケーリング、サーバー構成を代行してくれます。
+マネージドプラットフォームは、Next.jsアプリをデプロイするための実用的なオプションです。これらのプロバイダーは、ホスティング、スケーリング、サーバー構成を代行してくれます。
-Next.js の作成者およびメンテナーである [Vercel](https://vercel.com/docs/frameworks/nextjs?utm_source=next-site&utm_medium=docs&utm_campaign=next-website) は、**フル機能サポート**と**ゼロ構成**でアプリケーションをデプロイすることができます。
+Next.jsの開発者およびメンテナーである[Vercel](https://vercel.com/docs/frameworks/nextjs?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)は、**フル機能サポート**と**ゼロ構成**でアプリケーションをデプロイすることができます。
-- [Vercel 上の Next.js についてさらに学ぶ](https://vercel.com/docs/frameworks/nextjs?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)
-- [テンプレートをデプロイして](https://vercel.com/templates/next.js?utm_source=next-site&utm_medium=docs&utm_campaign=next-website) Vercel 上で Next.js を試す
+- [VercelでのNext.js](https://vercel.com/docs/frameworks/nextjs?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)について詳しく学ぶ
+- [テンプレートをデプロイ](https://vercel.com/templates/next.js?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)してVercelでNext.jsを試す
また、以下のコミュニティが管理するデプロイテンプレートもあります:
@@ -23,21 +23,21 @@ Next.js の作成者およびメンテナーである [Vercel](https://vercel.co
- [Render](https://github.com/nextjs/deploy-render)
- [SST](https://github.com/nextjs/deploy-sst)
-各プロバイダーのドキュメントを参照して、サポートされている Next.js の機能についての情報を確認してください。
+各プロバイダーのドキュメントを参照して、サポートされているNext.jsの機能についての情報を確認してください。
## セルフホスティング {#self-hosting}
-セルフホスティングは、独自のサーバーのプロビジョニング、コンテナの管理、スケーリングを担当することを意味するかもしれません。Next.js をセルフホスティングする方法は3つあります:
+セルフホスティングは、独自のサーバーのプロビジョニング、コンテナの管理、スケーリングを自分で行うことを意味するかもしれません。Next.jsをセルフホスティングする方法は3つあります:
-- [Node.js サーバー](/docs/app/building-your-application/deploying#nodejs-server)
-- [Docker コンテナ](/docs/app/building-your-application/deploying#docker-image)
-- [静的エクスポート](/docs/app/building-your-application/deploying#static-html-export)
+- [Node.jsサーバー](/docs/app/guides/self-hosting#nodejs-server)
+- [Dockerコンテナ](/docs/app/guides/self-hosting#docker-image)
+- [静的エクスポート](/docs/app/guides/self-hosting#static-html-export)
-以下のセルフホスティングプロバイダーに関するコミュニティが管理するデプロイ例があります:
+以下のセルフホスティングプロバイダーでのコミュニティが管理するデプロイ例があります:
- [DigitalOcean](https://github.com/nextjs/deploy-digitalocean)
- [Fly.io](https://github.com/nextjs/deploy-fly)
- [GitHub Pages](https://github.com/nextjs/deploy-github-pages)
- [Google Cloud Run](https://github.com/nextjs/deploy-google-cloud-run)
-> **🎥 視聴:** Next.js のセルフホスティングについてさらに学ぶ → [YouTube (45 分)](https://www.youtube.com/watch?v=sIVL4JMqRfc)
+> **🎥 視聴:** Next.jsのセルフホスティングについて詳しく学ぶ → [YouTube (45分)](https://www.youtube.com/watch?v=sIVL4JMqRfc).
diff --git a/docs/01-app/03-building-your-application/09-authentication/index.mdx b/docs/01-app/02-guides/authentication.mdx
similarity index 85%
rename from docs/01-app/03-building-your-application/09-authentication/index.mdx
rename to docs/01-app/02-guides/authentication.mdx
index 53b9abc3..b6a87227 100644
--- a/docs/01-app/03-building-your-application/09-authentication/index.mdx
+++ b/docs/01-app/02-guides/authentication.mdx
@@ -1,13 +1,14 @@
---
-title: 'Authentication'
-description: 'Next.jsアプリケーションでの認証の実装方法を学びます。'
+title: 'Next.jsで認証を実装する方法'
+nav_title: 'Authentication'
+description: 'Next.jsアプリケーションで認証を実装する方法を学びます。'
---
-アプリケーションのデータを保護するためには、認証を理解することが重要です。このページでは、認証を実装するために使用するReactとNext.jsの機能について説明します。
+認証を理解することは、アプリケーションのデータを保護するために重要です。このページでは、認証を実装するために使用するReactとNext.jsの機能について説明します。
始める前に、プロセスを3つの概念に分解すると役立ちます:
-1. **[Authentication](#authentication)**: ユーザーが自分が主張する人物であるかどうかを確認します。ユーザーは、ユーザー名とパスワードなど、何かを持っているもので自分の身元を証明する必要があります。
+1. **[Authentication](#authentication)**: ユーザーが自分が主張する人物であるかどうかを確認します。ユーザーは、ユーザー名とパスワードなど、何かを持っていることで自分の身元を証明する必要があります。
2. **[Session Management](#session-management)**: リクエスト間でユーザーの認証状態を追跡します。
3. **[Authorization](#authorization)**: ユーザーがアクセスできるルートとデータを決定します。
@@ -21,7 +22,7 @@ description: 'Next.jsアプリケーションでの認証の実装方法を学
height="1383"
/>
-このページの例では、教育目的で基本的なユーザー名とパスワードの認証を説明します。カスタム認証ソリューションを実装することもできますが、セキュリティとシンプルさを向上させるために、認証ライブラリの使用をお勧めします。これらは、認証、セッション管理、認可のための組み込みソリューションを提供し、ソーシャルログイン、多要素認証、役割ベースのアクセス制御などの追加機能も提供します。[Auth Libraries](#auth-libraries)セクションでリストを見つけることができます。
+このページの例では、教育目的で基本的なユーザー名とパスワードの認証を説明します。カスタム認証ソリューションを実装することもできますが、セキュリティとシンプルさを向上させるために、認証ライブラリを使用することをお勧めします。これらは、認証、セッション管理、認可のための組み込みソリューションを提供し、ソーシャルログイン、多要素認証、役割ベースのアクセス制御などの追加機能も提供します。[Auth Libraries](#auth-libraries)セクションでリストを見つけることができます。
## Authentication {#authentication}
@@ -37,7 +38,7 @@ Server Actionsは常にサーバー上で実行されるため、認証ロジッ
#### 1. ユーザーの資格情報をキャプチャする {#1-capture-user-credentials}
-ユーザーの資格情報をキャプチャするには、送信時にServer Actionを呼び出すフォームを作成します。たとえば、ユーザーの名前、メールアドレス、パスワードを受け付けるサインアップフォームです:
+ユーザーの資格情報をキャプチャするには、送信時にServer Actionを呼び出すフォームを作成します。たとえば、ユーザーの名前、メールアドレス、パスワードを受け付けるサインアップフォーム:
@@ -117,7 +118,7 @@ export async function signup(formData) {}
Server Actionを使用して、サーバー上でフォームフィールドを検証します。認証プロバイダーがフォーム検証を提供していない場合は、[Zod](https://zod.dev/)や[Yup](https://github.com/jquense/yup)のようなスキーマ検証ライブラリを使用できます。
-Zodを例にとると、適切なエラーメッセージを含むフォームスキーマを定義できます:
+Zodを例にとると、適切なエラーメッセージを持つフォームスキーマを定義できます:
@@ -181,7 +182,7 @@ export const SignupFormSchema = z.object({
-フォームフィールドが定義されたスキーマに一致しない場合、認証プロバイダーのAPIやデータベースへの不要な呼び出しを防ぐために、Server Actionで早期に`return`することができます。
+フォームフィールドが定義されたスキーマに一致しない場合、Server Actionで早期に`return`して、認証プロバイダーのAPIやデータベースへの不要な呼び出しを防ぐことができます。
@@ -400,7 +401,7 @@ export async function signup(state, formData) {
// 例:ユーザーのパスワードを保存する前にハッシュ化する
const hashedPassword = await bcrypt.hash(password, 10)
- // 3. データベースにユーザーを挿入するか、Library APIを呼び出す
+ // 3. データベースにユーザーを挿入するか、Auth LibraryのAPIを呼び出す
const data = await db
.insert(users)
.values({
@@ -431,8 +432,8 @@ export async function signup(state, formData) {
> **Tips:**
>
-> - 上記の例は教育目的で認証ステップを詳細に説明しているため冗長です。独自の安全なソリューションを実装することはすぐに複雑になる可能性があることを強調しています。プロセスを簡素化するために[Auth Library](#auth-libraries)の使用を検討してください。
-> - ユーザーエクスペリエンスを向上させるために、登録フローの早い段階で重複するメールアドレスやユーザー名を確認することを検討してください。たとえば、ユーザーがユーザー名を入力しているときや入力フィールドがフォーカスを失ったときです。これにより、不要なフォーム送信を防ぎ、ユーザーに即時のフィードバックを提供できます。[use-debounce](https://www.npmjs.com/package/use-debounce)などのライブラリを使用して、これらのチェックの頻度を管理することができます。
+> - 上記の例は、教育目的で認証ステップを分解しているため冗長です。これにより、独自の安全なソリューションを実装することが迅速に複雑になることが強調されます。プロセスを簡素化するために[Auth Library](#auth-libraries)を使用することを検討してください。
+> - ユーザーエクスペリエンスを向上させるために、登録フローの早い段階で重複するメールアドレスやユーザー名を確認することを検討してください。たとえば、ユーザーがユーザー名を入力しているときや入力フィールドがフォーカスを失ったときに行うことができます。これにより、不要なフォーム送信を防ぎ、ユーザーに即時のフィードバックを提供できます。[use-debounce](https://www.npmjs.com/package/use-debounce)などのライブラリを使用して、これらのチェックの頻度を管理するためにリクエストをデバウンスすることができます。
@@ -440,7 +441,7 @@ export async function signup(state, formData) {
サインアップおよび/またはログインフォームを実装する手順は次のとおりです:
-1. ユーザーがフォームを通じて資格情報を送信します。
+1. ユーザーはフォームを通じて資格情報を送信します。
2. フォームはAPIルートによって処理されるリクエストを送信します。
3. 検証が成功すると、プロセスが完了し、ユーザーの認証が成功したことを示します。
4. 検証が失敗した場合、エラーメッセージが表示されます。
@@ -530,9 +531,9 @@ export default function LoginPage() {
-上記のフォームには、ユーザーのメールアドレスとパスワードをキャプチャするための2つの入力フィールドがあります。送信時に、APIルート(`/api/auth/login`)にPOSTリクエストを送信する関数をトリガーします。
+上記のフォームには、ユーザーのメールアドレスとパスワードをキャプチャするための2つの入力フィールドがあります。送信時に、`/api/auth/login`というAPIルートにPOSTリクエストを送信する関数をトリガーします。
-次に、APIルートで認証を処理するために認証プロバイダーのAPIを呼び出すことができます:
+その後、APIルートで認証を処理するために認証プロバイダーのAPIを呼び出すことができます:
@@ -610,7 +611,7 @@ export default async function handler(req, res) {
上記に加えて、ユーザーがアプリケーションに戻ったときにセッションを[更新(またはリフレッシュ)](#updating-or-refreshing-sessions)し、ユーザーがログアウトしたときにセッションを[削除](#deleting-the-session)する機能を追加することを検討してください。
-> **Good to know:** [auth library](#auth-libraries)がセッション管理を含んでいるかどうかを確認してください。
+> **Good to know:** [auth library](#auth-libraries)にセッション管理が含まれているかどうかを確認してください。
#### 1. 秘密鍵の生成 {#1-generating-a-secret-key}
@@ -626,7 +627,7 @@ openssl rand -base64 32
SESSION_SECRET=your_secret_key
```
-次に、この鍵をセッション管理ロジックで参照できます:
+その後、この鍵をセッション管理ロジックで参照できます:
```js title="app/lib/session.js"
const secretKey = process.env.SESSION_SECRET
@@ -710,7 +711,7 @@ export async function decrypt(session) {
- **HttpOnly**: クライアント側のJavaScriptがcookieにアクセスするのを防ぎます。
- **Secure**: httpsを使用してcookieを送信します。
-- **SameSite**: cookieがクロスサイトリクエストで送信できるかどうかを指定します。
+- **SameSite**: cookieがクロスサイトリクエストと共に送信できるかどうかを指定します。
- **Max-AgeまたはExpires**: 一定期間後にcookieを削除します。
- **Path**: cookieのURLパスを定義します。
@@ -775,7 +776,7 @@ export async function signup(state: FormState, formData: FormData) {
// 前のステップ:
// 1. フォームフィールドを検証する
// 2. データベースへの挿入のためのデータを準備する
- // 3. データベースにユーザーを挿入するか、Library APIを呼び出す
+ // 3. データベースにユーザーを挿入するか、Auth LibraryのAPIを呼び出す
// 現在のステップ:
// 4. ユーザーセッションを作成する
@@ -795,7 +796,7 @@ export async function signup(state, formData) {
// 前のステップ:
// 1. フォームフィールドを検証する
// 2. データベースへの挿入のためのデータを準備する
- // 3. データベースにユーザーを挿入するか、Library APIを呼び出す
+ // 3. データベースにユーザーを挿入するか、Auth LibraryのAPIを呼び出す
// 現在のステップ:
// 4. ユーザーセッションを作成する
@@ -912,7 +913,7 @@ export async function deleteSession() {
-次に、アプリケーションで`deleteSession()`関数を再利用できます。たとえば、ログアウト時に:
+その後、アプリケーション内で`deleteSession()`関数を再利用できます。たとえば、ログアウト時に:
@@ -1011,7 +1012,7 @@ export default function handler(req, res) {
-例:
+たとえば:
@@ -1094,10 +1095,10 @@ export async function createSession(id) {
> **Tips**:
>
-> - データの取得を高速化するために、[Vercel Redis](https://vercel.com/docs/storage/vercel-kv)のようなデータベースを使用することを検討してください。ただし、セッションデータをプライマリデータベースに保持し、データリクエストを組み合わせてクエリの数を減らすこともできます。
-> - より高度なユースケースのためにデータベースセッションを使用することを選択するかもしれません。たとえば、ユーザーが最後にログインした時間を追跡したり、アクティブなデバイスの数を追跡したり、ユーザーにすべてのデバイスからログアウトする機能を提供したりすることができます。
+> - より高速なデータ取得のために、[Vercel Redis](https://vercel.com/docs/storage/vercel-kv)のようなデータベースを使用することを検討してください。ただし、セッションデータをプライマリデータベースに保持し、データリクエストを組み合わせてクエリの数を減らすこともできます。
+> - より高度なユースケースのために、データベースセッションを使用することを選択することができます。たとえば、ユーザーが最後にログインした時間やアクティブなデバイスの数を追跡したり、ユーザーにすべてのデバイスからログアウトする機能を提供したりすることができます。
-セッション管理を実装した後、アプリケーション内でユーザーがアクセスできるものとできることを制御するための認可ロジックを追加する必要があります。[Authorization](#authorization)セクションに進んで詳細を学びましょう。
+セッション管理を実装した後、アプリケーション内でユーザーがアクセスできる内容と実行できる操作を制御するための認可ロジックを追加する必要があります。[Authorization](#authorization)セクションに進んで詳細を学びましょう。
@@ -1162,29 +1163,29 @@ export default async function handler(req, res) {
## Authorization {#authorization}
-ユーザーが認証され、セッションが作成された後、アプリケーション内でユーザーがアクセスできるものとできることを制御するために認可を実装できます。
+ユーザーが認証され、セッションが作成された後、アプリケーション内でユーザーがアクセスできる内容と実行できる操作を制御するために認可を実装できます。
認可チェックには2つの主要なタイプがあります:
-1. **Optimistic**: cookieに保存されたセッションデータを使用して、ユーザーがルートにアクセスしたりアクションを実行したりする権限があるかどうかを確認します。これらのチェックは、UI要素の表示/非表示や、権限や役割に基づくユーザーのリダイレクトなどの迅速な操作に役立ちます。
-2. **Secure**: データベースに保存されたセッションデータを使用して、ユーザーがルートにアクセスしたりアクションを実行したりする権限があるかどうかを確認します。これらのチェックはより安全で、機密データやアクションへのアクセスが必要な操作に使用されます。
+1. **Optimistic**: cookieに保存されたセッションデータを使用して、ユーザーがルートにアクセスしたりアクションを実行したりする権限があるかどうかを確認します。これらのチェックは、UI要素の表示/非表示や、権限や役割に基づいてユーザーをリダイレクトするなどの迅速な操作に役立ちます。
+2. **Secure**: データベースに保存されたセッションデータを使用して、ユーザーがルートにアクセスしたりアクションを実行したりする権限があるかどうかを確認します。これらのチェックはより安全で、機密データへのアクセスやアクションを必要とする操作に使用されます。
どちらの場合も、次のことをお勧めします:
-- 認可ロジックを集中化するための[Data Access Layer](#creating-a-data-access-layer-dal)を作成する
+- 認可ロジックを集中化するために[Data Access Layer](#creating-a-data-access-layer-dal)を作成する
- 必要なデータのみを返すために[Data Transfer Objects (DTO)](#using-data-transfer-objects-dto)を使用する
-- 楽観的なチェックを行うために[Middleware](#optimistic-checks-with-middleware-optional)をオプションで使用する。
+- オプションで[Middleware](#optimistic-checks-with-middleware-optional)を使用して楽観的なチェックを実行する。
-### 楽観的なチェックを行うMiddleware(オプション) {#optimistic-checks-with-middleware-optional}
+### Middlewareを使用した楽観的なチェック(オプション) {#optimistic-checks-with-middleware-optional}
[Middleware](/docs/app/building-your-application/routing/middleware)を使用して、権限に基づいてユーザーをリダイレクトする場合があります:
-- 楽観的なチェックを行うため。Middlewareはすべてのルートで実行されるため、リダイレクトロジックを集中化し、許可されていないユーザーを事前にフィルタリングするのに適しています。
+- 楽観的なチェックを実行するため。Middlewareはすべてのルートで実行されるため、リダイレクトロジックを集中化し、許可されていないユーザーを事前にフィルタリングするのに適しています。
- ユーザー間でデータを共有する静的ルートを保護するため(例:ペイウォールの背後にあるコンテンツ)。
ただし、Middlewareはすべてのルートで実行され、[prefetched](/docs/app/building-your-application/routing/linking-and-navigating#2-prefetching)ルートも含まれるため、パフォーマンスの問題を防ぐために、cookieからセッションを読み取るだけにする(楽観的なチェック)ことが重要です。データベースチェックを避けることが重要です。
-例:
+たとえば:
@@ -1285,7 +1286,7 @@ Middlewareは初期チェックに役立ちますが、データを保護する
>
> - Middlewareでは、`req.cookies.get('session').value`を使用してcookieを読み取ることもできます。
> - Middlewareは[Edge Runtime](/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes)を使用します。認証ライブラリとセッション管理ライブラリが互換性があるかどうかを確認してください。
-> - Middlewareの`matcher`プロパティを使用して、Middlewareが実行されるルートを指定できます。ただし、認証のためには、Middlewareがすべてのルートで実行されることをお勧めします。
+> - Middlewareの`matcher`プロパティを使用して、Middlewareが実行されるルートを指定できます。ただし、認証のために、Middlewareがすべてのルートで実行されることをお勧めします。
@@ -1295,7 +1296,7 @@ Middlewareは初期チェックに役立ちますが、データを保護する
DALには、アプリケーションと対話する際にユーザーのセッションを検証する関数を含める必要があります。少なくとも、関数はセッションが有効かどうかを確認し、ユーザー情報を返すか、リダイレクトする必要があります。
-たとえば、DAL用の別のファイルを作成し、`verifySession()`関数を含めます。次に、Reactの[cache](https://react.dev/reference/react/cache) APIを使用して、Reactのレンダーパス中に関数の戻り値をメモ化します:
+たとえば、DAL用の別のファイルを作成し、`verifySession()`関数を含めます。その後、Reactの[cache](https://react.dev/reference/react/cache) APIを使用して、Reactのレンダリングパス中に関数の戻り値をメモ化します:
@@ -1342,7 +1343,7 @@ export const verifySession = cache(async () => {
-次に、データリクエスト、Server Actions、Route Handlersで`verifySession()`関数を呼び出すことができます:
+その後、データリクエスト、Server Actions、Route Handlersで`verifySession()`関数を呼び出すことができます:
@@ -1355,7 +1356,7 @@ export const getUser = cache(async () => {
try {
const data = await db.query.users.findMany({
where: eq(users.id, session.userId),
- // 必要なカラムのみを明示的に返す
+ // 必要な列のみを明示的に返す
columns: {
id: true,
name: true,
@@ -1384,7 +1385,7 @@ export const getUser = cache(async () => {
try {
const data = await db.query.users.findMany({
where: eq(users.id, session.userId),
- // 必要なカラムのみを明示的に返す
+ // 必要な列のみを明示的に返す
columns: {
id: true,
name: true,
@@ -1407,15 +1408,15 @@ export const getUser = cache(async () => {
> **Tip**:
>
-> - DALはリクエスト時にデータを保護するために使用できます。ただし、ユーザー間でデータを共有する静的ルートの場合、データはビルド時にフェッチされ、リクエスト時にはフェッチされません。[Middleware](#optimistic-checks-with-middleware-optional)を使用して静的ルートを保護します。
-> - セキュアなチェックのために、セッションIDをデータベースと比較してセッションが有効かどうかを確認できます。Reactの[cache](https://react.dev/reference/react/cache)関数を使用して、レンダーパス中にデータベースへの不要な重複リクエストを回避します。
-> - 関連するデータリクエストをJavaScriptクラスに統合し、メソッドを実行する前に`verifySession()`を実行することを検討するかもしれません。
+> - DALはリクエスト時にフェッチされるデータを保護するために使用できます。ただし、ユーザー間でデータを共有する静的ルートの場合、データはビルド時にフェッチされ、リクエスト時にはフェッチされません。静的ルートを保護するために[Middleware](#optimistic-checks-with-middleware-optional)を使用してください。
+> - セキュアなチェックのために、データベースとセッションIDを比較してセッションが有効かどうかを確認できます。Reactの[cache](https://react.dev/reference/react/cache)関数を使用して、レンダリングパス中にデータベースへの不要な重複リクエストを回避します。
+> - 関連するデータリクエストをJavaScriptクラスに統合し、メソッドを実行する前に`verifySession()`を実行することを検討することができます。
### Data Transfer Objects (DTO)の使用 {#using-data-transfer-objects-dto}
-データを取得する際には、アプリケーションで使用される必要なデータのみを返し、オブジェクト全体を返さないことをお勧めします。たとえば、ユーザーデータをフェッチする場合、ユーザーのIDと名前のみを返し、パスワードや電話番号などを含むユーザーオブジェクト全体を返さないかもしれません。
+データを取得する際には、アプリケーションで使用される必要なデータのみを返し、オブジェクト全体を返さないことをお勧めします。たとえば、ユーザーデータをフェッチする場合、ユーザーのIDと名前のみを返すことができます。これにより、パスワード、電話番号などを含む可能性のあるユーザーオブジェクト全体を返すことを避けることができます。
-ただし、返されるデータ構造を制御できない場合や、チームで作業している場合で、クライアントに全体のオブジェクトが渡されるのを避けたい場合は、クライアントに公開しても安全なフィールドを指定するなどの戦略を使用できます。
+ただし、返されるデータ構造を制御できない場合や、チームで作業している場合で、クライアントにオブジェクト全体が渡されるのを避けたい場合は、クライアントに公開しても安全なフィールドを指定するなどの戦略を使用できます。
@@ -1435,13 +1436,13 @@ function canSeePhoneNumber(viewer: User, team: string) {
export async function getProfileDTO(slug: string) {
const data = await db.query.users.findMany({
where: eq(users.slug, slug),
- // 特定のカラムをここで返す
+ // ここで特定の列を返す
})
const user = data[0]
const currentUser = await getUser(user.id)
- // または、クエリに特化したものをここで返す
+ // または、ここでクエリに特化したものを返す
return {
username: canSeeUsername(currentUser) ? user.username : null,
phonenumber: canSeePhoneNumber(currentUser, user.team)
@@ -1469,13 +1470,13 @@ function canSeePhoneNumber(viewer, team) {
export async function getProfileDTO(slug) {
const data = await db.query.users.findMany({
where: eq(users.slug, slug),
- // 特定のカラムをここで返す
+ // ここで特定の列を返す
})
const user = data[0]
const currentUser = await getUser(user.id)
- // または、クエリに特化したものをここで返す
+ // または、ここでクエリに特化したものを返す
return {
username: canSeeUsername(currentUser) ? user.username : null,
phonenumber: canSeePhoneNumber(currentUser, user.team)
@@ -1488,16 +1489,16 @@ export async function getProfileDTO(slug) {
-データリクエストと認可ロジックをDALに集中化し、DTOを使用することで、すべてのデータリクエストが安全で一貫性があることを保証し、アプリケーションがスケールするにつれて、メンテナンス、監査、デバッグが容易になります。
+データリクエストと認可ロジックをDALに集中化し、DTOを使用することで、すべてのデータリクエストが安全で一貫性があり、アプリケーションがスケールするにつれてメンテナンス、監査、デバッグが容易になります。
> **Good to know**:
>
-> - DTOを定義する方法はいくつかあります。`toJSON()`を使用する方法、上記の例のように個別の関数を使用する方法、またはJSクラスを使用する方法です。これらはJavaScriptのパターンであり、ReactやNext.jsの機能ではないため、アプリケーションに最適なパターンを見つけるために調査することをお勧めします。
+> - DTOを定義する方法はいくつかあります。`toJSON()`を使用する方法、上記の例のような個別の関数、またはJSクラスを使用する方法です。これらはJavaScriptのパターンであり、ReactやNext.jsの機能ではないため、アプリケーションに最適なパターンを見つけるために調査することをお勧めします。
> - [Security in Next.js article](https://nextjs.org/blog/security-nextjs-server-components-actions)でセキュリティのベストプラクティスについて詳しく学びましょう。
### Server Components {#server-components}
-[Server Components](/docs/app/building-your-application/rendering/server-components)での認証チェックは、役割ベースのアクセスに役立ちます。たとえば、ユーザーの役割に基づいてコンポーネントを条件付きでレンダリングする場合:
+[Server Components](/docs/app/building-your-application/rendering/server-components)での認証チェックは、役割ベースのアクセスに役立ちます。たとえば、ユーザーの役割に基づいてコンポーネントを条件付きでレンダリングする:
@@ -1546,7 +1547,7 @@ export default function Dashboard() {
### レイアウトと認証チェック {#layouts-and-auth-checks}
-[Partial Rendering](/docs/app/building-your-application/routing/linking-and-navigating#4-partial-rendering)のため、[Layouts](/docs/app/building-your-application/routing/layouts-and-templates)でチェックを行う際には注意が必要です。これらはナビゲーション時に再レンダリングされないため、ユーザーセッションはすべてのルート変更時にチェックされません。
+[Partial Rendering](/docs/app/building-your-application/routing/linking-and-navigating#4-partial-rendering)のため、[Layouts](/docs/app/building-your-application/routing/layouts-and-templates)でチェックを行う際には注意が必要です。これらはナビゲーション時に再レンダリングされないため、ユーザーセッションはルート変更ごとにチェックされません。
代わりに、データソースや条件付きでレンダリングされるコンポーネントに近い場所でチェックを行うべきです。
@@ -1671,7 +1672,7 @@ export async function serverAction() {
[Route Handlers](/docs/app/building-your-application/routing/route-handlers)を公開APIエンドポイントと同じセキュリティ考慮事項で扱い、ユーザーがRoute Handlerにアクセスする権限があるかどうかを確認します。
-例:
+たとえば:
@@ -1683,19 +1684,19 @@ export async function GET() {
// ユーザー認証と役割の確認
const session = await verifySession()
- // ユーザーが認証されているか確認
+ // ユーザーが認証されているかどうかを確認する
if (!session) {
// ユーザーが認証されていない
return new Response(null, { status: 401 })
}
- // ユーザーが'admin'役割を持っているか確認
+ // ユーザーが'admin'役割を持っているかどうかを確認する
if (session.user.role !== 'admin') {
// ユーザーは認証されているが、適切な権限を持っていない
return new Response(null, { status: 403 })
}
- // 認可されたユーザーのために続行
+ // 認可されたユーザーのために続行する
}
```
@@ -1709,26 +1710,26 @@ export async function GET() {
// ユーザー認証と役割の確認
const session = await verifySession()
- // ユーザーが認証されているか確認
+ // ユーザーが認証されているかどうかを確認する
if (!session) {
// ユーザーが認証されていない
return new Response(null, { status: 401 })
}
- // ユーザーが'admin'役割を持っているか確認
+ // ユーザーが'admin'役割を持っているかどうかを確認する
if (session.user.role !== 'admin') {
// ユーザーは認証されているが、適切な権限を持っていない
return new Response(null, { status: 403 })
}
- // 認可されたユーザーのために続行
+ // 認可されたユーザーのために続行する
}
```
-上記の例は、2段階のセキュリティチェックを備えたRoute Handlerを示しています。最初にアクティブなセッションを確認し、次にログインしているユーザーが'admin'であるかどうかを確認します。
+上記の例は、2段階のセキュリティチェックを備えたRoute Handlerを示しています。まず、アクティブなセッションを確認し、次にログインしているユーザーが'admin'であるかどうかを確認します。
## Context Providers {#context-providers}
@@ -1786,7 +1787,7 @@ export default function Profile() {
}
```
-クライアントコンポーネントでセッションデータが必要な場合(例:クライアントサイドのデータフェッチ)、Reactの[`taintUniqueValue`](https://react.dev/reference/react/experimental_taintUniqueValue) APIを使用して、クライアントに機密セッションデータが公開されないようにします。
+セッションデータがClient Componentsで必要な場合(例:クライアントサイドのデータフェッチ)、Reactの[`taintUniqueValue`](https://react.dev/reference/react/experimental_taintUniqueValue) APIを使用して、クライアントに機密セッションデータが公開されないようにします。
@@ -1812,7 +1813,7 @@ export default async function handler(
) {
const session = await getSession(req)
- // ユーザーが認証されているか確認
+ // ユーザーが認証されているかどうかを確認する
if (!session) {
res.status(401).json({
error: 'User is not authenticated',
@@ -1820,7 +1821,7 @@ export default async function handler(
return
}
- // ユーザーが'admin'役割を持っているか確認
+ // ユーザーが'admin'役割を持っているかどうかを確認する
if (session.user.role !== 'admin') {
res.status(401).json({
error: 'Unauthorized access: User does not have admin privileges.',
@@ -1828,7 +1829,7 @@ export default async function handler(
return
}
- // 認可されたユーザーのためにルートを続行
+ // 認可されたユーザーのためにルートを続行する
// ... API Routeの実装
}
```
@@ -1840,7 +1841,7 @@ export default async function handler(
export default async function handler(req, res) {
const session = await getSession(req)
- // ユーザーが認証されているか確認
+ // ユーザーが認証されているかどうかを確認する
if (!session) {
res.status(401).json({
error: 'User is not authenticated',
@@ -1848,15 +1849,15 @@ export default async function handler(req, res) {
return
}
- // ユーザーが'admin'役割を持っているか確認
+ // ユーザーが'admin'役割を持っているかどうかを確認する
if (session.user.role !== 'admin') {
- res.status: 401).json({
+ res.status(401).json({
error: 'Unauthorized access: User does not have admin privileges.',
})
return
}
- // 認可されたユーザーのためにルートを続行
+ // 認可されたユーザーのためにルートを続行する
// ... API Routeの実装
}
```
@@ -1864,13 +1865,13 @@ export default async function handler(req, res) {
-この例は、認証と認可のための2段階のセキュリティチェックを備えたAPI Routeを示しています。最初にアクティブなセッションを確認し、次にログインしているユーザーが'admin'であるかどうかを確認します。このアプローチは、リクエスト処理のために認証され、認可されたユーザーに限定された安全なアクセスを保証します。
+この例は、認証と認可の2段階のセキュリティチェックを備えたAPI Routeを示しています。まず、アクティブなセッションを確認し、次にログインしているユーザーが'admin'であるかどうかを確認します。このアプローチは、認証され、認可されたユーザーに限定された安全なアクセスを保証し、リクエスト処理の堅牢なセキュリティを維持します。
## Resources {#resources}
-Next.jsでの認証について学んだ今、セキュアな認証とセッション管理を実装するのに役立つNext.js互換のライブラリとリソースを紹介します:
+Next.jsでの認証について学んだ今、Next.jsと互換性のあるライブラリやリソースを使用して、安全な認証とセッション管理を実装するのに役立つ情報を以下に示します:
### Auth Libraries {#auth-libraries}
@@ -1892,7 +1893,7 @@ Next.jsでの認証について学んだ今、セキュアな認証とセッシ
## Further Reading {#further-reading}
-認証とセキュリティについてさらに学ぶために、次のリソースをチェックしてください:
+認証とセキュリティについて学び続けるために、以下のリソースをチェックしてください:
- [How to think about security in Next.js](https://nextjs.org/blog/security-nextjs-server-components-actions)
- [Understanding XSS Attacks](https://vercel.com/guides/understanding-xss-attacks)
diff --git a/docs/01-app/02-guides/ci-build-caching.mdx b/docs/01-app/02-guides/ci-build-caching.mdx
new file mode 100644
index 00000000..be5f708f
--- /dev/null
+++ b/docs/01-app/02-guides/ci-build-caching.mdx
@@ -0,0 +1,169 @@
+---
+title: 'Continuous Integration (CI) ビルドキャッシュの設定方法'
+nav_title: 'CI ビルドキャッシュ'
+description: 'Next.js ビルドをキャッシュするための CI の設定方法を学びます'
+---
+
+ビルドパフォーマンスを向上させるために、Next.js はビルド間で共有されるキャッシュを `.next/cache` に保存します。
+
+このキャッシュを Continuous Integration (CI) 環境で活用するには、CI ワークフローを適切に設定してビルド間でキャッシュを永続化する必要があります。
+
+> CI がビルド間で `.next/cache` を永続化するように設定されていない場合、[No Cache Detected](https://nextjs.org/docs/messages/no-cache) エラーが表示されることがあります。
+
+以下は、一般的な CI プロバイダー向けのキャッシュ設定例です:
+
+## Vercel {#vercel}
+
+Next.js のキャッシングは自動的に設定されます。特に操作は必要ありません。Vercel で Turborepo を使用している場合は、[こちらをご覧ください](https://vercel.com/docs/monorepos/turborepo)。
+
+## CircleCI {#circleci}
+
+`.circleci/config.yml` の `save_cache` ステップを編集して `.next/cache` を含めます:
+
+```yaml
+steps:
+ - save_cache:
+ key: dependency-cache-{{ checksum "yarn.lock" }}
+ paths:
+ - ./node_modules
+ - ./.next/cache
+```
+
+`save_cache` キーがない場合は、CircleCI の[ビルドキャッシュ設定に関するドキュメント](https://circleci.com/docs/2.0/caching/)を参照してください。
+
+## Travis CI {#travis-ci}
+
+以下を `.travis.yml` に追加またはマージします:
+
+```yaml
+cache:
+ directories:
+ - $HOME/.cache/yarn
+ - node_modules
+ - .next/cache
+```
+
+## GitLab CI {#gitlab-ci}
+
+以下を `.gitlab-ci.yml` に追加またはマージします:
+
+```yaml
+cache:
+ key: ${CI_COMMIT_REF_SLUG}
+ paths:
+ - node_modules/
+ - .next/cache/
+```
+
+## Netlify CI {#netlify-ci}
+
+[`@netlify/plugin-nextjs`](https://www.npmjs.com/package/@netlify/plugin-nextjs) を使用して [Netlify Plugins](https://www.netlify.com/products/build/plugins/) を利用します。
+
+## AWS CodeBuild {#aws-codebuild}
+
+`buildspec.yml` に以下を追加(またはマージ)します:
+
+```yaml
+cache:
+ paths:
+ - 'node_modules/**/*' # `yarn` または `npm i` を高速化するために `node_modules` をキャッシュ
+ - '.next/cache/**/*' # アプリケーションの再ビルドを高速化するために Next.js をキャッシュ
+```
+
+## GitHub Actions {#github-actions}
+
+GitHub の [actions/cache](https://github.com/actions/cache) を使用して、ワークフローファイルに以下のステップを追加します:
+
+```yaml
+uses: actions/cache@v4
+with:
+ # `yarn`、`bun` または他のパッケージマネージャーでのキャッシュについては https://github.com/actions/cache/blob/main/examples.md を参照するか、actions/setup-node でのキャッシュを活用できます https://github.com/actions/setup-node
+ path: |
+ ~/.npm
+ ${{ github.workspace }}/.next/cache
+ # パッケージまたはソースファイルが変更されたときに新しいキャッシュを生成します。
+ key: ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}-${{ hashFiles('**/*.js', '**/*.jsx', '**/*.ts', '**/*.tsx') }}
+ # ソースファイルが変更されてもパッケージが変更されていない場合、以前のキャッシュから再ビルドします。
+ restore-keys: |
+ ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}-
+```
+
+## Bitbucket Pipelines {#bitbucket-pipelines}
+
+`bitbucket-pipelines.yml` のトップレベル(`pipelines` と同じレベル)に以下を追加またはマージします:
+
+```yaml
+definitions:
+ caches:
+ nextcache: .next/cache
+```
+
+その後、パイプラインの `step` の `caches` セクションで参照します:
+
+```yaml
+- step:
+ name: your_step_name
+ caches:
+ - node
+ - nextcache
+```
+
+## Heroku {#heroku}
+
+Heroku の[カスタムキャッシュ](https://devcenter.heroku.com/articles/nodejs-support#custom-caching)を使用して、トップレベルの package.json に `cacheDirectories` 配列を追加します:
+
+```javascript
+"cacheDirectories": [".next/cache"]
+```
+
+## Azure Pipelines {#azure-pipelines}
+
+Azure Pipelines の [Cache task](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/cache) を使用して、`next build` を実行するタスクの前に以下のタスクをパイプライン yaml ファイルに追加します:
+
+```yaml
+- task: Cache@2
+ displayName: 'Cache .next/cache'
+ inputs:
+ key: next | $(Agent.OS) | yarn.lock
+ path: '$(System.DefaultWorkingDirectory)/.next/cache'
+```
+
+## Jenkins (Pipeline) {#jenkins-pipeline}
+
+Jenkins の [Job Cacher](https://www.jenkins.io/doc/pipeline/steps/jobcacher/) プラグインを使用して、通常 `next build` または `npm install` を実行する `Jenkinsfile` に以下のビルドステップを追加します:
+
+```yaml
+stage("Restore npm packages") {
+ steps {
+ // GIT_COMMIT ハッシュに基づいてキャッシュにロックファイルを書き込みます
+ writeFile file: "next-lock.cache", text: "$GIT_COMMIT"
+
+ cache(caches: [
+ arbitraryFileCache(
+ path: "node_modules",
+ includes: "**/*",
+ cacheValidityDecidingFile: "package-lock.json"
+ )
+ ]) {
+ sh "npm install"
+ }
+ }
+}
+stage("Build") {
+ steps {
+ // GIT_COMMIT ハッシュに基づいてキャッシュにロックファイルを書き込みます
+ writeFile file: "next-lock.cache", text: "$GIT_COMMIT"
+
+ cache(caches: [
+ arbitraryFileCache(
+ path: ".next/cache",
+ includes: "**/*",
+ cacheValidityDecidingFile: "next-lock.cache"
+ )
+ ]) {
+ // つまり `next build`
+ sh "npm run build"
+ }
+ }
+}
+```
diff --git a/docs/01-app/02-guides/index.mdx b/docs/01-app/02-guides/index.mdx
index 96382bf9..e69ede4c 100644
--- a/docs/01-app/02-guides/index.mdx
+++ b/docs/01-app/02-guides/index.mdx
@@ -6,58 +6,58 @@ description: 'Next.jsを使用して一般的なUIパターンやユースケー
### データフェッチング {#data-fetching}
- [`fetch` APIを使用する](/docs/app/building-your-application/data-fetching/fetching#fetching-data-on-the-server-with-the-fetch-api)
-- [ORMやデータベースクライアントを使用する](/docs/app/building-your-application/data-fetching/fetching#fetching-data-on-the-server-with-an-orm-or-database)
-- [サーバーで検索パラメータを読み取る](/docs/app/api-reference/file-conventions/page)
-- [クライアントで検索パラメータを読み取る](/docs/app/api-reference/functions/use-search-params)
+- ORMやデータベースクライアントを使用する](/docs/app/building-your-application/data-fetching/fetching#fetching-data-on-the-server-with-an-orm-or-database)
+- サーバーで検索パラメータを読み取る](/docs/app/api-reference/file-conventions/page)
+- クライアントで検索パラメータを読み取る](/docs/app/api-reference/functions/use-search-params)
### データの再検証 {#revalidating-data}
-- [一定時間後にデータを再検証するためにISRを使用する](/docs/app/building-your-application/data-fetching/incremental-static-regeneration#time-based-revalidation)
-- [オンデマンドでデータを再検証するためにISRを使用する](/docs/app/building-your-application/data-fetching/incremental-static-regeneration#on-demand-revalidation-with-revalidatepath)
+- 一定時間後にデータを再検証するためにISRを使用する](/docs/app/building-your-application/data-fetching/incremental-static-regeneration#time-based-revalidation)
+- オンデマンドでデータを再検証するためにISRを使用する](/docs/app/building-your-application/data-fetching/incremental-static-regeneration#on-demand-revalidation-with-revalidatepath)
### フォーム {#forms}
-- [フォーム送信中に保留状態を表示する](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#pending-states)
-- [サーバーサイドのフォームバリデーション](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#server-side-form-validation)
-- [予期されたエラーの処理](/docs/app/building-your-application/routing/error-handling#handling-expected-errors-from-server-actions)
-- [予期しない例外の処理](/docs/app/building-your-application/routing/error-handling#uncaught-exceptions)
-- [楽観的なUI更新を表示する](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#optimistic-updates)
-- [プログラムによるフォーム送信](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#programmatic-form-submission)
+- フォーム送信中に保留状態を表示する](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#pending-states)
+- サーバーサイドのフォームバリデーション](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#server-side-form-validation)
+- 予期されたエラーの処理](/docs/app/building-your-application/routing/error-handling#handling-expected-errors-from-server-actions)
+- 予期しない例外の処理](/docs/app/building-your-application/routing/error-handling#uncaught-exceptions)
+- 楽観的なUI更新を表示する](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#optimistic-updates)
+- プログラムによるフォーム送信](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#programmatic-form-submission)
### サーバーアクション {#server-actions}
-- [追加の値を渡す](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#passing-additional-arguments)
-- [データを再検証する](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#revalidating-data)
-- [リダイレクト](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#redirecting)
-- [cookieを設定する](/docs/app/api-reference/functions/cookies#setting-a-cookie)
-- [cookieを削除する](/docs/app/api-reference/functions/cookies#deleting-cookies)
+- 追加の値を渡す](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#passing-additional-arguments)
+- データを再検証する](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#revalidating-data)
+- リダイレクトする](/docs/app/building-your-application/data-fetching/server-actions-and-mutations#redirecting)
+- cookieを設定する](/docs/app/api-reference/functions/cookies#setting-a-cookie)
+- cookieを削除する](/docs/app/api-reference/functions/cookies#deleting-cookies)
### メタデータ {#metadata}
-- [RSSフィードを作成する](/docs/app/building-your-application/routing/route-handlers#non-ui-responses)
-- [Open Graph画像を作成する](/docs/app/api-reference/file-conventions/metadata/opengraph-image)
-- [サイトマップを作成する](/docs/app/api-reference/file-conventions/metadata/sitemap)
-- [robots.txtファイルを作成する](/docs/app/api-reference/file-conventions/metadata/robots)
-- [カスタム404ページを作成する](/docs/app/api-reference/file-conventions/not-found)
-- [カスタム500ページを作成する](/docs/app/api-reference/file-conventions/error)
+- RSSフィードを作成する](/docs/app/building-your-application/routing/route-handlers#non-ui-responses)
+- Open Graph画像を作成する](/docs/app/api-reference/file-conventions/metadata/opengraph-image)
+- サイトマップを作成する](/docs/app/api-reference/file-conventions/metadata/sitemap)
+- robots.txtファイルを作成する](/docs/app/api-reference/file-conventions/metadata/robots)
+- カスタム404ページを作成する](/docs/app/api-reference/file-conventions/not-found)
+- カスタム500ページを作成する](/docs/app/api-reference/file-conventions/error)
### 認証 {#auth}
-- [サインアップフォームを作成する](/docs/app/building-your-application/authentication#sign-up-and-login-functionality)
-- [ステートレスでcookieベースのセッション管理](/docs/app/building-your-application/authentication#stateless-sessions)
-- [ステートフルでデータベースをバックにしたセッション管理](/docs/app/building-your-application/authentication#database-sessions)
-- [認可の管理](/docs/app/building-your-application/authentication#authorization)
+- サインアップフォームを作成する](/docs/app/guides/authentication#sign-up-and-login-functionality)
+- ステートレスでcookieベースのセッション管理](/docs/app/guides/authentication#stateless-sessions)
+- データベースをバックエンドに持つステートフルなセッション管理](/docs/app/guides/authentication#database-sessions)
+- 認可を管理する](/docs/app/guides/authentication#authorization)
### テスト {#testing}
-- [Vitest](/docs/app/building-your-application/testing/vitest)
-- [Jest](/docs/app/building-your-application/testing/jest)
-- [Playwright](/docs/app/building-your-application/testing/playwright)
-- [Cypress](/docs/app/building-your-application/testing/cypress)
+- Vitest](/docs/app/building-your-application/testing/vitest)
+- Jest](/docs/app/building-your-application/testing/jest)
+- Playwright](/docs/app/building-your-application/testing/playwright)
+- Cypress](/docs/app/building-your-application/testing/cypress)
### デプロイ {#deployment}
-- [Dockerfileを作成する](/docs/app/building-your-application/deploying#docker-image)
-- [静的エクスポート(SPA)を作成する](/docs/app/building-your-application/deploying/static-exports)
-- [セルフホスティング時のキャッシュ設定](/docs/app/building-your-application/deploying#configuring-caching)
-- [セルフホスティング時の画像最適化の設定](/docs/app/building-your-application/deploying#image-optimization)
+- Dockerfileを作成する](/docs/app/guides/self-hosting#docker-image)
+- 静的エクスポート(SPA)を作成する](/docs/app/guides/static-exports)
+- 自己ホスティング時のキャッシュ設定](/docs/app/guides/self-hosting#configuring-caching)
+- 自己ホスティング時の画像最適化の設定](/docs/app/guides/self-hosting#image-optimization)
diff --git a/docs/01-app/03-building-your-application/10-deploying/index.mdx b/docs/01-app/02-guides/self-hosting.mdx
similarity index 59%
rename from docs/01-app/03-building-your-application/10-deploying/index.mdx
rename to docs/01-app/02-guides/self-hosting.mdx
index c0910302..69c1e13f 100644
--- a/docs/01-app/03-building-your-application/10-deploying/index.mdx
+++ b/docs/01-app/02-guides/self-hosting.mdx
@@ -1,49 +1,22 @@
---
-title: 'Deploying'
-description: 'Next.jsアプリケーションを本番環境にデプロイする方法を学びましょう。管理された環境またはセルフホスティングのいずれかを選択できます。'
+title: 'Next.jsアプリケーションをセルフホストする方法'
+nav_title: 'セルフホスティング'
+description: 'Node.jsサーバー、Dockerイメージ、または静的HTMLファイル(静的エクスポート)でNext.jsアプリケーションをセルフホストする方法を学びます。'
---
-{/* このドキュメントの内容は、app routerとpages routerの両方で共有されています。Pages Routerに特化した内容を追加するには、`Content`コンポーネントを使用できます。共有されるコンテンツはコンポーネントでラップしないでください。 */}
-
-おめでとうございます。いよいよ本番環境に出荷する時が来ました。
-
-[managed Next.js with Vercel](#managed-next-js-with-vercel)を使用してデプロイするか、Node.jsサーバー、Dockerイメージ、または静的HTMLファイルでセルフホストすることができます。`next start`を使用してデプロイする場合、すべてのNext.js機能がサポートされます。
-
-## 本番ビルド {#production-builds}
-
-`next build`を実行すると、アプリケーションの最適化されたバージョンが生成されます。HTML、CSS、およびJavaScriptファイルがページに基づいて作成されます。JavaScriptは[Next.js Compiler](/docs/architecture/nextjs-compiler)を使用して**コンパイル**され、ブラウザバンドルは**最小化**され、最高のパフォーマンスを達成し、[すべての最新ブラウザ](/docs/architecture/supported-browsers)をサポートします。
-
-Next.jsは、managedとセルフホストの両方で使用される標準的なデプロイメント出力を生成します。これにより、両方のデプロイメント方法で全ての機能がサポートされます。次のメジャーバージョンでは、この出力を[Build Output API仕様](https://vercel.com/docs/build-output-api/v3?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)に変換する予定です。
-
-## Managed Next.js with Vercel {#managed-next-js-with-vercel}
-
-Next.jsの作成者およびメンテナーである[Vercel](https://vercel.com/docs/frameworks/nextjs?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)は、Next.jsアプリケーションのための管理されたインフラストラクチャと開発者体験プラットフォームを提供しています。
-
-Vercelへのデプロイはゼロコンフィグレーションで、グローバルにスケーラビリティ、可用性、パフォーマンスの向上を提供します。ただし、セルフホストでもすべてのNext.js機能がサポートされます。
-
-[Next.js on Vercel](https://vercel.com/docs/frameworks/nextjs?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)についてさらに学ぶか、[無料でテンプレートをデプロイ](https://vercel.com/templates/next.js?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)して試してみてください。
-
-## セルフホスティング {#self-hosting}
+{/* このドキュメントの内容はapp routerとpages routerの間で共有されています。Pages Routerに特化した内容を追加するには、`Content`コンポーネントを使用できます。共有される内容はコンポーネントでラップしないでください。 */}
Next.jsをセルフホストする方法は3つあります:
-- [Node.jsサーバー](#node-js-server)
+- [Node.jsサーバー](#nodejs-server)
- [Dockerコンテナ](#docker-image)
- [静的エクスポート](#static-html-export)
-> **🎥 視聴:** Next.jsのセルフホスティングについてさらに学ぶ → [YouTube (45分)](https://www.youtube.com/watch?v=sIVL4JMqRfc)。
+> **🎥 視聴:** Next.jsのセルフホスティングについて詳しく学ぶ → [YouTube (45分)](https://www.youtube.com/watch?v=sIVL4JMqRfc)。
-以下のプロバイダーでコミュニティがメンテナンスしているデプロイメント例があります:
+## 本番ビルド {#production-builds}
-- [Deno](https://github.com/nextjs/deploy-deno)
-- [DigitalOcean](https://github.com/nextjs/deploy-digitalocean)
-- [Flightcontrol](https://github.com/nextjs/deploy-flightcontrol)
-- [Fly.io](https://github.com/nextjs/deploy-fly)
-- [GitHub Pages](https://github.com/nextjs/deploy-github-pages)
-- [Google Cloud Run](https://github.com/nextjs/deploy-google-cloud-run)
-- [Railway](https://github.com/nextjs/deploy-railway)
-- [Render](https://github.com/nextjs/deploy-render)
-- [SST](https://github.com/nextjs/deploy-sst)
+`next build`を実行すると、アプリケーションの本番用に最適化されたバージョンが生成されます。HTML、CSS、JavaScriptファイルがページに基づいて作成されます。JavaScriptは[Next.js Compiler](/docs/architecture/nextjs-compiler)を使用して**コンパイル**され、ブラウザバンドルは**最小化**され、最高のパフォーマンスを達成し、[すべてのモダンブラウザ](/docs/architecture/supported-browsers)をサポートします。
### Node.jsサーバー {#node-js-server}
@@ -63,10 +36,10 @@ Next.jsはNode.jsをサポートする任意のホスティングプロバイダ
### Dockerイメージ {#docker-image}
-Next.jsは[Docker](https://www.docker.com/)コンテナをサポートする任意のホスティングプロバイダーにデプロイできます。このアプローチは、[Kubernetes](https://kubernetes.io/)などのコンテナオーケストレーターにデプロイする場合や、任意のクラウドプロバイダー内でコンテナ内で実行する場合に使用できます。
+Next.jsは[Docker](https://www.docker.com/)コンテナをサポートする任意のホスティングプロバイダーにデプロイできます。このアプローチは、[Kubernetes](https://kubernetes.io/)のようなコンテナオーケストレーターにデプロイする場合や、任意のクラウドプロバイダー内でコンテナ内で実行する場合に使用できます。
-1. マシンに[Dockerをインストール](https://docs.docker.com/get-docker/)します
-2. [例をクローン](https://github.com/vercel/next.js/tree/canary/examples/with-docker)(または[マルチ環境の例](https://github.com/vercel/next.js/tree/canary/examples/with-docker-multi-env))します
+1. [Dockerをインストール](https://docs.docker.com/get-docker/)します
+2. [例をクローン](https://github.com/vercel/next.js/tree/canary/examples/with-docker)します(または[マルチ環境の例](https://github.com/vercel/next.js/tree/canary/examples/with-docker-multi-env))
3. コンテナをビルドします:`docker build -t nextjs-docker .`
4. コンテナを実行します:`docker run -p 3000:3000 nextjs-docker`
@@ -74,11 +47,11 @@ Dockerを通じたNext.jsはすべてのNext.js機能をサポートします。
### 静的HTMLエクスポート {#static-html-export}
-Next.jsは静的サイトまたはシングルページアプリケーション(SPA)として開始し、後でサーバーを必要とする機能を使用するようにオプションでアップグレードすることができます。
+Next.jsは静的サイトまたはシングルページアプリケーション(SPA)として開始し、後でサーバーを必要とする機能を使用するようにオプションでアップグレードできます。
-Next.jsはこの[静的エクスポート](/docs/app/building-your-application/deploying/static-exports)をサポートしているため、HTML/CSS/JSの静的アセットを提供できる任意のWebサーバーにデプロイおよびホストできます。これには、AWS S3、Nginx、またはApacheなどのツールが含まれます。
+Next.jsはこの[静的エクスポート](/docs/app/guides/static-exports)をサポートしているため、HTML/CSS/JSの静的アセットを提供できる任意のWebサーバーにデプロイおよびホストできます。これには、AWS S3、Nginx、Apacheなどのツールが含まれます。
-[静的エクスポート](/docs/app/building-your-application/deploying/static-exports)として実行する場合、サーバーを必要とするNext.js機能はサポートされません。[詳細はこちら](/docs/app/building-your-application/deploying/static-exports#unsupported-features)。
+[静的エクスポート](/docs/app/guides/static-exports)として実行する場合、サーバーを必要とするNext.jsの機能はサポートされません。[詳細はこちら](/docs/app/guides/static-exports#unsupported-features)。
> **Good to know:**
>
@@ -88,23 +61,23 @@ Next.jsはこの[静的エクスポート](/docs/app/building-your-application/d
### 画像最適化 {#image-optimization}
-`next/image`を通じた[画像最適化](/docs/app/building-your-application/optimizing/images)は、`next start`を使用してデプロイする際にゼロコンフィグレーションでセルフホストで動作します。画像を最適化するための別のサービスを使用したい場合は、[画像ローダーを設定](/docs/app/building-your-application/optimizing/images#loaders)できます。
+`next/image`を通じた[画像最適化](/docs/app/building-your-application/optimizing/images)は、`next start`を使用してデプロイする際にゼロ設定でセルフホストで動作します。画像を最適化するための別のサービスを持ちたい場合は、[画像ローダーを設定](/docs/app/building-your-application/optimizing/images#loaders)できます。
-画像最適化は、`next.config.js`でカスタム画像ローダーを定義することで[静的エクスポート](/docs/app/building-your-application/deploying/static-exports#image-optimization)と共に使用できます。画像はビルド時ではなく、実行時に最適化されることに注意してください。
+画像最適化は、`next.config.js`でカスタム画像ローダーを定義することで[静的エクスポート](/docs/app/guides/static-exports#image-optimization)と一緒に使用できます。画像はビルド時ではなく、実行時に最適化されることに注意してください。
> **Good to know:**
>
> - glibcベースのLinuxシステムでは、画像最適化に[追加の設定](https://sharp.pixelplumbing.com/install#linux-memory-allocator)が必要な場合があります。過剰なメモリ使用を防ぐためです。
-> - 最適化された画像の[キャッシュ動作](/docs/app/api-reference/components/image#caching-behavior)とTTLの設定方法について学びましょう。
-> - 画像を別途最適化している場合でも、`next/image`を使用する他の利点を保持しつつ、[画像最適化を無効化](/docs/app/api-reference/components/image#unoptimized)することもできます。
+> - 最適化された画像の[キャッシュ動作](/docs/app/api-reference/components/image#caching-behavior)とTTLの設定方法について詳しく学びましょう。
+> - 画像を別途最適化している場合でも、`next/image`を使用する他の利点を保持しながら[画像最適化を無効にする](/docs/app/api-reference/components/image#unoptimized)ことができます。
### ミドルウェア {#middleware}
-[ミドルウェア](/docs/app/building-your-application/routing/middleware)は、`next start`を使用してデプロイする際にゼロコンフィグレーションでセルフホストで動作します。受信リクエストへのアクセスが必要なため、[静的エクスポート](/docs/app/building-your-application/deploying/static-exports)を使用する場合はサポートされません。
+[ミドルウェア](/docs/app/building-your-application/routing/middleware)は、`next start`を使用してデプロイする際にゼロ設定でセルフホストで動作します。受信リクエストへのアクセスが必要なため、[静的エクスポート](/docs/app/guides/static-exports)を使用する場合はサポートされません。
-ミドルウェアは、アプリケーション内のすべてのルートまたはアセットの前で実行される可能性があるため、低レイテンシを確保するために、利用可能なすべてのNode.js APIのサブセットである[runtime](/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes)を使用します。このランタイムは「エッジで」実行する必要はなく、単一のリージョンサーバーで動作します。ミドルウェアを複数のリージョンで実行するには、追加の設定とインフラストラクチャが必要です。
+ミドルウェアは、アプリケーション内のすべてのルートまたはアセットの前で実行される可能性があるため、低遅延を確保するために利用可能なNode.js APIのサブセットである[ランタイム](/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes)を使用します。このランタイムは「エッジで」実行する必要はなく、単一のリージョンサーバーで動作します。ミドルウェアを複数のリージョンで実行するには、追加の設定とインフラストラクチャが必要です。
-すべてのNode.js APIを必要とするロジックを追加したい場合(または外部パッケージを使用したい場合)、このロジックを[Server Component](/docs/app/building-your-application/rendering/server-components)として[layout](/docs/app/building-your-application/routing/layouts-and-templates#layouts)に移動することができます。たとえば、[headers](/docs/app/api-reference/functions/headers)をチェックして[リダイレクト](/docs/app/api-reference/functions/redirect)する場合です。`next.config.js`を通じて、headers、cookies、またはクエリパラメータを使用して[リダイレクト](/docs/app/api-reference/config/next-config-js/redirects#header-cookie-and-query-matching)または[書き換え](/docs/app/api-reference/config/next-config-js/rewrites#header-cookie-and-query-matching)することもできます。それがうまくいかない場合は、[カスタムサーバー](https://nextjs.org/docs/canary/pages/building-your-application/configuring/custom-server)を使用することもできます。
+すべてのNode.js APIを必要とするロジックを追加したい場合(または外部パッケージを使用したい場合)、このロジックを[Server Component](/docs/app/building-your-application/rendering/server-components)として[レイアウト](/docs/app/building-your-application/routing/layouts-and-templates#layouts)に移動できるかもしれません。たとえば、[ヘッダー](/docs/app/api-reference/functions/headers)のチェックや[リダイレクト](/docs/app/api-reference/functions/redirect)です。`next.config.js`を通じて、ヘッダー、クッキー、またはクエリパラメータを使用して[リダイレクト](/docs/app/api-reference/config/next-config-js/redirects#header-cookie-and-query-matching)または[書き換え](/docs/app/api-reference/config/next-config-js/rewrites#header-cookie-and-query-matching)を行うこともできます。それがうまくいかない場合は、[カスタムサーバー](https://nextjs.org/docs/canary/pages/building-your-application/configuring/custom-server)を使用することもできます。
### 環境変数 {#environment-variables}
@@ -114,7 +87,7 @@ Next.jsはビルド時と実行時の両方の環境変数をサポートでき
-実行時の環境変数を読み取るには、`getServerSideProps`を使用するか、[App Routerを段階的に採用する](/docs/app/guides/migrating/app-router-migration)ことをお勧めします。
+実行時の環境変数を読み取るには、`getServerSideProps`または[App Routerの段階的な採用](/docs/app/guides/migrating/app-router-migration)を使用することをお勧めします。
@@ -159,43 +132,43 @@ export default async function Component() {
-これにより、異なる値を持つ複数の環境を通じて昇格できる単一のDockerイメージを使用することができます。
+これにより、異なる値を持つ複数の環境を通じて昇格できる単一のDockerイメージを使用できます。
> **Good to know:**
>
> - [`register`関数](/docs/app/building-your-application/optimizing/instrumentation)を使用してサーバーの起動時にコードを実行できます。
-> - [runtimeConfig](https://nextjs.org/docs/canary/pages/api-reference/config/next-config-js/runtime-configuration)オプションの使用は推奨されません。これはスタンドアロン出力モードでは機能しないためです。代わりに、App Routerを[段階的に採用する](/docs/app/guides/migrating/app-router-migration)ことをお勧めします。
+> - [runtimeConfig](https://nextjs.org/docs/canary/pages/api-reference/config/next-config-js/runtime-configuration)オプションの使用は推奨しません。これはスタンドアロン出力モードでは機能しないためです。代わりに、App Routerの[段階的な採用](/docs/app/guides/migrating/app-router-migration)をお勧めします。
### キャッシングとISR {#caching-and-isr}
Next.jsは、レスポンス、生成された静的ページ、ビルド出力、および画像、フォント、スクリプトなどの他の静的アセットをキャッシュできます。
-ページのキャッシングと再検証([Incremental Static Regeneration](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)を使用)は、**同じ共有キャッシュ**を使用します。デフォルトでは、このキャッシュはNext.jsサーバー上のファイルシステム(ディスク上)に保存されます。**これはセルフホスティング時に自動的に機能します**。Pages RouterとApp Routerの両方で使用されます。
+ページのキャッシングと再検証([Incremental Static Regeneration](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)を使用)は、**同じ共有キャッシュ**を使用します。デフォルトでは、このキャッシュはNext.jsサーバーのファイルシステム(ディスク上)に保存されます。**セルフホスティング時に自動的に動作します**。Pages RouterとApp Routerの両方で使用できます。
キャッシュされたページとデータを永続的なストレージに保存したり、Next.jsアプリケーションの複数のコンテナやインスタンス間でキャッシュを共有したい場合は、Next.jsキャッシュの場所を設定できます。
#### 自動キャッシング {#automatic-caching}
-- Next.jsは、`public, max-age=31536000, immutable`の`Cache-Control`ヘッダーを真に不変のアセットに設定します。これは上書きできません。これらの不変ファイルにはファイル名にSHAハッシュが含まれているため、無期限に安全にキャッシュできます。たとえば、[静的画像インポート](/docs/app/building-your-application/optimizing/images#local-images)です。画像の[TTLを設定](/docs/app/api-reference/components/image#caching-behavior)できます。
+- Next.jsは、`public, max-age=31536000, immutable`の`Cache-Control`ヘッダーを真に不変のアセットに設定します。これは上書きできません。これらの不変ファイルにはファイル名にSHAハッシュが含まれているため、安全に無期限にキャッシュできます。たとえば、[静的画像インポート](/docs/app/building-your-application/optimizing/images#local-images)です。画像の[TTLを設定](/docs/app/api-reference/components/image#caching-behavior)できます。
- Incremental Static Regeneration(ISR)は、`s-maxage: , stale-while-revalidate`の`Cache-Control`ヘッダーを設定します。この再検証時間は、[`getStaticProps`関数](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/get-static-props)で秒単位で定義されます。`revalidate: false`を設定すると、デフォルトで1年間のキャッシュ期間になります。
-- 動的にレンダリングされたページは、ユーザー固有のデータがキャッシュされないようにするために、`private, no-cache, no-store, max-age=0, must-revalidate`の`Cache-Control`ヘッダーを設定します。これはApp RouterとPages Routerの両方に適用されます。これには[Draft Mode](/docs/app/building-your-application/configuring/draft-mode)も含まれます。
+- 動的にレンダリングされたページは、`private, no-cache, no-store, max-age=0, must-revalidate`の`Cache-Control`ヘッダーを設定して、ユーザー固有のデータがキャッシュされないようにします。これは、App RouterとPages Routerの両方に適用されます。これには[ドラフトモード](/docs/app/building-your-application/configuring/draft-mode)も含まれます。
#### 静的アセット {#static-assets}
静的アセットを別のドメインまたはCDNにホストしたい場合は、`next.config.js`の`assetPrefix`[設定](/docs/app/api-reference/config/next-config-js/assetPrefix)を使用できます。Next.jsはJavaScriptまたはCSSファイルを取得する際にこのアセットプレフィックスを使用します。アセットを別のドメインに分離することには、DNSおよびTLS解決に余分な時間がかかるというデメリットがあります。
-[`assetPrefix`についてさらに学ぶ](/docs/app/api-reference/config/next-config-js/assetPrefix)。
+[`assetPrefix`について詳しく学ぶ](/docs/app/api-reference/config/next-config-js/assetPrefix)。
#### キャッシングの設定 {#configuring-caching}
-デフォルトでは、生成されたキャッシュアセットはメモリ(デフォルトで50MB)とディスクに保存されます。Kubernetesのようなコンテナオーケストレーションプラットフォームを使用してNext.jsをホストしている場合、各ポッドにはキャッシュのコピーがあります。デフォルトでポッド間でキャッシュが共有されないため、古いデータが表示されるのを防ぐために、Next.jsキャッシュを設定してキャッシュハンドラーを提供し、メモリ内キャッシュを無効にすることができます。
+デフォルトでは、生成されたキャッシュアセットはメモリ(デフォルトで50mb)とディスクに保存されます。Kubernetesのようなコンテナオーケストレーションプラットフォームを使用してNext.jsをホストしている場合、各ポッドにはキャッシュのコピーがあります。デフォルトでポッド間でキャッシュが共有されないため、古いデータが表示されるのを防ぐために、Next.jsキャッシュを設定してキャッシュハンドラーを提供し、メモリ内キャッシングを無効にできます。
セルフホスティング時にISR/データキャッシュの場所を設定するには、`next.config.js`ファイルでカスタムハンドラーを設定できます:
```jsx title="next.config.js"
module.exports = {
cacheHandler: require.resolve('./cache-handler.js'),
- cacheMaxMemorySize: 0, // デフォルトのメモリ内キャッシュを無効にする
+ cacheMaxMemorySize: 0, // デフォルトのメモリ内キャッシングを無効にする
}
```
@@ -235,7 +208,7 @@ module.exports = class CacheHandler {
}
}
- // 単一のリクエストのための一時的なメモリ内キャッシュを持ち、次のリクエストの前にリセットされる場合は、このメソッドを活用できます
+ // 単一のリクエストのための一時的なメモリ内キャッシュを持ちたい場合は、このメソッドを活用できます
resetRequestCache() {}
}
```
@@ -250,7 +223,7 @@ module.exports = class CacheHandler {
Next.jsは、`next build`中にアプリケーションのどのバージョンが提供されているかを識別するためのIDを生成します。同じビルドを使用して複数のコンテナを起動する必要があります。
-環境の各ステージごとに再ビルドしている場合、コンテナ間で使用する一貫したビルドIDを生成する必要があります。`next.config.js`で`generateBuildId`コマンドを使用します:
+環境の各ステージごとに再ビルドしている場合は、コンテナ間で使用する一貫したビルドIDを生成する必要があります。`next.config.js`で`generateBuildId`コマンドを使用します:
```jsx title="next.config.js"
module.exports = {
@@ -263,9 +236,9 @@ module.exports = {
### バージョンスキュー {#version-skew}
-Next.jsは、[バージョンスキュー](https://www.industrialempathy.com/posts/version-skew/)のほとんどのインスタンスを自動的に緩和し、検出された場合に新しいアセットを取得するためにアプリケーションを自動的にリロードします。たとえば、`deploymentId`に不一致がある場合、ページ間の遷移はプリフェッチされた値を使用するのではなく、ハードナビゲーションを実行します。
+Next.jsは[バージョンスキュー](https://www.industrialempathy.com/posts/version-skew/)のほとんどのインスタンスを自動的に緩和し、検出された場合に新しいアセットを取得するためにアプリケーションを自動的にリロードします。たとえば、`deploymentId`に不一致がある場合、ページ間の遷移はプリフェッチされた値を使用するのではなく、ハードナビゲーションを実行します。
-アプリケーションがリロードされると、ページナビゲーション間で永続化されるように設計されていない場合、アプリケーションの状態が失われる可能性があります。たとえば、URL状態やローカルストレージを使用すると、ページの更新後も状態が永続化されます。ただし、`useState`のようなコンポーネント状態は、そのようなナビゲーションで失われます。
+アプリケーションがリロードされると、ページナビゲーション間で永続するように設計されていない場合、アプリケーションの状態が失われる可能性があります。たとえば、URL状態やローカルストレージを使用すると、ページのリフレッシュ後も状態が保持されます。ただし、`useState`のようなコンポーネント状態は、そのようなナビゲーションで失われます。
Vercelは、Next.jsアプリケーションのために追加の[スキュー保護](https://vercel.com/docs/deployments/skew-protection?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)を提供し、新しいバージョンがデプロイされた後でも、以前のバージョンのアセットと機能が古いクライアントに対して利用可能であることを保証します。
@@ -299,13 +272,13 @@ module.exports = {
### 部分的なプリレンダリング {#partial-prerendering}
-[部分的なプリレンダリング(実験的)](/docs/app/building-your-application/rendering/partial-prerendering)は、Next.jsでデフォルトで動作し、CDN機能ではありません。これには、Node.jsサーバーとしてのデプロイ(`next start`を通じて)およびDockerコンテナでの使用が含まれます。
+[部分的なプリレンダリング(実験的)](/docs/app/building-your-application/rendering/partial-prerendering)は、Next.jsでデフォルトで動作し、CDN機能ではありません。これには、Node.jsサーバー(`next start`を通じて)としてのデプロイや、Dockerコンテナと一緒に使用する場合が含まれます。
### CDNとの使用 {#usage-with-cdns}
-Next.jsアプリケーションの前にCDNを使用する場合、動的APIがアクセスされると、ページには`Cache-Control: private`レスポンスヘッダーが含まれます。これにより、結果のHTMLページがキャッシュされないようにマークされます。ページが完全に静的にプリレンダリングされると、`Cache-Control: public`が含まれ、ページがCDNでキャッシュされることが許可されます。
+Next.jsアプリケーションの前にCDNを使用する場合、動的APIがアクセスされるとページには`Cache-Control: private`レスポンスヘッダーが含まれます。これにより、生成されたHTMLページがキャッシュされないようにマークされます。ページが完全に静的にプリレンダリングされると、`Cache-Control: public`が含まれ、ページがCDNでキャッシュされることが許可されます。
-静的および動的コンポーネントの両方を必要としない場合、ルート全体を静的にして、出力HTMLをCDNでキャッシュすることができます。動的APIが使用されていない場合、`next build`を実行するときのデフォルトの動作は自動的な静的最適化です。
+静的コンポーネントと動的コンポーネントの両方を混在させる必要がない場合は、ルート全体を静的にして、出力HTMLをCDNでキャッシュできます。この自動静的最適化は、動的APIが使用されていない場合に`next build`を実行するときのデフォルトの動作です。
@@ -315,15 +288,15 @@ Next.jsアプリケーションの前にCDNを使用する場合、動的APIが
[`after`](/docs/app/api-reference/functions/after)は、`next start`でセルフホスティングする際に完全にサポートされています。
-サーバーを停止する際には、`SIGINT`または`SIGTERM`シグナルを送信して待機することで、優雅なシャットダウンを確保してください。これにより、Next.jsサーバーは`after`内で使用される保留中のコールバック関数またはプロミスが終了するまで待機できます。
+サーバーを停止する際には、`SIGINT`または`SIGTERM`シグナルを送信して待機することで、優雅なシャットダウンを確保します。これにより、Next.jsサーバーは`after`内で使用される保留中のコールバック関数やプロミスが完了するまで待機できます。
カスタムインフラストラクチャで`after`を使用したい場合は、プロバイダのドキュメントを確認して`after`のサポートを確認してください。
- サーバーレスプラットフォームの`after`サポートに関するリファレンス
- サーバーレスコンテキストで`after`を使用するには、レスポンスが送信された後に非同期タスクが終了するのを待つ必要があります。Next.jsとVercelでは、`waitUntil(promise)`というプリミティブを使用して、すべてのプロミスが解決されるまでサーバーレス呼び出しの寿命を延ばします。
+ サーバーレスプラットフォームでの`after`のサポートに関するリファレンス
+ サーバーレスコンテキストで`after`を使用するには、レスポンスが送信された後に非同期タスクが完了するのを待つ必要があります。Next.jsとVercelでは、`waitUntil(promise)`というプリミティブを使用して、すべてのプロミスが[`waitUntil`](https://vercel.com/docs/functions/functions-api-reference#waituntil)に渡されるまでサーバーレス呼び出しの寿命を延ばします。
-ユーザーが`after`を実行できるようにするには、`waitUntil`の実装を提供し、類似の方法で動作する必要があります。
+ユーザーが`after`を実行できるようにするには、`waitUntil`の実装を提供し、類似の方法で動作するようにする必要があります。
`after`が呼び出されると、Next.jsは次のように`waitUntil`にアクセスします:
@@ -352,7 +325,7 @@ import { AsyncLocalStorage } from 'node:async_hooks'
const RequestContextStorage = new AsyncLocalStorage()
-// next.jsが使用するアクセサを定義して注入します
+// Next.jsが使用するアクセサを定義して注入します
const RequestContext: NextRequestContext = {
get() {
return RequestContextStorage.getStore()
@@ -405,3 +378,17 @@ if (process.env.NEXT_MANUAL_SIG_HANDLE) {
```
+
+## 例 {#examples}
+
+次のプロバイダーとのコミュニティによって維持されているデプロイ例があります:
+
+- [Deno](https://github.com/nextjs/deploy-deno)
+- [DigitalOcean](https://github.com/nextjs/deploy-digitalocean)
+- [Flightcontrol](https://github.com/nextjs/deploy-flightcontrol)
+- [Fly.io](https://github.com/nextjs/deploy-fly)
+- [GitHub Pages](https://github.com/nextjs/deploy-github-pages)
+- [Google Cloud Run](https://github.com/nextjs/deploy-google-cloud-run)
+- [Railway](https://github.com/nextjs/deploy-railway)
+- [Render](https://github.com/nextjs/deploy-render)
+- [SST](https://github.com/nextjs/deploy-sst)
diff --git a/docs/01-app/02-guides/single-page-applications.mdx b/docs/01-app/02-guides/single-page-applications.mdx
index dc7e215a..7b8eafdf 100644
--- a/docs/01-app/02-guides/single-page-applications.mdx
+++ b/docs/01-app/02-guides/single-page-applications.mdx
@@ -1,25 +1,25 @@
---
title: 'Next.jsでシングルページアプリケーションを構築する方法'
nav_title: 'SPAs'
-description: 'Next.jsはシングルページアプリケーション(SPA)の構築を完全にサポートしています。'
+description: 'Next.jsはシングルページアプリケーション(SPAs)の構築を完全にサポートしています。'
---
-Next.jsはシングルページアプリケーション(SPA)の構築を完全にサポートしています。
+Next.jsはシングルページアプリケーション(SPAs)の構築を完全にサポートしています。
これには、プリフェッチによる高速なルート遷移、クライアントサイドでのデータ取得、ブラウザAPIの使用、サードパーティのクライアントライブラリとの統合、静的ルートの作成などが含まれます。
-既存のSPAをお持ちの場合、大きなコード変更をせずにNext.jsに移行できます。その後、必要に応じてサーバー機能を段階的に追加することが可能です。
+既存のSPAがある場合、大きなコード変更をせずにNext.jsに移行できます。その後、必要に応じてサーバー機能を段階的に追加することが可能です。
## シングルページアプリケーションとは? {#what-is-a-single-page-application}
SPAの定義はさまざまです。ここでは「厳密なSPA」を次のように定義します:
-- **クライアントサイドレンダリング(CSR)**: アプリは1つのHTMLファイル(例:`index.html`)で提供されます。すべてのルート、ページ遷移、データ取得はブラウザ内のJavaScriptによって処理されます
-- **フルページリロードなし**: 各ルートごとに新しいドキュメントを要求するのではなく、クライアントサイドのJavaScriptが現在のページのDOMを操作し、必要に応じてデータを取得します
+- **クライアントサイドレンダリング(CSR)**:アプリは1つのHTMLファイル(例:`index.html`)によって提供されます。すべてのルート、ページ遷移、データ取得はブラウザ内のJavaScriptによって処理されます
+- **フルページリロードなし**:各ルートごとに新しいドキュメントを要求するのではなく、クライアントサイドのJavaScriptが現在のページのDOMを操作し、必要に応じてデータを取得します
厳密なSPAは、ページがインタラクティブになる前に大量のJavaScriptをロードする必要があることが多いです。さらに、クライアントデータのウォーターフォールを管理するのは難しい場合があります。Next.jsを使用してSPAを構築することで、これらの問題に対処できます。
-## なぜNext.jsをSPAに使用するのか? {#why-use-next-js-for-spas}
+## なぜNext.jsをSPAsに使用するのか? {#why-use-next-js-for-spas}
Next.jsはJavaScriptバンドルを自動的にコード分割し、異なるルートに複数のHTMLエントリーポイントを生成できます。これにより、クライアントサイドで不要なJavaScriptコードをロードすることを避け、バンドルサイズを削減し、ページの読み込みを高速化します。
@@ -29,7 +29,7 @@ Next.jsは静的サイトやすべてがクライアントサイドでレンダ
## 例 {#examples}
-SPAを構築するために使用される一般的なパターンと、それをNext.jsがどのように解決するかを探ってみましょう。
+SPAsを構築するために使用される一般的なパターンと、それをNext.jsがどのように解決するかを探ってみましょう。
### Context Provider内でのReactの`use`の使用 {#using-react-s-use-within-a-context-provider}
@@ -88,7 +88,7 @@ export default function RootLayout({ children }) {
-単一のPromiseを[遅延させてクライアントコンポーネントにpropとして渡す](/docs/app/getting-started/fetching-data#with-the-use-hook)こともできますが、一般的にはこのパターンはReactのコンテキストプロバイダーと組み合わせて使用されます。これにより、カスタムReactフックを使用してクライアントコンポーネントからのアクセスが容易になります。
+単一のPromiseを[遅延させてpropとしてクライアントコンポーネントに渡す](/docs/app/getting-started/fetching-data#with-the-use-hook)こともできますが、一般的にこのパターンはReactのコンテキストプロバイダーと組み合わせて使用されます。これにより、カスタムReactフックを使用してクライアントコンポーネントからのアクセスが容易になります。
PromiseをReactのコンテキストプロバイダーに転送できます:
@@ -201,15 +201,15 @@ export function Profile() {
Promiseを消費するコンポーネント(例:上記の`Profile`)はサスペンドされます。これにより部分的なハイドレーションが可能になります。JavaScriptの読み込みが完了する前にストリーミングされたプリレンダリングされたHTMLを確認できます。
-### SWRを使用したSPA {#spas-with-swr}
+### SWRを使用したSPAs {#spas-with-swr}
[SWR](https://swr.vercel.app)はデータ取得のための人気のあるReactライブラリです。
SWR 2.3.0(およびReact 19+)では、既存のSWRベースのクライアントデータ取得コードと並行してサーバー機能を段階的に採用できます。これは上記の`use()`パターンの抽象化です。これにより、データ取得をクライアントとサーバーサイド間で移動したり、両方を使用したりできます:
-- **クライアントのみ**: `useSWR(key, fetcher)`
-- **サーバーのみ**: `useSWR(key)` + RSC提供のデータ
-- **混合**: `useSWR(key, fetcher)` + RSC提供のデータ
+- **クライアントのみ**:`useSWR(key, fetcher)`
+- **サーバーのみ**:`useSWR(key)` + RSC提供のデータ
+- **混合**:`useSWR(key, fetcher)` + RSC提供のデータ
例えば、``と`fallback`でアプリケーションをラップします:
@@ -268,7 +268,7 @@ export default function RootLayout({ children }) {
-これはサーバーコンポーネントであるため、`getUser()`はcookie、ヘッダーを安全に読み取ったり、データベースと通信したりできます。別のAPIルートは必要ありません。``の下のクライアントコンポーネントは、同じキーで`useSWR()`を呼び出してユーザーデータを取得できます。`useSWR`を使用したコンポーネントコードは、既存のクライアント取得ソリューションから**変更を必要としません**。
+これはサーバーコンポーネントであるため、`getUser()`はcookieやヘッダーを安全に読み取ったり、データベースと通信したりできます。別のAPIルートは必要ありません。``の下のクライアントコンポーネントは、同じキーで`useSWR()`を呼び出してユーザーデータを取得できます。`useSWR`を使用したコンポーネントコードは、既存のクライアント取得ソリューションから**変更を必要としません**。
@@ -307,9 +307,9 @@ export function Profile() {
-`fallback`データはプリレンダリングされ、初期HTMLレスポンスに含まれ、その後`useSWR`を使用して子コンポーネントで即座に読み取られます。SWRのポーリング、再検証、キャッシングは**クライアントサイドのみ**で実行されるため、SPAに必要なすべてのインタラクティビティを保持します。
+`fallback`データはプリレンダリングされ、初期HTMLレスポンスに含まれ、`useSWR`を使用して子コンポーネントで即座に読み取られます。SWRのポーリング、再検証、キャッシングは**クライアントサイドのみ**で実行されるため、SPAに必要なすべてのインタラクティビティを保持します。
-初期の`fallback`データはNext.jsによって自動的に処理されるため、以前に`data`が`undefined`であるかどうかを確認するために必要だった条件付きロジックを削除できます。データが読み込まれている間、最も近い``境界がサスペンドされます。
+初期の`fallback`データはNext.jsによって自動的に処理されるため、以前に`data`が`undefined`であるかどうかを確認するために必要だった条件付きロジックを削除できます。データが読み込まれているときは、最も近い``境界がサスペンドされます。
| | SWR | RSC | RSC + SWR |
| ---------------------- | ------------------- | ------------------- | ------------------- |
@@ -318,9 +318,9 @@ export function Profile() {
| リクエストの重複排除 | | | |
| クライアントサイド機能 | | | |
-### React Queryを使用したSPA {#spas-with-react-query}
+### React Queryを使用したSPAs {#spas-with-react-query}
-Next.jsではクライアントとサーバーの両方でReact Queryを使用できます。これにより、厳密なSPAを構築するだけでなく、React Queryと組み合わせたNext.jsのサーバー機能を活用することもできます。
+Next.jsと共にReact Queryをクライアントとサーバーの両方で使用できます。これにより、厳密なSPAを構築するだけでなく、React Queryと組み合わせたNext.jsのサーバー機能を活用することができます。
詳細は[React Queryのドキュメント](https://tanstack.com/query/latest/docs/framework/react/guides/advanced-ssr)をご覧ください。
@@ -336,11 +336,11 @@ const ClientOnlyComponent = dynamic(() => import('./component'), {
})
```
-これは、`window`や`document`のようなブラウザAPIに依存するサードパーティライブラリに役立ちます。また、これらのAPIの存在を確認する`useEffect`を追加し、存在しない場合は`null`またはプリレンダリングされるローディング状態を返すこともできます。
+これは、`window`や`document`のようなブラウザAPIに依存するサードパーティライブラリに役立ちます。また、これらのAPIの存在を確認する`useEffect`を追加し、それらが存在しない場合は`null`またはプリレンダリングされるローディング状態を返すこともできます。
### クライアントでのシャローなルーティング {#shallow-routing-on-the-client}
-[Create React App](/docs/app/guides/migrating/from-create-react-app)や[Vite](/docs/app/guides/migrating/from-vite)のような厳密なSPAから移行する場合、URL状態を更新するためにシャローなルートを持つ既存のコードがあるかもしれません。これは、Next.jsのデフォルトのファイルシステムルーティングを使用せずに、アプリケーション内のビュー間で手動で遷移するのに役立ちます。
+[Create React App](/docs/app/guides/migrating/from-create-react-app)や[Vite](/docs/app/guides/migrating/from-vite)のような厳密なSPAから移行する場合、URL状態を更新するためにシャローなルートを持つ既存のコードがあるかもしれません。これは、Next.jsのデフォルトのファイルシステムルーティングを使用せずに、アプリケーション内のビュー間の手動遷移に役立ちます。
Next.jsでは、ネイティブの[`window.history.pushState`](https://developer.mozilla.org/en-US/docs/Web/API/History/pushState)と[`window.history.replaceState`](https://developer.mozilla.org/en-US/docs/Web/API/History/replaceState)メソッドを使用して、ページをリロードせずにブラウザの履歴スタックを更新できます。
@@ -465,10 +465,10 @@ export function Button() {
## 静的エクスポート(オプション) {#static-export-optional}
-Next.jsは完全な[静的サイト](/docs/app/building-your-application/deploying/static-exports)の生成もサポートしています。これは厳密なSPAに対していくつかの利点があります:
+Next.jsは完全な[静的サイト](/docs/app/guides/static-exports)の生成もサポートしています。これは厳密なSPAに対していくつかの利点があります:
-- **自動コード分割**: 単一の`index.html`を配信する代わりに、Next.jsはルートごとにHTMLファイルを生成するため、訪問者はクライアントJavaScriptバンドルを待たずにコンテンツをより早く取得できます
-- **ユーザーエクスペリエンスの向上**: すべてのルートに対して最小限のスケルトンを提供する代わりに、各ルートに対して完全にレンダリングされたページを取得できます。ユーザーがクライアントサイドでナビゲートすると、遷移は瞬時でSPAのように感じられます
+- **自動コード分割**:単一の`index.html`を配信する代わりに、Next.jsはルートごとにHTMLファイルを生成するため、訪問者はクライアントJavaScriptバンドルを待たずにコンテンツをより早く取得できます
+- **ユーザーエクスペリエンスの向上**:すべてのルートに対して最小限のスケルトンを提供する代わりに、各ルートに対して完全にレンダリングされたページを取得できます。ユーザーがクライアントサイドでナビゲートすると、遷移は瞬時でSPAのように感じられます
静的エクスポートを有効にするには、設定を更新します:
@@ -484,7 +484,7 @@ export default nextConfig
`next build`を実行した後、Next.jsはアプリケーションのHTML/CSS/JSアセットを含む`out`フォルダを作成します。
-> **注意:** 静的エクスポートではNext.jsのサーバー機能はサポートされていません。[詳細はこちら](/docs/app/building-your-application/deploying/static-exports#unsupported-features)。
+> **注意:** Next.jsのサーバー機能は静的エクスポートではサポートされていません。[詳細はこちら](/docs/app/guides/static-exports#unsupported-features)。
## 既存プロジェクトのNext.jsへの移行 {#migrating-existing-projects-to-next-js}
@@ -493,4 +493,4 @@ export default nextConfig
- [Create React Appからの移行](/docs/app/guides/migrating/from-create-react-app)
- [Viteからの移行](/docs/app/guides/migrating/from-vite)
-Pages Routerを使用しているSPAを既にお持ちの場合、[App Routerを段階的に採用する方法](/docs/app/guides/migrating/app-router-migration)を学ぶことができます。
+Pages Routerを使用しているSPAを既に使用している場合は、[App Routerを段階的に採用する方法](/docs/app/guides/migrating/app-router-migration)を学ぶことができます。
diff --git a/docs/01-app/03-building-your-application/10-deploying/02-static-exports.mdx b/docs/01-app/02-guides/static-exports.mdx
similarity index 73%
rename from docs/01-app/03-building-your-application/10-deploying/02-static-exports.mdx
rename to docs/01-app/02-guides/static-exports.mdx
index c6550c8a..898bf60e 100644
--- a/docs/01-app/03-building-your-application/10-deploying/02-static-exports.mdx
+++ b/docs/01-app/02-guides/static-exports.mdx
@@ -1,13 +1,14 @@
---
-title: '静的エクスポート'
-description: 'Next.jsは静的サイトやシングルページアプリケーション(SPA)として始め、後でサーバーを必要とする機能をオプションで利用することができます。'
+title: 'Next.jsアプリケーションの静的エクスポートを作成する方法'
+nav_title: '静的エクスポート'
+description: 'Next.jsは、静的サイトやシングルページアプリケーション(SPA)として開始し、後でサーバーを必要とする機能をオプションで利用することができます。'
---
-{/* このドキュメントの内容はapp routerとpages routerの間で共有されています。Pages Routerに特化した内容を追加するには、`Content`コンポーネントを使用できます。共有される内容はコンポーネントでラップしないでください。 */}
+{/* このドキュメントの内容は、app routerとpages routerの両方で共有されています。Pages Routerに特化した内容を追加するには、`Content`コンポーネントを使用できます。共有されるコンテンツはコンポーネントでラップしないでください。 */}
-Next.jsは静的サイトやシングルページアプリケーション(SPA)として始め、後でサーバーを必要とする機能をオプションで利用することができます。
+Next.jsは、静的サイトやシングルページアプリケーション(SPA)として開始し、後でサーバーを必要とする機能をオプションで利用することができます。
-`next build`を実行すると、Next.jsはルートごとにHTMLファイルを生成します。厳密なSPAを個々のHTMLファイルに分割することで、Next.jsはクライアント側で不要なJavaScriptコードの読み込みを避け、バンドルサイズを削減し、ページの読み込みを高速化します。
+`next build`を実行すると、Next.jsはルートごとにHTMLファイルを生成します。厳密なSPAを個別のHTMLファイルに分割することで、Next.jsはクライアント側で不要なJavaScriptコードの読み込みを避け、バンドルサイズを削減し、ページの読み込みを高速化します。
Next.jsはこの静的エクスポートをサポートしているため、HTML/CSS/JSの静的アセットを提供できる任意のWebサーバーにデプロイしてホストすることができます。
@@ -35,11 +36,11 @@ const nextConfig = {
module.exports = nextConfig
```
-`next build`を実行した後、Next.jsはアプリケーションのHTML/CSS/JSアセットを含む`out`フォルダを作成します。
+`next build`を実行すると、Next.jsはアプリケーションのHTML/CSS/JSアセットを含む`out`フォルダを作成します。
-[`getStaticProps`](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/get-static-props)と[`getStaticPaths`](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/get-static-paths)を利用して、`pages`ディレクトリ内の各ページ(または[動的ルート](/docs/app/building-your-application/routing/dynamic-routes)の場合はさらに多くのページ)のHTMLファイルを生成できます。
+[`getStaticProps`](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/get-static-props)と[`getStaticPaths`](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/get-static-paths)を利用して、`pages`ディレクトリ内の各ページ(または[dynamic routes](/docs/app/building-your-application/routing/dynamic-routes)の場合はさらに多くのページ)のHTMLファイルを生成できます。
@@ -53,7 +54,7 @@ Next.jsのコアは静的エクスポートをサポートするように設計
静的エクスポートを生成するために`next build`を実行すると、`app`ディレクトリ内で使用されるServer Componentsは、従来の静的サイト生成と同様にビルド中に実行されます。
-結果として得られるコンポーネントは、初回ページロード時に静的HTMLとしてレンダリングされ、ルート間のクライアントナビゲーション用に静的ペイロードが生成されます。静的エクスポートを使用する際、Server Componentsに変更は必要ありませんが、[動的サーバー関数](#unsupported-features)を使用する場合を除きます。
+結果として得られるコンポーネントは、初回ページロード時に静的HTMLとしてレンダリングされ、ルート間のクライアントナビゲーション用に静的ペイロードが生成されます。静的エクスポートを使用する際、Server Componentsに変更は必要ありませんが、[dynamic server functions](#unsupported-features)を使用する場合を除きます。
@@ -175,12 +176,12 @@ export default function Page() {
## サポートされている機能 {#supported-features}
-静的サイトを構築するために必要なNext.jsの主要な機能の大部分がサポートされています。これには以下が含まれます:
+静的サイトを構築するために必要なNext.jsのコア機能の大部分がサポートされています。これには以下が含まれます:
-- [`getStaticPaths`を使用した動的ルート](/docs/app/building-your-application/routing/dynamic-routes)
+- [`getStaticPaths`を使用したDynamic Routes](/docs/app/building-your-application/routing/dynamic-routes)
- `next/link`によるプリフェッチ
- JavaScriptのプリロード
-- [動的インポート](https://nextjs.org/docs/canary/pages/building-your-application/optimizing/lazy-loading)
+- [Dynamic Imports](https://nextjs.org/docs/canary/pages/building-your-application/optimizing/lazy-loading)
- 任意のスタイリングオプション(例:CSS Modules、styled-jsx)
- [クライアントサイドのデータフェッチ](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/client-side)
- [`getStaticProps`](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/get-static-props)
@@ -190,7 +191,7 @@ export default function Page() {
### 画像最適化 {#image-optimization}
-`next/image`を使用した[画像最適化](/docs/app/building-your-application/optimizing/images)は、`next.config.js`でカスタム画像ローダーを定義することで静的エクスポートと共に使用できます。たとえば、Cloudinaryのようなサービスで画像を最適化できます:
+`next/image`を使用した[画像最適化](/docs/app/building-your-application/optimizing/images)は、`next.config.js`でカスタムイメージローダーを定義することで静的エクスポートと共に使用できます。たとえば、Cloudinaryのようなサービスで画像を最適化できます:
```js title="next.config.js"
/** @type {import('next').NextConfig} */
@@ -273,7 +274,7 @@ export default function Page() {
### Route Handlers {#route-handlers}
-Route Handlersは`next build`を実行すると静的なレスポンスをレンダリングします。サポートされているのは`GET` HTTPメソッドのみです。これは、キャッシュされたまたはキャッシュされていないデータから静的なHTML、JSON、TXT、またはその他のファイルを生成するために使用できます。たとえば:
+Route Handlersは、`next build`を実行すると静的なレスポンスをレンダリングします。サポートされているのは`GET` HTTPメソッドのみです。これを使用して、キャッシュされたまたはキャッシュされていないデータから静的なHTML、JSON、TXT、その他のファイルを生成できます。たとえば:
@@ -296,9 +297,9 @@ export async function GET() {
-上記のファイル`app/data.json/route.ts`は、`next build`中に静的ファイルとしてレンダリングされ、`{ name: 'Lee' }`を含む`data.json`を生成します。
+上記のファイル`app/data.json/route.ts`は、`next build`中に静的ファイルとしてレンダリングされ、`data.json`に`{ name: 'Lee' }`が含まれます。
-受信リクエストから動的な値を読み取る必要がある場合、静的エクスポートを使用することはできません。
+受信リクエストから動的な値を読み取る必要がある場合、静的エクスポートは使用できません。
### ブラウザAPI {#browser-apis}
@@ -311,7 +312,7 @@ import { useEffect } from 'react';
export default function ClientComponent() {
useEffect(() => {
- // `window`にアクセスできるようになりました
+ // ここで`window`にアクセスできます
console.log(window.innerHeight);
}, [])
@@ -323,12 +324,12 @@ export default function ClientComponent() {
## サポートされていない機能 {#unsupported-features}
-Node.jsサーバーを必要とする機能や、ビルドプロセス中に計算できない動的ロジックはサポートされていません:
+Node.jsサーバーを必要とする機能や、ビルドプロセス中に計算できない動的ロジックは**サポートされていません**:
-- `dynamicParams: true`を使用した[動的ルート](/docs/app/building-your-application/routing/dynamic-routes)
-- `generateStaticParams()`を使用しない[動的ルート](/docs/app/building-your-application/routing/dynamic-routes)
+- [`dynamicParams: true`を使用したDynamic Routes](/docs/app/building-your-application/routing/dynamic-routes)
+- `generateStaticParams()`を使用しない[Dynamic Routes](/docs/app/building-your-application/routing/dynamic-routes)
- Requestに依存する[Route Handlers](/docs/app/building-your-application/routing/route-handlers)
- [Cookies](/docs/app/api-reference/functions/cookies)
- [Rewrites](/docs/app/api-reference/config/next-config-js/rewrites)
@@ -336,7 +337,7 @@ Node.jsサーバーを必要とする機能や、ビルドプロセス中に計
- [Headers](/docs/app/api-reference/config/next-config-js/headers)
- [Middleware](/docs/app/building-your-application/routing/middleware)
- [Incremental Static Regeneration](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)
-- デフォルトの`loader`を使用した[画像最適化](/docs/app/building-your-application/optimizing/images)
+- デフォルトの`loader`を使用した[Image Optimization](/docs/app/building-your-application/optimizing/images)
- [Draft Mode](/docs/app/building-your-application/configuring/draft-mode)
- [Server Actions](/docs/app/building-your-application/data-fetching/server-actions-and-mutations)
- [Intercepting Routes](/docs/app/building-your-application/routing/intercepting-routes)
@@ -351,17 +352,17 @@ export const dynamic = 'error'
-- [国際化ルーティング](https://nextjs.org/docs/canary/pages/building-your-application/routing/internationalization)
+- [Internationalized Routing](https://nextjs.org/docs/canary/pages/building-your-application/routing/internationalization)
- [API Routes](https://nextjs.org/docs/canary/pages/building-your-application/routing/api-routes)
- [Rewrites](https://nextjs.org/docs/canary/pages/api-reference/config/next-config-js/rewrites)
- [Redirects](https://nextjs.org/docs/canary/pages/api-reference/config/next-config-js/redirects)
- [Headers](https://nextjs.org/docs/canary/pages/api-reference/config/next-config-js/headers)
- [Middleware](https://nextjs.org/docs/canary/pages/building-your-application/routing/middleware)
- [Incremental Static Regeneration](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/incremental-static-regeneration)
-- デフォルトの`loader`を使用した[画像最適化](https://nextjs.org/docs/canary/pages/building-your-application/optimizing/images)
+- デフォルトの`loader`を使用した[Image Optimization](https://nextjs.org/docs/canary/pages/building-your-application/optimizing/images)
- [Draft Mode](https://nextjs.org/docs/canary/pages/building-your-application/configuring/draft-mode)
-- [`fallback: true`を使用した`getStaticPaths`](https://nextjs.org/docs/canary/pages/api-reference/functions/get-static-paths#fallback-true)
-- [`fallback: 'blocking'`を使用した`getStaticPaths`](https://nextjs.org/docs/canary/pages/api-reference/functions/get-static-paths#fallback-blocking)
+- [`getStaticPaths` with `fallback: true`](https://nextjs.org/docs/canary/pages/api-reference/functions/get-static-paths#fallback-true)
+- [`getStaticPaths` with `fallback: 'blocking'`](https://nextjs.org/docs/canary/pages/api-reference/functions/get-static-paths#fallback-blocking)
- [`getServerSideProps`](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/get-server-side-props)
@@ -375,14 +376,14 @@ export const dynamic = 'error'
- `/`
- `/blog/[id]`
-`next build`を実行した後、Next.jsは次のファイルを生成します:
+`next build`を実行すると、Next.jsは次のファイルを生成します:
- `/out/index.html`
- `/out/404.html`
- `/out/blog/post-1.html`
- `/out/blog/post-2.html`
-Nginxのような静的ホストを使用している場合、受信リクエストを正しいファイルにリライトするように設定できます:
+Nginxのような静的ホストを使用している場合、受信リクエストから正しいファイルへのリライトを設定できます:
```nginx title="nginx.conf"
server {
@@ -410,8 +411,8 @@ server {
## バージョン履歴 {#version-history}
-| バージョン | 変更点 |
-| ---------- | ----------------------------------------------------------------------------------------------------------------------------- |
-| `v14.0.0` | `next export`は削除され、`"output": "export"`に置き換えられました |
-| `v13.4.0` | App Router(安定版)は、React Server ComponentsやRoute Handlersの使用を含む強化された静的エクスポートサポートを追加しました。 |
-| `v13.3.0` | `next export`は非推奨となり、`"output": "export"`に置き換えられました |
+| Version | 変更点 |
+| --------- | --------------------------------------------------------------------------------------------------------------------- |
+| `v14.0.0` | `next export`は削除され、`"output": "export"`が推奨されます |
+| `v13.4.0` | App Router(安定版)は、React Server ComponentsやRoute Handlersを含む強化された静的エクスポートサポートを追加します。 |
+| `v13.3.0` | `next export`は非推奨となり、`"output": "export"`に置き換えられます |
diff --git a/docs/01-app/02-guides/upgrading/version-14.mdx b/docs/01-app/02-guides/upgrading/version-14.mdx
index fbea4378..17055011 100644
--- a/docs/01-app/02-guides/upgrading/version-14.mdx
+++ b/docs/01-app/02-guides/upgrading/version-14.mdx
@@ -30,8 +30,8 @@ bun add next@next-14 react@18 react-dom@18 && bun add eslint-config-next@next-14
### v14の概要 {#v14-summary}
-- Node.jsの最低バージョンが16.14から18.17に引き上げられました。これは16.xがサポート終了となったためです
-- `next export`コマンドは`output: 'export'`設定に置き換えられました。詳細は[ドキュメント](https://nextjs.org/docs/app/building-your-application/deploying/static-exports)をご覧ください
+- Node.jsの最低バージョンが16.14から18.17に引き上げられました。16.xはサポート終了となったためです
+- `next export`コマンドは`output: 'export'`設定に置き換えられました。詳細は[ドキュメント](https://nextjs.org/docs/app/guides/static-exports)をご覧ください
- `ImageResponse`のための`next/server`インポートは`next/og`に名前が変更されました。インポートを安全かつ自動的にリネームするための[コードモッドが利用可能です](/docs/app/guides/upgrading/codemods#next-og-import)
- `@next/font`パッケージは組み込みの`next/font`に完全に置き換えられました。インポートを安全かつ自動的にリネームするための[コードモッドが利用可能です](/docs/app/guides/upgrading/codemods#built-in-next-font)
- `next-swc`のWASMターゲットが削除されました
diff --git a/docs/01-app/03-building-your-application/02-data-fetching/04-incremental-static-regeneration.mdx b/docs/01-app/03-building-your-application/02-data-fetching/04-incremental-static-regeneration.mdx
index a075c303..215550dc 100644
--- a/docs/01-app/03-building-your-application/02-data-fetching/04-incremental-static-regeneration.mdx
+++ b/docs/01-app/03-building-your-application/02-data-fetching/04-incremental-static-regeneration.mdx
@@ -15,7 +15,7 @@ description: 'Incremental Static Regenerationを使用して、実行時に静
Incremental Static Regeneration (ISR) により、次のことが可能になります:
- サイト全体を再構築することなく静的コンテンツを更新する
-- ほとんどのリクエストに対して事前レンダリングされた静的ページを提供することでサーバー負荷を軽減する
+- ほとんどのリクエストに対してプリレンダリングされた静的ページを提供することでサーバー負荷を軽減する
- 適切な `cache-control` ヘッダーがページに自動的に追加されることを保証する
- 長い `next build` 時間をかけずに大量のコンテンツページを処理する
@@ -36,8 +36,8 @@ interface Post {
// Next.jsはリクエストが来たときに、最大で60秒ごとにキャッシュを無効化します。
export const revalidate = 60
-// ビルド時に `generateStaticParams` からのパラメータのみを事前レンダリングします。
-// 生成されていないパスに対してリクエストが来た場合、Next.jsはオンデマンドでページをサーバーレンダリングします。
+// ビルド時に `generateStaticParams` からのパラメータのみをプリレンダリングします。
+// 生成されていないパスにリクエストが来た場合、Next.jsはオンデマンドでページをサーバーレンダリングします。
export const dynamicParams = true // または false にして、未知のパスで404を返す
export async function generateStaticParams() {
@@ -74,8 +74,8 @@ export default async function Page({
// Next.jsはリクエストが来たときに、最大で60秒ごとにキャッシュを無効化します。
export const revalidate = 60
-// ビルド時に `generateStaticParams` からのパラメータのみを事前レンダリングします。
-// 生成されていないパスに対してリクエストが来た場合、Next.jsはオンデマンドでページをサーバーレンダリングします。
+// ビルド時に `generateStaticParams` からのパラメータのみをプリレンダリングします。
+// 生成されていないパスにリクエストが来た場合、Next.jsはオンデマンドでページをサーバーレンダリングします。
export const dynamicParams = true // または false にして、未知のパスで404を返す
export async function generateStaticParams() {
@@ -132,7 +132,7 @@ export const getStaticPaths: GetStaticPaths = async () => {
params: { id: String(post.id) },
}))
- // ビルド時にこれらのパスのみを事前レンダリングします。
+ // ビルド時にこれらのパスのみをプリレンダリングします。
// { fallback: 'blocking' } は、パスが存在しない場合にオンデマンドでページをサーバーレンダリングします。
return { paths, fallback: false }
}
@@ -175,7 +175,7 @@ export async function getStaticPaths() {
params: { id: post.id },
}))
- // ビルド時にこれらのパスのみを事前レンダリングします。
+ // ビルド時にこれらのパスのみをプリレンダリングします。
// { fallback: false } は、他のルートが404を返すことを意味します。
return { paths, fallback: false }
}
@@ -212,7 +212,7 @@ export default function Page({ post }) {
1. `next build` の間に、すべての既知のブログ投稿が生成されます(この例では25件あります)
2. これらのページへのすべてのリクエスト(例:`/blog/1`)はキャッシュされ、即座に応答します
3. 60秒が経過した後、次のリクエストはキャッシュされた(古い)ページを表示します
-4. キャッシュが無効化され、ページの新しいバージョンがバックグラウンドで生成され始めます
+4. キャッシュが無効化され、新しいバージョンのページがバックグラウンドで生成され始めます
5. 正常に生成されると、Next.jsは更新されたページを表示し、キャッシュします
6. `/blog/26` がリクエストされた場合、Next.jsはこのページをオンデマンドで生成し、キャッシュします
@@ -225,7 +225,7 @@ export default function Page({ post }) {
- [`revalidate`](/docs/app/api-reference/file-conventions/route-segment-config#revalidate)
- [`dynamicParams`](/docs/app/api-reference/file-conventions/route-segment-config#dynamicparams)
-### Functions {#functions}
+### 関数 {#functions}
- [`revalidatePath`](/docs/app/api-reference/functions/revalidatePath)
- [`revalidateTag`](/docs/app/api-reference/functions/revalidateTag)
@@ -234,7 +234,7 @@ export default function Page({ post }) {
-### Functions {#functions}
+### 関数 {#functions}
- [`getStaticProps`](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/get-static-props)
- [`res.revalidate`](https://nextjs.org/docs/canary/pages/building-your-application/routing/api-routes#response-helpers)
@@ -247,7 +247,7 @@ export default function Page({ post }) {
### 時間ベースの再検証 {#time-based-revalidation}
-これは `/blog` でブログ投稿のリストを取得して表示します。1時間後、このページのキャッシュは次回のページ訪問時に無効化されます。その後、バックグラウンドで最新のブログ投稿を含むページの新しいバージョンが生成されます。
+これは `/blog` でブログ投稿のリストを取得して表示します。1時間後、このページのキャッシュは次回の訪問時に無効化されます。その後、バックグラウンドで最新のブログ投稿を含む新しいバージョンのページが生成されます。
@@ -259,7 +259,7 @@ interface Post {
content: string
}
-export const revalidate = 3600 // 1時間ごとに無効化
+export const revalidate = 3600 // 毎時無効化
export default async function Page() {
const data = await fetch('https://api.vercel.app/blog')
@@ -281,7 +281,7 @@ export default async function Page() {
```jsx title="app/blog/page.js" switcher
-export const revalidate = 3600 // 1時間ごとに無効化
+export const revalidate = 3600 // 毎時無効化
export default async function Page() {
const data = await fetch('https://api.vercel.app/blog')
@@ -302,13 +302,13 @@ export default async function Page() {
-再検証時間を長く設定することをお勧めします。例えば、1秒ではなく1時間です。より精密な再検証が必要な場合は、オンデマンド再検証を検討してください。リアルタイムデータが必要な場合は、[dynamic rendering](/docs/app/building-your-application/rendering/server-components#dynamic-rendering)への切り替えを検討してください。
+再検証時間を長く設定することをお勧めします。たとえば、1秒ではなく1時間です。より精密な制御が必要な場合は、オンデマンド再検証を検討してください。リアルタイムデータが必要な場合は、[動的レンダリング](/docs/app/building-your-application/rendering/server-components#dynamic-rendering)への切り替えを検討してください。
### `revalidatePath` を使用したオンデマンド再検証 {#on-demand-revalidation-with-revalidatepath}
より精密な再検証方法として、`revalidatePath` 関数を使用してオンデマンドでページを無効化します。
-例えば、新しい投稿を追加した後にこのServer Actionが呼び出されます。Server Componentでデータを取得する方法に関係なく、`fetch`を使用するかデータベースに接続するかにかかわらず、これによりルート全体のキャッシュがクリアされ、Server Componentが新しいデータを取得できるようになります。
+たとえば、新しい投稿を追加した後にこのServer Actionが呼び出されます。Server Componentでデータを取得する方法に関係なく、`fetch`を使用するかデータベースに接続するかにかかわらず、これによりルート全体のキャッシュがクリアされ、Server Componentが新しいデータを取得できるようになります。
@@ -345,7 +345,7 @@ export async function createPost() {
### `revalidateTag` を使用したオンデマンド再検証 {#on-demand-revalidation-with-revalidatetag}
-ほとんどのユースケースでは、全体のパスを再検証することをお勧めします。より細かい制御が必要な場合は、`revalidateTag` 関数を使用できます。例えば、個々の `fetch` 呼び出しにタグを付けることができます:
+ほとんどのユースケースでは、全体のパスを再検証することをお勧めします。より細かい制御が必要な場合は、`revalidateTag` 関数を使用できます。たとえば、個々の `fetch` 呼び出しにタグを付けることができます:
@@ -464,7 +464,7 @@ export async function createPost() {
より精密な再検証方法として、`res.revalidate` を使用してAPIルーターからオンデマンドで新しいページを生成します。
-例えば、このAPIルートは `/api/revalidate?secret=` で呼び出され、指定されたブログ投稿を再検証します。Next.jsアプリのみが知っているシークレットトークンを作成します。このシークレットは、再検証APIルートへの不正アクセスを防ぐために使用されます。
+たとえば、このAPIルートは `/api/revalidate?secret=` で呼び出され、指定されたブログ投稿を再検証します。Next.jsアプリのみが知っている秘密のトークンを作成します。この秘密は、再検証APIルートへの不正アクセスを防ぐために使用されます。
@@ -476,7 +476,7 @@ export default async function handler(
req: NextApiRequest,
res: NextApiResponse
) {
- // シークレットを確認して、これが有効なリクエストであることを確認します
+ // このリクエストが有効であることを確認するための秘密を確認します
if (req.query.secret !== process.env.MY_SECRET_TOKEN) {
return res.status(401).json({ message: 'Invalid token' })
}
@@ -487,8 +487,8 @@ export default async function handler(
await res.revalidate('/posts/1')
return res.json({ revalidated: true })
} catch (err) {
- // エラーが発生した場合、Next.jsは引き続き
- // 最後に正常に生成されたページを表示します
+ // エラーが発生した場合、Next.jsは
+ // 最後に正常に生成されたページを表示し続けます
return res.status(500).send('Error revalidating')
}
}
@@ -499,7 +499,7 @@ export default async function handler(
```js title="pages/api/revalidate.js" switcher
export default async function handler(req, res) {
- // シークレットを確認して、これが有効なリクエストであることを確認します
+ // このリクエストが有効であることを確認するための秘密を確認します
if (req.query.secret !== process.env.MY_SECRET_TOKEN) {
return res.status(401).json({ message: 'Invalid token' })
}
@@ -510,8 +510,8 @@ export default async function handler(req, res) {
await res.revalidate('/posts/1')
return res.json({ revalidated: true })
} catch (err) {
- // エラーが発生した場合、Next.jsは引き続き
- // 最後に正常に生成されたページを表示します
+ // エラーが発生した場合、Next.jsは
+ // 最後に正常に生成されたページを表示し続けます
return res.status(500).send('Error revalidating')
}
}
@@ -528,13 +528,13 @@ export default async function handler(req, res) {
-データを再検証しようとした際にエラーが発生した場合、最後に正常に生成されたデータがキャッシュから引き続き提供されます。次のリクエスト時に、Next.jsはデータの再検証を試みます。[エラー処理について詳しく学ぶ](/docs/app/building-your-application/routing/error-handling)。
+データを再検証しようとした際にエラーが発生した場合、最後に正常に生成されたデータがキャッシュから提供され続けます。次のリクエスト時に、Next.jsはデータの再検証を試みます。[エラー処理について詳しく学ぶ](/docs/app/building-your-application/routing/error-handling)。
-バックグラウンド再生成を処理する際に `getStaticProps` 内でエラーが発生した場合、または手動でエラーをスローした場合、最後に正常に生成されたページが引き続き表示されます。次のリクエスト時に、Next.jsは `getStaticProps` の呼び出しを再試行します。
+バックグラウンド再生成を処理する際に `getStaticProps` 内でエラーが発生した場合、または手動でエラーをスローした場合、最後に正常に生成されたページが表示され続けます。次のリクエスト時に、Next.jsは `getStaticProps` の呼び出しを再試行します。
@@ -566,7 +566,7 @@ export const getStaticProps: GetStaticProps = async ({
if (!res.ok) {
// サーバーエラーが発生した場合、キャッシュが更新されないように
// エラーをスローすることを検討してください。
- // 次の正常なリクエストまでキャッシュは更新されません。
+ // 次の成功したリクエストまで。
throw new Error(`Failed to fetch posts, received status ${res.status}`)
}
@@ -592,7 +592,7 @@ export async function getStaticProps({ params }) {
if (!res.ok) {
// サーバーエラーが発生した場合、キャッシュが更新されないように
// エラーをスローすることを検討してください。
- // 次の正常なリクエストまでキャッシュは更新されません。
+ // 次の成功したリクエストまで。
throw new Error(`Failed to fetch posts, received status ${res.status}`)
}
@@ -613,9 +613,9 @@ export async function getStaticProps({ params }) {
ページのキャッシュと再検証(Incremental Static Regenerationを使用)は、同じ共有キャッシュを使用します。[Vercelにデプロイする](https://vercel.com/docs/incremental-static-regeneration?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)場合、ISRキャッシュは自動的に耐久性のあるストレージに保存されます。
-セルフホスティングの場合、ISRキャッシュはNext.jsサーバーのファイルシステム(ディスク上)に保存されます。PagesとApp Routerの両方を使用してセルフホスティングする場合に自動的に機能します。
+セルフホスティングの場合、ISRキャッシュはNext.jsサーバーのファイルシステム(ディスク上)に保存されます。これは、PagesとApp Routerの両方を使用してセルフホスティングする場合に自動的に機能します。
-キャッシュされたページとデータを耐久性のあるストレージに保存したり、Next.jsアプリケーションの複数のコンテナやインスタンス間でキャッシュを共有したりする場合は、Next.jsのキャッシュの場所を設定できます。[詳細を学ぶ](/docs/app/building-your-application/deploying#caching-and-isr)。
+キャッシュされたページとデータを耐久性のあるストレージに保存したり、Next.jsアプリケーションの複数のコンテナやインスタンス間でキャッシュを共有したい場合は、Next.jsのキャッシュの場所を設定できます。[詳細を学ぶ](/docs/app/guides/self-hosting#caching-and-isr)。
## トラブルシューティング {#troubleshooting}
@@ -643,34 +643,34 @@ module.exports = {
NEXT_PRIVATE_DEBUG_CACHE=1
```
-これにより、Next.jsサーバーのコンソールにISRキャッシュのヒットとミスがログ出力されます。`next build` 中に生成されたページや、パスがオンデマンドでアクセスされる際にページがどのように更新されるかを確認できます。
+これにより、Next.jsサーバーのコンソールにISRキャッシュのヒットとミスがログ出力されます。`next build` 中に生成されたページや、パスがオンデマンドでアクセスされるときにページがどのように更新されるかを確認できます。
## 注意事項 {#caveats}
- ISRはNode.jsランタイム(デフォルト)を使用している場合にのみサポートされます。
-- ISRは[Static Export](/docs/app/building-your-application/deploying/static-exports)を作成する際にはサポートされません。
-- 静的にレンダリングされたルートに複数の `fetch` リクエストがあり、それぞれが異なる `revalidate` 周期を持つ場合、ISRには最も短い時間が使用されます。ただし、これらの再検証頻度は[Data Cache](/docs/app/building-your-application/caching#data-cache)によって引き続き尊重されます。
+- ISRは[Static Export](/docs/app/guides/static-exports)を作成する際にはサポートされていません。
+- 静的にレンダリングされたルートに複数の `fetch` リクエストがあり、それぞれが異なる `revalidate` 周期を持つ場合、ISRには最も短い時間が使用されます。ただし、これらの再検証頻度は[データキャッシュ](/docs/app/building-your-application/caching#data-cache)によって引き続き尊重されます。
- ルートで使用される `fetch` リクエストのいずれかが `revalidate` 時間を `0` に設定している場合、または明示的に `no-store` を指定している場合、そのルートは[動的にレンダリング](/docs/app/building-your-application/rendering/server-components#dynamic-rendering)されます。
-- オンデマンドISRリクエストに対してはミドルウェアは実行されません。つまり、ミドルウェア内のパスの書き換えやロジックは適用されません。正確なパスを再検証していることを確認してください。例えば、書き換えられた `/post-1` ではなく、`/post/1` です。
+- オンデマンドISRリクエストにはミドルウェアが実行されないため、ミドルウェア内のパスの書き換えやロジックは適用されません。正確なパスを再検証していることを確認してください。たとえば、書き換えられた `/post-1` ではなく、`/post/1` です。
- ISRはNode.jsランタイム(デフォルト)を使用している場合にのみサポートされます。
-- ISRは[Static Export](/docs/app/building-your-application/deploying/static-exports)を作成する際にはサポートされません。
-- オンデマンドISRリクエストに対してはミドルウェアは実行されません。つまり、ミドルウェア内のパスの書き換えやロジックは適用されません。正確なパスを再検証していることを確認してください。例えば、書き換えられた `/post-1` ではなく、`/post/1` です。
+- ISRは[Static Export](/docs/app/guides/static-exports)を作成する際にはサポートされていません。
+- オンデマンドISRリクエストにはミドルウェアが実行されないため、ミドルウェア内のパスの書き換えやロジックは適用されません。正確なパスを再検証していることを確認してください。たとえば、書き換えられた `/post-1` ではなく、`/post/1` です。
## バージョン履歴 {#version-history}
-| Version | Changes |
+| Version | 変更点 |
| --------- | ----------------------------------------------------------------------------------------------------------------- |
| `v14.1.0` | カスタム `cacheHandler` が安定版になりました。 |
| `v13.0.0` | App Router が導入されました。 |
-| `v12.2.0` | Pages Router: オンデマンドISRが安定版になりました |
+| `v12.2.0` | Pages Router: オンデマンドISRが安定版になりました。 |
| `v12.0.0` | Pages Router: [Bot-aware ISR fallback](https://nextjs.org/blog/next-12#bot-aware-isr-fallback) が追加されました。 |
| `v9.5.0` | Pages Router: [安定版ISRが導入されました](https://nextjs.org/blog/next-9-5)。 |
diff --git a/docs/01-app/03-building-your-application/07-configuring/16-debugging.mdx b/docs/01-app/03-building-your-application/07-configuring/16-debugging.mdx
index aeec4431..8d56c92a 100644
--- a/docs/01-app/03-building-your-application/07-configuring/16-debugging.mdx
+++ b/docs/01-app/03-building-your-application/07-configuring/16-debugging.mdx
@@ -1,17 +1,17 @@
---
title: 'デバッグ'
-description: 'VS Code、Chrome DevTools、またはFirefox DevToolsを使用してNext.jsアプリケーションをデバッグする方法を学びましょう。'
+description: 'VS Code、Chrome DevTools、または Firefox DevTools を使用して Next.js アプリケーションをデバッグする方法を学びます。'
---
-{/* このドキュメントの内容はapp routerとpages routerの間で共有されています。Pages Routerに特化した内容を追加するには、`Content`コンポーネントを使用できます。共有されるコンテンツはコンポーネントでラップしないでください。 */}
+{/* このドキュメントの内容は、app router と pages router の間で共有されています。Pages Router に特有のコンテンツを追加するには、`Content` コンポーネントを使用できます。共有コンテンツはコンポーネントでラップしないでください。 */}
-このドキュメントでは、[VS Codeデバッガー](https://code.visualstudio.com/docs/editor/debugging)、[Chrome DevTools](https://developers.google.com/web/tools/chrome-devtools)、または[Firefox DevTools](https://firefox-source-docs.mozilla.org/devtools-user/)を使用して、Next.jsのフロントエンドおよびバックエンドコードをフルソースマップサポートでデバッグする方法を説明します。
+このドキュメントでは、[VS Code デバッガー](https://code.visualstudio.com/docs/editor/debugging)、[Chrome DevTools](https://developers.google.com/web/tools/chrome-devtools)、または [Firefox DevTools](https://firefox-source-docs.mozilla.org/devtools-user/) を使用して、Next.js のフロントエンドおよびバックエンドコードをフルソースマップサポートでデバッグする方法を説明します。
-Node.jsにアタッチできるデバッガーであれば、Next.jsアプリケーションのデバッグに使用できます。詳細はNode.jsの[デバッグガイド](https://nodejs.org/en/docs/guides/debugging-getting-started/)をご覧ください。
+Node.js にアタッチできるデバッガーであれば、Next.js アプリケーションのデバッグにも使用できます。詳細は Node.js の[デバッグガイド](https://nodejs.org/en/docs/guides/debugging-getting-started/)をご覧ください。
-## VS Codeでのデバッグ {#debugging-with-vs-code}
+## VS Code でのデバッグ {#debugging-with-vs-code}
-プロジェクトのルートに`.vscode/launch.json`という名前のファイルを作成し、次の内容を記述します:
+プロジェクトの root に `.vscode/launch.json` という名前のファイルを作成し、次の内容を記述します:
```json title="launch.json"
{
@@ -46,7 +46,7 @@ Node.jsにアタッチできるデバッガーであれば、Next.jsアプリケ
"name": "Next.js: debug full stack",
"type": "node",
"request": "launch",
- "program": "${workspaceFolder}/node_modules/.bin/next",
+ "program": "${workspaceFolder}/node_modules/next/dist/bin/next",
"runtimeArgs": ["--inspect"],
"skipFiles": ["/**"],
"serverReadyAction": {
@@ -61,56 +61,56 @@ Node.jsにアタッチできるデバッガーであれば、Next.jsアプリケ
}
```
-> **Note**: VS CodeでFirefoxデバッグを使用するには、[Firefox Debugger拡張機能](https://marketplace.visualstudio.com/items?itemName=firefox-devtools.vscode-firefox-debug)をインストールする必要があります。
+> **Note**: VS Code で Firefox デバッグを使用するには、[Firefox Debugger 拡張機能](https://marketplace.visualstudio.com/items?itemName=firefox-devtools.vscode-firefox-debug)をインストールする必要があります。
-`npm run dev`は、Yarnを使用している場合は`yarn dev`、pnpmを使用している場合は`pnpm dev`に置き換えることができます。
+`npm run dev` は、Yarn を使用している場合は `yarn dev`、pnpm を使用している場合は `pnpm dev` に置き換えることができます。
-"Next.js: debug full stack"の設定では、`serverReadyAction.action`がサーバーが準備完了したときに開くブラウザを指定します。`debugWithEdge`はEdgeブラウザを起動することを意味します。Chromeを使用している場合は、この値を`debugWithChrome`に変更してください。
+"Next.js: debug full stack" の設定では、`serverReadyAction.action` がサーバーが準備完了したときに開くブラウザを指定します。`debugWithEdge` は Edge ブラウザを起動することを意味します。Chrome を使用している場合は、この値を `debugWithChrome` に変更してください。
-アプリケーションの起動時に[ポート番号を変更している](https://nextjs.org/docs/canary/pages/api-reference/cli/next#next-dev-options)場合は、`http://localhost:3000`の`3000`を使用しているポートに置き換えてください。
+アプリケーションの起動時に[ポート番号を変更している場合](https://nextjs.org/docs/canary/pages/api-reference/cli/next#next-dev-options)、`http://localhost:3000` の `3000` を使用しているポートに置き換えてください。
-Next.jsをroot以外のディレクトリから実行している場合(例えば、Turborepoを使用している場合)、サーバーサイドおよびフルスタックデバッグタスクに`cwd`を追加する必要があります。例えば、`"cwd": "${workspaceFolder}/apps/web"`のようにします。
+Next.js を root 以外のディレクトリから実行している場合(たとえば、Turborepo を使用している場合)、サーバーサイドおよびフルスタックデバッグタスクに `cwd` を追加する必要があります。たとえば、`"cwd": "${workspaceFolder}/apps/web"` のようにします。
-次に、デバッグパネル(Windows/Linuxでは`Ctrl+Shift+D`、macOSでは`⇧+⌘+D`)に移動し、起動構成を選択して、`F5`を押すか、コマンドパレットから**Debug: Start Debugging**を選択してデバッグセッションを開始します。
+次に、デバッグパネル(Windows/Linux では `Ctrl+Shift+D`、macOS では `⇧+⌘+D`)に移動し、起動構成を選択して `F5` を押すか、コマンドパレットから **Debug: Start Debugging** を選択してデバッグセッションを開始します。
-## Jetbrains WebStormでのデバッガーの使用 {#using-the-debugger-in-jetbrains-webstorm}
+## Jetbrains WebStorm でのデバッガーの使用 {#using-the-debugger-in-jetbrains-webstorm}
-ランタイム構成をリストしているドロップダウンメニューをクリックし、`Edit Configurations...`をクリックします。`http://localhost:3000`をURLとして`JavaScript Debug`デバッグ構成を作成します。お好みに合わせてカスタマイズ(例:デバッグ用のブラウザ、プロジェクトファイルとして保存)し、`OK`をクリックします。このデバッグ構成を実行すると、選択したブラウザが自動的に開きます。この時点で、NextJSノードアプリケーションとクライアント/ブラウザアプリケーションの2つがデバッグモードになります。
+ランタイム構成をリストしているドロップダウンメニューをクリックし、`Edit Configurations...` をクリックします。`http://localhost:3000` を URL として `JavaScript Debug` デバッグ構成を作成します。好みに合わせてカスタマイズ(例:デバッグ用のブラウザ、プロジェクトファイルとして保存)し、`OK` をクリックします。このデバッグ構成を実行すると、選択したブラウザが自動的に開きます。この時点で、NextJS ノードアプリケーションとクライアント/ブラウザアプリケーションの2つがデバッグモードになります。
-## ブラウザDevToolsでのデバッグ {#debugging-with-browser-devtools}
+## ブラウザ DevTools でのデバッグ {#debugging-with-browser-devtools}
### クライアントサイドコード {#client-side-code}
-通常どおり`next dev`、`npm run dev`、または`yarn dev`を実行して開発サーバーを起動します。サーバーが起動したら、お好みのブラウザで`http://localhost:3000`(または代替URL)を開きます。
+通常どおり `next dev`、`npm run dev`、または `yarn dev` を実行して開発サーバーを開始します。サーバーが起動したら、`http://localhost:3000`(または代替 URL)をお好みのブラウザで開きます。
-Chromeの場合:
+Chrome の場合:
-- Chromeの開発者ツールを開く(Windows/Linuxでは`Ctrl+Shift+J`、macOSでは`⌥+⌘+I`)
-- **Sources**タブに移動
+- Chrome のデベロッパーツールを開く(Windows/Linux では `Ctrl+Shift+J`、macOS では `⌥+⌘+I`)
+- **Sources** タブに移動
-Firefoxの場合:
+Firefox の場合:
-- Firefoxの開発者ツールを開く(Windows/Linuxでは`Ctrl+Shift+I`、macOSでは`⌥+⌘+I`)
-- **Debugger**タブに移動
+- Firefox のデベロッパーツールを開く(Windows/Linux では `Ctrl+Shift+I`、macOS では `⌥+⌘+I`)
+- **Debugger** タブに移動
-どちらのブラウザでも、クライアントサイドコードが[`debugger`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/debugger)ステートメントに到達するたびに、コードの実行が一時停止し、そのファイルがデバッグエリアに表示されます。また、手動でブレークポイントを設定するためにファイルを検索することもできます:
+どちらのブラウザでも、クライアントサイドコードが [`debugger`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Statements/debugger) ステートメントに到達するたびに、コードの実行が一時停止し、そのファイルがデバッグエリアに表示されます。また、ファイルを検索して手動でブレークポイントを設定することもできます:
-- Chromeでは:Windows/Linuxでは`Ctrl+P`、macOSでは`⌘+P`を押す
-- Firefoxでは:Windows/Linuxでは`Ctrl+P`、macOSでは`⌘+P`を押すか、左パネルのファイルツリーを使用
+- Chrome では:Windows/Linux では `Ctrl+P`、macOS では `⌘+P` を押す
+- Firefox では:Windows/Linux では `Ctrl+P`、macOS では `⌘+P` を押すか、左パネルのファイルツリーを使用
-検索時に、ソースファイルのパスは`webpack://_N_E/./`で始まります。
+検索時に、ソースファイルのパスは `webpack://_N_E/./` で始まります。
### サーバーサイドコード {#server-side-code}
-ブラウザDevToolsを使用してサーバーサイドのNext.jsコードをデバッグするには、基盤となるNode.jsプロセスに[`--inspect`](https://nodejs.org/api/cli.html#cli_inspect_host_port)フラグを渡す必要があります:
+ブラウザ DevTools を使用してサーバーサイドの Next.js コードをデバッグするには、基盤となる Node.js プロセスに [`--inspect`](https://nodejs.org/api/cli.html#cli_inspect_host_port) フラグを渡す必要があります:
```bash title="Terminal"
NODE_OPTIONS='--inspect' next dev
```
-> **Good to know**: `NODE_OPTIONS='--inspect=0.0.0.0'`を使用すると、Dockerコンテナでアプリを実行する場合など、localhost以外でのリモートデバッグアクセスが可能になります。
+> **Good to know**: `NODE_OPTIONS='--inspect=0.0.0.0'` を使用すると、Docker コンテナでアプリを実行する場合など、localhost 以外でのリモートデバッグアクセスが可能になります。
-`npm run dev`または`yarn dev`を使用している場合は、`package.json`の`dev`スクリプトを更新する必要があります:
+`npm run dev` または `yarn dev` を使用している場合は、`package.json` の `dev` スクリプトを更新する必要があります:
```json title="package.json"
{
@@ -120,7 +120,7 @@ NODE_OPTIONS='--inspect' next dev
}
```
-`--inspect`フラグを使用してNext.js開発サーバーを起動すると、次のようになります:
+`--inspect` フラグを使用して Next.js 開発サーバーを起動すると、次のようになります:
```bash title="Terminal"
Debugger listening on ws://127.0.0.1:9229/0cf90313-350d-4466-a748-cd60f4e47c95
@@ -128,34 +128,34 @@ For help, see: https://nodejs.org/en/docs/inspector
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
```
-Chromeの場合:
+Chrome の場合:
-1. 新しいタブを開き、`chrome://inspect`にアクセス
-2. **Configure...**をクリックして、両方のデバッグポートがリストされていることを確認
-3. `localhost:9229`と`localhost:9230`の両方を追加(まだ存在しない場合)
-4. **Remote Target**セクションでNext.jsアプリケーションを探す
-5. **inspect**をクリックして、別のDevToolsウィンドウを開く
-6. **Sources**タブに移動
+1. 新しいタブを開き、`chrome://inspect` にアクセス
+2. **Configure...** をクリックして、両方のデバッグポートがリストされていることを確認
+3. `localhost:9229` と `localhost:9230` の両方を追加(まだ存在しない場合)
+4. **Remote Target** セクションで Next.js アプリケーションを探す
+5. **inspect** をクリックして、別の DevTools ウィンドウを開く
+6. **Sources** タブに移動
-Firefoxの場合:
+Firefox の場合:
-1. 新しいタブを開き、`about:debugging`にアクセス
-2. 左サイドバーで**This Firefox**をクリック
-3. **Remote Targets**の下でNext.jsアプリケーションを見つける
-4. **Inspect**をクリックしてデバッガーを開く
-5. **Debugger**タブに移動
+1. 新しいタブを開き、`about:debugging` にアクセス
+2. 左サイドバーで **This Firefox** をクリック
+3. **Remote Targets** の下で Next.js アプリケーションを見つける
+4. **Inspect** をクリックしてデバッガーを開く
+5. **Debugger** タブに移動
-サーバーサイドコードのデバッグは、クライアントサイドのデバッグと同様に機能します。ファイルを検索する際(`Ctrl+P`/`⌘+P`)、ソースファイルのパスは`webpack://{application-name}/./`で始まります(`{application-name}`は`package.json`ファイルに従ってアプリケーションの名前に置き換えられます)。
+サーバーサイドコードのデバッグは、クライアントサイドのデバッグと同様に機能します。ファイルを検索する際(`Ctrl+P`/`⌘+P`)、ソースファイルのパスは `webpack://{application-name}/./` で始まります(`{application-name}` は `package.json` ファイルに従ってアプリケーションの名前に置き換えられます)。
-### ブラウザDevToolsでサーバーエラーを検査する {#inspect-server-errors-with-browser-devtools}
+### ブラウザ DevTools でサーバーエラーを検査する {#inspect-server-errors-with-browser-devtools}
エラーが発生した場合、ソースコードを検査することでエラーの根本原因を追跡するのに役立ちます。
-Next.jsは、エラーオーバーレイのNext.jsバージョンインジケーターの下にNode.jsアイコンを表示します。そのアイコンをクリックすると、DevToolsのURLがクリップボードにコピーされます。そのURLで新しいブラウザタブを開くことで、Next.jsサーバープロセスを検査できます。
+Next.js は、エラーオーバーレイの Next.js バージョンインジケーターの下に Node.js アイコンを表示します。そのアイコンをクリックすると、DevTools の URL がクリップボードにコピーされます。その URL を使用して新しいブラウザタブを開き、Next.js サーバープロセスを検査できます。
-### Windowsでのデバッグ {#debugging-on-windows}
+### Windows でのデバッグ {#debugging-on-windows}
-Windowsユーザーは、`NODE_OPTIONS='--inspect'`を使用する際に問題が発生する可能性があります。この構文はWindowsプラットフォームではサポートされていないためです。これを回避するには、[`cross-env`](https://www.npmjs.com/package/cross-env)パッケージを開発依存関係としてインストールし(`npm`と`yarn`では`-D`)、`dev`スクリプトを次のように置き換えます。
+Windows ユーザーは、`NODE_OPTIONS='--inspect'` を使用する際に問題が発生する可能性があります。この構文は Windows プラットフォームではサポートされていません。これを回避するために、[`cross-env`](https://www.npmjs.com/package/cross-env) パッケージを開発依存関係としてインストールし(`npm` と `yarn` では `-D`)、`dev` スクリプトを次のように置き換えます。
```json title="package.json"
{
@@ -165,14 +165,14 @@ Windowsユーザーは、`NODE_OPTIONS='--inspect'`を使用する際に問題
}
```
-`cross-env`は、どのプラットフォーム(Mac、Linux、Windowsを含む)でも`NODE_OPTIONS`環境変数を設定し、デバイスやオペレーティングシステムを問わず一貫してデバッグできるようにします。
+`cross-env` は、どのプラットフォーム(Mac、Linux、Windows を含む)でも `NODE_OPTIONS` 環境変数を設定し、デバイスやオペレーティングシステム間で一貫してデバッグできるようにします。
-> **Good to know**: Windows Defenderが無効になっていることを確認してください。この外部サービスは*すべてのファイル読み取り*をチェックし、`next dev`でのFast Refresh時間を大幅に増加させることが報告されています。これはNext.jsに関連しない既知の問題ですが、Next.jsの開発に影響を与えます。
+> **Good to know**: Windows Defender が無効になっていることを確認してください。この外部サービスは*すべてのファイル読み取り*をチェックし、`next dev` での Fast Refresh 時間を大幅に増加させると報告されています。これは Next.js に関連しない既知の問題ですが、Next.js の開発に影響を与えます。
## 詳細情報 {#more-information}
-JavaScriptデバッガーの使用方法について詳しく学ぶには、次のドキュメントをご覧ください:
+JavaScript デバッガーの使用方法について詳しく学ぶには、次のドキュメントをご覧ください:
-- [VS CodeでのNode.jsデバッグ:ブレークポイント](https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_breakpoints)
-- [Chrome DevTools:JavaScriptのデバッグ](https://developers.google.com/web/tools/chrome-devtools/javascript)
+- [VS Code での Node.js デバッグ:ブレークポイント](https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_breakpoints)
+- [Chrome DevTools:JavaScript のデバッグ](https://developers.google.com/web/tools/chrome-devtools/javascript)
- [Firefox DevTools:デバッガー](https://firefox-source-docs.mozilla.org/devtools-user/debugger/)
diff --git a/docs/01-app/03-building-your-application/07-configuring/16-progressive-web-apps.mdx b/docs/01-app/03-building-your-application/07-configuring/16-progressive-web-apps.mdx
index d4716b3f..877f5b29 100644
--- a/docs/01-app/03-building-your-application/07-configuring/16-progressive-web-apps.mdx
+++ b/docs/01-app/03-building-your-application/07-configuring/16-progressive-web-apps.mdx
@@ -1,24 +1,24 @@
---
title: 'Progressive Web Applications (PWA)'
-description: 'Next.jsでProgressive Web Application (PWA)を構築する方法を学びます。'
+description: 'Next.jsでProgressive Web Application (PWA)を構築する方法を学びましょう。'
related:
links:
- - app/api-reference/file-conventions/metadata/manifest
+ - 'app/api-reference/file-conventions/metadata/manifest'
---
Progressive Web Applications (PWA)は、Webアプリケーションの到達範囲とアクセシビリティを、ネイティブモバイルアプリの機能とユーザーエクスペリエンスと組み合わせたものです。Next.jsを使用すると、複数のコードベースやアプリストアの承認を必要とせずに、すべてのプラットフォームでシームレスでアプリのような体験を提供するPWAを作成できます。
PWAを使用すると、次のことが可能です:
-- アプリストアの承認を待たずに、即座に更新をデプロイする
-- 単一のコードベースでクロスプラットフォームのアプリケーションを作成する
-- ホーム画面へのインストールやプッシュ通知など、ネイティブのような機能を提供する
+- アプリストアの承認を待たずに、即座に更新をデプロイ
+- 単一のコードベースでクロスプラットフォームのアプリケーションを作成
+- ホーム画面へのインストールやプッシュ通知など、ネイティブのような機能を提供
## Next.jsでPWAを作成する {#creating-a-pwa-with-next-js}
-### 1. Webアプリマニフェストの作成 {#1-creating-the-web-app-manifest}
+### 1. Web App Manifestの作成 {#1-creating-the-web-app-manifest}
-Next.jsは、App Routerを使用して[webアプリマニフェスト](/docs/app/api-reference/file-conventions/metadata/manifest)を作成するための組み込みサポートを提供しています。静的または動的なマニフェストファイルを作成できます:
+Next.jsは、App Routerを使用して[web app manifest](/docs/app/api-reference/file-conventions/metadata/manifest)を作成するための組み込みサポートを提供しています。静的または動的なmanifestファイルを作成できます:
例えば、`app/manifest.ts`または`app/manifest.json`ファイルを作成します:
@@ -28,7 +28,7 @@ Next.jsは、App Routerを使用して[webアプリマニフェスト](/docs/app
```tsx title="app/manifest.ts" switcher
import type { MetadataRoute } from 'next'
-// マニフェストを返す関数
+// PWAのメタデータを定義する関数をエクスポート
export default function manifest(): MetadataRoute.Manifest {
return {
name: 'Next.js PWA',
@@ -58,7 +58,7 @@ export default function manifest(): MetadataRoute.Manifest {
```jsx title="app/manifest.js" switcher
-// マニフェストを返す関数
+// PWAのメタデータを定義する関数をエクスポート
export default function manifest() {
return {
name: 'Next.js PWA',
@@ -87,13 +87,13 @@ export default function manifest() {
-このファイルには、名前、アイコン、およびユーザーのデバイスにアイコンとして表示される方法に関する情報を含める必要があります。これにより、ユーザーはPWAをホーム画面にインストールし、ネイティブアプリのような体験を提供できます。
+このファイルには、名前、アイコン、ユーザーのデバイス上でアイコンとして表示される方法に関する情報が含まれている必要があります。これにより、ユーザーはPWAをホーム画面にインストールし、ネイティブアプリのような体験を提供できます。
-[faviconジェネレーター](https://realfavicongenerator.net/)のようなツールを使用して、さまざまなアイコンセットを作成し、生成されたファイルを`public/`フォルダに配置できます。
+[favicon generators](https://realfavicongenerator.net/)のようなツールを使用して、さまざまなアイコンセットを作成し、生成されたファイルを`public/`フォルダに配置できます。
-### 2. Webプッシュ通知の実装 {#2-implementing-web-push-notifications}
+### 2. Web Push Notificationsの実装 {#2-implementing-web-push-notifications}
-Webプッシュ通知は、次のすべての最新ブラウザでサポートされています:
+Web Push Notificationsは、以下を含むすべての最新ブラウザでサポートされています:
- ホーム画面にインストールされたアプリケーション用のiOS 16.4+
- macOS 13以降のSafari 16
@@ -102,9 +102,9 @@ Webプッシュ通知は、次のすべての最新ブラウザでサポート
これにより、PWAはネイティブアプリの代替として有効です。特に、オフラインサポートを必要とせずにインストールプロンプトをトリガーできます。
-Webプッシュ通知を使用すると、ユーザーがアプリを積極的に使用していないときでも再エンゲージできます。Next.jsアプリケーションでの実装方法は次のとおりです:
+Web Push Notificationsを使用すると、ユーザーがアプリを積極的に使用していないときでも再エンゲージできます。Next.jsアプリケーションでの実装方法は次のとおりです:
-まず、`app/page.tsx`にメインページコンポーネントを作成します。理解を深めるために小さな部分に分けて説明します。まず、必要なインポートとユーティリティを追加します。参照されているServer Actionsがまだ存在しないことは問題ありません:
+まず、`app/page.tsx`にメインページコンポーネントを作成します。理解を深めるために、これを小さな部分に分解します。まず、必要なインポートとユーティリティを追加します。参照されているServer Actionsがまだ存在しないことは問題ありません:
```tsx switcher
'use client'
@@ -203,7 +203,7 @@ function PushNotificationManager() {
}
if (!isSupported) {
- return このブラウザではプッシュ通知はサポートされていません。
+ return このブラウザではプッシュ通知がサポートされていません。
}
return (
@@ -280,7 +280,7 @@ function PushNotificationManager() {
}
if (!isSupported) {
- return このブラウザではプッシュ通知はサポートされていません。
;
+ return このブラウザではプッシュ通知がサポートされていません。
;
}
return (
@@ -309,7 +309,7 @@ function PushNotificationManager() {
}
```
-最後に、iOSデバイスにホーム画面にインストールするよう指示するメッセージを表示するコンポーネントを作成し、アプリがすでにインストールされている場合はこれを表示しないようにします。
+最後に、iOSデバイスにホーム画面にインストールするよう指示するメッセージを表示するコンポーネントを作成し、アプリがすでにインストールされていない場合にのみ表示します。
```tsx switcher
function InstallPrompt() {
@@ -339,12 +339,12 @@ function InstallPrompt() {
{' '}
⎋{' '}
- てから「ホーム画面に追加」を選択します
+ てから「ホーム画面に追加」
{' '}
➕{' '}
- 。
+ を選択してください。
)}
@@ -389,11 +389,12 @@ function InstallPrompt() {
{' '}
⎋{' '}
- てから「ホーム画面に追加」を選択します
+ てから「ホーム画面に追加」
{' '}
➕{' '}
- 。
+
+ を選択してください。
)}
@@ -437,7 +438,7 @@ let subscription: PushSubscription | null = null
export async function subscribeUser(sub: PushSubscription) {
subscription = sub
// 本番環境では、購読をデータベースに保存することをお勧めします
- // 例:await db.subscriptions.create({ data: sub })
+ // 例: await db.subscriptions.create({ data: sub })
return { success: true }
}
@@ -445,7 +446,7 @@ export async function subscribeUser(sub: PushSubscription) {
export async function unsubscribeUser() {
subscription = null
// 本番環境では、データベースから購読を削除することをお勧めします
- // 例:await db.subscriptions.delete({ where: { ... } })
+ // 例: await db.subscriptions.delete({ where: { ... } })
return { success: true }
}
@@ -493,7 +494,7 @@ let subscription= null;
export async function subscribeUser(sub) {
subscription = sub;
// 本番環境では、購読をデータベースに保存することをお勧めします
- // 例:await db.subscriptions.create({ data: sub })
+ // 例: await db.subscriptions.create({ data: sub })
return { success: true };
}
@@ -501,7 +502,7 @@ export async function subscribeUser(sub) {
export async function unsubscribeUser() {
subscription = null;
// 本番環境では、データベースから購読を削除することをお勧めします
- // 例:await db.subscriptions.delete({ where: { ... } })
+ // 例: await db.subscriptions.delete({ where: { ... } })
return { success: true };
}
@@ -558,12 +559,12 @@ NEXT_PUBLIC_VAPID_PUBLIC_KEY=your_public_key_here
VAPID_PRIVATE_KEY=your_private_key_here
```
-### 5. サービスワーカーの作成 {#5-creating-a-service-worker}
+### 5. Service Workerの作成 {#5-creating-a-service-worker}
サービスワーカー用に`public/sw.js`ファイルを作成します:
```js title="public/sw.js"
-// プッシュイベントのリスナー
+// プッシュイベントをリッスン
self.addEventListener('push', function (event) {
if (event.data) {
const data = event.data.json()
@@ -581,7 +582,7 @@ self.addEventListener('push', function (event) {
}
})
-// 通知クリックイベントのリスナー
+// 通知クリックイベントをリッスン
self.addEventListener('notificationclick', function (event) {
console.log('通知クリックを受信しました。')
event.notification.close()
@@ -591,11 +592,11 @@ self.addEventListener('notificationclick', function (event) {
このサービスワーカーは、カスタム画像と通知をサポートします。受信したプッシュイベントと通知クリックを処理します。
-- 通知のカスタムアイコンを`icon`と`badge`プロパティを使用して設定できます。
-- `vibrate`パターンを調整して、サポートされているデバイスでカスタム振動アラートを作成できます。
-- `data`プロパティを使用して、通知に追加のデータを添付できます。
+- 通知のカスタムアイコンは、`icon`と`badge`プロパティを使用して設定できます。
+- `vibrate`パターンは、サポートされているデバイスでカスタム振動アラートを作成するために調整できます。
+- 追加のデータは、`data`プロパティを使用して通知に添付できます。
-サービスワーカーが異なるデバイスやブラウザで期待どおりに動作することを確認するために、十分にテストしてください。また、`notificationclick`イベントリスナー内の`'https://your-website.com'`リンクをアプリケーションの適切なURLに更新することを忘れないでください。
+サービスワーカーがさまざまなデバイスやブラウザで期待どおりに動作することを確認するために、十分にテストしてください。また、`notificationclick`イベントリスナー内の`'https://your-website.com'`リンクをアプリケーションの適切なURLに更新することを忘れないでください。
### 6. ホーム画面への追加 {#6-adding-to-home-screen}
@@ -603,7 +604,7 @@ self.addEventListener('notificationclick', function (event) {
モバイルのホーム画面にアプリケーションをインストールできるようにするには、次の要件を満たす必要があります:
-1. 有効なwebアプリマニフェスト(ステップ1で作成)
+1. 有効なweb app manifest(ステップ1で作成)
2. HTTPSで提供されるウェブサイト
これらの条件が満たされると、最新のブラウザは自動的にユーザーにインストールプロンプトを表示します。[`beforeinstallprompt`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeinstallprompt_event)を使用してカスタムインストールボタンを提供することもできますが、これはクロスブラウザおよびプラットフォームではないため(Safari iOSでは動作しません)、お勧めしません。
@@ -621,7 +622,7 @@ self.addEventListener('notificationclick', function (event) {
### 8. アプリケーションのセキュリティ {#8-securing-your-application}
-セキュリティは、特にPWAにおいて、Webアプリケーションの重要な側面です。Next.jsでは、`next.config.js`ファイルを使用してセキュリティヘッダーを設定できます。例えば:
+セキュリティは、特にPWAにおいて、すべてのWebアプリケーションの重要な側面です。Next.jsでは、`next.config.js`ファイルを使用してセキュリティヘッダーを設定できます。例えば:
```js title="next.config.js"
module.exports = {
@@ -671,18 +672,18 @@ module.exports = {
1. グローバルヘッダー(すべてのルートに適用):
1. `X-Content-Type-Options: nosniff`:MIMEタイプのスニッフィングを防止し、悪意のあるファイルアップロードのリスクを軽減します。
2. `X-Frame-Options: DENY`:クリックジャッキング攻撃から保護し、サイトがiframeに埋め込まれるのを防ぎます。
- 3. `Referrer-Policy: strict-origin-when-cross-origin`:リクエストに含まれるリファラー情報の量を制御し、セキュリティと機能性のバランスを取ります。
+ 3. `Referrer-Policy: strict-origin-when-cross-origin`:リクエストに含まれるリファラー情報の量を制御し、セキュリティと機能のバランスを取ります。
2. サービスワーカー固有のヘッダー:
1. `Content-Type: application/javascript; charset=utf-8`:サービスワーカーが正しくJavaScriptとして解釈されることを保証します。
- 2. `Cache-Control: no-cache, no-store, must-revalidate`:サービスワーカーのキャッシュを防止し、常に最新バージョンをユーザーに提供します。
- 3. `Content-Security-Policy: default-src 'self'; script-src 'self'`:サービスワーカーに対して厳格なコンテンツセキュリティポリシーを実装し、同じオリジンからのスクリプトのみを許可します。
+ 2. `Cache-Control: no-cache, no-store, must-revalidate`:サービスワーカーのキャッシュを防止し、ユーザーが常に最新バージョンを取得することを保証します。
+ 3. `Content-Security-Policy: default-src 'self'; script-src 'self'`:サービスワーカーのための厳格なコンテンツセキュリティポリシーを実装し、同じオリジンからのスクリプトのみを許可します。
-Next.jsでの[コンテンツセキュリティポリシーの定義](/docs/app/building-your-application/configuring/content-security-policy)について詳しく学びましょう。
+Next.jsでの[Content Security Policiesの定義](/docs/app/building-your-application/configuring/content-security-policy)について詳しく学びましょう。
## 次のステップ {#next-steps}
-1. **PWAの機能を探る**:PWAはさまざまなWeb APIを活用して高度な機能を提供できます。バックグラウンド同期、定期的なバックグラウンド同期、またはファイルシステムアクセスAPIなどの機能を探求して、アプリケーションを強化することを検討してください。PWAの機能に関するインスピレーションや最新情報については、[What PWA Can Do Today](https://whatpwacando.today/)などのリソースを参照できます。
-2. **静的エクスポート**:アプリケーションがサーバーを実行せず、代わりにファイルの静的エクスポートを使用する必要がある場合、Next.jsの設定を更新してこの変更を有効にできます。[Next.js静的エクスポートのドキュメント](/docs/app/building-your-application/deploying/static-exports)で詳しく学びましょう。ただし、Server Actionsから外部APIの呼び出しに移行し、定義されたヘッダーをプロキシに移動する必要があります。
+1. **PWAの機能を探る**:PWAはさまざまなWeb APIを活用して高度な機能を提供できます。バックグラウンド同期、定期的なバックグラウンド同期、またはFile System Access APIなどの機能を探求して、アプリケーションを強化することを検討してください。PWAの機能に関するインスピレーションや最新情報については、[What PWA Can Do Today](https://whatpwacando.today/)などのリソースを参照できます。
+2. **静的エクスポート**:アプリケーションがサーバーを実行せず、代わりにファイルの静的エクスポートを使用する必要がある場合は、Next.jsの設定を更新してこの変更を有効にできます。[Next.js Static Exportドキュメント](/docs/app/guides/static-exports)で詳しく学びましょう。ただし、Server Actionsから外部APIの呼び出しに移行し、定義されたヘッダーをプロキシに移動する必要があります。
3. **オフラインサポート**:オフライン機能を提供するための1つのオプションは、Next.jsと[Serwist](https://github.com/serwist/serwist)を使用することです。Next.jsとSerwistを統合する方法の例は、[ドキュメント](https://github.com/serwist/serwist/tree/main/examples/next-basic)で見つけることができます。**注意**:このプラグインは現在、webpackの設定が必要です。
4. **セキュリティの考慮事項**:サービスワーカーが適切に保護されていることを確認してください。これには、HTTPSの使用、プッシュメッセージのソースの検証、適切なエラーハンドリングの実装が含まれます。
-5. **ユーザーエクスペリエンス**:ユーザーのブラウザが特定のPWA機能をサポートしていない場合でも、アプリが正常に動作するように、プログレッシブエンハンスメント技術を実装することを検討してください。
+5. **ユーザーエクスペリエンス**:ユーザーのブラウザが特定のPWA機能をサポートしていない場合でも、アプリがうまく動作するように、プログレッシブエンハンスメント技術を実装することを検討してください。
diff --git a/docs/01-app/03-building-your-application/index.mdx b/docs/01-app/03-building-your-application/index.mdx
index 69d07e4d..891c2ab3 100644
--- a/docs/01-app/03-building-your-application/index.mdx
+++ b/docs/01-app/03-building-your-application/index.mdx
@@ -3,20 +3,20 @@ title: 'アプリケーションの構築'
description: 'Next.jsの機能を使ってアプリケーションを構築する方法を学びましょう。'
---
-{/* このドキュメントの内容は、app router と pages router の間で共有されています。Pages Router に特有の内容を追加するには、`Content` コンポーネントを使用できます。共有される内容はコンポーネントでラップしないでください。 */}
+{/* このドキュメントの内容は、app routerとpages routerの間で共有されています。Pages Routerに特化した内容を追加するには、`Content`コンポーネントを使用できます。共有される内容はコンポーネントでラップしないでください。 */}
-Next.jsは、柔軟なフルスタックWebアプリケーションを作成するための基盤を提供します。**アプリケーションの構築**ガイドでは、これらの機能をどのように使用し、アプリケーションの動作をどのようにカスタマイズするかを説明します。
+Next.jsは、柔軟でフルスタックなWebアプリケーションを作成するための基盤を提供します。**アプリケーションの構築**ガイドでは、これらの機能をどのように使用し、アプリケーションの動作をどのようにカスタマイズするかを説明します。
セクションとページは基本から高度なものへと順に整理されているため、Next.jsアプリケーションを構築する際にステップバイステップで進めることができます。ただし、どの順序で読んでもよく、あなたのユースケースに適したページに直接進むこともできます。
-Next.jsを初めて使用する場合は、[ルーティング](/docs/app/building-your-application/routing)、[レンダリング](/docs/app/building-your-application/rendering)、[データフェッチング](/docs/app/building-your-application/data-fetching)、[スタイリング](/docs/app/building-your-application/styling)のセクションから始めることをお勧めします。これらのセクションは、Next.jsとWebの基本概念を紹介し、スタートを切るのに役立ちます。その後、[最適化](/docs/app/building-your-application/optimizing)や[設定](/docs/app/building-your-application/configuring)などの他のセクションを深く掘り下げることができます。最後に、準備が整ったら、[デプロイ](/docs/app/building-your-application/deploying)と[アップグレード](/docs/app/guides/upgrading)のセクションを確認してください。
+Next.jsを初めて使用する場合は、[ルーティング](/docs/app/building-your-application/routing)、[レンダリング](/docs/app/building-your-application/rendering)、[データフェッチング](/docs/app/building-your-application/data-fetching)、[スタイリング](/docs/app/building-your-application/styling)のセクションから始めることをお勧めします。これらのセクションは、Next.jsとWebの基本概念を紹介し、スタートを切るのに役立ちます。その後、[最適化](/docs/app/building-your-application/optimizing)や[設定](/docs/app/building-your-application/configuring)などの他のセクションに深く入り込むことができます。最後に、準備が整ったら、[デプロイ](/docs/app/getting-started/deploying)と[アップグレード](/docs/app/guides/upgrading)のセクションを確認してください。
-Next.jsを初めて使用する場合は、[ルーティング](https://nextjs.org/docs/canary/pages/building-your-application/routing)、[レンダリング](https://nextjs.org/docs/canary/pages/building-your-application/rendering)、[データフェッチング](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching)、[スタイリング](https://nextjs.org/docs/canary/pages/building-your-application/styling)のセクションから始めることをお勧めします。これらのセクションは、Next.jsとWebの基本概念を紹介し、スタートを切るのに役立ちます。その後、[最適化](https://nextjs.org/docs/canary/pages/building-your-application/optimizing)や[設定](https://nextjs.org/docs/canary/pages/building-your-application/configuring)などの他のセクションを深く掘り下げることができます。最後に、準備が整ったら、[デプロイ](https://nextjs.org/docs/canary/pages/building-your-application/deploying)と[アップグレード](https://nextjs.org/docs/canary/pages/guides/upgrading)のセクションを確認してください。
+Next.jsを初めて使用する場合は、[ルーティング](https://nextjs.org/docs/canary/pages/building-your-application/routing)、[レンダリング](https://nextjs.org/docs/canary/pages/building-your-application/rendering)、[データフェッチング](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching)、[スタイリング](https://nextjs.org/docs/canary/pages/building-your-application/styling)のセクションから始めることをお勧めします。これらのセクションは、Next.jsとWebの基本概念を紹介し、スタートを切るのに役立ちます。その後、[最適化](https://nextjs.org/docs/canary/pages/building-your-application/optimizing)や[設定](https://nextjs.org/docs/canary/pages/building-your-application/configuring)などの他のセクションに深く入り込むことができます。最後に、準備が整ったら、[デプロイ](https://nextjs.org/docs/canary/pages/getting-started/deploying)と[アップグレード](https://nextjs.org/docs/canary/pages/guides/upgrading)のセクションを確認してください。
diff --git a/docs/01-app/05-api-reference/05-config/01-next-config-js/assetPrefix.mdx b/docs/01-app/05-api-reference/05-config/01-next-config-js/assetPrefix.mdx
index 9b94920f..fed4f816 100644
--- a/docs/01-app/05-api-reference/05-config/01-next-config-js/assetPrefix.mdx
+++ b/docs/01-app/05-api-reference/05-config/01-next-config-js/assetPrefix.mdx
@@ -1,32 +1,32 @@
---
title: 'assetPrefix'
-description: 'CDNを設定するためにassetPrefix設定オプションを使用する方法を学びましょう'
+description: 'CDNを設定するためのassetPrefix設定オプションの使い方を学びましょう。'
---
-{/* このドキュメントの内容はapp routerとpages routerの間で共有されています。Pages Routerに特化したコンテンツを追加するには、`コンテンツ`コンポーネントを使用できます。共有コンテンツはコンポーネントでラップしないでください。 */}
+{/* このドキュメントの内容はapp routerとpages routerの両方で共有されています。Pages Routerに特化した内容を追加するには、`Content`コンポーネントを使用できます。共有される内容はコンポーネントでラップしないでください。 */}
-> **注意**:[Vercelにデプロイする](/docs/app/building-your-application/deploying)と、あなたのNext.jsプロジェクトに自動的にグローバルCDNが設定されます;
-> Asset Prefixを手動で設定する必要はありません。
+> **注意**: [Vercelへのデプロイ](/docs/app/getting-started/deploying)は、Next.jsプロジェクトのためにグローバルCDNを自動的に設定します。
+> 手動でAsset Prefixを設定する必要はありません。
-> **注意**:[Vercelにデプロイする](https://nextjs.org/docs/canary/pages/building-your-application/deploying)と、あなたのNext.jsプロジェクトに自動的にグローバルCDNが設定されます;
-> Asset Prefixを手動で設定する必要はありません。
+> **注意**: [Vercelへのデプロイ](https://nextjs.org/docs/canary/pages/getting-started/deploying)は、Next.jsプロジェクトのためにグローバルCDNを自動的に設定します。
+> 手動でAsset Prefixを設定する必要はありません。
-> **Good to know**:Next.js 9.5+では、カスタマイズ可能な[Base Path](/docs/app/api-reference/config/next-config-js/basePath)のサポートが追加され、`/docs`のようなサブパスでアプリケーションをホスティングするのに適しています;
-> このユースケースでは、カスタムAsset Prefixを使用することをお勧めしません。
+> **Good to know**: Next.js 9.5+では、カスタマイズ可能な[Base Path](/docs/app/api-reference/config/next-config-js/basePath)のサポートが追加されました。これは、`/docs`のようなサブパスでアプリケーションをホスティングするのに適しています。
+> このユースケースでは、カスタムAsset Prefixの使用をお勧めしません。
## CDNの設定 {#set-up-a-cdn}
-[CDN](https://en.wikipedia.org/wiki/Content_delivery_network)を設定するには、asset prefixを設定し、Next.jsがホストされているドメインにCDNのオリジンを解決するように設定します;
+[CDN](https://en.wikipedia.org/wiki/Content_delivery_network)を設定するには、asset prefixを設定し、Next.jsがホストされているドメインに解決するようにCDNのオリジンを設定します。
-`next.config.mjs`を開き、[フェーズ](/docs/app/api-reference/config/next-config-js#async-configuration)に基づいてassetPrefix設定を追加します:
+`next.config.mjs`を開き、[phase](/docs/app/api-reference/config/next-config-js#async-configuration)に基づいて`assetPrefix`設定を追加します:
```js title="next.config.mjs"
// @ts-check
@@ -44,32 +44,32 @@ export default (phase) => {
}
```
-Next.jsは、自動的に`/_next/`パス(`.next/static/`フォルダー)からロードするJavaScriptとCSSファイルに対して、あなたのasset prefixを使用します;例えば、上記の設定を使用すると、JSチャンクのリクエストは次のようになります:
+Next.jsは、`/_next/`パス(`.next/static/`フォルダ)から読み込むJavaScriptおよびCSSファイルに対して自動的にasset prefixを使用します。たとえば、上記の設定では、次のJSチャンクのリクエストが:
```
/_next/static/chunks/4b9b41aaa062cbbfeff4add70f256968c51ece5d.4d708494b3aed70c04f0.js
```
-これは代わりに次のようになります:
+次のようになります:
```
https://cdn.mydomain.com/_next/static/chunks/4b9b41aaa062cbbfeff4add70f256968c51ece5d.4d708494b3aed70c04f0.js
```
-指定したCDNにファイルをアップロードするための具体的な設定は、選択するCDNに依存します;CDNにホストする必要がある唯一のフォルダーは、`.next/static/`の内容であり、上記のURLリクエストが示すように`_next/static/`としてアップロードする必要があります。**`.next/`フォルダーの残りをアップロードしないでください**;あなたのサーバーコードや他の設定を公開するべきではありません。
+特定のCDNにファイルをアップロードするための正確な設定は、選択したCDNによって異なります。CDNにホストする必要がある唯一のフォルダは、`.next/static/`の内容であり、上記のURLリクエストが示すように`_next/static/`としてアップロードする必要があります。**他の`.next/`フォルダをアップロードしないでください**。サーバーコードやその他の設定を公開しないようにするためです。
-`assetPrefix`は、`_next/static`へのリクエストをカバーしますが、次のパスには影響しません:
+`assetPrefix`は`_next/static`へのリクエストをカバーしますが、次のパスには影響しません:
-- [public](/docs/app/building-your-application/optimizing/static-assets)フォルダー内のファイル;これらのアセットをCDN経由で提供したい場合は、自分でプレフィックスを導入する必要があります
+- [public](/docs/app/building-your-application/optimizing/static-assets)フォルダ内のファイル;これらのアセットをCDN経由で提供したい場合は、自分でプレフィックスを導入する必要があります
-- [public](https://nextjs.org/docs/canary/pages/building-your-application/optimizing/static-assets)フォルダー内のファイル;これらのアセットをCDN経由で提供したい場合は、自分でプレフィックスを導入する必要があります
+- [public](https://nextjs.org/docs/canary/pages/building-your-application/optimizing/static-assets)フォルダ内のファイル;これらのアセットをCDN経由で提供したい場合は、自分でプレフィックスを導入する必要があります
- `getServerSideProps`ページの`/_next/data/`リクエスト。これらのリクエストは静的ではないため、常にメインドメインに対して行われます。
-- `getStaticProps`ページの`/_next/data/`リクエスト。これらのリクエストは、[incremental static regeneration](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/incremental-static-regeneration)をサポートするため、使用していない場合でもメインドメインに対して行われます(一貫性のため)。
+- `getStaticProps`ページの`/_next/data/`リクエスト。これらのリクエストは、[Incremental Static Generation](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/incremental-static-regeneration)をサポートするために、使用していなくても一貫性のために常にメインドメインに対して行われます。
diff --git a/docs/01-app/05-api-reference/05-config/01-next-config-js/exportPathMap.mdx b/docs/01-app/05-api-reference/05-config/01-next-config-js/exportPathMap.mdx
index 3468a614..025b9b9a 100644
--- a/docs/01-app/05-api-reference/05-config/01-next-config-js/exportPathMap.mdx
+++ b/docs/01-app/05-api-reference/05-config/01-next-config-js/exportPathMap.mdx
@@ -1,22 +1,22 @@
---
title: 'exportPathMap'
-description: '`next export` を使用する際にHTMLファイルとしてエクスポートされるページをカスタマイズ'
-version: 'レガシー'
+description: '`next export`を使用する際にHTMLファイルとしてエクスポートされるページをカスタマイズします。'
+version: 'legacy'
---
-{/* このドキュメントの内容は、app router と pages router の間で共有されています。Pages Router に特有のコンテンツを追加するには `Content` コンポーネントを使用できます。共有コンテンツはコンポーネントでラップしないでください。 */}
+{/* このドキュメントの内容はapp routerとpages routerの間で共有されています。Pages Routerに特有の内容を追加するには、`Content`コンポーネントを使用できます。共有される内容はコンポーネントでラップしないでください。 */}
-> この機能は `next export` に特有のもので、現在は `pages` での `getStaticPaths` か、`app` での `generateStaticParams` が推奨されており、**非推奨** となっています。
+> この機能は`next export`に特有のもので、現在は`pages`での`getStaticPaths`や`app`での`generateStaticParams`が推奨されています。
-`exportPathMap` は、エクスポート時に使用されるリクエストパスとページのマッピングを指定することができます。`exportPathMap` で定義されたパスは、[`next dev`](/docs/app/api-reference/cli/next#next-dev-options) を使用する際にも使用可能です。
+`exportPathMap`を使用すると、エクスポート時に使用されるリクエストパスとページのマッピングを指定できます。`exportPathMap`で定義されたパスは、[`next dev`](/docs/app/api-reference/cli/next#next-dev-options)を使用する際にも利用可能です。
-以下のページを持つアプリのために、カスタムの `exportPathMap` を作成する例から始めましょう:
+次に、以下のページを持つアプリのカスタム`exportPathMap`を作成する例を示します:
- `pages/index.js`
- `pages/about.js`
- `pages/post.js`
-`next.config.js` を開いて、次のように `exportPathMap` の設定を追加します:
+`next.config.js`を開き、以下の`exportPathMap`設定を追加します:
```js title="next.config.js"
module.exports = {
@@ -35,30 +35,30 @@ module.exports = {
}
```
-> **Good to know**:`exportPathMap` の `query` フィールドは、[自動的に静的に最適化されたページ](https://nextjs.org/docs/canary/pages/building-your-application/rendering/automatic-static-optimization)や [`getStaticProps` ページ](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/get-static-props)とは使用できません;これらはビルド時にHTMLファイルとしてレンダリングされ、追加のクエリ情報は `next export` 中に提供できません。
+> **Good to know**: `exportPathMap`の`query`フィールドは、[自動的に静的最適化されたページ](https://nextjs.org/docs/canary/pages/building-your-application/rendering/automatic-static-optimization)や[`getStaticProps`ページ](https://nextjs.org/docs/canary/pages/building-your-application/data-fetching/get-static-props)では使用できません。これらはビルド時にHTMLファイルとしてレンダリングされ、`next export`中に追加のクエリ情報を提供することはできません。
-その後、ページはHTMLファイルとしてエクスポートされます。たとえば、`/about` は `/about.html` になります。
+その後、ページはHTMLファイルとしてエクスポートされます。例えば、`/about`は`/about.html`になります。
-`exportPathMap` は2つの引数を受け取る `async` 関数です:最初のものは Next.js が使用するデフォルトマップである `defaultPathMap` です。2番目の引数は次のフィールドを持つオブジェクトです:
+`exportPathMap`は2つの引数を受け取る`async`関数です。最初の引数はNext.jsが使用するデフォルトのマップである`defaultPathMap`です。2番目の引数は以下のフィールドを持つオブジェクトです:
-- `dev` - 開発中に `exportPathMap` が呼ばれるときは `true`;`next export` を実行するときは `false`。開発中には `exportPathMap` を使用してルートを定義します。
+- `dev` - `exportPathMap`が開発中に呼び出されている場合は`true`。`next export`を実行している場合は`false`。開発中は`exportPathMap`がルートを定義するために使用されます。
- `dir` - プロジェクトディレクトリへの絶対パス
-- `outDir` - `out/` ディレクトリへの絶対パス([`-o`](#customizing-the-output-directory) で設定可能)。`dev` が `true` の場合、`outDir` の値は `null` です。
-- `distDir` - `.next/` ディレクトリへの絶対パス([`distDir`](https://nextjs.org/docs/canary/pages/api-reference/config/next-config-js/distDir) 設定で設定可能)
+- `outDir` - `out/`ディレクトリへの絶対パス([`-o`](#customizing-the-output-directory)で設定可能)。`dev`が`true`の場合、`outDir`の値は`null`になります。
+- `distDir` - `.next/`ディレクトリへの絶対パス([`distDir`](https://nextjs.org/docs/canary/pages/api-reference/config/next-config-js/distDir)設定で設定可能)
- `buildId` - 生成されたビルドID
-返されるオブジェクトは、ページのマップであり、`key` が `pathname`、`value` が次のフィールドを受け入れるオブジェクトです:
+返されるオブジェクトはページのマップで、`key`が`pathname`で、`value`が以下のフィールドを受け入れるオブジェクトです:
-- `page`: `String` - レンダリングする `pages` ディレクトリ内のページ
-- `query`: `Object` - プリレンダリング時に `getInitialProps` に渡される `query` オブジェクト。デフォルトは `{}`
+- `page`: `String` - レンダリングする`pages`ディレクトリ内のページ
+- `query`: `Object` - プリレンダリング時に`getInitialProps`に渡される`query`オブジェクト。デフォルトは`{}`
-> エクスポートされた `pathname` は、(たとえば `/readme.md` のように)ファイル名でも可能ですが、それが `.html` でない場合、そのコンテンツを提供する際に `Content-Type` ヘッダーを `text/html` に設定する必要があるかもしれません。
+> エクスポートされた`pathname`はファイル名(例えば、`/readme.md`)にすることもできますが、内容を提供する際に`.html`と異なる場合は`Content-Type`ヘッダーを`text/html`に設定する必要があるかもしれません。
-## 末尾のスラッシュを追加する {#adding-a-trailing-slash}
+## トレーリングスラッシュを追加する {#adding-a-trailing-slash}
-Next.js を設定してページを `index.html` ファイルとしてエクスポートし、末尾のスラッシュを必要とするようにすることが可能です。`/about` は `/about/index.html` になり、`/about/` からルーティング可能になります。これは Next.js 9 より以前のデフォルトの動作でした。
+Next.jsを設定してページを`index.html`ファイルとしてエクスポートし、トレーリングスラッシュを必要とするようにすることができます。`/about`は`/about/index.html`となり、`/about/`でルーティング可能です。これはNext.js 9以前のデフォルトの動作でした。
-元に戻して末尾のスラッシュを追加するには、`next.config.js` を開き、`trailingSlash` 設定を有効にします:
+トレーリングスラッシュを追加するには、`next.config.js`を開き、`trailingSlash`設定を有効にします:
```js title="next.config.js"
module.exports = {
@@ -66,22 +66,22 @@ module.exports = {
}
```
-## 出力ディレクトリをカスタマイズする {#customizing-the-output-directory}
+## 出力ディレクトリのカスタマイズ {#customizing-the-output-directory}
-[`next export`](/docs/app/building-your-application/deploying/static-exports) はデフォルトで `out` を出力ディレクトリとして使用しますが、次のように `-o` 引数を使用してカスタマイズできます:
+[`next export`](/docs/app/guides/static-exports)はデフォルトで`out`を出力ディレクトリとして使用しますが、以下のように`-o`引数を使用してカスタマイズできます:
-[`next export`](https://nextjs.org/docs/canary/pages/building-your-application/deploying/static-exports) はデフォルトで `out` を出力ディレクトリとして使用しますが、次のように `-o` 引数を使用してカスタマイズできます:
+[`next export`](https://nextjs.org/docs/canary/pages/guides/static-exports)はデフォルトで`out`を出力ディレクトリとして使用しますが、以下のように`-o`引数を使用してカスタマイズできます:
-```bash title="ターミナル"
+```bash title="Terminal"
next export -o outdir
```
-> **警告**:`exportPathMap` の使用は非推奨であり、`pages` 内の `getStaticPaths` によって上書きされます;これらを一緒に使用することは推奨しません。
+> **Warning**: `exportPathMap`の使用は非推奨であり、`pages`内の`getStaticPaths`によって上書きされます。これらを一緒に使用することはお勧めしません。
diff --git a/docs/01-app/05-api-reference/05-config/01-next-config-js/incrementalCacheHandlerPath.mdx b/docs/01-app/05-api-reference/05-config/01-next-config-js/incrementalCacheHandlerPath.mdx
index c2beb3a7..61bdf4fe 100644
--- a/docs/01-app/05-api-reference/05-config/01-next-config-js/incrementalCacheHandlerPath.mdx
+++ b/docs/01-app/05-api-reference/05-config/01-next-config-js/incrementalCacheHandlerPath.mdx
@@ -1,63 +1,63 @@
---
title: 'カスタム Next.js キャッシュハンドラー'
nav_title: 'cacheHandler'
-description: 'データの保存と再検証に使用する Next.js のキャッシュを、Redis、Memcached、その他の外部サービスに設定できます。'
+description: 'Redis、Memcached、その他の外部サービスを使用してデータを保存および再検証するための Next.js キャッシュを設定します。'
---
-ページのキャッシュと再検証(Incremental Static Regenerationを使用)では、同じ共有キャッシュを使用します。 [Vercel にデプロイすると](https://vercel.com/docs/incremental-static-regeneration?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)、ISR キャッシュは自動的に耐久性のあるストレージに永続化されます。
+ページのキャッシュと再検証(Incremental Static Regeneration を使用)は、同じ共有キャッシュを使用します。[Vercel にデプロイする際](https://vercel.com/docs/incremental-static-regeneration?utm_source=next-site&utm_medium=docs&utm_campaign=next-website)、ISR キャッシュは自動的に耐久性のあるストレージに保存されます。
-自己ホスティングの場合、ISR キャッシュは Next.js サーバー上のファイルシステム(ディスク)に保存されます。これは、PagesとApp Routerの両方を使用して自己ホスティングする場合、自動的に動作します。
+セルフホスティングの場合、ISR キャッシュは Next.js サーバーのファイルシステム(ディスク上)に保存されます。これは、Pages Router と App Router の両方を使用してセルフホスティングする場合に自動的に機能します。
-キャッシュされたページとデータを耐久性のあるストレージに永続化したり、Next.js アプリケーションの複数のコンテナやインスタンス間でキャッシュを共有したりしたい場合は、Next.js のキャッシュの場所を設定できます。
+キャッシュされたページとデータを耐久性のあるストレージに保存したり、Next.js アプリケーションの複数のコンテナやインスタンス間でキャッシュを共有したりする場合は、Next.js キャッシュの場所を設定できます。
```js title="next.config.js"
module.exports = {
cacheHandler: require.resolve('./cache-handler.js'),
- cacheMaxMemorySize: 0, // デフォルトのメモリ内キャッシュを無効にします
+ cacheMaxMemorySize: 0, // デフォルトのメモリ内キャッシュを無効にする
}
```
-[カスタムキャッシュハンドラー](/docs/app/building-your-application/deploying#configuring-caching)の例を確認し、実装について詳しく学んでください。
+[カスタムキャッシュハンドラー](/docs/app/guides/self-hosting#configuring-caching)の例を参照し、実装について詳しく学んでください。
-## APIリファレンス {#api-reference}
+## API リファレンス {#api-reference}
-キャッシュハンドラーは以下のメソッドを実装できます:`get`、`set`、`revalidateTag`
+キャッシュハンドラーは、次のメソッドを実装できます:`get`、`set`、および `revalidateTag`。
### `get()` {#get}
-| パラメーター | 型 | 説明 |
-| ------------ | -------- | -------------------------------- |
-| `key` | `string` | キャッシュされている値のキーです |
+| パラメーター | 型 | 説明 |
+| ------------ | -------- | -------------------------- |
+| `key` | `string` | キャッシュされた値のキー。 |
-キャッシュされた値を返します。見つからなければ `null` を返します。
+キャッシュされた値を返すか、見つからない場合は `null` を返します。
### `set()` {#set}
-| パラメーター | 型 | 説明 |
-| ------------ | ------------------ | ---------------------------- |
-| `key` | `string` | データを保存するキーです |
-| `data` | Data または `null` | キャッシュするデータです |
-| `ctx` | `{ tags: [] }` | 提供されるキャッシュタグです |
+| パラメーター | 型 | 説明 |
+| ------------ | ------------------ | -------------------------- |
+| `key` | `string` | データを保存するキー。 |
+| `data` | Data または `null` | キャッシュするデータ。 |
+| `ctx` | `{ tags: [] }` | 提供されたキャッシュタグ。 |
`Promise` を返します。
### `revalidateTag()` {#revalidatetag}
-| パラメーター | 型 | 説明 |
-| ------------ | ---------------------- | ---------------------------- |
-| `tag` | `string` or `string[]` | 再検証するキャッシュタグです |
+| パラメーター | 型 | 説明 |
+| ------------ | -------------------------- | -------------------------- |
+| `tag` | `string` または `string[]` | 再検証するキャッシュタグ。 |
-`Promise` を返します。データの[再検証について詳しく](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)知るか、[`revalidateTag()`](/docs/app/api-reference/functions/revalidateTag) 関数について理解を深めてください。
+`Promise` を返します。[データの再検証](/docs/app/building-your-application/data-fetching/incremental-static-regeneration)や [`revalidateTag()`](/docs/app/api-reference/functions/revalidateTag) 関数について詳しく学んでください。
**Good to know:**
-- `revalidatePath` はキャッシュタグの上位にある便利なレイヤーです。`revalidatePath` を呼び出すと、`revalidateTag` 関数が呼び出され、そこからパスに基づいてキャッシュキーにタグを付けるかどうか選択できます。
+- `revalidatePath` はキャッシュタグの上にある便利なレイヤーです。`revalidatePath` を呼び出すと、`revalidateTag` 関数が呼び出され、その後、パスに基づいてキャッシュキーにタグを付けるかどうかを選択できます。
## バージョン履歴 {#version-history}
-| バージョン | 変更点 |
-| ---------- | ------------------------------------------------------------------------- |
-| `v14.1.0` | `cacheHandler` に改名され、安定化しました。 |
-| `v13.4.0` | `revalidateTag` 用の `incrementalCacheHandlerPath` をサポートしました。 |
-| `v13.4.0` | スタンドアロン出力用の `incrementalCacheHandlerPath` をサポートしました。 |
-| `v12.2.0` | 実験的な `incrementalCacheHandlerPath` が追加されました。 |
+| バージョン | 変更内容 |
+| ---------- | ------------------------------------------------------------------- |
+| `v14.1.0` | `cacheHandler` に名前が変更され、安定版になりました。 |
+| `v13.4.0` | `revalidateTag` のための `incrementalCacheHandlerPath` サポート。 |
+| `v13.4.0` | スタンドアロン出力のための `incrementalCacheHandlerPath` サポート。 |
+| `v12.2.0` | 実験的な `incrementalCacheHandlerPath` が追加されました。 |
diff --git a/docs/01-app/05-api-reference/05-config/01-next-config-js/reactCompiler.mdx b/docs/01-app/05-api-reference/05-config/01-next-config-js/reactCompiler.mdx
index 2adff7aa..59bbed62 100644
--- a/docs/01-app/05-api-reference/05-config/01-next-config-js/reactCompiler.mdx
+++ b/docs/01-app/05-api-reference/05-config/01-next-config-js/reactCompiler.mdx
@@ -4,9 +4,17 @@ description: 'React Compilerを有効にして、コンポーネントのレン
version: 'experimental'
---
-Next.js 15では、[React Compiler](https://react.dev/learn/react-compiler)のサポートが導入されました。コンパイラはコンポーネントのレンダリングを自動的に最適化することでパフォーマンスを向上させます。これにより、開発者が`useMemo`や`useCallback`などのAPIを通じて手動で行うメモ化の量が減少します。
+Next.jsは、コンポーネントのレンダリングを自動的に最適化することでパフォーマンスを向上させることを目的としたツールである[React Compiler](https://react.dev/learn/react-compiler)をサポートしています。これにより、`useMemo`や`useCallback`を使用した手動のメモ化の必要性が減少します。
-使用するには、Next.js 15にアップグレードし、`babel-plugin-react-compiler`をインストールします:
+Next.jsには、React Compilerをより効率的にするためにSWCで書かれたカスタムのパフォーマンス最適化が含まれています。すべてのファイルに対してコンパイラを実行するのではなく、Next.jsはプロジェクトを分析し、関連するファイルにのみReact Compilerを適用します。これにより、不要な作業を避け、Babelプラグインを単独で使用する場合と比較してビルドが高速化されます。
+
+## 仕組み {#how-it-works}
+
+React CompilerはBabelプラグインを通じて実行されます。ビルドを高速に保つために、Next.jsはカスタムのSWC最適化を使用し、JSXやReactフックを含む関連ファイルにのみReact Compilerを適用します。
+
+これにより、すべてをコンパイルすることを避け、パフォーマンスコストを最小限に抑えます。デフォルトのRustベースのコンパイラと比較して、ビルドがわずかに遅くなることがありますが、その影響は小さく局所的です。
+
+使用するには、`babel-plugin-react-compiler`をインストールします:
```bash title="Terminal"
npm install babel-plugin-react-compiler
@@ -46,8 +54,6 @@ module.exports = nextConfig
-> **Note:** React Compilerは現在、Next.jsでBabelプラグインを通じてのみ使用可能です。これにより、Next.jsのデフォルトの[Rustベースのコンパイラ](/docs/architecture/nextjs-compiler)が無効になり、ビルド時間が遅くなる可能性があります。React Compilerをデフォルトのコンパイラとしてサポートするために取り組んでいます。
-
## アノテーション {#annotations}
コンパイラを「オプトイン」モードで実行するように設定できます:
diff --git a/docs/01-app/05-api-reference/05-config/01-next-config-js/trailingSlash.mdx b/docs/01-app/05-api-reference/05-config/01-next-config-js/trailingSlash.mdx
index c6939f52..fea600f5 100644
--- a/docs/01-app/05-api-reference/05-config/01-next-config-js/trailingSlash.mdx
+++ b/docs/01-app/05-api-reference/05-config/01-next-config-js/trailingSlash.mdx
@@ -5,7 +5,7 @@ description: 'Next.jsのページを末尾のスラッシュありまたはな
{/* このドキュメントの内容は、app routerとpages routerの間で共有されています。Pages Routerに特有の内容を追加するには、`Content`コンポーネントを使用できます。共有される内容はコンポーネントでラップしないでください。 */}
-デフォルトでは、Next.jsは末尾にスラッシュが付いたURLを、スラッシュが付いていない対応するURLにリダイレクトします。たとえば、`/about/`は`/about`にリダイレクトされます。この動作を逆に設定し、末尾にスラッシュがないURLを、スラッシュが付いた対応するURLにリダイレクトするように設定できます。
+デフォルトでは、Next.jsは末尾にスラッシュが付いたURLを、スラッシュなしの対応するURLにリダイレクトします。たとえば、`/about/`は`/about`にリダイレクトされます。この動作を逆に設定し、末尾にスラッシュがないURLを、スラッシュ付きの対応するURLにリダイレクトするように構成できます。
`next.config.js`を開き、`trailingSlash`の設定を追加します:
@@ -19,12 +19,12 @@ module.exports = {
`trailingSlash: true`を使用する場合、特定のURLは例外となり、末尾にスラッシュが追加されません:
-- 拡張子が付いた静的ファイルのURL
-- `.well-known/`以下のパス
+- 拡張子を持つ静的ファイルのURL
+- `.well-known/`以下のすべてのパス
-たとえば、次のURLは変更されません:`/file.txt`、`images/photos/picture.png`、および`.well-known/subfolder/config.json`
+たとえば、次のURLは変更されません:`/file.txt`、`images/photos/picture.png`、および`.well-known/subfolder/config.json`。
-[`output: "export"`](/docs/app/building-your-application/deploying/static-exports)設定と一緒に使用すると、`/about`ページは`/about/index.html`を出力します(デフォルトの`/about.html`ではなく)。
+[`output: "export"`](/docs/app/guides/static-exports)設定と一緒に使用すると、`/about`ページはデフォルトの`/about.html`ではなく、`/about/index.html`として出力されます。
## バージョン履歴 {#version-history}
diff --git a/kj-diff.json b/kj-diff.json
index bb72e58f..eb229129 100644
--- a/kj-diff.json
+++ b/kj-diff.json
@@ -1,63 +1,29 @@
{
"submodule": "next.js",
"hash": {
- "previous": "581975d7cfa5c9aa8a008df3306d8779a175bfc7",
- "current": "126c22678f9d0736044eb527b2ebc2e6c01d532b"
+ "previous": "126c22678f9d0736044eb527b2ebc2e6c01d532b",
+ "current": "a556825dd7347fc5ecff20e2d8e94118cb668099"
},
"diffs": [
- "A\tdocs/01-app/01-getting-started/11-deploying.mdx",
- "M\tdocs/01-app/01-getting-started/12-upgrading.mdx",
- "A\tdocs/01-app/02-guides/migrating/app-router-migration.mdx",
- "A\tdocs/01-app/02-guides/migrating/from-create-react-app.mdx",
- "A\tdocs/01-app/02-guides/migrating/from-vite.mdx",
- "A\tdocs/01-app/02-guides/migrating/index.mdx",
- "A\tdocs/01-app/02-guides/multi-tenant.mdx",
- "A\tdocs/01-app/02-guides/multi-zones.mdx",
- "A\tdocs/01-app/02-guides/production-checklist.mdx",
- "A\tdocs/01-app/02-guides/single-page-applications.mdx",
- "A\tdocs/01-app/02-guides/upgrading/codemods.mdx",
- "A\tdocs/01-app/02-guides/upgrading/index.mdx",
- "A\tdocs/01-app/02-guides/upgrading/version-14.mdx",
- "A\tdocs/01-app/02-guides/upgrading/version-15.mdx",
- "M\tdocs/01-app/03-building-your-application/01-routing/03-layouts-and-templates.mdx",
- "M\tdocs/01-app/03-building-your-application/01-routing/10-dynamic-routes.mdx",
- "M\tdocs/01-app/03-building-your-application/01-routing/13-route-handlers.mdx",
- "M\tdocs/01-app/03-building-your-application/06-optimizing/03-fonts.mdx",
- "M\tdocs/01-app/03-building-your-application/06-optimizing/04-metadata.mdx",
- "M\tdocs/01-app/03-building-your-application/06-optimizing/06-package-bundling.mdx",
- "M\tdocs/01-app/03-building-your-application/06-optimizing/14-local-development.mdx",
- "M\tdocs/01-app/03-building-your-application/07-configuring/03-environment-variables.mdx",
- "M\tdocs/01-app/03-building-your-application/08-testing/02-jest.mdx",
- "D\tdocs/01-app/03-building-your-application/10-deploying/01-production-checklist.mdx",
- "D\tdocs/01-app/03-building-your-application/10-deploying/03-multi-zones.mdx",
- "M\tdocs/01-app/03-building-your-application/10-deploying/index.mdx",
- "D\tdocs/01-app/03-building-your-application/11-upgrading/01-codemods.mdx",
- "D\tdocs/01-app/03-building-your-application/11-upgrading/02-canary.mdx",
- "D\tdocs/01-app/03-building-your-application/11-upgrading/03-version-15.mdx",
- "D\tdocs/01-app/03-building-your-application/11-upgrading/04-version-14.mdx",
- "D\tdocs/01-app/03-building-your-application/11-upgrading/05-app-router-migration.mdx",
- "D\tdocs/01-app/03-building-your-application/11-upgrading/06-from-create-react-app.mdx",
- "D\tdocs/01-app/03-building-your-application/11-upgrading/07-from-vite.mdx",
- "D\tdocs/01-app/03-building-your-application/11-upgrading/08-single-page-applications.mdx",
- "D\tdocs/01-app/03-building-your-application/11-upgrading/index.mdx",
+ "M\tdocs/01-app/01-getting-started/11-deploying.mdx",
+ "A\tdocs/01-app/02-guides/authentication.mdx",
+ "A\tdocs/01-app/02-guides/ci-build-caching.mdx",
+ "M\tdocs/01-app/02-guides/index.mdx",
+ "A\tdocs/01-app/02-guides/self-hosting.mdx",
+ "M\tdocs/01-app/02-guides/single-page-applications.mdx",
+ "A\tdocs/01-app/02-guides/static-exports.mdx",
+ "M\tdocs/01-app/02-guides/upgrading/version-14.mdx",
+ "M\tdocs/01-app/03-building-your-application/02-data-fetching/04-incremental-static-regeneration.mdx",
+ "M\tdocs/01-app/03-building-your-application/07-configuring/16-debugging.mdx",
+ "M\tdocs/01-app/03-building-your-application/07-configuring/16-progressive-web-apps.mdx",
+ "D\tdocs/01-app/03-building-your-application/09-authentication/index.mdx",
+ "D\tdocs/01-app/03-building-your-application/10-deploying/02-static-exports.mdx",
+ "D\tdocs/01-app/03-building-your-application/10-deploying/index.mdx",
"M\tdocs/01-app/03-building-your-application/index.mdx",
- "M\tdocs/01-app/05-api-reference/02-components/image.mdx",
- "M\tdocs/01-app/05-api-reference/02-components/link.mdx",
- "M\tdocs/01-app/05-api-reference/03-file-conventions/layout.mdx",
- "M\tdocs/01-app/05-api-reference/03-file-conventions/page.mdx",
- "M\tdocs/01-app/05-api-reference/03-file-conventions/route-segment-config.mdx",
- "M\tdocs/01-app/05-api-reference/03-file-conventions/route.mdx",
- "M\tdocs/01-app/05-api-reference/04-functions/cookies.mdx",
- "M\tdocs/01-app/05-api-reference/04-functions/draft-mode.mdx",
- "M\tdocs/01-app/05-api-reference/04-functions/generate-viewport.mdx",
- "M\tdocs/01-app/05-api-reference/04-functions/headers.mdx",
- "M\tdocs/01-app/05-api-reference/04-functions/use-router.mdx",
- "M\tdocs/01-app/05-api-reference/04-functions/userAgent.mdx",
- "M\tdocs/01-app/05-api-reference/05-config/01-next-config-js/appDir.mdx",
- "M\tdocs/01-app/05-api-reference/05-config/01-next-config-js/rewrites.mdx",
- "M\tdocs/01-app/05-api-reference/05-config/01-next-config-js/turbopack.mdx",
- "M\tdocs/01-app/05-api-reference/08-turbopack.mdx",
- "M\tdocs/01-app/index.mdx",
- "M\tdocs/03-architecture/fast-refresh.mdx"
+ "M\tdocs/01-app/05-api-reference/05-config/01-next-config-js/assetPrefix.mdx",
+ "M\tdocs/01-app/05-api-reference/05-config/01-next-config-js/exportPathMap.mdx",
+ "M\tdocs/01-app/05-api-reference/05-config/01-next-config-js/incrementalCacheHandlerPath.mdx",
+ "M\tdocs/01-app/05-api-reference/05-config/01-next-config-js/reactCompiler.mdx",
+ "M\tdocs/01-app/05-api-reference/05-config/01-next-config-js/trailingSlash.mdx"
]
}
diff --git a/next.js b/next.js
index 126c2267..a556825d 160000
--- a/next.js
+++ b/next.js
@@ -1 +1 @@
-Subproject commit 126c22678f9d0736044eb527b2ebc2e6c01d532b
+Subproject commit a556825dd7347fc5ecff20e2d8e94118cb668099