このエントリは2025/10/28現在の情報に基づいています。将来の機能追加や変更に伴い、記載事項からの乖離が発生する可能性があります。
2025年10月に以下の機能がPreviewとして登場した。
Introducing native Service Bus message publishing from Azure API Management (Preview)
https://techcommunity.microsoft.com/blog/integrationsonazureblog/introducing-native-service-bus-message-publishing-from-azure-api-management-prev/4462644
ドキュメントの記述は以下のあたり。
Azure API Management から Azure Service Bus にメッセージを送信する方法 / How to send messages to Azure Service Bus from Azure API Management
https://learn.microsoft.com/azure/api-management/api-management-howto-send-service-bus
サービス バス メッセージを送信する / Send service bus message
https://learn.microsoft.com/azure/api-management/send-service-bus-message-policy
新しい感じもするが、実際のところ、Event Hubへログを送出する機能を工夫し、Service Busに適用拡大したようにも見える（個人の見解です）。
イベント ハブにログを記録する / Log to event hub
https://learn.microsoft.com/azure/api-management/log-to-eventhub-policy
ユースケースとして、Tech Communityのブログには以下のような記述がある。
Common use cases
This capability makes it easy to integrate your APIs into event-driven workflows:
- Order processing – Queue incoming orders for fulfillment or billing.
- Event notifications – Trigger internal workflows across multiple applications.
- Telemetry ingestion – Forward IoT or mobile app data to Service Bus for analytics.
- Partner integrations – Offer REST-based endpoints for external systems while maintaining policy-based control.
Each of these scenarios benefits from simplified integration, centralized governance, and improved reliability.
HTTPで送信されたメッセージを、Service BusのQueue/Topicに投げ込むのはもちろん、テレメトリの収集にも使える、という記載があるが、その他、流入してきたメッセージがService Busに保持されるので、バックエンドで障害発生した場合に、再試行時にService Busに蓄積されたメッセージを活用できる（Service BusのGeo replication (Public Preview) を組み合わせると、災害発生時に冗長化したService Busに対してメッセージが複製されるので、メッセージロストも避けることができる）、というユースケースも考えられる（もちろん、保持期間も考慮しなければならないのはその通り）。
設定にあたっての注意点
1. Service Busへの送信のみ
ドキュメントにも記載がある通り、現時点では、送信のみが可能で、Service Busからの着信をAPIMで受け取ることはできない。そのような要求がある場合にはFunctionsなどで変換する必要がある。
2. Streamingメッセージは取り扱い不可
Streamingメッセージをバッファリングできないので、LLMからのレスポンスをService Busに入れる、なんてこともできない。
3. RBAC
User/System assigned Managed Identityを使った接続のみをサポートしているので、Service Principalは使えない。APIMに割り当てたManaged identityには、Service Busのデータ送信者 (Azure Service Bus Data Sender) のロールを付与する必要がある（Data Ownerでもいいけれども、最小権限の原則に基づいてData Senderを指定）。
<send-service-bus-message queue-name="service bus queue" topic-name="service bus topic"
namespace="FQDN of service bus namespace" client-id="ID of user-assigned managed identity">
<message-properties>
<message-property name="property-name">property-value</message-property>
<!-- if there are multiple properties, then add additional message-property elements -->
</message-properties>
<payload>"message content"</payload>
</send-service-bus-message>
4. Message properties
HTTP HeaderをまるごとService BusのMessage Propertyに突っ込みたい、というニーズがあるかもしれないが、それはできない。そのため、個別のHeaderに分解する、もしくはPayloadにJSON Objectとして書き出す必要がある。
なお、このポリシーを使ってEvent Hubsには送信できない。確かに名前空間のFQDNだけを見ると、Service BusとEvent Hubsは類似しているので出来そうに思うが、実際はエラーが出てしまうのでそれは叶わない（当然といえば当然）。
Logico Inside 