MENU

Edge 147 Web プラットフォームで Android の Web Serial API に対応　何が変わるかと実装の要点

Microsoft Edge

Edge 147 Web プラットフォームのリリースで、Android 版 Microsoft Edge は Web Serial API を扱えるようになりました。これにより、シリアルポートそのものだけでなく、シリアルをエミュレートする USB 機器や Bluetooth 機器にも、Android 上の Web アプリから接続できる可能性が広がります。Microsoft Learn の Web プラットフォーム ノートでは Edge 147 のリリースを 2026年4月9日と案内し、Stable Channel のリリースノートでは 147.0.3912.60 が 2026年4月10日付で掲載されています。今回の変更は、単なる API 追加ではなく、接続デバイス Web アプリを Android でも現実的に運用しやすくしたアップデートです。(Microsoft Learn)

影響が大きいのは、教育向けのマイコン・ロボット制御、3D プリンタやレーザー加工機のブラウザ管理画面、現場保守用の機器コンソール、Bluetooth シリアル機器を使う業務アプリです。この記事では、Edge 147 で何が変わったのかに加えて、WebUSB や Web Bluetooth との違い、Android 実装で詰まりやすい点、管理端末でのポリシー設計まで、すぐ判断に使える形で整理します。(Microsoft Learn)

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

Edge 147 Web プラットフォームで何が追加されたのか

Microsoft Edge 147 の Web プラットフォーム ノートには、Android で Web Serial API をサポートしたと明記されています。接続対象は通常のシリアルポートだけでなく、シリアルポートをエミュレートする取り外し可能な USB 機器や Bluetooth 機器も含まれます。Microsoft が例として挙げているのは、ロボット、ミル加工機、レーザー加工機、3D プリンタです。(Microsoft Learn)

ここで重要なのは、これまで PC や専用アプリ寄りだった「機器をつなぐ Web アプリ」を、Android スマートフォンやタブレットにも広げやすくなったことです。Chrome の公式解説でも、Web Serial はマイクロコントローラや 3D プリンタのようなシリアル機器を Web から扱うための API と説明されており、代表例には Microsoft MakeCode のような Web ベースのツールも含まれています。(Chrome for Developers)

さらに、Bluetooth Classic の RFCOMM / Serial Port Profile 系の機器も Web Serial の守備範囲です。Chrome 開発者向けの公式ブログでは、モバイル POS のレシートプリンタのような Bluetooth SPP 機器も実例として挙げられています。つまり、今回の Android 対応は教育用途だけでなく、現場業務アプリにも効いてきます。(Chrome for Developers)

影響が大きいのはどんなケースか

とくに影響が大きいのは、教育現場、設備制御、現場保守、Bluetooth シリアル機器を使う業務アプリです。Microsoft のリリースノートはロボット、ミル加工機、レーザー加工機、3D プリンタを挙げており、Chrome の公式資料は Microsoft MakeCode やモバイル POS のレシートプリンタのような実例を示しています。(Microsoft Learn)

立場影響最初にやること
接続デバイス Web アプリの開発者Android 版 Edge を対象に入れやすくなるnavigator.serial の検出と接続 UI を追加する
学校・研修の担当者PC 前提の教材運用を見直しやすい使う機器がシリアル接続か確認する
現場運用担当タブレット中心の運用に寄せやすい実機で USB / Bluetooth 接続を検証する
IT 管理者許可・禁止の設計が必要になるEdge ポリシーの適用方針を決める

Web Serial API と WebUSB・Web Bluetooth の使い分け

Web Serial API が向くケース

Web Serial API が向くのは、機器の仕様書や SDK の説明に serial、COM、baud rate、SPP、RFCOMM といった言葉が出てくるケースです。公式ドキュメントでも、Web Serial はシリアルポートそのものに加え、シリアルをエミュレートする USB / Bluetooth 機器を対象にしています。(Microsoft Learn)

WebUSB が向くケース

WebUSB が向くのは、シリアル化された通信ではなく、USB デバイスサービスそのものを Web から扱いたいケースです。Chrome の公式資料は WebUSB を「non-standardized USB devices」を Web へ公開する仕組みとして説明しており、ベンダー独自の USB プロトコルを直接扱うならこちらが本命です。(Chrome for Developers)

Web Bluetooth が向くケース

Web Bluetooth が向くのは、BLE GATT ベースの機器です。Chrome の公式資料でも、Web Bluetooth は Bluetooth Low Energy の GATT サーバー接続を前提にしており、Bluetooth Classic の RFCOMM サービスを使う機器では Web Serial を検討するよう案内しています。(Chrome for Developers)

迷ったときの判断基準はシンプルです。シリアル通信の概念が前面に出るなら Web Serial、BLE のサービスや characteristic を読むなら Web Bluetooth、USB 独自プロトコルを直接扱うなら WebUSB と整理すると、実装の方向を誤りにくくなります。(Chrome for Developers)

Android 向け実装で最初に確認すべきこと

接続フローは navigator.serial とユーザー操作から始める

実装の入口は navigator.serial の feature detection です。そのうえで requestPort() はユーザー操作から呼び出す必要があり、仕様は secure context を前提にしています。すでに許可済みのポートを再利用する場合は getPorts() を使います。ページ表示直後に自動接続しようとして動かない、HTTP の検証環境でだけ失敗する、といった詰まり方はここで起きやすいです。(WICG)

if (!("serial" in navigator)) {
  console.log("Web Serial API は未対応です");
}

document.querySelector("#connect").addEventListener("click", async () => {
  try {
    const port = await navigator.serial.requestPort();
    await port.open({ baudRate: 115200 });

    const reader = port.readable.getReader();

    while (true) {
      const { value, done } = await reader.read();
      if (done) {
        reader.releaseLock();
        break;
      }
      if (value) {
        console.log(value);
      }
    }
  } catch (error) {
    console.error(error);
  }
});

単一機種向けアプリなら requestPort({ filters: [...] }) で候補を絞った方が誤接続を減らせます。既に許可されたポートは navigator.serial.getPorts() で拾えるため、再訪時の UX も改善しやすいです。baudRate は機器仕様に合わせるのが基本で、値が違うと受信データが読めなくなります。一方で、一部の USB / Bluetooth シリアル機器では baudRate が無視される場合もあります。(Chrome for Developers)

iframe と Worker の扱いを早めに決める

埋め込み構成も見落としやすい点です。Web Serial の仕様は secure context を要求し、クロスオリジン iframe で API を使うにはトップレベル文書側の Permissions Policy による許可が必要です。また、仕様上 serial と getPorts() は Dedicated Worker でも使えますが、requestPort() は Window だけに公開されています。つまり、ポート選択は UI スレッド、継続的な読み書きは Worker という分担にすると設計が安定します。(WICG)

失敗しやすいポイント

Android 対応だけ見て機器側の方式を確認しない

Android 版 Edge 147 が対応したのは「Web Serial API を使う土台」です。実際に扱えるのは、シリアルポートとして認識できる機器、または USB / Bluetooth でシリアルをエミュレートする機器です。仕様書が BLE GATT 中心なら Web Bluetooth を見るべきですし、USB の独自プロトコルなら WebUSB の方が自然です。API を取り違えると、実装前半は進んでも接続フェーズで止まりやすくなります。(Microsoft Learn)

キャンセルと切断を異常終了としてしか扱わない

requestPort() のプロンプトでユーザーが機器を選ばなければ、仕様上は NotFoundError が返ります。現場向けアプリでは、これを単純な失敗として扱うより、「接続はキャンセルされました」「もう一度選択する」のような再試行導線を用意した方が運用は安定します。(WICG)

シリアル通信は、抜き差し、電源断、ペアリング切れでセッションが終わります。Chrome の公式解説でも、致命的な読み取りエラーが起きると port.readable が null になり得ると説明されています。接続ボタンを一度押したら終わりではなく、切断検知後に再接続できる UI を最初から入れておく方が安全です。(Chrome for Developers)

ボーレートをサンプル値のまま固定する

baudRate は機器ドキュメントで確認するのが原則で、値を誤ると受信データが読めなくなります。開発初期に動いたサンプル値をそのまま量産機へ流用すると、現場ごとに文字化けや通信不能が起きます。USB / Bluetooth でシリアルをエミュレートする一部機器では無視される場合があるため、「常に不要」ではなく「機器依存」と捉えるのが安全です。(Chrome for Developers)

管理端末で使うなら Edge ポリシーを確認する

管理端末でこの機能を使うなら、Android 147 以降で使える Edge ポリシーを先に整理しておくと運用がぶれません。DefaultSerialGuardSetting はサイト全体の既定動作を Ask / Block で制御でき、SerialAskForUrls と SerialBlockedForUrls は特定サイト単位の許可・禁止、SerialAllowAllPortsForUrls は特定オリジンに全シリアルポートへの自動許可を与えます。これらは Microsoft の各ポリシー文書で Android 147 以上対応とされています。(Microsoft Learn)

やりたいこと見るポリシーAndroid 147 での扱い
まずは毎回ユーザー確認にしたい / 全体禁止したいDefaultSerialGuardSetting対応
特定サイトだけ許可したいSerialAskForUrls対応
特定サイトだけ禁止したいSerialBlockedForUrls対応
特定サイトへ全シリアルポートを自動許可したいSerialAllowAllPortsForUrls対応
USB ベンダー / 製品 ID 単位で自動許可したいSerialAllowUsbDevicesForUrlsAndroid は非対応

上表の対応状況は、Microsoft の各ポリシー文書にある Supported versions の記載に基づきます。(Microsoft Learn)

実務上の注意点は最後の行です。デスクトップでは USB の vendor / product ID 単位で自動許可する設計ができますが、SerialAllowUsbDevicesForUrls は Android では未サポートです。Android 端末では、サイト単位の許可・禁止や全ポート自動許可を軸にしつつ、アプリ側で filters を使って機器候補を絞る設計の方が現実的です。(Microsoft Learn)

いま取るべき次の一手

今回のポイントは、Edge 147 で Android の Web Serial API が使えるようになり、接続デバイス Web アプリをモバイルへ広げやすくなったことです。ただし、実装では secure context、ユーザー操作、API の選定、切断時の再接続、管理ポリシーまで含めて初めて安定します。(Microsoft Learn)

次にやることは、この 3 つです。

  • 開発者は、対象の Android 実機で Edge 147 以降を使い、navigator.serial の検出、接続ボタン、再接続導線まで含めて検証する
  • サービス担当は、対象機器の仕様書を見て、Web Serial・WebUSB・Web Bluetooth のどれが自然かを先に判定する
  • 管理者は、DefaultSerialGuardSetting、SerialAskForUrls、SerialBlockedForUrls、SerialAllowAllPortsForUrls のどこまで使うかを決め、Android では SerialAllowUsbDevicesForUrls が使えない前提で設計する

Edge 147 の Android 向け Web Serial 対応は、単に「スマホでもつながるようになった」という話ではありません。専用アプリ前提だった接続デバイスの運用を、ブラウザ中心へ寄せられるかどうかを見直すきっかけです。まずは対象機器の通信方式を確認し、実機で requestPort() と getPorts() の挙動を確かめるところから始めるのが最短です。(Chrome for Developers)

Microsoft Edge
Web開発 Microsoft Edge Android Web Serial API

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次