SQLのMERGE文の基本と注意点｜安全にUPSERTする実践手順

この記事でわかること（結論）

MERGE文は「一致したら更新、なければ追加」を一つのSQLで表現できる一方で、条件設計と事前確認を誤ると想定外の大量更新を起こしやすい構文です。

MERGEは便利な反面で「一度に多くをやるSQL」なので、まずは安全の作法をセットで覚えるのが近道です。

特に、更新と追加が同時に走るため、どこが更新され、どこが追加されるかを実行前に言語化できない状態で本番投入すると、トラブル時の切り分けが難しくなります。

実行結果の件数や対象キーを説明できないまま実行するのは、WHEREなしUPDATEと同じくらい危険だと考えるのが現実的です。

そのため、MERGEは「書けること」よりも「影響範囲を説明できること」を合格条件にするのが安全です。

影響範囲を説明できる状態とは、ON句の同一性の定義、USINGの入力品質、更新列の範囲がセットで固定できている状態です。

加えて、止める基準が数値で決まっていて、想定外なら中断できる運用になっている状態でもあります。

本記事では、書き方だけでなく本番運用で事故を起こしにくい確認手順まで含めて整理します。

読むだけで終わらないよう、チェック観点を固定して、チームで再利用できる型に落とし込みます。

実装担当が変わっても同じ安全基準で運用できるよう、判断を数値と手順に寄せていきます。

現場でありがちな「とりあえずMERGEを書いて実行してしまう」を避けるために、準備と検証を先に置く構成にします。

安全にUPSERTする3原則

安全にUPSERTするための要点は「ON句をユニークに寄せる」「USING側の重複を潰す」「実行前にSELECTで対象を確定させる」の3つに集約できます。

この3原則は、DBが変わっても考え方としてはほぼ共通なので、手順としてテンプレ化しやすいです。

加えて「更新対象を必要最小限にする」意識を持つと、負荷とリスクを同時に下げられます。

さらに、更新列を絞る、差分がない行は更新しないなど「更新の最小化」を意識すると、ロックや監査ログのノイズも抑えられます。

実行後の復旧を考えるなら、影響範囲を数で把握できる状態にしてから実行するのが基本です。

件数の想定レンジを決めておけば、実行前に異常を検知し、止める判断を迷いにくくなります。

想定レンジは「普段の件数」から決めると実務に乗りやすいので、過剰に厳しい運用にもなりにくいです。

加えて、想定レンジを超えたときに誰が止めるかを決めておくと、緊急時の判断が速くなります。

この記事の前提（対象DBの考え方）

MERGE文の構文や挙動はDB製品やバージョンで差があるため、必ず自分の環境の公式ドキュメントと実行結果で確認する前提で読み進めてください。

特に、同時実行時のロックや競合の挙動は実運用で問題になりやすいので、テスト環境で再現する意識が重要です。

運用上は、同じSQLでも実行タイミングや同時トランザクションの状況で結果が変わる可能性があるため、再現できるテスト条件を用意しておくと安心です。

SQLの例は読み方の補助として捉え、最終的には自分のテーブル定義と制約に合わせて調整してください。

環境差を吸収するために、まずは「自分のDBで何ができるか」を確認し、次に「安全に運用するには何を固定すべきか」を決めていきます。

固定すべきものは、キー定義、入力整形のルール、実行前チェックの手順の3つだと覚えるとブレにくいです。

さらに、実行後に何を確認して合格にするかという事後検証の基準も、あわせて固定すると運用が安定します。

MERGE文とは何か

MERGE文は、ターゲット表とソース（入力）を突き合わせて、条件に一致した行はUPDATE、条件に一致しない行はINSERTという分岐をまとめて実行するためのSQLです。

「更新か追加か」を分けて書く手間を減らせる一方で、条件がズレたときの影響が大きい点が特徴です。

また、ターゲットとソースの突き合わせが前提なので、ソースの品質とON句の妥当性が結果を左右します。

MERGEは「結合してから更新するSQL」だと捉えると、索引や入力整形を軽視しなくなります。

さらに、MERGEはテーブル定義の制約とセットで考えると安全で、ユニーク制約やNOT NULL制約の有無が設計の前提になります。

UPSERTとMERGEの関係

UPSERTは「更新か追加かを自動で切り替える」処理の呼び名で、MERGEはその代表的な実装手段の一つです。

UPSERTを実現する方法は他にもありますが、MERGEは読みやすい形で分岐を一文にまとめられるのが強みです。

一方で、分岐が一文に収まることで「どこが危ないか」を見落としやすいので、確認手順とセットで使うのが前提になります。

ただし、名前が同じでもDBによって書ける構文や推奨される書き方が異なることがあります。

運用ルールとしては「同じ名前だから同じ挙動」と決めつけず、毎回ドキュメントとテストで裏取りします。

裏取りは、構文だけでなく、エラー時の挙動やロックの傾向まで含めて確認すると実務で役立ちます。

MERGEの処理イメージ（一致/不一致）

MERGEは大まかに「ターゲットとソースをON句で突き合わせ、MATCHEDなら更新、NOT MATCHEDなら追加」という流れで動きます。

まずは、ターゲットとソースが結合されるという前提を持つと、実行計画や索引の重要性も理解しやすくなります。

結合が遅いと、それに連動して更新が遅くなり、ロック時間が伸びて競合も起きやすくなります。

ON句で一致条件を作ったあと、WHEN MATCHED THEN UPDATEで更新内容を定義し、WHEN NOT MATCHED THEN INSERTで追加内容を定義するイメージを持つと読みやすくなります。

WHEN句は「どの条件で何をするか」を決めるスイッチなので、増やしすぎると読み間違いも起きやすくなります。

分岐を増やす場合でも、まずはON句とUSINGが安全であることを先に証明してからにします。

レビューでは、分岐の増加よりも、ON句がユニークに寄っているかと、USINGの一意性が担保できているかを優先して確認します。

ここで重要なのは、ON句が「この行は同じ個体だ」と判断する基準になるため、キーが曖昧だと別物を同一視して更新してしまう点です。

同一性の基準が揺れると、更新対象が想定外に膨らみ、結果としてロックや監査の問題にも波及します。

逆に、ON句が厳しすぎて一致しないと、本来は更新すべき行がINSERTに回って重複行を作る原因になります。

重複が発生すると、後続の集計や参照が壊れるだけでなく、復旧のための手作業が増えがちです。

重複は後から気づくことも多いので、INSERT件数の増減を定期的に監視するだけでも効果があります。

INSERT件数が急増したときは、新規データ増加より先にON句と入力整形の崩れを疑うと事故を早期に止めやすいです。

そのため、MERGEは便利さ以上に「一致条件をどう作るか」が核心だと捉えるのが安全です。

安全設計では、まずユニーク制約のあるキーに寄せ、次に入力の整形で揺れを消す順で固めます。

一致条件が決まれば、確認用のSELECTも定型化でき、運用のブレが小さくなります。

定型化できると、実行前に「いつもと違う」変化を見つけやすくなり、止める判断も早くなります。

さらに、定型の確認があると「何を見れば安全か」が共有されるため、属人性が下がります。

MERGE文の基本構文

MERGE文の基本は「MERGE INTO ターゲット USING ソース ON 条件 WHEN …」の骨格で、まずはこの並び順に慣れるのが近道です。

構文は長く見えても役割は分かれているので、ターゲット、ソース、ON、WHENの順に読む癖を付けると理解が速いです。

さらに、UPDATE部分とINSERT部分を別々に読み、最後にON句に戻って整合が取れているかを確認すると見落としが減ります。

読み方を固定しておくと、SQLが長くなってもレビューの観点がブレにくくなります。

読み方の順序は、トラブル対応時にもそのまま原因の切り分け手順として使えます。

MERGE文の基本形

典型的な形は「MERGE INTO 目的の表 AS T USING 入力データ AS S ON T.キー = S.キー WHEN MATCHED THEN UPDATE SET … WHEN NOT MATCHED THEN INSERT (…) VALUES (…)」のように書きます。

読み解くときは、まずON句がユニークな一致条件になっているかを先に確認すると事故を防ぎやすいです。

最初に押さえるべきポイントは、ON句が一致判定であり、UPDATEやINSERTの条件そのものを支配するという点です。

ON句が適切でも、ソースに余計な行が混ざると結果が変わるため、USINGの作り方も同じくらい重要です。

UPDATEのSET句には「更新したい列だけ」を書くのが基本で、ソースと同値を常に書き戻すと不要な更新が増えてロックや監査列の更新を招きます。

同値更新の積み重ねは、負荷だけでなく、差分の追跡や監査ログのノイズにもつながります。

INSERTではターゲットに入れる列を明示し、VALUES側でソースの対応列を並べることで、列追加などの変更にも気づきやすくなります。

列の明示は、将来の保守で「何を入れているか」をレビューしやすくする効果もあります。

また、NOT MATCHEDの分岐は「ターゲットに存在しない」ではなく「ON条件で一致しない」と理解すると、条件設計の事故が減ります。

一致しない理由はキー欠損や正規化不足でも起こるので、INSERTが増えたときは入力側も疑う癖が役に立ちます。

INSERTが増えたときは「本当に新規が増えたのか」「一致条件が崩れたのか」を切り分ける観点を持つと原因特定が速くなります。

切り分けの最短ルートは、ON結合結果をSELECTで出し、想定外のマッチや想定外の非マッチがないかを見ることです。

さらに、想定外のマッチがある場合はON句の甘さを疑い、想定外の非マッチがある場合は入力整形不足を疑うと整理しやすいです。

よく使う派生（必要最小限）

実務では「更新は特定条件のときだけ」「更新列は差分があるときだけ」「不要な更新を避ける」などの派生を使う場面が多いです。

派生は便利ですが、条件が増えるほどテスト観点も増えるので、導入時は最小限に抑えるのが安全です。

例えば、更新対象を絞るためにWHEN MATCHED AND 条件 THEN UPDATEのようにAND条件を追加し、更新の発火条件を明確にします。

発火条件を明確にすると、想定外の更新件数になったときに原因の切り分けもしやすくなります。

差分更新を意識するなら、SET対象を最小限にしつつ「同値なら更新しない」条件を併用して、想定以上の更新件数にならないよう制御します。

差分更新は性能改善にもなりますが、まずは「安全に件数が読める」ことを優先する方が実務では効きます。

ただし派生を増やすほど読みづらくなるため、まずは基本形で安全に動く条件を固めてから最小限だけ追加するのが無難です。

レビューでは、ON句とUSING整形の方針が説明できるかを合格ラインにするとブレにくいです。

導入初期は、派生を入れる前に「基本形＋確認手順」で安定運用できることを先に証明します。

安定運用ができれば、必要な派生だけを選んで追加でき、SQLが肥大化しにくくなります。

さらに、派生を追加するときは「追加によって何が減るのか」を一文で説明できると、目的のない複雑化を避けられます。

MERGE文が向いている場面

MERGEは「同じキーで更新か追加を切り替える」処理を繰り返す場面で威力を発揮します。

扱うデータがマスタ系で、キーが安定しているほどMERGEのメリットが出やすいです。

キーが安定していない場合は、MERGE以前にキー設計や運用ルールの見直しが必要になります。

キーが安定していない状態でMERGEを導入すると、INSERT増加と誤更新が同時に起きやすくなります。

そのため、まずキーが安定しているかを確認し、安定していないなら運用ルールを先に整えるのが安全です。

バッチ取り込みでのマスタ同期

外部システムから日次で取り込むマスタの同期では、差分行だけ更新し、新規行だけ追加するニーズが多く、MERGEは構文として相性が良いです。

取り込みが失敗して再実行が必要になる運用では、同じ入力で同じ結果に収束する設計が特に重要です。

再実行が起きる運用でも、ON句と入力整形が正しければ同じ結果に収束しやすく、手順の単純化につながります。

ただし、入力が途中で欠損したり並び替えられたりしても結果が変わらないよう、検証手順を一緒に作る必要があります。

また、再実行時にINSERTが増えないことを確認できるよう、実行前後の件数比較を手順に含めます。

再実行を想定するなら、更新件数と追加件数が「同じ入力なら同じになる」ことをテストで確認すると安心です。

さらに、再実行時の想定件数が明確なら、異常検知も自動化しやすくなります。

差分更新・集計結果の反映

集計テーブルに対して、集計結果をキーで突き合わせて更新するような処理でもMERGEは使いやすいです。

集計結果は同じキーが複数行に割れやすいので、事前にユニーク化する工程がほぼ必須になります。

ただし、集計側のソースが重複しやすい設計だと多重マッチを起こすため、USING側のユニーク化が必須になります。

ユニーク化の基準は「どの行を正とするか」なので、ビジネスルールとして固定しておくと揉めにくいです。

さらに、集計ロジックの変更でキーの粒度が変わるとMERGE結果が変わるため、変更時のテスト手順も合わせて用意します。

集計ロジックの変更時は、更新件数と追加件数がどのように変わるかを事前に見積もると、想定外の増加を止めやすいです。

加えて、集計の前提が変わった場合にUSINGが重複しやすくなることがあるので、重複検知は常に入れておくと安心です。

UPDATEとINSERTを分ける場合との違い

MERGEは一文で完結する反面、検証や事故防止の観点では「分けて書く方が安全」なケースもあります。

便利さと安全性のトレードオフを理解して、ケースごとに選ぶのが現実的です。

運用の成熟度が低い段階では、分離で検証しやすい形を優先する方が事故が減りやすいです。

安全性を優先するなら、最初からMERGEにこだわらず、段階実行できる設計を選べるのが強みになります。

可読性・検証容易性の違い

UPDATEとINSERTを分けると、それぞれの対象行をSELECTで確認しやすく、更新だけ、追加だけを段階的に実行する運用も取りやすいです。

段階実行ができると、想定外の件数になった時点で止められるため、被害が小さくなります。

一方、MERGEは一度に分岐が走るため、ON句を誤ると更新と追加の両方で意図しない影響が出やすいという特徴があります。

特に、ON句が甘い状態でMERGEを実行すると、更新と追加が同時に膨らみ、復旧が難しくなりがちです。

そのため、初導入や影響範囲が大きい処理では「まず分離で安全に動く形を作り、慣れてからMERGEに統合する」進め方も現実的です。

分離で運用が安定したあとに統合すれば、MERGEの導入理由も明確になり、レビューも通りやすくなります。

分離から統合する際は、更新対象と追加対象のSELECT確認がMERGEでも再現できるようにしておくと移行がスムーズです。

統合後も、更新対象と追加対象が読み取れる確認SQLを残しておくと、運用が継続しやすくなります。

性能・ロック・競合の観点

性能面はDBや索引設計に依存しますが、MERGEはターゲットとソースの結合が前提なので、ON句のキーに適切な索引がないと一気に重くなります。

結合が重い状態で更新が走ると、処理時間のブレが大きくなり、運用の見積もりが難しくなります。

また、更新件数が膨らむとロックが広がりやすく、同時実行の競合が起きたときに想定外の待ちやデッドロックに発展することがあります。

同時実行があるなら、ロックの粒度と実行時間をテストで把握し、ピーク時間を避ける配慮も必要です。

更新を最小限にし、必要ならバッチ分割やトランザクション設計で影響範囲を制御する視点が重要です。

影響範囲を制御できると、失敗時の切り戻しも現実的になり、心理的な不安も減ります。

競合が起きる環境では、テストでデッドロックの再現を試みるだけでも、危ない条件を早めに見つけられます。

さらに、処理時間が伸びるとロックが伸びるので、性能は安全性の一部だと捉えると設計が変わります。

採用判断チェック（3〜5項目）

MERGEを採用するか迷ったら「キーが明確でユニークか」「USINGをユニークにできるか」「事前確認とロールバック手順があるか」「段階実行が必要か」を基準に判断します。

加えて、監査や差分追跡の要件が強い場合は、分離の方が運用ルールを作りやすいこともあります。

判断に迷うときは、安全側として分離で運用できるかを先に検討すると、後から戻りにくい事故を避けられます。

さらに、チームのレビュー体制や夜間バッチの監視体制など、運用の現実に合わせて選ぶのが成功の近道です。

MERGE文で注意したいポイント

ここからは事故が起きやすい論点を「何が起きる→なぜ→どう防ぐ」の順で整理します。

どれも「想定外の件数」がシグナルになるので、件数を見て止める運用が前提になります。

件数は最も簡単に取れる安全指標なので、まず件数を見て止める仕組みを作るのが近道です。

加えて、件数に加えて対象キーの範囲も見られると、異常の種類を切り分けやすくなります。

ON句の条件を甘くしない

ON句が甘いと、別の行まで一致扱いになって更新され、想定外の大量更新や誤更新が起きます。

大量更新は一度発生すると、影響の調査と復旧に時間がかかり、業務停止の原因にもなります。

原因は「ユニークでない列をキーにしている」「複合キーの片側だけで一致させている」「大文字小文字や前後空白の揺れを吸収しようとして条件を広げすぎる」などが典型です。

条件を広げる前に、入力側で正規化する方が安全で、ON句をシンプルに保ちやすいです。

対策は「ターゲットでユニーク制約がある列の組み合わせに寄せる」「ソース側を正規化してからONで突き合わせる」「同一性の定義を変更しない」という順で固めることです。

ユニーク制約がない場合でも、まずユニークに相当する論理キーを決めてからMERGEを考えるのが安全です。

実行前には、ON句で結合した結果をSELECTで可視化し、どのキーがどの行に当たるかを目で確認できる形にしておくと安全性が上がります。

この確認ができないまま本番実行するのは、WHEREなし更新に近いリスクを抱えることになります。

確認時には、結合結果の重複やNULLを同時に見ると、後段のトラブルをまとめて潰しやすいです。

さらに、結合結果の件数がソース件数と整合するかを確認すると、異常に気づきやすくなります。

USING側に重複データを持たせない

USING側に同じキーの行が重複していると、ターゲット1行に対して複数行がマッチし、多重マッチのエラーや予期しない更新の原因になります。

エラーで止まる場合でも、途中まで更新が走る設計だと影響が残ることがあるため注意が必要です。

原因は「取り込み元が重複を含む」「結合や集計の途中でキーが崩れている」「最新行を選ぶつもりが選べていない」などです。

最新行を選ぶなら、タイムスタンプや優先順位など、判定基準を仕様として固定する必要があります。

対策は「USINGを作る段階でキーごとに一意になる形に整形する」「重複検知用のSELECTを用意してゼロ件を確認してから実行する」「最新行の選択基準を固定する」という手順にします。

整形はMERGEの中で頑張るより、事前に作ったUSINGを別SQLで検証できる形にする方が安全です。

重複検知は「キーでGROUP BYして件数が2以上を抽出する」だけでも効果があり、運用ルーチンに組み込みやすいです。

検知がゼロ件であることを確認してからMERGEを実行するだけで、事故率は大きく下がります。

運用では、重複検知がゼロ件である証跡を残すと、後日の監査や調査でも説明がしやすくなります。

さらに、重複が出たときの対処方針を決めておくと、緊急時でも安全側に倒しやすいです。

更新対象を必要最小限にする

更新対象列が多いと、同値更新が増えてロックが広がり、更新日時や監査列の変更を誘発して差分追跡が難しくなります。

不要な更新は性能を落とすだけでなく、監査ログやレプリケーションの負荷を増やすこともあります。

原因は「とりあえず全列をSETしている」「比較をせず常に書き戻す」「不要な列まで入力に含めている」ことが多いです。

入力に含める列を減らすと、USING側の検証も単純になり、レビューもしやすくなります。

対策は「業務的に変わり得る列だけをSETする」「差分があるときだけ更新する条件を併用する」「監査列はDBの仕組みに任せる」などで更新範囲を縮めます。

差分条件を入れる場合は、NULLの扱いで意図せず更新が走らないかも合わせて確認します。

更新件数が少ないことは安全性のサインになりやすいので、件数が増えたら止める基準も合わせて作ります。

止める基準は「普段の件数」から決めると実用的で、運用で迷いにくくなります。

更新列を絞ると、変更履歴の読みやすさも上がるので、運用担当の心理的負荷も下がります。

さらに、更新列を絞ると「どの項目が変わったか」が見えやすくなり、障害調査でも役に立ちます。

本番前にSELECTで対象確認を行う

MERGEは実行してから気づくと手遅れになりやすいので、実行前のSELECT確認を手順として固定するのが最重要です。

事前確認は面倒に見えても、復旧にかかる時間と比べれば圧倒的に安い投資です。

原因は「WHEREなし更新と同じで、実行前に対象が見えていない」「入力やON句の揺れで件数が変わるのに検知できていない」ことです。

確認を省略すると、たまたまうまくいった経験が油断につながり、次の事故を招きやすくなります。

対策は「結合結果をSELECTで出す」「更新対象と追加対象を分けて件数を見る」「想定件数のレンジ外なら中断する」という確認を必須にします。

確認は件数だけでなく、代表的なキーを数件抜き出して目視するだけでも検知力が上がります。

止める基準は「更新件数が想定より多い」「追加件数が急増している」「キーの欠損がある」など、数値で判断できる形にしておくと迷いが減ります。

運用で基準を守れるよう、担当者が変わっても同じ手順で確認できる形にするのが理想です。

対象確認は一度テンプレ化してしまえばコストが下がるので、最初に仕組み化しておく価値があります。

さらに、確認SQLの結果を保存できる形にしておくと、後日の再現や説明がしやすくなります。

安全にUPSERTするための実践ポイント

注意点を踏まえたうえで、日々の運用に落とし込める「型」を作ると、担当者が変わっても事故が減ります。

型があると、レビュー観点が固定され、運用の属人化も減ります。

型は「確認の順番」を固定するものなので、最初は厳格に守り、慣れてから最小化するのが安全です。

型を守ることで、たとえSQLが変わっても「安全確認の手順」は変わらないという状態を作れます。

事前確認の流れを決めておく

おすすめの流れは「入力を整形してUSINGを確定→重複検知がゼロ件→ON結合結果を確認→更新対象件数と追加対象件数を確認→MERGE実行→実行後に件数と差分を再確認」です。

この流れは、MERGEを実行する前に「入力の品質」と「一致判定の妥当性」を確定させるための手順です。

この型のポイントは、MERGEそのものより先に「USINGが正しいか」と「ONでどこに当たるか」を検証してしまうことです。

検証が終わっていれば、MERGEの実行は「最後の確定操作」になり、心理的にも安全になります。

運用では、確認用SQLを毎回書き直さずに済むよう、テンプレ化してチェック項目として残すと継続しやすくなります。

テンプレに「想定件数」と「前回実績件数」を書ける欄を作ると、異常に気づきやすくなります。

さらに、異常時の連絡先や中断判断の責任者を決めておくと、現場で迷いにくくなります。

加えて、実行後の差分確認もテンプレ化すると、成功と失敗の境界が明確になります。

例外ケースを考慮する

例外は「キーがNULLや空文字」「同一人物のキー変更」「削除フラグの扱い」「入力に不正値が混ざる」などで、放置するとON句の一致判定が崩れます。

例外は少数でも、1件のズレが大きな更新件数のズレを生むことがあるため軽視できません。

対策は「キー欠損を弾く」「キー変更は別手順にする」「削除はMERGEでやるのか別途でやるのかを決める」「入力バリデーションの位置を固定する」など、例外を仕様として切り分けることです。

仕様として切り分けると、MERGEの条件式をシンプルに保ち、テストの漏れも減らせます。

例外処理をMERGEの条件式に詰め込みすぎると可読性が落ちるため、まずは入力段階で整形し、MERGEはシンプルに保つ方が安全です。

「入力で整形できること」と「DBで保証すべきこと」を分けると、設計の責務が明確になります。

例外が増えてきたら、MERGEに追加するのではなく、前処理で分岐させる方が総合的に安全なことが多いです。

さらに、例外を前処理に寄せると、MERGEのテストケースが減り、品質が上げやすくなります。

トランザクションと影響範囲ログ

本番では「ロールバックできる状態で実行する」「更新件数と追加件数をログとして残す」だけでも復旧の難易度が大きく下がります。

ログがあると、異常が起きたときに原因の切り分けと影響範囲の特定が速くなります。

実行直後に件数が想定外なら即座に中断できるよう、影響範囲の指標を先に決めておくと判断が速くなります。

指標は更新件数だけでなく、対象キーの範囲や処理時間も含めると運用が安定します。

ログは「後で読む」だけでなく「実行直後に確認する」用途もあるので、見やすい形で残すことが重要です。

加えて、ログがあると「どのタイミングで変化したか」が追えるため、運用改善にもつながります。

MERGE文の使用例

ここでは社員マスタを例に、ON句の厳格化、USING整形、更新列の絞り込みを同時に意識する考え方を示します。

例はあくまで型の理解が目的なので、自社のキー設計や監査要件に合わせて読み替えてください。

例を自社に当てはめるときは、まずユニーク制約の位置と、入力の一意性がどこで保証されるかを確認します。

加えて、入力の到着タイミングや欠損時の扱いなど、運用条件も合わせて確認するとズレが減ります。

前提（キー・制約・入力データ）

社員マスタのユニークキーを社員IDとし、入力データも社員IDが必ず埋まっている前提で設計すると安全に寄せやすいです。

ユニークキーが決まっていれば、ON句の設計が迷いにくく、確認SQLも作りやすくなります。

入力側は「社員IDが一意であること」「同一社員IDの重複がないこと」「更新対象列が明確であること」を満たす形に整形してからMERGEに渡します。

入力整形は、重複排除だけでなく、空白や表記揺れの正規化も含めて考えると事故が減ります。

前提が崩れるとON句が正しくても結果が崩れるので、前提のチェックを先に用意するのが安全です。

さらに、社員IDが欠損した場合の扱いを決めておくと、INSERTの増加や誤更新を避けやすくなります。

社員マスタを更新・追加する例

ON句は「ターゲットの社員IDとソースの社員IDが一致する」を基本にし、ここを曖昧にしないことが最優先です。

社員ID以外の情報で一致させたくなる場合でも、まずはキー変更の扱いを別手順に切り出す方が安全です。

更新は「氏名や部署など変わり得る列」に限定し、監査用の更新日時などは不要に書き換えない設計にすると副作用が減ります。

更新列を限定すると、件数が増えた場合でも「何が原因で増えたか」の切り分けがしやすくなります。

追加は「社員IDを含む必要列を明示してINSERTする」形にし、列の追加や仕様変更があったときにレビューで気づける形にします。

INSERT列を明示すると、入力の欠損がそのままNULLで入る事故にも気づきやすくなります。

実行前には、結合結果をSELECTして「この社員IDは更新対象」「この社員IDは追加対象」という分類と件数を確認し、想定外ならMERGEを実行しません。

実行後にも、更新件数と追加件数が事前確認と一致するかを見て、運用の型が守れているかを検証します。

例のポイントは、MERGEそのものより「事前確認と事後検証」を同じ粒度で用意することです。

さらに、例を通して「確認できないなら実行しない」という判断基準を体に染み込ませるのが狙いです。

よくある質問（Q & A）

最後に、MERGEを調べたときに頻出する疑問を短く整理します。

疑問点は「安全に運用できるか」に直結するので、曖昧なまま本番に持ち込まないことが大切です。

疑問が残る場合は、実装に進むより先にテストで挙動を確認するのが最短です。

加えて、疑問点をそのまま手順のチェック項目に落とすと、運用の抜け漏れが減ります。

MERGE文はすべてのデータベースで同じように使えますか？

同じMERGEという名前でも構文やサポート範囲、ロックや同時実行時の挙動に差があるため、必ず対象DBの公式情報で確認してください。

特に、例外時の挙動や競合時の仕様は実装差が出やすいので、テスト環境で実行して確かめるのが安全です。

同じSQLでもバージョンアップで挙動が変わる可能性があるため、変更時は必ず回帰テストを行います。

さらに、推奨される回避策が変わることもあるので、運用ルールは固定しつつ定期的に見直します。

MERGE文を使えば必ず安全ですか？

MERGEは便利なだけで安全を保証する仕組みではなく、ON句の厳格さ、USINGのユニーク化、事前SELECT確認の3点が揃って初めて安全性が上がります。

安全性は構文ではなく運用で作るものなので、確認手順を省略しないことが最重要です。

安全を担保するのは「止める基準」を守れることなので、件数レンジと中断判断を最初に決めておきます。

さらに、異常時にロールバックできる状態で実行することで、被害を最小化できます。

INSERTとUPDATEを分けた方がよい場合はありますか？

対象が大きくて段階実行や検証を重視したい場合や、条件が複雑でレビューしやすさを優先したい場合は、分離した方が事故が減ることがあります。

分離で件数と対象を確定できるなら、そのまま運用した方が総合的に安全なこともあります。

分離は実装が増える代わりに検証ポイントが明確になるので、運用体制に合わせて選ぶのが現実的です。

さらに、監査要件が厳しい場合は、分離でログを取りやすい方が説明責任を満たしやすいことがあります。

まとめ

MERGE文はUPSERTを簡潔に書ける反面、ON句や入力の重複、事前確認の不足がそのまま事故につながる構文です。

事故の多くは「一致条件」と「入力品質」と「事前確認」のどれかが欠けたときに起きます。

まずは「ON句をユニークに寄せる」「USING側の重複を潰す」「実行前にSELECTで対象を確定させる」の3原則を運用の型として固定してください。

型を固定すると、担当者が変わっても同じ観点で確認でき、レビューも短時間で済みます。

小さな件数で検証してから本番に適用し、件数ログとロールバック可能な手順を用意しておくと、UPSERTを安全に継続運用できます。

本番での一回の成功より、同じ手順で何度でも安全に回せることをゴールにすると、MERGEの便利さを安心して活かせます。

安全な運用のゴールは「ミスが起きない」ではなく「ミスが起きても被害を小さくして戻せる」状態を作ることです。

その状態を作るために、MERGEは便利な道具として使い、確認とログの仕組みを先に整えるのが最短ルートです。

さらに、仕組みが整っていれば、新しいメンバーが参加しても同じ手順で安全に実行でき、チーム全体の品質が底上げされます。

最後に、MERGEは万能ではないので、迷ったら分離で安全に運用できるかを検討し、無理に統合しない判断も持っておくと安心です。