- Codex CLIで要件定義からER図・スキーマ定義を自然言語で自動生成
- Prisma・TypeORMのマイグレーションファイル作成と差分管理を自動化
- SES現場でのDB設計レビュー・正規化チェック・パフォーマンスチューニングに活用
「テーブル設計書を作って、マイグレーションファイルも用意しておいてください。あ、インデックス設計も忘れずに。」
SES現場でデータベース周りのタスクを振られると、設計・実装・ドキュメントとやるべきことが一気に広がります。テーブル定義、リレーション設計、正規化の検討、マイグレーションファイルの作成、シードデータの投入——しかもこれらは相互に影響し合うため、1つ変更するとドミノ倒しのように修正が連鎖します。
本記事では、OpenAI Codex CLI を使ってデータベース設計からマイグレーション管理までを自動化する方法を解説します。ER図の自動設計からPrisma/TypeORMスキーマの生成、インデックス最適化、SES現場での実践パターンまで網羅しました。
なぜDB設計・マイグレーションにCodex CLIが効くのか
データベース設計は構造化された知識の塊です。正規化理論、リレーション設計、インデックス戦略——これらには明確なルールとベストプラクティスがあり、LLMが最も得意とする領域です。Codex CLIを使えば、自然言語の要件記述からデータベース設計の大部分を自動化できます。
DB設計における3つの課題
| 課題 | 従来の対処法 | Codex CLI活用後 |
|---|---|---|
| テーブル設計の試行錯誤 | ホワイトボード＋手作業 | 自然言語で即座にスキーマ生成 |
| マイグレーションの差分管理 | 手動でSQLファイル作成 | 変更要件からマイグレーション自動生成 |
| インデックス設計の漏れ | 本番障害で発覚 | クエリパターンから最適なインデックスを提案 |
特にSES現場では、既存DBへのテーブル追加やスキーマ変更を任されるケースが多く、既存のテーブル構造を理解した上で整合性のある変更を行う能力がCodex CLIの大きな強みになります。
要件定義からスキーマを自動生成する
Step 1: 自然言語で要件を伝える
データベース設計の出発点は要件定義です。Codex CLIに自然言語で要件を伝えるだけで、テーブル構造を自動設計してくれます。
codex "以下の要件でデータベーススキーマを設計してください:
ECサイトの注文管理システム
- ユーザー: メールアドレス、名前、住所、電話番号
- 商品: 商品名、説明、価格、在庫数、カテゴリ
- 注文: ユーザーが複数商品を1回の注文で購入できる
- 注文には配送先住所、合計金額、ステータスを持つ
- カテゴリは階層構造（親カテゴリ → 子カテゴリ）
Prisma schema 形式で出力してください"Codex CLIはリレーショナルデータベースの設計原則に基づき、正規化されたスキーマを自動生成します。
Step 2: 生成されたスキーマを確認する
// 生成例: prisma/schema.prisma
model User {
id String @id @default(cuid())
email String @unique
name String
address String
phone String?
orders Order[]
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
@@index([email])
}
model Category {
id String @id @default(cuid())
name String
parentId String?
parent Category? @relation("CategoryTree", fields: [parentId], references: [id])
children Category[] @relation("CategoryTree")
products Product[]
}
model Product {
id String @id @default(cuid())
name String
description String?
price Decimal @db.Decimal(10, 2)
stock Int @default(0)
categoryId String
category Category @relation(fields: [categoryId], references: [id])
orderItems OrderItem[]
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
@@index([categoryId])
@@index([price])
}
model Order {
id String @id @default(cuid())
userId String
user User @relation(fields: [userId], references: [id])
shippingAddress String
totalAmount Decimal @db.Decimal(10, 2)
status OrderStatus @default(PENDING)
items OrderItem[]
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
@@index([userId])
@@index([status])
@@index([createdAt])
}
model OrderItem {
id String @id @default(cuid())
orderId String
order Order @relation(fields: [orderId], references: [id], onDelete: Cascade)
productId String
product Product @relation(fields: [productId], references: [id])
quantity Int
unitPrice Decimal @db.Decimal(10, 2)
@@unique([orderId, productId])
}
enum OrderStatus {
PENDING
CONFIRMED
SHIPPED
DELIVERED
CANCELLED
}注目すべきは、Codex CLIが注文と商品の多対多関係を中間テーブル（OrderItem）で自動設計し、unitPrice を注文時点の価格として保存する設計にしている点です。これはECサイトの定石パターンであり、手作業なら見落としがちな考慮点です。
Step 3: 正規化の妥当性をチェックする
codex "prisma/schema.prisma を分析して、以下の観点でレビューしてください:
- 第3正規形を満たしているか
- N+1問題が発生しやすいリレーションはないか
- インデックスの過不足はないか
- 将来の拡張性に問題はないか"Codex CLIは設計の問題点を具体的に指摘し、改善案を提示してくれます。チームのDB設計レビューの事前チェックとして非常に有効です。
マイグレーション管理の自動化
Prismaマイグレーションの自動生成
スキーマ変更時のマイグレーションファイル作成もCodex CLIで自動化できます。
codex "以下の変更をprisma/schema.prismaに反映し、マイグレーションを生成してください:
- User モデルに role フィールド（enum: USER/ADMIN、デフォルト USER）を追加
- Product モデルに isActive フィールド（Boolean、デフォルト true）を追加
- Order モデルに cancelledAt フィールド（DateTime?）を追加
マイグレーション名は 'add-user-role-and-product-status' としてください"Codex CLIはスキーマファイルの変更だけでなく、npx prisma migrate dev コマンドの実行まで一括で行います。
安全なマイグレーション戦略
本番環境へのマイグレーション適用は慎重に行う必要があります。Codex CLIを使って安全なマイグレーション戦略を構築しましょう。
codex "以下のマイグレーションを本番適用する前に、安全性チェックリストを作成してください:
- prisma/migrations/ の最新マイグレーションを分析
- データ損失のリスクがある操作（DROP, ALTER TYPE）がないか確認
- 大量データのテーブルに対するALTERがないか確認
- ロールバック手順を生成"マイグレーション安全性チェックの例
codex "prisma/migrations/20260307_add_user_role/ のSQLを分析して:
1. 破壊的変更（カラム削除・型変更）の有無
2. NOT NULL制約追加時のデフォルト値設定
3. テーブルロック時間の見積もり
4. ロールバック用のダウンマイグレーションSQL
を出力してください"TypeORMマイグレーションへの対応
TypeORMを使用するプロジェクトでも同様のアプローチが可能です。
codex "src/entities/ のTypeORMエンティティを読み取り、
現在のデータベーススキーマとの差分を検出して、
マイグレーションファイルを src/migrations/ に生成してください"インデックス設計の最適化
クエリパターンからインデックスを自動提案
パフォーマンスに直結するインデックス設計も、Codex CLIで最適化できます。
codex "src/repositories/ のクエリを全て分析して、
最適なインデックス構成を提案してください。
以下を含めること:
- 単一カラムインデックス
- 複合インデックス（カラム順序の根拠も説明）
- 部分インデックス（PostgreSQLの場合）
- 不要なインデックスの指摘"EXPLAIN分析の自動化
codex "以下のクエリのEXPLAIN結果を分析して、改善案を提示してください:
SELECT o.*, u.name as user_name
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.status = 'PENDING'
AND o.created_at > NOW() - INTERVAL '7 days'
ORDER BY o.created_at DESC
LIMIT 20"Codex CLIは以下のような改善案を提示します。
orders(status, created_at DESC)の複合インデックス追加created_atの範囲検索にはB-treeインデックスが最適- カバリングインデックスの検討:
orders(status, created_at DESC) INCLUDE (user_id)
シードデータの自動生成
開発・テスト環境のシードデータもCodex CLIで効率的に生成できます。
codex "prisma/schema.prisma のモデル定義に基づいて、
リアルな日本語テストデータを生成してください:
- ユーザー: 50件（日本の名前・住所・電話番号）
- カテゴリ: 10件（家電・ファッション・食品など、子カテゴリ各3件）
- 商品: 100件（各カテゴリに均等配分、価格は100〜50000円）
- 注文: 200件（ステータス分布: pending 20%, confirmed 30%, shipped 25%, delivered 20%, cancelled 5%）
prisma/seed.ts に出力してください"Codex CLIはfaker.jsなどのライブラリを活用し、リアルなテストデータを含むシードスクリプトを自動生成します。手動でテストデータを用意する手間を大幅に削減できます。
SES現場での実践パターン
パターン1: 既存DBへのテーブル追加
SES案件で最も多いのが、稼働中のシステムにテーブルを追加するケースです。
# 1. 既存のスキーマを把握
codex "prisma/schema.prisma の全モデルとリレーションを分析して、
ER図の概要をテキストで出力してください"
# 2. 新テーブルを既存構造に整合させて追加
codex "既存のUserモデルとOrderモデルに関連する
通知テーブル（Notification）を追加してください。
種類: 注文ステータス変更、お知らせ、システムアラート
既読管理、一括既読機能に対応すること"
# 3. マイグレーションを生成して適用
codex "追加したNotificationモデルのマイグレーションを生成し、
シードデータも50件追加してください"パターン2: パフォーマンス改善のためのスキーマ変更
本番環境でスロークエリが発生した場合の対応もCodex CLIで効率化できます。
codex "以下のスロークエリログを分析して、
必要なインデックス追加またはスキーマ変更のマイグレーションを生成してください:
Query: SELECT * FROM orders WHERE user_id = ? AND status IN (?, ?) ORDER BY created_at DESC
Duration: 3.2s
Rows examined: 1,200,000
Query: SELECT p.*, COUNT(oi.id) as order_count FROM products p
LEFT JOIN order_items oi ON p.id = oi.product_id
GROUP BY p.id ORDER BY order_count DESC
Duration: 5.8s
Rows examined: 2,500,000"パターン3: DB設計レビューの自動化
チームのDB設計レビューの事前チェックとしてCodex CLIを活用し、レビューの質を向上させられます。
codex "prisma/schema.prisma の設計を以下の観点でレビューして、
改善提案をマークダウン形式で出力してください:
- 命名規則の一貫性
- 適切なデータ型の選択
- NOT NULL制約の妥当性
- カスケード削除の安全性
- ソフトデリート vs ハードデリートの判断
- 監査カラム（createdAt, updatedAt, deletedAt）の網羅性"データベーススキーマのドキュメント自動生成
ドキュメント自動生成の手法を応用し、DB設計書も自動生成できます。
codex "prisma/schema.prisma から以下のドキュメントを生成してください:
1. テーブル一覧（名前、用途、主要カラム）
2. ER図（Mermaid形式）
3. 各テーブルの詳細定義書（カラム名、型、制約、説明）
4. リレーション一覧（外部キー、カスケード設定）
5. インデックス一覧と設計意図
docs/database-design.md に出力してください"Mermaid ER図の自動生成例
codex "prisma/schema.prisma からMermaid形式のER図を生成してください"生成されるMermaid図はGitHubのREADMEやNotionに貼り付けるだけで、視覚的なER図として表示されます。SES現場での引き継ぎ資料としても非常に有用です。
注意点とベストプラクティス
1. 本番マイグレーションは必ず人間が確認する
Codex CLIが生成したマイグレーションは必ず人間がレビューし、以下を確認してください。
- 破壊的変更がないか: カラム削除、型変更、制約変更
- ダウンタイムの見積もり: 大量データテーブルへのALTER操作
- ロールバック手順の準備: 問題発生時の復旧方法
2. ステージング環境でのテストを省略しない
マイグレーションの本番適用前に、必ずステージング環境でテストしましょう。テスト自動化のテクニックを使い、マイグレーション後のデータ整合性テストも自動化できます。
3. バックアップ戦略を組み合わせる
codex "PostgreSQLのバックアップスクリプトを作成してください:
- マイグレーション実行前の自動バックアップ
- pg_dump でスキーマ＋データの完全バックアップ
- リストア手順のドキュメント付き"4. セキュリティ観点のチェック
セキュリティと権限管理で解説しているように、Codex CLIにデータベースの接続情報や本番データを渡さないよう注意してください。スキーマファイルや匿名化されたクエリログのみを入力として使用しましょう。
まとめ：DB設計・マイグレーションの生産性を劇的に向上させるCodex CLI
本記事では、Codex CLIを使ったデータベース設計・マイグレーション自動化の実践テクニックを解説しました。
- スキーマ自動設計: 自然言語の要件からER図・テーブル定義を一括生成
- マイグレーション管理: スキーマ変更の差分検出とマイグレーションファイル自動作成
- インデックス最適化: クエリパターン分析に基づく最適なインデックス提案
- ドキュメント生成: ER図・テーブル定義書・リレーション一覧の自動生成
- SES現場での活用: 既存DBへの安全なテーブル追加、パフォーマンス改善、設計レビュー
データベース設計は一度の判断が長期にわたってシステム全体に影響するため、Codex CLIで設計の選択肢を素早く可視化し、人間が最終判断に集中するというワークフローが理想的です。
SES現場でDB設計・マイグレーションを任される機会がある方は、ぜひCodex CLIを活用して生産性と品質の両方を向上させてください。
参考リンク:
シリーズ内の関連記事:
