Next.jsをAmplifyに_しっかり_と載せるためには

Next.js をAmplifyに"しっかり"と 載せるためには n13u / 2026.08.25 / #AWSAmplifyJP

• http://next.js

⾃⼰紹介 ● Nishimura Wataru / ⻄村航 ● ちょっと株式会社 プロダクト部 Orizm プロダクトマネージャー ● Next.js / React 愛好家 ● 最近の好きなもの ○ ⾳楽：BOOM BOOM SATELLITES ○ 本：プロジェクト・ヘイルメアリー

ちょっと株式会社 について ● ちょっと株式会社（chot Inc.）は、AIやテクノロジーを活⽤して社会に「ちょっといい変 化」をもたらすことを⽬指しています ○ ● ⽇本初のVercel公式パートナーとして、⼤規模Webサイトの制作や独⾃CMS「Orizm」 の開発を⼿掛けています。 ○ ● Next.jsを中⼼としたモダンフロントエンド開発に特化しており、AIアプリケーションやエージェント型Webサイ トの開発を⾏っています。 VercelとAWSはIntergrationがあったりするので競合でもありつつ、⼀緒に使えるサービスなんですよね... フルリモートで柔軟な働き⽅が可能で、エンジニアが成⻑できる環境を提供しています。

Orizm について ● Orizmはちょっと社が提供する企業の情報発信を⽀援するためのWebサービスです ● BaaS型のCMSサービスと組み合わせたWebマーケティングを効率化するための仕組みを 提供しています

AWS Amplify と私（ とちょっと社） ● AWS AmplifyはOrizm公式ドキュメント docs.orizm.com サイトのホスティングに利⽤ しています ● Nextraをベースに、静的サイト⽣成（SSG）したものをデプロイしています ● 受託側では必要に応じて軽量なNext.js製Webアプリケーションのデプロイに利⽤してい ます ● 社内サービスのVercel->Amplify移⾏を考えたことがきっかけで今⽇の登壇につながって います ○ ● OrizmはCMSをVercelにデプロイしていますが、今後Amplifyも視野に⼊れています（が厳しそう 私⾃⾝はAmplify Gen1の時に触る機会が多かったです

今⽇する話

AmplifyにNext.jsをしっかりとのせる ● Next.jsをAWS Amplifyに載せる時に考えるべき技術的要素とその原因を探ってみます ● ● そこから導き出されるAWS AmplifyにおけるNext.jsとの向き合い⽅をまとめます 前提としている知識の整理 ○ ○ ○ Node.js環境とブラウザJavaScript環境の違い フロントエンドメタフレームワークにおけるレンダリング⽅式の違い AWS Amplify、Next.js、Reactの基礎知識

最初に結論 ● Next.jsをAWS Amplifyで動かしたいときに、AppSyncやCognitoなどを統合して使える ことにメリットを感じているのか、デプロイ環境として単純にAWSを選んでいるのかを考 える必要がある ● Amplify Hosting で未対応な機能は、Next.jsもAWS Amplifyも悪くなく現状の技術的な 制約によるもの。なのでLambdaでもいいことがある。でもLambdaだと⾃分で CloudFrontやS3との連携を書く必要がある。 ● Amplifyに載せるときはやりたいことをしっかり考えて整理することが⼤事

amplify-jsとAmplifyのホスティング環境は 別物である（おさらい） 以下の２つは別のもので、それぞれでNext.jsとの相性を考える必要があります ● aws-amplify（amplify-js） CognitoやAppSyncにAmplifyが提供するラッパーを通してアクセスするためのSDK ○ ● @aws-amplify/adapter-nextjs SSR環境でaws-amplifyを動かすためのNext.js向けのSDK（サーバー⽤） Amplify Hosting デプロイされたアプリケーションが動くAmplifyのインフラ基盤。aws-amplifyとの依 存関係はない

• http://next.js

整理するとこう Amplify Hosting（Compute） aws-amplify（amplify-js） 役割 ビルド・配信・SSR 実⾏をするデプロイ環境 ognito / AppSync / S3 を叩くnpm パッケージ 実体 S3、CloudFront、Lambdaなどの集合。 内部の詳細は公開されていない SigV4と⾃前のfetchを持っている 元はブラウザ向けのSDK Next.js 対応 公式では12~15まで 13.5.0~16.xまで 環境 どんなフレームワークでもデプロイできる どんなホスティング環境でも動く

Next.js を動かす上 で⼤事なこと はAmplify が 提供するAWSサービス を使いたいのかというこ と ● ⾃分のアプリケーションでやりたいことを考える ● Cognitoの認証基盤の上で、AppSync経由のDynamoDBにデータストアを⾏いアプリ ケーションを構築したい →aws-amplifyとNext.jsとの間の制約を探す ● ではなくNext.jsアプリケーションをデプロイしたいだけ →デプロイ環境として、どのレンダリング⽅式が最適かを考える

Amplify Hosting の制約

Amplify Hostingの制約を知る ● Next.jsアプリケーションはApp Router登場からキャッシュやレンダリング⽅式⾯、⾮同 期な処理の扱い、デプロイ先を選ばないようなビルド時のAdapter規約の開発など新しい 機能をどんどん出しており、実際のWebアプリケーション構築で利⽤できるチャンスが多 いです ● ただ、機能が動くためにはインフラ環境側に制約がいくつかありそれらを知らないと 「アレ、これVercel（やLambda）だと動くけどAmplifyだと動かないね？？？」 ということになります ● 今回はSSGでなくできる限りSSR環境で、そしてApp RouterやNext.jsの最新機能を使お うという前提です（受託案件では特にISRやキャッシュ機構を使うことが多いです

Amplifyのデプロイフローを整理 Git push └→ Amplify CI/CD ＝ 中⾝は CodeBuild └→ next build → .next（← ここがoutだとSSGとしてAmplifyが検知し置き換える） └→ Amplifyのclosed adapter（多分ある、NuxtやSvelteKitはOSSのアダプタが変換し ている └→ amplify-compute-bundle-output/ ├─ compute/default/ server.js、chunks/、node_modules/ ├─ static/ └─ deploy-manifest.json └→ S3 + Lambda に配置

Amplifyがどうやってリクエストを捌くか → CloudFront（Amplify 管理。⾃分の AWS アカウントには⾒えない）cache policy を content type で⾃動選択 Amplify-Default … Authorization/Accept/Viewer-Country/Host + Cookie全部 + QS全部 Amplify-DefaultNoCookies … 上から Cookie を除外 Amplify-StaticContent … Cookie / QS を cache key に含めない Amplify-ImageOptimization routes を先頭から評価 ├─ Static → S3 ├─ ImageOptimization → Amplify の最適化サービス（sharp は⾃動デプロイ） └─ Compute → AWS Lambda

つまり、どういうことか ● ● ● Next.jsが動くためのバンドル結果をLambda、S3に分けておくためにアダプタ（変換機 構）が存在している CloudFrontでインターネットからのアクセスをContent-Typeごとに整理してS3や Lambdaに振り分けることでNext.jsアプリケーションを動かしている Lambdaに制約が左右される ○ ○ ○ ○ ○ SSR ビルド出⼒ 220 MB（⾮圧縮）→今⽇社内でこれに引っかかっている⼈がいました レスポンス最⼤ 5.72 MB タイムアウト 30秒 Lambda メモリ 1024 MB 固定 etc…

`deploy-manifest.json` ファイル ● ● ● Amplify Hosting向けにRoute構成設定を書き、S3に振り分けるのかLambdaに振り分 けてSSRするのかを分割する Next.jsでも⽣成されているはず（⽣成の仕組みはclosed） 詳細は公式ドキュメントに書かれている ○ ● https://docs.aws.amazon.com/ja_ jp/amplify/latest/userguide/ssr-deployment-specification.html このファイルでできること＝Amplify Hostingでできること

• https://docs.aws.amazon.com/ja_jp/amplify/latest/userguide/ssr-deployment-specification.html

Next.js最新（16.x）で 何ができて何ができないのか

Amplify HostingとAWS Amplifyの Next.js対応状況をおさらい ● AWS Amplify→Amplify JSのAdapterがNext.js 16まで対応 ○ ● がドキュメントは未更新っぽい Amplify Hosting→15まで公式サポート、16はどう...？どんな機能使えるの...?

公式ドキュメント では 以下の通りだが... ● サポートされていない機能 ○ ○ ○ ○ ○ ○ ○ ● イメージの最適化 OnDemand-ISR 国際化 (i18n) ドメインルーティング 国際化 (i18n) ⾃動ロケール検出 ミドルウェア エッジ ミドルウェア エッジ API ルート¶ 上記どれも全てNext.js 15までの機能しか網羅されていない

Amplify Hostingの技術的制約 ● ● 公式ドキュメントに「未対応」と明記されている5つ ○ ○ ○ ○ ○ Edge API Routes / Edge Middleware On-demand ISR（revalidatePath / revalidateTag) Next.js ストリーミング ・ 静的アセットと最適化画像への middleware 実⾏ ・ unstable_after ○ ○ ○ PPR Cache Components（use cache / cacheComponents） Server Actions（動くが redirect() で不安定報告 / Issue #4075） ドキュメントに記載すらないが実質使えないもの 4つの根本原因 1. レスポンスをバッファして返す a. 2. 共有キャッシュのプリミティブが無い a. b. 3. manifest のキャッシュ表現が cacheControl と minimumCacheTTL のみ on-demand ISR / revalidateTag / use cache のためのバックエンドにRedis等が必要だが... アプリディレクトリが read-only a. b. 4. レスポンス上限 5.72MB ≒ Lambda 同期呼び出しサイズと同じで公式も使えないことを明記している streaming / PPR / Suspense / Server Actions の逐次配信が使えない...orz EROFS: read-only file system, open '/tmp/app/.next/server/app/….html'（Issue #3707 他、2023年から） Next.js 既定の file-system cache handler による prerender cache 更新ができない CloudFront で分岐して Lambdaに届かない...

例えばCache Componentsは？ ● ● ● 16.0から登場した15.xまでで提供していたDynamicIO、PPR、Cacheをまとめた1つの機 能 アプリケーション全体のうち静的な箇所とキャッシュ可能な箇所（または常に動的な箇 所）を分けて、構築することでキャッシュサイズやライフタイムを機能・コンポーネント・ データ単位ごとに最適化できる Amplify Hostingは⾮対応、つまりAWS AmplifyをAmplify HostingでCache Components下で使っても意図した通りに動かない

Cache Componentsの中⾝ ● ● ● Cache Componentsは基本的にStreaming＋Next.js Cache機構の機能を多分に使って いる 意図した振る舞いをしないことの⽅が多い... 実際のデモでは動いているように⾒えるけど... ○ ○ インメモリキャッシュなので、Lambdaのインスタンスが変わるとキャッシュが落ちる→Cacheされてはいるので Cache Componentsとしてはまあ動いている...？ただ予測不可な振る舞いになるといえばそう Streamingが効いていないのでFallbackが効かない...

ストリーミングが使えないと... ● <Suspense>で囲んだアプリケーションのfallback→本体の表⽰がうまく動かなくなる ○ ● ● 段階的に画⾯をローディングすることもできない... 他のReactフレームワークでもRSC＋SSRを使う際に気をつける必要が出てくる 詰まるところNext.js App RouterやCache Componentsが提供する部分的に更新してい くUXモデルが機能しない

Next.js 16.2 Deployment Adapters APIの登場

⾰命（？） かも ● ● ● Next.js 16.2 登場時にオフィシャルでリリースされたデプロイ前のビルド時の振る舞いを 新しく定めどんなデプロイ環境でも準拠できるAPI 現在Vercelもこれに従ってデプロイ⽤の変換を記述している 開発にあたってAWS Amplifyチームも参加しているっぽい ○ ● Thank you to the members of the Build Adapters working group: engineers at Netlify, Cloudflare, Google Cloud, AWS Amplify, and OpenNext who invested their time co-designing this API and validating it for their platforms. Thank you to every contributor who built adapters, filed bugs, and shipped workarounds. （https://nextjs.org/blog/nextjs-across-platforms#the-ecosystem-working-group） とはいえ、ビルド時の変換をするだけでdeploy-manifest.jsonで表現できる範囲しか Amplify Hostingでは実現で不可なのでできるようになることは少ない...

• https://nextjs.org/blog/nextjs-across-platforms#the-ecosystem-working-group

Amplify Hostingこれができたら完璧 ● Next.js 公式 Adapter API への対応 ○ ○ ● レスポンスのストリーミング ○ ○ ● revalidateTag / on-demand ISR / use cache が全部ここに依存している... 書き込み可能な（インスタンス間で共有される）キャッシュ領域 ○ ● ● ⼤きな原因の１つ。対応してくれると嬉しい Next.js 公式の要件表でも軒並み "Streaming: Required"な機能が多い ■ LambdaはStreaming Responseが使えるはずなので..？ 共有キャッシュと cacheHandler の差し込み⼝ ○ ● AWS 向け adapter は「OpenNext 経由で開発中」とアナウンス済み Amplify Hostingも対応して欲しいが、deploy-manifest.jsonではない仕組みをAmplifyが導⼊ /tmp/app が read-only なので Next.js 既定の file-system cache handler が prerender cache を更新でき ない 未対応機能を「未対応」とドキュメントに書く サポート対象 Next.js バージョンの追随とロードマップの公開 ○ Feature Request Tracker は公開されているが、Next.js バージョン追随の⾒通しは載っていない などなどありますが...

お願い、AWSさん 🙏

Next.jsを”しっかり”と載せるために Next.js の最新機能（PPR / use cache / streaming / on-demand ISR）が要件？ ├─ YES → Vercel、または Fargate で next start └─ NO ├─ プライベート VPC 内のリソースに直接繋ぐ？ │ └─ YES → Amplify Hosting は落ちる（ECS / Lambda+VPC） └─ NO ├─ 開発者5名以上 & バックエンドが AWS → Amplify Hosting └─ 少⼈数 & 転送量が多い → その他サービス

結論振り返り ● Next.jsをAWS Amplifyで動かしたいときに、AppSyncやCognitoなどを統合して使える ことにメリットを感じているのか、デプロイ環境として単純にAWSを選んでいるのかを考 える必要がある ● Amplify Hosting で未対応な機能は、Next.jsもAWS Amplifyも悪くなく現状の技術的な 制約によるもの。なのでLambdaでもいいことがある。でもLambdaだと⾃分で CloudFrontやS3との連携を書く必要がある。 ● Amplifyに載せるときはやりたいことをしっかり考えて整理することが⼤事（というかなん でもそうですね...

イベント宣伝

おまけ

それでもAmplify+Next.jsを使いたいあなた に Next.jsアプリケーションをどう構築するか ● On-Demand ISRがない→時間ベースでのキャッシュ更新しかできない ● ● ● Streamingがない→App Router/Cache Componentsの機能の⼤部分が意図した挙動を しない とはいえ、今後対応される可能性はあるのでそこを⾒越すべき... すべきこと... ○ ○ Container/Presentationalパターンの導⼊→Cache Components/App Routerでも有効な⼿法 https://zenn.dev/akfm/books/nextjs-basic-principle/viewer/part_2_container_presentational_pattern SWRやTanStack QueryとSuspense（クライアントサイド）を利⽤して段階的なUI提供は可能 ■ 擬似的に動的な箇所と静的な範囲を整理できる→Cachedに将来的にしたい箇所とStaticな箇所を分けてお ける

• https://zenn.dev/akfm/books/nextjs-basic-principle/viewer/part_2_container_presentational_pattern