AI に作ってもらったエフェクトを確かめるたびに、私たちはモニタのログをコピーして、会話に貼り付けていました。
そこで MIDIFabric に、接続した AI のツールがモニタの記録とルーティングの構成を MCP で読める仕組みを加えました。どちらも初期設定ではオフで、設定 > AI で別々に許可します。許可しても AI は読むだけで、ルーティングを変えることも、MIDI を送ることもできません。読ませるかどうかは利用者が決め、決めたことはすぐに効く、という形にしました。
なぜ必要になったか
AI にエフェクトを頼むと、AI はコードを書き、MIDIFabric の確認(Check)にかけて提出します。でも、Check で分かるのはコンパイルして起動できるところまでで、狙いどおりに動くかは分かりません。それを確かめるには、弾いたときに何が出たかを見る必要があります。
それまでは、モニタのログを私たちが貼り付け、AI がそれを数えていました。貼る範囲を選ぶのも、設定値を伝えるのも人の仕事です。AI が自分で記録とルーティングを読めれば、「弾きました」と伝えるだけで確かめられます。実際にそうした様子は「AI に頼んだエフェクトを、AI が自分で確かめる」に書きました。
読めるもの、読めないもの
MCP の道具を 2 つ足しました。
- モニタの記録(
get_monitor_records)。 モニタが今保持している記録を、古い順にページに分けて読みます。MIDI のメッセージ、保持している SysEx、機器とポートの名前、エフェクトの処理と出力の関連、欠落の数、一時停止中かどうか、記録の絞り込みの設定、途中で切った記録の印が含まれます。画面の検索とは関係なく、保持から外れた記録は読めません。 - ルーティングの構成(
get_routing_snapshot)。 適用済みのルートと接続、Bypass、置いてあるエフェクトの名前と今のパラメータの値を読みます。まだ Apply していない編集は含みません。
読めないものもはっきりさせました。MIDI Debugger で保存した記録、アプリのログ、そのほかのファイルは読めません。MIDIFabric は音を録音しないので、AI が読めるのは MIDI の記録と設定だけです。読むことでモニタの一時停止やクリア、絞り込みが変わることもなく、MIDI を送ったり、ルーティングを始めたり変えたりもしません。
許可の決め方
初期はオフ、別々に
モニタの記録には、SysEx の中身や、利用者が付けた機器やポートの名前が入ります。ルーティングには、ルートやエフェクトの名前と設定値が入ります。読んだ内容は AI のツールを通して AI の会社へ送られるので、何を渡すかは利用者が選べるべきだと考えました。
そこで設定 > AI に「AIによるデータの読み取り」を設け、「モニターの保持記録の読み取りを許可」と「ルーティング設定の読み取りを許可」を別々のチェックボックスにしました。どちらも初期設定ではオフです。両方オフのままでも、エフェクトの作成や提出は今までどおり使えます。
道具は隠さない
許可がオフのときも、2 つの道具は一覧に出ます。呼び出すと「許可されていない」(permission_denied)という答えが返ります。道具を隠すと、AI は読めない理由が分からず、利用者に何を頼めばよいかも伝えられないからです。隠すことを、守りの仕組みとしては使いません。
オフはすぐ効き、オンは保存してから
許可をオフにすると、保存より先に、今の接続での読み取りを止めます。保存に失敗しても、止めたままにします。オンは、設定の保存に成功してから効きます。
読み取りの途中でオフにした要求は、その後またオンに戻しても、古い要求として拒否します。オフにした後に、オフにする前の要求の答えが返ってしまわないようにするためです。どちらの切り替えでも、AI のツールを再起動する必要はありません。ただし、新しく足した二つの道具を AI のツールが初めて見つけるには、AI のツールの側で MCP をつなぎ直す必要がある場合があります。私たちも、Claude Code でつなぎ直しました。
返したものは戻せない
許可をオフにしても、すでに AI に渡した記録は取り戻せません。設定の説明とプライバシーポリシーに、そのことを書いています。
接続そのものは、これまでどおり Mac の中だけで受け付け、アクセストークンのない要求は拒否します(「AI に MIDI アプリを扱わせる、Mac の外へ出さずに」)。MIDIFabric 自身は、読み取ったものをどこへも送りません。
記録は、そのまま正しいとは限らない
モニタの記録にも限りがあります。保持できる件数には上限があり、一時停止中は記録されず、絞り込みで外したメッセージは残りません。
そのため、記録と一緒に、欠落の数、一時停止、絞り込みの設定、途中で切った記録の印を返し、AI にはそれを判断の根拠に添えるよう指示しています。対象の演奏が記録にない場合や、欠落がある場合は、正常と言い切らず、もう一度弾くよう頼むように、という指示です。ルーティングの構成とモニタの記録は別々の時点の写しなので、AI はエフェクトの定義の版を照らし合わせてから比べます。
そして、記録が正しくても、それは出した MIDI が正しいということで、音として狙いどおりかは別です。答えには「動作は確認していない」(behavior_verified: false)を付けたままにしています。聞こえ方は、弾いた人の耳で確かめるしかありません。
細かいところでは、記録の通し番号や時刻のような大きな数は、10 進の文字列で返しています。JSON を読む側が小数として扱うと、桁が丸められて照合できなくなるためです。
確かめたこと
製品のコードを写した試作で、通常の実行と App Sandbox の両方で 22 項目を確かめました。たとえば、トークンのない要求の拒否、両方の許可が初期でオフであること、片方の許可でもう片方が開かないこと、読み取りの途中でオフにした要求の拒否、ページ分けの読み取り、欠落と一時停止の伝え方、読み取りでルーティングが変わらないこと、接続を止めた後の遅れた応答の扱いです。
実際の利用では、Claude Code が反復のエフェクトを確かめる中で、二つの道具を使って数百件の記録を読み、回数や止め方を数えました。記録がとても多いときの読み取りの速さは、まだ測っていません。
MIDIFabric について
MIDIFabricは、利用者が自分で動かす AI のツールと MCP で連携します。AI に何を読ませるかは利用者が設定で決め、AI が作るのは道具で、弾くのは利用者です。