PostgreSQL NULL 判定のすべて！IS NULLから応用まで

はい、承知いたしました。PostgreSQLにおけるNULL判定について、IS NULLから応用までを網羅し、詳細な説明を含む約5000語の記事を記述します。

PostgreSQL NULL 判定のすべて！IS NULLから応用まで

リレーショナルデータベースを扱う上で、NULLという概念は避けて通れません。NULLは単なるゼロや空文字列ではなく、「値が存在しない」「不明」「適用不能」といった特殊な意味を持ちます。特にPostgreSQLでは、NULLの扱いがSQLクエリの結果やデータベースの設計に大きな影響を与えます。

本記事では、PostgreSQLにおけるNULLの基本的な概念から、最も基本的な判定方法であるIS NULL、NULLを含む比較や演算の特殊性、そしてNULLをより柔軟に扱うための様々な関数や応用テクニックに至るまで、NULL判定に関するすべてを詳細に解説します。約5000語というボリュームで、理論から実践、注意点まで網羅し、PostgreSQLでのNULLとの付き合い方を完全にマスターすることを目指します。

1. はじめに：データベースにおけるNULLの重要性

現実世界のデータをデータベースで表現する際、全ての情報が常に利用可能であるとは限りません。例えば、顧客の電話番号が未入力である、商品の価格がまだ決定していない、従業員の退職日が未定である、といった状況は頻繁に発生します。このような「値がない状態」を表現するために、データベースシステムではNULLという特別なマーカーが用意されています。

NULLは、数値のゼロ(0)とも、空文字列(”)とも、ブール値のFALSEとも異なります。これらは全て「存在する値」ですが、NULLは「値が存在しない」ことを示します。この違いが、NULLを扱う上で最も重要なポイントです。

PostgreSQLを含む多くのリレーショナルデータベースでは、NULLの存在は3値論理（True, False, Unknown）をもたらし、通常の比較演算子の挙動に影響を与えます。そのため、NULLを適切に識別し、処理するための特別な方法が必要になります。この記事では、その特別な方法を網羅的に見ていきましょう。

2. NULLの基本：値が存在しないとは？

2.1. NULLとは何か？その意味と他の値との違い

繰り返しますが、NULLは「値が存在しない」「不明」「未定義」「適用不能」といった状態を表すマーカーです。

NULL vs 0 (数値): 0は数値としての値であり、「量がゼロである」という明確な情報です。NULLは数値そのものが存在しない状態です。例えば、商品の在庫数が0であれば「在庫がゼロ個ある」という情報ですが、在庫数がNULLであれば「在庫数が不明である」という情報になります。
NULL vs 空文字列 (”) (文字列): 空文字列は長さゼロの文字列であり、これも「存在する値」です。NULLは文字列そのものが存在しない状態です。例えば、コメント欄が空文字列であれば「何も書かれていない」という情報ですが、コメント欄がNULLであれば「コメントが入力されていない（不明）」という情報になります。
NULL vs FALSE (ブール値): FALSEは論理的な偽という明確な値です。NULLは真偽が判定できない状態を表す可能性があります。

これらの違いを理解することは、NULL判定の第一歩です。NULLはデータ型の概念から独立した存在であり、数値型、文字列型、日付型、ブール型など、ほとんど全てのデータ型の列に格納される可能性があります（ただし、NOT NULL 制約が定義されている列は除きます）。

2.2. PostgreSQLにおけるNULLの扱い：3値論理

PostgreSQLを含む多くのSQLデータベースは、NULLの存在により、論理演算において真(TRUE)、偽(FALSE)に加えて未知(UNKNOWN)という3番目の状態を持つ3値論理を採用しています。

通常の比較演算子（=, <>, <, >, <=, >=）は、NULLを含むオペランドと比較されると、結果は必ずUNKNOWNになります。

例えば：

5 = NULL の結果は UNKNOWN
'abc' <> NULL の結果は UNKNOWN
NULL > 10 の結果は UNKNOWN
NULL = NULL の結果も UNKNOWN

これが非常に重要な点です。なぜなら、「NULLとNULLは等しい」と直感的に考えてしまうかもしれませんが、SQLの世界では「不明な値と不明な値を比較しても、それが等しいかどうかは不明である」と解釈されるためです。

このUNKNOWNという状態が、SQLクエリ、特に WHERE 句や JOIN 条件の挙動に影響を与えます。

3. 基本的なNULL判定：IS NULLとIS NOT NULL

NULLを含む比較演算の結果が常にUNKNOWNになるため、NULLであるかどうかを判定するために特別な構文が用意されています。それが IS NULL と IS NOT NULL です。

3.1. `IS NULL` の使い方

ある列の値がNULLであるかどうかを判定するには、IS NULL 構文を使用します。

構文：
sql expression IS NULL

この expression がNULLであれば結果はTRUE、NULLでなければ結果はFALSEになります。IS NULL は結果が必ずTRUEまたはFALSEのいずれかになり、UNKNOWNになることはありません。

例：products テーブルから価格が不明な製品を検索する。

“`sql
CREATE TABLE products (
product_id SERIAL PRIMARY KEY,
product_name VARCHAR(100),
price DECIMAL,
stock INTEGER
);

INSERT INTO products (product_name, price, stock) VALUES
(‘Widget A’, 100.00, 50),
(‘Gadget B’, NULL, 100),
(‘Gizmo C’, 200.00, NULL),
(‘Thingamajig D’, 300.00, 0),
(‘Doohickey E’, NULL, NULL);

— 価格がNULLの製品を検索
SELECT product_name, price, stock
FROM products
WHERE price IS NULL;
“`

3.2. `IS NOT NULL` の使い方

ある列の値がNULLではないかどうかを判定するには、IS NOT NULL 構文を使用します。

構文：
sql expression IS NOT NULL

この expression がNULLであれば結果はFALSE、NULLでなければ結果はTRUEになります。こちらも結果はTRUEまたはFALSEのいずれかです。

例：products テーブルから在庫数が明確な（NULLではない）製品を検索する。

sql -- 在庫数がNULLではない製品を検索 SELECT product_name, price, stock FROM products WHERE stock IS NOT NULL;

3.3. なぜ `expression = NULL` は機能しないのか？

ここで、多くのSQL初心者が陥りやすい間違いについて改めて説明します。なぜ WHERE price = NULL や WHERE stock <> NULL のようなクエリが期待通りに動作しないのでしょうか？

これは、先ほど説明した「NULLを含む比較の結果はUNKNOWNになる」というルールと、「WHERE 句は条件式がTRUEになる行のみを選択する」というルールの組み合わせによります。

WHERE 句の条件式が：

TRUE の場合：その行は結果セットに含まれます。
FALSE の場合：その行は結果セットから除外されます。
UNKNOWN の場合：その行は結果セットから除外されます。

つまり、WHERE 句にとっては UNKNOWN は FALSE と同様に扱われるのです。

したがって、WHERE price = NULL; というクエリを実行すると：

price が 100.00 の行： 100.00 = NULL -> UNKNOWN。この行は除外。
price が NULL の行： NULL = NULL -> UNKNOWN。この行も除外。

結果として、どの行も選択されず、空の結果セットが返されます。

同様に、WHERE price <> NULL; というクエリでも：

price が 100.00 の行： 100.00 <> NULL -> UNKNOWN。この行は除外。
price が NULL の行： NULL <> NULL -> UNKNOWN。この行も除外。

やはり結果は空になります。

したがって、NULLの判定は必ず IS NULL または IS NOT NULL を使う必要があります。これはSQLの基本的なルールであり、PostgreSQLに限らずほぼ全てのRDBMSで共通です。

4. NULLを含む比較と演算：UNKNOWNとNULLの伝播

NULLは比較や演算において特別な挙動を示します。これはNULLが単なる値ではなく、「不明」という状態を表すからです。このセクションでは、様々な種類の演算におけるNULLの挙動を見ていきます。

4.1. 比較演算子（`=`, `<`, `>`, `<>`, etc.）

前述の通り、NULLを含む比較演算の結果は常にUNKNOWNです。

例：
sql SELECT 5 = NULL AS five_eq_null, 'abc' <> NULL AS abc_ne_null, NULL > 10 AS null_gt_ten, NULL <= NULL AS null_le_null;

実行結果：
five_eq_null | abc_ne_null | null_gt_ten | null_le_null --------------+-------------+-------------+-------------- | | | (1 row)
NULLを含む比較結果は、PostgreSQLでは通常、特別なNULL表示（psqlコマンドラインツールでは空白）で表示されます。これはSQLレベルではUNKNOWNというブール値に評価されていることを意味します。これらの結果を WHERE 句で使うと、その行は選択されません。

4.2. 算術演算子（`+`, `-`, `*`, `/`, etc.）

NULLを含む算術演算の結果は、通常NULLになります。これはNULLが「不明な値」であるため、「不明な値との計算結果もまた不明である」と解釈されるからです。

例：
sql SELECT 10 + NULL AS sum_with_null, 50 * NULL AS product_with_null, NULL - 20 AS difference_with_null, 100 / NULL AS division_by_null;

実行結果：
sum_with_null | product_with_null | difference_with_null | division_by_null ---------------+-------------------+----------------------+------------------ | | | (1 row)
全ての演算結果がNULLになっています。NULLは算術演算において「感染性」を持つと言えます。

4.3. 文字列連結 (`||`)

PostgreSQLを含む一部のSQL方言では、文字列連結演算子 (||) を使用します。文字列連結にNULLが含まれる場合、結果はNULLになります。

例：
sql SELECT 'Hello' || ' World' AS normal_concat, 'Hello' || NULL AS concat_with_null, NULL || ' World' AS concat_null_with_string;

実行結果：
normal_concat | concat_with_null | concat_null_with_string ---------------+------------------+------------------------- Hello World | | (1 row)
concat_with_null と concat_null_with_string の結果がNULLになっています。
ただし、標準SQLの CONCAT() 関数など、NULLを無視して非NULL部分を連結する関数も存在します。PostgreSQLの CONCAT() 関数は複数の引数を取り、NULL以外の引数を連結しますが、すべての引数がNULLの場合はNULLを返します。

例：
sql SELECT CONCAT('Hello', ' ', 'World') AS normal_concat_func, CONCAT('Hello', NULL, 'World') AS concat_with_null_func, CONCAT(NULL, NULL) AS concat_only_nulls;
実行結果：
normal_concat_func | concat_with_null_func | concat_only_nulls --------------------+-----------------------+------------------- Hello World | HelloWorld | (1 row)
このように、PostgreSQLの CONCAT() 関数は || 演算子とは異なるNULLの扱いをします。どちらを使うかは、NULLをどのように扱いたいかによって適切に選択する必要があります。

4.4. 論理演算子（`AND`, `OR`, `NOT`）とUNKNOWN

3値論理の中心となるのが、論理演算におけるUNKNOWNの扱いです。真値表でその挙動を確認しましょう。

AND 演算子

A	B	A AND B
TRUE	TRUE	TRUE
TRUE	FALSE	FALSE
TRUE	UNKNOWN	UNKNOWN
FALSE	TRUE	FALSE
FALSE	FALSE	FALSE
FALSE	UNKNOWN	FALSE
UNKNOWN	TRUE	UNKNOWN
UNKNOWN	FALSE	FALSE
UNKNOWN	UNKNOWN	UNKNOWN

TRUE AND UNKNOWN は UNKNOWN です。「真であることは確定しているが、もう一つが不明なので、全体として真かどうかは不明」
FALSE AND UNKNOWN は FALSE です。「どちらか一つでも偽なら全体として偽が確定する」

OR 演算子

A	B	A OR B
TRUE	TRUE	TRUE
TRUE	FALSE	TRUE
TRUE	UNKNOWN	TRUE
FALSE	TRUE	TRUE
FALSE	FALSE	FALSE
FALSE	UNKNOWN	UNKNOWN
UNKNOWN	TRUE	TRUE
UNKNOWN	FALSE	UNKNOWN
UNKNOWN	UNKNOWN	UNKNOWN

TRUE OR UNKNOWN は TRUE です。「どちらか一つでも真なら全体として真が確定する」
FALSE OR UNKNOWN は UNKNOWN です。「真ではないことは確定しているが、もう一つが不明なので、全体として真かどうかは不明」

NOT 演算子

A	NOT A
TRUE	FALSE
FALSE	TRUE
UNKNOWN	UNKNOWN

NOT UNKNOWN は UNKNOWN です。「不明の否定はやはり不明」

これらの真値表は、特に複雑な WHERE 句や CASE 式でNULLを扱う場合に非常に重要になります。

4.5. `WHERE` 句、`JOIN` 条件でのNULLの挙動

再掲になりますが、WHERE 句は条件式がTRUEになる行のみを選択します。条件式がFALSEまたはUNKNOWNになる行は除外されます。この性質が、expression = NULL が期待通りに動かない根本的な理由です。

JOIN 条件 (ON 句) も同様に3値論理に従います。

内部結合 (INNER JOIN): ON 句の条件式がTRUEになる組み合わせの行だけが結果に含まれます。FALSEやUNKNOWNになる組み合わせは除外されます。したがって、結合キーの一方がNULLの場合、他方がNULLであろうとなかろうと、その組み合わせは NULL = value や NULL = NULL のような比較になり、結果はUNKNOWNとなるため、内部結合の結果には含まれません。
外部結合 (LEFT JOIN, RIGHT JOIN, FULL JOIN): 外部結合では、一致しない側の行はNULLで埋められます。例えば LEFT JOIN では、左テーブルの全ての行が結果に含まれ、対応する右テーブルの行がない場合は、右テーブルの列がNULLで埋められます。このNULLは結合条件が一致しなかった結果として発生するものであり、元のテーブルにNULLが格納されていた場合とは区別して理解する必要があります。

4.6. `GROUP BY`, `ORDER BY`, `DISTINCT` でのNULLの扱い

NULLは、GROUP BY, ORDER BY, DISTINCT といった操作において、他の非NULL値とは異なる特別扱いを受けることがあります。

GROUP BY: GROUP BY 句では、全てのNULL値は同じグループにまとめられます。つまり、column にNULL値を持つ全ての行は、一つのNULLグループとして扱われます。
ORDER BY: ORDER BY 句では、NULL値は非NULL値よりも前に来るか後ろに来るかが決まっています。PostgreSQLのデフォルトのソート順は以下の通りです。
- ASC (昇順): NULLs LAST (NULLは一番後ろ)
- DESC (降順): NULLs FIRST (NULLは一番前)
  このデフォルト順序は NULLS FIRST または NULLS LAST オプションを使って変更できます（後述）。
DISTINCT: SELECT DISTINCT column のように使用した場合、複数のNULL値は一つのNULL値として扱われます。結果セットには、その列のユニークな非NULL値と、もしNULLが存在するなら一つのNULL値が含まれます。

これらの挙動は標準SQLで定められているものとPostgreSQL独自の部分がありますが、NULLを「等しくない」「不明」と扱う比較演算とは異なり、GROUP BY や DISTINCT ではNULL同士を「同じもの」として扱う側面があることがわかります。ORDER BY も同様に、NULL値をまとめて扱います。

5. NULLを扱うための関数と演算子

NULLの特殊な性質に対処するため、PostgreSQLはいくつかの便利な関数や演算子を提供しています。これらを活用することで、NULLを含むデータを柔軟かつ安全に処理できます。

5.1. `COALESCE(value1, value2, ...)`

COALESCE 関数は、引数リストの最初の非NULL値を返します。全ての引数がNULLの場合はNULLを返します。

構文：
sql COALESCE(value1, value2 [, ...])
COALESCE は非常に頻繁に利用されます。NULL値を代替値に置き換えて表示したり、計算に使用したりする場合に便利です。

例1：表示目的でNULLを「不明」という文字列に置き換える

例2：計算目的でNULLをゼロに置き換える

sql -- 在庫数が不明な場合は在庫ゼロとみなして合計在庫を計算 SELECT SUM(COALESCE(stock, 0)) AS total_stock FROM products;
実行結果：
“`
total_stock

(1 row)
`` もしCOALESCEを使わずにSUM(stock)とすると、NULL値は合計から除外されます。SUM(stock)の結果は 100+50+0 = 150 となります。COALESCE(stock, 0)を使うことで、NULLを0として合計に含めることができます (50 + 100 + NULL(->0) + 0 + NULL(->0) = 150)。あれ、例がおかしい。 Widget A (50) + Gadget B (100) + Gizmo C (NULL -> 0) + Thingamajig D (0) + Doohickey E (NULL -> 0) SUM = 50 + 100 + 0 + 0 + 0 = 150. SELECT SUM(stock) FROM products; -- NULL無視なので 50 + 100 + 0 = 150 SELECT SUM(COALESCE(stock, 0)) FROM products; -- 50 + 100 + 0 + 0 + 0 = 150 この例ではSUM(stock)とSUM(COALESCE(stock, 0))の結果が同じになってしまいました。これはstock` 列がNULLでない行の合計がたまたま一致したためです。在庫がNULLの製品だけだった場合を考えます。

例2再考：在庫が不明な場合、計算にどう影響するか

“`sql
— products テーブルに以下の行を追加
INSERT INTO products (product_name, price, stock) VALUES
(‘NullStock A’, 400.00, NULL),
(‘NullStock B’, 500.00, NULL);

— SUM(stock) を計算
SELECT SUM(stock) FROM products;
— 結果: 50 + 100 + NULL + 0 + NULL + NULL + NULL = 150 (NULLは無視される)

— SUM(COALESCE(stock, 0)) を計算
SELECT SUM(COALESCE(stock, 0)) FROM products;
— 結果: 50 + 100 + 0 + 0 + 0 + 0 + 0 = 150 (NULLを0に置換してから合計)
`` やはり同じ結果になりました。なぜでしょうか？最初のデータセットで在庫がNULLでない行は Widget A (50), Gadget B (100), Thingamajig D (0) でした。これらを合計すると 50+100+0 = 150 です。新しいデータセットを追加しても、追加された行のstockは NULL です。SUM(stock)はNULLを無視するので、結果は変わりません。SUM(COALESCE(stock, 0))は、NULLを0に置き換えるので、元の行と追加された行のstock` はそれぞれ 50, 100, 0, 0, 0, 0, 0 となり、合計は 150 となります。

すみません、集計関数とNULLの挙動は後述のセクションで詳しく説明しますが、ここではCOALESCEの計算目的での利用例として、より適切な例を考えます。

例2再考2：NULLをゼロとみなして計算

「NULLをゼロとみなして計算」というシナリオとして、例えば「注文数量がNULLの場合は数量ゼロとして合計売上を計算する」というケースを考えます。

“`sql
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
product_id INTEGER,
quantity INTEGER — 注文数量。キャンセルなどでNULLになる可能性
);

INSERT INTO orders (product_id, quantity) VALUES
(1, 10),
(2, 5),
(1, NULL), — この注文は数量不明（キャンセル等）
(3, 20),
(2, NULL); — この注文も数量不明

— 全注文の合計数量を計算 (数量不明な注文を無視)
SELECT SUM(quantity) FROM orders;
— 結果: 10 + 5 + NULL + 20 + NULL = 35 (NULLは無視される)

— 全注文の合計数量を計算 (数量不明な注文を数量ゼロとみなす)
SELECT SUM(COALESCE(quantity, 0)) FROM orders;
— 結果: 10 + 5 + 0 + 20 + 0 = 35
`` またもや同じ結果に...。これはSUM関数がNULLを無視する性質のため、COALESCE` で0に置き換えても置き換えなくても、結果的に同じ合計になるケースがあるためです。

COALESCEが真価を発揮するのは、集計関数ではなく、個々の行レベルでNULLをデフォルト値に置き換えたい場合です。

例2再再考：各製品の在庫表示（NULLは「要確認」）と、それを元にした単純な計算（NULLはゼロ）

sql SELECT product_name, stock, COALESCE(stock::TEXT, '要確認') AS stock_display, COALESCE(stock, 0) AS stock_for_calculation FROM products;
実行結果：
product_name | stock | stock_display | stock_for_calculation ---------------+-------+---------------+----------------------- Widget A | 50 | 50 | 50 Gadget B | 100 | 100 | 100 Gizmo C | | 要確認 | 0 Thingamajig D | 0 | 0 | 0 Doohickey E | | 要確認 | 0 NullStock A | | 要確認 | 0 NullStock B | | 要確認 | 0 (7 rows)
このように、COALESCE はNULL値を異なるデフォルト値（文字列または数値）に置き換えるために効果的です。集計関数との組み合わせ方については、集計関数のセクションで改めて解説します。

5.2. `NULLIF(value1, value2)`

NULLIF 関数は、2つの引数を比較し、value1 と value2 が等しい場合にNULLを返し、等しくない場合に value1 を返します。

構文：
sql NULLIF(value1, value2)
この関数は、特定の値をNULLとして扱いたい場合に便利です。最も一般的な用途は、ゼロ除算の回避です。

例：分母がゼロの場合に計算をNULLにする

“`sql
— 製品の売上と販売数を記録するテーブル
CREATE TABLE sales (
sale_id SERIAL PRIMARY KEY,
product_id INTEGER,
amount DECIMAL, — 売上金額
quantity INTEGER — 販売数
);

INSERT INTO sales (product_id, amount, quantity) VALUES
(1, 1000.00, 10),
(2, 500.00, 5),
(3, 0.00, 0), — 販売数ゼロ
(4, 1200.00, 8),
(5, 800.00, 0); — 販売数ゼロ

— 平均価格を計算 (売上金額 / 販売数)
— 販売数ゼロの場合はゼロ除算エラーになる可能性がある
— SELECT amount / quantity AS average_price FROM sales; — quantityが0の行でエラー

— NULLIFを使って販売数ゼロをNULLに変換してから計算
SELECT amount / NULLIF(quantity, 0) AS average_price
FROM sales;
実行結果：
average_price

    100.00
    100.00
          | -- quantityが0なのでNULLIF(0,0)はNULLになり、amount/NULLはNULL
    150.00
          | -- quantityが0なのでNULLIF(0,0)はNULLになり、amount/NULLはNULL

(5 rows)
``NULLIF(quantity, 0)は、quantityが0の場合はNULLを返します。これにより、amount / NULLとなり、結果がNULLになることでゼロ除算エラーを回避しています。quantityが0でない場合は、quantity` そのものが返されるため、通常の計算が行われます。

他の用途としては、データ入力規則として「-1」や「9999」などの特定の値がNULLを意味する場合に、それらをDB内でNULLに変換するといった使い方も考えられます。

5.3. `GREATEST(value1, value2, ...)` / `LEAST(value1, value2, ...)`

これらの関数は、引数リスト中の最大値または最小値を返します。

構文：
sql GREATEST(value1, value2 [, ...]) LEAST(value1, value2 [, ...])
PostgreSQLにおけるこれらの関数の重要な挙動として、引数リストの中に一つでもNULL値が含まれる場合、結果はNULLになります。これはNULLが「不明な値」であるため、「不明な値が含まれるリストの中から最大値（または最小値）を特定することはできない」と解釈されるからです。

例：複数の数値列の中から最大値を求める

sql SELECT GREATEST(10, 20, 5, NULL) AS max_value_with_null; SELECT LEAST(10, 20, 5, NULL) AS min_value_with_null; SELECT GREATEST(10, 20, 5) AS max_value_without_null;
実行結果：
“`
max_value_with_null

                | -- NULLが含まれるため結果はNULL

(1 row)

min_value_with_null

                | -- NULLが含まれるため結果はNULL

(1 row)

max_value_without_null

(1 row)
`` NULLを無視して最大値/最小値を求めたい場合は、FILTER句（集計関数用）や、複数のCOALESCEをネストする、あるいはCASE式を使うなどの工夫が必要です。例えば、GREATEST(COALESCE(val1, -infinity), COALESCE(val2, -infinity), …)` のように、NULLを非常に小さい（または大きい）値に置き換えてから比較する方法が考えられます（ただし、適切な代替値はデータによって異なります）。

5.4. `NULLS FIRST` / `NULLS LAST`

ORDER BY 句でNULL値を非NULL値に対して先頭に配置するか末尾に配置するかを明示的に指定するためのオプションです。

構文：
sql ORDER BY column_name [ASC | DESC] [NULLS FIRST | NULLS LAST]
デフォルトの挙動は以下の通りです。
* ASC: NULLS LAST (昇順でNULLは末尾)
* DESC: NULLS FIRST (降順でNULLは先頭)

例：価格でソートする（昇順、降順、NULLの位置指定）

— 正しいデータ挿入と ORDER BY 例
— price が NULL の行: Gadget B, Doohickey E
— stock が NULL の行: Gizmo C, Doohickey E, NullStock A, NullStock B

5.5. `IS DISTINCT FROM` / `IS NOT DISTINCT FROM`

これらの演算子は、NULLを他のデータ値と同様に扱って比較を行います。通常の = や <> 演算子と異なり、NULLとの比較結果がUNKNOWNになることはありません。結果は必ずTRUEまたはFALSEになります。

A IS DISTINCT FROM B: AとBが異なる場合にTRUEを返します。ここでいう「異なる」とは、値が異なる場合と、一方がNULLでもう一方がNULLでない場合を含みます。NULLとNULLは異なるとはみなされません (NULL IS DISTINCT FROM NULL は FALSE)。
A IS NOT DISTINCT FROM B: AとBが異ならない場合にTRUEを返します。これはAとBが等しい場合と、両方ともNULLの場合を含みます。NULLとNULLは異ならないとみなされます (NULL IS NOT DISTINCT FROM NULL は TRUE)。

真値表：

A	B	A = B	A IS NULL	B IS NULL	A IS DISTINCT FROM B	A IS NOT DISTINCT FROM B
value1	value1	TRUE	FALSE	FALSE	FALSE	TRUE
value1	value2	FALSE	FALSE	FALSE	TRUE	FALSE
value1	NULL	UNKNOWN	FALSE	TRUE	TRUE	FALSE
NULL	value1	UNKNOWN	TRUE	FALSE	TRUE	FALSE
NULL	NULL	UNKNOWN	TRUE	TRUE	FALSE	TRUE

例：
“`sql
SELECT
10 IS DISTINCT FROM 20 AS ten_distinct_twenty,
10 IS DISTINCT FROM 10 AS ten_distinct_ten,
10 IS DISTINCT FROM NULL AS ten_distinct_null,
NULL IS DISTINCT FROM 10 AS null_distinct_ten,
NULL IS DISTINCT FROM NULL AS null_distinct_null;

SELECT
10 IS NOT DISTINCT FROM 20 AS ten_not_distinct_twenty,
10 IS NOT DISTINCT FROM 10 AS ten_not_distinct_ten,
10 IS NOT DISTINCT FROM NULL AS ten_not_distinct_null,
NULL IS NOT DISTINCT FROM 10 AS null_not_distinct_ten,
NULL IS NOT DISTINCT FROM NULL AS null_not_distinct_null;
実行結果：
ten_distinct_twenty | ten_distinct_ten | ten_distinct_null | null_distinct_ten | null_distinct_null
———————+——————+——————-+——————-+——————–
t | f | t | t | f
(1 row)

UNION DISTINCT: UNION DISTINCT は、結果セットから重複行を排除しますが、この「重複」の判定に IS NOT DISTINCT FROM と同等のロジックが使われます。つまり、全ての列の値が一致するか、全ての列の値がNULLであれば重複とみなされます。
UNIQUE 制約: PostgreSQLの UNIQUE 制約は、NULL値が複数存在することを許容します。これは、NULL IS DISTINCT FROM NULL が FALSE であるという IS DISTINCT FROM の定義に基づいているためです（ただし、標準SQLの UNIQUE 制約は IS NOT DISTINCT FROM を使用するため、PostgreSQLの挙動は標準とは異なります）。PostgreSQLでは、(col1 IS NOT DISTINCT FROM value1 AND col2 IS NOT DISTINCT FROM value2 AND ...) となる行の組み合わせが一意である必要があります。したがって、NULL IS NOT DISTINCT FROM NULL は TRUE なので、(NULL, NULL) のような組み合わせは1つしか許容されないように思えますが、PostgreSQLの UNIQUE 制約はNULL値を互いに等しいとはみなさない特別な挙動をします。これは少し混乱しやすい点ですが、PostgreSQLのドキュメントを確認すると、「UNIQUE制約はNULL値を含むタプルには一意性を強制しない。NULL値は互いに等しいとは見なされないからである。」と明確に記述されています。つまり、PostgreSQLの UNIQUE 制約におけるNULLの扱いは、IS DISTINCT FROM/IS NOT DISTINCT FROM の挙動とは少し異なります。PostgreSQLでは、UNIQUE制約が付けられた列に複数のNULLを格納できます。
データの差分検出: 2つのテーブルや同じテーブルの新旧バージョン間でデータの差分を確認する際に、NULLを通常の値と同様に比較したい場合に便利です。例えば、ある行の特定の列の値が変更されたかどうかを判定する場合、old_value IS NOT DISTINCT FROM new_value で判定できます。これがTRUEなら変更なし、FALSEなら変更ありと判断できます。通常の = 比較では、old_value がNULLで new_value もNULLだった場合に結果がUNKNOWNになり、変更なしと判断できません。

5.6. その他の関連関数

CASE 式: CASE WHEN expression IS NULL THEN ... ELSE ... END の形で、NULL値に基づいて条件分岐を行うことができます。これは非常に強力で柔軟な方法です。
集計関数: COUNT, SUM, AVG などの集計関数は、通常NULL値を無視して計算します。この挙動を理解し、必要に応じて COALESCE や他の関数と組み合わせて使用することが重要です（後述）。

6. 応用的なNULL判定と利用シーン

このセクションでは、実際のデータベース運用やクエリ開発においてNULL判定がどのように応用されるかを見ていきます。

6.1. 集計関数（COUNT, SUM, AVG, etc.）とNULL

集計関数は、NULL値をどのように扱うかという点で特別なルールを持っています。

COUNT(*): これは行数をカウントします。NULL値を含むかどうかに関わらず、対象となる全ての行の数を返します。
COUNT(column_name): これは指定した column_name の値がNULLではない行の数をカウントします。NULL値はカウントから除外されます。
SUM(column_name), AVG(column_name), MIN(column_name), MAX(column_name): これらの関数は、指定した column_name の値がNULLではない行の値のみを対象として計算を行います。NULL値は計算から単純に除外（スキップ）されます。対象となる全ての行の column_name がNULLだった場合、SUM と AVG はNULLを返し、MIN と MAX もNULLを返します。

例：製品テーブルを使った集計

SELECT
COUNT() AS total_rows,
COUNT(price) AS non_null_prices,
COUNT(stock) AS non_null_stocks,
SUM(price) AS total_price,
AVG(stock) AS average_stock
FROM products;
実行結果：
total_rows | non_null_prices | non_null_stocks | total_price | average_stock
————+—————–+—————–+————-+—————
7 | 5 | 3 | 1500.00 | 50.00000
(1 row)
`` 解説： *COUNT(): 全7行をカウントするので 7。 *COUNT(price): priceがNULLでない行 (Widget A, Gizmo C, Thingamajig D, NullStock A, NullStock B) は5つなので 5。 *COUNT(stock): stockがNULLでない行 (Widget A, Gadget B, Thingamajig D) は3つなので 3。 *SUM(price): priceがNULLでない行の合計 (100.00 + 200.00 + 300.00 + 400.00 + 500.00) は 1500.00。 *AVG(stock)`: stockがNULLでない行の平均 (50 + 100 + 0) / 3 = 150 / 3 = 50。

もしNULL値を集計に含めたい場合は、COALESCE などを使ってNULLを代替値に置き換えてから集計関数に渡します。

例：在庫不明をゼロとみなして平均在庫数を計算

sql SELECT AVG(COALESCE(stock, 0)) AS average_stock_incl_nulls FROM products;
実行結果：
“`
average_stock_incl_nulls

         21.42857142857

(1 row)
“`
解説：stock列の全ての値（50, 100, NULL, 0, NULL, NULL, NULL）に対して、NULLを0に置き換えると (50, 100, 0, 0, 0, 0, 0) となります。これらの合計は150、行数は7なので、平均は 150 / 7 ≈ 21.43 となります。

6.2. 条件式での利用 (`CASE` 文)

CASE 文はSQLで条件分岐を行うための強力なツールです。NULL判定も CASE 文の中で頻繁に使用されます。

構文：
sql CASE WHEN condition1 THEN result1 WHEN condition2 THEN result2 ... ELSE default_result END
CASE 文の各 WHEN 句の condition は、評価結果がTRUEのものを探します。condition がUNKNOWNの場合、その WHEN 句はスキップされます。

例：価格の状態を表示する

sql SELECT product_name, price, CASE WHEN price IS NULL THEN '価格未定' WHEN price = 0 THEN '無料' WHEN price > 0 THEN '有料' ELSE 'その他 (UNKNOWN?)' -- priceが数値型なので、実はここには来ない END AS price_status FROM products;
実行結果：
product_name | price | price_status ---------------+--------+----------------- Widget A | 100.00 | 有料 Gadget B | | 価格未定 Gizmo C | 200.00 | 有料 Thingamajig D | 300.00 | 有料 Doohickey E | | 価格未定 NullStock A | 400.00 | 有料 NullStock B | 500.00 | 有料 (7 rows)
WHEN price IS NULL THEN '価格未定' という条件が、価格がNULLの行に対してTRUEとなり、適切に処理されています。もしここで WHEN price = NULL THEN ... と書いてしまうと、その条件は常にUNKNOWNになるため、決してTRUEにならず、NULLの行は ELSE 句（あるいは ELSE がなければNULL）として扱われてしまいます。

6.3. 制約 (`NOT NULL` 制約, `UNIQUE` 制約)

NOT NULL 制約: 列定義時に NOT NULL を指定すると、その列にNULL値を挿入または更新しようとした場合にエラーが発生します。これはデータ品質を保証するために非常に重要です。可能な限り NOT NULL 制約を利用することが推奨されます。
sql CREATE TABLE users ( user_id SERIAL PRIMARY KEY, username VARCHAR(50) NOT NULL, -- ユーザー名は必須 email VARCHAR(100) UNIQUE, -- メールアドレスはユニークだがNULL可 registration_date DATE DEFAULT CURRENT_DATE NOT NULL -- 登録日は必須でデフォルト値あり );
INSERT INTO users (username, email) VALUES ('test_user', NULL); は成功しますが、INSERT INTO users (email) VALUES ('[email protected]'); は username が NOT NULL なのでエラーになります。
UNIQUE 制約: 前述の通り、PostgreSQLにおける UNIQUE 制約は、NULL値を含む列に対しては一意性を強制しません。つまり、UNIQUE 制約が付けられた列に複数のNULL値を格納することができます。これはPostgreSQLの独自仕様であり、標準SQLや他のDBMS（SQL Serverなど）ではNULLを一意とみなす（つまり、1つしかNULLを格納できない）場合があるため注意が必要です。
CREATE TABLE unique_test (col1 INTEGER UNIQUE);
INSERT INTO unique_test (col1) VALUES (1); — OK
INSERT INTO unique_test (col1) VALUES (1); — エラー (重複)
INSERT INTO unique_test (col1) VALUES (NULL); — OK
INSERT INTO unique_test (col1) VALUES (NULL); — OK (PostgreSQLではNULLは複数可)

6.4. インデックスとNULL

PostgreSQLでは、B-treeインデックスを含む多くの種類のインデックスがNULL値を格納できます。これは、WHERE column IS NULL や WHERE column IS NOT NULL といった条件を含むクエリのパフォーマンスを向上させるために役立ちます。

例えば、頻繁に WHERE status IS NULL のようなクエリを実行する場合、status 列にインデックスがあると検索が高速化される可能性があります。

また、PostgreSQLでは部分インデックス (Partial Index) を作成することも可能です。これはテーブルの一部の行のみにインデックスを作成する機能です。WHERE 句を使ってインデックスの対象行を制限します。これは、特定の条件を満たす行（例えば、NULLではない行）だけを対象とする場合に有効です。

例：ステータスがNULLではない行にのみインデックスを作成

sql CREATE INDEX my_table_status_idx ON my_table (status) WHERE status IS NOT NULL;
このようなインデックスは、WHERE status = 'Active' や WHERE status <> 'Inactive' のように、status がNULLではないことを前提としたクエリで有効に利用されます。これにより、NULLが多いテーブルで、NULL以外の値に対する検索を効率化できます。

6.5. パフォーマンス考慮事項

NULLが多い列へのインデックス: NULLが多い列に対して通常のB-treeインデックスを作成すると、インデックスサイズが大きくなる可能性があります。WHERE column IS NOT NULL を頻繁に使う場合は、前述の部分インデックスが有効な戦略となり得ます。
IS NULL / IS NOT NULL の選択性: WHERE column IS NULL や WHERE column IS NOT NULL の条件は、その列にNULL値がどれくらい存在するかに応じて選択性が変わります。統計情報が最新であれば、PostgreSQLのクエリオプティマイザはこれらの条件のコストを正確に見積もり、適切な実行計画を選択します。
関数の利用: COALESCE や NULLIF などの関数を WHERE 句や JOIN 条件の右辺（またはインデックス付き列ではない方）で使用することは、通常インデックスの利用を妨げません。しかし、WHERE COALESCE(column, default_value) = some_value のように、インデックスを付けたい列自体に関数を適用すると、インデックスが利用されない可能性が高くなります。この場合は、関数インデックス (CREATE INDEX ... ON table_name (COALESCE(column, default_value));) を作成することも検討できますが、これはストレージとメンテナンスのコストが増加します。

6.6. データ移行・ETLにおけるNULLの扱い

異なるシステム間でデータを連携したり、データを抽出・変換・ロード（ETL）する際には、NULLの扱いが重要な課題となります。

ソースシステムの空値/特定値: ソースシステムで「未入力」が空文字列や特定のマーカー値（例: -1, ‘N/A’）で表現されている場合、ターゲットのPostgreSQLデータベースにロードする際にこれらを適切にNULLに変換する必要があります。CASE 文や NULLIF 関数が役立ちます。
NULLのデフォルト値: ターゲットシステムでNULLを許容しない列にデータをロードする場合、ソースがNULLの行に対して代替となるデフォルト値を指定する必要があります。COALESCE 関数が効果的です。
データ品質: ETLプロセス中に、NULLの許容/非許容ルールに反するデータがないかチェックすることも重要です。

6.7. プログラミング言語からのNULLの扱い

アプリケーション開発でPostgreSQLと連携する場合、SQLのNULLとプログラミング言語のNULL（あるいはnil, Noneなど）とのマッピングを理解しておく必要があります。

マッピング: 通常、DBのNULLはプログラミング言語のNULL/nil/Noneに対応付けられます。しかし、言語によっては数値型のNULLをゼロ、文字列型のNULLを空文字列に自動変換してしまうような、予期しない挙動をすることがあります。使用しているDBドライバやORMのドキュメントを確認し、NULLがどのように扱われるかを理解しておくことが重要です。
NULLチェック: アプリケーションコード側でも、DBから取得した値がNULLである可能性がある場合は、必ずNULLチェックを行う必要があります。DB側で COALESCE を使ってNULLを代替値に置き換えてからアプリケーションに渡すことで、アプリケーション側のNULLチェックのコードを簡略化できる場合もありますが、NULLであるという元の情報を失う可能性も考慮が必要です。
NULL vs 空文字列: プログラミング言語によってはNULLと空文字列の区別が曖昧な場合があります。SQLではこれらは明確に異なるため、連携時には注意が必要です。特に文字列型の列でNULLと空文字列が混在している場合、アプリケーション側で両方を適切にハンドリングする必要があります。

7. 注意点とベストプラクティス

NULLは「不明」を意味することを常に意識する: NULLをゼロや空文字列と混同しないことが、NULL関連のバグを防ぐための最も基本的な心構えです。
可能な限り NOT NULL 制約を利用する: データモデル設計時、その情報が「必須」であれば必ず NOT NULL 制約をつけましょう。これにより、不要なNULLの発生を防ぎ、データ品質を向上させ、クエリをシンプルに保つことができます。NULLを許容すると、その列を扱う全てのクエリでNULLの可能性を考慮する必要が生じ、複雑さが増します。
NULL許容設計のトレードオフ: NULL許容設計は、データ入力の柔軟性を高める一方で、クエリやアプリケーションコードの複雑性を増大させます。NOT NULL設計はデータ品質とクエリのシンプルさを向上させる一方、データの入力時に全ての必須情報が揃っている必要があります。どちらを採用するかは、要件とトレードオフを考慮して慎重に判断する必要があります。
NULLを含む可能性のある式を扱う際は細心の注意を払う: 比較演算子や算術演算子、文字列連結演算子などでNULLが含まれると、結果がUNKNOWNやNULLになり、予期しない結果を招くことがあります。IS NULL, IS NOT NULL, COALESCE, NULLIF などのNULL対応関数・演算子を適切に使用しましょう。
集計関数のNULLの扱いを理解する: COUNT(*) と COUNT(column) の違い、SUM, AVG などがNULLを無視する挙動を理解し、意図した通りの集計結果が得られるようにクエリを作成しましょう。
CASE 文でNULL条件を扱う際は IS NULL を使う: CASE WHEN column IS NULL THEN ... のように IS NULL を使い、WHEN column = NULL THEN ... としないように注意しましょう。
PostgreSQL独自のNULLに関する挙動（特にUNIQUE制約）を把握しておく: 標準SQLとの違いを理解し、移植性や予期せぬ挙動に備えましょう。
パフォーマンスを考慮したNULLの扱い: NULL値が多い列に対するインデックス戦略（部分インデックスなど）や、関数利用によるインデックス利用への影響を考慮してクエリやインデックス設計を行いましょう。
アプリケーション層とデータベース層でのNULL扱いの整合性を保つ: データベースとアプリケーションの間で、NULLの解釈やマッピングに齟齬がないように設計・実装しましょう。

8. まとめ

PostgreSQLにおけるNULLは、「値が存在しない」という特殊な状態を表すマーカーであり、3値論理をもたらし、比較や演算において特別な挙動を示します。

NULLの判定には、標準的な IS NULL および IS NOT NULL 演算子を必ず使用する必要があります。これは、NULLを含む通常の比較演算の結果がUNKNOWNとなり、WHERE 句などがUNKNOWNをFALSEと同様に扱うためです。

PostgreSQLは、NULLを柔軟に、または安全に扱うための様々な機能を提供しています。COALESCE はNULLを代替値に置き換え、NULLIF は特定の値と等しい場合にNULLを返します。IS DISTINCT FROM / IS NOT DISTINCT FROM はNULLを値として扱った比較を可能にします。NULLS FIRST / NULLS LAST はソート順におけるNULLの位置を制御します。また、集計関数はデフォルトでNULLを無視する挙動を持ちます。

これらの関数や演算子、そしてNULLを含む比較・演算・論理演算のルールを深く理解することは、PostgreSQLで正確かつ効率的なクエリを作成するために不可欠です。さらに、NOT NULL 制約の適切な利用、インデックス戦略、アプリケーション連携におけるNULLの考慮など、データベース設計・運用の各フェーズでNULLの存在を意識することが重要です。

NULLは一見単純な概念ですが、その挙動は奥深く、適切に扱わないと予期せぬ結果やバグの原因となります。本記事で解説したNULL判定の基本から応用までのすべてを習得し、PostgreSQLでの開発や運用に役立てていただければ幸いです。NULLと上手に付き合い、堅牢で信頼性の高いデータベースシステムを構築しましょう。