GTMエンジニアリングのフレームワーク選定ガイド -- React Router v7, Hono, Prisma, n8nを組み合わせる理由

Phase 3の総まとめ

Phase 3ではGTMエンジニアリングの技術基盤を具体的なフレームワークとツールの組み合わせにまで落とし込んできた。4層モデルで全体像を俯瞰し、技術選定フレームワークでインフラの判断基準を定め、インフラ実測比較でCloudflare Workers / AWS Lambda / Vercelを数字で比較した。モノレポ構成ではプロジェクト全体のディレクトリ設計を定義した。

この記事はPhase 3の最後として、フレームワーク層の選定を扱う。インフラの上に載せるフレームワークとして、React Router v7、Hono、Prisma、n8nの4つを組み合わせる技術的根拠を示す。

「好きだから」「流行っているから」ではなく、GTMエンジニアリングの業務特性から逆算した選定理由を示す。

フレームワーク選定の判断軸（GTMエンジニアリング固有）

プロダクトエンジニアのフレームワーク選定とは、評価軸が異なる。GTMエンジニアリング固有の4つの判断軸を先に定義する。

判断軸1: 営業チームが使うUI

GTMエンジニアが構築するフロントエンドの主たるユーザーは営業チームだ。営業ダッシュボード、リードリスト、デモ環境管理画面、KPIレポート。これらは社内ツールであり、外部公開のプロダクトとは要件が異なる。

SEOが不要な代わりに、SSRによる初期表示速度が求められる。営業は朝の出社直後にダッシュボードを開く。10秒待たされるダッシュボードは使われない。クライアントサイドレンダリングだけでは、初期表示にJavaScriptのパース・実行時間が加わり、体感速度が悪化する。SSRで初期HTMLを返し、ハイドレーション後にインタラクティブにするアプローチが最適。

判断軸2: API中心のバックエンド

4層モデルの記事で整理した通り、GTMエンジニアリングのバックエンドはCRM API（HubSpot / Salesforce）、エンリッチメントAPI（Clay / Apollo）、AI API（Claude / GPT）との統合が中心になる。自前でビジネスロジックを書くというよりも、外部APIを繋ぎ、変換し、CRMに書き戻すパイプラインを構築する。

判断軸3: データアクセス層

GTMシステムのデータは大きく2種類ある。自前のDB（リード管理、スコアリング結果、デモテナント）と、CRMのデータ（HubSpot/Salesforceが正）。4層モデルの原則「Single Source of TruthはCRM」に従うと、自前DBはキャッシュやワーキングデータの保管が主な役割になる。

判断軸4: ワークフローエンジン

GTMエンジニアリングの自動化パイプラインは、Claude APIによるスコアリング、CLAUDE.mdベースのAgent Team、CRM Webhookトリガーなど、複数のステップを連結する。これをコードだけで管理するか、ワークフローエンジンで可視化するかは重要な判断だ。

この4つの判断軸を踏まえて、各フレームワークの選定理由を述べる。

React Router v7を選ぶ理由

SSR + file-based routing

React Router v7はSSR対応のfile-based routingを標準で提供する。app/routes/ ディレクトリにファイルを置くだけでルーティングが定義される。

app/
  routes/
    _index.tsx           → /
    dashboard.tsx        → /dashboard
    leads.$leadId.tsx    → /leads/:leadId
    settings.tsx         → /settings

営業ダッシュボードで必要なルートは10-20程度。file-based routingなら、ルート定義を別ファイルに切り出す必要がなく、ファイル名がそのままURLパスになる。チームに新しいメンバーが加わったとき、ルーティング設計の理解に要する時間が短い。

Loaderパターンとデータフェッチ

React Router v7のLoaderパターンは、営業ダッシュボードとの相性が良い。各ルートに対応するデータフェッチをcolocateできる。

typescript
// app/routes/dashboard.tsx
import type { Route } from './+types/dashboard'

export async function loader({ context }: Route.LoaderArgs) {
  const [pipelineData, topLeads, weeklyMetrics] = await Promise.all([
    context.api.getPipelineSummary(),
    context.api.getTopLeads({ limit: 10, minScore: 70 }),
    context.api.getWeeklyMetrics(),
  ])

  return {
    pipeline: pipelineData,
    leads: topLeads,
    metrics: weeklyMetrics,
  }
}

export default function Dashboard({ loaderData }: Route.ComponentProps) {
  const { pipeline, leads, metrics } = loaderData

  return (
    <div className="grid grid-cols-3 gap-6">
      <PipelineSummary data={pipeline} />
      <TopLeadsTable leads={leads} />
      <WeeklyMetricsChart metrics={metrics} />
    </div>
  )
}

Loaderの特徴は3つある。

1. データフェッチとUIのcolocate: ダッシュボードに表示するデータの取得ロジックが、表示コンポーネントと同じファイルにある。営業チームから「この画面にリードスコアの分布グラフを追加してほしい」と言われたとき、変更すべきファイルは1つだけ。

2. 並列フェッチ: Promise.all() でパイプライン情報、トップリード、週次メトリクスを同時に取得する。営業ダッシュボードの初期表示時間は、最も遅いAPIコールに律速される。直列フェッチでは3つのAPIコールの合計時間がかかるが、並列なら最長の1つ分で済む。

3. 型安全: Route.LoaderArgs と Route.ComponentProps により、Loaderの返り値とコンポーネントのpropsが型レベルで接続される。返り値の型を変更すれば、コンポーネント側でコンパイルエラーが出る。

React 19対応

React Router v7はReact 19をサポートしている。Server Components、Actions、use hookなどReact 19の新機能を段階的に導入できる。

GTMエンジニアリングの文脈でReact 19が効くのは、Server Componentsによる営業ダッシュボードの構築だ。

typescript
// app/routes/leads.$leadId.tsx
// React Server Component として動作
export default async function LeadDetail({ params }: Route.ComponentProps) {
  const lead = await fetchLeadFromCRM(params.leadId)
  const analysis = await fetchAIAnalysis(params.leadId)

  return (
    <div>
      <LeadHeader lead={lead} />
      <AIAnalysisPanel analysis={analysis} />
      {/* クライアントコンポーネントはインタラクティブ部分のみ */}
      <LeadActions leadId={params.leadId} />
    </div>
  )
}

Server Componentsではデータフェッチがサーバー上で完結するため、クライアントにAPIキーを渡す必要がない。CRM APIトークンやClaude APIキーがクライアントバンドルに含まれない設計が自然に実現する。

Cloudflare Pages / Vercel 両方にデプロイ可能

React Router v7は複数のデプロイターゲットをサポートする。

bash
# Cloudflare Pages
npx create-react-router@latest --template cloudflare

# Vercel
npx create-react-router@latest --template vercel

# Node.js
npx create-react-router@latest --template node

インフラ実測比較で述べた「まず始めるならCloudflare Workers、フロントエンド込みならVercel」という選択肢の両方に対応できる。インフラを切り替えるとき、ルーティングとコンポーネントのコードはそのままで、設定ファイルの変更だけで済む。

vs Next.js: シンプルさとCloudflare Workers親和性

Next.jsは2026年時点でも最も使われているReactフレームワークだ。React Router v7を選ぶ理由は「Next.jsが劣っている」からではなく、GTMエンジニアリングの文脈でReact Router v7の方が適合する判断軸が3つあるからだ。

GTMエンジニアリングではAPI層をHonoで独立させる設計を採る（理由は後述する）。React Router v7はフロントエンドに徹し、APIはHonoに任せるという分離がきれいに成立する。Next.jsのAPI Routesを使うとフロントエンドとAPIが密結合になり、API層だけをCloudflare Workersにデプロイする構成が取りにくい。

vs Remix: React Router v7はRemixの後継

React Router v7は事実上Remixの後継プロジェクトだ。Remix v2で導入された機能（Loader、Action、nested routing）がReact Router v7に統合され、Remixは個別プロジェクトとしての開発を終了した。

Remix v1 → Remix v2 → React Router v7
                         ↑ ここに統合

Remixの設計思想（Web Standardsベース、プログレッシブエンハンスメント、Loaderによるデータフェッチ）がReact Router v7に引き継がれている。Remixを検討していたなら、React Router v7がその答えだ。

Honoを選ぶ理由

マルチランタイム対応

Honoの最大の差別化要因はマルチランタイム対応だ。同一のコードベースが複数のランタイムで動作する。

typescript
// src/app.ts -- ビジネスロジックは共通
import { Hono } from 'hono'
import { crmProxy } from './routes/crm-proxy'
import { aiPipeline } from './routes/ai-pipeline'
import { webhook } from './routes/webhook'

const app = new Hono()

app.route('/api/crm', crmProxy)
app.route('/api/ai', aiPipeline)
app.route('/api/webhook', webhook)

export default app

typescript
// Cloudflare Workers エントリポイント
export default app

// AWS Lambda エントリポイント
import { handle } from 'hono/aws-lambda'
export const handler = handle(app)

// Bun エントリポイント
export default { port: 3000, fetch: app.fetch }

// Node.js エントリポイント
import { serve } from '@hono/node-server'
serve({ fetch: app.fetch, port: 3000 })

インフラ実測比較で示した通り、GTMエンジニアリングでは複数プラットフォームの併用が現実的な構成になる。CRM API中継はCloudflare Workers、AIパイプラインはAWS Lambda、ローカル開発はBun。Honoならビジネスロジックは1つのコードベースで、エントリポイントの差し替えだけでデプロイ先を変更できる。

Web Standards APIベース

HonoはWeb Standards API（Request、Response、Headers、URL）をベースに構築されている。Node.js固有のAPI（http.IncomingMessage、http.ServerResponse）には依存しない。

typescript
// Hono のハンドラ: Web Standards の Request/Response を使う
app.get('/api/leads', async (c) => {
  // c.req は standard Request のラッパー
  const url = new URL(c.req.url)
  const email = url.searchParams.get('email')

  // Response も standard
  return new Response(JSON.stringify({ leads }), {
    headers: { 'Content-Type': 'application/json' },
  })
  // または Hono のヘルパー
  return c.json({ leads })
})

Web Standards APIをベースにすることで、Cloudflare Workers（V8 isolate）、Deno、Bunなど、Node.js以外のランタイムでも追加の互換性レイヤーなしに動作する。インフラ比較記事のWebhook受信シナリオで示した通り、node:crypto の代わりに Web Crypto API を使えば3プラットフォーム共通のコードが書ける。

ミドルウェアの軽量さ

Honoのミドルウェアは関数の合成で実装される。GTMエンジニアリングで必要なミドルウェアを見てみる。

typescript
import { Hono } from 'hono'
import { cors } from 'hono/cors'
import { logger } from 'hono/logger'
import { jwt } from 'hono/jwt'
import { zValidator } from '@hono/zod-validator'

const app = new Hono()

// グローバルミドルウェア
app.use('*', logger())
app.use('*', cors({ origin: 'https://dashboard.example.com' }))

// 認証: JWT検証
app.use('/api/*', jwt({ secret: 'your-secret' }))

// テナント解決: マルチテナント対応
app.use('/api/tenant/*', async (c, next) => {
  const tenantId = c.req.header('X-Tenant-ID')
  if (!tenantId) {
    return c.json({ error: 'Tenant ID required' }, 400)
  }
  c.set('tenantId', tenantId)
  await next()
})

// CRMレート制限ミドルウェア
app.use('/api/crm/*', async (c, next) => {
  const allowed = await checkRateLimit(c.env.KV, 'hubspot', 110, 10)
  if (!allowed) {
    return c.json({ error: 'CRM rate limit exceeded' }, 429)
  }
  await next()
})

各ミドルウェアが独立した関数で、必要なルートにだけ適用できる。技術選定フレームワークで述べたCRM APIレート制限への対応も、ミドルウェアとして分離できる。

OpenAPI統合（Hono + Zod OpenAPI）

@hono/zod-openapi を使うと、Zodスキーマからルート定義とOpenAPIドキュメントを同時に生成できる。

typescript
import { OpenAPIHono, createRoute, z } from '@hono/zod-openapi'

const LeadSchema = z.object({
  id: z.string().openapi({ example: 'lead_01' }),
  email: z.string().email().openapi({ example: 'tanaka@example.co.jp' }),
  company: z.string().openapi({ example: 'Example Corp.' }),
  aiScore: z.number().min(0).max(100).openapi({ example: 85 }),
  hypothesis: z.string().openapi({ example: 'DX推進中のため業務効率化ニーズあり' }),
})

const route = createRoute({
  method: 'get',
  path: '/api/leads',
  responses: {
    200: {
      content: { 'application/json': { schema: z.array(LeadSchema) } },
      description: 'リード一覧を取得',
    },
  },
})

const app = new OpenAPIHono()

app.openapi(route, async (c) => {
  const leads = await fetchLeads()
  return c.json(leads)
})

// /doc でOpenAPI JSONを公開
app.doc('/doc', { openapi: '3.1.0', info: { title: 'GTM API', version: '1.0.0' } })

// /swagger でSwagger UIを公開
app.get('/swagger', swaggerUI({ url: '/doc' }))

なぜOpenAPIが重要か。GTMエンジニアが構築するAPIの利用者は、別のGTMエンジニアやn8nのHTTP Requestノードだ。OpenAPIドキュメントがあれば、n8nのCode Nodeからの呼び出しやPostmanでの動作確認が容易になる。営業チームに「このAPIは何ができるのか」を説明する際にも、Swagger UIを見せれば済む。

vs Express: パフォーマンスと型安全性

Expressは2026年時点でもNode.jsのデファクトスタンダードだが、GTMエンジニアリングの主戦場であるCloudflare Workersでは動作しない。Honoに移行するコストは低い。ExpressからのマイグレーションはAPIインターフェースの差異が小さいため、ルーティング定義とミドルウェアの書き換えで完了する。

vs Fastify: エッジランタイム非対応

FastifyはNode.js上のパフォーマンスではHonoと同等以上だが、Cloudflare Workers / Deno / Bunで動作しない。GTMエンジニアリングの「まずCloudflare Workersで始めて、必要に応じてAWS Lambdaに拡張する」というパターンに適合しない。Node.js専用のバックエンドを最初から前提にするなら、Fastifyも有力な選択肢だ。

Prismaを選ぶ理由

型安全なクエリビルダー

Prismaのスキーマ定義からTypeScriptの型が自動生成される。

prisma
// prisma/schema.prisma
model Lead {
  id              String   @id @default(uuid())
  email           String   @unique
  company         String
  industry        String
  employeeCount   Int
  aiScore         Int?
  hypothesis      String?
  triggerEvent    String?
  lifecycleStage  LifecycleStage @default(SUBSCRIBER)
  tenantId        String
  createdAt       DateTime @default(now())
  updatedAt       DateTime @updatedAt

  tenant          Tenant   @relation(fields: [tenantId], references: [id])
  activities      Activity[]

  @@index([tenantId])
  @@index([aiScore])
}

model Tenant {
  id              String   @id @default(uuid())
  companyName     String
  industry        String
  slug            String   @unique
  status          TenantStatus @default(ACTIVE)
  expiresAt       DateTime
  createdAt       DateTime @default(now())
  updatedAt       DateTime @updatedAt

  leads           Lead[]
  seedData        SeedData[]

  @@index([status, expiresAt])
}

enum LifecycleStage {
  SUBSCRIBER
  LEAD
  MQL
  SQL
  OPPORTUNITY
  CUSTOMER
}

enum TenantStatus {
  ACTIVE
  EXPIRED
  DELETED
}

このスキーマから生成されるPrisma Clientは、クエリの入出力が完全に型付けされる。

typescript
// 型安全なクエリ: aiScoreが存在しないフィールド名を書くとコンパイルエラー
const highScoreLeads = await prisma.lead.findMany({
  where: {
    tenantId: currentTenantId,
    aiScore: { gte: 70 },
    lifecycleStage: 'SQL',  // enum値もコンパイル時に検証
  },
  orderBy: { aiScore: 'desc' },
  take: 20,
  include: {
    activities: {
      orderBy: { createdAt: 'desc' },
      take: 5,
    },
  },
})
// highScoreLeads の型は (Lead & { activities: Activity[] })[] と推論される

営業チームの要望に応じてスキーマが頻繁に変わるGTMシステムでは、型安全なクエリビルダーがリファクタリングのセーフティネットになる。カラム名を変更すれば、そのカラムを参照している全てのクエリでコンパイルエラーが出る。ランタイムエラーとして本番で発覚するリスクを排除できる。

マイグレーション管理

Prismaのマイグレーションは prisma migrate dev でスキーマの差分をSQLマイグレーションファイルとして生成する。

bash
# スキーマ変更後にマイグレーション生成
npx prisma migrate dev --name add-lead-source-field

# 生成されるファイル
# prisma/migrations/20260426_add_lead_source_field/migration.sql

sql
-- prisma/migrations/20260426_add_lead_source_field/migration.sql
ALTER TABLE "Lead" ADD COLUMN "source" TEXT;
ALTER TABLE "Lead" ADD COLUMN "sourceDetail" TEXT;
CREATE INDEX "Lead_source_idx" ON "Lead"("source");

マイグレーションファイルはGit管理される。「いつ、誰が、どのスキーマ変更を行ったか」がcommit historyから追跡できる。CLAUDE.mdの記事で述べた「営業の暗黙知をバージョン管理する」思想と同じく、データスキーマの変更もバージョン管理する。

マルチテナント対応

カスタムデモ環境の記事で実装したマルチテナント設計を、Prisma Client Extensionsで宣言的に実現する。

typescript
// src/db/tenant-client.ts
import { PrismaClient } from '@prisma/client'

export function createTenantClient(tenantId: string) {
  const prisma = new PrismaClient()

  return prisma.$extends({
    query: {
      $allOperations({ args, query }) {
        // 全クエリにtenantIdフィルターを自動適用
        if ('where' in args) {
          args.where = { ...args.where, tenantId }
        }
        return query(args)
      },
    },
  })
}

// 使用時
const tenantPrisma = createTenantClient('tenant_abc')

// tenantIdの指定なしでクエリを書いても、自動的にフィルターされる
const leads = await tenantPrisma.lead.findMany({
  where: { aiScore: { gte: 70 } },
  // 内部的に { tenantId: 'tenant_abc', aiScore: { gte: 70 } } に変換される
})

Row-Level Security（RLS）をアプリケーションレベルで実装するパターンだ。テナント間のデータ漏洩を防ぐフィルターが全クエリに自動適用されるため、開発者がクエリごとにtenantIdを指定し忘れるリスクがない。

PostgreSQLネイティブのRLSを使う場合は以下のようになる。

sql
-- PostgreSQL Row-Level Security
ALTER TABLE "Lead" ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON "Lead"
  USING (tenant_id = current_setting('app.current_tenant_id')::text);

typescript
// Prismaからの利用
await prisma.$executeRaw`SET app.current_tenant_id = ${tenantId}`
const leads = await prisma.lead.findMany({ where: { aiScore: { gte: 70 } } })

どちらのアプローチも有効だが、Prisma Client ExtensionsはDB非依存のため、PostgreSQLからCloudflare D1（SQLiteベース）に移行する際にもコードの書き換えが少ない。

vs Drizzle: Prismaエコシステムの成熟度

DrizzleはPrismaの有力な代替だ。SQLに近いクエリ構文が特徴で、生成されるSQLの予測可能性が高い。

Drizzleはエッジランタイムとの親和性で優位だ。PrismaのQueryEngineはWASMバイナリを含むため、Cloudflare Workersのバンドルサイズ制限（1MB / Freeプラン）に抵触する可能性がある。Prisma AccelerateやD1 adapterで回避可能だが、Drizzleならこの問題が最初から存在しない。

それでもPrismaを選ぶ理由は、エコシステムの成熟度にある。

• Prisma Studio: GUIでデータを確認・編集できるツール。営業から「このリードのスコアを手動で修正したい」と言われたとき、SQLを書かずに対応できる
• Prisma Migrate: マイグレーションの競合解決、本番環境への適用フローが確立している
• Prisma Pulse: テーブルの変更をリアルタイムに検知するChange Data Capture。リードのスコアが更新されたらSlackに通知する、といったイベント駆動処理に使える
• ドキュメントとコミュニティ: 日本語を含む膨大なドキュメント、Stack Overflowの回答数、サードパーティのチュートリアルの蓄積

Drizzleはパフォーマンスとエッジ親和性で優れているが、GTMエンジニアが1-3名で運用するチームでは、成熟したエコシステムとドキュメントの充実度が日々の運用効率に直結する。Prismaのエコシステムは5年以上の蓄積がある。

vs TypeORM: 型安全性

TypeORMはデコレータベースのORMで、TypeScriptとの統合は古い設計に基づく。

typescript
// TypeORM: デコレータ + クラスベース
@Entity()
class Lead {
  @PrimaryGeneratedColumn('uuid')
  id: string

  @Column()
  email: string

  @Column({ nullable: true })
  aiScore: number
}

// クエリの型安全性が弱い
const leads = await leadRepository.find({
  where: { aiScor: 70 }, // タイポしてもコンパイルエラーにならない場合がある
})

typescript
// Prisma: スキーマファイルから型を自動生成
const leads = await prisma.lead.findMany({
  where: { aiScor: 70 }, // コンパイルエラー: 'aiScor' は存在しない
})

TypeORMのデコレータベースの型定義は、ランタイムのリフレクションに依存するため、コンパイル時の型検証に限界がある。Prismaはスキーマファイルから型を静的に生成するため、クエリのフィールド名のタイポやフィルター条件の型ミスマッチをコンパイル時に検出する。

GTMシステムのスキーマは営業要件の変化に応じて頻繁に変更される。「aiScore」を「leadScore」にリネームする際、Prismaなら prisma generate 後に参照箇所すべてでコンパイルエラーが出る。TypeORMでは一部の参照が漏れてランタイムエラーになるリスクがある。

n8nを選ぶ理由

セルフホスト（データ主権）

GTMエンジニアが扱うデータには、リード情報（氏名、メールアドレス、企業情報）、商談内容、営業戦略が含まれる。技術選定フレームワークで述べた個人データ保護への対応を考慮すると、ワークフローエンジンを外部SaaSに依存するリスクは見過ごせない。

n8nはDocker 1コンテナでセルフホスト可能だ。

bash
# Docker Compose で起動
docker compose up -d

# または Railway / Fly.io にワンクリックデプロイ

yaml
# docker-compose.yml
version: '3.8'
services:
  n8n:
    image: n8nio/n8n:latest
    ports:
      - '5678:5678'
    environment:
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_BASIC_AUTH_PASSWORD=${N8N_PASSWORD}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=Asia/Tokyo
    volumes:
      - n8n_data:/home/node/.n8n
    restart: unless-stopped

volumes:
  n8n_data:

セルフホストにより、ワークフローの実行ログ（含むリードデータ）が自社管理のインフラに閉じる。GDPRや日本の個人情報保護法への対応で「データが外部サービスを経由しない」ことを証明できる。

月額コストはRailway Hobby Planで$5、Fly.ioで$5-15程度。n8n Cloudの$24/月（2,500実行制限）と比較して、セルフホストはコスト面でも有利だ。

Code Nodeでの自由度

n8nのCode Nodeは、JavaScript/TypeScriptで任意のロジックを実行できる。

javascript
// n8n Code Node: Claude APIでリード分析
const Anthropic = require('@anthropic-ai/sdk')

const anthropic = new Anthropic({
  apiKey: $env.ANTHROPIC_API_KEY,
})

const lead = $input.first().json

const message = await anthropic.messages.create({
  model: 'claude-sonnet-4-5-20250514',
  max_tokens: 1024,
  messages: [{
    role: 'user',
    content: `以下のリードを分析し、0-100のスコアと課題仮説を生成してください。

企業名: ${lead.company}
業種: ${lead.industry}
従業員数: ${lead.employeeCount}
直近ニュース: ${lead.recentNews}`
  }],
})

const analysis = JSON.parse(message.content[0].text)

return [{
  json: {
    ...lead,
    aiScore: analysis.score,
    hypothesis: analysis.challenges.join(' / '),
    triggerEvent: analysis.triggerEvent,
  }
}]

Code Nodeの存在により、n8nは「ノーコードツール」の制約から解放される。LLM APIの呼び出し、カスタムスコアリングロジック、複雑なデータ変換、外部APIとの認証フローなど、ビジュアルノードだけでは表現できない処理をインラインで書ける。

これはCLAUDE.mdの記事で設計したAgent Teamのワークフローをn8n上で実行する際に不可欠な機能だ。

ビジュアルフロー（営業チームへの説明が容易）

n8nのワークフローエディタは、処理フローをGUIで可視化する。

[Schedule Trigger] → [HubSpot: 新規リード取得]
       ↓
[Code Node: データ整形]
       ↓
[HTTP Request: Claude API]
       ↓
[IF: aiScore > 70]
  ├─ YES → [HubSpot: Deal作成] → [Slack: 営業通知]
  └─ NO  → [HubSpot: ナーチャリング登録]

このビジュアルフローは3つの場面で効く。

1. 営業マネージャーへのレビュー: 「リードが入ったら、AIで分析して、スコア70以上なら商談を自動作成。それ以下はナーチャリングに回す」というロジックをフロー図で見せるだけで理解される。コードを読めない営業マネージャーも、条件分岐やデータの流れを視覚的に把握できる。

2. 営業チームによるフロー調整: スコアの閾値を70から60に変更する、Slack通知の宛先チャネルを変更する、ナーチャリングのメール文面を差し替える。これらの調整はn8nのGUI上でノーコードで行える。GTMエンジニアの手を借りずに、営業チームが自分でフローを微調整できる。

3. 障害時の原因特定: ワークフローが失敗した場合、n8nは各ノードの入出力データとエラーメッセージを保持する。「HubSpot APIがレート制限に引っかかった」「Claude APIのレスポンスがJSON parseに失敗した」といった原因が、ビジュアルフロー上で特定できる。

400以上の統合ノード

n8nは2026年時点で400以上の統合ノードを提供する。GTMエンジニアリングで特に使うのは以下。

統合ノードを使えば、HubSpotのAPIドキュメントを読んでHTTPリクエストを手書きする必要がない。ノードのGUIでフィールドを選択するだけで、コンタクトの作成やDealの更新が完了する。

vs Make: ノード数制限なし、セルフホスト

Makeの方がGUI上の操作性は洗練されている。非エンジニアにとっての学習コストはMakeの方が低い。しかし、GTMエンジニアリングのワークフローは「毎日1回、全リードに対してAI分析を実行する」といった大量実行を含む。月間リード数が500件で日次実行すると、1ワークフローあたり5-10オペレーションとして月間75,000-150,000オペレーションを消費する。Makeの上位プランでも月額が跳ね上がる。

n8nのセルフホストなら実行回数は無制限で、月額はインフラ費の$5-15のみ。コストの予測可能性が高い。

vs Zapier: カスタマイズ性

Zapierは最大のアプリ統合数を誇るが、ワークフロー構造がリニア（直線的）であるため、GTMエンジニアリングの複雑な分岐処理には向かない。「スコア70以上→営業Aに通知、50-69→ナーチャリング、49以下→除外、ただし特定業種は閾値を変える」といった多段の条件分岐をZapierで表現するのは手間がかかる。

n8nのグラフ構造なら、分岐と合流を自由に組み合わせられる。

4つのフレームワークの統合アーキテクチャ

ここまで個別に選定理由を述べてきた4つのフレームワークを、1つのアーキテクチャに統合する。

全体構成図

[React Router v7 on Cloudflare Pages]
         │ SSR/CSR
         │ fetch → /api/*
         ↓
[Hono API on Cloudflare Workers]
         │ REST API
         │ JWT認証 + テナントコンテキスト
         ↓
[Prisma + D1 / PostgreSQL]
         │ 型安全なクエリ
         │ マルチテナント分離
         ↓
[n8n (self-hosted on Railway)]
         │ ワークフロー実行
         │ Code Node → Claude API
         ↓
[CRM / 外部サービス]
  ├── HubSpot API
  ├── Salesforce API
  ├── Claude API
  ├── Slack API
  └── Clay API

フロントエンド → API の接続

React Router v7のLoaderからHono APIを呼び出す。

typescript
// app/routes/dashboard.tsx (React Router v7)
import type { Route } from './+types/dashboard'

export async function loader({ context }: Route.LoaderArgs) {
  const apiBase = context.env.API_URL // Hono APIのURL

  const response = await fetch(`${apiBase}/api/leads?minScore=70&limit=10`, {
    headers: {
      Authorization: `Bearer ${context.env.API_TOKEN}`,
      'X-Tenant-ID': context.tenantId,
    },
  })

  if (!response.ok) {
    throw new Response('Failed to fetch leads', { status: response.status })
  }

  return response.json()
}

フロントエンド（React Router v7 on Cloudflare Pages）とAPI（Hono on Cloudflare Workers）は別ドメインで動作する。dashboard.example.com と api.example.com のように分離することで、APIサーバーを独立してスケール・デプロイできる。

認証フロー（JWT + Cookie）

typescript
// Hono API側: 認証ミドルウェア
import { jwt } from 'hono/jwt'
import { setCookie, getCookie } from 'hono/cookie'

// JWT検証
app.use('/api/*', jwt({
  secret: env.JWT_SECRET,
  cookie: 'session_token',  // CookieからもJWTを読む
}))

// ログインエンドポイント
app.post('/api/auth/login', async (c) => {
  const { email, password } = await c.req.json()
  const user = await authenticateUser(email, password)

  if (!user) {
    return c.json({ error: 'Invalid credentials' }, 401)
  }

  const token = await sign({
    sub: user.id,
    tenantId: user.tenantId,
    role: user.role,
    exp: Math.floor(Date.now() / 1000) + 60 * 60 * 24, // 24時間
  }, c.env.JWT_SECRET)

  setCookie(c, 'session_token', token, {
    httpOnly: true,
    secure: true,
    sameSite: 'Lax',
    maxAge: 60 * 60 * 24,
    path: '/',
  })

  return c.json({ user: { id: user.id, email: user.email, role: user.role } })
})

営業ダッシュボードの認証にはJWT + HttpOnly Cookieの組み合わせを使う。SSR時にはCookieからJWTを読み取り、サーバーサイドでのAPI呼び出しに使用する。クライアントサイドではCookieが自動的にリクエストに付与されるため、フロントエンドのコードでトークン管理を意識する必要がない。

テナントコンテキストの伝播

マルチテナントシステムでは、リクエストが通過する全レイヤーでテナントコンテキストを伝播させる必要がある。

typescript
// Hono: テナント解決ミドルウェア
app.use('/api/*', async (c, next) => {
  const payload = c.get('jwtPayload')
  const tenantId = payload.tenantId

  // Prisma Clientにテナントコンテキストを設定
  const tenantPrisma = createTenantClient(tenantId)
  c.set('prisma', tenantPrisma)
  c.set('tenantId', tenantId)

  await next()
})

// ルートハンドラ: テナント分離されたクエリ
app.get('/api/leads', async (c) => {
  const prisma = c.get('prisma')

  // tenantIdフィルターが自動適用される
  const leads = await prisma.lead.findMany({
    where: { aiScore: { gte: 70 } },
    orderBy: { aiScore: 'desc' },
    take: 20,
  })

  return c.json(leads)
})

テナントコンテキストの伝播:

[Cookie] → JWT内のtenantId
    ↓
[Hono ミドルウェア] → c.set('tenantId', tenantId)
    ↓
[Prisma Client Extensions] → 全クエリにWHERE tenant_id = ?を自動付与
    ↓
[n8n Webhook] → ヘッダーでtenantIdを受け渡し
    ↓
[CRM API] → テナント別のAPIキーを使用（必要に応じて）

テナントIDはJWTに含まれ、認証と同時に解決される。Honoのミドルウェアがテナントコンテキストをリクエストスコープにバインドし、Prisma Client Extensionsがクエリレベルでテナント分離を強制する。n8nのWebhookにはHTTPヘッダーでテナントIDを伝播する。

この設計により、各レイヤーの開発者はテナント分離を意識せずにコードを書ける。テナント分離はミドルウェアとClient Extensionsが横断的に担保する。

トレードオフと注意点

この構成は万能ではない。既知のトレードオフと制約を明示する。

Cloudflare D1の制限

Cloudflare D1はSQLiteベースのサーバーレスデータベースだ。Cloudflare Workers上でPrismaを使う場合のDB選択肢の1つだが、制約がある。

回避策: 本番環境ではCloudflare D1ではなく、Neon（サーバーレスPostgreSQL）やSupabaseを使う。D1はデモ環境や軽量な社内ツールに限定し、営業パイプラインのメインDBはPostgreSQLを選択する。PrismaのdatasourceをD1からPostgreSQLに切り替えるのはスキーマファイルの1行変更で済む。

prisma
// D1の場合
datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

// PostgreSQLの場合
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

Prisma + Edge Runtimeの互換性

PrismaをCloudflare Workers上で動かす場合、Query EngineのWASMバイナリをバンドルに含める必要がある。

typescript
// Cloudflare Workers + Prisma + Neon の組み合わせ
import { PrismaClient } from '@prisma/client'
import { PrismaNeon } from '@prisma/adapter-neon'
import { Pool } from '@neondatabase/serverless'

export default {
  async fetch(request: Request, env: Env) {
    const neon = new Pool({ connectionString: env.DATABASE_URL })
    const adapter = new PrismaNeon(neon)
    const prisma = new PrismaClient({ adapter })

    // 通常通りPrisma Clientを使用
    const leads = await prisma.lead.findMany()

    return Response.json(leads)
  },
}

Prisma Accelerateを使えば、Prisma Client自体はEdge Runtimeで動作し、実際のDB接続はPrisma Accelerateのプロキシサーバーが処理する。バンドルサイズの問題も解消される。ただし、Prisma Accelerateは外部サービスへの依存となるため、データ主権の観点でトレードオフが発生する。

n8nのスケーリング

n8nのセルフホストは単一インスタンスで動作する。ワークフローの並列実行数はサーバーのCPU/メモリに依存する。

Queue Modeを有効にすると、n8nはメインプロセスとワーカープロセスを分離し、Redisをキューとして使って水平スケーリングが可能になる。

yaml
# docker-compose.yml (Queue Mode)
services:
  n8n-main:
    image: n8nio/n8n
    environment:
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
    command: n8n start

  n8n-worker:
    image: n8nio/n8n
    environment:
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
    command: n8n worker
    deploy:
      replicas: 3  # ワーカーを3台に水平スケール

  redis:
    image: redis:7-alpine

月間100,000ワークフロー実行を超える規模では、Queue Modeの導入が必要。GTMエンジニアリングの典型的なワークロード（日次リードパイプライン + Webhook駆動の即時処理）では、月間リード数5,000件程度なら小規模構成で十分だ。

代替構成パターン

ここまで述べたReact Router v7 + Hono + Prisma + n8nの構成を、異なる条件下で置き換える場合の代替パターンを示す。

パターンA: Next.js + tRPC + Drizzle（フルスタック統合重視）

フロントエンドとバックエンドを密結合にし、開発速度を最大化する構成。APIの分離が不要で、Vercelへのデプロイが前提の場合に適する。

Next.js App Router → tRPC → Drizzle → Neon PostgreSQL

トレードオフ: Cloudflare Workersへの移行が難しくなる。APIを他のサービスから呼び出しにくい。

パターンB: Hono + Drizzle + Temporal（長時間ワークフロー重視）

AIパイプラインの実行時間が長く、信頼性の高いワークフローエンジンが必要な場合。Temporalはコードベースのワークフローエンジンで、リトライ、サガパターン、タイマーを宣言的に書ける。

Hono → Drizzle → Temporal (self-hosted) → CRM/外部API

トレードオフ: 非エンジニアがワークフローを操作できない。n8nのビジュアルフローの利点を失う。

パターンC: Remix + Prisma + Make（ノンエンジニア協業重視）

営業チームやマーケチームがワークフローを直接編集する頻度が高い場合。MakeのGUIはn8nより操作性が良い。

Remix → Prisma → Make → CRM/外部API

トレードオフ: Makeの実行回数制限がコストに直結。セルフホストができない。

パターンD: AWS中心構成（エンタープライズ要件）

技術選定フレームワークのパターンCに対応する、VPC内完結の構成。

Next.js (Amplify) → Lambda (Hono) → Aurora → Step Functions → CRM

トレードオフ: 構築・運用コストが高い。小規模チームには過剰。

この組み合わせを実際に使ってみてわかったこと

このスタックを半年近く使って、選定時の想定と実際のズレが出た部分を残しておく。

Prismaのバンドルサイズ問題は想定より早く直面した。最初はCloudflare WorkersでPrismaを直接使おうとしたが、WASMバイナリが1MBのFreeプラン制限にすぐ引っかかった。結果的にNeon + Prisma Accelerateの組み合わせに切り替えた。Accelerateは外部依存が増えるが、Edge Runtimeとの相性を考えると今のところこれが現実解だ。DrizzleのほうがCloudflare Workersとの親和性は高く、新規プロジェクトなら選択肢として真剣に検討する。

n8nのUI操作を営業チームに委ねるのは、最初は心配だった。「フローを壊したらどうするか」という懸念があった。実際には、閾値の変更や通知先の変更程度なら問題なく自分でやってくれている。一方で、新しいワークフローの作成やCode Nodeの編集はエンジニアが担当するという暗黙の分担が自然に生まれた。n8nの「触れる範囲」が営業チームと合意できると、GTMエンジニアの介在コストが下がる。

React Router v7とHonoの分離は設計としてはきれいだが、型の二重管理が面倒だと感じることがある。HonoのZod OpenAPIでスキーマを定義し、React Router v7のLoader側でそのレスポンス型を手動でimportしている。tRPCのような型の自動伝播はないので、APIレスポンスの型をどう共有するかはモノレポのpackages/shared/で管理する方針にした。

Phase 3を通じて構築した技術基盤は、GTMエンジニアが1-2名で動かす規模には十分機能している。次の記事ではGTMエンジニアリングの組織導入ロードマップとして、この技術基盤を組織にどう広げるかに入る。1人目のGTMエンジニアの採用と、営業組織との協業モデルの確立について書く。

---

参考資料

• React Router v7 Documentation
• React Router v7 - Framework Mode
• Hono - Web Framework for the Edges
• Hono + Zod OpenAPI
• Prisma Documentation
• Prisma Client Extensions
• Prisma with Cloudflare Workers
• n8n Documentation
• n8n Queue Mode
• n8n Code Node
• Drizzle ORM
• Cloudflare D1 Documentation
• Neon - Serverless PostgreSQL
• Temporal - Durable Execution