Event-Driven Copy Job Execution with Fabric Activator の要点は、Microsoft Fabric の Copy job を Fabric Activator のルールから直接実行できるようになったことです。これにより、「5分ごとに空振り実行する」のではなく、「新しいファイルが届いた」「テーブルが更新された」「メトリックがしきい値を超えた」といったイベントをきっかけにデータ移動を開始できます。Microsoft Fabric 利用者は、既存のスケジュール実行をすぐ置き換えるのではなく、空実行が多い Copy job、低遅延化したい取り込み処理、Pipeline を使うほど複雑ではないデータコピーから確認するのが現実的です。Microsoft の更新情報では、この機能は June 2026 の Data Factory 項目として Generally Available とされています。(Microsoft Learn)
Event-Driven Copy Job Execution with Fabric Activator は何が変わった？
今回の変更は、Copy job と Fabric Activator の距離が近くなった点にあります。公式ブログでは、Activator から Copy job を直接呼び出せるようになり、Pipeline を介さずイベント駆動のデータ移動を構成できると説明されています。([Microsoft Fabric Community][2])
従来のデータ移動は、毎時、毎日、5分ごとなどの固定スケジュールで実行する構成が一般的でした。しかし、データが更新されていない時間帯にもジョブが動くため、無駄な実行、コスト増、監視対象の増加が起きやすくなります。今回の GA により、Copy job を「時間」ではなく「出来事」に反応して実行しやすくなりました。
| 観点 | これまでの典型例 | 今回の変更後にできること | 実務上の意味 |
|---|---|---|---|
| 起動方法 | Copy job を手動実行、またはスケジュール実行 | Activator ルールから Copy job を直接起動 | データが変わった時だけコピーしやすい |
| 構成の複雑さ | イベント起動に Pipeline を挟むことが多い | 単純なコピーなら Pipeline なしで構成可能 | 小規模な取り込み処理を軽く作れる |
| 遅延 | 実行間隔に依存 | イベント検知後に実行 | データ鮮度を上げやすい |
| コスト管理 | 空実行が発生しやすい | 不要な実行を減らしやすい | ただし実行時の CU 消費確認は必要 |
重要なのは、Pipeline が不要になるわけではないことです。条件分岐、複数ステップの前後処理、承認、複雑なリトライ、複数ジョブの依存関係を制御する場合は、引き続き Pipeline のほうが適しています。今回の機能は、「イベントを検知したら、決まった Copy job を起動する」用途に向いています。
対象になる Microsoft Fabric 利用者
影響を受けるのは、主に Microsoft Fabric の Data Factory、Copy job、Activator、OneLake、Lakehouse、Warehouse を使っているチームです。特に次のような運用をしている場合は確認する価値があります。
- 高頻度のスケジュール実行で、実際には空実行が多い
- ファイル到着後、できるだけ早く Lakehouse や Warehouse にコピーしたい
- OneLake、Eventstream、監視データなどを起点に処理を動かしたい
- Pipeline を作るほどではないが、手動実行や定期実行だけでは不便
- Copy job のフルコピー、差分コピー、CDC を使ってデータ移動を標準化したい
たとえば、外部ストレージに CSV や Parquet ファイルが到着したタイミングで Lakehouse に取り込む処理、業務テーブルの更新を検知して Warehouse へ差分コピーする処理、監視メトリックが一定値を超えたときだけ退避用データをコピーする処理などが候補になります。公式ブログでも、OneLake のテーブル更新、新規ファイル到着、メトリックしきい値到達といった例が示されています。([Microsoft Fabric Community][2])
すぐ確認したい設定ポイント
Copy job のコピー方式を確認する
最初に見るべきなのは、対象の Copy job がフルコピーなのか、増分コピーなのかです。Copy job はフルコピーと増分コピーを選択でき、増分コピーでは初回に全件コピーを行い、その後は前回成功時点以降の新規または変更データをコピーします。(Microsoft Learn)
イベント駆動にする場合、毎回フルコピーだとイベント発生のたびに大きなデータ移動が走る可能性があります。小さなマスターデータなら問題になりにくい一方、取引明細、ログ、IoT データのように量が増えるテーブルでは、増分コピーや CDC の利用を優先して検討してください。
| 確認項目 | 推奨判断 |
|---|---|
| 小さな参照テーブル | フルコピーでも運用しやすい |
| 日々増える明細テーブル | 増分コピーを優先 |
| 更新・削除も反映したい | 対応ソースで CDC を検討 |
| 宛先の重複が困る | Merge、キー列、宛先更新方式を確認 |
| 初回ロードが重い | 初回実行の時間帯と容量を事前に調整 |
Copy job のドキュメントでは、ウォーターマークベースの増分コピーと CDC ベースの増分コピーの使い分けも説明されています。CDC が使えるソースで、挿入、更新、削除まで追跡したい場合は CDC が候補になります。一方、信頼できる日時列や連番列で新規・更新を追える場合は、ウォーターマーク方式が現実的です。(Microsoft Learn)
Activator ルールの条件を絞り込む
Activator は、データの状態やイベントを監視し、条件を満たしたときにアクションを起動する仕組みです。Microsoft Learn では、Activator のルールが継続的に評価され、条件を満たすと Pipeline、Notebook、Dataflow、Copy job などの Fabric アイテムを起動できると説明されています。(Microsoft Learn)
ただし、イベントを広く取りすぎると、同じような Copy job が短時間に何度も走る可能性があります。たとえば、1つのフォルダーに多数のファイルが連続投入されるケースでは、「ファイルが1つ作成されるたびに起動」でよいのか、「一定のまとまりがそろったら起動」にすべきかを考える必要があります。
実務では、次のように条件を分けると判断しやすくなります。
| シナリオ | 条件設計の考え方 |
|---|---|
| 1日数回のファイル到着 | ファイル作成イベントで起動しやすい |
| 数百ファイルが短時間に到着 | 連続起動や重複処理の抑制を検討 |
| テーブル更新を検知したい | 更新頻度とコピー対象範囲を確認 |
| メトリックしきい値で起動 | しきい値超過が続く間に何度も起動しない設計が必要 |
| 本番データの取り込み | テストルールで発火回数を確認してから開始 |
Action で Invoke Copy job を選ぶ
公式ブログの手順では、まず Copy job を作成し、次に Activator ルールでデータソースと条件を定義し、Action で “Invoke Copy job” を選択して対象の Copy job を指定する流れが示されています。ルールを開始すると、Activator が条件を監視し、条件が満たされたタイミングで Copy job が自動実行されます。([Microsoft Fabric Community][2])
実装時は、いきなり本番ジョブを接続せず、まず検証用の Copy job を作るのが安全です。宛先をテスト用 Lakehouse や検証テーブルにして、イベント1回あたりの実行回数、コピー件数、失敗時の挙動を確認してから本番に近づけてください。
運用上の注意点
イベント駆動でもコスト確認は必要
イベント駆動にすると空実行は減らしやすくなりますが、Copy job の実行が無料になるわけではありません。Copy job は実行時に Fabric Capacity Units、つまり CU を消費します。Microsoft Learn では、フルコピーと増分コピーのパターンに応じて CU が消費され、Fabric Capacity Metrics app で実行コストを見積もるのが最も正確だと説明されています。(Microsoft Learn)
特に注意したいのは、増分コピーの初回実行です。増分コピーでも初回は全件ロードになるため、イベントルールを開始した直後に大きなデータ移動が走る可能性があります。本番では、初回ロードを業務時間外に実行し、その後に Activator 連携へ切り替えるほうが安全です。
既存スケジュールとの二重起動を避ける
既存の Copy job にスケジュールが残ったまま Activator からも起動すると、同じ時間帯にスケジュール実行とイベント実行が重なる可能性があります。
すぐにスケジュールを消す必要はありませんが、目的を明確に分けてください。たとえば、イベント起動を主系にし、1日1回のスケジュールを整合性確認用の補助実行として残す設計はあり得ます。一方、5分ごとのスケジュールとイベント起動を同時に動かすと、コストと監視ノイズが増えるだけになりがちです。
Copy job にパラメーターを渡す設計は慎重にする
Microsoft Learn の Trigger Fabric items のページでは、Activator から Fabric アイテムにパラメーター値を渡す説明がある一方で、Copy jobs はパラメーターを受け付けない旨も記載されています。(Microsoft Learn)
そのため、「イベントの内容に応じて、同じ Copy job のソースパスや宛先を動的に切り替える」前提で設計すると、期待通りに実装できない可能性があります。現時点では、用途別に Copy job を分け、Activator ルール側で起動対象を明確にする設計のほうが安全です。
発火回数と制限を確認する
Activator には制限があります。Microsoft Learn の制限ページでは、1ルールあたり最大 10,000 incoming events per second、Fabric item の Activation は user/minute あたり 50 という制限が示されています。(Microsoft Learn)
通常の業務データ取り込みではすぐ問題にならないことも多いですが、ログ、IoT、クリックストリーム、ファイル大量投入のようなケースでは、イベント数が想定を超えることがあります。Activator ルールを作る前に、ピーク時のイベント数と Copy job の実行時間を確認してください。
既存環境への影響範囲
今回の変更は、新しい実行方法が増える更新です。既存の Copy job、Pipeline、スケジュール実行が自動的に置き換わるものではありません。そのため、既存運用に対する直接的な破壊的変更というより、「改善できる運用が増えた」と捉えるのが自然です。
ただし、運用設計を変える場合は影響があります。特に次の点を確認してください。
| 確認対象 | 見るべきポイント |
|---|---|
| 既存 Copy job | フルコピーか増分コピーか、宛先更新方式は何か |
| 既存スケジュール | Activator 起動と重複しないか |
| 宛先テーブル | 重複行、更新漏れ、削除反映の要件があるか |
| 監視 | Copy job panel と Monitoring hub で追跡できるか |
| 容量 | イベント起動後の CU 消費が想定内か |
| 権限・管理 | 誰が Activator ルールを作成・開始・停止するか |
| 障害対応 | 失敗時に再実行する担当と判断基準が決まっているか |
Copy job の監視では、Copy job panel や Monitoring hub から実行状態、Rows read、Rows written、Throughput、Run ID、増分コピーの lower bound / upper bound などを確認できます。運用開始後は、少なくとも数日間は実行履歴を確認し、発火回数とコピー件数が想定通りかを見てください。(Microsoft Learn)
置き換えるべき処理と残すべき処理
Event-Driven Copy Job Execution with Fabric Activator は便利ですが、すべてのデータ移動をイベント駆動にすればよいわけではありません。
置き換え候補になりやすい処理
- 高頻度スケジュールなのに、実際の更新が少ない
- ファイル到着後すぐにコピーしたい
- 単一の Copy job を起動するだけで完結する
- 処理失敗時の再実行が比較的単純
- Pipeline の条件分岐や複数ステップを使っていない
既存の Pipeline やスケジュールを残したほうがよい処理
- 前処理、コピー、後処理、通知を一連の流れで制御している
- 複数の Copy job や Notebook を順番に実行している
- 複雑なリトライ、分岐、承認、例外処理が必要
- バックフィルや月次締め処理など、時間基準の実行に意味がある
- イベントの欠落や遅延に備えて定期的な整合性確認が必要
判断基準はシンプルです。「イベントが起きたら決まった Copy job を動かすだけ」なら Activator 連携が向いています。「処理全体の流れを制御する必要がある」なら Pipeline を残します。
導入前のチェックリスト
本番適用前に、次の順番で確認すると失敗を減らせます。
| 手順 | 確認内容 |
|---|---|
| 1 | 既存の Copy job とスケジュールを棚卸しする |
| 2 | 空実行が多いジョブを候補にする |
| 3 | フルコピー、増分コピー、CDC のどれが適切か確認する |
| 4 | 宛先の重複、更新、削除反映の要件を確認する |
| 5 | 検証用 Copy job を作成する |
| 6 | Activator ルールで発火条件を絞る |
| 7 | Test action と少量データで挙動を確認する |
| 8 | Monitoring hub で実行履歴、件数、スループットを確認する |
| 9 | 既存スケジュールを停止するか、補助用途として残すか決める |
| 10 | CU 消費と失敗時の再実行手順を運用ルールに入れる |
よくある疑問
既存の Copy job は作り直しが必要？
必ず作り直す必要はありません。既存の Copy job を Activator から起動できる構成にできる場合は、そのまま活用できます。ただし、フルコピーのままイベント駆動にすると実行回数が増えたときに重くなるため、コピー方式と宛先更新方式は見直してください。
Pipeline は不要になる？
不要にはなりません。今回の GA は、単純なイベント駆動コピーを軽く作れるようにする変更です。複数ステップのオーケストレーション、条件分岐、エラー処理、通知、承認を含む処理では Pipeline の役割が残ります。
まずどの処理から試すべき？
最初は、失敗しても業務影響が小さく、データ量が少なく、現在スケジュール実行している Copy job が向いています。たとえば、検証用フォルダーへのファイル到着をトリガーに、テスト用 Lakehouse へコピーする構成から始めると安全です。
まとめ：最初に確認すべきこと
Event-Driven Copy Job Execution with Fabric Activator の変更点は、Microsoft Fabric の Copy job を Activator ルールから直接起動できるようになったことです。これにより、Pipeline を挟まずに、ファイル作成、テーブル更新、メトリックしきい値到達などのイベントを起点にデータ移動を実行できます。
Microsoft Fabric 利用者がまず行うべきことは、既存の高頻度スケジュール Copy job を棚卸しし、空実行が多いものを1つ選ぶことです。そのうえで、増分コピーや CDC の適用可否、宛先の重複対策、Activator ルールの発火条件、Monitoring hub での監視、CU 消費を確認してください。
いきなり全社標準にするのではなく、低リスクな Copy job で検証し、効果が見えたものから段階的に置き換えるのが最も安全です。
[2]: https://community.fabric.microsoft.com/t5/Fabric-Updates-Blog/Event-Driven-Copy-Job-Execution-with-Fabric-Activator-Generally/ba-p/5195808 “
Event-Driven Copy Job Execution with Fabric Activa… – Microsoft Fabric Community
“
コメント