ShareShopiのCloudflare移行を再現できる技術記録にする

2026年06月29日から2026年07月05日にかけては、shared-shopping-app という共有買い物リストアプリのリポジトリで、ShareShopi の UX 改修と Cloudflare 移行を進めつつ、その変更を Gatsby ベースの個人技術ブログへ再利用可能な形で残す運用を整えた。ここでいう worklog-blogger は、Codex セッションログと Git 履歴から日次 worklog と週次記事の下書きを生成する自作スキルである。

この事例の主題は二つある。ひとつは ShareShopi を Supabase 依存から Firebase Auth と Cloudflare D1 中心の構成へ移すこと。もうひとつは、その移行作業を「後から読んで再現できる技術記録」に変換するために、日次 worklog の品質ゲートを ブログ側で整えたことだ。

この記事で解決すること

Cloudflare 移行は、認証、データ、API、運用文書が同時に動くため、単なる作業ログでは再現しづらい。この記事では、次の悩みを解く。

• Supabase 依存から Firebase Auth と Cloudflare D1 へ寄せる判断を整理したい。
• UI、API、DB、運用ドキュメントを混ぜずに移行記録へ落としたい。
• 後から検証できるよう、テスト済みの範囲と残課題を明確にしたい。

実施した改善

週の前半は、ブログ側で日次 worklog を保存する運用を毎日見直し、自動生成直後の草稿に残る抽象表現を減らした。週の後半は、ShareShopi 側でローディング UI の共通化、Firebase Auth への認証移行、Cloudflare D1 へのデータ移行、Cloudflare 前提の build・deploy・運用ドキュメント更新を進めた。

単なる日報にしなかったポイントは、実装と記録を分けて扱ったことにある。草稿生成スキルは下書きを集める役割に留め、本文では shared-shopping-app とブログ側の変更内容、テスト、運用判断を主語に置いた。

確認できた成果

成果として大きかったのは、アプリ移行の実装知見と、その記録方法が同時に整理されたことだ。ShareShopi 側では Cloudflare へ寄せる構成が具体化し、ブログ側ではそれを draft 記事として壊さず残す最小の品質ゲートが固まった。

判断と進め方

最初に見えた問題は、自動生成された daily worklog に 対象アプリ のような未具体化表現が残ることだった。これでは、後から見返しても「どのリポジトリの、どの層を、なぜ変えたのか」が伝わらない。そこで 2026-06-29、2026-07-01、2026-07-02、2026-07-04 の worklog では、ブログ側の記事データ契約、gatsby-source-filesystem による取り込み、validate-content.js による静的検証を確認しながら、人手で内容を具体化する流れを繰り返した。

そのうえで 2026-07-03 の ShareShopi では、実装の中心が明確だった。まず App Router のローディング表現を共通ローダーへ寄せて UX の揺れを減らし、その後に認証とデータ保存を Cloudflare 向け構成へ移した。最後に README.md、CLOUDFLARE_MIGRATION.md、無料運用の制約文書を更新し、build・preview・deploy の入口をコードと同じ日に揃えた。

この順番が有効だった理由は、UI、認証、データ、運用文書を一度に変えても、各層の責務を切り分けて説明できるからだ。後から週次記事へする時も、変更のまとまりごとに知識を再構成しやすかった。

使った技術

この事例の技術選定は、ログ生成ツールではなく、実際に変更したアプリとリポジトリを中心に整理した方が分かりやすい。

重要なのは、草稿生成スキルを「アプリの実装技術」としては扱わなかったことだ。あれは source material を集める補助であり、この事例の実装上の知見は ShareShopi の Cloudflare 移行と、ブログ側でその変更記録を安全に保持する運用にある。

構成

ShareShopi の移行後イメージは、認証、API、データ、運用ドキュメントの責務を分ける形に寄っている。

flowchart LR
  U["ブラウザ / Next.js UI"] --> A["Firebase Auth"]
  U --> B["Next.js API Routes"]
  A --> B
  B --> C["Cloudflare D1"]
  B --> D["公開リンク / リマインド処理"]
  E["README / Migration Docs"] --> B
  E --> C

フロントエンドでは components/app-loader.tsx を中心にローディング UI を共通化し、App Router の loading.tsx とナビゲーション中の待機表示をそろえた。API 層では lib/api-auth.ts が bearer token を受け、lib/firebase-token.ts で検証した結果を lib/d1.ts の viewer 解決へつなぐ。データ層では D1 の migration で profiles、共有リスト、メンバー、商品、招待、リマインド履歴を管理し、Supabase 側に散っていた責務を Cloudflare 前提へ集約した。

一方で記録側のブログ側はシンプルで、_data/blog/*.md がデータ層、Gatsby のファイル収集と Markdown 変換が表示層、validate-content.js が受け入れ検証層になる。この事例ではこの「実装アーキテクチャ」と「記録アーキテクチャ」を混ぜないことが重要だった。

採用理由と代替案

Firebase Auth を選んだ理由は、Google ログインとメールログインを Workers 本体へ抱え込まず、認証だけを独立サービスとして安定させたかったためだ。D1 を選んだ理由は、Cloudflare Workers と同じ基盤で API・DB・Cron を寄せられ、無料運用の条件を考えると構成が単純になるからである。

Supabase を段階的に残す選択肢もあったが、認証とデータアクセスの二重経路が残ると、権限境界と移行後の検証が難しくなる。そこで firebase_uid を追加しつつ D1 側へ viewer 解決を寄せ、旧 callback route や heartbeat 実装を削除する方向が採られた。

ブログ側で validate-content.js を品質ゲートに据えたのも同じ発想だ。weekly/daily 記事の変更はアプリコード改修よりコンテンツ追加が中心なので、まず壊れやすいのは frontmatter 契約と path の整合性である。毎回フル build を回すより、最短の静的検証でドラフト品質を守る方が作業密度に合っていた。

検証結果

確認した観点は、ShareShopi の認証、データ、API、運用文書を Cloudflare 移行の構成要素として分けて確認した点にある。確認した主な観点は次の通り。

npm test
npm run build
npm run test:e2e
# Firebase ID Token 検証テスト
# OpenNext / Wrangler の build・preview・deploy 手順確認

Supabase 依存を段階的に残す案と、Firebase Auth + D1 へ寄せる案を比較し、権限境界を単純にする方針を採った。

導入手順

この事例の流れを再利用可能な手順へ落とすと、次の順で進めるのが現実的だった。

1. ShareShopi の既存依存を棚卸しし、Supabase が担っていた認証、共有 API、公開リンク、リマインド、保存処理を分解する。
2. UI では共通ローダーを追加し、loading.tsx とナビゲーションの待機表示をそろえて、移行中でも利用者の体験を安定させる。
3. 認証では firebase-client.ts と firebase-token.ts を追加し、クライアントログインとサーバー側トークン検証を分離する。
4. データでは D1 migration を追加し、lib/d1.ts と API routes を介して共有リスト関連の読み書きを Cloudflare 側へ寄せる。
5. build / deploy では README.md と CLOUDFLARE_MIGRATION.md に、npm run cf:build、preview、wrangler d1 migrations apply、deploy の順を明示しておく。
6. 記録では草稿生成スキルの dry-run を確認したうえで、ブログ側の Markdown に対象リポジトリ名、変更箇所、テスト、未実施の release 項目を書き戻す。
7. 最後に validate-content.js で記事契約を確認し、公開に進まない場合でも draft として再利用できる状態にする。

build と deploy については、この事例の source material では「手順を更新した」ことまでは確認できたが、Cloudflare preview 実行結果や remote migration 完了までは確認できていない。したがって、手順の整備と反映準備は進んだが、最終 release 完了ではない。

制約と残課題

一番大きい課題は、Supabase が暗黙に持っていた認証・権限・データ責務を、Firebase token 検証と D1 側の API 実装へ明示的に書き戻す必要があったことだ。RLS に寄っていた部分をアプリコード側へ引き取るため、viewer 解決や閲覧権限の境界をコードで説明できる状態にしなければならなかった。

次の課題は、移行作業そのものよりも記録の精度だった。dry-run 直後の worklog は抽象表現やローカル文脈を含みやすく、そのままでは週次記事に使えない。結果として、ブログ側の記事契約に合わせて毎回人手で具体化し、どこまでテストし、どこから先は未実施かを明記する必要があった。

もうひとつは、build・deploy・無料運用の境界をドキュメントで揃える難しさである。実装だけ Cloudflare 前提に変わっても、README や migration 手順書が古いままだと、次に触る人が誤った順序で作業しやすい。この事例ではそこまで含めて同日に更新した点が重要だった。

次の改善候補

• ShareShopi では npm test、npm run test:e2e、npm run cf:build を継続的に通し、D1 移行後の回帰を早めに固定したい。
• Firebase token 検証だけでなく、公開リンク閲覧、共有メンバー権限、リマインド処理まで含む API テストを増やす余地がある。
• Cloudflare preview と remote D1 migration の実行結果を別 worklog として残し、release 手順書を実測ベースで固めたい。
• 草稿生成スキル には未解決プレースホルダや抽象語を検出する警告を足し、weekly 記事化の手補正量を下げたい。
• ブログ側では frontmatter 検証に加えて、必要なら draft 記事の build 確認を自動化し、レンダリング崩れも早めに拾えるようにしたい。