BigQuery（以下 BQ）で既存テーブルにカラムを追加しようとしたとき、想像以上にハマりました。
最初は単純に、
「ALTER TABLE で ADD COLUMN すればいいだけでしょ？」
と思っていました。
しかし実際には、
- ADD COLUMN が通らない
- DEFAULT を付けたらエラーになる
と、何が原因なのか分からない状態に。
この記事では、実際に試して分かった
BigQuery におけるカラム追加の仕様と、実務での正解パターンをまとめます。
先に結論まとめ
最初に結論だけ書きます。
| やりたいこと | 可否 |
|---|---|
| 既存テーブルにカラム追加 | ◯ |
| 複数カラムを一括で追加 | （環境依存・非推奨） |
| ADD COLUMN + DEFAULT | × |
| CREATE TABLE 時の DEFAULT | ◯ |
| 既存データを DEFAULT で自動補完 | × |
| カラムの途中追加・順序変更 | × |
BigQuery は「RDB と同じ感覚で DDL を書くと事故る」
これが最大の学びでした。
BigQuery でカラム追加する基本形
まずは、基本構文です。
ALTER TABLE `project.dataset.table`
ADD COLUMN status INT64;
- カラムは必ず 末尾に追加される
- 既存データはすべて NULL
- 型変更・順序変更は不可
この形は 最も安全で、実務でも推奨されます。
複数カラムを一括で追加できる？
ドキュメントや記事によっては、以下のような例を見かけます。
ALTER TABLE `project.dataset.table`
ADD COLUMN (
col1 INT64,
col2 STRING
);
しかし、実務では要注意です。
私の環境では、
- ( の位置でシンタックスエラーになる
- 実行環境（UI / bq / SDK）によって挙動が変わる
という状態になりました。
複数カラム一括追加は環境依存が強く、本番では非推奨
→ 1カラムずつ ADD COLUMN するのが安定解。
ADD COLUMN + DEFAULT はできる？
次にハマったのがこれです。
ALTER TABLE `project.dataset.table`
ADD COLUMN status INT64 DEFAULT 0;
一見、問題なさそうに見えます。
しかし実行すると、次のエラーが返ってきます。
Add field with default value to an existing table schema is not supported
結論
既存テーブルへのカラム追加時に DEFAULT を付けることは未サポートです。
DEFAULT が使える／使えないを整理
BigQuery の DEFAULT は中途半端に実装されているため、混乱しがちです。
| 操作 | DEFAULT |
|---|---|
| CREATE TABLE 時 | ◯ |
| ALTER TABLE ADD COLUMN | × |
| INSERT（列省略） | ◯ |
| 既存データ | × |
つまり、
DEFAULT は「テーブル作成時のみ定義可能」
という理解が正解です。
DEFAULT を使いたい場合の実務的な代替案
パターン①：UPDATE で既存データを埋める
最もシンプルでよく使われる方法です。
ALTER TABLE `project.dataset.table`
ADD COLUMN status INT64;
UPDATE `project.dataset.table`
SET status = 0
WHERE status IS NULL;
※ パーティションテーブルの場合は、
必ず WHERE 句でパーティション条件を指定します。
パターン②：VIEW で論理的な DEFAULT を持たせる
BigQuery では この設計が王道です。
CREATE OR REPLACE VIEW `project.dataset.v_table` AS
SELECT
*,
IFNULL(status, 0) AS status
FROM `project.dataset.table`;
- 元テーブルはシンプルに保つ
- 値の補完ロジックは VIEW に寄せる
これにより、後続の BI やクエリも安全になります。
なぜ BigQuery はこういう仕様なのか
- BigQuery は、もともとスキーマ変更を頻繁に行う前提ではない
- 分析向け・追記型を想定
という思想で設計されています。
そのため、
- DDL は保守的
- DEFAULT の後付け不可
カラム順に意味を持たせないという仕様になっています。
RDB の感覚をそのまま持ち込むと確実にハマる理由はここにあります。
おわりに
BigQuery は非常に強力ですが、DDL 周りは 「できそうでできない」罠が多いです。
今回のように一度ハマって整理しておくと、
- 次から迷わない
- チーム内での事故を防げる
- 設計判断が早くなる
というメリットがあります。
同じようにハマっている方の助けになれば幸いです。