The Conductor Pattern -Multi-Granularity Feedback for Creative Agents-

2026/09/11 AGNTCon + MCPCon Japan登壇資料
https://agntconmcpconjapan26.sched.com/event/2QlDs/the-conductor-pattern-multi-granularity-feedback-for-creative-agents-yusuke-shibui-mlopsllmopsagentops-community?iframe=no

Transcript

1. 人間とコラボレーションする作曲エージェントシステム 信号 The Conductor Pattern Multi-Granularity Feedback for Creative Agents Yusuke Shibui 2026/09/11
2. 自己紹介 shibui yusuke — Senior AI/ML Architect / Field CTO LLM に聞いてみた 経歴 猫のようで サイズは犬 いろいろ → Stability AI → LayerX → Snowflake 現職 Senior AI/ML Architect / Field CTO 活動 MLOps コミュニティ運営 リンク GitHub @shibuiwilliam · Facebook yusuke.shibui · X @cv_usk 猫耳メガネ 本日の登壇内容は私個人の意見であり、所属企業を代表するものではありません。 YouAndOrchestra · github.com/shibuiwilliam/YouAndOrchestra 02
3. 著書 新刊 『LLM・AI エージェントシステム ベストプラクティス』 翔泳社刊 · 2026年8月20日発売！ 過去の著作も発売中 amazon.co.jp 03
4. 前提 Human-in-the-loop は成功を定義できると仮定する AI Agentに対する”都合の良い”成功の定義 通るテスト グリーンな CI 構造化された評価 assert output == expected。 二値・事前・明確。 マージ前に通るか落ちるかが決ま るゲートの連なり。 ルーブリック、ゴールデンセット、閾 値を引けるスコア。 仕様が“好み”だったら？ 好みは結果を聴く前に書きだせない。視聴して初めて現れ、聴くうちに変わっていく。 YouAndOrchestra · github.com/shibuiwilliam/YouAndOrchestra 04
5. 問いの立て直し 好みは反応する仕様であり、固定された仕様ではない 事前に仕様化できない 「聴けば分かる」 目標は候補が出て初めて考えられる。 反応によって現れる 設計課題 判断を自動化しようとせずに、 どうすれば人間を判断の座に 留められるか？ 聴くたびに自分が本当に欲しかったものを知る。 仕様が自ら更新される。 Human-in-the-loop driven agentic composition 文脈的で個人的 ゴールデンセットはない。 同じ節も、ある曲では正解、次の曲では不正解になる。 音楽にユニットテストはない。 耳だけが唯一の正解。 好み＝仕様の理想的なストレステスト。 05
6. YaO とは何か Agentic Music Composition on Claude Code YouAndOrchestra github.com/shibuiwilliam/YouAndOrchestra 入力は自然言語。出力はフルスコア。 1 2 3 4 自然言語 7体のエージェント スコア＋ステム 来歴の記録 「物憂げなピアノ、雨の夕暮 れ」 役割分担したサブエージェ ントが曲を設計する MIDI · WAV · MusicXML 6軸評価 すべての音に存在理由を記 録 7 34 6 ≤3 役割型サブエージェント 敵対的批評ルール 評価ディメンション 閾値到達までの自動反復 06
7. 補足 · 仕様の三本柱 意図・仕様・時間を、別々のファイルに分ける なぜ分けるのか 一枚のプロンプトに混ぜると感情だけ直し たいのに全て変わってしまう。 意図は原点として残す intent.md がフィードバックの判断基準。 ループが迷ったらここに戻る。 仕様は差分で追える YAML なので git diff が効く。何を変えたの かを人間が読める。 パターン 01 の一段目 「仕様を書き直す」編集が安いのは、この 分離があるから。 07
8. 補足 · 時間軸トラジェクトリ 同じ編成でも感情の曲線を変えれば別の曲になる 時間を先に決める 音符より先に曲線を決める。設計原則 「時間軸ファースト」 編成を触らずに変える 楽器はそのままに、曲線だけ差し替え られる。 機械が測れる形にする 密度もダイナミクスも数値なので、評価 軸として検査できる。 好みが乗るところ どこを山にするかは結局は人間の判 断。曲線が編集点になる。 08
9. 音楽制作のマルチエージェントシステム 7体の役割型サブエージェント プロデューサー 作曲家 和声理論家 エージェント統括、衝突の解決 旋律・モチーフ・主題展開 進行・終止・転調 リズム設計者 オーケストレーター ミックスエンジニア ドラムパターン・グルーヴ・シン コペーション 楽器選択・ボイシング・音域分 離 バランス・空間・音量・マスキン グ 敵対的批評者 役割は実際のスタジオに対応する。 作曲家が向き合うのはモデルではなく、名前を持つ理解可能な専門家たち。 サブエージェント分割により、誰に反論すべきかを明確化。 作品をレビューする 07
10. 曲はどう作られるか 切り分ける：何を弾くか／どう弾くか PLAN（計画） — 構成・和声・モチーフ・グルーヴ・編成をエージェントが決める 構成プランナー 和声プランナー 作曲家 ドラム設計 オーケストレーター 聴取シミュレータ 評価器 批評ゲート 34 の敵対的ルールを実行しレビュー REALIZE（実体化） — 承認された計画を具体的な音符として配置し作曲する ノート実体化 演奏表現 レンダラー 計画は読み書きできるドキュメント。 作曲家は音符を手で編集するのではなく、意図のレベルで介入する。 08
11. 好みを機械検査する代理指標 6つの参考的評価軸 20% 25% 20% 構成 旋律 和声 セクション対比・形式・リズムの多様性 音域・輪郭・主題は回帰するか 協和度・声部進行の滑らかさ 20% 10% 5% 美的 アレンジ 音響 意外性・記憶しやすさ・展開 テクスチャの多様性・音域分離 スペクトルバランス・ LUFS 準拠 ジャンル対応の重み付け。 ドラムミュージックはリズム寄りに、アンビエント音楽は対比ペナルティを外す。 09
12. 反復する段階的サブエージェント 3つの協働パターン データとしてのスコア 01 三段階フィードバック 02 コンダクターループ＋批評ゲート 03 信頼の基盤としての来歴 粒度そのものが UX である 生成 → 評価 → 適応 追記のみの因果グラフ 10
13. パターン 01 · 三段階フィードバック 合わせる：編集の粒度を思考の粒度に 曲全体 1 セクション 小節 · 拍 · 楽器 仕様を書き直す セクションを再生成 音符にピン留め YAML を編集。キー、テンポ、ムード、楽 器。意図から再計画する。 サビだけを引き直す。主題の再現が一 貫性を保つ。 「ここは詰め込みすぎ」のように、スコア 上の正確な座標にフィードバックを紐づ ける。 edit composition.yaml /regenerate-section chorus /pin --loc bar:3,beat:2 難しいのは編集ではなく、人間が正しい程度を選ぶのを助けること。 粗すぎれば良い仕事を失い、細かすぎればマイクロマネジメントになる。 段階的セレクタ こそがプロダクト。 11
14. 補足 · CLI ワークフロー 対話でスケッチし、ループして、部分的に直す 入口は対話 音楽知識ゼロでも、 6ターンの質問に答 えれば仕様ができあがる。 ループは1コマンド /conduct が生成・評価・適応を回す。人 間は結果を待つ。 粒度がコマンドに出ている 全体か、セクションか、 1音か。段階セ レクタが CLI になっている。 規律はファイルで持つ CLAUDE.md の不可侵ルールが、エー ジェントの逸脱を止める。 14
15. パターン 02 · 批評ゲート付きコンダクターループ 生成 → 評価 → 適応 → 再生成——音を置く前にゲートで評価。 生成 ゲートが先に来る 34 の敵対的批評者が計画を検査し、弱い構成・ありがちな進 行・フックの不在を却下する。 ループはアイデアを音符に落とす反復を無駄にしない。 適応 コンダクター ≤ 3× 評価 なぜ 3 回で打ち切るのか？ 自動スコアはすぐ頭打ちになる。数回と繰り返すと、伸びるの は指標ではなく好みとなる。 ループは代理指標を過剰最適化せず、人間に戻す。 再生成 12
16. パターン 03 · 信頼の基盤としての来歴 すべての音が存在理由を持つ。 /explain 「なぜサビは平行短調へ転調した？」 仕様 ムード：「ほろ苦い高揚」 計画 構成プランナー：サビ ＝ 感情のピーク 決定 和声理論家：高揚のあとの痛みのため平行短調を借用 音符 実体化：共通音 D を保って G→Em をボイシング Append-only 因果グラフ 信頼は主張ではなく監査対象 出力を鵜呑みにせず問いただす。 反対意見に宛先を用意 「いや、長調のままで」が曲全体ではなく、正確 な決定ノードに届く。 好みは教えられるもの どのレバーが結果を動かしたかをグラフで判 別。次の編集は好み情報に基づく。 13
17. 補足 · 来歴レコード 1音ごとに、誰が・なぜ・何を追加し捨てたかが残る 「なぜ」が必ず付く 音の1つ1つに、どのエージェントがどう 判断したかが紐づく。 捨てた案も見える 採らなかった候補が残るので、別解を 名指しで指定し直せる。 書き換えられない Append-Only。後から差分の原因を必 ず追える。 反対意見の宛先になる 「そこは長調で」が曲全体ではなくこの 1 レコードに着地する。 17
18. 音楽を超えて 仕様が判断であるかぎりパターンは通用する 三段階フィードバック 思考の粒度に合った編集の粒度を人間に与える。 全体設定、コンポーネント単位の引き直し、あるいはピン留めして局所修正。 批評ゲート付きループ 高価な実体化の前に、計画へ安価な敵対的チェック。 代理指標に過剰適合する前に反復を打ち切る。 来歴グラフ 自動化された決定をすべて問い合わせ可能にする。 信頼は監査され、反対意見には宛先ができる。 設計原則：エージェントは作曲家ではなく環境。人間の創造性を加速するが、判断を置き換えはしない。 14
19. まとめ 判断の視座は 人間のもの。 好みが仕様なら、事前の仕様化ではなく反応のために設計する。 フィードバックに粒度の階段を。段階セレクタこそが本当の UX。 安価な計画を敵対者でゲートし、指標に過剰適合する前にループを止める。 すべての決定を問い合わせ可能に——来歴は主張ではなく信頼を獲得する方法だ。 オープンソース： github.com/shibuiwilliam/YouAndOrchestra 15