Excelの項目定義書とDDLを突合する手順 — Claude for Excelで型・桁・NULL可否のずれを洗う

Excelの項目定義書とDDLの食い違いは、DBから列の一覧を出力して同じブックに貼り、キーで突き合わせれば行単位で洗い出せます。Claude for Excelには、突き合わせの式と判定列の組み立てを任せられます。

洗う対象は3つです。データ型、桁(長さ・小数桁)、NULL可否。この記事では、PostgreSQLのinformation_schema.columnsを例に、定義書側の表記ゆれを正規化してから比較し、差異を種類別に集計するところまでを示します。

何を突き合わせ、何を突き合わせないか

突き合わせるのは、設計書に書かれた「あるべき姿」と、DBカタログに載っている「いまの姿」です。テーブルのデータそのものは読みません。列の一覧は定義情報なので、顧客データを含まないCSVにできます。

比較する項目は次の6つに絞ります。

論理名(日本語の項目名)は比較対象にしません。物理名が一致していれば、論理名の違いはDDLの食い違いではなく、設計書の表記の問題だからです。

前提 — 使える環境とブックの用意

Claude for Excelは、Pro・Max・Team・Enterpriseの各プランで使えます。動作環境は、Excel on the web、Microsoft 365版のExcel on Windows(ビルド16.0.13127.20296以降)、Excel on Mac(バージョン16.46以降、ビルド21011600以降)です。Excel 2016・2019の永続ライセンス版、iPad、Androidでは動きません。

設計書がExcel 2016のPCにしか入っていない現場では、web版で開けるかを先に確かめます。マクロとVBAの操作も未対応なので、突き合わせはシートの式で組みます。

ブックは3シートで組みます。

DB側の列一覧を出す

PostgreSQLなら、information_schema.columnsに列ごとの型・長さ・精度・NULL可否・既定値が載っています。必要な列だけを選んでCSVにします。

SELECT table_name, column_name, data_type,
       character_maximum_length,
       numeric_precision, numeric_precision_radix, numeric_scale,
       is_nullable, column_default
FROM information_schema.columns
WHERE table_schema = 'public'
ORDER BY table_name, ordinal_position;

CSVへの出力は、psqlの\copyが手早い方法です。

psql -h <host> -U <user> -d <db> -c "\copy ( \
  SELECT table_name, column_name, data_type, \
  character_maximum_length, numeric_precision, \
  numeric_precision_radix, numeric_scale, \
  is_nullable, column_default \
  FROM information_schema.columns \
  WHERE table_schema = 'public' \
  ORDER BY table_name, ordinal_position \
) TO 'columns.csv' CSV HEADER"

ほかのDBでも、カタログから同じ観点の列を取り出せば構いません。以降の比較は、列名を読み替えるだけで成り立ちます。

食い違いの出方を先に知っておく

DB側の読み方にはクセがあります。比較式を書く前に、ここを押さえておきます。

PostgreSQLの文字列型は、宣言した長さより長い値を入れるとエラーになります。ただし超過分がすべて空白のときは切り詰められます。設計書の桁がDDLより大きいと、運用で入る値の長さによっては、ずれがしばらく表に出ません。

数値型のNUMERIC(3, 1)は、小数1桁に丸めて-99.9から99.9までを持ちます。設計書の「10,2」の読み方(全体の桁数なのか整数部なのか)が現場でそろっていないと、桁の突合は意味を持ちません。

定義書側を正規化する

定義書は人が書いた表なので、型の表記が揺れます。「文字列」「VARCHAR」「varchar(20)」「可変長文字」が同じ意味で混在するのは、珍しくありません。そこで、突合シートの左半分を定義書の正規化に使います。

Claude for Excelには、依頼文で区切りと規則を渡します。

「定義書」シートの項目一覧を、「突合」シートに次の列で整理してください。
- A列: キー(テーブル物理名と項目物理名を「.」でつなぐ。小文字にそろえる)
- B列: 正規化した型(文字列系は varchar、数値の整数は integer、
  小数付きは numeric、日付は date、日時は timestamp のいずれか)
- C列: 文字列長(数値のみ。無ければ空)
- D列: 数値の全体桁数、E列: 小数桁数
- F列: NULL可否(「必須」に○があれば NO、無ければ YES)
型の表記が上の分類に当てはまらない行は、B列を空にして
G列に「要確認」と理由を書いてください。推測で分類しないでください。

最後の一文が重要です。分類不能な行を埋めさせると、食い違いの原因が正規化の段階で混ざります。空にさせておけば、人が読むべき行だけが残ります。

DB側の型名は、character varying→varchar、integer/smallint/bigint→integer、numeric→numeric、timestamp without time zone→timestampの対応表を「DDL実体」シートの右に置き、同じ規則で正規化します。設計書とDBで型の分類を揃えるこの対応表が、突合の物差しです。

行単位で突き合わせる

正規化ができたら、突合シートの右半分にDB側の値を引き、判定列を並べます。Claudeへの依頼は次の形です。

「突合」シートの A列のキーをもとに、「DDL実体」シートから
同じキー(table_name と column_name を「.」でつないだもの)の行を探し、
H列以降に DB側の型・文字列長・全体桁数・小数桁数・NULL可否を並べてください。
そのうえで次の判定列を数式で作ってください。
- 存在: 定義書にあるが DB に無い / DB にあるが定義書に無い / 両方にある
- 型: 一致 / 不一致
- 長さ・桁: 一致 / 不一致(型が不一致の行は「対象外」)
- NULL可否: 一致 / 不一致
値は書き換えず、数式だけを入れてください。
存在の判定は、定義書とDDL実体の両方向で確認してください。

「DBにあるが定義書に無い」行は、定義書側のキーを引くだけでは見つかりません。DB側の一覧にも同じ判定を作らせ、結果を下に足す必要があります。そのため依頼文の最後に、両方向で存在を確認する1行を入れています。

Claude for Excelは、セルの値と数式の関係を保ったまま編集でき、答えにはセル単位の根拠が付きます。判定列が正しい行を指しているかは、その根拠のリンクから個別に辿れます。

差異を種類別に数える

最後に、判定列を集計する小さな表を作らせます。

「集計」シートに、突合シートの判定列ごとの不一致件数を
テーブル別の表で出してください。行がテーブル、列が
「存在の不一致」「型」「長さ・桁」「NULL可否」です。

テーブル別に不一致が偏っていれば、その表の設計書だけが更新から漏れていた可能性があります。全テーブルに薄く散っていれば、型分類の規則そのものがずれている疑いが先です。

突合そのものを検算する

判定列を信じる前に、行数の整合を確かめます。「両方にある」の件数と、定義書だけの件数、DBだけの件数を足すと、キーの総数に一致するはずです。合わなければ、キーの小文字化や前後の空白で、同じ項目が別物として扱われています。

出てきた差異の読み方

不一致は、直す側が決まっていません。DDLが正しく設計書が古いのか、設計書が正しくDDLが実装ミスなのか、突合では分かりません。例えば、次の3行が突合シートに出たとします(架空の例です)。

1行目は、101文字以上のメモを登録するとエラーになる状態です。2行目は桁が広がっているだけなら実害は小さい一方、必須のはずの合計金額が空で入る点は、入力チェックの確認が先です。3行目は、設計書への反映漏れを疑います。

食い違いの種類ごとに、まず疑う側を表にしました。

NOT NULL制約は、CHECK (column_name IS NOT NULL)と機能的に同じです。一方、通常のCHECK制約は式がNULLのときも満たされた扱いになるので、「CHECKがあるからNULLは入らない」とは言えません。必須の判定はis_nullableで行い、CHECK制約の有無とは分けて読みます。

つまずきと注意点

設計書は外部から来たファイルであることが多い

SIの納品物やベンダーから受け取った設計書は、外部のファイルです。Claude for Excelは、信頼できるスプレッドシートだけで使う前提になっています。隠し文字列に仕込まれた指示で、データの抽出や書き換えが起きる可能性がある、と注意書きがあります。

受け取ったブックをそのまま開かず、必要なシートの値だけを新しいブックに貼ってから使います。リスクの高い操作は確認が出ますが、確認の内容は読んでから承認します。

結果は監査の根拠にしない

Claude for Excelは、人のレビューなしの最終成果物や、監査に関わる計算の検証なしでの利用には向きません。突合の結果は、レビューで人が確かめる候補一覧として使います。件数の多い不一致は、テーブルを数個抜き出し、設計書とDDLを目で見て確かめます。

会社のデータの扱い

列の一覧に社内のテーブル名や項目名が含まれる点は、意識しておきます。入力と出力はバックエンドで30日以内に削除される一方、チャット履歴はブラウザ内のIndexedDBに残ります。Enterpriseの監査ログには、アドインの操作は含まれません。扱いに規程のある案件では、管理者と確認しておきます。

自分の環境のDBに合わせて読み替える

この記事の列名はinformation_schema.columnsのPostgreSQL版です。カタログの列名や型名の表記は、DBMSごとに違うことがあります。依頼文の列名は、実際に出力したCSVの見出しに合わせて書き換えます。

設計書とDDLをそろえたあとの作業

食い違いの一覧を直し終えたら、同じ突合の仕組みを使い回せます。DDLが変わるたびに「DDL実体」シートだけを貼り替え、判定列が再計算されるのを見るだけです。

DDLからER図を起こす作業はClaude CodeでER図をMermaidで起こすに手順があります。外部キーの関連まで設計書と比べたいときの材料になります。

Excelの2つの表を突き合わせる点は、請求の突合と同じ構造です。差異の種類を先に分類してから集計する進め方は、運賃請求書を運賃表と突合する手順にもあります。Claude for Excelの利用環境と検算の考え方は、かんばん枚数の計算を検算する手順でも説明しています。

まとめ

突合の成否は、比較式よりも前段の正規化で決まります。設計書の型表記をDBのカタログと同じ分類に落とし、分類できない行は埋めずに残す。この2点を守れば、Claude for Excelは差異の洗い出しを速くします。

直す側の判断は突合では出ません。件数が多いときは、テーブル別の不一致の偏りを先に見ます。偏っていれば更新漏れの表を、散っていれば正規化の規則を疑うのが近道です。