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