ツールナビ
使い方ガイド このサイトについて プライバシーポリシー お問い合わせ
開発ツール 登録不要 無料 ブラウザ完結

SQL整形ツール（無料・登録不要）

SQLを貼り付けるだけで即座に整形・圧縮。MySQL/PostgreSQL/SQLite/BigQuery/Snowflake/SQL Server/Oracle/DB2など9方言対応。キーワード大文字小文字・インデント・カンマ位置を自由に設定。シンタックスハイライト・ダークモード・.sqlダウンロード対応。ブラウザ完結・無料・登録不要。

最終更新：2026年5月14日

SQLを貼り付けて「整形」ボタンを押すだけ。9方言対応・シンタックスハイライト・整形前後比較・ダークモード完全対応。ORM生成SQLのデバッグやコードレビュー前の整形に。完全ブラウザ完結・サーバー送信なし。
入力 SQL

SQL整形ツールの使い方

  1. 左側の入力欄にSQLを貼り付ける（.sqlファイルのドラッグ&ドロップも可）
  2. SQL方言・インデント幅・キーワードケース・カンマ位置を選択する
  3. 「整形」ボタンを押す（または Ctrl+Enter）
  4. 右側に整形・シンタックスハイライト済みのSQLが表示される
  5. 「コピー」で即クリップボード、「.sql保存」でファイルダウンロード
  6. 「比較」タブで整形前後の変化を確認する

使い方ガイド：こんな場面で役立ちます

1
SQLを貼り付けるか、ファイルをドロップ
APIから取得したSQL・ログファイルのクエリ・ORM生成SQL・DBツールからコピーしたSQLを左側の入力欄にそのまま貼り付けてください。.sqlファイルをドラッグ&ドロップで読み込むこともできます。圧縮された1行SQLも、複数クエリも対応します。
2
方言とオプションを選ぶ
使用しているDBに合わせて方言（MySQL/PostgreSQL/SQLite 等）を選択してください。方言を正しく設定すると、各DBの固有構文（GROUP BY ROLLUP・WITH RECURSIVE・ROWNUM等）も正確に整形されます。キーワードの大文字・小文字変換やインデント幅も設定可能です。
3
整形・圧縮・比較
「整形」：読みやすい複数行フォーマットへ変換。「圧縮」：本番環境やURLパラメータ用の1行SQL。「比較」タブ：整形前後の差分をサイドバイサイドで確認。整形結果はシンタックスハイライトでキーワード・文字列・数値・コメントが色分けされます。
4
コピー・ダウンロード・履歴から再利用
「コピー」で即クリップボード転送、「.sql保存」でファイルダウンロード。入力したSQLは自動的にLocalStorageに保存され、「履歴」から最新5件を再呼び出しできます。

主な利用シーン

SQLレビュー・コードレビュー

キーワードを大文字統一・インデントを揃えることでチームのSQL記述スタイルを統一。PRレビュー前に整形することで、フォーマット差分によるノイズを防ぎます。

クエリデバッグ・ログ解析

ORM（Hibernate/Rails ActiveRecord等）が生成した圧縮SQLをデバッグしやすい形に展開。スロークエリログから抽出したSQLを整形してボトルネックを特定。

データ分析・BI活用

BigQuery・Redshift・Snowflakeで実行する長大な分析クエリを整形。WITH句（CTE）の構造が一目でわかり、サブクエリの修正が容易になります。

SQL学習・教材作成

見づらいSQLサンプルを整形して学習者に共有。教材・スライド・ドキュメントに貼り付ける際の整形に。キーワード大文字統一でSQL標準の記法を習得できます。

プライバシー：入力したSQLはすべてブラウザ内で処理されます。サーバーへの送信は一切なく、機密データ・本番環境のクエリ・パスワードを含むSQLも安心して整形できます。

SQL方言の違いと選び方ガイド

同じSQLでも、データベースによって固有の構文・関数・予約語が異なります。方言を正しく設定することで整形精度が向上します。

方言 主なDB・用途 固有構文の例 選択場面
標準SQL ANSI SQL / 汎用 FETCH FIRST n ROWS ONLY 特定DBに依存しない汎用クエリ
MySQL MySQL 5.7+ / MariaDB LIMIT, IFNULL(), GROUP_CONCAT() Web系アプリ・WordPress・EC系
PostgreSQL PostgreSQL 12+ ILIKE, UNNEST(), JSONB演算子 データ分析・GIS・JSON処理
SQLite SQLite 3 / モバイルアプリ PRAGMA, ROWID, WITHOUT ROWID モバイルアプリ・組込DB・ローカル処理
BigQuery Google BigQuery STRUCT, ARRAY, UNNEST(), PARTITIONBY Google Cloud・データウェアハウス
Snowflake Snowflake FLATTEN(), QUALIFY, SAMPLE クラウドDWH・データレイク
T-SQL SQL Server / Azure SQL TOP, NOLOCK, CROSS APPLY Windowsサーバー・エンタープライズ
PL/SQL Oracle Database ROWNUM, NVL(), CONNECT BY 大規模基幹システム・銀行・官公庁
DB2 IBM DB2 FETCH FIRST n ROWS, LOCATE() IBM製品・金融・製造業

方言の選び方フローチャート

Q1
Google CloudのBigQueryを使っていますか？
→ はい: BigQuery を選択。STRUCT・ARRAY_AGGなどが正しく整形されます
Q2
SQL ServerまたはAzure SQLを使っていますか？
→ はい: T-SQL（Transact-SQL）を選択。TOP・WITH(NOLOCK)が対応します
Q3
OracleデータベースのPL/SQLを書いていますか？
→ はい: PL/SQL を選択。ROWNUM・CONNECT BYが正しく扱われます
Q4
それ以外のDBで、どれを選ぶか迷う場合
→ MySQL（最もポピュラー・Web系標準）またはPostgreSQL（分析・オープンソース）を選択してください

他のSQL整形ツールとの比較

主要なSQL整形ツールと当サイトの機能を比較しました（2026年5月調査）。

機能 tools-navi.jp
（当サイト）		 sqlformat.org codebeautify 日本製
整形ツール
日本語UI✅ 完全対応❌ 英語のみ❌ 英語のみ✅
対応方言数✅ 9種❌ 1種✅ 5種△ 8種
ダークモード✅❌△ beta❌
シンタックスハイライト✅❌❌❌
比較ビュー（整形前後diff）✅❌❌❌
SQL圧縮（minify）✅✅✅△
履歴保存（LocalStorage）✅ 5件❌❌❌
.sqlファイルDL✅❌✅❌
ファイルアップロード✅ D&D対応❌✅ URL読込❌
カンマ位置選択✅ 行末/行頭✅❌△
広告量少ない少ない極めて多い少ない
モバイル最適化✅ 完全対応△❌△
SQL解説・FAQ✅ 詳細❌❌△

✅=対応 ❌=未対応 △=部分対応。当サイト調査（2026年5月）。各ツールのバージョンにより変わる場合があります。

読みやすいSQLの書き方ガイド

SQLを読みやすく書くことで、チームの生産性・バグ発見速度・保守性が大幅に向上します。業界で広く使われるスタイルガイドをまとめました。

基本ルール：キーワードは大文字

読みにくい select id, name from users where status = 'active' and age > 18 order by name;
読みやすい SELECT id, name FROM users WHERE status = 'active' AND age > 18 ORDER BY name;

JOIN は明示的に書く

推奨
INNER JOINを省略しない
FROM users u INNER JOIN orders o ON u.id = o.user_id
結合の種類を明示することで意図が明確になります。カンマで結合する旧スタイル（FROM users, orders WHERE users.id = orders.user_id）は避けましょう。
ヒント
テーブルエイリアスには意味のある短縮名を
FROM users u・FROM orders oのように、テーブル名の頭文字や略称を使います。t1・t2のような無意味なエイリアスは可読性を下げます。

SELECT * を避ける

SELECT *はカラム追加時の予期しない結果やパフォーマンス低下を招きます。必要なカラムを明示的に列挙することで、クエリの意図が明確になり、DBのインデックス最適化も効きやすくなります。

CTE（WITH句）で複雑なクエリを構造化

構造化されたSQL（CTE使用） WITH active_users AS ( SELECT id, name, email FROM users WHERE status = 'active' ), recent_orders AS ( SELECT user_id, COUNT(*) AS order_count FROM orders WHERE created_at >= CURRENT_DATE - INTERVAL '30 days' GROUP BY user_id ) SELECT u.name, u.email, COALESCE(o.order_count, 0) AS orders_last_30d FROM active_users u LEFT JOIN recent_orders o ON u.id = o.user_id ORDER BY o.order_count DESC NULLS LAST;

SQLレビューでチェックすべき10項目

コードレビューでSQLをチェックする際に見落としがちなポイントをまとめました。

1
N+1問題が発生していないか
ループ内でSQLを実行していないか確認。リストを取得した後、各要素に対してSQLを実行するパターンはパフォーマンスの大敵です。JOINやIN句でまとめて取得するよう修正しましょう。
2
WHERE句でインデックスが効いているか
カラムに関数を適用すると（例: WHERE DATE(created_at) = '2026-01-01'）インデックスが効かなくなります。WHERE created_at BETWEEN '2026-01-01' AND '2026-01-01 23:59:59'のように書き換えましょう。
3
SQLインジェクション対策が施されているか
ユーザー入力を直接SQL文字列に埋め込んでいないか確認。プリペアドステートメント（Prepared Statement）またはパラメータバインディングを使用することが必須です。
4
SELECT * を使っていないか
必要なカラムのみを明示的に指定。ネットワーク転送量・メモリ使用量の節約だけでなく、カラム追加時の意図しない挙動を防ぎます。
5
NULL処理が適切か
NULLとの比較は IS NULL / IS NOT NULL を使うこと（= NULLはNULLを返す）。集計関数（COUNT/SUM等）のNULL扱いも確認しましょう。
6
トランザクションの範囲は適切か
DML（INSERT/UPDATE/DELETE）が複数ある場合はトランザクションで囲む。ただしトランザクション内にサードパーティAPIコールを入れると長時間のロックが発生するため注意が必要です。
7
大文字小文字の規則が統一されているか
キーワード（SELECT/FROM等）は大文字、識別子（テーブル名・カラム名）はスネークケース等、チームの規約に合わせて統一しましょう。
8
LIMIT（上限件数）が設定されているか
開発時は少量データでも本番では数百万行返す可能性があるクエリには必ずLIMITを。特にカーソルを使った全件処理はバッチサイズを明示しましょう。
9
カラムの型不一致がないか
WHERE user_id = '123'（文字列）vs WHERE user_id = 123（整数）の型不一致は暗黙的型変換でインデックスが無効になる場合があります。
10
方言固有構文が他DB環境を壊さないか
MySQL固有のLIMIT・PostgreSQL固有のILIKE・SQL Server固有のTOP等は他DBで動作しません。マルチDB対応が必要な場合は標準SQLまたはORMのクエリビルダーを検討しましょう。

よくある質問（FAQ）

SQL整形ツールはどのような場面で役立ちますか？
主な用途は①コードレビュー前の整形統一（差分ノイズ防止）、②ORM生成クエリのデバッグ（読みやすく展開）、③スロークエリログの解析、④チームへのSQL共有・ドキュメント作成、⑤SQL学習（標準記法の確認）の5つです。特に「ORM（Hibernate・Rails ActiveRecord・Django ORM等）が生成した圧縮SQLを展開してデバッグしたい」というニーズに最適です。
入力したSQLはサーバーに送信されますか？
いいえ、一切送信されません。整形処理はすべてブラウザ内のJavaScript（sql-formatterライブラリ）で完結しています。本番DBのクエリ・個人情報を含むSQLも安心してご利用いただけます。
どのSQL方言を選べばよいかわかりません。
迷った場合はまず「標準SQL」をお試しください。MySQLを使っている場合はMySQL、PostgreSQLならPostgreSQL、Google BigQueryならBigQuery、SQL ServerならT-SQL（Transact-SQL）を選ぶと方言固有の構文（LIMIT・ROWNUM・TOP等）も正しく整形されます。方言が違っても整形結果に大きな差が出ない場合も多いです。
SQLの圧縮（minify）は何のために使いますか？
主な用途は①URLパラメータにSQLを埋め込む際のサイズ削減、②本番アプリでのネットワーク転送量削減、③ORM等のクエリ文字列として埋め込む際の整形です。ただし一般的なDBクライアントへの入力やコードのSQLは整形版の方が保守性が高いです。
大きなSQLファイル（1,000行以上）でも使えますか？
対応していますが、非常に大きなSQL（数MB以上）は処理時間が長くなる場合があります。ブラウザのJavaScriptで処理を行うため、100MB超の超大容量ファイルはブラウザがフリーズする可能性があります。その場合はコマンドラインツール（sqlformatterコマンド・pgFormatter等）のご利用をおすすめします。
カンマ位置（行末・行頭）はどちらが推奨ですか？
一般的にはどちらでも構いませんが、傾向として①行末カンマ（trailing comma）は多くのORM・ツールのデフォルト・初心者向け、②行頭カンマ（leading comma）はコードレビューでカンマを含む行の変更が見やすい・熟練者向けです。GitのdiffやPRを重視するチームでは行頭カンマが好まれることがあります。チームの規約に合わせてください。
SQLのコメントは整形後も残りますか？
はい、コメント（-- 行コメント / /* ブロックコメント */）は整形後も保持されます。インデントはSQL本文と同様に調整されます。コメントを削除したい場合は、現状では整形後に手動で削除する必要があります。
SQLのANSI標準仕様はどこで確認できますか？
SQLのANSI/ISO標準（SQL:2023）は有償ですが、PostgreSQL公式ドキュメントやMySQL公式リファレンスで各DBMS実装の詳細を無料で確認できます。