はじめに：再び現れた「おまじない」の必要性
Next.js ブログにスマートフォン用のハンバーガーメニューを実装していたとき、またあのエラー画面に遭遇しました。
実は、前回の第 13 回補足（コードブロックのシンタックスハイライト実装）の際にも、同じようにシステムの先頭に 'use client' と書かなければ動かない場面がありました。
1回目は「エラーが出たから、とりあえず指示通りに書く」という、いわば「おまじない」のような感覚でした。しかし今回、2回目となる同じ壁にぶつかったことで、ようやく「なぜこれが必要なのか」が自分なりの言葉で説明できるようになった気がします。
サーバーとクライアントの役割分担
Next.js（App Router）では、画面の部品はデフォルトで 「サーバーコンポーネント」 として扱われます。これを整理すると、私の中では以下のような理解になりました。
- サーバーコンポーネント： VPS（サーバー）側で HTML を組み立ててからブラウザに送る仕組み。あらかじめ完成品を送るため表示が速いが、ユーザーが画面上で起こす「動き」には直接反応できない。
- クライアントコンポーネント： ブラウザ側で JavaScript が動く仕組み。ボタンのクリックやメニューの開閉など、ユーザーの操作に合わせてリアルタイムに画面を変化させることができる。
今回実装したハンバーガーメニューには、 React の機能である useState（メニューが開いているか閉じているかの状態を記憶するもの）を使用しました。
tsx'use client'; import Link from 'next/link'; import { useState } from 'react';
この useState はクライアントコンポーネントでしか使えません。ユーザーが三本線アイコンをタップするたびにメニューが飛び出すという「対話的な動作」は、サーバー側で事前には準備できないからです。
腑に落ちた判断基準：ユーザーに反応するかどうか
結局、いつ 'use client' を書けばいいのか。私は以下のように判断基準を持つことにしました。
「その部品が、ユーザーの操作に反応する必要があるかどうか」
記事の文章や画像を表示するだけの部分は、サーバーに任せておけば最高に速い。けれど、今回のメニューのように「タップで開く」「クリックで閉じる」といった、ユーザーとサイトのやり取り（インタラクション）が発生する場所には、ブラウザ側で動いてもらうための宣言が必要になるのだと、ようやく腑に落ちました。
ヘッダーをクライアントコンポーネントにしてもいいのか？
ここで一つ悩んだことがありました。「クライアントコンポーネントは、サーバーコンポーネントよりも初期表示がわずかに遅くなる」という点です。
サイトの顔であるヘッダーをクライアント側に寄せてしまうことに、最初は少し抵抗がありました。
しかし、私のブログのヘッダーはデータベースや外部 API から情報を取ってくるような重い処理は含んでいません。あくまでデザインとしてのナビゲーションリンクが並んでいるだけです。この程度の静的なコンテンツであれば、クライアントコンポーネントに切り替えたとしても、体感できるほどの遅延は発生せず、実用上の問題はないと判断しました。
まとめ：メリハリのある設計
「基本はサーバー、動きが欲しいときだけクライアント」。
この原則を理解できたことで、次にエラーが出たときも「ああ、ここはブラウザで動く必要があるからだね」と落ち着いて対応できそうです。非エンジニアにとって Next.js の仕組みは複雑に感じますが、こうして一つずつ「なぜそれを選んだか」を積み重ねていく過程が、サイト構築の醍醐味だと感じています。
メインブログでは、実装の手順を詳しく解説しています。
