BigQueryのラベル機能でプロジェクト横断のコスト配分を管理する

はじめに：どの案件がいくら使ったかが分からない

BigQueryを複数の用途で使い始めると、ある時点でこんな疑問にぶつかります。「先月の請求は全体でこれくらいだったけれど、A社の案件とB社の案件、それぞれいくらかかったんだろう？」というものです。

ひとつのGoogle Cloudプロジェクトに複数の案件のデータセットを同居させていたり、社内の分析チームとマーケチームが同じ環境を共有していたりすると、請求書には「合計いくら」しか出てきません。誰が・どの目的で・どれだけ使ったのかを後から切り分けようとしても、手がかりがないのです。

クライアントに費用を実費精算で請求したいときや、社内で部門ごとにコストを按分したいとき、この「内訳が見えない」状態はかなり困ります。プロジェクトを案件ごとに分ければ請求も分かれますが、プロジェクトを増やすと管理する設定や権限も増えて、それはそれで手間がかかります。

ここで役立つのが ラベル です。BigQueryのデータセットやテーブル、実行したジョブに「これはA社案件」「これはマーケ部門」といった目印を付けておけば、後からその目印で集計し、コストを利用主体ごとに配分できます。この記事では、ラベルの基本から付与の方法、そしてCloud Billingのエクスポートと組み合わせてコストを配分する流れまでを順に紹介します。

ラベルとは：リソースに付ける key:value の目印

ラベルは、Google Cloudのリソースに付けられる key:value 形式のメタデータ です。たとえば project:acme-corp や department:marketing のように、「キー」と「値」のペアで「このリソースは何のためのものか」を記録します。

BigQueryでは、主に次のリソースにラベルを付けられます。

データセット — 案件や部門の単位でまとめてラベルを付けるのに向いています。
テーブル / ビュー — データセット内をさらに細かく分けたいときに使います。
ジョブ（クエリ実行） — 「このクエリはどの用途で流したか」を実行のたびに記録できます。

ラベルにはいくつかの命名ルールがあります。Google Cloud公式ドキュメントによると、おもな制約は次のとおりです。

ひとつのリソースに付けられるラベルは最大64個まで。
キーは1〜63文字、値は0〜63文字（値は空でも構いません）。
キーと値に使えるのは、小文字の英字・数字・アンダースコア（_）・ハイフン（-）のみ。大文字やスペース、日本語は使えません。

つまり Project:ACME社 のような表記は使えず、project:acme-corp のように小文字とハイフンで揃える必要があります。仕様は変わることがあるので、本番で運用する前に公式ドキュメントの最新の上限値を確認しておくと安心です。

ラベル付与の例

実際にラベルを付ける方法を見ていきます。データセットやテーブルにはSQLで、ジョブには bq コマンドで付けるのが分かりやすい組み合わせです。

データセットとテーブルにSQLで付ける

データセットに対しては ALTER SCHEMA でラベルを設定できます。

-- データセットに案件と部門のラベルを付ける
ALTER SCHEMA `my_project.acme_analytics`
SET OPTIONS (
  labels = [
    ("project", "acme-corp"),
    ("department", "marketing"),
    ("env", "prod")
  ]
);

テーブルやビューには ALTER TABLE を使います。

-- テーブルにラベルを付ける
ALTER TABLE `my_project.acme_analytics.orders`
SET OPTIONS (
  labels = [
    ("project", "acme-corp"),
    ("data-tier", "raw")
  ]
);

新規にテーブルを作る時点でラベルを付けたい場合は、CREATE TABLE の OPTIONS 句に同じように書けます。

ジョブ（クエリ実行）に bq コマンドで付ける

コストの配分でとくに効くのが、ジョブへのラベルです。同じテーブルに対するクエリでも、「どの用途で流したか」を実行ごとに記録できるからです。bq query では --label オプションを使います。

# クエリ実行時に用途のラベルを付ける
bq query \
  --use_legacy_sql=false \
  --label=project:acme-corp \
  --label=team:analytics \
  'SELECT COUNT(*) FROM `my_project.acme_analytics.orders`'

定期実行しているスケジュールクエリや、アプリケーションから投げるクエリにも、同じ考え方でジョブラベルを付けておくと、後の集計がぐっと楽になります。--label は複数回指定すれば複数のラベルを付けられます。

Cloud Billingエクスポート × ラベルでコストを配分する

ラベルを付けただけではコストは見えません。これを Cloud Billingのエクスポート と組み合わせて、はじめてコスト配分ができるようになります。

Cloud Billingには、課金データをBigQueryのテーブルへ日次でエクスポートする機能があります。このエクスポートには、各課金明細に紐づくラベルの情報も含まれます。つまり「A社案件のラベルが付いたリソースで、いくら課金されたか」を、SQLで集計できるわけです。

エクスポート先のテーブルでは、ラベルは labels という繰り返しフィールド（key と value の配列）として格納されています。ここから特定のキーの値を取り出すには、UNNEST を使います。

-- Billingエクスポートからラベル別にコストを集計する
SELECT
  (SELECT value FROM UNNEST(labels) WHERE key = "project") AS project_label,
  ROUND(SUM(cost), 2) AS total_cost
FROM
  `my_project.billing_export.gcp_billing_export_v1_XXXXXX`
WHERE
  service.description = "BigQuery"
  AND usage_start_time >= TIMESTAMP("2026-08-01")
GROUP BY
  project_label
ORDER BY
  total_cost DESC;

実際のテーブル名（gcp_billing_export_v1_XXXXXX の部分）は、各環境のBilling設定で生成されたものに置き換えてください。このクエリを project ラベルの値ごとに集計すれば、「acme-corp にいくら、別案件にいくら」という内訳が出てきます。クライアントへの実費精算や、部門ごとの按分のベースとして使える数字です。

なお、Cloud Billingの管理画面にも、ラベルでコストをフィルタ・グルーピングできるレポート機能があります。まずは画面で傾向を眺め、定型の配分集計はBillingエクスポートのSQLで自動化する、という使い分けが現実的です。

INFORMATION_SCHEMA でラベルの付与状況を把握する

コストを配分する前に、「そもそもラベルがちゃんと付いているか」を確認しておきたい場面があります。付け忘れたデータセットやテーブルがあると、その分のコストは「ラベルなし」として配分から漏れてしまうからです。

ラベルの付与状況は INFORMATION_SCHEMA で確認できます。データセットのラベルは SCHEMATA_OPTIONS、テーブルのラベルは TABLE_OPTIONS で参照できます。

-- データセットに付いているラベルの一覧
SELECT
  schema_name,
  option_name,
  option_value
FROM
  `region-asia-northeast1`.INFORMATION_SCHEMA.SCHEMATA_OPTIONS
WHERE
  option_name = "labels"
ORDER BY
  schema_name;

ジョブに付けたラベルは、INFORMATION_SCHEMA.JOBS 系のビューにある labels 列から確認できます。これを使えば「ラベルの付いていないクエリがどれくらい流れているか」を把握し、付与のルールが守られているかをチェックできます。

-- 直近のジョブのラベル付与状況を確認する
SELECT
  user_email,
  job_id,
  labels,
  total_bytes_processed
FROM
  `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND job_type = "QUERY"
ORDER BY
  total_bytes_processed DESC
LIMIT 50;

リージョン名（region-asia-northeast1）は、対象のデータセットがあるリージョンに合わせてください。INFORMATION_SCHEMA を使ったコスト監視そのものについては、BigQueryのINFORMATION_SCHEMAでクエリコストと実行履歴を自動監視するで詳しく扱っているので、あわせて読むと全体像がつかみやすくなります。

⚠️ ラベル設計は付け始める前に決める

ここでひとつ注意点があります。ラベルは 付け始める前に、命名ルールを決めておく ことが何より大切です。

途中でルールがぶれると、project:acme-corp と project:acme と client:acme-corp のように、同じものを指すラベルが乱立してしまいます。こうなると集計のたびに表記ゆれを吸収する処理が必要になり、せっかくのコスト配分が信用できない数字になってしまいます。

最低限、次の3点は最初に決めておくことをおすすめします。

どのキーを使うか — たとえば project（案件）、department（部門）、env（本番/検証）の3軸に絞る、というように決めます。
値の表記をどう揃えるか — 小文字とハイフンで統一し、略称ではなく決まった識別子を使う、などのルールを文書に残します。
必須にするか — ラベルのない新規データセットやクエリを作らない運用にするのか、どこまで強制するのかを決めておきます。

キーを増やしすぎると今度は付ける側の負担になります。最初は2〜3軸に絞り、運用しながら必要なものを足していくのが現実的です。

まとめ

BigQueryのラベルは、「どの案件・どの部門が、いくら使ったのか」という内訳を取り戻すための仕組みです。ポイントを整理します。

ラベルは key:value 形式の目印で、データセット・テーブル・ジョブに付けられます。小文字英数字とアンダースコア・ハイフンのみ、1リソース最大64個までという制約があります。
データセットやテーブルにはSQLの OPTIONS、ジョブには bq query --label で付けられます。
Cloud Billingのエクスポートにはラベル情報も含まれるので、UNNEST でラベル別にコストを集計すれば、案件ごと・部門ごとの配分ができます。
INFORMATION_SCHEMA で付与状況を確認し、付け忘れを防ぎます。
何より、付け始める前に命名ルールを決めておくことが成否を分けます。

ラベルは一度仕組みを整えれば、その後はコストの内訳が自動的に積み上がっていきます。プロジェクトを分けずに利用主体を見分けたいときの、現実的な選択肢です。コストを配分する前に「そもそも総額を抑える」という観点では、BigQueryのクエリコストを月1万円以下に抑える7つの実践テクニックにまとめた工夫もあわせて取り入れてみてください。