PostgreSQL ANY演算子とは？使い方を徹底解説

---

PostgreSQL ANY演算子とは？使い方を徹底解説

はじめに

リレーショナルデータベースを操作する上で、特定の条件に合致するデータを選択することは基本的な操作です。単一の値との比較はもちろん、複数の候補値のいずれかに合致するかどうかを判定したい場面は頻繁に発生します。PostgreSQLを含む多くのSQLデータベースでは、このような「いずれかに一致する」という条件を指定するために、いくつかの方法が提供されています。その中でも特に強力で柔軟なのが、ANY演算子です。

ANY演算子は、ある値がサブクエリの結果セットや配列の要素の「いずれか」と比較演算子を満たすかどうかを判定するために使用されます。これにより、複数の OR 条件を列挙する必要がなくなり、クエリの可読性が向上し、多くの場合でより効率的な記述が可能になります。特に、PostgreSQLが得意とする配列型と組み合わせることで、その真価を発揮します。

この記事では、PostgreSQLにおけるANY演算子に焦点を当て、その基本的な使い方から、他の関連する演算子（IN, ALL, EXISTSなど）との比較、サブクエリや配列との連携、具体的な使用例、そしてパフォーマンスに関する注意点や最適化方法まで、徹底的に解説します。この記事を読むことで、ANY演算子の強力な機能を理解し、自身のデータベース操作において効果的に活用できるようになるでしょう。

ANY演算子の基本

ANY演算子は、左辺の単一の値と、右辺のサブクエリの結果セットまたは配列の「いずれか」の要素を、指定された比較演算子を用いて比較し、真偽値を返します。

基本的な構文は以下のようになります。

sql
expression comparison_operator ANY (subquery_or_array)

• expression: 比較対象となる単一の値（カラム名、リテラル、式など）。
• comparison_operator: 使用する比較演算子（ =, <, >, <=, >=, != など）。
• subquery_or_array: サブクエリ（単一列を返すもの）または配列。

ANY演算子を用いた比較 expression comparison_operator ANY (subquery_or_array) は、右辺の subquery_or_array が返すそれぞれの要素 e に対して expression comparison_operator e を評価し、その結果が少なくとも一つでも真になれば、クエリ全体の条件は真となります。もし右辺が空集合または空配列だった場合、ANY演算子を使った比較は常に偽を返します（ただし、NULLの扱いには注意が必要です。これについては後述します）。

比較演算子との組み合わせ

ANY演算子は、様々な比較演算子と組み合わせて使用できます。代表的な組み合わせをいくつか見てみましょう。

• = ANY (subquery_or_array): 左辺の値が、右辺のいずれかの要素と等しい場合に真となります。
• != ANY (subquery_or_array): 左辺の値が、右辺のいずれかの要素と等しくない場合に真となります。これは、左辺の値が右辺のすべての要素と等しいわけではない、という意味になります。例えば、value != ANY ('{1, 2, 3}') は、value が 1, 2, 3 のどれか一つでも等しくなければ真となります。つまり、value が 1, 2, 3 の中に含まれていない（value NOT IN (1, 2, 3)）ではありません。value = 1 であっても、value != 2 や value != 3 が真になるため、value != ANY ('{1, 2, 3}') は真になります。この挙動は直感と異なる場合があるので注意が必要です。後述の「注意点」で詳しく解説します。
• < ANY (subquery_or_array): 左辺の値が、右辺のいずれかの要素よりも小さい場合に真となります。つまり、左辺の値が右辺の要素の最大値よりも小さい場合に真となります（ただし、右辺にNULLが含まれる場合は異なります）。
• > ANY (subquery_or_array): 左辺の値が、右辺のいずれかの要素よりも大きい場合に真となります。つまり、左辺の値が右辺の要素の最小値よりも大きい場合に真となります（ただし、右辺にNULLが含まれる場合は異なります）。
• <= ANY (subquery_or_array): 左辺の値が、右辺のいずれかの要素以下である場合に真となります。
• >= ANY (subquery_or_array): 左辺の値が、右辺のいずれかの要素以上である場合に真となります。

サブクエリでの例

products テーブルと popular_categories テーブルがあるとします。popular_categories テーブルには、人気のあるカテゴリのIDリストが含まれています。人気のあるカテゴリに属するすべての商品を選択したい場合、ANY演算子を使用できます。

“`sql
— popular_categories テーブルの例
— category_id

---

— 101
— 105
— 203

— products テーブルの例
— product_id | product_name | category_id
— ———–|————–|————
— 1 | Apple | 101
— 2 | Banana | 102
— 3 | Cherry | 105
— 4 | Date | 201
— 5 | Elderberry | 203

SELECT product_name
FROM products
WHERE category_id = ANY (SELECT category_id FROM popular_categories);
“`

このクエリは、products テーブルから、category_id が popular_categories テーブルのサブクエリが返す category_id リストのいずれかに一致する行を選択します。結果は Apple, Cherry, Elderberry となります。

配列での例

PostgreSQLは配列型をネイティブにサポートしており、ANY演算子と配列を組み合わせて使用することは非常に一般的で強力なパターンです。

例えば、ユーザーが好むタグのリストを配列として users テーブルに持っているとします。また、各アイテムが持つタグのリストを items テーブルに持っているとします。ユーザーが好むタグのいずれかに合致するタグを持つアイテムを検索したい場合、ANY演算子と配列を組み合わせて使用できます。

“`sql
— items テーブルの例
— item_id | item_name | tags (TEXT[])
— ——–|———–|————–
— 101 | Book A | {‘fiction’, ‘mystery’}
— 102 | Book B | {‘science’, ‘education’}
— 103 | Book C | {‘mystery’, ‘thriller’}
— 104 | Book D | {‘fiction’, ‘romance’}

— user_preferences テーブルの例
— user_id | preferred_tags (TEXT[])
— ——–|——————
— 1 | {‘mystery’, ‘thriller’, ‘scifi’}

— 特定のユーザー (user_id = 1) が好むタグを持つアイテムを検索
SELECT item_name
FROM items
WHERE EXISTS (
SELECT 1
FROM unnest(items.tags) AS item_tag, unnest((SELECT preferred_tags FROM user_preferences WHERE user_id = 1)) AS preferred_tag
WHERE item_tag = preferred_tag
);

— これは複雑なので、ANY + 配列で書き直すと…

SELECT item_name
FROM items
WHERE EXISTS (
SELECT 1
FROM unnest(items.tags) AS item_tag
WHERE item_tag = ANY ((SELECT preferred_tags FROM user_preferences WHERE user_id = 1))
);

— さらに、PostgreSQLでは配列同士のANY比較をより簡潔に記述できます。
— array_element = ANY (other_array) の形式

SELECT item_name
FROM items
WHERE ANY (items.tags) = ANY ((SELECT preferred_tags FROM user_preferences WHERE user_id = 1)); — この構文は間違い。正しくは下の形式。

— 正しい ANY + 配列の比較形式:
— ある配列のいずれかの要素が、別の配列のいずれかの要素と比較演算子を満たすか？
— これは ANY(array1) operator ANY(array2) とは書けず、通常は UNNEST を使うか、
— 要素 対 配列 の比較をループ的に行う（SQLではJOINやEXISTS/ANY with UNNEST）。

— より簡単なシナリオとして、「アイテムのタグ配列のいずれかの要素が、特定のタグ名リスト（配列リテラル）のいずれかの要素と一致するか？」
— これは、'some_tag' = ANY(items.tags) を複数のタグに対してORで繋ぐのと同じ。
— ANY + 配列の典型的な使い方は「スカラー値 = ANY(配列)」または「配列の要素 = ANY(スカラー値のリスト/配列)」

— 例: アイテムのタグに ‘mystery’ または ‘thriller’ が含まれているアイテム
SELECT item_name
FROM items
WHERE ‘mystery’ = ANY(tags) OR ‘thriller’ = ANY(tags);

— このOR条件は、ANYを使ってスカラー値のリスト/配列と比較することで簡潔にできる。
SELECT item_name
FROM items
WHERE ANY(tags) = ANY(ARRAY[‘mystery’, ‘thriller’]); — この構文も間違い。

— 正しい構文:
— アイテムのタグ配列のいずれかの要素が、指定した配列に含まれているか？
— これは element = ANY(array) または array operator element (using @> <@ operators) を使う。
— ここでは、アイテムのタグ配列 items.tags の要素が、ユーザーの好むタグ配列 preferred_tags のいずれかに一致するかを見たい。

— 方法1: UNNESTとEXISTS/ANYを使う (前述の例)
SELECT item_name
FROM items
WHERE EXISTS (
SELECT 1
FROM unnest(items.tags) AS item_tag
WHERE item_tag = ANY ((SELECT preferred_tags FROM user_preferences WHERE user_id = 1))
);

— 方法2: 配列演算子を使う – これは ANY とは少し異なりますが、関連するため言及
— @> 演算子: 左辺の配列が右辺の配列のすべての要素を含むか (superset)
— <@ 演算子: 左辺の配列が右辺の配列のいずれかの要素に含まれるか (subset)
— && 演算子: 左辺の配列と右辺の配列が共通の要素を持つか (overlap) – これがANYの用途に近い

SELECT item_name
FROM items
WHERE tags && (SELECT preferred_tags FROM user_preferences WHERE user_id = 1);

— tags && preferred_tags は、tags 配列の要素が preferred_tags 配列のいずれかの要素と等しい場合に真となります。
— これは element = ANY(array) を両方の配列にわたって行うこととほぼ同じ結果になります。
— ただし、NULLの扱いやパフォーマンスは異なります。
— 通常、配列間の「いずれかの要素の一致」には && 演算子が推奨されます。

— さて、ANY + 配列の話に戻りましょう。
— ANYと配列を組み合わせる最も典型的なケースは、
— 「スカラー値 expression が、配列 array のいずれかの要素と比較演算子を満たすか？」です。
— 例: 特定のタグ (‘mystery’) を持つアイテムを検索
SELECT item_name
FROM items
WHERE ‘mystery’ = ANY(tags); — これが最も基本的な ANY + 配列の使い方

— 例: アイテムのタグ配列 tags のいずれかの要素が ‘mystery’ または ‘thriller’ か？
— この場合、右辺は配列リテラルになります。
SELECT item_name
FROM items
WHERE ANY(tags) = ANY(ARRAY[‘mystery’, ‘thriller’]); — 再度ですが、この構文は間違いです。ANY(array) は集約関数ではありません。

— 正しい ANY + 配列の使い方（右辺が配列の場合）は、
— 左辺が単一のスカラー値である必要があります。
— 例: 特定のアイテムが、ユーザーの好むタグ配列のいずれかのタグを持っているか？
— (アイテムは一つだけ。そのアイテムのタグ配列 item_tags を想定)
— WHERE ‘some_tag_from_item’ = ANY(user_preferred_tags_array)
— これは、'fiction' = ANY(ARRAY['mystery', 'thriller', 'scifi']) のように、特定のタグがユーザーの好みに含まれているかを確認する構文です。

— アイテム検索の例に戻ります。
— アイテムのタグ配列 items.tags のいずれかの要素が、ユーザーの好むタグ配列 preferred_tags のいずれかの要素に一致するか？
— これは結局、UNNEST と element = ANY(array) を組み合わせるか、&& 演算子を使うのが最も一般的です。
— もしユーザーの好むタグリストがサブクエリで取得される場合、それは単一の配列値として扱われます。
SELECT item_name
FROM items
WHERE EXISTS (
SELECT 1
FROM unnest(items.tags) AS item_tag
WHERE item_tag = ANY ((SELECT preferred_tags FROM user_preferences WHERE user_id = 1))
);

— あるいは、ユーザーの好むタグリストが固定の配列リテラルである場合
SELECT item_name
FROM items
WHERE EXISTS (
SELECT 1
FROM unnest(items.tags) AS item_tag
WHERE item_tag = ANY (ARRAY[‘mystery’, ‘thriller’, ‘scifi’])
);

— これらは tags && ARRAY['mystery', 'thriller', 'scifi'] と等価です。

ANY + 配列の基本的な使い方は、「スカラー値 expression が配列 array のいずれかの要素と比較演算子を満たすか？」です。
例:
– 'apple' = ANY(string_array_column)
– 42 > ANY(integer_array_column)
– '2023-01-01'::date < ANY(date_array_column)

この基本的な形を理解することが重要です。右辺が配列の場合、左辺は単一のスカラー値です。

サブクエリの場合も同様に、右辺のサブクエリは単一列を返す必要があり、その列の各行が比較対象の「いずれかの要素」となります。左辺は単一のスカラー値です。

ANY演算子 vs その他の比較方法

ANY演算子は「いずれかに一致する」という条件を表現する際に便利ですが、他にも同様の目的で使用できる演算子や構文があります。ここでは、ANYとよく比較されるIN、ALL、EXISTS、ORといった他の手法との違いや使い分けについて解説します。

ANY vs IN

最も一般的な比較は、= ANY (subquery_or_array) と IN (subquery) または IN (value1, value2, ...) です。

実際、SQL標準において IN (subquery) は = ANY (subquery) の糖衣構文（シンタックスシュガー）として定義されています。つまり、value IN (SELECT column FROM table WHERE ...) は value = ANY (SELECT column FROM table WHERE ...) と全く同じ意味であり、PostgreSQLを含む多くのデータベースシステムでは内部的にも同じように扱われます。

また、PostgreSQLでは value IN (value1, value2, ...) というリスト形式のINもサポートしていますが、これも value = ANY (ARRAY[value1, value2, ...]) と等価です。

したがって、= 演算子と組み合わせる場合、= ANY と IN は機能的に全く同じです。どちらを使うかは、個人の好みやチームのコーディング規約によります。ただし、INはリスト形式でも使えるため、固定値リストとの比較ではINの方が一般的かもしれません。

しかし、ANY演算子の強みは、= 以外の比較演算子 (<, >, != など) とも組み合わせられる点です。IN演算子は基本的に等価比較 (=) のみに使用されます。

例：
* 人気カテゴリに属する商品 (= ANY または IN)
sql
SELECT product_name FROM products WHERE category_id = ANY (SELECT category_id FROM popular_categories);
-- または
SELECT product_name FROM products WHERE category_id IN (SELECT category_id FROM popular_categories);
どちらも同じ結果になります。

• 価格が特定の価格リストのいずれかより高い商品 (> ANY)
  sql
-- 例えば、価格リスト {50, 100, 200}
-- 価格が50より大きい、または100より大きい、または200より大きい商品
-- つまり、価格がリストの最小値(50)より大きい商品
SELECT product_name FROM products WHERE price > ANY (ARRAY[50, 100, 200]);
  このような条件はINでは直接表現できません。ORを使って price > 50 OR price > 100 OR price > 200 と書くことはできますが、ANYを使った方が簡潔です。

結論として、等価比較の場合はINと= ANYは等価であり、好みで選べます。しかし、その他の比較演算子を使う場合はANYが必須となります。

ANY vs SOME

SQL標準では、SOME は ANY のシノニムとして定義されています。PostgreSQLもこれをサポートしています。つまり、value = SOME (subquery_or_array) は value = ANY (subquery_or_array) と全く同じ意味です。

どちらを使うかは完全に個人の好みです。ANY の方が一般的に使われている印象があります。

ANY vs ALL

ANYが右辺の「いずれか」の要素と比較演算子を満たす場合に真となるのに対し、ALL演算子は右辺の「すべての」要素と比較演算子を満たす場合に真となります。ALL演算子はANYの対義語のような存在です。

構文はANYと同様です。

sql
expression comparison_operator ALL (subquery_or_array)

• = ALL (subquery_or_array): 左辺の値が、右辺のすべての要素と等しい場合に真となります。これは、右辺が空集合でない限り、右辺のすべての要素が同じ値であり、かつ左辺がその値と等しい場合のみ真になります。
• != ALL (subquery_or_array): 左辺の値が、右辺のすべての要素と等しくない場合に真となります。これは、左辺の値が右辺のどの要素とも等しくないことを意味します。つまり、value NOT IN (subquery) と等価です。
• < ALL (subquery_or_array): 左辺の値が、右辺のすべての要素よりも小さい場合に真となります。つまり、左辺の値が右辺の要素の最小値よりも小さい場合に真となります（ただし、右辺にNULLが含まれる場合は異なります）。
• > ALL (subquery_or_array): 左辺の値が、右辺のすべての要素よりも大きい場合に真となります。つまり、左辺の値が右辺の要素の最大値よりも大きい場合に真となります（ただし、右辺にNULLが含まれる場合は異なります）。

例：
* 価格がすべての人気商品の価格より高い商品 (> ALL)
sql
SELECT product_name
FROM products
WHERE price > ALL (SELECT price FROM products WHERE category_id IN (SELECT category_id FROM popular_categories));
このクエリは、自身の価格が人気カテゴリに属する「すべての」商品の価格よりも高い商品を検索します。

ANYとALLは比較の性質が全く異なるため、混同しないように注意が必要です。「いずれか」であればANY、「すべて」であればALLと使い分けましょう。

ANY vs EXISTS

EXISTS演算子もサブクエリと共に使用されますが、その評価方法はANYとは根本的に異なります。

• expression comparison_operator ANY (subquery): サブクエリが返す各行の単一の列値に対して、左辺の expression と comparison_operator で比較を行い、一つでも真になれば結果は真となります。サブクエリは実際に実行され、その結果セットが利用されます。
• EXISTS (subquery): サブクエリが「一つ以上の行」を返すかどうかだけを判定します。サブクエリの具体的な内容は（通常）重要ではなく、行が返されるかどうかが判定基準です。サブクエリは条件を満たす行が見つかった時点で評価を停止することがあります。

value = ANY (subquery) と EXISTS (SELECT 1 FROM subquery_table WHERE subquery_table.column = value) は、しばしば似た結果を返しますが、ニュアンスが異なります。

例：人気カテゴリに属する商品

• ANYを使った場合
  sql
SELECT product_name
FROM products
WHERE category_id = ANY (SELECT category_id FROM popular_categories);
  これは、products.category_id が人気カテゴリのいずれかのIDと等しいかを評価します。

• EXISTSを使った場合
  sql
SELECT product_name
FROM products p
WHERE EXISTS (SELECT 1 FROM popular_categories pc WHERE pc.category_id = p.category_id);
  これは、各商品 p に対して、その category_id と同じ category_id を持つ行が popular_categories テーブルに存在するかどうかを評価します。

多くの場合、これらのクエリは同じ結果セットを返します。しかし、内部的な実行計画やパフォーマンスは異なる可能性があります。特に相関サブクエリ（外側のクエリのカラムをサブクエリが参照する形式 – EXISTSの例がこれに該当します）では、EXISTSが効率的な場合があります。これは、EXISTSが真になった時点でサブクエリの評価を停止できるためです。

また、サブクエリがNULLを含む場合、ANYとEXISTSの挙動には違いが生じることがあります。これについては後述します。

一般的に、特定のリストやセットに含まれるかを判定する場合はINや= ANYが直感的でよく使われます。関連テーブルに一致する行が存在するかどうかを判定する場合はEXISTSが使われることが多いです。

ANY vs 複数の OR 条件

ANY演算子の大きな利点は、複数の OR 条件を簡潔に表現できる点です。

例えば、category_id が 101, 105, 203 のいずれかである商品を検索する場合、OR を使うと以下のようになります。

sql
SELECT product_name
FROM products
WHERE category_id = 101 OR category_id = 105 OR category_id = 203;

ANY（またはIN）を使うと、これをより簡潔に書くことができます。

sql
SELECT product_name
FROM products
WHERE category_id = ANY (ARRAY[101, 105, 203]);
-- または
SELECT product_name
FROM products
WHERE category_id IN (101, 105, 203);

候補となる値が増えるほど、ANY/INを使った方がクエリの可読性が大幅に向上します。また、候補値が動的に変化する場合（サブクエリの結果など）、OR条件を動的に生成するのは非常に煩雑ですが、ANYを使えばサブクエリを指定するだけで済みます。

サブクエリでのANYの使い方

ANY演算子の最も伝統的で一般的な使い方は、サブクエリの評価結果との比較です。サブクエリは単一の列を返す必要があり、ANYはその列の各行の値を比較対象として使用します。

基本的なサブクエリとの組み合わせ

前述の人気カテゴリの例は、基本的なサブクエリとの組み合わせの良い例です。

sql
SELECT product_name
FROM products
WHERE category_id = ANY (SELECT category_id FROM popular_categories);

このサブクエリ SELECT category_id FROM popular_categories は、人気カテゴリIDのセット（例: {101, 105, 203}）を返します。WHERE句の条件 category_id = ANY (...) は、products テーブルの各行について、その category_id がこのセットのいずれかの値 (101, 105, 203) と等しいかどうを評価します。

!= ANY とサブクエリ

!= ANY は特に注意が必要な組み合わせです。

sql
-- 人気カテゴリ **ではない** カテゴリに属する商品を検索したい
-- これは NOT IN を使うべき場面ですが、あえて != ANY を使ってみましょう。
SELECT product_name
FROM products
WHERE category_id != ANY (SELECT category_id FROM popular_categories);

サブクエリが {101, 105, 203} を返すとします。
ある商品の category_id が 101 の場合、
101 != ANY ({101, 105, 203}) は、101 != 101 OR 101 != 105 OR 101 != 203 と評価されます。
101 != 101 は偽ですが、101 != 105 は真、101 != 203 も真です。
論理和 (OR) のため、結果は真となります。
つまり、category_id が 101 の商品もこのクエリで選択されてしまいます！

これは、!= ANY が「右辺のいずれかの要素と等しくない」という意味であり、「右辺のすべての要素と等しくない（すなわち含まれていない）」という意味ではないためです。

「右辺のすべての要素と等しくない」という条件を指定したい場合は、!= ALL を使うか、より一般的には NOT IN を使います。

sql
-- 正しい方法：人気カテゴリではない商品を検索
SELECT product_name
FROM products
WHERE category_id != ALL (SELECT category_id FROM popular_categories);
-- または
SELECT product_name
FROM products
WHERE category_id NOT IN (SELECT category_id FROM popular_categories);
どちらのクエリも、category_id が 101, 105, 203 のいずれとも異なる商品を検索します。

比較演算子とサブクエリの組み合わせ

他の比較演算子 (<, >, <=, >=) とサブクエリを組み合わせることも可能です。

例: 平均価格が特定の基準を超えるカテゴリに属するすべての商品を検索

sql
-- カテゴリごとの平均価格を計算し、平均価格が100以上のカテゴリIDを取得するサブクエリ
-- そのカテゴリに属する商品を検索
SELECT product_name
FROM products
WHERE category_id = ANY (
SELECT category_id
FROM products
GROUP BY category_id
HAVING AVG(price) >= 100
);

例: 価格が、人気カテゴリに属する商品のいずれかの価格よりも安い商品 (< ANY)

sql
-- products テーブルに price カラムがあると仮定
SELECT product_name
FROM products
WHERE price < ANY (SELECT price FROM products WHERE category_id IN (SELECT category_id FROM popular_categories));
これは、自身の価格が人気カテゴリの商品の最小価格よりも安い商品を探すのと似ていますが、NULLの扱いなど違いがあります。正確には、「人気カテゴリの商品のいずれか一つでも、自分の価格より高いものが存在する」という条件になります。

相関サブクエリとANY

ANYは相関サブクエリと共に使用することも可能です。相関サブクエリとは、外側のクエリで参照されているテーブルのカラムをサブクエリ内で参照するものです。

例: 各カテゴリにおいて、そのカテゴリの平均価格より高いすべての商品を検索

sql
SELECT product_name, price, category_id
FROM products p1
WHERE price > ANY (
SELECT AVG(price)
FROM products p2
WHERE p2.category_id = p1.category_id -- 相関参照
GROUP BY category_id
);
このクエリは、外側のクエリの各行 (p1) に対してサブクエリを実行します。サブクエリは、p1 と同じ category_id を持つ商品の平均価格を計算します。そして、外側の行の price がその平均価格 (SELECT AVG(price) ...) より大きいかどうかを判定します。ここではサブクエリが単一の値を返すため、ANYを使う意味は薄いですが（WHERE price > (...) と直接書ける）、もしサブクエリが複数の値を返す可能性があればANYが役立ちます。

例えば、「各商品について、その商品の価格が、同じメーカーの他の製品のいずれかの価格よりも高いか？」といった複雑な条件などです。

sql
SELECT product_name, price, manufacturer_id
FROM products p1
WHERE price > ANY (
SELECT price
FROM products p2
WHERE p2.manufacturer_id = p1.manufacturer_id -- 同じメーカー
AND p2.product_id != p1.product_id -- 自身以外の製品
);
この例では、サブクエリが同じメーカーの他のすべての製品の価格リストを返します。ANY演算子はそのリストのいずれかの価格と比較します。

配列でのANYの使い方

PostgreSQLの配列型は非常に強力であり、ANY演算子と組み合わせることで、配列内の要素に対する柔軟な条件指定が可能になります。

スカラー値と配列の比較

前述の通り、最も一般的なANY + 配列の使い方は、左辺のスカラー値が右辺の配列のいずれかの要素と比較演算子を満たすか、という形です。

sql
expression comparison_operator ANY (array_expression)

例: items テーブルに tags というTEXT型配列のカラムがあるとします。

• タグに ‘fiction’ が含まれているアイテムを検索:
  sql
SELECT item_name
FROM items
WHERE 'fiction' = ANY(tags);
  これは WHERE tags @> ARRAY['fiction'] や WHERE 'fiction' IN (SELECT unnest(tags)) とほぼ等価ですが、= ANY(array) の構文が最も直接的で読みやすいでしょう。

• タグに ‘thriller’ ではないタグが含まれているアイテムを検索 (!= ANY):
  sql
SELECT item_name
FROM items
WHERE 'thriller' != ANY(tags);
  これは、tags 配列に ‘thriller’ 以外の要素が一つでも含まれていれば真となります。もし tags が {'thriller'} のみの場合、この条件は偽となります。もし tags が {'thriller', 'mystery'} の場合、'thriller' != 'thriller' は偽ですが、'thriller' != 'mystery' は真なので、全体として真となります。
  繰り返しますが、!= ANY は「含まれていない」という意味ではないため注意が必要です。

• タグに ‘scifi’ よりも辞書順で後のタグが含まれているアイテムを検索 (> ANY):
  sql
SELECT item_name
FROM items
WHERE 'scifi' > ANY(tags);
  これは、tags 配列のいずれかの要素が ‘scifi’ よりも辞書順で小さい（つまり ‘scifi’ より前に来る）場合に真となります。例えば tags = {'fantasy', 'scifi', 'mystery'} の場合、’fantasy’ は ‘scifi’ より小さいため、条件は真です。

配列カラムと配列リテラルの比較

右辺に配列リテラルを指定することもよくあります。

例: タグに ‘mystery’ または ‘thriller’ が含まれているアイテムを検索:

“`sql
— 方法1: OR を使う
SELECT item_name FROM items WHERE ‘mystery’ = ANY(tags) OR ‘thriller’ = ANY(tags);

— 方法2: 右辺を配列リテラルにして、左辺を UNNEST した結果と比較 (UNNEST + ANY)
SELECT item_name
FROM items
WHERE EXISTS (
SELECT 1
FROM unnest(tags) AS item_tag
WHERE item_tag = ANY (ARRAY[‘mystery’, ‘thriller’])
);

— 方法3: 配列演算子 && を使う (推奨される方法)
SELECT item_name
FROM items
WHERE tags && ARRAY[‘mystery’, ‘thriller’];
``
方法3の&&演算子が、配列同士で「共通の要素が存在するか」という条件を表現する最も慣用的で効率的な方法です。しかし、概念的には方法2のUNNEST + ANY` が、「アイテムのタグ配列のいずれかの要素が、指定したタグリスト配列のいずれかの要素に一致するか」というANYの考え方をより明確に示しています。

重要な注意点: ANY(array1) comparison_operator ANY(array2) という構文は存在しません。ANYは左辺に単一のスカラー値を、右辺にサブクエリまたは配列を取ります。配列の要素同士をANYで比較したい場合は、通常 UNNEST を使って配列を擬似的なテーブルに展開し、その要素を別の配列とANYで比較する形になります（例: 方法2）。

配列カラムと別の配列カラムの比較

テーブルに2つの配列カラムがある場合、一方の配列の要素が他方の配列のいずれかの要素に含まれるか、といった比較もANYとUNNESTを使って可能です。

例: users テーブルに preferred_tags、items テーブルに tags があるとし、ユーザーが好むタグのいずれかがアイテムのタグに含まれているアイテムを検索（ユーザーは一人に限定しない）。

“`sql
SELECT i.item_name, u.user_id
FROM items i
JOIN user_preferences u ON EXISTS (
SELECT 1
FROM unnest(i.tags) AS item_tag
WHERE item_tag = ANY(u.preferred_tags)
);

— あるいは、配列演算子 && を使う (推奨)
SELECT i.item_name, u.user_id
FROM items i
JOIN user_preferences u ON i.tags && u.preferred_tags;
``
ここでも&&演算子が最も一般的で効率的です。しかし、例えば「アイテムのタグがいずれか一つでも、ユーザーの好むタグのいずれか一つより辞書順で後にあるか？」のような複雑な比較（> ANY` など）を行いたい場合は、UNNESTとANYを組み合わせる必要があるかもしれません。

sql
-- 例: アイテムのタグのいずれかが、ユーザーの好むタグのいずれかより辞書順で後にあるか？
SELECT i.item_name, u.user_id
FROM items i
JOIN user_preferences u ON EXISTS (
SELECT 1
FROM unnest(i.tags) AS item_tag
WHERE item_tag > ANY(u.preferred_tags)
);

具体的な使用例とシナリオ

ANY演算子は様々な実際のシナリオで役立ちます。いくつかの具体的な例を見てみましょう。

例1：eコマースサイトでの商品検索（複数カテゴリ）

products テーブル (product_id, product_name, price)
product_categories テーブル (product_id, category_id)
ユーザーが複数のカテゴリIDを指定して商品を検索したい場合。

“`sql
— ユーザーがカテゴリID 101 または 105 の商品を検索
— カテゴリIDのリストを配列として変数に格納
SELECT p.product_name
FROM products p
JOIN product_categories pc ON p.product_id = pc.product_id
WHERE pc.category_id = ANY (ARRAY[101, 105]);

— もしくは、INを使う（等価）
SELECT p.product_name
FROM products p
JOIN product_categories pc ON p.product_id = pc.product_id
WHERE pc.category_id IN (101, 105);
“`
この例では、サブクエリではなく配列リテラルを使用しています。JOINとANYを組み合わせることで、指定されたカテゴリのいずれかに属する商品を効率的に取得できます。もしカテゴリリストがサブクエリから得られる場合も、同じANYの構文が使えます。

sql
-- 人気カテゴリリストをサブクエリで取得し、該当商品を検索
SELECT p.product_name
FROM products p
JOIN product_categories pc ON p.product_id = pc.product_id
WHERE pc.category_id = ANY (SELECT category_id FROM popular_categories);

例2：タグベースのフィルタリング（アイテムが特定のタグセットのいずれかを持つ）

items テーブル (item_id, item_name, tags TEXT[])
特定のタグセット ({'fiction', 'mystery', 'thriller'}) のいずれかのタグを持つアイテムを検索したい場合。

“`sql
SELECT item_name
FROM items
WHERE tags && ARRAY[‘fiction’, ‘mystery’, ‘thriller’];
— これは内部的に ANY と似た処理を行います。

— UNNEST + ANY で明示的に書くことも可能
SELECT item_name
FROM items
WHERE EXISTS (
SELECT 1
FROM unnest(tags) AS item_tag
WHERE item_tag = ANY (ARRAY[‘fiction’, ‘mystery’, ‘thriller’])
);
``
配列演算子&&` が最も推奨される方法ですが、ANYの概念を理解する上で後者の書き方も参考になります。

例3：ユーザー権限チェック（ユーザーが特定のロールセットのいずれかを持つ）

users テーブル (user_id, username, roles INT[])
roles テーブル (role_id, role_name)
特定のロールIDセット ({1, 3, 5} – 例: 管理者, 編集者, モデレーター) のいずれかのロールを持つユーザーを検索したい場合。

“`sql
SELECT username
FROM users
WHERE 1 = ANY(roles) OR 3 = ANY(roles) OR 5 = ANY(roles);

— OR を ANY + 配列リテラルで置き換える (ただし、ANY(array) という構文はNG)
— 正しくは、UNNEST + ANY または && 演算子
SELECT username
FROM users
WHERE roles && ARRAY[1, 3, 5];

— UNNEST + ANY
SELECT username
FROM users
WHERE EXISTS (
SELECT 1
FROM unnest(roles) AS user_role_id
WHERE user_role_id = ANY (ARRAY[1, 3, 5])
);
``
ここでも&&` 演算子が簡潔です。ANYを直接使う場合は、UNNESTと組み合わせる必要があります。

例4：数値範囲でのフィルタリング（値が特定の範囲セットのいずれかに含まれる）

sensor_readings テーブル (reading_id, value, timestamp)
値が特定の危険範囲セット（例: [0, 10], [100, 200], [500, 無限大) のいずれかに該当する読み取り値を検索したい場合。
これは少し複雑ですが、ANYと組み合わせて表現できます。右辺は範囲のセットを表す何か（例えば、範囲の下限値の配列と上限値の配列を組み合わせて使うなど）になります。

例えば、危険な下限値の配列と上限値の配列があるとします。
critical_lows = ARRAY[0, 100]
critical_highs = ARRAY[10, 200]
ここで、value <= 10 または (value >= 100 かつ value <= 200) といった条件をANYで表現したい。

これは直接ANYで elegant に表現するのは難しいですが、UNNESTを使って範囲を要素ごとに分解し、EXISTS + ANY で比較することは可能です。

sql
-- 例: 値が {5, 15, 150} のいずれかである読み取り値を検索
SELECT *
FROM sensor_readings
WHERE value = ANY (ARRAY[5, 15, 150]);
これは単純な離散値の例ですが、ANYがどのようにリスト比較を扱うかを示しています。

より複雑な範囲の例は、ARRAY型に複合型やrange型を使う必要があります。例えば、critical_ranges range[] のようなカラムがあれば、value <@ ANY(critical_ranges) のように簡単に書ける可能性もありますが、標準的なANYの機能からは外れます。

ANY演算子は、右辺が「単一の値を要素とするリスト/セット」である場合に最も効果を発揮します。それがサブクエリの結果であろうと、配列の要素であろうとです。

ANY演算子の注意点と落とし穴

ANY演算子は強力ですが、使用にあたってはいくつかの注意点があります。

NULL値の扱い

ANY演算子を使った比較において、NULL値の扱いは重要です。SQLの比較演算子は、オペランドのいずれかがNULLである場合、結果は不明 (UNKNOWN) になります。ANY演算子はこの不明な結果を考慮して評価されます。

• expression = ANY (subquery_or_array):
  右辺にNULLが含まれていても、expression が右辺のNULLではない要素のいずれかと等しければ、結果は真になります。
  例: 1 = ANY (ARRAY[NULL, 1, 2]) -> 1 = NULL OR 1 = 1 OR 1 = 2 -> UNKNOWN OR TRUE OR FALSE -> TRUE
  右辺のすべての要素がNULLであるか、NULLではない要素のいずれとも比較演算子を満たさない場合、結果は偽またはUNKNOWNになります。具体的には、右辺にNULLではない要素が一つも存在せず、かつ左辺がNULLでない場合、結果は偽になります。左辺がNULLの場合は結果はUNKNOWNになります。

• expression != ANY (subquery_or_array):
  これも注意が必要です。右辺にNULLが含まれていても、expression が右辺のNULLではない要素のいずれかと等しくなければ、結果は真になります。
  例: 1 != ANY (ARRAY[NULL, 1, 2]) -> 1 != NULL OR 1 != 1 OR 1 != 2 -> UNKNOWN OR FALSE OR TRUE -> TRUE
  これは前述の通り、「右辺のすべての要素と等しくない」という意味ではありません。

• expression NOT IN (subquery_or_array) （これは != ALL と等価）:
  NOT IN は != ALL と等価ですが、NULLの扱いで重要な違いがあります。expression NOT IN (subquery_or_array) は、サブクエリまたは配列に一つでもNULLが含まれている場合、結果が絶対に真にならないという特性があります。これは、expression != value がNULLに対してUNKNOWNを返すため、expression != v1 AND expression != v2 AND ... AND expression != NULL という論理積 (AND) の中にUNKNOWNが混ざり、結果全体がUNKNOWNになるためです。
  例: 1 NOT IN (ARRAY[NULL, 2, 3]) -> 1 != NULL AND 1 != 2 AND 1 != 3 -> UNKNOWN AND TRUE AND TRUE -> UNKNOWN
  この挙動は意図しない結果を引き起こす可能性があるため、サブクエリや配列にNULLが含まれる可能性がある場合は、NOT IN の代わりに EXCEPT や LEFT JOIN ... WHERE ... IS NULL、あるいはNULLを除外した上での IN や = ANY を使う方が安全です。

• 比較演算子とNULL:
  ANY演算子で使われる比較演算子 (=, !=, <, >, <=, >=) はいずれも、オペランドにNULLが含まれると結果がUNKNOWNになります。ANY演算子は、このUNKNOWNを「偽ではない」と扱います（偽でも真でもない）。ANYのルールは「いずれか一つでも真なら全体が真」なので、UNKNOWNだけの場合は真になりません。

  例: 1 < ANY (ARRAY[NULL, 2, 3]) -> 1 < NULL OR 1 < 2 OR 1 < 3 -> UNKNOWN OR TRUE OR TRUE -> TRUE
  例: 5 < ANY (ARRAY[NULL, 2, 3]) -> 5 < NULL OR 5 < 2 OR 5 < 3 -> UNKNOWN OR FALSE OR FALSE -> UNKNOWN
  例: 5 > ANY (ARRAY[NULL, 2, 3]) -> 5 > NULL OR 5 > 2 OR 5 > 3 -> UNKNOWN OR TRUE OR TRUE -> TRUE
  例: 0 > ANY (ARRAY[NULL, 2, 3]) -> 0 > NULL OR 0 > 2 OR 0 > 3 -> UNKNOWN OR FALSE OR FALSE -> UNKNOWN

  右辺が空集合/空配列の場合、ANYを使った比較はすべて偽になります。
  例: 1 = ANY (ARRAY[]) -> FALSE
  例: 1 > ANY (SELECT column FROM empty_table) -> FALSE

NULLの扱いは複雑なので、サブクエリや配列にNULLが含まれる可能性がある場合は、クエリの結果が期待通りになるか十分にテストすることが重要です。特に != ANY や NOT IN を使う際は注意が必要です。

パフォーマンスに関する考慮事項

ANY演算子を使ったクエリのパフォーマンスは、右辺がサブクエリか配列か、そしてデータ量やインデックスの有無によって大きく異なります。

サブクエリの場合:

• value = ANY (subquery) または value IN (subquery):
  PostgreSQLオプティマイザは、サブクエリをマテリアライズ（一度評価して一時テーブルに格納）したり、ハッシュ結合に書き換えたり、セキュアな環境では場合によってはプランナがサブクエリの結果をインライン展開したりすることがあります。サブクエリの結果セットが小さい場合や、外部カラムとの相関がない場合は、効率的に処理されることが多いです。
  サブクエリの結果セットが大きい場合、マテリアライズのコストが高くなったり、ハッシュ結合がメモリに収まらなくなったりする可能性があります。
  このような場合、元のテーブルとサブクエリのテーブルをJOINしたり、EXISTSを使ったりする方が効率的になることもあります。最適な方法は、クエリ、データ、インデックスによって異なるため、EXPLAIN コマンドで実行計画を確認し、比較検討することが不可欠です。
  例: products と popular_categories の例で、
  WHERE category_id = ANY (SELECT category_id FROM popular_categories)
  と
  JOIN popular_categories ON products.category_id = popular_categories.category_id
  は多くの場合、オプティマイザによって同じ効率的な実行計画に変換されます。しかし、常にそうとは限りません。

• value < ANY (subquery), value > ANY (subquery) など（非等価比較）：
  これらのケースは = や IN の場合ほど簡単に最適化されないことがあります。特にサブクエリの結果セットが大きい場合、比較演算子の性質上、個々の要素との比較を効率的に行うのが難しいことがあります。
  例えば、WHERE price < ANY (SELECT price FROM expensive_items) のようなクエリは、expensive_items の価格リストが長いと非効率になる可能性があります。このような場合は、サブクエリで最大値/最小値を求めてから比較する (WHERE price < (SELECT MAX(price) FROM expensive_items))、あるいは他の手法（JOINやウィンドウ関数など）で代替できないか検討すると良いでしょう。

配列の場合:

• value = ANY (array_column):
  PostgreSQLは配列に対する操作を効率的に行うための特殊なインデックス型（GINまたはGiST）をサポートしています。配列カラムにGINインデックスを作成すると、= ANY(array) や && 演算子を使った検索性能が大幅に向上します。
  sql
CREATE INDEX items_tags_gin_idx ON items USING GIN (tags);
  GINインデックスを作成すると、WHERE 'fiction' = ANY(tags) や WHERE tags && ARRAY['mystery', 'thriller'] といったクエリは、配列の要素に対して高速なインデックススキャンを利用できるようになります。
  配列カラムに対してこれらの検索を頻繁に行う場合は、必ずGINインデックスの作成を検討してください。

• value != ANY (array_column), value < ANY (array_column) など（非等価比較）：
  これらの演算子と配列の組み合わせは、GINインデックスによる高速化の恩恵を = や && ほど受けられない場合があります。特定の非等価比較を高速化したい場合は、異なるインデックス戦略やクエリの書き換えが必要になることがあります。

インデックスの使用

ANY演算子を含むクエリのパフォーマンスは、適切にインデックスが使用されるかどうかに大きく依存します。

• サブクエリの場合:
  WHERE句でANYの左辺に使用されているカラム（例: category_id）にインデックスがあれば、外部クエリの処理（テーブルスキャンからインデックススキャンへの切り替え）が高速化される可能性があります。
  サブクエリ内でWHERE句やJOIN句に使用されているカラム（例: popular_categories.category_id）にインデックスがあれば、サブクエリ自体の実行が高速化されます。
  ANYがサブクエリ全体をマテリアライズしてハッシュ結合を行う場合、ANYの左辺カラムに対するインデックスは直接利用されませんが、サブクエリの実行速度向上は全体パフォーマンスに寄与します。

• 配列の場合:
  前述の通り、配列カラムに対する value = ANY(array_column) や array1 && array2 といった検索を高速化するには、その配列カラムにGINインデックスを作成することが非常に効果的です。

ANY演算子を使うクエリが遅いと感じたら、まず EXPLAIN ANALYZE コマンドを実行して実行計画を確認し、どのステップに時間がかかっているのか、インデックスが使われているかなどを調査することが重要です。

パフォーマンス最適化

ANY演算子を含むクエリのパフォーマンスを最適化するためには、以下の点を検討します。

1. EXPLAIN ANALYZE を使う:
   遅いクエリがあれば、必ず EXPLAIN ANALYZE を実行して実行計画を理解します。ANYを含む部分がどのように評価されているか（例: Subquery Scan, Hash Join, Bitmap Heap Scan on GIN Indexなど）を確認します。

2. 適切なインデックスの作成:
   サブクエリの対象となるカラムや、ANYの左辺に使用されるカラムにB-treeインデックスを検討します。
   配列カラムに対して value = ANY(array) や && 演算子を使う場合は、必ずその配列カラムにGINインデックスを作成します。

3. 代替手段の検討:
   ANY演算子を使ったクエリが非効率な場合、同等の結果を得られる別の方法を検討します。

   • JOIN: value = ANY (SELECT col FROM table WHERE ...) は、多くの場合 main_table JOIN subquery_table ON main_table.value = subquery_table.col と同等であり、JOINの方がオプティマイザにとって扱いやすく、効率的な実行計画が生成されやすいことがあります。
   • EXISTS: 相関サブクエリの場合は、ANYよりもEXISTSの方が効率的な実行計画になることがあります。
   • IN: = 演算子を使う場合は、ANYの代わりにINを使っても機能的には同じですが、オプティマイザの挙動がわずかに異なる可能性もゼロではありません。EXPLAIN で比較してみてください。
   • UNNEST + JOIN/Aggregate: 配列の要素をより複雑に扱いたい場合や、ANY + GINインデックスが効かない非等価比較などの場合、UNNEST 関数を使って配列を一時的な行セットに展開し、他のテーブルと結合したり集約したりする方法が有効な場合があります。ただし、UNNESTは配列が大きい場合に多くの行を生成するため、注意が必要です。

4. サブクエリの結果セットのサイズ:
   ANYがサブクエリを取る場合、サブクエリが返す行数がパフォーマンスに大きく影響します。サブクエリが返すデータ量を減らすように、WHERE句や他のフィルタリングをサブクエリ内で行うことを検討します。

5. NULL値の扱いを明確にする:
   前述の通り、NULLはANY演算子の挙動を複雑にします。NULLが含まれる可能性がある場合は、COALESCE 関数でNULLを特定の値に置換したり、WHERE column IS NOT NULL でNULLを除外したりするなど、NULLを明示的に扱うようにクエリを修正することで、予測可能な結果とより効率的な実行計画を得られる場合があります。

まとめ

PostgreSQLのANY演算子は、ある値がサブクエリの結果セットまたは配列の要素の「いずれか」と比較演算子を満たすかどうかを判定するための強力で柔軟なツールです。

• 基本的な使い方: expression comparison_operator ANY (subquery_or_array) の構文で使用します。右辺が返す要素のいずれか一つでも比較演算子を満たせば真となります。
• = との組み合わせ: = ANY は IN と機能的に等価であり、等価比較でリストやサブクエリとの比較を行う最も一般的な方法の一つです。
• その他の比較演算子: < ANY, > ANY, != ANY など、様々な比較演算子と組み合わせることで、「右辺の要素の最大値より小さい」「右辺の要素の最小値より大きい」「右辺のいずれかの要素と等しくない」といった条件を指定できます（ただし != ANY の挙動には注意が必要です）。
• サブクエリとの連携: サブクエリが返す単一列の結果セットに対して「いずれかに一致」の条件を適用できます。
• 配列との連携: PostgreSQLの強力な配列型と組み合わせることで、配列カラムの要素に対する柔軟な検索が可能になります。特に value = ANY(array_column) の形は配列検索で頻繁に利用されます。配列間の「いずれかの要素の一致」は && 演算子が推奨されますが、UNNESTとANYを組み合わせて実現することもできます。
• 注意点: NULL値の扱いは複雑であり、特に != ANY や NOT IN は意図しない結果を招く可能性があるため注意が必要です。
• パフォーマンス: サブクエリのサイズやインデックスの有無がパフォーマンスに大きく影響します。配列カラムの場合はGINインデックスが非常に効果的です。遅いクエリは EXPLAIN ANALYZE で実行計画を確認し、必要に応じてJOIN、EXISTS、IN、配列演算子 (&&)、UNNESTなどの代替手段を検討・比較することが重要です。

ANY演算子を使いこなすことで、より簡潔で表現力の高いクエリを作成し、PostgreSQLの能力を最大限に引き出すことができます。この記事で解説した内容を参考に、ぜひ自身のデータベース操作にANY演算子を取り入れてみてください。その際には、常に意図した結果が得られるか、パフォーマンスは適切かを確認することを忘れないでください。

---