プライバシーフィルターには指示の忠実性テストも必要だ

zkAPI の2026年10月16日の評価では、書き換えで制約が変化した。著者は匿名性や意味の同等性を証明する結果ではないと明記する。評価記録

遠隔モデルの前にローカル編集器を置くチームには、実務上の問いが生じる。編集後の依頼にも同じ権限が残っていると、誰が確認するのか。以下は Open Market Notes が提案する試験方法であり、導入済みシステムの実測結果ではない。

文章の読みやすさより、判断を検査する

完全に架空の業務を対にして用意する。一方では購買アシスタントに注文書の準備を許可し、他方では指定した役割の人が承認した後に注文を送信できるようにする。取引条件は同一にする。文章をフィルターに通す前に、評価者が許される最終行動を記録する。書き換え後は、どの版かを伏せて行動の境界を比較する。

これは「おおむね同じ意味か」という確認より厳しい。簡潔な要約が主題を残していても、次の手順を誰が承認すべきかを落とすことがある。注文のその他の内容が正しくても、失敗と数えるべきだ。

識別情報の削減は別に採点する

Tor の公式ガイドは、個人情報を渡すと相手のウェブサイトに識別され得ると警告する。これは一般的なブラウザーの説明であり、zkAPI の検証ではない。Tor ガイド

提案する試験では、業務と無関係な情報を含む架空の顧客プロフィールと、業務に不可欠な承認役割を用意する。前者の削除と後者の維持を別々に評価する。総合点だけでは、正しい行動に必要な情報までほぼすべて消すフィルターを見逃しかねない。

引き渡す内容全体を調べる

このブランチの文書では、ツールの結果と添付ファイルは変更されない。文書

架空の請求書を第二の入力経路にする。無害な固有マーカーを入れ、承認された試験用記録手段で組み立て済みの送信要求を調べる。書き換え後のチャットから内容を推測せず、実際の引き渡しを検査できる。実在する顧客データは不要だ。

失敗時に止められる設計にする

私たちが提案するリリース条件は、権限検査に失敗した依頼を、行動を実行できるエージェントへ渡さないことだ。元の業務依頼は権限のある人の確認用にローカルで保持し、黙って原文の外部送信に切り替えない。フィルター、モデル、メッセージの組み立て方を変更したら再試験する。

これらは提案する管理策であり、測定済みの保証ではない。調達時に聞くべきなのは、権限維持の失敗を再現し、その後どの処理が停止するかを供給者が示せるかという点だ。