あなたのAIエージェントを制御しているのは誰か？ operatorとanalystの分離によるエージェント型AI監視ギャップの解消

Open Interpreter、Claude Code、Cursor といったエージェント型AIシステムは、任意のコード実行、ファイルシステムアクセス、ネットワーク呼び出しといった operator権限 を、クラウド上でホストされる大規模言語モデルに委譲している。本稿では、産業界が、根本的に異なる二つの信頼モデル——データ共有（境界づけられ、ユーザーによってゲートされ、離散的）と リモートシステム制御（境界がなく、連続的で、委譲されたもの）——を混同することによって、質的に新しい監視サーフェスを常態化させてきたと論じる。あらゆるプロンプト、ツール呼び出し、ファイル内容、コマンド出力は、米国法域下にある単一のプロバイダーにとって観測可能となり、召喚状、捜索令状、National Security Letters、FISA §702 によって法的に強制取得され得る。しかも緘口令（gag order）を伴うため、ユーザーがそれを認識することはできない。この脅威モデルはもはや仮説ではない。2025年から2026年にかけて、チャットログが刑事裁判の証拠として提出され、訴訟ホールド命令がプロバイダー自身の削除ポリシーを無効化し、プロンプトからユーザーの身元を特定しようとする初の捜索令状が知られるところとなった。ここから得られる教訓は一般化できる。すなわち、プロバイダーのプライバシーポリシーは裁判所の命令に従属し、強制取得に耐えうる唯一の性質は 非保有——そもそも保有したことのないものの提出を強制されることはない——である。

既存の緩和策は、この問題に部分的にしか対処できていない。ローカル専用システム（Ollama、LM Studio）はクラウドを回避するが、能力のギャップ（capability gap）を残すため、非自明なタスクではユーザーを再びホスト型モデルへと押し戻してしまう。機密計算（Apple Private Cloud Compute）はインフラ運用者からコンテンツを秘匿するが、ユーザーのアイデンティティは保持されたままであり、課金と結びついた推論や法的強制は依然として有効である。いずれのアプローチも、フロンティアモデルの能力 と ユーザーの匿名性を同時に保つことはできない。

本稿では、このギャップを三つの組み合わせ可能なメカニズムによって解消するリファレンスアーキテクチャ SnowClaw を提示する。第一に、operator/analyst 分解である。ツール呼び出しを選択・実行するコンポーネント——operator——はローカルモデル（Gemma 4）に固定され、そのネットワーク送出は capability-gate フレームワークが fail-closed の規則——保護層が自らの有効性を検証できない場合、その層が守る経路そのものを閉じる——の下で遮断する。解釈は operator に対して通常のツール（analyst）として提示され、そのバックエンドがローカルの mini-analyst かフロンティアクラウドモデルかを operator は区別できない。第二に、三ドメインの信頼分離である。クラウド analyst へのクエリは、それぞれ別個の信頼ドメインとして運用される入口リレー、ゲートウェイ、トークン発行者を経由し、いかなる単一の当事者もユーザーの身元と内容を同時に保有しない。リレーが見るのは IP アドレスと暗号文のみ、ゲートウェイが見るのは非識別化されたテキストのみ（身元は見えない）、発行者が知るのは誰が支払ったかのみ（何に使われたかは知らない）である。このトポロジーは意図的に Oblivious HTTP（RFC 9458）と同型であり、Chaum のブラインド署名の標準化された後継である Privacy Pass アーキテクチャ（RFC 9576）に従う匿名利用トークンによって、課金とクエリの結びつきを断つ。クラウド上の analyst は、ユーザーのデバイスへツール呼び出しを発行することも、誰がクエリを送信したかを知ることもできない。第三に、クラウド経路上のオンデバイス可逆的仮名化ゲートである。個人識別子、認証情報、ホスト名、そしてクラウドが決して見ることのできないデバイスローカル辞書に由来する実名といった機微なエンティティが、階層化された検出器によって検出され、一貫性を保ちフォーマットを維持するプレースホルダーに置換される。置換マップがデバイスを離れることは決してない。検出は本質的にベストエフォートであるため、ゲートは fail-closed である。すなわち、確信をもって非識別化できないクエリは、クラウドではなくローカルの analyst にルーティングされる。

このキャリブレーション不要の分解は意図的なものである。小規模なローカルモデルは「これを実行できるか？」というメタ的な問いに対するキャリブレーションが不十分である一方、ツール選択については十分に訓練されている。ローカルかクラウドかの判断を、明示的なユーザー設定に結びつけられた固定のルーティングポリシーへと畳み込むことで、SnowClaw はローカルモデルの強みを活かし、ルーティングの決定をモデルの自己評価ではなくユーザーの意図に結びつける。

本アーキテクチャは部分的なリファレンス実装に基づいている。独自に開発し本番環境に展開したエンドツーエンド暗号化メッセンジャー SnowChat——自作の Pure Dart による Signal Protocol 実装（X3DH、Double Ratchet、Sealed Sender）と 115 件のライブラリレベルのテストを備える——の上に構築されており、明示的な claims-to-invariants 原則に従う。すなわち、あらゆるプライバシー上の主張は機械検証可能なテストに対応づけられ、未実装の層は暗示されるのではなく開示される。

実装状況。 ローカルの operator、capability gate、analyst 出力の構造的隔離（敵対的フィクスチャで検証済み）、および sealed-envelope リレーの骨格は実装済みである。さらに三つの層が仕様化され、後続フェーズに予定されている。すなわち、Privacy Pass トークンの発行・検証、オンデバイス仮名化ゲート、そしてリレーとゲートウェイの独立した信頼ドメインへの運用分離である。