AI Session Notes - 2026-02-12

Cloudflare Pagesでの独自ドメイン設定

学んだこと

Cloudflare Pagesで独自ドメインを使うにはルートドメインとサブドメインの2パターンがある
ルートドメイン（example.com）の場合、Cloudflareにゾーンとして追加し、ドメイン取得元でネームサーバーをCloudflare指定のものに変更する必要がある。CNAMEレコードはCloudflareが自動作成する
サブドメイン（blog.example.com）の場合、ネームサーバー変更は不要。DNSプロバイダーでCNAMEレコードを手動追加するだけで済む
必ずCloudflareダッシュボード経由でカスタムドメインを登録する。手動でDNSレコードだけ追加すると522エラーが発生する
SSL証明書はCloudflareが自動発行（無料）
ネームサーバー変更の反映は数分〜最大48時間かかる
Cloudflare Registrarでドメインを取得すれば、ネームサーバー変更の手間が不要で最もシンプル

ドメインレジストラの選び方

学んだこと

お名前.comは営業メール大量・管理画面がわかりにくい・自動更新解除が面倒・アップセルが激しいなど、UX面で評判が悪い
Cloudflare Registrarはドメインを卸値（原価）で販売しており、上乗せがない。ただしドル建てのため為替の影響を受ける
国内の円建てレジストラとしてはXserver Domainが評判が良い（.comで約1,500円/年、.jpは約1,200円/年〜）
一時的なサイト（イベント用、ジョークサイト等）であれば、独自ドメインを取得せず*.pages.devのサブドメインで十分な場合が多い
ドメインの要否は用途（一時的 vs 恒久的、ブランディングの必要性）で判断する

サーバー処理が必要なWebアプリの構成選択

学んだこと

フロントエンドで完結するアプリ（静的サイト、JSゲーム等）はCloudflare Pagesだけで十分
リアルタイム通信やデータ永続化が必要な場合は、追加のバックエンドサービスが必要
選択肢は大きく3つ：BaaS（Firebase/Supabase）、Cloudflare Workers + α、自前サーバー
Cloudflare PagesとFirestoreを組み合わせる構成も可能（ホスティングはCloudflare、リアルタイム部分だけFirebase）

WebSocketの仕組み

学んだこと

通常のHTTPでは、クライアントがサーバーに「新着ある？」と繰り返し問い合わせる（ポーリング）。無駄が多い
WebSocketでは、クライアントとサーバーが常時接続を維持する。サーバー側から即座にデータを送れる
チャットの場合、AさんとBさんがそれぞれサーバーとソケットを張り、サーバーが中継する。A↔Bが直接つながるわけではない
グループチャットでは、サーバーが「誰がどのルームにいるか」を管理し、同じルームの全員にメッセージを転送する

Firestoreのリアルタイムリスナー

学んだこと

FirestoreはWebSocketの代わりにリアルタイムリスナー（onSnapshot）という仕組みでリアルタイム通信を実現する
クライアントがFirestoreのデータを購読（リッスン）し、データが変更されると自動で通知される
クライアントとDBが直接つながっているため、サーバーレス関数の起動待ち（コールドスタート）がない
AWS Lambdaには「しばらくアクセスがないと初回の応答に数百ms〜数秒かかる」コールドスタート問題があるが、Firestoreは常時稼働のマネージドサービスなので発生しない

Firestoreのセキュリティルールと認証判断

学んだこと

FirestoreはNoSQLのドキュメントDBであり、RDBとは異なる。クライアント直結でもセキュリティルールで安全に使える
セキュリティルールはDB自体に組み込まれたアクセス制御の仕組みで、従来サーバー側で書いていた認証・認可ロジックを代替する
認証なし（allow read, write: if true）でも運用可能だが、本番では書き込み条件（文字数制限、更新・削除禁止など）をルールで制約すべき
認証の要否はアプリの性質で判断する。例えば部屋IDを共有して遊ぶゲームなら、部屋ID自体がアクセスキーとして機能するため認証不要
部屋IDを推測されにくいランダム文字列にすれば、連番による総当たり問題も防げる

Firestoreの料金体系

学んだこと

Firestoreの無料枠は日あたり：読み取り50,000回、書き込み20,000回、削除20,000回、ストレージ1GB
個人の趣味レベルのアプリ（簡単なゲームやチャット）なら無料枠で十分収まる
従量課金に切り替わっても単価は安い（読み取り10万回で約$0.06、書き込み10万回で約$0.18）
予算アラートを設定しておけば想定外の課金を防げる

パスワードなしの簡易ログイン実装パターン

学んだこと

Firebase Anonymous Auth — 匿名ユーザーが自動生成され、名前をFirestoreに紐付ける。ブラウザが匿名IDを保持する
LocalStorage + 名前 — 最もシンプルだが、同じ名前で衝突するリスクがある
名前 + ランダムID — 表示名は名前、裏ではランダムIDで一意に識別する。Firebase Authすら不要でFirestoreだけで完結する
いずれの方法もブラウザを変えたら別人になる点は共通。一時的な用途なら許容できる

Firestoreのデータ確認方法

学んだこと

FirestoreのデータはFirebaseコンソール（Webブラウザ）からツリー構造で一覧・編集・削除できる。別途クライアントソフトのインストールは不要
Firebase Emulator UIを使えば、本番データを触らずローカルでデータを確認・操作できる
Firebase CLIからデータのエクスポート・インポートも可能
Firestoreのデータ構造はRDBのテーブル形式ではなく、コレクション > ドキュメント > フィールドのツリー構造で表示される

FirebaseとFirestoreの関係

学んだこと

Firebaseは単体のサービスではなく、サービス群のブランド名（Firestore, Authentication, Hosting, Cloud Functions, Analytics等）
Firebaseプロジェクトを作成した上で、使いたいサービスだけ有効にして使える。全部入りで使う必要はない
FirebaseにはDBが2種類ある：Cloud Firestore（新・推奨）とFirebase Realtime Database（旧・レガシー）
ネットの古い記事ではRealtime Databaseの情報が出てくることがあるので、Cloud Firestoreの方を選ぶこと

Claude Codeの権限設定（permissions）

学んだこと

Claude Codeの権限設定ファイルにはスコープの異なる2種類がある
~/.claude/settings.json — グローバル設定。全セッションで適用される
<project>/.claude/settings.local.json — プロジェクト設定。そのディレクトリから起動したセッションのみ適用
Bashコマンドの許可パターンでは、ワイルドカード * の前のスペースの有無が重要
Bash(mkdir *) — mkdir + 任意の文字列にマッチ（mkdir -p /path/to/dir など）
Bash(mkdir*) — mkdir で始まる任意の文字列にマッチ（意図しないコマンドにもマッチしうる）
旧形式の :*（コロン + アスタリスク）は非推奨。現在はスペース + * が正しい形式
mkdir のような非破壊的なコマンドはパス制限なしで許可しても安全
権限設定の変更はClaude Codeの再起動後に反映される

メタ情報

ツール: Claude Code
関連技術: Cloudflare Pages, DNS, CNAME, SSL, ドメインレジストラ, Claude Code permissions, WebSocket, Firebase, Firebase Firestore, Firebase Realtime Database, Firebaseコンソール, Firebase Emulator, リアルタイムリスナー, セキュリティルール, NoSQL, Firebase Anonymous Auth, LocalStorage, コールドスタート, AWS Lambda, SQS, SNS