【2026年8月最新】SQLのBETWEEN句で範囲指定する方法まとめ｜境界値・NOT BETWEEN・日付型の注意点

「SQLで範囲指定をしたいけど、BETWENの境界値って両端含むの？含まないの？」——この記事にたどり着いた方は、そんな疑問を持っているはずです。

BETWEEN句は、SQLの中でも特に「知っているつもり」で書かれがちな構文です。数値の範囲指定なら問題になりにくいのですが、日付型で使うと、時刻部分の扱いによって「範囲の最終日のデータが抜け落ちる」という事故が起きやすく、実務でも定番のバグパターンになっています。

この記事では、BETWEEN句の基本的な使い方から、境界値の正確な挙動、日付型で起きやすい落とし穴、文字列で使うべきでない理由、INとの使い分け、そしてClaude Codeを使ったSQLレビューの活用方法まで整理します。

この記事を最後まで読むと、次の6つが明確になります。

01 OVERVIEW BETWEEN句の基本構文と動作 「範囲指定」をシンプルに書くための基本構文

BETWEEN句は、SQLで「ある値の範囲内にあるかどうか」を条件にする際に使う演算子です。基本構文は以下の通りです。

[カラム名] BETWEEN [最小値] AND [最大値]

たとえば、会員テーブルからidが2〜4のレコードを取得したい場合、以下のように書きます。

SELECT * FROM user WHERE id BETWEEN 2 AND 4;

-- 上記は以下と全く同じ意味・同じ実行計画になる
SELECT * FROM user WHERE id >= 2 AND id <= 4;

この2つのクエリは実行結果も実行計画（インデックスの使われ方）もほぼ同じです。つまりBETWEENは「>= AND <=」の組み合わせを読みやすく書くための糖衣構文（シンタックスシュガー）と理解しておくと、後述する境界値の挙動も自然に理解できます。

1-1. なぜBETWEENを使うと読みやすくなるのか

">= AND <="の組み合わせでも同じ結果は得られますが、条件が複雑になるクエリでは「どこからどこまで」という範囲であることが一目で伝わるBETWEENの方が可読性が高いとされています。特に他のエンジニアがレビューする際、意図が伝わりやすいというメリットがあります。

1-2. BETWENとインデックスの関係

BETWENを使うと処理が遅くなるのではないか、と心配される方もいますが、実際には「>= AND <=」の組み合わせとまったく同じ実行計画になるため、それ自体が速度低下の原因になることはありません。対象カラムに適切なインデックスが張られていれば、BETWENの条件でもインデックス範囲スキャンが使われ、高速に絞り込みが行われます。

注意が必要なのは、カラムに関数を適用してからBETWENを使うケースです。たとえば前述のDATE(order_date) BETWEEN ‘...’ AND ‘...’のように関数でカラムを加工すると、多くのデータベースではインデックスが効かなくなり、全件走査になってしまうことがあります。パフォーマンスを重視する場面では、関数を使わずに素のカラムのままBETWENの対象にできるよう、データ設計の段階で工夫しておくのが理想です。

1-3. 業務でよく使われるBETWENの具体例

BETWENは開発者だけのものではなく、営業・人事・経理の集計レポートでも頻繁に登場します。非エンジニアの方でも、依頼している集計処理の裏側でBETWENが使われているケースは多いはずです。

業務シーン	BETWENの使用例	意図
営業レポート	order_date BETWEEN '2026-08-01' AND '2026-08-31'	特定月の受注データだけを集計したい
人事評価	tenure_years BETWEEN 3 AND 5	勤続3〜5年の社員を対象に評価制度を見直したい
価格戦略	price BETWEEN 1000 AND 3000	特定の価格帯に属する商品の売上を分析したい
与信管理	credit_score BETWEEN 600 AND 750	特定の信用スコア帯の顧客を抽出したい

こうした集計依頼を出す立場の方にとっても、「BETWENは両端を含む」「日付型なら時刻の扱いに注意」という2点さえ知っておけば、エンジニアから上がってきた集計結果の妥当性を自分の目でも確認できるようになります。

02 BOUNDARY VALUES 境界値の扱いとNOT BETWEEN 「両端を含む」という最重要ポイントを正確に理解する

BETWEEN句を理解するうえで、絶対に外せないのが境界値（最小値・最大値そのもの）が範囲に含まれるかどうかという点です。

-- id BETWEEN 2 AND 4 は id=2, id=3, id=4 のすべてを含む
SELECT * FROM user WHERE id BETWEEN 2 AND 4;
-- 結果: id=2, 3, 4 のレコードすべて（3件）が返る

2-1. NOT BETWEENの挙動

BETWENの前にNOTを付けると、範囲の外側（境界値も含めて除外）を取得できます。

-- id が 2〜4 の範囲「以外」を取得（2,3,4は含まれない）
SELECT * FROM user WHERE id NOT BETWEEN 2 AND 4;

2-2. 最小値と最大値の順序を間違えるとどうなるか

BETWEEN A AND B の A（最小値）が B（最大値）より大きい場合、多くのデータベース（MySQL、PostgreSQL等）では自動的に入れ替えてくれず、該当レコードなし（0件）という結果になります。

-- 最小値と最大値が逆になっている例（多くのDBで0件になる）
SELECT * FROM user WHERE id BETWEEN 4 AND 2;

2-3. AND/ORと組み合わせる書き方

BETWENは単独で使うだけでなく、他の条件とAND/ORで組み合わせることも多くあります。組み合わせる際は括弧で条件のまとまりを明示することが可読性・安全性の両面で重要です。

-- 価格が1000〜5000円 かつ カテゴリがA
SELECT * FROM product
WHERE price BETWEEN 1000 AND 5000
  AND category = 'A';

-- 価格帯Aの範囲 または 価格帯Bの範囲（括弧で明示）
SELECT * FROM product
WHERE (price BETWEEN 1000 AND 3000)
   OR (price BETWEEN 8000 AND 10000);

03 DATA TYPES 数値・日付・文字列それぞれでの使用方法 BETWEENは複数のデータ型で使える

BETWENは整数だけでなく、日付型・文字列型でも使用可能です。ただし、データ型によって注意点が大きく異なります。

データ型	使用可否	注意点
数値（int, decimal等）	◎ 問題なく使える	境界値が両端含むことだけ意識すればよい
日付・日時（DATE, DATETIME等）	△ 使えるが注意が必要	時刻部分の扱いで最終日のデータが漏れることがある（次章で詳説）
文字列（VARCHAR等）	△ 使えるが非推奨	文字コード順の比較になり直感と異なる結果になりやすい

-- 数値での使用（最も安全で分かりやすい）
SELECT * FROM product WHERE price BETWEEN 1000 AND 5000;

-- 日付での使用
SELECT * FROM orders WHERE order_date BETWEEN '2026-08-01' AND '2026-08-31';

-- 文字列での使用（非推奨。次章・次々章で理由を解説）
SELECT * FROM user WHERE name BETWEEN 'A' AND 'M';

このように構文自体はどのデータ型でも共通ですが、「日付型」と「文字列型」は落とし穴が多いため、次の2つの章でそれぞれ詳しく解説します。

3-1. カラム同士をBETWENで比較する

BETWENの最小値・最大値には、固定の数値や日付だけでなく別のカラムの値を指定することもできます。たとえば「セール期間中の商品だけを抽出したい」といったケースです。

-- 「今日の日付」がセール開始日と終了日の間に入っている商品を抽出
SELECT * FROM product
WHERE CURDATE() BETWEEN sale_start_date AND sale_end_date;

-- 価格が割引下限〜上限の範囲に収まっている商品を抽出
SELECT * FROM product WHERE price BETWEEN discount_min AND discount_max;

このように、比較対象を固定値でなく別カラムにする書き方は、キャンペーン期間の判定や割引条件の判定など、実務のバッチ処理やレポーティングで頻繁に登場します。基本構文は同じですが、比較対象がすべてカラムになるため、NULLが混ざっていないかの確認が重要になります。sale_start_dateやsale_end_dateがNULLのレコードは、BETWENの判定自体が不定（結果に含まれない）になる点に注意してください。

04 DATE PITFALL 日付型で特に注意すべき「時刻切り捨て」の罠 実務で最も多い「最終日のデータが抜け落ちる」事故の正体

BETWENの落とし穴の中でも、実務で最も頻繁に発生するのが日付型（特にDATETIME・TIMESTAMP）での境界値の扱いです。

4-1. なぜ最終日のデータが抜け落ちるのか

たとえば「2026年8月の注文データを全件取得したい」という要件で、以下のようなクエリを書いたとします。

SELECT * FROM orders WHERE order_date BETWEEN '2026-08-01' AND '2026-08-31';

order_dateカラムがDATE型（日付のみ）であれば、このクエリは問題なく8月1日〜8月31日の全データを取得できます。しかし、order_dateがDATETIME型（日時）の場合、状況が変わります。

4-2. 正しい書き方：3つの回避策

この事故を防ぐには、主に以下の3つの方法があります。

回避策	書き方の例	特徴
上限に時刻を明示する	BETWEEN '2026-08-01' AND '2026-08-31 23:59:59'	直感的だが、ミリ秒以下のデータが漏れる可能性がわずかに残る
翌日の0時未満で条件を切る（半開区間）	order_date >= '2026-08-01' AND order_date < '2026-09-01'	最も安全。時刻の精度に関わらず取りこぼしがない
日付関数で日付部分だけを比較する	DATE(order_date) BETWEEN '2026-08-01' AND '2026-08-31'	分かりやすいが、日付関数を使うとインデックスが効きにくくなる場合がある

4-3. タイムゾーンのズレによる二次的な落とし穴

日付範囲の指定では、もう一つ見落とされがちな要因としてタイムゾーン（時差）の扱いがあります。データベース側がUTC（協定世界時）で日時を保存し、アプリケーション側で日本時間（JST、UTC+9）に変換して表示している構成は珍しくありません。

この問題は、BETWEN自体の仕様というよりシステム全体の日時管理の設計に起因するものですが、「日付範囲の集計結果がなぜかズレる」という相談の多くは、時刻切り捨てとタイムゾームのどちらか（あるいは両方）が原因になっているケースがほとんどです。

4-4. 週次・年次集計での応用と注意点

月次だけでなく、週次や年次の集計でも同様の考え方が適用できます。たとえば「今週分のデータ」を集計する場合も、週の開始日と終了日を半開区間で指定するのが安全です。

-- 今週（月曜始まり）のデータを安全に取得する例
SELECT * FROM orders
WHERE order_date >= '2026-08-03'
  AND order_date <  '2026-08-10';

-- 年次集計も同様に「翌年1月1日未満」で区切るのが安全
SELECT * FROM orders
WHERE order_date >= '2026-01-01'
  AND order_date <  '2027-01-01';

週次・年次いずれの場合も、「含めたい最後の瞬間」を境界値として指定するのではなく、「含めたくない次の期間の開始点未満」で区切るという考え方に統一しておくと、月末・週末・年末のいずれでも同じ思考パターンで安全に書けるようになります。

05 STRING CAUTION 文字列でBETWEENを避けるべき理由 「わかりやすそう」に見えて実は危険なパターン

BETWENは文字列に対しても構文上は使用できますが、実務では避けるのが無難とされています。理由は、文字列の比較が文字コード順（バイト列としての大小関係）で行われるためです。

SELECT * FROM user WHERE name BETWEEN 'A' AND 'M';
-- 'Apple' は範囲内、'Mike' は範囲外（辞書順で'M'より大きいため除外される）
-- しかし 'apple'（小文字始まり）は文字コード上 'M' より後になり範囲外になることがある
-- （データベースの照合順序=collationの設定によって挙動が変わる）

つまり、文字列でBETWEENを使うと「見た目は範囲指定しているつもりが、DBの設定（照合順序）次第で結果が変わる」という不安定さを抱えることになります。特に日本語（ひらがな・カタカナ・漢字）が混ざるカラムでは、想定通りの順序にならないことがよくあります。

特に日本語の氏名・住所・商品名を対象にBETWENでの範囲指定を検討している場合は、「五十音順で本当にA〜M相当が取得できているか」を必ず実データで検算してください。ひらがな・カタカナ・漢字・英数字が混在するカラムでは、期待する五十音順にならないことが多く、見た目のシンプルさに反して事故リスクが高い使い方だと理解しておくのが安全です。

06 IN VS BETWEEN INとの違いと使い分け 似ているようで役割がまったく異なる2つの演算子

BETWENとよく一緒に語られる演算子にINがあります。どちらも条件を簡潔に書ける点は似ていますが、役割は明確に異なります。

演算子	用途	書き方の例
BETWEEN	連続した範囲（以上〜以下）を指定したいとき	price BETWEEN 1000 AND 5000
IN	飛び飛びの特定の値のリストを指定したいとき	status IN ('未対応', '対応中', '保留')

-- BETWEEN: 連続した範囲
SELECT * FROM product WHERE price BETWEEN 1000 AND 5000;

-- IN: 飛び飛びの値のリスト
SELECT * FROM orders WHERE status IN ('未対応', '対応中', '保留');

-- 誤用例：連番でないIDの範囲指定にBETWEENを使うと、欠番があっても気づきにくい
SELECT * FROM user WHERE id BETWEEN 100 AND 105;
-- id=100〜105のうち欠番（削除済み等）はそもそも存在しないため単に該当なしになるだけで、
-- エラーにはならず「本当に全件揃っているか」を見落としやすい

6-1. NOT INのNULL罠にも触れておく

BETWENとIN・NOT BETWENとNOT INは似た関係にありますが、NOT INにはBETWENにはない別の罠があるので触れておきます。NOT INのリストの中に1つでもNULLが含まれていると、そのクエリ全体が0件を返してしまうという、SQL特有の「三値論理（TRUE/FALSE/UNKNOWN）」に起因する挙動です。

-- リストの中にNULLが1つ混ざっているだけで、想定通りに動かなくなる例
SELECT * FROM user WHERE status NOT IN ('退会済み', NULL);
-- 結果: 0件（NULLの影響で全件が対象外になる）

07 COMMON MISTAKES 実務でよくある間違いパターン ここまでの内容を「事故のパターン集」として総整理

最後に、実務でBETWENを使う際によく発生する間違いを一覧にまとめます。

間違いパターン	症状	対策
DATETIME型の上限に日付だけ指定	最終日のデータが抜け落ちる	半開区間（< 翌日）で書くか、時刻まで指定する
最小値と最大値の順序ミス	エラーは出ないが結果が0件になる	プログラム側で組み立てる際は必ず順序を検証する
文字列でのBETWEEN使用	照合順序次第で想定と異なる結果になる	英数字の規則的な文字列以外は避ける
境界値を含む・含まないの誤解	想定より1件多い/少ない結果になる	BETWENは両端を含むことを必ず確認する
連番でない値の範囲指定	欠番があっても気づかない	IDの連続性を前提にした設計をしない

これらはいずれも「エラーにはならないが、結果が意図と異なる」というサイレントなバグである点が共通しています。BETWENは書き方自体が簡単なだけに、こうした落とし穴が見過ごされやすい構文だと言えます。

7-1. レビューで確認すべきチェックポイント

社内でSQLレビューのルールを作る場合、BETWENに関しては以下の観点を確認項目に加えておくと、事故の再発防止に役立ちます。

08 AI CODING 【独自】SQLレビューでのAIコーディング活用 こうした「地味な落とし穴」こそAIレビューが効く領域

ここまで紹介してきたBETWENの落とし穴——特に「日付型の時刻切り捨て」「境界値の順序ミス」のようなサイレントなバグは、実はClaude CodeのようなAIコーディングエージェントによるレビューが効果を発揮しやすい領域です。

弊社（株式会社GENAI）では、経理・営業データの集計クエリなど、社内で使うSQLについてもClaude Codeにレビューを依頼する運用を取り入れています。人間のレビューだけでは見落としがちな「境界値の扱い」のような細かい観点を、AIが機械的にチェックしてくれる価値は決して小さくありません。

8-1. 非エンジニアがSQLの品質に関わる意味

「SQLは書かないから関係ない」という経営者・管理職の方もいるかもしれません。しかし、売上データの集計・レポーティングの正確性は経営判断に直結するテーマです。「月末のデータが1件抜けている」という事故が、意思決定の材料となる数字を狂わせるリスクは軽視できません。

弊社では経理・広告運用のデータ集計にもClaude Codeを組み込んでおり、月額約30,000円（Max 20xプラン）の投資で、こうした地味だが重要な品質チェックまで含めて業務を分担できている実感があります。「動いているはずのSQL」に潜むサイレントなバグを、非エンジニアの立場からも減らせるのが、AIコーディングツールの隠れた価値だと感じています。

もちろん、AIレビューが万能というわけではありません。最終的にどのデータをどう集計するかというビジネス上の要件定義は人間の役割であり、AIはあくまで「書かれたSQLが要件通りに動くか」を機械的に検証するアシスタントという位置づけです。この役割分担を理解した上で活用すると、レビュー工数の削減効果を最大限に引き出せます。

データ集計の正確性も、Claude Codeの業務活用も、AI鬼管理が伴走します

「社内の集計クエリの品質を見直したい」「開発以外の業務にもAIを活かしたい」という経営者・管理職の方に向けて、Claude Codeの導入設計をサポートしています。

よくある質問

Q. BETWEENの境界値（最小値・最大値）は範囲に含まれますか？

A. はい、含まれます。BETWEEN A AND B は「A以上B以下」を意味し、AとBの両方が範囲に含まれます。「Aより大きくBより小さい」という意味ではないので注意してください。

Q. DATETIME型のカラムにBETWEENで日付範囲を指定するとき、何に気をつければいいですか？

A. 上限の日付は「その日の午前0時00分00秒」として解釈されるため、その日のうちに発生したデータが抜け落ちます。上限に時刻（23:59:59等）を明示するか、「< 翌日の0時」という半開区間で書くのが安全です。

Q. BETWEENの最小値と最大値を逆に書くとどうなりますか？

A. 多くのデータベースでは自動的に入れ替えてくれず、該当レコードが0件という結果になります。エラーにはならないため、プログラム側で動的に値を組み立てる場合は特に順序のミスに注意が必要です。

Q. 文字列にBETWENを使うのは絶対にダメですか？

A. 構文上は使用できますが、文字コード順（照合順序）に依存するため、日本語混じりの自由入力の文字列では想定外の結果になりやすく、実務では避けるのが無難です。規則的な英数字コードであれば比較的安全に使えます。

Q. BETWENとINはどちらが処理速度として有利ですか？

A. どちらもインデックスが適切に設定されていれば大きな速度差は出ません。速度よりも「連続した範囲か、飛び飛びの値のリストか」という意味的な使い分けを優先して選ぶべきです。

Q. NOT BETWEENは境界値を含みますか？

A. 含みません。NOT BETWEEN A AND B は「A未満、またはBより大きい」を意味し、境界値のA・Bそのものは結果に含まれません。

Q. BETWENの比較対象にNULLが含まれているとどうなりますか？

A. 比較結果が「不明（UNKNOWN）」となり、そのレコードは検索結果に含まれません。NULLを含む可能性があるカラムを対象にする場合は、IS NOT NULL等の条件を別途追加して除外や補完を検討してください。

Q. BETWENを使ったクエリのレビューはAIに任せても大丈夫ですか？

A. 構造的なチェック（境界値の扱い、日付範囲の解釈、NULLの考慮漏れなど）はAIレビューが得意な領域です。ただし最終的な実行結果の妥当性は、必ず実データでの検算とあわせて確認することをお勧めします。

AIAI鬼管理

AI鬼管理へのお問い合わせ

この記事を読んで気になった方へ。
AI鬼管理の専門スタッフが、御社に最適な
業務自動化プランを無料でご提案します。

お客様情報

会社名・屋号*必須

会社名を入力してください

業種*必須 選択してください IT・ソフトウェア 製造業 建設・不動産 小売・EC 飲食・宿泊 医療・介護 教育・研修 士業・コンサル 人材・BPO その他

業種を選択してください

お名前*必須

お名前を入力してください

メールアドレス*必須

※法人・事業用のメールアドレスでお願いします（Gmail等の個人用フリーメールは受付できません）

正しいメールアドレスを入力してください

電話番号任意

---

現在の課題について

現在感じている課題*必須

人手不足で業務が回らない 社長・経営者が現場を離れられない 定型業務に時間を取られている AIを導入したいが何から始めればいいかわからない 外注・人件費コストが高い 業務フローが属人化している 社員のITリテラシーにばらつきがある

1つ以上選択してください

効率化・自動化したい業務*必須

営業・顧客対応（CRM・メール等） 経理・請求書・入金管理 採用・人事・労務管理 マーケティング・SNS・広告運用 カスタマーサポート・問い合わせ対応 資料作成・レポート・議事録 データ入力・集計・分析 社内の情報共有・ナレッジ管理

1つ以上選択してください

上記業務に現在かけている月額コスト*必須 選択してください まだかけていない（これから検討） 〜10万円 10〜30万円 30〜50万円 50〜100万円 100万円以上 その他（自由入力）

月額コストを選択してください

その他、ご相談内容任意

---

面談日時の選択

ご希望の日時*必須

約1時間のオンライン面談（Google Meet）です

空き枠を取得中...

面談日時を選択してください

この内容で面談を予約する

予約確定後、Google Calendarの招待メールをお届けします。
しつこい営業は一切ございません。