Azure Storage コンテナーを監視する Azure Databricks の「ファイル到着トリガー」が、SFTP アップロードだけ反応しない——この現象は設定ミスではなく、現時点の仕様制限に起因するケースが多いです。本記事ではイベントの仕組みを整理し、実運用で使える回避策を具体例つきでまとめます。
現象の整理：ポータル（HTTPS）だと即時起動、SFTPだと起動しない
まずは状況を、できるだけ「事実ベース」で整理します。ポイントは、同じコンテナー／同じフォルダ配下にファイルが置かれているのに、アップロード経路によって Databricks ジョブの起動有無が変わることです。
| アップロード経路 | Azure 側の見え方 | Event Grid ログ | Databricks「ファイル到着トリガー」 |
|---|---|---|---|
| Azure ポータル（コンテナーUI） | 通常の Blob/ADLS 経由の書き込み | 一致してすぐ流れる | ほぼ即時に起動する |
| HTTPS（SDK / REST / AzCopy など） | 通常の Blob/ADLS 経由の書き込み | 一致してすぐ流れる | ほぼ即時に起動する |
| SFTP（第三者が接続） | SFTP 特有の API（SftpCreate/SftpCommit 等）で書き込み | フィルターに「一致」しているのに、起動が不安定 | 起動しない／1日1回程度など極端に遅い |
「Event Grid のログ上はマッチしている」ことが確認できている場合、切り分けとしては以下が濃厚です。
- イベントが発行されていない（発行側の問題）ではない
- Event Grid のフィルターが間違っていて配送されない、だけでもない（少なくとも“一致”は見えている）
- 配送されたイベントを“最終的に消費してジョブを起動する側（Databricks）”が、そのイベントをトリガー条件として扱えていない
勘違いが多いポイント：Event Grid の「イベントタイプ」と「Data API」は別レイヤー
SFTP 周りのトラブルでは、用語の混線が起きやすいです。Event Grid には大きく分けて次の2つの観点があります。
- イベントタイプ（eventType / type）：例）
Microsoft.Storage.BlobCreated、Microsoft.Storage.BlobDeleted、Microsoft.Storage.BlobRenamed - Data API（data.api）：そのイベントの発火原因になった「操作名」。例）
PutBlockList、FlushWithClose、SftpCommit、SftpRename
特に SFTP の場合は、アップロード完了までに複数の操作が発生するのが重要です。たとえば「ファイルを開いた瞬間に空のファイル（またはゼロバイト）として作られ、クローズ時に中身がコミットされる」といった流れになります。そのため、イベントが複数回届くこと自体は“異常”ではないことがあります。
| 操作（data.api の例） | 意味合い | 運用上の注意 |
|---|---|---|
SftpCreate | SFTP クライアントがファイルを開くなどして、空の Blob を作る段階 | ここで処理を始めると「中身がまだない」可能性が高い |
SftpWrite | （環境や機能により）アップロード途中の書き込み | 途中データで処理しないように注意 |
SftpCommit | アップロードが完了し、内容が確定した段階 | 「到着トリガー」に最も向く（完了シグナルとして扱いやすい） |
SftpRename | SFTP でリネーム（多くの“テンポラリ→本番名”運用で発生） | “確定ファイル名にリネームされた瞬間”をトリガーにできる |
つまり「SftpCommit をイベントタイプとして追加した」と表現していても、実際には Event Grid のフィルター（Data API）に追加しているだけ、というケースが多いです。ここを整理しておくと、次の“結論”が腑に落ちやすくなります。
Databricks「ファイル到着トリガー」の仕組み：イベントが効くと速いが、万能ではない
Azure Databricks のファイル到着トリガーは、指定した外部ロケーション（Unity Catalog の external location / volume）配下を監視し、ファイル到着をきっかけにジョブを起動します。監視はベストエフォートで、一定間隔のチェック（ストレージ側の状態により遅延の影響を受ける）という性質があります。
また、外部ロケーションで「ファイルイベント（file events）」を有効化すると、クラウド側の変更通知を処理して到着検知を効率化する仕組みが使われます。一般にこの設定は“性能改善”に効きますが、どんな種類の通知でも必ずトリガーできるという意味ではありません。
結論：SFTP での到着を Databricks のファイル到着トリガーだけで安定起動させるのは難しい
質問の核心である「どのイベントタイプを、どのフィルター条件で設定すればよいか？」に対して、現時点での実務的な答えは次のとおりです。
Event Grid 側のフィルターを追加しても、Databricks のファイル到着トリガーが SFTP 由来のイベント（SftpCommit/SftpCreate 等）をトリガーとして消費できないため、設定だけで解決しないケースがある。
これは Azure Storage / Event Grid の設定不備というより、Databricks 側の対応範囲（仕様・制約）に起因する、という整理になります。
「Event Grid では一致しているのに、なぜ1日に1回程度だけ起動するのか
この“たまに動く”挙動が一番ややこしいところです。考え方としては、次の2つを分けると理解しやすくなります。
- イベント通知での高速検知：うまく消費できればほぼ即時。ただし未対応の通知だと検知に使えない
- ポーリング（一覧チェック）での遅延検知：イベントが機能しない／拾えない場合でも、最終的に「新規ファイルがある」ことを遅れて見つける可能性がある
Databricks のファイル到着トリガー自体が「ベストエフォートで定期チェック」という性質を持つため、イベントで拾えない状況でも、ストレージ側の状態や内部処理のタイミング次第で遅延検知が発生し得ます。その結果として「毎回即時ではないが、たまに走る」状態になりやすい、という整理です。
なお、SFTP はアップロード途中にもイベントや変更が発生しやすく、処理側が“完了”と判定できないと起動しても意味がない、という別の難しさもあります。だからこそ、回避策では「完了シグナル（SftpCommit もしくは rename）」を明確に扱う構成を取るのが現実的です。
回避策の全体像：目的別に選ぶ
SFTP の運用要件（第三者が SFTP でしか送れない／監査上 SFTP を残したい 等）があるかどうかで、選ぶべき対処が変わります。
| 回避策 | こんなときに向く | メリット | 注意点 |
|---|---|---|---|
| アップロード方式を HTTPS（SDK/REST/AzCopy）に変更 | 第三者の送信手段を変えられる | Databricks 標準のファイル到着トリガーをそのまま使いやすい | 相手先の手順変更が必要 |
| Event Grid → Azure Functions / Logic Apps → Databricks Jobs API | SFTP は維持しつつ、即時処理を実現したい | 完了イベント（SftpCommit / SftpRename）で確実に起動できる設計にできる | 実装・運用（認証/リトライ/重複排除）が必要 |
| Event Grid → Azure Data Factory（SFTP対応のフィルター）→ Databricks | すでに ADF を使っている／ノーコード寄りで組みたい | 運用設計（監視・再実行）を ADF 側に寄せやすい | ADF の設計思想に合わせる必要がある |
回避策：HTTPS/通常アップロードに切り替えられるなら最優先
もし第三者との合意が取れるなら、SFTP をやめて HTTPS（SDK/REST/AzCopy など）でアップロードするのが最もシンプルです。Databricks のファイル到着トリガーが想定している“通常の到着検知”に寄せられるため、追加コンポーネントが増えにくいからです。
実務でよく使う移行パターンは次のとおりです。
- SAS（期限付き URL）を発行して渡す（相手は HTTPS PUT/SDK でアップロード）
- AzCopy のコマンドテンプレートを渡す（相手の運用で回せるなら早い）
- 「アップロード完了後に done ファイルを置く」など、完了シグナルを明示する
ただし「第三者が SFTP クライアントしか使えない」「セキュリティ要件で SFTP が必須」のような場合は、このルートが取れません。その場合は次の構成が現実的です。
回避策：Event Grid で SFTP の完了イベントを拾い、Jobs API で Databricks を起動する
Databricks のファイル到着トリガーにこだわらず、“SFTP の完了通知”を起点に Databricks Jobs API を直接叩く構成にすると、要件を満たしやすくなります。
（推奨構成イメージ）
SFTP アップロード
↓（Azure Storage がイベント発行）
Event Grid（フィルター：SftpCommit / SftpRename）
↓
Azure Functions もしくは Logic Apps
↓（Jobs API 呼び出し）
Azure Databricks Job 実行（処理対象のパスをパラメータで渡す）Event Grid 側の設定の考え方
“処理を始めてよい瞬間”をどこに置くかで、フィルターが変わります。
| 狙い | イベントタイプ（例） | Data API（例） | おすすめの理由 |
|---|---|---|---|
| アップロード完了で起動 | Microsoft.Storage.BlobCreated | SftpCommit | 「中身が確定した」タイミングを拾いやすい |
| “確定名へのリネーム”で起動 | Microsoft.Storage.BlobRenamed | SftpRename | テンポラリ名→本番名にする運用と相性が良い |
| フォルダ単位の運用を検知 | Microsoft.Storage.DirectoryCreated 等 | SftpMakeDir 等 | フォルダ作成を“バッチ開始合図”にできることがある |
さらに、Event Grid には対象フォルダだけに絞るための subject フィルターがあります。対象コンテナー／対象パス以外のイベントを落とすことで、Function/Logic Apps 側の負荷や誤起動を減らせます。
設計のコツは次のとおりです。
- eventType は必要最小限（BlobCreated と BlobRenamed など、目的に合うものだけ）
- subject begins with でフォルダに絞る（例：
/blobServices/default/containers/コンテナー名/blobs/監視フォルダ/） - data.api は “完了” を示す値に寄せる（SftpCommit / SftpRename）
Azure Functions で Jobs API を叩く（実装例）
ここでは「Event Grid → Azure Functions（EventGridTrigger）→ Databricks Jobs API」という最小構成の考え方を示します。実装言語は何でもよいのですが、重要なのは以下です。
- Event Grid は少なくとも1回の配送（重複し得る）を前提にする
- SFTP は SftpCreate → SftpCommit のように複数イベントが発生し得る
- 結果として重複起動の抑止（冪等性）が必須になる
例として、受け取ったイベントから URL/パスを取り出してジョブを起動するイメージを示します。
POST https://<databricks-host>/api/2.2/jobs/run-now
Authorization: Bearer <token>
Content-Type: application/json
{
"job_id": 123456,
"notebook_params": {
"input_url": "https://<storage-account>.blob.core.windows.net/<container>/path/to/file.csv"
}
}ここで渡すパラメータは、次のどちらかが扱いやすいです。
- Blob の URL（
data.urlなど） - コンテナー＋パス（
subjectから復元）
Event Grid 側で subject フィルターをしっかりかけておけば、「監視フォルダ配下のファイル」だけが流れてくるので、Function 側の分岐が減ります。
認証の選び方：最短は PAT、運用目線なら OAuth（サービスプリンシパル）
Jobs API を呼び出すには Databricks への認証が必要です。結論としては次の判断が現実的です。
| 方式 | おすすめ度 | メリット | 注意点 |
|---|---|---|---|
| PAT（Personal Access Token） | PoC / 小規模運用向き | 実装が簡単。HTTP ヘッダに付けるだけ | トークン管理（期限・漏えい対策）が必須。Key Vault 推奨 |
| OAuth（M2M / サービスプリンシパル） | 本番向き | 原則として機械実行に適した設計。権限分離もしやすい | 初期設定（SP 作成、ワークスペース割り当て等）が必要 |
特に本番では「ジョブのオーナーや実行主体」をサービスプリンシパルに寄せると、担当者の退職・異動でジョブが止まるリスクを減らせます。
重複起動を防ぐための実務テクニック（重要）
Event Grid は再配信や重複があり得ます。また、SFTP は Create/Commit/（場合によっては Rename）と複数イベントが出ます。したがって、どの回避策を採る場合でも「重複排除」を組み込むのが安全です。
| 重複排除のキー例 | 長所 | 短所 |
|---|---|---|
Event Grid の id | イベント単位で一意になりやすい | 同一ファイルでも別イベントは別ID |
subject（パス）＋data.api | 「同じファイルに対する同じ操作」をまとめやすい | リネーム運用だと subject が変わる |
（可能なら）sequencer を併用 | 順序の判定に使える場合がある | 扱いに慣れが必要 |
一番シンプルな実装は、Function 側で「処理済みイベントIDを一定期間保存（Table Storage / Cosmos DB / Redis 等）」して、同じ ID が来たら何もしないようにすることです。ファイル単位で厳密にやりたいなら、ジョブ側（Delta テーブルなど）に処理済み一覧（ファイルURL・ハッシュ・到着時刻）を残す設計も強いです。
回避策：Azure Data Factory を挟んで起動する（すでに ADF を使うなら現実的）
すでに Azure Data Factory（または Synapse Pipelines）を運用している場合、ストレージイベントトリガーで SFTP の Data API をフィルター対象に含めたうえで、パイプラインから Databricks を起動する設計も取りやすいです。
このルートの利点は、再実行・監視・失敗時の運用を ADF の世界観に寄せられる点です。Databricks 側は「処理そのもの」に集中できます。
よくある設計パターン：SFTP の“完了”をより確実にする
「SftpCommit を拾う」以外にも、実運用では “ファイルが完全に揃ったこと” を表現する工夫が効きます。とくに第三者連携では、SFTP クライアントや運用ルールがバラバラになりやすいため、受け側で吸収できる仕組みを作ると事故が減ります。
| パターン | やり方 | メリット | 注意点 |
|---|---|---|---|
| テンポラリ名でアップロードして、最後にリネーム | file.csv.tmp → file.csv | “確定名”に変わった瞬間だけ処理できる | SftpRename/BlobRenamed を拾う設計が必要 |
| done ファイル方式 | file.csv と file.csv.done をセットで置く | バッチの完了条件を明確化できる | 送信側にルール徹底が必要 |
| 到着後に一定時間待ってから処理 | Function/Logic Apps 側で遅延させる、またはジョブ側で判定 | 途中書き込みを回避しやすい | 遅延が許容できるか要検討 |
まとめ：設定で直すより、起動経路を分けるのが現実解
- 「Event Grid 側で SftpCommit/SftpRename を追加したのに Databricks が即時起動しない」場合、ストレージや Event Grid の設定ミスではなく、Databricks 側の対応範囲（仕様制約）に当たっている可能性が高い
- SFTP を維持したいなら、Event Grid → Azure Functions / Logic Apps → Databricks Jobs API のように、SFTP 完了イベントから自前でジョブ起動する設計が安定しやすい
- 第三者連携では重複や途中ファイルの問題が起きやすいので、完了イベント（SftpCommit / SftpRename）＋重複排除をセットで入れるのが安全
コメント