---
title: 【新人～中堅向け】AI駆動開発で事故らない DB設計とテスト立案_20261013
tags:  #db  
author: [Yukiko](https://www.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LJ1Y6NM2EG.jpg?width=480
description: 【新人～中堅向け】AI駆動開発で事故らない DB設計とテスト立案_20261013 by Yukiko
published: October 13, 26
canonical: https://www.docswell.com/s/yukiko_it/Z3JQ8D-2026-10-13-221944
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LJ1Y6NM2EG.jpg)

うさうさ研修工房
AI駆動開発で事故らない
DB設計とテスト立案
商用プロジェクトの実務ガイド｜新人〜中級向け
査読済み論文・公式ドキュメントを根拠に／図解と実践ToDo付き


# Page. 2

![Page Image](https://bcdn.docswell.com/page/GJWGW43272.jpg)

GOAL
結論：AIは速い下書き係、責任は人が持つ
責任は人
DBは戻せない
お願いより仕組み
設計判断・本番の鍵・最終責任は
人が持つ。AIは案出しと雛形づく
り。
不可逆だから最も慎重に。変更は
小さく、段階的に進める。
プロンプトではなく、権限・環境分
離・レビューゲートで守る。
新人＝まず「型」を守る ／ 中級＝「仕組み」で守る
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/4EZL52V473.jpg)

WHY
なぜ「DB × AI」は事故りやすいのか
不可逆
暗黙知
長寿命
DROP・DELETE・型変更は取り
消せない
業務ルールや経緯は、スキーマに
もコードにも書かれていない
スキーマは数年使われ、変更コス
トが高い
起きること
起きること
起きること
データ消失／長時間停止
もっともらしいが業務に合わない
設計
初期の小さな判断ミスが巨大な
負債に
だから「AIの速さ」より先に「検証の仕組み」を作る
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/Y76W9V5G7V.jpg)

EVIDENCE｜研究が示すこと
数字で見る「 AIコード」の現実
約40%
過信
最大29%↓
19%遅
Copilot生成コードで脆弱性
が見つかった割合（セキュ
リティ関連の場面）
AI利用者は、より安全でな
いコードを書き、かつ安全
だと思いやすかった
テストを約80倍に増やす
と、26のLLMで正答率が
19.3〜28.9%低下（見逃し
の存在）
実測は遅くなったのに、本
人は速くなったと認識（プレ
プリント）
Pearce et al., IEEE S&P 2022
Perry et al., ACM CCS 2023
Liu et al., NeurIPS 2023
METR, arXiv 2025（査読前）
研究の示すこと：「使うな」ではなく「検証の仕組みを前提に使え」
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/G75MNDYX74.jpg)

EVIDENCE MAP｜研究 → 実務
研究が示したことを、実務のルールに変える
研究
分かったこと
実務への示唆（本資料）
Pearce 2022
セキュリティ関連の場面で、生成コードの約4割に脆弱性
SQLはパラメータ化・必ずレビュー（ 10カ条④⑤）
Perry 2023
AI利用者は安全でないコードを書き、安全だと思いやすい
過信を前提に検証の仕組みを作る（⑩）
Liu 2023
テスト不足だと誤りが見逃され、評価が歪む
テストは要件から厚く作る（ PART B）
Schäfer 2024
LLM生成テストのカバレッジは中央値でSt.70.2%／Br.52.8%
生成後に実行・レビュー、質は変異で測る
Barr 2015
期待値（オラクル）の正しさが本質的な課題
期待値の根拠は人が確認する
Huang 2025
幻覚の原因・種類・対策の体系的整理
スキーマを文脈に渡し、実行して検証（⑥）
査読済み論文の知見を “そのまま鵜呑み ”にせず、自社の条件で検証してから運用ルールに落とす。
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/9J2958GQER.jpg)

ROLES
責任分界：誰が何を担うかを先に決める
AI
人
ゲート
本番DB
下書き・案出し・雛形
判断・レビュー・承認
機械的な検証・統制
戻せない領域
•
ER図のたたき台
•
業務ルールの確認
•
自動テスト・CI
•
人が承認して適用
•
DDL・テストの雛形
•
•
スキーマ差分チェック
•
•
命名・観点の抜け漏れ
指摘
正規化・キー戦略の判
断
•
最小権限・承認フロー
バックアップと復元手
順
•
監視・監査ログ
•
期待値(オラクル)の妥
当性
•
最終承認
最終責任は常に「人」。 AIの出力は “提案”として扱う。
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/DEY4K6VYJM.jpg)

CASE｜2025年7月の事案（報道ベース）
事故に学ぶ： AIに本番DBを消された事例
1
指示
「コードフリーズ。変更するな」と
明示した
2
実行
AIが破壊的コマンドを実行した
と報告
3
拡大
4
開発・テスト・本番が同じDBだっ
た
復旧
ロールバック可否の説明が二転
三転
学び
フリーズ指示は「お願い」
環境を分ける
復元訓練をしておく
統制は権限で。実行できない状態にす
る
dev / staging / prod は別DB・別資格
情報
バックアップは戻せて初めて価値があ
る
出典：heise online／YourStory／AI Incident Database（当事者の発信と報道に基づく）
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/VJNYRZMR78.jpg)

GUARDRAIL
環境分離と権限： AIに「できること」を絞る
開発 DB
自由に実験 OK
合成データ・使い捨て可。AIが直接実行してよい
AIエージェント
提案・実行を担う
（権限は環境ごとに限定）
検証 DB
承認後に適用
本番相当のサイズ・マスク済みデータでリハーサル
本番 DB
AIは書込禁止
人が承認して適用。AIに資格情報を渡さない
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/YE9PMZNZJ3.jpg)

PART A｜DB設計
DB設計フロー： AIと人の役割分担
要件整理
概念設計 (ER)
論理設計 (正規化)
物理設計 (型・制約・
索引)
移行・運用
質問リストの案を出す
ER図のたたき台
正規化案・命名案
DDL雛形・索引候補
手順書・レビュー補助
業務ルールを確認・決
定
エンティティの過不足
を判断
落とし所とトレードオフ
を決める
EXPLAINで実測し採
否を判断
リハーサル・承認・復
旧手順
AI
人
全工程で：AIの提案には「根拠」を求め、採否の理由を ADRに残す
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/GE8DL1NYED.jpg)

PART A｜DB設計
ER図の例（ ECサイト）と見落としやすい業務ルール
customers
id
PK
email
UNIQUE
orders
1:N
id
設計ポイント
PK
•
unit_price は「注文時点の価格」を保存
する
•
products.price を参照するだけだと、値
上げで過去注文の金額が変わる
•
AIが見落としやすい「業務ルール」の典
型例
•
AIには「過去の金額は変えない」要件を
明示して渡す
customer_id FK
created_at
status
ordered_at
1:N
products
id
PK
order_items
order_id
FK
name
product_id
FK
price
quantity
1:N
unit_price
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
★
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/LELMLQP97R.jpg)

PART A｜DB設計
AIがやりがちな NG → 商用での正解
観点
AIが出しがち（ NG）
商用での正解
金額
float / double
NUMERIC(p,s)、または最小通貨単位の整数
時刻
タイムゾーンなし
TIMESTAMPTZ・UTC保存・表示で変換
制約
アプリ側のチェックのみ
NOT NULL / FK / UNIQUE / CHECK をDBにも
削除
物理削除のみ
論理削除＋部分ユニーク索引
索引
とりあえず全列に
クエリ起点で設計し、EXPLAINで検証
個人情報
平文・全環境に本番を複製
最小化・マスキング・暗号化・保持期限
DDLのコード例は記事（Markdown版）に掲載しています。
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/4JMYM14VJW.jpg)

PART A｜DB設計
見落としやすい 4つの設計テーマ
履歴・監査
削除と保持
いつ・誰が・何を変えたかを残す。履歴テーブル
やバージョン列で、後から説明できる設計にす
る。
論理削除は部分ユニーク索引とセットで。物理削
除と保持期限の方針を先に決める。
マルチテナント
個人情報
tenant_id を全テーブルに持たせる。
PostgreSQLなら行レベルセキュリティ(RLS)も候
補。
最小化・マスキング・暗号化。テスト環境に本番
データを入れない。プロンプトにも貼らない。
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/PJR9VLWW79.jpg)

PART A｜DB設計
マイグレーション： Expand / Contract で段階的に
1
2
Expand
新しい列/テーブルを追
加（互換あり）
3
Dual write
新旧の両方に書き込む
Backfill＆切替
既存データを移行し、読
み取りを新へ
4
Contract
十分な観察期間のあと
旧列を削除
旧スキーマ（ Contractまで残す）
新スキーマ（ Expandで追加し、以降も残る）
•
大きなテーブルの ALTERや索引作成はロックに注意（例： CREATE INDEX CONCURRENTLY）
•
AI生成のマイグレーションは、本番相当のデータ量でリハーサルしてから適用
•
適用前に「戻し方」と「停止判断」を決めておく
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/PEXQZWPVJX.jpg)

PART A｜DB設計
索引と性能： AIの提案は実測で検証する
1
2
3
4
遅いクエリと実行計画を AIに渡す
EXPLAIN (ANALYZE, BUFFERS) で取得
ステージングの実データ量で検証
出力イメージ（概念図）
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders
WHERE customer_id = 42
ORDER BY ordered_at DESC
LIMIT 20;
少量データの結果は当てにならない
書き込み性能・容量への影響も見る
索引は読みを速くし、書きを遅くする
見る点：
・Seq Scan → Index Scan に
変わったか
・実行時間・読んだ行数
・本番相当のデータ量か
なぜその索引かを残す
コメント/ADRに。後任が理由を分かるように
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/3EK98VD5ED.jpg)

PART B｜テスト立案
テスト立案パイプライン：要件から導く
要件・業務ルー
ル
テスト観点
テスト条件
テストケース
テストデータ
自動化・ CI
結果評価
人
AI案→人
AI案→人
AI案→人
AI（合成）
AI雛形→人
人が評価
最大の罠：実装コードだけからテストを書かせない
•
バグを「正しい挙動」として固定してしまう
•
テストは要件・仕様から導き、期待値の根拠（テストオラクル）は人が確認する
•
（オラクル問題：Barr et al., IEEE TSE 2015）
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/L73W2MR175.jpg)

PART B｜テスト立案
DBテストの 8観点
1
制約
違反データが拒否される
（NULL・重複・FK・CHECK）
5
データ品質
孤児レコード0件・合計値の整
合・重複なし
2
マイグレーション
up後のデータ保持・再実行・
失敗時の手当て
6
権限・セキュリティ
最小権限・SQLインジェクショ
ン耐性・RLS
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
3
並行性
二重更新・デッドロック・分離
レベル・楽観ロック
7
障害・復旧
復元手順の実演・ RPO/RTO
の確認
4
性能
実データ量での応答時間と実
行計画
8
互換性
DB/ORMのバージョン・文字
コード・照合順序
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/87DKZ6YKJG.jpg)

PART B｜テスト立案
テストピラミッド（ DB版）
少ない・遅い・高コスト
E2E／業務シナリオ
ポイント
主要フローのみ
結合テスト
•
上ほど遅く高コスト、下ほど速く
安い
•
AI生成テストは、まず下層から固
める
•
カバレッジ100％でも品質は保証
されない
API＋DB・トランザクション・並行性
DB単体テスト
制約・マイグレーション・SQL/関数
静的チェック
スキーマlint・命名・差分検知
多い・速い・安い
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/VJPKDY63E8.jpg)

PART B｜テスト立案
リスクベースで優先順位を付ける
個人情報の漏えい
決済金額の整合
並行更新の競合
優先度の決め方
影響 大
マイグレーション失敗
影響 中
•
影響×発生しやすさで点数化する
•
右上から手厚く、左下は軽く
•
出口基準（合格ライン）は人が決め
る。AIは候補出しまで
一覧の表示順
影響 小
発生しやすさ：低
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
発生しやすさ：中
発生しやすさ：高
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/2EVV1G3NEQ.jpg)

PART B｜テスト立案
テスト作業： AIに任せる／人が握る
AIに任せて効率化
人が握る
•
テスト観点の抜け漏れチェック
•
期待値の根拠（業務ルール）の確認
•
境界値の一覧化・合成テストデータ
•
本番データのテスト利用可否の判断
•
テストコードの雛形・リファクタ
•
優先順位（リスク評価）と合格基準
•
失敗ログからの原因仮説出し
•
原因の確定と再発防止策
テストの質を測る：ミューテーションテスト
コードをわざと壊して、テストが検出できるかを見る（ Jia & Harman 2011／Google事例：Petrović & Ivanković 2018）。AIの単体テスト自動
生成の報告例（ JS・25パッケージ）は、中央値でステートメント 70.2%・ブランチ52.8%。万能ではなく、実行確認とレビューが前提（ Schäfer et
al. 2024）。
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/57GL2835EL.jpg)

PART B｜テスト立案
テスト計画書テンプレ（簡略版）
項目
書くこと
AIの使いどころ
目的・範囲
何を保証し、何をしないか
たたき台の作成
方針・観点
8観点のどれを重点にするか
観点の抜け漏れチェック
環境・データ
環境分離・合成データ・マスキング
合成データ生成スクリプト
体制・役割
誰が作り、誰がレビューするか
（人が決める）
リスク・優先度
影響×発生しやすさ
リスク候補の列挙
入口／出口基準
開始条件と合格基準
基準案の提示
スケジュール
マイグレーション前後の確認点
（人が決める）
ISO/IEC/IEEE 29119 のテスト文書の考え方を参考に簡略化。
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/4EQYP95LJP.jpg)

PART C｜実践
AI駆動開発で気を付けること 10カ条
本番に触らせない
1
環境分離・最小権限
指示は統制ではない
2
機密をプロンプトに入れない
DDLは人がレビュー
3
dry-run・リハーサル
4
文字列連結を禁止
6
方言差で壊れない
8
ライセンス・規程の確認
9
生成物・ツール利用可否
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
幻覚を減らし実行で検証
判断をADRに残す
DB種別とバージョン明記
7
マスキングを徹底
スキーマを文脈で渡す
SQLはパラメータ化
5
権限とゲートで実装
採否の理由を記録
過信を前提に設計
10
検証時間を見積もる
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/KJ4WYX9571.jpg)

PART C｜実践
そのまま使えるプロンプト例
スキーマレビュー用
テスト観点の洗い出し用
あなたはPostgreSQL 16の
経験豊富なDBエンジニアです。
次のDDLを商用運用の観点でレビューして。
次の要件からテスト観点を洗い出して。
実装コードは見ず、要件だけから導く。
# 前提
・想定量: orders 1億行/年
・注文後の金額変更は不可
# 出力
1. 重大度別の指摘と根拠
2. 修正DDL案
3. 私が確認すべき質問リスト
# 注意
不明点は推測せず質問する。
存在が不確かな関数は使わない。
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
# 出力
・観点（制約/並行性/性能/
権限/復旧/互換性 で分類）
・各観点のテスト条件と
期待値の根拠（どの要件か）
・要件が曖昧で期待値を決められない
箇所（質問として）
# 要件
<ここに貼る>
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/LE1Y6NK27G.jpg)

PART C｜実践（新人）
新人向け ToDo：まず「型」を守る
開発/検証/本番の接続先と資格情報が別だと確認した
AIのSQLをステージングで自分で実行して確認した
金額はNUMERIC、時刻はTIMESTAMPTZを確認した
NOT NULL / FK / UNIQUE / CHECK を各1つ書いた
制約違反が拒否されるテストを3本書いた
境界値（0・1・上限・上限+1）のデータを作った
プロンプトに個人情報・機密を貼っていない
レビュー依頼で「AIを使った箇所」を伝えた
EXPLAINを1回実行し、読み方を先輩に確認した
今日の学びを1行、日報に書いた
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
23


# Page. 24

![Page Image](https://bcdn.docswell.com/page/GEWGW4D2J2.jpg)

PART C｜実践（中級）
中級向け ToDo：「仕組み」で守る
AIエージェントの権限を棚卸し（本番書込ゼロ）
マイグレーションをExpand/Contractで設計し予行した
CIにスキーマ差分チェックとup/再実行テストを入れた
テスト計画書にリスク優先度と出口基準を書いた
主要テストにミューテーションテストを試験導入した
バックアップの復元訓練をしRPO/RTOを実測した
ADR（設計判断記録）の運用をチームに提案した
チーム共通のAI利用ガイドを作った
負荷試験で実行計画の劣化を検知する仕組みを作った
AI提案を却下した例を振り返りで共有した
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
24


# Page. 25

![Page Image](https://bcdn.docswell.com/page/47ZL52G4J3.jpg)

PART C｜実践
7日間チャレンジ：毎日ひとつ「仕組み」を足す
1
2
3
4
5
6
7
点検
レビュー
制約テスト
境界値
予行
性能改善
共有
環境と権限を点検
し、誰がどこに書
けるか図にする
既存テーブルの型
・制約・索引を見
直す
違反データが拒否
されるテストを書く
境界値と状態遷移
のケースを作る
マイグレーションを
ステージングで予
行
遅いクエリを
EXPLAINで改善・
検証
ADRと日報にまと
めてチームに共有
1日30〜60分でOK。大事なのは「毎日ひとつ仕組みを足す」こと
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
25


# Page. 26

![Page Image](https://bcdn.docswell.com/page/YJ6W9VYGJV.jpg)

REFERENCES｜査読済み論文
参考文献（査読済み論文）
[1] Pearce et al. (2022). Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions. IEEE S&P.
[2] Perry, Srivastava, Kumar, Boneh (2023). Do Users Write More Insecure Code with AI Assistants? ACM CCS.
[3] Liu, Xia, Wang, Zhang (2023). Is Your Code Generated by ChatGPT Really Correct? Rigorous Evaluation of LLMs for Code Generation. NeurIPS.
[4] Huang et al. (2025). A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions. ACM TOIS.
[5] Schäfer, Nadi, Eghbali, Tip (2024). An Empirical Evaluation of Using LLMs for Automated Unit Test Generation. IEEE TSE.
[6] Barr, Harman, McMinn, Shahbaz, Yoo (2015). The Oracle Problem in Software Testing: A Survey. IEEE TSE.
[7] Jia, Harman (2011). An Analysis and Survey of the Development of Mutation Testing. IEEE TSE.
[8] Petrović, Ivanković (2018). State of Mutation Testing at Google. ICSE-SEIP.
[9] Codd (1970). A Relational Model of Data for Large Shared Data Banks. Communications of the ACM.
[10] Curino, Moon, Tanca, Zaniolo (2008). Schema Evolution in Wikipedia: Toward a Web Information System Benchmark. ICEIS.
巻号・ページ・DOIは公開前に最新情報で再確認してください。
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
26


# Page. 27

![Page Image](https://bcdn.docswell.com/page/GJ5MNDGXJ4.jpg)

REFERENCES｜公式・その他
参考（公式ドキュメント・報道・プレプリント）
公式ドキュメント
プレプリント・報道
•
PostgreSQL Documentation（Constraints / Indexes /
EXPLAIN / Transaction Isolation / Backup and Restore）
•
METR (2025) 経験豊富なOSS開発者の生産性調査 arXiv
（査読前）
•
MySQL Reference Manual（InnoDB）
•
•
OWASP Top 10 / OWASP Top 10 for LLM Applications
Replit事案：heise online／YourStory／AI Incident
Database
•
ISTQB CTFL シラバス／ISO/IEC/IEEE 29119
•
IPA「安全なSQLの呼び出し方」
•
Claude公式：Claude Code Docs（Best
practices／Sandboxing／Security）、Prompting best
practices
公開前の確認
公式ドキュメントのバージョン固有の記述は最新版で再確認。報
告された数値は研究設定に依存します。
うさうさ研修工房｜ AI駆動開発 × DB設計 × テスト立案
27


# Page. 28

![Page Image](https://bcdn.docswell.com/page/LE3W2MR4E5.jpg)

AIは強力な相棒。
責任を持つのは、人。
速さを手に入れるほど、「検証と統制の仕組み」に投資しよう。
面白きこともなき世を面白く ｜ うさうさ研修工房