読了時間 7分

クライアントとサーバー — 画面は「お願い」を送るだけ。決めるのはサーバー

あなたが触っている画面（クライアント）は、お願いを組み立てて送る場所。「見せていいか」を決めてデータを返しているのは、別の場所で動くコンピュータ（サーバー）。F12 の Network タブで自分のアプリの実物を見る手順、客席と厨房のたとえ、なぜこの区別が以降の全記事の土台になるのか。

動画で見る

結論から

あなたが触っている画面（ブラウザ・スマホアプリ）は、「お願い」を組み立てて送る場所です。そのお願いを受け取って、「見せていいか」「やっていいか」を決め、データを返しているのは、どこか別の場所で動いているコンピュータ（サーバー）です。

この記事で伝えたいのは、この一点だけです。画面は、お願いを送るだけ。決めるのは、サーバー。 AIツールで作ったアプリも、例外なくこの2者で動いています。

  • 画面＝クライアント。あなたの端末の中にあり、あなた（と、他の利用者）の手の中にある
  • サーバー＝画面の求めに応じて処理し、返事を返す常時稼働のコンピュータ。あなたが用意した覚えがなくても、Vercel・Supabase・OpenAI がその役をしている
  • 2者は「リクエスト（お願い）」と「レスポンス（返事）」をやり取りしている。F12 の Network タブで、自分のアプリの実物が見える
  • この区別が分かると、以降の記事（URLの数字・/admin・APIキー・RLS）が全部「サーバーが決めているか？」の一言に集約される

動画版（約2分半）は本文の上に埋め込んであります。

① 実際に見てみる：F12 → Network

言葉より先に、自分のアプリで見るのがいちばん早いです。

  1. 自分のアプリ（公開URLでもローカルでも）をブラウザで開く
  2. F12（Mac は ⌥⌘I）で開発者ツールを開き、Network タブを選ぶ
  3. ページを再読み込みする

表に行が並びます。デモの予約アプリではこう見えました。

  • reservations/12 — 200 — document：予約詳細ページを「ください」と頼んで、HTML が返ってきた
  • app.js — 200 — script：画面を動かすプログラムを「ください」と頼んだ
  • api/book — 200 — fetch：予約ボタンを押したときに「この内容で予約して」と頼んだ
  • uploads/license.jpg — 200 — document：画像を「ください」と頼んだ

1行が、クライアントがサーバーに送ったお願い1件です。行をクリックすると右側に、どこへ（Request URL）、どう（GET/POST）、何を持って（Cookie: uid=12）頼んだかと、返ってきた中身が見えます。あなたのアプリは、この行の集まりで動いています。

画面は「お願い」を送るだけ。決めるのは、サーバー

② たとえ：客席と厨房

レストランで考えると、こうなります。

  • 客席（クライアント）：メニューを見て、注文を書く。「カット＋カラー、14時で」
  • 注文票（リクエスト）：客席から厨房へ渡される紙
  • 厨房（サーバー）：注文票を読んで、作るか断るかを決め、料理を返す
  • 料理（レスポンス）：客席に届くもの

大事なのは、客席では料理は作れないことです。客席にできるのは「注文票を書く」ことだけ。注文票に「無料で」と書いても、厨房が「無料にするか」を決めます。逆に、厨房が注文票をそのまま信じる店だと、「無料で」と書いた人全員が無料になります。

これが、このサイトの記事すべてに共通する話です。URLの数字を変える（→ 注文票の番号を書き換える）、/admin を開く（→ 厨房のドアを直接開ける）、金額を書き換える（→「¥1で」と書く）。全部「厨房が、注文票を信じるかどうか」に帰着します。

③ サーバーを"用意した覚えがない"人へ

「画面は AI に作ってもらったけど、サーバーなんて契約していない」という人は多いはずです。でも、次のどれかを使っていれば、それが厨房です。

  • Vercel / Netlify / Lovable の公開機能：アプリのコードを動かし、ページを返す
  • Supabase / Firebase / Neon：データを保存し、「この人にこの行を見せていいか」を決める（RLS）
  • OpenAI / Anthropic / Google：AI の返事を作る
  • Stripe：支払いを処理する

アカウントを作った時点で、厨房を1つ借りています。AI ツールは「動かすため」にこれらを自動でつなぎますが、厨房のルール（誰に何を返すか）は、頼まれない限り書きません。「動く」と「安全」が別の話になるのは、ここが原因です。

④ なぜこの区別が効くのか：判断の場所

画面（クライアント）は、利用者の端末の中にあります。あなたの管理外です。F12 で書き換えられる、URL を直接打てる、画面を使わずに API を直接叩ける。つまり画面側に書いた「チェック」は、守りにならない。親切にはなりますが、悪意のある人は素通りします。

だから、「これを誰に見せていいか」「この操作をしていいか」「この金額でいいか」の判断は、サーバー側で、お願いが来るたびに行います。以降の記事は、すべてこの一点の具体例です。

  • URLの数字を1つ変える → サーバーが「本人のものか」を確かめているか
  • シークレットで /admin → サーバーが「ログイン済み・管理者か」を確かめているか
  • 金額を書き換える → サーバーが「定価から再計算」しているか
  • RLS → データベースが「誰の行か」を確かめているか
  • APIキー → 鍵が、客席（画面）ではなく厨房（サーバー）にあるか

2026年1月の Moltbook（AI エージェント向けSNS）の事故は、この話そのものでした。画面の機能は全部動いていたのに、サーバー側（Supabase）に「誰が読めるか」の判断が無く、150万件の認証トークンが誰でも読める状態で公開されていました。作った人は「コードは一行も書いていない」と語っています。厨房にルールが無かった、ということです。

AIに、こう聞く

自分のアプリのどこが客席で、どこが厨房かを知るには、AI にこう聞いてください。

「このアプリで、ブラウザで動いている部分と、サーバー側（Vercel の関数・Supabase・外部API）で動いている部分を分けて一覧にして。特に、ログイン確認・本人確認・金額計算・データの読み書きが、どちら側で行われているかを明記して。」

「ブラウザ側で行われている」と返ってきた判断があれば、それが次に直す場所です（→「サーバー側で検証して」の一言）。

よくある質問

サーバーは、常に自分のアプリを動かし続けているのですか。

いいえ。お願いが届いたときだけ処理し、返事をしたら待機に戻ります。だから使われなければ費用も小さい。逆に、お願いを大量に送りつけられると、その分だけ動いて、その分だけ請求されます（→ DDoS の記事）。

クライアント側だけで完結するアプリもありますか。

あります。HTML・CSS・JavaScript だけの「静的サイト」です。ただし、フォーム送信・ログイン・データ保存・AI の返事が1つでもあれば、その瞬間に厨房が関わっています。

クライアント側のコードは、他人に見えますか。

見えます。ブラウザに届いた時点で、F12 → Sources で誰でも読めます。だから API キーを画面側に書いてはいけません（→ APIキーの記事）。

「サーバー側で」と AI に言えば、それで安全ですか。

判断の場所が正しくなる、という意味で必要条件です。そのうえで「何を判断させるか」（本人か・管理者か・定価か）を指定します。次の記事から、1つずつ見ていきます。

関連記事