藤本健のDigital Audio Laboratory
第1052回
ウィンドウズが「ASIO」標準対応になる件。裏事情をヤマハに聞いてみた
2026年7月27日 08:00
6月8日の本連載で、「WindowsがASIOに標準対応する!?」という話を取り上げた。マイクロソフトのGitHubに上がっているオープンソースのUSBドライバーをChatGPTの手を借りながらビルドし、手元のFocusrite Scarlett 2i2 4th GenでASIOとして動作させることに成功した、という話である。
あの記事は、ADC Japanの会場でヤマハのオーディオインターフェイス系エンジニアとたまたま立ち話をしたところから生まれたものだった。立ち話で聞いた話をもとに悪戦苦闘してビルドし、なんとか形にしたわけだが、話を聞かせてくれた本人にきちんと連絡を取り、あらためて時間をもらって話を聞くことができた。
今回、取材に応じてくれたのは、ヤマハ株式会社 音響事業本部 商品開発統括部 MX開発部 第2ソフトグループの3人。サブリーダーの櫻田信弥氏、主事の伊藤孝氏、そして近藤建樹氏である。
今回のインタビューでまず見えてきたのは、この話が決して降って湧いたものではなく、ヤマハとマイクロソフトの間に、90年代のXG音源カードの時代から続く長い関係があったという事実だ。
そして10年以上前、マイクロソフト側から「ヤマハでASIOドライバーを作らないか」という打診が、すでに一度あったのだとか。ただ当時は資金面とASIOのライセンス契約という2つの壁に阻まれ、話は立ち消えになってしまったそうだ。
その状況を大きく動かしたのが、Qualcommの存在である。
Snapdragon Xを搭載したARM版Windows PCをクリエイター向けとして本格展開したいQualcomm、そしてWindows on ARMで音楽制作をきちんと動かしたいマイクロソフト。この両者の思惑が重なったことで、かつて頓挫した話にあらためてドライブがかかった、という経緯があったようだ。
なぜヤマハは、自社製品だけを優遇するのではなく、あえて汎用的に使えるオープンソースドライバーとして開発することを選んだのか？
そこには、音楽制作を始めるハードルそのものを下げたいという狙いと、Windowsという環境そのものへの信頼度を上げたいという業界全体を見据えた判断があった。
マイクロソフトとの長い関係、そして一度は立ち消えになった話
藤本：まずはみなさんが所属している音響事業本部 商品開発統括部 MX開発部 第2ソフトグループというのは、具体的に何をしているところなのでしょうか。
櫻田氏(以下敬称略)：音響事業部の中のMX開発部というのは、簡単に言うとミキサー関連なのですが、我々第2ソフトグループは、機器そのものに組み込まれるソフトウェアではなく、PCやモバイル、クラウドと連携する部分を作っています。
「第1」が本当に機器組み込みのファームウェアを担当していて、「第2」はドライバーや、機器と連携するPCアプリケーションを作っているという住み分けです。
藤本：普段からドライバーやソフトウェアの開発を手がけている中で、各社がしのぎを削っている分野だと思いますが、今回、その競争の中にありながらマイクロソフトに提供していく形になった経緯を教えてください。
櫻田：話せば長いのですが、もともとマイクロソフトとヤマハとの関係には長い歴史があります。古くはXG音源のカードの時代、つまり90年代ですね。Windows上でヤマハの音源を使ってもらうためのドライバーを書いていた頃からの付き合いです。
そのつながりがずっと続いている中で、あるとき、マイクロソフトのピート・ブラウン氏から「ヤマハでWindows用のASIOドライバーを作らないか」という話が、アメリカの現地法人経由で来たことがありました。
藤本：最初はいつ頃の話だったのですか。
伊藤：もう10年以上前だったと思います。細かい年は覚えていないのですけれど。
藤本：その時はなぜ実現しなかったのでしょうか。
伊藤：まず、費用を誰が負担するのかという問題がありました。それに加えて、当時ASIOのライセンス契約をSteinbergとの間で結ばないと使えなかったのです。
さらに、ライセンス契約を結んだからといって、マイクロソフトにドライバーを渡していいというわけでもありません。この2点がネックとなって、結局話は進まなかったのです。
Qualcommの参入が話を動かした
藤本：それがなぜ、いまこのタイミングで動き始めたのしょうか？
櫻田：実はここにQualcommが関わってくるのです。
藤本：確かに、先日ビルドしたASIOのシステムのREADMEの中にもヤマハとQualcommが共同開発した旨の記載がありました。が、どうしてQualcommがASIOに絡んでくるのか、ピンと来ません。
櫻田：QualcommはSnapdragonというチップを使って、WindowsをARMで動かすという取り組みに力を入れています。3年ほど前からARM版Windowsマシンに本腰を入れ始めていて、マイクロソフトのSurfaceにもQualcommのチップが採用されるようになっていました。
そして2024年、Qualcommが「Snapdragon X」を発表します。これはとりわけクリエイター向けという打ち出し方で、いろいろなメーカーからPCが出るという宣伝の仕方をしていました。
藤本：クリエイター向けというのは、具体的にどのような意味だったのでしょうか。
伊藤：要するに、Photoshopのようなクリエイティブ系アプリが動きますよ、というのがメインだったと思います。
もともとSnapdragonは性能が低く、事務用途くらいにしか使えないという印象だったんですが、性能がかなり向上して、AppleのCPU、Mシリーズにも対抗できるくらいになってきた。
そこでQualcommとしては、軽くてバッテリーの持つクリエイター向けWindowsマシン、という打ち出し方をするようになったのだと推察します。
藤本：これまでQualcommのSnapdragonというと、Android向けのイメージが強かったのですが、そこからPC分野にも力を入れるようになった。そこにマイクロソフトがQualcommを連れてきた、ということですね。
伊藤：そうですね。音楽制作アプリにもきちんと対応したいというのがあったはずなのですが、ARM向けには専用のドライバーを用意しないといけません。アプリと違って互換性の仕組みがないので、ドライバーはそれぞれ開発しないといけないのです。
当時、RMEさんなどは早めにARM対応を出してきていましたが、まだどこも十分ではない状態でした。
藤本：ヤマハとしてもドライバーのARM対応は進めていたのですか。
櫻田：はい、我々もドライバーのARM対応はすでに進めていましたし、CubaseもARMネイティブ対応をこの頃にはすでに終えていました。2024年には対応が完了していたと思います。
Steinbergはこのあたり、かなり早い段階からARMに一気に対応しました。Qualcommとしては、いろいろなメーカーに声をかけてARM対応を進めていて、その中の一社に我々もいた、という形だったのだと思います。
藤本：なるほど。つまり今回、ASIOを本気でやろうという話が動き出した背景には、ARM対応もセットで進めていたQualcommがドライブをかけた、という側面があったわけですね。
櫻田：そこが一つの引き金になったのは間違いないと思います。
実際、2024年のQualcommのイベント「Snapdragon Summit」で、ヤマハのロゴとともに、マイクロソフトとこのプロジェクトをやっていることが初めて対外的に明らかにされています。
この時点ではまだソースコードなどは何も公開されていませんでしたが、翌年、実際にGitHubでソースコードが公開される流れにつながっていきました。
ひっそりと公開されたオープンソースドライバー
藤本：GitHubで実際に公開されたのはいつ頃だったのですか。
伊藤：最初のコミットは、去年の夏か、秋くらいだったと思います。
近藤：そこからソースが移って、実際に一般公開という形になったのは去年の9月です。
藤本：あのプロジェクトのオーナーはマイクロソフトのピート・ブラウン氏になっていますが、実際に中身を書いているのはヤマハさんということですね。
伊藤：そうです。外から見ると、プロジェクトのオーナーはピートで、我々がそこにコミットしてコードを書いている、という形に見えると思います。
もうオープンな状態ですから、プルリクエストを送ってもらえれば誰でも見ることができますし、書いていただいても構わない、という状態になっています。
藤本：公開についてヤマハから何かアナウンスはしていたのですか。
櫻田：いえ、特にヤマハから発表ということはしていません。ピートが自身のブログなどで触れることはありますが、あくまで「分かる人には分かる」くらいの状態でした。
藤本：実際、公開後の反響はどうでしたか。
伊藤：積極的に宣伝していたわけではなかったので、正直あまり期待はしていませんでした。ピート・ブラウン氏の周辺、おそらく競合他社の方だろうなという方が、ときどきコードに反応してくれるくらいでしたね。そうした中で、先日、AV WatchのDigital Audio Laboratoryに取り上げていただいたのは、意外な展開でした。
藤本：前回の記事を見て、実際にビルドした人が他にいたのか、少し気になっているんですが。
伊藤：ビルドしたという書き込みは、あまり見かけなかったですね。正直、こちらとしても、まだ誰でも簡単にビルドできる状態だとは思っていなかったので、藤本さんがやってしまったのには驚きました。
MIDI 2.0の混乱と、今後のスケジュール
藤本：ピート・ブラウン氏のところでは、今年の1月以降、MIDI 2.0関連でWindowsのMIDIドライバーがいろいろとトラブっている印象があります。
この前、ドイツ・ベルリンのSuperboothでお会いしたときには、5月中にはすべて解決する、と話していましたが、まだ収束していません。もともとの計画としては、MIDI 2.0の問題が片付いたら、このASIOドライバーをWindows本体に組み込んでいく、という順番だったと思いますが。
櫻田：ピートが直接そう言っているわけではないんですが、そういうつもりなんだろうな、というのはこちらでも感じています。今年の春先くらいは、正直「MIDI 2.0問題で、それどころじゃないだろうな」という状況でした。ですから、こちらはこちらで、必要な機能開発をどんどん進めておく、という形で動いています。
藤本：機能の開発自体は、いつ頃までに完成させる予定なのですか。
櫻田：我々としては、寒くなる前には機能実装自体を終わらせたいと考えています。ただ、その後Windowsに実際に載せていくかどうかは、完全にマイクロソフトさん次第になるので、そこはまだ何とも言えません。テストの進め方もどうするか、まだ完全には決まっていないのです。
藤本：Windows Insider経由で配布する、という案もあったのですよね。
近藤：もともとはそういう話もありましたが、Windows Insiderが適切なのかどうかというのは、内部でも議論になっています。
ピート・ブラウン氏自身がDiscordで言っていたことですが、一般の音楽制作ユーザーは、そもそもInsider Previewを実用環境として使わないだろうと。ライセンスの制約もありますし、OSを元に戻す手間を考えると、普通は使わないですよね。MIDI 2.0のときに、それに気づいたようです。
伊藤：マイクロソフト社内では、社員に強制的にInsiderが配られるくらいの感覚らしいですが、それと同じ感覚で音楽制作ユーザーに考えてもらうのは難しい、ということですね。
近藤：だからこそ、もっと広くテストに参加してもらえるような、別の配布のやり方を考えないといけないだろうと。GitHub上のビルド済みバイナリをIntel版・ARM版それぞれ用意して、一般ユーザーに使ってもらいながら不具合を報告してもらう、といったやり方も一つの案としてはあると思います。
藤本：そうしたテストを重ねて問題を潰していって、最終的に実装、という流れになっていくわけですね。
近藤：基本的にはそういう流れになると思います。ただ、どうしてもASIOとして動かせないデバイスも出てくるとは思うので、そのあたりの見極めが最後の課題になるだろうと考えています。
Macを目指しているのか、Windowsならではの限界は何か
藤本：Macの場合、USB Audio Class 2.0対応のインターフェイスであれば、つなぐだけでCore Audioがそのまま動きます。今回のドライバーが実現すれば、Windowsも同じような状況になる、という理解で合っていますか。
伊藤：目指している方向としては、まさにそこです。どこまでMacに迫れるかは分かりませんが、WindowsだからMacだから、という違いがなくなったほうが、我々オーディオインターフェイスなどを提供するメーカーとしても本当は良いはずなのです。
世の中的にはWindows PCのほうが台数として多いのに、音楽をやろうと思うとMacを買わなければ、という空気があります。Windowsでも同じようにできたほうが、間違いなく裾野は広がるはずです。
藤本：ちなみにMacの場合、内蔵の音源でCore Audioが利用できるので、わざわざオーディオインターフェイスを用意しなくてもすぐにDTMを始められるというメリットがあります。今回のドライバを使うことで、Windows PC内蔵のサウンド機能をASIO化する……ということはさすがにできないですかね？
伊藤：残念ながら、これはUSBオーディオをASIO化するものなので、難しいですね。私自身も普段はMacの内蔵音源とスピーカーで作業をしているので、Windowsでも同じようにできればという要望自体は同感です。
ただし内蔵オーディオはUSBのような統一規格ではなく、各社バラバラの実装になっており、PCメーカー以外の第三者がデータシートを入手すること自体が難しいこと、そしてヤマハ側にもそのあたりのノウハウが乏しいことから、現時点で対応の計画はありません。いろいろなPCに搭載されているRealtekのオーディオコントローラーには、すでにASIOドライバーが用意されていることが意外と多いですよ。
ただし、それらのドライバーには不具合を抱えているケースも少なくなく、ヤマハ自身が改良するのは難しいものの、今回開発しているUSB ASIOドライバーを参考にしてもらいながら、品質が上がっていけばいいな、と思っています。
Snapdragon XのPCはDTM用途で使えるか
藤本：ところでQualcommとの関係を築いたことで、開発上のメリットもあったんですか。
近藤：このプロジェクトはQualcommのプラットフォーム上で開発しているので、何か問題が起きたときにQualcommに直接言えば、Windows側やハードウェア起因の細かい部分、DPCレイテンシーのようなところまで見てもらえるんじゃないか、という期待がありました。
実際、Wi-Fi関連の問題を一つ、Qualcomm側で見てもらえたこともあります。PCメーカーなど、中間に位置するメーカーと話すのではなく、CPUメーカーと直接やり取りできるというのは、我々にとってはありがたいことです。
藤本：Snapdragon XのPCとIntel PCを、DTM用途で比較するとどのような違いがありますか。
近藤：やはりハイエンドのIntelには、まだ性能面で及ばない部分があります。ただ、ミドルクラス相当であれば、それなりの性能は出ています。対応アプリがまだ少ないので、ネイティブ対応しているアプリに限って言えば、ミドルクラスのPCとして十分使えるレベルにはなっていると思います。
藤本：今後、ヤマハとQualcommの間で、そのあたりがさらに最適化されていく可能性もあるということですね。
近藤：それはぜひ期待したいところですし、逆にIntelやAMDのプラットフォームにも同じように働きかけができれば、と思っています。ただ、Qualcommのように一社でハードからソフトまで見ているところだと話がしやすい、というのはあります。
ベンダードライバーは不要になるのか
藤本：今後数年でこのドライバーが標準搭載されたとき、各社が独自に出しているベンダードライバーは不要になるのでしょうか。
Macの場合、クラス2.0対応であればとりあえず音は出ますが、RMEなどのようにドライバーを入れることでレイテンシーが小さくなったり、追加の機能が使えたりしますよね。Windowsでも同じような世界になる、という理解でいいですか。
櫻田：基本的にはそうなると思います。標準的な機能についてはこのドライバーでカバーしていきたいと考えていますが、各社独自の実装や、よりパフォーマンスを詰めたいという部分は、引き続きベンダードライバーの出番になると思います。オープンソースなので、このコードをフォークして、自社製品向けにカスタマイズしていただく、という使い方も十分あり得ると思っています。
伊藤：実は、URシリーズ、URXシリーズなど、当社のコントロールパネルにも「ローレイテンシーモード」という項目があるのですが、これをオンにすると、USBの標準プロトコルから外れた独自の通信に切り替わって、レイテンシーをかなり詰められるようになっています。これはもうクラスドライバーの範囲では実現できないので、こうした部分は各社が独自にベンダードライバーとして出していくことになると思います。
藤本：Macのように、複数のオーディオインターフェイスを束ねて1台の仮想デバイスとして扱う、というような機能はASIOでは難しいんでしょうか。
伊藤：難しいですね。MacはSRCなどの仕組みを使って非同期のデバイス同士をうまく扱えるようになっていますが、ASIOはそもそもそういう用途を想定していない、かなり古いプロトコルなのです。
1対1の通信が前提になっているので、それをやろうとすると、ASIOという規格自体をかなり根本から拡張しないと難しい。加えてUSBの場合、クロックの同期という問題もあります。デバイスごとに独立したクロックで動いているので、複数のインターフェイスを同期させる汎用的な仕組みは、今のところ存在しません。
コントロールパネルの実演と、Device IDという名の壁
藤本：前回、私がビルドを試した際にはコントロールパネルがどうしてもビルドできませんでした。現状どのようになっているか、見せていただけますか。
近藤：はい、今ここで開いてみますね。
これはIntel版なんですが、GitHubのリポジトリをビルドすると生成されるフォルダの中に、ドライバー本体とコントロールパネルの実行ファイルが出てきます。開くとこんな画面になっていて、今はSteinbergのUR22Cが認識されている状態です。バッファーサイズやサンプルレートなど、一般的なコントロールパネルとして使える機能が一通り揃っています。
藤本：これで十分ですね。
近藤：各社どこも最低限持っているであろう機能は、一通り用意しているつもりです。あとはこの画面に、マイクロソフト・Qualcomm・ヤマハがこのプロジェクトに関わっていることを示すライセンス情報も表示されるようになっています。
藤本：ちなみに、このコントロールパネルのビルドは、以前より簡単になりましたか。
近藤：もう手こずらなくなりましたね。ドライバー本体は、必要なビルドツールを正しいバージョンで揃えないといけないので、そこが一番のハードルだと思います。
似た名前のビルドツールがいくつもあって、正しいものを入れないと動かない。しかもドライバーは、入っていなくても「入っていない」と教えてくれないので、原因が分かりにくいのです。そのあたりのビルドガイドは、今後用意していきたいと思っています。
伊藤：今のクラスドライバーの仕組みでは、事前にVID・PID、つまりベンダーIDとモデルIDが登録されているデバイスでないと動作しません。マイクロソフトが正式に署名してWindowsに組み込まれれば、この制限はなくなるはずですが、今の段階では、GitHub上のinfファイルというデバイス定義ファイルに、対応させたい機種のIDをあらかじめ書いておく必要があります。
藤本：あのinfファイルに載っていたのは、これまでテストしたことのある機種のリストということなのですね。てっきり、機種名が入っている時点でクラスドライバーとは関係のない話なのかと混乱していました。
伊藤：いえ、クラスドライバーとして動くかどうかとは別に、Windowsが正式にこのドライバーを組み込むまでは、動作確認済みのIDを一つずつ登録していく必要があります。
ですから、ヤマハに限らず、これまで動作確認した機種のIDがどんどん増えていっている状態です。新製品が出るたびに、機能は変わっていなくても、IDを追加するためだけにバージョンアップが必要になります。
藤本：ということは、前回私が偶然Scarlett 2i2 4th Genで動かせたのは、たまたまあのリストに載っていた機種を使ったから、というだけの話だったのですね。載っていなかったら、まったく動かなかったと。
伊藤：その通りです。今後、皆さんにテストに参加していただくとなったときも、「自分の持っている機材だけ動かない」ということが、リストに載っていないという理由だけで起こり得ます。Windowsに正式に組み込まれれば、クラスドライバーとして誰でも使える状態になるはずですが、それまでは、このような形にせざるを得ません。
藤本：外部の人間が、勝手にクラスドライバーとして動くように書き換えることはできないんですか。
伊藤：セキュリティ上、それはできません。infファイルに「クラス」と書いても、我々が勝手にビルドしたものでは、Windowsが正式なクラスドライバーとして扱ってくれません。
藤本：新しい機種を使いたい場合、こちらでDevice IDを調べてお伝えすれば、追加してもらえますか。
伊藤：はい、ご要望をいただければ、こちらで追加してinfファイルを更新することもできますし、ビルドできる方であれば、ご自身でIDを追記していただいても構いません。
デバイスマネージャーのプロパティから該当デバイスのハードウェアIDを確認して、それをVisual Studioのプロジェクト内にあるinfファイルに一行追記するだけです。
藤本：これが一般公開されたら、追加のリクエストが一気に来そうな気もします。
伊藤：来た分だけ追加できればいいのですが、100件で済むかどうかも分かりませんし、どんどん新しいデバイスも出てきますからね。そのあたりは、正直これからの課題だと思っています。
藤本：本来であれば、マイクロソフトに直接インタビューするのが筋だったとは思いますが、ヤマハの開発チームの皆さんに直接お話を伺うことができたのは、大きな意味があったと思っています。
櫻田：正直、我々からするとなかなか光の当たらないドライバー開発の分野なので、こうして取り上げていただける機会自体をありがたく思っています。
ビジネスの立て付けとしては、あくまでマイクロソフトとQualcommの下で開発を受託している立場になるので、我々から単独でプレスリリースを出す、という形にはなりにくいのです。
ただ、GitHubのREADMEにもヤマハが関わっていることは堂々と書かれていますし、ソースコードも公開されているので、その周辺の裏側の話であれば、今回のようにお伝えしやすいと思っています。
今回のような形で発信の機会を積み重ねていくことが、いずれQualcommさんやマイクロソフトさんの側で何か発表するときに、こちらとしても乗っかりやすくなる、という意味もあるかなと考えています。
持ち帰ってからの検証、そしてすべてのデバイスがうまくいくわけではないという現実
取材の際、実際に近藤氏が持参してくれたビルド済みのドライバーとコントロールパネルをコピーさせてもらうことができた。
帰宅後、さっそく自分の環境で試してみたところ、前回はビルドできなかったコントロールパネルもしっかり画面が表示され、バッファーサイズなどの設定変更もきちんと反映されることを確認できた。
さらに、インタビュー中に話題に上がったDevice IDの制限についても、試してみた。
具体的にはデバイスマネージャーからハードウェアIDを確認し、それを伊藤氏に連絡した上で、infファイルに追記してもらったうえで、再度テストするいう作業である。
試したのは、QuestyleのUSB DACである「Sigma Pro」、KORGのユーロラック対応小型ミキサー「NTS-4」、そしてヤマハのオーディオインターフェイス「UR22C」の3機種だ。
結果は機種によってはっきりと分かれた。
まずSigma ProとUR22Cは問題なくASIOとして認識され、動作させることができた。ところがNTS-4だけは、Device IDを追加してもエラーが出てしまい、うまく動作させることができなかった。
USB Audio Class 2.0に準拠していれば、原理的にはどのデバイスでも同じように動くはずだと思っていたのだが、必ずしもすべてのUSB Classコンプライアントなデバイスが、同じように簡単に動くというわけではないらしい。
伊藤氏によると「このコード10エラーは、ドライバは起動したものの初期化に失敗していることを意味します。おそらく何か未対応の部分があるのではないかと思いますが、これ以上は実際に機材に接続してデバッグをしないとわかりません」とのこと。
インタビューで聞いた通り、まだこのドライバーは発展途上であり、機種ごとの相性や、まだ拾いきれていない実装差がどこかに残っている、ということなのだろう。Windowsが正式にこの仕組みを取り込むまでには、こうした一つひとつの積み重ねが必要になりそうだ。
リクルートに15年勤務した後、2004年に有限会社フラクタル・デザインを設立。リクルート在籍時代からMIDI、オーディオ、レコーディング関連の記事を中心に執筆している。以前にはシーケンスソフトの開発やMIDIインターフェイス、パソコン用音源の開発に携わったこともあるため、現在でも、システム周りの知識は深い。 著書に「コンプリートDTMガイドブック」(リットーミュージック)、「できる初音ミク&鏡音リン・レン 」(インプレスジャパン)、「MASTER OF SONAR」(BNN新社)などがある。またブログ型ニュースサイトDTMステーションを運営するほか、All AboutではDTM・デジタルレコーディング担当ガイドも務めている。Twitterは@kenfujimoto。