SQL

整形

SQL フォーマッタ

Q: キーワードの大文字化はチームのスタイルに合いますか？

UPPER / lower / そのまま の 3 通りから選べます。リポジトリの慣習に合わせて選んでください。

SELECT / INSERT / UPDATE / DELETE などの SQL 文を読みやすいインデントに整形します。PostgreSQL / MySQL / SQLite / BigQuery / Snowflake / MariaDB / Standard SQL の方言、キーワードの大文字化、インデント幅の調整に対応。

サンプル

入力

出力

方言

大文字化

インデント

こんなときに使う

ORM が生成した 1 行 SQL をデバッグする

Prisma / TypeORM / Active Record などの ORM が出力した 1 行の SQL を整形して、JOIN 関係や WHERE 条件を確認します。実行計画を見る前のステップとして必須です。

SELECT u.id, u.name, p.title FROM users u INNER JOIN posts p ON p.user_id = u.id WHERE u.active = true ORDER BY u.created_at DESC LIMIT 20;

アプリログから抜き出したクエリを読みやすくする

本番ログに記録された slow query を切り出して整形し、なぜ遅いのかを分析します。読みづらい状態のままだとボトルネックの見落としに繋がります。

[2026-05-06 12:34:56] slow query: SELECT * FROM events WHERE ...

PR レビュー前にチームの SQL スタイルに揃える

キーワードを大文字に統一・インデント幅を 2 / 4 で揃えるなど、レビュー時に指摘されがちな差を機械的に解消できます。

select id, name from users where active = true

BigQuery の長いウィンドウ関数を可読化する

OVER (PARTITION BY ... ORDER BY ... ROWS BETWEEN ...) のような複雑な集約を改行で分けて、要素ごとに確認しやすくします。

SELECT user_id, SUM(amount) OVER (PARTITION BY user_id ORDER BY created_at ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS running_total FROM payments;

ドキュメントに貼る SQL を体裁よく整える

Notion / Confluence / GitHub README に SQL 例を載せる際、整形しておくと後から読む人がスムーズに理解できます。

INSERT INTO orders (id, user_id, total) VALUES (1, 42, 1200);

CTE（WITH 句）の入れ子を整理する

複数の CTE をネストしたクエリを整形し、どこで何を計算しているかを把握しやすくします。

WITH a AS (...), b AS (...) SELECT * FROM a JOIN b ON ...

よくあるエラーと対処

ERR Parse error: Expected one of these tokens

原因: 選択した方言と入力 SQL の文法が一致していません。例えば PostgreSQL 用の方言で BigQuery の SAFE_CAST を整形しようとした場合に発生します。
対処: 方言セレクタで対応する DB を選んでください。Standard SQL を選ぶと最も汎用的です。

ERR 整形結果が崩れる（インデントが揃わない）

原因: コメント /* ... */ の中に SQL 風のキーワードが含まれていると、パーサが誤認することがあります。
対処: コメント内のキーワードを削るか、コメント自体を一時的に外して整形してください。

ERR ストアドプロシージャが正しく整形されない

原因: PL/pgSQL や T-SQL の制御構文（DECLARE / BEGIN / END / IF）には方言依存性が強く、汎用フォーマッタでは追従しきれません。
対処: 対応方言で改善するか、ストアド部分は手で整形してください。

ERR 識別子の大文字小文字が変わってしまう

原因: 「キーワードの大文字化」設定が識別子にも作用するように見えるケースがあります。実際にはキーワードのみ対象ですが、予約語と紛らわしい識別子は影響を受けることがあります。
対処: 「そのまま」を選ぶか、識別子を引用符で囲んでください（PostgreSQL: "name"、MySQL: `name`）。

CLI / 他言語でやる方法

sqlfluff

sqlfluff fix --dialect postgres input.sql

lint 機能も持つ。CI に組み込みやすい。

pg_format

pg_format -i input.sql

PostgreSQL 専用。-w で行幅指定。

VS Code 拡張

Prettier SQL Formatter / sqltools

保存時整形に使えるが方言サポートは拡張依存。

よくある質問

▶ 対応している方言は？

Standard SQL / PostgreSQL / MySQL / SQLite / BigQuery / MariaDB / Snowflake です。内部では sql-formatter ライブラリを使用しています。

▶ コメントは保持されますか？

保持されます。-- 1 行コメントと /* ... */ 複数行コメントの両方に対応します。位置は元の構造に追従して再配置されます。

▶ サブクエリや CTE は綺麗に整形されますか？

はい。WITH 句、INNER/LEFT JOIN、UNION、サブクエリなど標準的な構文はインデントが揃います。深くネストしている場合は方言を合わせるとより正確になります。

▶ 文字列リテラル内の改行は影響しますか？

クォート内の文字列はそのまま保持されます。SQL 文として動作する内容を変更することはありません。

▶ クエリの実行はできますか？

整形のみで、実行は行いません。フォーマッタは構文を解析するだけで、データベースには接続しません。

▶ 巨大な SQL でも動きますか？

数千行程度であれば動作します。CI で大量のスクリプトを処理したい場合は CLI 版（sqlfluff など）を推奨します。

▶ キーワードの大文字化はチームのスタイルに合いますか？

UPPER / lower / そのままの 3 通りから選べます。リポジトリの慣習に合わせて選んでください。

▶ セキュリティ上、機密データを含む SQL を貼っても大丈夫ですか？

ブラウザ内でのみ処理されサーバー送信はありません。ただしブラウザ拡張やキー入力ロガーには注意が必要です。共有 URL は機密データを含めないでください。

もっと深く知る

書籍