翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amplify ホスティングのデプロイ仕様を使用したビルド出力の設定 Amplify ホスティングのデプロイ仕様は、Amplify ホスティングへのデプロイを容易にするディレクトリ構造を定義するファイルシステムベースの仕様です。フレームワークは、ビルドコマンドの出力としてこの想定されるディレクトリ構造を生成できます。これにより、フレームワークは Amplify ホスティングのサービスプリミティブを利用できるようになります。Amplify ホスティングは、デプロイバンドルの構造を理解し、それに応じてデプロイします。 デプロイ仕様の使用方法を説明するデモ動画については、Amazon Web Services YouTube チャンネルで「* AWS 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 ホスティングが書き換えとリダイレクトを処理する方法の詳細については、「[Amplify アプリケーションのリダイレクトと書き換えの設定](redirects.md)」を参照してください。 ルーティングルールは、リクエストを書き換えたり、変換したりしません。着信リクエストがルートのパスパターンと一致する場合、リクエストはそのままルートのターゲットにルーティングされます。 `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` オブジェクトのプロパティについて説明します。 | Key | タイプ | 必須 | 説明 | | --- | --- | --- | --- | | パス | String | はい | 着信リクエストのパス (クエリ文字列を除く) に一致するパターンを定義します。
最大パス長は 255 文字です。
パスはスラッシュ `/` で始まる必要があります。
パスには、[A-Z]、[a-z]、[0-9]、[ \_-.\*$/\~"'@:\+] の文字を使用できます。
パターンマッチングでは、次のワイルドカード文字のみがサポートされます:[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/amplify/latest/userguide/ssr-deployment-specification.html) | | target | ターゲット | はい | 一致したリクエストのルーティング先となるターゲットを定義するオブジェクト。
`Compute` ルートが指定されている場合は、対応する `ComputeResource` ルートが存在する必要があります。
`ImageOptimization` ルートを指定する場合は、`imageSettings` も指定する必要があります。 | | fallback | ターゲット | いいえ | 元のターゲットが 404 エラーを返した場合にフォールバックするターゲットを定義するオブジェクト。
指定したルートで `target` の種類と `fallback` の種類を同じにすることはできません。例えば、`Static` から `Static` へのフォールバックは許可されません。フォールバックは、本文のない GET リクエストでのみサポートされます。リクエストに本文が存在する場合、その本文はフォールバック中にドロップされます。 | 次のオブジェクト定義は、`Target` オブジェクトの設定を示しています。 ``` type Target = { kind: TargetKind; src?: string; cacheControl?: string; } ``` 次の表では、`Target` オブジェクトのプロパティについて説明します。 | Key | タイプ | 必須 | 説明 | | --- | --- | --- | --- | | kind | Targetkind | はい | ターゲットのタイプを定義する `enum`。有効な値は、`Static`、`Compute`、`ImageOptimization` です。 | | src | String | `Compute`: はい
他のプリミティブ: いいえ | プリミティブの実行可能コードを含むデプロイバンドル内のサブディレクトリの名前を指定する文字列。コンピューティングプリミティブでのみ有効かつ必須です。
値は、デプロイバンドルに存在するコンピューティングリソースの 1 つをポイントする必要があります。現在、このフィールドでサポートされている値は `default` のみです。 | | cacheControl | String | いいえ | 応答に適用する Cache-Control ヘッダーの値を指定する文字列。Static および ImageOptimization プリミティブでのみ有効です。
指定された値は、カスタムヘッダーによってオーバーライドされます。Amplify ホスティングのカスタマーヘッダーの詳細については、「[Amplify アプリのカスタムヘッダーの設定](custom-headers.md)」を参照してください。 このキャッシュコントロールヘッダーは、ステータスコードが 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" } } ] ``` デプロイマニフェストでのルーティングルールの指定の詳細については、「[ルーティングルールの設定に関するベストプラクティス](#routing-best-practices)」を参照してください。 ### computeResources 属性の使用 `computeResources` 属性により、フレームワークは、プロビジョニングされたコンピューティングリソースに関するメタデータを提供できるようになります。あらゆるコンピューティングリソースには、対応するルートが関連付けられている必要があります。 次のオブジェクト定義は、`ComputeResource` オブジェクトの使用法を示しています。 ``` type ComputeResource = { name: string; runtime: ComputeRuntime; entrypoint: string; }; type ComputeRuntime = 'nodejs20.x' | 'nodejs22.x'; ``` 次の表では、`ComputeResource` オブジェクトのプロパティについて説明します。 | Key | タイプ | 必須 | 説明 | | --- | --- | --- | --- | | 名前 | String | はい | コンピューティングリソースの名前を指定します。この名前は、`.amplify-hosting/compute directory` 内のサブディレクトリの名前と一致する必要があります。
デプロイ仕様のバージョン 1 である場合、有効な値は `default` のみです。 | | ランタイム | ComputeRuntime | はい | プロビジョニングされたコンピューティングリソースのランタイムを定義します。
有効な値は、`nodejs20.x` および `nodejs22.x` です。 | | entrypoint | String | はい | 指定されたコンピューティングリソースのためにコードが実行される開始ファイルの名前を指定します。このファイルは、コンピューティングリソースを表すサブディレクトリ内に存在している必要があります。 | 次のようなディレクトリ構造があるとします。 ``` .amplify-hosting |---compute | |---default | |---index.js ``` `computeResource` 属性の JSON は次のようになります。 ``` "computeResources": [ { "name": "default", "runtime": "nodejs20.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` オブジェクトのプロパティについて説明します。 | Key | タイプ | 必須 | 説明 | | --- | --- | --- | --- | | sizes | Number[] | はい | サポートされている画像の幅の配列。 | | domains | String[] | はい | 画像の最適化を使用できる許可された外部ドメインの配列。デプロイドメインのみが画像の最適化を使用できるようにするには、配列を空のままにしておきます。 | | remotePatterns | RemotePattern[] | はい | 画像の最適化を使用できる許可された外部パターンの配列。ドメインに似ていますが、正規表現 (regex) によりさらに詳細なコントロールを提供します。 | | formats | ImageFormat[] | はい | 許可される出力画像形式の配列。 | | minimumCacheTTL | Number | はい | 最適化された画像のキャッシュ期間 (秒)。 | | dangerouslyAllowSVG | ブール値 | はい | SVG 入力画像 URL を許可します。これは、セキュリティ上の理由からデフォルトでは無効になっています。 | 次のオブジェクト定義は、`RemotePattern` オブジェクトの使用法を示しています。 ``` type RemotePattern = { protocol?: 'https'; hostname: string; port?: string; pathname?: string; } ``` 次の表では、`RemotePattern` オブジェクトのプロパティについて説明します。 | Key | タイプ | 必須 | 説明 | | --- | --- | --- | --- | | protocol | String | いいえ | 許可されるリモートパターンのプロトコル。唯一の有効な値は `https` です。 | | hostname | String | はい | 許可されるリモートパターンのホスト名。
リテラルまたはワイルドカードを指定できます。単一の「\*」は単一のサブドメインに一致します。二重の「\*\*」は任意の数のサブドメインに一致します。Amplify では、「\*\*」のみが指定されるブランケットワイルドカードを使用できません。 | | port | String | いいえ | 許可されるリモートパターンのポート。 | | pathname | String | いいえ | 許可されるリモートパターンのパス名。 | 次の例は、`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` オブジェクトのプロパティについて説明します。 | Key | タイプ | 必須 | 説明 | | --- | --- | --- | --- | | 名前 | String | はい | フレームワークの名前。 | | バージョン | String | はい | フレームワークのバージョン。
有効なセマンティックバージョニング (semver) 文字列である必要があります。 | ## ルーティングルールの設定に関するベストプラクティス ルーティングルールは、着信リクエストのパスをデプロイバンドル内の特定のターゲットにルーティングするメカニズムを提供します。デプロイバンドルでは、フレームワークの作成者は、次のターゲットのいずれかにデプロイされるファイルをビルド出力に出力できます: + **静的アセットプリミティブ** – ファイルは `.amplify-hosting/static` ディレクトリに含まれます。 + **コンピューティングプリミティブ** – ファイルは `.amplify-hosting/compute/default` ディレクトリに含まれます。 また、フレームワークの作成者は、デプロイマニフェストファイルでルーティングルールの配列も提供します。配列内の各ルールは、一致が見つかるまで、シーケンシャルトラバーサル順序で着信リクエストと照合されます。一致するルールがある場合、リクエストは一致ルールで指定されたターゲットにルーティングされます。オプションで、ルールごとにフォールバックターゲットを指定できます。元のターゲットが 404 エラーを返した場合、リクエストはフォールバックターゲットにルーティングされます。 デプロイ仕様では、トラバーサル順序の最後のルールがキャッチオールルールである*必要があります*。キャッチオールルールは `/*` パスで指定されます。着信リクエストがルーティングルールの配列内の以前のルートのいずれとも一致しない場合、リクエストはキャッチオールルールのターゲットにルーティングされます。 Nuxt.js などの SSR フレームワークでは、キャッチオールルールのターゲットはコンピューティングプリミティブである必要があります。これは、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` フォルダを管理するには、次のいずれかのアプローチをお勧めします。 1. ファイル拡張子を含むリクエストパスをターゲットにするためにパスパターンを使用します。例えば、ファイル拡張子を含むすべてのリクエストパスをターゲットにするために ` /*.*` を使用できます。 このアプローチは信頼できない可能性があることに留意してください。例えば、`public` フォルダ内にファイル拡張子のないファイルが存在する場合、それらのファイルはこのルールのターゲットになりません。このアプローチで留意すべきもう 1 つの問題は、名前にピリオドが含まれるページがアプリケーションに存在する可能性があることです。例えば、`/blog/2021/01/01/hello.world` のページは `/*.* ` ルールのターゲットになります。ページは静的アセットではないため、これは理想的ではありません。ただし、このルールにフォールバックターゲットを追加して、静的プリミティブで 404 エラーが発生した場合に、リクエストがコンピューティングプリミティブにフォールバックされるようにすることができます。 ``` { "path": "/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } } ``` 1. ビルド時に `public` フォルダ内のファイルを識別し、各ファイルのルーティングルールを出力します。デプロイ仕様によって課されるルールの数が 25 個に制限されているため、このアプローチはスケーラブルではありません。 ``` { "path": "/favicon.ico", "target": { "kind": "Static" } }, { "path": "/robots.txt", "target": { "kind": "Static" } } ``` 1. フレームワークのユーザーがすべてのミュータブルな静的アセットを `public` フォルダ内のサブフォルダに保存することを推奨します。 次の例では、ユーザーはすべてのミュータブルな静的アセットを `public/assets` フォルダ内に保存できます。その後、パスパターン `/assets/*` を含むルーティングルールを使用して、`public/assets` フォルダ内のすべてのミュータブルな静的アセットをターゲットにすることができます。 ``` { "path": "/assets/*", "target": { "kind": "Static" } } ``` 1. キャッチオールルートの静的フォールバックを指定します。このアプローチには欠点があり、次の [キャッチオールフォールバックルーティング](#catchall-fallback-routing) セクションで詳しく説明します。 ### キャッチオールフォールバックルーティング コンピューティングプリミティブターゲットにキャッチオールルートが指定されている 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": "nodejs22.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": "nodejs22.x" } ], "framework": { "name": "nuxt", "version": "3.8.1" } } ``` `routes` 属性の使用に関する詳細については、「[ルート属性の使用](#deployment-manifest-routes)」を参照してください。