Azure Sphere OS 26.09 RC1の互換性評価方法｜Linuxカーネル更新を本番前に検証

Azure Sphere OS 26.09 RC1は、2026年7月29日にAzure Update 568466としてRetail Evalフィードへ公開されました。Azure Sphereを本番運用している組織は、代表端末を「Production OS Evaluation」などの評価用デバイスグループへ移し、現在市場で稼働している本番署名済みアプリケーションの互換性評価を早急に始める必要があります。

今回のリリースでは、顧客向け機能や契約済みインターフェースの変更は意図されていません。一方で、Azure Sphere OSの基盤となるLinuxカーネルがメジャーバージョンアップされます。Microsoftは6か月を超える統合テストと回帰テストを実施済みですが、実際の製品構成での検証を強く推奨しています。評価期間は2026年9月まで設けられ、その後、26.09はRetailフィードの端末へ広く展開される予定です。

Azure Sphere OS 26.09 RC1で何が変わるのか

Azure Sphere OS 26.09 RC1の公開内容を整理すると、次のようになります。

項目	内容
公開日	2026年7月29日
対象バージョン	Azure Sphere OS 26.09 RC1
配信フィード	Retail Eval
主な変更	基盤Linuxカーネルのメジャーバージョンアップ
顧客向け変更	意図された変更なし
Microsoft側の検証	6か月超の統合テスト、回帰テスト
評価期間	2026年9月まで
評価後の予定	Retailフィードへ昇格し、対象端末へ広く展開
問題発見時の対応	Azure Sphere製品チームへ早期に報告

通常、Retail EvalではRetailへの展開より約2週間早くOSが提供されます。しかし、26.09 RC1はLinuxカーネルの大幅な更新を伴うため、通常より長い評価期間が用意されています。(Microsoft Learn)

「Generally Available」や「Launched」を本番展開済みと解釈しない

Azure Updateのメタデータでは、26.09の更新情報に「Generally Available」や「Launched」と表示されます。

ただし、更新内容の本文には、26.09 RC1がRetail Evalフィードへ評価用として公開され、評価期間終了後にRetailフィードへ昇格すると明記されています。

したがって、現時点では次のように理解するのが適切です。

表示	実際の意味
Azure Update上の「Launched」	評価用リリースが利用可能になった
Retail Eval	互換性評価を行う先行配信環境
Retail	本番端末へ広く配信される通常フィード
2026年9月まで	問題を検出し、Microsoftへ報告するための評価期間

「Azure Updateで一般提供と表示されたから、すでに全端末へ展開済み」と判断しないよう注意してください。

顧客向け変更がなくても互換性評価が必要な理由

今回の変更は、Azure Sphereアプリケーションが直接利用するAPIの追加や削除ではなく、OS内部のLinuxカーネル更新です。

そのため、ソースコードの再ビルドが必須になるとは限りません。しかし、カーネルより上で動作するアプリケーションの挙動が、更新前と完全に同一になることまで保証されるわけではありません。

特に確認すべきなのは、次のような非機能面です。

• アプリケーションの起動時間
• 周辺機器との通信タイミング
• ネットワーク切断後の再接続
• 長時間稼働時の安定性
• メモリやCPU使用量
• OS更新後の再起動
• High-levelアプリとRTApp間の連携
• OTAによるアプリケーション更新
• 電源断や通信断からの復旧

Microsoft Learnでは、Production APIで構築されたアプリケーションは更新後のOSとの互換性を前提とする一方、Beta機能はリリース間で変更される可能性があると説明されています。それでもMicrosoftが実機評価を推奨しているのは、製品ごとにハードウェア、周辺機器、ネットワーク、アプリケーションの組み合わせが異なるためです。(Microsoft Learn)

OSの自動ロールバックだけでは業務上の問題を検出できない

Azure SphereのOS更新には、署名検証の失敗やOS実行上の重大な問題が発生した場合に、既知の正常な状態へ戻すロールバック機構があります。更新が通信断や電源断で中断された場合も、復旧後にダウンロードやインストールを再開する仕組みが用意されています。(Microsoft Learn)

ただし、次のような問題はOSの自動ロールバックを引き起こさない可能性があります。

• センサーの取得間隔がわずかにずれる
• クラウド接続の確立に以前より時間がかかる
• 特定条件でUARTやSPIの応答が遅れる
• 通信は成功するが再接続回数が増える
• アプリケーションは動作するが消費電力が増える
• 数日間の連続稼働後にだけ問題が現れる

自動ロールバックは更新失敗から端末を守るための機能であり、製品固有の業務要件や性能要件を判定するものではありません。

互換性評価に使う端末を選ぶ

評価端末は、単に空いている開発ボードを1台選ぶだけでは不十分です。実際に販売・設置している製品構成を代表できる端末を選びます。

最低限、次の違いを考慮してください。

選定軸	確認する内容
ハードウェア	製品型番、モジュール、基板リビジョン
周辺機器	センサー、UART、SPI、I2C、GPIOなどの構成
アプリケーション	本番で稼働中のアプリイメージと設定
通信環境	Wi-Fi、アクセスポイント、プロキシ、DNS、電波状況
設置環境	屋内、屋外、温度、電源品質
利用パターン	常時稼働、間欠稼働、低電力運用
地域	接続先やネットワーク条件が異なる拠点
バックエンド	Azure IoT Hub、自社API、MQTT接続先など

製品や基板の構成が複数ある場合は、各構成から少なくとも1台を選びます。重要度が高い製品では、同一構成でも複数台を用意し、端末固有の故障とOS更新による問題を切り分けられるようにします。

Retail端末を比較対象として残す

評価端末をすべて26.09 RC1へ更新してはいけません。

同一構成の端末を次の2グループに分けます。

グループ	OSフィード	役割
比較用端末	Retail	更新前の基準値を取得する
評価用端末	Retail Eval	26.09 RC1で同じ試験を実施する

起動時間、接続時間、通信成功率、メモリ使用量、消費電力などを両方で測定すると、26.09 RC1による差を把握しやすくなります。

Retail EvalでAzure Sphere OS 26.09 RC1を評価する方法

Azure Sphereには、OS評価用として次の既定デバイスグループがあります。

デバイスグループ	用途	OSフィード
Field Test OS Evaluation	ラボやフィールドテスト端末での評価	Retail Eval
Production OS Evaluation	本番アプリケーションと本番端末構成での評価	Retail Eval

どちらも通常のField Test、Productionグループと用途は似ていますが、受信するOSフィードがRetailではなくRetail Evalである点が異なります。市場投入済みアプリケーションを検証する場合は、Production OS Evaluationが基本的な選択肢です。(Microsoft Learn)

事前にアプリケーションのデプロイ内容をそろえる

評価端末を別のデバイスグループへ移動すると、その端末は移動先グループに割り当てられたアプリケーションを受信します。

Azure Sphereでは、デバイスグループに対するデプロイが端末イメージの正しい状態として扱われ、デプロイに含まれないアプリケーションイメージは端末から削除される場合があります。(Microsoft Learn)

そのため、端末を移動する前に次の点を確認してください。

1. Production OS Evaluationに本番と同じアプリケーションがデプロイされている
2. アプリケーションのバージョンとイメージIDが一致している
3. ボード構成イメージや設定に差がない
4. アプリケーション更新ポリシーが検証目的に合っている
5. 接続先やアプリ設定を変更していない

OS以外の条件が異なると、不具合がOS更新によるものか、アプリケーションの差によるものか判断できなくなります。

Azure Portalから評価端末を移動する

Azure Portalでは、次の手順で端末を評価用グループへ割り当てます。

1. Azure Portalで「Azure Sphere」を開く
2. 対象のAzure Sphere Catalogを選択する
3. 「Devices」を開く
4. 評価対象の端末を選択する
5. 上部メニューの「Assign」を選択する
6. 対象のProductを選択する
7. Device groupで「Production OS Evaluation」を選択する
8. 「Assign」を実行する

端末の割り当てには、対象Catalogに対するAzure Sphere Contributor権限が必要です。権限がない場合、Assign操作は利用できません。(Microsoft Learn)

Azure CLIから評価端末を移動する

以下の例はAzure Sphere IntegratedのAzure CLIを使用しています。

まず、対象製品のデバイスグループを確認します。

az sphere device-group list --resource-group MyResourceGroup --catalog MyCatalog --product MyProduct --output table

Production OS Evaluationの設定を確認します。

az sphere device-group show --resource-group MyResourceGroup --catalog MyCatalog --product MyProduct --device-group "Production OS Evaluation"

出力で、OSフィードがRetailEvalになっていることを確認してください。

次に、評価対象端末をProduction OS Evaluationへ移動します。

az sphere device assign --resource-group MyResourceGroup --catalog MyCatalog --target-product MyProduct --target-device-group "Production OS Evaluation" --device <DeviceIdValue>

デバイスグループの一覧表示、設定確認、更新には、az sphere device-groupコマンドを使用できます。(Microsoft Learn)

独自の評価用デバイスグループを作る場合

製品構成や地域ごとに評価端末を分けたい場合は、独自のRetailEvalグループを作成できます。

az sphere device-group create --resource-group MyResourceGroup --catalog MyCatalog --product MyProduct --name OS2609Eval --description "Azure Sphere OS 26.09 RC1 evaluation" --os-feed RetailEval --application-update UpdateAll

既存のカスタムグループのOSフィードを変更する場合は、次のように指定します。

az sphere device-group update --resource-group MyResourceGroup --catalog MyCatalog --product MyProduct --device-group MyEvaluationGroup --os-feed RetailEval

ただし、通常のProductionグループ全体をRetailEvalへ変更する方法は避けてください。評価対象を限定した別グループを用意したほうが、影響範囲を管理しやすくなります。

また、UpdateAllを指定する場合は、本番環境のアプリケーション更新ポリシーと一致しているか確認してください。(Microsoft Learn)

26.09 RC1が適用されたことを確認する

端末をRetailEvalのデバイスグループへ移動しただけでは、すぐにOS更新が完了するとは限りません。

Azure Sphere端末は、電源投入後にインターネットへ接続したときや、その後の定期的な更新確認時にOSを取得します。OS更新には再起動が伴い、通信状況によっては完了まで時間がかかります。Microsoft Learnでは、ダウンロードとインストールに15～20分程度かかる場合があり、途中で数分間応答しないこともあると説明されています。(Microsoft Learn)

接続した検証端末のOSバージョンは、次のコマンドで確認できます。

az sphere device show-os-version --resource-group MyResourceGroup --catalog MyCatalog --device <DeviceIdValue>

更新状態を確認する場合は、次のコマンドを使用します。

az sphere device show-deployment-status --resource-group MyResourceGroup --catalog MyCatalog --device <DeviceIdValue>

クラウド上に登録されている端末情報を確認する場合は、次のコマンドも利用できます。

az sphere device show --resource-group MyResourceGroup --catalog MyCatalog --device <DeviceIdValue> --output json

更新前後で、少なくとも次の情報を記録してください。

• インストール済みOSバージョン
• 更新可能なOSバージョン
• 最終OS更新日時
• 最終更新確認日時
• デバイスID
• Product名
• Device group名
• アプリケーションのイメージIDとバージョン

Azure SphereのAPIやCLIでは、インストール済みOS、利用可能なOS、更新時刻などの端末情報を確認できます。(Microsoft Learn)

Azure Sphere OS 26.09 RC1の互換性テスト項目

互換性評価では「アプリが起動した」という確認だけで終わらせないことが重要です。

次の表を基に、自社製品で使用している機能だけを抽出し、試験記録を残してください。

評価項目	具体的な試験	合格基準の例
OS更新	RetailEvalへの移動、ダウンロード、再起動	26.09 RC1が正常に適用される
コールドブート	電源切断後に起動	起動失敗がなく、本番アプリが自動起動する
再起動	ソフトウェア再起動を繰り返す	20～30回程度で異常終了がない
アプリ起動	初期化、設定読込、バックエンド接続	起動時間が基準値の許容範囲内
周辺機器	UART、SPI、I2C、GPIO、PWMなど	通信エラーやデータ欠損がない
RTApp連携	High-levelアプリとの通信、再起動	メッセージ欠損や停止がない
ネットワーク	Wi-Fi接続、DNS、TLS、クラウド認証	接続成功率と接続時間が基準内
再接続	AP停止、電波断、インターネット切断	通信復旧後に自動再接続する
クラウド通信	テレメトリ送信、コマンド受信	重複、欠損、順序異常がない
ローカルデータ	設定や状態の保存、再起動後の読込	データ破損や初期化がない
OTAアプリ更新	評価グループへのアプリ配信	正常に更新され、期待バージョンが起動する
性能	処理周期、遅延、スループット	製品のSLAや基準値を満たす
リソース	メモリ、CPU、ハンドル、再起動回数	時間経過による増加傾向がない
消費電力	アイドル時、通信時、処理時	設計上の許容範囲内
長時間稼働	72時間以上の連続運転	クラッシュ、停止、異常再起動がない
更新中断	ラボ環境で通信断や電源断を試験	復旧後に更新または通常起動できる

20～30回の再起動や72時間の連続稼働は、あくまで開始時の目安です。24時間365日稼働する設備や、現地で交換が難しい製品では、評価期間を活用して1週間以上の連続試験も検討してください。

性能差の許容範囲を試験前に決める

「少し遅くなったが問題ない」といった曖昧な判定を避けるため、試験前に数値基準を設定します。

例えば、次のように定義します。

指標	更新前	合格基準の例
アプリ起動時間	4.2秒	5秒以内
クラウド接続時間	8秒	10秒以内
テレメトリ欠損率	0％	0％
再接続時間	15秒	30秒以内
アイドル時消費電流	80mA	85mA以下
24時間あたり異常再起動	0回	0回

許容値は製品のSLAや設計要件から決めます。すべてを一律に「更新前から±10％」とするのではなく、データ欠損や異常再起動など、発生自体を許容できない項目は0件を基準にします。

評価期間中の進め方

2026年9月までの評価期間を有効に使うには、短い動作確認と長期試験を分けて実施します。

評価開始直後

1. Retail端末で更新前の基準値を取得する
2. 評価グループのアプリケーションデプロイを本番とそろえる
3. 代表端末をRetailEvalへ移動する
4. 26.09 RC1の適用を確認する
5. 起動、通信、周辺機器のスモークテストを行う

最初の1週間

1. 全機能の回帰テストを実施する
2. ネットワーク切断と再接続を確認する
3. OTAアプリ更新を実施する
4. 複数回の再起動を行う
5. Retail端末との差を比較する

2週目以降

1. 72時間以上の連続稼働試験を行う
2. 実際の設置環境に近い条件で運用する
3. メモリ、通信、消費電力の推移を記録する
4. 複数地域や複数ハードウェア構成へ評価を広げる
5. 発見した問題をMicrosoftへ報告する
6. 修正版や回避策が提示された場合は再試験する

評価期間の最終盤まで試験開始を遅らせると、Microsoft側が原因を調査し、Retail展開前に対応するための時間が不足します。

問題を報告するときに用意する情報

互換性問題を発見した場合は、「動かなくなった」という説明だけでなく、更新前後の比較情報をまとめます。

情報	記載内容
発生日時	UTCと現地時刻の両方
OSバージョン	更新前と26.09 RC1適用後
端末情報	デバイスID、製品、基板リビジョン
デバイスグループ	移動前と移動後
アプリ情報	イメージID、バージョン、署名状態
発生条件	起動時、通信断後、特定センサー使用時など
再現手順	誰でも再現できる操作手順
発生頻度	毎回、10回に1回、数日後など
期待結果	本来の動作
実際の結果	エラー、停止、遅延、再起動など
比較結果	Retail端末では発生するか
ログ	アプリログ、クラウドログ、エラーコード
影響	データ欠損、安全性、サービス停止時間
回避策	再起動、設定変更、アプリ修正など

特に重要なのは、同じアプリケーションを実行しているRetail端末では再現せず、26.09 RC1端末だけで再現することを示す比較結果です。

Microsoftは、互換性問題を発見した場合、可能な限り早くAzure Sphere製品チームへ報告するよう求めています。TAMがいる場合はTAMへ連絡し、それ以外の場合は契約中のMicrosoftサポート窓口を通じて、Azure Sphere製品チームへのエスカレーションを依頼します。

本番展開の判定基準

評価結果は、担当者の感覚ではなく、事前に定めたGo／No-Go基準で判定します。

Goと判断できる状態

• すべての評価端末へ26.09 RC1が正常に適用された
• 本番署名済みアプリケーションが正常に起動した
• 重要機能の試験がすべて合格した
• 異常再起動、クラッシュ、データ破損が発生していない
• 周辺機器との通信に問題がない
• ネットワークとクラウド接続が基準内である
• OTAアプリ更新が成功した
• 性能や消費電力が許容範囲内である
• 長時間試験で問題が発生していない
• 未解決の重大な互換性問題がない

No-Goまたは保留とすべき状態

• 26.09 RC1端末だけで再現する不具合がある
• データ欠損やデータ破損が発生する
• 手動操作をしなければ通信が復旧しない
• 原因不明の再起動やアプリ停止がある
• センサーやアクチュエーターの制御結果が変わる
• 消費電力や処理遅延が製品要件を超える
• OTA更新後にアプリケーションが起動しない
• 重大な問題をMicrosoftへ未報告のままにしている

問題が見つかった場合は、Retail展開を待つのではなく、アプリケーション側の回避策や修正版も並行して検討します。

よくある評価の失敗

開発用のデバッグビルドだけで確認する

Microsoftが評価を推奨しているのは、実際に市場で稼働しているアプリケーションです。

デバッグ用に機能を省略したアプリや、sideloadした開発版だけでは、本番のOTAデプロイ、署名済みイメージ、実際の設定を再現できません。本番と同じイメージを評価用グループへデプロイしてください。

Production OS Evaluationのデプロイ内容を確認せず端末を移動する

移動先グループに本番アプリケーションが正しくデプロイされていないと、アプリが削除されたり、別バージョンへ置き換わったりする可能性があります。

これをOSの互換性問題と誤認しないよう、移動前にデプロイ内容を比較してください。(Microsoft Learn)

起動確認だけで評価を終了する

カーネル更新の影響は、長時間稼働、ネットワーク再接続、I/Oタイミング、電源状態など、特定条件でのみ現れる可能性があります。

最低でも、再起動、通信断、周辺機器、OTA更新、長時間稼働を確認します。

比較用のRetail端末を残さない

更新後だけを調べても、発見した遅延や通信エラーが以前から存在していたのか判断できません。

同じ製品構成のRetail端末を残し、同じ試験を同じ条件で実施してください。

評価期間の終了直前に報告する

2026年9月まで評価できるとしても、問題報告が遅ければ、Retailフィードへの広範な展開前に調査や修正が間に合わない可能性があります。

再現性のある問題を確認した時点で、ログや試験全体が完全にそろうのを待たず、第一報を入れることが重要です。

Azure Sphereの移行計画とは分けて管理する

Microsoftは2026年3月20日にAzure Sphereの計画的な廃止を発表しており、MT3620 MCUは2026年7月31日に製品ライフサイクル上の終了を迎えました。一方、Azure Sphere OSとSecurity Serviceの延長サポートは2031年7月31日まで予定されています。(Microsoft Learn)

そのため、企業は次の2つを別の作業として管理する必要があります。

作業	目的
26.09 RC1の互換性評価	現在稼働している端末を安全に継続運用する
後継基盤への移行計画	将来の製品や2031年以降の運用に備える

将来的にAzure Sphereから移行する予定があっても、現在設置済みの端末が26.09へ更新される以上、今回の互換性評価を省略する理由にはなりません。

まず実施すべき5つの作業

Azure Sphere OS 26.09 RC1への対応では、次の順番で作業を進めます。

1. 製品型番、基板、周辺機器ごとに代表端末を選ぶ
2. Production OS Evaluationへ本番と同じアプリをデプロイする
3. 代表端末をProduction OS Evaluationへ移動する
4. 26.09 RC1の適用を確認し、Retail端末と比較試験する
5. 問題を発見したら、評価期間中のできるだけ早い段階でMicrosoftへ報告する

今回のポイントは、顧客向けAPIの変更有無ではなく、Linuxカーネルのメジャー更新によって製品全体の挙動が変わっていないかを確認することです。

Retailへの広範な展開後に問題を発見するのではなく、Retail Evalが利用できる2026年9月までの期間を使い、本番に近い端末、本番署名済みアプリケーション、実際のネットワーク環境で評価を完了させてください。