藤本健のDigital Audio Laboratory
第1049回
ウィンドウズが「ASIO」に標準対応!? GitHubのドライバをChatGPTの手を借りてビルドしてみた
2026年6月8日 08:00
Digital Audio Laboratoryの連載においては、「Windowsは普通にオーディオを再生するとカーネルミキサーを経由するため音質が劣化する」という問題点を何度も指摘してきた。まあWASAPIを使うことでそれを回避することは可能だが、いよいよWindowsが「ASIO」に標準対応する可能性が出てきたようだ。
この話を知ったのは、6月1日から3日まで、東京・秋葉原で行なわれた「ADC Japan」というオーディオ系の開発者イベントでのことである。
たまたまヤマハのオーディオインターフェイス系のエンジニアと立ち話をした際、ヤマハが汎用のASIOドライバを開発し、それをマイクロソフトがGitHubにUPしていること、そして近い将来、マイクロソフトがそれをWindowsに組み込んでいく考えであることなどを聞いたのだ。
実際それがどんなものなのか試してみたので、レポートしてみよう。
GitHubにインストーラがない？ 自らビルドすることに……
そのヤマハのエンジニアから聞いたのがこちらのGitHubのサイトだ。
USB Audio Class 2.0対応のオーディオインターフェイスであれば、基本的にASIOドライバが利用できるようになるシステムのようなので、ここからソフトをダウンロードし、インストールすればいいもの……と思っていた。
ところが帰宅して、このGitHubサイトを覗いてみたところ、どうもインストーラが見当たらない。
GitHubのページをよく読むと、「このプロジェクトにはUSB Audio Class 2(UAC2)ドライバとASIOインターフェイスが含まれており、将来的にWindowsに搭載予定」と書かれている。
つまり現時点ではまだWindowsには組み込まれておらず、ソースコードから自分でビルドする必要があるということだ。
また、ASIOを利用するにはSteinbergのASIO SDKが別途必要で、それはSteinbergの開発者向けページから入手しなければならないことも記されていた。
さらにREADMEにはヤマハとQualcommとの共同開発であることも明記されており、ADC Japanでのヤマハエンジニアの話と合致する。
まあ、従来であれば「自分でビルドしなくてはならない」ということを知った時点でお手上げだ。
確かに大昔は、筆者もC言語で書いたプログラムをコンパイルして実行ファイルを作って……なんてことをしていたが、長らくそんなことをしていないし、現在のシステムを自分でビルドする、なんてできそうにない。
けれど、今はそうした難しいこともAIが手助けしてくれる時代。そこで、事情をChatGPTに伝えて手伝ってもらうことにしたのだ。
すると、まずはVisual Studioが必要だ、という。大昔にはVisual C++とかVisual Basicなどを購入して使ったことがあった。
この実験のためにそんな高価なものを買わなくちゃいけないのか……と思ったら、実験用途であれば、とくに購入しなくてもダウンロードして使うことができるという。そこで、これをダウンロードし、インストールするところからはじめていった。
Visual StudioとWDKの環境構築
Visual Studio自体はダウンロードできるとわかったものの、インストールは単純ではなかった。
Visual Studio本体に加え、Windowsドライバを開発するための「Windows Driver Kit(WDK)」、そしてビルドに必要なコンポーネントとして「MSVC v143 - VS 2022 C++ビルドツール」なども追加でインストールしなければならなかったためだ。
インストーラを起動するたびにどのコンポーネントを選べばよいかわからず、ChatGPTに画面のスクリーンショットを見せながら「これでいいか？」と確認しつつ進めていく、という作業の繰り返すことに。
Visual Studioは数GBもある大型アプリで、WDKと合わせるとダウンロードとインストールだけでかなりの時間を要した。
さらにSteinbergのASIO SDKも開発者向けページから入手し、所定の場所に配置する必要がある。「ダウンロードしてインストールするだけ」という話とはまったく別世界の作業量だ。
それでもChatGPTが「次はこれをインストール」「このチェックを入れる」と丁寧に案内してくれるので、なんとか作業を進めていくことができた。
USB Audio Class 2ドライバのビルドから始める
環境がひとまず整ったところで、いよいよビルドに取り掛かる。
まず最初に手をつけたのは、USB Audio Class 2のドライバ本体である「USBAudioAcxDriver」だ。
GitHubからダウンロードしたソースコードの中にあるソリューションファイル(USBAudioAcxDriver.sln)をVisual Studioで開き、ビルドを実行する。
しかし、ここからが試行錯誤の連続となった。
エラーが出るたびにそのスクリーンショットをChatGPTに見せ、対処法を教えてもらい、また次のエラーが出て……という繰り返し。
SDKのパス設定が間違っている、プラットフォームツールセットの指定が合っていない、ヘッダファイルが見つからない……といった問題が次々と出てくる。
一つ解決するとまた別のエラー、というパターンが延々と続いた。
それでも粘り強く進めた結果、トータル3時間近くかかって、ようやくUSBAudioAcxDriverのビルドがなんとか完成した。
ただし、ここで一つ重要なことに気づく。
このUSBAudioAcxDriverはあくまでもUSB Audio Class 2対応のWDMドライバであり、ASIOドライバではない。Windowsで普通にオーディオデバイスとして使えるようになる、という段階にすぎない。
ASIOとして機能させるには、もうひとつ別のコンポーネント「USBAsioDriver」を別途ビルドする必要があるとChatGPTから教えられた。
……ちょっと気が遠くなる感じである。
ASIOドライバのビルドでさらに苦戦
そのUSBAsioDriverのビルドも、やはり手間取ることになった。
先ほど入手したSteinbergのASIO SDKをプロジェクト内の所定の場所に配置し、Visual Studio上で各種パスを設定していくわけだが、バージョンの不一致やヘッダファイルの参照エラーなど、問題が次々と発生した。
「このパスを追加してください」「このファイルをここに置いてください」とChatGPTの指示に従って設定を修正すること数十回。
途中でWindowsを再起動したり、Visual Studioを入れ直したりもしながら、なんとかUSBAsioDriverのビルドにも成功した。
こちらのビルドはUSB Audio Class 2のビルドと比較すれば、少し効率よく進んだ気はするが、それでも1時間以上を費やした。慣れていないからだとは思うが、なかなか大変な作業である。
USBAudioドライバをアクティブ化し、動作確認へ
両方のビルドが完了したところで、いよいよドライバのインストールと動作確認に進む。
まずは、Windowsをいったんテストモードにしたうえで、USBAudioAcxDriverをインストール。
インストールが確認できたら、さらにUSB ASIOドライバをインストールしていく。
ここで手元にあったUSBオーディオインターフェース「Focusrite Scarlett 2i2 4th」をPCにUSBで接続。DAWの「Cubase」を起動し、ASIOドライバの設定を見てみる。するとUSB Asioなるものが追加されていることが確認できた。
「これで大成功！」と思って、選択してみたところ、「オーディオドライバを読み込むことができませんでした」というエラーが出て使えない。
ChatGPTもやや混乱して、変なアドバイスをしだすのだが、落ち着いて考えると、そもそもこのシステムは、USB Class Audio 2.0のドライバとそれをASIO化するドライバの2階建て構造だ。
その1階部分であるUSBAudioAcxDriverが正しく認識されていない可能性がある。
そもそもUSB Audio Class 2のデバイスであれば、普通何もしなくても認識されて音が出る。デバイスマネジャーから確認してみたところ、案の定、いまビルドしたドライバが使われていないことが判明した。
そこで、このデバイスマネジャーでドライバの更新を行ない、先ほどビルドしたUSB Audio Class 2のドライバを選択する。
その結果、Windowsにこのドライバがきちんと認識され、Windowsから再生・録音ができることを確認できた。
まあ、ここまでなら標準ドライバとほぼ何も変わらないわけだが、ここからが本番。ASIOドライバとしての動作確認である。
再度Cubaseを起動し、ASIOドライバ選択画面から、先ほど選んだUSB Audioを選んでみると……今度は問題なく選択することができた。そして、Input1、Input2に加えLoopback1、Loopback2と入力が4系統、Output1、Output2と出力が2系統が確認できた。
実際に再生、録音を行なってみたところ、しっかり動作している。5～6時間かかって、なんとかここまでできたのは感無量だ。
もっとも、同じことはASIO4ALLなどでも実現できるが、ASIO4ALLは非常に不安定だし使い勝手も悪いのが実際のところ。レイテンシーでもあまり性能はよくないので、Windows標準のASIOドライバが登場してくれれば、状況は大きく変わってくるだろう。
コントロールパネルのビルドは断念
動作確認ができたところで、ASIO4ALLと比較して、レイテンシーをどこまで詰められるのかなど試そう、バッファサイズなどの設定を行なうためのASIOコントロールパネルを開こうとした。
ところが、ボタンを押してももまったく反応がない。
理由はすぐにわかった。コントロールパネルアプリ(USBAsioControlPanel)がビルドできていなかったのだ。ドライバ本体とは別に、このコントロールパネルも個別にビルドする必要があったわけだ。
そこで改めてUSBAsioControlPanelのビルドに挑戦したのだが、これが難題だった。
このコンポーネントはWinUIというWindowsのモダンなUIフレームワークを使っており、Visual Studio 2026環境との相性問題が噴出した。
SDKのバージョン問題、プラットフォームツールセットの不一致、Windows Storeアプリとしての依存関係……と、問題が芋づる式に出てくる。
Visual C++のプロジェクトファイルをテキストエディタで修正したりしながら、一つ解決したと思ったら、また別の問題が現れる。
ChatGPTに相談しながらあれこれ対処を続けること2時間近く。それでも最終的にビルドを成功させることはできなかった。今回はコントロールパネルなしの状態でのASIO動作確認にとどめ、この件については継続調査とすることにした。
Windowsが標準でASIO対応する意味
今回の実験を通じて、あらためてこのプロジェクトの持つ意味の大きさを感じた。
現在、ASIOドライバはオーディオインターフェイスメーカーが個別に開発・提供するものであり、安価な製品や一部の海外製品ではASIO非対応のものも少なくない。
しかしUSB Audio Class 2に対応したデバイスであれば汎用のASIOドライバが使えるようになるとしたら、状況は大きく変わる。
GitHubのREADMEには「このドライバおよびその構成コンポーネントはWindowsに搭載される予定」と明記されており、Windows Insider Buildへのプレビュー搭載に向けて準備が進んでいることがうかがえる。
実現すれば、USB Audio Class 2対応デバイスであれば原則としてASIOが使えるようになり、メーカーが専用ドライバを用意していなくても、DAWで利用することが可能になる。また音楽プレーヤーでも高品位に鳴らすことが可能だ。
もっとも、レイテンシーを小さくするなど、各オーディオインターフェイスの性能を100％引き出すためには、専用のドライバが必要になることは今後も変わらないとは思うが、それでもASIOがWindows標準になるとしたら、その意義は大きいはずだ。
まあ、まだGitHubに登録されたソースコードでしかなく、ビルドもされていないので、誰もが使うものではないが、ぜひ近い将来Windows標準搭載になることを期待したい。
個人的にはコントロールパネルの件を含め、引き続き検証を続けつつ、今後のWindows Insider情報にも注目していくつもりだ。
リクルートに15年勤務した後、2004年に有限会社フラクタル・デザインを設立。リクルート在籍時代からMIDI、オーディオ、レコーディング関連の記事を中心に執筆している。以前にはシーケンスソフトの開発やMIDIインターフェイス、パソコン用音源の開発に携わったこともあるため、現在でも、システム周りの知識は深い。 著書に「コンプリートDTMガイドブック」(リットーミュージック)、「できる初音ミク&鏡音リン・レン 」(インプレスジャパン)、「MASTER OF SONAR」(BNN新社)などがある。またブログ型ニュースサイトDTMステーションを運営するほか、All AboutではDTM・デジタルレコーディング担当ガイドも務めている。Twitterは@kenfujimoto。