第10章 Webアプリ実装と公開（Cloudflare Pages 中心、移行体験含む）

ここまでの章で、Code を使う基礎・コアパターン・周辺ツール（Git/GitHub、MCP）が一通り見えました。

第10章は、いよいよそれを使って本格的な Web アプリを作って、世界に公開する章です。

ただ「Web アプリの作り方」を抽象的に説明しても腑に落ちないので、本章では僕自身が3週間で作った訪看訪問時間管理アプリの実際の進化をなぞる形で進めます。

実際のバージョン履歴：

v1.x（2026-04-27〜05-09）ローカル版
  IndexedDB保存、訪問タイマー、GPS取得、利用者マスタ管理、履歴・集計

v2.1（2026-05-09）ネットワーク版ローンチ
  Supabase 接続、Chrome Mac ログイン問題修正

v2.2（2026-05-10）機能追加
  メモ機能、月ごとアコーディオン履歴、CSV出力（GPS含む）

v2.3（2026-05-10）自動デプロイ環境
  GitHub + Netlify 連携

v2.4（2026-05-12）メール通知 + ホスティング移行
  新規登録時の管理者通知（Resend + Edge Function）
  Netlify → Cloudflare Pages 移行

v2.5（2026-05-14）細かい修正
  iPhone Safari スクロール問題、同時訪問数制限

これを9レッスンに分けてなぞっていきます。

10-1. Webアプリ開発の全体像（フロント／バック／DB／インフラ）

【学習目標】

Web アプリを構成する4つの要素を理解する
「自分が今どこを作っているか」が分かるようになる

【前提知識】

第9章まで完了していること
第2章の「世界地図」を読んでいること

【概念解説】

Web アプリは、大きく4つの要素で出来ています。

1. フロントエンド（見える部分）

ブラウザに表示される画面
HTML、CSS、JavaScript で作る
例：カフェ紹介ページの見た目、ボタン、フォーム

2. バックエンド（裏で動く処理）

ユーザーが入力した内容を処理する
データを保存したり、計算したり、別のサービスと通信したり
例：ログイン認証、メール送信、決済処理

3. データベース（情報を保存する場所）

ユーザー情報、入力データ、設定など
第2章で「貸し金庫」と比喩したやつ
例：訪問記録、利用者マスタ、職員アカウント

4. インフラ（全部を動かす土台）

フロント・バック・DB を「世界に公開」する仕組み
第2章で「宅配業者」と比喩したホスティング
例：Cloudflare Pages、Vercel、Netlify

訪看アプリで言うと

訪看アプリの各要素を当てはめてみます。

要素	訪看アプリでの実装
フロントエンド	index.html、style.css、app.js（訪問時間記録の画面）
バックエンド	Supabase Edge Functions（メール通知の処理）
データベース	Supabase（訪問記録、職員、利用者）
インフラ	Cloudflare Pages（公開・配信）

これが、僕が3週間で組み立てた構成。1つひとつは難しくありません。1つずつ作っていけば形になります。

「全部 Code が作ってくれる」は本当

「フロントエンド」「バックエンド」「データベース」「インフラ」と聞くと身構えますが、Code に依頼すれば全部やってくれます。

僕は、これらの言葉を全部知ってから訪看アプリを作り始めたわけではなく、作りながら覚えました。「フロントエンドって何？」というレベルから、Code とブラウザに聞きながら2週間ちょっとで動くアプリが出来上がりました。

なので、この章を読み始めた時点で全部理解している必要はないです。「こういう4つの要素があるんだな」を頭に入れておけば、後で「あ、今やってるのはバックエンドの話か」と位置づけられるようになります。

【ハンズオン手順】

▼ ブラウザ側でやること

ブラウザに次のように打って、4つの要素の関係を整理してもらう

私はこれから Web アプリを作ろうとしています。
フロントエンド、バックエンド、データベース、インフラの
4つの要素について、初心者にも分かるように比喩で説明してください。
レストランに例えるなら何ですか？

ブラウザが「フロントエンドは客席、バックエンドは厨房、データベースは食材倉庫、インフラは建物」のような比喩で答えてくれる
自分にしっくりくる例を頭に入れておく

【つまずきポイント】

「全要素を理解してから始めよう」と思わない。やりながら覚える
小規模なアプリだと、4要素すべてが揃っているとは限らない。たとえば「ストップウォッチ」はフロントエンドだけで成立する

【確認問題】

Web アプリの4つの要素を言えますか？
データベースの役割を、比喩で説明してください

【次のレッスンへの橋渡し】

全体像が見えました。次は、その「インフラ」をどう選ぶか、という話に進みます。

10-2. ホスティング選び：Cloudflare Pages を主軸にする理由

【学習目標】

主要なホスティングサービスの違いを知る
Cloudflare Pages を選ぶ理由を理解する

【前提知識】

10-1 で「インフラ」が何か理解していること

【概念解説】

Web アプリを公開するための「ホスティング」サービスは、有名どころが複数あります。

Vercel：Next.js の開発元が作ったサービス、Next.js と相性◎
Netlify：シンプルで人気、無料枠あり
Cloudflare Pages：Cloudflare 社のサービス、無料枠が広い

僕は最初 Netlify を使っていて、後に Cloudflare Pages に移行しました。本書では Cloudflare Pages を主軸として進めます。

なぜ Cloudflare Pages を推すか

3つ理由があります。

1. 無料枠が圧倒的に広い

Netlify 無料枠：1ヶ月300回のデプロイ制限
Cloudflare Pages 無料枠：デプロイ無制限、月500ビルドまで

開発中は何度もデプロイするので、Netlify の300回はあっという間に使い切ります。僕は実際に訪看アプリの v2.4 開発中に Netlify のクレジットを使い切って、Cloudflare Pages に移行しました。

2. GitHub と連携した自動デプロイ

git push
   ↓
GitHub にコードが上がる
   ↓
Cloudflare Pages が自動で検知
   ↓
ビルド・デプロイ（数秒〜数十秒）
   ↓
公開完了

これが完全に自動。push するだけで世界に最新版が公開される。

3. CDN による高速配信

Cloudflare はもともと CDN（コンテンツ配信ネットワーク）の会社です。世界中にサーバーがあって、ユーザーの近くから配信してくれる。日本のユーザーには日本のサーバー、アメリカのユーザーにはアメリカのサーバー、というふうに。

これにより、アクセスが速い。

Netlify との関係

「じゃあ Netlify は使う価値がないの？」というと、そうではないです。

Netlify はインターフェースがシンプルで初心者向き
「とりあえずデプロイ」が早い
機能が直感的

僕も最初は Netlify を使って、慣れてから Cloudflare Pages に移行しました。最初は Netlify、本気で運用するなら Cloudflare Pages、というのが現実的な選択かもしれません。

ただ、本書では最初から Cloudflare Pages で進めます。理由は、「最初から本気で運用できる構成にする」ためと、「途中で移行する手間を省く」ためです。

【ハンズオン手順】

▼ ブラウザ側でやること（自分のプロジェクトに合うホスティング）

ブラウザに次のように打つ

私はこれから Web アプリを作ります。要件：
- 個人プロジェクト
- 月に数十回はデプロイしそう
- 日本のユーザーが中心
- 無料で始めたい

Vercel、Netlify、Cloudflare Pages のどれが向いていますか？
理由付きで教えてください。

ブラウザがアドバイスする
自分のプロジェクトに合うのを選ぶ（本書では Cloudflare Pages 推奨）

【つまずきポイント】

「最初から完璧なホスティングを選ぼう」と思わない。途中で移行も可能（10-9 で扱います）
無料枠の制限を超えると有料になる。初心者でも、開発が活発になると意外と早く到達する

【確認問題】

本書で推奨するホスティングサービスは何ですか？
Cloudflare Pages の3つのメリットを挙げてください

【次のレッスンへの橋渡し】

ホスティングが決まりました。次は、いよいよ作りたいアプリの仕様を固める段階に入ります。

10-3. ブラウザでアプリの仕様を固める

【学習目標】

作りたいアプリの仕様を、自分の言葉で表現できる
ブラウザを使って仕様を磨くプロセスを身につける

【前提知識】

10-2 までを読んでいること

【概念解説】

いきなり Code に「○○アプリを作って」と言うと、抽象的すぎて Code が困ります。「どんな機能？」「どんなデザイン？」「データの保存先は？」と質問が連発します。

これを避けるには、事前に仕様を固めておくことが効きます。仕様を固める時の相棒が、ブラウザです。

仕様を固めるプロセス

僕が訪看アプリで実践したやり方：

1. ブラウザに「○○というアプリを作りたい」と打つ
2. ブラウザがいくつか質問してくる
3. 質問に答えながら、自分が何を作りたいか整理されていく
4. 最後にブラウザが仕様書を作ってくれる
5. その仕様書を Code に渡す

訪看アプリの仕様確定の実例

僕はブラウザにこう打ちました：

訪問看護の訪問時間を管理するアプリを作りたい。
ストップウォッチの様な機能がベースで、一日に5〜10件訪問するので、
訪問開始時と終了時にタップするだけで、滞在時間が記録されるような
形で、デフォルトで5件は記録できるようになってて、追加は＋ボタン等で
1件ずつ追加されるイメージ。
UIはシンプルに、ただ、DBとしては日々の記録がストックされるようにしたい。

これに対してブラウザが、

「どのプラットフォーム向けに作りますか？」（Web、ネイティブアプリなど）
「データの保存先はどうしますか？」（ローカルのみ、クラウド、両方）
「GPS 情報も記録しますか？」
「複数人で使う想定ですか？」

と質問を返してきます。

僕は順に答えていって、最終的に「React + IndexedDB のローカル動作する Web アプリ」という仕様に固まりました。

これが訪看アプリ v1.x の出発点。

仕様をブラウザで固めるメリット

Code に渡す前に方向性が固まる
Code のコンテキストウィンドウを節約できる
自分自身が「何を作りたいか」を明文化できる
後で「あの時こうだったよね」と振り返れる

仕様書のフォーマット

仕様書には決まった形式はありませんが、参考までに含めると良い項目：

# アプリ名

## 目的
何のために作るか

## 想定ユーザー
誰が使うか

## 主な機能
- 機能1
- 機能2
- 機能3

## 技術スタック
- フロントエンド
- バックエンド（あれば）
- データベース
- ホスティング

## デザインの方向性
- 雰囲気
- 色使い

## やらないこと（スコープ外）
- 機能X
- 機能Y

「やらないこと」を明示しておくのが、意外と効きます。Code が暴走して余計な機能を作るのを防げます。

【ハンズオン手順】

▼ ブラウザ側でやること（仕様を固める）

ブラウザに「○○アプリを作りたい」と打つ（題材は何でもOK、家計簿、ToDo、習慣記録など）
ブラウザが質問を返してくる
順に答えていく
最後にブラウザに次のように依頼

ここまでのやり取りを踏まえて、このアプリの仕様書を作ってください。
目的、想定ユーザー、主な機能、技術スタック、デザインの方向性、
やらないこと、を含めて。

ブラウザが仕様書を生成
内容を読んで、自分のイメージと合っているか確認
違うところがあれば修正を依頼

▼ Code 側でやること（仕様書を渡す）

プロジェクトフォルダを Code で開く
仕様書を Code に渡して、「この仕様で開発を始めたい」と伝える
Code が「最初に何を作るか」を提案してくる（Plan モード推奨）

▼ スクショ伴走のチェックポイント

ブラウザでの仕様確定のやり取り
完成した仕様書
Code が仕様書を受け取って Plan を提示した画面

【つまずきポイント】

仕様を「完璧に」固めようとしない。後で変えていい
ブラウザの質問に「お任せ」と答えると、それなりに進む。完璧な答えを出そうとして止まらないこと
「やらないこと」を必ず書く。これがないと Code が機能を盛り込みすぎることがある

【確認問題】

Code に依頼する前に仕様を固める意義は何ですか？
仕様書に「やらないこと」を明記するメリットは何ですか？

【次のレッスンへの橋渡し】

仕様が固まりました。次は、いよいよ実装に入ります。最初は「ローカル版」、つまりインターネットに繋がない、自分のPC内だけで動くバージョンから。

10-4. ローカル版を作る — IndexedDB で動かす（訪看v1.x相当）

【学習目標】

「ローカル版」のメリットを理解する
IndexedDB を使った Web アプリの感覚を掴む

【前提知識】

10-3 で仕様書ができていること

【概念解説】

Web アプリを作る時、いきなり「インターネットに繋がるバージョン」を作ろうとすると、難易度が一気に上がります。

そこで、まず「ローカル版」を作るのが、僕の進め方。ローカル版とは：

自分のPCのブラウザ内だけで動く
データは自分のPC内にだけ保存される
インターネットに繋がっていなくても使える
公開しなければ、他人は触れない

「これって意味あるの？」と思うかもしれません。が、意味あります。

ローカル版を先に作るメリット

DB の設定が要らない
- Supabase などの設定が不要
- 「とりあえず動く」までの距離が短い
エラーが減る
- 認証、ネットワーク、CORS（クロスオリジン）などのトラブルが起きない
- 純粋に「機能が動くか」だけ集中できる
作ったものを早く触れる
- 1日で動く版が手元にできる
- 仕様の見直しがしやすい

僕も訪看アプリの最初の2週間（v1.x）は、完全にローカル版で進めていました。動くものを手で触りながら、「ここはこうしたい」を直していく。

IndexedDB とは

ローカル版で「データを保存する」場所として使うのが、IndexedDB。

ブラウザに最初から組み込まれている「データベース機能」です。

ブラウザ内に勝手にできる
自分が触らなくていい（コードから操作する）
データはそのブラウザの中だけに残る
別のブラウザや別の PC からはアクセスできない

これがあれば、訪問記録のような「保存しておきたいデータ」もちゃんと残ります。

訪看アプリ v1.x で実装したこと

僕が訪看アプリの v1.x で実装した機能：

IndexedDB によるローカル保存
訪問タイマー（開始・終了ボタン）
GPS 位置情報の取得
利用者マスタ管理（CSV 一括登録対応）
履歴・集計ビュー

これだけで、もう実用的なアプリです。僕自身、まずこの v1.x を実際に訪看の現場で試して、改善点を洗い出してから v2.x に進めました。

【ハンズオン手順】

▼ Code 側でやること（ローカル版の実装依頼）

プロジェクトフォルダを Code で開く
Plan モードに切り替え
仕様書を渡して、次のように依頼

この仕様書に基づいて、ローカル版を実装してください。
データの保存先は IndexedDB を使用します。
まず最小限の機能（○○と○○）から作って、動くようにしてください。

Code が Plan を提示
Plan を確認して OK
Code が実装を開始

▼ Code 側でやること（動作確認）

実装が完了したら、プレビューパネルでアプリを動かす
機能を1つずつ試す
動かない部分があれば、Code にフィードバック
CHANGELOG.md に「v1.0 ローカル版完成」のように記録

▼ スクショ伴走のチェックポイント

ローカル版が動いている画面のスクショ
IndexedDB にデータが保存されている様子（ブラウザの開発者ツールで確認できる）

【つまずきポイント】

「最初から多機能にしよう」と思わない。最小限から始める
IndexedDB のデータは、ブラウザを変えると消える。「Chrome で作ったデータは Firefox では見えない」ということ
ローカル版で完成しても、他人と共有はできない。それはこれからの話

【確認問題】

ローカル版を先に作るメリットを2つ挙げてください
IndexedDB はどこにデータを保存しますか？

【次のレッスンへの橋渡し】

ローカル版が出来ました。次は、これを「インターネット経由で使える」ネットワーク版に進化させます。僕の訪看アプリで言う、v1.x → v2.1 の移行です。

10-5. ネットワーク版に移行 — Supabase 接続（訪看v2.1相当）

【学習目標】

ローカル版とネットワーク版の違いを理解する
Supabase を使ったクラウド DB の感覚を掴む

【前提知識】

10-4 でローカル版が動いていること

【概念解説】

ローカル版で動くものができたら、次は「ネットワーク版」に進化させます。

ネットワーク版とは：

データがクラウドのデータベースに保存される
複数の端末（PC、スマホ）から同じデータを見られる
複数人で使える（自分一人でなく、職員みんなで）
インターネットがないと動かない

訪看アプリでいうと、v1.x（ローカル版）から v2.1（ネットワーク版）に進化したタイミング。これによって「複数の職員が同じ訪問記録を見る」ことが可能になりました。

移行に必要なもの

ローカル版からネットワーク版への移行には、以下が必要です。

データベースのクラウド化：IndexedDB → Supabase
認証の追加：誰でもアクセスできない、ログインが必要
アクセス権限の管理：誰がどのデータを見られるか

これらを1つずつ Code に頼んで実装していきます。

Supabase とは

第2章で「貸し金庫」の比喩で紹介した、データベースのサービス。改めて整理すると：

インターネット上にあるデータベース
無料枠が広い（個人プロジェクトには十分）
認証機能が組み込まれている（ログイン管理が楽）
API が自動で生成される（Code から操作しやすい）

僕が訪看アプリで使ったのも Supabase。本書も Supabase を推します。

移行の流れ

1. Supabase でプロジェクトを作る
2. テーブル（データの保管場所の構造）を設計
3. 認証を有効化
4. Code に「IndexedDB を Supabase に置き換えて」と依頼
5. Code がコードを書き換える
6. 動作確認

僕が体験した実例

僕が v1.x → v2.1 の移行で体験した、いくつかのトラブル：

Chrome Mac のログイン問題：Web Locks API という仕組みが原因で、Chrome の Mac 版だけログインが失敗した。Code に相談して「Web Locks API バイパス」という対処を実装
データ移行のタイミング：v1.x のローカルデータを v2.1 でも使えるようにする処理が必要だった

こういう問題に1つずつ対処しながら進めるのが、ネットワーク版への移行です。

【ハンズオン手順】

▼ ブラウザ側でやること（Supabase プロジェクト作成）

ブラウザで https://supabase.com にアクセス
アカウント作成 → ログイン
「New project」をクリック
プロジェクト名、地域（東京推奨）、データベースパスワードを設定
プロジェクトが作られる（1〜2分）

▼ Code 側でやること（テーブル設計）

Code に次のように依頼

ローカル版で IndexedDB に保存していたデータを、Supabase に
保存するように変更します。

まず、必要なテーブル設計を提案してください。
- どんなテーブルが必要か
- 各テーブルにどんなカラムが必要か
- テーブル間の関係

Code が設計を提案
確認したら、SQL に変換してもらう

このテーブル設計を Supabase に作るための SQL を書いてください。
Supabase の SQL Editor に貼り付けて実行する形で。

Code が SQL を出す

▼ Supabase 側でやること（SQL 実行）

Supabase ダッシュボードで「SQL Editor」を開く
Code が出した SQL を貼り付け
「Run」を押す
テーブルが作成される

▼ Code 側でやること（コード書き換え）

Code に次のように依頼

ローカル版のコードを、Supabase に接続するように書き換えてください。
Supabase のプロジェクト URL：[URL]
anon key：[キー]

CRUD（作成・読み込み・更新・削除）の各操作を Supabase に向けてください。

Code がコードを書き換え
動作確認

▼ スクショ伴走のチェックポイント

Supabase プロジェクトが作られた画面
テーブルが作成された Supabase の画面
ネットワーク版が動いている画面（データが Supabase に保存されている）

【つまずきポイント】

API キーの取り扱いに注意。anon key は公開しても比較的安全（権限が制限されている）ですが、service_role key は絶対に公開しない。「APIってどっちのこと？」と Code に確認しながら進める
CORS エラーが出ることがある。スクショを Code に貼って対処
ローカルデータの移行は別途設計が必要。「v1.x のローカルデータを v2.1 にも残したい」場合は事前に Code と相談

【確認問題】

ローカル版とネットワーク版の主な違いは何ですか？
Supabase のテーブルを作る操作は、どの画面で行いますか？

【次のレッスンへの橋渡し】

ネットワーク版が動き始めました。次は、Supabase などの外部サービスを設定する時の「チェックボックスをひとつずつ確認しながら進める」スクショ伴走のリアルな実例を見ていきます。

10-6. 外部サービスの GUI 設定はチェックボックス1個ずつスクショ伴走で

【学習目標】

外部サービスの GUI 設定で、Code に伴走してもらうコツを身につける
「変更後のイメージ」提示を活用できる

【前提知識】

10-5 で Supabase に接続できていること
5-6 で「変更後のイメージ」提示パターンを学んでいること

【概念解説】

Supabase や Cloudflare Pages を使い始めると、設定画面のチェックボックスや項目がたくさん出てきます。

☐ Enable Data API
☐ Automatically expose new tables
☐ Enable automatic RLS
☐ Allow public access
...

「これ、どれをチェックすればいいの？」状態。説明文を読んでも、初心者には意味不明。

ここで第5章で学んだ**スクショ伴走モデルのパターン①「変更後のイメージ提示型」**が威力を発揮します。

僕の実例：Supabase の API 設定

僕が Supabase の API 設定画面で迷った時、Code がこう返してくれました。

変更後のイメージ:
☑ Enable Data API              ← そのままON
☐ Automatically expose new tables ← チェックを外す
☑ Enable automatic RLS         ← チェックを入れる

「何を ON にして、何を OFF にすべきか」を、図つきで完全に指示してくれた。僕はこの通りに設定して、設定完了スクショを Code に返した。Code は「合ってます！」と確認。完了。

設定画面を進める時の鉄則

わからない項目は触らない
触る前に Code に「これどうすればいい？」と聞く
Code の指示通りに設定する
設定後のスクショを Code に返して確認

これだけ守れば、外部サービスの設定で事故は起きません。

RLS（Row Level Security）の話

Supabase で必ず出てくる設定が RLS（Row Level Security） です。「どのデータを、誰が見られるか」を制御する仕組み。

これも初心者には難しい概念ですが、Code に頼めば適切に設定してくれます。

僕は訪看アプリで、こんな RLS を設定しました：

一般職員 → 自分の訪問記録だけ閲覧可
管理者 → 全職員の訪問記録を閲覧可
未認証ユーザー → 何も閲覧不可

これも Code に「こういうルールで RLS を設定して」と依頼するだけ。

「Step3に進んだけど、APIってどっち？」

僕がリアルに困った例。Supabase の管理画面には「API Keys」と「DATA API」と、似た名前の項目があって、初心者には区別がつかない。

Code に「API ってどっちのこと？API Keys？DATA API？」と聞いたら、

左サイドバーの「API Keys」をクリックしてください！
そこに anon public キー（eyJ... で始まる長い文字列）が表示されます。

と、画面の場所まで含めて教えてくれた。**設定画面の「どこを見るか」**まで指示してもらえる、これがスクショ伴走の本領です。

【ハンズオン手順】

▼ Code 側でやること（Supabase 設定の確認を依頼）

Supabase の管理画面を開いた状態で、画面のスクショを撮る
Code に次のように依頼

Supabase の設定画面のスクショです。
このアプリ（訪問時間記録アプリ）で、各項目をどう設定すべきか
教えてください。

特に：
- Authentication の設定
- RLS の設定
- API Keys の使い分け

Code が「変更後のイメージ」を提示
それに従って設定
設定後のスクショを Code に返す
Code が「合ってます」または「ここがまだ違います」と返す

▼ スクショ伴走のチェックポイント

設定前のスクショ
Code から「変更後のイメージ」が提示された画面
設定後のスクショ
Code から「合ってます」確認が出た画面

【つまずきポイント】

分からない項目を自分の判断で ON/OFF にしない。Code の指示を待つ
設定画面の言葉が英語でも怖がらない。Code に画面を見せれば日本語で説明してくれる
「これ何の設定？」と思ったら、項目名でスクショを撮って Code に聞く

【確認問題】

外部サービスの GUI 設定で迷った時、まず何をすべきですか？
RLS（Row Level Security）は何の仕組みですか？

【次のレッスンへの橋渡し】

設定を進める術が身につきました。次は、ローカルで動いているアプリを「世界に公開する」ステップです。GitHub と Cloudflare Pages を連携させます。

10-7. GitHub と Cloudflare Pages を連携して本番デプロイ

【学習目標】

GitHub と Cloudflare Pages の連携セットアップができる
自動デプロイの仕組みを体験する

【前提知識】

第8章で GitHub にコードを push できていること
10-2 で Cloudflare Pages の概要を知っていること

【概念解説】

ここまでで、

ローカル版を作った（10-4）
ネットワーク版に進化させた（10-5）
外部サービスの設定を済ませた（10-6）
GitHub にコードを push した（第8章）

次は、これを世界に公開するステップ。GitHub と Cloudflare Pages を連携させます。

訪看アプリで言うと

訪看アプリの changelog で言うと、これは v2.3 のタイミングに相当します。

v2.3（2026-05-10）GitHub + Netlify 自動デプロイ環境を構築

僕の場合は最初 Netlify を使いましたが、本書では Cloudflare Pages で進めます。本質的な流れは同じです。

連携の全体像

1. Cloudflare アカウントを作る
2. Cloudflare Pages に新規プロジェクトを作る
3. GitHub のリポジトリと連携する
4. Cloudflare が GitHub からコードを取得
5. ビルド・デプロイ
6. 世界に公開
7. 以降は git push するだけで自動更新

これも一度設定すれば、後は何もしなくていい。

僕の実体験から：設定中の質問の数々

僕が Cloudflare Pages の連携で実際に Code に聞いた質問の例：

- Connect GitHub でいいの？
- Only の方よね？（リポジトリへのアクセス権限）
- これでいいね（リポジトリ選択）
- ここは何も記入しない？（ビルド設定）
- このまま Save and Deploy でいい？

ぜんぶ Code が「はい、そのままで OK です」または「ここはこう変えてください」と1つずつ答えてくれる。これがスクショ伴走の威力。

ビルド設定で気をつけること

Cloudflare Pages の新規プロジェクト作成画面では、いくつかの項目があります。

Project name：プロジェクト名（後で URL に影響する）
Production branch：通常 main のままでOK
Build command：HTML/CSS/JS だけなら空白でOK
Build output directory：通常空白でOK

初心者の場合、「空白でいい」項目が結構ある。これを Code に「何も入力しなくていい？」と確認すれば、「そのままで OK」と教えてくれます。

【ハンズオン手順】

▼ ブラウザ側でやること（Cloudflare アカウント）

ブラウザで https://pages.cloudflare.com にアクセス
「Sign up」でアカウント作成（GitHub アカウントでサインインできる）
ログイン完了

▼ ブラウザ側でやること（プロジェクト作成）

ダッシュボードで「Create application」または「Pages」→「Connect to Git」
「Connect GitHub」をクリック
GitHub の認証画面で「Only select repositories」を選び、対象リポジトリだけを指定
「Install & Authorize」をクリック
Cloudflare に戻り、対象リポジトリを選択
「Begin setup」をクリック

▼ ブラウザ側でやること（ビルド設定）

Project name、Production branch、Build command、Build output directory を確認
分からない項目は Code に「これは何を入力すべき？」と聞く
通常は Build command と Build output directory は空白でOK
「Save and Deploy」をクリック
ビルドが始まる（数秒〜数十秒）

▼ ブラウザ側でやること（公開確認）

ビルド完了後、URL が表示される（例：https://your-app.pages.dev）
URL をクリックしてアプリを開く
動いていれば成功

▼ Code 側でやること（自動デプロイの確認）

プロジェクトに小さな変更を加える（例：見出しの色を変える）
Code に push してもらう
数十秒待つ
ブラウザで Cloudflare の URL を再読み込み
変更が反映されているはず

▼ スクショ伴走のチェックポイント

Cloudflare Pages のプロジェクト作成画面
GitHub 連携画面
ビルド完了画面（URL が表示される）
自分のアプリが世界に公開されている画面

【つまずきポイント】

GitHub 連携で「All repositories」と「Only select」がある。後者を選んで対象を絞るのが安全
ビルド設定の項目を勝手に埋めない。Code に確認しながら、空白でいいものは空白に
初回デプロイが失敗しても慌てない。ビルドログをスクショして Code に貼ればよい

【確認問題】

Cloudflare Pages と GitHub を連携すると、何が自動化されますか？
ビルド設定で分からない項目があった時、まず何をしますか？

【次のレッスンへの橋渡し】

世界に公開できました！次は、僕が v2.4 で実装した「メール通知機能」を、自分も実装してみます。

10-8. メール通知の追加（Resend + Supabase Edge Function、訪看v2.4相当）

【学習目標】

アプリにメール送信機能を追加できる
Resend と Supabase Edge Function を組み合わせる感覚を掴む

【前提知識】

10-7 で世界にアプリを公開できていること

【概念解説】

僕が訪看アプリ v2.4 で実装した、新規登録時に管理者にメール通知を送る機能。これを真似て、自分のアプリにメール機能を追加してみます。

メール送信の構成要素

[アプリ]
   ↓ 「新しい職員が登録した」と通知
[Supabase Edge Function]   ← 通知を受け取って送信処理
   ↓ メール送信を依頼
[Resend]                    ← メール送信サービス
   ↓ メールを送信
[管理者のメールボックス]

3つのサービスが連携する仕組み。

それぞれの役割

1. Resend

メール送信専用のサービス
月3,000通まで無料
API でメール送信できる

2. Supabase Edge Function

Supabase 上で動くサーバープログラム
「何かが起きたら、これを実行する」のような処理を書ける
ここから Resend にメール送信を依頼する

3. Database Webhook（Supabase の機能）

データベースに変更があった時、Edge Function を自動で呼び出す
「新規ユーザー登録があったら通知する」のような連携

これらを組み合わせて、「ユーザー登録 → 管理者にメール通知」のフローを作ります。

僕の実装の流れ

僕が訪看アプリでやった3ステップ：

Step 1: Resend アカウントを作って、API キーを取得
Step 2: Supabase Edge Function を作って、メール送信のコードを書く
Step 3: Database Webhook を設定して、登録時に Edge Function を呼ぶ

それぞれ Code に手伝ってもらいながら進めます。

重要：API キーの保管

Resend の API キーは「後から確認できないことがある」ので、作成時にメモ帳などにコピーしておくのが安全。僕も Code に「コピーしておいてください！後で Supabase に登録するので必要です」と注意されました。

【ハンズオン手順】

▼ ブラウザ側でやること（Resend のセットアップ）

ブラウザで https://resend.com にアクセス
GitHub アカウントでサインイン
ダッシュボードで「Add API Key」をクリック
API キーが表示される → コピーして安全な場所に保存
「Send email」のテストでメールが届くか確認

▼ Code 側でやること（Edge Function の作成）

Code に次のように依頼

Supabase の Edge Function を使って、新規ユーザー登録時に
管理者にメール通知を送る機能を追加したいです。

メール送信には Resend を使います。
Resend の API キー：[キー]
管理者のメールアドレス：[アドレス]

実装の Plan を提示してください。

Code が Plan を提示
Plan を確認して OK
Code が Edge Function のコードを生成
表示されたコードを Supabase Edge Function に貼り付け（Code が手順を案内してくれます）

▼ Supabase 側でやること（Edge Function のデプロイ）

Supabase ダッシュボードで「Edge Functions」を開く
新規 Function を作成
Code が出したコードを貼り付け
「Deploy Function」をクリック

▼ Supabase 側でやること（Database Webhook の設定）

Code に「Database Webhook の設定方法を教えて」と依頼
Code が手順を案内
手順に従って Webhook を設定
「ユーザー登録時に Edge Function を呼び出す」設定が完了

▼ 動作確認

アプリで新規ユーザー登録を試す
管理者のメールアドレスに通知メールが届くはず

▼ スクショ伴走のチェックポイント

Resend で API キーを発行した画面
Edge Function のコードが Supabase にデプロイされた画面
Database Webhook の設定画面
実際に届いた通知メール

【つまずきポイント】

API キーは作成時にコピーする。後から見られないことが多い
Edge Function のデプロイ後、初回呼び出しが失敗することがある。少し時間を置いて再試行
メールが届かない時は、迷惑メールフォルダを確認。Resend のテストメールはたまに迷惑メール扱いになる

【確認問題】

メール通知に関わる3つのサービスは何ですか？
API キーを取得した時の注意点は何ですか？

【次のレッスンへの橋渡し】

メール通知ができました！第10章最後のレッスンで、僕が実際に経験した「ホスティング移行」の話に進みます。

10-9. ホスティング移行体験 — Netlify→Cloudflare Pages（訪看v2.4相当）

【学習目標】

ホスティングの引っ越しがどんな流れか把握する
「移行＝怖い」ではなく「移行＝普通の作業」だと知る

【前提知識】

10-7 で Cloudflare Pages に公開できていること

【概念解説】

僕は訪看アプリで Netlify を使っていましたが、開発が進んで Netlify の無料枠を使い切ってしまいました。Cloudflare Pages に移行することにしたのが v2.4 のタイミング。

「ホスティングを変える」と聞くと身構える

「ホスティングを変えるって、ものすごく大変なんじゃ？」と思いがちですが、実はそんなに大変じゃないんです。

理由は、Web アプリの構成要素のうち：

コード：GitHub にある → 移行しなくていい
データ：Supabase にある → 移行しなくていい
ホスティングだけ：これを Netlify から Cloudflare Pages に変えるだけ

つまり、ホスティング以外は全部そのまま使えるんですよ。コードもデータも、引っ越しの対象ではないんです。

変わるのは URL だけ

唯一変わるのは「アプリの URL」。

[移行前] my-app.netlify.app
   ↓
[移行後] my-app.pages.dev

これは仕方ない。ただし、独自ドメイン（例：my-app.com）を設定していれば、ホスティングを変えてもユーザーから見れば URL は変わらない。

僕の実体験

僕が Netlify から Cloudflare Pages に移行した時のやり取り：

僕：まるっとお引越しして問題はない？

Code：問題ないです。
- コード：GitHub リポジトリはそのまま使う（変更不要）
- データ：Supabase は独立しているので影響なし
- URL：新しい URL に変わる（Cloudflare のサブドメインになる）

URL が変わる点だけ注意ですが、将来独自ドメインを設定すれば
関係なくなります。

移行しますか？

僕は「そうか、じゃ移行しよう」と進めて、特に大きなトラブルなく完了しました。

移行の手順

1. Cloudflare Pages で新規プロジェクトを作る
2. 既存の GitHub リポジトリと連携（同じリポジトリでOK）
3. ビルド設定（10-7 と同じ）
4. デプロイ
5. 動作確認
6. （必要なら）Netlify のプロジェクトを削除

10-7 で Cloudflare Pages のセットアップを済ませている人は、もうこのステップは経験済み。なので、移行ハードルはさらに低いです。

「移行慣れ」しておくと将来安心

僕は「一度移行を経験しておくと、将来ホスティングを変えたくなった時に怖くなくなる」と言っています。

ホスティングを変える理由は色々：

無料枠を使い切った
もっと速いホスティングに変えたい
機能が物足りなくなった
価格を下げたい

そういう時に、「移行＝大ごと」ではなく「いつでもできる作業」と思えるかどうかで、判断の幅が変わります。

【ハンズオン手順】

▼ 仮想的に「移行」を体験する（実際の作業）

既に Cloudflare Pages を使っている人 → このレッスンは「読み物」として読むだけでOK
もし Netlify を使っている人 → 実際に移行してみる

▼ ブラウザ側でやること（移行検討）

ブラウザに次のように相談

私は今、Web アプリを Netlify で公開しています。
Cloudflare Pages に移行を検討しています。
注意すべき点と、具体的な手順を教えてください。

ブラウザが手順をまとめてくれる
不安があれば、ここで質問

▼ Code 側でやること（移行作業）

Code に次のように依頼

Netlify から Cloudflare Pages に移行したいです。
変更ポイントと、注意点を Plan として出してください。

Code が Plan を提示
確認して進める

▼ スクショ伴走のチェックポイント

Cloudflare Pages の新プロジェクト画面
移行後の動作確認画面
旧 Netlify プロジェクトを削除する前後の状態

【つまずきポイント】

環境変数の移行を忘れない。Netlify で設定していた環境変数（API キーなど）は、Cloudflare 側でも設定し直す必要がある
URL が変わるので、ユーザーに告知する（個人プロジェクトなら自分宛のメモで OK）
独自ドメインを使っている場合は、DNS 設定の変更が必要

【確認問題】

ホスティングを変える時、移行が不要なのは何ですか？
ホスティング移行で変わるのは何ですか？

【次のレッスンへの橋渡し】

第10章はこれで完了です。Web アプリを作って公開する、その全プロセスを体験しました。

訪看アプリの v1.x（ローカル版）から v2.5（細かい修正済み版）までの道のりを、お疲れさまでした。あなたも今、同じ流れで自分のアプリを作れるはずです。

次の第11章は、認証と決済を組み込む話。「ログインしないと使えない」「お金を払って使う」アプリを作る時の流れです。