{title}
+{desc}
+例
@@ -20,21 +21,21 @@ CSPを使用することで、開発者はコンテンツのソース、スク{title}
+{desc}
+
- {/* 即座に読み込まれますが、別のクライアントバンドルで */}
+ {/* 即座に読み込むが、別のクライアントバンドルで */}
)
}
```
-> **Note:** server componentがclient componentを動的にインポートする場合、自動的な[コード分割](https://developer.mozilla.org/docs/Glossary/Code_splitting)は現在サポートされていません。
+> **注意：** Server ComponentがClient Componentを動的にインポートする場合、自動的な[コード分割](https://developer.mozilla.org/docs/Glossary/Code_splitting)は現在サポートされていません。
-### SSRのスキップ {#skipping-ssr}
+### SSRをスキップする {#skipping-ssr}
-`React.lazy()`とSuspenseを使用する場合、client componentはデフォルトで[プリレンダリング](https://github.com/reactwg/server-components/discussions/4)（SSR）されます。
+`React.lazy()`とSuspenseを使用する場合、Client Componentsはデフォルトで[プリレンダリング](https://github.com/reactwg/server-components/discussions/4)（SSR）されます。
-> **Note:** `ssr: false`オプションはclient componentでのみ機能し、クライアントのコード分割が適切に動作するようにclient componentに移動してください。
+> **注意：** `ssr: false`オプションはClient Componentsでのみ機能し、クライアントのコード分割が適切に動作するようにClient Componentsに移動してください。
-client componentのプリレンダリングを無効にしたい場合は、`ssr`オプションを`false`に設定できます：
+Client Componentのプリレンダリングを無効にしたい場合は、`ssr`オプションを`false`に設定できます：
```jsx
const ComponentC = dynamic(() => import('../components/C'), { ssr: false })
@@ -71,8 +72,7 @@ const ComponentC = dynamic(() => import('../components/C'), { ssr: false })
### Server Componentsのインポート {#importing-server-components}
-server componentを動的にインポートする場合、そのserver componentの子であるclient componentのみが遅延ロードされます。server component自体は遅延ロードされません。
-また、server componentで使用する場合、CSSなどの静的アセットのプリロードにも役立ちます。
+Server Componentを動的にインポートする場合、Server Component自体ではなく、その子であるClient Componentsのみが遅延読み込みされます。また、Server Componentsで使用する際にCSSなどの静的アセットをプリロードするのにも役立ちます。
```jsx title="app/page.js"
import dynamic from 'next/dynamic'
@@ -89,8 +89,8 @@ export default function ServerComponentExample() {
}
```
-> **Note:** server componentでは`ssr: false`オプションはサポートされていません。server componentで使用しようとするとエラーが表示されます。
-> `ssr: false`はserver componentで`next/dynamic`と共に使用することはできません。client componentに移動してください。
+> **注意：** Server Componentsでは`ssr: false`オプションはサポートされていません。Server Componentsで使用しようとするとエラーが発生します。
+> `ssr: false`はServer Componentsで`next/dynamic`と共に使用することはできません。Client Componentに移動してください。
### 外部ライブラリの読み込み {#loading-external-libraries}
@@ -174,7 +174,7 @@ const ClientComponent = dynamic(() =>
I love using Next.js
``` -[MDX](https://mdxjs.com/)は、Markdownのスーパーセットであり、Markdownファイル内で直接[JSX](https://react.dev/learn/writing-markup-with-jsx)を書くことができます。これは、動的なインタラクティビティを追加し、Reactコンポーネントをコンテンツ内に埋め込む強力な方法です。 +[MDX](https://mdxjs.com/)は、Markdownのスーパーセットであり、Markdownファイル内で直接[JSX](https://react.dev/learn/writing-markup-with-jsx)を書くことができます。動的なインタラクティビティを追加し、Reactコンポーネントをコンテンツ内に埋め込む強力な方法です。 -Next.jsは、アプリケーション内のローカルMDXコンテンツと、サーバー上で動的に取得されるリモートMDXファイルの両方をサポートできます。Next.jsプラグインは、MarkdownとReactコンポーネントをHTMLに変換する処理を行い、Server Components（App Routerでのデフォルト）での使用もサポートしています。 +Next.jsは、アプリケーション内のローカルMDXコンテンツと、サーバー上で動的にフェッチされるリモートMDXファイルの両方をサポートできます。Next.jsプラグインは、MarkdownとReactコンポーネントをHTMLに変換する処理を行い、Server Components（App Routerのデフォルト）での使用もサポートしています。 > **Good to know**: 完全な動作例については、[Portfolio Starter Kit](https://vercel.com/templates/next.js/portfolio-starter-kit)テンプレートを参照してください。 @@ -62,7 +62,7 @@ export default withMDX(nextConfig) ## `mdx-components.tsx`ファイルの追加 {#add-an-mdx-components-tsx-file} -グローバルなMDXコンポーネントを定義するために、プロジェクトのrootに`mdx-components.tsx`（または`.js`）ファイルを作成します。例えば、`pages`や`app`と同じレベル、または該当する場合は`src`内に作成します。 +プロジェクトのrootに`mdx-components.tsx`（または`.js`）ファイルを作成して、グローバルなMDXコンポーネントを定義します。たとえば、`pages`や`app`と同じレベル、または該当する場合は`src`内に配置します。{children}
}
```
@@ -553,7 +553,7 @@ export default function MdxLayout({ children }: { children: React.ReactNode }) {
```jsx title="app/mdx-page/layout.js" switcher
export default function MdxLayout({ children }) {
- // ここで共有レイアウトやスタイルを作成
+ // ここで共有レイアウトやスタイルを作成します
return {children}
}
```
@@ -572,7 +572,7 @@ MDXページ周りでレイアウトを共有するには、レイアウトコ
```tsx title="components/mdx-layout.tsx" switcher
export default function MdxLayout({ children }: { children: React.ReactNode }) {
- // ここで共有レイアウトやスタイルを作成
+ // ここで共有レイアウトやスタイルを作成します
return {children}
}
```
@@ -582,7 +582,7 @@ export default function MdxLayout({ children }: { children: React.ReactNode }) {
```jsx title="components/mdx-layout.js" switcher
export default function MdxLayout({ children }) {
- // ここで共有レイアウトやスタイルを作成
+ // ここで共有レイアウトやスタイルを作成します
return {children}
}
```
@@ -611,7 +611,7 @@ export default function MDXPage({ children }) {
このプラグインは、Markdownのようなソースからのコンテンツブロックにタイポグラフィスタイルを追加するための`prose`クラスを追加します。
-[Tailwind typographyのインストール](https://github.com/tailwindlabs/tailwindcss-typography?tab=readme-ov-file#installation)と[共有レイアウト](#shared-layouts)を使用して、必要な`prose`を追加します。
+[Tailwind typographyをインストール](https://github.com/tailwindlabs/tailwindcss-typography?tab=readme-ov-file#installation)し、[共有レイアウト](#shared-layouts)で使用して、必要な`prose`を追加します。
{children}
@@ -634,7 +634,7 @@ export default function MdxLayout({ children }: { children: React.ReactNode }) {
```jsx title="app/mdx-page/layout.js" switcher
export default function MdxLayout({ children }) {
- // ここで共有レイアウトやスタイルを作成
+ // ここで共有レイアウトやスタイルを作成します
return (
{children}
@@ -657,7 +657,7 @@ MDXページ周りでレイアウトを共有するには、レイアウトコ
```tsx title="components/mdx-layout.tsx" switcher
export default function MdxLayout({ children }: { children: React.ReactNode }) {
- // ここで共有レイアウトやスタイルを作成
+ // ここで共有レイアウトやスタイルを作成します
return (
{children}
@@ -671,7 +671,7 @@ export default function MdxLayout({ children }: { children: React.ReactNode }) {
```jsx title="components/mdx-layout.js" switcher
export default function MdxLayout({ children }) {
- // ここで共有レイアウトやスタイルを作成
+ // ここで共有レイアウトやスタイルを作成します
return (
{children}
@@ -706,7 +706,7 @@ Frontmatterは、ページに関するデータを保存するために使用で
- [remark-mdx-frontmatter](https://github.com/remcohaszing/remark-mdx-frontmatter)
- [gray-matter](https://github.com/jonschlinkert/gray-matter)
-`@next/mdx`は、他のJavaScriptコンポーネントと同様にエクスポートを使用することを**許可**しています:
+`@next/mdx`は、他のJavaScriptコンポーネントと同様にエクスポートを使用することを許可しています:
@@ -790,7 +790,7 @@ export default function Page() {
-これの一般的な使用例は、MDXのコレクションを反復処理してデータを抽出したい場合です。例えば、すべてのブログ投稿からブログインデックスページを作成する場合です。[Nodeの`fs`モジュール](https://nodejs.org/api/fs.html)や[globby](https://www.npmjs.com/package/globby)などのパッケージを使用して、投稿のディレクトリを読み取り、メタデータを抽出できます。
+これの一般的な使用例は、MDXのコレクションを反復処理してデータを抽出したい場合です。たとえば、すべてのブログ投稿からブログインデックスページを作成する場合です。[Nodeの`fs`モジュール](https://nodejs.org/api/fs.html)や[globby](https://www.npmjs.com/package/globby)などのパッケージを使用して、投稿のディレクトリを読み取り、メタデータを抽出できます。
> **Good to know**:
>
@@ -801,7 +801,7 @@ export default function Page() {
MDXコンテンツを変換するために、remarkとrehypeプラグインをオプションで提供できます。
-例えば、[`remark-gfm`](https://github.com/remarkjs/remark-gfm)を使用してGitHub Flavored Markdownをサポートできます。
+たとえば、[`remark-gfm`](https://github.com/remarkjs/remark-gfm)を使用してGitHub Flavored Markdownをサポートできます。
remarkとrehypeのエコシステムはESMのみであるため、設定ファイルとして`next.config.mjs`または`next.config.ts`を使用する必要があります。
@@ -811,7 +811,7 @@ import createMDX from '@next/mdx'
/** @type {import('next').NextConfig} */
const nextConfig = {
- // ファイルの.mdおよび.mdx拡張子を許可
+ // ファイルの.mdまたは.mdx拡張子を許可
pageExtensions: ['js', 'jsx', 'md', 'mdx', 'ts', 'tsx'],
// 必要に応じて、他のNext.jsの設定を以下に追加
}
@@ -856,9 +856,9 @@ export default withMDX(nextConfig)
## リモートMDX {#remote-mdx}
-MDXファイルやコンテンツが*他の場所*にある場合、サーバー上で動的に取得できます。これは、CMS、データベース、または他の場所に保存されたコンテンツに便利です。この用途に人気のあるコミュニティパッケージは[`next-mdx-remote`](https://github.com/hashicorp/next-mdx-remote#react-server-components-rsc--nextjs-app-directory-support)です。
+MDXファイルやコンテンツが*他の場所*にある場合、サーバー上で動的にフェッチできます。これは、CMS、データベース、または他の場所に保存されているコンテンツに便利です。この用途で人気のあるコミュニティパッケージは[`next-mdx-remote`](https://github.com/hashicorp/next-mdx-remote#react-server-components-rsc--nextjs-app-directory-support)です。
-> **Good to know**: 注意して進めてください。MDXはJavaScriptにコンパイルされ、サーバー上で実行されます。信頼できるソースからのみMDXコンテンツを取得する必要があります。そうしないと、リモートコード実行（RCE）につながる可能性があります。
+> **Good to know**: 注意して進めてください。MDXはJavaScriptにコンパイルされ、サーバー上で実行されます。信頼できるソースからのみMDXコンテンツをフェッチする必要があります。そうでない場合、リモートコード実行（RCE）につながる可能性があります。
次の例では`next-mdx-remote`を使用しています:
@@ -952,9 +952,9 @@ export async function getStaticProps() {
## 深掘り: MarkdownをHTMLに変換する方法 {#deep-dive-how-do-you-transform-markdown-into-html}
-ReactはMarkdownをネイティブに理解しません。Markdownのプレーンテキストは、まずHTMLに変換される必要があります。これは`remark`と`rehype`で実現できます。
+ReactはネイティブにMarkdownを理解しません。Markdownのプレーンテキストは、まずHTMLに変換する必要があります。これは`remark`と`rehype`を使用して達成できます。
-`remark`はMarkdownに関するツールのエコシステムです。`rehype`はHTMLに関する同様のエコシステムです。例えば、次のコードスニペットはMarkdownをHTMLに変換します:
+`remark`はMarkdownに関するツールのエコシステムです。`rehype`はHTMLに関する同様のエコシステムです。たとえば、次のコードスニペットはMarkdownをHTMLに変換します:
```js
import { unified } from 'unified'
@@ -979,7 +979,7 @@ async function main() {
`remark`と`rehype`のエコシステムには、[シンタックスハイライト](https://github.com/atomiks/rehype-pretty-code)、[見出しのリンク](https://github.com/rehypejs/rehype-autolink-headings)、[目次の生成](https://github.com/remarkjs/remark-toc)などのプラグインがあります。
-上記のように`@next/mdx`を使用する場合、`remark`や`rehype`を直接使用する必要は**ありません**。これは自動的に処理されます。ここでは、`@next/mdx`パッケージが内部で行っていることをより深く理解するために説明しています。
+上記のように`@next/mdx`を使用する場合、`remark`や`rehype`を直接使用する必要はありません。これらは自動的に処理されます。ここでは、`@next/mdx`パッケージが内部で何をしているのかを深く理解するために説明しています。
## RustベースのMDXコンパイラの使用（実験的） {#using-the-rust-based-mdx-compiler-experimental}
diff --git a/docs/01-app/02-guides/memory-usage.mdx b/docs/01-app/02-guides/memory-usage.mdx
new file mode 100644
index 00000000..05e6d64a
--- /dev/null
+++ b/docs/01-app/02-guides/memory-usage.mdx
@@ -0,0 +1,137 @@
+---
+title: 'メモリ使用量を最適化する方法'
+nav_title: 'メモリ使用量'
+description: '開発および本番環境でアプリケーションのメモリ使用量を最適化します。'
+---
+
+アプリケーションが成長し、機能が豊富になるにつれて、ローカルでの開発や本番ビルドの作成時により多くのリソースを要求することがあります。
+
+Next.jsでメモリを最適化し、一般的なメモリ問題に対処するための戦略と技術を探ってみましょう。
+
+## 依存関係の数を減らす {#reduce-number-of-dependencies}
+
+依存関係が多いアプリケーションは、より多くのメモリを使用します。
+
+[Bundle Analyzer](/docs/app/guides/package-bundling)を使用すると、アプリケーション内の大きな依存関係を調査し、パフォーマンスとメモリ使用量を改善するために削除できるかどうかを確認できます。
+
+## `experimental.webpackMemoryOptimizations`を試す {#try-experimental-webpackmemoryoptimizations}
+
+`v15.0.0`から、`next.config.js`ファイルに`experimental.webpackMemoryOptimizations: true`を追加することで、Webpackの動作を変更し、最大メモリ使用量を削減できますが、コンパイル時間がわずかに増加する可能性があります。
+
+> **Good to know**: この機能は現在実験的であり、より多くのプロジェクトでテストするために提供されていますが、リスクは低いと考えられています。
+
+## `next build`を`--experimental-debug-memory-usage`で実行する {#run-next-build-with-experimental-debug-memory-usage}
+
+`14.2.0`から、`next build --experimental-debug-memory-usage`を実行することで、Next.jsがビルド中にメモリ使用量に関する情報を継続的に出力するモードでビルドを実行できます。ヒープ使用量やガベージコレクションの統計情報などが表示されます。メモリ使用量が設定された制限に近づくと、自動的にヒープスナップショットが取得されます。
+
+> **Good to know**: この機能は、カスタムwebpack設定がない限り自動的に有効になるWebpackビルドワーカーオプションとは互換性がありません。
+
+## ヒーププロファイルを記録する {#record-a-heap-profile}
+
+メモリ問題を探るために、Node.jsからヒーププロファイルを記録し、Chrome DevToolsで読み込んでメモリリークの潜在的な原因を特定できます。
+
+ターミナルで、Next.jsビルドを開始する際にNode.jsに`--heap-prof`フラグを渡します：
+
+```sh
+node --heap-prof node_modules/next/dist/bin/next build
+```
+
+ビルドの終了時に、Node.jsによって`.heapprofile`ファイルが作成されます。
+
+Chrome DevToolsでは、メモリタブを開き、「Load Profile」ボタンをクリックしてファイルを視覚化できます。
+
+## ヒープのスナップショットを分析する {#analyze-a-snapshot-of-the-heap}
+
+インスペクターツールを使用して、アプリケーションのメモリ使用量を分析できます。
+
+`next build`または`next dev`コマンドを実行する際に、コマンドの先頭に`NODE_OPTIONS=--inspect`を追加します。これにより、デフォルトポートでインスペクターエージェントが公開されます。
+ユーザーコードが開始する前にブレークしたい場合は、代わりに`--inspect-brk`を渡すことができます。プロセスが実行中の間、Chrome DevToolsなどのツールを使用してデバッグポートに接続し、ヒープのスナップショットを記録して分析し、どのメモリが保持されているかを確認できます。
+
+`14.2.0`から、`--experimental-debug-memory-usage`フラグを使用して`next build`を実行することもでき、ヒープスナップショットを簡単に取得できます。
+
+このモードで実行中に、任意の時点でプロセスに`SIGUSR2`シグナルを送信すると、プロセスはヒープスナップショットを取得します。
+
+ヒープスナップショットはNext.jsアプリケーションのプロジェクトrootに保存され、Chrome DevToolsなどのヒープアナライザーで読み込んで、どのメモリが保持されているかを確認できます。このモードはまだWebpackビルドワーカーとは互換性がありません。
+
+詳細については、[ヒープスナップショットの記録と分析方法](https://developer.chrome.com/docs/devtools/memory-problems/heap-snapshots)を参照してください。
+
+## Webpackビルドワーカー {#webpack-build-worker}
+
+Webpackビルドワーカーを使用すると、別のNode.jsワーカー内でWebpackコンパイルを実行でき、ビルド中のアプリケーションのメモリ使用量を削減できます。
+
+このオプションは、`v14.1.0`以降、カスタムWebpack設定がない場合にデフォルトで有効になります。
+
+古いバージョンのNext.jsを使用している場合やカスタムWebpack設定がある場合は、`next.config.js`内に`experimental.webpackBuildWorker: true`を設定してこのオプションを有効にできます。
+
+> **Good to know**: この機能はすべてのカスタムWebpackプラグインと互換性がない場合があります。
+
+## Webpackキャッシュを無効にする {#disable-webpack-cache}
+
+[Webpackキャッシュ](https://webpack.js.org/configuration/cache/)は、ビルドの速度を向上させるために生成されたWebpackモジュールをメモリおよび/またはディスクに保存します。これによりパフォーマンスが向上しますが、キャッシュデータを保存するためにアプリケーションのメモリ使用量も増加します。
+
+アプリケーションに[カスタムWebpack設定](/docs/app/api-reference/config/next-config-js/webpack)を追加することで、この動作を無効にできます：
+
+```js title="next.config.mjs"
+/** @type {import('next').NextConfig} */
+const nextConfig = {
+ webpack: (
+ config,
+ { buildId, dev, isServer, defaultLoaders, nextRuntime, webpack }
+ ) => {
+ if (config.cache && !dev) {
+ config.cache = Object.freeze({
+ type: 'memory',
+ })
+ }
+ // 重要: 修正された設定を返す
+ return config
+ },
+}
+
+export default nextConfig
+```
+
+## 静的解析を無効にする {#disable-static-analysis}
+
+型チェックやリントは、特に大規模なプロジェクトでは多くのメモリを必要とする場合があります。
+しかし、ほとんどのプロジェクトにはこれらのタスクをすでに処理する専用のCIランナーがあります。
+ビルド中に「型の有効性のリントとチェック」ステップでメモリ不足の問題が発生する場合、ビルド中にこれらのタスクを無効にできます：
+
+```js title="next.config.mjs"
+/** @type {import('next').NextConfig} */
+const nextConfig = {
+ eslint: {
+ // 警告: プロジェクトにESLintエラーがある場合でも
+ // 本番ビルドが正常に完了することを許可します。
+ ignoreDuringBuilds: true,
+ },
+ typescript: {
+ // !! 警告 !!
+ // プロジェクトに型エラーがある場合でも
+ // 本番ビルドが正常に完了することを危険に許可します。
+ // !! 警告 !!
+ ignoreBuildErrors: true,
+ },
+}
+
+export default nextConfig
+```
+
+- [TypeScriptエラーの無視](/docs/app/api-reference/config/typescript#disabling-typescript-errors-in-production)
+- [Next.js設定でのESLint](https://nextjs.org/docs/canary/pages/api-reference/config/next-config-js/eslint)
+
+これにより、型エラーやリントの問題が原因で誤ったデプロイが発生する可能性があることに注意してください。
+静的解析が完了した後にのみビルドを本番環境に昇格させることを強くお勧めします。
+Vercelにデプロイする場合は、[ステージングデプロイメントのガイド](https://vercel.com/docs/deployments/managing-deployments#staging-and-promoting-a-production-deployment)を参照して、カスタムタスクが成功した後にビルドを本番環境に昇格させる方法を学んでください。
+
+## ソースマップを無効にする {#disable-source-maps}
+
+ソースマップの生成は、ビルドプロセス中に追加のメモリを消費します。
+
+ソースマップの生成を無効にするには、`productionBrowserSourceMaps: false`と`experimental.serverSourceMaps: false`をNext.js設定に追加します。
+
+> **Good to know**: 一部のプラグインはソースマップをオンにする可能性があり、無効にするためにカスタム設定が必要な場合があります。
+
+## Edgeのメモリ問題 {#edge-memory-issues}
+
+Next.js `v14.1.3`では、Edge runtimeを使用する際のメモリ問題が修正されました。このバージョン（またはそれ以降）に更新して、問題が解決するかどうかを確認してください。
diff --git a/docs/01-app/02-guides/migrating/app-router-migration.mdx b/docs/01-app/02-guides/migrating/app-router-migration.mdx
index 5a53b5b7..1693b6c4 100644
--- a/docs/01-app/02-guides/migrating/app-router-migration.mdx
+++ b/docs/01-app/02-guides/migrating/app-router-migration.mdx
@@ -4,9 +4,9 @@ nav_title: 'App Router'
description: '既存の Next.js アプリケーションを Pages Router から App Router にアップグレードする方法を学びます。'
---
-このガイドでは、以下のことをサポートします：
+このガイドでは、以下のことを支援します：
-- [Next.js アプリケーションをバージョン 12 からバージョン 13 に更新する](#next-js-version)
+- [Next.js アプリケーションをバージョン 12 からバージョン 13 に更新する](#nextjs-version)
- [`pages` ディレクトリと `app` ディレクトリの両方で動作する機能をアップグレードする](#upgrading-new-features)
- [既存のアプリケーションを `pages` から `app` に段階的に移行する](#migrating-from-pages-to-app)
@@ -26,7 +26,7 @@ npm install next@latest react@latest react-dom@latest
### ESLint バージョン {#eslint-version}
-ESLint を使用している場合、ESLint のバージョンをアップグレードする必要があります：
+ESLint を使用している場合は、ESLint のバージョンをアップグレードする必要があります：
```bash title="Terminal"
npm install -D eslint-config-next@latest
@@ -43,13 +43,13 @@ npm install -D eslint-config-next@latest
## 新機能のアップグレード {#upgrading-new-features}
-Next.js 13 では、新しい [App Router](/docs/app/building-your-application/routing) が新機能と規約と共に導入されました。新しい Router は `app` ディレクトリで利用可能で、`pages` ディレクトリと共存します。
+Next.js 13 では、新しい [App Router](/docs/app/building-your-application/routing) が新機能と規約とともに導入されました。新しい Router は `app` ディレクトリで利用可能で、`pages` ディレクトリと共存します。
Next.js 13 へのアップグレードは、App Router の使用を必須としません。`pages` を引き続き使用し、両方のディレクトリで動作する新機能を利用できます。例えば、更新された [Image コンポーネント](#image-component)、[Link コンポーネント](#link-component)、[Script コンポーネント](#script-component)、および [Font 最適化](#font-optimization) などです。
### `
@@ -324,7 +324,7 @@ export default function Page() {
-**後:**
+**後：**
@@ -361,9 +361,9 @@ export default function Page() {
### ステップ 4: ページの移行 {#step-4-migrating-pages}
-- [`app` ディレクトリ](/docs/app/building-your-application/routing) のページはデフォルトで [Server Components](/docs/app/building-your-application/rendering/server-components) です。これは、`pages` ディレクトリのページが [Client Components](/docs/app/building-your-application/rendering/client-components) であるのとは異なります。
-- `app` での [データフェッチ](/docs/app/building-your-application/data-fetching) は変更されました。`getServerSideProps`、`getStaticProps`、`getInitialProps` はよりシンプルな API に置き換えられました。
-- `app` ディレクトリはネストされたフォルダを使用してルートを定義し、特別な `page.js` ファイルを使用してルートセグメントを公開します。
+- [`app` ディレクトリ](/docs/app/building-your-application/routing) のページはデフォルトで [Server Components](/docs/app/building-your-application/rendering/server-components) です。これは、`pages` ディレクトリのページが [Client Components](/docs/app/building-your-application/rendering/client-components) であることとは異なります。
+- `app` での [データ取得](/docs/app/building-your-application/data-fetching) は変更されました。`getServerSideProps`、`getStaticProps`、および `getInitialProps` は、よりシンプルな API に置き換えられました。
+- `app` ディレクトリは、ネストされたフォルダを使用してルートを定義し、特別な `page.js` ファイルを使用してルートセグメントを公開します。
- | `pages` ディレクトリ | `app` ディレクトリ | ルート |
| -------------------- | --------------------- | -------------- |
| `index.js` | `page.js` | `/` |
@@ -373,13 +373,13 @@ export default function Page() {
ページの移行を 2 つの主要なステップに分解することをお勧めします：
- ステップ 1: デフォルトでエクスポートされた Page コンポーネントを新しい Client Component に移動します。
-- ステップ 2: 新しい `page.js` ファイル内で新しい Client Component をインポートします。
+- ステップ 2: 新しい Client Component を `app` ディレクトリ内の新しい `page.js` ファイルにインポートします。
-> **Good to know**: これは `pages` ディレクトリと最も比較可能な動作を持つため、最も簡単な移行パスです。
+> **Good to know**: これは、`pages` ディレクトリと最も比較可能な動作を持つため、最も簡単な移行パスです。
**ステップ 1: 新しい Client Component を作成する**
-- `app` ディレクトリ内に新しいファイル（例：`app/home-page.tsx` など）を作成し、Client Component をエクスポートします。Client Components を定義するには、ファイルの先頭（インポートの前）に `'use client'` ディレクティブを追加します。
+- `app` ディレクトリ内に新しいファイル（例：`app/home-page.tsx` など）を作成し、Client Component をエクスポートします。Client Components を定義するには、ファイルの先頭に `'use client'` ディレクティブを追加します（インポートの前）。
- Pages Router と同様に、初回ページ読み込み時に Client Components を静的 HTML にプリレンダリングする [最適化ステップ](/docs/app/building-your-application/rendering/client-components#full-page-load) があります。
- `pages/index.js` からデフォルトでエクスポートされたページコンポーネントを `app/home-page.tsx` に移動します。
@@ -429,7 +429,7 @@ export default function HomePage({ recentPosts }) {
- `app` ディレクトリ内に新しい `app/page.tsx` ファイルを作成します。これはデフォルトで Server Component です。
- `home-page.tsx` Client Component をページにインポートします。
-- `pages/index.js` でデータをフェッチしていた場合、新しい [データフェッチ API](/docs/app/building-your-application/data-fetching/fetching) を使用してデータフェッチロジックを直接 Server Component に移動します。詳細は [データフェッチのアップグレードガイド](#step-6-migrating-data-fetching-methods) を参照してください。
+- `pages/index.js` でデータを取得していた場合は、新しい [データ取得 API](/docs/app/building-your-application/data-fetching/fetching) を使用してデータ取得ロジックを Server Component に直接移動します。詳細については、[データ取得アップグレードガイド](#step-6-migrating-data-fetching-methods)を参照してください。
@@ -445,9 +445,9 @@ async function getPosts() {
}
export default async function Page() {
- // Server Component で直接データをフェッチします
+ // Server Component で直接データを取得します
const recentPosts = await getPosts()
- // フェッチしたデータを Client Component に転送します
+ // 取得したデータを Client Component に転送します
return
-- 以前のページで `useRouter` を使用していた場合、新しいルーティングフックに更新する必要があります。[詳細はこちら](/docs/app/api-reference/functions/use-router)。
+- 以前のページで `useRouter` を使用していた場合は、新しいルーティングフックに更新する必要があります。[詳細はこちら](/docs/app/api-reference/functions/use-router)。
- 開発サーバーを起動し、[`http://localhost:3000`](http://localhost:3000) にアクセスします。`app` ディレクトリを通じて提供される既存のインデックスルートが表示されるはずです。
### ステップ 5: ルーティングフックの移行 {#step-5-migrating-routing-hooks}
-新しいルーターが `app` ディレクトリの新しい動作をサポートするために追加されました。
+新しいルーターが追加され、`app` ディレクトリでの新しい動作をサポートしています。
-`app` では、`next/navigation` からインポートされる 3 つの新しいフックを使用する必要があります：[`useRouter()`](/docs/app/api-reference/functions/use-router)、[`usePathname()`](/docs/app/api-reference/functions/use-pathname)、および [`useSearchParams()`](/docs/app/api-reference/functions/use-search-params)。
+`app` では、`next/navigation` からインポートされる 3 つの新しいフック、[`useRouter()`](/docs/app/api-reference/functions/use-router)、[`usePathname()`](/docs/app/api-reference/functions/use-pathname)、および [`useSearchParams()`](/docs/app/api-reference/functions/use-search-params) を使用する必要があります。
- 新しい `useRouter` フックは `next/navigation` からインポートされ、`pages` の `useRouter` フックとは異なる動作をします。`pages` の `useRouter` フックは `next/router` からインポートされます。
- [`next/router` からインポートされる `useRouter` フック](https://nextjs.org/docs/canary/pages/api-reference/functions/use-router) は `app` ディレクトリではサポートされていませんが、`pages` ディレクトリでは引き続き使用できます。
@@ -533,21 +533,21 @@ export default function ExampleClientComponent() {
- `isFallback` は削除されました。`fallback` は [置き換えられました](#replacing-fallback)。
- `locale`、`locales`、`defaultLocales`、`domainLocales` の値は削除されました。組み込みの i18n Next.js 機能は `app` ディレクトリでは不要です。[i18n について詳しくはこちら](/docs/app/building-your-application/routing/internationalization)。
-- `basePath` は削除されました。代替案は `useRouter` の一部ではありません。まだ実装されていません。
-- `asPath` は削除されました。新しいルーターから `as` の概念が削除されたためです。
+- `basePath` は削除されました。代替案は `useRouter` の一部にはなりません。まだ実装されていません。
+- `asPath` は削除されました。`as` の概念は新しいルーターから削除されました。
- `isReady` は削除されました。もはや必要ありません。[静的レンダリング](/docs/app/building-your-application/rendering/server-components#static-rendering-default) 中に、[`useSearchParams()`](/docs/app/api-reference/functions/use-search-params) フックを使用するコンポーネントはプリレンダリングステップをスキップし、代わりにクライアントで実行時にレンダリングされます。
- `route` は削除されました。`usePathname` または `useSelectedLayoutSegments()` が代替手段を提供します。
-[`useRouter()` API リファレンスを表示](/docs/app/api-reference/functions/use-router)。
+[`useRouter()` API リファレンスを参照](/docs/app/api-reference/functions/use-router)。
#### `pages` と `app` 間でのコンポーネントの共有 {#sharing-components-between-pages-and-app}
-コンポーネントを `pages` と `app` ルーター間で互換性を保つために、[`next/compat/router` からの `useRouter` フック](https://nextjs.org/docs/canary/pages/api-reference/functions/use-router#the-nextcompatrouter-export) を参照してください。
+`pages` と `app` ルーター間でコンポーネントを互換性のある状態に保つには、[`next/compat/router` からの `useRouter` フック](https://nextjs.org/docs/canary/pages/api-reference/functions/use-router#the-nextcompatrouter-export) を参照してください。
これは `pages` ディレクトリからの `useRouter` フックですが、ルーター間でコンポーネントを共有する際に使用することを意図しています。`app` ルーターでのみ使用する準備ができたら、新しい [`next/navigation` からの `useRouter`](/docs/app/api-reference/functions/use-router) に更新してください。
-### ステップ 6: データフェッチメソッドの移行 {#step-6-migrating-data-fetching-methods}
+### ステップ 6: データ取得メソッドの移行 {#step-6-migrating-data-fetching-methods}
-`pages` ディレクトリでは、`getServerSideProps` と `getStaticProps` を使用してページのデータをフェッチします。`app` ディレクトリ内では、これらの以前のデータフェッチ関数は、`fetch()` と `async` React Server Components を基盤とした [よりシンプルな API](/docs/app/building-your-application/data-fetching) に置き換えられました。
+`pages` ディレクトリでは、`getServerSideProps` と `getStaticProps` を使用してページのデータを取得します。`app` ディレクトリ内では、これらの以前のデータ取得関数は、`fetch()` と `async` React Server Components を基盤とした [よりシンプルな API](/docs/app/building-your-application/data-fetching) に置き換えられました。
@@ -564,7 +564,7 @@ export default async function Page() {
const dynamicData = await fetch(`https://...`, { cache: 'no-store' })
// このリクエストは 10 秒の寿命でキャッシュされるべきです。
- // `revalidate` オプションを持つ `getStaticProps` に似ています。
+ // `revalidate` オプションを使用した `getStaticProps` に似ています。
const revalidatedData = await fetch(`https://...`, {
next: { revalidate: 10 },
})
@@ -588,7 +588,7 @@ export default async function Page() {
const dynamicData = await fetch(`https://...`, { cache: 'no-store' })
// このリクエストは 10 秒の寿命でキャッシュされるべきです。
- // `revalidate` オプションを持つ `getStaticProps` に似ています。
+ // `revalidate` オプションを使用した `getStaticProps` に似ています。
const revalidatedData = await fetch(`https://...`, {
next: { revalidate: 10 },
})
@@ -602,7 +602,7 @@ export default async function Page() {
#### サーバーサイドレンダリング (`getServerSideProps`) {#server-side-rendering-getserversideprops}
-`pages` ディレクトリでは、`getServerSideProps` を使用してサーバー上でデータをフェッチし、ファイル内のデフォルトでエクスポートされた React コンポーネントに props を転送します。ページの初期 HTML はサーバーからプリレンダリングされ、その後ブラウザでページを「ハイドレート」（インタラクティブにする）します。
+`pages` ディレクトリでは、`getServerSideProps` を使用してサーバー上でデータを取得し、ファイル内のデフォルトでエクスポートされた React コンポーネントに props を転送します。ページの初期 HTML はサーバーからプリレンダリングされ、その後ブラウザでページを「ハイドレート」（インタラクティブにする）します。
```jsx title="pages/dashboard.js"
// `pages` ディレクトリ
@@ -625,9 +625,9 @@ export default function Dashboard({ projects }) {
}
```
-App Router では、[Server Components](/docs/app/building-your-application/rendering/server-components) を使用して React コンポーネント内にデータフェッチを配置できます。これにより、クライアントに送信する JavaScript の量を減らしながら、サーバーからレンダリングされた HTML を維持できます。
+App Router では、[Server Components](/docs/app/building-your-application/rendering/server-components) を使用して React コンポーネント内にデータ取得を配置できます。これにより、クライアントに送信する JavaScript の量を減らしながら、サーバーからレンダリングされた HTML を維持できます。
-`cache` オプションを `no-store` に設定することで、フェッチされたデータが [決してキャッシュされない](/docs/app/building-your-application/data-fetching/fetching) ことを示すことができます。これは `pages` ディレクトリの `getServerSideProps` に似ています。
+`cache` オプションを `no-store` に設定することで、取得したデータが [決してキャッシュされない](/docs/app/building-your-application/data-fetching/fetching) ことを示すことができます。これは `pages` ディレクトリの `getServerSideProps` に似ています。
@@ -690,7 +690,7 @@ export default async function Dashboard() {
`pages` ディレクトリでは、Node.js HTTP API に基づいてリクエストベースのデータを取得できます。
-例えば、`getServerSideProps` から `req` オブジェクトを取得し、リクエストの cookie やヘッダーを取得することができます。
+たとえば、`getServerSideProps` から `req` オブジェクトを取得し、リクエストの cookie やヘッダーを取得することができます。
```jsx title="pages/index.js"
// `pages` ディレクトリ
@@ -726,8 +726,8 @@ async function getData() {
}
export default async function Page() {
- // `cookies` または `headers` を Server Components 内で
- // 直接またはデータフェッチ関数内で使用できます
+ // Server Components 内で `cookies` または `headers` を直接使用するか、
+ // データ取得関数内で使用できます
const theme = (await cookies()).get('theme')
const data = await getData()
return '...'
@@ -748,8 +748,8 @@ async function getData() {
}
export default async function Page() {
- // `cookies` または `headers` を Server Components 内で
- // 直接またはデータフェッチ関数内で使用できます
+ // Server Components 内で `cookies` または `headers` を直接使用するか、
+ // データ取得関数内で使用できます
const theme = (await cookies()).get('theme')
const data = await getData()
return '...'
@@ -761,7 +761,7 @@ export default async function Page() {
#### 静的サイト生成 (`getStaticProps`) {#static-site-generation-getstaticprops}
-`pages` ディレクトリでは、`getStaticProps` 関数を使用してビルド時にページをプリレンダリングします。この関数は、外部 API からデータをフェッチしたり、データベースから直接データを取得したりして、このデータをページ全体に渡すために使用されます。
+`pages` ディレクトリでは、`getStaticProps` 関数を使用してビルド時にページをプリレンダリングします。この関数は、外部 API からデータを取得したり、データベースから直接データを取得したりして、このデータをページ全体に渡し、ビルド中に生成します。
```jsx title="pages/index.js"
// `pages` ディレクトリ
@@ -778,7 +778,7 @@ export default function Index({ projects }) {
}
```
-`app` ディレクトリでは、[`fetch()`](/docs/app/api-reference/functions/fetch) を使用したデータフェッチはデフォルトで `cache: 'force-cache'` となり、リクエストデータが手動で無効化されるまでキャッシュされます。これは `pages` ディレクトリの `getStaticProps` に似ています。
+`app` ディレクトリでは、[`fetch()`](/docs/app/api-reference/functions/fetch) を使用したデータ取得はデフォルトで `cache: 'force-cache'` となり、リクエストデータが手動で無効化されるまでキャッシュされます。これは `pages` ディレクトリの `getStaticProps` に似ています。
```jsx title="app/page.js"
// `app` ディレクトリ
@@ -826,7 +826,7 @@ export default function Post({ post }) {
`app` ディレクトリでは、`getStaticPaths` は [`generateStaticParams`](/docs/app/api-reference/functions/generate-static-params) に置き換えられました。
-[`generateStaticParams`](/docs/app/api-reference/functions/generate-static-params) は `getStaticPaths` と同様に動作しますが、ルートパラメータを返すためのシンプルな API を持ち、[レイアウト](/docs/app/building-your-application/routing/layouts-and-templates) 内で使用できます。`generateStaticParams` の戻り値の形は、ネストされた `param` オブジェクトの配列や解決されたパスの文字列ではなく、セグメントの配列です。
+[`generateStaticParams`](/docs/app/api-reference/functions/generate-static-params) は `getStaticPaths` と同様に動作しますが、ルートパラメータを返すための簡素化された API を持ち、[レイアウト](/docs/app/building-your-application/routing/layouts-and-templates) 内で使用できます。`generateStaticParams` の戻り値の形状は、ネストされた `param` オブジェクトの配列ではなく、解決されたパスの文字列の配列です。
```jsx title="app/posts/[id]/page.js"
// `app` ディレクトリ
@@ -850,7 +850,7 @@ export default async function Post({ params }) {
}
```
-`app` ディレクトリの新しいモデルにおいて、`generateStaticParams` という名前を使用することは `getStaticPaths` よりも適切です。`get` プレフィックスは、`getStaticProps` や `getServerSideProps` がもはや必要ないため、より説明的な `generate` に置き換えられています。`Paths` サフィックスは、複数の動的セグメントを持つネストされたルーティングに対してより適切な `Params` に置き換えられています。
+`app` ディレクトリの新しいモデルには `generateStaticParams` という名前が `getStaticPaths` よりも適しています。`get` プレフィックスは、`getStaticProps` や `getServerSideProps` がもはや必要ないため、より説明的な `generate` に置き換えられました。`Paths` サフィックスは `Params` に置き換えられ、複数の動的セグメントを持つネストされたルーティングにより適しています。
---
@@ -877,12 +877,12 @@ export default function Post({ post }) {
}
```
-`app` ディレクトリでは、[`config.dynamicParams` プロパティ](/docs/app/api-reference/file-conventions/route-segment-config#dynamicparams) が [`generateStaticParams`](/docs/app/api-reference/functions/generate-static-params) の外でのパラメータの処理方法を制御します：
+`app` ディレクトリでは、[`config.dynamicParams` プロパティ](/docs/app/api-reference/file-conventions/route-segment-config#dynamicparams) が [`generateStaticParams`](/docs/app/api-reference/functions/generate-static-params) の外部でのパラメータの処理方法を制御します：
- **`true`**: （デフォルト）`generateStaticParams` に含まれていない動的セグメントはオンデマンドで生成されます。
- **`false`**: `generateStaticParams` に含まれていない動的セグメントは 404 を返します。
-これは `pages` ディレクトリの `getStaticPaths` の `fallback: true | false | 'blocking'` オプションを置き換えます。`dynamicParams` に `fallback: 'blocking'` オプションは含まれていません。ストリーミングでは `'blocking'` と `true` の違いはわずかです。
+これは `pages` ディレクトリの `getStaticPaths` の `fallback: true | false | 'blocking'` オプションを置き換えます。`dynamicParams` には `fallback: 'blocking'` オプションは含まれていません。`'blocking'` と `true` の違いはストリーミングではわずかです。
```jsx title="app/posts/[id]/page.js"
// `app` ディレクトリ
@@ -906,7 +906,7 @@ export default async function Post({ params }) {
[`dynamicParams`](/docs/app/api-reference/file-conventions/route-segment-config#dynamicparams) が `true`（デフォルト）に設定されている場合、生成されていないルートセグメントがリクエストされると、サーバーレンダリングされてキャッシュされます。
-#### インクリメンタル静的再生成 (`getStaticProps` with `revalidate`) {#incremental-static-regeneration-getstaticprops-with-revalidate}
+#### インクリメンタル静的再生成 (`getStaticProps` と `revalidate`) {#incremental-static-regeneration-getstaticprops-with-revalidate}
`pages` ディレクトリでは、`getStaticProps` 関数を使用して、一定の時間が経過した後にページを自動的に再生成するための `revalidate` フィールドを追加できます。
@@ -932,7 +932,7 @@ export default function Index({ posts }) {
}
```
-`app` ディレクトリでは、[`fetch()`](/docs/app/api-reference/functions/fetch) を使用したデータフェッチで `revalidate` を使用でき、指定された秒数の間リクエストをキャッシュします。
+`app` ディレクトリでは、[`fetch()`](/docs/app/api-reference/functions/fetch) を使用したデータ取得で `revalidate` を使用でき、指定された秒数の間リクエストをキャッシュします。
```jsx title="app/page.js"
// `app` ディレクトリ
@@ -974,11 +974,11 @@ export async function GET(request) {}
-> **Good to know**: 以前にクライアントから外部 API を呼び出すために API ルートを使用していた場合、代わりに [Server Components](/docs/app/building-your-application/rendering/server-components) を使用してデータを安全にフェッチできます。[データフェッチ](/docs/app/building-your-application/data-fetching/fetching) について詳しく学びましょう。
+> **Good to know**: 以前にクライアントから外部 API を呼び出すために API ルートを使用していた場合は、代わりに [Server Components](/docs/app/building-your-application/rendering/server-components) を使用してデータを安全に取得できます。[データ取得](/docs/app/building-your-application/data-fetching/fetching) について詳しく学びましょう。
#### シングルページアプリケーション {#single-page-applications}
-同時にシングルページアプリケーション（SPA）から Next.js に移行する場合は、[ドキュメント](/docs/app/guides/single-page-applications) を参照して詳細を学びましょう。
+同時にシングルページアプリケーション（SPA）から Next.js に移行する場合は、[ドキュメント](/docs/app/guides/single-page-applications)を参照して詳細を学びましょう。
### ステップ 7: スタイリング {#step-7-styling}
@@ -987,13 +987,13 @@ export async function GET(request) {}
- [CSS Modules](/docs/app/building-your-application/styling/css#css-modules)
- [Tailwind CSS](/docs/app/building-your-application/styling/tailwind-css)
- [グローバルスタイル](/docs/app/building-your-application/styling/css#global-styles)
-- [CSS-in-JS](/docs/app/building-your-application/styling/css-in-js)
+- [CSS-in-JS](/docs/app/guides/css-in-js)
- [外部スタイルシート](/docs/app/building-your-application/styling/css#external-stylesheets)
-- [Sass](/docs/app/building-your-application/styling/sass)
+- [Sass](/docs/app/guides/sass)
#### Tailwind CSS {#tailwind-css}
-Tailwind CSS を使用している場合、`tailwind.config.js` ファイルに `app` ディレクトリを追加する必要があります：
+Tailwind CSS を使用している場合は、`tailwind.config.js` ファイルに `app` ディレクトリを追加する必要があります：
```js title="tailwind.config.js"
module.exports = {
@@ -1023,7 +1023,7 @@ export default function RootLayout({ children }) {
## App Router と Pages Router の併用 {#using-app-router-together-with-pages-router}
-異なる Next.js ルーターによって提供されるルート間をナビゲートする際には、ハードナビゲーションが発生します。`next/link` を使用した自動リンクプリフェッチは、ルーター間でプリフェッチしません。
+異なる Next.js ルーターによって提供されるルート間をナビゲートする際には、ハードナビゲーションが発生します。`next/link` を使用した自動リンクプリフェッチは、ルーター間でプリフェッチを行いません。
代わりに、App Router と Pages Router 間のナビゲーションを最適化して、プリフェッチされた高速なページ遷移を維持できます。[詳細はこちら](https://vercel.com/guides/optimizing-hard-navigations)。
diff --git a/docs/01-app/02-guides/migrating/from-create-react-app.mdx b/docs/01-app/02-guides/migrating/from-create-react-app.mdx
index 5c3415e6..f8d149d4 100644
--- a/docs/01-app/02-guides/migrating/from-create-react-app.mdx
+++ b/docs/01-app/02-guides/migrating/from-create-react-app.mdx
@@ -10,46 +10,46 @@ description: '既存の React アプリケーションを Create React App か
Create React App から Next.js に移行したい理由はいくつかあります：
-### 初期ページ読み込み時間の遅さ {#slow-initial-page-loading-time}
+### 初期ページの読み込み時間が遅い {#slow-initial-page-loading-time}
-Create React App は純粋にクライアントサイドの React を使用しています。クライアントサイドのみのアプリケーション、別名 [シングルページアプリケーション (SPA)](/docs/app/guides/single-page-applications) は、初期ページ読み込み時間が遅くなることがよくあります。これは以下の理由によります：
+Create React App は純粋にクライアントサイドの React を使用しています。クライアントサイドのみのアプリケーション、別名 [シングルページアプリケーション (SPA)](/docs/app/guides/single-page-applications) は、初期ページの読み込み時間が遅くなることがよくあります。これは以下の理由によります：
-1. ブラウザは、React コードとアプリケーション全体のバンドルがダウンロードされて実行されるまで待つ必要があります。
-2. 新しい機能や依存関係を追加するたびにアプリケーションコードが増加します。
+1. ブラウザは、React コードとアプリケーション全体のバンドルがダウンロードされて実行されるのを待たなければならず、その後にコードがデータをロードするためのリクエストを送信できるようになります。
+2. 新しい機能や依存関係を追加するたびに、アプリケーションコードが増加します。
### 自動コード分割がない {#no-automatic-code-splitting}
-前述の読み込み時間の遅さの問題は、コード分割である程度緩和できます。しかし、手動でコード分割を試みると、ネットワークウォーターフォールを引き起こす可能性があります。Next.js は、自動コード分割と tree-shaking をルーターとビルドパイプラインに組み込んでいます。
+前述の読み込み時間の遅さの問題は、コード分割である程度緩和できます。しかし、手動でコード分割を試みると、ネットワークのウォーターフォールを意図せずに引き起こす可能性があります。Next.js は、自動コード分割と tree-shaking をルーターとビルドパイプラインに組み込んでいます。
-### ネットワークウォーターフォール {#network-waterfalls}
+### ネットワークのウォーターフォール {#network-waterfalls}
-パフォーマンスが悪化する一般的な原因は、データを取得するためにクライアントとサーバー間で順次リクエストを行うことです。[SPA](/docs/app/guides/single-page-applications) でのデータ取得のパターンの1つは、プレースホルダーをレンダリングし、コンポーネントがマウントされた後にデータを取得することです。残念ながら、子コンポーネントは親が自身のデータを読み込んだ後でしかデータを取得できないため、リクエストの「ウォーターフォール」が発生します。
+パフォーマンスが悪化する一般的な原因は、アプリケーションがデータを取得するためにクライアントとサーバー間で順次リクエストを行うことです。[SPA](/docs/app/guides/single-page-applications) でのデータ取得のパターンの1つは、プレースホルダーをレンダリングし、コンポーネントがマウントされた後にデータを取得することです。残念ながら、子コンポーネントは親が自身のデータを読み込むのを完了した後でしかデータを取得し始めることができず、リクエストの「ウォーターフォール」を引き起こします。
Next.js ではクライアントサイドのデータ取得もサポートされていますが、データ取得をサーバーに移動することもできます。これにより、クライアントとサーバー間のウォーターフォールが完全に排除されることがよくあります。
### 高速で意図的な読み込み状態 {#fast-and-intentional-loading-states}
-[React Suspense を通じたストリーミング](/docs/app/building-your-application/routing/loading-ui-and-streaming#streaming-with-suspense) の組み込みサポートにより、ネットワークウォーターフォールを作成せずに、UI のどの部分を最初にどの順序で読み込むかを定義できます。
+[React Suspense を通じたストリーミング](/docs/app/building-your-application/routing/loading-ui-and-streaming#streaming-with-suspense) の組み込みサポートにより、ネットワークのウォーターフォールを作成せずに、UI のどの部分を最初にどの順序で読み込むかを定義できます。
これにより、ページの読み込みが速くなり、[レイアウトシフト](https://vercel.com/blog/how-core-web-vitals-affect-seo)を排除できます。
### データ取得戦略の選択 {#choose-the-data-fetching-strategy}
-必要に応じて、Next.js ではページまたはコンポーネントレベルでデータ取得戦略を選択できます。たとえば、CMS からデータを取得し、ビルド時（SSG）にブログ投稿をレンダリングして高速な読み込み速度を実現したり、必要に応じてリクエスト時（SSR）にデータを取得したりできます。
+必要に応じて、Next.js ではページまたはコンポーネントレベルでデータ取得戦略を選択できます。たとえば、CMS からデータを取得し、ブログ投稿をビルド時（SSG）にレンダリングして高速な読み込み速度を実現したり、必要に応じてリクエスト時（SSR）にデータを取得したりできます。
### ミドルウェア {#middleware}
-[Next.js ミドルウェア](/docs/app/building-your-application/routing/middleware) を使用すると、リクエストが完了する前にサーバー上でコードを実行できます。たとえば、認証が必要なページのミドルウェアでユーザーをログインページにリダイレクトすることで、未認証コンテンツのフラッシュを回避できます。また、A/B テスト、実験、[国際化](/docs/app/building-your-application/routing/internationalization) などの機能にも使用できます。
+[Next.js ミドルウェア](/docs/app/building-your-application/routing/middleware) を使用すると、リクエストが完了する前にサーバー上でコードを実行できます。たとえば、認証が必要なページのミドルウェアでユーザーをログインページにリダイレクトすることで、認証されていないコンテンツのフラッシュを回避できます。また、A/B テスト、実験、[国際化](/docs/app/building-your-application/routing/internationalization) などの機能にも使用できます。
### 組み込みの最適化 {#built-in-optimizations}
-[画像](/docs/app/building-your-application/optimizing/images)、[フォント](/docs/app/building-your-application/optimizing/fonts)、および[サードパーティスクリプト](/docs/app/building-your-application/optimizing/scripts) は、アプリケーションのパフォーマンスに大きな影響を与えることがよくあります。Next.js には、これらを自動的に最適化するための専用コンポーネントと API が含まれています。
+[画像](/docs/app/building-your-application/optimizing/images)、[フォント](/docs/app/building-your-application/optimizing/fonts)、および[サードパーティのスクリプト](/docs/app/guides/scripts) は、アプリケーションのパフォーマンスに大きな影響を与えることがよくあります。Next.js には、それらを自動的に最適化するための専門のコンポーネントと API が含まれています。
## 移行手順 {#migration-steps}
私たちの目標は、できるだけ早く動作する Next.js アプリケーションを作成し、その後で Next.js の機能を段階的に採用できるようにすることです。まず、アプリケーションを純粋なクライアントサイドアプリケーション（[SPA](/docs/app/guides/single-page-applications)）として扱い、既存のルーターをすぐに置き換えないようにします。これにより、複雑さとマージの競合が軽減されます。
-> **注意**: `package.json` のカスタム `homepage` フィールド、カスタムサービスワーカー、特定の Babel/webpack 調整など、CRA の高度な設定を使用している場合は、Next.js でこれらの機能を再現または適応するためのヒントについて、このガイドの最後にある **追加の考慮事項** セクションを参照してください。
+> **注意**: `package.json` のカスタム `homepage` フィールド、カスタムサービスワーカー、特定の Babel/webpack の調整など、CRA の高度な設定を使用している場合は、このガイドの最後にある **追加の考慮事項** セクションを参照して、これらの機能を Next.js で再現または適応するためのヒントを確認してください。
### ステップ 1: Next.js の依存関係をインストールする {#step-1-install-the-next-js-dependency}
@@ -61,7 +61,7 @@ npm install next@latest
### ステップ 2: Next.js の設定ファイルを作成する {#step-2-create-the-next-js-configuration-file}
-プロジェクトの root に `next.config.ts` を作成します（`package.json` と同じレベル）。このファイルには、[Next.js の設定オプション](/docs/app/api-reference/config/next-config-js)が含まれます。
+プロジェクトの root（`package.json` と同じレベル）に `next.config.ts` を作成します。このファイルには [Next.js の設定オプション](/docs/app/api-reference/config/next-config-js) が含まれます。
```js title="next.config.ts"
import type { NextConfig } from 'next'
@@ -74,15 +74,15 @@ const nextConfig: NextConfig = {
export default nextConfig
```
-> **注意**: `output: 'export'` を使用すると、静的エクスポートを行っていることを意味します。サーバーサイドの機能（SSR や API など）にはアクセスできません。Next.js のサーバー機能を活用するには、この行を削除できます。
+> **注意**: `output: 'export'` を使用すると、静的エクスポートを行っていることになります。サーバーサイドの機能（SSR や API など）にはアクセスできません。この行を削除すると、Next.js のサーバー機能を活用できます。
-### ステップ 3: Root レイアウトを作成する {#step-3-create-the-root-layout}
+### ステップ 3: root レイアウトを作成する {#step-3-create-the-root-layout}
Next.js [App Router](/docs/app) アプリケーションには、すべてのページをラップする [root レイアウト](/docs/app/building-your-application/routing/layouts-and-templates#root-layout-required) ファイルが必要です。これは、[React Server Component](/docs/app/building-your-application/rendering/server-components) です。
CRA アプリケーションでの root レイアウトファイルに最も近いものは、``、``、および `` タグを含む `public/index.html` です。
-1. `src` ディレクトリ内に新しい `app` ディレクトリを作成します（または、`app` を root に配置する場合はプロジェクトの root に作成します）。
+1. `src` フォルダ内に新しい `app` ディレクトリを作成します（または、`app` を root に配置する場合はプロジェクトの root に作成します）。
2. `app` ディレクトリ内に `layout.tsx`（または `layout.js`）ファイルを作成します：
@@ -163,7 +163,7 @@ export default function RootLayout({ children }) {
-> **Good to know**: Next.js はデフォルトで CRA の `public/manifest.json`、追加のアイコン、および[テスト設定](/docs/app/building-your-application/testing)を無視します。これらが必要な場合、Next.js は [Metadata API](/docs/app/building-your-application/optimizing/metadata) と[テスト](/docs/app/building-your-application/testing)のセットアップをサポートしています。
+> **Good to know**: Next.js はデフォルトで CRA の `public/manifest.json`、追加のアイコン、および[テスト設定](/docs/app/guides/testing)を無視します。これらが必要な場合、Next.js には [Metadata API](/docs/app/building-your-application/optimizing/metadata) と[テスト](/docs/app/guides/testing)のセットアップがサポートされています。
### ステップ 4: メタデータ {#step-4-metadata}
@@ -216,7 +216,7 @@ export default function RootLayout({ children }) {
-`favicon.ico`、`icon.png`、`robots.txt` などの[メタデータファイル](/docs/app/building-your-application/optimizing/metadata#file-based-metadata)は、`app` ディレクトリのトップレベルに配置されている限り、アプリケーションの `` タグに自動的に追加されます。すべての[サポートされているファイル](/docs/app/building-your-application/optimizing/metadata#file-based-metadata)を `app` ディレクトリに移動した後、それらの `` タグを安全に削除できます：
+`favicon.ico`、`icon.png`、`robots.txt` などの[メタデータファイル](/docs/app/building-your-application/optimizing/metadata#file-based-metadata)は、`app` ディレクトリのトップレベルに配置されている限り、自動的にアプリケーションの `` タグに追加されます。[すべてのサポートされているファイル](/docs/app/building-your-application/optimizing/metadata#file-based-metadata)を `app` ディレクトリに移動した後、それらの `` タグを安全に削除できます：
@@ -314,11 +314,11 @@ export default function RootLayout({ children }) {
-上記の変更により、`index.html` にすべてを宣言する方法から、フレームワークに組み込まれた Next.js の規約ベースのアプローチ（[Metadata API](/docs/app/building-your-application/optimizing/metadata)）を使用する方法に移行しました。このアプローチにより、ページの SEO とウェブの共有性をより簡単に向上させることができます。
+上記の変更により、`index.html` にすべてを宣言するのではなく、Next.js のフレームワークに組み込まれた規約ベースのアプローチを使用するようにシフトしました（[Metadata API](/docs/app/building-your-application/optimizing/metadata)）。このアプローチにより、ページの SEO とウェブの共有性をより簡単に向上させることができます。
### ステップ 5: スタイル {#step-5-styles}
-CRA と同様に、Next.js は [CSS Modules](/docs/app/building-your-application/styling/css#css-modules) を標準でサポートしています。また、[グローバル CSS インポート](/docs/app/building-your-application/styling/css#global-styles)もサポートしています。
+CRA と同様に、Next.js は [CSS Modules](/docs/app/building-your-application/styling/css#css-modules) をサポートしています。また、[グローバル CSS インポート](/docs/app/building-your-application/styling/css#global-styles) もサポートしています。
グローバル CSS ファイルがある場合は、`app/layout.tsx` にインポートします：
@@ -357,7 +357,7 @@ Tailwind CSS を使用している場合は、[インストールドキュメン
Create React App は `src/index.tsx`（または `index.js`）をエントリーポイントとして使用します。Next.js（App Router）では、`app` ディレクトリ内の各フォルダがルートに対応し、各フォルダには `page.tsx` が必要です。
-現在のところアプリを SPA として保持し、**すべて**のルートをインターセプトしたいので、[optional catch-all route](/docs/app/building-your-application/routing/dynamic-routes#optional-catch-all-segments) を使用します。
+アプリを SPA として保持し、**すべて**のルートをインターセプトしたいので、[optional catch-all route](/docs/app/building-your-application/routing/dynamic-routes#optional-catch-all-segments) を使用します。
1. **`app` 内に `[[...slug]]` ディレクトリを作成します。**
@@ -368,7 +368,7 @@ app
┣ layout.tsx
```
-2. **`page.tsx` に次の内容を追加します**：
+2. **`page.tsx` に以下を追加します**：
@@ -399,11 +399,11 @@ export default function Page() {
-これは Next.js に空のスラッグ（`/`）のための単一のルートを生成するよう指示し、**すべて**のルートを同じページにマッピングします。このページは[Server Component](/docs/app/building-your-application/rendering/server-components)であり、静的 HTML にプリレンダリングされます。
+これは Next.js に空のスラッグ（`/`）のための単一のルートを生成するよう指示し、**すべて**のルートを同じページにマッピングします。このページは [Server Component](/docs/app/building-your-application/rendering/server-components) であり、静的 HTML にプリレンダリングされます。
### ステップ 7: クライアント専用のエントリーポイントを追加する {#step-7-add-a-client-only-entrypoint}
-次に、CRA の root App コンポーネントを[Client Component](/docs/app/building-your-application/rendering/client-components)内に埋め込み、すべてのロジックをクライアントサイドに残します。Next.js を初めて使用する場合、クライアントコンポーネント（デフォルトでは）もサーバーでプリレンダリングされることを知っておく価値があります。クライアントサイドの JavaScript を実行する追加の機能を持っていると考えることができます。
+次に、CRA の root App コンポーネントを [Client Component](/docs/app/building-your-application/rendering/client-components) 内に埋め込み、すべてのロジックをクライアントサイドに保持します。Next.js を初めて使用する場合、クライアントコンポーネント（デフォルトでは）もサーバーでプリレンダリングされることを知っておく価値があります。クライアントサイドの JavaScript を実行する追加の機能を持っていると考えることができます。
`app/[[...slug]]/` に `client.tsx`（または `client.js`）を作成します：
@@ -440,7 +440,7 @@ export function ClientOnly() {
-- `'use client'` ディレクティブは、このファイルを**クライアントコンポーネント**にします。
+- `'use client'` ディレクティブは、このファイルを **Client Component** にします。
- `dynamic` インポートと `ssr: false` は `` コンポーネント](/docs/app/api-reference/components/image)で直接使用することができ、または既存の `![]()
` タグでオブジェクトの `src` プロパティを使用することができます。
+Next.js では、静的画像インポートはオブジェクトを返します。このオブジェクトは Next.js の [`` コンポーネント](/docs/app/api-reference/components/image) で直接使用することができ、または既存の `![]()
` タグでオブジェクトの `src` プロパティを使用することができます。
-`` コンポーネントには[自動画像最適化](/docs/app/building-your-application/optimizing/images)の追加の利点があります。`` コンポーネントは、画像の寸法に基づいて結果の `![]()
` の `width` と `height` 属性を自動的に設定します。これにより、画像が読み込まれるときのレイアウトシフトを防ぎます。ただし、アプリに寸法の一方のみがスタイルされ、他方が `auto` にスタイルされていない画像が含まれている場合、問題が発生する可能性があります。`auto` にスタイルされていない場合、寸法は `![]()
` の寸法属性の値にデフォルト設定され、画像が歪んで表示される可能性があります。
+`` コンポーネントには[自動画像最適化](/docs/app/building-your-application/optimizing/images)の利点があります。`` コンポーネントは、画像の寸法に基づいて結果の `![]()
` の `width` と `height` 属性を自動的に設定します。これにより、画像が読み込まれる際のレイアウトシフトを防ぎます。ただし、アプリに寸法の一方のみがスタイル設定され、他方が `auto` にスタイル設定されていない画像が含まれている場合、問題が発生する可能性があります。`auto` にスタイル設定されていない場合、寸法は `![]()
` の寸法属性の値にデフォルト設定され、画像が歪んで表示される可能性があります。
-`![]()
` タグを保持することで、アプリケーションの変更量を減らし、上記の問題を防ぐことができます。その後、[ローダーを設定](/docs/app/building-your-application/optimizing/images#loaders)するか、画像を自動的に最適化するデフォルトの Next.js サーバーに移行することで、画像を最適化するために `` コンポーネントに移行することができます。
+`![]()
` タグを保持することで、アプリケーションの変更を減らし、上記の問題を防ぐことができます。その後、[ローダーを設定](/docs/app/building-your-application/optimizing/images#loaders)して画像を最適化するために `` コンポーネントに移行するか、自動画像最適化を備えたデフォルトの Next.js サーバーに移行することができます。
**`/public` からインポートされた画像の絶対インポートパスを相対インポートに変換します：**
```tsx
-// 変更前
+// Before
import logo from '/logo.png'
-// 変更後
+// After
import logo from '../public/logo.png'
```
**画像オブジェクト全体ではなく、画像の `src` プロパティを `![]()
` タグに渡します：**
```tsx
-// 変更前
+// Before
-// 変更後
+// After
```
または、ファイル名に基づいて画像アセットの公開 URL を参照することもできます。たとえば、`public/logo.png` はアプリケーションの `/logo.png` で画像を提供し、これが `src` 値になります。
-> **警告**: TypeScript を使用している場合、`src` プロパティにアクセスするときに型エラーが発生する可能性があります。これを修正するには、`tsconfig.json` ファイルの [`include` 配列](https://www.typescriptlang.org/tsconfig#include)に `next-env.d.ts` を追加する必要があります。Next.js は、ステップ 9 でアプリケーションを実行するときにこのファイルを自動的に生成します。
+> **警告**: TypeScript を使用している場合、`src` プロパティにアクセスするときに型エラーが発生する可能性があります。これを修正するには、`tsconfig.json` ファイルの [`include` 配列](https://www.typescriptlang.org/tsconfig#include) に `next-env.d.ts` を追加する必要があります。Next.js は、ステップ 9 でアプリケーションを実行するときにこのファイルを自動的に生成します。
### ステップ 9: 環境変数を移行する {#step-9-migrate-environment-variables}
-Next.js は CRA と同様に[環境変数](/docs/app/building-your-application/configuring/environment-variables)をサポートしていますが、ブラウザで公開したい変数には `NEXT_PUBLIC_` プレフィックスが**必要**です。
+Next.js は CRA と同様に[環境変数](/docs/app/guides/environment-variables)をサポートしていますが、ブラウザで公開したい変数には `NEXT_PUBLIC_` プレフィックスが**必要**です。
主な違いは、クライアントサイドで環境変数を公開するために使用されるプレフィックスです。`REACT_APP_` プレフィックスを持つすべての環境変数を `NEXT_PUBLIC_` に変更します。
@@ -568,7 +568,7 @@ Create React App に特有のアーティファクトを削除できます：
### CRA でカスタム `homepage` を使用する {#using-a-custom-homepage-in-cra}
-CRA の `package.json` で `homepage` フィールドを使用してアプリを特定のサブパスで提供していた場合、Next.js の `next.config.ts` で [`basePath` 設定](/docs/app/api-reference/config/next-config-js/basePath)を使用してそれを再現できます：
+CRA の `package.json` で `homepage` フィールドを使用してアプリを特定のサブパスで提供していた場合、Next.js の `next.config.ts` で [`basePath` 設定](/docs/app/api-reference/config/next-config-js/basePath) を使用してそれを再現できます：
```ts title="next.config.ts"
import { NextConfig } from 'next'
@@ -583,11 +583,11 @@ export default nextConfig
### カスタム `Service Worker` の処理 {#handling-a-custom-service-worker}
-CRA のサービスワーカー（例：`create-react-app` の `serviceWorker.js`）を使用していた場合、Next.js で[プログレッシブウェブアプリケーション (PWA)](/docs/app/building-your-application/configuring/progressive-web-apps)を作成する方法を学ぶことができます。
+CRA のサービスワーカー（例：`create-react-app` の `serviceWorker.js`）を使用していた場合、Next.js で[プログレッシブウェブアプリケーション (PWA)](/docs/app/guides/progressive-web-apps) を作成する方法を学ぶことができます。
### API リクエストのプロキシ {#proxying-api-requests}
-CRA アプリで `package.json` の `proxy` フィールドを使用してバックエンドサーバーへのリクエストを転送していた場合、`next.config.ts` で [Next.js のリライト](/docs/app/api-reference/config/next-config-js/rewrites)を使用してこれを再現できます：
+CRA アプリで `package.json` の `proxy` フィールドを使用してバックエンドサーバーへのリクエストを転送していた場合、`next.config.ts` で [Next.js のリライト](/docs/app/api-reference/config/next-config-js/rewrites) を使用してこれを再現できます：
```ts title="next.config.ts"
import { NextConfig } from 'next'
@@ -635,25 +635,25 @@ Next.js は `tsconfig.json` がある場合、自動的に TypeScript をセッ
## バンドラーの互換性 {#bundler-compatibility}
-Create React App と Next.js はどちらもデフォルトで webpack をバンドリングに使用します。Next.js はまた、ローカル開発をより高速にするための [Turbopack](/docs/app/api-reference/config/next-config-js/turbopack) を提供しています：
+Create React App と Next.js はどちらもデフォルトで webpack をバンドリングに使用します。Next.js はまた、ローカル開発を高速化するための [Turbopack](/docs/app/api-reference/config/next-config-js/turbopack) を提供しています：
```bash
next dev --turbopack
```
-CRA から高度な webpack 設定を移行する必要がある場合は、[カスタム webpack 設定](/docs/app/api-reference/config/next-config-js/webpack)を提供することもできます。
+CRA から高度な webpack 設定を移行する必要がある場合は、[カスタム webpack 設定](/docs/app/api-reference/config/next-config-js/webpack) を提供することもできます。
## 次のステップ {#next-steps}
すべてが正常に動作した場合、現在はシングルページアプリケーションとして動作する Next.js アプリケーションがあります。まだサーバーサイドレンダリングやファイルベースのルーティングなどの Next.js の機能を活用していませんが、これらを段階的に行うことができます：
-- [Next.js App Router](/docs/app/building-your-application/routing) に**React Router から移行**して：
+- [Next.js App Router](/docs/app/building-your-application/routing) に**React Router から移行**して、以下を実現します：
- 自動コード分割
- [ストリーミングサーバーレンダリング](/docs/app/building-your-application/routing/loading-ui-and-streaming)
- [React Server Components](/docs/app/building-your-application/rendering/server-components)
-- [`` コンポーネント](/docs/app/building-your-application/optimizing/images)で**画像を最適化**
-- [`next/font`](/docs/app/building-your-application/optimizing/fonts)で**フォントを最適化**
-- [`
+```
+
+または、`dangerouslySetInnerHTML`プロパティを使用することもできます：
+
+```jsx
+
+```
+
+> **警告**: インラインスクリプトには`id`プロパティを割り当てる必要があり、Next.jsがスクリプトを追跡し、最適化するために必要です。
+
+### 追加コードの実行 {#executing-additional-code}
+
+イベントハンドラは、特定のイベントが発生した後に追加のコードを実行するためにScriptコンポーネントで使用できます：
+
+- `onLoad`: スクリプトの読み込みが完了した後にコードを実行します。
+- `onReady`: スクリプトの読み込みが完了し、コンポーネントがマウントされるたびにコードを実行します。
+- `onError`: スクリプトの読み込みに失敗した場合にコードを実行します。
+
+
+
+これらのハンドラは、`next/script`がインポートされ、`"use client"`がコードの最初の行として定義されている[Client Component](/docs/app/building-your-application/rendering/client-components)内で使用される場合にのみ動作します：
+
+
+
+
+```tsx title="app/page.tsx" switcher
+'use client'
+
+import Script from 'next/script'
+
+export default function Page() {
+ return (
+ <>
+
-```
-
-または `dangerouslySetInnerHTML` プロパティを使用して：
-
-```jsx
-
-```
-
-> **警告**: Next.js がスクリプトを追跡し最適化するために、インラインスクリプトには `id` プロパティを割り当てる必要があります。
-
-### 追加コードの実行 {#executing-additional-code}
-
-イベントハンドラを使用して、特定のイベントが発生した後に追加のコードを実行することができます：
-
-- `onLoad`: スクリプトの読み込みが完了した後にコードを実行します。
-- `onReady`: スクリプトの読み込みが完了し、コンポーネントがマウントされるたびにコードを実行します。
-- `onError`: スクリプトの読み込みに失敗した場合にコードを実行します。
-
-
-
-これらのハンドラは、`next/script` がインポートされ、[Client Component](/docs/app/building-your-application/rendering/client-components) 内で使用される場合にのみ機能します。この場合、コードの最初の行として `"use client"` が定義されます：
-
-
-
-
-```tsx title="app/page.tsx" switcher
-'use client'
-
-import Script from 'next/script'
-
-export default function Page() {
- return (
- <>
-