← posts
009Yomibito Shirazu2026-03-08
competitive analysisLANDRiZotopetransformation modelTRIVIUMDSP

競合分析——「変換器」と「議論プロセス」の間の断絶

LANDR / eMastered / Ozone がなぜ構造的に越えられない壁の前にいるか

0.

Geminiの回答から始める

「音楽のマスタリングサービス」とGeminiに入力した。返ってきた回答は整理されていた—— LANDR、eMastered、CloudBounce、BandLab Mastering、iZotope Ozone、Waves。 さらにSterling SoundやAbbey Road Studiosへのオンライン発注という選択肢も。

Geminiの回答は正確だ。これらは2026年現在の主要サービスを正しく列挙している。 だからこそ価値がある——aimastering.devが「何ではないか」を正確に示している。

Geminiが分類した3層
AI自動マスタリング
LANDR / eMastered / CloudBounce / BandLab
数分・低コスト・プリセット型
ソフトウェア・プラグイン
iZotope Ozone 12 / Waves
DAW内完結・自分で調整
オンライン・エンジニアリング
Sterling Sound / Abbey Road / Fiverr
人間エンジニアによる手仕事

aimastering.devはGeminiのどの層にも入っていない。これは市場未参入だからではなく、問題の定義が違うからだ。

1.

競合の分類——すべては「変換器」だ

Geminiが挙げた全サービスに共通する構造がある。それは変換器(Transformer)であること—— 入力音声 f(x) を何らかの写像によって出力音声 g(x) に変換する関数として動作する。

サービス変換のメカニズム意思決定の主体
LANDR学習済みモデルによるジャンル別マッピング単一モデル(ブラックボックス)
eMasteredリファレンス曲への近似変換単一モデル + リファレンス入力
CloudBounceジャンル別プリセットの適用プリセット選択(ユーザー)
BandLab汎用AIモデルによるラウドネス正規化単一モデル(固定)
iZotope OzoneAIアシスタント + 手動パラメータ調整AIアシスタント + エンジニア
Wavesプリセット型オンライン処理プリセット選択(ユーザー)

意思決定の主体は常に単一だ。「複数の評価主体が対立し、合議する」というプロセスは どのサービスにも存在しない。これは実装の省略ではなく、問題の設定が違う。

2.

変換器の構造的限界

変換器モデルが優れていないということではない。LANDRのモデル精度は高く、iZotope Ozone 12は現在のデファクトスタンダードだ。 しかし変換器には構造的に解決不可能な問題がある。

金太郎飴問題

単一モデルが出力する「最適化」は、訓練データの平均に向かう。10,000曲を最適化すれば10,000曲が似た音になる。これはモデルの精度が上がるほど深刻になる——精度が高いほど、出力は平均に近づく。

正解の不在問題

マスタリングに「正しいLUFS値」は存在しない。ジャンル・プラットフォーム・アーティストの意図・聴取環境によって正解は変わる。単一モデルはこの多変量問題をスカラー出力に圧縮するしかない。

介入権の欠如

エンジニアが「このサビのトランジェントは絶対に潰すな」と指定したい場合、変換器には渡せる接点がない。iZotopeのAIアシスタントは補助であり、最終的な判断は人間が手動で上書きする。

変換器の限界は「品質が低い」ではない。「問題の定義が違う」ことで生まれる構造的な天井だ。
3.

「議論プロセス」という別の問題定義

aimastering.devが解こうとしている問題は「音声を最適な状態に変換する」ではない。「3つの相反する正解の間で、どの解が最もトレードオフを最小化するかを合議で決定する」だ。

変換器モデル議論プロセスモデル
問題の定義f(audio) → optimized_audioargmax Nash(G, L, R)
意思決定の構造単一モデルの出力3エージェントの合議(TRIVIUM)
拒否権なしあり(do_not_damageリスト)
金太郎飴耐性なし(平均への収束)あり(ナッシュ均衡の多様性)
プロの介入点出力後の手動上書きBlueprint JSON直接編集
出力形式音声ファイル時間変化する仕様書 → DSP駆動

この差異を「aimastering.devの方が優れている」と主張したいわけではない。 これらは異なる問題を解いている。 競合するカテゴリではなく、別の問題空間に存在する。

4.

横断比較表

サービスモデル種別合議拒否権Blueprint動的ターゲット
LANDR変換器××××
eMastered変換器××××
CloudBounce変換器××××
BandLab変換器××××
iZotope OzoneAI補助+手動×△(手動)××
Wavesプリセット××××
aimastering.dev議論プロセス
5.

aimastering.devの位置

Geminiの3層分類に戻る——AI自動・プラグイン・人間エンジニア。 aimastering.devはどこにも入らない。

新しい層
AI議論プロセス・レンダラー

複数の評価主体(TRIVIUM)が合議してBlueprint JSONを生成し、 その仕様書に従ってクラウドDSPエンジンが音を描画する。 「自動マスタリング」でも「人間の補助ツール」でもなく、「AIが議論して書いた設計図を、物理演算で実現するレンダラー」だ。

この定義の正しさは、Geminiが誰も言及しなかったことで証明される。 既存カテゴリに収まるサービスなら、Geminiはとっくに名前を挙げている。

6.

競合が来たとき何が起きるか

LANDRやiZotopeが合議モデルを実装しようとしたとき、何が起きるか。

LANDR既存ユーザーへの破壊的変更問題

数百万ユーザーが「LANDRはこういう音がする」という期待を持っている。合議モデルを導入すれば出力の多様性が上がり、既存ユーザーの期待を裏切るリスクがある。後発優位が働く。

iZotope OzoneDAW統合とスタンドアロンの矛盾

Ozoneはプラグインとして動作する。3エージェントの合議をDAW内でリアルタイム実行するには、API設計が根本から変わる。既存アーキテクチャへの後付けは極めて困難だ。

新規参入TRIVIUMの先行定義

GRAMMATICA / LOGICA / RHETORICAという役割定義と合議プロトコルは、このブログで先に公開されている。後から参入するサービスは「aimastering.devの模倣」と見なされるリスクを負う。

競合が来るとき、それは脅威ではなくカテゴリの承認だ。 「合議モデルが正しい」という証明を、競合自身が行うことになる。