問題——「魔法の箱」の罠
「このAIで処理したら音が良くなった」——それだけを示すサービスは全員やっている。差別化できない。
問題はもっと根深い。なぜ良くなったのかを説明できないサービスは、 法人エンジニアの信頼を得られない。「魔法の箱」に月額を払うのは個人ユーザーだけだ。 TuneCoreの技術部門が導入判断をするとき、彼らが見るのは音ではなくアーキテクチャだ。
透明性は思想ではなく工学的戦略だ。プロセスを見せることが、そのまま差別化になる。
3層構造の完全公開
aimastering.devのプレイグラウンドは3つの層を順番に見せる。
| Layer | コンポーネント | ユーザーに見せるもの |
|---|---|---|
| 1 | Gemini Scan | 全曲スキャン結果——LUFS・RMS・周波数帯域・セクション構造・ジャンル推定をJSON形式で完全表示 |
| 2 | TRIVIUM | GRAMMATICA / LOGICA / RHETORICA 3者の議論ログと重み付き合議結果（consensus_minutes） |
| 3 | 14-Stage DSP | 各段のパラメータ——LR crossover係数、EQ gain、limiter threshold、dither設定まで全開示 |
Layer 1: Geminiスキャン
GeminiはMP3/WAVを受け取り、dynamic_mastering_formplan_v2 スキーマに従ってJSONを返す。 プレイグラウンドはこのJSONをそのままレンダリングする——隠さない、加工しない。
{
"track_identity": {
"genre": "Club / Techno",
"bpm": 134,
"key": "Am"
},
"whole_track_metrics": {
"integrated_lufs": -14.2,
"dynamic_range_lu": 8.1,
"peak_dbtp": -0.4,
"spectral_balance": { "sub": -2.1, "low": 0.3, "mid": -0.8, "high": 1.1 }
},
"macro_form": {
"sections": [
{ "label": "Intro", "start": 0, "end": 32, "energy": 0.42 },
{ "label": "Drop1", "start": 32, "end": 96, "energy": 0.91 },
{ "label": "Break", "start": 96, "end": 128, "energy": 0.55 }
]
}
}Layer 2: TRIVIUM合議ログ
3エージェントが独立して意見を出し、consensus_arbiter.py がweighted medianで統合する。 合議の議事録（consensus_minutes）はプレイグラウンドに全文表示される。
{
"target_lufs": {
"GRAMMATICA": -9.0,
"LOGICA": -8.5,
"RHETORICA": -8.0,
"consensus": -8.6,
"method": "weighted_median",
"weights": [0.55, 0.25, 0.20]
},
"unresolved_tensions": [
{
"field": "high_shelf_gain",
"GRAMMATICA": "+0.5 dB (ceiling constraint)",
"RHETORICA": "+1.8 dB (presence target)",
"note": "GRAMMATICA veto applied. Final: +0.5 dB"
}
]
}Layer 3: 14段DSP物理演算
Blueprint JSONが確定した後、control_layer.py がセクション別DSPパラメータへ変換し、 14段のDSPエンジンが順番に処理する。プレイグラウンドは各段の入出力を表示する。
| # | Stage | 表示パラメータ |
|---|---|---|
| 01 | DC Offset Removal | offset_db |
| 02 | LR Crossover Split | crossover_hz × 3 (complementary Linkwitz-Riley) |
| 03–06 | Per-Band EQ | gain_db × 4 bands × section |
| 07 | Multiband Compressor | threshold / ratio / attack / release × 4 bands |
| 08 | MS Processing | mid_gain_db / side_gain_db |
| 09 | Stereo Width | width_factor (0.0–2.0) |
| 10 | Harmonic Saturation | drive_db / character (tube|tape|solid) |
| 11 | LR Crossover Merge | merge_gain_db |
| 12 | True Peak Limiter | threshold_dbtp / ceiling_dbtp (stereo-linked) |
| 13 | Oversampled TP Safety | oversample_rate / final_ceiling_dbtp |
| 14 | TPDF Dither | bit_depth / noise_shaping: none |
透明性が営業資料になる
ホワイトラベル交渉で相手が最初に聞くのは「どんなAIを使っているか」ではない。 「なぜこの音になるのか説明できるか」だ。
| 観点 | 魔法の箱型 | 透明なスタジオ型 |
|---|---|---|
| 法人の信頼 | 「良くなった」の主観のみ | アーキテクチャで説明可能 |
| 監査対応 | 不可能 | Blueprint JSON + logs で完全追跡 |
| 導入障壁 | 「中身が分からない」 | 「中身が全部見える」 |
| 差別化 | なし（全員同じ主張） | プロセス自体が固有資産 |
| IP評価 | 低い（ブラックボックス） | 高い（説明可能なパイプライン） |
「透明なスタジオ」宣言
このプレイグラウンドは「体験」を売らない。「工学的プロセスの完全公開」を売る。
Geminiが何を読んだか、TRIVIUMが何を議論し何を否決したか、14段のDSPがどのパラメータで動いたか—— すべてが見える。隠す理由が何もないからではなく、隠すことが最大の弱点になるとわかっているからだ。
透明なスタジオが発するメッセージ：
"Every decision is visible. Every parameter is yours to override."
— すべての判断が見える。すべてのパラメータは、あなたが上書きできる。