PowerShell から SQL Server にクエリを投げる — Invoke-Sqlcmd と SqlClient の使い分けと業務SEが踏む罠

みなさんこんにちは！ヒロポンです！

運用スクリプトから SQL Server にクエリを投げてデータを取りたい。バッチで更新もかけたい。で、PowerShell からどう書くのが正解なんや？？って、最初に手が止まりますよね。

正直、俺は昔これで痛い目を見ました。SqlClient で接続を開いたまま閉じ忘れて、本番の接続プールを枯らして、関係ない他の処理まで巻き込んで止めたことがあります。

PowerShell から SQL Server に行く道は、ざっくり2つ。Invoke-Sqlcmd（お手軽）と System.Data.SqlClient（.NET そのまま）です。

今回は、PowerShell SQL Server クエリの2つの道の使い分けと、業務SEが踏みやすい罠を5つ整理します。Windows Server / PowerShell 5.1 前提でいきます。

⏱ 2つの道と罠のサマリ（先に全体像）

細かい話に入る前に、地図だけ先に置いときます。

踏みやすい罠は、SqlServer モジュール依存 / 接続の閉じ忘れ / 文字列連結のインジェクション / 認証方式 / 大量取得のメモリ。この5つを順に潰していきます。

道A: Invoke-Sqlcmd — 1コマンドで手軽

SqlServer モジュールの Invoke-Sqlcmd は、1行でクエリを投げて結果まで受け取れます。

Import-Module SqlServer   # 事前に入っている前提

$rows = Invoke-Sqlcmd `
    -ServerInstance "localhost" `
    -Database "MyDb" `
    -Query "SELECT Id, Name FROM dbo.Customers WHERE Region = 'Tokyo'"

$rows | ForEach-Object { $_.Name }

結果は DataRow の配列で返ってくるので、$_.Name みたいに列名でそのまま取れます。こんな感じで、手早く1発クエリを投げたい時はこれが一番ラク。

クエリに外部から来る値（引数やファイル）を混ぜたい時は注意が要ります。Invoke-Sqlcmd は後述の罠③のとおり真のパラメータ化ができないので、未信頼の値を渡すなら道B（SqlClient）に寄せるのが安全です。

道B: System.Data.SqlClient — 依存なしで細かく制御

.NET の SqlConnection / SqlCommand を直に使う道。モジュール依存が無くて、タイムアウトやトランザクションまで細かく握れます。

$conn = New-Object System.Data.SqlClient.SqlConnection
$conn.ConnectionString = "Server=localhost;Database=MyDb;Integrated Security=True"

try {
    $conn.Open()
    $cmd = $conn.CreateCommand()
    $cmd.CommandText = "SELECT Id, Name FROM dbo.Customers WHERE Region = @r"
    $cmd.Parameters.AddWithValue("@r", "Tokyo") | Out-Null

    $reader = $cmd.ExecuteReader()
    while ($reader.Read()) {
        $reader["Name"]
    }
}
finally {
    $conn.Close()   # ← 必ず閉じる（後述の罠②）
}

長く見えますが、やってるのは「開く → 実行 → 読む → 閉じる」だけ。依存モジュールを入れられない現場や、細かい制御が要る時はこっち。こんな感じで、開いてから閉じるまで全部自分で握ります。

罠①: Invoke-Sqlcmd は SqlServer モジュールが要る

Invoke-Sqlcmd は SqlServer モジュール（または旧 SQLPS）に入っているコマンドです。モジュールが無い環境では、そもそも動きません。

# 入ってなければインストール（管理者権限・オンライン環境）
Install-Module -Name SqlServer -Scope AllUsers

閉じたイントラや、勝手にモジュールを入れられない現場だと、ここがネックになります。そういう時は、モジュール不要な道B（SqlClient）に寄せるのが確実です。

罠②: SqlClient は接続を閉じないと、プールが枯れる

俺が本番でやらかしたのがこれ。SqlConnection.Open() したのに Close() を忘れると、接続が返却されず、接続プールが枯渇します。

こうなると、他の処理も「接続が取れない」で軒並み止まる。たった1つの閉じ忘れが、システム全体を巻き込む事故になるわけです。

対策は、必ず try / finally の finally で Close() する。途中でエラーが飛んでも確実に閉じるためです。

try {
    $conn.Open()
    # クエリ実行...
}
finally {
    $conn.Close()   # 例外が出ても、ここは必ず通る
}

Invoke-Sqlcmd のほうは接続を内部で開いて閉じてくれるので、この罠は道A側では起きません。閉じ忘れが怖いなら道A、という選び方もアリ。事故りやすさで選ぶのも、いい感じに効く手だと思います。

罠③: 文字列連結はインジェクション — 真のパラメータ化は道B

一番やっちゃいけないのがこれ。クエリに変数を文字列連結で埋め込むと、SQL インジェクションの穴になります。

# ❌ 絶対ダメ。$region に「'; DROP TABLE ...」が入ったら終わり
$query = "SELECT * FROM dbo.Customers WHERE Region = '$region'"

対策は値をパラメータとして渡すこと。ただし、ここは道AとBで意味が全然違うので要注意です。

• 道B の SqlParameter（AddWithValue）は「真のパラメータ化」。値は SQL のテキストではなくパラメータ値としてバインドされるので、injection を防げます。
• 道A の Invoke-Sqlcmd -Variable は injection 対策になりません。-Variable は sqlcmd スクリプト変数で、クエリ側は $(名前) で参照するただのテキスト置換。悪意ある SQL が入れば、そのまま展開されて刺さります（@変数 にも束縛されません）。

# ✅ 道B: パラメータで渡す（値は SQL として解釈されない）
$cmd.Parameters.AddWithValue("@r", $region) | Out-Null

だから、外から来る値（ファイル・引数・DB・画面）をクエリに混ぜるなら、道B のパラメータ化に寄せる。道A は「値が固定 or 自分で握ってる信頼できる値」の1発クエリに留めるのが鉄則です！！

罠④: Windows 認証と SQL 認証で、接続文字列が違う

接続文字列は、認証方式で書き方が変わります。ここを取り違えると「ログインできない」で詰まる。

• Windows 認証: Integrated Security=True（実行アカウントの権限で接続）
• SQL 認証: User Id=sa;Password=xxxx（SQL Server のログインで接続）

# Windows 認証（実行アカウントに DB 権限が要る）
"Server=localhost;Database=MyDb;Integrated Security=True"

# SQL 認証
"Server=localhost;Database=MyDb;User Id=appuser;Password=$pw"