WriteGuard：MCP の「書き込みを許すか」問題に、リスク階層と帰属記録で答える

要約

Cloudflare が 2026-08-05、MCP サーバーに対する共通の統制レイヤー「WriteGuard」をプライベートベータで公開しました。MCP クライアントとサーバーの間に入り、エージェントによる書き込み操作を制御・記録します。

中心にあるのはリスク階層による分類です。MCP サーバーが提供するツールを4段階に分けます。Read Only（読むだけ）、Minimal Impact（影響が小さい書き込み）、Contained Write（影響範囲が限定された書き込み）、Critical（重大な操作）。この分類に対してポリシーを設定し、高リスクの操作は実行前にブロックできます。

2つ目が帰属記録です。実行された操作には「どのエージェントが行ったか」を示すラベルが付き、下流のアプリケーション側でもそれを識別できます。エージェント経由の変更と人間の操作が同じログに混ざって区別できない、という状況を避けるための仕組みです。

3つ目が横断監査です。接続されている複数の MCP サーバーをまたいで書き込み活動を集中的に確認でき、結果は成功 / 失敗 / ブロックに分類されます。

公式が挙げている動機は具体的です。Cloudflare 自身が、エージェントが数千件のチケットを一括クローズしてしまうような事故を防ぐために内製したものだと説明されています。位置づけとしては、書き込み権限を社内展開する前段に置くレイヤーです。

提供は Cloudflare の MCP サーバーポータル経由のプライベートベータで、GA に向けて段階的に拡大予定とされています。

何が変わったか

• MCP のツールを Read Only / Minimal Impact / Contained Write / Critical の4段階リスク階層で分類できるようになった
• 階層ごとにポリシーを設定し、高リスクの書き込み操作を実行前にブロックできる
• 実行された操作にエージェント帰属ラベルが付き、下流アプリケーション側でも識別できる
• 接続された複数の MCP サーバーを横断して書き込み活動を集中監査できる（成功 / 失敗 / ブロック）
• 提供は Cloudflare MCP サーバーポータル経由のプライベートベータ。GA に向けて段階拡大予定

業務インパクト（一般企業向け）

MCP を検討したことがある企業なら、この発表が指している状況にはおそらく心当たりがあります。読み取り専用の MCP は入れられたが、書き込みを許すところで止まっている、という状態です。

止まる理由ははっきりしています。読み取りなら最悪でも情報が漏れるだけですが、書き込みは実データが壊れます。しかもエージェントの失敗は人間の失敗と質が違います。人間が誤ってチケットを閉じるなら1件か2件ですが、エージェントは数千件を一瞬で処理します。公式が挙げている例がまさにこれで、実際に起きうる事故として現実味があります。この差を前にすると、「まず小さく試す」という常套句が機能しません。小さく試したつもりでも、ループが回れば規模は勝手に大きくなるからです。

WriteGuard の答えは、権限をオール・オア・ナッシングで扱わないことです。ツールを4段階に分けて、下から順に解禁する。この考え方自体は目新しいものではなく、権限管理の常識に近いのですが、MCP の世界ではツール単位でこれをやる標準的な手段がありませんでした。サーバーごとに実装がばらつき、統一的に見る場所もない。そこに共通レイヤーを差し込むというのが今回の設計です。

導入判断とは別に、この分類作業自体は今日から始められます。自社が使っている、あるいは使おうとしている MCP サーバーのツールを一覧にして、4段階に振り分けてみる。これをやると、どのツールが Critical に落ちるかが具体的に見え、「そもそもこのツールをエージェントに渡す必要があるのか」という問いが立ちます。ツールを渡さないという選択が一番確実な統制であることも多く、その判断材料になります。

帰属記録のほうは、監査要件がある組織ほど重く効きます。変更履歴に「誰が」が残らないシステムは、内部統制の観点で通りません。エージェントが操作するようになると、ログ上はサービスアカウント名しか残らず、実際にどのエージェントのどの実行だったかが追えない、という事態が起きます。MCP の導入検討時に見落とされやすい観点で、チェックリストに入れておく価値があります。

ただし現時点ではプライベートベータです。導入計画に組み込む段階ではなく、リスク階層の考え方を先に社内の設計指針として持っておき、GA 時に手段として当てるという順序が現実的です。

副業・個人活用視点

個人で MCP 関連の開発や導入支援を請けているなら、ここは提案の武器になる考え方です。

MCP サーバーを作る案件で、機能を実装して終わりにするか、リスク階層まで設計して納品するかで、成果物の性質が変わります。クライアントが本当に不安なのは「エージェントが勝手に何かを壊さないか」であって、ツールが何個あるかではありません。設計段階でツールを4段階に分類し、どこまでを自動実行、どこから人間の承認を挟むかを明示した資料を添えると、それだけで説明の通りが良くなります。この分類は Cloudflare の製品を使わなくてもできます。設計上の考え方だけを借りて、実装は自前の承認フローで組めばよい話です。

自分の作業環境にも同じ整理が使えます。Claude Code や各種エージェントに MCP サーバーを繋いでいるなら、その中に Critical に相当するツールが混ざっていないかを一度見直す価値があります。データベースへの書き込み、外部サービスへの投稿、ファイルの削除。この手のツールを常時接続したまま長時間のエージェント実行を回すのは、想像より危ない状態です。接続するサーバーを作業内容ごとに切り替える、書き込み系は別プロファイルに分ける、といった運用でかなり緩和できます。

発信の題材としても扱いやすいテーマです。「読み取り MCP は入れたが書き込みで止まっている」という状況は多くの人が共有していて、そこに対する具体的な整理の枠組みは需要があります。ただしプライベートベータの製品そのものをレビューする形にすると、手元で検証できないまま書くことになります。製品紹介ではなく設計パターンの解説として書くほうが、内容も持続性も良くなります。GA になってから手順記事を追加する二段構えが安全です。