認可付きのリモートサービス（OAuth 保護された HTTP エンドポイント等）に「今どの対象を扱っているか」を伝える手段は、URL path / URL query / ツール引数の三択で語られやすい。だがクライアントが接続時にコマンドを実行してヘッダを動的生成できる場合、ヘッダが第四の選択肢になり、対象を頻繁に切り替える用途ではこれが最良になることが多い。

なぜヘッダが効くか

• クライアントは設定された URL 全体をサーバー同一性として扱い、保護リソースのメタデータも query なしの URL で広告される。対象ごとに query を変えると接続と認可が対象の数だけ分裂し、対象ごとの再認可が必要になる。ヘッダは URL を変えないので認可は一つのまま保てる。
• 同一サービスへの接続を対象ごとに複数定義して回避すると、クライアントから同種のツールが二重に見え、モデルがどちらを掴むかで挙動が確率的になる。恩恵が確率依存になる時点で設計として成立していない。
• ツール引数へ寄せると値をモデルが毎回渡す前提になり、渡し忘れで静かに文脈が外れる。ヘッダは接続時に機械的に決まるので取りこぼしが起きない。

適用条件

• クライアント側に「接続時にコマンドを実行してヘッダ集合を得る」仕組みがあること。無ければこの選択肢は取れない。
• 値が非秘密であること。秘密情報は認証経路に載せる。
• サーバーは同じ値をヘッダと query の両方から読み、ヘッダ優先・どちらも無ければ無指定へ劣化する実装にする。動的ヘッダを持てないクライアントが併存するため、片方だけの実装にしない。

落とし穴

• ヘッダ生成の入力（どの対象か）を作業リポジトリ内の設定ファイルから取ると、リポジトリが接続パラメータを注入する構造になる。ホスト側がこの経路を将来塞ぐ動機があるうえ、他人のリポジトリを開いただけで別の対象へ切り替わりうる。入力は利用者のホーム側設定に置き、リポジトリ側は読まないか明示的な opt-in に限る。
• 生成コマンドは入力が壊れていても空のヘッダ集合を返して正常終了させる。失敗を例外にせず劣化に倒す。

検証

対象の異なる二つの作業ディレクトリでクライアントを起動し、受信ヘッダを記録するだけのローカル HTTP リスナーへ接続させて、届いたヘッダが対象ごとに切り替わることを確認する。あわせて生成コマンドを意図的に失敗させ、接続自体は維持されヘッダだけが落ちることも確認する。