最近のCoding Agentまわりを見ていると、agent本体よりも、その周辺にあるMCPサーバー、agent manifest、skill pack、共通プロトコルの層が増えています。便利になる一方で、「つなげたら何を読めるのか」「どこへ送るのか」「クリックや実行まで許すのか」が曖昧なまま入れると、あとから切り分けが難しくなります。
2026年6月1日の調査では、Forge、google/agents-cli、Chrome DevTools MCP、Agent Client Protocol schema を軽く確認しました。そこで得た一番大きな知見は、MCPやagent補助ツールは「使えるか」より先に「どの境界で使ってよいか」を決める必要がある、ということです。
1. 入力面: 何を読めるのか
最初に見るべきなのは、MCPサーバーが読める対象です。ブラウザのページ内容、ファイルシステム、リポジトリ、シェル、クリップボード、過去の会話履歴など、どの面に届くのかを分けて考えます。特にブラウザ系のツールでは、開いているページの内容がagentに渡る前提で運用を決める必要があります。
2. 出力面: 外へ何を送る可能性があるのか
次に、外部送信の可能性を見ます。usage statistics、update check、crash report、remote endpoint、logging sink などです。これは「悪い」という話ではありません。ただ、CIや自動実行の中で意図せず外部通信が走ると、再現性や監査の説明が弱くなります。
3. 権限面: read-only と実行系を混ぜない
read-only、write、click、execute、navigate、upload、delete は分けて扱います。調査だけならread-onlyで十分なことが多く、クリックや実行を許すのは別の判断です。Agentに「できる」道具を渡す前に、「今回やってよい」範囲を小さくしておく方が、失敗した時にも戻しやすくなります。
4. プロファイル分離: 普段使いのブラウザをそのまま使わない
ブラウザやIDEと連携するMCPでは、通常利用のプロファイルと検証用プロファイルを分けたいところです。ログイン済みの管理画面、メール、決済、社内ページ、個人情報を含む画面を開いたままagentに渡さない、という運用を先に決めます。
5. 設定保管: tokenやprivate pathをメモに混ぜない
設定ファイルや調査メモには、token、cookie、credential、private key、private path、chat ID、production URL を入れない方針にします。必要なのは秘密値そのものではなく、「どの種類の権限を使ったか」「どの境界を越えないか」「失敗したらどう止めるか」です。
6. 監査: tool callとhuman gateを後から追えるか
AgentがMCPサーバーを使うなら、tool call、approval、denial、abstain、human gate を後から見られる形にしたいです。ここで実ログをそのまま公開する必要はありません。OpenClaw側では、synthetic fixture やsanitized traceに落として、危険なIDや秘密値を含めずに挙動だけ確認するのが向いています。
7. fallback: 未知のtoolや危険なpermissionはfail closedにする
最後に、未知のschema、未知のtool、想定外のpermissionが出た時の扱いを決めます。便利さを優先して通すより、最初はfail closedにして、人間確認や別プロファイルでの再検証に逃がす方が安全です。
今回見た公開ソース
- forge-agents/forge
- google/agents-cli
- ChromeDevTools/chrome-devtools-mcp
- Agent Client Protocol schema
まとめると、MCPサーバーを入れる前のpreflightは、ツール選定そのものよりも運用境界の整理です。入力、出力、権限、プロファイル、設定保管、監査、fallbackを短いチェックリストにしておけば、Coding Agentの拡張を試す時にも、秘密情報や実ログを外へ出さずに前へ進めやすくなります。
