ものがたり
戻る

AAP 1.0 Preview Post Mortem (ja)

7月にAAP 1.0 Previewと銘打って主にAAP v0.11.1とUAPMD v0.5.0、それと10本近いAAPプラグインをGoogle Play Storeにリリースしてから2ヶ月ほど経過して、いろいろなフィードバックをコミュニティから受けるようになってきました。それらを受けて、開発者として、AAPやUAPMDのスタンス・位置付け・役割について、ちゃんと表明しておいたほうが良さそうだと思うようになってきたので、今回はAAP 1.0 Previewリリースのpost mortemとしてそれらをまとめようと思います。

AAP ecosystemに対する要求と対応ポリシーの概要

現状、ユーザーフィードバックとしてAAPに寄せられている不満・要改善点としては、次のようなものがあります:

どれも「対応するつもりはない」ものですが、それにはそれぞれ理由があります。箇条書きにするとこんな感じです:

公開フォーマットとしてのAAP

公開フォーマットの意義

AAPは任意のホストと任意のプラグインを組み合わせて利用できる仕組みです。これはAvid AAX、FL Studio Native PluginsやReaper JSFXといった、特定のベンダーの製品でしか利用できないプラグインフォーマットとは異なります（JSFXはysfxというプロジェクトのコードを使うと誰でもホストを作れて、実際に筆者もUAPMDに取り込んでいるのですが、ここでは特定ベンダー用という枠組みに入れます）。

一方で、AAPはVST3やLV2やCLAPとは異なり、純粋なAPIだけで実現しているプラグインフォーマットではありません。aap-coreというGitHubリポジトリで公開されているモジュールを使用してプラグインやホストを作ることになります。これはAudioUnitに近い位置付けといえます。ただしAAP本体はAudioUnitの実装を含むプロプライエタリなmacOSとは異なり、全体がMITライセンスで公開されています。

AAPバージョン1.0はこの方向性で突き進むことになる予定です。AAP2が設計される頃にはホスト側も純粋なAPIとIDLだけになっているかもしれません。筆者はどのフォーマットも20年は続かないと思っています（VST3は名目上は本稿執筆時点で19年続いていることになるのですが、2018年までは空気だったというべきでしょう）。

公開プラグインフォーマットは制約を広汎に強制できない

現状、Androidで動作するDAWでは、任意のプラグインフォーマットに対応しようとするものがありません。モバイルプラットフォームは制約が強く、たとえば画面全体を覆うようなプラグインをDAWの上に表示できてしまうとUXが損なわれます。

特定の画面サイズを指定して、そのサイズに収まるようにプラグインを作らせることは、ルールとしては策定できます。しかし後でプラグインの節で言及しますが「プラグイン開発はアーティスティックな仕事」であり、「Android向けに個別にプラグインを作ってくれる開発者はいない」のです。独自の制約が多ければ多いほど、それに準拠してもらうというのは無理があります。

Androidにおける公開フォーマットの課題はプロセス分離と配布可能性

Androidで利用するために作られたAAPにとって、最大の特徴はプラグインを任意のAPKとして配布する方式で自由なプラグイン開発を実現できていることです。

これは、Google Play Storeでは任意のネイティブコードを動的にロードするアプリケーションの配布が禁止されていて、Androidプラットフォーム（Google Play Storeを介さないエコシステム）でも出処不明な動的ライブラリのロードは抑圧されつつあるというのが一因です。それが許されているなら、インプロセスでメモリ空間を共有できない他のAPKに依存する必要はないのです。

そしてDSPをリアルタイムセーフに構築できる言語ランタイムは非常に限られており、一般論としては同じことをJavaScriptで出来るわけではありません。この制約を回避するには、DSPに目的が特化したオーディオDSL（Reaper JSFXやCmajorなど）が必要です。Androidの場合は実行時にJITコンパイルできるのでiOSよりは可能性があるといえます。ただし、C++でネイティブに書かれたプラグインよりは自由度がはるかに低いでしょう（たとえばNAMプラグインやSFZサンプラーを「FAUSTで」「Cmajorで」実装することを考えてみてください）。

WebAssemblyはこの点ではまだ可能性がある技術です。WebAssemblyとWeb UIで構築されたプラグインであれば、純粋にホストプロセスだけでロードして実行できるでしょう。WebCLAPはまさにこれを実現しているものといえます。Web Audio APIが独立プロセスで動作するAudioWorkletの仕組みを強制するため、GUIとDSPの分離は必須になっています。ただし、Web UIを使用したプラグインはまだ多くなく、開発もJavaScriptランタイムとの相互運用を意識しなければならず（あるいはJUCEのようなSDKがそれを吸収するのであれば、そのAPIの制約のもとでしかコーディングできず）、一般的なプラグイン開発に比べると少し面倒ではあります。WebCLAPをサポートするプラグインも現状では実験的なものしかありません。

AAP「プラグイン」

プラグイン開発はアーティスティックな仕事

オーディオプラグインは、（広い意味での）シンセサイザーのコードをプラグインフォーマットに繋ぎ込むことで成り立っているソフトウェアです。そのDSPのほとんどは、外部入力としてはオーディオ入出力とMIDI入力だけで実現できるもので、特定のプラグインフォーマットの機能だけに最適化されたプラグイン製品というのは多くありません。VST3でもAUでもLV2でも、何ならReaper JSFXでも出来るものがほとんどです。そこにGUIが付属しますが、GUIが無くても入力をもとに演奏できるように作られています。GUIもクロスプラットフォームなソースコードで作られていることが多いです（ビルドされたバイナリはクロスプラットフォームではないのが一般的です）。

シンセサイザー製品には、そのエンジン部分をどう構築するか、オーディオやMIDIの（あるいはそれに類する）入力をどう加工するか、パラメーターとして何を用意するか、それらがどのようにDSPに影響を与えるか、そしてどのようなプリセットを用意するか、といった様々な設計要素があります。オーディオプラグイン開発は「楽器を作る」という創作の側面が大きく、それは単純なコーディング技術力の問題だけではない、アーティスティックな選択に基づく仕事といえます。

これは非常に属人的なもので、Androidで同等の機能を有するプラグインフォーマットのAPIを用意したからといって、Androidアプリ開発者が似たようなプラグインを開発できる、といった性質のものではありません。特定の製品1つくらいなら出来るかもしれませんが、世の中には無数のオーディオプラグイン製品があって、それぞれが特徴をもっています。それらを全て再実装するのは現実的ではありません。今ある楽器は、なるべくそのまま使えることの意義が大きいのです。

aap-juce: AAPエコシステムのゲートウェイ

幸いなことに、今オーディオプラグイン製品の開発において大きなシェアを占めているJUCEは、プラットフォームとしてはAndroidをサポートしています。AAPはこれをAndroid用のプラグインとしてビルドする仕組みをaap-juceとして用意しています。

CLAPのエコシステムがclap-juce-extensionsを提供することでJUCEのエコシステムを取り込んだように、AAPはaap-juceを提供することでJUCEのエコシステムを取り込んでいます。

AAPコミュニティが、JUCEを特別に優遇することはありません。しかしiPlug2やDPFといった他のプラグインSDKはAndroidを（特にGUIで）サポートしていないので、AAPにとっての選択肢におけるJUCEの比率は限りなく高いものです。AAPプロジェクトで移植されているプラグインの大部分がJUCEに由来するのはこのためです。

AAPにはLV2プラグインをそのままに近いかたちで取り込めるAAP-LV2というプロジェクトも含まれていますが、これはGUIを取り込むには至っていません。LV2はデスクトップ用のプラグインフォーマットであり、Android用のGUIはAPIとしても用意されておらず、プラグインもAndroidで使えるGUIを用意しているものはありません。JUCEプラグインでもそうですが、WebViewを使うプラグインも、あくまでデスクトップ ネイティブのGUIとして動作させるコードであるにすぎません。

オリジナルソースを可能な限り修正せずに使う

AAPへのプラグインの移植は、開発者が維持可能であることを意識して行われています。移植もののプラグインは、本家で開発されるコードを継続的に取り込めることが重要です。継続的に本家の変更を取り込めなくなった移植は古くなり、オリジナルと互換性の無いサウンドが増えて、ユーザー体験が損なわれることになります。

そのため、オリジナルをなるべく維持して、変更は最小限に抑えるかたちで移植を維持することになります。「モバイルではこうしたほうが使いやすい」という思いつきで細かい改善を加えていくと、本家の変更に追従できなくなります。筆者は、これは分散システムにおけるCAP定理のようなもので、オリジナルの維持・モバイルの最適化・両プロジェクトの独立性を維持した高速な進化、の3つは併存し得ない願望だと考えています。

JUCEはAndroidをそれなりに尊重してユーザビリティを改善していますが、モバイルプラットフォームに最適化されているとは言い難いですし、プラグイン開発者はAndroidをターゲットプラットフォームとは思っていません。何しろ共通のプラグインフォーマットが存在しないので、プラグイン市場と言えるものが存在しないのです。存在しない市場に向けて製品をリリースしてほしいというのは無理があるので、AAPはまず誰でも利用できて自由に参入もできるエコシステムの構築を目指しています。

サポートできる数には限りがある

AAP 1.0 Previewをリリースしてから一番よく聞いたリクエストが「Vitalは無いのか?」というものです。Vitalをサポートできない理由は個別に2つあります。

あとVitalは重いのであまりモバイル向きではないという話もあります。デスクトップでも割と重いわけですが、多機能でモダンなシンセなので当然だと思います。ただそれを理由に移植しないというほど強い理由ではないです（重いという話ならOB-Xfなんかもだいぶ重いです）。

あとVitalはProjucerが主流だった時代に作られていて（公開されたのはCMakeサポートされたJUCE 6.0.x時代ですが）、移植のメンテナンスコストが高いので、よほど意味のあるプラグインでなければサポートできません。どちらかというとProjucerのプロジェクトをサポートしている理由の大きな1つがVitalだったのですが（もう1つがHelio Sequencer）、そろそろProjucerサポートは切り捨てるかもしれません。

AAPエコシステム開発の作業の少なからぬ部分がビルドマネジメントでした。この状況はClaude CodeやCodexにメンテナンス作業や移植作業を肩代わりさせることでだいぶ軽減されていますが、それでも自分のメンテナンス作業が必要であることに変わりはありません。むしろこれまで無視していたPlay Storeリリースなどの作業などが発生することもあって、状況が悪化している部分もあります。atsushienoがサポートできるプラグインの数には限りがあります。

AAP「ホスト」

UAPMD: シーケンサーエンジンのPoCプロジェクト

まず、UAPMDは「MIDI 2.0ネイティブなシーケンサーエンジン」であり、エンドユーザー向けに”UAPMD”というアプリケーションとして表に見えているものはuapmd-appというuapmdのproof-of-conceptとしての「デモアプリケーション」です。さらに、uapmd-appはdesktop firstで作られているものであり、Androidにはデスクトップで編集した楽曲を「再生」したり微調整程度の最低限の編集をサポートする程度の想定で作られています。

これをCompose firstで作ったものがuapmd-kmpというKotlinバインディングと、uapmd-appの機能をほぼ移植しているuapmd-cmpというアプリケーションで、ComposeのUIはAndroidに最適化されているので、たとえばImGuiでは想定されていない「プラグインリストのウィンドウでプラグインリストをドラッグするとスクロールする」みたいな操作が自然に実装されています。ImGuiではリストがスクロールする代わりにプラグインリストのウィンドウが移動します(!)

とはいえ、proof-of-conceptアプリの移植は、やはりproof-of-conceptでしかありません。基本的には「AndroidでもAAPを使えばこのくらいの機能をもつDAWをこのくらいの性能で実現できる」みたいなデモンストレーション目的で作られています。

逆に、UAPMDでは単に「複数トラックの演奏がチープな音源でも可能なDAW」を目指して作っているわけではありません。それはサウンドフォントのような過去の技術を使えばすぐ出来ることです。また、オープンではないDAWの仕組みを用いて固有の制限のもとで実現することも、目的としていません。それはある意味JSFXのサポートによってすでに実現しています。ただしそれは「DTMerが普段からデスクトップで使っているような楽器を使ったDTMをAndroidでも出来るようにしたい」という目的からは、だいぶ離れたものになってしまいます。

greenhouse: プラグインホスト

UAPMDが作られるまで、AAPのエコシステムには長いことPoCとしてまともに機能するプラグインホストが不在でした。各プラグインのAPKに含まれるMainActivityはJetpack Composeで作られた動作確認用のものであり、さまざまな音作りを体験できたり、ましてや楽曲制作に活用できる性質のものではありませんでした。UAPMDは、外部からSMFやオーディオファイルを引っ張り込んでトラックに配置して、そこにプラグインを割り当てて音作りができる仕組みであり、楽曲を再生できるところまでは立証していますが、それ以上のユーザー体験が良いものとはいえませんし、前述の通りそれを主要な目的にしているわけではありません。

この穴をうまく埋めてくれているのが、AAPコミュニティで作られているgreenhouseというプラグインホストです。1つのインストゥルメントと複数のエフェクトを直列的に繋いでMIDIキーボードで演奏でき、それぞれのプラグインについてはGUIを表示できてパラメーターとプリセットを操作できるという、シンプルながら十分にそれぞれのプラグインを使った音作りを体験できるホストになっています。

aap-juce-helio: JUCEプラグインホストの利用可能性

aap-juceは、clap-juce-extensionsとは異なり、プラグインホストの開発をサポートするjuce_audio_plugin_clientのAAP実装であるaap_audio_plugin_clientも公開しています。ホストとはDAW側のコードのことであり、オープンソースのDAWで特にJUCEを使用しているものはごく限られています…というのが2025年までの状況だったのですが、実はこの辺はAI codingの時代になって大きく変わりつつあります。UAPMDもその類型といえるのですが、OSSとしてDAWを雑に作って公開するプロジェクトが増えてきました。とはいえ、JUCEあるいはより具体的にTracktion Engineを使ったDAWは、まともに機能するものを探すのも手間なので、とりあえずは概ね無視しておくことにします。2027年にはまた状況が変わっていることでしょう。

そういうわけで、従来通りのやり方で、オープンソースでJUCEを使っているDAWはほとんど無かったのですが、Helio Sequencerはその数少ない1つだったので、aap-juceの応用例として古くから統合したものをaap-juce-helioとして作っていました。今年になってAAPプラグインのGUIサポートも含め、いろいろ安定性を向上させるまでは使い物にならなかったのですが、現在では「落ちる」ような問題はOOM Killer以外ではそんなに出なくなり、あくまで「オリジナルから手を加えていないAndroidビルドにAAPのホスティングを統合したもの」としては十分に使えるものになったと思います。

とはいえ、そもそも本家もAndroidビルドは「サポートしているもの」というわけではなく、特別にユーザビリティが考慮されているわけではありません。そして現状ではUAPMDほど多くのトラックを演奏できてはいません。ただこのDAWはそこまで動作検証しているわけではなく、あくまでデフォルトで上がってくるシーケンスにプラグインを割り当てて確認している程度です。

Tracktion Engineをもとに構築されたDAWの移植として試しに作ってみたaap-juce-magdaは、本体の問題なのかTracktion Engineの問題なのかわかりませんがHelio Sequencer以上に十分なパフォーマンスが出ないようなので、現状では選択肢として上がってこないと思います。

JUCEを使ったモバイル用のプラグインホストやDAWが開発されれば、AAPはその有用性を高める基盤技術のひとつとなるでしょう。既存のDAWが自動的にmobile friendlyな製品となるかどうかは、また別の話です。

総括

というわけで、冒頭に書いた通り、AAPやUAPMDのスタンス・位置付け・役割についてまとめました。AAPもUAPMDも、それなりに合理的な理由に基づいて技術選択・市場選択をしています。この辺の状況はAAPエコシステムのadoptionやAIコーディングによるプロダクト開発の進化といった外部的な要因によって変わってくることもあるかもしれませんが、AAP 1.0リリースまでは概ねこの方向性で進むことでしょう。

この記事を共有:
Hatenaで共有 Blueskyで共有 Mastodonで共有
次の記事
Undoable Activities (8月の開発記録/2026)