Algorithm Music Dev Log

議長不在の設計判断

「議長（Arbiter）を置く」という誘惑は常にある。複数の意見が衝突したとき、誰かに「まとめさせよう」とするのは自然な発想だ。しかしそれをした瞬間、議長役AIの「好み」や「平均値への引力」が働き始める。

aimastering.devのTRIVIUMが議長不在なのは、それが美学的選択ではなく工学的必然だからだ。議長を置いた設計が最終的に行き着く先は常に「標準的な設定への回帰」——つまり金太郎飴だ。

議長がいると「迷ったら標準に寄せる」バイアスが必ず発生する。議長不在で均衡点を探る場合、全エージェントが「これ以上譲れない」ラインをぶつけ合い、その交点にしか解が存在しない。これが曲の個性を殺さない唯一の構造だ。

例えばAgent A（Engineer）が「この低域は物理的にクリップする」と主張し、Agent C（Artist）が「この煌びやかさは譲れない」と押し返す場合——議長がいなければ「両方をギリギリまで両立させる極限のポイント」を探しに行く。それが「曲の限界を引き出す」ということだ。

議長不在の合議が数学的に正しい根拠は、ゲーム理論のナッシュ均衡にある。各エージェントが「他のエージェントの戦略を所与として、自分の戦略を一方的に変えても利得が改善しない」状態——それが均衡点だ。

Nash Product

Consensus = argmax_p ∏_i∈{A,B,C} U_i(p)

U_i は各エージェントの効用関数、p はDSPパラメータセット。積を最大化することで、どのエージェントも一方的に逸脱しない唯一の解が導かれる。これが拒否権の数学的根拠だ。

各エージェントは独立した評価軸と「許容できるエラーの範囲（コスト関数）」を持つ。3つの制約条件が重なる領域の中で積が最大になる点が、14-Stage DSPへ流し込まれる最終パラメータになる。

TRIVIUMも同じ構造だ。3つのエージェントが独立して評価し、その「ジレンマ（葛藤）」そのものが出力になる。「議長が選ぶ」のではなく、「3つの知能がぶつかり合った結果残った唯一の解」がDSPに流し込まれる。

議長不在のTRIVIUM合議は高度な設計だが、プロのエンジニアにとってそれすら「一つの意見」に過ぎない。プロが最も求めるのは合議結果の正しさではなく、「自分の意図が介在できること」だ。

「アホなAI」のサービスが抱える最大の問題は、ユーザーを「何もわからない素人」として扱い、すべてをブラックボックスに閉じ込めることだ。プロはブラックボックスを信頼しない。

プロのエンジニアにとって「自動化」は敵ではない。「介入できない自動化」が敵だ。

Geminiが解析した結果（Blueprint JSON）をそのまま受け取り、ローカルで数値を微調整してから再投入できる——この「パラメータ注入（Parameter Injection）」こそが、プロが$299を払う理由になる。

Blueprint JSONはGeminiの全曲スキャン結果を人間（とプロ）が読める形式にまとめた「設計図」だ。このJSONがTRIVIUM合議への入力にもなり、プロがバイパスする際の直接入力にもなる。

このJSONはTRIVIUM合議の入力スキーマでもある。通常フローではGeminiが自動生成するが、エキスパートモードではユーザーがこのJSONを手書き・編集して直接渡す。TRIVIUMをバイパスしてDSPエンジンを直接駆動できる。

解析と描画を分離することで、「自動マスタリング」と「クラウド型DSPレンダラー」を同一のAPIで提供できる。通常ユーザーはフルオート、プロはステージを分けて使う。

blueprint=@blueprint.json を渡した場合、TRIVIUMの合議フェーズをスキップし、提供されたBlueprintを直接ControlLayerへ送る。これがParameter Injectionの実装形だ。

この2ステージAPI設計は、単なる「エンドポイントの追加」ではない。サービスの自己定義を変える。

Before

自動マスタリングサービス

After

クラウド型DSPレンダラー

開発者として伝えたいことは一文に収まる：

"Own the engine. The blueprint is yours."

— エンジンを手に入れろ。設計図はあなたのものだ。