AI に作ってもらったエフェクトを確かめるたびに、私たちはモニタのログをコピーして、会話に貼り付けていました。
そこで MIDIFabric に、接続した AI のツールがモニタの記録とルーティングの構成を MCP で読める仕組みを加えました。どちらも初期設定ではオフで、設定 > AI で別々に許可します。この権限で行えるのは読み取りだけです。ルーティングの変更や MIDI の送信はできません。
なぜ必要になったか
AI にエフェクトを頼むと、AI はコードを書き、MIDIFabric の確認(Check)にかけて提出します。Check で確認できるのはコンパイルと初期化までです。狙った動作になっているかを調べるには、演奏時に出力された MIDI も必要です。
それまでは、モニタのログを私たちが貼り付け、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 つのツールは MCP のツール一覧に表示します。呼び出すと「許可されていない」(permission_denied)という答えが返ります。一覧から隠すより、呼び出し時に権限不足を伝えるほうが、AI も利用者に設定の変更を案内できます。権限の検査は呼び出しごとに行います。
無効化は即時、有効化は保存後
許可をオフにした時点で、現在の接続からの読み取りを止めます。設定の保存に失敗しても読み取りは再開しません。逆に、オンにするときは保存が成功してから読み取りを許可します。
読み取りの途中でオフにした要求は、その後またオンに戻しても、古い要求として拒否します。オフにした後に、オフにする前の要求の答えが返ってしまわないようにするためです。どちらの切り替えでも、AI のツールを再起動する必要はありません。ただし、新しく足した二つの道具を AI のツールが初めて見つけるには、AI のツールの側で MCP をつなぎ直す必要がある場合があります。私たちも、Claude Code でつなぎ直しました。
すでに渡した記録の扱い
許可をオフにしても、すでに AI に渡した記録は取り戻せません。設定の説明とプライバシーポリシーに、そのことを書いています。
接続そのものは、これまでどおり Mac の中だけで受け付け、アクセストークンのない要求は拒否します(「MIDIFabric と AI を MCP でつなぐ」)。MIDIFabric 自身は、読み取ったものをどこへも送りません。
記録の欠落も AI に伝える
モニタの記録にも限りがあります。保持できる件数には上限があり、一時停止中は記録されず、絞り込みで外したメッセージは残りません。
そのため、記録と一緒に、欠落の数、一時停止、絞り込みの設定、途中で切った記録の印を返し、AI にはそれを判断の根拠に添えるよう指示しています。対象の演奏が記録にない場合や、欠落がある場合は、正常と言い切らず、もう一度弾くよう頼むように、という指示です。ルーティングの構成とモニタの記録は別々の時点の写しなので、AI はエフェクトの定義の版を照らし合わせてから比べます。
読み取れた記録だけで、エフェクトの動作全体や聞こえ方まで確認できるわけではありません。応答には behavior_verified: false を付け、音は実際に弾いて確認してもらいます。
細かいところでは、記録の通し番号や時刻のような大きな数は、10 進の文字列で返しています。JSON を読む側が小数として扱うと、桁が丸められて照合できなくなるためです。
確かめたこと
製品のコードを写した試作で、通常の実行と App Sandbox の両方で 22 項目を確かめました。たとえば、トークンのない要求の拒否、両方の許可が初期でオフであること、片方の許可でもう片方が開かないこと、読み取りの途中でオフにした要求の拒否、ページ分けの読み取り、欠落と一時停止の伝え方、読み取りでルーティングが変わらないこと、接続を止めた後の遅れた応答の扱いです。
実際の利用では、Claude Code が反復のエフェクトを確かめる中で、2 つのツールで数百件の記録を読み、反復回数と Note Off のタイミングを確認しました。記録がとても多いときの読み取りの速さは、まだ測っていません。
MIDIFabric について
MIDIFabricは、利用者が自分で動かす AI のツールと MCP で連携します。モニタとルーティングへの読み取り権限は、利用者が設定で管理します。