LabHub

ブログ

オーディオプラグイン開発 2026 完全ガイド - JUCE 8 / VST3 / AU / AAX / CLAP / iPlug2 / FAUST / Cmajor / Elementary Audio 徹底解説

2026-05-16 · 31 分で読めます · #japanese#audio-plugin#juce#vst3#audio-unit#aax#clap#iplug2#faust#cmajor#elementary-audio#dsp#music-software#deep-dive

한국어English日本語

1. 2026年のオーディオプラグイン開発の景色 — なぜ今が黄金時代か

2026年5月現在、オーディオプラグイン開発はかつてないほど面白い時期にあります。1996年に Steinberg が VST 1.0 を発表してから30年、音楽制作ソフトウェア市場は絶え間なく進化してきました。2020年代後半に入って、新しい潮流が二つ生まれました。CLAP のような真に開かれた標準の登場と、Cmajor や Elementary Audio のように C++ の参入障壁を下げる次世代 DSP 言語/フレームワークの登場です。

2026年の典型的なプラグイン開発者の道具箱はだいたいこんな感じになります。

この記事は、2026年5月時点でそれらすべてを駆け足で見渡すガイドです。シンセを作りたい学生、社内オーディオツールを作らされたシニア、AI オーディオに興味のある ML エンジニア — どの読者にも出発点になるように整理しました。

2. プラグイン形式の比較 — VST3 / AU / AAX / CLAP / LV2

まずプラグインがどんな形式にコンパイルされ、DAW にロードされるのかを整理しましょう。2026年時点で意味のある形式は次の五つです。

VST2 は2018年に新規ライセンス発行を停止しており、2026年現在の新規プラグイン開発には推奨されません。ただし古い DAW プロジェクトとの互換性のために VST2 ビルドオプションを残している会社もまだあります。

CLAP は2026年時点で最も急速に伸びているフォーマットです。Bitwig、Reaper、FL Studio、Studio One がすでにホストとして対応しており、u-he の Diva/Hive/Bazille のような大手シンセが公式 CLAP ビルドを提供しています。純粋な C ヘッダなのでバインディングを書きやすく、ポリフォニックモジュレーションのような表現力では VST3 を超える部分もあります。

形式ライセンスホスト主な強み
VST3GPLv3/独自デュアルすべての主要 DAWシェア最大
AU/AUv3Apple SDK 無償Logic、GarageBand、iOSApple エコシステム
AAXAvid NDAPro Tools映画/放送標準
CLAPMITBitwig、Reaper、FL Studioモジュール式、表現力
LV2ISC/GPLArdour、QtractorLinux ネイティブ

3. JUCE 8 — C++ オーディオ開発の事実上の標準

JUCE は2026年現在、最も広く使われている C++ オーディオフレームワークです。元は Julian Storer の個人プロジェクトから始まり、2014年に Roli、2020年に Sound Devices が買収し、そして2024年10月に Spotify が Sound Devices の JUCE 事業を買収しました。現在は Spotify 傘下のチームがメンテナンスしています。

JUCE 8.x の主要モジュールは以下のとおりです。

プラグイン一個の基本骨格はこのくらいシンプルです。

// PluginProcessor.h - JUCE 8 の最小 AudioProcessor
#pragma once
#include <juce_audio_processors/juce_audio_processors.h>

class MyGainPlugin : public juce::AudioProcessor
{
public:
    MyGainPlugin() : AudioProcessor(BusesProperties()
        .withInput("Input", juce::AudioChannelSet::stereo(), true)
        .withOutput("Output", juce::AudioChannelSet::stereo(), true)) {}

    void prepareToPlay(double sampleRate, int blockSize) override {}
    void releaseResources() override {}

    void processBlock(juce::AudioBuffer<float>& buffer,
                      juce::MidiBuffer& midiMessages) override
    {
        // 最も単純なゲイン処理
        const float gain = 0.5f;
        for (int ch = 0; ch < buffer.getNumChannels(); ++ch)
            buffer.applyGain(ch, 0, buffer.getNumSamples(), gain);
    }

    // ... 残りのボイラープレートは省略
};

ライセンスはデュアルです。AGPL でオープンソースプロジェクトは無償、商用プロジェクトは Personal (個人、売上一定以下)、Indie、Pro の三段階のいずれかで年間ライセンスを購入します。2026年5月時点で Personal は無料、Indie は年約40 USD、Pro は年約800 USD、Education は別ライセンスです。

JUCE の強みはシンプルです。VST3、AU、AAX、CLAP、LV2、Standalone を同一コードでビルドでき、GUI まで一気に解決し、学習資料が最も豊富です。

4. JUCE の AudioProcessorValueTreeState — パラメータの標準パターン

JUCE の本当の価値は単なるビルドシステムではなく、パターン化された API にあります。その中心が AudioProcessorValueTreeState (APVTS) です。APVTS はプラグインのパラメータを ValueTree (XML ツリーに相当) と同期させ、オートメーション/プリセット/UI バインディングを一気に解決します。

// APVTS のパラメータレイアウト定義
juce::AudioProcessorValueTreeState::ParameterLayout createLayout()
{
    using juce::AudioParameterFloat;
    using juce::NormalisableRange;

    std::vector<std::unique_ptr<juce::RangedAudioParameter>> params;

    params.push_back(std::make_unique<AudioParameterFloat>(
        juce::ParameterID{"gain", 1},
        "Gain",
        NormalisableRange<float>(-60.0f, 12.0f, 0.1f),
        0.0f));

    params.push_back(std::make_unique<AudioParameterFloat>(
        juce::ParameterID{"mix", 1},
        "Mix",
        NormalisableRange<float>(0.0f, 1.0f, 0.01f),
        1.0f));

    return { params.begin(), params.end() };
}

GUI とのバインディングは SliderAttachment 一行で終わります。なので新規プラグインを作るときに APVTS パターンに従えば、ホスト側のオートメーションラベル/プリセット保存/UI 更新が自動で解決します。このパターン一つをよく覚えるだけで、JUCE の学習曲線の半分は終わったようなものです。

5. iPlug2 — JUCE の軽量な代替

iPlug2 は Oli Larkin がメンテナを務める OSS の C++ フレームワークです。MIT ライセンスで、VST/AU/AAX/Web Audio Module (WAM) まで対応し、JUCE より軽いコアと自由度の高いライセンスが強みです。

iPlug2 の特徴:

弱点もはっきりしています。学習資料は JUCE ほど豊富ではなく、GUI 作業も JUCE の LookAndFeel ほど標準化されていません。なので「会社がライセンス費を負担しづらく、コードベースの完全な制御が欲しい」なら iPlug2、「素早く出荷したく、学習資料が多い方がいい」なら JUCE という分かれ方になります。

6. DPF (DISTRHO Plugin Framework) — ミニマリストの選択

DPF は ISC ライセンスのミニマリスト C++ フレームワークです。LV2、VST2、VST3、AU、JACK、CLAP まで対応し、コアが非常に小さいのが特徴です。Linux オーディオコミュニティ (Distrho、KXStudio) 発祥なので、LV2 対応は一級です。

DPF の魅力:

DPF は JUCE や iPlug2 ほどの厚いチュートリアルはありませんが、Linux オーディオエコシステムで LV2 プラグインを作るときの事実上の標準です。また GUI がシンプルなエフェクトを作るときの負担が一番軽い選択肢でもあります。

7. FAUST — 関数型 DSP 言語

FAUST はフランスの GRAME 研究所で開発された関数型 DSP 言語です。最大のセールスポイントは、一本の FAUST コードが C++、JavaScript、Rust、WebAssembly、JUCE プラグイン、VST3 まで自動でコンパイルされる点です。

シンプルなゲインエフェクトを FAUST で書くと、こんなに短くなります。

// gain.dsp - FAUST のゲインエフェクト
import("stdfaust.lib");

gain = hslider("Gain", 0, -60, 12, 0.1) : ba.db2linear;
process = *(gain), *(gain);

この一ファイルを faust2juce、faust2webaudiowasm、faust2vst3 のようなビルドスクリプトに通すと、各ターゲットのプラグインコードが自動生成されます。DSP アルゴリズム自体に集中できる点で学界や研究者に人気があり、最近は商用プラグイン会社がプロトタイピングツールとして使うケースも増えています。

ただし FAUST は関数型パラダイムなので学習曲線が急です。C++ しか使ってこなかった開発者が初めて触ると「オーディオ信号が関数合成だって?」とショックを受けます。そのショックを乗り越えると、一度書いた DSP がすべてのプラットフォームへ自動で移植される魔法を体験できます。

8. Cmajor — JUCE チームの次世代オーディオ DSL

Cmajor は JUCE の創始者 Julian Storer が SOUL の後継として作ったオーディオドメイン専用言語です。2023年に公開され、2026年時点でほぼ安定版 1.0 に近づいています。

Cmajor のゴールは明快です。C++ の参入障壁を下げ、JUCE 並みの性能を出し、ホットリロード可能なオーディオ DSL を提供すること。

// Cmajor で書いたシンプルなサイン波オシレータ
processor SineOsc
{
    output stream float out;
    input value float freqHz [[ name: "Frequency", min: 20, max: 20000 ]];

    void main()
    {
        float phase = 0.0f;
        loop
        {
            out <- sin(phase);
            phase += float(twoPi * freqHz / processor.frequency);
            advance();
        }
    }
}

Cmajor の決め手は JIT コンパイルとホットリロードです。JUCE の新しいグラフシステムと組み合わせると、コードを保存した瞬間にプラグインが更新されるワークフローが可能です。これは SOUL 時代から続くビジョンであり、2026年の Cmajor はそのビジョンにほぼ到達しています。

言語自体は独自ライセンスですが、Cmajor は無償配布されており、JUCE 内の一部モジュールとして統合して利用できます。

9. Elementary Audio — JavaScript/TypeScript の挑戦

Elementary Audio は Nick Thompson が作った JavaScript/TypeScript ベースのリアルタイムオーディオフレームワークです。「オーディオグラフを React のように宣言的に記述する」というのが核となるアイデアです。

// Elementary Audio - 宣言的なオーディオグラフ
import { el } from "@elemaudio/core";

const sine = el.cycle(440);
const gained = el.mul(sine, 0.2);
const out = el.add(gained, el.mul(el.cycle(880), 0.05));

core.render(out, out);

Elementary の魅力は次のとおりです。

商用プラグインの中でも Elementary 上に作られるものが増えており、特にブラウザ音楽ツール (ブラウザシンセ、学習アプリ) の領域で急速にシェアを伸ばしています。

10. CLAP 標準を覗く — なぜ皆が注目するのか

CLAP は2022年6月に Bitwig と u-he が公開したオープン標準です。一言でいえば「VST3 が応えなかったところをすべて応える新標準」です。

CLAP の主な特徴:

2026年時点での CLAP ホストは Bitwig Studio、Reaper、FL Studio 21、Studio One 7、Cakewalk など。u-he の Diva/Hive/Zebra、Surge XT、Vital 等が公式 CLAP ビルドを提供しています。Ableton Live と Logic Pro はまだ公式対応していませんが、時間の問題という見方が多いです。

CLAP は JUCE 8 の正式出力ターゲットに含まれているため、同じ JUCE コードベースから VST3/AU/AAX/CLAP/LV2 をすべてビルドできます。

11. AAX と Pro Tools エコシステム

Pro Tools は映画/放送/ポストプロダクションの事実上の標準で、その中で動かすには AAX フォーマットが必須です。AAX SDK は Avid と NDA を結ぶ必要があり、自由に配布できません。

AAX の主な特徴:

JUCE 8 と iPlug2 はいずれも AAX 出力をサポートしますが、AAX SDK のライセンスのため実ビルドには Avid との契約が必要です。映画/放送市場を狙わない会社は、初回出荷時に AAX を外して市場検証後に追加するというパターンが一般的です。

12. DSP 基礎 — FIR / IIR / コンボリューション / FFT

プラグイン開発の半分はフレームワーク、もう半分は信号処理です。DSP の基礎は次の四点に集約されます。

JUCE DSP モジュールはこれら四つをきれいな API で包んでいます。

// JUCE DSP の IIR ローパスフィルタ
#include <juce_dsp/juce_dsp.h>

juce::dsp::IIR::Filter<float> lowpass;
juce::dsp::ProcessSpec spec{ 48000.0, 512, 2 };
lowpass.prepare(spec);
lowpass.coefficients =
    juce::dsp::IIR::Coefficients<float>::makeLowPass(48000.0, 5000.0, 0.7071f);

// オーディオブロックを処理
juce::dsp::AudioBlock<float> block(buffer);
juce::dsp::ProcessContextReplacing<float> ctx(block);
lowpass.process(ctx);

FIR フィルタの長さが伸びると、直接畳み込みより FFT ベースの高速コンボリューションが効率的になります。JUCE の ConvolutionEngine は分割処理を自動で行うため、インパルス応答が数十秒に及んでも実時間動作を保証します。

13. FFT ライブラリ比較 — FFTW / KFR / kissfft / PFFFT

FFT ライブラリはプラグインの性能に直結します。2026年の主な選択肢は次のとおりです。

商用プラグインなら PFFFT か JUCE FFT が一般的な出発点で、極限性能が必要なら FFTW の商用ライセンスか KFR を検討する流れです。

14. SIMD 最適化 — SSE / AVX / NEON

オーディオプラグインは実時間動作が必須で、その性能を引き上げる主役が SIMD です。2026年の主要 SIMD アーキテクチャは次のとおり。

JUCE と KFR は SIMD 抽象化クラスを提供しており、同じコードが SSE と NEON で自動コンパイルされます。直接書く場合は次のようなパターンが一般的です。

// JUCE の SIMDRegister で4チャネル同時処理
juce::dsp::SIMDRegister<float> a, b, result;
a = juce::dsp::SIMDRegister<float>::fromRawArray(input);
b = juce::dsp::SIMDRegister<float>::expand(0.5f);
result = a * b;
result.copyToRawArray(output);

Apple Silicon の M シリーズがプロ用オーディオワークステーションの主流となった今、NEON 最適化は macOS プラグインで必須です。意外にも NEON が AVX 並みに速いケースは多く、M4 の新しい行列命令はコンボリューション高速化の決め手となります。

15. シンセサイザの合成方式 — 6種類整理

シンセプラグインを作りたいなら、まずどの合成方式を採るか決める必要があります。2026年の主要方式は次の六つです。

それぞれ得手不得手が異なります。減算合成はアナログシンセの暖かさを真似、FM は金属的なベル音に強く、ウェーブテーブルは現代的エレクトロニックの標準、グラニュラーはサウンドデザインやテクスチャに強い、物理モデリングはアコースティック楽器の自然さを、スペクトルはノイズリバーブや変形音に光ります。

新規シンセを作るなら、Vital のような現代的なウェーブテーブルシンセを分析するのが最良の出発点です。Vital は OSS で、モジュール式モジュレーションマトリクスの実装が模範的です。

16. コンボリューションリバーブの実装

リバーブはオーディオ永遠の課題です。アルゴリズムリバーブ (Schroeder、Moorer、FDN 等) とコンボリューションリバーブ (IR ベース) の二系統があり、2026年には両者がハイブリッドに結合される流れです。

コンボリューションリバーブの核心は次のとおり。

JUCE の dsp Convolution クラスはこのすべてを自動で扱います。実時間動作のため最初のブロックは時間領域、その後は FFT ベースの分割処理へ自動切替されます。

// JUCE Convolution で IR リバーブ
juce::dsp::Convolution conv;
conv.prepare({48000.0, 512, 2});
conv.loadImpulseResponse(
    juce::File("path/to/impulse.wav"),
    juce::dsp::Convolution::Stereo::yes,
    juce::dsp::Convolution::Trim::yes,
    0);

juce::dsp::AudioBlock<float> block(buffer);
juce::dsp::ProcessContextReplacing<float> ctx(block);
conv.process(ctx);

17. 空間オーディオ — Dolby Atmos / Spatial Audio / Ambisonics / Binaural

2026年の音楽市場で最大の潮流の一つが空間オーディオです。Apple Music の Spatial Audio、Dolby Atmos Music の普及、Tidal/Amazon Music HD のロスレス + 空間チャンネル対応がそれを牽引しています。

主要な標準は次のとおり。

プラグイン開発者の視点では、AAX で Dolby Atmos のベッド/オブジェクトチャンネルを扱う、VST3 のマルチチャンネルバスを対応する、といった作業が増えてきました。JUCE 8 の BusesProperties API は可変チャンネルを自然に表現します。

18. AI オーディオ — Neural Amp Modeler / Magenta / Spear

2026年オーディオで最も熱い領域が AI です。その中心には次のツールがあります。

NAM は特に興味深いです。一時間分のギター + アンプ録音さえあれば、そのアンプの応答をニューラルネットでモデル化し、実時間プラグインとして使えます。Fractal Audio の Axe-Fx、Line 6 の Helix のような企業製品に挑む OSS の動きで、2026年には大量のユーザ作成モデルが共有されています。

# NAM のモデル学習擬似コード (実コードは nam.training)
import nam

# 1. 入力(ドライ) と出力(アンプ出力) のペアを用意
input_wav = "dry_di.wav"
target_wav = "amp_output.wav"

# 2. WaveNet ベースのモデルを学習
model = nam.WaveNet(channels=16, kernel_size=3)
trainer = nam.train.Trainer(model, lr=1e-3)
trainer.fit(input_wav, target_wav, epochs=100)

# 3. .nam ファイルへ書き出し (NAM プラグインが直接ロード)
model.export("my_amp.nam")

19. OSS 学習素材 — Surge XT / Vital / Helm / Dexed / Airwindows

プラグイン開発を学ぶ最良の方法は、よくできた OSS プラグインのコードを読むことです。2026年のおすすめリストは次のとおり。

これらをビルドしてコードを読むと、本一冊読むより早くパターンが身に付きます。特に Surge XT はコードベースが巨大ですがモジュール化が良く、一モジュールずつ取り出して学べます。

20. 韓国と日本のオーディオ開発エコシステム

韓国と日本のオーディオプラグイン/機材産業は規模と性格が大きく異なります。

韓国 は B2C プラグイン会社は少ないものの、ゲームサウンドミドルウェアやモバイルオーディオ SDK の領域が強いです。NHN Cloud のオーディオサービス、NCsoft のサウンドチーム、ウェイメイド/ネクソンのサウンドデザイナがゲーム内のプロシージャルオーディオシステムを作っています。また K-pop 産業の影響で SM/HYBE/JYP 内部に自前のエンジニアリングチームがあり、ポストプロダクションワークフローに独自ツールが組み込まれています。

日本 はハードウェア大国です。Roland (V-Synth、Aira、Cloud)、Yamaha (Vocaloid、Cubase の親会社)、Korg (Wavestate、Opsix) のような会社が30年以上世界標準を作ってきました。ソフトウェア面でも Steinberg (ヤマハ子会社) が VST の本家であり、IK Multimedia の東京 R&D、Native Instruments の東京支社が日本市場と接続します。インディ開発者コミュニティも活発で、KVR Audio の日本掲示板は小規模ながら深さがあります。

両国とも音楽大学やコンピュータ音楽学科の授業が増えており、学生レベルで JUCE や FAUST に触れる事例が急速に増えています。

21. ライセンス費用整理 — 2026年5月現在

商用プラグインを作るなら、ライセンス費用構造を事前に把握しておく必要があります。

コード署名/公証費用も別途必要です。Apple Developer のノタリゼーション、Windows のコード署名証明書が年単位で追加されます。

22. YouTube チャンネルと学習リソース

最後に学習素材を整理します。

これらに加えて Surge XT、Vital、Dexed を自分でビルド/読む、KVR Audio と The Audio Programmer Discord のコミュニティに参加することを並行すれば、1年で出荷可能なプラグインを作れるレベルに到達できます。

23. どこから始めるか — 6つの学習経路

最後に「今始めるならどの道がいいか」を整理します。

どの道でも、6〜12ヶ月以内に最初の成果物が出ます。オーディオプラグイン開発は GUI/DSP/プラットフォーム/ライセンスが絡み合った領域で最初は途方に暮れますが、一度最初のプロジェクトを出荷すれば二回目以降ははるかに速くなります。

2026年のオーディオプラグイン開発エコシステムはかつてないほど豊かで、参入障壁は下がり続けています。CLAP のような真にオープンな標準、Cmajor のような次世代言語、NAM のような AI ツール、Vital/Surge のような模範的 OSS — すべてが今同時に存在する時代です。音楽とコード両方を愛するなら、今が始めるのに最高のタイミングです。

24. おわりに

本記事で扱った道具と標準は、2026年5月現在いずれも活発に進化中です。各々のライセンス、ホスト対応、ビルドシステムは素早く変わるので、最初のプロジェクトを始める前に必ず公式ドキュメントを再確認することを推奨します。

この記事が音楽を愛する開発者の出発線になることを願います。JUCE の最初のビルドを走らせる瞬間、自分の作ったシンセから最初のサイン波が鳴る瞬間 — それが私たちがこの道に入った理由であることを忘れずにいてください。

25. 参考資料 (References)

コメント

まだコメントはありません。

ログインするとコメントできます