【新人～中堅向け】AI駆動開発で事故らない DB設計とテスト立案_20261013

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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