データ基盤（SQL/Synapse）
定石を愚直に。「小さく分割して複雑化を止める」
データ基盤を検討する顧客が不安なのは、「作ること」よりも"使い続けられること"です。
元データをそのまま突っ込んで後から整合性が崩れる、BIが遅くて定着しない、ストレージと計算課金が膨らむ、権限と監査が難しい、系統が追えず変更が怖い——この5つが典型です。
当社は、データベース設計の定石を愚直に実行し、「小さく分割して複雑化を止める」ことで解消します。
よくある課題
「作ること」よりも
「使い続けられること」に不安があります
設計が破綻しやすい
元データのまま突っ込み、後から整合性と集計ロジックが崩れて作り直しになる
BIが遅くて使えない
Power BI等で本番データを食わせた瞬間に性能問題が顕在化する
コストが予想できない
ストレージと計算（クエリ）の課金が膨らみ、運用フェーズで予算超過する
権限と監査が難しい
誰が何にアクセスできるかが曖昧になり、監査・事故対応で詰む
ブラックボックス化する
データの出どころ（系統）や依存関係が追えず、変更が怖くなる
当社はデータベース設計の定石を愚直に行い「小さく分割して複雑化を止める」ことで、これらを解消します。
規模別の定石：小規模→中規模→大規模へ「自然に伸びる」構成
まずは最小構成で価値を出し、必要な箇所だけを段階拡張します。
１．小規模
最短で立ち上げ、無駄を作らない
[App] → [Azure SQL] → [Blob]（単一リージョン）
正規化とデータ型最適化で無駄を削り、DBはSKUを段階アップ。コールドデータはBlobのライフサイクルで低頻度階層へ移し、ストレージ費を抑えます。
２．中規模
冗長化＋分析基盤、運用と性能を両立
[SQL(HA)]＋[Cache]／ETL：Synapse Pipeline／分析：ADLS＋Synapse
読み取り分離、パーティション／索引、予約容量を組み合わせ、計算費と性能をバランスします。Serverless/Dedicatedの使い分けで柔軟に対応。
３．大規模
ワークロード分離＋DR、止めない設計へ
[Ingest] → [ADLS] → [Synapse Dedicated] → [BI] ＋ リージョンDR
ワークロード別にプールを分離し、夜間停止・自動スケールでコストを抑制。クエリはServerless/Dedicatedを使い分けて最適化します。
当社のアプローチ
コスト最適化：ストレージと計算を分けてコントロールする
データ基盤のコストは「データの置き方」と「クエリの回し方」で決まります。
Blob／ADLSは階層設計とライフサイクルでストレージ費を抑え、SynapseはServerless/Dedicatedの使い分け、予約容量、自動スケール／停止で計算費を制御します。
「気づいたら高い」を仕組みで防ぎます。
ガバナンス：権限・監査・系統管理を標準化して事故を防ぐ
品質と権限はRBAC＋最小権限（View／Stored Proc）＋監査ログを標準化し、権限棚卸しはCLI等で定期自動化。
さらにPurviewでデータカタログ／リネージ（系統）を可視化し、GitでSQL資産を系統管理。変更に強く、「誰が見ても説明できる」状態を作ります。
つまずきポイントと解決：止めずに立て直す「現実解」も用意する
つまずきは大きく2つです。
1つ目の「生データ突っ込み」は、正規化・キー設計・テーブル分割で辻褄を合わせて解消。
2つ目の「BIが遅い」は、本番データで早期に性能検証し、必要ならSQL／ストアドや集計テーブルへ一時回帰して運用を止めません。
その上で必要箇所だけを選択的に非正規化し、性能と整合性を両立させます。
段階拡張：必要な箇所だけを伸ばす設計思想
最小構成で価値を出し、必要に応じて拡張
正規化・キー設計の定石に忠実に設計
Purviewでリネージを可視化、監査に強い運用
Azure Monitorでクエリ遅延と容量を定点観測し改善を積み上げ