azure-messaging

Event Hubs か Service Bus の SDK が期待どおり動かないときです。

対象は「Azure のメッセージング全般」ではなく、クライアント側の SDK で起きる症状に絞られています。

扱う症状は 6 種類

本文の「使うとき」の 8 項目を、6 つにまとめると次のとおりです。

• 接続接続の失敗、認証のエラー、AMQP のリンク切断
• 待ち無通信によるタイムアウト、切断後の再接続が遅い
• ロックメッセージロックの喪失・期限切れ、更新の失敗
• セッションセッションロックの喪失、受信側のエラー
• 処理処理が止まる、重複、チェックポイントの巻き戻り
• 設定再試行、先読み、一括の大きさ

ロックとセッションの項目が厚いのが特徴です。Service Bus の運用でつまずく定番がここで、azure-diagnostics 側の手引き（.NET の Service Bus）では、「ロックが切れる」の原因として処理時間の長さ・ロックの更新・接続（リンク）の切断や 10 分の無通信が挙がっています。

同梱ファイルが 1 件もありません

ここが最大の注意点です。

本文の「手引き」の節にこう書かれています。

接続・SDK・認証の手引きは、azure-diagnostics スキルの troubleshooting/messaging/ に置かれている。

つまりこのスキルは振り分けだけを持ち、中身は持っていません。同梱ファイルは 0 件です（2026-09-21 時点）。

azure-diagnostics を入れていないと、参照先が存在しません。

切り分けの順序が決まっている

手順は 6 段階です。

1. SDK と版を特定する分からなければ先に進む
2. リソース正常性を確認するAzure 側の障害かどうかを先に見る
3. エラーの文言を突き合わせる言語別の手引きと突き合わせる
4. 文書検索最新の指針を引く
5. 名前と設定を確認接続文字列・エンティティ名・コンシューマーグループを確認
6. 修正を勧める見つけた文書を示して直す

段階 2 が先にあるのは同じ公開元の流儀です。 Azure 側の障害なら、こちらの設定をいくら見ても原因は出ません。

段階 1 の「分からなければ先に進む」も実務的です。版が分からないという理由で止まらず、あとで聞けばよい、という切り分けになっています。

使う道具が 5 つ挙げてある

MCP の道具が表で指定されています。

• mcp_azure_mcp_eventhubs名前空間・ハブ・コンシューマーグループの一覧
• mcp_azure_mcp_servicebusキュー・トピック・サブスクリプションの一覧
• mcp_azure_mcp_monitorKQL による診断ログの照会
• mcp_azure_mcp_resourcehealthサービスの健全性の確認
• mcp_azure_mcp_documentation公式文書の検索

KQL の書き方そのものは azure-kusto の側が詳しいです。

説明文が異常に長い

description に症状の語が数十並んでいます。message lock lost、link detach、offset reset、eventhub python、servicebus dotnet のような、実際に検索窓へ打つ言葉が列挙されています。

これは呼ばれやすさを狙った設計です。エラーの文言をそのまま貼れば当たりやすい作りになっています。仕組みの説明はスキルが呼ばれないときの直し方にまとめています。

公開元の全体の役割分担

この公開元には組で入れないと止まるものがあります。全体の役割分担は microsoft/azure-skills の地図にまとめています。

azure-diagnostics が要る

手引きがあちら側にあります。単体では振り分けだけが残ります。

設計の相談には向かない

キューにするかトピックにするか、分割数をいくつにするかはこのスキルの対象外です。可用性の設計は azure-reliability の側です。

他社のメッセージングには使えない

Kafka や SQS の症状は扱いません。

アプリ側の論理の不具合は見ない

「重複が出る」の原因が自分の処理の冪等性にあるなら、SDK の設定をいくら見ても直りません。

読み取り権限が無いと段階 2 で止まる

リソース正常性も診断ログも権限が要ります。

解析で見つかった記述と、同梱ファイル

SKILL.md の解析では、外部通信・シェル実行・ファイル書き換えの記述は見つかっていません。同梱ファイルは 0 件です（2026-09-21 時点）。

同梱が無いということは、本文がすべてです。3,282 バイトの振り分けだけを持つスキルなので、深い手順を期待しないでください。

診断ログに業務のデータが入る

メッセージの本文、宛先、識別子が入ります。

接続文字列が出力に現れる

段階 5 で接続文字列を確認する手順があるので、そのまま貼り付けさせないでください。

修正をそのまま適用させない

先読みの数や再試行の設定は、本番の負荷に直結します。手順の段階 6 は「修正を勧める」と題しつつ、中身は「見つけた文書を示して直しを当てる（Apply remediation）」と書かれています。直しを当てる前に止めるよう、最初に頼んでおいてください。

ライセンス

ライセンス: MIT。再配布や商用利用の前に公開元の表記を確認してください。

これだけ入れれば使えますか

使えません。手引きが azure-diagnostics の同梱ファイルの中にあります。

このスキル自身の同梱は 0 件なので、組で入れてください。

メッセージロックが切れるのはなぜですか

原因は 1 つではありません。このスキルが扱うのは、ロックの喪失・期限切れ・更新の失敗・一括処理でのロックの時間切れ、といった切り分けです。azure-diagnostics 側の手引きは、処理時間を縮める・ロックを更新する・ネットワークを確かめる、を直し方に挙げています。

症状の語が description に列挙されているので、エラーの文言をそのまま渡すのが早いです。

最初に何を見ればいいですか

リソース正常性です。手順の段階 2 に置かれています。

Azure 側の障害なら、こちらの設定を見ても原因は出ません。同じ公開元の azure-diagnostics も同じ順序を指定しています。

SDK の版が分からなくても使えますか

使えます。段階 1 に「分からなければ診断を進め、必要なら後で聞く」と書かれています。

版の特定で止まらない作りです。

対応しているエージェントはどれですか

Claude Code と Codex です。公開元の README が Claude Code と Codex CLI それぞれへの入れ方を節に分けて案内しています（2026-10-09 確認）。当サイトは公開元が明記しているものだけを「対応」として表示する方針なので、このスキルのページには両方が対応として出ます（指標の意味と限界）。