はじめに
こんにちは！
NRI xPalette Advent Calendar 2025の5日目は、
【Next.js 16まで対応】もう置いていかれない！App Routerから理解する、速習Next.js📖
という記事の内容でお届けします！
フロントエンドのエコシステムの中でもNext.jsは特に変化が早く、その変化の早さから賛否が分かれるフレームワークです。
Next.jsが「Reactのメタフレームワーク」という認識から抜け出せない人が、Next.js の大きな転換点、App Router 以降の特徴を把握し、いつも Next.js を避けてViteばかり採用していたけど、Next.js を採用してみようかな、と思えるように改めて調査しまとめてみましたので、是非最後まで目を通してみてもらえると幸いです！
想定読者
この記事は以下のような人を読者として想定しています。
- React や Next.js の基本はわかるが、何となくNext.jsを避けてきてしまっている
- Next.jsのことを、React のフレームワークくらいしか理解できてない
- 正直、App Router くらいから段々置いてかれてしまっている
- ざっと最新バージョンまでの変更履歴をさらいたい
この記事で書くこと・書かないこと
書くこと
- App Router 以前の Next.js の特徴
- App Router の特徴
- Nextjs 14〜16 までの各バージョンでの大きな変更
この記事を読み終えると、
App Routerの設計思想（Server-first / レイアウト / データフェッチ / キャッシュ）がざっくり頭に入り、v13〜16 の「どのバージョンで何が変わったか」を大まかに時系列で説明できるようになります。
書かないこと
- React そのものの詳細解説
- 全ての Breaking Change の細かな挙動
- APIリファレンスの網羅（Next.jsの理解に必要な、根幹の考え方の説明が中心となります）
Pages Router とは
App Routerを理解する前に、まずApp Router以前の設計である、Pages Routerについて簡単にまとめます。
Pages Routerが抱えていた課題を理解して、App Routerがその課題をどのように解決したかを学ぶことで、Next.jsの全体像が一気に理解しやすくなります。
Pages Router の特徴
現在のNext.jsではバージョン13.4でstableになって以降、App Routerという仕組みが採用されていますが、それ以前はPages Routerという仕組みが導入されていました。
Next.js（Pages Router）は登場当時（2016年）から、
- ファイルベースでの ルーティング
- ページ単位での SSR / SSG / CSR
- API Routes との統合
などの機能を有しており、フロントエンド開発のブレイクスルーとなった存在でした。
ファイルベースの ルーティング
Pages Router は追加のライブラリ不要で、ファイルベースでのシンプルなルーティングを提供します。
pages/about.js → /about
pages/blog/[id].js → /blog/123
/pages下にファイルを実装していくだけで、ルーティングが成立します。
ページ単位での SSR / SSG / CSR
Pages Router ではページごとに SSR（Server Side Rendering）、SSG（Static Site Generation）、CSR（Client Side Rendering） を選択できる仕組みが用意されています。
たとえば、pages/index.js に getServerSideProps を書けば SSR に、getStaticProps を書けば SSG に、というようにページファイル内で宣言するだけで描画方式を切り替えられるのが特徴です。
// SSR（毎リクエストごとにサーバーでHTML生成）
export async function getServerSideProps() {
return { props: { time: new Date().toISOString() } }
}
// SSG（ビルド時に静的HTMLを生成）
export async function getStaticProps() {
return { props: { generatedAt: new Date().toISOString() } }
}
このように、ページ単位で描画方式を自由に選択できるという Pages Router の設計は、SSR / SSG をとても手軽に扱える画期的な機能でした。
API Routesとの統合
Pages Routerでは、pages/api 配下にファイルを置くだけで、そのままAPIエンドポイントとして動作する仕組みが用意されています。
この仕組みにより、pages/ には画面用コンポーネント、pages/api/ にはAPIエンドポイントを実装していくことで、1つのリポジトリ・1つのデプロイ単位でフロントエンドとAPIを完結させる、フロントリッチなフルスタックフレームワークが実現されていきました。
しかし、そんな Pages Router にも進化していくフロントエンド開発において、以下のような課題を抱えていたのです。
Pages Routerでの課題
課題1 - レイアウトと状態管理の辛さ
Pages Router はファイルベースでのルーティングを実現する分、純粋な React と比較してレイアウト制御の柔軟性に欠けていました。
Pages Routerでも当然、ページを跨いだレイアウト機能は存在していたのですが、
<App>
<_app.js>
<Component> // ページ部分
</_app.js>
</App>
_app.jsが唯一のレイアウト、ページコンポーネントの上位要素となっており、ページを跨いだレイアウトの変更がとても難しいという課題がありました。
また、ルーティングと同様に、Pages Router は「ページ単位のコンポーネント構造」が基本で、React のツリーがページ遷移ごとにほぼ根本から再描画される特徴により、ページを跨いだ状態管理にも支障が生じていました。
ページを跨いで管理したい状態は全てcontextや状態管理ライブラリにより、グローバルな状態としなくてはいけませんでした。
Pages Routerにより過剰な中央集権型な state 設計を強要されてしまうケースも、中規模以上のプロジェクトでは多く存在していました。
課題2 - レンダリング戦略
Pages Routerでは前述した通り、ページ単位でレンダリング方式を選択する仕組みを採用しています。
そのため、逆に言えば開発者がそのページの仕様によって、ページ単位でレンダリング方式を判断しなくてはならないという負荷が生じていました。
- このページは SEO 必要？ → SSR or SSG
- データ更新頻度は？ → ISR？SSR？
- 認証が必要？ → SSR？
- ページ遷移の体験を優先？ → CSR？
- 外部 API のレスポンス遅いけど SSR で大丈夫？
選択できることは便利ですが、「ページ単位」という制約により、開発者の判断負荷を高めてしまっていたのです。
さらに、Pages Router では明示的に SSG/SSR を選択できますが、多くのプロジェクトではクライアント側でデータ取得（useEffect など）が行われたため、結果として CSR が採用されやすくブラウザがダウンロードするJavaScript 量の増加を招いていました。
課題3 - データフェッチAPIの分散及びUIとロジックの密結合
ページごとにレンダリング方式を変更できるPages Routerの設計は、ページ単位でデータ取得方式がバラバラになり、分散することで大きな学習コストを生じさせていました。
サーバーサイドで実行される、
getServerSidePropsgetStaticProps
があり、クライアントサイドで実行される、
-
useEffect内でfetch -
SWR/React Query（現在はTanStack Query）
もあり、とデータ取得ロジックの種類が多く、クライアント側のコンポーネントにもロジックが散らばってしまっていたのです。
また、Pages RouterではgetServerSideProps()やgetStaticProps()などでデータフェッチを行い、それをpropsとしてPagesに渡す以下のような設計となっていました。
export default function UsersPage({ users }) {
return (
<div>
<h1>ユーザー一覧</h1>
{users.map(u => (
<div key={u.id}>{u.name}</div>
))}
</div>
)
}
export async function getServerSideProps() {
const res = await fetch('https://api.example.com/users')
const users = await res.json()
return { props: { users } }
}
これにより、propsのネストされたバケツリレーやUIとロジックの密結合という問題も生じていました。
以上の課題を解決するために、Next.js は 13 で大きな転換点を迎えました。
それが App Router です。
App Router（Next.js 13）は何を解決したか
Next.js 13にて登場し、Next.js 13.4でstableとなったApp RouterはPages Routerが抱えていた課題を解決するために、様々な設計の変更が行われました。
（原文）Every part of the framework has to be designed around the router. Page transitions, data fetching, caching, mutating and revalidating data, streaming, styling content, and more.
To make our router compatible with streaming, and to solve these requests for enhanced support for layouts, we set out to build a new version of our router.
（日本語訳）フレームワークのあらゆる部分は、ルーターを中心に設計される必要があります。ページの遷移、データフェッチ、キャッシング、データの変更と再検証（リバリデーション）、ストリーミング、コンテンツのスタイリングなど、多岐にわたります。
私たちのルーターをストリーミングに対応させ、レイアウトに対する強化されたサポートへの要望に応えるため、私たちはルーターの新しいバージョンを構築することに着手しました。
公式ブログでは上記のように語られており、Next.jsチームはPages Routerが抱えていた課題を、Routerを刷新することで解決しようとしました。
App Routerによって変わったこと
変更点1 - レイアウトと状態管理の辛さへの対応
App Routerではファイルの構造がPages Routerから大きく変化しました。
app/
├── layout.tsx // ルートレイアウト（全ページ共通）
├── page.tsx // "/" のページ
└── dashboard/
├── layout.tsx // "/dashboard" 以下共通レイアウト
├── page.tsx // "/dashboard"
└── settings/
└── page.tsx // "/dashboard/settings"
このルーティングシステムにより、Pages Routerが抱えていたレイアウトの制御の課題が大きく緩和されました。
レイアウトの概念としては以下のようになります。
<RootLayout>
{/* /dashboard 以下のときだけ効く */}
<DashboardLayout>
<Page /> // /dashboard, /dashboard/settings など
</DashboardLayout>
</RootLayout>
また、レイアウトがページのセグメント単位で切れるということはつまり、レイアウトが再マウントされにくく、状態を保持しやすいということにも繋がります。
これにより、Pages Routerが抱えていた、過剰な中央集権型な state 設計も解決されます。
（そもそも、App RouterではReact Server Component前提であり、stateの考え方も変化します。）
その他にも、APIのルーティング方法が、API Routes から Route Handlers となり、HTTPメソッドをより宣言的に実装することが可能となりました。
export async function GET() {
const res = await fetch('https://data.mongodb-api.com/...', {
headers: {
'Content-Type': 'application/json',
'API-Key': process.env.DATA_API_KEY,
},
})
const data = await res.json()
return Response.json({ data })
}
このように、App Routerではルーティング周りが強化され、Pages Routerよりも柔軟なルーティングが可能となりました。
（参考: Next.js 公式ドキュメント）
変更点2 - レンダリング戦略への対応
App Routerでは、クライアントサイドでJSを実行したいコンポーネントは、ユーザーが"use client"と明示する、Server Components を使った Server-first モデルとなり、これによりページ単位でのレンダリング方式の選択から、必要なコンポーネントのみをクライアントサイドでレンダリングする選択方式に変化しました。
さらに、パフォーマンスについても大きく改善しています。
App RouterではSuspenseと深く統合されたため、コンポーネントの粒度で遅い部分だけ遅らせる設計も可能です。Server Components は JS に含まれないため、クライアントに送られるJSの量も減少します。
Pages Routerで課題として存在していた SSR / SSG / CSR をページ単位で選び続ける設計から、Server Components + Suspense/ストリーミングによって、コンポーネント単位で静的/動的を組み合わせるレンダリングモデルに再定義されたのです。
変更点3 - データフェッチAPIの分散及びUIとロジックの密結合への対応
データフェッチ周りも同様に、App Routerで非常に強化されました。
まず、Pages Routerで抱えていた、getServerSideProps()やgetStaticProps()の乱立ですが、
（原文）Only JavaScript. Everything is a function
（日本語訳）JavaScript の関数だけで作れる。
と公式ブログに書かれているように、とてもシンプルに書けるようになりました。
データフェッチが async / await に一本化したのです。
（参考: Static and Dynamic Rendering）
export default async function UsersPage() {
const res = await fetch("https://api.example.com/users", { cache: "no-store" })
const users = await res.json()
return (
<ul>
{users.map(u => <li key={u.id}>{u.name}</li>)}
</ul>
)
}
これは、App Routerがデフォルトでサーバーサイド実行されることに由来します。
また、これにより、
export async function UserList() {
const users = await getUsers()
return <UserListView users={users} />
}
// "use client"
export function UserListView({ users }) {
return (
<ul>
{users.map(u => <li key={u.id}>{u.name}</li>)}
</ul>
)
}
上記のようにデータをフェッチするロジックと、UIのコンポーネントが自然に切り離されるようになり、ロジックとUIの密結合が解決されていきました。
App Routerは Server-first なアーキテクチャとなることでデータ取得とUIの責務を自然に分離し、Pages Router時代の複雑性を根本から取り除いたのです。
以上の他にも、App Router導入のタイミングで様々な変更が加えられ、従来フロントエンド開発者が抱えていた課題を一気に解決する、Next.jsにとって大きな転換点となりました。
Next.js 14 - App Routerの本番運用フェーズへ
次に、App Router以降のNext.jsの主要な動きをまとめていきます。
まず、Next.js 14ですが、一言で言うと、
「ビルド体験が向上し、App Routerの本番運用フェーズへ入った」
と言えるでしょう。
Next.js 14
Next.js 14.1
Next.js 14.2
変更点1 - Turbopackによる開発体験の向上
Next.js 14 で最も象徴的なアップデートの一つが、Turbopack の本格的な実用段階への突入です。
Turbopack は Webpack の後継を目指して Vercel が開発している Rust 製の高速バンドラー／開発サーバー で、Next.js に最適化されています。
Next.js 14.2にて、テストが99.8%成功していると報告されており、リリース候補となりました。
それまで使用されていたwebpackと比較し、
- ローカルサーバーの起動が最大 76.7% 高速化
- Fast Refresh によりコード更新が最大 96.3% 高速化
- キャッシュなしの初期ルートコンパイルが最大 45.8% 高速化
とNext.js 14.2時点では報告されています。
TurbopackはNext.js 16にてstableとなりました。
変更点2 - Server Actions の安定化
Next.js 14 ではServer Actionsがstableとなり、RSCとApp Routerを軸とした、フロントリッチなフルスタックフレームワークとしてさらにフロントエンドとバックエンドの垣根が薄くなっていきました。
Server Actions は、API を経由せずにサーバー関数を直接呼び出せる機能です。
従来、
UI
↓ fetch
API Routes
↓
サーバーで処理
上記の流れで行っていた処理を、
UI
↓ （直接）
サーバー関数
サーバー関数を直接叩くことによって、APIによる中間レイヤーを不要とします。
Server Actionsを利用したい処理には、'use server'を付与します。
export default function Page() {
async function create(formData: FormData) {
'use server';
const id = await createItem(formData);
}
return (
<form action={create}>
<input type="text" name="name" />
<button type="submit">Submit</button>
</form>
);
}
公式ブログではServer Actionsを「プログレッシブエンハンスメント」（まず最低限の機能を純粋な HTML/HTTP の力だけで確実に動かし、その上に JavaScript などの高度な機能を後から載せるという考え）と共に紹介されています。
Next.js 14にて安定化したServer Actionsも、フルスタックフレームワークとして進化するNext.jsを語る上で欠かせない機能となりました。
変更点3 - Partial Prerendering（PPR）のプレビュー提供
Partial Prerendering（PPR）は15までexperimentalな機能でしたが、16にて発表された新たなexperimentalな機能である、Cache Componentsと統合されています。
Next.js 14にて、experimentalな機能としてPartial Prerenderingが発表されました。
Next.js 16にて発表された新たなexperimentalな機能である、Cache Componentsと統合されてしまいましたが、Next.js 14時点で発表されたPartial Prerenderingが提唱する新たなレンダリングの概念をここでは簡単にまとめます。
Partial Prerenderingは、ページの「変わらない部分」は事前ビルドしてキャッシュから即返し、「リクエストごとに変わる部分」だけは穴（ホール）として後からストリーミングで埋めるというレンダリングモデルです。
App Routerでも静的なページの一部を動的にすることは可能で、主には以下の二つの手法が採用されていました。
- SSG + Client fetch（CSRで動的部分を補う）
- Streaming SSR（SSRしつつ一部を遅延ストリーミング）
「ショッピングサイトにおいて、ユーザーのカート数だけ動的にしたい場合」を例に考えます。
手法1の、SSG + Client fetchではその名の通り、ページ全体・レイアウトは SSG し、カート数のような「ユーザー依存の情報」は Client Component の中で fetch します。
この方法でも確かに要件は実現できますが、HTTPラウンドトリップが複数回発生し、クライアントで API を叩くことによるUXの悪化が、場合によっては生じます。
手法2の、Streaming SSRでは、ページ全体を SSR（Server Component）で生成し、カート数だけを fetch(..., { cache: "no-store" }) でサーバー側 API 呼び出し、そして<Suspense> でカート部分を遅延ストリーミングすることとなります。
この方法だと、要件もクリアし、かつSSG + Client fetchで生じていた課題も一部クリアするものの、動的なコンポーネントによりページ全体が SSR となってしまいます。
このジレンマを解消するために、Next.js 14で実験的に導入された機能が、Partial Prerenderingです。
PPRはページをStatic renderingとしつつ、部分的にDynamic renderingにすることを可能とする機能です。
PPRが成し遂げたい世界を公式の説明の画像から引用します。
仕組みの詳細はここでは省略しますが、Next.js 14はサーバーサイドでのレンダリングを用いたフロントエンドのパフォーマンス向上にPPRで立ち向かおうとしていたのです。
Next.js 15 - React19への対応とキャッシュモデルの再定義
Next.js 15は、一言で言うと、
「React19への本格的な対応とキャッシュモデルの再定義」
と言えるでしょう。
Next.js 14と比較しても細かい変更点が多く、とても全て書ききれません。
当記事では開発体験を大きく変える、主要な変更点のみまとめますので、詳細は以下の公式ブログを参照していただけると幸いです。
Next.js 15
Next.js 15.1
Next.js 15.2
Next.js 15.3
Next.js 15.4
Next.js 15.5
変更点1 - React 19 への対応とReact Compiler
Next.js 15 ではReact 19 への対応が発表されました。
App Router が登場した Next.js 13 以降、Next.js は React と密接に歩調を合わせて進化してきましたが、Next.js 15 はその流れをさらに前に進めるものとなりました。
中でも特段、影響度の高い変更はReact Compilerのサポートです。
React CompilerはReactが自動で最適なメモ化を行ってくれる機能です。
React Compilerが登場する以前の以下のような実装を、
import { useMemo, useCallback, memo } from 'react';
const ExpensiveComponent = memo(function ExpensiveComponent({ data, onClick }) {
const processedData = useMemo(() => {
return expensiveProcessing(data);
}, [data]);
const handleClick = useCallback((item) => {
onClick(item.id);
}, [onClick]);
return (
<div>
{processedData.map(item => (
<Item key={item.id} onClick={() => handleClick(item)} />
))}
</div>
);
});
React Compilerを有効化することにより、
function ExpensiveComponent({ data, onClick }) {
const processedData = expensiveProcessing(data);
const handleClick = (item) => {
onClick(item.id);
};
return (
<div>
{processedData.map(item => (
<Item key={item.id} onClick={() => handleClick(item)} />
))}
</div>
);
}
このように実装できます。
（参考: React Compiler）
React Compiler自体はNext.js独自の機能ではなく、Meta社によって開発されているReactの機能ですが、Next.js 15においてexperimentalなサポートが開始され、Next.js 16でstableとなりました。
変更点2 - 非同期リクエストAPI
App Routerから、サーバーコンポーネントがデフォルトになり、Next.jsもサーバー側でのレンダリング最適化に力を入れています。
その一つに、Next.js 15で採用された、Async Request APIsがあります。
従来のサーバーサイドレンダリングでは、コンテンツをレンダリングする前に必要なリクエストの完了を待機する必要がありますが、当然すべてのコンポーネントがリクエスト固有のデータに依存するわけではありません。
そのため、Async Request APIsでは、cookies / headers / draftMode / params / searchParams など リクエスト依存の API がすべて async 化し、リクエスト到着前にできる限り、先にレンダリングを進められるようにする仕組みが導入されました。
変更点3 - キャッシュセマンティクスの変更
Next.js の難しさの一つは、キャッシュだと考えています。そのため、当記事ではレンダリング戦略には触れつつも、キャッシュについては触れてきませんでした。
Next.js 15ではそのキャッシュ戦略が大きく変更されました。
当記事では、Next.jsの詳細なキャッシュについての仕組みには踏み込まず、どんな流れの変化が生じたかについてのみの説明に留めます。詳細について深掘りしたい方は別途公式ドキュメント等を読んでいただけると幸いです。
（参考: Our Journey with Caching ）
Next.jsはApp Routerが登場して以降、Next.js 14でもパフォーマンスを優先した、かなり攻めたデフォルトキャッシュ機構を備えていました。明示的に動的を指定しない限り、デフォルトでキャッシュするという考え方が先行して設計されていたのです。
公式サイトによるとざっくり次の4つに分かれています。
- Request Memoization（リクエスト単位のメモ化）
- Data Cache（fetch 等で取得したデータの永続キャッシュ）
- Full Route Cache（HTML / RSC ペイロードの静的キャッシュ）
- Router Cache（クライアント側での RSC ペイロードキャッシュ）
しかし、この設計により、いつ/どこで/どのレイヤがキャッシュしているのかわかりにくく、キャッシュが原因で生じるバグや外部ライブラリの fetch と組み合わせた時の挙動が読みにくいといった欠点が生じていました。
そこで、Next.js 15では暗黙的なキャッシュを減らす方向へと舵が切られていきました。
一例として、公式サイトではfetchがデフォルトでキャッシュしなくなった例が紹介されています。キャッシュをさせたいときは、{ cache: 'force-cache' }を明示的に指定する必要があります。（キャッシュの明示的な指定方法については、Next.js 16にて発表されたCache Componentsでより直感的な宣言ができるようになりました。）
export default async function RootLayout() {
const a = await fetch('https://...') // Not Cached
const b = await fetch('https://...', { cache: 'force-cache' }) // Cached
// ...
}
キャッシュにより生じていた難しさに対応したのと同時に、同一ページのなかで、静的に生成できる部分はstatic renderingとしつつ、部分的にdynamic renderingにすることを可能とするPPR（Cache Components）の利用を見込んだ流れの修正が、Next.js 15には加わりました。
Next.js 16 - Cache Components と AI 時代へ対応
最後にNext.js 16です。
Next.js 16は2025年10月に発表された執筆時点（2025年12月）での最新バージョンとなります。
Next.js 16は、一言で
「Cache Components によるキャッシュ戦略の再設計と AI 時代に向けた機能拡充」
と言えるでしょう。
変更点1 - Cache Componentsによるキャッシュの再設計
（原文）Cache Components is a new approach to rendering and caching in Next.js that provides fine-grained control over what gets cached and when, while ensuring a great user experience through Partial Prerendering (PPR).
（日本語）Cache Components は、Next.js における新しいレンダリングおよびキャッシュ手法であり、「何を・いつ」キャッシュするかをきめ細かく制御できる一方で、Partial Prerendering（PPR）を通じて優れたユーザー体験も両立する仕組みです。
ここまでNext.js 14 ではPPRの導入、Next.js 15ではキャッシュセマンティクスの変更が行われ、Next.js がキャッシュに対し、これまでユーザーを悩ませていた暗黙的なキャッシュを減らしつつも、パフォーマンスを落とさずに可能な限り静的とする方向に向かっていたことがわかります。
Next.js 16ではその流れとしてPPRの仕組みが補完された、Cache Componentsが提供されました。
Cache Componentsについては公式ドキュメントに非常に丁寧にまとまっています。
当記事では、これまでのキャッシュ戦略と同様大まかな変更のみまとめますので、より深い仕組みや実装方法を知りたい方は別途ドキュメントを参照していただけますと幸いです。
Cache Componentsは、use cacheディレクティブを中心とする仕組みです。
これにより、App Router 上のすべてのルートは、デフォルトでキャッシュされず、「Dynamic by default」となり、（キャッシュされない部分に限り）サーバー処理が毎リクエスト実行される挙動、つまりキャッシュしたい箇所だけを use cache で明示するモデルに変わりました。
export async function getProducts() {
'use cache'
const data = await db.query('SELECT * FROM products')
return data
}
キャッシュは完全にopt-in（明示的に記載する）という設計となったのです。
さらに、このuse cacheに加えて、Next.js 14でexperimentalな機能として提供されていたPPRが統合し、よりPPRの利点を自然に利用できるようになりました。
これまで、Next.jsの難しさの要因、そしてパフォーマンスの柱となっていた
- PPRをはじめとしたレンダリングの仕組み
- 複雑なキャッシュ設計
が統合し、Cache Componentsとしてパフォーマンスについては可能な限り落とさずに、キャッシュとレンダリング戦略をよりシンプルな形で考えられるようになったのです。
変更点2 - Next.js Devtools MCP
Next.js 16から、ついにMCPサーバーが登場しました。
next-devtools-mcpによって、AIエージェントは一例として
- 現在のビルドエラー / ランタイムエラーの取得
- アクティブな ルート構成（app ルーティングのツリー） の把握
- サーバー / ブラウザ両方の統合ログの取得
- プロジェクト内の Server Actions の一覧 / 参照
上記のことが可能となります。
AIエージェント時代における開発者体験を向上させる機能が、公式から提供されました。
まとめ
大きな転換点、App Routerを理解して、Next.jsの変遷を追っていくことでNext.jsが歩もうとしている方向や、アップデートの背景が少し腑に落ちやすくなったのではないでしょうか。
変化が激しいNext.jsですが、この記事が皆様のNext.jsに対する理解度を上げるきっかけになれたら大変嬉しいです。
最後に、ここまでお読みになってくださった皆様、誠にありがとうございました！
参考資料
当記事を執筆するにあたって、先人の皆様の大いなる知見をお借りいたしました。
素晴らしい記事ばかりですので、この記事で足りない部分に関して、是非下記の記事も参照していただけますと幸いです。