翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amplify ホスティングのデプロイ仕様
Amplify ホスティングのデプロイ仕様は、Amplify ホスティングへのデプロイを容易にするディレクトリ構造を定義するファイルシステムベースの仕様です。フレームワークは、ビルドコマンドの出力としてこの予想されるディレクトリ構造を生成し、フレームワークが Amplify ホスティングのサービスプリミティブタイプを利用できるようにします。Amplify ホスティングは、デプロイバンドルの構造を理解し、それに応じてデプロイします。
Amplify がデプロイバンドルについて想定するフォルダ構造の例を次に示します。大まかに言うと、static という名前のフォルダ、compute という名前のフォルダ、deploy-manifest.json という名前のデプロイマニフェストファイルがあります。
.amplify-hosting/ ├── compute/ │ └── default/ │ ├── chunks/ │ │ └── app/ │ │ ├── _nuxt/ │ │ │ ├── index-xxx.mjs │ │ │ └── index-styles.xxx.js │ │ └── server.mjs │ ├── node_modules/ │ └── server.js ├── static/ │ ├── css/ │ │ └── nuxt-google-fonts.css │ ├── fonts/ │ │ ├── font.woff2 │ ├── _nuxt/ │ │ ├── builds/ │ │ │ └── latest.json │ │ └── entry.xxx.js │ ├── favicon.ico │ └── robots.txt └── deploy-manifest.json
Amplify SSR プリミティブタイプのサポート
Amplify ホスティングのデプロイ仕様では、以下のプリミティブタイプに密接にマッピングされる契約を定義します。
- 静的アセット
-
静的ファイルをホストする機能をフレームワークに提供します。
- コンピューティング
-
ポート 3000 で Node.js HTTP サーバーを実行する機能をフレームワークに提供します。
- イメージの最適化
-
実行時に画像を最適化するサービスをフレームワークに提供します。
- ルーティングルール
-
着信リクエストのパスを特定のターゲットにマッピングするメカニズムをフレームワークに提供します。
.amplify-hosting/static ディレクトリ
アプリケーション URL から提供される、パブリックにアクセス可能なすべての静的ファイルを .amplify-hosting/static ディレクトリに格納する必要があります。このディレクトリ内のファイルは、静的アセットプリミティブタイプを介して提供されます。
静的ファイルには、内容、ファイル名、または拡張子の変更なしで、アプリケーション URL のルート (/) でアクセスできます。さらに、サブディレクトリは URL 構造内に保持され、ファイル名の前に表示されます。一例として、.amplify-hosting/static/favicon.ico は https://myAppId.amplify-hostingapp.com/favicon.ico から提供され、.amplify-hosting/static/_nuxt/main.js は
https://myAppId.amplify-hostingapp.com/_nuxt/main.js から提供されます
フレームワークがアプリケーションのベースパスを変更する機能をサポートしている場合は、.amplify-hosting/static ディレクトリ内の静的アセットへのベースパスを先頭に付加する必要があります。例えば、ベースパスが /folder1/folder2 である場合、main.css という静的アセットのビルド出力は .amplify-hosting/static/folder1/folder2/main.css になります。
.amplify-hosting/compute ディレクトリ
単一のコンピューティングリソースは、.amplify-hosting/compute ディレクトリ内に含まれる defaultという名前の単一のサブディレクトリによって表されます。パスは .amplify-hosting/compute/default です。このコンピューティングリソースは、Amplify ホスティングのコンピューティングプリミティブタイプにマッピングされます。
default サブディレクトリの内容は、次のルールに準拠する必要があります。
-
コンピューティングリソースへのエントリポイントとして機能するファイルは、
defaultサブディレクトリのルートに存在する必要があります。 -
エントリポイントファイルは Node.js モジュールでなければならず、ポート3000 でリッスンする HTTP サーバーを起動する必要があります。
-
他のファイルを
defaultサブディレクトリに格納し、エントリポイントファイルのコードからそれらのファイルを参照できます。 -
サブディレクトリの内容は自己完結型である必要があります。エントリポイントモジュール内のコードは、サブディレクトリの外部のモジュールを参照できません。フレームワークは任意の方法で HTTP サーバーをバンドルできることに留意してください。サブディレクトリ内から
node server.jsコマンド (ここでserver.js isはエントリファイルの名前) を使用してコンピューティングプロセスを開始できる場合、Amplify は、ディレクトリ構造がデプロイ仕様に準拠しているものとみなします。
Amplify ホスティングは、default サブディレクトリ内のすべてのファイルをバンドルし、プロビジョニングされたコンピューティングリソースにデプロイします。各コンピューティングリソースには、512 MB のエフェメラルストレージが割り当てられます。このストレージは実行インスタンス間では共有されませんが、同じ実行インスタンス内での後続の呼び出しの間では共有されます。実行インスタンスの実行時間は最大 15 分に制限されており、実行インスタンス内の唯一の書き込み可能なパスは /tmp ディレクトリです。各コンピューティングリソースバンドルの圧縮サイズは 220 MB を超えることはできません。例えば、.amplify/compute/default サブディレクトリは圧縮された際に 220 MB を超えることはできません。
.amplify-hosting/deploy-manifest.json ファイル
デプロイの設定の詳細とメタデータを保存するには deploy-manifest.json ファイルを使用します。deploy-manifest.json ファイルには少なくとも、version 属性、キャッチオールルートが指定された routes 属性、およびフレームワークメタデータが指定された framework 属性が含まれている必要があります。
次のオブジェクト定義は、デプロイマニフェストの設定を示しています。
type DeployManifest = { version: 1; routes: Route[]; computeResources?: ComputeResource[]; imageSettings?: ImageSettings; framework: FrameworkMetadata; };
次のトピックでは、デプロイマニフェストの各属性の詳細と使用法について説明します。
バージョン属性の使用
version 属性は、実装しようとしているデプロイ仕様のバージョンを定義します。現在、Amplify ホスティングのデプロイ仕様の唯一のバージョンはバージョン 1 です。次の JSON の例は、version 属性の使用法を示しています。
"version": 1
ルート属性の使用
routes 属性を使用すると、フレームワークは Amplify ホスティングルーティングルールのプリミティブタイプを活用できます。ルーティングルールは、着信リクエストのパスをデプロイバンドル内の特定のターゲットにルーティングするメカニズムを提供します。ルーティングルールは着信リクエストの宛先のみを決定し、リクエストが書き換えルールとリダイレクトルールによって変換された後に適用されます。Amplify ホスティングが書き換えとリダイレクトを処理する方法の詳細については、「リダイレクトを使用する」を参照してください。
ルーティングルールは、リクエストを書き換えたり、変換したりしません。着信リクエストがルートのパスパターンと一致する場合、リクエストはそのままルートのターゲットにルーティングされます。
routes 配列で指定されたルーティングルールは、次のルールに準拠する必要があります。
-
キャッチオールルートが指定されている必要があります。キャッチオールルートには、すべての着信リクエストに一致する
/*パターンがあります。 -
routes配列には最大 25 個の項目を含めることができます。 -
StaticルートまたはComputeルートのいずれかを指定する必要があります。 -
Staticルートを指定する場合は、.amplify-hosting/staticディレクトリが存在している必要があります。 -
Computeルートを指定する場合は、.amplify-hosting/computeディレクトリが存在している必要があります。 -
ImageOptimizationルートを指定する場合は、Computeルートも指定する必要があります。画像の最適化は純粋に静的なアプリケーションではまだサポートされていないため、これは必須です。
次のオブジェクト定義は、Route オブジェクトの設定を示しています。
type Route = { path: string; target: Target; fallback?: Target; }
次の表では、Route オブジェクトのプロパティについて説明します。
| キー | タイプ | 必須 | 説明 |
|---|---|---|---|
|
パス |
文字列 |
あり |
着信リクエストのパス (クエリ文字列を除く) に一致するパターンを定義します。 最大パス長は 255 文字です。 パスはスラッシュ パスには、[A-Z]、[a-z]、[0-9]、[ _-.*$/~"'@:+] の文字を使用できます。 パターンマッチングでは、次のワイルドカード文字のみがサポートされます:
|
|
target |
Target |
あり |
一致したリクエストのルーティング先となるターゲットを定義するオブジェクト。
|
|
fallback |
Target |
なし |
元のターゲットが 404 エラーを返した場合にフォールバックするターゲットを定義するオブジェクト。 指定したルートで |
次のオブジェクト定義は、Target オブジェクトの設定を示しています。
type Target = { kind: TargetKind; src?: string; cacheControl?: string; }
次の表では、Target オブジェクトのプロパティについて説明します。
| キー | タイプ | 必須 | 説明 |
|---|---|---|---|
|
kind |
Targetkind |
あり |
ターゲットのタイプを定義する |
|
src |
文字列 |
他のプリミティブ型にはいいえ |
プリミティブタイプの実行可能コードを含むデプロイバンドル内のサブディレクトリの名前を指定する文字列。コンピューティングプリミティブタイプに対してのみ有効で必須です。 値は、デプロイバンドルに存在するコンピューティングリソースの 1 つをポイントする必要があります。現在、このフィールドでサポートされている値は |
|
cacheControl |
文字列 |
なし |
応答に適用する Cache-Control ヘッダーの値を指定する文字列。静的型と ImageOptimizationプリミティブ型に対してのみ有効です。 指定された値は、カスタムヘッダーによってオーバーライドされます。Amplify ホスティングのカスタマーヘッダーの詳細については、「カスタムヘッダー」を参照してください。 注記この Cache-Control ヘッダーは、ステータスコードが 200 (OK) に設定されている正常なレスポンスにのみ適用されます。 |
次のオブジェクト定義は、TargetKind 列挙型の使用法を示しています。
enum TargetKind { Static = "Static", Compute = "Compute", ImageOptimization = "ImageOptimization" }
次のリストは、TargetKind 列挙型の有効な値を指定します。
- 静的
-
静的アセットプリミティブタイプにリクエストをルーティングします。
- コンピューティング
-
リクエストをコンピューティングプリミティブタイプにルーティングします。
- ImageOptimization
-
リクエストを画像最適化プリミティブタイプにルーティングします。
次の JSON の例は、複数のルーティングルールが指定された routes 属性の使用法を示しています。
"routes": [ { "path": "/_nuxt/image", "target": { "kind": "ImageOptimization", "cacheControl": "public, max-age=3600, immutable" } }, { "path": "/_nuxt/builds/meta/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/_nuxt/builds/*", "target": { "cacheControl": "public, max-age=1, immutable", "kind": "Static" } }, { "path": "/_nuxt/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } }, { "path": "/*", "target": { "kind": "Compute", "src": "default" } } ]
デプロイマニフェストでのルーティングルールの指定の詳細については、「ルーティングルールの設定に関するベストプラクティス」を参照してください。
computeResources 属性の使用
computeResources 属性により、フレームワークは、プロビジョニングされたコンピューティングリソースに関するメタデータを提供できるようになります。あらゆるコンピューティングリソースには、対応するルートが関連付けられている必要があります。
次のオブジェクト定義は、ComputeResource オブジェクトの使用法を示しています。
type ComputeResource = { name: string; runtime: ComputeRuntime; entrypoint: string; }; type ComputeRuntime = 'nodejs16.x' | 'nodejs18.x' | 'nodejs20.x';
次の表では、ComputeResource オブジェクトのプロパティについて説明します。
| キー | タイプ | 必須 | 説明 |
|---|---|---|---|
|
name |
文字列 |
あり |
コンピューティングリソースの名前を指定します。この名前は、 デプロイ仕様のバージョン 1 である場合、有効な値は |
|
ランタイム |
ComputeRuntime |
あり |
プロビジョニングされたコンピューティングリソースのランタイムを定義します。 有効な値は、 |
|
entrypoint |
文字列 |
あり |
指定されたコンピューティングリソースのためにコードが実行される開始ファイルの名前を指定します。このファイルは、コンピューティングリソースを表すサブディレクトリ内に存在している必要があります。 |
次のようなディレクトリ構造があるとします。
.amplify-hosting |---compute | |---default | |---index.js
computeResource 属性の JSON は次のようになります。
"computeResources": [ { "name": "default", "runtime": "nodejs16.x", "entrypoint": "index.js", } ]
imageSettings 属性の使用
imageSettings 属性を使用すると、フレームワークはイメージ最適化プリミティブタイプの動作をカスタマイズでき、実行時にイメージをオンデマンドで最適化できます。
次のオブジェクト定義は、ImageSettings オブジェクトの使用法を示しています。
type ImageSettings = { sizes: number[]; domains: string[]; remotePatterns: RemotePattern[]; formats: ImageFormat[]; minumumCacheTTL: number; dangerouslyAllowSVG: boolean; }; type ImageFormat = 'image/avif' | 'image/webp' | 'image/png' | 'image/jpeg';
次の表では、ImageSettings オブジェクトのプロパティについて説明します。
| キー | タイプ | 必須 | 説明 |
|---|---|---|---|
|
sizes |
Number[] |
あり |
サポートされている画像の幅の配列。 |
|
domains |
String[] |
あり |
画像の最適化を使用できる許可された外部ドメインの配列。デプロイドメインのみが画像の最適化を使用できるようにするには、配列を空のままにしておきます。 |
|
remotePatterns |
RemotePattern[] |
あり |
画像の最適化を使用できる許可された外部パターンの配列。ドメインに似ていますが、正規表現 (regex) によりさらに詳細なコントロールを提供します。 |
|
formats |
ImageFormat[] |
あり |
許可される出力画像形式の配列。 |
|
minimumCacheTTL |
数 |
あり |
最適化された画像のキャッシュ期間 (秒)。 |
|
dangerouslyAllowSVG |
ブール値 |
あり |
SVG 入力画像 URL を許可します。これは、セキュリティ上の理由からデフォルトでは無効になっています。 |
次のオブジェクト定義は、RemotePattern オブジェクトの使用法を示しています。
type RemotePattern = { protocol?: 'http' | 'https'; hostname: string; port?: string; pathname?: string; }
次の表では、RemotePattern オブジェクトのプロパティについて説明します。
| キー | タイプ | 必須 | 説明 |
|---|---|---|---|
|
protocol |
文字列 |
なし |
許可されるリモートパターンのプロトコル。 有効な値は |
|
hostname |
文字列 |
あり |
許可されるリモートパターンのホスト名。 リテラルまたはワイルドカードを指定できます。単一の「*」は単一のサブドメインに一致します。二重の「**」は任意の数のサブドメインに一致します。Amplify では、「**」のみが指定されるブランケットワイルドカードを使用できません。 |
|
port |
文字列 |
なし |
許可されるリモートパターンのポート。 |
|
pathname |
文字列 |
なし |
許可されるリモートパターンのパス名。 |
次の例は、imageSettings 属性を示しています。
"imageSettings": { "sizes": [ 100, 200 ], "domains": [ "example.com" ], "remotePatterns": [ { "protocol": "https", "hostname": "example.com", "port": "", "pathname": "/**", } ], "formats": [ "image/webp" ], "minumumCacheTTL": 60, "dangerouslyAllowSVG": false }
フレームワーク属性の使用
framework 属性を使用してフレームワークのメタデータを指定します。
次のオブジェクト定義は、FrameworkMetadata オブジェクトの設定を示しています。
type FrameworkMetadata = { name: string; version: string; }
次の表では、FrameworkMetadata オブジェクトのプロパティについて説明します。
| キー | タイプ | 必須 | 説明 |
|---|---|---|---|
|
name |
文字列 |
あり |
フレームワークの名前。 |
|
version |
文字列 |
あり |
フレームワークのバージョン。 有効なセマンティックバージョニング (semver) 文字列である必要があります。 |
ルーティングルールの設定に関するベストプラクティス
ルーティングルールは、着信リクエストのパスをデプロイバンドル内の特定のターゲットにルーティングするメカニズムを提供します。デプロイバンドルでは、フレームワークの作成者は、次のターゲットのいずれかにデプロイされるファイルをビルド出力に出力できます:
-
静的アセットのプリミティブタイプ – ファイルは
.amplify-hosting/staticディレクトリに含まれています。 -
コンピューティングプリミティブタイプ — ファイルは
.amplify-hosting/compute/defaultディレクトリに含まれています。
また、フレームワークの作成者は、デプロイマニフェストファイルでルーティングルールの配列も提供します。配列内の各ルールは、一致が見つかるまで、シーケンシャルトラバーサル順序で着信リクエストと照合されます。一致するルールがある場合、リクエストは一致ルールで指定されたターゲットにルーティングされます。オプションで、ルールごとにフォールバックターゲットを指定できます。元のターゲットが 404 エラーを返した場合、リクエストはフォールバックターゲットにルーティングされます。
デプロイ仕様では、トラバーサル順序の最後のルールがキャッチオールルールである必要があります。キャッチオールルールは /* パスで指定されます。着信リクエストがルーティングルールの配列内の以前のルートのいずれとも一致しない場合、リクエストはキャッチオールルールのターゲットにルーティングされます。
などの SSR フレームワークの場合Nuxt.js、キャッチオールルールターゲットはコンピューティングプリミティブタイプである必要があります。これは、SSR アプリケーションには、ビルド時に予測できないルートを含むサーバーサイドレンダリングされたページがあるためです。例えば、Nuxt.js アプリケーションでは /blog/[slug] にページがあるとします (ここで [slug] は動的ルートパラメータです)。キャッチオールルールのターゲットは、リクエストをこれらのページにルーティングする唯一の方法です。
対照的に、特定のパスパターンを使用して、ビルド時に既知のルートをターゲットにすることができます。例えば、Nuxt.js は /_nuxt パスから静的アセットを提供します。つまり、/_nuxt/*パスは、リクエストを静的アセットプリミティブタイプにルーティングする特定のルーティングルールによってターゲットにすることができます。
パブリックフォルダのルーティング
ほとんどの SSR フレームワークは、public フォルダから変更可能な静的アセットを提供する機能を提供します。favicon.ico や robots.txt のようなファイルは通常、public フォルダ内に保存され、アプリケーションのルート URL から提供されます。例えば、favicon.ico ファイルは https://example.com/favicon.ico から提供されます。これらのファイルには予測可能なパスパターンがないことに留意してください。それらは、ほぼ完全にファイル名によって決まります。public フォルダ内のファイルをターゲットにする唯一の方法は、キャッチオールルートを使用することです。ただし、キャッチオールルートターゲットはコンピューティングプリミティブタイプである必要があります。
public フォルダを管理するには、次のいずれかのアプローチをお勧めします。
-
ファイル拡張子を含むリクエストパスをターゲットにするためにパスパターンを使用します。例えば、ファイル拡張子を含むすべてのリクエストパスをターゲットにするために
/*.*を使用できます。このアプローチは信頼できない可能性があることに留意してください。例えば、
publicフォルダ内にファイル拡張子のないファイルが存在する場合、それらのファイルはこのルールのターゲットになりません。このアプローチで留意すべきもう 1 つの問題は、名前にピリオドが含まれるページがアプリケーションに存在する可能性があることです。例えば、/blog/2021/01/01/hello.worldのページは/*.*ルールのターゲットになります。ページは静的アセットではないため、これは理想的ではありません。ただし、このルールにフォールバックターゲットを追加して、静的プリミティブタイプから 404 エラーが発生した場合に、リクエストがコンピューティングプリミティブタイプにフォールバックするようにすることができます。{ "path": "/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } } -
ビルド時に
publicフォルダ内のファイルを識別し、各ファイルのルーティングルールを出力します。デプロイ仕様によって課されるルールの数が 25 個に制限されているため、このアプローチはスケーラブルではありません。{ "path": "/favicon.ico", "target": { "kind": "Static" } }, { "path": "/robots.txt", "target": { "kind": "Static" } } -
フレームワークのユーザーがすべてのミュータブルな静的アセットを
publicフォルダ内のサブフォルダに保存することを推奨します。次の例では、ユーザーはすべてのミュータブルな静的アセットを
public/assetsフォルダ内に保存できます。その後、パスパターン/assets/*を含むルーティングルールを使用して、public/assetsフォルダ内のすべてのミュータブルな静的アセットをターゲットにすることができます。{ "path": "/assets/*", "target": { "kind": "Static" } } -
キャッチオールルートの静的フォールバックを指定します。このアプローチには欠点があり、次の キャッチオールフォールバックルーティング セクションで詳しく説明します。
キャッチオールフォールバックルーティング
コンピューティングプリミティブタイプのターゲットにキャッチオールルートNuxt.jsが指定されている などの SSR フレームワークの場合、フレームワークの作成者はpublic、フォルダルーティングの問題を解決するために、キャッチオールルートの静的フォールバックの指定を検討する場合があります。しかし、このタイプのルーティングルールでは、サーバーサイドレンダリングされた 404 ページが壊れます。例えば、存在しないページにエンドユーザーがアクセスすると、アプリケーションはステータスコード 404 で 404 ページを表示します。しかし、キャッチオールルートに静的フォールバックがある場合、404 ページはレンダリングされません。代わりに、リクエストは静的プリミティブ型にフォールバックし、404 ステータスコードで終了しますが、404 ページはレンダリングされません。
{ "path": "/*", "target": { "kind": "Compute", "src": "default" }, "fallback": { "kind": "Static" } }
ベースパスルーティング
アプリケーションのベースパスを変更する機能を提供するフレームワークは、.amplify-hosting/static ディレクトリ内の静的アセットへのベースパスを先頭に付加することが想定されます。例えば、ベースパスが /folder1/folder2 である場合、main.css という静的アセットのビルド出力は .amplify-hosting/static/folder1/folder2/main.css になります。
これは、ベースパスを反映するためにルーティングルールも更新する必要があることを意味します。例えば、ベースパスが /folder1/folder2 である場合、public フォルダ内の静的アセットのルーティングルールは次のようになります。
{ "path": "/folder1/folder2/*.*", "target": { "kind": "Static" } }
同様に、サーバー側のルートにもベースパスを先頭に付加する必要があります。例えば、ベースパスが /folder1/folder2 である場合、/api ルートのルーティングルールは次のようになります。
{ "path": "/folder1/folder2/api/*", "target": { "kind": "Compute", "src": "default" } }
ただし、ベースパスをキャッチオールルートの先頭に付加しないでください。例えば、ベースパスが /folder1/folder2 である場合、キャッチオールルートは次のようになります。
{ "path": "/*", "target": { "kind": "Compute", "src": "default" } }
Nuxt.js ルートの例
ルーティングルールを指定する方法を示す Nuxt アプリケーションのサンプル deploy-manifest.json ファイルを次に示します。
{ "version": 1, "routes": [ { "path": "/_nuxt/image", "target": { "kind": "ImageOptimization", "cacheControl": "public, max-age=3600, immutable" } }, { "path": "/_nuxt/builds/meta/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/_nuxt/builds/*", "target": { "cacheControl": "public, max-age=1, immutable", "kind": "Static" } }, { "path": "/_nuxt/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } }, { "path": "/*", "target": { "kind": "Compute", "src": "default" } } ], "computeResources": [ { "name": "default", "entrypoint": "server.js", "runtime": "nodejs18.x" } ], "framework": { "name": "nuxt", "version": "3.8.1" } }
ベースパスを含むルーティングルールを指定する方法を示す Nuxt のサンプル deploy-manifest.json ファイルを次に示します。
{ "version": 1, "routes": [ { "path": "/base-path/_nuxt/image", "target": { "kind": "ImageOptimization", "cacheControl": "public, max-age=3600, immutable" } }, { "path": "/base-path/_nuxt/builds/meta/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/base-path/_nuxt/builds/*", "target": { "cacheControl": "public, max-age=1, immutable", "kind": "Static" } }, { "path": "/base-path/_nuxt/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/base-path/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } }, { "path": "/*", "target": { "kind": "Compute", "src": "default" } } ], "computeResources": [ { "name": "default", "entrypoint": "server.js", "runtime": "nodejs18.x" } ], "framework": { "name": "nuxt", "version": "3.8.1" } }
routes 属性の使用に関する詳細については、「ルート属性の使用」を参照してください。
