SQLのPIVOT完全ガイド｜行→列変換の基本・実務・注意点まで解説

「SQLで縦持ちデータを横並びにしたい」

「レポートでカテゴリごとに比較したいが、毎回集計が面倒」

「BIツールに渡す前に、見やすい形に整形したい」

こうした悩みを持つエンジニア・データ担当者は非常に多いです。

本記事では、SQLのPIVOT（ピボット）を使って

👉 行データを列データへ変換し

👉 比較しやすいクロス集計を作る方法

を、基礎から実務レベルまで徹底解説します。

さらに、

• DBごとの違い（SQL Server / MySQL / PostgreSQL）
• 動的PIVOTの設計と注意点
• CASE式での代替方法
• 実務での失敗例と回避策

まで網羅しています。

👉 この記事を読めば「PIVOTを安全に・正しく・実務で使える」状態になります。

PIVOTとは？行→列に変換するクロス集計の基本

PIVOTの本質

PIVOTとは、縦持ち（行）のデータを横持ち（列）に変換するSQL機能です。

具体的には：

• カテゴリ列 → 列見出しに変換
• 数値列 → 集計してセルに配置

つまり、単なる整形ではなく

👉 「集計を伴うデータ再配置」です。

例：縦持ち vs 横持ち

縦持ち（通常のテーブル）

Year | Quarter | Revenue
2024 | Q1      | 1000
2024 | Q2      | 1500

PIVOT後（横持ち）

Year | Q1   | Q2
2024 | 1000 | 1500

👉 比較・分析が一気にしやすくなるのが最大のメリットです。

なぜPIVOTが必要なのか？正規化とレポートのギャップ

データベースは「縦持ち」が正しい

• 更新・追加しやすい
• データ整合性を保ちやすい

しかし分析・レポートは「横持ち」が最適

• 比較しやすい
• 視覚的に理解しやすい

👉 PIVOTはこのギャップを埋めるための技術です。

PIVOTの基本構文と考え方

構造はたった3つ

PIVOTは次の3要素で決まります：

• 行として残す列（キー）
• 列にするカテゴリ
• 集計する値

SQL Serverの基本構文

SELECT *
FROM (
  SELECT seller, product, amount
  FROM Sales
) AS Source
PIVOT (
  SUM(amount)
  FOR product IN ([A], [B], [C])
) AS P

キーワードの意味

• SUM(amount) → セルの値（集計）
• FOR product → 列にする対象
• IN ([A],[B],[C]) → 出力列

👉 INが「結果の列構造」を決める点が重要です。

実務で使えるPIVOT設計のコツ

① 完成形を先に決める

PIVOTで失敗する最大の原因はこれです。

必ず先に決める：

• 行：何を1行とするか
• 列：何を並べるか
• 値：何を比較するか

② 非ピボット列＝グループキー

PIVOTでは：

👉 行に残る列 = 自動的にGROUP BYされる

これを理解していないと：

• 行が増える
• 数値がズレる

という事故が起きます。

③ NULLの意味を理解する

PIVOT後のNULLは：

• ❌ 0ではない
• ✅ データが存在しない

👉 COALESCEで0に変換するかは要件次第

DB別：PIVOTの使い方の違い

SQL Server / Oracle（ネイティブ対応）

• PIVOT構文あり
• 短く書ける
• 可読性が高い

MySQL / PostgreSQL（非対応）

👉 CASE式で代替

SELECT
  Year,
  SUM(CASE WHEN Quarter='Q1' THEN Revenue END) AS Q1,
  SUM(CASE WHEN Quarter='Q2' THEN Revenue END) AS Q2
FROM Sales
GROUP BY Year;

👉 移植性重視ならCASEが最強

動的PIVOT vs 固定PIVOT

固定PIVOT（推奨）

向いているケース：

• 四半期（Q1〜Q4）
• 曜日
• 固定カテゴリ

👉 安定・安全・高速

動的PIVOT（上級者向け）

必要なケース：

• カテゴリが増減
• ユーザー定義項目

注意点（重要）

• SQLインジェクションリスク
• 実行計画キャッシュ効かない
• 列順が不安定

👉 基本は「固定で済むなら固定」

よくある失敗と対策（実務で超重要）

① 集計関数を忘れる

👉 PIVOTは必ず集計が必要

（SUM / COUNT / MAX など）

② INリストのミス

• 値のスペル違い
• クオート忘れ
• 日本語列名

👉 列が出ない・エラーの原因

③ 重複データで数値がズレる

👉 最も危険

対策：

• 事前にCOUNTで検査
• 要件に合う集計関数を選ぶ

④ 粒度設計ミス

👉 「1行＝何か」を決めていない

UNPIVOT：列→行に戻す方法

UNPIVOTとは

• 横持ち → 縦持ちに戻す
• 分析や再集計で使用

重要な注意点

👉 元データには戻らない

理由：

• PIVOTで集計しているため
  
  （情報が失われる）

PIVOT vs CASE：どっちを使うべき？

結論

• 固定レポート → PIVOT
• 複数DB対応 → CASE

参考（公式・信頼情報）

• Microsoft公式（SQL Server PIVOT）
  https://learn.microsoft.com/sql/t-sql/queries/from-using-pivot-and-unpivot
• PostgreSQL公式（tablefunc）
  https://www.postgresql.org/docs/current/tablefunc.html
• MySQL公式（CASE式）
  https://dev.mysql.com/doc/refman/en/control-flow-functions.html

まとめ：PIVOTは「設計」が9割

重要ポイント

• PIVOTは単なる整形ではなく集計処理
• 行・列・値の設計が最重要
• NULLの扱いを理解する
• 固定PIVOTが基本
• 移植性はCASEで担保

👉 SQLスキルの中でも「実務力が出る分野」です。

次にやるべきこと

• 自分の業務データでPIVOTを実装
• CASE版と比較して理解を深める
• 集計粒度の設計を意識する

次のアクション

ここまで読んだ方は、

• データの「見せ方」にこだわれる
• 単なるSQLではなく「意思決定のための設計」ができる

という、エンジニアとして非常に重要な視点を持っています。

私たちは、こうした

👉 データ設計・分析・実装まで一貫して考えられるエンジニア

と一緒に、より価値のあるプロダクトを作りたいと考えています。

もし、

• SQLやデータ設計をもっと深く極めたい
• 実務レベルの分析基盤に関わりたい

と感じたなら、ぜひ一度、私たちのチームを覗いてみてください。

あなたのその「一歩踏み込んだ理解」が、次のキャリアにつながるはずです。