MENU

Azure SDKのnotification-hubs 2026年5月更新｜2.1.0の変更点と確認ポイント

Azure

Azure SDKのドキュメント更新「[notification-hubs] prepare for 2026 May release」は、Azure Notification Hubs向けJavaScript/TypeScript SDKである @azure/notification-hubs の2026年5月リリース準備に関する更新です。結論から言うと、今回の2.1.0は大規模な破壊的変更ではなく、RestError と isRestError を @azure/notification-hubs から直接扱いやすくする変更が中心です。すぐに設定変更が必要なケースは限定的ですが、SDKのバージョン固定、例外処理、Node.js実行環境、1.x系からのアップデート有無は必ず確認してください。PRは2026年5月5日にmainへマージされ、CHANGELOGでは2.1.0のリリース日が2026年5月5日として記載されています。(GitHub)

目次

Azure SDK ドキュメント更新の要点

今回確認すべきポイントは、「Azure Notification Hubsサービスそのものの仕様変更」ではなく、「Azure SDK for JavaScriptに含まれる @azure/notification-hubs パッケージのリリース準備とドキュメント反映」です。

確認項目内容実務で見るべきポイント
対象パッケージ@azure/notification-hubsJavaScript/TypeScriptでNotification Hubsを操作しているか
対象バージョン2.1.0package.json やロックファイルで利用バージョンを確認
更新日2026年5月5日Microsoft LearnのSDK READMEも2026年5月5日に更新
主な変更RestError と isRestError の再エクスポートHTTPエラー判定やログ出力の実装を整理できる
破壊的変更2.1.0のCHANGELOG上はBreaking Changesの記載なしただし1.x系から上げる場合は2.0.0の破壊的変更を確認

Azure SDKのリリース一覧でも、JavaScript/TypeScriptのNotification Hubsパッケージとして @azure/notification-hubs 2.1.0 が掲載されています。(Azure)

何が変わったのか

RestError と isRestError をパッケージ直下から扱える

2.1.0のCHANGELOGでは、@azure/core-rest-pipeline 由来の RestError と isRestError を利便性のために再エクスポートしたことが変更点として記載されています。(GitHub)

これにより、Notification Hubs SDKを使うコードで、Azure SDKのHTTPエラーを判定する処理をより自然に書けます。

import {
  NotificationHubsClient,
  createAppleNotification,
  isRestError,
} from "@azure/notification-hubs";

const client = new NotificationHubsClient(
  process.env.NOTIFICATIONHUBS_CONNECTION_STRING!,
  process.env.NOTIFICATION_HUB_NAME!
);

try {
  const notification = createAppleNotification({
    body: JSON.stringify({
      aps: {
        alert: "Hello",
      },
    }),
  });

  await client.sendBroadcastNotification(notification);
} catch (error) {
  if (isRestError(error)) {
    console.error("Azure Notification Hubs error", {
      statusCode: error.statusCode,
      code: error.code,
      message: error.message,
    });
    throw error;
  }

  console.error("Unexpected error", error);
  throw error;
}

Microsoft LearnのAPIリファレンスにも、isRestError は RestError のタイプガード、RestError は失敗したパイプラインリクエスト向けのカスタムエラー型として掲載されています。(Microsoft Learn)

既存コードを必ず書き換える必要はない

すでに次のように @azure/core-rest-pipeline から直接インポートしている場合、すぐに壊れるという意味ではありません。

import { isRestError } from "@azure/core-rest-pipeline";

ただし、Notification Hubs SDKを使うアプリケーションの中でエラー処理をまとめたい場合は、次のようにトップレベルの @azure/notification-hubs からインポートする方が、コードの意図が分かりやすくなります。

import { isRestError } from "@azure/notification-hubs";

特に、チーム内で「Notification Hubs関連の処理は @azure/notification-hubs からまとめてimportする」というルールを置いている場合、今回の変更は保守性を上げる小さな改善になります。

誰が対応すべきか

今回のAzure SDK ドキュメント更新で確認が必要なのは、主にJavaScript/TypeScriptでAzure Notification Hubsを使っている開発者です。

対象者・チーム対応優先度理由
Node.jsバックエンドからプッシュ通知を送信しているチーム高@azure/notification-hubs の実行環境、送信処理、例外処理に影響する可能性がある
RestError や statusCode を使って障害判定しているチーム高isRestError を使うと型安全にエラーを扱える
1.x系の @azure/notification-hubs を使い続けているチーム高2.0.0で破壊的変更が入っているため、2.1.0だけを見て更新すると見落としやすい
React Nativeやブラウザ向けにSDKをバンドルしているチーム中polyfillやバンドル結果の確認が必要になる場合がある
Azure PortalだけでNotification Hubsを管理している運用担当低SDKコードを書いていなければ直接影響は小さい
.NET、Java、Python SDKのみを使っているチーム低今回のPRはAzure SDK for JavaScriptリポジトリの更新

注意したいのは、@azure/arm-notificationhubs ではなく @azure/notification-hubs が今回の主対象である点です。前者はNotification Hubsリソースを管理する管理系SDK、後者は登録、インストール、通知送信などを扱うクライアントSDKです。

影響範囲をコード・依存関係・運用で整理する

アプリケーションコードへの影響

2.1.0単体で見ると、既存APIの大きな削除や引数変更ではなく、エラー関連のエクスポート追加が中心です。そのため、すでに2.0.xを使っているアプリケーションでは、通常は大規模な修正なしで検証できます。

ただし、次のようなコードがある場合は確認してください。

catch (error) {
  console.log(error.statusCode);
}

TypeScriptでは catch した値は unknown として扱うのが安全です。statusCode や code を読む前に、isRestError で型を絞り込む実装にすると、実行時エラーと型エラーの両方を避けやすくなります。

catch (error) {
  if (isRestError(error)) {
    console.log(error.statusCode);
    console.log(error.code);
  }
}

この変更は、通知送信の成功・失敗をログに残しているシステムで特に有効です。たとえば、プッシュ通知が届かない問い合わせに備えて、statusCode、code、trackingId、correlationId をログに残す運用をしている場合、エラー判定が明確になります。

依存関係への影響

@azure/notification-hubs の package.json では、パッケージバージョンが2.1.0、Node.jsエンジンが >=20.0.0 とされています。(GitHub)

そのため、更新前に次の点を確認してください。

node -v
npm ls @azure/notification-hubs

CI/CD、Dockerfile、Azure App Service、Azure Functions、コンテナ実行環境などでNode.js 18以前を使っている場合、SDK更新より先にランタイムの見直しが必要になる可能性があります。特に本番環境と開発環境でNode.jsのメジャーバージョンが違うと、「ローカルでは動くがCIで落ちる」「ビルドは通るがデプロイ後に起動しない」といった問題につながります。

運用・設定への影響

今回の更新はSDK側の変更であり、Notification Hubsの接続文字列、資格情報、SKU、PNS設定を自動的に変更するものではありません。ただし、SDK更新の検証時には設定も合わせて点検するべきです。

Microsoft Learnでは、Notification Hubs SDKはShared Access Signature接続文字列を使い、Listen、Manage、Sendの権限レベルを扱うと説明されています。(Microsoft Learn)

設定項目確認する理由
接続文字列の権限送信だけならSend、登録管理ならManageが必要。不要なManage権限をクライアント側に置かない
Hub名接続文字列だけでなく、SDK初期化時のHub名が正しいか確認する
Node.jsバージョン>=20.0.0 前提の環境か確認する
ログ出力障害調査に必要な trackingId、correlationId、statusCode を残す
送信方式ブロードキャスト、タグ送信、直接送信、スケジュール送信のどれを使っているか把握する
SKUスケジュール送信や通知テレメトリを使う場合、該当機能を利用できるSKUか確認する

1.x系から更新する場合は2.0.0の変更を必ず確認する

今回の2.1.0だけを見ると小さな更新に見えますが、現在の利用バージョンが1.x系の場合は話が変わります。CHANGELOGでは2.0.0に破壊的変更が記載されており、@azure/core-lro v3への移行、beginSubmitNotificationHubJob などで使うPoller APIの変更、ブロードキャスト送信と通常送信の整理が含まれています。(GitHub)

つまり、次のような更新は慎重に進めるべきです。

{
  "dependencies": {
    "@azure/notification-hubs": "^1.2.3"
  }
}

この状態から2.1.0へ上げる場合、2.1.0の変更点だけでなく、2.0.0の変更点もまとめて受けることになります。

1.x系から更新するときのチェックポイント

確認対象見るべき内容
sendNotification の使い方ブロードキャスト送信を旧来の形で呼んでいないか
sendBroadcastNotification2.x系で明示的に使うべき送信処理に置き換えられているか
scheduleNotificationスケジュール送信の対象がタグ送信か、ブロードキャストかを区別しているか
LRO関連beginSubmitNotificationHubJob の戻り値やポーリング処理が古い型前提になっていないか
型定義旧バージョンの型名、戻り値、オプション名を前提にしていないか
テスト送信、登録、一覧取得、スケジュール、ジョブ操作の主要パスを通す

特にプッシュ通知は、単体テストだけでは問題を見つけにくい領域です。APNs、FCM、Web Pushなど、実際に使っているPNSごとにステージング環境で送信確認を行ってください。

移行・確認の実務手順

現在のSDKバージョンを確認する

まず、プロジェクトで使っているバージョンを確認します。

npm ls @azure/notification-hubs

pnpmを使っている場合は次のように確認できます。

pnpm why @azure/notification-hubs

複数のワークスペースを持つmonorepoでは、アプリごとに異なるバージョンが入っていることがあります。通知送信用の共通ライブラリだけでなく、管理画面、バッチ、APIサーバー、検証用スクリプトも確認してください。

ロックファイルを含めて更新する

2.1.0へ更新する場合は、package.json だけでなく、package-lock.json、pnpm-lock.yaml、yarn.lock も必ず確認します。

npm install @azure/[email protected]

更新後は、依存関係に重複がないか確認します。

npm ls @azure/core-rest-pipeline
npm ls @azure/notification-hubs

RestError を @azure/notification-hubs から使えるようになったからといって、@azure/core-rest-pipeline が不要になるとは限りません。他のAzure SDKや内部ライブラリが依存している場合があります。依存削除は、利用箇所を検索してから判断してください。

エラー処理を見直す

通知送信では、単に「成功したか失敗したか」だけでなく、障害調査に使える情報を残すことが重要です。Microsoft LearnのREADMEでは、送信操作の戻り値としてTracking IDやCorrelation IDが返ること、Standard SKU以上ではNotification IDを使ったテレメトリ確認ができることが説明されています。(Microsoft Learn)

最低限、次のようなログ設計にしておくと、問い合わせ対応が速くなります。

ログ項目用途
trackingIdAzureサポート問い合わせや送信追跡に使う
correlationId関連するリクエストをひも付ける
notificationIdStandard SKU以上で通知結果の追跡に使う
statusCodeHTTPレベルの失敗原因を判断する
codeAzure SDK側のエラー種別を判定する
対象プラットフォームAPNs、FCM、Web Pushなど、影響範囲を切り分ける

主要な送信パターンをテストする

Notification Hubs SDKのREADMEでは、直接送信、タグを使ったオーディエンス送信、ブロードキャスト送信、スケジュール送信などが紹介されています。(Microsoft Learn)

更新後は、使っている送信パターンだけを効率よくテストしてください。

使っている機能テスト内容
直接送信特定のデバイスハンドルに通知が届くか
タグ送信タグ条件に一致する端末だけに届くか
ブロードキャスト送信想定外の全体配信にならないか
スケジュール送信指定時刻、キャンセル、Notification IDの扱いを確認する
登録・インストール更新タグ、userId、installationIdが正しく保存されるか
一覧取得ページングや継続トークンの扱いに問題がないか

スケジュール送信はStandard SKU以上で最大7日先までの予約送信として説明されているため、利用中のSKUも合わせて確認してください。(Microsoft Learn)

React Nativeやブラウザ利用時の注意点

Microsoft LearnのREADMEでは、React NativeでSDKを使う場合、URLSearchParams、TextEncoder、async iterator API向けのpolyfillが必要になることが説明されています。(Microsoft Learn)

そのため、React Nativeやフロントエンドバンドルで @azure/notification-hubs を使っている場合は、単にnpmパッケージを更新するだけでなく、次の点を確認してください。

確認項目失敗しやすいポイント
polyfill開発環境では動くが、実機や本番ビルドでエラーになる
tree-shakingimport経路の変更でバンドルサイズが変わる
ESM/CommonJSテスト環境と本番ビルドで解決されるモジュール形式が異なる
環境変数接続文字列をフロントエンドに埋め込んでしまう

特に接続文字列の扱いには注意が必要です。Notification Hubsの送信や管理に使う接続文字列をブラウザやモバイルアプリに直接埋め込むと、権限の漏えいにつながります。クライアントアプリから直接SDKを使うのではなく、必要に応じてバックエンドAPIを経由する設計を検討してください。

更新してよいケースと待つべきケース

更新してよいケース

すでに2.0.xを使っていて、Node.js 20以上の環境で動作している場合は、2.1.0への更新は比較的進めやすいです。特に次の条件に当てはまるなら、ステージング検証後に更新する価値があります。

条件理由
2.0.xを利用中2.0.0の破壊的変更をすでに吸収している可能性が高い
エラー処理を改善したいisRestError をSDKパッケージ直下から扱える
ログ設計を見直している通知失敗時の原因分析を型安全に実装しやすい
CI/CDでNode.js 20以上を使っている実行環境の条件を満たしやすい

いったん待つべきケース

次のような状況では、すぐに本番反映せず、検証計画を立ててから更新してください。

条件理由
1.x系から直接2.1.0へ上げる2.0.0の破壊的変更も同時に受ける
本番キャンペーン配信の直前通知基盤の変更は影響範囲が大きい
Node.js 18以前で運用中SDKのエンジン要件とずれる可能性がある
React Nativeで利用中polyfillや実機検証が必要
エラー処理を独自ラッパーで共通化しているimport経路や型判定の影響を確認する必要がある

現場で見落としやすい失敗パターン

2.1.0だけを見て「影響なし」と判断する

今回の2.1.0自体は小さな更新ですが、現在のバージョンが1.x系なら2.0.0の変更が重要です。特に sendNotification、sendBroadcastNotification、scheduleNotification まわりの呼び分けは、通知範囲のミスにつながる可能性があります。

「SDKのマイナー更新だから大丈夫」と判断するのではなく、現在の導入バージョンから目的バージョンまでのCHANGELOGを連続して確認してください。

RestError 以外の例外まで同じ扱いにする

isRestError はAzure SDKのHTTPリクエスト失敗を判定するために便利ですが、すべての例外が RestError になるわけではありません。

たとえば、環境変数が未設定、JSON生成に失敗、アプリ側の引数が不正、ネットワーク層より前で例外が出るといったケースでは、別のエラーになる可能性があります。isRestError で判定した後、最後に未知の例外を扱う分岐を残してください。

catch (error) {
  if (isRestError(error)) {
    // Azure SDKのHTTPエラーとして扱う
    throw error;
  }

  // それ以外のアプリケーションエラーも握りつぶさない
  throw error;
}

送信テストで本番タグを使う

タグ送信やブロードキャスト送信のテストでは、誤配信に注意が必要です。検証環境では、必ずテスト専用のタグやHubを使ってください。

悪い例は、既存の本番タグを使って「少しだけ送って確認する」運用です。タグ条件の解釈ミスや環境変数の取り違えがあると、想定外のユーザーに通知が届く可能性があります。

ログに接続文字列を出してしまう

エラー調査で環境変数や接続文字列をログに出すのは避けてください。残すべきなのは、trackingId、correlationId、statusCode、code、対象Hub名、送信種別などです。Shared Access Signature接続文字列、キー、デバイストークンはマスク対象にしてください。

次に取るべき行動

まず、プロジェクトで @azure/notification-hubs を使っているか確認してください。使っている場合は、現在のバージョン、Node.jsのバージョン、送信パターン、エラー処理、ロックファイルを確認します。

すでに2.0.xを使っているなら、2.1.0はエラー処理の改善を中心に検証できます。一方、1.x系から更新する場合は、2.0.0の破壊的変更を含めた移行計画が必要です。

最後に、ステージング環境で直接送信、タグ送信、ブロードキャスト、スケジュール送信のうち実際に使っている経路をテストし、ログに trackingId と correlationId が残ることを確認してください。今回のAzure SDK ドキュメント更新は小さく見えますが、通知基盤では「届かない」「誤って届く」「原因を追えない」が大きな障害になります。SDK更新と同時に、例外処理と運用ログを見直すことが最も実務的な対応です。

Azure
JavaScript TypeScript Azure SDK Azure Notification Hubs SDK更新

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次