[Next.js #05] App Router の“基本 UI 構造”を理解する：layout / page / component / client-server の境界

はじめに

以前のような覇気を失い、体調は余り良くなく、実装もあまり進まず。

Unityの３日連続トラブルで、全く進まなかった後遺症を未だに引きずってるというか、今まで走り続けて進めなくなった事で、燃え尽き症候群みたいになってます。

自分の書いたコードや、過去記事を読み直すと異常な速度で学習と実装を繰り返してきた事を実感しますが、コードは読めるし修正も出来るので、忘れたわけでもない。

走り続けてきた自分が他人みたいに感じますね…。

AIにも、異常な速度だとは言われてましたが実感はないというか、目の前の実装をする事だけを考えて日々探究と学習を繰り返してたので、実感は全くないです。

Redditとかみると、海外の達人が書いた素晴らしいThree.jsアプリがあるので、それに追いつこうと研究と努力を重ねた結果だと思います。

只管、学習記事を書き続けるだけだったので、これからはアウトプットでYoutubeに動画を少しずつアップして行こうかとは思ってます。

意味があるかどうかは分からないですが、出来る事をやる、今までもそうやってきたので。

マーケティングとかやり方があるのは知ってますが、金儲けやアクセスの為にやりだすと、自分を見失うので、そこは意識しないようにしたいです。
そうじゃないと、アクセスや金の為だったら何でもやる、金の亡者みたいになるので。
今のYoutubeがそういう輩で溢れかえってるので、好きじゃないけど、そのメディア媒体に投稿するしかないという…。

私生活でも、殆ど何処にもいかず、家事も私が全部やってるので、食費を切り詰める生活、ただ、魚と野菜とか健康管理はしっかりやる。 外食は一切しない、全て自炊で、早朝４時にまとめて一日分作って時間節約。

そういう生活努力の先で時間を奪われたUnityにはほんとに参りましたね…。

あと、買いたい物もなく貯金がたまってきたので、Youtubeみて困ってる人を見て放っておけない性分なので、１万円のスパチャを２回も投げるという…。 ちょっとやり過ぎたかなと、後で少し後悔しましたが、お金が減った分、また生活を切り詰めて自炊に力を入れる感じです。損失もまた生きる原動力になる。

スキルもお金も、失わないと何かを得られないという、感覚はずっとありますね。棚ぼたを求める人がYoutube見ても異常に多いけど、その考え方には賛同できないです。

どうでもいい余談は置いておいて、今日は、緩い学習記事で、Next.jsの基礎に立ち返ろうという内容です。

前回の記事：

この回のゴール

  • Next.js(App Router) の UI の骨格

    • layout.tsx （外枠）
    • page.tsx （ページ本体）
    • components/ （小さく分割）

  • Server Component / Client Component の境界

  • Image / Link / メタデータの正しい使い方

  • R3F や WebXR の “土台” が分かるようになる

#05 は、難しいことを一切しない。
「Next.js の UI 思想を理解しておくと、後が10倍ラク」 という “地固め回”。

1. Next.js の UI は「階層」で考える

Next.js（App Router）でまず理解すべきなのは、 “UI はフォルダ階層の通りに構成される” という思想。

React は「UI = コンポーネントの組み合わせ」で成り立っている。 Next.js はそれを フォルダ構造と強制的に同期 させる。

app/
 ├ layout.tsx      ← すべてのページ共通の外枠
 ├ page.tsx        ← トップページ（/）
 └ about/
      └ page.tsx   ← /about

つまり：

UI = 関数のネスト = フォルダのネスト

という、とてもシンプルで強い思想。

layout.tsx：サイト全体の外側

layout.tsx は “全ページに共通する UI” を定義する場所。

具体的には：

  • ヘッダー / フッター
  • グローバルナビ
  • ボディ全体のスタイル
  • 共通のラッパー構造

たとえるなら 「家の外枠と土台」 の役割。

この layout の中に children が入り込み、各ページが“埋まる”。

page.tsx：ページ本体

一方 page.tsx は、そのフォルダが表す URL の中身そのもの 。

  • 固有の文章や画像
  • そのページだけの UI
  • コンポーネントを組み合わせて構築

こちらは 「各部屋の内装」 というイメージ。

まとめ：階層さえ理解すれば Next.js は怖くない

Next.js が難しく見えるのは、 構造を理解する前に R3F や動的処理に飛び込むから 。

まずはこの2層構造を押さえるだけで、 Next.js の UI 設計は “一気に理解できる領域” に入る。

layout = 外枠 page = 中身 components = 部品

これだけで十分戦える。

2. 最小の layout.tsx を書いてみる（基礎の基礎）

Next.js(App Router) の UI は layout.tsx を理解するだけで半分クリア できる。 まずは、もっともシンプルな layout を書いてみる。

// app/layout.tsx
export default function RootLayout({ children }) {
  return (
    <html lang="ja">
      <body className="font-sans bg-zinc-50">
        <header className="p-4 text-xl font-bold">My Site</header>
        <main className="p-6">{children}</main>
        <footer className="p-4 text-center text-sm text-gray-500">
          © 2026 lain
        </footer>
      </body>
    </html>
  );
}

ポイント解説

1. children が “ページ本体”

layout.tsx は 外枠だけを返す 。 実際の中身（トップページや他ページ）は children として挿入される。

  • layout = 枠
  • children = 中身

この関係が理解できれば、Next.js の App Router の動きが腑に落ちる。

2. layout は「テンプレート」

ヘッダー、フッター、ナビゲーション、共通スタイルなど、 全ページで使う UI は全部ここに書く。

React の “親コンポーネント” と同じ発想だが、 Next.js はそれをフレームワークとして強制してくれるので、構造が乱れない。

3. ページを増やしても layout は 1つでOK

/about /blog /contact …とページが増えても、

  • ヘッダー
  • デザイン
  • ページ全体の骨格

は layout がすべて担当するので、各 page には中身だけ書けばよい。

＝保守性が圧倒的に高くなる

R3F / WebXR の Canvas を置ける位置も分かる

実際に 3D を扱う時、 Canvas を layout に置くか、page に置くか の判断で迷う人が多い。

この layout の仕組みが理解できると判断が簡単になる。

  • サイト全体で 3D を常時動かしたい → layout
  • ページ単位で 3D を切り替えたい → page
  • ゲームボックスのような専用エリア → component

この回で「UI の地図」を持てるようになるのが狙い。

3. page.tsx：実際のページは超シンプルでいい

page.tsx は、App Router において URL そのものを表す関数コンポーネント 。 特別な class も、継承も、設定ファイルもいらない。

Next.js の強みは “ページの作り方が極端にシンプル” なところにある。

最小の page.tsx の例

// app/page.tsx
import Hello from "./components/Hello";

export default function Page() {
  return (
    <div className="space-y-6">
      <h1 className="text-2xl font-bold">Next.js Sample</h1>
      <Hello />
    </div>
  );
}

やっていることは本当にこれだけ：

  • ページの内容を書く
  • 必要ならコンポーネントを import する
  • JSX を返す

React の関数コンポーネントと同じ発想のまま。

page.tsx は “ただの関数”

Next.js では、ページを作るのに クラスや継承は一切必要ない 。

  • 余計な抽象化なし
  • 関数を export するだけ
  • React の延長線で書ける

この “シンプルさ” が Next.js のUI構築を圧倒的に早くする。

ページが増えてもやることは同じ

例えば /about を作るなら、 app/about/page.tsx を置くだけで完成。

app/
 └ about/
      └ page.tsx  ← これだけで /about ができる

URL とフォルダがそのまま一致するため、迷わない。

4. components/ へ切り出す感覚を掴む

Next.js は React の上に成り立っている。 だから、 UI を小さく分割する“React の鉄則” はそのまま適用できる。

大きい UI は必ず小さくして再利用する。

ページが複雑になるほど、 小さなコンポーネントに分解しておくメリットは大きい。

最小のコンポーネント例：Hello.tsx

// app/components/Hello.tsx
export default function Hello() {
  return <p>Hello Component!</p>;
}

コンポーネント化すると：

  • UI の再利用ができる
  • 読みやすくなる
  • page.tsx がシンプルに保てる
  • 機能ごとに責務を分離できる

Next.js でも、React と同じ “部品化” の思想がそのまま生きる。

components/ は “自分のUIパーツ集”

app/components/ フォルダは、 lain が作る UI 部品置き場 として使えばよい。

  • ボタン
  • カード
  • UIフレーム
  • 記事パーツ
  • R3F の 3Dモデル表示
  • ゲームボックスの切替UI

全部ここに置ける。

Next.js は、このフォルダに特別な制限を設けていないので、 “React流のコンポーネント管理” がそのまま使えるのが強み。

5. Client Component / Server Component を一度整理

Next.js(App Router) で初心者が一番つまずくのが、 Server Component と Client Component の違い 。

でも本質は驚くほどシンプル。 “UI が動くかどうか”——ただそれだけ。

Server Component（デフォルト）

Next.js の基本は Server Component。

  • デフォルト（書くだけで全部これ）
  • 高速
  • SEO 向き
  • useState / useEffect が使えない
  • UI が「静的に」描画される部分は全部ここでOK

基本的には 8〜9割を Server Component にして問題ない。

Client Component（“use client” が必要）

ファイルの先頭に "use client" を書いたときだけ、 そのコンポーネントは Client Component になる。

"use client";

Client Component が必要なのは、 UI が動く場合だけ 。

  • ボタンクリック
  • アニメーションの発火
  • useState / useEffect
  • イベントリスナー
  • R3F の <Canvas />（これは100% client）

Next.js は “動的 UI の部分だけ” を Client にする思想。

判断基準はこの1行で十分

UIが動く → Client
UIがただ表示されるだけ → Server

これ以外に難しいルールは存在しない。 Next.js の設計思想がめちゃくちゃミニマルだから成立する話。

R3F / WebXR を置く時にもこの基準が有効

  • R3F の <Canvas /> → 動くので Client
  • WebXR の VR/AR 処理 → Client
  • 3D を飾りとして背景表示するだけ → Server or Client（構成次第）
  • UI パネルや説明文 → Server

3Dより UI の方が Server Component で軽い、という逆転現象も普通にある。

Next.jsの強みはここで、“動くところだけ Client にする” と全体が速くなる。

6. Next.js 公式コンポーネントの基礎（Image / Link）

Next.js には、 「普通の HTML ではなく、Next.js 流に最適化された UI コンポーネント」 が用意されている。

特に重要なのが Image と Link の2つ。

この2つを正しく使えるだけで、 Next.js の “速度・最適化メリット” を自然に享受できる。

Image コンポーネント

Next.js の Image は、普通の <img> より高性能。

import Image from "next/image";

<Image src="/next.svg" width={120} height={40} alt="Next.js" />

何が良いのか？

  • 自動で画像を最適化（WebP変換など）
  • レイアウトシフトが起きない（CLS対策）
  • 遅延読み込み（lazy load）標準搭載
  • width / height を指定するだけでOK

ブログやポートフォリオ、商品画像など、 Next.js で画像を扱うなら基本的に <Image /> 一択 。

Next.js の Link は SPA らしくページ遷移を高速化する。

import Link from "next/link";

<Link href="/about">About</Link>

特徴

  • <a> ではなく <Link> を使う
  • ページ遷移が高速（クライアント遷移）
  • プリフェッチ（先読み）で体感速度が上がる
  • SEO 的にも問題なし（サーバー側で正しく扱われる）

シンプルだが、Next.js で “サイト全体の速さ” を作る重要な要素。

まとめ：この2つは Next.js の基本の基本

  • <Image> → 画像表示の最適解
  • <Link> → 次ページを高速に開く近道

Next.js サイトを作るうえで最初に身につけるべき “公式の流儀”。

この2つが自然に使えるようになると、 UI実装が 「Next.js らしい書き方」 に寄っていく。

7. メタデータ（SEO）の最小実装

Next.js（App Router）では、 ページごとの SEOメタデータ を簡単に定義できる。

基本形はこれだけ。

export const metadata = {
  title: "Next.js sample",
  description: "App Router basic",
};

なぜ重要か？

  • Google に正しく内容を伝えられる
  • SNS のサムネイルと文章が正しく表示される
  • 記事タイトル・概要が一貫して整う
  • ページ数が増えても SEO 設計が崩れない

特にブログ連載や技術記事では、 小さな SEO 積み重ねが後で効く 。

Next.js のメタデータは App Router の恩恵で TypeScript で補完される ので、 書き間違いも起こりにくい。

習慣化すると強い

  • 新しい記事を作る
  • metadata を書く
  • 内容を微調整する

これを毎回やるだけで、 サイト全体の SEO 品質が自然と安定する。

“コードを書く前に metadata を書く” くらいの感覚でちょうどいい。

8. まとめ：地固めすると後が10倍ラクになる

この回で扱った内容は、どれも Next.js(App Router) の“基礎の基礎”。

  • layout / page / components → UI を階層で理解する
  • client / server の境界 → 動く部分だけ Client にする
  • Image / Link の公式コンポーネント → Next.js の最適化を自然に使う
  • 最低限の metadata (SEO) → 記事が増えても崩れない基盤を作る

これらを理解すると、 Next.js の UI 開発は “直線的に進む” ようになる。

そしてこの地固めができていると、 次のステップ——

#06：R3F × Next.js の統合 （3D・Canvas・インタラクションの本番）

が一気に楽になる。