SQL Server の窓関数 LAG / LEAD / 累計 (SUM OVER) を業務帳票で使う3パターン

月次帳票で「前月比」と「累計」を出す。これ、SQL でどう書いてました？？

カーソルで1行ずつ回して前の行を覚えておく。同じテーブルを自分自身に結合して1ヶ月ずらす。俺も昔はそっち側でした。動くんだけど、長い。そして遅い。

どうも、ヒロポンです。

今回は SQL Server の窓関数を、月次帳票の実務で使う3パターンで解説します。LAG で前月比、SUM() OVER で累計、LEAD で翌月比較。構文をただ並べるんじゃなくて、「どこで区切って、どう並べるか」という OVER 句の考え方から積み上げていきます。ここが腹落ちすると、窓関数って一気に手に馴染むんですよね。

前月比・累計・順位みたいな「行をまたいだ計算」を、カーソルや自己結合で書いてた業務SE 向けです。

はじめに: 行をまたいで計算したい、という課題

普通の集計（SUM / GROUP BY）は、行をグループにまとめて1行に畳みます。でも帳票でやりたいのはそっちじゃない。各行を残したまま、他の行を参照した値を横に足すほうです。

「この行の売上と、前の月の売上を比べたい」「ここまでの累計を各行に出したい」。この「行を畳まずに、行をまたいで計算する」やつ。これを解決するのが窓関数（Window Function）です。

GROUP BY は縦に畳む。窓関数は横に列を足す。このイメージの差が腹落ちすると、いい感じに一気に見えてきます。ここが出発点。

窓関数以前: カーソルと自己結合で書いていた

窓関数がなかった頃（や、知らなかった頃）、前月比はこう書いてました。

-- 自己結合で1ヶ月前を引っ張る（古いやり方）
SELECT t1.month, t1.sales,
       t1.sales - t2.sales AS diff
FROM Monthly t1
LEFT JOIN Monthly t2 ON t2.month = DATEADD(MONTH, -1, t1.month);

累計に至っては、カーソルで1行ずつ回して変数に足し込む。そういう処理を書いてた人、多いはず。動くんですよ。ただ、自己結合は行数が増えると重くなる。カーソルは1行ずつなので遅い。しかもコードが長い。

窓関数は、これを1つの OVER 句に置き換えます。まずはその OVER 句の考え方から。

窓関数の基本: OVER 句の PARTITION BY と ORDER BY

窓関数の心臓は OVER 句です。ここで「窓（ウィンドウ）＝計算に使う行の範囲」を決める。決めることは2つだけ。

• PARTITION BY: どこで区切るか（グループの境目）。部門ごと、商品ごと、みたいな
• ORDER BY: 窓の中でどう並べるか。前月比や累計は「時間順」が要る

PARTITION BY を書かなければ全行が1つの窓。書けばグループごとに窓が分かれてリセットされる。ORDER BY は「前」「次」「ここまで」を決めるための並び順。この2つで窓が決まる。全部の窓関数に共通する土台がこれです。

ここまでで、窓関数は「区切って、並べて、その上で計算する」ものだと掴めれば OK。では3パターン、順にいきます。

パターン1: LAG で前月比を出す

LAG(列) は、窓の中で1つ前の行の値を返します。ORDER BY month で月順に並べれば、「1つ前の行 ＝ 前月」になる。

SELECT
    month,
    sales,
    LAG(sales) OVER (ORDER BY month) AS prev_sales,
    sales - LAG(sales) OVER (ORDER BY month) AS diff
FROM Monthly
ORDER BY month;

実行結果（prev_sales に前月・diff に前月差・先頭行は NULL）:

LAG(sales) が前月の売上、sales - LAG(sales) が前月差。あの自己結合が丸ごと1行に消えました！！ 前月比（割合）にしたいなら sales * 1.0 / LAG(sales) OVER (ORDER BY month) です。

部門ごとに前月比を出すなら OVER (PARTITION BY dept ORDER BY month)。部門の境目で LAG がリセットされるので、隣の部門の値を誤って引くこともない。これが PARTITION BY の効きどころ。

（ここまで: LAG = 前の行、ORDER BY で「前」が決まる、PARTITION BY で区切る。この3点。）

パターン2: SUM() OVER で累計を出す（フレームに注意）

累計は SUM(列) OVER (ORDER BY ...)。ただ、ここに窓関数で一番踏む落とし穴が待ってます。

まず正しい書き方から。

SELECT
    month,
    sales,
    SUM(sales) OVER (
        ORDER BY month
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS running_total
FROM Monthly
ORDER BY month;

ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW が「先頭からこの行まで」というフレーム（範囲）の指定。これで行ごとに積み上がる累計になります。

問題は、このフレームを省くとどうなるか。SUM(sales) OVER (ORDER BY month) とだけ書くと、既定のフレームは ROWS じゃなくて RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW になる。

ORDER BY の値が全部ユニークなら、RANGE でも ROWS でも結果は同じ。でも、同じ月が複数行ある（重複がある）と話が変わります。RANGE は「同じ ORDER BY 値の行を全部まとめて」扱う。だから重複月のところで累計が一気にジャンプする。

行単位で1行ずつ積み上げたいなら、必ず ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW を明示。これが累計の鉄則です。「なんか累計の数字が飛んでる？？」と思ったら、まずフレームを疑ってください。

実機で再現（同じ月 2026-03-01 が2行ある時、ROWS 明示版と RANGE 既定版で累計が変わる）:

上の対比、重複月の行で ROWS 版は 270、RANGE 既定版は 300。RANGE は「同じ月の行を全部まとめて」足すので、重複があるとこう変わる。

（ここまで: 累計は SUM() OVER、ただしフレームを ROWS で明示しないと重複月で累計がずれる。）

パターン3: LEAD で翌月と比べる

LEAD(列) は LAG の逆。窓の中で1つ後の行の値を返します。ORDER BY month なら「翌月」ですね。

SELECT
    month,
    sales,
    LEAD(sales) OVER (ORDER BY month) AS next_sales,
    LEAD(sales) OVER (ORDER BY month) - sales AS next_diff
FROM Monthly
ORDER BY month;