Foundation Modelsの歌声によせて 〜 オンデバイス推論から聞こえてくる自動作曲の可能性

https://fortee.jp/iosdc-japan-2026/proposal/a14a0584-f65f-433d-83b2-5a2176d8fe27

sample app source code > https://github.com/log5r/fm-melody-sandbox-app

Transcript

1. Foundation Modelsの 歌声によせて 〜 オンデバイス推論から聞こえてくる自動作曲の可能性 log5 / iOSDC Japan 2026 log5 @ iOSDC Japan 2026
2. 突然ですが、クイズの時間です
3. どれがFoundation Modelsの曲? a 画像制作: Ch tGPT
4. どれがFoundation Modelsの曲? これから3つの音楽が流れるので、Foundation Models が ”作曲”した音楽を当てよう！ a 画像制作: Ch tGPT
5. どれがFoundation Modelsの曲? これから3つの音楽が流れるので、Foundation Models が ”作曲”した音楽を当てよう！ 1. Found tion Models由来の曲 (正解) 2. 乱択アルゴリズム由来の曲 (不正解) 3. 私(log5)が人力で作った曲（絶対アカン） 注: 機械的な作曲においては音楽理論に基づく後処理が入っているよ！ a a 画像制作: Ch tGPT
6. A
7. B
8. C
9. 正解は…
10. 正解は… セッションの途中で！
11. Foundation Modelsに よる自動作曲 の可能性 本日のテーマ
12. お品書き Agenda 1. 自動作曲の要点 2. Found tion Modelsの基礎 3. LLM×作曲の設計論 a 4. まとめと展望
13. そもそも「作曲」とは?
14. そもそも「作曲」とは? • 音響の集合をいい感じに作り、組織化すること • 音響: 音量 + ピッチ + 長さ + 音色 + 空間的位置 + 反響
15. そもそも「作曲」とは? • 音響の集合をいい感じに作り、組織化すること • 音響: 音量 + ピッチ + 長さ + 音色 + 空間的位置 + 反響 • いまひとつピンと来ない…
16. そもそも「作曲」とは? • 音響の集合をいい感じに作り、組織化すること • 音響: 音量 + ピッチ + 長さ + 音色 + 空間的位置 + 反響 • いまひとつピンと来ない… • 例: 大衆音楽（ポップス）の場合、何を決めれば音楽になるか？
17. 大衆音楽を構成するもの ざっくりまとめ 1. メロディ —— ドレミの並び 2. コード —— 音の重なり 3. リズム —— いつ鳴らすか 4. 構成 ——Aメロ / Bメロ / サビなど (一般に大衆音楽の場合) • それ以外（歌詞・歌声・音色など）
18. 「自動作曲」とは？ ここでの定義 • 創造的な行為の延長として、特定の曲想や条件から音楽を生成する仕組みを指す • 以下については、今回は「創造的な行為」の対象から外し、自動作曲には含めない • 事前に決められた音楽を自動的に演奏すること • 乱数のみに依拠して演奏すること • 例: モーツァルトの「音楽のサイコロ遊び」（Musik lisches Würfelspiel, K516f） • 自然現象のみに依拠して演奏すること • 例: エオリアン・ハープ（風の力で音を鳴らす楽器） a 注: 上記で自動作曲に含めなかったものに創造性がないという意味ではありません
19. 自動作曲の2つの流派 • 記号表現の生成 • 指示の配列。楽譜を作るようなもの。(MIDI等・数KB) • 信号表現の生成 • 音そのものを作る(波形・数MB〜) a a • 例: M gent 系 / MusicGen・Suno系
20. iPhoneの土俵は「記号的生成」 • 信号生成: St bility AI と Arm 等での実例はあるが、GPUサーバ級の計算量が欲しくなる • 記号生成: 概ねテキストと数値の列 → 3Bモデルの守備範囲 a • 楽譜はAIが書き、音はiOSが鳴らす
21. Foundation Models フレームワーク 本日の主役 • Apple Intelligenceの言語モデルをアプリから直接利用 • OS標準 —— モデル同梱不要 • API課金なし • 完全オンデバイス = オフラインで動く
22. Foundation Models フレームワーク 約3Bパラメータのモデル • 約30億パラメータ / 2bit量子化 • 得意なこと: 要約・分類・短い構造化生成 • 不得意なこと: 長文の一貫性・複雑な推論・算数
23. Foundation Models の使い方 import FoundationModels の後に、 let model = SystemLanguageModel.default guard model.availability "# .available else { … } let session = LanguageModelSession(instructions: …) let response = try await session.respond(to: …)
24. Guided Generation 生成したいデータを@Generableで定義 import FoundationModels @Generable struct GeneratedNote { @Guide(description: "MIDIノート番号", .range(55""#84)) var midiNote: Int @Guide(description: "開始位置：16分音符単位", .range(0""#15)) var startSixteenth: Int @Guide(description: "長さ：16分音符単位", .range(1""#16)) var durationSixteenths: Int @Guide(description: "音の強さ", .range(40""#110)) var velocity: Int }
25. Guided Generation generating:に型を渡し、結果をそのまま取得 let session = LanguageModelSession() let response = try await session.respond( to: "メロディの最初の音を1つ作ってください", generating: GeneratedNote.self ) let note: GeneratedNote = response.content
26. 型と値域の保証、内容の検証 • 生成時に制約できること • @Generable：プロパティの構造と型 • @Guide の .range：各プロパティの値域 • 複数にまたがる場合は別途検証が必要！ !" 生成された値の例 note.startSixteenth note.durationSixteenths !" 15：0!!$15の範囲内 !" 16：1!!$16の範囲内 !" 複数の値にまたがる条件は、アプリ側で検証 let fitsInBar = note.startSixteenth + note.durationSixteenths !% 16 !" false
27. 作曲との相性 なぜ作曲と相性が良いか • 楽譜データは制約の塊 • 各フィールドの値域を生成時に強制 • 形式の揺れ・自前パース失敗をなくす • 値をまたぐ制約・音楽的妥当性は別
28. 3つの壁 色々音楽生成を試みてわかったこと • コンテキスト 4,096トークン • 生成速度 • 後述のシンプルな実装でも、8小節で約30〜45秒かかることも a a • gu rdr ils(安全フィルタ)による拒否
29. ちなみに: iOS 27でのアップデート WWDC26での話とか • モデル刷新 / 画像入力 / サードパーティモデル対応 / PCC / トークン使用量API • 今日のデモと実装は iOS 26 の安定APIのみ • 詳しくは最後の展望で
30. 生成方式と改善の段階 Strategyと生成方式 • Str tegy A: 自由に作らせる （自由テキストから音符を読む） • Str tegy B: 構造を強制する （スキーマに沿って曲を生成） a a a • Str tegy C: 分割統治（分割して生成・検証する）
31. Strategy A: 自由に作らせる FMにCSV形式の音符列を頼み、自前のパーサで読む • FMにCSV形式の音符列を頼み、自前のパーサで読む • 出力形式を守ることも、プロンプトでお願いする • Guided Gener tionはまだ登場しないです b r st rt dur tion midiNote velocity 1 0 2 60 96 1 2 2 62 96 a a a a …
32. Strategy A: 自由に作らせる プロンプトはだいたいこんな感じ let session = LanguageModelSession(instructions: """ Output MIDI events as plain text in the exact requested format. No explanations or Markdown. Do not generate lyrics. Use integer sixteenth-note steps for all timing. """) var prompt = """ \(request.style.instructions). Mood: \(moodText(request.mood)) Create a monophonic melody of \(request.bars) bars. Key: \(request.keyRoot?.rawValue "# "choose") Minor: \(request.requestedMinor.map(String.init) "# "choose") Format: KEY:C MINOR:\(request.requestedMinor.map(String.init) "# "false") TEMPO:120 CHORDS:I,V,vi,IV NOTES: bar,start,duration,midiNote,velocity 0,0,4,60,90 """
33. 簡単なサンプルアプリで 実際に聞いてみましょう
34. 🎬 聴いてみましょう: Strategy A
35. 🎬 聴いてみましょう: Strategy A • かなり微妙 • というより音楽として成り立っているのか
36. 何が問題? Strategy A • 拍の算数ミス: 3Bモデルは数えるのが苦手 • 長い出力ほど一貫性が低下 • 音数・充填率を指定しないプロンプトだと、音数の少ない出力が目立った • とはいえ、自由度の観点からこれをディレクションに入れるのは考えもの
37. Strategy B: スキーマを強制する • @Generable で楽譜スキーマを定義 • タイミングは16分音符グリッドの整数(0–15) • 整数グリッドと値域制約で負担を減らす • 算数が苦手なら、算数をさせない
38. 🎬 聴いてみましょう: Strategy B
39. 🎬 聴いてみましょう: Strategy B • 型適合・各フィールドのr ngeは守る a • でも…値同士の関係 / 音楽的妥当性は別
40. Strategy C: 分割統治 1. 全体構成をまず考えさせる（Aメロ・サビ、みたいないもの） 2. コード進行はセクション単位 3. メロディは小節単位（曲固有文脈はpromptへ） 4. 違反があれば『修正依頼』して リトライ • 副産物: 短命セッションで4,096トークン問題を回避
41. リトライ は「言い直し」より「対話」 同じプロンプトで再依頼せずに • 同一プロンプトで再依頼だと 平均11.5回/8小節・約52秒 • 違反を伝えて修正依頼すれば 平均9.9回・約43秒(-17%) • 今回の測定では、修正依頼の導入後に平均生成時間が約17%短縮した • 「スケール外です」等をそのまま渡すだけ • 劇的ではないが、改善はしている
42. 🎬 聴いてみましょう: Strategy C
43. 🎬 聴いてみましょう: Strategy C • さっきよりはマシだが… • リトライ後も、狙った和声とのなじみ方にならない音が残る
44. Strategy C: 分割統治 + 音楽理論 1. 全体構成をまず考えさせる（Aメロ・サビ、みたいないもの） 2. コード進行はセクション単位 3. メロディは小節単位（曲固有文脈はpromptへ） 4. 違反があれば『修正依頼』 リトライ → 後処理 • 副産物: 短命セッションで4,096トークン問題を回避
45. 音楽理論による「 後処理 」 LLMに任せない勇気 • スケール外音を最近傍のスケール音へスナップ • 小節あふれをクリップ • 強拍スナップ（副作用が強いので注意） • LLM = 創造 / コード = 規律
46. 🎬 聴いてみましょう: Strategy C1 Phase 1: 分割統治 + 後処理
47. 🎬 聴いてみましょう: Strategy C1 Phase 1: 分割統治 + 後処理 • ノートの偏りと単調性は軽減されているように見える • 旋律の豊かさでいえばまだ課題が
48. 生成方式と改善の段階 Strategyと生成方式 • Str tegy A: 自由に書かせる（自由テキストから音符を読む） • Str tegy B: 構造を強制する（スキーマに沿って曲を生成） a a a • Str tegy C: 分割統治（分割して生成・検証する）
49. 生成方式と改善の段階 Strategyと生成方式 • Str tegy A: 自由に書かせる（自由テキストから音符を読む） • Str tegy B: 構造を強制する（スキーマに沿って曲を生成） • Str tegy C: 分割統治（分割して生成・検証する） a a a a • Str tegy D: 乱択アルゴリズムとルール（比較用, AIなし）
50. 比較用: 乱択＋ルールによる生成 乱択アルゴリズムとルール • Str tegy D: 乱数 → 後処理 → 曲 a • 局所的な正しさは、ルールだけで作れる
51. 🎬 聴いてみましょう: Strategy D 乱択アルゴリズムとルール
52. 🎬 聴いてみましょう: Strategy D 乱択アルゴリズムとルール • 機械的な処理がされたような不自然さはある • 運要素とはいえ、小節間の繋がりなどは偶発的に噛み合う場合がある • 「これで良くない？」と思った方も多いのでは
53. 事例: MoodCraft 作者: かっくんさん MoodCr ft - Focus Music a a a https://moodcr ft-d0c8e.web. pp/ , https://fromkk.me/
54. 🎬 聴いてみましょう: Strategy D 乱択アルゴリズムとルール • 機械的な処理がされたような不自然さはある • 小節間の繋がりなどは偶発的に噛み合う場合があるが、運要素 • 「これで良くない？」と思った方も多いのでは • 乱数が良いと品質がいいものを得られる
56. Aはランダム生成によるものでした（Aは不正解）
57. Fondation Models の強みを問い直す 乱択アルゴリズムとの違いは何か • ランダム性にはない「一貫した文脈」 • ランダム性では生み出しづらい「モチーフの反復」 • 曲想や文脈に応じてモチーフや展開方法を選ぶ役割を期待する
58. 小節ごとの生成では厳しい Strategy C -Phase 1（分割統治 + 後処理）の課題 • 小節単位の生成だけでは、曲全体の反復と変化を安定して作りにくい • テキストコーパスに「音楽についての言説」があるかもしれない？
59. Phase 2：モチーフを選んで展開 • Ph se 1で扱ったこと • 小節の生成結果を検証し、補正する • Ph se 2で挑戦すること a a • 短いモチーフを、反復と変化で曲へ展開する
60. Phase 2：モチーフを選んで展開 • モチーフとは • 動機（どうき）と訳され、独立した楽想を持った最小単位のいくつかの音符ないし休符の 特徴的な連なりを言う。(出典: Wikipedi ) a • いい感じの音が連続している状態のカタマリ
61. Phase 2：モチーフを選んで展開 a a a 選択とルールによる展開 フェーズ 担当 曲の構成とコード進行 Found tion Models 1小節のモチーフ候補を生成 Found tion Models 展開方法を選択 Found tion Models 反復・移調・反行・リズム変形・終止を実行 後処理 展開した音符を検証・補正 後処理
62. Phase 2：モチーフを選んで展開 • FM：1小節のモチーフを2候補生成 • Swift：検証・補正し、品質スコアが高い候補を採用 • FM：残りの小節の展開方法をenumで選択 • 後処理：選択された変形を実行し、コードに合わせて補正 @Generable public enum GeneratedBarTreatment: String, CaseIterable { case repeatMotif case sequenceUp case sequenceDown case invert case rhythmVariation case cadence }
63. 🎬 聴いてみましょう: Strategy C2 Phase 2: 分割統治 + 後処理 + モチーフを選んで展開
64. 🎬 聴いてみましょう: Strategy C2 Phase 2: 分割統治 + 後処理 + モチーフを選んで展開 • 前後関係を意識できている • 反復もできている • まだ淡白さは残っている • 特にリズムが単調すぎる
65. Phase 3：フレーズごとの役割を先に決める FMが形式や展開の意図を生成し、Swiftが計画に沿って音符を組み立てる • フレーズ全体を先に計画し、展開後の音符列を評価して、候補を選ぶ 小節 1〜2 3〜4 5〜6 7〜8 役割 提示 問い 応答 回帰・終止 狙い モチーフを戻して モチーフを聴かせる 少し変えて続ける 受けて落ち着かせる 締める
66. Phase 3：フレーズごとの役割を先に決める 2小節のモチーフを型で受け取る（ついでにリズムもテコ入れ） • Rhythms：各小節のリズム型 • 単調なリズム対策 • degrees：音階上の位置 • Cメジャーの例： • [0, 1, 2, 4] ＝ ド・レ・ミ・ソ @Generable struct GeneratedPhraseMotif { @Guide(.count(2)) var rhythms: [GeneratedPhraseRhythm] var degrees: [Int] }
67. Phase 3：フレーズごとの役割を先に決める 展開後の音符列で候補を選ぶ • 展開：同じフレーズ計画で、両候補を展開する • 音高の決定・補正：和声や前後のつながりを考慮する • 選択：最終音符列の品質を評価し、補正量を減点する !" 処理順を示す疑似コード let expanded = expand(motif, plan) let realized = realize(expanded, chords, context) let quality = analyze(realized) let repairCost = measureRepair(expanded, realized) let selectionScore = quality.score - repairCost
68. 🎬 聴いてみましょう: Strategy C3 Phase 3: 分割統治 + 後処理 + モチーフを選んで展開 + フレーズを計画 + 各候補を展開した完成形から選ぶ
69. 🎬 聴いてみましょう: Strategy C3 Phase 3: 分割統治 + 後処理 + モチーフを選んで展開 + フレーズを計画 + 各候補を展開した完成形から選ぶ • 前後関係を意識できている • 反復もできている • 変化、展開がいい感じにできている…?
71. Bは Strategy C3 によるものでした（Bが正解）
72. Cは私(log5)による手作りです
73. 上振れと下振れ 確率に左右される品質 • 品質上限はガチャ • 出力品質にはばらつきがある • 品質下限は設計で引き上げられる
74. 上振れと下振れ 確率に左右される品質 • 上限はガチャ • 出力品質にはばらつきがある • 下限は設計で引き上げられる • とはいえ、設計で縛りすぎるとそれが作曲の自由度を奪う • どこかのタイミングで「飽き」が発生する a a • 先程の Str tegy C - Ph se 3 が最も理想的、とは言えない
75. 限界の整理 Foundation Models (3Bの汎用言語モデル) がどこまで出来るか • 出来たこと • モチーフを反復・展開する短い小品をオフラインで生成可能 • 課題 • プロンプト改善だけで品質上限を越えるのは難しそう • 長尺の一貫性 / 歌声・音響生成 / 「売れる曲」水準
76. まとめ • 「記号表現の生成」なら、オンデバイス自動作曲は現実になった • 短い曲を、iPhoneだけでオフライン生成できた • モデルが構成やモチーフを選び、Swiftが音符にする • 曲のまとまりは作れた。魅力の安定には課題が残る
77. 展望: この先の夢 オンデバイス自動作曲のこれから • プロンプトだけでは、3B汎用モデルの構造的限界を越えられない • iOS 27 で期待 • 20Bモデル、Priv te Cloud Compute • LanguageModelSession が使用するモデルを選択・切り替えられる a • 音楽特化オンデバイスモデルを使うときも、同じAPIで生成部だけを差し替えられる
78. 展望: この先の夢 オンデバイス自動作曲のこれから • プロンプトだけでは、3B汎用モデルの構造的限界を越えられない • iOS 27 で期待 • 20Bモデル、Priv te Cloud Compute • LanguageModelSession が使用するモデルを選択・切り替えられる • 音楽特化オンデバイスモデルを使うときも、同じAPIで生成部だけを差し替えられる a • iOS 27 は 9月15日、週明けの火曜日です
79. ご清聴ありがとうございました 発表者: log5 (visit https: log5.jp ) • スライドで使用したサンプルアプリのコードは後ほど Githubで公開します。 • 参考文献 • Cheung et l. (2019), Uncert inty nd Surprise Jointly Predict Music l Ple sure nd Amygd l , Hippoc mpus, nd Auditory Cortex Activity • Shih et l. (2021/2022), Theme Tr nsformer: Symbolic Music Gener tion with Theme-Conditioned Tr nsformer • M dison & Schiölde (2017), Repe ted Listening Incre ses the Liking for Music Reg rdless of Its Complexity a a a a a a a a a a a / / a a a a a a a a a a a a a a • Touizr r et l. (2021), Repetition nd Aesthetic Judgment in Post-ton l Music for L rge Ensemble nd Orchestr