DB整合性修復パターン（Liquibaseマイグレーション乖離）

参照すべき状況:

根本原因パターン

DATABASECHANGELOGテーブルの記録と実際のDBスキーマの乖離。

  1. バージョンアップ試行 → 途中でマイグレーション失敗
  2. バックアップからDBを復元
  3. スキーマはバックアップ時点に戻ったが、DATABASECHANGELOGは復元対象外
  4. 「実行済み」記録が残ったまま、実際のスキーマには未適用の状態が発生
スキーマ（実態） : v48.00-004まで適用済み
DATABASECHANGELOG : v48.00-021まで「EXECUTED」と記録
                        ↑ ここが噛み合っていない

失敗パターン（アンチパターン）

試した方針失敗理由
チェックサムエラーを無視して再実行Liquibaseがハッシュ不一致を検出してブロック
手動DDLで修正（13文SQL）存在しないUNIQUE KEYへのADD等、生成ミスが多発
古いバージョンのまま運用継続セキュリティリスクの蓄積、負債増大
中間バージョンを順番に経由Liquibase系では不要（直接最新へ可能）。工数の無駄
本番DBに直接AIをアクセスさせてSQL実行個人情報保護法・社内規定違反リスク

正しい修復手順

1調査（AIに委譲）

以下を調査・分析してください（本番DBへの直接アクセス・操作は禁止）：
1. DATABASECHANGELOGの最終エントリとEXECTYPEを確認
2. 実スキーマとchangeSet記録の乖離範囲を特定
3. OSSの場合はGitHubからマイグレーションYAMLを取得して実行順序を解析
4. 修復SQLの案を生成し、別視点でのレビュー観点も列挙すること

2乖離範囲の特定

クリーンインストール版スキーマ・旧バージョンスキーマ・本番スキーマの3ファイルを用意してAIに比較させる

3修復SQL（最終形）

-- Liquibaseロックの解除（忘れると次回起動時にロックエラー）
UPDATE DATABASECHANGELOGLOCK
SET LOCKED = 0, LOCKGRANTED = NULL, LOCKEDBY = NULL
WHERE ID = 1;

-- 誤ったDATABASECHANGELOGレコードを削除
-- ※ スキーマ反映済みのchangeSetは残す
-- ※ 削除後、次回起動時にLiquibaseが自動的に未実行分を順次適用する
DELETE FROM DATABASECHANGELOG
WHERE ID LIKE 'v48.00-%'
  AND ID NOT IN ('v48.00-001', 'v48.00-002', 'v48.00-003', 'v48.00-004');

4本番前にクローンDBで必ず検証

本番DBのクローンに修復SQLを実行 → マイグレーション完走を確認してから本番適用

AIとの分業ルール

役割Claude Code人間
担当調査・スキーマ比較・SQL生成・OSSリポジトリ解析・AIレビュー方針決定・本番DB操作・最終承認
禁止事項本番DBへの直接アクセス・操作AIの出力を無レビューで本番適用
AIレビューの実施方法:
生成されたSQLや対応方針は、必ず別セッションのClaude Codeに以下を指示してレビューさせる。
「抜け漏れ」「存在しないオブジェクトへの操作」「実行順序の問題」を重点的に確認。

医療・介護DXへの横展開

制約事項（医療・介護データ特有）:

同じパターンが起きやすい場面:

今後調べる仮説:

鮮度管理
登録日: 2026-03-12 ／ 次回見直し: 2026-09-12
出典: Zenn記事
Liquibase DB保守 マイグレーション Claude Code活用 DB整合性 バージョンアップ