diff --git a/apps/docs/content/ja/docs/01-app/01-getting-started/10-updating-data.mdx b/apps/docs/content/ja/docs/01-app/01-getting-started/10-updating-data.mdx index d73d4b97..a8da7a4a 100644 --- a/apps/docs/content/ja/docs/01-app/01-getting-started/10-updating-data.mdx +++ b/apps/docs/content/ja/docs/01-app/01-getting-started/10-updating-data.mdx @@ -1,12 +1,12 @@ --- -source-updated-at: 2025-06-01T01:32:20.000Z -translation-updated-at: 2025-06-02T20:01:14.188Z -title: データの更新方法 +source-updated-at: 2025-06-03T15:30:49.000Z +translation-updated-at: 2025-06-06T16:36:21.895Z +title: データ更新方法 nav_title: データ更新 -description: Next.jsアプリケーションでデータを更新する方法について学びましょう。 +description: Next.jsアプリケーションでデータを更新する方法について学びます。 related: title: APIリファレンス - description: このページで紹介されている機能について詳しく知るには、APIリファレンスをお読みください。 + description: このページで言及されている機能について詳しく知るにはAPIリファレンスを参照してください。 links: - app/api-reference/functions/revalidatePath - app/api-reference/functions/revalidateTag @@ -15,11 +15,11 @@ related: Next.jsではReactの[サーバー関数 (Server Functions)](https://react.dev/reference/rsc/server-functions)を使用してデータを更新できます。このページでは[サーバー関数の作成](#creating-server-functions)と[呼び出し](#invoking-server-functions)方法について説明します。 -## サーバー関数 +## サーバー関数 (Server Functions) -サーバー関数とは、サーバー上で実行される非同期関数です。サーバー関数はクライアントからネットワークリクエスト経由で呼び出されるため、本質的に非同期です。`action`の一部として呼び出される場合、**サーバーアクション (Server Actions)** とも呼ばれます。 +サーバー関数はサーバー上で実行される非同期関数です。クライアントからネットワークリクエスト経由で呼び出されるため、サーバー関数は本質的に非同期です。`action`の一部として呼び出される場合、**サーバーアクション (Server Actions)** とも呼ばれます。 -慣例として、`action`は`startTransition`に渡される非同期関数です。サーバー関数は以下の場合に自動的に`startTransition`でラップされます： +慣例として、`action`は`startTransition`に渡される非同期関数です。サーバー関数は以下の場合に自動的に`startTransition`でラップされます: - `
`の`action`プロパティに渡された場合 - ` ) } @@ -279,7 +279,7 @@ export function Button() { ```jsx filename="app/ui/button.js" switcher 'use client' -import { useActionState } from 'react' +import { useActionState, startTransition } from 'react' import { createPost } from '@/app/actions' import { LoadingSpinner } from '@/app/ui/loading-spinner' @@ -287,8 +287,8 @@ export function Button() { const [state, action, pending] = useActionState(createPost, false) return ( - ) } @@ -296,14 +296,14 @@ export function Button() { ### キャッシュの再検証 -更新を実行した後、サーバー関数内で[`revalidatePath`](/docs/app/api-reference/functions/revalidatePath)または[`revalidateTag`](/docs/app/api-reference/functions/revalidateTag)を呼び出すことでNext.jsのキャッシュを再検証し、更新されたデータを表示できます： +更新を実行した後、サーバー関数内で[`revalidatePath`](/docs/app/api-reference/functions/revalidatePath)または[`revalidateTag`](/docs/app/api-reference/functions/revalidateTag)を呼び出すことでNext.jsのキャッシュを再検証し、更新されたデータを表示できます: ```ts filename="app/lib/actions.ts" switcher import { revalidatePath } from 'next/cache' export async function createPost(formData: FormData) { 'use server' - // データを更新 + // データ更新 // ... revalidatePath('/posts') @@ -315,7 +315,7 @@ import { revalidatePath } from 'next/cache' export async function createPost(formData) { 'use server' - // データを更新 + // データ更新 // ... revalidatePath('/posts') } @@ -323,7 +323,7 @@ export async function createPost(formData) { ### リダイレクト -更新後にユーザーを別のページにリダイレクトしたい場合があります。サーバー関数内で[`redirect`](/docs/app/api-reference/functions/redirect)を呼び出すことでこれを行えます： +更新後にユーザーを別のページにリダイレクトしたい場合があります。サーバー関数内で[`redirect`](/docs/app/api-reference/functions/redirect)を呼び出すことで実現できます: ```ts filename="app/lib/actions.ts" switcher 'use server' @@ -331,7 +331,7 @@ export async function createPost(formData) { import { redirect } from 'next/navigation' export async function createPost(formData: FormData) { - // データを更新 + // データ更新 // ... redirect('/posts') @@ -344,7 +344,7 @@ export async function createPost(formData: FormData) { import { redirect } from 'next/navigation' export async function createPost(formData) { - // データを更新 + // データ更新 // ... redirect('/posts') diff --git a/apps/docs/content/ja/docs/01-app/01-getting-started/14-deploying.mdx b/apps/docs/content/ja/docs/01-app/01-getting-started/14-deploying.mdx index b34ebdcb..ca0c8266 100644 --- a/apps/docs/content/ja/docs/01-app/01-getting-started/14-deploying.mdx +++ b/apps/docs/content/ja/docs/01-app/01-getting-started/14-deploying.mdx @@ -1,23 +1,23 @@ --- -source-updated-at: 2025-06-01T01:32:20.000Z -translation-updated-at: 2025-06-02T20:00:00.349Z -title: Next.jsアプリケーションのデプロイ方法 +source-updated-at: 2025-06-05T23:52:35.000Z +translation-updated-at: 2025-06-06T16:35:25.702Z +title: Next.js アプリケーションのデプロイ方法 nav_title: デプロイ -description: Next.jsアプリケーションをデプロイする方法について学びましょう。 +description: Next.js アプリケーションをデプロイする方法を学びます。 --- -Next.jsアプリケーションは、Node.jsサーバー、Dockerコンテナ、静的エクスポートとしてデプロイしたり、さまざまなプラットフォームで実行できるように適応させたりできます。 +Next.js アプリケーションは、Node.js サーバー、Docker コンテナ、静的エクスポート、またはさまざまなプラットフォームで実行するように適応させてデプロイできます。 -| デプロイオプション | 機能サポート | -| ------------------------------- | ------------------ | -| [Node.jsサーバー](#nodejs-server) | すべて | -| [Dockerコンテナ](#docker) | すべて | -| [静的エクスポート](#static-export) | 制限あり | -| [アダプター](#adapters) | プラットフォーム依存 | +| デプロイ方法 | サポート機能 | +| -------------------------------- | ----------------- | +| [Node.js サーバー](#nodejs-server) | すべて | +| [Docker コンテナ](#docker) | すべて | +| [静的エクスポート](#static-export) | 制限あり | +| [アダプター](#adapters) | プラットフォーム依存 | -## Node.jsサーバー +## Node.js サーバー -Next.jsはNode.jsをサポートする任意のプロバイダーにデプロイできます。`package.json`に`"build"`と`"start"`スクリプトがあることを確認してください： +Next.js は Node.js をサポートする任意のプロバイダーにデプロイできます。`package.json` に `"build"` と `"start"` スクリプトが含まれていることを確認してください: ```json filename="package.json" { @@ -29,9 +29,9 @@ Next.jsはNode.jsをサポートする任意のプロバイダーにデプロイ } ``` -その後、`npm run build`を実行してアプリケーションをビルドし、`npm run start`を実行してNode.jsサーバーを起動します。このサーバーはすべてのNext.js機能をサポートしています。必要に応じて、[カスタムサーバー](/docs/app/guides/custom-server)に移行することもできます。 +その後、`npm run build` を実行してアプリケーションをビルドし、`npm run start` を実行して Node.js サーバーを起動します。このサーバーはすべての Next.js 機能をサポートします。必要に応じて、[カスタムサーバー](/docs/app/guides/custom-server) に移行することも可能です。 -Node.jsデプロイはすべてのNext.js機能をサポートします。インフラストラクチャ向けに[設定する方法](/docs/app/guides/self-hosting)を学びましょう。 +Node.js デプロイではすべての Next.js 機能がサポートされます。インフラストラクチャ向けの [設定方法](/docs/app/guides/self-hosting) を学んでください。 ### テンプレート @@ -41,9 +41,11 @@ Node.jsデプロイはすべてのNext.js機能をサポートします。イン ## Docker -Next.jsは[Docker](https://www.docker.com/)コンテナをサポートする任意のプロバイダーにデプロイできます。これにはKubernetesなどのコンテナオーケストレーターや、Dockerを実行するクラウドプロバイダーが含まれます。 +Next.js は [Docker](https://www.docker.com/) コンテナをサポートする任意のプロバイダーにデプロイできます。これには Kubernetes のようなコンテナオーケストレーターや、Docker を実行するクラウドプロバイダーが含まれます。 -DockerデプロイはすべてのNext.js機能をサポートします。インフラストラクチャ向けに[設定する方法](/docs/app/guides/self-hosting)を学びましょう。 +Docker デプロイではすべての Next.js 機能がサポートされます。インフラストラクチャ向けの [設定方法](/docs/app/guides/self-hosting) を学んでください。 + +> **開発に関する注意:** Docker は本番デプロイに最適ですが、Mac や Windows での開発時にはパフォーマンス向上のため、Docker ではなくローカル開発 (`npm run dev`) の使用を検討してください。[ローカル開発の最適化について詳しく学ぶ](/docs/app/guides/local-development)。 ### テンプレート @@ -57,11 +59,11 @@ DockerデプロイはすべてのNext.js機能をサポートします。イン ## 静的エクスポート -Next.jsは静的サイトまたは[シングルページアプリケーション（SPA）](/docs/app/guides/single-page-applications)として開始し、後でサーバーを必要とする機能を使用するようにアップグレードすることができます。 +Next.js は静的サイトまたは [シングルページアプリケーション (SPA)](/docs/app/guides/single-page-applications) として開始し、後でサーバーを必要とする機能を使用するようにアップグレードすることが可能です。 -Next.jsは[静的エクスポート](/docs/app/guides/static-exports)をサポートしているため、HTML/CSS/JS静的アセットを提供できる任意のWebサーバーにデプロイしてホストできます。これにはAWS S3、Nginx、Apacheなどのツールが含まれます。 +Next.js は [静的エクスポート](/docs/app/guides/static-exports) をサポートしているため、HTML/CSS/JS 静的アセットを提供できる任意のウェブサーバーにデプロイしてホストできます。これには AWS S3、Nginx、Apache などのツールが含まれます。 -[静的エクスポート](/docs/app/guides/static-exports)として実行すると、サーバーを必要とするNext.js機能は**サポートされません**。[詳細はこちら](/docs/app/guides/static-exports#unsupported-features)をご覧ください。 +[静的エクスポート](/docs/app/guides/static-exports) として実行する場合、サーバーを必要とする Next.js 機能は **サポートされません**。[詳細を確認する](/docs/app/guides/static-exports#unsupported-features)。 ### テンプレート @@ -69,9 +71,9 @@ Next.jsは[静的エクスポート](/docs/app/guides/static-exports)をサポ ## アダプター -Next.jsはさまざまなプラットフォームで実行できるように適応させ、それらのインフラストラクチャ機能をサポートできます。 +Next.js はさまざまなプラットフォームで実行できるように適応させ、それらのインフラストラクチャ機能をサポートできます。 -サポートされているNext.js機能については、各プロバイダーのドキュメントを参照してください： +サポートされている Next.js 機能については、各プロバイダーのドキュメントを参照してください: - [AWS Amplify Hosting](https://docs.amplify.aws/nextjs/start/quickstart/nextjs-app-router-client-components) - [Cloudflare](https://developers.cloudflare.com/workers/frameworks/framework-guides/nextjs) @@ -79,4 +81,4 @@ Next.jsはさまざまなプラットフォームで実行できるように適 - [Netlify](https://docs.netlify.com/frameworks/next-js/overview/#next-js-support-on-netlify) - [Vercel](https://vercel.com/docs/frameworks/nextjs) -> **注記:** すべてのプラットフォームが採用できる[デプロイメントアダプターAPI](https://github.com/vercel/next.js/discussions/77740)を開発中です。完了後、独自のアダプターを作成する方法に関するドキュメントを追加します。 \ No newline at end of file +> **注意:** すべてのプラットフォームが採用できる [デプロイメントアダプター API](https://github.com/vercel/next.js/discussions/77740) を開発中です。完了後、独自のアダプターを作成する方法に関するドキュメントを追加する予定です。 \ No newline at end of file diff --git a/apps/docs/content/ja/docs/01-app/02-guides/local-development.mdx b/apps/docs/content/ja/docs/01-app/02-guides/local-development.mdx index e539acfc..fa4807b3 100644 --- a/apps/docs/content/ja/docs/01-app/02-guides/local-development.mdx +++ b/apps/docs/content/ja/docs/01-app/02-guides/local-development.mdx @@ -1,28 +1,28 @@ --- -source-updated-at: 2025-05-19T22:31:51.000Z -translation-updated-at: 2025-06-02T19:59:08.481Z +source-updated-at: 2025-06-05T23:52:35.000Z +translation-updated-at: 2025-06-06T16:35:50.318Z title: ローカル開発環境を最適化する方法 nav_title: 開発環境 -description: Next.js を使用してローカル開発環境を最適化する方法について学びましょう。 +description: Next.js を使用してローカル開発環境を最適化する方法を学びます。 --- -Next.js は優れた開発者体験を提供するように設計されています。アプリケーションが成長するにつれて、ローカル開発中のコンパイル時間が遅くなることに気付くかもしれません。このガイドでは、コンパイル時のパフォーマンスに関する一般的な問題を特定し、修正する方法を説明します。 +Next.js は優れた開発者体験を提供するように設計されています。アプリケーションが成長するにつれて、ローカル開発中のコンパイル時間が遅くなることに気付くかもしれません。このガイドでは、コンパイル時のパフォーマンス問題を特定して修正する方法を説明します。 -## ローカル開発と本番環境の違い +## ローカル開発環境と本番環境の違い `next dev` を使用した開発プロセスは、`next build` や `next start` とは異なります。 -`next dev` は、アプリケーション内のルートを開いたりナビゲートしたりする際にコンパイルします。これにより、アプリケーション内のすべてのルートがコンパイルされるのを待たずに開発サーバーを起動できるため、より高速でメモリ使用量も少なくなります。本番ビルドを実行すると、ファイルのミニファイやコンテンツハッシュの作成など、ローカル開発では不要な最適化が適用されます。 +`next dev` は、アプリケーション内のルートを開いたりナビゲートしたりする際にコンパイルします。これにより、アプリケーション内のすべてのルートがコンパイルされるのを待たずに開発サーバーを起動でき、より高速でメモリ使用量も少なくなります。本番ビルドを実行すると、ファイルの最小化やコンテンツハッシュの作成など、ローカル開発では不要な最適化が適用されます。 ## ローカル開発のパフォーマンス向上 -### 1. コンピューターのアンチウイルスを確認する +### 1. コンピュータのアンチウイルスを確認 アンチウイルスソフトウェアがファイルアクセスを遅くしている可能性があります。 プロジェクトフォルダをアンチウイルスの除外リストに追加してみてください。Windows マシンでより一般的ですが、アンチウイルスツールがインストールされているシステムではすべて推奨します。 -### 2. Next.js を更新し、Turbopack を有効にする +### 2. Next.js を更新して Turbopack を有効化 最新バージョンの Next.js を使用していることを確認してください。新しいバージョンにはパフォーマンス改善が含まれていることがよくあります。 @@ -33,45 +33,45 @@ npm install next@latest npm run dev --turbopack ``` -[Turbopack の詳細についてはこちら](/blog/turbopack-for-development-stable)。[アップグレードガイド](/docs/app/guides/upgrading) や codemods も参照してください。 +[Turbopack の詳細](/blog/turbopack-for-development-stable) や [アップグレードガイド](/docs/app/guides/upgrading)、コードモッドについてはこちらをご覧ください。 -### 3. インポートを確認する +### 3. インポートを確認 -コードのインポート方法は、コンパイルやバンドリング時間に大きく影響します。[パッケージバンドリングの最適化](/docs/app/guides/package-bundling) について学び、[Dependency Cruiser](https://github.com/sverweij/dependency-cruiser) や [Madge](https://github.com/pahen/madge) などのツールを試してみてください。 +コードのインポート方法はコンパイルやバンドル時間に大きく影響します。[パッケージバンドリングの最適化](/docs/app/guides/package-bundling) や [Dependency Cruiser](https://github.com/sverweij/dependency-cruiser)、[Madge](https://github.com/pahen/madge) などのツールについて学びましょう。 ### アイコンライブラリ -`@material-ui/icons` や `react-icons` などのライブラリは、使用しているアイコンが少数であっても数千のアイコンをインポートする可能性があります。必要なアイコンのみをインポートするようにしてください： +`@material-ui/icons` や `react-icons` などのライブラリは、使用するアイコンが少数でも数千のアイコンをインポートする可能性があります。必要なアイコンのみをインポートするようにしてください: ```jsx -// このようにする代わりに： +// このようにする代わりに: import { Icon1, Icon2 } from 'react-icons/md' -// このようにします： +// このようにします: import Icon1 from 'react-icons/md/Icon1' import Icon2 from 'react-icons/md/Icon2' ``` -`react-icons` のようなライブラリには多くの異なるアイコンセットが含まれています。1つのセットを選択し、そのセットに統一してください。 +`react-icons` のようなライブラリには多くの異なるアイコンセットが含まれています。1つのセットを選択し、そのセットに固執してください。 -例えば、アプリケーションが `react-icons` を使用していて、以下のすべてをインポートしている場合： +例えば、アプリケーションが `react-icons` を使用していて、以下のすべてをインポートしている場合: - `pi` (Phosphor Icons) - `md` (Material Design Icons) - `tb` (tabler-icons) - `cg` (cssgg) -これらを組み合わせると、各セットから1つだけインポートしている場合でも、コンパイラーが処理しなければならないモジュールは数万になります。 +これらを組み合わせると、各セットから1つのインポートしか使用していなくても、コンパイラが処理しなければならないモジュールは数万になります。 ### バレルファイル -「バレルファイル」とは、他のファイルから多くの項目をエクスポートするファイルのことです。コンパイラーがモジュールスコープの副作用を見つけるために解析しなければならないため、ビルドが遅くなる可能性があります。 +「バレルファイル」とは、他のファイルから多くの項目をエクスポートするファイルです。コンパイラがモジュールスコープの副作用を見つけるために解析する必要があるため、ビルドが遅くなる可能性があります。 -可能な場合は、特定のファイルから直接インポートするようにしてください。[バレルファイルの詳細](https://vercel.com/blog/how-we-optimized-package-imports-in-next-js) と Next.js の組み込み最適化について学びましょう。 +可能な場合は特定のファイルから直接インポートしてください。[バレルファイルの詳細](https://vercel.com/blog/how-we-optimized-package-imports-in-next-js) と Next.js の組み込み最適化について学びましょう。 ### パッケージインポートの最適化 -Next.js は特定のパッケージのインポートを自動的に最適化できます。バレルファイルを使用するパッケージを使用している場合は、`next.config.js` に追加してください： +Next.js は特定のパッケージのインポートを自動的に最適化できます。バレルファイルを利用するパッケージを使用している場合は、`next.config.js` に追加してください: ```jsx module.exports = { @@ -83,15 +83,15 @@ module.exports = { Turbopack はインポートを自動的に分析して最適化します。この設定は必要ありません。 -### 4. Tailwind CSS の設定を確認する +### 4. Tailwind CSS の設定を確認 -Tailwind CSS を使用している場合は、正しく設定されていることを確認してください。 +Tailwind CSS を使用している場合、正しく設定されていることを確認してください。 -よくある間違いは、`content` 配列を設定する際に、スキャンすべきでない `node_modules` や他の大きなディレクトリを含めてしまうことです。 +よくある間違いは、スキャンすべきでない `node_modules` や他の大きなファイルディレクトリを含む方法で `content` 配列を設定することです。 Tailwind CSS バージョン 3.4.8 以降では、ビルドを遅くする可能性のある設定について警告が表示されます。 -1. `tailwind.config.js` で、スキャンするファイルを具体的に指定します： +1. `tailwind.config.js` でスキャンするファイルを具体的に指定します: ```jsx module.exports = { @@ -104,7 +104,7 @@ Tailwind CSS バージョン 3.4.8 以降では、ビルドを遅くする可能 } ``` -2. 不要なファイルをスキャンしないようにします： +2. 不要なファイルのスキャンを避けます: ```jsx module.exports = { @@ -115,31 +115,45 @@ Tailwind CSS バージョン 3.4.8 以降では、ビルドを遅くする可能 } ``` -### 5. カスタム webpack 設定を確認する +### 5. カスタム webpack 設定を確認 -カスタム webpack 設定を追加している場合、コンパイルが遅くなっている可能性があります。 +カスタム webpack 設定を追加している場合、コンパイルを遅くしている可能性があります。 -ローカル開発に本当に必要かどうかを検討してください。特定のツールを本番ビルドのみに含めるか、Turbopack に移行して [ローダー](/docs/app/api-reference/config/next-config-js/turbopack#supported-loaders) を使用することを検討してください。 +ローカル開発に本当に必要かどうかを検討してください。本番ビルドにのみ特定のツールを含めるか、Turbopack に移行して [ローダー](/docs/app/api-reference/config/next-config-js/turbopack#supported-loaders) を使用することを検討してください。 -### 6. メモリ使用量を最適化する +### 6. メモリ使用量の最適化 -アプリケーションが非常に大きい場合、より多くのメモリが必要になることがあります。 +アプリケーションが非常に大きい場合、より多くのメモリが必要になる可能性があります。 [メモリ使用量の最適化について詳しく学ぶ](/docs/app/guides/memory-usage)。 ### 7. サーバーコンポーネントとデータフェッチ -サーバーコンポーネントへの変更は、新しい変更を表示するためにローカルでページ全体を再レンダリングする原因となり、コンポーネントの新しいデータをフェッチする必要があります。 +サーバーコンポーネントへの変更は、新しい変更を表示するためにローカルではページ全体を再レンダリングさせます。これにはコンポーネントの新しいデータのフェッチも含まれます。 -実験的な `serverComponentsHmrCache` オプションを使用すると、ローカル開発中の Hot Module Replacement (HMR) 更新にわたってサーバーコンポーネントの `fetch` レスポンスをキャッシュできます。これにより、レスポンスが高速化され、課金対象の API 呼び出しのコストが削減されます。 +実験的な `serverComponentsHmrCache` オプションを使用すると、ローカル開発中の Hot Module Replacement (HMR) 更新を跨いでサーバーコンポーネントの `fetch` レスポンスをキャッシュできます。これにより、より高速なレスポンスと課金対象の API 呼び出しのコスト削減が実現します。 -[実験的なオプションについて詳しく学ぶ](/docs/app/api-reference/config/next-config-js/serverComponentsHmrCache)。 +[実験的オプションについて詳しく学ぶ](/docs/app/api-reference/config/next-config-js/serverComponentsHmrCache)。 + +### 8. Docker よりもローカル開発を検討 + +Mac または Windows で Docker を使用して開発している場合、Next.js をローカルで実行するよりも大幅にパフォーマンスが低下する可能性があります。 + +Mac と Windows での Docker のファイルシステムアクセスにより、Hot Module Replacement (HMR) に数秒から数分かかる場合がありますが、同じアプリケーションをローカルで開発すると高速な HMR で実行されます。 + +このパフォーマンスの違いは、Docker が Linux 環境以外でファイルシステム操作を処理する方法によるものです。最適な開発体験を得るには: + +- 開発中は Docker ではなくローカル開発 (`npm run dev` または `pnpm dev`) を使用する +- Docker は本番デプロイと本番ビルドのテストに限定する +- 開発に Docker を使用する必要がある場合は、Linux マシンまたは VM 上で Docker を使用することを検討する + +本番使用のための [Docker デプロイについて詳しく学ぶ](/docs/app/getting-started/deploying#docker)。 ## 問題を見つけるためのツール ### 詳細なフェッチログ -`next.config.js` ファイルで `logging.fetches` オプションを使用すると、開発中に何が起こっているかについての詳細な情報を見ることができます： +`next.config.js` ファイルの `logging.fetches` オプションを使用して、開発中に何が起こっているかについての詳細な情報を確認できます: ```js module.exports = { @@ -151,37 +165,37 @@ module.exports = { } ``` -[フェッチログの詳細について学ぶ](/docs/app/api-reference/config/next-config-js/logging)。 +[フェッチログについて詳しく学ぶ](/docs/app/api-reference/config/next-config-js/logging)。 ## Turbopack トレーシング -Turbopack トレーシングは、ローカル開発中のアプリケーションのパフォーマンスを理解するのに役立つツールです。 +Turbopack トレーシングは、ローカル開発中のアプリケーションパフォーマンスを理解するのに役立つツールです。 各モジュールのコンパイルにかかった時間とそれらの関係についての詳細な情報を提供します。 1. Next.js の最新バージョンがインストールされていることを確認します。 -1. Turbopack トレースファイルを生成します： +1. Turbopack トレースファイルを生成します: ```bash NEXT_TURBOPACK_TRACING=1 npm run dev ``` -1. アプリケーションを操作したり、ファイルを編集して問題を再現します。 +1. アプリケーション内を移動したりファイルを編集したりして問題を再現します。 1. Next.js 開発サーバーを停止します。 1. `.next` フォルダに `trace-turbopack` というファイルが作成されます。 -1. `next internal trace [path-to-file]` を使用してファイルを解釈できます： +1. `next internal trace [ファイルパス]` を使用してファイルを解釈できます: ```bash next internal trace .next/trace-turbopack ``` - `trace` が利用できないバージョンでは、コマンド名は `turbo-trace-server` でした： + `trace` が利用できないバージョンでは、コマンド名が `turbo-trace-server` でした: ```bash next internal turbo-trace-server .next/trace-turbopack ``` -1. トレースサーバーが起動したら、https://trace.nextjs.org/ でトレースを表示できます。 -1. デフォルトでは、トレースビューアはタイミングを集約します。個々の時間を見るには、ビューアの右上にある「Aggregated in order」から「Spans in order」に切り替えます。 +1. トレースサーバーが起動すると、https://trace.nextjs.org/ でトレースを表示できます。 +1. デフォルトでは、トレースビューアはタイミングを集約します。個々の時間を確認するには、ビューアの右上にある「Aggregated in order」から「Spans in order」に切り替えます。 ## まだ問題が解決しない場合 diff --git a/apps/docs/content/ja/docs/01-app/02-guides/memory-usage.mdx b/apps/docs/content/ja/docs/01-app/02-guides/memory-usage.mdx index f44fbed8..47fa628f 100644 --- a/apps/docs/content/ja/docs/01-app/02-guides/memory-usage.mdx +++ b/apps/docs/content/ja/docs/01-app/02-guides/memory-usage.mdx @@ -1,36 +1,36 @@ --- -source-updated-at: 2025-05-16T04:52:11.000Z -translation-updated-at: 2025-06-02T19:58:09.475Z +source-updated-at: 2025-06-05T15:29:30.000Z +translation-updated-at: 2025-06-06T16:35:37.972Z title: メモリ使用量の最適化方法 nav_title: メモリ使用量 -description: 開発環境および本番環境でのアプリケーションのメモリ使用量を最適化します。 +description: 開発環境と本番環境におけるアプリケーションのメモリ使用量を最適化します。 --- アプリケーションが成長し、機能が豊富になるにつれて、ローカルでの開発や本番ビルドの作成時により多くのリソースを必要とする場合があります。 -Next.jsにおけるメモリの最適化と一般的なメモリ問題への対処方法について、いくつかの戦略とテクニックを探ってみましょう。 +Next.jsにおけるメモリの最適化と一般的なメモリ問題に対処するための戦略とテクニックを探ってみましょう。 ## 依存関係の数を減らす 大量の依存関係を持つアプリケーションは、より多くのメモリを使用します。 -[バンドルアナライザー](/docs/app/guides/package-bundling)を使用すると、アプリケーション内の大きな依存関係を調査し、パフォーマンスとメモリ使用量を改善するために削除可能なものを特定できます。 +[バンドルアナライザー](/docs/app/guides/package-bundling)を使用すると、パフォーマンスとメモリ使用量を改善するために削除可能な大きな依存関係を調査できます。 ## `experimental.webpackMemoryOptimizations` を試す -`v15.0.0` 以降では、`next.config.js` ファイルに `experimental.webpackMemoryOptimizations: true` を追加することで、Webpackの動作を変更し、最大メモリ使用量を削減できます（ただし、コンパイル時間がわずかに増加する可能性があります）。 +`v15.0.0` から、`next.config.js` ファイルに `experimental.webpackMemoryOptimizations: true` を追加することで、Webpackの動作を変更し、最大メモリ使用量を削減できます（ただし、コンパイル時間がわずかに増加する可能性があります）。 -> **豆知識**: この機能は現在実験段階であり、より多くのプロジェクトでテスト中ですが、低リスクと考えられています。 +> **知っておくと良い**: この機能は現在実験的であり、より多くのプロジェクトでテストされていますが、リスクは低いと考えられています。 ## `next build` を `--experimental-debug-memory-usage` で実行する -`14.2.0` 以降では、`next build --experimental-debug-memory-usage` を実行することで、ビルド中にヒープ使用量やガベージコレクション統計など、メモリ使用量に関する情報を継続的に出力するモードでビルドを実行できます。また、メモリ使用量が設定された制限に近づくと、ヒープスナップショットが自動的に取得されます。 +`14.2.0` から、`next build --experimental-debug-memory-usage` を実行すると、ビルド中にメモリ使用量に関する情報（ヒープ使用量やガベージコレクションの統計など）が継続的に出力されます。また、メモリ使用量が設定された制限に近づくと、ヒープスナップショットが自動的に取得されます。 -> **豆知識**: この機能は、カスタムWebpack設定がない場合に自動的に有効になるWebpackビルドワーカーオプションと互換性がありません。 +> **知っておくと良い**: この機能は、カスタムWebpack設定がない場合に自動的に有効になるWebpackビルドワーカーオプションと互換性がありません。 ## ヒーププロファイルを記録する -メモリ問題を調査するために、Node.jsからヒーププロファイルを記録し、Chrome DevToolsで読み込んでメモリリークの潜在的な原因を特定できます。 +メモリの問題を調査するために、Node.jsからヒーププロファイルを記録し、Chrome DevToolsで読み込んでメモリリークの潜在的な原因を特定できます。 ターミナルで、Next.jsビルドを開始する際にNode.jsに `--heap-prof` フラグを渡します: @@ -38,20 +38,20 @@ Next.jsにおけるメモリの最適化と一般的なメモリ問題への対 node --heap-prof node_modules/next/dist/bin/next build ``` -ビルド終了時に、Node.jsによって `.heapprofile` ファイルが作成されます。 +ビルドの終了時に、Node.jsによって `.heapprofile` ファイルが作成されます。 -Chrome DevToolsでは、Memoryタブを開き、"Load Profile"ボタンをクリックしてファイルを視覚化できます。 +Chrome DevToolsでは、Memoryタブを開き、「Load Profile」ボタンをクリックしてファイルを視覚化できます。 ## ヒープのスナップショットを分析する インスペクターツールを使用して、アプリケーションのメモリ使用量を分析できます。 `next build` または `next dev` コマンドを実行する際に、コマンドの先頭に `NODE_OPTIONS=--inspect` を追加します。これにより、デフォルトポートでインスペクターエージェントが公開されます。 -ユーザーコードが開始する前にブレークしたい場合は、代わりに `--inspect-brk` を渡すことができます。プロセスが実行中に、Chrome DevToolsなどのツールを使用してデバッグポートに接続し、ヒープのスナップショットを記録・分析して、どのメモリが保持されているかを確認できます。 +ユーザーコードが開始する前にブレークしたい場合は、代わりに `--inspect-brk` を渡します。プロセスが実行されている間、Chrome DevToolsなどのツールを使用してデバッグポートに接続し、ヒープのスナップショットを記録・分析して、どのメモリが保持されているかを確認できます。 -`14.2.0` 以降では、`next build` を `--experimental-debug-memory-usage` フラグ付きで実行することで、ヒープスナップショットの取得が容易になります。 +`14.2.0` から、`next build` を `--experimental-debug-memory-usage` フラグ付きで実行すると、ヒープスナップショットの取得が容易になります。 -このモードで実行中、任意の時点でプロセスに `SIGUSR2` シグナルを送信すると、プロセスがヒープスナップショットを取得します。 +このモードで実行中、任意の時点でプロセスに `SIGUSR2` シグナルを送信すると、プロセスはヒープスナップショットを取得します。 ヒープスナップショットはNext.jsアプリケーションのプロジェクトルートに保存され、Chrome DevToolsなどのヒープアナライザーで読み込んで、保持されているメモリを確認できます。このモードはまだWebpackビルドワーカーと互換性がありません。 @@ -61,11 +61,11 @@ Chrome DevToolsでは、Memoryタブを開き、"Load Profile"ボタンをクリ Webpackビルドワーカーを使用すると、Webpackコンパイルを別のNode.jsワーカー内で実行できるため、ビルド中のアプリケーションのメモリ使用量が減少します。 -`v14.1.0` 以降、カスタムWebpack設定がないアプリケーションではこのオプションがデフォルトで有効になっています。 +このオプションは、`v14.1.0` からカスタムWebpack設定がないアプリケーションでデフォルトで有効になっています。 -古いバージョンのNext.jsを使用している場合やカスタムWebpack設定がある場合は、`next.config.js` 内で `experimental.webpackBuildWorker: true` を設定することでこのオプションを有効にできます。 +古いバージョンのNext.jsを使用している場合やカスタムWebpack設定がある場合は、`next.config.js` 内で `experimental.webpackBuildWorker: true` を設定してこのオプションを有効にできます。 -> **豆知識**: この機能はすべてのカスタムWebpackプラグインと互換性があるわけではありません。 +> **知っておくと良い**: この機能はすべてのカスタムWebpackプラグインと互換性があるわけではありません。 ## Webpackキャッシュを無効にする @@ -97,18 +97,18 @@ export default nextConfig 型チェックとリンターは、特に大規模なプロジェクトで多くのメモリを必要とする場合があります。 ただし、ほとんどのプロジェクトにはこれらのタスクを処理する専用のCIランナーがあります。 -ビルド中に「Linting and checking validity of types」ステップでメモリ不足の問題が発生する場合は、ビルド中にこれらのタスクを無効にできます: +ビルド中に「Linting and checking validity of types」ステップでメモリ不足の問題が発生する場合、ビルド中にこれらのタスクを無効にできます: ```js filename="next.config.mjs" /** @type {import('next').NextConfig} */ const nextConfig = { eslint: { - // 警告: これにより、プロジェクトにESLintエラーがあっても本番ビルドが正常に完了します + // 警告: これにより、プロジェクトにESLintエラーがあっても本番ビルドが成功します。 ignoreDuringBuilds: true, }, typescript: { // !! 警告 !! - // プロジェクトに型エラーがあっても本番ビルドが正常に完了するようにします + // プロジェクトに型エラーがあっても本番ビルドが成功するようにします。 // !! 警告 !! ignoreBuildErrors: true, }, @@ -117,21 +117,54 @@ const nextConfig = { export default nextConfig ``` -- [TypeScriptエラーの無視](/docs/app/api-reference/config/typescript#disabling-typescript-errors-in-production) +- [TypeScriptエラーを無視する](/docs/app/api-reference/config/typescript#disabling-typescript-errors-in-production) - [Next.js設定でのESLint](/docs/pages/api-reference/config/next-config-js/eslint) 型エラーやリンターの問題により、欠陥のあるデプロイが生成される可能性があることに注意してください。 -静的解析が完了した後にのみ本番環境にビルドを昇格させることを強くお勧めします。 -Vercelにデプロイする場合は、[ステージングデプロイのガイド](https://vercel.com/docs/deployments/managing-deployments#staging-and-promoting-a-production-deployment)をチェックして、カスタムタスクが成功した後に本番環境にビルドを昇格させる方法を学べます。 +静的解析が完了した後にのみ本番環境にビルドをプロモートすることを強く推奨します。 +Vercelにデプロイする場合は、[ステージングデプロイのガイド](https://vercel.com/docs/deployments/managing-deployments#staging-and-promoting-a-production-deployment)を参照して、カスタムタスクが成功した後に本番環境にビルドをプロモートする方法を学べます。 ## ソースマップを無効にする ソースマップの生成は、ビルドプロセス中に追加のメモリを消費します。 -Next.js設定に `productionBrowserSourceMaps: false` と `experimental.serverSourceMaps: false` を追加することで、ソースマップの生成を無効にできます。 +`productionBrowserSourceMaps: false` と `experimental.serverSourceMaps: false` をNext.js設定に追加することで、ソースマップの生成を無効にできます。 -> **豆知識**: 一部のプラグインはソースマップを有効にする場合があり、無効にするにはカスタム設定が必要になることがあります。 +> **知っておくと良い**: 一部のプラグインはソースマップを有効にすることがあり、無効にするにはカスタム設定が必要な場合があります。 ## Edgeランタイムのメモリ問題 -Next.js `v14.1.3` では、Edgeランタイム使用時のメモリ問題が修正されました。この問題が解決されているか確認するには、このバージョン（またはそれ以降）に更新してください。 \ No newline at end of file +Next.js `v14.1.3` では、Edgeランタイム使用時のメモリ問題が修正されました。この問題に対処するには、このバージョン（またはそれ以降）に更新してください。 + +## エントリのプリロード + +Next.jsサーバーが起動すると、各ページのJavaScriptモジュールがリクエスト時ではなく、起動時にメモリにプリロードされます。 + +この最適化により、応答時間が短縮されますが、初期メモリ使用量が増加します。 + +この最適化を無効にするには、`experimental.preloadEntriesOnStart` フラグを `false` に設定します。 + +```ts filename="next.config.ts" switcher +import type { NextConfig } from 'next' + +const config: NextConfig = { + experimental: { + preloadEntriesOnStart: false, + }, +} + +export default config +``` + +```js filename="next.config.mjs" switcher +/** @type {import('next').NextConfig} */ +const config = { + experimental: { + preloadEntriesOnStart: false, + }, +} + +export default config +``` + +Next.jsはこれらのJavaScriptモジュールをアンロードしないため、この最適化を無効にしても、すべてのページが最終的にリクエストされると、Next.jsサーバーのメモリ使用量は最終的に同じになります。 \ No newline at end of file diff --git a/apps/docs/content/ja/docs/01-app/05-api-reference/04-functions/generate-metadata.mdx b/apps/docs/content/ja/docs/01-app/05-api-reference/04-functions/generate-metadata.mdx index 6babd233..c61b0f89 100644 --- a/apps/docs/content/ja/docs/01-app/05-api-reference/04-functions/generate-metadata.mdx +++ b/apps/docs/content/ja/docs/01-app/05-api-reference/04-functions/generate-metadata.mdx @@ -1,11 +1,11 @@ --- -source-updated-at: 2025-06-01T01:32:20.000Z -translation-updated-at: 2025-06-02T20:13:29.566Z +source-updated-at: 2025-06-05T15:29:30.000Z +translation-updated-at: 2025-06-06T16:42:35.576Z title: generateMetadata -description: Next.jsアプリケーションにメタデータを追加して検索エンジン最適化（SEO）とWeb共有性を向上させる方法を学びましょう。 +description: Next.jsアプリケーションにメタデータを追加して検索エンジン最適化（SEO）とウェブ共有性を向上させる方法を学びます。 related: title: 次のステップ - description: メタデータAPIの全オプションを確認する + description: メタデータAPIの全オプションを確認する。 links: - app/api-reference/file-conventions/metadata - app/api-reference/functions/generate-viewport @@ -41,7 +41,7 @@ export default function Page() {} ## `generateMetadata`関数 -動的メタデータは、現在のルートパラメータ、外部データ、または親セグメントの`metadata`などの**動的情報**に依存します。これは、[`Metadata`オブジェクト](#metadata-fields)を返す`generateMetadata`関数をエクスポートすることで設定できます。 +動的な情報（現在のルートパラメータ、外部データ、または親セグメントの`metadata`など）に依存する動的メタデータは、[`Metadata`オブジェクト](#metadata-fields)を返す`generateMetadata`関数をエクスポートすることで設定できます。 ```tsx filename="app/products/[id]/page.tsx" switcher import type { Metadata, ResolvingMetadata } from 'next' @@ -58,7 +58,7 @@ export async function generateMetadata( // ルートパラメータを読み取る const { id } = await params - // データを取得する + // データを取得 const product = await fetch(`https://.../${id}`).then((res) => res.json()) // オプションで親メタデータにアクセスして拡張（置換ではなく） @@ -80,7 +80,7 @@ export async function generateMetadata({ params, searchParams }, parent) { // ルートパラメータを読み取る const { id } = await params - // データを取得する + // データを取得 const product = await fetch(`https://.../${id}`).then((res) => res.json()) // オプションで親メタデータにアクセスして拡張（置換ではなく） @@ -97,13 +97,13 @@ export async function generateMetadata({ params, searchParams }, parent) { export default function Page({ params, searchParams }) {} ``` -> **知っておくと良いこと**: +> **知っておくと便利**: > > - メタデータは`layout.js`と`page.js`ファイルに追加できます。 > - Next.jsは自動的にメタデータを解決し、ページに関連する``タグを作成します。 > - `metadata`オブジェクトと`generateMetadata`関数のエクスポートは**サーバーコンポーネントでのみサポート**されています。 > - 同じルートセグメントから`metadata`オブジェクトと`generateMetadata`関数の両方をエクスポートすることはできません。 -> - `generateMetadata`内の`fetch`リクエストは、`generateMetadata`、`generateStaticParams`、レイアウト、ページ、およびサーバーコンポーネント間で同じデータに対して自動的に[メモ化](/docs/app/deep-dive/caching#request-memoization)されます。 +> - `generateMetadata`内の`fetch`リクエストは、`generateMetadata`、`generateStaticParams`、レイアウト、ページ、サーバーコンポーネント間で同じデータに対して自動的に[メモ化](/docs/app/deep-dive/caching#request-memoization)されます。 > - `fetch`が利用できない場合、Reactの[`cache`を使用できます](/docs/app/deep-dive/caching#react-cache-function)。 > - [ファイルベースのメタデータ](/docs/app/api-reference/file-conventions/metadata)は優先度が高く、`metadata`オブジェクトと`generateMetadata`関数を上書きします。 @@ -111,11 +111,11 @@ export default function Page({ params, searchParams }) {} ### パラメータ -`generateMetadata`関数は次のパラメータを受け入れます: +`generateMetadata`関数は以下のパラメータを受け取ります: - `props` - 現在のルートのパラメータを含むオブジェクト: - - `params` - `generateMetadata`が呼び出されたセグメントまでのルートセグメントからの[動的ルートパラメータ](/docs/app/api-reference/file-conventions/dynamic-routes)オブジェクトを含むオブジェクト。例: + - `params` - `generateMetadata`が呼び出されたセグメントまでの[動的ルートパラメータ](/docs/app/api-reference/file-conventions/dynamic-routes)オブジェクトを含むオブジェクト。例: | ルート | URL | `params` | | ------------------------------- | ----------- | ------------------------- | @@ -137,10 +137,10 @@ export default function Page({ params, searchParams }) {} `generateMetadata`は、1つ以上のメタデータフィールドを含む[`Metadata`オブジェクト](#metadata-fields)を返す必要があります。 -> **知っておくと良いこと**: +> **知っておくと便利**: > > - メタデータがランタイム情報に依存しない場合は、`generateMetadata`ではなく静的[`metadata`オブジェクト](#the-metadata-object)を使用して定義する必要があります。 -> - `fetch`リクエストは、`generateMetadata`、`generateStaticParams`、レイアウト、ページ、およびサーバーコンポーネント間で同じデータに対して自動的に[メモ化](/docs/app/deep-dive/caching#request-memoization)されます。`fetch`が利用できない場合、Reactの[`cache`を使用できます](/docs/app/deep-dive/caching#react-cache-function)。 +> - `fetch`リクエストは、`generateMetadata`、`generateStaticParams`、レイアウト、ページ、サーバーコンポーネント間で同じデータに対して自動的に[メモ化](/docs/app/deep-dive/caching#request-memoization)されます。`fetch`が利用できない場合、Reactの[`cache`を使用できます](/docs/app/deep-dive/caching#react-cache-function)。 > - `searchParams`は`page.js`セグメントでのみ利用可能です。 > - Next.jsの[`redirect()`](/docs/app/api-reference/functions/redirect)および[`notFound()`](/docs/app/api-reference/functions/not-found)メソッドも`generateMetadata`内で使用できます。 @@ -160,7 +160,7 @@ export const metadata = { } ``` -```html filename=" 出力" hideLineNumbers +```html filename=" output" hideLineNumbers Next.js ``` @@ -188,7 +188,7 @@ export const metadata: Metadata = {} ##### `template` -`title.template`は、**子**ルートセグメントで定義された`title`にプレフィックスまたはサフィックスを追加するために使用できます。 +`title.template`は、**子**ルートセグメントで定義された`titles`にプレフィックスまたはサフィックスを追加するために使用できます。 ```tsx filename="app/layout.tsx" switcher import type { Metadata } from 'next' @@ -196,7 +196,7 @@ import type { Metadata } from 'next' export const metadata: Metadata = { title: { template: '%s | Acme', - default: 'Acme', // テンプレートを作成する際はデフォルトが必要です + default: 'Acme', // テンプレート作成時にはdefaultが必要 }, } ``` @@ -205,7 +205,7 @@ export const metadata: Metadata = { export const metadata = { title: { template: '%s | Acme', - default: 'Acme', // テンプレートを作成する際はデフォルトが必要です + default: 'Acme', // テンプレート作成時にはdefaultが必要 }, } ``` @@ -228,13 +228,13 @@ export const metadata = { // 出力: About | Acme ``` -> **知っておくと良いこと**: +> **知っておくと便利**: > -> - `title.template`は、それが定義されているセグメントではなく、**子**ルートセグメントに適用されます。つまり: +> - `title.template`は**子**ルートセグメントに適用され、定義されたセグメント自体には適用されません。つまり: > -> - `title.template`を追加する際は、`title.default`が**必須**です。 +> - `title.template`を追加する場合、`title.default`は**必須**です。 > - `layout.js`で定義された`title.template`は、同じルートセグメントの`page.js`で定義された`title`には適用されません。 -> - `page.js`で定義された`title.template`は効果がありません。なぜなら、ページは常に終端セグメント（子ルートセグメントを持たない）だからです。 +> - `page.js`で定義された`title.template`は効果がありません。ページは常に終端セグメントであるため（子ルートセグメントを持たない）。 > > - ルートが`title`または`title.default`を定義していない場合、`title.template`は**効果がありません**。 @@ -282,7 +282,7 @@ export const metadata = { // 出力: About ``` -> **知っておくと良いこと**: +> **知っておくと便利**: > > - `layout.js` > @@ -291,10 +291,10 @@ export const metadata = { > - `title.template`は子セグメントの新しいタイトルテンプレートを定義します。 > > - `page.js` -> - ページが独自のタイトルを定義していない場合、最も近い親の解決されたタイトルが使用されます。 +> - ページが独自のタイトルを定義していない場合、最も近い親の解決済みタイトルが使用されます。 > - `title`（文字列）はルートのタイトルを定義します。存在する場合、最も近い親セグメントの`title.template`を拡張します。 -> - `title.absolute`はルートのタイトルを定義します。親セグメントの`title.template`を無視します。 -> - `title.template`は`page.js`では効果がありません。なぜなら、ページは常にルートの終端セグメントだからです。 +> - `title.absolute`はルートタイトルを定義します。親セグメントの`title.template`を無視します。 +> - `title.template`は`page.js`では効果がありません。ページは常にルートの終端セグメントであるため。 ### `description` @@ -304,7 +304,7 @@ export const metadata = { } ``` -```html filename=" 出力" hideLineNumbers +```html filename=" output" hideLineNumbers ``` @@ -327,7 +327,7 @@ export const metadata = { } ``` -```html filename=" 出力" hideLineNumbers +```html filename=" output" hideLineNumbers @@ -364,16 +364,16 @@ export const metadata = { } ``` -```html filename=" 出力" hideLineNumbers +```html filename=" output" hideLineNumbers ``` -> **知っておくと良いこと**: +> **知っておくと便利**: > -> - `metadataBase`は通常、すべてのルートにわたってURLベースの`metadata`フィールドを適用するためにルート`app/layout.js`で設定されます。 +> - `metadataBase`は通常、すべてのルートにわたるURLベースの`metadata`フィールドに適用するためにルート`app/layout.js`で設定されます。 > - 絶対URLを必要とするすべてのURLベースの`metadata`フィールドは、`metadataBase`オプションで設定できます。 > - `metadataBase`にはサブドメイン（例: `https://app.acme.com`）またはベースパス（例: `https://acme.com/start/from/here`）を含めることができます。 > - `metadata`フィールドが絶対URLを提供する場合、`metadataBase`は無視されます。 @@ -387,7 +387,7 @@ URL構成は、デフォルトのディレクトリトラバーサルセマン - `metadataBase`と`metadata`フィールド間の末尾のスラッシュは正規化されます。 - `metadata`フィールドの「絶対」パス（通常はURLパス全体を置き換える）は、「相対」パス（`metadataBase`の末尾から開始）として扱われます。 -例えば、次の`metadataBase`がある場合: +例えば、以下の`metadataBase`がある場合: ```tsx filename="app/layout.tsx" switcher import type { Metadata } from 'next' @@ -405,14 +405,14 @@ export const metadata = { 上記の`metadataBase`を継承し、独自の値を設定する`metadata`フィールドは次のように解決されます: -| `metadata`フィールド | 解決されたURL | -| -------------------------------- | -------------------------------- | -| `/` | `https://acme.com` | -| `./` | `https://acme.com` | -| `payments` | `https://acme.com/payments` | -| `/payments` | `https://acme.com/payments` | -| `./payments` | `https://acme.com/payments` | -| `../payments` | `https://acme.com/payments` | +| `metadata`フィールド | 解決されたURL | +| ------------------------------ | -------------------------------- | +| `/` | `https://acme.com` | +| `./` | `https://acme.com` | +| `payments` | `https://acme.com/payments` | +| `/payments` | `https://acme.com/payments` | +| `./payments` | `https://acme.com/payments` | +| `../payments` | `https://acme.com/payments` | | `https://beta.acme.com/payments` | `https://beta.acme.com/payments` | ### `openGraph` @@ -532,7 +532,7 @@ export const metadata: Metadata = { ### `icons` -> **知っておくと便利**: 可能な限り[ファイルベースのMetadata API](/docs/app/api-reference/file-conventions/metadata/app-icons#image-files-ico-jpg-png)を使用することをお勧めします。設定エクスポートと実際のファイルを同期させる必要がなく、ファイルベースのAPIが自動的に正しいメタデータを生成します。 +> **知っておくと便利**: アイコンには可能な限り[ファイルベースのMetadata API](/docs/app/api-reference/file-conventions/metadata/app-icons#image-files-ico-jpg-png)を使用することを推奨します。設定エクスポートと実際のファイルを同期させる必要がなく、ファイルベースのAPIが自動的に正しいメタデータを生成します。 ```jsx filename="layout.js | page.js" export const metadata = { @@ -840,7 +840,7 @@ export const metadata = { ### `archives` -歴史的価値のある記録、文書、その他の資料のコレクションを記述します（[出典](https://www.w3.org/TR/2011/WD-html5-20110113/links.html#rel-archives)）。 +歴史的な価値のある記録、文書、その他の資料のコレクションを記述します（[出典](https://www.w3.org/TR/2011/WD-html5-20110113/links.html#rel-archives)）。 ```jsx filename="layout.js | page.js" export const metadata = { @@ -965,7 +965,7 @@ export const metadata = { ``` -同じキーの複数のメタタグを生成したい場合は配列値を使用できます。 +同じキーのメタタグを複数生成したい場合は配列値を使用できます。 ```jsx filename="layout.js | page.js" export const metadata = { @@ -979,13 +979,13 @@ export const metadata = { ``` -### サポートされていないメタデータ +### 未サポートのメタデータ 以下のメタデータタイプは現在組み込みサポートがありません。ただし、レイアウトやページ内で直接レンダリングすることは可能です。 ### タイプ -`Metadata` タイプを使用してメタデータに型安全性を追加できます。[組み込みのTypeScriptプラグイン](/docs/app/api-reference/config/typescript)をIDEで使用している場合、手動でタイプを追加する必要はありませんが、明示的に追加することも可能です。 +メタデータに型安全性を追加するには、`Metadata` タイプを使用します。[組み込みのTypeScriptプラグイン](/docs/app/api-reference/config/typescript)をIDEで使用している場合、手動でタイプを追加する必要はありませんが、必要に応じて明示的に追加することもできます。 #### `metadata` オブジェクト @@ -1023,7 +1023,7 @@ export async function generateMetadata(): Promise { } ``` -##### セグメントプロパティ付き +##### セグメントプロパティを使用 ```tsx filename="layout.tsx | page.tsx" import type { Metadata } from 'next' @@ -1042,7 +1042,7 @@ export function generateMetadata({ params, searchParams }: Props): Metadata { export default function Page({ params, searchParams }: Props) {} ``` -##### 親メタデータ付き +##### 親メタデータを使用 ```tsx filename="layout.tsx | page.tsx" import type { Metadata, ResolvingMetadata } from 'next' @@ -1073,16 +1073,16 @@ export const metadata = { | `` | [`redirect()`](/docs/app/api-reference/functions/redirect)、[ミドルウェア](/docs/app/building-your-application/routing/middleware#nextresponse)、[セキュリティヘッダー](/docs/app/api-reference/config/next-config-js/headers)を使用して適切なHTTPヘッダーを設定 | | `` | レイアウトまたはページ自体でタグをレンダリング | | `