知っておきたい6つのSQL結合（簡単でわかりやすい例付き）

SQL JOINとは何か、なぜ使うのか

SQLのJOINは、関連する列（通常はID）で2つ以上のテーブルの行を結びつけ、1つの結果セットにまとめる方法です。

JOINが重要な理由

実務ではデータベースは繰り返しを避けるために複数のテーブルに分割されます。たとえば、顧客の名前はcustomersテーブルにあり、購入はordersテーブルにあります。JOINは、レポートや分析でそれらを再結合する手段です。

そのため、JOINはレポーティングや分析のあらゆる場面に登場します：

• 顧客名、注文合計、支払い状況を含む売上レポートの作成
• まだ注文していない顧客の抽出
• 支払いのない注文など不整合の監査
• 多数の関連行から「顧客ごとに1行」の要約を作る

JOINがなければ別々にクエリを実行して手作業で結合する必要があり、遅くてエラーが起きやすく再現性も低くなります。

製品（ダッシュボード、管理画面、内部ツール、顧客ポータル）を関係データベース上で作る場合も、JOINの基礎は重要です。例えば、Koder.aiのようなプラットフォームでReact + Go + PostgreSQLのアプリを自動生成しても、正確な一覧ページやレポート、突合画面を作るには適切なJOINロジックが欠かせません。

よく使う6種類のJOIN

このガイドでは日常的によく使う6つのJOINを扱います：

• INNER JOIN：両方のテーブルに一致がある行だけを返す（“関係のあるものだけ見せる”用途）
• LEFT JOIN：左テーブルのすべての行を保持し、右テーブルから一致するものだけを追加する（関連データが欠けている場合も含めたいとき）
• RIGHT JOIN：LEFT JOINの鏡（読み方の好みや既存クエリの編集時に便利）
• FULL OUTER JOIN：両方のテーブルの全行を保持し、可能ならマッチさせる（照合やギャップ探しに最適）
• CROSS JOIN：全組み合わせを作る（カレンダーやシナリオ生成、テストデータに有効だが誤用しやすい）
• SELF JOIN：テーブルを自身と結合する（従業員と上司のような階層に便利）

構文について一言

JOINの構文はPostgreSQL、MySQL、SQL Server、SQLiteなどで非常に似ています。FULL OUTER JOINのサポートや一部の挙動に差はありますが、概念と基本パターンは共通です。

例で使うテーブル（customers, orders, payments）

例を単純にするために、顧客が注文を行い、注文に支払いが紐づくという一般的な構成の3つの小さなテーブルを使います。

以下のサンプルテーブルは一部の列しか示していませんが、後のクエリではorder_date、created_at、status、paid_atなどの典型的な列を参照します。実運用のスキーマでよくある列だと考えてください。

1) customers

主キー: customer_id

2) orders

主キー: order_id
外部キー: customer_id → customers.customer_id

注意：order_id = 104はcustomer_id = 5を参照していますが、customersに5は存在しません。こうした「一致しない」ケースはLEFT JOINやFULL OUTER JOINの挙動を確認するのに役立ちます。

3) payments

主キー: payment_id
外部キー: order_id → orders.order_id

ここで学びのために重要な点が二つあります：

• order_id = 102には2つの支払い行があります（分割支払い）。ordersとpaymentsを結合すると、その注文は2回現れます。これが重複で驚く原因になります。
• payment_id = 9004はorder_id = 999を参照していますが、ordersに999はありません。これも「一致しない」ケースです。

JOINしたときに期待すること

• 一致する行：例）顧客1 ↔ 注文101/102、注文101 ↔ 支払い9001
• 一致しない行：例）顧客3と4は注文がない、注文104は顧客がない、支払い9004は注文がない
• 重複：注文102は支払いが2件あるため、ordersとpaymentsの結合で2行になる

INNER JOIN：一致する行だけ残す

INNER JOINは両方のテーブルに一致がある行のみを返します。顧客に注文がなければ結果に出ません。注文が存在しない顧客IDを参照していれば（データ不整合）、その注文も結果に出ません。

基本パターン

「左」テーブルと「右」テーブルを選び、ON句で結合条件を指定します。

SELECT
  c.customer_id,
  c.name,
  o.order_id,
  o.order_date
FROM customers c
INNER JOIN orders o
  ON o.customer_id = c.customer_id;

ポイントはON o.customer_id = c.customer_idで、どの列で行を対応づけるかを指定している点です。

実例：注文を出した顧客

注文を1つでも出した顧客だけをリストしたいときはINNER JOINが自然です：

SELECT
  c.name,
  o.order_id,
  o.total_amount
FROM customers c
INNER JOIN orders o
  ON o.customer_id = c.customer_id
ORDER BY o.order_id;

これは「注文フォローのメールを送る」や「購入がある顧客に対する売上集計」などに有効です。

よくあるミス：結合条件の忘れや不正確さ

ON条件を忘れる（または間違った列で結合する）と、意図せずデカルト積（全組み合わせ）になったり、微妙に間違ったマッチが生じます。

やってはいけない例：

SELECT c.name, o.order_id
FROM customers c
JOIN orders o;

常にON（あるいは適切な場合はUSING）で明確な結合条件を指定してください。

LEFT JOIN：左テーブルの全行を保持する

LEFT JOINは左テーブルのすべての行を返し、右テーブルに一致があればそのデータを追加します。一致がなければ右側の列はNULLになります。

いつ使うか

メインのテーブルの全行を取りつつ、関連データを任意で付けたいときにLEFT JOINを使います。

例：「すべての顧客を表示し、もし注文があればその注文を含める」

SELECT
  c.customer_id,
  c.name,
  o.order_id,
  o.order_date
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
ORDER BY c.customer_id;

• 注文のある顧客は注文情報付きで表示されます。
• 注文がない顧客も表示されますが、o.order_idなどはNULLになります。

「一致なし」行を見つける典型パターン

LEFT JOINのよくある使い方は、関連レコードが存在しない項目を探すことです。

SELECT
  c.customer_id,
  c.name
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
WHERE o.order_id IS NULL;

このWHERE ... IS NULLが、結合で一致が見つからなかった左側の行だけを残します。

注意：複数一致で左側の行が増える

右側に複数一致があると左側の行が「重複」して見えます。例えば1人の顧客が3件の注文を持つと、その顧客は3回出力されます。これは期待される動作ですが、顧客数を数えたい場合に誤解を招きます。

例えば次は注文の件数を数えます（顧客数ではない）：

SELECT COUNT(*)
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id;

顧客数を数えたいなら通常はCOUNT(DISTINCT c.customer_id)のようにキーを基準にします。

RIGHT JOIN：右テーブルの全行を保持する

RIGHT JOINは右テーブルのすべての行を保持し、一致する左側の行だけを追加します。一致しない場合は左側の列がNULLになります。LEFT JOINの鏡です。

簡単な例

すべての支払いをリストしたい（たとえ注文に紐づかないものがあっても）場合：

SELECT
  o.order_id,
  o.customer_id,
  p.payment_id,
  p.amount,
  p.paid_at
FROM orders o
RIGHT JOIN payments p
  ON o.order_id = p.order_id;

この場合：

• すべての支払いが含まれます（右側がpaymentsのため）。
• 支払いに一致する注文がなければ、o.order_idやo.customer_idはNULLになります。

多くの場合はLEFT JOINで書き換え可能

通常はテーブルの順序を入れ替えてLEFT JOINに直せます：

SELECT
  o.order_id,
  o.customer_id,
  p.payment_id,
  p.amount,
  p.paid_at
FROM payments p
LEFT JOIN orders o
  ON o.order_id = p.order_id;

この方が「メインにしたいテーブルから始めて、必要な関連をLEFT JOINで付ける」という読み方に沿うため多くのチームで好まれます。

可読性の観点からRIGHT JOINを避ける理由

多くのSQLスタイルガイドはRIGHT JOINを避けるよう勧めます。なぜなら、読者がテーブルの主語を逆に考えないといけないためです。

ただし、既存の長いクエリの一部を編集するときに右テーブルを残したままにしたいケースでは、RIGHT JOINは素早い対応手段になります。

FULL OUTER JOIN：両方のテーブルの全行を保持する

FULL OUTER JOINは両テーブルのすべての行を返します。

• マッチする行は結合されます（INNER JOINのように）。
• 左にしかない行は右側がNULLになります。
• 右にしかない行は左側がNULLになります。

いつ有用か

注文と支払いの突合は典型例です：

• 支払いがある注文（マッチ）
• 支払いのない注文（左のみ）
• 注文がない支払い（右のみ）

SELECT
  o.order_id,
  o.customer_id,
  p.payment_id,
  p.amount
FROM orders o
FULL OUTER JOIN payments p
  ON p.order_id = o.order_id;

DBサポート状況

FULL OUTER JOINはPostgreSQL、SQL Server、Oracleでサポートされています。

MySQLやSQLiteではサポートされていないため、回避策が必要です。

ポータブルな代替：LEFT JOINとRIGHT JOINのUNION

DBがFULL OUTER JOINをサポートしない場合、次のようにLEFT JOINと（場合によっては）RIGHT JOINをUNIONで組み合わせてエミュレートします。

SELECT o.order_id, o.customer_id, p.payment_id, p.amount
FROM orders o
LEFT JOIN payments p
  ON p.order_id = o.order_id

UNION

SELECT o.order_id, o.customer_id, p.payment_id, p.amount
FROM orders o
RIGHT JOIN payments p
  ON p.order_id = o.order_id;

片側がNULLになっている行は「相手側に存在しなかった」ことを示しており、監査や突合には役立ちます。

CROSS JOIN：全組み合わせを作る（慎重に使う）

CROSS JOINは2つのテーブル間のすべての組み合わせを返します。テーブルAが3行、テーブルBが4行なら結果は3 × 4 = 12行になります（デカルト積）。

用途が限られますが、有用な場面もあります。

小さく安全な例：サイズ × 色（SKU生成）

sizesとcolorsのように別テーブルにオプションを持っている場合、全バリエーションを作るのに使えます：

SELECT
  s.size,
  c.color
FROM sizes AS s
CROSS JOIN colors AS c;

結果（3 × 2 = 6行）：

• S / Red
• S / Blue
• M / Red
• M / Blue
• L / Red
• L / Blue

警告：結果は急速に増える

行数は掛け算で増えるため、CROSS JOINはすぐに巨大な結果を作ります。入力テーブルが大きい場合は実行しないか、制限やフィルタを必ず組み合わせてください。

SELF JOIN：テーブルを自分自身に結合する

SELF JOINは同じテーブルを2回使って互いに関連づけるケースで使います。最もよくあるのは従業員とその上司の関係です。

エイリアスが必要な理由

同じテーブルを2回参照するので、各コピーに別名（エイリアス）を付けてどちらの側かを明確にします。慣例として：

• e を従業員（employee）に
• m をマネージャー（manager）に

実用例：従業員と上司の名前を並べる

employeesテーブルが id, name, manager_id を持つとすると：

SELECT
  e.id,
  e.name AS employee_name,
  m.name AS manager_name
FROM employees e
LEFT JOIN employees m
  ON e.manager_id = m.id;

CEOなどトップレベルの扱い

上司がいない従業員（manager_idがNULL）を保持するためにLEFT JOINを使っています。INNER JOINにすると上司がいない人は結果から消えてしまいます。

結合条件：ONとUSING（違いと使いどころ）

JOINはテーブル同士の関係を知らないので、どの列で結合するかを明示する必要があります。結合条件はJOINに近い位置に置くのが自然です。

ON：最も柔軟で一般的

列名が異なる場合や複雑な条件を使いたい場合はONを使います。

SELECT
  c.customer_id,
  c.name,
  o.order_id,
  o.created_at
FROM customers AS c
INNER JOIN orders AS o
  ON o.customer_id = c.customer_id;

ONでは複数列での比較や追加条件も書けるため、曖昧さが少なくなります。

USING：同名列のときに短く書ける

PostgreSQLやMySQLではUSINGが使え、両テーブルに同名の列がありその列で結合する場合に短く書けます。

SELECT
  customer_id,
  name,
  order_id
FROM customers
JOIN orders
USING (customer_id);

USINGの利点は出力に同名列が1つだけ残ることが多い点です。

あいまいな列名を避けるために必ず修飾する

結合するとidやcreated_atなど列名が重なることが多いです。SELECT idのように書くとDBが曖昧だとエラーになるか、意図しない列を参照する危険があります。テーブル接頭辞（またはエイリアス）を使いましょう：

SELECT c.customer_id, o.order_id
FROM customers AS c
JOIN orders AS o
  ON o.customer_id = c.customer_id;

JOINでSELECT *は避ける

結合クエリでSELECT *を使うと不要な列を引き込み、重複名の混乱を招き、意図を読み取りにくくします。必要な列だけを指定する習慣をつけると結果がきれいで保守性も上がります。

結合後のフィルタ：WHEREとONの違い

ONは結合時にどの行をマッチさせるかを決め、WHEREは結合結果の最終行を絞り込みます。このタイミングの違いにより、LEFT JOINがINNER JOINのように振る舞ってしまうことがあります。

WHEREでLEFT JOINが壊れる例

「すべての顧客を表示しつつ、最近の有料注文だけを含めたい」とした場合：

SELECT c.customer_id, c.name, o.order_id, o.status, o.order_date
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
WHERE o.status = 'PAID'
  AND o.order_date >= DATE '2025-01-01';

問題点：注文がない顧客ではo.statusやo.order_dateがNULLであり、WHEREで弾かれてしまうため、LEFT JOINの意図（左側の全行を保持）が失われます。

右テーブルの条件はONに入れる

SELECT c.customer_id, c.name, o.order_id, o.status, o.order_date
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.customer_id
 AND o.status = 'PAID'
 AND o.order_date >= DATE '2025-01-01';

こう書くと、条件に合致する注文があればその注文がつき、合致する注文がなければNULLになって顧客行は残ります。

まとめのチェックリスト：ONとWHEREの振り分け

• ON：右テーブルのどの行をマッチさせるかを定義する（右テーブルのstatusやdateなどの条件）
• WHERE：最終的にどの行を残すか（左テーブルに関するフィルタや、明示的にマッチが必要な場合）
• 「左の全行を残して右を制限したい」ならLEFT JOIN + ON内の条件が基本
• 「一致する行だけを欲しい」ならINNER JOINか、WHERE o.order_id IS NOT NULLを使う

重複行・多対多の落とし穴を避ける

JOINは列を追加するだけでなく行を掛け合わせることで増やします。これが正しい挙動であることが多いですが、合計が突然倍になるなどで驚くことがあります。

なぜ増えるのか

一致する行ごとに出力行が作られるためです。

• 1対多：1人の顧客が複数注文を持つと、その顧客は注文ごとに複数行になる。
• 多対多：注文に対して支払いが複数、さらに注文商品（order_items）も複数ある場合、payments × itemsのように掛け合わせが起きます。

事前に集約してから結合する

「顧客ごとに1行」や「注文ごとに1行」を保ちたいなら、多側を先に集約してから結合します：

-- paymentsを注文ごとに1行にまとめる
WITH payment_totals AS (
  SELECT
    order_id,
    SUM(amount) AS total_paid,
    COUNT(*)   AS payment_count
  FROM payments
  GROUP BY order_id
)
SELECT
  o.order_id,
  o.customer_id,
  COALESCE(pt.total_paid, 0) AS total_paid,
  COALESCE(pt.payment_count, 0) AS payment_count
FROM orders o
LEFT JOIN payment_totals pt
  ON pt.order_id = o.order_id;

これにより「1注文 = 1行」の形が保たれます。

DISTINCTは最後の手段

SELECT DISTINCTは重複を見かけ上取り除きますが、本質的な問題を隠すことがあるため注意が必要です。

• 正当な行を消してしまう可能性
• 結合条件の欠落を覆い隠す
• 合計や件数が狂うことがある

必要な場合だけ、理由が明確なときに使ってください。

安全確認：件数を検証する

結果を信用する前に次を比較してください：

• メインテーブルの行数（例：orders）
• 結合後の行数

もし数が不意に増えているなら、どのキーで複数マッチが起きているかを調べ、事前集約や別の結合経路を検討します。

パフォーマンスの基礎とJOINの簡易リファレンス

JOINが「遅い」と言われるとき、原因は通常「データ量」と「マッチ行の検索のしやすさ（インデックスなど）」です。

インデックス（概念）とJOINの高速化

インデックスは本の目次のようなもので、無いとDBは多くの行を走査して一致を探す必要があります。結合キーにインデックスがあると、DBは該当する行に素早くジャンプできます。

頻繁に結合に使う列（ON a.id = b.a_idなど）はインデックス候補です。

安定したキーで結合する（名前やメールで結合しない）

可能なら安定した一意の識別子で結合してください：

• 良い例：customers.customer_id = orders.customer_id
• 危険な例：customers.email = orders.emailやcustomers.name = orders.name

名前やメールは変更され得るし重複することもあります。IDは結合に適し、通常インデックスも張られています。

早めに作業量を減らす

次の2点でJOINはかなり速くなります：

1. 取得する列を絞る（結合時にSELECT *を避ける）
2. 結合の前または内部で行数を制限する（サブクエリやCTEで必要な行に絞る）

例：まずordersを絞ってから結合する

SELECT c.customer_id, c.name, o.order_id, o.created_at
FROM customers c
JOIN (
  SELECT order_id, customer_id, created_at
  FROM orders
  WHERE created_at >= DATE '2025-01-01'
) o
  ON o.customer_id = c.customer_id;

アプリのレポートページなどでJOINロジックが正確さを決める場合、スキーマやエンドポイント、UIの雛形作成を高速化するツール（例：Koder.ai）は便利ですが、JOINの正しさは開発速度が上がっても残る重要な責務です。

JOINの早見表

• INNER JOIN → 両方のテーブルに一致する行のみ
• LEFT JOIN → 左テーブルの全行 + 右の一致（不一致はNULL）
• RIGHT JOIN → 右テーブルの全行 + 左の一致（不一致はNULL）
• FULL OUTER JOIN → 両方の全行。マッチは結合、不一致は片側がNULL
• CROSS JOIN → 全組み合わせ（行数が掛け算で増える）
• SELF JOIN → テーブルを自身と結合（階層や比較に便利）