AIがデータを変更する前にMCPクライアントはどう確認するか — 2026年比較

2026年に意味のあるMCPクライアントは、どれもアシスタントが何かを変更するツールを実行する前に確認してきます。答えのこの部分は退屈で、安心できるものです。役に立つのはその先、最初の確認のあとに何が起きるかです。1日に40回も「Allow」を押し続ける人はいません。どのクライアントにも確認を止める方法があり、その方法がどこまで細かいかでクライアントは大きく異なります。

要点をまとめると、Claude Code、Zed、Cursor、Devin Desktopでは個々のMCPツールを名前で事前に許可できます。ChatGPTデスクトップアプリの中核でもあるCodexは、代わりにサーバー自身のラベルから判断できます。read-onlyと記されていないものはすべて確認する、という形です。 VS Codeはダイアログのレベルで両方を行い、さらにワークスペース全体のスイッチを加えています。どの設計も間違いではありませんが、失敗の仕方がそれぞれ違い、気にすべき失敗はサーバーを誰が書いたかによって決まります。

この比較は、ローカルのMCPサーバーを起動できるクライアントの調査と対になるものです。あちらは「そもそも起動するか」に答え、こちらは「アシスタントが何かを変えようと決めたとき、何が起きるか」に答えます。以下の内容はすべて、2026年9月29日に各ベンダーのドキュメントと照らし合わせて確認しました。

結論から

クライアント MCPツールの既定動作 最も細かい恒久的な許可 アノテーションで判断するか
Claude Code 確認する(Manualモード) ツール単位:allow、ask、denyにmcp__server__tool ドキュメントに記載なし
Claude Desktopのコネクタ 確認する ツールまたはカテゴリ単位:Always allow、Needs approval、Blocked ツールを読み取り専用と書き込み/削除に分類
Codex CLI、IDE、ChatGPTデスクトップ モードによる サーバー単位、ツールごとに上書き可 する:writesモード、destructiveヒント
Web版ChatGPT(開発者モード) 書き込みは確認する ツール単位、1つの会話の間だけ する:readOnlyHint
Cursor 確認する server:toolの許可リスト ドキュメントに記載なし
VS Code 確認する(Manual permissions) ツールまたはサーバー単位。セッション、ワークスペース、または常に ドキュメントに記載なし
Zed 確認する(confirm) mcp:server:toolのルール ドキュメントに記載なし
Devin Desktop すべてのMCPツールの前に確認 ツール単位またはサーバー全体。セッションまたは恒久的 ドキュメントに記載なし

意味の大部分は2つの列が担っています。「最も細かい恒久的な許可」は、shareを信頼せずにsearchだけを信頼できるかどうかを示します。「アノテーションで判断するか」は、その切り分けをクライアントが代わりにやってくれるかどうか、つまりサーバーが自分自身について書いたラベルを使うかどうかを示します。

各MCPクライアントでツールをどこまで細かく事前許可できるか
どのクライアントも既定で確認する。違うのは、確認をどこまで狭く止められるか。

CodexとChatGPTデスクトップアプリ:4つのモードとラベル

Codexの設計は最も明示的です。ChatGPTデスクトップアプリ、Codex CLI、IDE拡張は1つの設定ファイルを共有しているので、この設計は3つすべてに当てはまります。各MCPサーバーにはdefault_tools_approval_modeがあり、どのツールもtools.<tool>.approval_modeでそれを上書きできます。ドキュメントに記載された値はauto、prompt、writes、approveです。

興味深いのはwritesです。OpenAIの言葉では、このモードは「read-onlyと記されていないツールについて確認する」ものです。検索は黙って実行され、それ以外はすべて止まって確認を求めます。アノテーションがまったくないツールは書き込みとして扱われます。サーバーが何も言わないときの安全な既定値です。モードに加えて、Codexの承認に関するドキュメントによれば、destructiveのアノテーションを宣言しているMCPツールの呼び出しは、読み取りのアノテーションも同時に宣言していない限り、常に承認が必要です。

古い設定を使っているなら知っておきたい変更が1つあります。Codexはapproval_policy = "untrusted"をサポートしなくなり、この廃止された設定があるとクライアントが起動しないことがあります。プロジェクトの信頼は、現在はプロジェクトのtrust_levelで設定します。

Web版ChatGPTも同じ原則で動きます。Pro、Plus、Business、Enterprise、Educationのアカウントで使える開発者モードでは、「書き込み操作は既定で確認が必要」です。ChatGPTはreadOnlyHintを尊重し、それのないツールはすべて書き込みとして扱います。選択はツールごとに会話の残りの間だけ記憶でき、それ以上は続きません。

Claude CodeとClaude Desktop:名前で書くルール

Claude Codeは判断にアノテーションを読みません。使うのはallow、ask、denyの3つのリストに書く権限ルールで、deny、ask、allowという固定の順序で評価されます。MCPツールの名前はmcp__<server>__<tool>なので、mcp__notes__searchは1つのツールを、mcp__notes__get_*は一群のツールを許可し、mcp__notesまたはmcp__notes__*はサーバー全体を対象にします。既定のモードは現在Manualと表示され、より緩いモードにはacceptEdits、あなたの代わりに分類器が操作を審査するauto、そしてbypassPermissionsがあります。

安全寄りの細部が2つあります。プロジェクトにコミットされた.mcp.jsonのサーバーは、そもそも接続する前にあなたの承認が必要です。また、サーバーの作者はツールに_meta["anthropic/requiresUserInteraction"]を付けることができ、そうするとClaude CodeはacceptEdits、auto、bypassPermissionsであっても、呼び出しのたびに確認を表示します。

Claude Desktopのコネクタ設定(Customize → Connectors)は、サーバーのツールを読み取り専用や書き込み/削除といったカテゴリに分け、カテゴリごと、または個々のツールごとにAlways allow、Needs approval、Blockedを設定できます。

Cursor、VS Code、Zed、Devin Desktop:エディタ

Cursorははっきりこう書いています。「Cursorは既定で、MCPツールを使う前に承認を求める」。MCPはターミナルコマンドと同じRun Modesに従います。Auto-reviewでは許可リストにある呼び出しはすぐに実行され、それ以外はすべて分類モデルを通ります。Run Everythingはすべてのツール呼び出しを確認なしで実行します。許可リストはワイルドカード付きのserver:tool形式のエントリを受け付けます。落とし穴が1つあります。サーバーのツール許可リストを空のままにすると、そのサーバーのすべてのツールが許可されます。

VS Codeは既定のレベルをManual permissionsと呼んでいます。自動承認されていないものはすべて確認が必要です。ダイアログでは1回だけの使用を承認するか、セッション、ワークスペース、または今後のすべての呼び出しに対して承認を与えることができ、ツール単位の承認はMCPサーバーごとに設定できます。Allow allは確認を完全になくし、モデルが各呼び出しを判断するAssisted permissionsは実験的と記されています。注意すべき例外が1つあります。エージェントプラグインに同梱されたMCPサーバーは「プラグインをインストールした時点で暗黙的に信頼され」、起動時の個別の信頼確認を飛ばします。プラグインのインストールそのものが信頼の判断なのです。

Zedは最も読みやすいルール体系を持っています。agent.tool_permissions.defaultは変更しない限りconfirmで、代わりの値はallowとdenyです。ルールではMCPツールをmcp:<server>:<tool_name>と書き、常に許可、常に確認、常に拒否のいずれかを設定でき、拒否が優先されます。確認ダイアログ自体は「Allow once」「Deny once」、そしてツールに対する「Always for」を提示しますが、MCPツールではツール単位の選択肢しかありません。

Devin Desktop(旧Windsurf)は、名前と一緒にモデルも変えました。エージェントのDevin Localは「自動実行レベルを、よりきめ細かい権限システムに置き換え」ており、既定ではあらゆるMCPツールを呼び出す前に確認します。確認ダイアログからは、1つのツールまたはそのサーバーのすべてのツールを、セッションの間または恒久的に許可でき、Denyルールは何よりも優先されます。Enterpriseの管理者は、特定のサーバーやツールを組織全体に対して事前に承認できます。

アノテーションにできること、できないこと

MCP仕様は、サーバーが自分のツールを説明するための語彙を用意しています。readOnlyHint、destructiveHint、idempotentHint、openWorldHintです。同時に、クライアントがそれをどこまで信じるべきかも定めています。クライアントは「信頼できるサーバーから来たものでない限り、ツールアノテーションを信頼できないものとして扱わなければならない」。さらに、人間が介在し、どのツール呼び出しでも拒否できるようにすることを求めています。

これで上の2つの設計の位置づけがはっきりします。Codexのwritesモードのようにアノテーションで判断するクライアントは、信頼しているサーバーとなら便利です。設定は1行で済み、サーバーが追加する新しい書き込み系ツールは自動的に確認の対象になります。信頼していないサーバーとでは、安全性はサーバーの正直さとまったく同じです。データを変更するのに自分を読み取り専用と称するツールは、確認なしで実行されます。

Claude CodeやZedのようにツール名を書かせるクライアントは、逆の形で失敗します。サーバーが何を主張しようと気にしませんが、アップデートで追加された新しい書き込み系ツールがカバーされるのは、ルールがそれを捉えるほど広かった場合だけです。あるいは、それを取りこぼすほど狭く、確認に戻る場合です。名前ベースのルールは「このサーバーを許可する」ではなく、「これらの読み取りを許可する」と書くのが最も安全です。

MCPの承認の3つの層:サーバーのヒント、クライアントのポリシー、そしてあなたのクリック
アノテーションは確認の判断材料になるが、確認の代わりにはならない。

読み書きするサーバーのための妥当な設定

クライアントが何であれ、次の4つの習慣でリスクの大部分をカバーできます。

  1. サーバー全体ではなく、読み取りを名前で許可する。 文字起こしの検索や閲覧はアシスタントが一日中していることで、確認のコストが最も高く、守るものが最も少ない場面です。
  2. 共有や置き換えを行うものには確認を残す。 他の人への公開とテキストの上書きは、値を元に戻すだけでは取り消せない2種類の変更です。
  3. アノテーションに頼るのは信頼しているサーバーだけにする。 使ったことのないレジストリのサーバーについては、代わりにルールでツール名を明示する。
  4. あまり信頼していないクライアントには読み取り専用のインスタンスを渡す。 サーバーが読み取り専用モードに対応していれば、あるクライアントは読み取りに限定し、別のクライアントにはフルアクセスを残せます。

危険信号:ツールリストが空のサーバーを含むCursorの許可リスト、チームの誰もレビューしていないVS Codeプラグイン、そして名前を読んでいないツールに対して押された「Always allow」。

データを変更するMCPツールを承認するための4つの習慣
読み取りは事前に許可し、共有や置き換えには確認を残す。

Speak-Yではどうなっているか

Speak-YのMCPサーバーは、どちらの種類のクライアントにも合うように作られています。読み取り系のツール、つまり録音の検索、文字起こし・要約・アクションアイテムの閲覧、タグやチャンネルの一覧はreadOnlyHintを持ち、ライブラリをあなたのマシンから直接読み取ります。何かを変更するツール、つまりタグ、タイトル、話者名、再文字起こし、チームチャンネルへの共有は、データを変更するものとして宣言され、起動中のSpeak-Yアプリを経由します。そこではすべての呼び出しが記録され、オフにすることもできます。

そのうち2つには意図的にdestructiveHintを付けています。retranscribeは、手で行った修正も含めて録音の現在のテキストを置き換えるため。share_to_channelは、取り消す前に同僚が録音を読むかもしれないためです。Codexのwritesモードでは、これらの確認は何も設定しなくても行われます。Claude CodeやZedでは、読み取り系のツールを名前で許可し、残りはaskのままにしておきます。

クライアントに読み取りだけをさせたい場合は、そのクライアントの設定でサーバーを--read-only付きで起動します。変更系のツールはそのクライアントにはそもそも公開されないので、うっかり承認してしまうものがありません。導入は設定 → 連携からワンクリックで、MCPサーバーはFreeを含むすべてのプランで無料です。

MCPクライアントが接続されたSpeak-Yの設定 → 連携
読み取りはreadOnlyHintを持ちローカルで実行。変更はアプリを経由し、記録され、オフにできる。

承認の確認は、書き込みのできるアシスタントを安全に使うための仕組みの1つにすぎません。ほかの仕組み、つまりどの変更が元に戻せるか、ログに何が残るかについてはMCPの書き込みアクセスを安全にするもので扱っています。クライアントごとの設定はMCPドキュメントにあります。

FAQ

MCPクライアントは、データを変更するツールを実行する前に確認してきますか

主要なクライアントはいずれも既定で確認します。Claude Code、Cursor、VS Code、Zed、Devin Desktopは、事前に許可するまでMCPツールの実行前に必ず確認し、ChatGPTの開発者モードはread-onlyと記されていないすべてのツールに確認を求めます。違うのは、その後どこまで細かく事前許可できるかです。ツール単位か、サーバー単位か、セッション単位か、恒久的か。2026年9月29日時点の情報です。

確認するかどうかの判断にreadOnlyHintアノテーションを使うMCPクライアントはどれですか

明示的に使っているのはCodexとChatGPTです。Codexのwrites承認モードはread-onlyと記されていないツールについて確認し、自らdestructiveと宣言したツールの前では必ず確認します。ChatGPTの開発者モードはreadOnlyHintのないツールをすべて書き込み操作として扱います。Claude Code、Cursor、VS Code、Zedは、アノテーションを承認の判断材料としてドキュメントに記載していません。ルールは自分でツール名を使って書きます。

読み取り系のツールは自動で許可し、書き込みの前だけ確認させることはできますか

できます。この比較のすべてのクライアントで可能ですが、仕組みは異なります。Claude Code、Zed、Cursor、Devin Desktopでは、Claude Codeならmcp__server__search、Zedならmcp:server:searchのように、読み取り系のツールを名前で許可します。Codexではwritesモードの1行で済みますが、サーバーが読み取り系ツールを正直に宣言していることが前提になります。

readOnlyHintのようなツールアノテーションはセキュリティ上の保証になりますか

なりません。MCP仕様は、信頼できるサーバーから来たものでない限り、クライアントはツールアノテーションを信頼できないものとして扱わなければならないと定めています。書き込み系のツールを読み取り専用と記したサーバーは、そのヒントに基づくクライアントのポリシーをすべて無効にします。アノテーションはすでに信頼しているサーバーのための便宜と考え、信頼していないサーバーについてはルールの中でツール名を明示してください。

会議メモのサーバーをAIアシスタントにつなぐ最も安全な方法は何ですか

事前に許可するのは読み取り系のツールだけにし、データを変更するものにはすべて確認を残し、あまり信頼していないクライアントには読み取り専用のインスタンスを渡します。Speak-Yなら、あるクライアントの設定でサーバーを--read-only付きで起動すると、そのクライアントからは変更系のツールが完全に消えます。一方、別のクライアントは独自の確認付きでフルアクセスを保てます。