DB 設計は「問い」に分けて壁打ちし、4人のペルソナのサブエージェントでレビューを回す

実装はほぼ AI に任せても、DB 設計の判断は人がする。Claude Code に issue と既存のマイグレーションを読ませて叩き台を出させ、人が論点を「問い」に分けて issue に書き、1問ずつ壁打ちし、最後に性格の違う4つのサブエージェントにレビューさせる。

どんな場面で使う？

新機能で既存テーブルとの関係整理を含む DB 設計をするとき
AI に設計を丸投げすると論点が散らかって迷走するとき

手順

叩き台: 「issue 1234 を読んで。要件を満たすように設計していくから、一緒にやろう」。Claude Code が issue・既存コード・マイグレーションを読んで叩き台を出す（情報過多で論点が散らかるのは想定内）
人が整える: 同時に聞かれた論点を結合・分離し、コードから読めない運用知識（「このテーブルは今使われていない」など）を足す。issue に「ユースケース表（条件／期待する振る舞い）」と「設計で答えを出すべき問い（A: テーブルを統一か併存か、B: 多重度、C: パラメータの形式と有効期限…）」として書かせる
1問ずつ壁打ち: 結論が出たら issue に「問いの答え」として書き、ER 図（mermaid）とテーブル定義に起こす
- 思い込みを防ぐ指示例:「◯◯の代替パターンについて、学習データや推論ではなく、権威ある人の blog や書籍で提唱されたパターンを集めて整理して」
- 途中で新しい問いが出たら、深掘りせず issue に追記して元の議論に戻る
サブエージェントでレビュー: 楽観的・悲観的・UI/UX 第一・こだわりが強い、の4人の AgentTeam を組ませる。ルールは「全員が自分で issue 全文を読む（伝言で情報が落ちないように）」「全員の意見が出たら、各自が反論・同意して結論を出し直す」「リーダーが統合して issue にコメントする」
レビューを評価して回す: 別セッション（文脈をクリア）でレビュー自体の妥当性を評価させ、人が過剰設計や仕様漏れを取り除いて issue に反映。満足するまで繰り返す

注意点

本人がプロジェクトを理解していないと AI に振り回される、と作者
悲観寄りのペルソナが多いと「念のため」の指摘が増える。人の役割はたいてい過剰設計のふるい落とし
関連: シングルエージェントとマルチエージェントの使い分け、仕様・手順書の曖昧さを「複数回実装させて」検出する

出典

いいね: @choclucy_ · 2026-04-24
Zenn「Claude Code と二人七脚 DB 設計」: zenn.dev