第1章 Webアプリの登場人物
📖 この章のゴール：Webアプリが「魔法」ではなく、4人の登場人物の連携で動いていることが分かる。 ← 目次・はじめにへもどる
📱 Twitterではこう見える
Twitter（X）を開くと、投稿がずらっと並んでいます。文章を書いて「ポスト」ボタンを押すと、自分の投稿が一番上に増えます。スマホでもパソコンでも、別の人の画面でも、同じ投稿が見えます。
あたりまえに使っていますが、この裏側では何が起きているのでしょう？ ここが分かると、これから作るものが「魔法」ではなく「部品の組み合わせ」に見えてきます。
🤔 登場人物は4人（🟢 基礎）
Webアプリは、ざっくり 4人の登場人物 で動いています。レストランにたとえると分かりやすいです。
| 登場人物 | 役割 | レストランでいうと |
|---|---|---|
| ブラウザ | あなたが見て・触る画面 | 席に座っているお客さん（あなた） |
| API（窓口） | 注文を受け渡しする窓口・メニュー | 注文を取りにくるウェイター |
| サーバー | 注文を処理する司令塔 | 料理を作るキッチン |
| データベース | データをしまっておく倉庫 | 食材をしまう冷蔵庫・倉庫 |
ひとつずつ、もう少しだけ。
- ブラウザ（Chrome や Safari）… あなたの目の前にある画面です。ボタンを押したり文字を打ったりするのは、全部ここ。
- サーバー（さーばー）… ネットの向こうにある、いつも動いているコンピュータ。注文を受けて「保存して」「探してきて」を実際にやる司令塔です。
- データベース（でーたべーす、略してDB）… データをしまう倉庫。イメージは 超巨大な表計算（Excel）。1行が1件のデータです。
- API（えーぴーあい）… ブラウザとサーバーをつなぐ 「注文窓口」とそのメニュー。「この投稿を保存して」「最新の投稿をちょうだい」といった注文の決まった受け渡し口です。
🍔 たとえ話：あなた（ブラウザ）は、冷蔵庫（データベース）を直接あさったりしません。ウェイター（API）にメニューから注文し、キッチン（サーバー）が冷蔵庫から食材を出して料理してくれる。お客さんが勝手に厨房や冷蔵庫に入らない——これは後で出てくる「データを守る」話にそのままつながります。
🔁 「あなたのツイートが画面に出るまで」
2つの場面で、4人がどう動くか追ってみましょう。
① ツイートを投稿するとき
あなた（ブラウザ）
│ 「この文章を保存して」とお願い
▼
API（窓口）
│ 注文をサーバーに渡す
▼
サーバー（司令塔）
│ データベースに1行 追加
▼
データベース（倉庫） ← ここに投稿が保存される
│ 「保存できたよ」
▼
あなたの画面が更新され、投稿が一番上に増える
② タイムラインを見るとき
あなた（ブラウザ）
│ 「最新の投稿をちょうだい」
▼
API（窓口） → サーバー（司令塔）
│ データベースから新しい順に取り出す
▼
データベース（倉庫）
│ 投稿のデータを返す
▼
あなたの画面に、投稿がずらっと並ぶ
ポイントは、投稿は「あなたのスマホの中」ではなく、ネットの向こうのデータベースに保存されていること。だからこそ、別の人の画面からも同じ投稿が見えるのです。
🛠 Supabaseだと、3人は用意済み（🟢 基礎）
ふつう、サーバー・データベース・APIを自分でゼロから用意するのは大変です。でも、この教材で使う Supabase（すーぱーべーす） は、
サーバー ＋ データベース ＋ API（窓口）を、最初からまとめて用意してくれます。
つまりあなたが作るのは、おもに ブラウザ側（画面） だけ。あとはSupabaseの窓口に「保存して」「取り出して」とお願いするだけです。
あなたが作る Supabaseが用意してくれる
┌──────────┐ ┌───────────────────────────┐
│ ブラウザ │ ──→ API ──→ │ サーバー ＋ データベース │
│ （画面） │ ←── 窓口 ←── │ （ログインの仕組みも） │
└──────────┘ └───────────────────────────┘
これが「できる限り簡素に」作るための近道です。むずかしい部分をSupabaseに任せて、あなたは大事な考え方（誰のデータか）に集中できます。
⚠️ ハマりどころ
- 「全部ブラウザの中で動いている」と思い込む → 実際は、データはネットの向こうのデータベースにあります。ここを誤解すると、次章以降の「そのデータは誰のもの？」がピンと来ません。「画面（手元）」と「倉庫（向こう）」は別、と覚えてください。
- 「サーバー」と「データベース」をごっちゃにする → サーバーは働く人（司令塔）、データベースはしまう倉庫。役割が別です。
- APIを難しく考えすぎる → いまは「決まった形でお願いする窓口」くらいの理解で十分。くわしい設計は第5章でやります。
🤖 AIに頼むなら（Vibe codingのコツ）
AIに「Twitterみたいなアプリ作って」とだけ頼むと、何ができたのか分からないまま動くものが出てきます。登場人物を意識して頼むと、出てきたコードが読めるようになります。
🗣 プロンプト例： 「Supabaseを使ってシンプルなツイート投稿画面を作って。ブラウザ側のコードと、Supabase（サーバー・DB）に何をお願いしているかを分けて、コメント付きで説明して」
出てきたコードを見るときは、「これは画面（ブラウザ）の部分？ それともSupabaseの窓口（API）にお願いしている部分？」と自問してみましょう。
📝 ことばメモ
- ブラウザ：あなたが見て触る画面（Chrome・Safariなど）
- サーバー：注文を処理する、ネットの向こうの司令塔コンピュータ
- データベース（DB）：データをしまう倉庫。イメージは超巨大な表計算
- API：ブラウザとサーバーをつなぐ「注文窓口」
- Supabase：サーバー・DB・API・ログインをまとめて貸してくれるサービス
➡️ 次の章へ
第2章では、いよいよ ログイン を扱います。テーマは 「『ユーザー』って何？」。Twitterで「ログインしている自分」とは、システムから見ると何なのか——ここから「データは誰のもの」の話が始まります。