📚 この記事は「Claude Code 完全攻略シリーズ」の Episode 22 です。
- Claude Codeは要件定義からER図・スキーマ設計・マイグレーションファイルまで一貫して生成できる
- 既存DBの分析・正規化チェック・インデックス設計もプロンプト一つで実行可能
- SES現場で「DB設計タスク」を受けたときの実践ワークフローを紹介
「テーブル設計を任されたけど、正規化がこれで合っているか自信がない…」「マイグレーションファイルを手書きするのが面倒で、毎回ミスが怖い…」——SES現場でデータベース関連のタスクを担当するエンジニアなら、こうした不安を感じたことがあるのではないでしょうか。
Claude Codeを活用すれば、要件を自然言語で伝えるだけで、正規化されたスキーマ設計からマイグレーションファイルの生成まで一気通貫で対応できます。本記事では、データベース設計・マイグレーションにClaude Codeを活用する実践テクニックを解説します。
- Claude Codeで要件からER図・スキーマ設計を自動生成する方法
- 既存データベースの分析・正規化チェック・改善提案
- マイグレーションファイルの自動生成と安全な適用
- インデックス設計・パフォーマンスを考慮したDB設計
- SES現場でのDB設計ワークフロー
なぜClaude Codeがデータベース設計に強いのか
従来のDB設計の課題
データベース設計は、アプリケーション開発の基盤でありながら、多くのエンジニアが苦手意識を持つ領域です。
| 課題 | 具体例 | 影響 |
|---|---|---|
| 正規化の判断が難しい | 第3正規形まで崩すべきか迷う | パフォーマンスと保守性のトレードオフ |
| 命名規則の統一が困難 | snake_case・camelCase・日本語混在 | チーム開発でのコンフリクト |
| マイグレーション作成が手間 | ALTER TABLE文の手書きミス | 本番環境でのデータ破損リスク |
| 影響範囲の見落とし | カラム変更がアプリ側に波及 | 回帰バグの発生 |
Claude Codeの強み
Claude Codeがデータベース設計で力を発揮する理由は、アプリケーションコードとデータベーススキーマの両方を理解した上で設計できる点にあります。
要件定義・仕様書
↓
Claude Codeがエンティティとリレーションを抽出
↓
正規化されたスキーマ設計 + ER図を出力
↓
マイグレーションファイル生成 + ORM定義の更新
ORMの定義、APIのエンドポイント、バリデーションロジックまで横断的に見た上でスキーマを設計するため、アプリケーションとDBの整合性が担保された設計が可能です。

要件からスキーマ設計を自動生成する
新規テーブル設計の基本フロー
新しい機能のためのテーブル設計をClaude Codeに依頼する際は、ビジネス要件を自然言語で伝えるだけで十分です。
# 新規機能のテーブル設計を依頼
> ECサイトの注文管理機能を作りたい。以下の要件がある:
- ユーザーは複数の商品を1回の注文で購入できる
- 注文にはクーポンを1つ適用できる
- 配送先は複数登録でき、注文ごとに選択する
- 注文ステータスは「未決済→決済済→発送準備→発送済→配達完了」
既存のusersテーブルとproductsテーブルを踏まえて、
必要なテーブル設計をER図付きで提案して。
Claude Codeは既存のスキーマを読み取った上で、以下のような設計を提案します。
-- 配送先テーブル
CREATE TABLE shipping_addresses (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
user_id BIGINT NOT NULL,
label VARCHAR(50) NOT NULL DEFAULT '自宅',
postal_code VARCHAR(8) NOT NULL,
prefecture VARCHAR(10) NOT NULL,
city VARCHAR(50) NOT NULL,
address_line1 VARCHAR(100) NOT NULL,
address_line2 VARCHAR(100),
phone VARCHAR(15) NOT NULL,
is_default BOOLEAN NOT NULL DEFAULT FALSE,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE,
INDEX idx_shipping_addresses_user_id (user_id)
);
-- 注文テーブル
CREATE TABLE orders (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
user_id BIGINT NOT NULL,
shipping_address_id BIGINT NOT NULL,
coupon_id BIGINT,
status ENUM('pending','paid','preparing','shipped','delivered')
NOT NULL DEFAULT 'pending',
subtotal DECIMAL(10,2) NOT NULL,
discount DECIMAL(10,2) NOT NULL DEFAULT 0,
shipping_fee DECIMAL(10,2) NOT NULL DEFAULT 0,
total DECIMAL(10,2) NOT NULL,
ordered_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (user_id) REFERENCES users(id),
FOREIGN KEY (shipping_address_id) REFERENCES shipping_addresses(id),
FOREIGN KEY (coupon_id) REFERENCES coupons(id),
INDEX idx_orders_user_id (user_id),
INDEX idx_orders_status (status)
);
-- 注文明細テーブル
CREATE TABLE order_items (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
order_id BIGINT NOT NULL,
product_id BIGINT NOT NULL,
quantity INT NOT NULL DEFAULT 1,
unit_price DECIMAL(10,2) NOT NULL,
subtotal DECIMAL(10,2) NOT NULL,
FOREIGN KEY (order_id) REFERENCES orders(id) ON DELETE CASCADE,
FOREIGN KEY (product_id) REFERENCES products(id),
INDEX idx_order_items_order_id (order_id)
);
ER図の自動生成
Claude Codeは、Mermaid記法でER図を生成することも得意です。
# ER図の生成を依頼
> 今設計したテーブルのER図をMermaid記法で出力して。
リレーションのカーディナリティも明示して。
erDiagram
users ||--o{ shipping_addresses : "has"
users ||--o{ orders : "places"
orders ||--|{ order_items : "contains"
orders }o--|| shipping_addresses : "ships to"
orders }o--o| coupons : "applies"
products ||--o{ order_items : "included in"
生成されたMermaid図は、そのままドキュメントに埋め込んだり、設計レビューの資料として活用できます。
既存データベースの分析と改善
スキーマの健全性チェック
SES現場では、既存プロジェクトに途中参加して既存DBを分析するケースが頻繁にあります。Claude Codeを使えば、スキーマの問題点を網羅的に洗い出せます。
# 既存スキーマの分析を依頼
> このプロジェクトのデータベーススキーマを分析して、
以下の観点で問題点をリストアップして:
1. 正規化の問題(冗長なデータ、更新異常のリスク)
2. インデックスの過不足
3. 外部キー制約の欠落
4. 命名規則の不統一
5. データ型の選択ミス
Claude Codeはマイグレーション履歴やORMの定義ファイルを自動的に読み込み、以下のような分析結果を返します。
## スキーマ分析結果
### 🔴 重大な問題
1. `orders.address` にJSON文字列で住所を格納
→ 正規化違反。検索・更新が困難
→ 推奨: shipping_addressesテーブルに分離
2. `products`テーブルにインデックスがない
→ category_id, priceでのクエリが全テーブルスキャン
→ 推奨: 複合インデックス追加
### 🟡 改善推奨
3. `users.phone`が VARCHAR(255)
→ VARCHAR(15) で十分。ストレージ効率に影響
正規化レベルの判断
「どこまで正規化すべきか」は、パフォーマンスと保守性のトレードオフです。Claude Codeに相談すれば、プロジェクトの特性を踏まえた判断を提案してくれます。
# 正規化の相談
> このreportsテーブルに user_name と department_name を
直接持たせているのは非正規化だと思うが、
このプロジェクトの読み書き比率を考慮して、
正規化すべきか非正規化のまま残すべきか判断して。
Claude Codeは、該当テーブルのクエリパターン(読み取り頻度 vs 書き込み頻度)をアプリケーションコードから分析し、根拠のある判断を提示します。
マイグレーションファイルの自動生成
ORM対応のマイグレーション生成
Claude Codeは、プロジェクトで使用しているORMを自動検出し、適切な形式でマイグレーションファイルを生成します。
# Prismaの場合
> usersテーブルにprofile_image_urlカラムを追加して、
Prismaのschema.prismaを更新し、マイグレーションを生成して。
# TypeORMの場合
> ordersテーブルのstatusカラムをENUMに変更する
マイグレーションを作成して。既存データの変換も含めて。
# Sequelizeの場合
> productsテーブルにsoft deleteを追加するマイグレーションを
作成して。deleted_atカラムの追加と、既存クエリの修正も含めて。
安全なマイグレーション設計
本番環境へのマイグレーション適用は、最もリスクの高い作業の一つです。Claude Codeは、安全性を考慮したマイグレーション設計を提案します。
# 安全なマイグレーションの作成を依頼
> productsテーブルのpriceカラムをINTからDECIMAL(10,2)に
変更したい。本番環境でダウンタイムなしで実行する
マイグレーション戦略を提案して。
Claude Codeは、以下のような段階的な移行戦略を提案します。
-- Step 1: 新カラムを追加(ダウンタイムなし)
ALTER TABLE products ADD COLUMN price_decimal DECIMAL(10,2);
-- Step 2: データを移行(バッチ処理で段階的に)
UPDATE products SET price_decimal = price / 100.0
WHERE price_decimal IS NULL LIMIT 10000;
-- Step 3: アプリケーションコードを更新(両方のカラムを参照)
-- → デプロイ後に動作確認
-- Step 4: 旧カラムを削除(十分な検証後)
ALTER TABLE products DROP COLUMN price;
ALTER TABLE products RENAME COLUMN price_decimal TO price;
この段階的アプローチにより、万が一問題が発生しても前のステップにロールバックできます。
インデックス設計の最適化
クエリパターンからのインデックス提案
インデックスの設計は、実際のクエリパターンに基づいて行うべきです。Claude Codeは、アプリケーションコードで実行されるクエリを分析し、最適なインデックスを提案します。
# インデックス最適化を依頼
> このプロジェクトのSQLクエリとORM呼び出しを分析して、
不足しているインデックスを提案して。
各インデックスの効果(推定)も教えて。
## インデックス最適化提案
1. orders(user_id, status) 複合インデックス
→ マイページの注文一覧クエリが使用
→ 推定効果: フルスキャン → インデックスシーク(100倍高速化)
2. products(category_id, is_active, price) カバリングインデックス
→ カテゴリ別商品一覧のクエリが使用
→ 推定効果: テーブルアクセス不要(10倍高速化)
3. order_items(order_id) ※既に存在するが
order_items(order_id, product_id) に拡張推奨
→ 注文詳細取得時のルックアップ削減
不要なインデックスの検出
インデックスが多すぎると書き込み性能が低下します。Claude Codeは、使われていないインデックスの特定も行います。
# 不要インデックスの検出
> データベースのインデックスを分析して、
アプリケーションコードのクエリで使われていない
インデックスをリストアップして。削除しても安全かも判断して。
テーブル設計のベストプラクティス
Claude Codeに設計レビューを依頼する
テーブル設計が完了したら、Claude Codeにレビューを依頼しましょう。以下のプロンプトが効果的です。
# 設計レビューを依頼
> 以下の観点でこのDB設計をレビューして:
1. 第3正規形を満たしているか
2. 将来の拡張性(新しい要件への対応しやすさ)
3. パフォーマンス(想定アクセスパターンでの効率)
4. データ整合性(制約・トリガーの適切さ)
5. 命名規則の一貫性
改善が必要な箇所はSQLコード付きで修正案を出して。
論理削除 vs 物理削除の判断
SES現場では「削除」の実装方針を決める場面が頻繁にあります。
# 削除方針の相談
> このプロジェクトのusersテーブルで論理削除を実装したい。
deleted_atカラムの追加と、既存の全クエリに
WHERE deleted_at IS NULL を追加するマイグレーション、
及びORMレベルでのデフォルトスコープ設定を作成して。
Claude Codeは、既存のクエリすべてを走査し、漏れなく条件を追加します。また、管理画面など「削除済みも含めて表示したい」箇所を自動的に検出し、別途対応を提案してくれます。
SES現場でのDB設計ワークフロー
実践的なワークフロー
SES現場でDB設計タスクを受けたときの、Claude Codeを活用した実践ワークフローを紹介します。
1. 要件ヒアリング結果をClaude Codeに共有
↓
2. ER図 + テーブル定義書を自動生成
↓
3. Claude Codeに設計レビューを依頼
↓
4. レビュー結果を反映して設計を修正
↓
5. マイグレーションファイルを自動生成
↓
6. ステージング環境で動作確認
↓
7. 本番適用(ロールバック手順も用意)
プロンプトテンプレート集
SES現場ですぐに使えるDB設計関連のプロンプトテンプレートをまとめました。
テーブル設計の依頼:
> [要件を記述]の機能を実装するためのテーブル設計をして。
既存スキーマとの整合性を確認し、ER図(Mermaid)と
CREATE TABLE文を出力して。インデックス設計も含めて。
マイグレーション生成:
> [変更内容]のマイグレーションを作成して。
ロールバック可能な設計にして、既存データの移行スクリプトも含めて。
本番環境での実行手順も教えて。
スキーマ分析:
> このプロジェクトのDB設計を分析して、
改善すべき箇所を優先度順にリストアップして。
各改善のリスクと効果も見積もって。
注意すべきポイント
Claude Codeに任せきりにしない
Claude Codeは優れた設計を提案しますが、以下の点は必ず人間が確認すべきです。
| 確認項目 | 理由 |
|---|---|
| ビジネスロジックとの整合性 | Claude Codeは業務知識を完全には理解できない |
| データ量の見積もり | テーブルの成長速度はプロジェクト固有 |
| バックアップ・リカバリ戦略 | インフラ構成に依存 |
| 機密データの暗号化 | セキュリティポリシーはプロジェクトごとに異なる |
マイグレーションの実行前チェックリスト
本番環境にマイグレーションを適用する前に、以下を必ず確認しましょう。
- ステージング環境で実行済みか
- ロールバック手順が用意されているか
- データバックアップが完了しているか
- ロック時間の見積もりを確認したか(大規模テーブルのALTER TABLEは特に注意)
- アプリケーション側の変更と同時にデプロイする必要があるか
まとめ
Claude Codeを活用することで、データベース設計・マイグレーションの品質とスピードを大幅に向上させることができます。
| 活用シーン | Claude Codeでできること |
|---|---|
| 新規テーブル設計 | 要件から正規化されたスキーマ+ER図を自動生成 |
| 既存DB分析 | 正規化・インデックス・命名規則の問題を網羅的に検出 |
| マイグレーション | ORM対応のマイグレーションファイルを安全に生成 |
| インデックス最適化 | クエリパターンに基づく最適なインデックスを提案 |
| 設計レビュー | 複数の観点で設計の問題点を指摘 |
特にSES現場では、プロジェクトごとに異なるORM・DB製品・命名規則に素早くキャッチアップする必要があります。Claude Codeを「DB設計のペアプログラミング相手」として活用することで、品質を維持しながらスピーディにタスクを完了できます。
ただし、ビジネスロジックの理解やデータ量の見積もりなど、プロジェクト固有の判断は必ずエンジニア自身が行うことを忘れないでください。Claude Codeはあくまで強力なアシスタントであり、最終的な設計判断の責任はエンジニアにあります。