Summary

  • Web MIDI は入力・出力ポートを見つけ、鍵盤からの操作を受け取り、シンセや照明機器へメッセージを送る。MIDI が運ぶのは音符や制御の情報で、音声そのものではない。
  • ポートの識別情報は機材構成を映し、System Exclusive（SysEx）は機器固有の機能に届く。通常の演奏用メッセージと SysEx には別の権限が必要になった。

古い鍵盤を使い続けたい理由は、鍵盤の重さやつまみの感触にある。ソフトを替えるたびに楽器まで替える必要はない。2012 年の W3C 草案 は、ブラウザーから MIDI の入力と出力を列挙し、メッセージをやり取りする道を示した。鍵盤、ドラムマシン、外部シンセ、舞台照明まで対象になる。ここで MIDI を「音」と思うと話がずれる。届くのは「この音符を鳴らす」「この値を変える」といった指示だ。実際に音を出すのは楽器。ブラウザーが指揮棒を持っても、オーケストラにはならない。

この低い層に徹する設計には利点がある。あるノブがビブラートなのか、照明の明るさなのかをブラウザーが決める必要はない。ポートとメッセージを扱い、意味づけはアプリと人に任せる。同じ仕組みを音楽室にも舞台にも持ち込めるのは、ウェブが勝手な楽典を押しつけないからだ。

しかし「どのポートか」を覚えるだけでも、機材室の情報は見える。初期草案には、再起動後も同じポートを探せる fingerprint があった。似た機材が並ぶスタジオではありがたい。ページにとっては、利用者の構成を見分ける手掛かりでもある。製造元、名前、バージョンもポートの属性だ。草案は列挙によるプライバシー問題と、機器固有メッセージの危険をすでに取り上げていた。便利な機材リストは、他人にも読まれ得る機材リストだ。

奥の扉の名は System Exclusive、略して SysEx。普通の MIDI メッセージは音符やつまみの変化を伝える。SysEx はメーカーごとの言葉で、音色や設定など機器固有のデータを扱える。演奏したいページと、機器の内部に話しかけたいページは同じ許可を求めていない。2015 年の草案 は requestMIDIAccess({sysex:true}) でその違いを明示した。追加の権限が拒まれれば、その要求は失敗する。演奏用の入口まで、保守室の鍵と抱き合わせにする必要はない。

実際の演奏では、権限表示だけで仕事は終わらない。ケーブルは途中で抜ける。音符は決めた時刻に送らなければ、耳にはっきり遅れて聞こえる。アプリが別のページ内に埋め込まれることもある。そこで API はポートの接続状態や時刻を指定した送信を扱う一方、ボタンの音楽的な意味はアプリに残す。ブラウザーは交通整理をする。作曲までは引き受けない。

2026 年 10 月 20 日の W3C 草案 では、権限の名前は midi、sysex: true は通常の MIDI より強い権限とされる。許可がなければ SysEx の送信は例外になり、受信した SysEx は隠される。requestMIDIAccess() は安全なコンテキストで使う機能だ。Permissions Policy の midi は既定の許可先が 'self'。埋め込みページが同席しただけで機材室の鍵を渡されることはない。草案は機器固有の命令が脆弱なハードウェアに及ぼし得る影響も検討する。可能性の分析を、実際に起きた事件と取り違えてはいけない。

W3C の公開履歴 には 2012、2013、2015 年、その後の 2024～2026 年の草案が並ぶ。発行日は仕様作業の節目であって、すべてのブラウザーが同時に実装した日ではない。長く残った問いは、楽器をウェブで使いながら、ページにスタジオの万能鍵を渡さない方法だった。

もう一度ドを押す。メッセージは届き、シンセが鳴る。古い鍵盤は古い鍵盤のまま役に立つ。受付係のブラウザーも、音楽を止めたわけではない。奥の引き出しだけ、別の鍵にした。