ピアノ練習をサポートするAIくんを作ってみた

第 5回 JAZUG Shizuoka / 2026.09.12 ピアノ練習をサポート する AIくんを作ってみた 弾きっぱなしにしない。 1曲を仕上げるためのAI練習コーチ。 しろくま / 野 村 宏 樹 （ Hiroki Nomura） KINTOテ ク ノ ロ ジ ー ズ AIフ ァ ー ス ト G Microsoft MVP for Microsoft Foundry github.com/nomhiro/piano-ledgerlines 01

自己紹介 しろくま 野村宏樹 / Hiroki Nomura Microsoft MVP for Microsoft Foundry 所属：KINTOテクノロジーズ AIファーストG 愛知県在住のエンジニアです。技術関係のブログを書いた り、登壇したりしています。 コミュニティ AzPoC部 #AzPoC X Zenn なごあず #75azu GitHub Copilot User Group Japan #GhCUG Ledger Lines 02

なぜ作ったのか 1時間練習しても、一人で練習してると 客観的な判断ができない 1 どこが悪かった？ 弾いている間は指と楽譜で頭がいっぱい。自分の耳では、ズレや抜けに気づけない。 2 前より良くなった？ 感覚だけでは、良くなったのか分かりません。前の録音と並べて聴き比べることは、まずやりません。 3 次に何をする？ 結局また最初から通して弾いてしまう。本当は弱い数小節だけを繰り返すべきなのに。 録音すれば、これを教えてくれるツールが欲しかった。 出典 docs/spec/functional.md §1 / 先 生 に 見 て も ら え る の は 週 に 1回 。 残 り の 6日 を 、 ひ と り で ど う 練 習 す る か 03

作ったもの 欲しかったのは「採点」ではなく、練習のループ 1 楽譜を登録 MusicXML、またはPDFか ら自動で譜面データに変換 する。 2 演奏を録音 → スマホやPCのマイクだけ でOK。ブラウザだけで終 3 弱い小節を発見 → 楽譜上に色で表示。前回の テイクとも比較する。 4 今日の練習へ → どこを、どのテンポで、ど う練習するかまで出す。 わります。 弾いて、直して、また録る 総合スコアは前に出さない 出すのは小節ごとの内訳 「82点」では、明日どこを弾けばいいのか分からない。上がった 「19小節目のリズムが54点」。ここまで分かると、次に弾く場所 か下がったかしか言えません。 が決まります。 ※ MusicXML＝ 楽 譜 を デ ー タ で 表 し た 標 準 形 式 。 音 符 ・ 拍 子 ・ 強 弱 記 号 ま で 構 造 化 さ れ て い る 04

作ったもの（画面） 画面では、弱点が「次の練習」に変わる 分析結果 AIコーチ 小節スコアを楽譜に重ねて、弱い小節を色で出す（左）。その弱点から、今日やる練習を具体的に組む（右）。 ※ PoVの モ ッ ク UI（ サ ン プ ル デ ー タ ） 。 指 標 が 6つ 出 て い る の は 、 articulation を 外 す 前 の 画 面 で す 05

デモ Ledger Lines 06

どういう仕組みなのか 録音を、4段階で「練習できる情報」にする 録音 音符化 楽譜と照合 改善点 スマホのマイクで演奏を 採譜＝録音を音符データに 速さが揺れても、どこを弾 小節ごとの差を出して、次 録る。 前処理 S0 → 3秒 変える。 S2 → 採譜 25秒 いたか探す。 → の練習を決める。 S4 指標算出 2秒 S1 参照譜の展開 1秒 S5 指摘生成 1秒 S3 アライメント 8秒 S6 AI講評 12秒 3分の演奏で 合計 約 52秒 / 時間がかかるのは S2 採譜 と S3 アライメント 採譜に使っているモデル 打鍵の強さとペダルまで出る どのくらい当たるのか ByteDance が公開している 「どの音が、いつ、どれくらいの強さで鳴っ 音符の検出は、きれいな録音で F1 0.98。スマ piano_transcription。ピアノの演奏音声 たか」に加えて、ペダルの踏み込みも返す。 ホ録音や部屋の残響ありでも 0.83〜0.89。 を、音符の列に書き起こす学習済みモデル 強弱とペダルを測るには、この2つが必要で です。 した。 ※ 採譜 ＝ 音 声 か ら 音 符 を 書 き 起 こ す こ と / アライメント ＝ 楽 譜 と 演 奏 の 音 符 を 対 応 づ け る こ と 07

楽譜との照合 録音の音を、楽譜の「どこ」に当てはめるか 弾き落とし 楽譜 演奏 S3 DTW 余分な音 線でつながった音＝対応がとれた音。つながらない音は 弾き落とし（楽譜にあるのに鳴っていない）か 余分な音（楽譜にないのに鳴っている）。 使うのは DTW という方法 同時に鳴った音はひとまとまり ノイズと弾き直しは減点しない Dynamic Time Warping（動的時間伸縮法）。名前 和音をばらばらに扱うと対応が崩れる。ド・ミ・ 響きによる誤検出は「余分な音」と区別します。 のとおり時間軸を伸び縮みさせて、2つの列を対応 ソをひと組として、前後にずらしながら一番似る 弾き直しは、最後に弾いたほうを採点します。 づける方法です。テンポが揺れても、今どこを弾 場所を探します。 いているかを追えます。 ※ DTW は 音 声 認 識 や 時 系 列 デ ー タ の 照 合 で 古 く か ら 使 わ れ て い る 方 法 。 特 別 な 新 技 術 で は あ り ま せ ん 08

何を測っているのか 演奏を5つに分けると、直す場所が見える 指標 音の正しさ リズム テンポ 強弱 ペダル 重み 測っていること 0.28 抜けた音と余分な音。弾いた音を楽譜と比べる 0.28 音を出すタイミングと、和音の揃い。全体の速さには影響されない 0.17 急な速まり・遅れ。基準は実演奏の平均的な速さ 0.17 大きく・小さくの変化。楽譜の強弱記号と比べる 0.10 踏んでいる長さ、和音が変わったのに踏み替えない「濁り」 小さな差は許す リズムとテンポは分ける 材料がなければ点を出さない 人が聞き分けられない差や、録音による揺れでは 1つのミスで5指標すべてが落ちると、原因が分か 対象外（楽譜に指示がない）と保留（判断する材 減点しない。 らなくなる。 料が足りない）を用意しました。 ※ 点はまず 小節ごと に 出 す 。 「 全 体 で 80点 」 で は な く 「 こ の 小 節 の リ ズ ム を 直 そ う 」 に つ な げ る た め 09

採点の設計思想 楽譜どおり = 良い演奏、ではない 楽譜どおりに正確に弾くほど満点に近づく、という作りは、音楽としては間違っています。「ず れ」を3つに分けて考えます。 誤り 揺らぎ 表現 抜けた音、余分な音、明確なリズムの間 20〜30ミリ秒の微小な差。人間には聞き ルバート、意図的な間。曲に合った変化 違い。直すべきもの。 分けられない。 なら、ミスではありません。 減点する 減点しない 見つけて、ほめる ルバートをそのまま減点すると、音楽的に弾く人ほど点が下がります。 ※ ルバート ＝ テ ン ポ を 意 図 的 に 伸 び 縮 み さ せ る 演 奏 表 現 。 楽 譜 に 書 か れ て い な く て も 音 楽 的 に 正 し い 10

AIに 何 を さ せ る か 確実な計算はツール、説明は生成AI ツール ── 正確に、いつも同じ結果で 生成AI ── 結果を読んで、伝わる言葉にする 採譜（音声を音符に） 分析結果の要約 楽譜との位置合わせ（DTW） 弱点の説明 小節ごとの差とスコアの計算 次の練習メニューの提案 同じ演奏なら、いつも同じ答えが出る 同じ内容でも言い方を変えられる AIに正解を計算させない。ツールが出した答えを、練習する人に分かる言葉にする。 最大のリスクは「分析結果と矛盾する講評」。LLMには判断済みのラベルだけを渡し、出力は Structured Outputs（出す形をあらかじめ決めておく仕組 み）で固め、さらにプログラムで検査します。 出典 docs/design/ai-prompts.md §1.1「 最 大 の リ ス ク 」 11

Azureの 構 成 Azureは「数分かかる分析」を待たせないために使う Container Apps 2 Next.js SSR + API 3 5 ブラウザ Storage Queue 録音・表示 分析の順番待ち 1 Cosmos DB 状態を読んで SSE で進捗を返す Blob Storage 4 Container Apps 解析ワーカー Foundry 音声を取得 音声・楽譜を保存 1 SASでBlobへ直接 2 状態を queued に 履歴・指標を保存 講評・練習メニュー 3 ジョブを積んで 202 を返す 4 KEDAが 0 → 1 5 採点はCosmos、講評はFoundry 非同期 約2.5分 Managed Identity 監視と秘密情報 録音したあと、画面の前で待たせ 3分の曲をCPUで分析したときの パスワードを埋め込まず接続 Application Insights / Key Vault ない。 実測です。 する。 ※ SAS＝ Blobへ の 一 時 的 な ア ク セ ス 許 可 ト ー ク ン / KEDA＝ キ ュ ー の 長 さ に 応 じ て コ ン テ ナ 数 を 自 動 調 整 す る 仕 組 み 12

なぜこの構成なのか 「AIだから」ではなく、制約から決めた 解析が重い → Container Apps 結果を急がせない → Storage Queue 夜だけ集中したり、何時間も来なかったりする。min 0 まで落と 録音と解析を切り離す。載せるのは Blobのパスと ID だけで 64KB せる。これが選んだ理由です。 に収まる。 却下 App Service＝使っていない時間も課金／AKS＝ノードの管理が重い 却下 音声は大きい 履歴を育てる → Blob Storage Service Bus＝この用途には機能が余る。そのうえ料金が高い → Cosmos DB ブラウザから直接アップロードし、Web API を通さない。混雑し 月2万テイク ≒ 200万 RU なら Serverless が安い。5,000 RU/s・ ても順番に処理できる。 20GB の上限に近づいたら自動スケールに変えます。 却下 API経由のアップロード＝3分の曲で数MB、APIが詰まる 却下 あらかじめ容量を確保する方式＝この規模だと払いすぎになる ※ RU＝ Cosmos DB の 処 理 量 の 単 位 。 テ イ ク 1件 の 読 み 取 り が 約 3RU / 選 ぶ 基 準 は 「 利 用 者 を ど こ で 待 た せ な い か 」 13

まとめ・所感 Ledger Lines 14

まとめ AIが「作る」を簡単にするほど、ドメイン知識が差になる FDE ドメイン専門家 Forward Deployed Engineer 医師・音楽家・教師・現場担当 技術者が現場へ近づく ↔ はっきりしない困りごとを、動くものにする。 専門家がAIで作る側へ近づく 何を直すべきか、どうなれば良いのかを知っている。 非エンジニアの研修医が、医療現場の課題を題材に Claude Hackathon 2025 in Tokyo でソロ準優勝。 出典 AGIラ ボ 本 人 寄 稿 agi-labo.com/articles/n63d3cfabf318 15

所感 「何でも作れる時代」だから、何を作るかで差がつく 主要活動 パートナー 顧客との関係 価値提案 顧客セグメント リソース コスト構造 チャネル 収益の流れ 作りはじめる前に、 ビジネスモデルキャンバスを AIと叩く 。普段からやっています 色を付けた3つの枠——顧客セグメント・価値提案・収益の流れ——が埋まらないなら、まだ作る段階ではあ りません。ここはAIも代わりに考えてくれない。 AI時代だからこそ、単能工から多能工へ。 一つの持ち場だけでなく、前後の工程まで。そう動いていく気がしています。 ※ ビジネスモデルキャンバス ＝ 事 業 の 全 体 像 を 9つ の 枠 に 書 き 出 す フ レ ー ム ワ ー ク 。 1枚 に 収 ま る の で 、 作 る 前 の 検 証 に 向 く 16

ありがとうございました 第 5回 JAZUG Shizuoka / 2026.09.12 17

宣伝 Ledger Lines 18