【注記】 2026-09-03、TeamWorks 提供の実DDL（clean_watch_20260902.sql）と手書き prisma/schema.prisma の答え合わせのために作成した記録です（prisma db pull による方法）。 同じ照合を別方法（DDL文の直接パース）で行った ddl-diff-parse.md と対になる相互検証の記録です。 当時の記録であり、現行方針ではありません。 以降の決定は docs/decisions.md と docs/handoff.md を参照してください。

30 — 実DDL と 手書き schema.prisma の答え合わせ（prisma db pull）

• 実施日: 2026-09-03
• 入力DDL: C:\Users\daich\Downloads\clean_watch_20260902.sql（46,390 bytes / CREATE TABLE 39個）
  • MySQL dump 10.13, Distrib 8.0.41 (Linux x86_64) / 元DB名 clean_watch
• 手書き版: C:\Users\daich\dev\d-watch\prisma\schema.prisma（28モデル / md5 a1d48b7927c2b93171d3394986abbdf1）
• 生成版: <scratchpad>\ddl\pulled.prisma（39モデル / 703行）
• 比較スクリプト: <scratchpad>\ddl\compare.py → 生出力 diff.txt / 構造化 diff.json

0. 作業条件（守った制約）

Laravel 基盤10テーブルは比較対象外として除外した: users / sessions / jobs / migrations / cache / cache_locks / failed_jobs / job_batches / password_reset_tokens / personal_access_tokens → 業務テーブルは DDL 側 29個、手書き側 28モデル。

1. DDL 読み込みの結果

成功。エラー・警告は0件。

1-1. 事前確認した内容

USE 文が無いため、投入先DBは接続時に明示した。

1-2. 実行コマンドと結果

mysql -u root -e "CREATE DATABASE dwatch_ddl CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root --default-character-set=utf8mb4 dwatch_ddl < clean_watch_20260902.sql

• 終了コード 0 / 標準エラー出力なし
• information_schema 上のテーブル数: dwatch_ddl = 39（DDLの CREATE TABLE 数と一致）
• dwatch_local = 28（投入前後で不変）
• サーバは MySQL 8.4.9、dump 元は 8.0.41。バージョン差による失敗は発生しなかった。

1-3. db pull

Prisma 7 では datasource ブロックに url を書けない（P1012）。 最初にスタブへ url = env(...) を書いて1度失敗したため、url を削って --url フラグで渡す形に変更し成功した。 この失敗はスタブ側の書き方の問題で、DDL/DBには影響していない。

npx prisma db pull --print \
  --schema="<scratchpad>/ddl/stub.prisma" \
  --url="mysql://root@localhost:3306/dwatch_ddl"

終了コード 0。生成結果 39モデル。

2. テーブル単位の差分

差分 1件。

業務テーブル 29 のうち 28 は名前レベルで一致。@@map の物理名も全件一致した。

2-1. clean_link_schedules の全カラム（新テーブル）

link_schedules と構造が完全に同一（カラム名・型・既定値・NULL許容・FK先すべて）。 唯一の違いは制約名の接頭辞（clean_link_schedules_section_id_foreign）と、link_schedules 側に AUTO_INCREMENT=10 が入っている点（データ有無の差）。

• 主キー: PRIMARY KEY (id)
• インデックス: KEY clean_link_schedules_section_id_foreign (section_id)
• 外部キー: section_id → sections(id)（ON DELETE / ON UPDATE 指定なし = NoAction）
• ユニーク制約: なし

link_schedules と clean_link_schedules が両方存在し中身が同一という点は、どちらを参照すべきか TeamWorks に要確認（旧テーブルの残置か、用途別の並存か判断できない）。

3. カラム単位の差分（テーブルごと）

カラムの有無の差分は 14件（生成版にあって手書きに無い 3 / 手書きにあって実DDLに無い 11）。 うち 3件はカラム名の綴り違い（リネーム）で、実質は「6件のリネーム片側」＋「8件の実在しないカラム」。

業務カラム総数: 手書き 311 / 生成版 312。

3-1. 生成版にあって手書き版に無いカラム（3件）

3-2. 手書き版にあって実DDLに無いカラム（11件）

3-3. カラム名リネーム3件の DDL 原文（裏取り）

-- robot_error_reports
`responded_at` datetime DEFAULT NULL,
-- control_error_histories
`responded_at` datetime DEFAULT NULL,
-- control_reports
`serial_number` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL,

responsed_at は定義書の typo であり、実カラム名は responded_at（d が入る）で確定。 control_reports.sireal_number も定義書の typo で、実カラム名は serial_number。

4. 型・既定値・null許容の差分

4-1. 型（Prisma型）の差分 — 1件

同名カラムなのに facility_contacts.contact_type は tinyint unsigned（Int @db.UnsignedTinyInt）で、 実DDL上で顧客側と施設側の型が食い違っている。手書き版は両方 tinyint に揃えていたため顧客側が外れた。

4-2. @db.* 属性（桁数・符号）の差分 — 4件

customer_contacts.email は varchar(100) のまま（一致）。facility_contacts.email のみ 255。

4-3. NULL 許容の差分 — 1件

同テーブルの responded_at / resolved_at / product_code などはいずれも手書きも NULL 可で一致。

4-4. 既定値の差分 — 15件

(a) 実装に影響する既定値差分（9件）

履歴系2テーブルの id は AUTO_INCREMENT ではない（採番はアプリ側 or 元テーブルの id を引き継ぐ設計）。 clean_task_reports の created_at / updated_at と security_status_histories.reported_at は DEFAULT句が無い timestamp NOT NULL なので、INSERT 時に明示的に値を入れる必要がある。

(b) 数値リテラル表記のみの差分（6件・値は同一）

DDL は decimal(12,6) unsigned NOT NULL DEFAULT '0.000000'。 数値としては同一だがリテラル表記が異なるため差分として計上した。生成版の表記に合わせるのが正。

4-5. 主キー / ユニークの差分 — 4件

robot_error_reports には PRIMARY KEY が一つも無い。 Prisma はモデルの一意識別子として error_id @unique を採用しており、 id（varchar(50)）はただのカラムになっている。 つまり Prisma Client からは findUnique({ where: { id } }) が使えず、error_id でしか一意引きできない。

clean_status_histories も PRIMARY KEY が無く、id は UNIQUE KEY のみ。 手書き版のコメント「定義書原文のまま: キー種別が他テーブルの pk ではなく uk（unique key）と記載されている」は 実DDLと合っていた（定義書の記述は正しかった）が、Prisma 属性は @id ではなく @unique が正。

4-6. @updatedAt（Prisma固有・introspectionでは生成されない）

db pull は @updatedAt を出力しないため §4-4 の機械比較には出てこないが、 DDL の ON UPDATE CURRENT_TIMESTAMP の有無で検証すると以下の不整合がある。

5. リレーション（外部キー）の差分

差分 3件。すべて「手書き版が実在しない外部キーを張っていた」方向。 生成版にあって手書きに無い外部キーは 0件（新テーブル clean_link_schedules の1本を除く）。

5-1. 特に確認を依頼された項目の結果

5-2. 業務テーブルの外部キー一覧（実DDL・全件）

すべて ON DELETE / ON UPDATE 指定なし → Prisma は onDelete: NoAction, onUpdate: NoAction を生成。

5-3. インデックスの差分 — 6件

補足: clean_timetable_histories のインデックス名は ..._started_at_index / ..._ended_at_index だが 対象カラムは start_at / end_at（DDL側の命名が実カラム名とずれている）。

6. 手書き版が正しかった点

業務テーブル28のうち、比較項目すべてが完全一致したのは 12 テーブル。

（カラムの有無・Prisma型・@db.*・NULL許容・既定値・主キー・ユニーク・インデックス・外部キーのすべてが一致。 @updatedAt のみ introspection では検証不能なため §4-6 で別途確認済み。security_statuses.reported_at の付け漏れ1件を除き整合。）

6-1. 判断に迷った箇所が正解だった例

makers テーブル、controls の facility FK、clean_schedules.end_time の型、 サマリの比率・面積の型と精度、error_type の型は、すべて手書き版が実DDLと一致していた。

7. 実装に影響する差分の優先順位

P1 — 直さないと動かない / データが取れない（8件）

P2 — 実行時エラーやデータ欠損につながる（7件）

P3 — 表示・既定値の意味が変わる（6件）

P4 — 表記のみ（2件）

8. 差分の総件数

• 完全一致したテーブル: 12 / 28
• 手書き版の物理名（@@map）は 28/28 すべて一致

9. 生成物

投入先DB dwatch_ddl は残してある（不要になれば DROP DATABASE dwatch_ddl;）。 dwatch_local は一切変更していない。

手書き版 prisma/schema.prisma は未修正。修正は別指示で行う。