検証環境への QA データ準備で「DB へ直接 SQL を流せば早い」は、接続経路（ポートフォワード等）が文書化されていても採用しない。判定は次の2軍で行う。

判断基準

1. 二重書き込みの整合: アプリが RDB + 検索インデックス（OpenSearch 等）の二重管理を持つ場合、直接 INSERT したレコードはインデックスに反映されず、検索・一覧・集計系の画面に現れない中途半端な状態になる。QA の前提状態自体が壊れ、偵査にくい偽の FAIL/PASS を生む。データ型ごとのテーブル分割など正規化が深い設計ほど、手書き SQL で整合の取れたレコードを作るのは非現実的になる。
2. 誤爆面: ブランチ別・環境別の DB が「共有ホスト上の別データベース」として同居する構成では、接続認証情報が全 DB に届くため、database 名の指定を 1 箇所間違えるだけで共有環境への書き込みになる。SQL はアプリのバリデーション・認可を一切通らないので、誤爆の影響が直撃する。

文書裏づけは用途単位で判定する

接続手順がリポジトリに文書化されていても、その文書の目的（例: データをローカルへダンプする読み取り用途）と違う用途（検証環境への書き込み）への転用は「既存手段の裏づけあり」とは見なさない。安全性の根拠は接続可能性ではなく、その用途での作成・限定 cleanup が文書で裏づけられているか。

例外と代替

• 正規のマイグレーション実行機構（workflow 経由の migration 実行等）がある場合はそちらを使う。任意データ投入の押し込み先にしない。
• 読み取り専用の状態確認（件数・値の検証）に接続を使うのは別判断でよいが、書き込みと同じセッション・同じツールに混ぜない。

検証観点

データ準備後は、書き込んだ経路とは別の読み取り経路（検索・一覧画面）で見えることを確認する。これが通れば二重書き込みの整合確認を兼ねられる。