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 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. 仮説とモチベーション 音楽の意図・仕様・時間を言語化する Research Question 音楽は音符で表現される。 音符は自然言語同様に書き方のルールに従って論理的かつ感性的に 構成できるので、コーディングエージェントで執筆できるのでは？ 07
5. 前提 Human-in-the-loop は成功を定義できると仮定する AI Agentに対する”都合の良い”成功の定義 通るテスト グリーンな CI 構造化された評価 assert output == expected。 二値・事前・明確。 マージ前に通るか落ちるかが決ま るゲートの連なり。 ルーブリック、ゴールデンセット、閾 値を引けるスコア。 仕様が“好み”だったら？ 好みは結果を聴く前に書きだせない。視聴して初めて現れ、聴くうちに変わっていく。 YouAndOrchestra · github.com/shibuiwilliam/YouAndOrchestra 04
6. 問いの立て直し 好みは反応する仕様であり、固定された仕様ではない 事前に仕様化できない 「聴けば分かる」 目標は候補が出て初めて考えられる。 反応によって現れる 設計課題 判断を自動化しようとせずに、 どうすれば人間を判断の座に 留められるか？ 聴くたびに自分が本当に欲しかったものを知る。 仕様が自ら更新される。 Human-in-the-loop driven agentic composition 文脈的で個人的 ゴールデンセットはない。 同じ節も、ある曲では正解、次の曲では不正解になる。 音楽にユニットテストはない。 耳だけが唯一の正解。 好み＝仕様の理想的なストレステスト。 05
7. YaO とは何か Agentic Music Composition on Claude Code Skills YouAndOrchestra (YaO) github.com/shibuiwilliam/YouAndOrchestra 入力は自然言語。出力はフルスコアと音楽。 1 2 3 4 自然言語 7体のエージェント スコア＋ステム 来歴の記録 「物憂げなピアノ、雨の夕暮 れ」 役割分担したサブエージェ ントが曲を設計する MIDI · WAV · MusicXML 6軸評価 すべての音に存在理由を記 録 7 34 6 ≤3 役割型サブエージェント 敵対的批評ルール 評価ディメンション 閾値到達までの自動反復 06
8. 補足 · 仕様の三本柱 意図・仕様・時間を、別々のファイルに分ける なぜ分けるのか 一枚のプロンプトに混ぜると感情だけ直し たいのに全て変わってしまう。 意図は原点として残す intent.md がフィードバックの判断基準。 ループが迷ったらここに戻る。 仕様は差分で追える YAML なので git diff が効く。何を変えたの かを人間が読める。 パターン 01 の一段目 「仕様を書き直す」編集が安いのは、この 分離があるから。 07
9. 補足 · 仕様の三本柱 INTENT.md # Intent: Puzzle Light A playful, light-hearted 30-second loop for a puzzle game. Bright mallet instruments (glockenspiel, marimba) carry interlocking melodic patterns over gentle piano chords and soft drums. Minimalist, curious, unobtrusive — designed for repeated listening without fatigue. ## Emotional Core - Playful, curious, light-hearted - Never tense or dark - Maintains engagement without demanding attention ## Listening Context - Puzzle game background music - Repeated listening over extended play sessions - Must not become annoying or fatiguing ## Sound World - Toy-like, crystalline mallet timbres - Bright, major-key harmony - Minimalist interlocking patterns - Soft, brushed percussion 07
10. 補足 · 仕様の三本柱 COMPOSITION.yaml title: "Puzzle Light" genre: "game" tonal_system: kind: tonal_major_minor key: "C" mode: "major" tempo_bpm: 90 time_signature: "4/4" total_bars: 11 loopable: true instruments: - name: glockenspiel role: melody density_factor: 0.6 techniques: [staccato, bell_tone] - name: marimba role: counter_melody density_factor: 0.5 techniques: [ostinato, arpeggiated] - name: piano role: harmony density_factor: 0.4 techniques: [arpeggiated, block_chord] - name: drums role: rhythm density_factor: 0.3 techniques: [brushes, light_shaker] sections: - name: section_a bars: 4 dynamics: "mp" - name: section_b bars: 4 dynamics: "mf" - name: section_a_prime bars: 3 dynamics: "mp" constraints: - type: must scope: global rule: "glockenspiel carries a simple 2-bar melodic motif" - type: must_not scope: global rule: "dark or tense harmonies" - type: prefer scope: global rule: "stepwise melodic motion in glockenspiel" generation: strategy: stochastic seed: 42 temperature: 0.4 07
11. 補足 · 仕様の三本柱 TRAJECTORY.yaml title: "Puzzle Light" description: "Gentle arc for a puzzle game loop — mild peak in section B, seamless return" waypoints: - section: section_a bar: 1 tension: 0.3 density: 0.4 energy: 0.35 description: "Glockenspiel motif enters with light piano. Marimba joins bar 2." climax: section: section_b bar: 6 description: "Fullest moment — all instruments active, but still light and unobtrusive" loop_point: enabled: true crossfade_bars: 0.5 description: "section_a_prime tail connects seamlessly back to section_a" - section: section_b bar: 5 tension: 0.5 density: 0.6 energy: 0.55 description: "All four instruments active. Marimba counter-rhythm. Mild peak." - section: section_a_prime bar: 9 tension: 0.25 density: 0.35 energy: 0.3 description: "Thins out. Drums to shaker only. Piano simplifies. Prepares loop return." 07
12. 補足 · 時間軸トラジェクトリ 同じ編成でも感情の曲線を変えれば別の曲になる 時間を先に決める 音符より先に曲線を決める。設計原則 「時間軸ファースト」 編成を触らずに変える 楽器はそのままに、曲線だけ差し替え られる。 機械が測れる形にする 密度もダイナミクスも数値なので、評価 軸として検査できる。 好みが乗るところ どこを山にするかは結局は人間の判 断。曲線が編集点になる。 08
13. 音楽制作のマルチエージェントシステム 7体の役割型サブエージェント プロデューサー 作曲家 和声理論家 エージェント統括、衝突の解決 旋律・モチーフ・主題展開 進行・終止・転調 リズム設計者 オーケストレーター ミックスエンジニア ドラムパターン・グルーヴ・シン コペーション 楽器選択・ボイシング・音域分 離 バランス・空間・音量・マスキン グ 敵対的批評者 役割は実際のスタジオに対応する。 作曲家が向き合うのはモデルではなく、名前を持つ理解可能な専門家たち。 サブエージェント分割により、誰に反論すべきかを明確化。 作品をレビューする 07
14. 曲はどう作られるか 切り分ける：何を弾くか／どう弾くか PLAN（計画） — 構成・和声・モチーフ・グルーヴ・編成をエージェントが決める 構成プランナー 和声プランナー 作曲家 ドラム設計 オーケストレーター 聴取シミュレータ 評価器 批評ゲート 34 の敵対的ルールを実行しレビュー REALIZE（実体化） — 承認された計画を具体的な音符として配置し作曲する ノート実体化 演奏表現 レンダラー 計画は読み書きできるドキュメント。 作曲家は音符を手で編集するのではなく、意図のレベルで介入する。 08
15. 好みを機械検査する代理指標 6つの評価軸と割合（参考） 20% 25% 20% 構成 旋律 和声 セクション対比・形式・リズムの多様性 音域・輪郭・主題は回帰するか 協和度・声部進行の滑らかさ 20% 10% 5% 美的 アレンジ 音響 意外性・記憶しやすさ・展開 テクスチャの多様性・音域分離 スペクトルバランス・ LUFS 準拠 ジャンル対応の重み付け。 ドラムミュージックはリズム寄りに、アンビエント音楽は対比ペナルティを外す。 09
16. 反復する段階的サブエージェント 3つのコラボレーションパターン データとしてのスコア 01 三段階フィードバック 02 コンダクターループ＋批評ゲート 03 信頼の基盤としての来歴 粒度そのものが UX である 生成 → 評価 → 適応 追記のみの因果グラフ 10
17. パターン 01 · 三段階フィードバック 合わせる：編集の粒度を思考の粒度に 曲全体 1 セクション 小節 · 拍 · 楽器 仕様を書き直す セクションを再生成 音符にピン留め YAML を編集。キー、テンポ、ムード、楽 器。意図から再計画する。 サビだけを引き直す。主題の再現が一 貫性を保つ。 「ここは詰め込みすぎ」のように、スコア 上の正確な座標にフィードバックを紐づ ける。 edit composition.yaml /regenerate-section chorus /pin --loc bar:3,beat:2 難しいのは編集ではなく、人間が正しい程度を選ぶのを助けること。 粗すぎれば良い仕事を失い、細かすぎればマイクロマネジメントになる。 段階的セレクタ こそがプロダクト。 11
18. 補足 · CLI ワークフロー 対話でスケッチし、ループで部分的に直す 入口は対話 音楽知識ゼロでも、 6ターンの質問に答 えれば仕様ができあがる。 ループは1コマンド /conduct が生成・評価・適応を回す。人 間は結果を待つ。 粒度がコマンドに出ている 全体か、セクションか、 1音か。段階セ レクタが CLI になっている。 規律はファイルで持つ CLAUDE.md の不可侵ルールが、エー ジェントの逸脱を止める。 14
19. パターン 02 · 批評ゲート付きコンダクターループ 生成 → 評価 → 適応 → 再生成——音を置く前にゲートで評価。 生成 ゲートが先に来る 34 の敵対的批評者が計画を検査し、弱い構成・ありがちな進 行・フックの不在を却下する。 ループはアイデアを音符に落とす反復を無駄にしない。 適応 コンダクター ≤ 3× 評価 なぜ 3 回で打ち切るのか？ 自動スコアはすぐ頭打ちになる。数回と繰り返すと、伸びるの は指標ではなく好みとなる。 ループは代理指標を過剰最適化せず、人間に戻す。 再生成 12
20. パターン 03 · 信頼の基盤としての来歴 すべての音が存在理由を持つ。 /explain 「なぜサビは平行短調へ転調した？」 仕様 ムード：「ほろ苦い高揚」 計画 構成プランナー：サビ ＝ 感情のピーク 決定 和声理論家：高揚のあとの痛みのため平行短調を借用 音符 実体化：共通音 D を保って G→Em をボイシング Append-only 因果グラフ 信頼は主張ではなく監査対象 出力を鵜呑みにせず問いただす。 反対意見に宛先を用意 「いや、長調のままで」が曲全体ではなく、正確 な決定ノードに届く。 好みは教えられるもの どのレバーが結果を動かしたかをグラフで判 別。次の編集は好み情報に基づく。 13
21. 補足 · 来歴レコード 1音ごとに誰が・なぜ・何を追加し捨てたかが残る 「なぜ」が必ず付く 音の1つ1つに、どのエージェントがどう 判断したかが紐づく。 捨てた案も見える 採らなかった候補が残るので、別解を 名指しで指定し直せる。 書き換えられない Append-Only。後から差分の原因を必 ず追える。 反対意見の宛先になる 「そこは長調で」が曲全体ではなくこの 1 レコードに着地する。 17
22. 音楽を超えて 仕様が判断であるかぎり作曲以外でもパターンは通用する 三段階フィードバック 思考の粒度に合った編集の粒度を人間に与える。 全体設定、コンポーネント単位の引き直し、あるいはピン留めして局所修正。 批評ゲート付きループ 高価な実体化の前に、計画へ安価な敵対的チェック。 代理指標に過剰適合する前に反復を打ち切る。 来歴グラフ 自動化された決定をすべて問い合わせ可能にする。 信頼は監査され、反対意見には宛先ができる。 設計原則：エージェントは作曲家ではなく環境。 人間の創造性を加速するが、判断を置き換えはしない。 14
23. まとめ 判断の視座は 人間 好みが仕様なら、事前の仕様化ではなく反応のために設計する。 フィードバックに粒度の階段を。段階セレクタこそが本当の UX。 安価な計画を敵対者でゲートし、指標に過剰適合する前にループを止める。 すべての決定を問い合わせ可能に——来歴は主張ではなく信頼を獲得する方法だ。 オープンソース： github.com/shibuiwilliam/YouAndOrchestra 15