AIコーディングエージェントでVST3・CLAPプラグインを作る方法

エージェントがオーディオプラグインを誤る理由

慣れない C++ ライブラリでエージェントが拒否することはまれで、代わりに即興で書いてしまいます。オーディオプラグインは、即興を次の3つの形で罰します。

1. 作り出された名前。 CompressorPro のような存在すべきクラス、あるいは別のフレームワークのメソッドを割り当てられた実在のクラス。コードは完璧に読めますが、コンパイルできません。
2. コンパイルは通るが誤っているコード。 process() 内でのメモリ確保やロック。process() はオーディオスレッドで実行されます。開発者のマシンでは動いても、誰かのセッションで負荷がかかると途切れます。
3. API のどこにも書かれていない規則。 レイテンシを報告しないルックアヘッドリミッターは、それが入っているすべての並列ミックスのタイミングをずらします。バージョン1.1 で並べ替えられたパラメータテーブルは、古いセッションを間違ったコントロールに読み込みます。どちらのことも、ヘッダーには何も書かれていません。

最初の問題は名前に、2つ目は動作に、3つ目は規則に関するものです。より大きなモデルはどれにも役立ちません。必要な情報が学習データに、信頼できるほど確実には含まれていないからです。

エージェントに必要なもの

3つが必要です。それぞれが上の失敗モードのひとつに答えます。

3つすべては、同じスクリプトによって SDK のヘッダーから生成されています。これは思う以上に重要です。エージェント向けの手書きの早見表は、リリースごとにコードから乖離し、そうなると第二の架空の名前の源になります。ここでは、ファイルがヘッダーと食い違うと npm run verify:llms がビルドを失敗させ、npm run verify:mcp が検索がすべての公開型を見つけることを確認します。そのため、サーバーからの「一致なし」は、インデックスの穴ではなく、本当の答えになります。

MCP サーバーの6つのツール

サーバーはローカルのチェックアウトから stdio で動作し、必要なのは Node.js だけです。すべてのツールは、チェックアウト内のファイルを読むだけです。

違いの例です。CompressorPro を尋ねると、サーバーは SDK に一致するものがないと答えます。「ladder filter」を尋ねると、LadderFilter と、ダイオードラダーを、それらが存在するヘッダーとともに返します。エージェントは最初ではなく、2番目を書きます。

セットアップ

SDK をクローンし、エージェントにスキルとサーバーを追加します。Claude Code の場合は次のとおりです。

git clone https://github.com/SonorieAI/sonore-sdk "$HOME/sonore-sdk"
npx skills add SonorieAI/sonore-sdk --skill sonore-sdk -a claude-code -g
claude mcp add --scope user sonore-sdk -- node "$HOME/sonore-sdk/scripts/mcp-server.mjs"

Codex は -a codex と codex mcp add を使います。Cursor と Antigravity は -a cursor または -a antigravity でスキルを入れ、MCP 設定ファイルにサーバーを設定します。ホームページのスキルと MCP をインストールボタンに、それぞれの正確なコマンドがあります。skills コマンドラインツールがなくても、skills/sonore-sdk をエージェントのスキルフォルダにコピーすれば同じことができます。

うまく動く最初のプロンプト

プラグインを具体的に指定し、「完了」が何を意味するかを伝えます。

Make a tape-style saturator plugin with Drive, Tone and Mix.
Start from a generated Sonore project. Look up every sonore:: name
before you use it. It is done when it builds, ctest passes, and
clap-validator and pluginval run clean.

スキルを読み込んだ状態なら、エージェントは SDK のワークフローに従って自分で進めます。sonore_new_plugin.cmake で生成されたプロジェクトを作り、DSP を1つの src/plugin.cpp に書き、名前を確認しながら進めてビルドします。1つのソースファイルから、.clap、.vst3、macOS 上の Audio Unit、LV2 バンドル、スタンドアロンアプリが生成され、同じプロジェクトで iPhone と iPad 向けの AUv3 と Android アプリもビルドされます。

「完了」とは何か

コンパイルできるプラグインは下書きにすぎません。生成されたプロジェクトは、エージェントが順に取り組むべき3つのチェックを提供します。証明できる内容の重要度順です。

1. ビルドが通る。 1回のコンパイルからすべてのフォーマットをビルドします。
2. ctest が通る。 2つのテストを実行します。スタンドアロンアプリの --verify はオフラインでオーディオをレンダリングし、正常であることを確認します。SDK のチェックアウトからビルドされたプロジェクトでは、リアルタイム監査（sonore_add_rt_test）が、サンプルレートとブロックサイズを横断して、オーディオスレッドで行われたすべてのメモリ確保を数え、ひとつでもあれば失敗します。SDK 自身のサンプルも同じ基準に従います。8 kHz から 384 kHz までの9つのサンプルレート、1 から 8192 までのブロックサイズで、確保はゼロです。
3. バリデータが通る。 clap-validator と pluginval は、ホストと同じ方法でプラグインを読み込みます。両方のプロジェクトテンプレートは、生成されたままの状態で pluginval の厳格度10を通ります。そのため、失敗はエージェントが持ち込んだものだとわかります。

監査とバリデータは、コードを読むだけでは捉えられないものを捕まえます。だからこそ、プロンプトに含める価値があります。

人間が担当する部分

適切なツールを持つエージェントは、読み込めて、検証を通り、オーディオスレッドでメモリ確保をしないプラグインを書きます。しかし、そのサチュレーターの音が良いか、インターフェースがセッション内で自然に感じられるか、あなたが気にするホストが正しく動くかは判断できません。聴くこと、趣味、自分の DAW でのテストは、あなたの仕事として残ります。ゲートキーパーが絡むフォーマットも同様です。AAX には Avid の開発者契約と PACE による署名が必要で、どのフレームワークもこれを与えることはできません。

エージェントを使わない手順版は、はじめにをお読みください。Sonore SDK が JUCE、iPlug2 などとどう比べられるかは、オーディオプラグイン・フレームワークの比較をご覧ください。

出典

• Sonore SDK リポジトリ：README の「Writing plugins with a coding agent」セクション、llms.txt、scripts/mcp-server.mjs
• sonore-sdk スキル
• Model Context Protocol 仕様
• Agent Skills 形式
• llms.txt の規約