EspressifがAliro SDKを公開｜ESP32でスマートロック標準に対応、今できること

はじめに

2026年7月16日、Espressif が esp-aliro SDK を公開しました。Aliro は、スマートフォンやウェアラブルを物理の鍵として使うための標準規格です。

自作のスマートロックというジャンルは、これまで各自が独自に実装するしかありませんでした。そこに標準が用意され、しかも手元の ESP32 で扱えるようになった、という話です。

ただし ESP32 に NFC は内蔵されていません。 初期の Aliro が NFC のみだとすると、当然「では何が要るのか」という疑問が出ます。そこも公式資料から確認します。

1. 🔑 Aliro とは何か

Aliro は CSA（Connectivity Standards Alliance） が策定した規格です。CSA は Matter を作った団体でもあります。

CSA の公式ページは、Aliro を「業界標準のアクセス資格情報および通信プロトコル」と説明しています。もう少し具体的には、

アクセスリーダーとユーザーデバイスの間の標準化された通信プロトコルであり、便利で一貫した体験を提供する

とされています。解決しようとしている課題として挙げられているのは次の3つです。

• 商業利用者にとっては、異なるベンダのハードウェア間の相互運用性
• 住宅の所有者にとっては、物理的な鍵の代わりにスマートフォンやウェアラブルを安全かつ確実に使えること
• システム管理者にとっては、混在したハードウェアをより簡単に管理できること

要するに「どのメーカーの錠前でも、同じ作法でスマホをかざせば開く」を目指した規格です。

2. 🧩 Matter と Aliro は競合しない

ESP32 で Matter を触ったことがある人は、「また新しい規格か」と思うかもしれません。この2つは役割が分かれています。

Espressif の説明はこうです。

Matter と Aliro は補完関係にあります。 Matter は Wi-Fi または Thread を経由したスマートホームのコミッショニング、制御、管理の経路を提供し、Aliro はユーザーデバイスとリーダーの間のローカルなデジタル鍵のやり取りを提供します。

「登録と管理は Matter、開ける瞬間は Aliro」と考えると分かりやすいはずです。ネットワークが落ちていても鍵は開かないと困る、という事情を考えれば、この分担は自然です。

3. 🔌 ESP32 に NFC は載っていない — では何が要るのか

ここが実装する側にとって一番の疑問です。ESP32 シリーズに NFC は内蔵されていません。

Espressif の記事は、Espressif の SoC に加えて NFC フロントエンドとロックアクチュエータが必要だとしています。つまり最低でも3つの要素が要ります。

1. ESP32 系の SoC（Aliro のプロトコル処理）
2. NFC フロントエンド（外付け。電波のやり取り）
3. ロックアクチュエータ（実際に鍵を動かす機構）

公式サンプルが使っているもの

esp-aliro に含まれるサンプルは aliro_reader の1本です。その README には、必要なハードウェアが具体的に書かれています。

この例は M5Stack Unit NFC と、互換性のある M5Stack のコントローラを使った Aliro NFC リーダーを示します。

必要な条件として挙げられているのは、HY2.0-4P の I2C ポートを持つ M5Stack コントローラと、M5Unit-NFC が対応しているチップ／ターゲットであること。そして動作確認済みのボードが明記されています。

M5Stack Unit NFC 側については、I2C アドレスは 0x50 固定、サンプルは 400kHz のポーリングモードで動作、ESP-IDF の I2C コントローラの選択は CONFIG_ST25R3916_I2C_PORT で行う、と書かれています。ST25R3916 という NFC コントローラが使われていることが、この設定名から読み取れます。

動作確認の手順も具体的です。起動時に I2C アドレス 0x50 で ST25R3916 の識別読み出しが成功するログが出て、ISO-14443-4 の NFC-A デバイスをかざすと ATQA・UID・SAK・ATS 長をログに出し、Aliro のトランザクションが始まる、とされています。

開発環境

README には ESP-IDF v5.5.3 をベースに開発したが、>=5.2,<6 のバージョンなら問題ないはずと書かれています。ビルドはボードごとの sdkconfig.defaults を指定する形です。

idf.py -D SDKCONFIG_DEFAULTS="sdkconfig.defaults;sdkconfig.defaults.BOARD" build
idf.py -p <port> erase-flash flash monitor

ESP-IDF の環境がまだの方は VS Codeで始めるESP-IDF環境構築ガイド｜最小構成でHello Worldまで が最短です。

4. 🧪 SDK は今どの段階にあるのか

公開から1週間です。 リポジトリの状態を見ておく価値があります。

README は、この SDK を「ESP32 シリーズ SoC 向けの公式 Aliro 開発フレームワークであり、Aliro リーダーの開発に使える」ものと説明しています。リーダー側、つまりドアに付く方が対象です。

対応している機能として挙げられているのは、Aliro-over-NFC の次の項目です。

• Standard Expedited Phase
• Fast Expedited Phase
• AUTH1/LoadCert コマンドによるリーダー証明書の送信
• アクセス資格情報の公開鍵を引くためのキースロット
• Mailbox of Exchange コマンド
• Step-up Phase

Bluetooth LE と UWB のサポートは将来のリリースで予定とされています。

エンドツーエンドの検証には壁がある

README の注記に、見落とせない一文があります。

CSA の aliro-actuator リファレンスは、2026年5月29日時点でまだプライベートアクセスです。 アクセスを希望する場合は CSA に申請してください。

そのうえで、エンドツーエンドの Aliro 検証にはこのリファレンスの使用を推奨すると書かれています。つまり、通しの動作確認をしようとすると、CSA への申請という手続きが挟まるということです。

リーダー単体の動作（NFC デバイスを認識してトランザクションを開始するところまで）はサンプルで確認できますが、「スマホの資格情報で実際に解錠する」ところまでを個人が今日すぐ試せるかは、また別の話です。

5. 🚪 玄関に付けるとなると、また別の話

標準が出たこと自体は素直に面白いのですが、扱っているのは物理の錠前です。ソフトウェアの不具合が「家に入れない」「誰でも入れる」に直結します。

標準化されたのは、スマホとリーダーの間の通信の作法です。次のような部分は、依然として設計する側が自分で決めることになります。

• 停電・電池切れのときにどうなるか（施錠状態のまま固まるのか、機械式で開けられるのか）
• 締め出しへの備え（物理鍵の併用、非常用の手段）
• 物理的なこじ開けへの耐性。通信をいくら固めても、機構が弱ければ意味がない
• 鍵をなくした端末の資格情報を、どうやって失効させるか

これらは Aliro が答えを出してくれる領域ではありません。「規格に沿って作れば安全な錠前になる」わけではない、という切り分けは持っておいたほうがよさそうです。

なお、こうした製品を EU 市場で販売する場合はサイバーレジリエンス法（CRA）の対象になり得ます。2026年9月11日から脆弱性の報告義務が始まる点については EUサイバーレジリエンス法9月11日開始｜個人開発者は対象か・JC-STARとの違い にまとめています。

まとめ

• 2026年7月16日、Espressif が esp-aliro SDK を公開。 Aliro は CSA が策定したアクセス資格情報の標準で、スマホやウェアラブルを物理の鍵にするためのもの
• esp-aliro が対象にするのはリーダー側（ドアに付く方）。ライセンスは Apache-2.0
• 対応は「Matter 対応の Espressif チップ全系（ESP32 / ESP32-C / ESP32-S / ESP32-H シリーズ）」と説明されている
• 現時点の対応は Aliro-over-NFC のみ。Bluetooth LE と UWB は将来のリリース予定
• ESP32 に NFC は内蔵されていないため外付けが必要。 公式サンプルは M5Stack Unit NFC（ST25R3916、I2C アドレス 0x50） を使い、M5Stack NanoC6 / NanoH2 で動作確認済み
• 開発は ESP-IDF v5.5.3 ベース、>=5.2,<6 なら問題ないはずとされている
• リポジトリはリリースタグなし・コミット14・サンプル1本。 エンドツーエンド検証に推奨されている CSA の aliro-actuator リファレンスは申請が必要な状態
• Matter とは競合せず役割分担。 管理は Matter、開ける瞬間は Aliro

よくある質問（FAQ）

Q1. どの ESP32 で使えますか？

Espressif は「Matter 対応の Espressif チップ全系、ESP32・ESP32-C・ESP32-S・ESP32-H シリーズを含む」としています。ただし公式サンプルで動作確認済みと明記されているのは、M5Stack NanoC6（ESP32-C6）と NanoH2（ESP32-H2）の2機種です。

Q2. NFC モジュールは別に買う必要がありますか？

はい。ESP32 に NFC は内蔵されていません。 Espressif は SoC に加えて NFC フロントエンドとロックアクチュエータが必要だとしており、サンプルは M5Stack Unit NFC を使っています。

Q3. 手持ちの ESP32 開発ボードと市販の NFC モジュールで動きますか？

公式には記載がありませんでした。 サンプルが前提にしているのは M5Stack のコントローラと M5Stack Unit NFC の組み合わせです。設定名（CONFIG_ST25R3916_I2C_PORT）から ST25R3916 を I2C で使う構成であることは読み取れますが、他の NFC IC で動くかどうかは公式資料からは分かりません。

Q4. Bluetooth や UWB でも使えますか？

現時点では NFC のみです。Bluetooth LE と UWB は将来のリリースで予定とされています。時期は公表されていません。

Q5. スマホ側は何をすればいいのですか？

esp-aliro が提供するのはリーダー側です。ユーザーデバイス（スマホ）側の実装については、この SDK の範囲ではありません。またエンドツーエンドの検証に推奨されている CSA の aliro-actuator リファレンスは、README の注記時点でプライベートアクセスで、CSA への申請が必要です。

Q6. ライセンスは何ですか？

Apache-2.0 です（リポジトリの表記）。

Q7. 今すぐ玄関の鍵を置き換えられますか？

通信の作法が標準化されただけで、停電時の挙動、締め出し対策、物理的なこじ開けへの耐性、端末を紛失したときの資格情報の失効といった部分は、設計する側が決める領域のままです。SDK もリリースタグが無く、サンプルは1本の段階です。評価と試作から始めるのが現実的だと考えます。

関連記事

• ESP32 シリーズの選び方｜S3・C3・C6・H2・P4 の違いと使い分け：動作確認済みの C6・H2 がどういうチップなのか
• VS Codeで始めるESP-IDF環境構築ガイド｜最小構成でHello Worldまで：サンプルのビルドに必要な ESP-IDF 環境
• ESP32-S31 発表｜Wi-Fi 6・イーサネット搭載、ESP32-S3から移行すべきか：Matter を Wi-Fi と Thread の両方で扱える新しいチップ
• EUサイバーレジリエンス法9月11日開始｜個人開発者は対象か・JC-STARとの違い：作ったものを EU 市場に出す場合の規制
• 目に見えないマルウェア「GlassWorm」｜Unicode不可視文字が突いたVS Code拡張とnpmのサプライチェーン：依存先が汚染されるとどうなるか

参考

• Announcing Espressif’s Aliro SDK（Espressif 公式開発者ポータル・2026年7月16日）
• espressif/esp-aliro（GitHub リポジトリ）
• esp-aliro / examples / aliro_reader（公式サンプル）
• Aliro（Connectivity Standards Alliance 公式）
• News（Espressif 公式ニュースルーム）
• M5Stack Unit NFC ドキュメント