先に結論
2026年10月10日、アプリ内のアシスタントStarlingが、ある人に、4小節目の左手をヘ音記号に変えたと伝えました。ところが、その小節はト音記号のままでした。3つのことが重なっていました。編集ツールが、何も変えなかった編集に「Applied」と答えたこと。楽譜のテキスト読み取りが、曲の途中の音部記号の変更を示さなかったこと。そして、モデルがページの画像を信じたことです。3つともツール側で直し、共通のルールを1つ加えました。修正前と修正後を比べる測定は、まだ行っていません。
何が起きたのですか?
ピアノの楽譜で、下の譜表が4小節目の1小節だけト音記号になり、そのあとヘ音記号に戻っていました。4小節目は、分散和音が高い音域に上がるところです。依頼した人は、楽譜の横にいるStarlingに、4小節目の左手をヘ音記号にするよう頼みました。Starlingは編集ツールを呼び出し、成功の結果を受け取って、できたと伝えました。ところが、ページの4小節目はト音記号のままでした。何も変わっていないと言われたとき、モデルはもっともらしく聞こえるほうの説明に従い、その小節を読み直しませんでした。
私たちは、ステージングサーバーに保存されたチャットと楽譜のバージョン履歴を読んで、同じ日に原因を見つけました。
なぜアシスタントは、編集がうまくいったと信じたのですか?
手元にある情報源が、どれもそう言っていたか、何も言っていなかったからです。原因はどれも、ひとつだけなら、やり過ごせたはずでした。
- 依頼「4小節目、左手、ヘ音記号」
- 編集譜表の冒頭の音部記号を設定する。すでにヘ音記号だった
- 結果「Applied」と、新しいバージョン番号
- 読み取り冒頭の音部記号しか示さないので、おかしな点は見えない
- 返信「完了しました」
- 編集は何も変えていないのに、成功しました。ツールは、有効な依頼をすべて新しいバージョンとして扱っていました。譜表を、すでにある音部記号に設定するのは有効な依頼だったので、サーバーは同じ楽譜を保存し、新しいバージョン番号とともに「Applied」と返しました。モデルが疑う理由はありませんでした。
- 読み取りは、肝心なことを隠していました。楽譜のテキスト読み取りが挙げていたのは、各パートの冒頭の音部記号と調で、曲の途中の変更は挙げていませんでした。4小節目で切り替わる音部記号は、テキストでは見えませんでした。さらに悪いことに、次の小節の音部記号を予告するために小節の終わりに印刷される予告の音部記号が、その小節自身の音部記号として数えられていました。
- モデルは画像を信じました。テキストとレンダリングされたページが食い違っているとき、またはテキストが何も語らないとき、モデルは画像から判断しました。段の中にある小さな音部記号は、画像では読み違えやすいものです。
何を変えましたか?
変更は4つで、すべて2026年10月10日に、StarlingとMCPコネクタが共有するサーバーに加えました。
- 楽譜がそのままになる編集は、拒否します。ツールは「Nothing changed: this edit leaves the score as it was, so no new version was saved」(変更なし:この編集では楽譜が変わらないため、新しいバージョンは保存されませんでした)というエラーを返し、バージョン番号は進みません。「元に戻す」と「やり直す」は、この拒否の対象外です。
- すべての編集が、書き込んだ内容を一覧にします。結果に
bar 4: lower staff clef treble -> bassやbars 1-4: key C major -> F majorのような行が付くので、モデルは編集後の楽譜にあるとおりを報告できます。 - 読み取りに、曲の途中の変更が出るようになりました。楽譜の読み取りは、音部記号、調、拍子が変わる小節ごとに、それらを示します。確認用のテキストは、「treble clef from here」(ここからト音記号)のような印と調の変更をその位置に付け、予告の音部記号は、それが告げる小節のものとして数えます。
- すべての経路に共通のルールを1つ。Starling、MCPサーバー、プラグインのスキルの指示文に、次のことを書きました。ツールの結果が示すことだけを言う。エラーや「Nothing changed」は、編集が行われなかったという意味なので、そう伝える。音部記号、調、音符は、画像ではなくテキストの読み取りで判断する。本人が異議を唱えたら、その小節をもう一度読む。
順番が大切です。最初の2つは、事実をモデルが読む結果の中に入れるもので、プロンプトの言い回しにはできないことです。MCPの仕様も同じ分け方をしています。ツールの実行中に起きたエラーはツールの結果に入れ、isErrorを付ける。そうすれば、モデルがそれを見て、自分で直せるという考えです。私たちの「Applied」は、エラーであるべきところで成功を返していました。
どのようにテストしますか?
方法は2つあります。1つは完了し、もう1つは待っているところです。
- テストスイートの検査が、下の譜表が音部記号を切り替え、調が後で変わる楽譜を開きます。そして、すべての読み取りが両方の変更を示すこと、編集が書き込んだ音部記号と調を一覧にすること、何も変えない編集が新しいバージョンを作らずに拒否されることを確かめます。ほかの素早い検査と一緒に、プルリクエストのたびに実行されます。
- 評価では、問題が起きた曲と同じ作りの12小節のピアノ曲について、Starlingに6つの依頼を送ります。実際の音部記号の修正、すでにヘ音記号の小節への同じ修正、変更後の調についての質問、何も変えない音高の編集、ペダルの編集、小節数の質問です。別のモデルが、返信に含まれる主張をひとつずつ挙げ、そのターンのあとに保存された楽譜と照らして採点します。アシスタント自身の言葉とは照らしません。この評価は、変更の前後でまだ実行していないので、報告できるハルシネーションの割合はありません。
ルールは、誤った主張の割合を下げますが、ゼロにはしません。モデルは、画像だけを見ると小節を読み違えることがあります。だからルールはモデルをテキストへ向かわせ、モデルが行う編集には印が付き、元に戻せるのです。
ツールを使うエージェントを作る人には、何を伝えますか?
- ツールは、何も起きていないのに成功を報告してはいけません。呼び出しが状態を変えられないなら、モデルが読めるエラーを返します。
- 書き込んだ内容を、その分野の言葉で返します。依頼をそのまま返しても、何の証明にもなりません。
- モデルが自分の作業を確かめるのに必要な事実は、すべてテキストに入れます。事実が画像の中にしかないと、モデルは画像から判断します。
- 会話を読みます。私たちはこの問題を、指標ではなく、保存されたチャット1件から見つけました。
出典
- Model Context Protocol、Specification 2025-11-25: Tools、Error Handlingの節。
- 2026年10月10日のScoreStarlingの保存済みチャットと楽譜の履歴、およびそのあとに行った変更とテスト。
よくある質問
なぜツールは、何も変えなかった編集を成功と報告したのですか?
私たちのツールは、有効な依頼をすべて新しいバージョンとして扱っていました。音部記号を、すでにある音部記号に設定する依頼も有効だったため、同じ楽譜を保存して「Applied」と返していました。2026年10月10日からは、そうした編集は「Nothing changed」(変更なし)として拒否され、バージョンは保存されません。
プロンプトのルールだけで、エージェントが、していない編集を「した」と言うのを防げますか?
確実には防げません。ルールは役に立ちますが、何が事実なのかは、モデルが知っていなければなりません。いちばん効くのはツール側の変更です。何も変えない編集を拒否することと、各編集が書き込んだ内容を一覧にして、事実をモデルが読む結果の中に入れることです。
ChatGPTやClaudeにも当てはまりますか?
はい。StarlingとMCPコネクタは同じツールを呼び出すので、ChatGPT、Claude、ほかのMCPクライアントも、同じ拒否と、書き込んだ変更の同じ一覧を受け取ります。同じルールは、サーバーの指示文にも入っています。



