民主化が暴走する5つの典型パターン：先に怖さを知っておく

前回 EP.01 で「健全な民主化と危険な民主化を区別する」と書きました。本記事では、「とりあえず開放してみた」組織で実際に起きる暴走パターン 5 つを、再現コードと予防策セットで紹介します。先に事故の形を知っておくことがガードレール設計の出発点です。

AP1: 全件スキャンによるコスト爆発

「全顧客のデータを見たい」という素朴な要求が `SELECT * FROM all_orders` に翻訳され、全期間・全カラム・全行をスキャンしてしまう。BigQuery なら TB スキャン、Snowflake なら クレジット枯渇を一発で起こす。

-- 善意のスタッフが Slack で投げてしまう典型パターンSELECT *FROM events;-- → events が3年分・1兆行・JSON カラム多数 = 数十TBスキャン-- BigQuery で $5/TB なら、このクエリ1本で数百ドル

AP2: 個人情報の Slack リーク

メールアドレスや電話番号を含む生データが Slack の ! クエリ結果として垂れ流される。個人情報保護法・GDPR・PCI DSS の違反になり、会社が監査で指摘される。

-- アナリストが投げる「お客さんのリスト見せて」SELECT user_id, email, phone, nameFROM usersWHERE last_login >= '2027-10-01';-- → email/phone/name はマスキングなしで Slack のチャンネルに展開-- 削除しても Slack のログには残り、退職者が見える

AP3: BI（Business Intelligence） 職人化（属人化の増殖）

「この計算は田中さんしか書けない 300 行 SQL（Structured Query Language）」が増殖する。田中さんが退職すると組織の指標が再現できなくなる。Looker / Tableau の Personal Folder が放置され、誰の数字が正で誰のが間違いか分からない。

AP4: クエリの巨大化と DWH（Data Warehouse） 詰まり

民主化が進むと 同時実行クエリが急増し、ある日 BigQuery は `quota exceeded`、Snowflake は `warehouse queueing` で 業務時間中に分析が止まる。ノイジーネイバー問題を放置すると、夜間バッチも吹き飛ぶ。

AP5: 監査不能（誰が何を見たか分からない）

ログ設定をしないまま民主化を進めると、情報漏洩発生時に「誰が何を見たか追えない」。退職者調査・内部不正調査・コンプライアンス監査で詰む。これは 取り返しのつかないアンチパターン ── 後から過去のログは復元できない。

-- 過去90日の高コストクエリ TOP 20SELECT  user_email,  query,  total_bytes_billed / POW(10,12) AS tb_billed,  creation_timeFROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECTWHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)  AND state = 'DONE'ORDER BY total_bytes_billed DESCLIMIT 20;

5 アンチパターン早見表

ふくふくの提案：先に「事故記録ノート」を作る

民主化プロジェクトを始める前に、「うちで起きそうな事故」を先に書き出す ことを推奨します。各部門のリスク責任者にヒアリングし、重要度 × 発生確率で 5-10 件にまとめると、ガードレール設計の優先順位が自然に決まります。民主化は『開放』だけでなく『予防』とセットで動く。

次の話

EP.03 では、民主化のインターフェース選び。Slack Bot / Streamlit / Looker Studio / NotebookLM など、組織サイズ・データリテラシー・データ機密性に応じてどれを選ぶかの判断軸を整理します。