レガシー SQL 由来の日本語テーブル名と、どう向き合うか

なぜ書いたか

レガシー業務系のSQLを読むと、テーブル名や列名が 日本語 で書かれていることが普通にあります。「漢字混じりのマスタ_明細」みたいなやつです。Blazor + EFへの移行で、AIにこれらをマッピングさせると、微妙に名前を間違えたり、同音異義のテーブルを混同したりする事故が起きます。今回はその扱い方をルール化した話です。

何が起きやすいか

具体的に踏んだのはこのあたりです。

• 似た名前のテーブルを 別物として2系統持っている のに、片方しか触らずに「削除完了」してしまう（本体だけ消して内訳・添付が残る）
• カナ・漢字・全角半角がぶれた名前をAIが「同じ」と推論してしまう
• 元実装のクエリが日本語識別子を 二重引用符で囲んだOracle SQL だったが、移行先のEF Coreで囲み方を間違えて通らない

対策: 命名は「正確さ」が品質そのもの

3つだけルールにしました。

1. エンティティ名は元のテーブル名と1:1対応 にする（漢字含めてそのまま）。略称や英語化は禁止
2. 削除・更新クエリは元VBのSQLを写経して比較する。AIに書き直させる前に、まず人間が「触るテーブル一覧」を抽出する
3. 関連マスタは集合として扱う。「本体・内訳・添付」のような3系統が常にセットなら、削除サービスの中で一括ハンドリングする責任を1箇所に集める

わかったこと

• 日本語識別子は移行で最も誤字が出やすい場所。AIに丸投げせず、触るべきテーブルの一覧を先に確定 してから実装させるのが安全
• 元実装が「本体 + 内訳 + 添付」のような関連系統を持っていたら、移行先でも 集合として扱うサービス を1つ用意するのが結局速い。個別呼び出しを画面ごとにやると、どこかで漏れます
• レビュー観点に「触るべきテーブルが全部触られているか」を固定で入れると、漏れがほぼ消えました

次にやること / 未解決の問題

• EF Core側の [Table("漢字混じりのマスタ_明細")] 属性の運用ガイドを書きたい。今は属性で日本語名を吸収しているが、運用ルールが揺れている
• 同音異義テーブルがあるドメインでは、エンティティのクラス名を英語にしつつ属性で日本語テーブルを指定する方式と、クラス名も日本語にする方式が両方混ざっている。どちらかに寄せたい