SELECT * で困ったことありませんか？SQLFluffプラグインを作って公開した話
この記事は10X 新春ブログリレー 2026の1月8日分です。
こんにちは、10X 売場チームの takimo です。普段は dbt を使ったデータパイプラインの開発・運用を担当しています。
今日は、誰もが一度は書いたことがある というSQL文について、そしてそれをチェックするための SQLFluff プラグインを作成して公開した話をしたいと思います。
「SELECT *」使ってますか？
みなさん、こんなSQL書いたことありませんか？
シンプルで便利ですよね。全カラムを取得できて、新しいカラムが追加されても自動的に含まれる。初心者にも優しい。
でも、データパイプラインでこれを使うと、痛い目に遭います。
私自身、何度も以下のような経験をしてきました：
- 🔥 ある日突然、下流のモデルがエラーになる
- 原因：上流テーブルにカラムが追加され、予期しないデータ型が流れてきた
- 💸 BigQuery のコストが想定の3倍に
- 原因：使っていないカラムまで全て読み込んでいた
- 🐛 バグの原因調査に半日かかる
- 原因：どのカラムが実際に使われているか誰も把握していなかった
これらの原因の中に が潜んでいたという場面あると思います。
SELECT * の何が問題なのか？
データパイプラインの文脈で が引き起こす問題は、主に4つあります。
1. 予測不可能なスキーマ変更
ソーステーブルのスキーマが変更（カラムの追加・削除）されると、 はクエリ出力を自動的かつ暗黙的に変更します。
下流のモデルやアプリケーションが カラムを想定していなければ、予告なく壊れる可能性があります。
2. パフォーマンスの低下
特に列指向データベース（BigQuery、Snowflake など）では、必要のないカラムを読み込むことで：
- ネットワークの無駄
- メモリの無駄
- ストレージI/Oの無駄
- コストの増加（BigQuery はスキャン量で課金）
が発生します。
3. 保守性の低下
コードレビューやトラブルシューティング時、以下の問題が発生します：
- どのカラムが実際に使われているのか分からない
- データリネージ（依存関係）の追跡が困難
- 影響範囲の分析も困難
4. ドキュメント性の欠如
明示的なカラム選択は、それ自体がデータコントラクトとして機能します：
このコードを見れば、下流が何に依存しているかが一目瞭然です。
社内での課題と解決策
課題：チーム全体での品質担保
dbtを使って数百のモデルを管理しているといった事例は多いと思います。特にステージングモデル（ で始まるファイル）は生データの入り口であり、ここでの品質が下流全体に影響します。
しかし、以下の課題がありました：
- コードレビューで を見逃すことがある
- 新しいメンバーが知らずに を使ってしまう
- 既存のコードをリファクタリングする際の見落とし
解決策：Linterでの自動チェック
自分たちのチームはSQLFluff という SQL Linter を使っています。そこで、「 を禁止する独自ルール」を作ることにしました。
最初は社内専用のルールとして開発しましたが、以下の理由からOSS として公開してみようかなと思いました：
- 同じ課題を抱えている人は多いはず
- データエンジニアリング界隈での共通課題
- 外部からのフィードバックで品質向上
- 多様なユースケースでテストされる
技術的なアプローチ
SQLFluff のプラグインアーキテクチャ
プラグインの実装は主に3つのステップで構成されます：
1. エントリーポイントの定義
で SQLFluff にプラグインを認識させます：
2. ルールの実装
3. 設定による柔軟な制御
ユーザーは ファイルで対象を指定できます：
実装のポイント
パフォーマンスの最適化
を使うことで、SQL の全セグメントを走査するのではなく、 だけを効率的にチェックします：
これにより、大規模なコードベースでも高速に動作します。
COUNT(*) は許可
は集約関数として一般的で問題ないため、SQLFluff のパーサーが セグメントとして認識する場合は除外しています：
段階的な導入をサポート
設定により、特定のファイルだけにルールを適用できます。これにより：
- まずステージング層から導入
- 徐々に適用範囲を拡大
- 既存コードへの影響を最小化
というアプローチが可能です。
外部化で学んだこと
社内ツールをOSSとして公開する過程で、いくつかの学びがありました。
1. ドキュメントの重要性
社内では「暗黙の了解」で済んでいたことも、外部公開するには明示的な説明が必要です：
- インストール手順
- 設定オプションの詳細
- トラブルシューティングガイド
- ユースケースの具体例
2. テストの重要性
外部公開に際して、テストカバレッジを大幅に強化しました：
- Python 3.9-3.12 のマトリックステスト
- 8つのテストケースで主要シナリオをカバー
- CI/CD での自動テスト実行
これにより、バグの早期発見と品質向上につながりました。
3. コミュニティからのフィードバック
まだ公開したばかりですが、以下のような反響を期待しています：
- 異なるSQL方言での動作確認
- 新しいユースケースの発見
- パフォーマンスの改善提案