カテゴリIの位置づけ
G章では画面の作り方を、H章では画面の設計を学びました。カテゴリIでは、その設計を実際に動くアプリへと変える実装に入ります。ここで使う道具が、参照スタックであるReactとNext.jsです。ただし最初の一歩は道具の使い方ではなく、フロントエンドがそもそも何を担当する層なのかをはっきりさせることです。担当範囲がわかって初めて、この先の実装が地に足のついたものになります。
このスライドのポイント
- G章: 画面の作り方
- H章: 画面の設計
- カテゴリI: それを「動くアプリ」にする実装
- 使う道具は参照スタックのReactとNext.js
フロントエンドの5責務とReact・JSX
フロントエンドの責任は、5つに整理できます。1つ目は表示、データを画面に映すことです。2つ目は入力の受付、G-04で見たフォームがこれにあたります。3つ目は画面状態の管理で、H-06で設計した状態の実装版です。4つ目は通信の開始、D-03で扱ったサーバーへの依頼を出すことです。5つ目はフィードバック、H-08で学んだ操作への反応を返すことです。この5責務を部品単位で書くための道具がReactで、その中で見た目を書く記法がJSXです。JSXはHTMLに似ていますが、JavaScriptの中に書く別物です。
このスライドのポイント
- フロントエンドの5責務: ①表示（データを画面に）②入力の受付（G-04のフォーム）③画面状態の管理（H-06の状態の実装）④通信の開始（サーバーへの依頼＝D-03）⑤フィードバック（H-08）
- React＝この5責務を部品単位で書くためのライブラリ
- JSX＝見た目をJavaScriptの中に書く記法（HTMLに似るが別物）
責任範囲を知らないと何に失敗するか
この責任範囲があいまいだと、バイブコーディングで困りごとが起きます。AIが生成したReactのコードを見ても、どこまでがフロントの仕事で、どこからがサーバーの仕事かを切り分けられません。これはD-01の役割の境界、H-05の内容の実装版の判断です。切り分けができないと、本来サーバー側に置くべき秘密情報や重要な判定がフロントに書かれていても気づけません。フロントのコードは利用者のブラウザに届く、中身の見える場所だからこそ、何を置いてよいかの線引きが安全性に直結します。
このスライドのポイント
- AI生成のReactコードで「何がフロントの仕事・何がサーバーの仕事か」を切り分けられない（D-01・H-05の実装版）
- 秘密情報や重要な判定をフロントに書いてしまう事故を見抜けない
フロントの5責務と「やってはいけないこと」
全体像を、担う仕事とやってはいけないことの対比で押さえます。フロントが担うのは、表示・入力の受付・画面状態の管理・通信の開始・フィードバックの5つです。反対に、やってはいけないこともあります。1つは防御としての検証で、これはサーバー側が担当し、詳細はカテゴリJで扱います。もう1つは秘密情報を持つことで、B-09やQ章で触れた通りフロントには置けません。フロントは「見せる・受け取る・状態を持つ・依頼を出す・反応を返す」までで、最後の砦を守る役ではありません。
このスライドのポイント
- フロントが担う: 表示／入力の受付／画面状態の管理／通信の開始／フィードバック
- フロントがやってはいけない: 防御としての検証（サーバー側の仕事＝カテゴリJで扱う）／秘密情報の保持（B-09・Q章）
- 「見せる・受け取る・状態を持つ・依頼を出す・反応を返す」までがフロント
経費申請画面を5責務に分解する
具体例として、経費申請画面の動作を5責務に分解してみます。過去の申請一覧を見せるのが表示、金額を打ち込む欄が入力の受付です。送信から完了までの「送信中」という状態を持つのが画面状態の管理、その内容をサーバーへ保存してもらうよう頼むのが通信の開始です。そして「申請しました」と画面に返すのがフィードバックです。1つの画面が、5つの責務へ分かれました。この分解の視点が、以降9講義の地図になります。
このスライドのポイント
- 一覧の表示＝①表示
- 金額の入力＝②入力の受付
- 送信中の状態＝③画面状態の管理
- 保存の依頼＝④通信の開始
- 完了の表示＝⑤フィードバック
- この分解が、以降9講義の地図になる
技術サンプル: 5責務と担当講義の対応表
この講義の技術サンプルは、コードではなく地図です。フロントの5責務が、カテゴリIのどの講義で実装として埋まるかを対応表にしました。表示はI-05、入力の受付はI-06、画面状態の管理はI-04、通信の開始はI-10で扱い、これらの土台になる部品化をI-02とI-03で学びます。読み方のポイントは、カテゴリIがこの地図を1つずつ埋めていく構成だという点です。AIにコードを見せるときは、質問例のように「この部品は5責務のどれを担当し、サーバー側の処理が混ざっていないか」を聞くとよいでしょう。
「フロントで確認」と「フロントで防御」の違い
混同しやすい1組を再確認します。「フロントで確認する」と「フロントで防御する」は、似ていても役割がまったく違います。フロントでの確認は、H-05で学んだ親切としての案内で、たとえば空欄のまま送らせないよう、その場で気づかせることです。一方、フロントでの防御は成り立ちません。フロントのコードは利用者側にあり、書き換えられてしまうからです。本当に守る防御はサーバー側の仕事で、詳細はカテゴリJで扱います。いまは「フロントの確認は親切、防御はサーバー」と握っておいてください。
このスライドのポイント
- フロントでの確認（H-05）: 利用者に早く気づかせる「親切」。例: 空欄のまま送信させない案内
- フロントでの防御: 不可能。フロントのコードは利用者側で書き換えられるため、最後の砦にはならない
- 本当の防御はサーバー側の仕事（詳細はカテゴリJ）
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIにフロントのコードを書かせたら、毎回「秘密情報・重要な判定・防御の検証が、フロントに紛れ込んでいないか」をチェックします。含まれていたら、そのままにせず「その処理はサーバー側へ移してください」と指示します。AIは指定がなければ、動くことを優先して境界を越えたコードを書くことがあります。だからこそ人間が線引きの番人になります。具体的には「このコンポーネントに、サーバー側に置くべき処理は混ざっていませんか」と聞くのが有効です。
このスライドのポイント
- AIが書いたフロントのコードには毎回確認: 「秘密情報・重要な判定・防御の検証が含まれていないか」
- 含まれていたら「サーバー側へ移して」と指示する
- 質問例:「このコンポーネントに、サーバー側に置くべき処理は混ざっていませんか」
まとめと次回
一問一答です。入力値の防御的な検証は、フロントとサーバーのどちらの責任でしょうか。……答えはサーバーです。フロントができるのは親切としての確認までで、防御はサーバーの仕事でした。30秒でまとめます。フロントの5責務は、表示・入力の受付・画面状態の管理・通信の開始・フィードバックの5つ。そして防御と秘密情報はフロントの外に置く。この2点が今日の芯です。次回は、画面を部品に分けるコンポーネントへ進みます。「Webアプリ構築 完全ワークフロー」「UI改善プロンプト50」もあわせて確認しておきましょう。
このスライドのポイント
- 一問一答:「入力値の防御的な検証は、フロントとサーバーのどちらの責任？」
- 30秒まとめ: フロントの5責務は表示・入力の受付・画面状態の管理・通信の開始・フィードバック。防御と秘密情報はフロントの外
- 次回: 画面を部品に分けるコンポーネントへ
- 関連資料:「Webアプリ構築 完全ワークフロー」「UI改善プロンプト50」
