Databricks、SQL 実行に業務文脈を付与する Query Tags を公開プレビュー

Databricks は 2026年6月2日、Databricks SQL の実行にカスタムメタデータを付与できる Query Tags を公開プレビューとして紹介しました。チーム、プロジェクト、ダッシュボード、アプリケーションなどの文脈をクエリに紐づけ、システムテーブルで分析できる機能です。

要点

• Query Tags は SQL 実行に key-value 形式の業務文脈を付与する機能
• コスト配賦、遅いクエリの特定、パートナーツール由来のクエリ監視に使える
• dbt、Power BI、Tableau などの識別子をクエリに伝搬する用途が説明されている
• SQL Editor、Notebooks、Dashboards、APIs、connectors、drivers など幅広い実行元から利用できる
• タグ命名規則と必須タグの運用が重要になる

今回のブログ記事で語られていること

この記事は、Databricks SQL のクエリログに「誰が」「どのウェアハウスで」「どのツールから」実行したかだけでは足りないという問題から始まります。たとえば Power BI から遅いクエリが来ていることは分かっても、どのダッシュボードが原因か分からない。コストが増えても、どのプロジェクトやコストセンターに紐づくか分からない。Query Tags は、この欠けていた業務文脈を SQL 実行ごとに付与する仕組みです。

Query Tags では、project、cost_center、dashboard_id、application_name のような key-value をクエリに付けられます。タグは Query History System Table に記録され、SQL で集計・分析できます。記事では、dbt のモデル名、Power BI のレポート ID、Tableau の workbook 名など、パートナーツール由来の情報をクエリに伝搬する例も示されています。これにより、遅延調査、コスト配賦、利用状況分析、SLA 管理がしやすくなります。

重要なのは、Query Tags が単なるログ装飾ではなく、データウェアハウス運用の観測性を上げる機能だという点です。クエリの技術的メトリックと業務文脈がつながると、費用や性能の議論をチーム、プロジェクト、顧客、アプリ単位で行えます。一方で、タグ名がばらばらだと分析できないため、命名規則と必須タグの標準化が必要です。

Databricks は 2026年6月2日、Databricks SQL の実行にカスタムメタデータを付与できる Query Tags を公開プレビューとして紹介しました。チーム、プロジェクト、ダッシュボード、アプリケーションなどの文脈をクエリに紐づけ、システムテーブルで分析できる機能です。

今回のブログ記事が関係する人

• databricks をすでに利用しており、今回の内容が運用、開発、分析、データ連携にどう影響するかを確認したいチーム
• AI・データ基盤の選定や導入計画を進めており、公式ブログの背景や実務上の読み方を整理したい担当者
• セキュリティ、ガバナンス、監査、コスト、サポート体制など、発表内容を本番運用の判断材料に落とし込みたい管理者

実務で確認したいポイント

導入時は、タグキーの標準、必須タグ、パートナーツールからの伝搬可否、個人情報をタグに入れないルールを決めるべきです。System Tables で集計し、コスト配賦や性能監視に使うダッシュボードを先に作ると定着しやすくなります。

結局、今回のブログ記事をどう読むべきか

Query Tags は、Databricks SQL の運用を技術ログから業務文脈つきの観測性へ引き上げる更新です。コスト管理、BI 運用、パートナー連携を真面目に見るチームほど効果が出やすい機能です。