Azure Data Factory Copy ActivityでCookieヘッダー認証が通らない原因と回避策

Azure Data Factory（ADF）でSOAP APIを叩き、Copy Activityでレスポンスをそのままファイル化したい。しかし認証がCookie（ASP.NET_SessionId）依存だと、Webアクティビティでは成功するのにCopy Activityだけ失敗することがあります。本記事では原因と、実務で安全に運用できる回避策を整理します。

状況：ADFのCopy ActivityでCookieベース認証のSOAP APIを呼び出したい

現場でよくあるのが、社内システムやレガシー基盤のSOAP APIがCookieベース認証（セッションCookie）を採用しているケースです。典型例は ASP.NET_SessionId のようなセッション識別子で、まず「ログイン／Connect」系のエンドポイントを呼び出してセッションを確立し、その後のリクエストで同じCookieを送ることで認証・認可が成立します。

やりたいこと	ADFでの実装イメージ	つまずきポイント
Connectを呼び出してCookieを受け取る	WebアクティビティでPOSTし、レスポンスヘッダー（Set-Cookie）を取得して変数へ保存	レスポンスCookieを後続に安全に受け渡す仕組みが弱い
同じCookieを付けてSOAP APIを呼び出す	Copy Activity（ソース: HTTP）で「追加ヘッダー」にCookieを設定	Cookieが送られていないように見え、認証が通らない
結果をファイルとして保存したい	Copy ActivityでBlob/Data Lakeへ直接出力	Webアクティビティは「結果をそのままファイル化」しづらい

結論から言うと、「Webアクティビティで受け取ったCookieを、ADFだけで引き回してCopy Activityへ渡す」設計はハマりやすく、本番運用に向きません。以下では、なぜそうなるのかを整理し、運用に耐える選択肢を具体的に紹介します。

WebアクティビティとCopy Activityが「似ているようで別物」な理由

ADFにはどちらもHTTPを叩ける仕組みがありますが、目的が違います。

観点	Webアクティビティ	Copy Activity（HTTP/RESTソース）
役割	制御（オーケストレーション）向け。APIを叩いて結果を次の処理に渡す	データ移動向け。読み取り元からストレージ/DBへ転送する
扱いやすいデータ量	小さめ（制御情報・トークン取得など）	大きめ（ファイル出力・大量レコード転送など）
セッション/状態の保持	単発呼び出し前提だが、結果を変数に保持して使える	コネクタとしては基本的にステートレス。Cookieジャーのような仕組みを前提にしない
認証の得意分野	任意のヘッダー・ボディを組みやすい（SOAPActionなども入れやすい）	「コネクタが想定する認証方式」が中心。Cookieの自動処理は想定外になりやすい
結果の保存	レスポンスをそのままストレージに保存する用途は弱い	保存が主目的。形式変換（マッピング）や分割なども組み込みやすい

今回のつまずきは、この「Copy Activityはデータ転送用のコネクタ実装で、WebアクティビティのようにHTTPセッションを組み立てる前提が薄い」というギャップから起きます。

結論：ADFのHTTPコネクタは「レスポンスCookieの受け取り→再利用」を正式サポートしていない

現状のADFでは、HTTP応答に含まれるCookie（Set-Cookie）を正式な機能として後続アクティビティに引き継ぐことが想定されていません。そのため、次のような構成は動くこともありますが、環境・IR・コネクタ実装差分・セキュリティ制約などで期待どおり動作しない可能性が高い、という扱いになります。

• WebアクティビティでConnectを呼び、レスポンスからCookieを抽出
• Set VariableでCookie値を変数に保存
• Copy Activityの「追加ヘッダー」に Cookie を設定してAPIを呼ぶ

ここで重要なのは、単に「ヘッダーを追加できるか」ではなく、Cookieの寿命・更新・複数Cookieの結合・SameSite/Secure属性・ドメイン/パス制約といった、Cookie特有の状態管理が絡むことです。ADFのコネクタは、こうしたセッション維持を全面的に肩代わりする作りではありません。

まず確認：設定ミスで「Cookieが送られていないように見える」ケース

公式に保証されない前提は置いたうえで、検証・切り分けとしては次も押さえておくと無駄が減ります。特にCopy Activityの追加ヘッダーはUIの入力形式にクセがあり、ちょっとした差で送信内容が変わります。

よくある症状	原因の例	確認・対処の例
追加ヘッダーに入れたはずなのにサーバー側でCookieが見えない	ヘッダー名と値の入れ方が不適切（値側に Cookie: を含めている等）	ヘッダー名は Cookie、値は ASP.NET_SessionId=xxxx のように「値だけ」にする
Cookieが1つではなく複数返ってくる	Set-Cookieが複数（セッション＋負荷分散用など）	Cookieヘッダーは name=value; name2=value2 のようにセミコロン区切りで結合する
Connect直後は通るが少しすると401/403になる	Cookieの有効期限が短い、もしくはサーバー側でセッションが失効	「Cookieを使い回す」より、外部コンポーネントで毎回ログイン→取得を確実に行う
自ホストIRだと通るがAzure IRだと通らない（または逆）	ネットワーク経路、プロキシ、TLS、IP制限、ヘッダー制限の差	サーバー側ログで受信ヘッダーを確認し、IRの出口IP・TLS設定を点検する
ヘッダー値にダブルクォートが混ざり壊れる	JSON/式展開のエスケープ不足	Key Vaultに保存する値は「そのまま貼る」前提で、不要な引用符を入れない

ただし、これらを全部整えても「セッションCookieをレスポンスから受け取り、次のHTTP呼び出しに確実に引き継ぐ」という要件自体がADFのコネクタ設計と噛み合わないため、運用では別アプローチを推奨します。

本番運用で選ばれやすい解決策：API呼び出しをADFの外に切り出す

セッションCookieが絡むAPIは、ADFに「全部やらせる」よりも、Cookie管理とAPI呼び出しを専用コンポーネントに寄せ、ADFはオーケストレーションとデータ取り込みに集中させたほうが安定します。特にSOAPはリクエストボディやSOAPActionなどの自由度が必要になりやすく、コードでの制御が効く形が現実的です。

選択肢A：Azure Functionsでログイン→取得→保存まで一気通貫

最も実務で扱いやすいのが、Azure Functions（またはApp Service）で「ログインしてCookieを取得し、SOAP APIを叩き、結果をBlob/Data Lakeへ保存する」役割をまとめる方法です。ADF側はFunctionsをトリガーし、戻り値（保存先パスなど）を後続処理に渡します。

ステップ	担当	具体例
1. Connectでセッション確立	Azure Functions	HTTPクライアントでログイン。Set-CookieをCookieContainer等で保持
2. SOAP API呼び出し	Azure Functions	同一セッションで必要なエンドポイントを呼び、XMLレスポンスを取得
3. 結果をストレージに保存	Azure Functions	Blob/Data Lakeに yyyy/MM/dd/... で保存し、パスを返す
4. 後続の加工・取り込み	ADF	保存済みファイルをソースにCopy Activityで整形・ロード

この方式のメリットは、Cookieの細かい扱い（失効時の再ログイン、複数Cookie、リトライ、サーバーの癖）をコードで吸収できることです。また、セキュリティ面でも「CookieをADFの変数に入れて可視化リスクを抱える」より、Key Vault＋マネージドIDでFunctions側に閉じ込めやすくなります。

実装イメージ（擬似コード）

// 例：概念だけ示す（言語は任意）
1) ConnectへPOST
2) 応答ヘッダー Set-Cookie をCookieコンテナへ格納
3) 同じHTTPクライアントでSOAPエンドポイントへPOST（Cookieは自動付与）
4) 応答ボディ（XML/ZIP等）をBlobへ書き込み
5) 書き込み先URLやパスを返却

選択肢B：Logic AppsでHTTPワークフローを組む

コードを書きたくない、もしくはワークフローとして可視化したい場合はLogic Appsも候補です。HTTPアクションでConnect→SOAP呼び出し→ストレージ保存を構成し、ADFからはLogic Appsを呼び出します。

• 監査・可観測性（各ステップの履歴）が欲しい
• エラー時の分岐や通知（Teams/メール）が必要
• API呼び出し回数がそれほど多くない

こうした要件がある現場では、Logic Appsのほうが運用しやすいことがあります。

選択肢C：コンテナ/バッチに寄せて「API取得ジョブ」を別建てにする

大量データや長時間処理になりがちな場合、Container Apps / AKS / Azure Batchなどで取得ジョブを動かし、ADFはジョブの起動と結果取り込みを担当する構成も現実的です。

向いているケース	理由
取得に時間がかかる（分〜時間）	タイムアウトやリトライ制御を自由に設計できる
API側の制限が厳しい（レート制限、同時接続数）	キューイングやバックオフなどを実装しやすい
複数ステップのセッション継続が必須	同一プロセス内でCookie管理を完結できる

コミュニティで見かける回避策：Cookie値をKey Vaultに入れてヘッダーに差し込む

後日談として共有されがちな手として、Cookie値そのものをAzure Key Vaultのシークレットとして登録し、HTTPリンクドサービスの認証ヘッダー（Auth headers）や追加ヘッダーに参照させる方法があります。ポイントは「レスポンスから自動でCookieを受け取る」のではなく、事前に固定値としてCookieを持つことです。

項目	内容	注意点
やり方	Key Vaultに soap-cookie のようなシークレットを保存し、Cookieヘッダーに差し込む	Cookieが短命だとすぐ失効する
運用	別仕組みで定期的にログイン→Cookie再取得→Key Vault更新	更新処理そのもののセキュリティ・監査が必要
メリット	ADFだけで完結しやすい（見た目上）	公式パターンではなく、仕様変更に弱い

「Cookieの有効期限が比較的長い」「更新頻度が低い」「セキュリティ審査で許容される」など条件が揃えば、実装コストは抑えられます。一方で、Cookieの更新を自動化する時点で結局は外部コンポーネントが必要になり、中途半端に複雑化することも多いので、採用判断は慎重に行うのがおすすめです。

API提供元と相談できるなら：認証方式の見直しが最も保守しやすい

セッションCookieは、ブラウザーや人手操作を前提にした設計であることが多く、データ連携基盤（ETL/ELT）からの利用と相性が良いとは言えません。可能であれば、次のような方式へ変更できないか、API提供元と相談する価値があります。

• OAuth2 / Client Credentials：長寿命トークンやトークン更新の標準化がしやすい
• 静的なAPIキー：権限分離やローテーション設計を前提にできる
• クライアント証明書（mTLS）：ネットワーク境界と組み合わせて強固にできる

また、直接変更が難しい場合でも、Azure API Managementなどで「Cookie必須のSOAP」を「ADFが呼びやすいエンドポイント」にラップする設計が取れることがあります（社内向けの変換層を作るイメージです）。

セキュリティと運用で押さえるべきポイント

Cookieは「ただの文字列」ではなく、実質的にログイン済みセッションを再現できる資格情報です。ADFの変数やアクティビティ出力に残すと、権限のある人が再利用できるリスクが生まれます。次の観点で点検してください。

観点	推奨	避けたい例
秘密情報の保管	Key Vault＋マネージドIDで参照。更新も監査可能にする	ADFのパラメータや変数に平文で埋め込む
ログ/出力の露出	必要に応じてSecure input/outputを使い、閲覧権限も最小化	モニター画面でCookieが見えてしまう状態を放置
失効時の挙動	外部コンポーネントで再ログイン・再取得を自動化し、アラートも設計	たまたま動いている状態に依存し、失効時に原因不明で止まる
ネットワーク境界	Private Link/VNet統合、IP制限、証明書検証などを明確化	インターネット経由で無防備に叩く

設計判断の早見表：どの選択肢を取るべきか

条件	おすすめ	理由
Cookieが短命（数分〜数時間）で、毎回ログインが必要	Azure Functions / コンテナでAPI取得を実装	セッション維持と再ログインをコードで確実に扱える
API呼び出しが少なく、分岐や通知も含めて運用したい	Logic Appsでワークフロー化	履歴が追いやすく、運用チームが扱いやすい
Cookieが長命で、更新頻度が低い（例：月1など）	Key VaultにCookieを保管し、ADFのヘッダーに参照	実装コストは小さいが、更新運用は必須
提供元と交渉でき、長期保守性を重視したい	認証方式の変更（OAuth2等）	ADFとの相性が良くなり、将来コストが最小化しやすい

よくある質問

Q. Copy Activityの追加ヘッダーにCookieを入れれば「理屈では」動くのでは？
A. 固定値のCookieを送るだけなら動く場合もあります。ただし、レスポンスCookieを受け取って次に引き継ぐ、失効時に再取得する、といったCookie特有の状態管理はADFが得意ではありません。再現性と運用性を優先するなら外部化が安全です。

Q. Webアクティビティだけで完結させるのはダメ？
A. 小さなレスポンスを扱うだけなら成立することがありますが、「レスポンスをそのままファイル化」「大きなペイロード」「リトライや分割」まで求めると設計が苦しくなりやすいです。結果の保存はCopy Activityに任せ、API取得は別コンポーネントに寄せると整理できます。

Q. セキュリティ上、CookieをストレージにPOSTするMVPはどう判断すべき？
A. 方式としては作れますが、資格情報や業務データが混ざると漏えいリスクが高くなります。どうしても行う場合でも、暗号化、短期保存、アクセス制御、監査ログ、失効手順までセットで設計してください。一般にはKey Vault＋マネージドID＋サーバー側での直接保存のほうが安全です。

まとめ

• ADFのCopy Activity（HTTP/RESTコネクタ）は、レスポンスCookieを受け取って後続呼び出しに引き回す用途を前提にしていないため、Cookieベース認証のSOAP APIとは噛み合いにくい
• 「WebアクティビティでCookie取得→変数保存→Copy Activityの追加ヘッダーに設定」は再現性が低く、本番運用では事故要因になりやすい
• 実務では、Azure Functions/Logic Apps/コンテナ等にAPI呼び出しを寄せ、結果をBlob/Data Lakeに保存してからADFで取り込む構成が安定しやすい
• Key VaultにCookieを事前登録して差し込む方法は条件が合えば使えるが、更新運用と将来の仕様変化リスクを織り込んで採用する
• 可能なら認証方式の見直し（OAuth2等）が長期的には最も保守しやすい