Azure Service Bus trigger for Azure Functionsの変更点【2026年6月15日更新】

2026年6月15日の更新で、Azure Service Bus trigger for Azure Functionsの実行仕様や料金が変更されたわけではありません。今回の主な変更は、公式ドキュメントで一時的に非表示となっていたC#、TypeScript、JavaScript、Pythonのコードサンプルが再表示されたことです。

そのため、既存のFunction Appを緊急で更新する必要はありません。ただし、Azure Functions 1.xやC#のインプロセスモデル、旧Service Bus SDKには2026年中のサポート期限があります。管理者は今回の更新をきっかけに、ランタイム、拡張機能、接続方式を確認しておくと安心です。(GitHub)

2026年6月15日に変更された内容

公式ドキュメントのソース履歴では、2026年6月15日に「コードスニペット参照の復元」が実施されています。

依存先のGitHubリポジトリが一時的に利用できなくなったため、2026年6月5日にコード参照が外されました。その後、リポジトリの復旧確認が完了し、コードサンプルが再び表示されるようになっています。(GitHub)

確認項目	2026年6月15日の変更内容	利用者の対応
Azure Functionsの実行仕様	変更なし	不要
Service Busトリガーの設定値	変更なし	不要
APIや拡張機能	新機能追加なし	不要
コードサンプル	一時的に外されていた参照を復元	必要に応じて再確認
料金	変更なし	不要
移行期限	今回の更新による新しい期限はなし	既存のサポート期限を確認

復元されたのは、主に次の8種類のサンプルです。

C#のロガー初期化
C#の単一メッセージ処理
C#のバッチ処理
C#のメッセージ完了処理
TypeScriptのService Busトリガー
JavaScriptのService Busトリガー
Python SDK型によるキュー処理
Python SDK型によるトピック処理

特に、C#の分離ワーカーモデルで単一メッセージ、バッチ、手動メッセージ処理を実装する開発者にとって、公式サンプルを再び参照できるようになった点が実務上の変更です。(GitHub)

Azure Service Bus trigger for Azure Functionsとは

Azure Service Bus triggerは、Service Busのキューまたはトピックのサブスクリプションにメッセージが届いたとき、Azure Functionsを自動実行する仕組みです。

たとえば、次のような処理に利用できます。

注文メッセージを受け取り、在庫を更新する
IoT機器から送信されたイベントを非同期で処理する
複数システム間のデータ連携を疎結合にする
時間のかかる処理をバックグラウンドで実行する
トピックから複数の業務システムへイベントを配信する

送信側は受信側の処理完了を待つ必要がありません。急激にメッセージが増えた場合もキューに保持できるため、Web APIから重い処理を切り離したい場合に適しています。Azure Functionsでは、単一メッセージ、メッセージのバッチ、セッション、手動メッセージ処理などを構成できます。(Microsoft Learn)

今回の更新で影響を受ける人

公式サンプルを参照して実装している開発者

最も直接的な影響を受けるのは、Microsoft Learnのサンプルコードを見ながらService Busトリガーを実装する開発者です。

一時的に表示されていなかったサンプルが復元されたため、現在はC#、JavaScript、TypeScript、Pythonの具体的な実装を確認できます。ただし、サンプルをそのままコピーするのではなく、自分の実行モデルや拡張機能のバージョンと一致しているかを確認してください。

すでにAzure Functionsを運用している管理者

既存のFunction Appには直接影響しません。

今回変更されたのはドキュメントのコード参照であり、Azure Functionsのホスト、Service Bus拡張機能、トリガー設定が自動変更されるものではありません。デプロイ済みの関数が、今回の更新だけを理由に停止することもありません。

古いランタイムやSDKを使用している組織

今回のドキュメント更新とは別に、2026年中には複数のサポート期限があります。

特に、次の環境を使用している場合は対応が必要です。

Azure Functionsランタイム1.x
C#のインプロセスモデル
WindowsAzure.ServiceBus
Microsoft.Azure.ServiceBus
com.microsoft.azure.servicebus
SBMPプロトコル

管理者が確認すべき設定とバージョン

FunctionsランタイムとC#実行モデルを確認する

最初に、Function Appが利用しているランタイムと実行モデルを確認します。

C#プロジェクトでは、アプリ設定、プロジェクトファイル、NuGetパッケージを確認してください。

確認対象	主な確認内容
`FUNCTIONS_EXTENSION_VERSION`	原則としてFunctions 4.xを示す設定になっているか
`FUNCTIONS_WORKER_RUNTIME`	`dotnet`か`dotnet-isolated`か
`.csproj`	使用中のFunctions SDKとService Bus拡張機能
ソースコード	インプロセス用と分離ワーカー用の属性が混在していないか
デプロイ設定	ステージングと本番でランタイム設定が一致しているか

FUNCTIONS_WORKER_RUNTIMEがdotnetのC#アプリは、インプロセスモデルである可能性があります。C#インプロセスモデルのサポートは2026年11月10日に終了するため、分離ワーカーモデルへの移行計画が必要です。Functions 4.x以外を使用している場合は、先にホストランタイムの更新を検討します。(Microsoft Learn)

Service Bus拡張機能を確認する

C#では、実行モデルによって使用するNuGetパッケージが異なります。

実行モデル	主なパッケージ
分離ワーカーモデル	`Microsoft.Azure.Functions.Worker.Extensions.ServiceBus`
インプロセスモデル	`Microsoft.Azure.WebJobs.Extensions.ServiceBus`

Service Bus拡張機能5.x以降では、Azure.Messaging.ServiceBusの型や、Microsoft Entra IDを利用したIDベース接続を使用できます。

Node.jsやPythonなどで拡張機能バンドルを使用している場合は、host.jsonを確認します。公式ドキュメントでは、4.x系のバンドルを選択する例として次の範囲が示されています。

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.0.0, 5.0.0)"
  }
}

バージョンを固定しすぎると修正版を取り込めないことがあります。一方で、検証せずにメジャーバージョンを変更すると動作差分が発生する可能性があります。開発環境で処理、再試行、デッドレター移動まで確認してから本番へ反映してください。(Microsoft Learn)

接続文字列からマネージドIDへの移行を検討する

Service Bus拡張機能5.x以降では、接続文字列の代わりにマネージドIDを利用できます。

トリガーのconnectionがServiceBusConnectionの場合、システム割り当てマネージドIDでは、次のようなアプリ設定を使用します。

ServiceBusConnection__fullyQualifiedNamespace=myservicebus.servicebus.windows.net

ユーザー割り当てマネージドIDでは、必要に応じて次の設定も追加します。

ServiceBusConnection__credential=managedidentity
ServiceBusConnection__clientId=<マネージドIDのクライアントID>

IDには、通常はAzure Service Bus Data Receiverロールを付与します。トピックトリガーを使用する場合、ロールのスコープがトピックだけでなく、対象のサブスクリプションリソースにも有効か確認してください。

接続文字列をマネージドIDへ切り替える際は、設定変更とRBAC付与を同時に行うのが重要です。権限の反映前に接続文字列を削除すると、トリガーがメッセージを受信できなくなることがあります。(Microsoft Learn)

host.jsonで確認すべき重要項目

Service Busトリガーの性能やメッセージ処理は、host.jsonの設定に左右されます。

設定	既定値の例	確認ポイント
`autoCompleteMessages`	`true`	コードで手動完了する場合は`false`にする
`prefetchCount`	`0`	増やす場合はメッセージロック時間に注意する
`maxConcurrentCalls`	`16`	下流システムの処理能力を超えないようにする
`maxConcurrentSessions`	`8`	セッション利用時の同時処理数を調整する
`maxAutoLockRenewalDuration`	5分	長時間処理でロック切れが起きないか確認する
`maxMessageBatchSize`	`1000`	メモリ使用量と1回の処理時間を確認する

maxConcurrentCallsは、スケールされたインスタンスごとの同時呼び出し数です。複数コアの環境では実際の同時実行数がコア数に応じて増えるため、値を上げる前にデータベースや外部APIの同時接続上限を確認してください。

また、clientRetryOptionsはService Busサービスとの通信再試行に適用される設定です。関数コード自体の実行失敗を再試行する設定ではありません。両者を同じものとして扱うと、想定した回数だけ業務処理が再実行されない可能性があります。(Microsoft Learn)

メッセージを手動で完了する場合の注意点

通常、関数が正常終了するとランタイムがメッセージをCompleteし、失敗するとAbandonします。

コード内でServiceBusMessageActionsを使い、CompleteMessageAsyncやDeadLetterMessageAsyncなどを呼び出す場合は、自動完了を無効にします。

{
  "version": "2.0",
  "extensions": {
    "serviceBus": {
      "autoCompleteMessages": false
    }
  }
}

自動完了を有効にしたままコードでも完了処理を実行すると、同じメッセージを二重に完了しようとしてエラーになる可能性があります。分離ワーカーモデルでServiceBusMessageActionsを使用する場合は、対応するService Bus拡張機能のバージョンも確認してください。(Microsoft Learn)

2026年に確認すべき移行期限

今回の2026年6月15日更新自体には、設定変更や移行の期限はありません。ただし、関連するAzure FunctionsとService Busには次の期限があります。

期限	対象	必要な対応
2026年9月14日	Azure Functionsランタイム1.x	Functions 4.xへ移行
2026年9月30日	旧Service Bus SDK	最新のAzure SDKへ移行
2026年9月30日	SBMPプロトコル	AMQPなど対応プロトコルへ移行
2026年11月10日	C#インプロセスモデル	分離ワーカーモデルへ移行

旧Service Bus SDKは期限後も動作する可能性がありますが、Microsoftの公式サポートや更新を受けられなくなります。SBMPプロトコルは期限後に利用できなくなるため、旧SDKを使用しているだけでなく、接続プロトコルまで確認する必要があります。(Microsoft Learn)

移行作業は、次の順序で進めると問題を切り分けやすくなります。

現在のFunctionsランタイム、実行モデル、SDKを一覧化する
Functions 4.xで動作する状態に更新する
Service Bus拡張機能とSDKを更新する
C#は分離ワーカーモデルへ移行する
開発環境で単一処理、バッチ、再試行、デッドレターを検証する
ステージング環境で負荷試験を行う
本番反映後に失敗数、処理時間、メッセージ滞留数を監視する

ランタイム、実行モデル、SDKを一度に変更すると、障害発生時に原因を特定しにくくなります。可能であれば段階的に更新してください。

今回の変更による料金への影響

2026年6月15日のドキュメント更新による料金変更はありません。また、Service Busトリガーを使用するためだけの追加料金が新設されたわけでもありません。

実際の料金は、主にAzure FunctionsとAzure Service Busで別々に発生します。

サービス	主な課金要素
Azure Functions Flex Consumption	実行回数、実行中のメモリと時間、Always Readyの設定
Azure Functions Consumption	実行回数、リソース使用量
Azure Functions Premium	割り当てたコアとメモリ、稼働時間
Service Bus Basic・Standard	プラン、操作数、接続数など
Service Bus Premium	メッセージングユニットと稼働時間など

Service BusのBasicでは、トピック、トランザクション、重複除外、セッションを利用できません。これらが必要になりStandardやPremiumへ変更すると、料金体系も変わります。(Microsoft Azure)

maxConcurrentCallsやバッチサイズを変更しても、それ自体に設定料金が発生するわけではありません。ただし、処理時間、スケール数、Service Busの操作量、接続先サービスの負荷が変わり、結果として請求額が動く可能性があります。設定変更後は、Azure Monitorの実行数や処理時間だけでなく、Service Busの受信数、アクティブメッセージ数、デッドレターメッセージ数も確認してください。

よくある疑問

既存のFunction Appをすぐ更新する必要はある？

2026年6月15日の更新だけを理由に、設定やパッケージを更新する必要はありません。

ただし、Functions 1.x、C#インプロセスモデル、旧Service Bus SDKを使用している場合は、別途移行が必要です。

今回の更新でService Busトリガーが動かなくなる？

動かなくなりません。

今回の変更は公式ドキュメント内のコードサンプル参照を復元したもので、Azure上にデプロイ済みのFunction Appには直接作用しません。

復元されたコードをそのまま使用してよい？

実行モデルと拡張機能のバージョンが一致していれば参考にできます。

ただし、キュー名、トピック名、接続設定、マネージドID、メッセージ完了方式は環境ごとに異なります。特に手動完了のサンプルを利用する場合は、autoCompleteMessagesの設定を必ず確認してください。

接続文字列は必須？

必須ではありません。

Service Bus拡張機能5.x以降では、Microsoft Entra IDとマネージドIDを利用できます。新規構築では、秘密情報をアプリ設定に保存しなくて済むマネージドIDを優先すると、認証情報の漏えいや更新漏れを減らせます。(Microsoft Learn)

まず実施すべきこと

2026年6月15日の変更はドキュメント改善であり、緊急対応は不要です。ただし、2026年後半のサポート期限に備え、次の確認は早めに実施してください。

Functionsランタイムが4.xか確認する
C#アプリがインプロセスモデルか確認する
旧Service Bus SDKを使用していないか検索する
Service Bus拡張機能のバージョンを確認する
接続文字列からマネージドIDへ移行できるか検討する
autoCompleteMessages、同時実行数、ロック更新時間を確認する
移行後の処理時間、失敗数、キュー滞留数を監視する

まずリポジトリ内で旧パッケージ名を検索し、Function Appのランタイムと実行モデルを一覧化してください。該当環境が見つかった場合は、期限直前ではなく、負荷試験と切り戻しが可能な時期に移行を進めることが重要です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure Service Bus trigger for Azure Functionsの変更点【2026年6月15日更新】

2026年6月15日に変更された内容

Azure Service Bus trigger for Azure Functionsとは

今回の更新で影響を受ける人

公式サンプルを参照して実装している開発者

すでにAzure Functionsを運用している管理者

古いランタイムやSDKを使用している組織

管理者が確認すべき設定とバージョン

FunctionsランタイムとC#実行モデルを確認する

Service Bus拡張機能を確認する

接続文字列からマネージドIDへの移行を検討する

host.jsonで確認すべき重要項目

メッセージを手動で完了する場合の注意点

2026年に確認すべき移行期限

今回の変更による料金への影響

よくある疑問

既存のFunction Appをすぐ更新する必要はある？

今回の更新でService Busトリガーが動かなくなる？

復元されたコードをそのまま使用してよい？

接続文字列は必須？

まず実施すべきこと

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure Service Bus trigger for Azure Functionsの変更点【2026年6月15日更新】

2026年6月15日に変更された内容

Azure Service Bus trigger for Azure Functionsとは

今回の更新で影響を受ける人

公式サンプルを参照して実装している開発者

すでにAzure Functionsを運用している管理者

古いランタイムやSDKを使用している組織

管理者が確認すべき設定とバージョン

FunctionsランタイムとC#実行モデルを確認する

Service Bus拡張機能を確認する

接続文字列からマネージドIDへの移行を検討する

host.jsonで確認すべき重要項目

メッセージを手動で完了する場合の注意点

2026年に確認すべき移行期限

今回の変更による料金への影響

よくある疑問

既存のFunction Appをすぐ更新する必要はある？

今回の更新でService Busトリガーが動かなくなる？

復元されたコードをそのまま使用してよい？

接続文字列は必須？

まず実施すべきこと

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル