1.
きっかけ — プロンプト評価から見えた工学的弱点
ハードテクノ楽曲（138 BPM、909キック、JD-800パッド、JUNO-106ベース）のAI生成用プロンプトを多角的に評価した。 美学的指標は軒並み高得点だったが、工学的記述は赤点寄りだった。
プロンプト評価スコア
| コンセプト | 93 / 100 |
| 世界観一貫性 | 91 / 100 |
| 音像指定精度 | 89 / 100 |
| クラブ機能性 | 88 / 100 |
| 音響工学の精度 | 54 / 100 |
| マスタリング素材指示としての有効性 | 61 / 100 |
以下の弱点が確認された:
- —「-8.5 LUFS low-end」— LUFSは全体ラウドネス指標であり、帯域指定ではない
- —低域の帯域分離が未指定
- —サイドチェイン過多の前提条件不足
- —3Dリバーブと低域圧の両立条件なし
- —キックとベースの優先順位が未固定
この評価が「クリエイティブプロンプトと工学的マスタリング仕様は完全に別物」という認識につながった。
2.
現行パイプラインの問題 — 静的マスタリングの限界
現行フローflow
// 旧: Analysis → AI params → DSP
1回分析 → 1回パラメータ決定 → 1回全体処理現行パイプライン評価
| パイプライン総合 | 68 / 100 |
| 静的マスタリング適性 | 81 / 100 |
| 動的マスタリング適性 | 52 / 100 |
最大の問題は、AIコンセンサスが曲全体の代表値に対してDSP値を出していること。 動的マスタリングで重要なのは全曲平均ではなく、セクションごとの局所状態 （intro / verse / build / drop / breakdown / outro） である。
弱点内訳
| トラック全体単一プリセット依存 | 38 / 100 |
| セクション追従性 | 44 / 100 |
| 曲展開追従性 | 49 / 100 |
| 瞬時ラウドネス制御適性 | 57 / 100 |
| ジャンル横断耐性 | 61 / 100 |
3.
設計方針の転換 — 「ノブ出力」から「目標出力」へ
AIが直接DSP値を決める設計を廃止し、AIが時間変化する目標を決めてDSPが追従する設計へ移行する。
新アーキテクチャflow
// 新: Analysis → Section map → Target envelopes → Control layer → DSP
音源分析
↓
Section map（展開構造マッピング）
↓
Target envelopes（時間変化する目標値）
↓
Control layer（目標をDSPへ変換）
↓
Dynamic DSP Render推奨アーキテクチャ評価
| 商用妥当性 | 87 / 100 |
| 動的マスタリング性能 | 84 / 100 |
| スケーラビリティ | 83 / 100 |
| 説明可能性 | 79 / 100 |
4.
音源解析の出力仕様 — 秒ベースから構造ベースへ
Geminiの最適な役割は「いつ何dB」ではなく「なぜその区間が存在するか」を出すこと。 分析AIの役割は「診断書」ではなく「時間軸つきターゲット仕様書」を吐くことにある。
出力方式比較
| 時刻ベース出力 | 58 / 100 |
| 構造ベース出力 | 91 / 100 |
出力の3系統
- 1.曲全体の数値ベースライン — integrated LUFS, true peak, LRA, PSR, crest, stereo width/correlation, mono correlation below 120Hz, 帯域エネルギー比, transient sharpness, harshness/mud/clip risk 等
- 2.展開分析 — form type, section分割, 各sectionの構造的役割, musical function, repeat/variation関係, energy profile, build/release/contrast/resetの判定
- 3.セクションごとの数値 — short-term loudness, PSR, crest, width, 低域バランス, transient, vocal presence, risk profile
最終スキーマ: dynamic_mastering_formplan_v2
schema
track_identity
whole_track_metrics ← 全体数値
whole_track_targets ← 全体目標
whole_track_deltas ← 現状と目標の差分
macro_form ← 展開分析 + セクションごとの数値・目標・保護対象
transition_logic ← 遷移の意味と数値差分
global_mastering_strategy ← 全体方針 + 失敗条件
problems ← 検出された問題（evidenceつき）
confidence ← 各項目の確信度全体数値の必須度
| Integrated LUFS | 100 / 100 |
| True Peak | 100 / 100 |
| Low mono correlation below 120Hz | 96 / 100 |
| Band energy ratios | 95 / 100 |
| PSR / Crest | 94 / 100 |
| LRA | 92 / 100 |
| Harshness / mud / clip risk | 91 / 100 |
| Stereo width / correlation | 90 / 100 |
5.
Geminiに展開分析をやらせる — 5つの必須タスク
Gemini 必須タスク 重要度
| 展開分類（intro/build/drop/break/outro） | 100 / 100 |
| セクションの役割判定（主役drop vs 変奏drop等） | 96 / 100 |
| 遷移の意味判定（盛り上げ/解放/フェイク/引き算） | 94 / 100 |
| セクションごとの保護対象（何を壊してはいけないか） | 92 / 100 |
| 全体のフラット化回避（均一化監視） | 98 / 100 |
Geminiに出力させてはいけないもの
"3.2秒で width +0.14"41 / 100弱い"12.8秒で limiter drive +0.7dB"46 / 100弱い"この小節は少し元気に"28 / 100論外Geminiはサンプル精度制御器ではない。出力は意味のある構造単位・比較可能な状態ラベル・制約と優先度に寄せる。
6.
3モデル並列合議システム（MAGI式）
同じ analysis_json を3モデルに配り、役割を固定し、最終的に別レイヤーで統合する。
合議方式比較
| 3モデル同列多数決 | 62 / 100 |
| 3モデルが直接1つの文を共同生成 | 57 / 100 |
| 3モデル役割固定 + arbiter | 91 / 100 |
役割分担
| モデル | 役割 | 重み | 主担当 |
|---|---|---|---|
| GPT-5.4 Thinking | Engineer | 0.40 | 工学妥当性、LUFS/TP/low-end制約、数値目標の現実性 |
| Claude Opus 4.6 Thinking | Structure Guard | 0.30 | 展開破壊検出、flattening risk、section間矛盾、failure conditions |
| Gemini Pro 3.1 | Form Analyst | 0.30 | 展開理解、section role、transition meaning、動的方針 |
フィールド別責任重み
| フィールド | GPT-5.4 | Claude Opus | Gemini Pro |
|---|---|---|---|
| macro_form | 0.20 | 0.30 | 0.50 |
| whole_track_targets | 0.55 | 0.20 | 0.25 |
| section_targets | 0.40 | 0.20 | 0.40 |
| transition_logic | 0.20 | 0.35 | 0.45 |
| failure_conditions | 0.30 | 0.50 | 0.20 |
7.
Arbiter（議長）の設計
統合は3モデルの誰かではなく、独立したArbiterがやる。Arbiterは意見を持つ存在ではなく、ルールで裁定する存在。
Arbiter方式比較
| モデル1体に統合させる | 58 / 100 |
| 3モデル再討論で統合 | 64 / 100 |
| 専用Arbiterで統合 | 93 / 100 |
| ルールベースArbiter | 95 / 100 |
| 創造的議長 | 57 / 100 |
Arbiterの責務
- 1.Schema validation — 3モデルのJSONが正しいか確認
- 2.Hard constraint filtering — TP違反、mono low-end違反、drop < build、stereo instability等を除外
- 3.Field-wise merge — 数値は重み付き中央値、risksはupper median/max、do_not_damageはunion
- 4.Contradiction detection — whole trackとsection間の矛盾整理
- 5.Minutes generation — 議事録JSON生成
統合ルール
数値項目→ weighted median（平均より安全）リスク→ max or upper-mediando_not_damage→ union（全モデルの保護要求を保持）objective→ 2モデル以上一致を優先、Claudeがflattening指摘時は抑制側に倒す少数意見→ 消さない — unresolved_tensions を最終出力に残す8.
合議議事録の構造化
議事録方式比較
| 合議結果だけ | 78 / 100 |
| 合議結果 + 構造化議事録 | 94 / 100 |
| 自由文議事録 | 67 / 100 |
議事録の6必須項目
| model_positions（各モデルの立場） | 100 / 100 |
| hard_constraint_checks | 98 / 100 |
| discussion_log（争点ログ） | 96 / 100 |
| unresolved_tensions（未解決の緊張） | 95 / 100 |
| resolved_items | 92 / 100 |
| final_rationale | 90 / 100 |
議事録は「チャットログ保存」ではなく「争点ログ保存」とする。論点単位 （
target_integrated_lufs, drop_section_objective, low_end_width_policy 等） で残す。9.
最終フロー
動的マスタリングパイプライン
音源アップロード
バリデーション
音の分析担当AI → analysis_json 作成
whole_track_metrics
macro_form（展開分析）
section metrics / targets
transition_logic
problems
3モデル並列合議
GPT-5.4
Engineer
Claude Opus 4.6
Structure Guard
Gemini Pro 3.1
Form Analyst
Arbiter統合
hard constraint filtering
field-wise weighted merge
contradiction check
minutes generation
mastering_consensus_bundle_v1
consensus_result
consensus_minutes
control_layer_input
Control Layer（目標→DSPパラメータ変換）
Dynamic DSP Render
Post-analysis Verification
出力保存 → ダウンロードURL返却
10.
DSP Engine v2 の工学評価（現状）
DSP Engine v2 評価
| Architecture | 84 / 100 |
| Signal-Flow Design | 81 / 100 |
| Standards Compliance (BS.1770-4 LUFS) | 86 / 100 |
| Oversampled saturation concept | 82 / 100 |
| Multiband crossover accuracy | 44 / 100 |
| Stereo-linked limiting integrity | 49 / 100 |
| Final true-peak safety logic | 54 / 100 |
| Overall DSP engineering | 72 / 100 |
DSP優先修正
- 1._split_4bands を complementary crossover に置換+8〜+12
- 2.Limiter を stereo-linked に+6〜+9
- 3.Final sample-peak trim を oversampled TP safety pass に+3〜+5
- 4.Stage numbering / comments 修正+1〜+2
修正後の天井値: 88 / 100
今後の実装優先度
期待改善値（+スコア）
| 全曲1セットparamsを廃止 | 16 / 20 |
| section-aware mastering | 14 / 20 |
| AI出力を target profile 化 | 12 / 20 |
| control layer 導入 | 11 / 20 |
| マスタリング後の自動再解析→再最適化 | 8 / 20 |
11.
次ステップ — 実装ロードマップ
この投稿で決定した設計方針を実装に落とす。優先度順に記録する。
P1
- 3-model MAGI合議システム実装GPT-5.4 / Claude Opus 4.6 / Gemini Pro 3.1。役割固定（Engineer / Structure Guard / Form Analyst）+ フィールド別重み付き統合。
- consensus_arbiter.py 実装ルールベースmerge: weighted median, risk max, do_not_damage union, contradiction detection, minutes generation。
P2
- control_layer.py 実装formplan targets → セクション別DSPパラメータへの変換レイヤー。AI出力とDSPの橋渡し。
- DSP engine: section-adaptive processing全曲1セットparams廃止 → セクション別params。動的マスタリングの核心部分。
P3
- DSP fix: _split_4bands → complementary Linkwitz-Riley crossover現行の帯域分割をcomplementary crossoverに置換。期待改善: +8〜+12。
- DSP fix: TP Limiter → stereo-linkedステレオリンクリミッタへの変更。期待改善: +6〜+9。
- DSP fix: final safety pass → oversampled true peaksample-peak trimをoversampled true peak safety passへ変更。期待改善: +3〜+5。
P4
- post_verification.py 実装マスタリング後の自動再解析 → 目標との比較 → レポート生成。フィードバックループの完成。
- DSP fix: TPDF dither naming修正HF shaping除去 or rename。命名と実装の不一致を解消。
← Dev Log 一覧次回: consensus_arbiter.py 実装