Azure SQL trigger for Functionsは、Azure SQLやSQL Serverのテーブル変更をきっかけにAzure Functionsを実行するためのSQLトリガーバインドです。結論から言うと、今回確認すべきポイントは「コードの書き方」だけではありません。変更追跡の有効化、az_funcスキーマと内部テーブルに対する権限、マネージドID利用時の追加権限、スケーリング設定、失敗時の再試行動作まで確認する必要があります。公式ドキュメントでも、Azure SQL trigger for FunctionsはSQL change trackingを使って行の作成・更新・削除を検出し、Functionsを起動する仕組みとして説明されています。(Microsoft Learn)
特に既存のAzure FunctionsでAzure SQLバインドを使っている環境では、「入力バインドや出力バインドで動いているからSQLトリガーも同じ権限で動く」と考えると失敗しやすいです。SQLトリガーではdb_datareaderやdb_datawriterだけでは不足するため、DBA、開発者、運用担当者が事前に設定を分担して確認することが重要です。(Microsoft Learn)
Azure SQL trigger for Functionsとは
Azure SQL trigger for Functionsは、SQLテーブルの変更を監視し、変更が見つかったときにAzure Functionsを呼び出す機能です。たとえば、注文テーブルに新しい行が追加されたら通知処理を実行する、ステータス更新を検知して外部システムへ連携する、削除を検知してキャッシュを無効化するといった用途に使えます。
注意したいのは、これはSQL ServerのDMLトリガーそのものではないという点です。Azure Functions側のトリガーバインドがSQL change trackingを参照し、変更をポーリングして関数を起動します。公式ドキュメントでは、一定間隔で変更一覧を取得し、変更があれば関数を呼び出し、その後Sql_Trigger_PollingIntervalMsで制御される待機時間を挟む流れとして説明されています。(Microsoft Learn)
処理対象になる操作は、基本的に次の3種類です。
| 操作 | 検知される内容 | 実務での例 |
|---|---|---|
Insert | 行の作成 | 新規注文を受け取って配送システムへ連携する |
Update | 行の更新 | ステータス変更を検知して通知を送る |
Delete | 行の削除 | 関連キャッシュや検索インデックスを削除する |
C#ではIReadOnlyList<SqlChange<T>>のように変更一覧を受け取り、Itemで変更後のデータ、Operationで操作種別を参照します。JavaScript、Python、PowerShell、Javaでも同様に、変更オブジェクトの配列やリストとして扱う形になります。(Microsoft Learn)
2026年5月の公式情報で特に見るべき変更点
2026年5月の公式情報で実務上重要なのは、Azure SQL trigger for Functionsを動かすための権限要件が明確化されたことです。GitHub上のドキュメント履歴でも、Azure SQLトリガーで必要な権限を明記するセクションが追加され、スキーマやテーブルアクセスに関するSQLコマンドが整理されています。(GitHub)
| 確認項目 | 公式情報で強調されている内容 | 現場でやるべきこと |
|---|---|---|
| SQLトリガーの権限 | 入力・出力バインド用のdb_datareader、db_datawriterだけでは不足 | 監視対象テーブル、change tracking、az_funcスキーマへの権限を付与する |
| マネージドID | Azure SQL Databaseとの接続ではMicrosoft Entra IDとマネージドIDの利用が推奨 | 接続文字列に資格情報を直書きせず、IDベース接続へ移行を検討する |
| 変更追跡 | データベースとテーブルの両方でchange trackingが必要 | 本番・ステージング・ローカルの対象DBで有効化状況を確認する |
| スケーリング | 従量課金プランとPremiumプランではターゲットベースのスケーリングが関係する | 拡張機能バージョン、PremiumプランのRuntime Scale Monitoringを確認する |
| C#実行モデル | インプロセスモデルは2026年11月10日にサポート終了予定 | 新規開発は分離ワーカーモデルを優先し、既存アプリは移行計画を作る |
単に「SQLの更新でFunctionが起動できるようになる」と捉えるのではなく、DB権限・実行モデル・スケール・再試行まで含めて設計を見直すのが今回の実務上のポイントです。
対象者と影響範囲
Azure SQL trigger for Functionsの影響を受けるのは、Functionsのコードを書く開発者だけではありません。権限設定や監視対象テーブルの管理が必要になるため、DBAやクラウド管理者も関わります。
| 対象者 | 確認すべき内容 |
|---|---|
| アプリ開発者 | SqlTrigger属性、function.json、受け取る変更データの型、例外処理、冪等性 |
| DBA | change trackingの有効化、保持期間、az_funcスキーマ、監視対象テーブルへの権限 |
| Azure管理者 | Function Appのアプリ設定、マネージドID、ホスティングプラン、Runtime Scale Monitoring |
| セキュリティ担当 | 接続文字列のシークレット管理、最小権限、マネージドID利用方針 |
| 運用担当 | Application Insights、失敗時の再試行、処理遅延、重複実行への備え |
既存のバッチ処理や常駐ポーリング処理をAzure SQL trigger for Functionsへ置き換える場合は、特に影響が大きくなります。ポーリングロジックをFunctionsに任せられる一方で、変更追跡の保持期間や失敗時の再試行動作を理解していないと、取りこぼしや重複処理の原因になります。
導入前に必ず確認したい設定
change trackingはデータベースとテーブルの両方で有効化する
Azure SQL trigger for Functionsを使うには、SQL change trackingの有効化が必須です。公式ドキュメントでは、データベース側でCHANGE_TRACKING = ONを設定し、その後に監視対象テーブルでENABLE CHANGE_TRACKINGを実行する流れが示されています。(Microsoft Learn)
ALTER DATABASE [your database name]
SET CHANGE_TRACKING = ON
(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);
ALTER TABLE [dbo].[your table name]
ENABLE CHANGE_TRACKING;CHANGE_RETENTIONは変更履歴の保持期間です。たとえば保持期間を2日にした場合、Function Appが数日間停止してから再開されたときに、保持期間を超えた変更をさかのぼって処理できない可能性があります。業務上「週末停止して月曜に再開する」「メンテナンスで数日止まる」可能性があるなら、保持期間を短くしすぎないことが重要です。
AUTO_CLEANUPは古い変更追跡情報を削除する設定です。一時的な障害でトリガーが動かない場合、状況によっては自動クリーンアップを一時的に止める判断が必要になることがあります。ただし、長期間止めると変更追跡情報が増えるため、DBAと相談して運用ルールを決めてください。
SQLトリガー用の追加権限を付与する
Azure SQL trigger for Functionsでは、監視対象テーブルを読むだけでなく、変更追跡情報や内部状態テーブルを扱う必要があります。公式ドキュメントでは、CREATE TABLE、CREATE SCHEMA、監視対象テーブルへのSELECT、VIEW CHANGE TRACKING、さらにaz_funcスキーマへの権限が必要とされています。(Microsoft Learn)
GRANT CREATE TABLE TO [<UserOrManagedIdentity>];
GRANT CREATE SCHEMA TO [<UserOrManagedIdentity>];
GRANT SELECT ON [<TableName>] TO [<UserOrManagedIdentity>];
GRANT VIEW CHANGE TRACKING ON [<TableName>] TO [<UserOrManagedIdentity>];
CREATE SCHEMA az_func;
GO
GRANT ALTER ON SCHEMA::az_func TO [<UserOrManagedIdentity>];
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::az_func TO [<UserOrManagedIdentity>];実務では、ここが最も詰まりやすいポイントです。入力バインドや出力バインドで動いていたFunction AppにSQLトリガーを追加しても、同じ権限のままでは起動時や監視時に失敗する可能性があります。特にマネージドIDを使っている場合は、「Function AppのIDにAzureリソースの権限を付けた」だけでは足りず、SQL Database内のユーザーや権限設定も必要です。
function.jsonまたは属性の必須項目を確認する
JavaScript、PowerShell、Python v1などでは、function.jsonでSQLトリガーを定義します。最低限、type、direction、tableName、connectionStringSettingを確認してください。公式ドキュメントでは、typeはsqlTrigger、directionはinに設定する必要があるとされています。(Microsoft Learn)
{
"name": "todoChanges",
"type": "sqlTrigger",
"direction": "in",
"tableName": "dbo.ToDo",
"connectionStringSetting": "SqlConnectionString"
}C#ではSqlTrigger属性を使います。tableNameにスキーマを含めるか、接続先のアプリ設定名が本番環境に存在するかを必ず確認してください。
[SqlTrigger("[dbo].[ToDo]", "SqlConnectionString")]
IReadOnlyList<SqlChange<ToDoItem>> changesLeasesTableNameは任意項目です。指定しない場合は、Function IDとTable IDをもとにリーステーブル名が生成されます。関数名や監視対象テーブルを変更すると内部状態の扱いに影響する可能性があるため、移行時はステージング環境で挙動を確認してから本番に反映するのが安全です。
host.jsonとアプリ設定で制御するポイント
Azure SQL trigger for Functionsでは、バッチサイズ、ポーリング間隔、ワーカーあたりの変更数上限を調整できます。公式ドキュメントでは、host.jsonのextensions.Sql配下にMaxBatchSize、PollingIntervalMs、MaxChangesPerWorkerを設定する例が示されています。(Microsoft Learn)
| 設定 | 既定値 | 判断基準 |
|---|---|---|
MaxBatchSize | 100 | 1回の関数呼び出しで処理する変更数。処理が重い場合は大きくしすぎない |
PollingIntervalMs | 1000 | 変更確認の間隔。短くすると反応は速くなるがDB負荷が増える |
MaxChangesPerWorker | 1000 | 保留中の変更数に応じたスケール判断に関係する |
設定例は次のとおりです。
{
"version": "2.0",
"extensions": {
"Sql": {
"MaxBatchSize": 300,
"PollingIntervalMs": 1000,
"MaxChangesPerWorker": 100
}
}
}実務では、最初からバッチサイズを大きくしすぎないほうが安全です。たとえば1件の変更で外部APIを呼ぶ処理なら、MaxBatchSizeを大きくすると一度の実行で大量のAPI呼び出しが発生します。逆に、軽量なログ連携や集計キュー投入であれば、ある程度まとめて処理したほうが効率的です。
local.settings.jsonには接続文字列などのシークレットが入ることがあります。公式ドキュメントでも、local.settings.jsonをリモートリポジトリに保存しないよう注意されています。ローカル設定とAzure上のアプリ設定は別物なので、デプロイ後にFunction App側の構成へ必要な値を登録することも忘れないでください。(Microsoft Learn)
スケーリングで確認すべきこと
Azure SQL trigger for Functionsのスケーリングは、従量課金プランとPremiumプランでターゲットベースのスケーリングが関係します。また、従量課金プランで利用するにはAzure SQL bindings for Azure Functionsのv3.1.284以降が必要とされています。(Microsoft Learn)
PremiumプランでSQLトリガーを適切にスケールさせるには、Runtime Scale Monitoringを有効にする必要があります。公式ドキュメントでは、Azure portalのFunction App構成からオンにする方法と、Azure CLIでfunctionsRuntimeScaleMonitoringEnabled=1を設定する方法が示されています。(Microsoft Learn)
az resource update \
-g <RESOURCE_GROUP> \
-n <FUNCTION_APP_NAME>/config/web \
--set properties.functionsRuntimeScaleMonitoringEnabled=1 \
--resource-type Microsoft.Web/sitesスケール設計で大切なのは、「SQLの変更量」と「関数の処理時間」をセットで見ることです。たとえば1分間に数千件の更新があるテーブルで、各変更ごとに外部APIを呼び出すと、Function側だけをスケールしても外部APIやSQL Database側が先に詰まることがあります。大量更新があるテーブルでは、SQLトリガーから直接重い処理を実行せず、Service BusやStorage Queueへ軽いメッセージを積む構成も検討してください。
移行時に失敗しやすいポイント
SQLトリガーを「完全なリアルタイム処理」と誤解する
Azure SQL trigger for Functionsは、変更をポーリングして処理します。イベント駆動に近い使い方はできますが、SQL更新と完全に同期した即時処理ではありません。ミリ秒単位の厳密なリアルタイム性や、すべての変更順序を完全に保証する設計には向きません。
公式ドキュメントでも、複数行の変更順序はCHANGETABLE関数が返す順序に基づくこと、同じ行に対して複数回の変更があった場合は変更が行単位でまとめられることが説明されています。(Microsoft Learn)
例外時の再試行と無視される行を考慮していない
関数内で例外が発生した場合、処理中の行バッチは60秒後に再試行されます。ただし、特定の行で関数実行が5回連続して失敗すると、その行は以後の変更で無視されると公式ドキュメントに記載されています。(Microsoft Learn)
そのため、SQLトリガーの関数では次の対策が重要です。
- 外部API呼び出しはタイムアウトと再試行回数を明示する
- 同じ変更を複数回処理しても壊れない冪等な実装にする
- 失敗したレコードのID、操作種別、エラー内容をログに残す
- 処理できないデータは別キューや例外テーブルへ退避する
特に「必ず1回だけ処理される」前提で請求、在庫、ポイント付与のような処理を書くのは危険です。重複しても安全な更新キーを持たせる、処理済みフラグを別テーブルで管理するなど、アプリ側で防御してください。
暗号化列の値を取得できると思い込む
Azure SQL change trackingは、Always EncryptedやTransparent Data Encryptionを使うテーブルでも行レベルの変更検出はできます。ただし、Azure SQLトリガーは変更ペイロード内の暗号化された列値を復号したり公開したりしません。変更があったことは検知できますが、暗号化列の復号済みデータにはアクセスできない点に注意が必要です。(Microsoft Learn)
暗号化列の値を使って後続処理を分岐したい場合は、Functions側で安全に取得できる別のデータ設計にするか、必要最小限の非暗号化ステータス列を用意するなど、セキュリティ要件と実装要件を分けて検討してください。
C#インプロセスモデルのまま新規実装する
C#でAzure Functionsを使う場合、インプロセスモデルと分離ワーカーモデルがあります。公式ドキュメントでは、インプロセスモデルのサポートは2026年11月10日に終了予定であり、完全なサポートのために分離ワーカーモデルへの移行が推奨されています。(Microsoft Learn)
新規開発であれば、特別な理由がない限り分離ワーカーモデルを選ぶのが無難です。既存のインプロセスFunctionにSQLトリガーを追加する場合も、短期対応なのか、移行まで含めた改修なのかを先に決めてください。サポート終了が近づいてからSQLトリガー対応と実行モデル移行を同時に行うと、テスト範囲が大きくなります。
Azure SQL trigger for Functionsが向いているケース・向かないケース
Azure SQL trigger for Functionsは便利ですが、すべてのSQL変更処理に向いているわけではありません。導入判断では、次の基準で考えると失敗しにくくなります。
| 向いているケース | 向かないケース |
|---|---|
| テーブル変更後に通知、同期、キャッシュ更新などを行いたい | SQL更新と完全同期のトランザクション処理が必要 |
| 数秒程度の遅延を許容できる | ミリ秒単位の低遅延が必須 |
| 重複処理に備えた冪等性を実装できる | 厳密に1回だけの処理をアプリ側で担保できない |
| 変更追跡を有効化できるDBを使っている | change trackingを有効化できない、またはDBA承認が難しい |
| SQL変更をきっかけに軽い後続処理を始めたい | 大量データのETLを直接Functionで実行したい |
たとえば「注文が作成されたらTeams通知を送る」「顧客情報更新後に検索インデックスを更新する」「ステータス変更を検知してワークフローを開始する」といった用途には向いています。一方で、在庫引当や決済確定のようにトランザクション境界が厳しい処理は、SQLトリガーで非同期に処理するより、アプリケーションの更新処理内で明示的にキューへイベントを発行する設計のほうが安全な場合があります。
管理者・開発者向けの確認チェックリスト
本番投入前に、最低限次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| 拡張機能バージョン | 従量課金プランで使う場合、Azure SQL bindings for Azure Functionsがv3.1.284以降か |
| 実行モデル | C#の場合、分離ワーカーモデルへの移行方針があるか |
| change tracking | データベースと監視対象テーブルの両方で有効化されているか |
| 保持期間 | Function停止期間や障害対応時間を考慮したCHANGE_RETENTIONになっているか |
| SQL権限 | CREATE TABLE、CREATE SCHEMA、SELECT、VIEW CHANGE TRACKING、az_func権限があるか |
| 接続方式 | 可能であればマネージドIDを使い、シークレットを接続文字列に直書きしていないか |
| アプリ設定 | SqlConnectionStringなどの設定がAzure上のFunction Appにも登録されているか |
| スケーリング | PremiumプランではRuntime Scale Monitoringを有効化しているか |
| 例外処理 | 失敗行のログ、退避、再処理手順があるか |
| 冪等性 | 同じ変更を複数回処理しても業務データが壊れないか |
| 監視 | Application Insightsで遅延、失敗、処理件数を追えるか |
まず何から対応すべきか
既存環境でAzure SQL trigger for Functionsを使っている、またはこれから導入する場合は、最初に権限と変更追跡を確認してください。今回の公式情報で特に実務影響が大きいのは、SQLトリガーに必要な権限が明確化された点です。db_datareaderとdb_datawriterだけで済ませず、az_funcスキーマ、変更追跡、監視対象テーブルへの権限をチェックしましょう。
次に、C#インプロセスモデルを使っている場合は分離ワーカーモデルへの移行計画を立てます。最後に、MaxBatchSizeやPollingIntervalMsなどの設定を本番の変更量に合わせて調整し、失敗時の再試行とログ監視をテストしてください。
Azure SQL trigger for Functionsは、SQLデータ変更をAzure Functionsのイベント駆動処理につなげる有力な選択肢です。ただし、DBの変更追跡、権限、スケーリング、再試行を含めて設計してこそ安定して使えます。まずは監視対象テーブルを1つに絞り、ステージング環境で変更検知、権限、再試行、スケール設定を検証してから本番展開するのが安全です。
コメント