ブランチごとの preview 環境が「共有ロードバランサ + リクエストヘッダーによるリスナールール振り分け」で実装されている場合、データ準備はブラウザ UI 操作しかできないと思い込みやすい。しかしフロントエンドが実行時に自ホスト名からブランチを導出して識別ヘッダーを付けているだけなら、同じヘッダーを付けた HTTP クライアントの API 呼び出しも同じブランチのバックエンドに届き、QA データ準備を API で自動化できる。

評価は2段に分ける

1. ルーティング条件: ロードバランサのリスナールールが要求するヘッダー集合。フロントのリクエストヘッダー構築コードと、環境を作るデプロイスクリプト（ルール作成部分）の両方から突き合わせて確認できる。到達性はここで決まる。
2. アプリ認証: ロードバランサを通過してもアプリの認証ガードは別に生きている。到達性と認可を混同せず、トークンの取得経路を別途確保する。

認証経路の選択基準

• マシン向け API キー機構が存在しても、発行エンドポイントがパートナー向け M2M 認証専用など QA 側で発行できない構成なら採用しない。認証方式の存在ではなく「QA の立場で取得できるか」で判定する。
• SPA が OAuth トークンをブラウザの localStorage キャッシュに保持する構成（Auth0 SPA SDK の cacheLocation を localstorage にしている等）なら、テスト用アカウントでログイン済みのブラウザからトークンを取り出して HTTP クライアントで再利用できる。

検証ゲート

実地未検証の抽出手順は、書き込み系に使う前に読み取り系エンドポイントで認証込みの正常応答を確認してから使う。失敗したら UI 操作にフォールバックし、未検証のまま書き込みへ進まない。

落とし穴

ルーティングヘッダーを付け忘れたリクエストはエラーにならず、デフォルトルーティング先（共有環境）に届いて成功してしまう。preview 向けのつもりの書き込み・削除が共有環境に当たる事故の型なので、書き込み前に「preview 固有のデータが返るか」等でルーティング先を確認する手順を挟む。