野良テーブルの増殖を止めるデータモデルレビューの手順
この記事の対象読者
クラウドDWHの野良テーブル対策に悩むデータ基盤担当者・データモデラー・情シス担当者
この記事で持ち帰れること
権限分離で勝手なテーブル作成を防ぐ手順
形骸化しない申請台帳とモデル審査項目
PRとCI/CDで事前審査を自動化する方法
クラウドDWHを導入した後、各部署が作ったテーブルが増え続け、同じ指標が別々の数字で出てくる。こうした状態に悩む現場は多い。
本記事では、権限分離、事前レビュー、CI/CDによる自動化を含む5つの手順で、野良テーブルの増殖を抑える方法を示す。審査を厳しくするだけでは回らない理由も、事例とあわせて整理する。
なぜ野良テーブルは増えるのか
野良テーブルが増える原因は、作成の自由度が高いことと、作成前に確認する場がないことの2点に集約される。クラウドDWHは、権限さえあれば簡単にテーブルを作れる。
典型的な原因は次の3つである。
一般ユーザーにテーブル作成権限が渡っている
新設時に「既存テーブルで代替できるか」を確認する場がない
テーブルの責任者が決まっていない
この状態が続くと、同じ項目に複数の定義が生まれ、集計ロジックも部署ごとに分かれる。結果として、全社データへの信頼が下がる。
ただし、審査を厳格にすれば解決するわけではない。審査の仕組みそのものが破綻する例が報告されている。
具体的な失敗パターン
パターン1：申請フローが複雑すぎて形骸化する
申請フォームの項目や承認階層が多すぎると、現場の負担が増え、自律的なデータ活用が阻害される。Asana がこの点を指摘している。
発生頻度の低い例外処理までフローに組み込むと、設定や運用マニュアルが肥大化して定着しなくなる。この点は kickflow が整理している。
回避策は、事前申請の焦点を「重複していないか」に絞り、必須記載項目を最小限にすることである。
パターン2：手動承認を強制して運用が破綻する
Zenn（レバテック） には、継続的デリバリーの実行時に有識者の参加を強制する承認フローを設けた例がある。運用が形骸化し、最終的にその設定をRevert（撤回）している。
審査をすべて人手に頼ると、デリバリーの流れが止まる。回避策は、構造チェックや構文判定をCI/CDで自動化し、人の負担を減らすことである。
パターン3：権限の過剰付与と役割の曖昧さ
BigQueryのEditorやOwnerといった基本ロールは、広い権限を含む。Google Cloudのドキュメント は、これらを避けて事前定義ロールを使うよう案内している。
ツールだけ入れて責任者を決めない失敗もある。Asana は、データカタログを導入しても入力や更新の責任者が不在だと放置されると述べている。
解決策：5つの手順
手順1：テーブル作成権限を切り離す
最初に、一般ユーザーからテーブル作成権限を外す。ここがまず取り組みたい対策である。
BigQueryでは、基本ロールを避ける。参照だけ許す場合は、承認済みルーティン や承認済みビューを使う。元テーブルへの権限も作成権限も渡さずに、結果の参照だけを許可できる。
Snowflakeでは、`GRANT CREATE TABLE ON SCHEMA` の対象を `AR_ETL_WRITE` のような書き込み専用ロールに限る。さらに管理アクセススキーマを適用すると、オブジェクトの所有者が独自にGRANTを行えなくなる。権限制御は `MANAGE GRANTS` を持つ管理者に集約される。参考として Zenn と Snowflakeのドキュメント がある。
手順2：新設申請に「重複確認」のゲートを置く
作成の入口には、レビューゲートを1つだけ置く。最初の問いは「既存のテーブルやマートで代替できないか」である。
申請台帳の記載項目は、GENIEE の整理に沿うと次の6つになる。
テーブル（マート）名
用途・分析目的
オーナー部門
更新頻度
依存ソーステーブル
廃止予定の有無
項目はこれ以上増やさない。増やすほど、パターン1に近づく。
手順3：モデルの審査項目を固定する
審査で見る観点を、あらかじめ固定する。DATA VIZ LAB が挙げる観点を整理すると、次のようになる。
命名では、テーブル名とカラム名がルールに沿い、論理名と物理名が対応しているかを見る。粒度では、1レコードの意味を一文で説明できるかを見る。制約では、主キーと一意制約により重複が入らないか、NULL可否と参照整合性が保たれているかを見る。履歴保持の要件に耐える構造かも確認する。
命名ルールを作る際は、行政の標準が参考になる。デジタル庁系の連携ファイル名は、スネイクケースで、タイムスタンプと版数を含む（例：`003o00100v0100_20220126155422111_1.csv`）。詳細は Qiita に整理されている。
項目定義書では、必須区分（◎・〇）、データ型、記入例をセットで管理する。デボノ が紹介している。これはファイル名と項目定義の規定であり、テーブル名にそのまま当てはまるものではない。考え方を自組織のルールへ転用する形が現実的である。
手順4：PRとCI/CDで事前審査を自動化する
審査の機械的な部分は、プルリクエスト（PR）を起点に自動化する。公開されている事例は4つある。
株式会社KINTO では、PR作成をきっかけにGitHub ActionsがAWS Step Functionsを起動する。LambdaがDDLを抽出し、Amazon Bedrock（Claude 3.5 Sonnet）がガイドラインに基づいて並列審査する。結果はPRコメントに返される。処理時間は約1分40秒、コストは1 DDLあたり約0.1 USDと報告されている。
LegalOn Technologies では、`sqldef` とGitHub Actionsを連携している。本番と同バージョンのDBコンテナにスキーマを投入し、`ALGORITHM=INSTANT` でALTER文を実行できるかをレビュー段階で検証する。
株式会社tacoms は、`sql-migrate` のDry-run結果をPRコメントに自動投稿している。マージ前に、チームで変更内容を確認できる。
キャディ株式会社 は、PR作成時に変更分のSQLで一時データセット（`tmp_PR_{PR番号}`）へ自動ビルドして検証している。
自動化の後、人が見る範囲は「既存と重複していないか」「粒度の意味が妥当か」に絞る。構文や制約の確認を機械に任せることは、パターン2のような負担を減らす助けになる。
手順5：作成後の棚卸しを回す
作成時に審査しても、放置すれば再び散らかる。利用されていないテーブルや不要になった権限を、定期的に検出して削除するルールを置く。
台帳には、オーナー部門と更新責任者を必ず書く。責任者のいないテーブルは、棚卸しの削除候補とする。この運用を決めておくと、パターン3の「名前だけの役割」を防げる。
DMBOKとの関係
DMBOK第2版は11の知識領域で構成され、ホイール図の中心にデータガバナンスが置かれている。本記事の権限分離はデータセキュリティ、事前レビューはデータモデリングとデザイン、申請台帳はメタデータ管理に当たる。これらをガバナンスが束ね、ルールとして定着させる関係にある。
棚卸しで未使用データを見つける作業は、データ品質の維持にもつながる。個別のツール設定は、知識領域の中でどこを担う施策かを意識すると、抜けを見つけやすくなる。
チェック項目や自動化の仕組みは、「良いモデルとは何か」という基準があって初めて機能する。基準を体系の中で学んでおくと、ツールが変わってもレビューの軸がぶれない。
体系的に学びたい方へ
この記事のテーマは、拙著『60分でわかる！DMBOKの基礎①: データ設計の極意（アーキテクチャとモデリングで「データの地図」を描く）』の「章9：データ設計の品質評価とガバナンス ― 「良い設計」を定義する（データ設計の品質評価, ガバナンス）」で体系的に解説しています。
データアーキテクチャとデータモデリングを解説しています。概念・論理・物理モデル、ER図、次元モデリング、設計の標準化までを解説する基礎編です。
免責事項
本記事は筆者の知見と公開情報に基づくもので、特定の組織・状況での成果を保証するものではありません。
記事中の情報は公開日時点のものです。実務への適用は、各組織の状況に合わせてご判断ください。
DAMA-DMBOKはDAMA Internationalの登録商標です。
