SQLでカラムを安全に追加する方法｜ALTER TABLE ADDの設計・本番運用完全ガイド

「カラム追加、簡単そうで実は怖い」と感じていませんか？

「既存テーブルに項目を1つ追加したいだけなのに、なぜか不安になる」

SQLを触るエンジニアなら、一度はそんな感覚を持ったことがあるはずです。

• ALTER TABLE ADDって書くだけで本当に大丈夫？
• 既存データはどうなる？
• 本番でロックはかからない？
• NOT NULLやDEFAULTはどのタイミングで付けるべき？

カラム追加はSQLの中でも最も“事故が起きやすいDDL”の1つです。
手順を誤ると、アプリ停止・長時間ロック・データ不整合といった深刻な障害につながります。

この記事では、

• ALTER TABLE ADD の基本構文
• DEFAULT / NOT NULL の正しい使い方
• 複数カラム追加・順序指定の実務判断
• MySQL / PostgreSQL / Oracle / SQL Server の違い
• 本番運用で失敗しないための設計・実行手順

までを体系的に解説します。

「動くSQL」ではなく「安全に運用できるSQL」を書けるようになる
それがこの記事のゴールです。

ALTER TABLE ADDとは？SQLでカラムを追加する基本

ALTER TABLE ADD は、既存テーブルに新しいカラム（列）を追加するためのSQLです。
多くのRDBMSで共通して使えるDDL文で、テーブル定義を変更する際の基本操作になります。

ALTER TABLE ADD の最小構文

ALTER TABLE テーブル名 ADD カラム名 データ型;

この構文だけで、カラム自体は追加できます。
ただし実務では、データ型・NULL可否・DEFAULTまで含めて設計することがほとんどです。

カラム追加時に設計すべきポイント

カラムを追加する前に、最低限以下は整理しておく必要があります。

• データ型は将来の拡張に耐えられるか
• NULL を許可するか
• 既存行にはどんな値が入るのか
• 後から NOT NULL や制約を付ける予定はあるか
• インデックス追加の可能性はあるか

特にデータ型とNULL設計は後から変更コストが高くなりがちです。
DDLを書く前に、軽くでも設計レビューを挟むのが実務的です。

単一カラムを追加する基本例

もっともシンプルな例

ALTER TABLE users ADD age INT;

この場合、

• 既存行の age はすべて NULL
• アプリが NULL を許容できるかの確認が必須

になります。

DEFAULT と NOT NULL を同時に指定する場合

ALTER TABLE users ADD age INT NOT NULL DEFAULT 0;

この場合、

• 既存行には自動的に 0 が入る
• 新規 INSERT でも値未指定時は 0

となります。

「0が未設定を意味するのか」「本当に妥当な値か」は
ビジネスロジックとセットで必ず確認してください。

実行後に必ず確認すべきポイント

DDL実行後は、必ず定義を確認します。

• 型は想定どおりか
• NOT NULL / DEFAULT は正しく付いているか
• DBや環境差で挙動が変わっていないか

例（MySQL）

SHOW COLUMNS FROM users;

例（PostgreSQL）

\d users

この確認を省略すると、本番で静かに事故が進行するケースが非常に多いです。

複数カラムを一括で追加する方法と判断基準

変更回数を減らしたい場合、複数カラムをまとめて追加できます。

ALTER TABLE users
ADD age INT,
ADD birthday DATE;

一括追加のメリット

• DDL回数が減る
• レビュー・手順書が簡潔になる
• 運用工数が下がる

注意点

• 失敗時の切り分けが難しい
• 重い変更（NOT NULL・DEFAULT付き）を混ぜると危険

本番では「軽い変更」と「影響が大きい変更」を分けるのが鉄則です。

カラムの順序を指定したい場合の考え方

MySQLの場合

ALTER TABLE users ADD age INT AFTER name;

ALTER TABLE users ADD id INT FIRST;

順序指定できないDB（PostgreSQL / Oracle など）

• SQLで物理的な順序は変更不可
• 原則「カラム順に依存しない設計」が前提

順序が必要な場合の代替策

• VIEW で列順を制御する
• SELECT で明示的に列挙する
• CSV出力専用SQLを用意する

列順依存は技術的負債になりやすい設計です。

DEFAULTを設定して追加する際の実務判断

DEFAULT は移行を楽にする反面、落とし穴もあります。

DEFAULT のメリット

• 新規INSERT時の値漏れ防止
• アプリ改修を段階的に進められる

DEFAULT のリスク

• 未設定データに気づきにくい
• 集計や判定ロジックが歪む可能性

「未設定」と「意味のある値」を混同しない設計が重要です。
迷ったら、NULL許可 → 後から埋める、が安全な選択です。

NOT NULL制約を安全に追加する手順

既存データがあるテーブルで、
いきなり NOT NULL を付けるのは非常に危険です。

安全な定石手順

1. NULL許可でカラム追加

2. UPDATEで既存行を段階的に埋める

3. データ確認

4. NOT NULL 制約を追加

ALTER TABLE users ADD age INT;
UPDATE users SET age = 0 WHERE age IS NULL;
ALTER TABLE users ALTER COLUMN age SET NOT NULL;

この手順を踏むだけで、事故率は大きく下がります。

DB別｜ALTER TABLE ADD の違いと注意点

MySQL

• AFTER / FIRST で順序指定可能
• 変更内容によってはテーブル再構築
• オンラインDDLの可否確認が必須
  
  公式：https://dev.mysql.com/doc/

PostgreSQL

• 常に末尾追加
• 列順依存しない設計が前提
• DEFAULT / 制約の追加タイミングに注意
  
  公式：https://www.postgresql.org/docs/

Oracle

• 基本は末尾追加
• メンテナンスウィンドウ設計が重要
  
  公式：https://docs.oracle.com/

SQL Server

• DEFAULT制約が別オブジェクト扱いの場合あり
• ツール依存の挙動差に注意

公式：https://learn.microsoft.com/sql/

どのDBでも「開発環境で動いた＝本番で安全」ではありません。

本番環境でカラム追加する際の注意点

既存データ・アプリ影響

• NULL前提でアプリは動くか
• ORMやマッピング定義に影響はないか
• SELECT * に依存していないか

ロック・実行時間

• DDLは短時間でもメタデータロックを取る
• トラフィックの少ない時間帯を選ぶ
• 実行前後の疎通確認を必ず行う

失敗時の戻し方

• DROP COLUMN できる前提か
• 途中で止めても成立する手順か
• 「追加 → 改修 → 移行 → 制約」の分割設計

DDLは“実行”より“設計”が8割です。

まとめ｜ALTER TABLE ADDを安全に使いこなすために

• カラム追加の基本は ALTER TABLE ADD
• DEFAULT / NOT NULL は既存データを考慮して設計する
• DBごとの差分を理解する
• 本番ではロック・戻し方まで含めて計画する

SQLは書けても、
「安全に運用できるDDLを書けるエンジニア」は意外と多くありません。

技術を深く考え、設計から向き合いたいエンジニアへ

ここまで読んでくださったあなたは、

単なるSQLの書き方ではなく、

• なぜその手順が安全なのか
• なぜ事故が起きるのか
• どう設計すれば防げるのか

を考えるエンジニアだと思います。

私たちは、
こうした“技術の背景まで理解しようとする姿勢”を何より大切にするチームです。

もし、

• DB設計や運用をもっと深めたい
• 本番を意識した技術に向き合いたい
• 同じ目線で議論できる仲間と働きたい

そう感じたなら、
ぜひ一度、私たちのエンジニア採用ページを覗いてみてください。

技術を大切にする環境で、
次は一緒に「安全な設計」を考えられたら嬉しいです。