Cloudflare Edge Architecture Map — 生存戦略スタック・インデックス

はじめに

なぜ、AIを使っても設計負債の利払いに追われるのか

AIの登場で開発の速さはコモディティ化しました。
それでも多くのプロダクトは、修正のたびに別の場所が壊れ、移行作業に時間を溶かします。原因は人ではなく、AIが最大性能を発揮できない構造を最初に選んでしまうことです。

典型的な失敗モードは3つです。

局所最適化：変更影響範囲が暗黙に広がる密結合構造のため、AIの提案が部分最適に留まる
不可視な依存：外部SaaSや実行環境への依存が曖昧で、自動修正の成功率が下がる
評価不能な境界：ビルド〜テスト〜デプロイが一気通貫で実行できず、修正の安全性を機械的に判定できない

これは「AIに任せても壊れない設計」を選定段階で外しているという構造的エラーです。

本マップの評価軸（AI時代の設計4原則）

本記事は、以下の4条件を満たすかどうかで技術を評価します。

疎結合（変更範囲の限定）：1機能の変更で触るモジュール数が限定される
依存の可視化（明示的な入出力）：データの流れと外部依存がコード上で追跡可能
自動化可能な境界（ワンコマンド完結）：ビルド・テスト・デプロイが単一経路で完結
置換可能性（部品交換）：外部契約を保ったまま内部実装を交換できる

この地図を使うと、AIに任せても壊れない設計から始められます。

この記事をおすすめしない人

現在の構成に長期的な不安がなく、変更の必要がない
技術選定の「なぜ」より「すぐ動く手順」だけを求めている
構造の持続性より短期の便益を優先する

技術的負債が静かに積み上がる瞬間

Edge実行で動かない依存が後から露出し、機能を作り直す
外部SaaSの障害や価格変更が、そのまま自サービスの停止要因になる
バンドルや実行制約を誰も管理せず、デプロイが通らなくなる

10年後も動き続ける「製造ライン」という選択

ClaudeMixのスタック全体を選定理由付きで把握できる
技術を「連合選択／連動／独立選択／事実上の標準」で整理した操作可能な地図を得られる
不採用技術の失敗モードを記録しているため、同じ轍を回避できる

このブログも同じ道を通った

最初から最適解が見えていたわけではありません。実行環境とのミスマッチや依存の不可視性に何度もぶつかり、構造の選び直しを繰り返しました。本記事は、その試行錯誤を評価軸に沿って再構成した技術選定の地図です。各技術の詳細な選定記録も公開します。

ラインのコンセプト

このスタックが防ぐ負債は2種類です。単一依存による崩壊リスクと実行環境ミスマッチ。

外部SaaSへの過度な依存は、障害・値上げ・仕様変更が即座に自サービスの停止要因になります。実行環境と設計の不一致は、ローカルで通る修正が本番で失敗する温床です。

そこで本ラインは、Web標準への準拠とEdge実行環境との整合を軸に構成しています。
入出力は標準APIで固定し、Node固有依存を露出させず、ビルド〜デプロイを単一経路に保つ。流行ではなく、部品交換で延命できる構造を優先します。

Cloudflareは単なる一社ベンダーではない。D1（構造データ）・KV（TTL付き短命データ）・R2（大容量オブジェクト）・Durable Objects（リアルタイム状態）という状態レイヤーを持つ【Edge OS】を構築している。これはUnixのファイル/メモリ/DB/プロセス状態に対応する。このシリーズが問うのは「どのツールを選ぶか」ではなく、「Edgeアプリの状態をどこに置くか」という配置ルールだ。Vercel＋Supabase＋Upstash＋Resendという「SaaSパッチワーク」と比べて依存が最小化され、依存を減らすほどAIが扱いやすい構造になる。

この地図は、道具の一覧ではありません。AIが扱える構造を先に選ぶための製造ライン設計図です。

標準採用リスト

React Router × Cloudflare スタック

Webアプリのフレームワークとホスティング実行環境を「連合選択」として1本の軸で決めています。React Router v7はWeb標準（Fetch API・FormData・HTTPヘッダー）に則った設計であり、Cloudflare PagesはそのスタンダードをEdge Runtimeで活かせる実行基盤を提供します。Vite・Vitest・TypeScriptはReact Router v7の採用により連動して決まります。

技術	選定種別	一言選定理由（延命医の診断）
React Router v7	連合選択	Web標準に準拠した設計で、Cloudflare Edge RuntimeとNode.js依存なしで動く
Cloudflare Pages/Workers	連合選択	EdgeでのゼロコールドスタートとD1/KV/R2との一元管理を実現する実行基盤
Vite	React Router連動	React Router v7でビルダーとして標準採用。React Router選択により自動決定
Vitest	Vite連動	Viteと設定共有でき、Jest移行コストゼロ。Vite採用により自然に決まる
TypeScript	React Router連動	React Router v7がTypeScriptファーストのため、型安全を追加コストなしに得られる

詳細な選定記録 → React Router × Cloudflare / Vite / Vitest / TypeScript

Cloudflareネイティブ層

Cloudflare Workersという実行環境を選んだことで自然に構成されるデータ層です。D1はリレーショナルデータ（長命データ）、KVは揮発性データ（短命データ）という役割分担で設計しています。Remix-authのEdge非対応が自前認証実装の起点になりましたが、各技術はそれぞれ独立した根拠で選定しています。

技術	選定種別	一言選定理由（延命医の診断）
Cloudflare D1	独立選択	SQLiteベースのEdgeネイティブDB。長命データ（ユーザー・サブスク状態）の保存先として構造的に最適
Cloudflare KV	Workers連動	temporal state（時間付き状態）専用のストレージ。TTLで寿命を管理するため、削除バッチ・cronが不要になる
Resend	独立選択	REST APIのみで動作するEdge対応のメール送信基盤。外部SaaS依存の最小化に寄与

詳細な選定記録 → D1 / KV / Resend

CSSインフラ層

技術	選定種別	一言選定理由（延命医の診断）
Tailwind CSS	独立選択	PurgeCSSによる未使用CSS自動削除でWorkersのバンドルサイズを制御し、Viteと一元管理できるCSSインフラ

詳細な選定記録 → Tailwind CSS

収益基盤

技術	選定種別	一言選定理由（延命医の診断）
Stripe	独立選択	サブスクリプション決済の事実上の業界標準。Webhook・API設計がWebコンベンション準拠

詳細な選定記録 → Stripe

E2Eテスト

技術	選定種別	一言選定理由（延命医の診断）
Playwright	事実上の標準	Microsoftメンテナンス・Chromium/Firefox/WebKit対応の業界標準E2Eツール

詳細な選定記録 → Playwright

代替案・不採用の記録

不自然な構造（悪）として、検討したが採用しなかった技術を記録します。

技術	不採用理由
Remix-auth	Cloudflare Workers（Edge Runtime）でNode.js依存部分が動かず不採用。この制約がD1/KV/Resendによる自前認証実装の起点になった
Clerk	選定時点では未認知。仮に知っていたとしても「ユーザーDBがClerk側とD1側に分散する問題」と「外部SaaS障害時に認証全停止するリスク」がある
Google認証のみ	Google OAuth単独構成はGoogleのポリシー変更・障害でサービス全体が止まるリスク。Googleとメール認証の二重構成で外部への単一依存を排除し、サービス存続力を確保

メンテナンスポリシー

このカタログは、採用技術のメジャーバージョンアップまたは不採用判断が生じた際に更新します。更新日と変更理由をこのセクションに追記してください。

このマップを起点に、各技術の詳細な選定記録・実装ボイラープレート・設定の勘所はL3記事（ClaudeMixガイド・有料）として順次公開していきます。

この地図が、あなたの技術選定の「なぜ」を整理する一助になれば幸いです。