Geminiの回答から始める
「音楽のマスタリングサービス」とGeminiに入力した。返ってきた回答は整理されていた—— LANDR、eMastered、CloudBounce、BandLab Mastering、iZotope Ozone、Waves。 さらにSterling SoundやAbbey Road Studiosへのオンライン発注という選択肢も。
Geminiの回答は正確だ。これらは2026年現在の主要サービスを正しく列挙している。 だからこそ価値がある——aimastering.devが「何ではないか」を正確に示している。
aimastering.devはGeminiのどの層にも入っていない。これは市場未参入だからではなく、問題の定義が違うからだ。
競合の分類——すべては「変換器」だ
Geminiが挙げた全サービスに共通する構造がある。それは変換器(Transformer)であること—— 入力音声 f(x) を何らかの写像によって出力音声 g(x) に変換する関数として動作する。
| サービス | 変換のメカニズム | 意思決定の主体 |
|---|---|---|
| LANDR | 学習済みモデルによるジャンル別マッピング | 単一モデル(ブラックボックス) |
| eMastered | リファレンス曲への近似変換 | 単一モデル + リファレンス入力 |
| CloudBounce | ジャンル別プリセットの適用 | プリセット選択(ユーザー) |
| BandLab | 汎用AIモデルによるラウドネス正規化 | 単一モデル(固定) |
| iZotope Ozone | AIアシスタント + 手動パラメータ調整 | AIアシスタント + エンジニア |
| Waves | プリセット型オンライン処理 | プリセット選択(ユーザー) |
意思決定の主体は常に単一だ。「複数の評価主体が対立し、合議する」というプロセスは どのサービスにも存在しない。これは実装の省略ではなく、問題の設定が違う。
変換器の構造的限界
変換器モデルが優れていないということではない。LANDRのモデル精度は高く、iZotope Ozone 12は現在のデファクトスタンダードだ。 しかし変換器には構造的に解決不可能な問題がある。
単一モデルが出力する「最適化」は、訓練データの平均に向かう。10,000曲を最適化すれば10,000曲が似た音になる。これはモデルの精度が上がるほど深刻になる——精度が高いほど、出力は平均に近づく。
マスタリングに「正しいLUFS値」は存在しない。ジャンル・プラットフォーム・アーティストの意図・聴取環境によって正解は変わる。単一モデルはこの多変量問題をスカラー出力に圧縮するしかない。
エンジニアが「このサビのトランジェントは絶対に潰すな」と指定したい場合、変換器には渡せる接点がない。iZotopeのAIアシスタントは補助であり、最終的な判断は人間が手動で上書きする。
「議論プロセス」という別の問題定義
aimastering.devが解こうとしている問題は「音声を最適な状態に変換する」ではない。「3つの相反する正解の間で、どの解が最もトレードオフを最小化するかを合議で決定する」だ。
| 変換器モデル | 議論プロセスモデル | |
|---|---|---|
| 問題の定義 | f(audio) → optimized_audio | argmax Nash(G, L, R) |
| 意思決定の構造 | 単一モデルの出力 | 3エージェントの合議(TRIVIUM) |
| 拒否権 | なし | あり(do_not_damageリスト) |
| 金太郎飴耐性 | なし(平均への収束) | あり(ナッシュ均衡の多様性) |
| プロの介入点 | 出力後の手動上書き | Blueprint JSON直接編集 |
| 出力形式 | 音声ファイル | 時間変化する仕様書 → DSP駆動 |
この差異を「aimastering.devの方が優れている」と主張したいわけではない。 これらは異なる問題を解いている。 競合するカテゴリではなく、別の問題空間に存在する。
横断比較表
| サービス | モデル種別 | 合議 | 拒否権 | Blueprint | 動的ターゲット |
|---|---|---|---|---|---|
| LANDR | 変換器 | × | × | × | × |
| eMastered | 変換器 | × | × | × | × |
| CloudBounce | 変換器 | × | × | × | × |
| BandLab | 変換器 | × | × | × | × |
| iZotope Ozone | AI補助+手動 | × | △(手動) | × | × |
| Waves | プリセット | × | × | × | × |
| aimastering.dev | 議論プロセス | ◯ | ◯ | ◯ | ◯ |
aimastering.devの位置
Geminiの3層分類に戻る——AI自動・プラグイン・人間エンジニア。 aimastering.devはどこにも入らない。
複数の評価主体(TRIVIUM)が合議してBlueprint JSONを生成し、 その仕様書に従ってクラウドDSPエンジンが音を描画する。 「自動マスタリング」でも「人間の補助ツール」でもなく、「AIが議論して書いた設計図を、物理演算で実現するレンダラー」だ。
この定義の正しさは、Geminiが誰も言及しなかったことで証明される。 既存カテゴリに収まるサービスなら、Geminiはとっくに名前を挙げている。
競合が来たとき何が起きるか
LANDRやiZotopeが合議モデルを実装しようとしたとき、何が起きるか。
数百万ユーザーが「LANDRはこういう音がする」という期待を持っている。合議モデルを導入すれば出力の多様性が上がり、既存ユーザーの期待を裏切るリスクがある。後発優位が働く。
Ozoneはプラグインとして動作する。3エージェントの合議をDAW内でリアルタイム実行するには、API設計が根本から変わる。既存アーキテクチャへの後付けは極めて困難だ。
GRAMMATICA / LOGICA / RHETORICAという役割定義と合議プロトコルは、このブログで先に公開されている。後から参入するサービスは「aimastering.devの模倣」と見なされるリスクを負う。