前回の続きと、この講義の役割
前回のI-08では、URLと画面を対応させるルーティングと、共通の外枠を1箇所で定義するレイアウトを学びました。フォルダ構成がそのままURLになる仕組みまで見ています。今回はその一歩先、1つの画面の中に引かれる、もう1つの境界を扱います。D-01で学んだ役割の境界が、画面を作るコンポーネント1つずつのレベルまで細かくなった話だと考えてください。
このスライドのポイント
- I-08: URLと画面を対応させるルーティング、共通の外枠を1箇所で定義するレイアウト
- 今回は「1つの画面の中」に引かれる、もう1つの境界
- D-01の「役割の境界」が、コンポーネント単位まで細かくなった話
2つの実行場所
Next.jsのコンポーネントには、実行される場所が2種類あります。サーバーコンポーネントは、サーバー側、F-01で見たNode.jsの側で実行され、その結果がHTMLとしてブラウザへ届きます。データの取得に向いていて、秘密情報も扱えます。もう一方のクライアントコンポーネントは、ブラウザの中で実行され、I-04からI-06で学んだstateやイベントを使えます。対話性が必要な部分だけを、こちらにします。D-01の役割の境界が、画面を作るコンポーネント1つずつのレベルまで細かくなった形です。
このスライドのポイント
- サーバーコンポーネント: サーバー側（F-01のNode.js側）で実行され、HTMLとして届く。データ取得に向き、秘密情報を扱える
- クライアントコンポーネント: ブラウザで実行され、state・イベント（I-04〜06）が使える。対話性が要る部分だけこちらにする
- D-01の「役割の境界」がコンポーネント単位まで細かくなった形
なぜこの境界が必要か
この境界を知らないと、AIが生成したコードにある「'use client'」という一行が何を意味するのか読めません。その結果、2つの極端な失敗に気づけなくなります。1つは、全部をクライアントコンポーネントにしてしまうこと。表示が重くなり、サーバー側にしか置けないはずの秘密情報がブラウザへ漏れる危険が生まれます。もう1つは、全部をサーバーコンポーネントにしてしまうこと。stateもイベントも使えないので、ボタンを押しても何も起きない画面になります。どちらもAIはやりがちなので、人間が境界を判断する必要があります。
このスライドのポイント
- 境界を知らないと、生成コードの「'use client'」の意味が読めない
- 全部クライアント: 表示が重い・秘密情報がブラウザへ漏れる危険
- 全部サーバー: stateもイベントも使えず、押しても動かない画面
- どちらもAIはやりがち。人間が境界を判断する
境界は「画面の中」に引く
境界は、画面の外か中かではなく、画面の中に引かれます。1つのページの中で、一覧の表示のような部分はサーバー側で取得して表示し、検索ボックスや申請ボタンのような部分だけをクライアント側にします。原則はシンプルです。枠はサーバー、対話の島だけクライアント、と覚えてください。既定はサーバー側で、stateかイベントが必要になった小さな部分だけを、島のようにクライアント側へ切り出すイメージです。
このスライドのポイント
- 境界は画面の外か中かではなく、画面の中に引かれる
- 一覧の表示 = サーバー側／検索ボックス・申請ボタン = クライアント側
- 原則: 枠はサーバー、対話の島だけクライアント
- 既定はサーバー側、stateかイベントが要る小部分だけを島として切り出す
経費一覧ページでの分け方
経費一覧ページで考えます。一覧データの取得と表示は、サーバーコンポーネントに任せます。データに近い場所で処理でき、速く、秘密情報も安全に扱えるからです。一方、行を削除するボタンや、条件で絞り込む検索欄は、クライアントコンポーネントにします。ここはstateとイベントが必要になる部分だからです。同じ1ページでも、静かに表示するだけの部分と、利用者が触って動く部分で、担当を分ける。これが境界の引き方の実際です。
このスライドのポイント
- 一覧データの取得と表示 = サーバーコンポーネント（データに近い・速い・安全）
- 行の削除ボタン・絞り込みの検索欄 = クライアントコンポーネント（stateとイベントが必要）
- 同じ1ページでも、表示だけの部分と、触って動く部分で担当を分ける
技術サンプルカード
図は、経費一覧ページの中に引かれた境界を示しています。一覧の取得と表示はサーバー側、データに近く、秘密も扱えます。検索ボックスと申請ボタンはクライアント側、stateとイベントが必要だからです。判断基準は1つ、その部分がstateかイベントを使うかどうか。使うならクライアント側です。既定はサーバー側に置き、対話の必要な島だけをクライアント側にする。そして秘密情報はサーバー側にしか置けない、というI-01の原則を、ここでもう一度確認してください。
混同しやすい概念
混同しやすいのが、名前のよく似た2つです。1つは、いま学んでいるサーバーコンポーネント。これはNext.jsの中で、コンポーネントをどこで実行するかという話です。もう1つは、サーバーそのもの。こちらはこの先のカテゴリJで扱う、サーバー側の実装全体を指します。名前は似ていますが、層が違います。サーバーコンポーネントは画面を作る部品の実行場所の話、サーバーそのものはその奥にある仕組みの話、と切り分けてください。
このスライドのポイント
- サーバーコンポーネント: Next.jsの中で、コンポーネントをどこで実行するかの話
- サーバーそのもの: この先のカテゴリJで扱う、サーバー側の実装全体
- 名前は似ているが層が違う（画面を作る部品の実行場所 vs その奥の仕組み）
バイブコーディングでの確認点
バイブコーディングでは、AIが生成した画面のコードに対して、毎回2つを確認してください。1つ目は、クライアントコンポーネントが最小限になっているか。対話の要らない部分までクライアント側になっていたら、サーバー側へ戻すよう指示します。2つ目は、秘密情報がクライアント側に漏れていないか。ブラウザで動く部分に秘密が書かれていたら、必ずサーバー側へ移させます。質問例は、このページでクライアントコンポーネントになっているのはどれで、それぞれ何のためですか、です。
このスライドのポイント
- 確認1: クライアントコンポーネントは最小限か（要らない部分はサーバー側へ戻す）
- 確認2: 秘密情報がクライアント側に漏れていないか（漏れていたらサーバー側へ移す）
- 質問例: 「このページでクライアントコンポーネントになっているのはどれで、それぞれ何のためですか」
一問一答とまとめ
最後に一問一答です。stateとイベントが使えるのは、どちらのコンポーネントでしょうか。（間）答えは、クライアントコンポーネントです。サーバーコンポーネントはデータ取得と表示に向き、対話はできません。30秒でまとめます。Next.jsのコンポーネントには実行場所が2種類あり、既定はサーバー側、stateかイベントが必要な対話の島だけをクライアント側にします。秘密情報はサーバー側だけ、が鉄則です。次回はカテゴリI最終回、データをどこで取り、いつまで使い回し、いつ取り直すかという鮮度の設計へ進みます。関連資料は「Webアプリ構築 完全ワークフロー」と「AIアプリのセキュリティ超入門」です。
このスライドのポイント
- 一問一答: stateとイベントが使えるのはどちらのコンポーネント？ → クライアントコンポーネント
- 30秒まとめ: 実行場所は2種類。既定はサーバー側、対話の島だけクライアント。秘密はサーバー側だけ
- 次回: I-10 データ取得・キャッシュ・再検証（鮮度の設計）
- 関連資料: 「Webアプリ構築 完全ワークフロー」「AIアプリのセキュリティ超入門」
