データフェッチの使い分けを「高級フレンチ」で例えたら一瞬で理解できた話

2026年5月27日 17:29

こんにちは！プロジェクトマネージャーとして全体の「効率化」を考えつつ、裏ではGitHubにゴリゴリ草を生やしている、午年（うまどし）エンジニアの筆者です。

Next.js（App Router）を触っていると必ず直面する、「これ、Server Componentでフェッチするべき？それともClient Component（use client）でフェッチするべき？」という問題。

「どっちでも動くからいいや」と適当に作っていると、パフォーマンスがガタガタになったり、セキュリティ崩壊の危機に瀕したりします。PM視点で見ても、これは大問題です。

今日はこの複雑なデータフェッチを、誰もが憧れる「高級フレンチ」に例えて、一瞬で腑に落ちるように解説します！

基本、Next.jsのデフォルトである「Server Component」でのデータ取得は、レストランの厨房（キッチン）で行う調理です。

秘伝のソース（APIキー）を隠せる: お客さん（ブラウザ）に見えない裏側でデータを取ってくるので、大事なデータベースのパスワードやAPIキーが漏洩しません。セキュリティは鉄壁です。
客席に届いた瞬間、すぐ食べられる: サーバー側でデータをすべてお皿に盛り付けた状態（HTML）にしてからブラウザに送るので、画面の表示が爆速になります。

「重たい処理や、見せちゃいけない秘密のレシピはすべて厨房（サーバー）で済ませる」。これが基本のキです。

一方で、use client を使った「Client Component」でのフェッチは、お客さんの目の前（客席）で行う仕上げの調理です。

リアルタイムの対話: 「お肉の焼き加減はいかがですか？」「もっとソース（データ）を追加して！」という、ユーザーのボタン操作（Clickイベント）や検索窓への入力に連動してデータを取るときに使います。
料理が届いてからコンロで温める: ブラウザ側で「よっこらしょ」とデータを取得しにいくため、ボタンを押した後のローディング表示（スピナーなど）の実装が必要になります。

使い分けは超シンプル。「動かない料理は厨房（サーバー）で、お客さんが味付けを変える料理は客席（クライアント）で！」です。

プロジェクトを管理する立場から見ると、この使い分けは「お店の回転率（UX）」に直結します。

何でもかんでも客席で調理（クライアント側でフェッチ）させていたら、客席は煙まみれになり、料理が出るのも遅くなり、最悪の場合はお店の評判（離脱率）が下がります。

まずは厨房（Server）でガッツリ作って、最後の「いいねボタン」や「検索フィルター」だけを客席（Client）に任せる。この美しい連携をObsidianにメモし、GitHubにPushした時、あなたのWebサイトは「三ツ星レストラン」へと進化するのです。

「なんとなく動くコード」から「洗練された超一流のアーキテクチャ」へ。Next.jsの本当の強みを引き出すなら、この一冊がバイブルになります。

『TypeScriptとReact/Next.jsでつくるECサイト開発』実践的なECサイト構築を通して、ServerとClientのリアルなデータの受け渡し（Server Actionsなど）が学べます。現場で「これ、どっちに書くべき？」と迷わなくなるための投資として、これ以上ない一冊です。

100本ノックも中盤戦。長距離を走り続けるランナーでもある筆者が、コーディングでバキバキになった体を「即座にリカバリー」するために愛用している秘密兵器がこちら。

デスクワークで固まったお尻やふくらはぎを、強烈な振動で一気に解きほぐします。血流が「Edge Runtime」並みの爆速で循環し始め、脳がシャキッとしてバグ発見のスピードも上がります。

]

📝 45日目の課題