Journal: 20260223-0019-スキーマバージョン管理テーブルの追加

1. 作業実施の理由

今後のデータベース構成の変更（マイグレーション）をより確実かつ自動的に管理するため。スキーマの現在のバージョンをデータベース自体に保持させることで、プログラム側での状態判断を容易にする。

2. 指示（背景、観点、意図を含む）

指示: 「dbに今のテーブル構成がどのバージョンであるか格納するテーブルを1つ作ったらどうかと思うんだが、どうだい？」
背景: これまでは特定のカラムの有無などでバージョンを推測していたが、将来的な複雑化に備えて明示的な管理が必要。
意図: 「管理テーブル（internal_metadata）が存在しない＝ 0.3.0 未満」という判断基準を導入し、既存のマイグレーションロジックを整理する。

3. 指示事項とその対応

管理テーブルの新設: key と value を持つ internal_metadata テーブルを追加。
バージョン記録: version: 0.3.0 を初期値（または移行完了値）として保存。
マイグレーションロジックの改善: 以前実装した migrate_025_to_030 において、まず internal_metadata の有無を確認するステップを追加。
ドキュメント反映: データベース仕様書を更新。

4. 作業詳細

AIエージェントは以下の手順で作業を実施した。

src/backend/src/db.rs を修正し、internal_metadata の作成とバージョン書き込み処理を init_schema に追加。
migrate_025_to_030 をリファクタリングし、管理テーブルの有無を最優先の判断材料とするように変更。
docs/specification/03_database_specification.md のER図と詳細説明に新テーブルを追記。
cargo check によりビルドの整合性を確認。

5. AI視点での結果

明示的なバージョン管理テーブルを導入したことで、今後のマイグレーションが極めて安全かつ論理的に行えるようになりました。場当たり的なカラムチェックではなく、「DBが語る自己のバージョン」に基づく挙動は、将来的な大規模アップデート時の事故防止に直結します。また、ユーザーが以前提案した「テーブルの有無で判断」というロジックは、既存の v0.2.5 以前の環境に対しても完璧に機能するため、非常に優れた移行パスとなりました。