---
title: ピアノ練習をサポートするAIくんを作ってみた
tags:  #ai #azure  
author: [Hiroki Nomura](https://www.docswell.com/user/shirokuma)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/GJ8D5N9LJD.jpg?width=480
description: 2026/09/12の第5回 JAZUG Shizuokaでの登壇内容です。  ピアノ練習をサポートするAIくんを作ってみた
published: September 12, 26
canonical: https://www.docswell.com/s/shirokuma/527YMG-piano-support-app
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/GJ8D5N9LJD.jpg)

第 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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/LJLMYPWQER.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/47MYN4YK7W.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/P7R9DW96E9.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/PJXQ1PQD7X.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/3JK92D9DJD.jpg)

デモ
Ledger Lines
06


# Page. 7

![Page Image](https://bcdn.docswell.com/page/LE3W4RWPE5.jpg)

どういう仕組みなのか
録音を、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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/8EDKQYK37G.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/V7PKL6KPJ8.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/2JVVQ3VVJQ.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/5EGLW3L1JL.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/4JQY35YN7P.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/K74W19W3E1.jpg)

なぜこの構成なのか
「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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/LJ1YGKYZEG.jpg)

まとめ・所感
Ledger Lines
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/GJWGKDG672.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/4EZLZGLR73.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/Y76WZYW17V.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/G75MWGML74.jpg)

宣伝
Ledger Lines
18