Claude Code × Neon：DBブランチをPRと連動させるサーバーレスPostgres活用術

Claude Code × Neon：DBブランチをPRと連動させるサーバーレスPostgres活用術

はじめに

ステージング環境のDBを誰かが壊してしまい、チーム全員の作業が止まった——共有のデータベースを複数人で使い回していると、こういった事故は避けにくい。Gitではブランチを切ることで個人の作業が独立するのに、DBは依然として「みんなで1つを共有する」形のままだ。

Neonはそのギャップを埋めるサービスだ。PostgreSQLをサーバーレスで提供しながら、「DBブランチ」という機能でGitと同じ感覚でDB環境を分岐できる。PRを作るたびに専用のDB環境を用意し、マイグレーションのテストが終わったら本番に反映する——Claude Codeの公式MCPサーバーを使うと、この一連の流れをほぼ自然言語だけで操作できる。

Neonが解決する問題

エッジ・サーバーレス環境でのPostgres接続

Cloudflare WorkersやVercel Edge FunctionsはTCP接続ができない。Node.jsのpgライブラリはTCP前提のため、エッジ環境でPostgresに接続しようとすると壁にぶつかる。

Neonが提供する@neondatabase/serverlessドライバーは、TCPの代わりにHTTPまたはWebSocketを使ってPostgresに接続する。エッジ環境のNetwork制約をそのまま回避できる。

HTTPモードは1回のfetchリクエストで完結するため、単発クエリに最速だ：

import { neon } from '@neondatabase/serverless';

const sql = neon(process.env.DATABASE_URL!);

// テンプレートリテラル（SQLインジェクション対策済み）
const posts = await sqlSELECT * FROM posts WHERE id = ${postId};

インタラクティブなトランザクションが必要な場合はWebSocketモードを使う。ただし、WebSocket接続はリクエストをまたいで使い回せないため、リクエストハンドラー内で毎回作成・破棄する必要がある：

import { Pool, neonConfig } from '@neondatabase/serverless';
import ws from 'ws';

neonConfig.webSocketConstructor = ws;

export default async (req: Request, ctx: any) => {
  const pool = new Pool({ connectionString: process.env.DATABASE_URL });
  const { rows } = await pool.query('SELECT * FROM posts WHERE id = $1', [postId]);
  ctx.waitUntil(pool.end());
  return new Response(JSON.stringify(rows));
};

Drizzle + Neonの組み合わせ

Drizzle ORMとNeonは公式ドキュメントで推奨される組み合わせだ：

npm install drizzle-orm @neondatabase/serverless
npm install -D drizzle-kit
// src/db/index.ts
import { drizzle } from 'drizzle-orm/neon-http';
import { neon } from '@neondatabase/serverless';

const sql = neon(process.env.DATABASE_URL!);
export const db = drizzle(sql);
// src/db/schema.ts
import { pgTable, serial, text, timestamp } from 'drizzle-orm/pg-core';

export const posts = pgTable('posts', {
  id: serial('id').primaryKey(),
  title: text('title').notNull(),
  content: text('content'),
  createdAt: timestamp('created_at').defaultNow(),
});

Claude Codeへの依頼は「schema.tsを読んで、この仕様で新しいテーブルを追加して」という形で通じる。スキーマファイルが1箇所に集まっている構造は、Claude Codeがコンテキストを掴みやすい。

ブランチ機能で変わるDB開発フロー

NeonのブランチはGitのコミットと同様のコピーオンライト（CoW）方式を採用している。データベースのサイズに関わらず、ブランチの作成は瞬時に完了する。差分のみを保存する仕組みのため、ストレージコストも抑えられる。

典型的な運用パターン：

- mainブランチ → 本番DB

- PRごとにフィーチャーブランチを作成

- そのブランチでマイグレーションをテスト

- 確認が取れたら本番ブランチに適用

- PRクローズ時にDBブランチを削除

この運用をGitHub Actionsで自動化する際は、neondatabase/create-branch-actionとneondatabase/schema-diff-actionを組み合わせることで、PRオープン時のブランチ作成・スキーマdiffのPRコメント表示・PRクローズ時のブランチ削除が自動で行える。

Claude CodeとNeon MCPの連携

MCPサーバーのセットアップ

NeonはClaude Code向けの公式MCPサーバー（mcp-server-neon）を提供している。最も簡単なセットアップはクイックセットアップコマンドだ：

npx neonctl@latest init

OAuth認証・APIキー作成・Claude Code設定を一括で自動化する。

手動でMCP設定を書く場合はリモート接続方式が使える（設定形式は公式ドキュメントで最新版を確認すること）：

{
  "mcpServers": {
    "Neon": {
      "type": "http",
      "url": "https://mcp.neon.tech/mcp"
    }
  }
}

APIキー認証の場合はAuthorizationヘッダーを追加する形になる。"type": "http"という設定形式が現在のClaude Codeで正しいかどうかは公式ドキュメントで確認してほしい。

MCPで使えるツール群

MCPを設定すると、Claude CodeからNeonの操作が自然言語で行えるようになる。

プロジェクト・ブランチ操作：

- create_project, list_projects, delete_project

- create_branch, delete_branch, describe_branch

- compare_database_schema（ブランチ間のスキーマdiff）

- reset_from_parent（親ブランチの状態にリセット）

SQL操作とマイグレーション：

- run_sql, run_sql_transaction

- prepare_database_migration（一時ブランチでテスト）

- complete_database_migration（本番ブランチに適用）

パフォーマンス分析：

- list_slow_queries, explain_sql_statement

自然言語でマイグレーションを実行する

MCPを使った安全なマイグレーションの流れは次のようになる。

「postsテーブルにupdated_atカラムを追加して」とClaude Codeに指示すると、まずprepare_database_migrationツールが実行される。一時ブランチが自動作成され、そこでマイグレーションのテストが行われる。問題がなければ確認を求められ、承認するとcomplete_database_migrationで本番ブランチに適用される。一時ブランチは自動的に削除される。

コードを一行も書かずに、本番DBに安全にスキーマ変更を反映できる。prepare_database_migrationが一時ブランチを使う設計になっているため、変更の影響を本番に反映する前に確認できる点が重要だ。

エンジニアリングマネジメントの視点

NeonとSupabaseの使い分け

Supabase記事（claude-code-supabase-baas）との差別化として、両者の位置付けを整理しておく。

SupabaseはPostgresを核にしながら、Auth・Storage・Realtime・Edge Functionsも提供するバックエンドフルスタックのサービスだ。一方でNeonはPostgresのみに特化した「サーバーレスPostgres専業」のサービスで、既存のORMやフレームワークと組み合わせて使う前提になっている。

「フロントエンドだけ作ればバックエンドはBaaSに任せたい」場合はSupabase、「PostgreSQLは使いたいが機能をBaaSに依存させたくない」場合はNeonという使い分けが実践的だ。

スケールゼロとコスト管理

Neonのアーキテクチャはストレージとコンピューティングを分離しており、アイドル時はコンピューティングを停止する。開発環境のDBが週末に動いていないのに課金され続けることがない。

Freeプランは永続的に使えてクレジットカード不要のため、試験的な導入ハードルが低い。PRごとにDBブランチを作り、PRクローズ時に削除する運用であれば、ブランチに対するコンピューティングコストはマイグレーション実行時間のみになる。

まとめ

NeonがClaude Codeとの組み合わせで際立つのは、MCPによる「自然言語でのDB操作」とブランチ機能による「PR連動のDB環境分離」の2点だ。

試すならnpx neonctl@latest initからMCPをセットアップし、「このテーブルにカラムを追加して」とClaude Codeに話しかけてみてほしい。コードを書かずにPostgresのスキーマが変更される体験が、今後のDB開発の基準点を変えるはずだ。

コメント

タイトルとURLをコピーしました