こんにちは！日々のデータベースとの格闘、本当にお疲れ様です。
開発をしていると、「ステージング環境ではこのテストデータを使い、本番環境では絶対にこのクエリを誤爆させちゃいけない……！」という緊張感の連続ですよね。手動でクエリのWHERE句を書き換えたり、コメントアウトを切り替えたりしていませんか？ そのやり方、いつか必ず大事故（ヒューマンエラー）に繋がります。
今回は、プロのデータベースエンジニアも愛用する最強のDBクライアント「DataGrip」の「Query Parameters（クエリパラメータ）」と「Environment Variables（環境変数）」を完璧に連携させ、「クエリの本体を1行も書き換えることなく、安全に環境を切り替える極意」を優しく、徹底的に解説していきます。
これをマスターすれば、毎日の作業が劇的に安全に、そしてスマートになりますよ。一緒に見ていきましょう！
—
1. 複数環境におけるクエリ使い回しの課題とセキュリティリスク
まずは、「なぜ従来のやり方が危険なのか」という本質からお話ししますね。
開発環境（Dev）、ステージング環境（Stg）、そして本番環境（Prod）。これらはデータベースの接続先が違うだけでなく、扱うデータの機密性も異なります。
よくあるアンチパターンがこれです。
- クエリの中に直接 `WHERE store_id = 999`（テスト用）と書き、本番実行時に `1`（本番用）に書き換えるのを忘れる。
- 本番の顧客データを誤ってステージングに流し込んだり、逆にステージング用の破壊的なクエリを本番で実行してしまう。
「クエリのテキスト自体を環境ごとに変更する」というアプローチを取っている時点で、それは爆弾を抱えているようなものです。
私たちが目指すべきは、「クエリは常に不変（Immutable）であり、変わるのは注入される『パラメータ』と『接続先』だけだ」という状態です。これをDataGripの機能で実現します。
—
2. DataGripのパラメータ機能と環境変数（Environment Variables）の紐付け設定手順
それでは早速、DataGripで環境ごとの安全な切り替えメカニズムを構築していきましょう。
ステップ①：パラメータ付きクエリを書く
まずは、環境によって変わる値（テナントIDや日付など）を、DataGripのパラメータ形式（`:$変数名$` または `?`）で記述します。
— 顧客の注文履歴を取得するクエリ（環境を問わずこのまま使い回す）
SELECT
order_id,
customer_id,
total_amount,
created_at
FROM
orders
WHERE
store_id = :target_store_id — ←ここが環境ごとに変わるパラメータ
AND created_at >= :target_date;
このクエリを実行しようとすると、DataGripが自動的に「`target_store_id` と `target_date` には何を入れますか？」とポップアップ（Query Parametersダイアログ）で聞いてくれます。しかし、手動入力ではヒューマンエラーを防げません。これを環境変数から自動注入するように設定します。
ステップ②：DataGripで「環境（Environments）」を作成する
DataGrip（JetBrains製IDE共通の機能）には、実行環境ごとに変数をスコープ分けする機能があります。
1. 画面右上の接続バー（または構成メニュー）から、実行環境の設定を開きます。
2. 「Edit Configurations」 または 「Environments」 の設定を開きます。
3. 以下のように、ステージング用と本番用の環境を作成し、それぞれに変数を定義します。
- Stg環境用の設定 (`stg-env`)
- `target_store_id` = `999` （テスト店舗）
- `target_date` = `2023-01-01`
- Prod環境用の設定 (`prod-env`)
- `target_store_id` = `1` （本番フラッグシップ店舗）
- `target_date` = `2024-01-01`
これで、クエリ側は一切変更せず、DataGrip側で「今はどの環境の文脈でこれを動かしているか」を切り替えるだけで、自動的に適切な値がバインドされる仕組みが完成します。
—
3. 誤爆を防ぐためのカラーリングや接続確認アラートの活用法
仕組みを作っても、人間はうっかりミスをする生き物です。「今、自分は本番を触っているのか？」という視覚的な認識が何よりも重要になります。DataGripの強力な視覚的ガード機能を設定しましょう。
① データソースごとに「色」を変える（最重要）
本番環境とステージング環境が、同じエディタの色だったら……想像するだけで冷や汗が出ますよね。DataGripでは接続（Data Source）ごとにテーマカラーを設定できます。
- Stg環境: 落ち着いた「青（Blue）」や「緑（Green）」
- Prod環境: 危険信号である「赤（Red）」や「オレンジ（Orange）」
設定方法:
DataGripの「Database」ツールウィンドウから対象の接続を右クリック ＞ `Color` を選択し、本番環境には必ず「赤系のカラー」を指定してください。これだけで、エディタの下部やタブが赤く染まり、「あ、今本番にいるぞ！」と脳が本能的に警戒するようになります。
② 本番環境実行時の「確認プロンプト」を設定する
さらに安全性を高めるために、本番環境のデータソースに対しては「実行前の確認ポップアップ」を強制させます。
1. `Settings` (または `Preferences`) ＞ `Tools` ＞ `Database` ＞ `Console` を開く。
2. 「Execution」セクションにある、「Show confirmation before executing statements on production/dangerous data sources」にチェックを入れます。
これで、本番環境のデータベースに対してクエリを実行しようとすると、「本当にこの本番環境で実行しますか？」という最終確認ダイアログが必ず挟まるようになります。二重の盾ですね。
—
4. 実務で役立つ安全なデプロイ・クエリ実行のワークフロー解説
ここまでの設定をすべて網羅した、現場で即座に使える「安全なクエリ実行の黄金ワークフロー」をまとめます。
1. コードは1つに統合する
開発するクエリは常にパラメータ化された単一のファイル（Git管理）として扱います。環境ごとに別々のSQLファイルを作るのは絶対にやめましょう。
2. コンテキスト（環境変数）を切り替える
クエリを実行する直前に、DataGripの実行コンテキストが「Stg」になっているか「Prod」になっているかを、エディタの赤・青のカラーリングで確認します。
3. 実行とパラメータの自動バインド
`Ctrl + Enter` （Macなら `Cmd + Enter`）で実行すると、環境変数に紐づいた値が安全にクエリに流し込まれます。
4. 本番なら警告を直視する
もしProd環境であれば警告ダイアログが表示されるため、そこで一度深呼吸して「本当にこのパラメータで合っているか？」を最終確認できます。
—
おわりに
いかがでしたでしょうか？
DataGripの「Query Parameters」と「環境変数」を連携させるこの手法は、単なる小手先のテクニックではありません。「ヒューマンエラーという不確実性を、ツールの仕組みによって完全にハジキ返す」ためのエンジニアリングの基本です。
今日からこの設定を取り入れれば、本番環境の前で冷や汗をかく夜とはお別れできます。あなたのデータベースライフが、より安全で快適なものになることを心から応援しています！