第2章 サービスの世界地図 — 役割の比喩で全体像を渡す
第1章でストップウォッチとカフェ紹介ページが出来ました。手応えがちょっと残っているかもしれません。
その勢いのまま、第2章では「世界地図」を見に行きます。
これから出会う言葉、たくさんあります。GitHub、Cloudflare、Supabase、ホスティング、デプロイ、リポジトリ、push、DNS、ドメイン……全部知らないかもしれません。僕も最初は全部知りませんでした。
でも安心してください。第2章のゴールは「全部覚えること」ではなく、「全体地図を頭の片隅に置いておくこと」です。手を動かしながら、徐々に腑に落ちていきますから。
2-1. この章の使い方 — 完璧に覚える必要はない
【学習目標】
- 第2章を「暗記する章」ではなく「地図を眺める章」として受け止める
- これから出会う用語に対する心理的ハードルを下げる
【前提知識】
- 第1章で2つの「動くもの」が作れていること
【概念解説】
正直に言うと、僕がこの世界地図を理解したのは、Web アプリを実際に作り始めてからでした。作りながら、Code に「いま全体としてどういう構成になってるの？」と聞いて、教えてもらいながら少しずつ繋がったんです。
なので、この章の中身を完璧に覚えてから先に進む必要はまったくないです。逆に「えっ、こんなに用語あるの……？」と圧倒されてしまう方が、進む手を止めてしまいます。
この章でやるのは2つだけ。
- これから出会う言葉に「あ、聞いたことあるな」を作っておく
- それぞれの役割を、比喩でざっくり頭に入れておく
「税理士って何する人？」と聞かれて「税金の専門家でしょ」くらい答えられるレベル感、で十分です。詳細は仕事を一緒にする中で学んでいく、それと同じです。
特に、僕自身の経験で言うと「ローカル」「GitHub」「ホスティング」「データベース」の4つの関係性は、訪問看護のアプリを作る過程で初めてピンと来ました。なので、もしこの章を読んで「分からん……」と思っても、それは正常です。第10章で実際に作る時に、再びここに戻ってきましょう。
【ハンズオン手順】
▼ ブラウザ側でやること
- ブラウザで Claude AI を開く（Code は閉じておいて構いません）
- 次のように打ってみてください
これから Web アプリ開発の世界地図を学ぼうとしています。
GitHub、Cloudflare、Supabase、ターミナル、Claude Code といった
言葉が出てきますが、全部の関係性を、初心者でも分かるように、
比喩を使ってざっくり教えてください。
- ブラウザがどう答えるか眺めてみてください。これから読む内容と似たような話が返ってくると思います
▼ スクショ伴走のチェックポイント
- ブラウザの回答のスクショを取っておくと、後で見比べる時に便利です
【つまずきポイント】
- 「専門用語をまず全部覚えなきゃ」と思わなくていい。地図は道に迷った時に開くもので、いつも頭の中にあるものではないです
- 第10章まで来てから戻ってきても遅くない。今は風景を眺めるくらいのつもりで
【確認問題】
- この章を「暗記する章」と思っていますか、「地図を眺める章」と思っていますか？
【次のレッスンへの橋渡し】
では、いよいよ地図を広げてみましょう。最初は登場人物の紹介から。
2-2. 役割の比喩 — GitHub＝図書館、Cloudflare Pages＝宅配業者、Supabase＝貸し金庫
【学習目標】
- Web アプリを動かすために必要な「役割」が複数あることを理解する
- 各役割が比喩でどう表現できるかを頭に入れる
【前提知識】
- 2-1 を読んでいること
【概念解説】
Web アプリを世界に公開するには、実はいくつかの「役割」が必要なんですよ。一人で全部やる人もいるけど、最近はそれぞれの役割を専門の業者に任せるスタイルが主流です。
僕が Code と対話しながら整理してくれた比喩がとても分かりやすいので、それをそのまま使います。
役割1：自分のPC（ローカル）
- 自分の作業机。ここでファイルを書いたり編集したりする
- 比喩で言うと 自宅の書斎
役割2：GitHub
- コードの保管庫。書いたファイルをここに送って、履歴管理してもらう
- 比喩で言うと 図書館。本（コード）を預けて、いつ誰がどう変えたかを記録してくれる
役割3：ホスティングサービス（Cloudflare Pages、Vercel、Netlify など）
- インターネット上でアプリを公開してくれる業者。GitHub から最新版を引き取って、世界中の人が見られる状態にする
- 比喩で言うと 宅配業者。GitHub から商品（コード）を受け取って、利用者にお届けする
役割4：データベース（Supabase など）
- アプリの中で扱うデータを保管しておく場所。ユーザー情報、入力内容、記録など
- 比喩で言うと 貸し金庫。大事な情報を安全に預けておく場所
役割5：MCP サーバー（後で出てきます）
- Claude に「目と手」を追加する拡張機能。たとえば Claude が直接 Notion を読んだり、Supabase のデータベースを見たりできるようになる
- 比喩で言うと 専門通訳。Claude が普段話せない相手とも会話できるようにしてくれる
これら5つが「同じ層」になっているわけではなく、それぞれ違う役割を持っています。「同じ層のサービス同士は競合（どっちかでいい）」「違う層のサービス同士は補完（両方いる）」、これだけ覚えておいてください。
たとえば Cloudflare Pages と Vercel は同じ層なので、どっちか1つでいい。でも GitHub と Cloudflare Pages と Supabase は違う層なので、全部いる、という感じです。
【ハンズオン手順】
▼ ブラウザ側でやること
- 次のように打って、自分の理解を確かめてみてください
GitHub、Cloudflare Pages、Supabase の3つは、それぞれ
「図書館」「宅配業者」「貸し金庫」の比喩で説明されました。
このうち2つを同時に使うことは普通ですか？
それとも片方だけにすべきですか？
- ブラウザの答えが「3つは違う層なので、全部同時に使うのが普通」となっていればOK
【つまずきポイント】
- 「比喩はあくまで比喩」。完全に1対1で対応はしません。図書館は実際には貸し出すけど、GitHub は基本的に貸し出すというより共有する場所、など細部は違います。雰囲気を掴むため、と割り切ってください
- **「全部使わないといけないの？」**は誤解です。趣味のサイトくらいなら GitHub と Cloudflare Pages の2つで足りる。データを保存する必要が出てきたら初めて Supabase を足す、という順序でOKです
【確認問題】
- GitHub の役割を、比喩を使って一文で説明してください
- Cloudflare Pages と Vercel は「同じ層」「違う層」のどちらですか？
【次のレッスンへの橋渡し】
役割の登場人物が見えました。次は、これらがどう繋がっているかを見ていきましょう。
2-3. ローカル ↔ GitHub ↔ ホスティング ↔ DB の繋がり図
【学習目標】
- 自分のPC、GitHub、ホスティング、データベース の4者の流れを言葉で説明できる
- 開発する時の流れと、利用する時の流れが違う、ということを理解する
【前提知識】
- 2-2 で役割の比喩を読んでいること
【概念解説】
役割が分かったところで、これらがどう繋がっているかを見ていきます。これは実際にアプリを作る時に何度も出てくる流れなので、ここで一度頭に入れておくと、後でグッと楽になります。
繋がりには「開発する時」と「利用する時」の2種類あります。
開発する時の流れ
自分のPC でコードを書く
↓ git push
GitHub にコードが保存される
↓ 自動連携
ホスティング（Cloudflare Pages 等）が変更を検知
↓ 自動デプロイ（数十秒〜数分）
インターネットでアプリが見られる状態になる
「git push」というのは、ローカルで書いたコードを GitHub に送る操作のことです。一度設定してしまえば、Code に「push しといて」と頼むだけで全部やってくれます。
そして大事なのが、「GitHub にコードが届いた瞬間、ホスティングが自動で気づいて、自動で世界に公開してくれる」点です。これがびっくりするくらい便利で、僕自身が「git push 一本で更新も履歴管理もできるのがめっちゃ便利」と実感した部分です。
利用する時の流れ
ユーザーがブラウザでアプリにアクセス
↓
ホスティングが HTML や CSS、JS を返す
↓
ブラウザでアプリが動く
↓ データが必要な時
データベース（Supabase）に問い合わせ
↓
データが保存される、または取得される
利用者は、ホスティング先（Cloudflare Pages のURL）にアクセスするだけ。裏でデータベースとやり取りが起きていることは意識しません。
ここでのポイント
- コードは GitHub に置いてある
- 見せる仕組みは Cloudflare Pages にある
- データは Supabase にある
この3者はそれぞれ独立しているので、コードを書き換えてもデータは消えないし、データが増えてもコードは変わらない、という構造になっています。僕が「これすごい便利」と感動したポイントの一つです。
【ハンズオン手順】
▼ ブラウザ側でやること
- 次のように打って、自分の理解を確かめてみてください
ローカルでコードを書き換えた後、git push をすると、
Cloudflare Pages に自動で反映されるまでに何が起きていますか？
ステップで教えてください。
- 4〜5ステップで「push → GitHub → Cloudflare 検知 → 自動ビルド → 公開」というような流れが返ってくればOK
【つまずきポイント】
- 「自動で反映される」というのが、最初は信じられないかもしれません。でも本当に自動です。「魔法」ではなく、Cloudflare Pages が GitHub の変更を定期的にチェックしている、という地味な仕組み
- データベースは別物、というのが分かりにくいかもしれません。よくある誤解が「コードを修正したら、保存されてたデータも消えるんじゃないか」というもの。消えません。コードとデータは完全に別の場所にあります
【確認問題】
- git push をした後、世界中の人がアプリの新しい版を見られるようになるまでに、いくつのサービスが関わっていますか？
- コードを書き換えたら、データベースのデータは消えますか？
【次のレッスンへの橋渡し】
繋がりが見えました。次は、この「役割を分担する」というやり方が、昔とはどう違うのかを比較して見てみましょう。
2-4. 従来型 vs モダン分散型 — 一軒家を借りる vs 専門業者に任せる
【学習目標】
- 「従来のレンタルサーバー型」と「現代のモダン分散型」の違いを理解する
- どちらが自分の用途に向いているかを判断できる材料を持つ
【前提知識】
- 2-3 で繋がり図を見ていること
【概念解説】
ここまで紹介した「役割ごとにサービスを分けて使う」スタイルは、実はわりと最近の主流なんです。10年くらい前までは、もっと違うやり方が普通でした。
従来型：レンタルサーバー方式
たとえば、さくらインターネットや ロリポップなどのサーバーを契約して、
- 契約料を払う（月数百円〜数千円）
- ドメインを取る（年間1〜2千円）
- FTP でファイルをアップロード
- データベース（MySQL）も同じサーバー内に作る
- メールサーバーも一緒に使う
- WordPress なんかを動かす
ぜんぶ「1つのサーバー」に集約されています。比喩で言うと、一軒家を借りて、電気・水道・インターネット・家具を全部自分で揃えて、管理も全部自分でやるスタイル。
モダン分散型：今回学ぶスタイル
役割ごとに専門業者に任せる：
- コード管理 → GitHub（図書館）
- 公開・配信 → Cloudflare Pages（宅配業者）
- データ管理 → Supabase（貸し金庫）
- メール送信 → Resend など別サービス（後で出てきます）
- 自分はコードを書くことだけに集中
比喩で言うと、役割ごとに専門業者に任せて、自分は本業（モノ作り）に集中するスタイル。
何が違うのか
| 比較項目 | 従来型 | モダン分散型 |
|---|---|---|
| 初期設定 | サーバー契約・ドメイン取得・FTP設定など手間が多い | GitHub アカウントがあればすぐ始められる |
| デプロイ | FTP でファイルアップロード | git push だけで自動反映 |
| コスト | 月額費用（サーバー＋ドメイン）が常にかかる | 小規模なら全部無料 |
| バージョン管理 | 自分でバックアップしないと戻せない | Git で全履歴が残り、いつでも戻せる |
| スケール | サーバーのスペック上限がある | 利用者が増えても自動で対応 |
じゃあ従来型はもう不要？
そうではないんですよ。用途によって向き不向きがあります。
| 向いているケース | 従来型 | モダン分散型 |
|---|---|---|
| WordPress などCMSを使いたい | ◎ | △ |
| メールサーバーも一緒に使いたい | ◎ | × |
| 既存のサーバーが契約済み | ◎ | どちらでも |
| 新規でWebアプリを作る | △ | ◎ |
| 無料で始めたい | × | ◎ |
| 自動デプロイ・バージョン管理したい | △ | ◎ |
僕の実体験で言えば、2012年に独立した時に WEB デザイナーを雇って WordPress でクライアントサイトを作っていた当時のスタイルは、完全に従来型でした。今 Claude Code で作っているのはモダン分散型。両方に向き不向きがあるので、用途で使い分ければOKです。
このカリキュラムでは、新規でWebアプリを作る、無料で始めたい、自動デプロイしたいという典型ケースを想定しているので、モダン分散型をメインに学んでいきます。
【ハンズオン手順】
▼ ブラウザ側でやること
- 次のように打ってみてください
従来型のレンタルサーバー方式と、GitHub + Cloudflare Pages + Supabase
のモダン分散型では、どちらが「個人で趣味の Web アプリを作って公開する」
のに向いていますか？理由も含めて教えてください。
- 「モダン分散型の方が向いている、無料で始められる、自動デプロイがある、など」の答えが返ってくればOK
【つまずきポイント】
- 「分散型は管理が大変そう」と感じるかもしれませんが、実際は逆。それぞれが専門業者なので、自分が管理する部分は減ります
- **「分散型に切り替えると、今あるサイトも全部移行しないといけないの？」**そんなことはないです。今あるサイトはそのまま動かして、新しいサイトだけ分散型で作る、という併用が普通です
【確認問題】
- 「自分の PC でコードを書く → git push する → 自動でデプロイされる」これは従来型と分散型、どちらの流れですか？
- 既存の WordPress サイトを運用している人が、新しい Web アプリを作る時に分散型を使うのは「あり」「なし」のどちらですか？
【次のレッスンへの橋渡し】
ここまでで、サービスの世界地図はだいたい見渡せたと思います。あと2つだけ、混乱しやすい用語の整理をしておきましょう。
2-5. 似た言葉の整理 — CLI / bash / ターミナル、git と GitHub
【学習目標】
- 「ターミナル」「CLI」「bash」「zsh」の関係を整理する
- 「git」と「GitHub」の違いを言葉で説明できる
【前提知識】
- ここまでの章を読んでいること
【概念解説】
これから手を動かしていく中で、似たような言葉に何度もぶつかります。最初に整理しておくと、後で混乱しないですみますよ。
ターミナル / CLI / bash / zsh の整理
ターミナル（窓口アプリ）
└── シェル（翻訳者：bash や zsh）
└── CLI ＝ 文字で命令を出す操作スタイル
- ターミナル：黒い画面の窓口アプリそのもの。Mac なら「Terminal.app」、Windows なら「ターミナル」または「PowerShell」
- シェル：ターミナルの中で実際に命令を解釈して実行するプログラム。bash（古いMac/Linux標準）や zsh（今のMac標準）が代表。Windows なら PowerShell
- CLI：Command Line Interface の略。「文字を打って命令を出すスタイル」を指す総称
たとえば「ターミナルで bash を使って CLI 操作をする」というのは、要するに「黒い画面で bash という翻訳者を使って文字打って命令する」ということです。
混乱しがちですが、実用上は「ターミナル」と一言で呼んで大丈夫です。シェルが何かを意識する場面は、初心者のうちはほぼないです。
git と GitHub の整理
これは非常によく混同される言葉ですが、別物です。
- git：履歴管理の仕組み。Linus Torvalds が2005年に作ったツール。自分のPCで動く
- GitHub：git で作った履歴を置いておく場所。Microsoft が運営するクラウドサービス
例えるなら、git は「ノート」で、GitHub は「ロッカー」みたいなものです。ノート（git）に書いた内容を、ロッカー（GitHub）に置いておく。
実用上の関係：
- 自分のPCでファイルを書き換える
- git で「ここを変えたよ」と履歴をつける（=「コミット」する）
- GitHub にその履歴を送る（=「プッシュ」する）
第8章で詳しくやりますが、まずは「git は仕組み、GitHub は場所」とだけ覚えてください。
【ハンズオン手順】
▼ ブラウザ側でやること
- 次のように打ってみてください
git と GitHub は別物だと聞きましたが、
日常的に使う上で、自分が意識すべき違いを教えてください。
- 「git は手元の道具、GitHub はネット上の置き場所」というような答えが返ってくればOK
【つまずきポイント】
- 「シェル」と「ターミナル」は混同して使われがち。気にせず、両方とも「黒い画面」のことだと思っておけば実害ありません
- 「自分は git を使ったことない」と思いがちですが、Code 経由で実は毎日使っています。第8章で意識的に学びます
【確認問題】
- ターミナルで動いている bash や zsh は、何と呼ばれるカテゴリのプログラムですか？
- git と GitHub の違いを、自分の言葉で一文で説明してください
【次のレッスンへの橋渡し】
第2章の最後の項目に行きます。MCP という、聞き慣れないけど重要な言葉について。
2-6. MCP の本質 — 「CLIで叩けないサービスへの橋」
【学習目標】
- MCP（Model Context Protocol）が何のためにあるかを理解する
- 「最初から全部入れる」必要がないことを知る
【前提知識】
- 2-2 で「MCP は専門通訳のようなもの」と聞いていること
【概念解説】
MCP は Model Context Protocol の略で、Anthropic が定めた「Claude に新しいツールを追加するための共通の約束」のことです。
これだけだと意味不明だと思うので、具体例で説明します。
たとえば Claude Code は、自分のPC内のファイルを読んだり、ターミナルでコマンドを実行したりできますよね。これは Claude Code に最初から備わっている能力です。
でも、「Notion の自分のページを読みたい」「Supabase のデータベースを Claude から直接見たい」「Stripe の決済履歴を確認したい」となると、Claude Code 単体ではできません。なぜなら Notion や Supabase や Stripe の内部構造は、ターミナルからは触れないからです。
そこで MCP の出番。「Notion MCP」「Supabase MCP」みたいに、サービスごとに専用の橋（通訳）を用意して、Claude がそのサービスを操作できるようにする仕組みです。
僕が学習メモの中でうまく言語化していて、こうあります：
「MCP の本質は CLI で叩けないサービスへの橋」
つまり、
- ターミナルから普通に操作できるサービス（GitHub、Cloudflare など） → MCP は不要
- ターミナルから直接は触れないサービス（Notion、Slack、Figma、Stripe など） → MCP があると便利
MCP は必要なものだけ入れる
ここで大事なのが、「MCP を最初から30個入れちゃおう！」は罠だということです。理由は単純で、
- 入れすぎると Claude が選択肢に迷う
- 自分も「どの MCP がどんな能力を追加したか」分からなくなる
- 使わない MCP は単にノイズ
なので、自分が実際に使うサービスの MCP だけを入れるのが鉄則です。
最初は MCP ゼロでも全然問題ありません。僕も最初の数週間は MCP を1つも入れていませんでした。実際にデータベースの中身をいちいち見たくなった時に Supabase MCP を入れる、というふうに、必要に応じて足していく順序がオススメです。
【ハンズオン手順】
▼ ブラウザ側でやること
- 次のように打ってみてください
Claude Code を使い始めて間もない初心者は、MCP を最初に何個くらい
入れるのが適切ですか？また、入れすぎるとどうなりますか？
- 「最初はゼロでもいい、必要になったら追加すればいい、入れすぎは混乱の元」という答えが返ってくればOK
【つまずきポイント】
- 「MCP を入れないと Claude Code が使えない」は誤解。MCP ゼロでも Web アプリは作れます
- 「みんなが使ってる MCP」と「自分に必要な MCP」は違う。SNS で話題になっている MCP に飛びつく必要はないです
【確認問題】
- MCP が「橋」だとしたら、どこからどこへの橋ですか？
- 初心者は MCP を最初に何個入れるべきですか？
【次のレッスンへの橋渡し】
第2章はこれで完了です。世界地図、なんとなく見えてきましたか？
繰り返しますが、ここで全部覚える必要はないです。「あ、こんな名前あったな」を作っておくのがゴール。実際に手を動かす中で、地図の中の位置関係が少しずつ腑に落ちていきますから。
次の第3章では、ちょっと怖い「ターミナル」と初対面します。でも安心してください。「コピペできれば十分」というのが第3章の結論です。